From enum-admin@ietf.org  Tue Jul  4 06:38:09 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26318
	for <enum-archive@odin.ietf.org>; Tue, 4 Jul 2000 06:38:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14256;
	Tue, 4 Jul 2000 06:35:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14227
	for <enum@ns.ietf.org>; Tue, 4 Jul 2000 06:35:18 -0400 (EDT)
Received: from p-voyageur.issy.cnet.fr (p-voyageur.issy.cnet.fr [139.100.0.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26305
	for <enum@ietf.org>; Tue, 4 Jul 2000 06:35:18 -0400 (EDT)
Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0)
	id <NX4FMP4A>; Tue, 4 Jul 2000 12:35:06 +0200
Message-ID: <98388C05D464D111B61800805F1504160123E7EF@p-ibis.issy.cnet.fr>
From: BARNOLE Valerie FTRD/DAC/ISS <valerie.barnole@rd.francetelecom.fr>
To: "'Richard Shockey'" <rshockey@ix.netcom.com>
Cc: ENUM List Group <enum@ietf.org>
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.int 
	?
Date: Tue, 4 Jul 2000 12:35:04 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA14228
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

Richard,

My apologies for intruding lately on the .int topic.
It seems that you suggest to remove all references to .int and replace it
with .arpa.
Does it mean that you replace .e164.int with .e164.arpa ?
To my knowledge (probably not big enough !), if it might come difficult to
use e164.int when the ICANN decide to move infrastructure delegations from
.int to .arpa (is it already decided and done ?), it seems that there is no
real reason to use .e164.arpa instead of e164.itu.int. So, wouldn't it be
more neutral and generic to use .foo, as you suggested in an earlier mail ?
 

Thanks for your highlights on this issue,

Valerie.

end of message
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

Valérie Barnole
FTR&D/DAC/ARS
tel. : + 33 1 45 29 58 39
fax : + 33 1 46 29 31 42

valerie.barnole@francetelecom.fr




_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Tue Jul  4 12:01:38 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28690
	for <enum-archive@odin.ietf.org>; Tue, 4 Jul 2000 12:01:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16901;
	Tue, 4 Jul 2000 12:00:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16804
	for <enum@ns.ietf.org>; Tue, 4 Jul 2000 12:00:00 -0400 (EDT)
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28621
	for <enum@ietf.org>; Tue, 4 Jul 2000 11:59:55 -0400 (EDT)
Received: from computer.ix.netcom.com ([209.138.5.244])
	by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA19205;
	Tue, 4 Jul 2000 11:59:33 -0400 (EDT)
Message-Id: <4.3.1.2.20000704102505.00dc53a0@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 04 Jul 2000 11:00:35 -0500
To: BARNOLE Valerie FTRD/DAC/ISS <valerie.barnole@rd.francetelecom.fr>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or
  .e;164.itu.int  ?
Cc: ENUM List Group <enum@ietf.org>
In-Reply-To: <98388C05D464D111B61800805F1504160123E7EF@p-ibis.issy.cnet.
 fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA16805
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

At 12:35 PM 7/4/2000 +0200, BARNOLE Valerie FTRD/DAC/ISS wrote:
>Richard,
>
>My apologies for intruding lately on the .int topic.
>It seems that you suggest to remove all references to .int and replace it
>with .arpa.
>Does it mean that you replace .e164.int with .e164.arpa ?

>To my knowledge (probably not big enough !), if it might come difficult to
>use e164.int when the ICANN decide to move infrastructure delegations from
>.int to .arpa (is it already decided and done ?),


Yes  the Internet Architecture Board has designated .arpa for the use of 
Internet infrastructure issues and has issued a statement to that 
effect.  see below.

>  it seems that there is no
>real reason to use .e164.arpa instead of e164.itu.int. So, wouldn't it be
>more neutral and generic to use .foo, as you suggested in an earlier mail ?

I believe it is fair to assume that e164.xxx will go into .arpa so I've 
asked the authors of the drafts to reflect this fact.


>
>
>Thanks for your highlights on this issue,
>
>Valerie.
>
>end of message
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>Valérie Barnole
>FTR&D/DAC/ARS
>tel. : + 33 1 45 29 58 39
>fax : + 33 1 46 29 31 42
>
>valerie.barnole@francetelecom.fr



May 10, 2000 IAB Statement on Infrastructure Domain and Subdomains Over the 
last several months, the IAB has been reviewing, and discussing with ICANN 
and other parties, the handling of various Internet Protocol-related 
infrastructure components that the community has concluded should be placed 
into the DNS. Historically, the most visible infrastructure domain has been 
the IPv4 address reverse-mapping domain. This domain was placed in 
"in-addr.arpa" as part of the initial ARPANET transition strategy from host 
table naming (see, e.g., RFC 881). It became the only active subdomain of 
that domain as the .arpa names that were also part of the transition were 
gradually removed. Other infrastructure domains have been placed under the 
"INT" TLD or under various organizational names. It is in the interest of 
general Internet stability, adequate attention to placement of secondary 
DNS servers, and administrative cleanliness, to start rationalizing this 
situation by locating new infrastructure subdomains in a single domain and 
migrating existing ones to it as appropriate. It appears that our original 
infrastructure domain, "ARPA", redesignated from an abbreviation for 
"ARPANET" to an acronym for "Address and Routing Parameters Area" is best 
suited for this purpose, rather than our getting further entangled with 
issues about what is appropriately an international organization and how 
that domain should be maintained. Consequently, we recommend the following 
to the IESG: (i) No new infrastructure domains should be added to ".INT", 
and protocols that need specific domain roots should be rooted elsewhere 
(see ii) (ii) For the reasons discussed above, new infrastructure domains 
arising from IETF protocols should be allocated in ".ARPA", with that TLD 
to be managed (as essentially it always has been) by the IANA as one of its 
protocol registry tasks. The US Department of Commerce (which reviews TLD 
designations and authorizes ICANN to add tasks to the IANA work list) has 
approved of this use, at our request. (iii) We recommend that IETF-related 
infrastructure subdomains now under .INT be reviewed as to whether the 
costs of moving them exceed the risks of leaving them in place. ICANN is 
committed to the stability of those subdomains for however long they need 
to be in place, with guidance from IAB (or some other body of the IETF's 
choosing) as to their management; we believe that we can work successfully 
with them on transition plans (or "freeze delegation in place" ones) as 
their plans for INT administration evolve. However, we believe that it is 
quite important that the new IPv6 reverse-mapping domain, and any other 
significant new IETF name spaces, be allocated in the ".ARPA" space and not 
in ".INT". John Klensin, for the IAB




 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Tue Jul  4 12:24:56 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28842
	for <enum-archive@odin.ietf.org>; Tue, 4 Jul 2000 12:24:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17248;
	Tue, 4 Jul 2000 12:24:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17223
	for <enum@ns.ietf.org>; Tue, 4 Jul 2000 12:24:29 -0400 (EDT)
Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28833
	for <enum@ietf.org>; Tue, 4 Jul 2000 12:24:29 -0400 (EDT)
Received: from computer.ix.netcom.com ([209.138.5.244])
	by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA03983
	for <enum@ietf.org>; Tue, 4 Jul 2000 12:24:12 -0400 (EDT)
Message-Id: <4.3.1.2.20000704111838.00cdadc0@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 04 Jul 2000 11:25:01 -0500
To: enum@ietf.org
From: Richard Shockey <rshockey@ix.netcom.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_6327745==_.ALT"
Subject: [Enum] Agenda for ENUM at IETF 48  Pittsburgh..
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

--=====================_6327745==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

I would like to solicit comments from the group on what issues need to be 
discussed at IETF 48 in Pittsburgh and find out who may be submitting 
additional drafts and if they want time to discuss them.

We already have one request to review Number Portability issues and current 
ITU work in numbering issues.

I have requested a 2 1/2 hour slot so there will be sufficient time for a 
couple of discussions ...so... please indicate your interest _now_.

A reminder of the dates..

IMPORTANT MEETING DATES
May 24 - Working Group and BOF scheduling begins
June 2- Registration begins
July 7 - Working Group and BOF scheduling closes at 17:00 ET
July 14 - Internet-Draft submission cutoff date at 17:00 ET
July 21 - Pre-Registration and Pre-payment cutoff date at 12:00 ET
July 24 - Working Group agendas due date by 17:00 ET
July 26 - Registration Cancellation cutoff date by 17:00 ET
July 30 - August 4, 2000 - 48th IETF Meeting
September 1 - Proceedings submission cutoff date by 17:00 ET
All times are in US Eastern Time



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 
--=====================_6327745==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
I would like to solicit comments from the group on what issues need to be
discussed at IETF 48 in Pittsburgh and find out who may be submitting
additional drafts and if they want time to discuss them.<br>
<br>
We already have one request to review Number Portability issues and
current ITU work in numbering issues.<br>
<br>
I have requested a 2 1/2 hour slot so there will be sufficient time for a
couple of discussions ...so... please indicate your interest _now_.<br>
<br>
A reminder of the dates..<br>
<br>
<b>IMPORTANT MEETING DATES<br>
</b>May 24 - Working Group and BOF scheduling begins <br>
June 2- Registration begins <br>
July 7 - Working Group and BOF scheduling closes at 17:00 ET <br>
July 14 - Internet-Draft submission cutoff date at 17:00 ET <br>
July 21 - Pre-Registration and Pre-payment cutoff date at 12:00 ET <br>
July 24 - Working Group agendas due date by 17:00 ET <br>
July 26 - Registration Cancellation cutoff date by 17:00 ET <br>
July 30 - August 4, 2000 - 48th IETF Meeting <br>
September 1 - Proceedings submission cutoff date by 17:00 ET <br>
All times are in US Eastern Time <br>
<br>
<br>
<br>
<div>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;</div>
<div>Please Note New Contact Information:</div>
<br>
<div>Richard Shockey</div>
<div>Shockey Consulting
LLC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</div>
<div>5237 Sutherland</div>
<div>St. Louis, MO 63109</div>
<div>Voice 314.503.0640</div>
<div>eFAX Fax to EMail 815.333.1237 (Preferred for Fax)</div>
<div>INTERNET Mail &amp; IFAX : rshockey@ix.netcom.com</div>
&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;
</html>

--=====================_6327745==_.ALT--


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Tue Jul  4 12:25:08 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28854
	for <enum-archive@odin.ietf.org>; Tue, 4 Jul 2000 12:25:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17296;
	Tue, 4 Jul 2000 12:24:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17265
	for <enum@ns.ietf.org>; Tue, 4 Jul 2000 12:24:34 -0400 (EDT)
Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28835
	for <enum@ietf.org>; Tue, 4 Jul 2000 12:24:32 -0400 (EDT)
Received: from computer.ix.netcom.com ([209.138.5.244])
	by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA19242;
	Tue, 4 Jul 2000 12:24:08 -0400 (EDT)
Message-Id: <4.3.1.2.20000704111333.00d0a820@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 04 Jul 2000 11:18:26 -0500
To: enum@ietf.org
From: Richard Shockey <rshockey@ix.netcom.com>
Cc: Scott Bradner <sob@harvard.edu>, mankin@east.isi.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Enum] Last Call ENUM Requirements
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org


I think we can begin the process of Last Call on our Requirements document.

Anne posted a revised document several weeks ago and I have not seen any 
additional discussion of the document...


	Title		: ENUM Requirements
	Author(s)	: A. Brown
	Filename	: draft-ietf-enum-rqmts-01.txt
	Pages		:
	Date		: 13-Jun-00
	
This paper defines the requirements for 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. There are many possible protocols that can be
considered for a telephone number mapping service.  The purpose of
this document is to focus discussion on a DNS-based solution.  The
intention is to enumerate the expectations of such a solution and to
clarify the scope.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-01.txt


The intent of the last call is to solicit comments before submitting the ID 
to the IESG as a Proposed Standard.

The purpose of a working group Last Call is in the style of "speak now or
forever hold your peace" in case there are fundamental objections which have
not gotten previous or adequate discussion, or minor errors which need
correction.

Work group last call will extend for two weeks from today July 5 to to at 
least July 21 th though we can modify that if new issues come up.


Your co-chair.


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul  5 04:20:32 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18662
	for <enum-archive@odin.ietf.org>; Wed, 5 Jul 2000 04:20:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00015;
	Wed, 5 Jul 2000 04:16:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29986
	for <enum@ns.ietf.org>; Wed, 5 Jul 2000 04:16:47 -0400 (EDT)
Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18652
	for <enum@ietf.org>; Wed, 5 Jul 2000 04:16:44 -0400 (EDT)
Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0)
	id <3JZBHLB2>; Wed, 5 Jul 2000 10:16:30 +0200
Message-ID: <98388C05D464D111B61800805F1504160123E7F3@p-ibis.issy.cnet.fr>
From: BARNOLE Valerie FTRD/DAC/ISS <valerie.barnole@rd.francetelecom.fr>
To: "'Richard Shockey'" <rshockey@ix.netcom.com>
Cc: ENUM List Group <enum@ietf.org>
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.int 
	 ?
Date: Wed, 5 Jul 2000 10:16:30 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA29987
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

Richard,
thank you for your answer and the provided information.
I understand that e164.int has to become e164.arpa. But as it were not
decided that e164.int would be the adhoc subdomain, and as you wisely said
that this choice was not under the purview of ENUM group, I thought that
.foo would have been an easy way to escape political issue of this subdomain
(why not e164.itu.int ? at the IETF/ITU-T SG2 WP1/2 call conference, this
possibility was not excluded). A naive and straight question : in case the
ENUM document quotes e164.arpa instead of .foo, does it cut the way to
e164.itu.int ?

Valerie.

end of message
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

Valérie Barnole
FTR&D/DAC/ARS
tel. : + 33 1 45 29 58 39
fax : + 33 1 46 29 31 42

valerie.barnole@francetelecom.fr



-----Message d'origine-----
De: Richard Shockey [mailto:rshockey@ix.netcom.com]
Date: mardi 4 juillet 2000 18:01
À: BARNOLE Valerie FTRD/DAC/ISS
Cc: ENUM List Group
Objet: RE: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.int
?


At 12:35 PM 7/4/2000 +0200, BARNOLE Valerie FTRD/DAC/ISS wrote:
>Richard,
>
>My apologies for intruding lately on the .int topic.
>It seems that you suggest to remove all references to .int and replace it
>with .arpa.
>Does it mean that you replace .e164.int with .e164.arpa ?

>To my knowledge (probably not big enough !), if it might come difficult to
>use e164.int when the ICANN decide to move infrastructure delegations from
>.int to .arpa (is it already decided and done ?),


Yes  the Internet Architecture Board has designated .arpa for the use of 
Internet infrastructure issues and has issued a statement to that 
effect.  see below.

>  it seems that there is no
>real reason to use .e164.arpa instead of e164.itu.int. So, wouldn't it be
>more neutral and generic to use .foo, as you suggested in an earlier mail ?

I believe it is fair to assume that e164.xxx will go into .arpa so I've 
asked the authors of the drafts to reflect this fact.


>
>
>Thanks for your highlights on this issue,
>
>Valerie.
>
>end of message
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>Valérie Barnole
>FTR&D/DAC/ARS
>tel. : + 33 1 45 29 58 39
>fax : + 33 1 46 29 31 42
>
>valerie.barnole@francetelecom.fr



May 10, 2000 IAB Statement on Infrastructure Domain and Subdomains Over the 
last several months, the IAB has been reviewing, and discussing with ICANN 
and other parties, the handling of various Internet Protocol-related 
infrastructure components that the community has concluded should be placed 
into the DNS. Historically, the most visible infrastructure domain has been 
the IPv4 address reverse-mapping domain. This domain was placed in 
"in-addr.arpa" as part of the initial ARPANET transition strategy from host 
table naming (see, e.g., RFC 881). It became the only active subdomain of 
that domain as the .arpa names that were also part of the transition were 
gradually removed. Other infrastructure domains have been placed under the 
"INT" TLD or under various organizational names. It is in the interest of 
general Internet stability, adequate attention to placement of secondary 
DNS servers, and administrative cleanliness, to start rationalizing this 
situation by locating new infrastructure subdomains in a single domain and 
migrating existing ones to it as appropriate. It appears that our original 
infrastructure domain, "ARPA", redesignated from an abbreviation for 
"ARPANET" to an acronym for "Address and Routing Parameters Area" is best 
suited for this purpose, rather than our getting further entangled with 
issues about what is appropriately an international organization and how 
that domain should be maintained. Consequently, we recommend the following 
to the IESG: (i) No new infrastructure domains should be added to ".INT", 
and protocols that need specific domain roots should be rooted elsewhere 
(see ii) (ii) For the reasons discussed above, new infrastructure domains 
arising from IETF protocols should be allocated in ".ARPA", with that TLD 
to be managed (as essentially it always has been) by the IANA as one of its 
protocol registry tasks. The US Department of Commerce (which reviews TLD 
designations and authorizes ICANN to add tasks to the IANA work list) has 
approved of this use, at our request. (iii) We recommend that IETF-related 
infrastructure subdomains now under .INT be reviewed as to whether the 
costs of moving them exceed the risks of leaving them in place. ICANN is 
committed to the stability of those subdomains for however long they need 
to be in place, with guidance from IAB (or some other body of the IETF's 
choosing) as to their management; we believe that we can work successfully 
with them on transition plans (or "freeze delegation in place" ones) as 
their plans for INT administration evolve. However, we believe that it is 
quite important that the new IPv6 reverse-mapping domain, and any other 
significant new IETF name spaces, be allocated in the ".ARPA" space and not 
in ".INT". John Klensin, for the IAB




 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul  5 09:14:08 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00809
	for <enum-archive@odin.ietf.org>; Wed, 5 Jul 2000 09:14:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02649;
	Wed, 5 Jul 2000 09:11:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02614
	for <enum@ns.ietf.org>; Wed, 5 Jul 2000 09:10:59 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00505
	for <enum@ietf.org>; Wed, 5 Jul 2000 09:10:55 -0400 (EDT)
From: john.loughney@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nok.ntc.nokia.com [131.228.10.153])
	by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id QAA11866
	for <enum@ietf.org>; Wed, 5 Jul 2000 16:10:54 +0300 (EETDST)
Received: from esebh03nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e40a99764d388262ed@esvir04nok.ntc.nokia.com>;
 Wed, 5 Jul 2000 15:55:50 +0300
Received: by esebh03nok with Internet Mail Service (5.5.2650.10)
	id <N63RY2QG>; Wed, 5 Jul 2000 15:55:50 +0300
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DECB2@eseis04nok>
To: rshockey@ix.netcom.com
Cc: enum@ietf.org
Subject: RE: [Enum] Agenda for ENUM at IETF 48  Pittsburgh..
Date: Wed, 5 Jul 2000 15:55:48 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Richard,

I would like to solicit comments from the group on what issues need to be
discussed at IETF 48 in Pittsburgh and find out who may be submitting
additional drafts and if they want time to discuss them.

[<JAL> ] James Yu and myself are currently writing a draft which discusses
roaming support for devices with e.164 numbers.  There are a number of
issues to address before the draft is finalized - hopefully we'll have it
submitted by the deadline.  
 
Would it be possible to get a short slot to discuss this draft in
Pittsburgh?
 
best regards,
John Loughney 


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul  5 10:11:24 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04471
	for <enum-archive@odin.ietf.org>; Wed, 5 Jul 2000 10:11:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03267;
	Wed, 5 Jul 2000 10:09:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03236
	for <enum@ns.ietf.org>; Wed, 5 Jul 2000 10:09:36 -0400 (EDT)
Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04303
	for <enum@ietf.org>; Wed, 5 Jul 2000 10:09:34 -0400 (EDT)
Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id JAA07107; Wed, 5 Jul 2000 09:59:05 -0400 (EDT)
Date: Wed, 5 Jul 2000 09:59:05 -0400
From: Michael Mealling <michael@bailey.dscga.com>
To: "Robert H. Walter" <rwalter@netnumber.com>
Cc: "Pfautz, Penn L, NNAD" <ppfautz@att.com>,
        Richard Shockey <rshockey@ix.netcom.com>,
        ENUM List Group <enum@ietf.org>
Subject: Re: [Enum] FW: Last Call or New Draft? - Portability
Message-ID: <20000705095905.A7103@bailey.dscga.com>
Reply-To: michaelm@netsol.com
References: <395ABA5E.4B4050F7@dynamicsoft.com> <NDBBKBNFDKEGNGMMLPBEEEAMCCAA.rwalter@netnumber.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.2i
In-Reply-To: <NDBBKBNFDKEGNGMMLPBEEEAMCCAA.rwalter@netnumber.com>; from rwalter@netnumber.com on Thu, Jun 29, 2000 at 10:46:40AM -0400
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

On Thu, Jun 29, 2000 at 10:46:40AM -0400, Robert H. Walter wrote:
> Richard Shockey wrote:
> > Looking good .... I've changed .int to .arpa
> > 
> > >      $ORIGIN     9.0.3.5.7.6.8.2.9.7.1.e164.arpa.
> > >      IN NAPTR 10 10 "a" "sip+N2R"      "" "sip:jenny@sipservice.com"
> > >      IN NAPTR 10 10 "a" "smtp+N2R"     "" "mailto:jenny@ispa.net"
> > >      IN NAPTR 10 10 "a" "http+N2R"     "" "http://jenny.ispa.net"
> > >      IN NAPTR 10 10 "a" "tel+N2R"      "" "tel:+1-792-867-5309"
> > >
> > >     Because this client knows sip, the first record above is selected,
> > >     and the SIP URI is extracted, and used according to SIP specifications.
> > 
> > Ta Da!..  ...if you use NAPTR records. Now we should see how our SIP
> > colleagues think about this scenerio.
> 
> Conceptually the works!, however the example NAPTR RRs are not accurately
> defined.  The replacement field MUST be a domain name and the above
> examples use URI's.
> 
> Mike Mealling wrote in a prevous post on Wed 6/28/00 10:01 AM:
> 
> > The Application gets to define the Appliction Unique String
> > which is the thing the algoirthm works on to find out specific
> > syntactic rules for delegation.
> > ...
> > In the case of an ENUM application the Unique String would be
> > the e.164 phone number and the output would be URIs that
> > identify services.
> 
> Mike would you mind shedding light on what the NAPTR RR's would
> look like given the unique string of 17928675309?  Your assistance
> is greatly appreciated.

Sure. Very similar actually:
 
 
$ORIGIN     9.0.3.5.7.6.8.2.9.7.1.e164.arpa.
IN NAPTR 10 10 "u" "sip+N2R"      "!^.*$!sip:jenny@sipservice.com!" .
IN NAPTR 10 10 "u" "smtp+N2R"     "!^.*$!mailto:jenny@ispa.net" .
IN NAPTR 10 10 "u" "http+N2R"     "!^.*$!http://jenny.ispa.net" .
IN NAPTR 10 10 "u" "tel+N2R"      "!^.*$!tel:+1-792-867-5309" .

Patrik has some other examples but I'll let him forward them when
he's done...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul  5 12:10:50 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09977
	for <enum-archive@odin.ietf.org>; Wed, 5 Jul 2000 12:10:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04885;
	Wed, 5 Jul 2000 12:09:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04854
	for <enum@ns.ietf.org>; Wed, 5 Jul 2000 12:09:50 -0400 (EDT)
Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09880
	for <enum@ietf.org>; Wed, 5 Jul 2000 12:09:46 -0400 (EDT)
Received: from computer.ix.netcom.com ([209.138.155.95])
	by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA15058;
	Wed, 5 Jul 2000 12:08:43 -0400 (EDT)
Message-Id: <4.3.1.2.20000705110828.00b46a40@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 05 Jul 2000 11:09:46 -0500
To: john.loughney@nokia.com
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: RE: [Enum] Agenda for ENUM at IETF 48  Pittsburgh..
Cc: enum@ietf.org
In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE1031DECB2@eseis04nok>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 03:55 PM 7/5/2000 +0300, john.loughney@nokia.com wrote:
>Hi Richard,
>
>I would like to solicit comments from the group on what issues need to be
>discussed at IETF 48 in Pittsburgh and find out who may be submitting
>additional drafts and if they want time to discuss them.
>
>[<JAL> ] James Yu and myself are currently writing a draft which discusses
>roaming support for devices with e.164 numbers.  There are a number of
>issues to address before the draft is finalized - hopefully we'll have it
>submitted by the deadline.
>
>Would it be possible to get a short slot to discuss this draft in
>Pittsburgh?


At this time I don't see a problem with that providing , of course, that 
you can get the ID posted in time.


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul  5 12:21:05 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10392
	for <enum-archive@odin.ietf.org>; Wed, 5 Jul 2000 12:21:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05089;
	Wed, 5 Jul 2000 12:20:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05064
	for <enum@ns.ietf.org>; Wed, 5 Jul 2000 12:20:27 -0400 (EDT)
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10348
	for <enum@ietf.org>; Wed, 5 Jul 2000 12:20:26 -0400 (EDT)
Received: from computer.ix.netcom.com ([209.138.155.95])
	by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA06664;
	Wed, 5 Jul 2000 12:20:16 -0400 (EDT)
Message-Id: <4.3.1.2.20000705111038.00b54460@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 05 Jul 2000 11:21:20 -0500
To: BARNOLE Valerie FTRD/DAC/ISS <valerie.barnole@rd.francetelecom.fr>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or
  .e;164.itu.int  ?
Cc: ENUM List Group <enum@ietf.org>
In-Reply-To: <98388C05D464D111B61800805F1504160123E7F3@p-ibis.issy.cnet.
 fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 10:16 AM 7/5/2000 +0200, BARNOLE Valerie FTRD/DAC/ISS wrote:
>Richard,
>thank you for your answer and the provided information.
>I understand that e164.int has to become e164.arpa. But as it were not
>decided that e164.int would be the adhoc subdomain, and as you wisely said
>that this choice was not under the purview of ENUM group, I thought that
>.foo would have been an easy way to escape political issue of this subdomain
>(why not e164.itu.int ? at the IETF/ITU-T SG2 WP1/2 call conference, this
>possibility was not excluded). A naive and straight question : in case the
>ENUM document quotes e164.arpa instead of .foo, does it cut the way to
>e164.itu.int ?
>
>Valerie.

I would say so... but I'm just a poor little IETF Work Group co-chair. :-)

I would interpret the IAB statement exactly the way it reads. The IAB wants 
administrative issues in the .arpa domain and IAB is providing guidance and 
instruction to WG's and chairs on what to do.

Since ENUM is a Internet Administrative issue it goes in .arpa.  Patrick 
and myself saw no reason to finesse the issue with references to .foo.


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul  5 21:58:35 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22032
	for <enum-archive@odin.ietf.org>; Wed, 5 Jul 2000 21:58:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10602;
	Wed, 5 Jul 2000 21:57:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10579
	for <enum@ns.ietf.org>; Wed, 5 Jul 2000 21:57:23 -0400 (EDT)
Received: from nix.swip.net (nix.swip.net [192.71.220.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22016
	for <enum@ietf.org>; Wed, 5 Jul 2000 21:57:22 -0400 (EDT)
Received: from [10.0.0.3] (nix.swip.net [192.71.220.2]) 
          by nix.swip.net (8.8.8/8.8.8) with ESMTP 
          id DAA06502; 
          Thu, 6 Jul 2000 03:54:54 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: paf@127.0.0.1
Message-Id: <p0432042fb58990f364dd@[10.0.0.3]>
In-Reply-To: <4.3.1.2.20000705111038.00b54460@127.0.0.1>
References: <4.3.1.2.20000705111038.00b54460@127.0.0.1>
Date: Wed, 5 Jul 2000 18:27:49 -0700
To: Richard Shockey <rshockey@ix.netcom.com>,
        BARNOLE Valerie FTRD/DAC/ISS <valerie.barnole@rd.francetelecom.fr>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <paf@swip.net>
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or  
 .e;164.itu.int  ?
Cc: ENUM List Group <enum@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 11.21 -0500 00-07-05, Richard Shockey wrote:
>Since ENUM is a Internet Administrative issue it goes in .arpa. 
>Patrick and myself saw no reason to finesse the issue with 
>references to .foo.

I have asked IAB explicitely what they want me to write in the I-D, 
and they say .arpa. So that is what will be in the draft which will 
be ready tomorrow.

    paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul  6 06:15:15 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10429
	for <enum-archive@odin.ietf.org>; Thu, 6 Jul 2000 06:15:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20664;
	Thu, 6 Jul 2000 06:14:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20641
	for <enum@ns.ietf.org>; Thu, 6 Jul 2000 06:14:36 -0400 (EDT)
Received: from p-voyageur.issy.cnet.fr (p-voyageur.issy.cnet.fr [139.100.0.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10425
	for <enum@ietf.org>; Thu, 6 Jul 2000 06:14:36 -0400 (EDT)
Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0)
	id <3JZJN28B>; Thu, 6 Jul 2000 12:14:38 +0200
Message-ID: <98388C05D464D111B61800805F1504160123E7FC@p-ibis.issy.cnet.fr>
From: BARNOLE Valerie FTRD/DAC/ISS <valerie.barnole@rd.francetelecom.fr>
To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <paf@swip.net>,
        Richard Shockey <rshockey@ix.netcom.com>,
        BARNOLE Valerie FTRD/DAC/ISS
	 <valerie.barnole@rd.francetelecom.fr>
Cc: ENUM List Group <enum@ietf.org>
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in
	t  ?
Date: Thu, 6 Jul 2000 12:14:38 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA20642
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

Thank you Richard and Patrick.
Patrick, thank you for making the issue clear to me. I do not have the Force
to fight against IAB wills !

Regards to both of you,

Valerie.


end of message
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

Valérie Barnole
FTR&D/DAC/ARS
tel. : + 33 1 45 29 58 39
fax : + 33 1 46 29 31 42

valerie.barnole@francetelecom.fr



-----Message d'origine-----
De: Patrik Fältström [mailto:paf@swip.net]
Date: jeudi 6 juillet 2000 03:28
À: Richard Shockey; BARNOLE Valerie FTRD/DAC/ISS
Cc: ENUM List Group
Objet: RE: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.int
?


At 11.21 -0500 00-07-05, Richard Shockey wrote:
>Since ENUM is a Internet Administrative issue it goes in .arpa. 
>Patrick and myself saw no reason to finesse the issue with 
>references to .foo.

I have asked IAB explicitely what they want me to write in the I-D, 
and they say .arpa. So that is what will be in the draft which will 
be ready tomorrow.

    paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul  6 08:01:34 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13417
	for <enum-archive@odin.ietf.org>; Thu, 6 Jul 2000 08:01:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21718;
	Thu, 6 Jul 2000 08:00:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21693
	for <enum@ns.ietf.org>; Thu, 6 Jul 2000 08:00:48 -0400 (EDT)
Received: from nix.swip.net (nix.swip.net [192.71.220.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13326
	for <enum@ietf.org>; Thu, 6 Jul 2000 08:00:47 -0400 (EDT)
Received: from [10.0.0.3] (nix.swip.net [192.71.220.2]) 
          by nix.swip.net (8.8.8/8.8.8) with ESMTP 
          id NAA18853; 
          Thu, 6 Jul 2000 13:59:24 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: paf@127.0.0.1
Message-Id: <p04320441b58a2178fdea@[10.0.0.3]>
In-Reply-To: <98388C05D464D111B61800805F1504160123E7FC@p-ibis.issy.cnet.fr>
References: <98388C05D464D111B61800805F1504160123E7FC@p-ibis.issy.cnet.fr>
Date: Thu, 6 Jul 2000 04:44:29 -0700
To: BARNOLE Valerie FTRD/DAC/ISS <valerie.barnole@rd.francetelecom.fr>,
        Richard Shockey <rshockey@ix.netcom.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <paf@swip.net>
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in
 	t  ?
Cc: ENUM List Group <enum@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 12.14 +0200 00-07-06, BARNOLE Valerie FTRD/DAC/ISS wrote:
>I do not have the Force
>to fight against IAB wills !

None of us has. If someone is unhappy with it, they should contact 
the IAB, not us. I.e. we have managed to NOT make this a wg issue, 
and I am happy for that.

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul  6 08:13:15 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13754
	for <enum-archive@odin.ietf.org>; Thu, 6 Jul 2000 08:13:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21858;
	Thu, 6 Jul 2000 08:12:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21829
	for <enum@ns.ietf.org>; Thu, 6 Jul 2000 08:12:37 -0400 (EDT)
Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13734
	for <enum@ietf.org>; Thu, 6 Jul 2000 08:12:35 -0400 (EDT)
Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0)
	id <3JZBH6YF>; Thu, 6 Jul 2000 14:12:36 +0200
Message-ID: <98388C05D464D111B61800805F1504160123E7FF@p-ibis.issy.cnet.fr>
From: BARNOLE Valerie FTRD/DAC/ISS <valerie.barnole@rd.francetelecom.fr>
To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <paf@swip.net>,
        BARNOLE Valerie FTRD/DAC/ISS <valerie.barnole@rd.francetelecom.fr>,
        Richard Shockey <rshockey@ix.netcom.com>
Cc: ENUM List Group <enum@ietf.org>
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in
	 t  ?
Date: Thu, 6 Jul 2000 14:12:34 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA21830
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

Patrick, maybe I forgot to add the ":-)" after my sentence, you have to
excuse me. I did not intend to hurt anyone.


end of message
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

Valérie Barnole
FTR&D/DAC/ARS
tel. : + 33 1 45 29 58 39
fax : + 33 1 46 29 31 42

valerie.barnole@francetelecom.fr



-----Message d'origine-----
De: Patrik Fältström [mailto:paf@swip.net]
Date: jeudi 6 juillet 2000 13:44
À: BARNOLE Valerie FTRD/DAC/ISS; Richard Shockey
Cc: ENUM List Group
Objet: RE: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.in t
?


At 12.14 +0200 00-07-06, BARNOLE Valerie FTRD/DAC/ISS wrote:
>I do not have the Force
>to fight against IAB wills !

None of us has. If someone is unhappy with it, they should contact 
the IAB, not us. I.e. we have managed to NOT make this a wg issue, 
and I am happy for that.

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul  6 15:08:08 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23615
	for <enum-archive@odin.ietf.org>; Thu, 6 Jul 2000 15:08:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27194;
	Thu, 6 Jul 2000 15:05:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27165
	for <enum@ns.ietf.org>; Thu, 6 Jul 2000 15:04:59 -0400 (EDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23546
	for <enum@ietf.org>; Thu, 6 Jul 2000 15:04:56 -0400 (EDT)
From: john.loughney@nokia.com
Received: from esvir03nok.ntc.nokia.com (esvir03nok.ntc.nokia.com [131.228.10.152])
	by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id WAA12465
	for <enum@ietf.org>; Thu, 6 Jul 2000 22:04:55 +0300 (EETDST)
Received: from esebh02nok.ntc.nokia.com (unverified) by esvir03nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.1.2) with ESMTP id <B83e40a984d3ccd7720@esvir03nok.ntc.nokia.com>;
 Thu, 6 Jul 2000 11:56:20 +0300
Received: by esebh02nok with Internet Mail Service (5.5.2650.10)
	id <N63PKYFS>; Thu, 6 Jul 2000 11:56:15 +0300
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DECC3@eseis04nok>
To: michaelm@netsol.com
Cc: enum@ietf.org
Subject: RE: [Enum] FW: Last Call or New Draft? - Portability
Date: Thu, 6 Jul 2000 11:56:13 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Michael,

> Sure. Very similar actually:
>  
> $ORIGIN     9.0.3.5.7.6.8.2.9.7.1.e164.arpa.
> IN NAPTR 10 10 "u" "sip+N2R"      "!^.*$!sip:jenny@sipservice.com!" .
> IN NAPTR 10 10 "u" "smtp+N2R"     "!^.*$!mailto:jenny@ispa.net" .
> IN NAPTR 10 10 "u" "http+N2R"     "!^.*$!http://jenny.ispa.net" .
> IN NAPTR 10 10 "u" "tel+N2R"      "!^.*$!tel:+1-792-867-5309" .
> 
> Patrik has some other examples but I'll let him forward them when
> he's done...

That clears a few things up in my mind, but could you help me out
a little bit more?  For the SIP example, is there any way to 
differentiate between different transport protocols (UDP, TCP, SCTP) 
in the records?

Or even more generally, if I wanted some service, let's call
it 'GOO' which had a couple of different protocol options, how
can we capture that?

Would it be something like:

IN NAPTR 10 10 "u" "goo._tcp+N2R"   "!^.*$!tcp:jenny@goo.service.com!" .
IN NAPTR 10 10 "u" "goo._sctp+N2R"  "!^.*$!sctp:jenny@goo.service.com!" .
IN NAPTR 10 10 "u" "goo._udp+N2R"   "!^.*$!udp:jenny@goo.service.com!" .

Thanks,
John Loughney

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul  6 15:39:01 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24199
	for <enum-archive@odin.ietf.org>; Thu, 6 Jul 2000 15:39:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27617;
	Thu, 6 Jul 2000 15:37:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27588
	for <enum@ns.ietf.org>; Thu, 6 Jul 2000 15:37:20 -0400 (EDT)
Received: from nix.swip.net (nix.swip.net [192.71.220.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24175
	for <enum@ietf.org>; Thu, 6 Jul 2000 15:37:18 -0400 (EDT)
Received: from [10.0.0.3] (nix.swip.net [192.71.220.2]) 
          by nix.swip.net (8.8.8/8.8.8) with ESMTP 
          id VAA01205; 
          Thu, 6 Jul 2000 21:36:13 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: paf@127.0.0.1
Message-Id: <p0432044eb58a8f97ebf8@[10.0.0.3]>
In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE1031DECC3@eseis04nok>
References: <01D91AFB08B6D211BFD00008C7EABAE1031DECC3@eseis04nok>
Date: Thu, 6 Jul 2000 12:37:02 -0700
To: john.loughney@nokia.com, michaelm@netsol.com
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <paf@swip.net>
Subject: RE: [Enum] FW: Last Call or New Draft? - Portability
Cc: enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 11.56 +0300 00-07-06, john.loughney@nokia.com wrote:
>That clears a few things up in my mind, but could you help me out
>a little bit more?  For the SIP example, is there any way to
>differentiate between different transport protocols (UDP, TCP, SCTP)
>in the records?
>
>Or even more generally, if I wanted some service, let's call
>it 'GOO' which had a couple of different protocol options, how
>can we capture that?
>
>Would it be something like:
>
>IN NAPTR 10 10 "u" "goo._tcp+N2R"   "!^.*$!tcp:jenny@goo.service.com!" .
>IN NAPTR 10 10 "u" "goo._sctp+N2R"  "!^.*$!sctp:jenny@goo.service.com!" .
>IN NAPTR 10 10 "u" "goo._udp+N2R"   "!^.*$!udp:jenny@goo.service.com!" .

 From my point of view, that should be part of the SIP protocol 
routing/resolution process to take care of, and in your example, that 
should be resolved in the GOO protocol suite.

That said, Greg mentioned to me (I don't remember if it was privately 
or on this mailing list) that in the case of VPIM, mailto-URI's are 
used, but it can be fax, voicemail or whatever content that is sent 
in the email.

My proposal would be to write a specific I-D about how to handle each 
one of these cases.

For example, one document can be:

    "Use of mailto URIs when doing ENUM resolution"

The solution could I guess (Michael, you know the NAPTR better than 
me) to define new flags for the NAPTR stuff as you suggest above for 
GOO, but maybe not syntactically exactly that way. More like this:

IN NAPTR 10 10 "u" "goo._tcp+N2R"   "!^.*$!goo:jenny@goo.service.com!" .
IN NAPTR 10 10 "u" "goo._sctp+N2R"  "!^.*$!goo:jenny@goo.service.com!" .
IN NAPTR 10 10 "u" "goo._udp+N2R"   "!^.*$!goo:jenny@goo.service.com!" .


    paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul  6 15:48:23 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24306
	for <enum-archive@odin.ietf.org>; Thu, 6 Jul 2000 15:48:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27774;
	Thu, 6 Jul 2000 15:47:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27745
	for <enum@ns.ietf.org>; Thu, 6 Jul 2000 15:47:54 -0400 (EDT)
Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24298
	for <enum@ietf.org>; Thu, 6 Jul 2000 15:47:52 -0400 (EDT)
Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id PAA09807; Thu, 6 Jul 2000 15:36:45 -0400 (EDT)
Date: Thu, 6 Jul 2000 15:36:44 -0400
From: Michael Mealling <michael@bailey.dscga.com>
To: john.loughney@nokia.com
Cc: michaelm@netsol.com, enum@ietf.org
Subject: Re: [Enum] FW: Last Call or New Draft? - Portability
Message-ID: <20000706153644.C9460@bailey.dscga.com>
Reply-To: michaelm@netsol.com
References: <01D91AFB08B6D211BFD00008C7EABAE1031DECC3@eseis04nok>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.2i
In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE1031DECC3@eseis04nok>; from john.loughney@nokia.com on Thu, Jul 06, 2000 at 11:56:13AM +0300
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

On Thu, Jul 06, 2000 at 11:56:13AM +0300, john.loughney@nokia.com wrote:
> > Sure. Very similar actually:
> >  
> > $ORIGIN     9.0.3.5.7.6.8.2.9.7.1.e164.arpa.
> > IN NAPTR 10 10 "u" "sip+N2R"      "!^.*$!sip:jenny@sipservice.com!" .
> > IN NAPTR 10 10 "u" "smtp+N2R"     "!^.*$!mailto:jenny@ispa.net" .
> > IN NAPTR 10 10 "u" "http+N2R"     "!^.*$!http://jenny.ispa.net" .
> > IN NAPTR 10 10 "u" "tel+N2R"      "!^.*$!tel:+1-792-867-5309" .
> > 
> > Patrik has some other examples but I'll let him forward them when
> > he's done...
> 
> That clears a few things up in my mind, but could you help me out
> a little bit more?  For the SIP example, is there any way to 
> differentiate between different transport protocols (UDP, TCP, SCTP) 
> in the records?

By using that field in the SIP URL format (Section 2 of RFC2543):
sip:j.doe:secret@big.com;transport=tcp
sip:j.doe:secret@big.com;transport=udp
sip:j.doe:secret@big.com;transport=sctp

> Or even more generally, if I wanted some service, let's call
> it 'GOO' which had a couple of different protocol options, how
> can we capture that?
> 
> Would it be something like:
> 
> IN NAPTR 10 10 "u" "goo._tcp+N2R"   "!^.*$!tcp:jenny@goo.service.com!" .
> IN NAPTR 10 10 "u" "goo._sctp+N2R"  "!^.*$!sctp:jenny@goo.service.com!" .
> IN NAPTR 10 10 "u" "goo._udp+N2R"   "!^.*$!udp:jenny@goo.service.com!" .

I would create a new Service as in I2GOO following the format's 
specified in RFC2483. This would read as:

NAPTR 10 10 "u" "gsmtp+I2GOO" "!^.*$!mailto:jenny@goo.service.com!" .
NAPTR 10 10 "u" "gsip+I2GOO"  "!^.*$!sip:jenny@goo.service.com;transport=tcp!" .
NAPTR 10 10 "u" "girc+I2GOO"  "!^.*$!irc:jenny@goo.service.com;someircbla!" .

(Note how I use gsmtp instead of just smtp since the Goo service probably
can't use SMTP by itself, it would have to specify some profile of
SMTP that specifies how its use with the Goo service. In the
URN stuff we used THTTP since its a profile of how to do URI resolution
using HTTP. If we had simply said the protocol was HTTP that wouldn't
have given anyone enough of a guideline for how to actually use HTTP
for that purpose. And since it wasn't meant to be fully HTTP we 
called it something else in order to disambiguate between them.)

That's just my opinion though. You'd have to check with Patrik on 
whether the use of Services outside of N2R fits the intent...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul  6 15:54:25 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24375
	for <enum-archive@odin.ietf.org>; Thu, 6 Jul 2000 15:54:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27892;
	Thu, 6 Jul 2000 15:54:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27863
	for <enum@ns.ietf.org>; Thu, 6 Jul 2000 15:54:01 -0400 (EDT)
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24365
	for <enum@ietf.org>; Thu, 6 Jul 2000 15:53:57 -0400 (EDT)
Received: from computer.ix.netcom.com ([209.138.7.53])
	by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id PAA10103;
	Thu, 6 Jul 2000 15:53:43 -0400 (EDT)
Message-Id: <4.3.1.2.20000706145206.00c52ba0@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 06 Jul 2000 14:54:40 -0500
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <paf@swip.net>,
        john.loughney@nokia.com, michaelm@netsol.com
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: RE: [Enum] FW: Last Call or New Draft? - Portability
Cc: enum@ietf.org
In-Reply-To: <p0432044eb58a8f97ebf8@[10.0.0.3]>
References: <01D91AFB08B6D211BFD00008C7EABAE1031DECC3@eseis04nok>
 <01D91AFB08B6D211BFD00008C7EABAE1031DECC3@eseis04nok>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org


>
>My proposal would be to write a specific I-D about how to handle each one 
>of these cases.
>
>For example, one document can be:
>
>    "Use of mailto URIs when doing ENUM resolution"




Or ... "The use of ENUM services in SIP"

Or  " The use of ENUM services by H.323 gateways"

et.al



>The solution could I guess (Michael, you know the NAPTR better than me) to 
>define new flags for the NAPTR stuff as you suggest above for GOO, but 
>maybe not syntactically exactly that way. More like this:
>
>IN NAPTR 10 10 "u" "goo._tcp+N2R"   "!^.*$!goo:jenny@goo.service.com!" .
>IN NAPTR 10 10 "u" "goo._sctp+N2R"  "!^.*$!goo:jenny@goo.service.com!" .
>IN NAPTR 10 10 "u" "goo._udp+N2R"   "!^.*$!goo:jenny@goo.service.com!" .

Mike ...correct me if I'm wrong here ..but were you thinking about a IANA 
registration procedure here for NAPTR service types?


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul  6 15:54:47 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24386
	for <enum-archive@odin.ietf.org>; Thu, 6 Jul 2000 15:54:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27934;
	Thu, 6 Jul 2000 15:54:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27907
	for <enum@ns.ietf.org>; Thu, 6 Jul 2000 15:54:24 -0400 (EDT)
Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24372
	for <enum@ietf.org>; Thu, 6 Jul 2000 15:54:21 -0400 (EDT)
Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id PAA09840; Thu, 6 Jul 2000 15:43:20 -0400 (EDT)
Date: Thu, 6 Jul 2000 15:43:20 -0400
From: Michael Mealling <michael@bailey.dscga.com>
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@swip.net>
Cc: john.loughney@nokia.com, michaelm@netsol.com, enum@ietf.org
Subject: Re: [Enum] FW: Last Call or New Draft? - Portability
Message-ID: <20000706154320.D9460@bailey.dscga.com>
Reply-To: michaelm@netsol.com
References: <01D91AFB08B6D211BFD00008C7EABAE1031DECC3@eseis04nok> <p0432044eb58a8f97ebf8@[10.0.0.3]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.1.2i
In-Reply-To: <p0432044eb58a8f97ebf8@[10.0.0.3]>; from paf@swip.net on Thu, Jul 06, 2000 at 12:37:02PM -0700
Content-Transfer-Encoding: 8bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

On Thu, Jul 06, 2000 at 12:37:02PM -0700, Patrik Fältström wrote:
> At 11.56 +0300 00-07-06, john.loughney@nokia.com wrote:
> >That clears a few things up in my mind, but could you help me out
> >a little bit more?  For the SIP example, is there any way to
> >differentiate between different transport protocols (UDP, TCP, SCTP)
> >in the records?
> >
> >Or even more generally, if I wanted some service, let's call
> >it 'GOO' which had a couple of different protocol options, how
> >can we capture that?
> >
> >Would it be something like:
> >
> >IN NAPTR 10 10 "u" "goo._tcp+N2R"   "!^.*$!tcp:jenny@goo.service.com!" .
> >IN NAPTR 10 10 "u" "goo._sctp+N2R"  "!^.*$!sctp:jenny@goo.service.com!" .
> >IN NAPTR 10 10 "u" "goo._udp+N2R"   "!^.*$!udp:jenny@goo.service.com!" .
> 
>  From my point of view, that should be part of the SIP protocol 
> routing/resolution process to take care of, and in your example, that 
> should be resolved in the GOO protocol suite.
> 
> That said, Greg mentioned to me (I don't remember if it was privately 
> or on this mailing list) that in the case of VPIM, mailto-URI's are 
> used, but it can be fax, voicemail or whatever content that is sent 
> in the email.
> 
> My proposal would be to write a specific I-D about how to handle each 
> one of these cases.

Yep....

> For example, one document can be:
> 
>     "Use of mailto URIs when doing ENUM resolution"
> 
> The solution could I guess (Michael, you know the NAPTR better than 
> me) to define new flags for the NAPTR stuff as you suggest above for 
> GOO, but maybe not syntactically exactly that way. More like this:
> 
> IN NAPTR 10 10 "u" "goo._tcp+N2R"   "!^.*$!goo:jenny@goo.service.com!" .
> IN NAPTR 10 10 "u" "goo._sctp+N2R"  "!^.*$!goo:jenny@goo.service.com!" .
> IN NAPTR 10 10 "u" "goo._udp+N2R"   "!^.*$!goo:jenny@goo.service.com!" .

I would prefer that we create new Service types instead of new 
protocols. I.e. is the Goo Service actually returning the resource
or is it returning some Goo service specific bit of information? If
its just returning the resource then I2R is appropriate but I dobut
that's what we're doign here.

I.e. create (and hopefully publish) the Goo service and create new
Service parameters such as I2GR (Identifier to Goo Resource) or
E2GM (E164 Number to Goo Metadata). I.e. once you're in the Goo
system you get (and should) define new Services to appropriately
refleect what actual functions you're after...

Also, after thinking about this some. I do think that the Service
you're using in ENUM should be something new. I2R (N2R was deprecated)
means "URI to Resource". ENUM is doing "E164 Number to URI" so it
should be something new tag here (E2I?)

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul  6 16:02:38 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24515
	for <enum-archive@odin.ietf.org>; Thu, 6 Jul 2000 16:02:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28190;
	Thu, 6 Jul 2000 16:02:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28166
	for <enum@ns.ietf.org>; Thu, 6 Jul 2000 16:02:08 -0400 (EDT)
Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24512
	for <enum@ietf.org>; Thu, 6 Jul 2000 16:02:06 -0400 (EDT)
Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id PAA09867; Thu, 6 Jul 2000 15:51:04 -0400 (EDT)
Date: Thu, 6 Jul 2000 15:51:04 -0400
From: Michael Mealling <michael@bailey.dscga.com>
To: Richard Shockey <rshockey@ix.netcom.com>
Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@swip.net>,
        john.loughney@nokia.com, michaelm@netsol.com, enum@ietf.org
Subject: Re: [Enum] FW: Last Call or New Draft? - Portability
Message-ID: <20000706155103.E9460@bailey.dscga.com>
Reply-To: michaelm@netsol.com
References: <01D91AFB08B6D211BFD00008C7EABAE1031DECC3@eseis04nok> <01D91AFB08B6D211BFD00008C7EABAE1031DECC3@eseis04nok> <p0432044eb58a8f97ebf8@[10.0.0.3]> <4.3.1.2.20000706145206.00c52ba0@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.2i
In-Reply-To: <4.3.1.2.20000706145206.00c52ba0@127.0.0.1>; from rshockey@ix.netcom.com on Thu, Jul 06, 2000 at 02:54:40PM -0500
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

On Thu, Jul 06, 2000 at 02:54:40PM -0500, Richard Shockey wrote:
> >The solution could I guess (Michael, you know the NAPTR better than me) to 
> >define new flags for the NAPTR stuff as you suggest above for GOO, but 
> >maybe not syntactically exactly that way. More like this:
> >
> >IN NAPTR 10 10 "u" "goo._tcp+N2R"   "!^.*$!goo:jenny@goo.service.com!" .
> >IN NAPTR 10 10 "u" "goo._sctp+N2R"  "!^.*$!goo:jenny@goo.service.com!" .
> >IN NAPTR 10 10 "u" "goo._udp+N2R"   "!^.*$!goo:jenny@goo.service.com!" .
> 
> Mike ...correct me if I'm wrong here ..but were you thinking about a IANA 
> registration procedure here for NAPTR service types?

Yep. RFC 2483 doesn't specify one but it does suggest that one should
be created if needed. It provides a template and some loose policies.
Setting up an IANA registry for these would be very easy....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul  6 17:03:52 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25589
	for <enum-archive@odin.ietf.org>; Thu, 6 Jul 2000 17:03:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28836;
	Thu, 6 Jul 2000 17:01:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28809
	for <enum@ns.ietf.org>; Thu, 6 Jul 2000 17:01:54 -0400 (EDT)
Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25558
	for <enum@ietf.org>; Thu, 6 Jul 2000 17:01:53 -0400 (EDT)
Received: from computer.ix.netcom.com ([209.138.14.81])
	by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA15160;
	Thu, 6 Jul 2000 17:01:52 -0400 (EDT)
Message-Id: <4.3.1.2.20000706155145.00bd4470@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 06 Jul 2000 15:53:00 -0500
To: enum@ietf.org
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: [Enum] Reminder ......Last Call ENUM Requirements
Cc: Scott Bradner <sob@harvard.edu>, mankin@east.isi.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Reminder....

Just in case you missed this over the long weekend here in the States....

####################


I think we can begin the process of Last Call on our Requirements document.

Anne posted a revised document several weeks ago and I have not seen any 
additional discussion of the document...


	Title		: ENUM Requirements
	Author(s)	: A. Brown
	Filename	: draft-ietf-enum-rqmts-01.txt
	Pages		:
	Date		: 13-Jun-00
	
This paper defines the requirements for 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. There are many possible protocols that can be
considered for a telephone number mapping service.  The purpose of
this document is to focus discussion on a DNS-based solution.  The
intention is to enumerate the expectations of such a solution and to
clarify the scope.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-01.txt


The intent of the last call is to solicit comments before submitting the ID 
to the IESG as a Proposed Standard.

The purpose of a working group Last Call is in the style of "speak now or
forever hold your peace" in case there are fundamental objections which have
not gotten previous or adequate discussion, or minor errors which need
correction.

Work group last call will extend for two weeks from today July 5 to to at 
least July 21 th though we can modify that if new issues come up.


Your co-chair.


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul  7 02:07:53 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15708
	for <enum-archive@odin.ietf.org>; Fri, 7 Jul 2000 02:07:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09806;
	Fri, 7 Jul 2000 02:06:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09775
	for <enum@ns.ietf.org>; Fri, 7 Jul 2000 02:06:18 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15699
	for <enum@ietf.org>; Fri, 7 Jul 2000 02:06:18 -0400 (EDT)
From: john.loughney@nokia.com
Received: from esvir06nok.ntc.nokia.com (esvir06nok.ntc.nokia.com [131.228.10.155])
	by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id JAA07333
	for <enum@ietf.org>; Fri, 7 Jul 2000 09:06:13 +0300 (EETDST)
Received: from esebh03nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e40a9b1574d41573626@esvir06nok.ntc.nokia.com>;
 Fri, 7 Jul 2000 09:05:16 +0300
Received: by esebh03nok with Internet Mail Service (5.5.2650.10)
	id <N63R7A16>; Fri, 7 Jul 2000 09:05:16 +0300
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DECDF@eseis04nok>
To: michaelm@netsol.com, rshockey@ix.netcom.com
Cc: enum@ietf.org
Subject: RE: [Enum] FW: Last Call or New Draft? - Portability
Date: Fri, 7 Jul 2000 09:05:13 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Mike,

> > Mike ...correct me if I'm wrong here ..but were you 
> thinking about a IANA  registration procedure here for NAPTR 
> service types?
> 
> Yep. RFC 2483 doesn't specify one but it does suggest that one should
> be created if needed. It provides a template and some loose policies.
> Setting up an IANA registry for these would be very easy....

That sounds like a good idea.  I have plans (partially in
electronic ink) and partially in my head for using NAPTR & ENUMs
for 2 different services.  I can try to address this in
the IANA sections of the draft.  

best regards,
John

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul  7 02:16:47 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15760
	for <enum-archive@odin.ietf.org>; Fri, 7 Jul 2000 02:16:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09947;
	Fri, 7 Jul 2000 02:16:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09914
	for <enum@ns.ietf.org>; Fri, 7 Jul 2000 02:16:18 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15757
	for <enum@ietf.org>; Fri, 7 Jul 2000 02:16:18 -0400 (EDT)
From: john.loughney@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nok.ntc.nokia.com [131.228.10.151])
	by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id JAA26394
	for <enum@ietf.org>; Fri, 7 Jul 2000 09:16:01 +0300 (EETDST)
Received: from esebh02nok.ntc.nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e40a97754d41610557@esvir02nok.ntc.nokia.com>;
 Fri, 7 Jul 2000 09:15:59 +0300
Received: by esebh02nok with Internet Mail Service (5.5.2650.10)
	id <N63PL878>; Fri, 7 Jul 2000 09:15:55 +0300
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DECE0@eseis04nok>
To: michaelm@netsol.com, paf@swip.net
Cc: enum@ietf.org
Subject: RE: [Enum] FW: Last Call or New Draft? - Portability
Date: Fri, 7 Jul 2000 09:15:55 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Mike & Patrik,


> > My proposal would be to write a specific I-D about how to 
> > handle each one of these cases.

That is being planned:

"Roaming Support with DNS"
"ENUM Resolution to Support Signaling Transport"

> I would prefer that we create new Service types instead of new 
> protocols. I.e. is the Goo Service actually returning the resource
> or is it returning some Goo service specific bit of information? If
> its just returning the resource then I2R is appropriate but I dobut
> that's what we're doign here.

For the first draft, I think I2R should be sufficient. 

The second draft is a bit more complicatated.  Essentially, in the
SIGTRAN protocols will be carrying some Application Protocol (AP) over
an user adaptation layer (UA) + SCTP (though it could even be an 
adaptation layer + TCP).  E.164 numbers will used by the AP to
identify the signaling endpoint.  Ideally, I'd like to perform
an ENUM guery and see what UAs the E.164 identified endpoint 
supports (I'll need the URI as well, most likely host name or IP 
address + port number).

> I.e. create (and hopefully publish) the Goo service and create new
> Service parameters such as I2GR (Identifier to Goo Resource) or
> E2GM (E164 Number to Goo Metadata). I.e. once you're in the Goo
> system you get (and should) define new Services to appropriately
> refleect what actual functions you're after...
> 
> Also, after thinking about this some. I do think that the Service
> you're using in ENUM should be something new. I2R (N2R was deprecated)
> means "URI to Resource". ENUM is doing "E164 Number to URI" so it
> should be something new tag here (E2I?)

I think E2I might be sufficient for both.  So, who gets to define
the E2I tag?

John

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul  7 08:05:29 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22457
	for <enum-archive@odin.ietf.org>; Fri, 7 Jul 2000 08:05:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13851;
	Fri, 7 Jul 2000 08:01:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13826
	for <enum@ns.ietf.org>; Fri, 7 Jul 2000 08:01:39 -0400 (EDT)
Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22341
	for <enum@ietf.org>; Fri, 7 Jul 2000 08:01:37 -0400 (EDT)
Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id HAA11018; Fri, 7 Jul 2000 07:51:12 -0400 (EDT)
Date: Fri, 7 Jul 2000 07:51:12 -0400
From: Michael Mealling <michael@bailey.dscga.com>
To: john.loughney@nokia.com
Cc: michaelm@netsol.com, paf@swip.net, enum@ietf.org
Subject: Re: [Enum] FW: Last Call or New Draft? - Portability
Message-ID: <20000707075112.B10439@bailey.dscga.com>
Reply-To: michaelm@netsol.com
References: <01D91AFB08B6D211BFD00008C7EABAE1031DECE0@eseis04nok>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.2i
In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE1031DECE0@eseis04nok>; from john.loughney@nokia.com on Fri, Jul 07, 2000 at 09:15:55AM +0300
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

On Fri, Jul 07, 2000 at 09:15:55AM +0300, john.loughney@nokia.com wrote:
> The second draft is a bit more complicatated.  Essentially, in the
> SIGTRAN protocols will be carrying some Application Protocol (AP) over
> an user adaptation layer (UA) + SCTP (though it could even be an 
> adaptation layer + TCP).  E.164 numbers will used by the AP to
> identify the signaling endpoint.  Ideally, I'd like to perform
> an ENUM guery and see what UAs the E.164 identified endpoint 
> supports (I'll need the URI as well, most likely host name or IP 
> address + port number).

I'd have to look at this more but it sounds like its transport
discovery. I.e. I have a URI but I don't know if its over tcp,udp, sctp or
what (sorry, I have to translate into my terms to understand this 
telephony stuff ;-). Hence it would be more "E164 to URI Plus 
Some Other Stuff". I'll let you figure out what Service tag that
might be. ;-)

> > I.e. create (and hopefully publish) the Goo service and create new
> > Service parameters such as I2GR (Identifier to Goo Resource) or
> > E2GM (E164 Number to Goo Metadata). I.e. once you're in the Goo
> > system you get (and should) define new Services to appropriately
> > refleect what actual functions you're after...
> > 
> > Also, after thinking about this some. I do think that the Service
> > you're using in ENUM should be something new. I2R (N2R was deprecated)
> > means "URI to Resource". ENUM is doing "E164 Number to URI" so it
> > should be something new tag here (E2I?)
> 
> I think E2I might be sufficient for both.  So, who gets to define
> the E2I tag?

You get to do it in the ENUM draft. If we start getting alot
of 'em we'll setup an IANA registration process so they're all listed
in one place...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul  7 10:02:32 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26613
	for <enum-archive@odin.ietf.org>; Fri, 7 Jul 2000 10:02:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15202;
	Fri, 7 Jul 2000 10:01:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15179
	for <enum@ns.ietf.org>; Fri, 7 Jul 2000 10:01:03 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26504
	for <enum@ietf.org>; Fri, 7 Jul 2000 10:00:59 -0400 (EDT)
From: john.loughney@nokia.com
Received: from esvir06nok.ntc.nokia.com (esvir06nok.ntc.nokia.com [131.228.10.155])
	by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id RAA16261
	for <enum@ietf.org>; Fri, 7 Jul 2000 17:00:58 +0300 (EETDST)
Received: from esebh03nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e40a9b1574d42c01268@esvir06nok.ntc.nokia.com>;
 Fri, 7 Jul 2000 15:39:25 +0300
Received: by esebh03nok with Internet Mail Service (5.5.2650.10)
	id <N63R83PH>; Fri, 7 Jul 2000 15:39:25 +0300
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DED03@eseis04nok>
To: michaelm@netsol.com
Cc: enum@ietf.org
Subject: RE: [Enum] FW: Last Call or New Draft? - Portability
Date: Fri, 7 Jul 2000 15:27:55 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Mike,

> > The second draft is a bit more complicatated.  Essentially, in the
> > SIGTRAN protocols will be carrying some Application 
> Protocol (AP) over
> > an user adaptation layer (UA) + SCTP (though it could even be an 
> > adaptation layer + TCP).  E.164 numbers will used by the AP to
> > identify the signaling endpoint.  Ideally, I'd like to perform
> > an ENUM guery and see what UAs the E.164 identified endpoint 
> > supports (I'll need the URI as well, most likely host name or IP 
> > address + port number).
> 
> I'd have to look at this more but it sounds like its transport
> discovery. I.e. I have a URI but I don't know if its over 
> tcp,udp, sctp or what (sorry, I have to translate into my terms
> to understand this telephony stuff ;-). Hence it would be more
> "E164 to URI Plus Some Other Stuff". I'll let you figure out what
> Service tag that might be. ;-)

Its a bit that.  In SIGTRAN there are about 4 UAs existing (for carrying
different types of SS7 stuff over SCTP).  I'd like to do a query
on _sig.x.x.x.x.x.e164.arpa and get the list of possible UAs supported by 
x.x.x.x.x.e164.arpa - essentially, x.x.x.x.x.e164.arpa will refer to
a box, probably a multihomed box; so we'd have a number of IP addresses
allocated for that box.

What I was hoping to get as a resonse would be something like this:

IN NAPTR 10 5  "s" "sig._sua+E2I"   "" _sua1._sctp.nokia.com
IN NAPTR 10 5  "s" "sig._sua+E2I"   "" _sua2._sctp.nokia.com
IN NAPTR 10 10 "s" "sig._m3ua+E2I"  "" _m3ua._sctp.nokia.com
IN NAPTR 10 10 "s" "sig._m2ua+E2I"  "" _m2ua._sctp.nokia.com

and then _sua1._sctp.nokia.com would get you:

     ;;                             Pref Weight Port Target
     _sua1._sctp.nokia.com   IN SRV 0    0      1000 glc1.nokia.com
                             IN SRV 0    0      1000 glc2.nokia.com
                             IN SRV 0    0      1000 glc3.nokia.com

and so on & so forth ...

If this makes any sense (or not), let me know.  I appreciate
the comments, as I am new to the world of DNS records.

cheers,
John

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul  7 11:10:57 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29087
	for <enum-archive@odin.ietf.org>; Fri, 7 Jul 2000 11:10:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16008;
	Fri, 7 Jul 2000 11:10:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15981
	for <enum@ns.ietf.org>; Fri, 7 Jul 2000 11:10:11 -0400 (EDT)
Received: from p-voyageur.issy.cnet.fr (p-voyageur.issy.cnet.fr [139.100.0.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29002
	for <enum@ietf.org>; Fri, 7 Jul 2000 11:10:07 -0400 (EDT)
Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0)
	id <3JZJN5R0>; Fri, 7 Jul 2000 16:53:26 +0200
Message-ID: <98388C05D464D111B61800805F1504160123E813@p-ibis.issy.cnet.fr>
From: BARNOLE Valerie FTRD/DAC/ISS <valerie.barnole@rd.francetelecom.fr>
To: "'Richard Shockey'" <rshockey@ix.netcom.com>,
        "'arbrown@nortelnetworks.com'" <arbrown@nortelnetworks.com>
Cc: Scott Bradner <sob@harvard.edu>, mankin@east.isi.edu, enum@ietf.org
Subject: RE: [Enum] Reminder ......Last Call ENUM Requirements
Date: Fri, 7 Jul 2000 16:53:26 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA15982
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

I've got a question for clarification on §3.13 "Competition" :

"3.13    Competition 
    
   The solution MUST permit competing service providers to offer 
   telecommunications service for a given number.  Competing 
   telecommunications services MUST be enabled where the ENUM entry is 
   administered by the single entity to which the number is delegated.  
   Who that single entity is, is beyond the scope of ENUM."

I understand that it means that Competing telecommunications services MUST
be technically enabled and that the sentence does not convey a regulatory
meaning.

Do I understand correctly ?

 


end of message
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

Valérie Barnole
FTR&D/DAC/ARS
tel. : + 33 1 45 29 58 39
fax : + 33 1 46 29 31 42

valerie.barnole@francetelecom.fr



-----Message d'origine-----
De: Richard Shockey [mailto:rshockey@ix.netcom.com]
Date: jeudi 6 juillet 2000 22:53
À: enum@ietf.org
Cc: Scott Bradner; mankin@east.isi.edu
Objet: [Enum] Reminder ......Last Call ENUM Requirements


Reminder....

Just in case you missed this over the long weekend here in the States....

####################


I think we can begin the process of Last Call on our Requirements document.

Anne posted a revised document several weeks ago and I have not seen any 
additional discussion of the document...


	Title		: ENUM Requirements
	Author(s)	: A. Brown
	Filename	: draft-ietf-enum-rqmts-01.txt
	Pages		:
	Date		: 13-Jun-00
	
This paper defines the requirements for 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. There are many possible protocols that can be
considered for a telephone number mapping service.  The purpose of
this document is to focus discussion on a DNS-based solution.  The
intention is to enumerate the expectations of such a solution and to
clarify the scope.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-01.txt


The intent of the last call is to solicit comments before submitting the ID 
to the IESG as a Proposed Standard.

The purpose of a working group Last Call is in the style of "speak now or
forever hold your peace" in case there are fundamental objections which have
not gotten previous or adequate discussion, or minor errors which need
correction.

Work group last call will extend for two weeks from today July 5 to to at 
least July 21 th though we can modify that if new issues come up.


Your co-chair.


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul  7 18:41:47 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14915
	for <enum-archive@odin.ietf.org>; Fri, 7 Jul 2000 18:41:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23172;
	Fri, 7 Jul 2000 18:40:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23145
	for <enum@ns.ietf.org>; Fri, 7 Jul 2000 18:40:57 -0400 (EDT)
Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14908
	for <enum@ietf.org>; Fri, 7 Jul 2000 18:40:57 -0400 (EDT)
Received: from computer.ix.netcom.com ([209.138.13.60])
	by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id SAA10184;
	Fri, 7 Jul 2000 18:40:44 -0400 (EDT)
Message-Id: <4.3.1.2.20000707173853.00bafe80@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 07 Jul 2000 17:41:48 -0500
To: BARNOLE Valerie FTRD/DAC/ISS <valerie.barnole@rd.francetelecom.fr>,
        "'arbrown@nortelnetworks.com'" <arbrown@nortelnetworks.com>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: RE: [Enum] Reminder ......Last Call ENUM Requirements
Cc: enum@ietf.org
In-Reply-To: <98388C05D464D111B61800805F1504160123E813@p-ibis.issy.cnet.
 fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA23146
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

At 04:53 PM 7/7/2000 +0200, BARNOLE Valerie FTRD/DAC/ISS wrote:
>I've got a question for clarification on §3.13 "Competition" :
>
>"3.13    Competition
>
>    The solution MUST permit competing service providers to offer
>    telecommunications service for a given number.  Competing
>    telecommunications services MUST be enabled where the ENUM entry is
>    administered by the single entity to which the number is delegated.
>    Who that single entity is, is beyond the scope of ENUM."
>
>I understand that it means that Competing telecommunications services MUST
>be technically enabled and that the sentence does not convey a regulatory
>meaning.
>
>Do I understand correctly ?


I certainly hope so.... say in the case of SIP ..there can be two or more 
SIP entries in the NAPTR RR. The order and preference fields then "signal" 
the application which to use first.


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul 12 06:37:36 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15448
	for <enum-archive@odin.ietf.org>; Wed, 12 Jul 2000 06:37:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27814;
	Wed, 12 Jul 2000 06:31:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27786
	for <enum@ns.ietf.org>; Wed, 12 Jul 2000 06:31:15 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15058;
	Wed, 12 Jul 2000 06:31:14 -0400 (EDT)
Message-Id: <200007121031.GAA15058@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: enum@ietf.org, sigtran@standards.nortelnetworks.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 12 Jul 2000 06:31:13 -0400
Subject: [Enum] I-D ACTION:draft-loughney-enum-sigtran-00.txt
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: The Use of ENUM Services by Signaling Transport 
                          Protocols
	Author(s)	: J. Loughney
	Filename	: draft-loughney-enum-sigtran-00.txt
	Pages		: 6
	Date		: 11-Jul-00
	
This draft proposes to use ENUM resolution to support signaling
transport.  This draft outlines the resolution E.164 numbers by NAPTR in
DNS to a service location.  Considerations need to be made for
scalability, reliability and performance.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-loughney-enum-sigtran-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-loughney-enum-sigtran-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-loughney-enum-sigtran-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000711134904.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-loughney-enum-sigtran-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-loughney-enum-sigtran-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000711134904.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul 12 06:38:41 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15461
	for <enum-archive@odin.ietf.org>; Wed, 12 Jul 2000 06:38:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27915;
	Wed, 12 Jul 2000 06:32:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27876
	for <enum@ns.ietf.org>; Wed, 12 Jul 2000 06:32:40 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15293;
	Wed, 12 Jul 2000 06:32:39 -0400 (EDT)
Message-Id: <200007121032.GAA15293@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: enum@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 12 Jul 2000 06:32:38 -0400
Subject: [Enum] I-D ACTION:draft-ietf-enum-e164s2-np-00.txt
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title		: The Number Portability Supplement to ITU-T 
                          Recommendation E.164
	Author(s)	: A. Gallant
	Filename	: draft-ietf-enum-e164s2-np-00.txt
	Pages		: 28
	Date		: 11-Jul-00
	
This document contains a text version of the Number Portability
Supplement (11/98) to ITU-T Recommendation E.164 (The international
public telecommunication numbering plan, 05/97) [2].  That
Supplement [3] defined terminology for number portability within an
E.164 numbering scheme; identified formats, call flows,
architectures, and routing approaches for some methods; and gave
examples of some processes needed to implement number portability.
A January 2000 workshop on IP-Telecomms interworking (focused on
numbering, naming, addressing, and routing) identified issues to be
addressed by the IETF and/or the ITU [4].  This Supplement was noted
as a document related to a joint IETF/ITU issue on E.164 number
portability.  A text version was posted on the ITU's web site in
March 2000 and notified to the itu+ietf and enum mailing lists.
This Internet Draft is being submitted to support work of the ENUM
(Telephone Number Mapping) Working Group on impacts of local number
portability on a DNS-based architecture and protocols for mapping a
telephone number to a set of attributes (e.g., URLs) [5].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-e164s2-np-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-enum-e164s2-np-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-enum-e164s2-np-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000711135219.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-enum-e164s2-np-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-enum-e164s2-np-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000711135219.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul 12 06:38:49 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15472
	for <enum-archive@odin.ietf.org>; Wed, 12 Jul 2000 06:38:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27862;
	Wed, 12 Jul 2000 06:32:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27829
	for <enum@ns.ietf.org>; Wed, 12 Jul 2000 06:32:34 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15279;
	Wed, 12 Jul 2000 06:32:32 -0400 (EDT)
Message-Id: <200007121032.GAA15279@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: enum@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 12 Jul 2000 06:32:32 -0400
Subject: [Enum] I-D ACTION:draft-ietf-enum-e164-dns-01.txt
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title		: E.164 number and DNS
	Author(s)	: P. Faltstrom
	Filename	: draft-ietf-enum-e164-dns-01.txt
	Pages		: 12
	Date		: 11-Jul-00
	
This document discusses the use of DNS for storage of E.164 numbers.
More specifically, how DNS can be used for identifying available
services connected to one E.164 number. Routing of the actual
connection using the service selected using these methods is not
discussed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-enum-e164-dns-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-enum-e164-dns-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000711135207.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-enum-e164-dns-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-enum-e164-dns-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000711135207.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul 12 07:48:53 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17518
	for <enum-archive@odin.ietf.org>; Wed, 12 Jul 2000 07:48:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28764;
	Wed, 12 Jul 2000 07:42:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28745
	for <enum@ns.ietf.org>; Wed, 12 Jul 2000 07:42:43 -0400 (EDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17131
	for <enum@ietf.org>; Wed, 12 Jul 2000 07:42:40 -0400 (EDT)
From: john.loughney@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nok.ntc.nokia.com [131.228.10.150])
	by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id OAA19814
	for <enum@ietf.org>; Wed, 12 Jul 2000 14:42:39 +0300 (EETDST)
Received: from esebh01nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e40a96c54d5c4bdf76@esvir01nok.ntc.nokia.com>;
 Wed, 12 Jul 2000 14:42:38 +0300
Received: by esebh01nok with Internet Mail Service (5.5.2650.10)
	id <N63NW7RZ>; Wed, 12 Jul 2000 14:42:38 +0300
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DED51@eseis04nok>
To: rshockey@ix.netcom.com
Cc: enum@ietf.org
Date: Wed, 12 Jul 2000 14:42:35 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Enum] Pittsburgh presentations: I-D ACTION:draft-loughney-enum-sigtran-
 00.txt
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Richard,

You might have noticed this draft.  I hope to have another draft
which is quite similar, for cellular roaming, published by Friday.

If possible, could I have a slot to present both in Pittsburgh?
There is much overlapping between the two drafts, so I could
probably dispense with both at the same time.

best regards,
John Loughney
Nokia

> -----Original Message-----
> From: EXT Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: July 12, 2000 13:31
> Cc: enum@ietf.org; sigtran@standards.nortelnetworks.com
> Subject: [Enum] I-D ACTION:draft-loughney-enum-sigtran-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: The Use of ENUM Services by Signaling 
> Transport 
>                           Protocols
> 	Author(s)	: J. Loughney
> 	Filename	: draft-loughney-enum-sigtran-00.txt
> 	Pages		: 6
> 	Date		: 11-Jul-00
> 	
> This draft proposes to use ENUM resolution to support signaling
> transport.  This draft outlines the resolution E.164 numbers 
> by NAPTR in
> DNS to a service location.  Considerations need to be made for
> scalability, reliability and performance.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-loughney-enum-sigtran-00.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-loughney-enum-sigtran-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-loughney-enum-sigtran-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul 12 19:47:18 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18341
	for <enum-archive@odin.ietf.org>; Wed, 12 Jul 2000 19:47:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07275;
	Wed, 12 Jul 2000 19:46:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07254
	for <enum@ns.ietf.org>; Wed, 12 Jul 2000 19:46:48 -0400 (EDT)
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18337
	for <ENUM@IETF.ORG>; Wed, 12 Jul 2000 19:46:46 -0400 (EDT)
From: rshockey@ix.netcom.com
Received: from smui4.eng00.mindspring.net (smui4.eng00.mindspring.net [207.69.200.49])
	by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id TAA03660;
	Wed, 12 Jul 2000 19:46:45 -0400 (EDT)
Received: by smui4.eng00.mindspring.net id TAA0000005331; Wed, 12 Jul 2000 19:46:45 -0400 (EDT)
Date: Wed, 12 Jul 2000 19:46:45 -0400
To: ENUM@ietf.org
Cc: john.loughney@nokia.com
Message-ID: <Springmail.105.963445605.0.59059400@www.springmail.com>
X-Originating-IP: 210.197.100.153
Subject: [Enum] Schedule..
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

From: john.loughney@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nok.ntc.nokia.com [131.228.10.150])
	by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id OAA19814
	for <enum@ietf.org>; Wed, 12 Jul 2000 14:42:39 +0300 (EETDST)
Received: from esebh01nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e40a96c54d5c4bdf76@esvir01nok.ntc.nokia.com>;
 Wed, 12 Jul 2000 14:42:38 +0300
Received: by esebh01nok with Internet Mail Service (5.5.2650.10)
	id <N63NW7RZ>; Wed, 12 Jul 2000 14:42:38 +0300
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DED51@eseis04nok>
To: rshockey@ix.netcom.com
Cc: enum@ietf.org
Date: Wed, 12 Jul 2000 14:42:35 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Enum] Pittsburgh presentations: I-D ACTION:draft-loughney-enum-sigtran-
 00.txt
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Richard,

You might have noticed this draft.  I hope to have another draft
which is quite similar, for cellular roaming, published by Friday.

If possible, could I have a slot to present both in Pittsburgh?
There is much overlapping between the two drafts, so I could
probably dispense with both at the same time.

best regards,
John Loughney
Nokia


######

HOW MUCH TIME DO YOU NEED?

RS

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul 13 01:53:38 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01576
	for <enum-archive@odin.ietf.org>; Thu, 13 Jul 2000 01:53:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15838;
	Thu, 13 Jul 2000 01:53:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15811
	for <enum@ns.ietf.org>; Thu, 13 Jul 2000 01:53:16 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01572
	for <ENUM@ietf.org>; Thu, 13 Jul 2000 01:53:15 -0400 (EDT)
From: john.loughney@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nok.ntc.nokia.com [131.228.10.151])
	by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id IAA11057
	for <ENUM@ietf.org>; Thu, 13 Jul 2000 08:53:14 +0300 (EETDST)
Received: from esebh01nok.ntc.nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e40a97754d60325952@esvir02nok.ntc.nokia.com>;
 Thu, 13 Jul 2000 08:53:14 +0300
Received: by esebh01nok with Internet Mail Service (5.5.2650.10)
	id <N63NXT8V>; Thu, 13 Jul 2000 08:53:14 +0300
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DED57@eseis04nok>
To: rshockey@ix.netcom.com, ENUM@ietf.org
Cc: john.loughney@nokia.com
Subject: RE: [Enum] Schedule..
Date: Thu, 13 Jul 2000 08:53:13 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Richard,

>> If possible, could I have a slot to present both in Pittsburgh?
>> There is much overlapping between the two drafts, so I could
>> probably dispense with both at the same time.
>> ######
> 
> HOW MUCH TIME DO YOU NEED?

10 minutes could be good, though, if pressed I guess 5 would
suffice.

thanks,
John

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul 13 08:26:04 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15397
	for <enum-archive@odin.ietf.org>; Thu, 13 Jul 2000 08:26:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20147;
	Thu, 13 Jul 2000 08:24:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20122
	for <enum@ns.ietf.org>; Thu, 13 Jul 2000 08:24:57 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15349
	for <enum@ietf.org>; Thu, 13 Jul 2000 08:24:54 -0400 (EDT)
From: john.loughney@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nok.ntc.nokia.com [131.228.10.151])
	by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id PAA18030
	for <enum@ietf.org>; Thu, 13 Jul 2000 15:24:31 +0300 (EETDST)
Received: from esebh02nok.ntc.nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e40a97754d617caf3a@esvir02nok.ntc.nokia.com>;
 Thu, 13 Jul 2000 14:54:03 +0300
Received: by esebh02nok with Internet Mail Service (5.5.2650.10)
	id <3VVZJ82Q>; Thu, 13 Jul 2000 14:54:02 +0300
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DED68@eseis04nok>
To: paf@swip.net, paf@cisco.com
Cc: enum@ietf.org
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in
	t  ?
Date: Thu, 13 Jul 2000 14:54:00 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Patrik,

A question about your draft.

You give this example:

>    A user, John Smith, want to contact Sven Svensson, he to start with
>    only has the E.164 number of Sven, i.e. +46-8-9761234. He takes the
>    number, and enters the number in his communication client, which
>    happen to know how to handle the SIP protocol. The client removes
>    the dashes, and ends up with the E.164 number +4689761234. That is
>    what is used in the algorithm for NAPTR records, which is as
>    follows.
>
>    The client converts the E.164 number into the domainname
>    4.3.2.1.6.7.9.8.6.4.e164.arpa., and queries for NAPTR records for
>    this domainname. Using DNS mechanisms which includes following the
>    NS record referals, the following records are returned:
>
>    $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
>     IN NAPTR 10 10 "a" "sip+N2R"  "!^.*$!sip:sven@sipservice.example.se"
 .
>     IN NAPTR 10 10 "a" "smtp+N2R" "!^.*$!mailto:sven@ispa.example.se"
 .
>     IN NAPTR 10 10 "a" "http+N2R" "!^.*$!http://svensson.ispa.example.se"
 .
>     IN NAPTR 10 10 "a" "tel+N2R"  "!^.*$!tel:+46-8-9761234"
 .
>
>    Because this client know sip, the first record above is selected,
>    and the SIP URI is extracted, and used according to SIP resolution.

Is there away to prepend the service name, if you know what you want?

If I wanted to contact Sven by SIP (& only by SIP), could I query:

  _sip.4.3.2.1.6.7.9.8.6.4.e164.arpa. (or something close to that)

That could simplify things.

also, I remember seeing a suggestion that we use a E2I for the ENUM
service name (instead of N2R) - is that at all applicable to this
draft?

best regards,
John

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul 13 13:02:33 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29221
	for <enum-archive@odin.ietf.org>; Thu, 13 Jul 2000 13:02:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23984;
	Thu, 13 Jul 2000 13:01:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23943
	for <enum@ns.ietf.org>; Thu, 13 Jul 2000 13:01:00 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29056
	for <enum@ietf.org>; Thu, 13 Jul 2000 13:00:59 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 80D1FF7; Thu, 13 Jul 2000 19:00:29 +0200 (MET DST)
Received: from [10.0.0.6] ([171.70.221.22])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA10182;
	Thu, 13 Jul 2000 19:00:26 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p0432042eb593a551b1d0@[10.0.0.6]>
In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE1031DED68@eseis04nok>
References: <01D91AFB08B6D211BFD00008C7EABAE1031DED68@eseis04nok>
Date: Thu, 13 Jul 2000 09:59:41 -0700
To: john.loughney@nokia.com, paf@swip.net
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in
 	t  ?
Cc: enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 14.54 +0300 00-07-13, john.loughney@nokia.com wrote:
>Is there away to prepend the service name, if you know what you want?
>
>If I wanted to contact Sven by SIP (& only by SIP), could I query:
>
>   _sip.4.3.2.1.6.7.9.8.6.4.e164.arpa. (or something close to that)
>
>That could simplify things.

No, in DNS you always get back all RRs which have the same "owner", 
and for NAPTRs that is 4.3.2.1.6.7.9.8.6.4.e164.arpa.

There is no definition at the moment for the NAPTR RRs to request 
only one of the services separately (for example by using a naming 
convention like you propose).

>also, I remember seeing a suggestion that we use a E2I for the ENUM
>service name (instead of N2R) - is that at all applicable to this
>draft?

Let me check with the NAPTR people.

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul 13 14:04:07 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03326
	for <enum-archive@odin.ietf.org>; Thu, 13 Jul 2000 14:04:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24882;
	Thu, 13 Jul 2000 14:01:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24858
	for <enum@ns.ietf.org>; Thu, 13 Jul 2000 14:01:32 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03103
	for <enum@ietf.org>; Thu, 13 Jul 2000 14:01:30 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 45A7317B7; Thu, 13 Jul 2000 20:01:01 +0200 (MET DST)
Received: from [10.0.0.6] ([171.70.221.22])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA17913;
	Thu, 13 Jul 2000 20:00:55 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p04320436b593b42e2fa4@[10.0.0.6]>
In-Reply-To: <p0432042eb593a551b1d0@[10.0.0.6]>
References: <01D91AFB08B6D211BFD00008C7EABAE1031DED68@eseis04nok>
 <p0432042eb593a551b1d0@[10.0.0.6]>
Date: Thu, 13 Jul 2000 11:00:28 -0700
To: john.loughney@nokia.com, paf@swip.net
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in
  	t  ?
Cc: enum@ietf.org
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

At 09.59 -0700 00-07-13, Patrik Fältström wrote:
>>also, I remember seeing a suggestion that we use a E2I for the ENUM
>>service name (instead of N2R) - is that at all applicable to this
>>draft?
>
>Let me check with the NAPTR people.

Ok, I will do a new version with E2I defined, and explain why.

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul 13 16:39:05 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18417
	for <enum-archive@odin.ietf.org>; Thu, 13 Jul 2000 16:39:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27159;
	Thu, 13 Jul 2000 16:36:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27126
	for <enum@ns.ietf.org>; Thu, 13 Jul 2000 16:36:25 -0400 (EDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17265
	for <enum@ietf.org>; Thu, 13 Jul 2000 16:36:18 -0400 (EDT)
From: john.loughney@nokia.com
Received: from esvir06nok.ntc.nokia.com (esvir06nok.ntc.nokia.com [131.228.10.155])
	by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id XAA02885
	for <enum@ietf.org>; Thu, 13 Jul 2000 23:36:14 +0300 (EETDST)
Received: from esebh03nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e40a9b1c84d5c4a2860@esvir06nok.ntc.nokia.com>;
 Wed, 12 Jul 2000 14:40:45 +0300
Received: by esebh03nok with Internet Mail Service (5.5.2650.10)
	id <3WZXFLFM>; Wed, 12 Jul 2000 14:40:45 +0300
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DED50@eseis04nok>
To: enum@ietf.org, sigtran@standards.nortelnetworks.com
Date: Wed, 12 Jul 2000 14:40:44 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Enum] RE: I-D ACTION:draft-loughney-enum-sigtran-00.txt
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi all,

Please comment on this draft, if you have the time.  I've realized that
I did not get the syntaxt of the NAPTR exactly correct - I will 
update that asap.  

thanks,
John Loughney


> -----Original Message-----
> From: EXT Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: July 12, 2000 13:31
> To: SIGTRAN@STANDARDS.NORTELNETWORKS.COM
> Subject: I-D ACTION:draft-loughney-enum-sigtran-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
>         Title           : The Use of ENUM Services by 
> Signaling Transport
>                           Protocols
>         Author(s)       : J. Loughney
>         Filename        : draft-loughney-enum-sigtran-00.txt
>         Pages           : 6
>         Date            : 11-Jul-00
> 
> This draft proposes to use ENUM resolution to support signaling
> transport.  This draft outlines the resolution E.164 numbers 
> by NAPTR in
> DNS to a service location.  Considerations need to be made for
> scalability, reliability and performance.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-loughney-enum-sigtran-00.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-loughney-enum-sigtran-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         mailserv@ietf.org.
> In the body type:
>         "FILE /internet-drafts/draft-loughney-enum-sigtran-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need 
> "munpack" or
>         a MIME-compliant mail reader.  Different 
> MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have 
> been split
>         up into multiple messages), so check your local 
> documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 03:11:14 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17021
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 03:11:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10200;
	Fri, 14 Jul 2000 03:10:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10169
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 03:10:51 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16930
	for <enum@ietf.org>; Fri, 14 Jul 2000 03:10:51 -0400 (EDT)
From: john.loughney@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nok.ntc.nokia.com [131.228.10.150])
	by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id KAA01120
	for <enum@ietf.org>; Fri, 14 Jul 2000 10:10:42 +0300 (EETDST)
Received: from esebh03nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e40a96c54d659f6a84@esvir01nok.ntc.nokia.com>;
 Fri, 14 Jul 2000 10:10:28 +0300
Received: by esebh03nok with Internet Mail Service (5.5.2650.10)
	id <3WZXKJ7Z>; Fri, 14 Jul 2000 10:10:27 +0300
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DED7F@eseis04nok>
To: paf@cisco.com
Cc: enum@ietf.org
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in
	 t  ?
Date: Fri, 14 Jul 2000 10:09:50 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Patrik,

> No, in DNS you always get back all RRs which have the same "owner", 
> and for NAPTRs that is 4.3.2.1.6.7.9.8.6.4.e164.arpa.
> 
> There is no definition at the moment for the NAPTR RRs to request 
> only one of the services separately (for example by using a naming 
> convention like you propose).

To whom should I talk to about this?  I feel that there might
be a scalability issue with ENUMs & NAPTR.  The reason being
is that if you have a 1 800 number (for example), there
might be a lot of services defined for it, which would like
to use DNS.  I think that quite quickly, we may see some
scalability issues.  Best to attempt to solve them now.

cheers,
John

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 10:40:09 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14375
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 10:40:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14791;
	Fri, 14 Jul 2000 10:38:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14767
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 10:38:50 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13971
	for <enum@ietf.org>; Fri, 14 Jul 2000 10:38:49 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id CDE9F199; Fri, 14 Jul 2000 16:38:19 +0200 (MET DST)
Received: from [10.0.0.7] ([171.70.221.22])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA29464;
	Fri, 14 Jul 2000 16:38:18 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p0432040bb594d3a897d1@[10.0.0.7]>
In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE1031DED7F@eseis04nok>
References: <01D91AFB08B6D211BFD00008C7EABAE1031DED7F@eseis04nok>
Date: Fri, 14 Jul 2000 07:29:03 -0700
To: john.loughney@nokia.com
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in
 	 t  ?
Cc: enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 10.09 +0300 00-07-14, john.loughney@nokia.com wrote:
>To whom should I talk to about this?  I feel that there might
>be a scalability issue with ENUMs & NAPTR.  The reason being
>is that if you have a 1 800 number (for example), there
>might be a lot of services defined for it, which would like
>to use DNS.  I think that quite quickly, we may see some
>scalability issues.  Best to attempt to solve them now.

How many?

I.e. I don't understand what you belive is a scalability issue. You 
also have to think about what is handled through different URIs 
(different NAPTRs) and what is handled through the URI resolution.

It could be more interesting to query on the service field than the protocol.

   paf


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 11:46:10 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07741
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 11:46:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15617;
	Fri, 14 Jul 2000 11:45:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15592
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 11:45:13 -0400 (EDT)
Received: from hvmta02-stg.us.psimail.psi.net (hvmta02-ext.us.psimail.psi.net [38.202.36.30])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07421
	for <enum@ietf.org>; Fri, 14 Jul 2000 11:45:11 -0400 (EDT)
Received: from seagal ([208.146.135.202]) by hvmta02-stg.us.psimail.psi.net
          (InterMail v4.01.01.00 201-229-111) with SMTP
          id <20000714154441.LPYQ26052.hvmta02-stg@seagal>;
          Fri, 14 Jul 2000 11:44:41 -0400
From: "David P. Peek" <dpeek@netnumber.com>
To: =?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= <paf@cisco.com>,
        <john.loughney@nokia.com>
Cc: <enum@ietf.org>
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in	 t  ?
Date: Fri, 14 Jul 2000 11:39:20 -0400
Message-ID: <NEBBIIBBHJMPEMJAACBPEECBCDAA.dpeek@netnumber.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <p0432040bb594d3a897d1@[10.0.0.7]>
Content-Transfer-Encoding: 8bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

In reference to the scalability issue...

With the way ENUM requirements are defined today the Fältström draft
supports these requirements by returning all the services based on a query.

I agree that there are scalability issues with this approach that is why the
http://search.ietf.org/internet-drafts/draft-peek-enum-itd-00.txt draft
supports 'application specific queries' which allows specific service
information to be retrieved separately based on a known service ("Service
Protocal") thereby limiting the amount of information returned solving the
scalability issue. (ie. sip.x.x.x.x.x.x.e164.arpa)

NetNumber has built and deployed the implementation as described in the
above draft and is also prepared to support the outcome of ENUM once it is
defined.
Dave




-----Original Message-----
From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of
Patrik Fältström
Sent: Friday, July 14, 2000 10:29 AM
To: john.loughney@nokia.com
Cc: enum@ietf.org
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.in
t ?


At 10.09 +0300 00-07-14, john.loughney@nokia.com wrote:
>To whom should I talk to about this?  I feel that there might
>be a scalability issue with ENUMs & NAPTR.  The reason being
>is that if you have a 1 800 number (for example), there
>might be a lot of services defined for it, which would like
>to use DNS.  I think that quite quickly, we may see some
>scalability issues.  Best to attempt to solve them now.

How many?

I.e. I don't understand what you belive is a scalability issue. You
also have to think about what is handled through different URIs
(different NAPTRs) and what is handled through the URI resolution.

It could be more interesting to query on the service field than the
protocol.

   paf


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 12:11:42 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15928
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 12:11:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16087;
	Fri, 14 Jul 2000 12:10:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16063
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 12:10:54 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15647
	for <enum@ietf.org>; Fri, 14 Jul 2000 12:10:52 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 55D0F135; Fri, 14 Jul 2000 18:10:23 +0200 (MET DST)
Received: from [10.0.0.7] (dhcp-2sjc13-85-108.cisco.com [171.70.85.108])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA11992;
	Fri, 14 Jul 2000 18:10:21 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p04320421b594eb193276@[10.0.0.7]>
In-Reply-To: <NEBBIIBBHJMPEMJAACBPEECBCDAA.dpeek@netnumber.com>
References: <NEBBIIBBHJMPEMJAACBPEECBCDAA.dpeek@netnumber.com>
Date: Fri, 14 Jul 2000 09:07:01 -0700
To: "David P. Peek" <dpeek@netnumber.com>, <john.loughney@nokia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in
  t  ?
Cc: <enum@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 11.39 -0400 00-07-14, David P. Peek wrote:
>I agree that there are scalability issues

What scalability issues?

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 12:40:18 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26036
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 12:40:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16409;
	Fri, 14 Jul 2000 12:39:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16379
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 12:39:26 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25785;
	Fri, 14 Jul 2000 12:39:26 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 5B45D11A; Fri, 14 Jul 2000 18:38:55 +0200 (MET DST)
Received: from [10.0.0.7] (dhcp-2sjc13-85-108.cisco.com [171.70.85.108])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA15235;
	Fri, 14 Jul 2000 18:38:53 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p04320429b594f0b48395@[10.0.0.7]>
Date: Fri, 14 Jul 2000 09:39:16 -0700
To: internet-drafts@ietf.org
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Cc: enum@ietf.org
Content-Type: text/plain; charset="us-ascii"
Subject: [Enum] draft-enum-e164-dns
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Here is a new version of draft-enum-e164-dns for publication. Changes 
sections are 3.1, which talks about a new NAPTR servce, E2U for E.164 
-> URL resolution. I have also done spell checking of the document :-)

    Regards, Patrik

Network Working Group                                        P Faltstrom
Internet-Draft                                         Cisco Systems Inc
Expires: January 12, 2001                                  July 14, 2000


                          E.164 number and DNS
                         draft-enum-e164-dns-02

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 12, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

   This document discusses the use of DNS for storage of E.164 numbers.
   More specifically, how DNS can be used for identifying available
   services connected to one E.164 number. Routing of the actual
   connection using the service selected using these methods is not
   discussed.










Faltstrom               Expires January 12, 2001                [Page 1]

Internet-Draft            E.164 number and DNS                 July 2000


1. Introduction

   Through transformation of E.164 numbers into DNS names and the use
   of existing DNS services like delegation through NS records, and use
   of NAPTR[1] records in DNS[2][3], one can look up what services are
   available for a specific domainname in a decentralized way with
   distributed management of the different levels in the lookup
   process. 

1.1 Terminology

   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
   in this document are to be interpreted as described in RFC2119[4]






































Faltstrom               Expires January 12, 2001                [Page 2]

Internet-Draft            E.164 number and DNS                 July 2000


2. E.164 numbers and DNS

   The domain "e164.arpa." is being populated in order to provide the
   infrastructure in DNS for storage of E.164 numbers. In order to
   facilitate distributed operations, this domain is divided into
   subdomains. Holders of E.164 numbers which want to be listed in DNS
   should contact the appropriate zone administrator in order to be
   listed, by examining the SOA resource record associated with the
   zone, just like in normal DNS operations. 

   To find the DNS names for a specific E.164 number, the following
   procedure is to be followed: 

   1.  See that the E.164 number is written in its full form, including
       the countrycode IDDD. Example: +46-8-9761234 

   2.  Remove all non-digit characters part from the leading '+'.
       Example: +4689761234 

   3.  Remove all characters part from the digits. Example: 4689761234 

   4.  Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4 

   5.  Change the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4 

   6.  Append the domain "e164.arpa" to the end. Example:
       4.3.2.1.6.7.9.8.6.4.e164.arpa 
























Faltstrom               Expires January 12, 2001                [Page 3]

Internet-Draft            E.164 number and DNS                 July 2000


3. Fetching URIs given an E.164 number

   For a record in DNS, the NAPTR record is used for identifying
   available ways of contacting a specific node identified by that
   name. Specifically it can be used for knowing what services exists
   for a specific domainname, including phone numbers by the use of the
   e164.arpa domain as described above. 

   The identification is using the NAPTR resource record defined for
   use in the URN resolution process, but it can be generalized in a
   way that suits the needs specified in this document. 

   It is the string which is the result of step 2 in section 2 above
   which is input to the NAPTR algorithm. 

3.1 The NAPTR record

   The key fields in the NAPTR RR are order, preference, service,
   flags, regexp, and replacement. For a detailed description, see: 

   o  The order field specifies the order in which records MUST be
      processed when multiple NAPTR records are returned in response to
      a single query. 

   o  The preference field specifies the order in which records SHOULD
      be processed when multiple NAPTR records have the same value of
      "order". 

   o  The service field specifies the resolution protocol and
      resolution service(s) that will be available if the rewrite
      specified by the regexp or replacement fields is applied. 

   o  The flags field contains modifiers that affect what happens in
      the next DNS lookup, typically for optimizing the process. 

   o  The regexp field is one of two fields used for the rewrite rules,
      and is the core concept of the NAPTR record. 

   o  The replacement field is the other field that may be used for the
      rewrite rule. 

   Note that the client applies all the substitutions and performs all
   lookups, they are not performed in the DNS servers. Note that URIs
   are stored in the regexp field. 

3.1.1 Specification for use of NAPTR Resource Records

   The input is an E.164 encoded telephone number. The output is a
   Uniform Resource Identifier in its absolute form according to the


Faltstrom               Expires January 12, 2001                [Page 4]

Internet-Draft            E.164 number and DNS                 July 2000


   'absoluteURI' production in the Collected ABNF found in RFC2396[5]

   An E.164 number, without any characters but leading '+' and digits,
   (result of step 2 in section 2 above) is the input to the NAPTR
   algorithm. 

   The service supported for a call is E2U. 

3.1.2 Specification of Service E2U (E.164 to URI)

   * Name: E.164 to URI
   * Mnemonic: E2U
   * Number of Operands: 1
   * Type of Each Operand: First operand is an E.164 number.
   * Format of Each Operand: First operand is the E.164 number in the
     form as specified in step 2 in section 2 in this document.
   * Algorithm: Opaque
   * Output: One or more URLs
   * Errors Conditions:
      o E.164 number not in the numbering plan
      o E.164 number in the numbering plan, but no URLs exist for
        that number
      o Access denied

   * Security Considerations:
      o Malicious Redirection
        One of the fundamental dangers related to any service such
        as this is that a malicious entry in a resolver's database
        will cause clients to resolve the E.164 into the wrong URL.
        The possible intent may be to cause the client to retrieve
        a resource containing fraudulent or damaging material.
      o Denial of Service
        By removing the URL to which the E.164 maps, a malicious
        intruder may remove the client's ability to access the
        resource.

   This operation is used to map a one E.164 number to a list of URIs.
   The first well-known step in the resolution process is to remove all
   non-digits part from the leading '+' from the E.164 number as
   described in step 1 and 2 in section 2 of this document. 

3.2 Examples

3.2.1 Example 1

   $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
    IN NAPTR 100 10 "u" "sip+E2U"  "!^.*$!sip:info@tele2.se!"     .
    IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:info@tele2.se!"  .

   This describes that the domain tele2.se is preferable contacted via


Faltstrom               Expires January 12, 2001                [Page 5]

Internet-Draft            E.164 number and DNS                 July 2000


   the SIP protocol, secondly via SMTP. 

   In both cases, the next step in the resolution process is to use the
   resolution mechanism for each of the protocols, (SIP and SMTP) to
   know what node to contact for each. 

3.2.2 Example 2

   $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
    IN NAPTR  10 10 "u" "sip+E2U"   "!^.*$!sip:paf@swip.net!"     .
    IN NAPTR 102 10 "u" "smtp+E2U"  "!^.*$!mailto:paf@swip.net!"  .
    IN NAPTR 102 10 "u" "tel+E2U"   "!^.*$!tel:+4689761234!"      .

   Note that the preferred method is to use the SIP protocol, but the
   result of the rewrite of the NAPTR record is a URI (the "u" flag in
   the NAPTR record). In the case of the protocol SIP, the URI might be
   a SIP URI, which is resolved as described in RFC 2543[6]. In the
   case of the "tel" URI scheme[7], the procedure is restarted with
   this new E.164 number. The client is responsible for loop detection. 

   The rest of the resolution of the routing is done as described
   above. 

3.2.3 Example 3

   $ORIGIN 6.4.e164.arpa.
   * IN NAPTR 100 10 "u" "sip+E2U" "!^+46(.*)$!ldap://ldap.example.se/cn=0$1!" .

   We see in this example that information about all E.164 numbers in
   the 46 countrycode (for Sweden) exists in an LDAP server, and the
   search to do is specified by the LDAP URI[8]. 




















Faltstrom               Expires January 12, 2001                [Page 6]

Internet-Draft            E.164 number and DNS                 July 2000


4. IANA considerations

   IANA is to create the E164.ARPA domain in the ARPA zone, and
   delegate names in the zone to parties according to the ITU
   recommendation E.164. The names allocated should be hierarchically
   allocated according to the description in this document, and the
   codes assigned in the E.164 recommendation by ITU. 

   Delegations should be done after Expert Review, and the IESG will
   appoint a designated expert. 









































Faltstrom               Expires January 12, 2001                [Page 7]

Internet-Draft            E.164 number and DNS                 July 2000


5. Security Considerations

   As this system is built on top of DNS, one can not be sure that the
   information one get back from DNS is more secure than any DNS query.
   To solve that, the use of DNSSEC[9] for securing and verifying zones
   is to be recommended. 

   The caching in DNS can make the propagation time for a change take
   the same amount of time as the time to live for the NAPTR and
   SRV[10] records in the zone that is changed. The TTL should because
   of that be kept to a minimum. The use of this in an environment
   where IP-addresses are for hire (for example when using DHCP[11])
   must therefore be done very carefully. 






































Faltstrom               Expires January 12, 2001                [Page 8]

Internet-Draft            E.164 number and DNS                 July 2000


6. Acknowledgement

   Support and ideas has come from people at Ericsson, especially Bjorn
   Larsson, especially the group which implemented this scheme in their
   lab to see that it worked. Input has also come from ITU-T SG2,
   Working Party 1/2 (Numbering, Routing, Global Mobility and Service
   Definition), the ENUM working group in the IETF, and Leif Sunnegardh
   at Tele2 for information about how SS7 really works. 











































Faltstrom               Expires January 12, 2001                [Page 9]

Internet-Draft            E.164 number and DNS                 July 2000


References

   [1]  Mealling, M and R Daniel, "The Naming Authority Pointer (NAPTR)
        DNS Resource Record", draft-ietf-urn-naptr-rr-03.txt (work in
        progress), June 1998.

   [2]  Mockapetris, P.V., "Domain names - concepts and facilities",
        RFC 1034, STD 13, Nov 1987.

   [3]  Mockapetris, P.V., "Domain names - implementation and
        specification", RFC 1035, STD 13, Nov 1987.

   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, BCP 14, March 1997.

   [5]  Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
        Resource Identifiers (URI): Generic Syntax", RFC 2396, August
        1998.

   [6]  Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
        "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [7]  Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
        2000.

   [8]  Howes, T. and M. Smith, "An LDAP URL Format", RFC 1959, June
        1996.

   [9]  Eastlake, D., "Domain Name System Security Extensions", RFC
        2535, March 1999.

   [10]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
         specifying the location of services (DNS SRV)", RFC 2782,
         February 2000.

   [11]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
         March 1997.


Author's Address

   Patrik Faltstrom
   Cisco Systems Inc
   170 W Tasman Drive SJ-13/2
   San Jose CA 95134
   USA

   EMail: paf@cisco.com
   URI:   http://www.cisco.com


Faltstrom               Expires January 12, 2001               [Page 10]

Internet-Draft            E.164 number and DNS                 July 2000


Appendix A. Scenario

   Say that the content of the e164.arpa zone is the following: 


   $ORIGIN e164.arpa.
   6.4 IN NS ns.regulator-e164.example.se.

   The regulator has in turn given a series of 10000 numbers to the
   telco with the name Telco-A. The regulator because of that has in
   his DNS. 


   $ORIGIN 6.4.e164.arpa.
   6.7.9.8 IN NS ns.telco-a.example.se.

   A user named Sven Svensson has from Telco A got the phone number
   +46-8-9761234. The user gets the service of running DNS from the
   company Redirection Service. Sven Svensson has asked Telco A to
   point out Redirection Service as the authoritative source for
   information about the number +46-8-9761234. Telco A because of this
   puts in his DNS the following. 


   $ORIGIN 6.7.9.8.6.4.e164.arpa.
   4.3.2.1 IN NS ns.redirection-service.example.se.

   Sven Svensson has already plain telephony from Telco A, but also a
   SIP service from the company Sip Service which provides Sven with
   the SIP URI "sip:sven@sipservice.example.se". The ISP with the name
   ISP A runs email and webpages for Sven, under the email address
   sven@ispa.example.se, and URL http://svensson.ispa.example.se. 

   The DNS for the redirection service because of this contains the
   following. 


   $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
    IN NAPTR 10 10 "a" "sip+E2U"  "!^.*$!sip:sven@sipservice.example.se!"  .
    IN NAPTR 10 10 "a" "smtp+E2U" "!^.*$!mailto:sven@ispa.example.se!"     .
    IN NAPTR 10 10 "a" "http+E2U" "!^.*$!http://svensson.ispa.example.se!" .
    IN NAPTR 10 10 "a" "tel+E2U"  "!^.*$!tel:+46-8-9761234!"               .

   A user, John Smith, want to contact Sven Svensson, he to start with
   only has the E.164 number of Sven, i.e. +46-8-9761234. He takes the
   number, and enters the number in his communication client, which
   happen to know how to handle the SIP protocol. The client removes
   the dashes, and ends up with the E.164 number +4689761234. That is
   what is used in the algorithm for NAPTR records, which is as


Faltstrom               Expires January 12, 2001               [Page 11]

Internet-Draft            E.164 number and DNS                 July 2000


   follows. 

   The client converts the E.164 number into the domainname
   4.3.2.1.6.7.9.8.6.4.e164.arpa., and queries for NAPTR records for
   this domainname. Using DNS mechanisms which includes following the
   NS record referrals, the following records are returned: 


   $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
    IN NAPTR 10 10 "a" "sip+E2U"  "!^.*$!sip:sven@sipservice.example.se"  .
    IN NAPTR 10 10 "a" "smtp+E2U" "!^.*$!mailto:sven@ispa.example.se"     .
    IN NAPTR 10 10 "a" "http+E2U" "!^.*$!http://svensson.ispa.example.se" .
    IN NAPTR 10 10 "a" "tel+E2U"  "!^.*$!tel:+46-8-9761234"               .

   Because this client know sip, the first record above is selected,
   and the SIP URI is extracted, and used according to SIP resolution. 



































Faltstrom               Expires January 12, 2001               [Page 12]

Internet-Draft            E.164 number and DNS                 July 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC editor function is currently provided by the
   Internet Society.



















Faltstrom               Expires January 12, 2001               [Page 13]


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 14:21:17 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27738
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 14:21:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17590;
	Fri, 14 Jul 2000 14:19:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17562
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 14:19:37 -0400 (EDT)
Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27333
	for <enum@ietf.org>; Fri, 14 Jul 2000 14:19:35 -0400 (EDT)
Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id OAA07242; Fri, 14 Jul 2000 14:09:13 -0400 (EDT)
Date: Fri, 14 Jul 2000 14:09:12 -0400
From: Michael Mealling <michael@bailey.dscga.com>
To: "David P. Peek" <dpeek@netnumber.com>
Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        john.loughney@nokia.com, enum@ietf.org
Subject: Re: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in	 t  ?
Message-ID: <20000714140912.H7073@bailey.dscga.com>
Reply-To: michaelm@netsol.com
References: <p0432040bb594d3a897d1@[10.0.0.7]> <NEBBIIBBHJMPEMJAACBPEECBCDAA.dpeek@netnumber.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.1.2i
In-Reply-To: <NEBBIIBBHJMPEMJAACBPEECBCDAA.dpeek@netnumber.com>; from dpeek@netnumber.com on Fri, Jul 14, 2000 at 11:39:20AM -0400
Content-Transfer-Encoding: 8bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

On Fri, Jul 14, 2000 at 11:39:20AM -0400, David P. Peek wrote:
> With the way ENUM requirements are defined today the Fältström draft
> supports these requirements by returning all the services based on a query.
> 
> I agree that there are scalability issues with this approach that is why the
> http://search.ietf.org/internet-drafts/draft-peek-enum-itd-00.txt draft
> supports 'application specific queries' which allows specific service
> information to be retrieved separately based on a known service ("Service
> Protocal") thereby limiting the amount of information returned solving the
> scalability issue. (ie. sip.x.x.x.x.x.x.e164.arpa)

I've heard this several times but I've never seen a single example
of anything that advertises more than a small handful of services.
How many different ways are there to make a telephone call these days 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          |  michaelm@netsol.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 15:13:06 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16341
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 15:13:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18382;
	Fri, 14 Jul 2000 15:12:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18353
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 15:12:37 -0400 (EDT)
Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16148
	for <enum@ietf.org>; Fri, 14 Jul 2000 15:12:35 -0400 (EDT)
Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1])
	by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA29498
	for <enum@ietf.org>; Fri, 14 Jul 2000 15:12:36 -0400 (EDT)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53])
	by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA29487
	for <enum@ietf.org>; Fri, 14 Jul 2000 15:12:35 -0400 (EDT)
Received: from buzz.ons.octel.com by ihrh1.emsr.lucent.com (8.8.8+Sun/EMS-1.5 Solaris/emsr)
	id OAA26998 for <enum@ietf.org>; Fri, 14 Jul 2000 14:12:33 -0500 (CDT)
Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200])
	by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id OAA25943
	for <enum@ietf.org>; Fri, 14 Jul 2000 14:12:33 -0500 (CDT)
Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0)
	id <KXYSH4PF>; Fri, 14 Jul 2000 14:09:02 -0500
Message-ID: <6B57F36F4FF9D111B30A0008C7F41337037051F5@exdal1.ons.octel.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: enum@ietf.org
Date: Fri, 14 Jul 2000 14:08:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [Enum] Rough Consensus or time to revist the charter?
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org


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
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 15:13:15 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16397
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 15:13:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18419;
	Fri, 14 Jul 2000 15:12:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18392
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 15:12:40 -0400 (EDT)
Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16167
	for <enum@ietf.org>; Fri, 14 Jul 2000 15:12:38 -0400 (EDT)
Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1])
	by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA29551
	for <enum@ietf.org>; Fri, 14 Jul 2000 15:12:38 -0400 (EDT)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53])
	by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA29494;
	Fri, 14 Jul 2000 15:12:36 -0400 (EDT)
Received: from buzz.ons.octel.com by ihrh1.emsr.lucent.com (8.8.8+Sun/EMS-1.5 Solaris/emsr)
	id OAA27000 for ; Fri, 14 Jul 2000 14:12:33 -0500 (CDT)
Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200])
	by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id OAA25941;
	Fri, 14 Jul 2000 14:12:33 -0500 (CDT)
Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0)
	id <KXYSH4P1>; Fri, 14 Jul 2000 14:09:02 -0500
Message-ID: <6B57F36F4FF9D111B30A0008C7F41337037051F6@exdal1.ons.octel.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: michaelm@netsol.com, "David P. Peek" <dpeek@netnumber.com>
Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        john.loughney@nokia.com, enum@ietf.org
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in
		 t  ?
Date: Fri, 14 Jul 2000 14:08:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA18393
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit


Aaarg.  Why do people continue to think ENUM is only about phone calls????

There are half-a-dozen ways to send a message using a telephone number....
each completely different services, each of which may have alternatives.

There dozens of potential information services that may be provided behind a
telephone number....

Not to restate the obvious, but phone number are useful!  As long as the
telephone keypad is the primary user interface on the vast majority of
legacy and NEW communications terminals, the number of messaging, calling,
and information services so addressed will continue to expand.

Greg V.



-----Original Message-----
From: Michael Mealling [mailto:michael@bailey.dscga.com]
Sent: Friday, July 14, 2000 1:09 PM
To: David P. Peek
Cc: Patrik Fältström; john.loughney@nokia.com; enum@ietf.org
Subject: Re: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.in
t ?


On Fri, Jul 14, 2000 at 11:39:20AM -0400, David P. Peek wrote:
> With the way ENUM requirements are defined today the Fältström draft
> supports these requirements by returning all the services based on a
query.
> 
> I agree that there are scalability issues with this approach that is why
the
> http://search.ietf.org/internet-drafts/draft-peek-enum-itd-00.txt draft
> supports 'application specific queries' which allows specific service
> information to be retrieved separately based on a known service ("Service
> Protocal") thereby limiting the amount of information returned solving the
> scalability issue. (ie. sip.x.x.x.x.x.x.e164.arpa)

I've heard this several times but I've never seen a single example
of anything that advertises more than a small handful of services.
How many different ways are there to make a telephone call these days
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          |
michaelm@netsol.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 15:15:53 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17401
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 15:15:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18551;
	Fri, 14 Jul 2000 15:15:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18518
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 15:15:33 -0400 (EDT)
Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17269
	for <enum@ietf.org>; Fri, 14 Jul 2000 15:15:31 -0400 (EDT)
Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id PAA07505; Fri, 14 Jul 2000 15:05:06 -0400 (EDT)
Date: Fri, 14 Jul 2000 15:05:06 -0400
From: Michael Mealling <michael@bailey.dscga.com>
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
Cc: michaelm@netsol.com, "David P. Peek" <dpeek@netnumber.com>,
        =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        john.loughney@nokia.com, enum@ietf.org
Subject: Re: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in t  ?
Message-ID: <20000714150506.B7480@bailey.dscga.com>
Reply-To: michaelm@netsol.com
References: <6B57F36F4FF9D111B30A0008C7F41337037051F6@exdal1.ons.octel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.2i
In-Reply-To: <6B57F36F4FF9D111B30A0008C7F41337037051F6@exdal1.ons.octel.com>; from gregv@lucent.com on Fri, Jul 14, 2000 at 02:08:58PM -0500
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

On Fri, Jul 14, 2000 at 02:08:58PM -0500, Vaudreuil, Greg M (Greg) wrote:
> Aaarg.  Why do people continue to think ENUM is only about phone calls????
> 
> There are half-a-dozen ways to send a message using a telephone number....
> each completely different services, each of which may have alternatives.
> 
> There dozens of potential information services that may be provided behind a
> telephone number....
> 
> Not to restate the obvious, but phone number are useful!  As long as the
> telephone keypad is the primary user interface on the vast majority of
> legacy and NEW communications terminals, the number of messaging, calling,
> and information services so addressed will continue to expand.

Point taken. But the question still stands:

Do you really expect more than a handful? And if so what might they
be and why so many?

-MM


-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 15:19:31 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18764
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 15:19:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18675;
	Fri, 14 Jul 2000 15:19:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18606
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 15:19:05 -0400 (EDT)
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18580
	for <enum@ietf.org>; Fri, 14 Jul 2000 15:19:02 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id PAA21437;
	Fri, 14 Jul 2000 15:18:24 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id PAA23476; Fri, 14 Jul 2000 15:17:14 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2650.21)
	id <3352QR5C>; Fri, 14 Jul 2000 15:18:23 -0400
Message-ID: <B13F591F20ACD311BE4300902761550F12673C@njb140po06.ems.att.com>
From: "Lind, Steven D, ALCOO" <sdlind@att.com>
To: "'Vaudreuil, Greg M (Greg)'" <gregv@lucent.com>, michaelm@netsol.com,
        "David P. Peek" <dpeek@netnumber.com>
Cc: Patrik Faltstrom <paf@cisco.com>, john.loughney@nokia.com, enum@ietf.org
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in
	 t  ?
Date: Fri, 14 Jul 2000 15:18:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA18607
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

Greg,

I sympathize with your frustration. I guess we (myself included) refer to
phone calls when talking about ENUM because it is the most pervasive
application that would make use of the process. I totally agree that there
are lots of other applications that could make use of ENUM.

Thanks for reminding us not to leave our heads in the sand too long. :-)

Steve

---------------------------------------------------------------
Steven D. Lind                   Tel: (973) 236-6787
AT&T                             Fax: (973) 236-6452  
180 Park Ave., Bldg. 2            e-mail: sdlind@att.com
Florham Park, NJ 07932        web: sdlind.ips.att.com         
---------------------------------------------------------------


> -----Original Message-----
> From:	Vaudreuil, Greg M (Greg) [SMTP:gregv@lucent.com]
> Sent:	Friday, July 14, 2000 3:09 PM
> To:	michaelm@netsol.com; David P. Peek
> Cc:	Patrik Faltstrom; john.loughney@nokia.com; enum@ietf.org
> Subject:	RE: [Enum] FW: Last Call or New Draft? - .arpa or
> .e;164.itu.in t  ?
> 
> 
> Aaarg.  Why do people continue to think ENUM is only about phone calls????
> 
> There are half-a-dozen ways to send a message using a telephone number....
> each completely different services, each of which may have alternatives.
> 
> There dozens of potential information services that may be provided behind
> a
> telephone number....
> 
> Not to restate the obvious, but phone number are useful!  As long as the
> telephone keypad is the primary user interface on the vast majority of
> legacy and NEW communications terminals, the number of messaging, calling,
> and information services so addressed will continue to expand.
> 
> Greg V.
> 
> 
> 
> -----Original Message-----
> From: Michael Mealling [mailto:michael@bailey.dscga.com]
> Sent: Friday, July 14, 2000 1:09 PM
> To: David P. Peek
> Cc: Patrik Fältström; john.loughney@nokia.com; enum@ietf.org
> Subject: Re: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.in
> t ?
> 
> 
> On Fri, Jul 14, 2000 at 11:39:20AM -0400, David P. Peek wrote:
> > With the way ENUM requirements are defined today the Fältström draft
> > supports these requirements by returning all the services based on a
> query.
> > 
> > I agree that there are scalability issues with this approach that is why
> the
> > http://search.ietf.org/internet-drafts/draft-peek-enum-itd-00.txt draft
> > supports 'application specific queries' which allows specific service
> > information to be retrieved separately based on a known service
> ("Service
> > Protocal") thereby limiting the amount of information returned solving
> the
> > scalability issue. (ie. sip.x.x.x.x.x.x.e164.arpa)
> 
> I've heard this several times but I've never seen a single example
> of anything that advertises more than a small handful of services.
> How many different ways are there to make a telephone call these days
> 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          |
> michaelm@netsol.com
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 15:58:31 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00049
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 15:58:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19204;
	Fri, 14 Jul 2000 15:53:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19174
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 15:53:49 -0400 (EDT)
Received: from rip.psg.com (rip.psg.com [147.28.0.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28916
	for <enum@ietf.org>; Fri, 14 Jul 2000 15:53:47 -0400 (EDT)
Received: from randy by rip.psg.com with local (Exim 3.13 #1)
	id 13DBWs-000NBn-00; Fri, 14 Jul 2000 12:53:46 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
Cc: enum@ietf.org
Subject: Re: [Enum] Rough Consensus or time to revist the charter?
References: <6B57F36F4FF9D111B30A0008C7F41337037051F5@exdal1.ons.octel.com>
Message-Id: <E13DBWs-000NBn-00@rip.psg.com>
Date: Fri, 14 Jul 2000 12:53:46 -0700
Content-Transfer-Encoding: 7bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

> 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

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

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 16:14:10 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04069
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 16:14:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19485;
	Fri, 14 Jul 2000 16:13:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19462
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 16:13:31 -0400 (EDT)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03889
	for <enum@ietf.org>; Fri, 14 Jul 2000 16:13:28 -0400 (EDT)
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch1.nortel.com; Fri, 14 Jul 2000 15:09:43 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <37KRJB7T>; Fri, 14 Jul 2000 15:12:23 -0500
Message-ID: <31AF4D00A662D211B6D10000F8BCBC24018D276E@bcarua63.ca.nortel.com>
From: "Anne Brown" <arbrown@nortelnetworks.com>
To: "'michaelm@netsol.com'" <michaelm@netsol.com>,
        "David P. Peek" <dpeek@netnumber.com>
Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        john.loughney@nokia.com, enum@ietf.org
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.in t ?
Date: Fri, 14 Jul 2000 15:11:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFEDCF.D24365CE"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFEDCF.D24365CE
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Michael,

We are, hopefully, providing information on more services than just
telephone calls.  For example, voice messaging over the Internet using =
SMTP.

Regards,

Anne Brown
Nortel Networks
arbrown@nortelnetworks.com
+1 613 765 5274

 -----Original Message-----
From: 	Michael Mealling [mailto:michael@bailey.dscga.com]=20
Sent:	July 14, 2000 2:09 PM
To:	David P. Peek
Cc:	Patrik F=E4ltstr=F6m; john.loughney@nokia.com; enum@ietf.org
Subject:	Re: [Enum] FW: Last Call or New Draft? - .arpa or
.e;164.itu.in t ?

On Fri, Jul 14, 2000 at 11:39:20AM -0400, David P. Peek wrote:
> With the way ENUM requirements are defined today the F=E4ltstr=F6m =
draft
> supports these requirements by returning all the services based on a
query.
>=20
> I agree that there are scalability issues with this approach that is =
why
the
> http://search.ietf.org/internet-drafts/draft-peek-enum-itd-00.txt =
draft
> supports 'application specific queries' which allows specific service
> information to be retrieved separately based on a known service =
("Service
> Protocal") thereby limiting the amount of information returned =
solving the
> scalability issue. (ie. sip.x.x.x.x.x.x.e164.arpa)

I've heard this several times but I've never seen a single example
of anything that advertises more than a small handful of services.
How many different ways are there to make a telephone call these days
anyway?

-MM

--=20
------------------------------------------------------------------------=
----
----
Michael Mealling	|      Vote Libertarian!       |
www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:
14198821
Network Solutions	|          www.lp.org          |
michaelm@netsol.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

------_=_NextPart_001_01BFEDCF.D24365CE
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.in =
t ?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Michael,</FONT>
</P>

<P><FONT SIZE=3D2>We are, hopefully, providing information on more =
services than just telephone calls.&nbsp; For example, voice messaging =
over the Internet using SMTP.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Anne Brown</FONT>
<BR><FONT SIZE=3D2>Nortel Networks</FONT>
<BR><FONT SIZE=3D2>arbrown@nortelnetworks.com</FONT>
<BR><FONT SIZE=3D2>+1 613 765 5274</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; Michael Mealling [<A =
HREF=3D"mailto:michael@bailey.dscga.com">mailto:michael@bailey.dscga.com=
</A>] </FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; July 14, 2000 2:09 PM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; David P. Peek</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; Patrik F=E4ltstr=F6m; =
john.loughney@nokia.com; enum@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Re: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.in t =
?</FONT>
</P>

<P><FONT SIZE=3D2>On Fri, Jul 14, 2000 at 11:39:20AM -0400, David P. =
Peek wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; With the way ENUM requirements are defined =
today the F=E4ltstr=F6m draft</FONT>
<BR><FONT SIZE=3D2>&gt; supports these requirements by returning all =
the services based on a query.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I agree that there are scalability issues with =
this approach that is why the</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://search.ietf.org/internet-drafts/draft-peek-enum-itd-00.tx=
t" =
TARGET=3D"_blank">http://search.ietf.org/internet-drafts/draft-peek-enum=
-itd-00.txt</A> draft</FONT>
<BR><FONT SIZE=3D2>&gt; supports 'application specific queries' which =
allows specific service</FONT>
<BR><FONT SIZE=3D2>&gt; information to be retrieved separately based on =
a known service (&quot;Service</FONT>
<BR><FONT SIZE=3D2>&gt; Protocal&quot;) thereby limiting the amount of =
information returned solving the</FONT>
<BR><FONT SIZE=3D2>&gt; scalability issue. (ie. =
sip.x.x.x.x.x.x.e164.arpa)</FONT>
</P>

<P><FONT SIZE=3D2>I've heard this several times but I've never seen a =
single example</FONT>
<BR><FONT SIZE=3D2>of anything that advertises more than a small =
handful of services.</FONT>
<BR><FONT SIZE=3D2>How many different ways are there to make a =
telephone call these days anyway?</FONT>
</P>

<P><FONT SIZE=3D2>-MM</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
-----------------</FONT>
<BR><FONT SIZE=3D2>Michael =
Mealling&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Vote =
Libertarian!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | =
www.rwhois.net/michael</FONT>
<BR><FONT SIZE=3D2>Sr. Research Engineer&nbsp;&nbsp; |&nbsp;&nbsp; =
www.ga.lp.org/gwinnett&nbsp;&nbsp;&nbsp;&nbsp; | =
ICQ#:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 14198821</FONT>
<BR><FONT SIZE=3D2>Network =
Solutions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
www.lp.org&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp; michaelm@netsol.com</FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>enum mailing list</FONT>
<BR><FONT SIZE=3D2>enum@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/enum" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/enum</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFEDCF.D24365CE--

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 16:17:51 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04931
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 16:17:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19558;
	Fri, 14 Jul 2000 16:17:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19531
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 16:17:26 -0400 (EDT)
Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04803
	for <enum@ietf.org>; Fri, 14 Jul 2000 16:17:23 -0400 (EDT)
Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id QAA07737; Fri, 14 Jul 2000 16:06:58 -0400 (EDT)
Date: Fri, 14 Jul 2000 16:06:58 -0400
From: Michael Mealling <michael@bailey.dscga.com>
To: Anne Brown <arbrown@nortelnetworks.com>
Cc: "'michaelm@netsol.com'" <michaelm@netsol.com>,
        "David P. Peek" <dpeek@netnumber.com>,
        =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        john.loughney@nokia.com, enum@ietf.org
Subject: Re: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.in t ?
Message-ID: <20000714160658.J7480@bailey.dscga.com>
Reply-To: michaelm@netsol.com
References: <31AF4D00A662D211B6D10000F8BCBC24018D276E@bcarua63.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.2i
In-Reply-To: <31AF4D00A662D211B6D10000F8BCBC24018D276E@bcarua63.ca.nortel.com>; from arbrown@nortelnetworks.com on Fri, Jul 14, 2000 at 03:11:58PM -0500
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

On Fri, Jul 14, 2000 at 03:11:58PM -0500, Anne Brown wrote:
> We are, hopefully, providing information on more services than just
> telephone calls.  For example, voice messaging over the Internet using
> SMTP.

Cool. Ok, that's one. I've seen some SIP stuff. That's two. Any more?

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 16:44:32 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14219
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 16:44:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19930;
	Fri, 14 Jul 2000 16:43:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19902
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 16:43:45 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13918
	for <enum@ietf.org>; Fri, 14 Jul 2000 16:43:41 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id E331E4AB; Fri, 14 Jul 2000 22:43:11 +0200 (MET DST)
Received: from [10.0.0.7] (dhcp-2sjc13-85-108.cisco.com [171.70.85.108])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA12041;
	Fri, 14 Jul 2000 22:43:10 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p0432042eb59527e37acc@[10.0.0.7]>
In-Reply-To: <E13DBWs-000NBn-00@rip.psg.com>
References: 
 <6B57F36F4FF9D111B30A0008C7F41337037051F5@exdal1.ons.octel.com>
 <E13DBWs-000NBn-00@rip.psg.com>
Date: Fri, 14 Jul 2000 13:35:04 -0700
To: Randy Bush <randy@psg.com>, "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: Re: [Enum] Rough Consensus or time to revist the charter?
Cc: enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 12.53 -0700 00-07-14, Randy Bush wrote:
>  > 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
>
>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.

(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

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 16:44:48 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14308
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 16:44:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19964;
	Fri, 14 Jul 2000 16:43:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19937
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 16:43:50 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13949
	for <enum@ietf.org>; Fri, 14 Jul 2000 16:43:47 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 141C04AC; Fri, 14 Jul 2000 22:43:18 +0200 (MET DST)
Received: from [10.0.0.7] (dhcp-2sjc13-85-108.cisco.com [171.70.85.108])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA12046;
	Fri, 14 Jul 2000 22:43:14 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p0432042fb5952a15feec@[10.0.0.7]>
In-Reply-To: <20000714160658.J7480@bailey.dscga.com>
References: 
 <31AF4D00A662D211B6D10000F8BCBC24018D276E@bcarua63.ca.nortel.com>
 <20000714160658.J7480@bailey.dscga.com>
Date: Fri, 14 Jul 2000 13:38:42 -0700
To: Michael Mealling <michael@bailey.dscga.com>,
        Anne Brown <arbrown@nortelnetworks.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: Re: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.in t
 ?
Cc: "'michaelm@netsol.com'" <michaelm@netsol.com>,
        "David P. Peek" <dpeek@netnumber.com>, john.loughney@nokia.com,
        enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 16.06 -0400 00-07-14, Michael Mealling wrote:
>On Fri, Jul 14, 2000 at 03:11:58PM -0500, Anne Brown wrote:
>  > We are, hopefully, providing information on more services than just
>  > telephone calls.  For example, voice messaging over the Internet using
>  > SMTP.
>
>Cool. Ok, that's one. I've seen some SIP stuff. That's two. Any more?

I guess that michaels point is that he and myself can not see any use 
for more than a handfull of NAPTR RRs for each owner, because the 
detailed resolution for example given a SIP URI should be handled 
inside the SIP protocol itself.

So, what we ask for is some more explicit arguments about why this 
will not scale than just those words.

Two people have said that this will not scale without being able to 
query directly for the protocol, and we want to know why.

IF it doesn't scale, it would be much more natural to query for a 
specific service, not protocol, but I want to save this discussion 
until I understand what problem we are going to solve.

    paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 17:24:15 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25960
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 17:24:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20415;
	Fri, 14 Jul 2000 17:23:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20390
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 17:23:55 -0400 (EDT)
Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25843
	for <ENUM@IETF.ORG>; Fri, 14 Jul 2000 17:23:52 -0400 (EDT)
From: rshockey@ix.netcom.com
Received: from smui3.eng00.mindspring.net (smui3.eng00.mindspring.net [207.69.200.50])
	by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA18797
	for <ENUM@IETF.ORG>; Fri, 14 Jul 2000 17:23:53 -0400 (EDT)
Received: by smui3.eng00.mindspring.net id RAA0000022740; Fri, 14 Jul 2000 17:23:53 -0400 (EDT)
Date: Fri, 14 Jul 2000 17:23:53 -0400
To: ENUM@ietf.org
Message-ID: <Springmail.105.963609833.0.48812800@www.springmail.com>
X-Originating-IP: 210.197.100.153
Subject: [Enum] Charter discussion in Pittsburgh
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org



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.


#########

Your co-chair in Japan...

If VPIM can be moved to a different slot[I think Glenn Parsons was looking into that]...would you want to make a presentation on that topic?  I believe we have time.
__________

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 17:30:03 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27405
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 17:30:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20497;
	Fri, 14 Jul 2000 17:29:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20466
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 17:29:29 -0400 (EDT)
Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27258
	for <enum@ietf.org>; Fri, 14 Jul 2000 17:29:25 -0400 (EDT)
Received: by dnspri.npac.com; id QAA20194; Fri, 14 Jul 2000 16:29:26 -0500 (CDT)
Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0)
	id xma020141; Fri, 14 Jul 00 16:28:53 -0500
Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0)
	id <L9L13G4R>; Fri, 14 Jul 2000 16:28:11 -0500
Message-ID: <ED88182BFF78D211A4D800A0C9E9435C5E14D6@dc02.npac.com>
From: James Yu <james.yu@neustar.com>
To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <paf@cisco.com>,
        Michael Mealling <michael@bailey.dscga.com>,
        Anne Brown
	 <arbrown@nortelnetworks.com>
Cc: "'michaelm@netsol.com'" <michaelm@netsol.com>,
        "David P. Peek"
	 <dpeek@netnumber.com>, john.loughney@nokia.com,
        enum@ietf.org
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.in t
	 ?
Date: Fri, 14 Jul 2000 16:26:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA20467
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

"roam" can be another one.  There can many others that emulate how E.164#s
are used in SS7 global title translation (GTT).  For example, today there
are GTTs that map "national" E.164 numbers to the point codes (and subsystem
number) of the Line Information Database (LIDB for calling card service or
third-party collect call service, etc.), the switch that serves a particular
E.164 number for message notification and automatic callbck service.  Those
can be changed to IP/URL if those nodes support IP in addition to SS7/C7.

James

> -----Original Message-----
> From: Patrik Fältström [mailto:paf@cisco.com]
> Sent: Friday, July 14, 2000 4:39 PM
> To: Michael Mealling; Anne Brown
> Cc: 'michaelm@netsol.com'; David P. Peek; john.loughney@nokia.com;
> enum@ietf.org
> Subject: Re: [Enum] FW: Last Call or New Draft? - .arpa or 
> .e;164.itu.in
> t ?
> 
> 
> At 16.06 -0400 00-07-14, Michael Mealling wrote:
> >On Fri, Jul 14, 2000 at 03:11:58PM -0500, Anne Brown wrote:
> >  > We are, hopefully, providing information on more 
> services than just
> >  > telephone calls.  For example, voice messaging over the 
> Internet using
> >  > SMTP.
> >
> >Cool. Ok, that's one. I've seen some SIP stuff. That's two. Any more?
> 
> I guess that michaels point is that he and myself can not see any use 
> for more than a handfull of NAPTR RRs for each owner, because the 
> detailed resolution for example given a SIP URI should be handled 
> inside the SIP protocol itself.
> 
> So, what we ask for is some more explicit arguments about why this 
> will not scale than just those words.
> 
> Two people have said that this will not scale without being able to 
> query directly for the protocol, and we want to know why.
> 
> IF it doesn't scale, it would be much more natural to query for a 
> specific service, not protocol, but I want to save this discussion 
> until I understand what problem we are going to solve.
> 
>     paf
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum
> 

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 17:55:19 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03237
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 17:55:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20791;
	Fri, 14 Jul 2000 17:54:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20766
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 17:54:43 -0400 (EDT)
Received: from hvmta02-stg.us.psimail.psi.net (hvmta02-ext.us.psimail.psi.net [38.202.36.30])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03148
	for <enum@ietf.org>; Fri, 14 Jul 2000 17:54:42 -0400 (EDT)
Received: from seagal ([208.146.135.202]) by hvmta02-stg.us.psimail.psi.net
          (InterMail v4.01.01.00 201-229-111) with SMTP
          id <20000714215412.OZJC26052.hvmta02-stg@seagal>;
          Fri, 14 Jul 2000 17:54:12 -0400
From: "David P. Peek" <dpeek@netnumber.com>
To: =?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= <paf@cisco.com>,
        "Randy Bush" <randy@psg.com>,
        "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
Cc: <enum@ietf.org>
Subject: RE: [Enum] Rough Consensus or time to revist the charter?
Date: Fri, 14 Jul 2000 17:48:44 -0400
Message-ID: <NEBBIIBBHJMPEMJAACBPOECFCDAA.dpeek@netnumber.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <p0432042eb59527e37acc@[10.0.0.7]>
Content-Transfer-Encoding: 8bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit


	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: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of
Patrik Fältström
Sent: Friday, July 14, 2000 4:35 PM
To: Randy Bush; Vaudreuil, Greg M (Greg)
Cc: enum@ietf.org
Subject: Re: [Enum] Rough Consensus or time to revist the charter?


At 12.53 -0700 00-07-14, Randy Bush wrote:
>  > 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
>
>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.

(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

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 18:08:23 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04860
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 18:08:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21049;
	Fri, 14 Jul 2000 18:07:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21024
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 18:07:44 -0400 (EDT)
Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04768
	for <enum@ietf.org>; Fri, 14 Jul 2000 18:07:41 -0400 (EDT)
Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id RAA08198; Fri, 14 Jul 2000 17:57:19 -0400 (EDT)
Date: Fri, 14 Jul 2000 17:57:18 -0400
From: Michael Mealling <michael@bailey.dscga.com>
To: "David P. Peek" <dpeek@netnumber.com>
Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        Randy Bush <randy@psg.com>,
        "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, enum@ietf.org
Subject: Re: [Enum] Rough Consensus or time to revist the charter?
Message-ID: <20000714175718.Y7480@bailey.dscga.com>
Reply-To: michaelm@netsol.com
References: <p0432042eb59527e37acc@[10.0.0.7]> <NEBBIIBBHJMPEMJAACBPOECFCDAA.dpeek@netnumber.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.2i
In-Reply-To: <NEBBIIBBHJMPEMJAACBPOECFCDAA.dpeek@netnumber.com>; from dpeek@netnumber.com on Fri, Jul 14, 2000 at 05:48:44PM -0400
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

On Fri, Jul 14, 2000 at 05:48:44PM -0400, David P. Peek wrote:
> 
> 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....)

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

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

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
> period a service provider or large enterprise will make and you find that
> not everyone can overlook the amount of data this represents.

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

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

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

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          |  michaelm@netsol.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 18:17:41 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05968
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 18:17:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21161;
	Fri, 14 Jul 2000 18:17:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21137
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 18:17:12 -0400 (EDT)
Received: from imo-r06.mx.aol.com (imo-r06.mx.aol.com [152.163.225.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05909
	for <enum@ietf.org>; Fri, 14 Jul 2000 18:17:10 -0400 (EDT)
From: Stevenmitchell1@aol.com
Received: from Stevenmitchell1@aol.com
	by imo-r06.mx.aol.com (mail_out_v27.12.) id p.a8.7cae0d6 (3934);
	Fri, 14 Jul 2000 18:16:28 -0400 (EDT)
Message-ID: <a8.7cae0d6.26a0eb3b@aol.com>
Date: Fri, 14 Jul 2000 18:16:27 EDT
Subject: Re: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in t  ?
To: john.loughney@nokia.com
CC: paf@cisco.com, dpeek@netnumber.com (David P. Peek), enum@ietf.org,
        michael@bailey.dscga.com (Michael Mealling)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 4.0 for Windows 95 sub 106
Content-Transfer-Encoding: 7bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

John,

Can you please elaborate on the scalability issues that you perceive being a 
potential problem or having ramifications?  To provide a more effective 
illustration, can you clarify both in the form of examples & in the 
broad-stroke sense, conceptually.


Steve

Internetworking Systems & Technology


In a message dated 7/14/00 3:18:45 AM Eastern Daylight Time, 
john.loughney@nokia.com writes:

> paf@cisco.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 14 19:17:48 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16510
	for <enum-archive@odin.ietf.org>; Fri, 14 Jul 2000 19:17:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22072;
	Fri, 14 Jul 2000 19:17:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22041
	for <enum@ns.ietf.org>; Fri, 14 Jul 2000 19:17:16 -0400 (EDT)
Received: from field.videotron.net (field.videotron.net [205.151.222.108])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16422
	for <enum@ietf.org>; Fri, 14 Jul 2000 19:17:16 -0400 (EDT)
Received: from thinkingcat.com ([207.253.205.30])
 by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8)
 with ESMTP id <0FXP005ORNCOFG@field.videotron.net> for enum@ietf.org; Fri, 14 Jul 2000 19:17:14 -0400 (EDT)
Date: Fri, 14 Jul 2000 19:12:57 -0400
From: Leslie Daigle <leslie@thinkingcat.com>
Subject: Re: [Enum] Rough Consensus or time to revist the charter?
To: "David P. Peek" <dpeek@netnumber.com>
Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>,
        Randy Bush <randy@psg.com>, Vaudreuil@field.videotron.net,
        Greg M <gregv@lucent.com> (Greg), enum@ietf.org
Message-id: <396F9E79.E7D73D3C@thinkingcat.com>
Organization: Thinking Cat Enterprises
MIME-version: 1.0
X-Mailer: Mozilla 4.72 [en] (Win98; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <NEBBIIBBHJMPEMJAACBPOECFCDAA.dpeek@netnumber.com>
Content-Transfer-Encoding: 7bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit


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.

"David P. Peek" wrote:
> 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.

Leslie.

-- 

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

Leslie Daigle
leslie@thinkingcat.com
-------------------------------------------------------------------

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Jul 15 11:41:17 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24684
	for <enum-archive@odin.ietf.org>; Sat, 15 Jul 2000 11:41:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05529;
	Sat, 15 Jul 2000 11:40:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05467
	for <enum@ns.ietf.org>; Sat, 15 Jul 2000 11:40:29 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24494
	for <enum@ietf.org>; Sat, 15 Jul 2000 11:40:28 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA20125
	for <enum@ietf.org>; Sat, 15 Jul 2000 11:40:29 -0400 (EDT)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53])
	by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA20109;
	Sat, 15 Jul 2000 11:40:28 -0400 (EDT)
Received: from buzz.ons.octel.com by ihrh1.emsr.lucent.com (8.8.8+Sun/EMS-1.5 Solaris/emsr)
	id KAA28601 for ; Sat, 15 Jul 2000 10:40:27 -0500 (CDT)
Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200])
	by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id KAA27672;
	Sat, 15 Jul 2000 10:40:27 -0500 (CDT)
Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0)
	id <KXYSHZR8>; Sat, 15 Jul 2000 10:36:57 -0500
Message-ID: <6B57F36F4FF9D111B30A0008C7F41337037051FD@exdal1.ons.octel.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        Randy Bush
	 <randy@psg.com>
Cc: enum@ietf.org
Subject: RE: [Enum] Rough Consensus or time to revist the charter?
Date: Sat, 15 Jul 2000 10:36:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA05468
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

We seem to disagree about the smallest of issues.

I do not believe that a very slightly broader reading of the word "resource"
in charter to permit the use of other resource records is equivalent to
opening up Pandora's box.  Of the many possible ENUM problems that were
ruled out of scope in the well negotiated chartering phase, I do not recall
the returning of other DNS RR's from a telephone number as being one of
them. 

It seems silly to have a separate ENUM-lite working group simply to
standardize the use of ENUM mechanics with other records than NAPTR!  I
assert that use of other, simpler RR's raise no additional interesting
technical issues or substantial interoperability risks to the ENUM work.

Greg V.


-----Original Message-----
From: Patrik Fältström [mailto:paf@cisco.com]
Sent: Friday, July 14, 2000 3:35 PM
To: Randy Bush; Vaudreuil, Greg M (Greg)
Cc: enum@ietf.org
Subject: Re: [Enum] Rough Consensus or time to revist the charter?


At 12.53 -0700 00-07-14, Randy Bush wrote:
>  > 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
>
>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.

(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

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Jul 15 12:26:00 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05061
	for <enum-archive@odin.ietf.org>; Sat, 15 Jul 2000 12:26:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06001;
	Sat, 15 Jul 2000 12:25:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05980
	for <enum@ns.ietf.org>; Sat, 15 Jul 2000 12:25:35 -0400 (EDT)
Received: from rip.psg.com (rip.psg.com [147.28.0.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04973
	for <enum@ietf.org>; Sat, 15 Jul 2000 12:25:35 -0400 (EDT)
Received: from randy by rip.psg.com with local (Exim 3.13 #1)
	id 13DUkw-0004kQ-00; Sat, 15 Jul 2000 09:25:34 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
Cc: enum@ietf.org
Subject: RE: [Enum] Rough Consensus or time to revist the charter?
References: <6B57F36F4FF9D111B30A0008C7F41337037051FD@exdal1.ons.octel.com>
Message-Id: <E13DUkw-0004kQ-00@rip.psg.com>
Date: Sat, 15 Jul 2000 09:25:34 -0700
Content-Transfer-Encoding: 7bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

> It seems silly to have a separate ENUM-lite working group simply to
> standardize the use of ENUM mechanics with other records than NAPTR!  I
> assert that use of other, simpler RR's raise no additional interesting
> technical issues or substantial interoperability risks to the ENUM work.

great!  then we are safe postponing this embellishment until next time, once
we have demonstrated that we have the basics under control.

randy

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Jul 15 16:56:12 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00784
	for <enum-archive@odin.ietf.org>; Sat, 15 Jul 2000 16:56:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07975;
	Sat, 15 Jul 2000 16:54:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07956
	for <enum@ns.ietf.org>; Sat, 15 Jul 2000 16:54:27 -0400 (EDT)
Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00401
	for <enum@ietf.org>; Sat, 15 Jul 2000 16:54:26 -0400 (EDT)
Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id QAA09308; Sat, 15 Jul 2000 16:44:08 -0400 (EDT)
Date: Sat, 15 Jul 2000 16:44:08 -0400
From: Michael Mealling <michael@bailey.dscga.com>
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        Randy Bush <randy@psg.com>, enum@ietf.org
Subject: Re: [Enum] Rough Consensus or time to revist the charter?
Message-ID: <20000715164408.D8296@bailey.dscga.com>
Reply-To: michaelm@netsol.com
References: <6B57F36F4FF9D111B30A0008C7F41337037051FD@exdal1.ons.octel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.2i
In-Reply-To: <6B57F36F4FF9D111B30A0008C7F41337037051FD@exdal1.ons.octel.com>; from gregv@lucent.com on Sat, Jul 15, 2000 at 10:36:54AM -0500
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

On Sat, Jul 15, 2000 at 10:36:54AM -0500, Vaudreuil, Greg M (Greg) wrote:
> It seems silly to have a separate ENUM-lite working group simply to
> standardize the use of ENUM mechanics with other records than NAPTR!  I
> assert that use of other, simpler RR's raise no additional interesting
> technical issues or substantial interoperability risks to the ENUM work.

It actually make sense due to some things that have happened
with the IETF over the past few years. We tend to have some groups
who outgrow their charters and live way beyond their years. Its
a pretty well grounded concensus that we'd rather have more
groups working faster than fewer working slower...

-MM


-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 16 17:44:07 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02829
	for <enum-archive@odin.ietf.org>; Sun, 16 Jul 2000 17:44:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23981;
	Sun, 16 Jul 2000 17:42:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23950
	for <enum@ns.ietf.org>; Sun, 16 Jul 2000 17:42:49 -0400 (EDT)
Received: from mail2.rdc2.pa.home.com (mail2.rdc2.pa.home.com [24.12.106.241])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02543
	for <enum@ietf.org>; Sun, 16 Jul 2000 17:42:48 -0400 (EDT)
Received: from home.com ([24.3.205.203]) by mail2.rdc2.pa.home.com
          (InterMail vM.4.01.03.00 201-229-121) with ESMTP
          id <20000716214244.OCZO11850.mail2.rdc2.pa.home.com@home.com>
          for <enum@ietf.org>; Sun, 16 Jul 2000 14:42:44 -0700
Message-ID: <39722C4F.FD5B92AF@home.com>
Date: Sun, 16 Jul 2000 17:42:39 -0400
From: Herman Silbiger <hsilbiger@home.com>
Reply-To: hsilbiger@ieee.org
X-Mailer: Mozilla 4.73 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: enum@ietf.org
References: <200007161600.MAA21445@optimus.ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Enum] Re: Rough Consensus or time to revist the charter?
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit


There are hazards to piecemeal standardization.  It may be like designing a human,
one part at a time: After designing the feeding function you discover two days later
that you also should have designed an elimination function.

enum-admin@ietf.org wrote:

>
>
> Message: 1
> From: Randy Bush <randy@psg.com>
> To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
> Cc: enum@ietf.org
> Subject: RE: [Enum] Rough Consensus or time to revist the charter?
> Date: Sat, 15 Jul 2000 09:25:34 -0700
>
> > It seems silly to have a separate ENUM-lite working group simply to
> > standardize the use of ENUM mechanics with other records than NAPTR!  I
> > assert that use of other, simpler RR's raise no additional interesting
> > technical issues or substantial interoperability risks to the ENUM work.
>
> great!  then we are safe postponing this embellishment until next time, once
> we have demonstrated that we have the basics under control.
>
> randy
>
> --__--__--
>
> Message: 2
> Date: Sat, 15 Jul 2000 16:44:08 -0400
> From: Michael Mealling <michael@bailey.dscga.com>
> To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
> Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
> Randy Bush <randy@psg.com>, enum@ietf.org
> Subject: Re: [Enum] Rough Consensus or time to revist the charter?
> Reply-To: michaelm@netsol.com
>
> On Sat, Jul 15, 2000 at 10:36:54AM -0500, Vaudreuil, Greg M (Greg) wrote:
> > It seems silly to have a separate ENUM-lite working group simply to
> > standardize the use of ENUM mechanics with other records than NAPTR!  I
> > assert that use of other, simpler RR's raise no additional interesting
> > technical issues or substantial interoperability risks to the ENUM work.
>
> It actually make sense due to some things that have happened
> with the IETF over the past few years. We tend to have some groups
> who outgrow their charters and live way beyond their years. Its
> a pretty well grounded concensus that we'd rather have more
> groups working faster than fewer working slower...
>


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 17 00:04:41 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02552
	for <enum-archive@odin.ietf.org>; Mon, 17 Jul 2000 00:04:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA27377;
	Mon, 17 Jul 2000 00:04:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA27348
	for <enum@ns.ietf.org>; Mon, 17 Jul 2000 00:04:04 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02423
	for <enum@ietf.org>; Mon, 17 Jul 2000 00:04:02 -0400 (EDT)
From: john.loughney@nokia.com
Received: from esvir06nok.ntc.nokia.com (esvir06nok.ntc.nokia.com [131.228.10.155])
	by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6H440u29944
	for <enum@ietf.org>; Mon, 17 Jul 2000 07:04:00 +0300 (EET DST)
Received: from esebh03nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e40a9bce4d7467c707@esvir06nok.ntc.nokia.com>;
 Mon, 17 Jul 2000 07:04:00 +0300
Received: by esebh03nok with Internet Mail Service (5.5.2650.10)
	id <PABCGLYW>; Mon, 17 Jul 2000 07:03:59 +0300
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE104721120@eseis04nok>
To: paf@cisco.com
Cc: enum@ietf.org
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in
	 t  ?
Date: Mon, 17 Jul 2000 07:03:59 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Patrik,

> How many?

Initially, more than 10 per E.164 number.
 
> I.e. I don't understand what you belive is a scalability issue. You 
> also have to think about what is handled through different URIs 
> (different NAPTRs) and what is handled through the URI resolution.

If 'properly' engineered DNS records using NAPTRs scale, then
I have no problems using them. 
 
> It could be more interesting to query on the service field 
> than the protocol.

thanks,
John

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 17 04:48:38 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00316
	for <enum-archive@odin.ietf.org>; Mon, 17 Jul 2000 04:48:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06668;
	Mon, 17 Jul 2000 04:48:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06643
	for <enum@ns.ietf.org>; Mon, 17 Jul 2000 04:48:10 -0400 (EDT)
Received: from kind.noc.inet2000.gr.jp (kind.noc.inet2000.gr.jp [133.195.1.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00193
	for <enum@ietf.org>; Mon, 17 Jul 2000 04:48:08 -0400 (EDT)
Received: from [133.195.65.75] (dhcp-065075.wireless-conference.inet2000.gr.jp [133.195.65.75])
	by kind.noc.inet2000.gr.jp (8.9.3/3.7W) with ESMTP id RAA14634;
	Mon, 17 Jul 2000 17:47:09 +0900 (JST)
Mime-Version: 1.0
X-Sender: pfaltstr@127.0.0.1
Message-Id: <p04320406b59876acfcb4@[133.195.65.75]>
In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE104721120@eseis04nok>
References: <01D91AFB08B6D211BFD00008C7EABAE104721120@eseis04nok>
Date: Mon, 17 Jul 2000 17:42:50 +0900
To: john.loughney@nokia.com
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <paf@cisco.com>
Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or   .e;164.itu.in
 	 t  ?
Cc: enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 07.03 +0300 00-07-17, john.loughney@nokia.com wrote:
>If 'properly' engineered DNS records using NAPTRs scale, then
>I have no problems using them.

Ok, I then urge people to think about NAPTR scaling, test, and 
eventually come out with a new version of the NAPTR RFC one day when 
we know that it doesn't scale, and how the scaling issues should be 
(re)solved.

Personally, if the problem is the number of records, I would firstly 
want to query for a specific service, not protocol, and see if that 
is enough. I.e. in many cases you don't know what protocol you look 
for, or you want to have this or that (not only one protocol). But, I 
belive that you for every step in the NAPTR resolution algorithm is 
interested only one of the services.

I suggest (the wg chair is making this call) that this question 
should be taken back to the URN wg where the NAPTR is discussed.

I do not see that this changes the paper I have written, as it uses 
the NAPTR record as defined in the NAPTR paper. If that is replaced 
by a new paper, then the algorithm defined in my paper will change 
accordingly. If people belive that I have written too much about how 
the actual NAPTR algorithm is, instead of referencing the NAPTR 
paper, then let me know and I'll remove text.

    Patrik

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 17 06:34:53 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23606
	for <enum-archive@odin.ietf.org>; Mon, 17 Jul 2000 06:34:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07915;
	Mon, 17 Jul 2000 06:34:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07892
	for <enum@ns.ietf.org>; Mon, 17 Jul 2000 06:34:09 -0400 (EDT)
Received: from msw.mimesweeper.com (msw.mimesweeper.com [194.168.90.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23448
	for <enum@ietf.org>; Mon, 17 Jul 2000 06:34:08 -0400 (EDT)
Received: from msw42.mimesweeper.com (unverified) by msw.mimesweeper.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc2a85a12f04d755f1542@msw.mimesweeper.com> for <enum@ietf.org>;
 Mon, 17 Jul 2000 11:34:07 +0100
Received: from BELL.mimesweeper.com (unverified) by msw42.mimesweeper.com
 (Content Technologies SMTPRS 4.2.0) with ESMTP id <T4d755df727c2a85a190bd@msw42.mimesweeper.com>;
 Mon, 17 Jul 2000 11:32:54 +0100
Received: from GK-VAIO.Dial.pipex.com (gk-vaio.mimesweeper.com [194.168.90.137]) by BELL.mimesweeper.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 37TTAB1Q; Mon, 17 Jul 2000 11:33:17 +0100
Message-Id: <4.3.2.7.2.20000717094604.00c54270@pop.dial.pipex.com>
X-Sender: maiw03@pop.dial.pipex.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 17 Jul 2000 09:47:17 +0100
To: michaelm@netsol.com
From: Graham Klyne <GK@dial.pipex.com>
Subject: Re: [Enum] FW: Last Call or New Draft? - .arpa or
  .e;164.itu.in t ?
Cc: enum@ietf.org
In-Reply-To: <20000714160658.J7480@bailey.dscga.com>
References: <31AF4D00A662D211B6D10000F8BCBC24018D276E@bcarua63.ca.nortel.com>
 <31AF4D00A662D211B6D10000F8BCBC24018D276E@bcarua63.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 04:06 PM 7/14/00 -0400, Michael Mealling wrote:
>On Fri, Jul 14, 2000 at 03:11:58PM -0500, Anne Brown wrote:
> > We are, hopefully, providing information on more services than just
> > telephone calls.  For example, voice messaging over the Internet using
> > SMTP.
>
>Cool. Ok, that's one. I've seen some SIP stuff. That's two. Any more?

I guess Internet fax would be another.  Text messaging (SMS etc) would be 
another.

#g


------------
Graham Klyne
(GK@ACM.ORG)


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 17 06:43:29 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26489
	for <enum-archive@odin.ietf.org>; Mon, 17 Jul 2000 06:43:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08038;
	Mon, 17 Jul 2000 06:42:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08012
	for <enum@ns.ietf.org>; Mon, 17 Jul 2000 06:42:53 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26241;
	Mon, 17 Jul 2000 06:42:52 -0400 (EDT)
Message-Id: <200007171042.GAA26241@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: enum@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Mon, 17 Jul 2000 06:42:52 -0400
Subject: [Enum] I-D ACTION:draft-ietf-enum-operation-00.txt
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title		: ENUM Service Specific Provisioning: Principles of 
                          Operation
 	Author(s)	: A. Brown, G. Vaudreuil
	Filename	: draft-ietf-enum-operation-00.txt
	Pages		: 
	Date		: 14-Jul-00
	
This document outlines the principles for the operation of a
telephone number directory service.  This service provides for the
resolution of telephone numbers into Internet domain name addresses
and service specific directory discovery.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-operation-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-enum-operation-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-enum-operation-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000714144020.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-enum-operation-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-enum-operation-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000714144020.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 17 07:46:52 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14949
	for <enum-archive@odin.ietf.org>; Mon, 17 Jul 2000 07:46:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08767;
	Mon, 17 Jul 2000 07:45:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08742
	for <enum@ns.ietf.org>; Mon, 17 Jul 2000 07:45:44 -0400 (EDT)
Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14555
	for <ENUM@IETF.ORG>; Mon, 17 Jul 2000 07:45:43 -0400 (EDT)
From: rshockey@ix.netcom.com
Received: from smui2.atl.mindspring.net (smui2.atl.mindspring.net [207.69.200.123])
	by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id HAA26828
	for <ENUM@IETF.ORG>; Mon, 17 Jul 2000 07:45:43 -0400 (EDT)
Received: by smui2.atl.mindspring.net id HAA0000015189; Mon, 17 Jul 2000 07:45:43 -0400 (EDT)
Date: Mon, 17 Jul 2000 07:45:43 -0400
To: ENUM@ietf.org
Message-ID: <Springmail.105.963834343.0.58106600@www.springmail.com>
X-Originating-IP: 210.197.100.153
Subject: [Enum] Draft Agenda for ENUM WG at IETF 48 Pittsburgh
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org


Well we have 2 1/2 hours on Tuesday so I'd like to propose a draft agenda ... some of the documents have not made it through the ID Editors yet and I've noted those here. Others we'll have to see based on what happens in the next week. 

The times stated are not in stone so if you need more or less time here let me know.

I'd like to get this finalized in the next day or so so it can be formally submitted.


Agenda..

1. Agenda Bashing - 5 min

2. Document Status: Chair 2 min

Requirements ..submitted to IESG Last Call

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-01.txt

e164-DNS submitted to IESG Last Call

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-01.txt

3. ENUM Operations issues... Greg Vaudreuil & Anne Brown [ 15 min open if either Anne or Greg can make it but there is currently a conflict with VPIM so their participation is questionable. (Greg I put you first just in case you could come by and then go to VPIM)

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-operation-00.txt

4 .   draft-lind-itut-e370-00.txt - Service Principles when Public Circuit Switched International Telecommunication Networks Interwork with IP-based Networks   Steve Lind  15 min

5.   draft-lind-enum-callflows-00.txt - ENUM Call Flows for VoIP Interworking (submitted in queue)  <<draft-lind-enum-callflows-00.txt>> Steve Lind 15 min


6.    ENUM in Signalling Transport: 20 min John Loughney

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-loughney-enum-sigtran-00.txt

7.    ENUM Usage in Cellular Roaming John Loughney  10 min ????

8.   ITU Number Portability  15 min Andy Gallant

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-e164s2-np-00.txt

9.   ITU e164 workplan Andy Galant (Submitted in queue) 10min

10.   Future Directions and revised milestones 10m
	
11.  General discussion ...


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 17 09:39:20 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10976
	for <enum-archive@odin.ietf.org>; Mon, 17 Jul 2000 09:39:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10840;
	Mon, 17 Jul 2000 09:38:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10811
	for <enum@ns.ietf.org>; Mon, 17 Jul 2000 09:38:46 -0400 (EDT)
Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10806
	for <enum@ietf.org>; Mon, 17 Jul 2000 09:38:42 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id JAA04957
	for <enum@ietf.org>; Mon, 17 Jul 2000 09:38:13 -0400 (EDT)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id JAA10899; Mon, 17 Jul 2000 09:37:04 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21)
	id <3NAC7SG0>; Mon, 17 Jul 2000 09:38:13 -0400
Message-ID: <012F722EA7AFD211860B00E0290C6C5B049F5470@njc240po04.mt.att.com>
From: "Pfautz, Penn L, NNAD" <ppfautz@att.com>
To: enum@ietf.org
Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-operation-00.txt
Date: Mon, 17 Jul 2000 09:38:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

I have some concerns about the treatment of portability in this document
and, in particular, the North American example.
It seems that the e.164 root points to the NANPA for CC=1 which in turn
points to the Number Portability Authority (putatively NPAC) for NPA-NXXs
that are portable. The NPAC in turn points to the ported-to service
provider, which, in the example, is itself the Service Registrar.
Leaving aside the questions of the willingness of NANPA and NPAC to provide
these services
(for a few dollars more ... :-), given the penetration of portability, I
don't see the point of having two separate levels. As I've argued earlier,
portability means that once you get to the national authority you're going
to have to define a zone for each number or block of numbers assigned to a
user. 
I agree that this level, maintained by NPAC or whoever, could refer to the
telephone service provider for the number but why not directly to the
Service Registrar? The document cites the  Long Distance PIC process as an
example of service registration with an arbiter function but this remains a
source of contention. If customers are free to choose a service registrar,
why not provision that directly in the NANP-level DNS?

Penn Pfautz
AT&T
732-420-4962
ppfautz@att.com


-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Monday, July 17, 2000 6:43 AM
To: IETF-Announce; @ietf.org@attrh3.attrh.att.com
Cc: enum@ietf.org
Subject: [Enum] I-D ACTION:draft-ietf-enum-operation-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Telephone Number Mapping Working Group of
the IETF.

	Title		: ENUM Service Specific Provisioning: Principles of 
                          Operation
 	Author(s)	: A. Brown, G. Vaudreuil
	Filename	: draft-ietf-enum-operation-00.txt
	Pages		: 
	Date		: 14-Jul-00
	
This document outlines the principles for the operation of a
telephone number directory service.  This service provides for the
resolution of telephone numbers into Internet domain name addresses
and service specific directory discovery.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-operation-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-enum-operation-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-enum-operation-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 17 15:37:47 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03915
	for <enum-archive@odin.ietf.org>; Mon, 17 Jul 2000 15:37:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15787;
	Mon, 17 Jul 2000 15:36:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15760
	for <enum@ns.ietf.org>; Mon, 17 Jul 2000 15:36:32 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03621;
	Mon, 17 Jul 2000 15:36:30 -0400 (EDT)
Message-Id: <200007171936.PAA03621@ietf.org>
To: IETF-Announce: ;
Cc: enum@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Reply-to: iesg@ietf.org
Date: Mon, 17 Jul 2000 15:36:30 -0400
Subject: [Enum] Last Call: E.164 number and DNS to Proposed Standard
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org


The IESG has received a request from the Telephone Number Mapping
Working Group to consider E.164 number and DNS
<draft-ietf-enum-e164-dns-01.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by August 14, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-01.txt


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 17 17:53:45 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03818
	for <enum-archive@odin.ietf.org>; Mon, 17 Jul 2000 17:53:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17681;
	Mon, 17 Jul 2000 17:53:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17653
	for <enum@ns.ietf.org>; Mon, 17 Jul 2000 17:53:01 -0400 (EDT)
Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03332;
	Mon, 17 Jul 2000 17:52:58 -0400 (EDT)
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA10756;
        Mon, 17 Jul 2000 17:53:00 -0400 (EDT)
Message-Id: <200007172153.RAA10756@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: iesg@ietf.org
cc: enum@ietf.org
In-reply-to: Your message of "Mon, 17 Jul 2000 15:36:30 EDT."
             <200007171936.PAA03621@ietf.org> 
X-SUBJECT-MSG-FROM: The IESG <iesg-secretary@ietf.org> 
Date: Mon, 17 Jul 2000 17:53:00 -0400
Subject: [Enum] Re: Last Call: E.164 number and DNS to Proposed Standard
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

In general I support this proposal for PS status.

nits:

1. I wonder if N2R should be the only valid service.  To me it seems 
perfectly reasonable to support N2L or N2C as well, even if they are not
defined at present.  or maybe we should define new services.


2. in section 3.1.2, example 1:

    $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
     IN NAPTR 100 10 "u" "sip+N2R"  "!^.*$!sip:information@tele2.se!"     .
     IN NAPTR 102 10 "u" "smtp+N2R" "!^.*$!mailto:information@tele2.se!"  .

    This describes that the domain tele2.se is preferrable contacted via
    the SIP protocol, secondly via SMTP.

seems like this describes how to contact the entity associated with
phone number +46 89 76 12 34  rather than that associated with the
domain name tele2.se.   

    In both cases, the next step in the resolution process is to use the
    resolution mechanism for each of the protocols, (SIP and SMTP) to
    know what node to contact for each.

you might want to be a bit more specific here: perhaps

In both cases the next step in the resolution process is to use
the mechanisms native to each protocol (e.g. SRV records for SIP 
and MX records for SMTP; other protocols may use A, AAAA, or A6
records.) to determine the set of address(es) at which the service 
may be contacted.  


3. in section 3.1.3, Example 2

    $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
     IN NAPTR  10 10 "u" "sip+N2R"   "!^.*$!sip:paf@swip.net!"     .
     IN NAPTR 102 10 "u" "smtp+N2R"  "!^.*$!mailto:paf@swip.net!"  .
     IN NAPTR 102 10 "u" "tel+N2R"   "!^.*$!tel:+4689761234!"      .

    Note that the prefered method is to use the SIP protocol, 

I don't understand this notion of preference.  if you want to send email 
or voice mail to the entity associated with this phone number, you're
going to want to use SMTP.  if you want to actually place a voice call,
you're going to want to use SIP or the PSTN.  but what does it mean
to say that "the preferred method is to use the SIP protocol"?
preferred for which operation?

IIRC, this is what the service field was intended for, but we
don't have services defined for most of the anticipated
uses of e.164 numbers..  maybe we should?

4. in the IANA considerations section it implies that names will be
delegated according to E.164.  is this intended to constrain 
(or recommend) the delegation below country-code level, to reflect 
the present delegation of phone numbers to telcos within that country?  

also, I think it would be a good idea if when using terms like 
"Expert Review" RFCs included a reference to the document that 
defines the term.

Keith

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 17 20:10:56 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03651
	for <enum-archive@odin.ietf.org>; Mon, 17 Jul 2000 20:10:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19046;
	Mon, 17 Jul 2000 20:10:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19017
	for <enum@ns.ietf.org>; Mon, 17 Jul 2000 20:10:04 -0400 (EDT)
Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03349
	for <ENUM@IETF.ORG>; Mon, 17 Jul 2000 20:10:02 -0400 (EDT)
From: rshockey@ix.netcom.com
Received: from smui4.eng00.mindspring.net (smui4.eng00.mindspring.net [207.69.200.49])
	by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id UAA07917
	for <ENUM@IETF.ORG>; Mon, 17 Jul 2000 20:10:03 -0400 (EDT)
Received: by smui4.eng00.mindspring.net id UAA0000024844; Mon, 17 Jul 2000 20:10:03 -0400 (EDT)
Date: Mon, 17 Jul 2000 20:10:03 -0400
To: ENUM@ietf.org
Message-ID: <Springmail.105.963879003.0.72787500@www.springmail.com>
X-Originating-IP: 210.197.100.153
Subject: [Enum] Agenda change request...
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org


I just want all of you to know that I have made a request to agenda@ietf.org to change the time and date of the meeting as not to confict with VPIM. I've still requested a 2 1/2 hour slot.

I think its very important that the VPIM community fully participate in the work and discussion since it is pretty clear that the VPIM application has a strong interest in using the ENUM protocol ASAP.

Rich Shockey
co-chair

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 17 20:58:53 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21023
	for <enum-archive@odin.ietf.org>; Mon, 17 Jul 2000 20:58:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19488;
	Mon, 17 Jul 2000 20:58:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19457
	for <enum@ns.ietf.org>; Mon, 17 Jul 2000 20:58:18 -0400 (EDT)
Received: from kind.noc.inet2000.gr.jp (kind.noc.inet2000.gr.jp [133.195.1.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20793;
	Mon, 17 Jul 2000 20:58:11 -0400 (EDT)
Received: from [133.195.65.75] (dhcp-033087.tc-conference.inet2000.gr.jp [133.195.33.87])
	by kind.noc.inet2000.gr.jp (8.9.3/3.7W) with ESMTP id JAA16192;
	Tue, 18 Jul 2000 09:58:03 +0900 (JST)
Mime-Version: 1.0
X-Sender: pfaltstr@127.0.0.1
Message-Id: <p0432041eb5995986a392@[133.195.65.75]>
In-Reply-To: <200007172153.RAA10756@astro.cs.utk.edu>
References: <200007172153.RAA10756@astro.cs.utk.edu>
Date: Tue, 18 Jul 2000 09:52:51 +0900
To: Keith Moore <moore@cs.utk.edu>, iesg@ietf.org
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <paf@cisco.com>
Cc: enum@ietf.org
Content-Type: multipart/mixed; boundary="============_-1248240589==_============"
Subject: [Enum] Re: Last Call: E.164 number and DNS to Proposed Standard
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

--============_-1248240589==_============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 17.53 -0400 00-07-17, Keith Moore wrote:
>In general I support this proposal for PS status.
>
>nits:
>
>1. I wonder if N2R should be the only valid service.  To me it seems
>perfectly reasonable to support N2L or N2C as well, even if they are not
>defined at present.  or maybe we should define new services.

Version 02 was requested to be published a few days ago, but it seems 
that the last call was on 01...and 02 doesn't seem to be in the 
repository yet. And, I am not surprised given the load the days 
before the IETF.

Version 02 defines E2U as a new service, and includes a registration 
template for the E2U service.

>2. in section 3.1.2, example 1:
>
>     $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
>      IN NAPTR 100 10 "u" "sip+N2R"  "!^.*$!sip:information@tele2.se!"     .
>      IN NAPTR 102 10 "u" "smtp+N2R" "!^.*$!mailto:information@tele2.se!"  .
>
>     This describes that the domain tele2.se is preferrable contacted via
>     the SIP protocol, secondly via SMTP.
>
>seems like this describes how to contact the entity associated with
>phone number +46 89 76 12 34  rather than that associated with the
>domain name tele2.se.

That is correct.

>     In both cases, the next step in the resolution process is to use the
>     resolution mechanism for each of the protocols, (SIP and SMTP) to
>     know what node to contact for each.
>
>you might want to be a bit more specific here: perhaps
>
>In both cases the next step in the resolution process is to use
>the mechanisms native to each protocol (e.g. SRV records for SIP
>and MX records for SMTP; other protocols may use A, AAAA, or A6
>records.) to determine the set of address(es) at which the service
>may be contacted.

Ok. A good suggestion.

>3. in section 3.1.3, Example 2
>
>     $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
>      IN NAPTR  10 10 "u" "sip+N2R"   "!^.*$!sip:paf@swip.net!"     .
>      IN NAPTR 102 10 "u" "smtp+N2R"  "!^.*$!mailto:paf@swip.net!"  .
>      IN NAPTR 102 10 "u" "tel+N2R"   "!^.*$!tel:+4689761234!"      .
>
>     Note that the prefered method is to use the SIP protocol,
>
>I don't understand this notion of preference.  if you want to send email
>or voice mail to the entity associated with this phone number, you're
>going to want to use SMTP.  if you want to actually place a voice call,
>you're going to want to use SIP or the PSTN.  but what does it mean
>to say that "the preferred method is to use the SIP protocol"?
>preferred for which operation?

Good question!

The individual which sets up the NAPTRs can regardless of what the 
senders preferences are regarding what you want to do (send email, 
open a SIP-based conversation or what not) say that SIP is the 
preferred protocol. A paralell example: I personally might list a 
tel: URI, but the mailto: URI will have higher preference, because I 
rather want to receive email than phonecalls.

>IIRC, this is what the service field was intended for, but we
>don't have services defined for most of the anticipated
>uses of e.164 numbers..  maybe we should?

As I said above, the new version uses E2U as the service.

>4. in the IANA considerations section it implies that names will be
>delegated according to E.164.  is this intended to constrain
>(or recommend) the delegation below country-code level, to reflect
>the present delegation of phone numbers to telcos within that country?

 From my point of view that is (according to the way DNS delegation 
works) up to each entity which get the country code delegated to them.

>also, I think it would be a good idea if when using terms like
>"Expert Review" RFCs included a reference to the document that
>defines the term.

Ok.

   paf
--============_-1248240589==_============
Content-Id: <p0432041eb5995986a392@[133.195.65.75].0.0>
Content-Type: multipart/appledouble; boundary="============_-1248240587==_D============"

--============_-1248240587==_D============
Content-Type: application/applefile; name="%e164.txt"
Content-Disposition: attachment; filename="%e164.txt"
 ; modification-date="Sat, 15 Jul 2000 01:28:51 +0900"
Content-Transfer-Encoding: base64

AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAPgAAAAgAAAAJAAAARgAAACAA
AAAIAAAAZgAAABBlMTY0LnR4dFRFWFRNUFcgAQD/////AAAAAAAAAAAAAAAAAAAAAAAA
ACEROwECetNLbQwAAQbmxQ==
--============_-1248240587==_D============
Content-Type: text/plain; name="e164.txt"; charset="us-ascii"
Content-Disposition: attachment; filename="e164.txt"
 ; modification-date="Sat, 15 Jul 2000 01:28:51 +0900"



Network Working Group                                        P Faltstrom
Internet-Draft                                         Cisco Systems Inc
Expires: January 12, 2001                                  July 14, 2000


                          E.164 number and DNS
                         draft-enum-e164-dns-02

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 12, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

   This document discusses the use of DNS for storage of E.164 numbers.
   More specifically, how DNS can be used for identifying available
   services connected to one E.164 number. Routing of the actual
   connection using the service selected using these methods is not
   discussed.










Faltstrom               Expires January 12, 2001                [Page 1]

Internet-Draft            E.164 number and DNS                 July 2000


1. Introduction

   Through transformation of E.164 numbers into DNS names and the use
   of existing DNS services like delegation through NS records, and use
   of NAPTR[1] records in DNS[2][3], one can look up what services are
   available for a specific domainname in a decentralized way with
   distributed management of the different levels in the lookup
   process. 

1.1 Terminology

   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
   in this document are to be interpreted as described in RFC2119[4]






































Faltstrom               Expires January 12, 2001                [Page 2]

Internet-Draft            E.164 number and DNS                 July 2000


2. E.164 numbers and DNS

   The domain "e164.arpa." is being populated in order to provide the
   infrastructure in DNS for storage of E.164 numbers. In order to
   facilitate distributed operations, this domain is divided into
   subdomains. Holders of E.164 numbers which want to be listed in DNS
   should contact the appropriate zone administrator in order to be
   listed, by examining the SOA resource record associated with the
   zone, just like in normal DNS operations. 

   To find the DNS names for a specific E.164 number, the following
   procedure is to be followed: 

   1.  See that the E.164 number is written in its full form, including
       the countrycode IDDD. Example: +46-8-9761234 

   2.  Remove all non-digit characters part from the leading '+'.
       Example: +4689761234 

   3.  Remove all characters part from the digits. Example: 4689761234 

   4.  Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4 

   5.  Change the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4 

   6.  Append the domain "e164.arpa" to the end. Example:
       4.3.2.1.6.7.9.8.6.4.e164.arpa 
























Faltstrom               Expires January 12, 2001                [Page 3]

Internet-Draft            E.164 number and DNS                 July 2000


3. Fetching URIs given an E.164 number

   For a record in DNS, the NAPTR record is used for identifying
   available ways of contacting a specific node identified by that
   name. Specifically it can be used for knowing what services exists
   for a specific domainname, including phone numbers by the use of the
   e164.arpa domain as described above. 

   The identification is using the NAPTR resource record defined for
   use in the URN resolution process, but it can be generalized in a
   way that suits the needs specified in this document. 

   It is the string which is the result of step 2 in section 2 above
   which is input to the NAPTR algorithm. 

3.1 The NAPTR record

   The key fields in the NAPTR RR are order, preference, service,
   flags, regexp, and replacement. For a detailed description, see: 

   o  The order field specifies the order in which records MUST be
      processed when multiple NAPTR records are returned in response to
      a single query. 

   o  The preference field specifies the order in which records SHOULD
      be processed when multiple NAPTR records have the same value of
      "order". 

   o  The service field specifies the resolution protocol and
      resolution service(s) that will be available if the rewrite
      specified by the regexp or replacement fields is applied. 

   o  The flags field contains modifiers that affect what happens in
      the next DNS lookup, typically for optimizing the process. 

   o  The regexp field is one of two fields used for the rewrite rules,
      and is the core concept of the NAPTR record. 

   o  The replacement field is the other field that may be used for the
      rewrite rule. 

   Note that the client applies all the substitutions and performs all
   lookups, they are not performed in the DNS servers. Note that URIs
   are stored in the regexp field. 

3.1.1 Specification for use of NAPTR Resource Records

   The input is an E.164 encoded telephone number. The output is a
   Uniform Resource Identifier in its absolute form according to the


Faltstrom               Expires January 12, 2001                [Page 4]

Internet-Draft            E.164 number and DNS                 July 2000


   'absoluteURI' production in the Collected ABNF found in RFC2396[5]

   An E.164 number, without any characters but leading '+' and digits,
   (result of step 2 in section 2 above) is the input to the NAPTR
   algorithm. 

   The service supported for a call is E2U. 

3.1.2 Specification of Service E2U (E.164 to URI)

   * Name: E.164 to URI
   * Mnemonic: E2U
   * Number of Operands: 1
   * Type of Each Operand: First operand is an E.164 number.
   * Format of Each Operand: First operand is the E.164 number in the
     form as specified in step 2 in section 2 in this document.
   * Algorithm: Opaque
   * Output: One or more URLs
   * Errors Conditions:
      o E.164 number not in the numbering plan
      o E.164 number in the numbering plan, but no URLs exist for that number
      o Access denied

   * Security Considerations:
      o Malicious Redirection
        One of the fundamental dangers related to any service such
        as this is that a malicious entry in a resolver's database
        will cause clients to resolve the E.164 into the wrong URL.
        The possible intent may be to cause the client to retrieve
        a resource containing fraudulent or damaging material.
      o Denial of Service
        By removing the URL to which the E.164 maps, a malicious
        intruder may remove the client's ability to access the
        resource.

   This operation is used to map a one E.164 number to a list of URIs.
   The first well-known step in the resolution process is to remove all
   non-digits part from the leading '+' from the E.164 number as
   described in step 1 and 2 in section 2 of this document. 

3.2 Examples

3.2.1 Example 1

   $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
    IN NAPTR 100 10 "u" "sip+E2U"  "!^.*$!sip:information@tele2.se!"     .
    IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@tele2.se!"  .

   This describes that the domain tele2.se is preferrable contacted via


Faltstrom               Expires January 12, 2001                [Page 5]

Internet-Draft            E.164 number and DNS                 July 2000


   the SIP protocol, secondly via SMTP. 

   In both cases, the next step in the resolution process is to use the
   resolution mechanism for each of the protocols, (SIP and SMTP) to
   know what node to contact for each. 

3.2.2 Example 2

   $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
    IN NAPTR  10 10 "u" "sip+E2U"   "!^.*$!sip:paf@swip.net!"     .
    IN NAPTR 102 10 "u" "smtp+E2U"  "!^.*$!mailto:paf@swip.net!"  .
    IN NAPTR 102 10 "u" "tel+E2U"   "!^.*$!tel:+4689761234!"      .

   Note that the prefered method is to use the SIP protocol, but the
   result of the rewrite of the NAPTR record is a URI (the "u" flag in
   the NAPTR record). In the case of the protocol SIP, the URI might be
   a SIP URI, which is resolved as described in RFC 2543[6]. In the
   case of the "tel" URI scheme[7], the procedure is restarted with
   this new E.164 number. The client is responsible for loop detection. 

   The rest of the resolution of the routing is done as described
   above. 

3.2.3 Example 3

   $ORIGIN 6.4.e164.arpa.
   * IN NAPTR 100 10 "u" "sip+E2U" "!^+46(.*)$!ldap://ldap.example.se/cn=0$1!" .

   We see in this example that information about all E.164 numbers in
   the 46 countrycode (for sweden) exists in an LDAP server, and the
   search to do is specified by the LDAP URI[8]. 




















Faltstrom               Expires January 12, 2001                [Page 6]

Internet-Draft            E.164 number and DNS                 July 2000


4. IANA considerations

   IANA is to create the E164.ARPA domain in the ARPA zone, and
   delegate names in the zone to parties according to the ITU
   recommendation E.164. The names allocated should be hierarichally
   allocated according to the description in this document, and the
   codes assigned in the E.164 recommendation by ITU. 

   Delegations should be done after Expert Review, and the IESG will
   appoint a designated expert. 









































Faltstrom               Expires January 12, 2001                [Page 7]

Internet-Draft            E.164 number and DNS                 July 2000


5. Security Considerations

   As this system is built on top of DNS, one can not be sure that the
   information one get back from DNS is more secure than any DNS query.
   To solve that, the use of DNSSEC[9] for securing and verifying zones
   is to be recommended. 

   The caching in DNS can make the propagation time for a change take
   the same amount of time as the time to live for the NAPTR and
   SRV[10] records in the zone that is changed. The TTL should because
   of that be kept to a minimum. The use of this in an environment
   where IP-addresses are for hire (for example when using DHCP[11])
   must therefore be done very carefully. 






































Faltstrom               Expires January 12, 2001                [Page 8]

Internet-Draft            E.164 number and DNS                 July 2000


6. Acknowledgement

   Support and ideas has come from people at Ericsson, especially Bjorn
   Larsson, especially the group which implemented this scheme in their
   lab to see that it worked. Input has also come from ITU-T SG2,
   Working Party 1/2 (Numbering, Routing, Global Mobility and Service
   Definition), the ENUM working group in the IETF, and Leif Sunnegardh
   at Tele2 for information about how SS7 really works. 











































Faltstrom               Expires January 12, 2001                [Page 9]

Internet-Draft            E.164 number and DNS                 July 2000


References

   [1]  Mealling, M and R Daniel, "The Naming Authority Pointer (NAPTR)
        DNS Resource Record", draft-ietf-urn-naptr-rr-03.txt (work in
        progress), June 1998.

   [2]  Mockapetris, P.V., "Domain names - concepts and facilities",
        RFC 1034, STD 13, Nov 1987.

   [3]  Mockapetris, P.V., "Domain names - implementation and
        specification", RFC 1035, STD 13, Nov 1987.

   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, BCP 14, March 1997.

   [5]  Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
        Resource Identifiers (URI): Generic Syntax", RFC 2396, August
        1998.

   [6]  Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
        "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [7]  Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
        2000.

   [8]  Howes, T. and M. Smith, "An LDAP URL Format", RFC 1959, June
        1996.

   [9]  Eastlake, D., "Domain Name System Security Extensions", RFC
        2535, March 1999.

   [10]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
         specifying the location of services (DNS SRV)", RFC 2782,
         February 2000.

   [11]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
         March 1997.


Author's Address

   Patrik Faltstrom
   Cisco Systems Inc
   170 W Tasman Drive SJ-13/2
   San Jose CA 95134
   USA

   EMail: paf@cisco.com
   URI:   http://www.cisco.com


Faltstrom               Expires January 12, 2001               [Page 10]

Internet-Draft            E.164 number and DNS                 July 2000


Appendix A. Scenario

   Say that the content of the e164.arpa zone is the following: 


   $ORIGIN e164.arpa.
   6.4 IN NS ns.regulator-e164.example.se.

   The regulator has in turn given a series of 10000 numbers to the
   telco with the name Telco-A. The regulator because of that has in
   his DNS. 


   $ORIGIN 6.4.e164.arpa.
   6.7.9.8 IN NS ns.telco-a.example.se.

   A user named Sven Svensson has from Telco A got the phone number
   +46-8-9761234. The user gets the service of running DNS from the
   company Redirection Service. Sven Svensson has asked Telco A to
   point out Redirection Service as the authoritative source for
   information about the number +46-8-9761234. Telco A because of this
   puts in his DNS the following. 


   $ORIGIN 6.7.9.8.6.4.e164.arpa.
   4.3.2.1 IN NS ns.redirection-service.example.se.

   Sven Svensson has already plain telephony from Telco A, but also a
   SIP service from the company Sip Service which provides Sven with
   the SIP URI "sip:sven@sipservice.example.se". The ISP with the name
   ISP A runs email and webpages for Sven, under the emailaddress
   sven@ispa.example.se, and URL http://svensson.ispa.example.se. 

   The DNS for the redirection service because of this contains the
   following. 


   $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
    IN NAPTR 10 10 "a" "sip+E2U"  "!^.*$!sip:sven@sipservice.example.se!"  .
    IN NAPTR 10 10 "a" "smtp+E2U" "!^.*$!mailto:sven@ispa.example.se!"     .
    IN NAPTR 10 10 "a" "http+E2U" "!^.*$!http://svensson.ispa.example.se!" .
    IN NAPTR 10 10 "a" "tel+E2U"  "!^.*$!tel:+46-8-9761234!"               .

   A user, John Smith, want to contact Sven Svensson, he to start with
   only has the E.164 number of Sven, i.e. +46-8-9761234. He takes the
   number, and enters the number in his communication client, which
   happen to know how to handle the SIP protocol. The client removes
   the dashes, and ends up with the E.164 number +4689761234. That is
   what is used in the algorithm for NAPTR records, which is as


Faltstrom               Expires January 12, 2001               [Page 11]

Internet-Draft            E.164 number and DNS                 July 2000


   follows. 

   The client converts the E.164 number into the domainname
   4.3.2.1.6.7.9.8.6.4.e164.arpa., and queries for NAPTR records for
   this domainname. Using DNS mechanisms which includes following the
   NS record referals, the following records are returned: 


   $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
    IN NAPTR 10 10 "a" "sip+E2U"  "!^.*$!sip:sven@sipservice.example.se"  .
    IN NAPTR 10 10 "a" "smtp+E2U" "!^.*$!mailto:sven@ispa.example.se"     .
    IN NAPTR 10 10 "a" "http+E2U" "!^.*$!http://svensson.ispa.example.se" .
    IN NAPTR 10 10 "a" "tel+E2U"  "!^.*$!tel:+46-8-9761234"               .

   Because this client know sip, the first record above is selected,
   and the SIP URI is extracted, and used according to SIP resolution. 



































Faltstrom               Expires January 12, 2001               [Page 12]

Internet-Draft            E.164 number and DNS                 July 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC editor function is currently provided by the
   Internet Society.



















Faltstrom               Expires January 12, 2001               [Page 13]

--============_-1248240587==_D============--
--============_-1248240589==_============--

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul 19 03:05:24 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06000
	for <enum-archive@odin.ietf.org>; Wed, 19 Jul 2000 03:05:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19647;
	Wed, 19 Jul 2000 03:03:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19616
	for <enum@ns.ietf.org>; Wed, 19 Jul 2000 03:03:24 -0400 (EDT)
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05156
	for <ENUM@IETF.ORG>; Wed, 19 Jul 2000 03:03:23 -0400 (EDT)
From: rshockey@ix.netcom.com
Received: from smui2.atl.mindspring.net (smui2.atl.mindspring.net [207.69.200.123])
	by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id DAA08201
	for <ENUM@IETF.ORG>; Wed, 19 Jul 2000 03:03:24 -0400 (EDT)
Received: by smui2.atl.mindspring.net id DAA0000031175; Wed, 19 Jul 2000 03:03:23 -0400 (EDT)
Date: Wed, 19 Jul 2000 03:03:23 -0400
To: ENUM@ietf.org
Message-ID: <Springmail.105.963990203.0.86995900@www.springmail.com>
X-Originating-IP: 210.197.100.153
Subject: [Enum] Agenda time changes
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org


The IETF Agenda folks have kindly moved VPIM to Tuesday afternoon.

Many thanks to Glenn Parsons for supporting this change. We are most grateful.

Greg if this is OK with you I'll keep your slot open for discussion of the operations document is 20 min OK?

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul 19 10:09:19 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16115
	for <enum-archive@odin.ietf.org>; Wed, 19 Jul 2000 10:09:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25187;
	Wed, 19 Jul 2000 10:08:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25160
	for <enum@ns.ietf.org>; Wed, 19 Jul 2000 10:08:22 -0400 (EDT)
Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15723;
	Wed, 19 Jul 2000 10:08:19 -0400 (EDT)
From: rshockey@ix.netcom.com
Received: from smui3.eng00.mindspring.net (smui3.eng00.mindspring.net [207.69.200.50])
	by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id KAA16534;
	Wed, 19 Jul 2000 10:08:18 -0400 (EDT)
Received: by smui3.eng00.mindspring.net id KAA0000018664; Wed, 19 Jul 2000 10:08:17 -0400 (EDT)
Date: Wed, 19 Jul 2000 10:08:17 -0400
To: ENUM@ietf.org, agenda@ietf.org
Cc: sob@harvard.edu, mankin@east.isi.edu
Message-ID: <Springmail.105.964015697.0.71217700@www.springmail.com>
X-Originating-IP: 210.197.100.153
Subject: [Enum] ENUM WG Agenda for IETF 48 Pittsburgh
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

In the interest of being earlier rather than later...



Our Proposed Agenda


1. 	Agenda Bashing - 5 min

2. 	Document Status: Chair 2 min

Requirements submitted to IESG Last Call

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-01.txt

e164-DNS submitted to IESG Last Call

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-01.txt

3. 	ENUM Operations issues... Greg Vaudreuil 20 min
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-operation-00.txt

4 .  	 Service Principles when Public Circuit Switched International Telecommunication Networks Interwork with IP-based Networks Steve Lind  15 min
 draft-lind-itut-e370-00.txt ?????  Not currently posted..may be deleted..

5  	 ENUM Call Flows for VoIP Interworking .   Steve Lind 15 min
draft-lind-enum-callflows-00.txt - (submitted in queue)  

6.   	 ENUM in Signaling Transport: 20 min John Loughney
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-loughney-enum-sigtran-00.txt

7.	ENUM Usage in Cellular Roaming John Loughney  10 min 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-loughney-enum-roaming-00.txt

8.  	 ITU Number Portability  15 min Andy Gallant
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-e164s2-np-00.txt

9.   	ITU e164 workplan Andy Galant  10min
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gallant-enum-e164-snap-00.txt

10.  	 Future Directions and revised milestones 10m
	
11.  	General discussion...


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul 19 16:40:58 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00495
	for <enum-archive@odin.ietf.org>; Wed, 19 Jul 2000 16:40:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00011;
	Wed, 19 Jul 2000 16:39:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29976
	for <enum@ns.ietf.org>; Wed, 19 Jul 2000 16:39:56 -0400 (EDT)
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00094;
	Wed, 19 Jul 2000 16:39:48 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id QAA18401;
	Wed, 19 Jul 2000 16:31:34 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id QAA17750; Wed, 19 Jul 2000 16:30:24 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2650.21)
	id <3352ZJ6D>; Wed, 19 Jul 2000 16:31:32 -0400
Message-ID: <B13F591F20ACD311BE4300902761550F126749@njb140po06.ems.att.com>
From: "Lind, Steven D, ALCOO" <sdlind@att.com>
To: "'rshockey@ix.netcom.com'" <rshockey@ix.netcom.com>, ENUM@ietf.org,
        agenda@ietf.org
Cc: sob@harvard.edu, mankin@east.isi.edu
Subject: RE: [Enum] ENUM WG Agenda for IETF 48 Pittsburgh
Date: Wed, 19 Jul 2000 16:31:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01BFF1C0.4E389890"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BFF1C0.4E389890
Content-Type: text/plain;
	charset="iso-8859-1"

Richard,

The draft of the E.370 Recommendation is at
http://search.ietf.org/internet-drafts/draft-lind-itut-e370-00.txt and is
also attached to this reply.

Steve Lind

-----Original Message-----
From: rshockey@ix.netcom.com [mailto:rshockey@ix.netcom.com]
Sent: Wednesday, July 19, 2000 10:08 AM
To: ENUM@ietf.org; agenda@ietf.org
Cc: sob@harvard.edu; mankin@east.isi.edu
Subject: [Enum] ENUM WG Agenda for IETF 48 Pittsburgh


In the interest of being earlier rather than later...



Our Proposed Agenda


1. 	Agenda Bashing - 5 min

2. 	Document Status: Chair 2 min

Requirements submitted to IESG Last Call

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-01.txt

e164-DNS submitted to IESG Last Call

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-01.txt

3. 	ENUM Operations issues... Greg Vaudreuil 20 min
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-operation-00.txt

4 .  	 Service Principles when Public Circuit Switched International
Telecommunication Networks Interwork with IP-based Networks Steve Lind  15
min
 draft-lind-itut-e370-00.txt ?????  Not currently posted..may be deleted..

5  	 ENUM Call Flows for VoIP Interworking .   Steve Lind 15 min
draft-lind-enum-callflows-00.txt - (submitted in queue)  

6.   	 ENUM in Signaling Transport: 20 min John Loughney
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-loughney-enum-sigtran-00.txt

7.	ENUM Usage in Cellular Roaming John Loughney  10 min 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-loughney-enum-roaming-00.txt

8.  	 ITU Number Portability  15 min Andy Gallant
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-e164s2-np-00.txt

9.   	ITU e164 workplan Andy Galant  10min
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gallant-enum-e164-snap-00.txt

10.  	 Future Directions and revised milestones 10m
	
11.  	General discussion...


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


------_=_NextPart_000_01BFF1C0.4E389890
Content-Type: text/plain;
	name="draft-lind-itut-e370-00.txt"
Content-Disposition: attachment;
	filename="draft-lind-itut-e370-00.txt"
Content-Transfer-Encoding: quoted-printable

=0A=
=0A=
                                                                S. =
Lind=0A=
Internet Draft                                                     =
AT&T=0A=
Document: draft-lind-itut-e370-00.txt                         July =
2000=0A=
Category: Informational=0A=
=0A=
=0A=
     Service Principles when Public Circuit-Switched International=0A=
      Telecommunication Networks Interwork with IP-based Networks=0A=
=0A=
=0A=
Status of this Memo=0A=
=0A=
   This document is an Internet-Draft and is NOT offered in =
accordance=0A=
   with Section 10 of RFC2026, and the author does not provide the =
IETF=0A=
   with any rights other than to publish as an Internet-Draft=0A=
=0A=
   Internet-Drafts are working documents of the Internet Engineering=0A=
   Task Force (IETF), its areas, and its working groups. Note that=0A=
   other groups may also distribute working documents as Internet-=0A=
   Drafts. Internet-Drafts are draft documents valid for a maximum =
of=0A=
   six months and may be updated, replaced, or obsoleted by other=0A=
   documents at any time. It is inappropriate to use Internet- =
Drafts=0A=
   as reference material or to cite them other than as "work in=0A=
   progress."=0A=
=0A=
   The list of current Internet-Drafts can be accessed at=0A=
   http://www.ietf.org/ietf/1id-abstracts.txt=0A=
=0A=
   The list of Internet-Draft Shadow Directories can be accessed at=0A=
   http://www.ietf.org/shadow.html.=0A=
=0A=
=0A=
1. Abstract=0A=
=0A=
   This document describes the current thinking of the collaborators =
of=0A=
   ITU-T Question 10/2, "Management and development of PSTN-based=0A=
   telecommunication services," about service principles when public=0A=
   circuit switched international telecommunication networks =
interwork=0A=
   with IP-based networks. This document contains most of the text=0A=
   (there has been some rearrangement of the text) from draft new=0A=
   Recommendation E.370 [1], starting from section 3 of this =
Internet=0A=
   Draft, which was determined to be stable at the March 2000 =
meeting=0A=
   of Study Group 2. It may be approved by the members of the ITU,=0A=
   subject to written comments received from those members, at a=0A=
   meeting of the Study Group (or its successor) in early 2001=0A=
   (provisionally 23-26 January 2001). It is hoped that this =
document=0A=
   will further the collaborative efforts between Study Group 2 and =
the=0A=
   various working groups of the IETF.=0A=
=0A=
=0A=
2. Conventions used in this document=0A=
=0A=
=0A=
=0A=
=0A=
Lind             Informational - Expires January 2001                =
1=0A=
=0A=
=0A=
                   Service Principles when Public          July 2001=0A=
            Circuit-Switched International Telecommunication=0A=
               Networks Interwork with IP-based Networks=0A=
=0A=
=0A=
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL =
NOT",=0A=
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in=0A=
   this document are to be interpreted as described in RFC-2119 [2].=0A=
=0A=
=0A=
3. Introduction=0A=
=0A=
   There is an increased availability of Internet Protocol =
(IP)-based=0A=
   networks on an international and national basis. Users of these =
IP-=0A=
   based networks expect to be able to be connected with users of=0A=
   public, circuit switched, international telecommunications =
networks.=0A=
   In order to ensure that the needs of both IP-based network users =
and=0A=
   circuit-switched, international telecommunication network users =
are=0A=
   met, principles of interworking between IP-based networks and the=0A=
   circuit-switched, international telecommunication networks are=0A=
   presented in this Recommendation.=0A=
=0A=
=0A=
4. Scope=0A=
=0A=
   This Recommendation defines the principles applicable to=0A=
   international public correspondence services provided by IP-based=0A=
   networks interworking with the ITU-defined, circuit-switched,=0A=
   public,  international telecommunication networks (for example, =
the=0A=
   PSTN, ISDN, and PLMN).=0A=
=0A=
   This Recommendation is applicable to those cases where the =
IP-based=0A=
   network is implemented by a separate service provider (e.g., ROA)=0A=
   from the service provider of the public, circuit-switched=0A=
   international telecommunication network. It does not cover the =
case=0A=
   where IP technology is integrated within the international=0A=
   telecommunication network of a single service provider.=0A=
=0A=
=0A=
5. Definitions=0A=
=0A=
   IP-based network: A network in which the Internet Protocol is =
used=0A=
   as the ISO layer 3 protocol (OSI Reference Model).=0A=
=0A=
=0A=
6. Abbreviations=0A=
=0A=
   For the purpose of this Recommendation, the following =
abbreviations=0A=
   are used:=0A=
   DTMF         Dual Tone Multi-Frequency=0A=
   IP           Internet Protocol=0A=
   ISDN         Integrated Services Digital Network=0A=
   ISO          International Standards Organization=0A=
   ITU          International Telecommunication Union=0A=
   ITU-T        International Telecommunication Union -=0A=
                Telecommunication Standardisation Sector=0A=
=0A=
Lind             Informational - Expires January 2001                =
2=0A=
=0A=
=0A=
                   Service Principles when Public          July 2001=0A=
            Circuit-Switched International Telecommunication=0A=
               Networks Interwork with IP-based Networks=0A=
=0A=
=0A=
   IWF          Interworking Facility=0A=
   OSI          Open System Interconnection=0A=
   PLMN         Public Land Mobile Network=0A=
   PSTN         Public Switched Telephone Network=0A=
   ROA          Recognised Operating Agency=0A=
   SIP          Session Initiation Protocol=0A=
=0A=
=0A=
7. General Principles of Interconnection=0A=
=0A=
   In general, the interconnection of a IP-based network to an =
existing=0A=
   international telecommunication network should not impose any=0A=
   requirement for additional functionality in the international=0A=
   telecommunication network, nor any restriction in the normal=0A=
   operation of the international telecommunication network. Any =
added=0A=
   functionality should be provided in the IP-based network, unless=0A=
   otherwise agreed between the operators of the IP-based and=0A=
   international telecommunication networks. The international=0A=
   telecommunication network should not have to be specially =
engineered=0A=
   to compensate for possible performance variation of services=0A=
   supported by the IP-based network interconnected to it in order =
to=0A=
   match the performance of similar services fully supported by the=0A=
   international telecommunication network.=0A=
=0A=
   The interconnection arrangements could be formalised by an =
agreement=0A=
   between the operators of the two networks. The agreement could =
cover=0A=
   the following areas:=0A=
=0A=
        - network topology;=0A=
        - interface specifications, including signalling systems;=0A=
        - provisioning procedures;=0A=
        - operations and maintenance procedures;=0A=
        - performance monitoring (quality of service, grade of=0A=
          service, traffic measurement, etc.);=0A=
        - growth management (forecasts, network planning, etc.);=0A=
        - charging and accounting arrangements.=0A=
=0A=
   It should be possible to setup calls:=0A=
=0A=
   a) that originate at a terminal (such as those based on H.323 [3] =
or=0A=
   SIP [4]) on an IP-based network and terminate at terminals on=0A=
   PSTN/ISDN/PLMN networks;=0A=
=0A=
   b) that originate at terminals on PSTN/ISDN/PLMN networks and=0A=
   terminate at a terminal on an IP-based network.=0A=
=0A=
   Backward and forward call clearing should be possible.  The=0A=
   detection of a non-recoverable failure of any of the critical=0A=
   resources involved in the call shall initiate the clearing of the=0A=
   call.=0A=
=0A=
=0A=
Lind             Informational - Expires January 2001                =
3=0A=
=0A=
=0A=
                   Service Principles when Public          July 2001=0A=
            Circuit-Switched International Telecommunication=0A=
               Networks Interwork with IP-based Networks=0A=
=0A=
=0A=
   User services, which make use of end to end bi-directional and=0A=
   unidirectional DTMF signaling, should be supported e.g. voice =
mail=0A=
   applications, conference bridge applications, etc.=0A=
=0A=
   An inability to complete the call within the PSTN/ISDN/PLMN =
network=0A=
   should be detected and communicated to the calling party (e.g. =
busy=0A=
   tone).=0A=
=0A=
   The ability for inband audio tones and announcements to be =
received=0A=
   by the caller should be supported (e.g. special information =
tones,=0A=
   referral messages, etc).=0A=
=0A=
   In order to preserve existing PSTN/ISDN/PLMN service features the=0A=
   following should be supported:=0A=
=0A=
   a) Presentation of a number in ITU-T Recommendation E.164 [5] =
format=0A=
   identifying the Calling Party for Calling Line Identification=0A=
   Presentation;=0A=
=0A=
   b) Transport of calling line identification;=0A=
=0A=
   c) Transport of calling line identification restriction;=0A=
=0A=
   d) Malicious call tracing;=0A=
=0A=
   e) Emergency calling;=0A=
=0A=
   f) International Emergency Preference Scheme (see Recommendation=0A=
   E.106 [6])=0A=
=0A=
   g) E.164 number portability.=0A=
=0A=
=0A=
8. Services=0A=
=0A=
   The services, including any supplementary services, offered by =
IP-=0A=
   based networks (voice, data, etc) when interworking with the=0A=
   international telecommunication networks to provide public=0A=
   correspondence services should, as far as practicable, be similar =
to=0A=
   those provided on those international telecommunication networks =
and=0A=
   work on an end-to-end basis. For example, when interworking with=0A=
   users on the PSTN, Recommendation E.105 [7] defines the =
requirements=0A=
   of the International Telephone Service. While it is recognized =
that=0A=
   the manner in which the services, including any supplementary=0A=
   services, are presented to users on an IP-based network may be=0A=
   different from the way in which those services are presented to=0A=
   users of the PSTN, ISDN and PLMN; the basic functions, as defined =
in=0A=
   the appropriate ITU-T Recommendation, should still operate across=0A=
   the various networks.=0A=
=0A=
=0A=
=0A=
Lind             Informational - Expires January 2001                =
4=0A=
=0A=
=0A=
                   Service Principles when Public          July 2001=0A=
            Circuit-Switched International Telecommunication=0A=
               Networks Interwork with IP-based Networks=0A=
=0A=
=0A=
9. Service Scenarios=0A=
=0A=
   A number of scenarios may be deployed to reflect particular=0A=
   configurations of networks, namely:=0A=
=0A=
   Scenario 1: communication between IP-based network users and=0A=
   International Telecommunication Network users, in which the call=0A=
   set-up is originated by the IP network user.=0A=
=0A=
   Scenario 2: communication between IP-based network users and=0A=
   International Telecommunication Network users, in which the call=0A=
   set-up is originated by the International Telecommunication =
Network=0A=
   user.=0A=
=0A=
   Scenario 3: communication between International Telecommunication=0A=
   Network users, using IP-based networks for the =
connection/trunking=0A=
   between the involved users.=0A=
=0A=
   Scenario 4: communication between IP-based network users, using=0A=
   International Telecommunication Networks for the =
connection/trunking=0A=
   between the involved users.=0A=
=0A=
   In principle the interworking between the IP-based network and =
the=0A=
   international telecommunication network can be at any level in =
the=0A=
   international telecommunication network hierarchy, e.g. local=0A=
   exchange, transit exchange, international exchange=0A=
=0A=
   For all scenarios, any added functionality to enable interworking=0A=
   should be provided in the IP-based network, unless otherwise =
agreed=0A=
   between the operators of the IP-based and international=0A=
   telecommunication networks.=0A=
=0A=
   In the case of scenarios 3 and 4, the IP-based network is =
provided=0A=
   by a separate entity (e.g., ROA) from the international=0A=
   telecommunication network. Recommendation E.370 does not cover =
the=0A=
   case where IP technology is integrated within the international=0A=
   telecommunication network of a single service provider. The =
traffic,=0A=
   technical, economical, and administrative =
advantages/disadvantages=0A=
   should be considered before such interconnection is proposed by=0A=
   network operators.=0A=
=0A=
=0A=
10. Operation=0A=
=0A=
   When interworking between IP-based networks and international=0A=
   telecommunication networks the operational procedures for =
services=0A=
   should, wherever possible, be the same as for those on the=0A=
   international telecommunications networks. The same tones,=0A=
   announcements, service codes and signals, etc., used in the=0A=
   international telecommunication services should be recognised and=0A=
   where appropriate returned by the IP-based network. For =
interworking=0A=
=0A=
Lind             Informational - Expires January 2001                =
5=0A=
=0A=
=0A=
                   Service Principles when Public          July 2001=0A=
            Circuit-Switched International Telecommunication=0A=
               Networks Interwork with IP-based Networks=0A=
=0A=
=0A=
   between IP-based networks and international telecommunication=0A=
   networks, User-to-Network signalling (where a user on one network =
is=0A=
   accessing functionality supplied on the other network), =
Network-to-=0A=
   Network signalling, and User-to-User signalling must be =
consistently=0A=
   interpreted across the various networks. The latter case is=0A=
   particularly important when users must interact with interactive=0A=
   voice response systems.=0A=
=0A=
   For users on the international telecommunication networks to =
reach=0A=
   users on IP-based networks, terminals on the IP-based network =
should=0A=
   be addressable using the international numbering plan applicable =
to=0A=
   the International telecommunications services (i.e., =
Recommendation=0A=
   E.164).=0A=
=0A=
   There should be mechanisms in place to cater for the needs of any=0A=
   call recording, billing and international accounting functions =
that=0A=
   might be required. For example, an answer supervisory signal =
should=0A=
   be returned by the terminating network when an incoming call is=0A=
   established.=0A=
=0A=
=0A=
11. Quality of Service=0A=
=0A=
   When international telecommunication networks interwork with IP-=0A=
   based networks, the quality of service experienced by the users=0A=
   should, as far as practible, be the same as if there had been no=0A=
   interworking involved. Note: Categories of speech quality are=0A=
   defined in Recommendation G.109 [8].=0A=
=0A=
12. References=0A=
=0A=
=0A=
   1  ITU-T Draft New Recommendation E.370, Service principles when=0A=
      public circuit switched international telecommunication =
networks=0A=
      interwork with IP-based networks, COM 2-R077, March 2000=0A=
=0A=
   2  Bradner, S., "Key words for use in RFCs to Indicate =
Requirement=0A=
      Levels", BCP 14, RFC 2119, March 1997=0A=
=0A=
   3  ITU-T Recommendation H.323, Packet-based multimedia=0A=
      communications systems, September 1999=0A=
=0A=
   4  M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, =
"SIP:=0A=
      session initiation protocol," RFC 2543, March 1999=0A=
=0A=
   5  ITU-T Recommendation E.164, The international public=0A=
      telecommunication numbering plan, May 1997=0A=
=0A=
   6  ITU-T Recommendation E.106, International Emergency Preference=0A=
      Scheme, March 2000=0A=
=0A=
=0A=
Lind             Informational - Expires January 2001                =
6=0A=
=0A=
=0A=
                   Service Principles when Public          July 2001=0A=
            Circuit-Switched International Telecommunication=0A=
               Networks Interwork with IP-based Networks=0A=
=0A=
=0A=
=0A=
=0A=
   7  ITU-T Recommendation E.105, International Telephone Service,=0A=
      August 1992=0A=
=0A=
   8  ITU-T Recommendation G.109 - Definition of categories of =
speech=0A=
      transmission quality, September 1999=0A=
=0A=
=0A=
13. Author's Address=0A=
=0A=
   Steven D. Lind=0A=
   AT&T=0A=
   180 Park Avenue, Bldg. 2, Room 2G25=0A=
   Florham Park, NJ 07932=0A=
   Phone: +1 973 236 6787=0A=
   Email: sdlind@att.com=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Lind             Informational - Expires January 2001                =
7=0A=
=0A=
=0A=
                   Service Principles when Public          June 2000=0A=
            Circuit-Switched International Telecommunication=0A=
               Networks Interwork with IP-based Networks=0A=
=0A=
=0A=
=0A=
Full Copyright Statement=0A=
=0A=
    Copyright (C) The Internet Society (2000). All Rights Reserved.=0A=
=0A=
    This document and translations of it may be copied and furnished =
to=0A=
    others, and derivative works that comment on or otherwise explain =
it=0A=
    or assist in its implementation may be prepared, copied, =
published=0A=
    and distributed, in whole or in part, without restriction of any=0A=
    kind, provided that the above copyright notice and this =
paragraph=0A=
    are included on all such copies and derivative works. However, =
this=0A=
    document itself may not be modified in any way, such as by =
removing=0A=
    the copyright notice or references to the Internet Society or =
other=0A=
    Internet organizations, except as needed for the purpose of=0A=
    developing Internet standards in which case the procedures for=0A=
    copyrights defined in the Internet Standards process must be=0A=
    followed, or as required to translate it into languages other =
than=0A=
    English.=0A=
=0A=
    The limited permissions granted above are perpetual and will not =
be=0A=
    revoked by the Internet Society or its successors or assigns.=0A=
=0A=
    This document and the information contained herein is provided on =
an=0A=
    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET =
ENGINEERING=0A=
    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, =
INCLUDING=0A=
    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A=
    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A=
    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Lind            Informational - Expires December 2000               =
8=0A=

------_=_NextPart_000_01BFF1C0.4E389890--

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul 19 22:56:50 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13869
	for <enum-archive@odin.ietf.org>; Wed, 19 Jul 2000 22:56:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03376;
	Wed, 19 Jul 2000 22:56:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03353
	for <enum@ns.ietf.org>; Wed, 19 Jul 2000 22:56:34 -0400 (EDT)
Received: from kind.noc.inet2000.gr.jp (kind.noc.inet2000.gr.jp [133.195.1.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13768
	for <ENUM@ietf.org>; Wed, 19 Jul 2000 22:56:31 -0400 (EDT)
Received: from [133.195.65.75] (dhcp-065075.wireless-conference.inet2000.gr.jp [133.195.65.75])
	by kind.noc.inet2000.gr.jp (8.9.3/3.7W) with ESMTP id LAA24691;
	Thu, 20 Jul 2000 11:56:22 +0900 (JST)
Mime-Version: 1.0
X-Sender: pfaltstr@127.0.0.1 (Unverified)
Message-Id: <p04320410b59c02f346c9@[133.195.65.75]>
In-Reply-To: <Springmail.105.964015697.0.71217700@www.springmail.com>
References: <Springmail.105.964015697.0.71217700@www.springmail.com>
Date: Thu, 20 Jul 2000 10:28:01 +0900
To: rshockey@ix.netcom.com, ENUM@ietf.org
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <paf@cisco.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [Enum] draft-ietf-enum-operation-00.txt
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 10.08 -0400 00-07-19, rshockey@ix.netcom.com wrote:
>3.	ENUM Operations issues... Greg Vaudreuil 20 min
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-enum-operation-00.txt

I object to the following parts in this draft:

>An
>    effective ENUM service requires that DNS time-to-live fields be set
>    to an appropriate value consistent with the telephone number
>    reassignment policies if the delegating authority.

Having a too low TTL is not appropriate in DNS. Therefore this draft 
needs to be much more specific on when a number is possible to change 
according to a "slow" or "fast" update. In normal telephony systems, 
the switch itself (or accordingly) handles "slow" updates, and IN 
systems handle the "fast" updates.

DNS is only suitable at this stage for "slow" updates.

"fast" update services should for example be handled by having an 
LDAP URI stored in one of the NAPTR RR, and the actual routing is 
fetched via LDAP.

I.e. you have to differ between "fast" and "slow" updates, and 
describe the differences between each one of them, and what is 
suitable to use DNS for, and what is suitable to use other protocols 
for.

I claim DNS is not suitable for fast updates just because DNS do have 
caching and do have delay between updates of slave servers from the 
master servers. We should and can not fight that. If DNS one day can 
handle "faster" updates, fine, but today we have a certain limit in 
what speed DNS updates propagates over the Internet.

I therefore suggest you talk more about these issues and strategies 
to solve them. _THAT_ I feel can be a very needed discussion, and why 
not in this draft?

Further:

>4.2 Second Level: Determining the service registrar and retrieving
>Resource records.
>
>    The second level uses MX or SRV RRs to discover the NAPTR RRs to
>    discover the URL for other service- identity of the appropriate
>    service-specific directory such as an LDAP directory server, H.323
>    gatekeeper, or specific endpoint addresses.
>

You do not use MX and SRV RRs to discover NAPTR RRs.

    Patrik

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul 20 06:56:55 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17615
	for <enum-archive@odin.ietf.org>; Thu, 20 Jul 2000 06:56:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12543;
	Thu, 20 Jul 2000 06:47:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12519
	for <enum@ns.ietf.org>; Thu, 20 Jul 2000 06:47:34 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12443;
	Thu, 20 Jul 2000 06:47:33 -0400 (EDT)
Message-Id: <200007201047.GAA12443@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: enum@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 20 Jul 2000 06:47:32 -0400
Subject: [Enum] I-D ACTION:draft-ietf-enum-e164-dns-02.txt
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title		: E.164 number and DNS
	Author(s)	: P. Faltstrom
	Filename	: draft-ietf-enum-e164-dns-02.txt
	Pages		: 13
	Date		: 19-Jul-00
	
This document discusses the use of DNS for storage of E.164 numbers.
More specifically, how DNS can be used for identifying available
services connected to one E.164 number. Routing of the actual
connection using the service selected using these methods is not
discussed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-enum-e164-dns-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-enum-e164-dns-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000719141706.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-enum-e164-dns-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-enum-e164-dns-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000719141706.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul 20 10:36:03 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12971
	for <enum-archive@odin.ietf.org>; Thu, 20 Jul 2000 10:36:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15837;
	Thu, 20 Jul 2000 10:35:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15809
	for <enum@ns.ietf.org>; Thu, 20 Jul 2000 10:35:21 -0400 (EDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12627
	for <ENUM@ietf.org>; Thu, 20 Jul 2000 10:35:19 -0400 (EDT)
Received: from slb-av-01.boeing.com ([129.172.13.4])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA01969
	for <ENUM@ietf.org>; Thu, 20 Jul 2000 07:35:20 -0700 (PDT)
Received: from slb-hub-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id HAA03977
	for <ENUM@ietf.org>; Thu, 20 Jul 2000 07:35:14 -0700 (PDT)
Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Thu, 20 Jul 2000 07:35:07 -0700
Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21)
	id <3GJSPKV4>; Thu, 20 Jul 2000 10:35:06 -0400
Message-Id: <4102273CEB77D211869200805FE6F5939EBD38@xch-phl-01.he.boeing.com>
From: "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>
To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <paf@cisco.com>, ENUM@ietf.org
Subject: RE: [Enum] draft-ietf-enum-operation-00.txt
Date: Thu, 20 Jul 2000 10:35:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA15810
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

> -----Original Message-----
> From: Patrik Fältström [mailto:paf@cisco.com]

> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-enum-operation-00.txt
> 
> I object to the following parts in this draft:
> 
> >An
> >    effective ENUM service requires that DNS time-to-live 
> fields be set
> >    to an appropriate value consistent with the telephone number
> >    reassignment policies if the delegating authority.
> 
> Having a too low TTL is not appropriate in DNS. Therefore this draft 
> needs to be much more specific on when a number is possible to change 
> according to a "slow" or "fast" update. In normal telephony systems, 
> the switch itself (or accordingly) handles "slow" updates, and IN 
> systems handle the "fast" updates.
> 
> DNS is only suitable at this stage for "slow" updates.

I'd like this settled, myself. I've seen claims on this list that DNS can
now be updated in seconds, including master and slave servers. True? False?

> I claim DNS is not suitable for fast updates just because DNS do have 
> caching and do have delay between updates of slave servers from the 
> master servers. We should and can not fight that. If DNS one day can 
> handle "faster" updates, fine, but today we have a certain limit in 
> what speed DNS updates propagates over the Internet.

Bert
albert.e.manfredi@boeing.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul 20 15:04:59 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02051
	for <enum-archive@odin.ietf.org>; Thu, 20 Jul 2000 15:04:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18957;
	Thu, 20 Jul 2000 15:04:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18927
	for <enum@ns.ietf.org>; Thu, 20 Jul 2000 15:04:40 -0400 (EDT)
Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01884
	for <ENUM@ietf.org>; Thu, 20 Jul 2000 15:04:38 -0400 (EDT)
Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1])
	by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA05614
	for <ENUM@ietf.org>; Thu, 20 Jul 2000 15:04:39 -0400 (EDT)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53])
	by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA05586;
	Thu, 20 Jul 2000 15:04:38 -0400 (EDT)
Received: from buzz.ons.octel.com by ihrh1.emsr.lucent.com (8.8.8+Sun/EMS-1.5 Solaris/emsr)
	id OAA13971 for ; Thu, 20 Jul 2000 14:04:36 -0500 (CDT)
Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200])
	by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id OAA07964;
	Thu, 20 Jul 2000 14:04:36 -0500 (CDT)
Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0)
	id <KXYSJLD4>; Thu, 20 Jul 2000 14:00:51 -0500
Message-ID: <6B57F36F4FF9D111B30A0008C7F413370370527A@exdal1.ons.octel.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>
Cc: =?ISO-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <paf@cisco.com>, ENUM@ietf.org
Subject: RE: [Enum] draft-ietf-enum-operation-00.txt
Date: Thu, 20 Jul 2000 14:00:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA18928
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

I will clarify the draft.

To start, DNS does not do badly when there is a low TTL for leaf-data, if
the leaf-data is infrequently accessed.  The odds of an individual phone
number leaf-node remaining in the cache of a given public DNS server
long-enough to be useful is very low.  There is limited locality of
reference for the PSTN.  Caching provides it's benefits higher in the
delegation tree.

The assertion that switch handles slow updates and the IN handles fast
updates confuses routing from delegation.  The routing between switches
changes slowly, but that is uninteresting given that we have ruled routing
out-of-scope.  The delegation of a phone number to a subscriber or block of
numbers to a company happens on the switch and happens "fast".  It is
reasonable for a phone number to become in-service within tens of minutes
from the time it is assigned to a subscriber, especially when correcting
previous provisioning errors.  Further, when porting numbers from one
provider to another, i.e., changing the DNAME or CNAME to point to another
domain, the change has to happen within a small service window.

If DNS deals with individual telephone numbers, as I understood the intent,
it must respond similarly fast.  That said, caching provides great value at
the e164.arpa, country code, and one or two more levels down depending on
national numbering plans.  IN the US, delegations of numbers are next
performed on the NPANXX boundary, a delegation that changes at fastest,
monthly, and normally only quarterly.  Within the 10,000 numbers within an
"exchange", the assignment changes almost minute-by-minute. 

I do not believe NAPTR provides any advantages unless you assume that
service-specific information for numbers within an entire sub-tree are
served off the same service-level directory.  We know that clearly does not
happen in a portability situation.

Greg V.


-----Original Message-----
From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com]
Sent: Thursday, July 20, 2000 9:35 AM
To: 'Patrik Fältström'; ENUM@ietf.org
Subject: RE: [Enum] draft-ietf-enum-operation-00.txt


> -----Original Message-----
> From: Patrik Fältström [mailto:paf@cisco.com]

> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-enum-operation-00.txt
> 
> I object to the following parts in this draft:
> 
> >An
> >    effective ENUM service requires that DNS time-to-live 
> fields be set
> >    to an appropriate value consistent with the telephone number
> >    reassignment policies if the delegating authority.
> 
> Having a too low TTL is not appropriate in DNS. Therefore this draft 
> needs to be much more specific on when a number is possible to change 
> according to a "slow" or "fast" update. In normal telephony systems, 
> the switch itself (or accordingly) handles "slow" updates, and IN 
> systems handle the "fast" updates.
> 
> DNS is only suitable at this stage for "slow" updates.

I'd like this settled, myself. I've seen claims on this list that DNS can
now be updated in seconds, including master and slave servers. True? False?

> I claim DNS is not suitable for fast updates just because DNS do have 
> caching and do have delay between updates of slave servers from the 
> master servers. We should and can not fight that. If DNS one day can 
> handle "faster" updates, fine, but today we have a certain limit in 
> what speed DNS updates propagates over the Internet.

Bert
albert.e.manfredi@boeing.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul 20 20:40:13 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05931
	for <enum-archive@odin.ietf.org>; Thu, 20 Jul 2000 20:40:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22146;
	Thu, 20 Jul 2000 20:39:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22113
	for <enum@ns.ietf.org>; Thu, 20 Jul 2000 20:39:55 -0400 (EDT)
Received: from kind.noc.inet2000.gr.jp (kind.noc.inet2000.gr.jp [133.195.1.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05814
	for <ENUM@ietf.org>; Thu, 20 Jul 2000 20:39:53 -0400 (EDT)
Received: from [133.195.65.75] (dhcp-065075.wireless-conference.inet2000.gr.jp [133.195.65.75])
	by kind.noc.inet2000.gr.jp (8.9.3/3.7W) with ESMTP id JAA27252;
	Fri, 21 Jul 2000 09:39:46 +0900 (JST)
Mime-Version: 1.0
X-Sender: pfaltstr@127.0.0.1
Message-Id: <p04320414b59d43b8e794@[133.195.65.75]>
In-Reply-To: 
 <6B57F36F4FF9D111B30A0008C7F413370370527A@exdal1.ons.octel.com>
References: <6B57F36F4FF9D111B30A0008C7F413370370527A@exdal1.ons.octel.com>
Date: Fri, 21 Jul 2000 09:07:09 +0900
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>,
        "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <paf@cisco.com>
Subject: RE: [Enum] draft-ietf-enum-operation-00.txt
Cc: ENUM@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 14.00 -0500 00-07-20, Vaudreuil, Greg M (Greg) wrote:
>Further, when porting numbers from one
>provider to another, i.e., changing the DNAME or CNAME to point to another
>domain, the change has to happen within a small service window.

 From my point of view, and the way I read your draft, the change of 
the CNAME and DNAME is something different than porting of the 
porting of a number.

I.e. I differ between the party which handles the redirect service, 
and the telco which handles the E.164 number. Those are two different 
entities.

When a customer changes the redirect service, you change the 
CNAME/DNAME/NS etc, but when changing telco (i.e. porting the number 
from one telco to another) you don't have to change the redirect 
service, but you update the content in the redirect service database.

This database can either be direct "tel" URIs in NAPTRs for the 
number, or changes in an LDAP database which the redirect service 
hosts. In both cases, porting of the telephone number from one telco 
to another means updating the NAPTR (in the case of a "direct" URI) 
or update of the LDAP database (in the case of an "indirect" URI).

Basically, I differ between the listing service for URIs, and who is 
responsible for the number.

    Patrik

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul 20 20:40:20 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05975
	for <enum-archive@odin.ietf.org>; Thu, 20 Jul 2000 20:40:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22097;
	Thu, 20 Jul 2000 20:39:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22074
	for <enum@ns.ietf.org>; Thu, 20 Jul 2000 20:39:50 -0400 (EDT)
Received: from kind.noc.inet2000.gr.jp (kind.noc.inet2000.gr.jp [133.195.1.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05775
	for <ENUM@ietf.org>; Thu, 20 Jul 2000 20:39:48 -0400 (EDT)
Received: from [133.195.65.75] (dhcp-065075.wireless-conference.inet2000.gr.jp [133.195.65.75])
	by kind.noc.inet2000.gr.jp (8.9.3/3.7W) with ESMTP id JAA27249;
	Fri, 21 Jul 2000 09:39:45 +0900 (JST)
Mime-Version: 1.0
X-Sender: pfaltstr@127.0.0.1
Message-Id: <p04320413b59d41b56e6b@[133.195.65.75]>
In-Reply-To: 
 <4102273CEB77D211869200805FE6F5939EBD38@xch-phl-01.he.boeing.com>
References: 
 <4102273CEB77D211869200805FE6F5939EBD38@xch-phl-01.he.boeing.com>
Date: Fri, 21 Jul 2000 09:01:10 +0900
To: "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>, ENUM@ietf.org
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <paf@cisco.com>
Subject: RE: [Enum] draft-ietf-enum-operation-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 10.35 -0400 00-07-20, Manfredi, Albert E wrote:
>I'd like this settled, myself. I've seen claims on this list that DNS can
>now be updated in seconds, including master and slave servers. True? False?

Updated in seconds IFF all servers:

- Can handle the extension NOTIFY
- Have enough spare CPU-cycles to actually request a zonetransfer within
   a short time span after a NOTIFY arrives
- Have enough I/O to transfer and handle the zone itself (or can handle
   IXFR for incremental updates) within the timespan

Most servers can handle all of the above.

What is not true though is that we can set TTL to zero. That have 
some weird consequences which caching and the impact on the number of 
queries that are sent. Having TTL on an RR zero is not recommended at 
all. 15 minutes, ok, 15 seconds....hmmm....I would not have that.

So, I would say that 15 minute delay for updates are probably pretty 
ok, so for updates that need faster updates (propagation time is what 
I would like to call it) than 15 minutes should update the 
information somewhere else than in DNS.

Personally, I feel that a redirect of a phonecall with 15 minute 
delay of propagation is normally quite ok. I.e. when I am at home and 
request the number at home to be redirected to my cellphone, it takes 
me more than 15 minutes to take on my shoes, jackets, forget the car 
keys, find them, find the cellphone, pick up my bag, leave the house 
and go to the car.

I have no experience in what propagation time one have in the 
traditional phone system, but do know that the time is different 
depending on what operation you do. For example, when changing data 
within one IN system, the update is probably quite fast (modulo time 
for eventual mirroring internally in the database that the IN system 
uses) while porting a phone number between two telco's is probably 
slower (slower than 15 minutes).

    paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul 20 21:45:37 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29691
	for <enum-archive@odin.ietf.org>; Thu, 20 Jul 2000 21:45:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22901;
	Thu, 20 Jul 2000 21:45:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22882
	for <enum@ns.ietf.org>; Thu, 20 Jul 2000 21:45:13 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29517
	for <ENUM@ietf.org>; Thu, 20 Jul 2000 21:45:11 -0400 (EDT)
Received: from research.telcordia.com (mmc-11-as5200-d25.cc.telcordia.com [128.96.11.25] (may be forged))
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6L1icR27181;
	Thu, 20 Jul 2000 21:44:38 -0400 (EDT)
Message-ID: <3977AB0A.4C19BF89@research.telcordia.com>
Date: Thu, 20 Jul 2000 21:44:42 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
CC: ENUM@ietf.org
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
References: <4102273CEB77D211869200805FE6F5939EBD38@xch-phl-01.he.boeing.com> <p04320413b59d41b56e6b@[133.195.65.75]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

Patrik,

I generally agree with your comments. There are two factors that affect the
propagation of changes in DNS:
(1) Caching delay, as determined by the TTL of individual NAPTR RR;
(2) Zone update delay, as determined by the REFRESH timer of the SOA RR of the
zone if NOTIFY is not used.
As you pointed out, setting TTL close to 0 may cause strained behaviors on the
DNS system. In your document draft-ietf-enum-e164-dns-02.txt (Section 5), you
also mentioned that TTL should be kept minimum. Since we are discussing
operational guidelines here, do you or other DNS experts in IETF have any
recommendation as to what constitutes minimum TTL in the context of ENUM? I
think that will really help to move this document forward.

I have some additional comments below.

Patrik Fältström wrote:

> At 10.35 -0400 00-07-20, Manfredi, Albert E wrote:
> >I'd like this settled, myself. I've seen claims on this list that DNS can
> >now be updated in seconds, including master and slave servers. True? False?
>
> Updated in seconds IFF all servers:
>
> - Can handle the extension NOTIFY
> - Have enough spare CPU-cycles to actually request a zonetransfer within
>    a short time span after a NOTIFY arrives
> - Have enough I/O to transfer and handle the zone itself (or can handle
>    IXFR for incremental updates) within the timespan
>
> Most servers can handle all of the above.
>

Agree. Zone transfer delay can be minimize via NOTIFY and incremental transfer
IF all name servers for a zone are configured to handle these two features. As
operational guidelines, shall we recommend that all ENUM servers should use
NOTIFY and IXFR for zone transfer?

>
> What is not true though is that we can set TTL to zero. That have
> some weird consequences which caching and the impact on the number of
> queries that are sent. Having TTL on an RR zero is not recommended at
> all. 15 minutes, ok, 15 seconds....hmmm....I would not have that.
>

Again, can we provide operational guideline here as to how minimum shall a NAPTR
RR TTL be set for ENUM systems?

>
> So, I would say that 15 minute delay for updates are probably pretty
> ok, so for updates that need faster updates (propagation time is what
> I would like to call it) than 15 minutes should update the
> information somewhere else than in DNS.
>
> Personally, I feel that a redirect of a phonecall with 15 minute
> delay of propagation is normally quite ok. I.e. when I am at home and
> request the number at home to be redirected to my cellphone, it takes
> me more than 15 minutes to take on my shoes, jackets, forget the car
> keys, find them, find the cellphone, pick up my bag, leave the house
> and go to the car.
>
> I have no experience in what propagation time one have in the
> traditional phone system, but do know that the time is different
> depending on what operation you do. For example, when changing data
> within one IN system, the update is probably quite fast (modulo time
> for eventual mirroring internally in the database that the IN system
> uses) while porting a phone number between two telco's is probably
> slower (slower than 15 minutes).

I guess you and Greg were talking about slightly different things regarding
"fast" or "slow" updates in switches and IN databases. Loosely speaking, IN
databases, such as 800 or LNP databases, are called real time databases. The
update on a real time database is scheduled on a daily basis in batch mode
through the SMS based on a common reference database, where changes are made
continuously during the day. There is no real-time update from the subscriber
directly, it is done by the operator via the SMS console. Once master copy is
downloaded to the real time database, there is little delay in propagation since
there is no caching mechanism in PSTN.

On the other hand, if you talk about the call forwarding feature, such as
redirect calls to your cell phone, is not slow either. Typically, call
forwarding is a switch-based feature. Once you activate the feature, the
forwarded number will be stored in the switch immediately after you hang up. In
fact, some system will give you a confirmation before you hang up. Even if the
feature is implemented in IN, the redirection will be effective right away,
though the activation duration may take longer since it involves signaling
between the switch and the SCP.

Now the question is: if someone wants to implement a service that needs
immediate update using ENUM, such as the call forwarding feature, what is the
guideline for populating the NAPTR RR? From what you explained above, it seems
that he/she needs to use ENUM as a redirect server to point to a server that
really handles the update in real time. In that case, the pointer is constant,
and there is no update involved for ENUM.

However, porting a number to another provider is different since it usually
involved chaning the NAPTR RR to point to the new provider. In this case, due to
caching, we may have to deal with inconsistent data for a short period of time.
I guess this is what Greg was concerned about. Is that true, Greg?

Cheers,

--Hong


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul 20 22:19:16 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11388
	for <enum-archive@odin.ietf.org>; Thu, 20 Jul 2000 22:19:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23327;
	Thu, 20 Jul 2000 22:17:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23302
	for <enum@ns.ietf.org>; Thu, 20 Jul 2000 22:17:50 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10902
	for <ENUM@ietf.org>; Thu, 20 Jul 2000 22:17:47 -0400 (EDT)
Received: from research.telcordia.com (mmc-11-as5200-d25.cc.telcordia.com [128.96.11.25] (may be forged))
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6L2GUR28023;
	Thu, 20 Jul 2000 22:16:31 -0400 (EDT)
Message-ID: <3977B283.365F233C@research.telcordia.com>
Date: Thu, 20 Jul 2000 22:16:35 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
CC: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>,
        "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>, ENUM@ietf.org
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
References: <6B57F36F4FF9D111B30A0008C7F413370370527A@exdal1.ons.octel.com> <p04320414b59d43b8e794@[133.195.65.75]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

Patrik, Greg and Albert,

I am reading your discussions with great interests. It seems to me that there
are a number of assumptions that need to be made explicit before we can
understand each other's viewpoint. The bottom line question is how delegation
of  the numbering space is done. So far, I have seen few discussions on this
topic. Maybe it is out of the scope of ENUM. But if we are to discuss
operational guidelines, then we need to find a good enough answer for this
basic question.

If we assume a single administrator for ENUM, at least on a national basis,
then what Patrik suggested may work. One possible way is to point the NAPTR
record to the common reference database of the administrator, or a finite
number of copies. (I am not saying this is a good solution.) If we assume a
distributed administration scheme like DNS today, then Greg's concern is quite
valid. Note that domain names are generally not portable, hence we need to come
up with special guidelines for using DNS to handle portable E.164 numbers.

So which model do we assume for ENUM, or both, or do we care?

I hope we can start discussing how delegation is done for ENUM, unless the WG
chairs declare that it is out of scope.

Cheers,

--Hong

Patrik Fältström wrote:

> At 14.00 -0500 00-07-20, Vaudreuil, Greg M (Greg) wrote:
> >Further, when porting numbers from one
> >provider to another, i.e., changing the DNAME or CNAME to point to another
> >domain, the change has to happen within a small service window.
>
>  From my point of view, and the way I read your draft, the change of
> the CNAME and DNAME is something different than porting of the
> porting of a number.
>
> I.e. I differ between the party which handles the redirect service,
> and the telco which handles the E.164 number. Those are two different
> entities.
>
> When a customer changes the redirect service, you change the
> CNAME/DNAME/NS etc, but when changing telco (i.e. porting the number
> from one telco to another) you don't have to change the redirect
> service, but you update the content in the redirect service database.
>
> This database can either be direct "tel" URIs in NAPTRs for the
> number, or changes in an LDAP database which the redirect service
> hosts. In both cases, porting of the telephone number from one telco
> to another means updating the NAPTR (in the case of a "direct" URI)
> or update of the LDAP database (in the case of an "indirect" URI).
>
> Basically, I differ between the listing service for URIs, and who is
> responsible for the number.
>
>     Patrik
>
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 21 00:14:03 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21962
	for <enum-archive@odin.ietf.org>; Fri, 21 Jul 2000 00:14:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24620;
	Fri, 21 Jul 2000 00:12:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24595
	for <enum@ns.ietf.org>; Fri, 21 Jul 2000 00:12:21 -0400 (EDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21427
	for <ENUM@ietf.org>; Fri, 21 Jul 2000 00:12:22 -0400 (EDT)
Received: from [133.195.65.75] (ssh.cisco.com [171.69.10.34])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id VAA15311;
	Thu, 20 Jul 2000 21:11:39 -0700 (PDT)
Mime-Version: 1.0
X-Sender: pfaltstr@127.0.0.1
Message-Id: <p04320409b59d794eaddb@[133.195.65.75]>
In-Reply-To: <3977AB0A.4C19BF89@research.telcordia.com>
References: 
 <4102273CEB77D211869200805FE6F5939EBD38@xch-phl-01.he.boeing.com>
 <p04320413b59d41b56e6b@[133.195.65.75]>
 <3977AB0A.4C19BF89@research.telcordia.com>
Date: Fri, 21 Jul 2000 13:05:49 +0900
To: Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <paf@cisco.com>
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
Cc: ENUM@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 21.44 -0400 00-07-20, Hong Liu wrote:
>I generally agree with your comments. There are two factors that affect the
>propagation of changes in DNS:
>(1) Caching delay, as determined by the TTL of individual NAPTR RR;
>(2) Zone update delay, as determined by the REFRESH timer of the SOA RR of the
>zone if NOTIFY is not used.

You also have to think about the time negative responses are cached, 
which is the minimum of the TTL for the SOA and the TTL in the SOA.

>As you pointed out, setting TTL close to 0 may cause strained behaviors on the
>DNS system. In your document draft-ietf-enum-e164-dns-02.txt (Section 5), you
>also mentioned that TTL should be kept minimum. Since we are discussing
>operational guidelines here, do you or other DNS experts in IETF have any
>recommendation as to what constitutes minimum TTL in the context of ENUM? I
>think that will really help to move this document forward.

I think TTL can be 5 minutes or so, and we can expect a propagation 
delay of some 15 minutes or so. Not shorter.

As Greg very correctly points out, for the use we expect, caching 
will not very often have any effect for the leaf nodes as one doesn't 
dial one number so many times in the same period of time, but as many 
people have pointed out we are not only talking about telephony.

Also, the problem with propagation of changes in DNS is a problem 
which "the normal" internet community already have because of 
interest in dynamic update and interaction with dhcp(-like) services.

So, writing more specific terms than "kept minimum" in my draft is 
not really good, I feel, as we don't work with DNS operational 
issues. We do though work with ENUM operational issues, and due to 
DNS operations, we can not expect (I belive) that a change propagates 
within a shorter time period than 15 minutes.

Experiments might show that I am wrong, and that changes might 
propagate faster.

But, I also always belive that we will always have a fast and a slow 
update mechanism for the services which uses the ENUM mechanism. The 
definition of what is fast and what is slow is defined by the 
propagation time in DNS. What it is measured in seconds may vary.

>Agree. Zone transfer delay can be minimize via NOTIFY and incremental transfer
>IF all name servers for a zone are configured to handle these two features. As
>operational guidelines, shall we recommend that all ENUM servers should use
>NOTIFY and IXFR for zone transfer?

I think all servers should use whatever mechanism the DNS people 
invent which makes DNS operations being as stable as possible.

Today, yes, NOTIFY is definitely _any_ person running a DNS server 
should use, not only ENUM.

You should talk with the wg chairs (at least) of the DNSOP wg to see 
that you do not replicate any work they do (I am not up to date on 
what they are doing...).

>Again, can we provide operational guideline here as to how minimum 
>shall a NAPTR
>RR TTL be set for ENUM systems?

Nope. That depends on your configuration of your DNS servers.

>I guess you and Greg were talking about slightly different things regarding
>"fast" or "slow" updates in switches and IN databases. Loosely speaking, IN
>databases, such as 800 or LNP databases, are called real time databases. The
>update on a real time database is scheduled on a daily basis in batch mode
>through the SMS based on a common reference database, where changes are made
>continuously during the day. There is no real-time update from the subscriber
>directly, it is done by the operator via the SMS console. Once master copy is
>downloaded to the real time database, there is little delay in 
>propagation since
>there is no caching mechanism in PSTN.

But, then you have a delay from the time when the change was ordered 
to when the batch process has finished. If that time is longer than 
15 minutes, we have a slow process.

I would _not_ call the above a real time database.

>On the other hand, if you talk about the call forwarding feature, such as
>redirect calls to your cell phone, is not slow either. Typically, call
>forwarding is a switch-based feature. Once you activate the feature, the
>forwarded number will be stored in the switch immediately after you 
>hang up. In
>fact, some system will give you a confirmation before you hang up. Even if the
>feature is implemented in IN, the redirection will be effective right away,
>though the activation duration may take longer since it involves signaling
>between the switch and the SCP.

This is fast according to me.

>Now the question is: if someone wants to implement a service that needs
>immediate update using ENUM, such as the call forwarding feature, what is the
>guideline for populating the NAPTR RR? From what you explained above, it seems
>that he/she needs to use ENUM as a redirect server to point to a server that
>really handles the update in real time. In that case, the pointer is constant,
>and there is no update involved for ENUM.

For updates (writes) you can use whatever mechanism you want. For 
slow updates, you can store the actual information in the NAPTR 
record (for reads). That is the first example of yours above. For 
fast  updates (second example of yours) you can in the NAPTR for 
example store an LDAP URI to the database which is updated (write) by 
the use of a phonecall.

>However, porting a number to another provider is different since it usually
>involved chaning the NAPTR RR to point to the new provider.

Yes, but that mean updating the content of the NAPTR RR. And you 
should not forget that you in some cases want to change the party 
which host the NAPTR RR itself, without changing the content of the 
NAPTR itself.

>In this case, due to
>caching, we may have to deal with inconsistent data for a short 
>period of time.
>I guess this is what Greg was concerned about. Is that true, Greg?

My point is that one can accept inconsistencies for a short amount of 
time for some services. Which ones have to be included in this draft 
I think. Just stating that DNS is not usable with broad arguments and 
waving with hands is not a  good thing.

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 21 00:14:06 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21997
	for <enum-archive@odin.ietf.org>; Fri, 21 Jul 2000 00:14:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24697;
	Fri, 21 Jul 2000 00:13:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24674
	for <enum@ns.ietf.org>; Fri, 21 Jul 2000 00:13:52 -0400 (EDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21903
	for <ENUM@ietf.org>; Fri, 21 Jul 2000 00:13:52 -0400 (EDT)
Received: from [133.195.65.75] (ssh.cisco.com [171.69.10.34])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id VAA15365;
	Thu, 20 Jul 2000 21:11:54 -0700 (PDT)
Mime-Version: 1.0
X-Sender: pfaltstr@127.0.0.1
Message-Id: <p0432040ab59d7cbe7c8b@[133.195.65.75]>
In-Reply-To: <3977B283.365F233C@research.telcordia.com>
References: 
 <6B57F36F4FF9D111B30A0008C7F413370370527A@exdal1.ons.octel.com>
 <p04320414b59d43b8e794@[133.195.65.75]>
 <3977B283.365F233C@research.telcordia.com>
Date: Fri, 21 Jul 2000 13:06:34 +0900
To: Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <paf@cisco.com>
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
Cc: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>,
        "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>, ENUM@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 22.16 -0400 00-07-20, Hong Liu wrote:
>Note that domain names are generally not portable, hence we need to come
>up with special guidelines for using DNS to handle portable E.164 numbers.

This probably differs from country to country on how to do this.

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 21 01:38:34 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04691
	for <enum-archive@odin.ietf.org>; Fri, 21 Jul 2000 01:38:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00598;
	Fri, 21 Jul 2000 01:38:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00520
	for <enum@ns.ietf.org>; Fri, 21 Jul 2000 01:38:05 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04373
	for <enum@ietf.org>; Fri, 21 Jul 2000 01:38:05 -0400 (EDT)
Received: from research.telcordia.com (mmc-11-as5200-d25.cc.telcordia.com [128.96.11.25])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6L5bXR03496;
	Fri, 21 Jul 2000 01:37:33 -0400 (EDT)
Message-ID: <3977E1A0.5A4BBBEC@research.telcordia.com>
Date: Fri, 21 Jul 2000 01:37:36 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: enum@ietf.org
Subject: [Fwd: [Enum] draft-ietf-enum-operation-00.txt]
Content-Type: multipart/mixed;
 boundary="------------D65C0F21F9B0AE05F24A1D6B"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

This is a multi-part message in MIME format.
--------------D65C0F21F9B0AE05F24A1D6B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Oops! I forgot to hit the reply-all button. Sorry.

--------------D65C0F21F9B0AE05F24A1D6B
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: <lhong@research.telcordia.com>
Received: from thumper.research.telcordia.com (thumper-7 [192.4.7.4])
	by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id BAA14276
	for <lhong@mailee>; Fri, 21 Jul 2000 01:33:49 -0400 (EDT)
Received: from research.telcordia.com (mmc-11-as5200-d25.cc.telcordia.com [128.96.11.25])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6L5XjR03428;
	Fri, 21 Jul 2000 01:33:45 -0400 (EDT)
Message-ID: <3977E0BC.6AB09145@research.telcordia.com>
Date: Fri, 21 Jul 2000 01:33:48 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
References: <4102273CEB77D211869200805FE6F5939EBD38@xch-phl-01.he.boeing.com>
	 <p04320413b59d41b56e6b@[133.195.65.75]>
	 <3977AB0A.4C19BF89@research.telcordia.com> <p04320409b59d794eaddb@[133.195.65.75]>
Content-Type: text/plain; charset=iso-8859-1
X-Mozilla-Status2: 00000000
Content-Transfer-Encoding: 8bit

Paf,

Thanks for your response. I have a few more comments, just for the sake of
discussion.

Cheers,

--Hong

Patrik Fältström wrote:

> At 21.44 -0400 00-07-20, Hong Liu wrote:
> You also have to think about the time negative responses are cached,
> which is the minimum of the TTL for the SOA and the TTL in the SOA.

That is true. Thanks!

> I think TTL can be 5 minutes or so, and we can expect a propagation
> delay of some 15 minutes or so. Not shorter.

It is always good to have a rough range.

>
> As Greg very correctly points out, for the use we expect, caching
> will not very often have any effect for the leaf nodes as one doesn't
> dial one number so many times in the same period of time, but as many
> people have pointed out we are not only talking about telephony.
>

That may not be totally true even for telephony, say call center applications.

>
> Also, the problem with propagation of changes in DNS is a problem
> which "the normal" internet community already have because of
> interest in dynamic update and interaction with dhcp(-like) services.
>

Do you have any pointers to this work? I really want to take a look at it.

>
> So, writing more specific terms than "kept minimum" in my draft is
> not really good, I feel, as we don't work with DNS operational
> issues. We do though work with ENUM operational issues, and due to
> DNS operations, we can not expect (I belive) that a change propagates
> within a shorter time period than 15 minutes.
>
> Experiments might show that I am wrong, and that changes might
> propagate faster.

I understand your intent now.

> But, I also always belive that we will always have a fast and a slow
> update mechanism for the services which uses the ENUM mechanism. The
> definition of what is fast and what is slow is defined by the
> propagation time in DNS. What it is measured in seconds may vary.

Agree. It just did not spell out clearly to me by reading the drafts.

> I think all servers should use whatever mechanism the DNS people
> invent which makes DNS operations being as stable as possible.
>
> Today, yes, NOTIFY is definitely _any_ person running a DNS server
> should use, not only ENUM.
>
> You should talk with the wg chairs (at least) of the DNSOP wg to see
> that you do not replicate any work they do (I am not up to date on
> what they are doing...).

I was simply requesting more information. If DNSOP already has guidelines, that
will be great.

> But, then you have a delay from the time when the change was ordered
> to when the batch process has finished. If that time is longer than
> 15 minutes, we have a slow process.

I just wanted to show that IN update is not necessarily "fast" by your first email
of this thread. It is a slow process for 800 database update.

>
> I would _not_ call the above a real time database.

By real time, I mean real time translation. I did not invent this term. It is
widely used in the PSTN world.

> Yes, but that mean updating the content of the NAPTR RR. And you
> should not forget that you in some cases want to change the party
> which host the NAPTR RR itself, without changing the content of the
> NAPTR itself.

Could you explain in more detail how to change the party hosting the NAPTR record?
I am just not knowledgeable enough about all DNS mechanisms. It seems to me that
the same E.164 number is fixed in the e164.arpa hierarchy.

> My point is that one can accept inconsistencies for a short amount of
> time for some services. Which ones have to be included in this draft
> I think. Just stating that DNS is not usable with broad arguments and
> waving with hands is not a  good thing.

I am not objecting the use of DNS. But I also want to understand the limitation of
DNS for potential applications using ENUM.





--------------D65C0F21F9B0AE05F24A1D6B--


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 21 12:27:23 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22639
	for <enum-archive@odin.ietf.org>; Fri, 21 Jul 2000 12:27:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08271;
	Fri, 21 Jul 2000 12:25:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08246
	for <enum@ns.ietf.org>; Fri, 21 Jul 2000 12:25:29 -0400 (EDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21850
	for <ENUM@ietf.org>; Fri, 21 Jul 2000 12:25:29 -0400 (EDT)
Received: from stl-av-01.boeing.com ([192.76.190.6])
	by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA20499
	for <ENUM@ietf.org>; Fri, 21 Jul 2000 11:25:28 -0500 (CDT)
Received: from slb-hub-01.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id LAA26118
	for <ENUM@ietf.org>; Fri, 21 Jul 2000 11:25:27 -0500 (CDT)
Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 21 Jul 2000 09:25:23 -0700
Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21)
	id <3GJSP6W5>; Fri, 21 Jul 2000 12:25:22 -0400
Message-Id: <4102273CEB77D211869200805FE6F5939EBD3A@xch-phl-01.he.boeing.com>
From: "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>
To: "'Hong Liu'" <lhong@research.telcordia.com>
Cc: ENUM@ietf.org
Subject: RE: [Enum] draft-ietf-enum-operation-00.txt
Date: Fri, 21 Jul 2000 12:25:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

> -----Original Message-----
> From: Hong Liu [mailto:lhong@research.telcordia.com]

> If we assume a
> distributed administration scheme like DNS today, then Greg's 
> concern is quite
> valid. Note that domain names are generally not portable, 
> hence we need to come
> up with special guidelines for using DNS to handle portable 
> E.164 numbers.

Hmmm. Domain names can be portable. Why not? Which is why I thought this
model works quite well for portable phone numbers too. Except, as Patrik
points out with his numbers, not portable "enough" in a conservative
scenario to handle mobility. But close.

Fast enough to forward the number to your cell phone if you dropped your
keys somewhere before leaving your house, but not always fast enough to keep
track of the actual location of your cell phone while you are driving down
the autobahn.

> So which model do we assume for ENUM, or both, or do we care?
> 
> I hope we can start discussing how delegation is done for 
> ENUM, unless the WG
> chairs declare that it is out of scope.

Agreed.

Bert
albert.e.manfredi@boeing.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 21 12:47:51 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01164
	for <enum-archive@odin.ietf.org>; Fri, 21 Jul 2000 12:47:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08644;
	Fri, 21 Jul 2000 12:47:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08619
	for <enum@ns.ietf.org>; Fri, 21 Jul 2000 12:47:08 -0400 (EDT)
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00883
	for <ENUM@ietf.org>; Fri, 21 Jul 2000 12:47:03 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id MAA21519;
	Fri, 21 Jul 2000 12:46:22 -0400 (EDT)
Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id MAA27048; Fri, 21 Jul 2000 12:48:01 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21)
	id <PLP5LAK0>; Fri, 21 Jul 2000 12:46:19 -0400
Message-ID: <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
From: "Pfautz, Penn L, NNAD" <ppfautz@att.com>
To: Hong Liu <lhong@research.telcordia.com>,
        =?iso-8859-1?Q?Patrik_F=E4?=
	=?iso-8859-1?Q?ltstr=F6m?= <paf@cisco.com>
Cc: ENUM@ietf.org
Subject: RE: [Enum] draft-ietf-enum-operation-00.txt
Date: Fri, 21 Jul 2000 12:43:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA08620
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

Just to clarify, changes to the LNP SMS are supposed to be reflected in
carrier networks within 15 minutes of activation.

Penn Pfautz

-----Original Message-----
From: Hong Liu [mailto:lhong@research.telcordia.com]
Sent: Thursday, July 20, 2000 9:45 PM
To: Patrik Fältström
Cc: ENUM@ietf.org
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt


Patrik,

I generally agree with your comments. There are two factors that affect the
propagation of changes in DNS:
(1) Caching delay, as determined by the TTL of individual NAPTR RR;
(2) Zone update delay, as determined by the REFRESH timer of the SOA RR of
the
zone if NOTIFY is not used.
As you pointed out, setting TTL close to 0 may cause strained behaviors on
the
DNS system. In your document draft-ietf-enum-e164-dns-02.txt (Section 5),
you
also mentioned that TTL should be kept minimum. Since we are discussing
operational guidelines here, do you or other DNS experts in IETF have any
recommendation as to what constitutes minimum TTL in the context of ENUM? I
think that will really help to move this document forward.

I have some additional comments below.

Patrik Fältström wrote:

> At 10.35 -0400 00-07-20, Manfredi, Albert E wrote:
> >I'd like this settled, myself. I've seen claims on this list that DNS can
> >now be updated in seconds, including master and slave servers. True?
False?
>
> Updated in seconds IFF all servers:
>
> - Can handle the extension NOTIFY
> - Have enough spare CPU-cycles to actually request a zonetransfer within
>    a short time span after a NOTIFY arrives
> - Have enough I/O to transfer and handle the zone itself (or can handle
>    IXFR for incremental updates) within the timespan
>
> Most servers can handle all of the above.
>

Agree. Zone transfer delay can be minimize via NOTIFY and incremental
transfer
IF all name servers for a zone are configured to handle these two features.
As
operational guidelines, shall we recommend that all ENUM servers should use
NOTIFY and IXFR for zone transfer?

>
> What is not true though is that we can set TTL to zero. That have
> some weird consequences which caching and the impact on the number of
> queries that are sent. Having TTL on an RR zero is not recommended at
> all. 15 minutes, ok, 15 seconds....hmmm....I would not have that.
>

Again, can we provide operational guideline here as to how minimum shall a
NAPTR
RR TTL be set for ENUM systems?

>
> So, I would say that 15 minute delay for updates are probably pretty
> ok, so for updates that need faster updates (propagation time is what
> I would like to call it) than 15 minutes should update the
> information somewhere else than in DNS.
>
> Personally, I feel that a redirect of a phonecall with 15 minute
> delay of propagation is normally quite ok. I.e. when I am at home and
> request the number at home to be redirected to my cellphone, it takes
> me more than 15 minutes to take on my shoes, jackets, forget the car
> keys, find them, find the cellphone, pick up my bag, leave the house
> and go to the car.
>
> I have no experience in what propagation time one have in the
> traditional phone system, but do know that the time is different
> depending on what operation you do. For example, when changing data
> within one IN system, the update is probably quite fast (modulo time
> for eventual mirroring internally in the database that the IN system
> uses) while porting a phone number between two telco's is probably
> slower (slower than 15 minutes).

I guess you and Greg were talking about slightly different things regarding
"fast" or "slow" updates in switches and IN databases. Loosely speaking, IN
databases, such as 800 or LNP databases, are called real time databases. The
update on a real time database is scheduled on a daily basis in batch mode
through the SMS based on a common reference database, where changes are made
continuously during the day. There is no real-time update from the
subscriber
directly, it is done by the operator via the SMS console. Once master copy
is
downloaded to the real time database, there is little delay in propagation
since
there is no caching mechanism in PSTN.

On the other hand, if you talk about the call forwarding feature, such as
redirect calls to your cell phone, is not slow either. Typically, call
forwarding is a switch-based feature. Once you activate the feature, the
forwarded number will be stored in the switch immediately after you hang up.
In
fact, some system will give you a confirmation before you hang up. Even if
the
feature is implemented in IN, the redirection will be effective right away,
though the activation duration may take longer since it involves signaling
between the switch and the SCP.

Now the question is: if someone wants to implement a service that needs
immediate update using ENUM, such as the call forwarding feature, what is
the
guideline for populating the NAPTR RR? From what you explained above, it
seems
that he/she needs to use ENUM as a redirect server to point to a server that
really handles the update in real time. In that case, the pointer is
constant,
and there is no update involved for ENUM.

However, porting a number to another provider is different since it usually
involved chaning the NAPTR RR to point to the new provider. In this case,
due to
caching, we may have to deal with inconsistent data for a short period of
time.
I guess this is what Greg was concerned about. Is that true, Greg?

Cheers,

--Hong


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 21 14:18:58 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00281
	for <enum-archive@odin.ietf.org>; Fri, 21 Jul 2000 14:18:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10053;
	Fri, 21 Jul 2000 14:18:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10026
	for <enum@ns.ietf.org>; Fri, 21 Jul 2000 14:18:11 -0400 (EDT)
Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29598
	for <ENUM@ietf.org>; Fri, 21 Jul 2000 14:18:08 -0400 (EDT)
Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA09193
	for <ENUM@ietf.org>; Fri, 21 Jul 2000 14:18:08 -0400 (EDT)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA08938;
	Fri, 21 Jul 2000 14:17:49 -0400 (EDT)
Received: from buzz.ons.octel.com by ihrh1.emsr.lucent.com (8.8.8+Sun/EMS-1.5 Solaris/emsr)
	id NAA12147 for ; Fri, 21 Jul 2000 13:17:47 -0500 (CDT)
Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200])
	by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id NAA19823;
	Fri, 21 Jul 2000 13:17:47 -0500 (CDT)
Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0)
	id <KXYSJWAA>; Fri, 21 Jul 2000 13:14:01 -0500
Message-ID: <6B57F36F4FF9D111B30A0008C7F4133703705290@exdal1.ons.octel.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@avaya.com>
To: "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>,
        "'Hong Liu'"
	 <lhong@research.telcordia.com>
Cc: ENUM@ietf.org
Subject: RE: [Enum] draft-ietf-enum-operation-00.txt
Date: Fri, 21 Jul 2000 13:13:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

I would not expect call forwarding to hit DNS.  That is far too dynamic and
should be handled by a gatekeeper or other service-specific directory.  

I completely agree with Patrick, DNS needs to deal with assignment of
addresses to service registrars and at the next level down, the mapping of
services (RRs) to addresses.  If you have a "one number" type
follow-me-wherever service, it should be done in a service-specific
directory, not as a laundry list of NAPTR records....

I can agree that a 15 minute TTL for address assignment and service record
mapping is OK.  It is clearly not OK to wait 15 minutes for a
call-=forwarding action to take hold.  That should be nearly instantanious,
but again, I do not see that as an ENUM problem.

Greg V.

-----Original Message-----
From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com]
Sent: Friday, July 21, 2000 11:25 AM
To: 'Hong Liu'
Cc: ENUM@ietf.org
Subject: RE: [Enum] draft-ietf-enum-operation-00.txt


> -----Original Message-----
> From: Hong Liu [mailto:lhong@research.telcordia.com]

> If we assume a
> distributed administration scheme like DNS today, then Greg's 
> concern is quite
> valid. Note that domain names are generally not portable, 
> hence we need to come
> up with special guidelines for using DNS to handle portable 
> E.164 numbers.

Hmmm. Domain names can be portable. Why not? Which is why I thought this
model works quite well for portable phone numbers too. Except, as Patrik
points out with his numbers, not portable "enough" in a conservative
scenario to handle mobility. But close.

Fast enough to forward the number to your cell phone if you dropped your
keys somewhere before leaving your house, but not always fast enough to keep
track of the actual location of your cell phone while you are driving down
the autobahn.

> So which model do we assume for ENUM, or both, or do we care?
> 
> I hope we can start discussing how delegation is done for 
> ENUM, unless the WG
> chairs declare that it is out of scope.

Agreed.

Bert
albert.e.manfredi@boeing.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Jul 22 17:08:23 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24866
	for <enum-archive@odin.ietf.org>; Sat, 22 Jul 2000 17:08:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10456;
	Sat, 22 Jul 2000 17:07:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10431
	for <enum@ns.ietf.org>; Sat, 22 Jul 2000 17:07:55 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24760
	for <ENUM@ietf.org>; Sat, 22 Jul 2000 17:07:54 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 156E397; Sat, 22 Jul 2000 23:07:25 +0200 (MET DST)
Received: from [10.0.0.9] ([171.70.221.22])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA11021;
	Sat, 22 Jul 2000 23:07:22 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p04320410b59fb8182bf7@[10.0.0.9]>
In-Reply-To: 
 <6B57F36F4FF9D111B30A0008C7F4133703705290@exdal1.ons.octel.com>
References: <6B57F36F4FF9D111B30A0008C7F4133703705290@exdal1.ons.octel.com>
Date: Sat, 22 Jul 2000 13:44:39 -0700
To: "Vaudreuil, Greg M (Greg)" <gregv@avaya.com>,
        "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>,
        "'Hong Liu'" <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: RE: [Enum] draft-ietf-enum-operation-00.txt
Cc: ENUM@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 13.13 -0500 00-07-21, Vaudreuil, Greg M (Greg) wrote:
>I can agree that a 15 minute TTL for address assignment and service record
>mapping is OK.  It is clearly not OK to wait 15 minutes for a
>call-=forwarding action to take hold.  That should be nearly instantanious,
>but again, I do not see that as an ENUM problem.

...and I would like to have text about this in your paper about enum 
operations. I.e. what is suitable for what, exactly like this thing 
you and I agree on.

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Jul 22 17:08:46 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24964
	for <enum-archive@odin.ietf.org>; Sat, 22 Jul 2000 17:08:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10380;
	Sat, 22 Jul 2000 17:06:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10349
	for <enum@ns.ietf.org>; Sat, 22 Jul 2000 17:06:57 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24571
	for <enum@ietf.org>; Sat, 22 Jul 2000 17:06:55 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 1761297; Sat, 22 Jul 2000 23:06:26 +0200 (MET DST)
Received: from [10.0.0.9] ([171.70.221.22])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA10974;
	Sat, 22 Jul 2000 23:06:22 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p04320402b59faceb8bf6@[10.0.0.9]>
In-Reply-To: <3977E0BC.6AB09145@research.telcordia.com>
References: 
 <4102273CEB77D211869200805FE6F5939EBD38@xch-phl-01.he.boeing.com>	
 <p04320413b59d41b56e6b@[133.195.65.75]>	
 <3977AB0A.4C19BF89@research.telcordia.com>
 <p04320409b59d794eaddb@[133.195.65.75]>
 <3977E0BC.6AB09145@research.telcordia.com>
Date: Sat, 22 Jul 2000 13:42:41 -0700
To: Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
Cc: enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 01.33 -0400 00-07-21, Hong Liu wrote:
>  > As Greg very correctly points out, for the use we expect, caching
>>  will not very often have any effect for the leaf nodes as one doesn't
>>  dial one number so many times in the same period of time, but as many
>>  people have pointed out we are not only talking about telephony.
>>
>
>That may not be totally true even for telephony, say call center applications.

Correct.

>  > Also, the problem with propagation of changes in DNS is a problem
>>  which "the normal" internet community already have because of
>  > interest in dynamic update and interaction with dhcp(-like) services.
>
>Do you have any pointers to this work? I really want to take a look at it.

DNSOP wg is working on this. Remember that Microsoft claims that they 
have solved this problem and uses dynamic updates, IXFR and NOTIFY in 
their 2000-version of the DNS server. Personally, I think they have 
ignored the caching problem.

>  > But, I also always belive that we will always have a fast and a slow
>>  update mechanism for the services which uses the ENUM mechanism. The
>>  definition of what is fast and what is slow is defined by the
>>  propagation time in DNS. What it is measured in seconds may vary.
>
>Agree. It just did not spell out clearly to me by reading the drafts.

It is not there, and that is what I want in the draft of Greg, i.e. 
the one about operation. That's why I wrote the first mail in this 
thread :-)

>  > Yes, but that mean updating the content of the NAPTR RR. And you
>>  should not forget that you in some cases want to change the party
>>  which host the NAPTR RR itself, without changing the content of the
>>  NAPTR itself.
>
>Could you explain in more detail how to change the party hosting the 
>NAPTR record?

You have in a parent domain an NS pointing to the server which hosts the NAPTR.

Example:

NeuStar has:

   1.e164.arpa. IN SOA ....
   7.6.5.4.3.2.1.e164.arpa. IN NS ns.number-authority.com.

Number Authority is responsible for 1-234-567-xxxx
They have:

   7.6.5.4.3.2.1.e164.arpa. IN SOA ...
   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NS ns.resolver-service.com.

I as a customer have the phone number 1-234-567-8901.
I have told number-authority that the one handling the NAPTRs for me 
is Resolver Service Inc.

Resolver service is responsible for among other things my number:

   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN SOA ....
   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NAPTR ....
   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NAPTR ....
   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NAPTR ....
   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NAPTR ....

If I am unhappy with the service of Resolver Service Inc, I tell 
Number Authority that my resolution is handled by some other 
authority, and Number Authority changes the NS which points to 
Resolver Service Inc.

    paf


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Jul 22 17:09:01 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25037
	for <enum-archive@odin.ietf.org>; Sat, 22 Jul 2000 17:09:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10415;
	Sat, 22 Jul 2000 17:07:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10390
	for <enum@ns.ietf.org>; Sat, 22 Jul 2000 17:07:45 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24730
	for <ENUM@ietf.org>; Sat, 22 Jul 2000 17:07:44 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id DCB8D8D; Sat, 22 Jul 2000 23:07:14 +0200 (MET DST)
Received: from [10.0.0.9] ([171.70.221.22])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA11016;
	Sat, 22 Jul 2000 23:07:10 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p0432040fb59fb7d21b6c@[10.0.0.9]>
In-Reply-To: 
 <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
References: 
 <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
Date: Sat, 22 Jul 2000 13:43:46 -0700
To: "Pfautz, Penn L, NNAD" <ppfautz@att.com>,
        Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: RE: [Enum] draft-ietf-enum-operation-00.txt
Cc: ENUM@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 12.43 -0400 00-07-21, Pfautz, Penn L, NNAD wrote:
>Just to clarify, changes to the LNP SMS are supposed to be reflected in
>carrier networks within 15 minutes of activation.

Can you explain what "LNP SMS" is? If you have the time and energy, 
both when you talk about a traditional telephony network, one based 
on SIP and one based on H.323 (if there is a difference).

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 06:47:16 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16040
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 06:47:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22016;
	Sun, 23 Jul 2000 06:45:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21987
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 06:45:44 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15712
	for <ENUM@ietf.org>; Sun, 23 Jul 2000 06:45:42 -0400 (EDT)
Received: from research.telcordia.com (uunet-14-232.cc.telcordia.com [128.96.14.232])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6NAj4R14593;
	Sun, 23 Jul 2000 06:45:05 -0400 (EDT)
Message-ID: <397ACCB2.69A2B88B@research.telcordia.com>
Date: Sun, 23 Jul 2000 06:45:06 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
CC: "Pfautz, Penn L, NNAD" <ppfautz@att.com>, ENUM@ietf.org
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
References: <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com> <p0432040fb59fb7d21b6c@[10.0.0.9]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

Patrik and Pfautz,

Though details may be a bit different, a more complete flow for porting a
number  is as follows:

(1) There is a lot of prep work that goes on between NPAC, the old (donor)
service provider, and the new (recipient) service provider before portingis
actually activated. At least they need to agree on a date and time for the
number to be ported.
(2) At the time of activation (let's say midnight today), the SMS sends a
message to NPAC, which then sends a message to all the effected LSMSs, which
then sends messages to the impacted Network Elements (SCPs that will be
handling the calls to the affected number).
(3) Once the update in SCPs are complete, the ported number is activated.
The maximum delay from the time that NPAC starts sending mesages (i.e.
midnight) is supposed to be 15 minutes.

Hence it is possible tha during those 15 minutes the old service provider
may have turned
off the service and the new service provider is not active yet.

If we are to provide comparable services on the IP network using ENUM, ENUM
may have to be subject to similar timing requirements for LNP updates. From
the discussion thus far, it seems that 15 minutes may be achieveable using
ENUM. It would be nice if DNS operations folks can provide some experimental
data to back this up.

Cheers,

--Hong


Patrik Fältström wrote:

> At 12.43 -0400 00-07-21, Pfautz, Penn L, NNAD wrote:
> >Just to clarify, changes to the LNP SMS are supposed to be reflected in
> >carrier networks within 15 minutes of activation.
>
> Can you explain what "LNP SMS" is? If you have the time and energy,
> both when you talk about a traditional telephony network, one based
> on SIP and one based on H.323 (if there is a difference).
>
>    paf


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 06:54:51 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17660
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 06:54:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22094;
	Sun, 23 Jul 2000 06:54:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22071
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 06:54:06 -0400 (EDT)
Received: from rip.psg.com (rip.psg.com [147.28.0.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17487
	for <enum@ietf.org>; Sun, 23 Jul 2000 06:54:03 -0400 (EDT)
Received: from randy by rip.psg.com with local (Exim 3.13 #1)
	id 13GJOU-000DGA-00; Sun, 23 Jul 2000 03:54:02 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Hong Liu <lhong@research.telcordia.com>
Cc: enum@ietf.org
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
References: <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
	<p0432040fb59fb7d21b6c@[10.0.0.9]>
	<397ACCB2.69A2B88B@research.telcordia.com>
Message-Id: <E13GJOU-000DGA-00@rip.psg.com>
Date: Sun, 23 Jul 2000 03:54:02 -0700
Content-Transfer-Encoding: 7bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

> it seems that 15 minutes may be achieveable using ENUM. It would be nice
> if DNS operations folks can provide some experimental data to back this
> up.

in the current environment, propagation of changed data in 15 minutes is a
very reasonable expectation.

but it would be nice (in the net.polite sense) if you used the knowledge to
pre-schedule you mention to not crank the ttl down until before it will be
needed.  i.e. use a long (e.g. an hour or four) ttl until the day before a
scheduled number port.

randy

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 06:57:44 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18294
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 06:57:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22174;
	Sun, 23 Jul 2000 06:57:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22146
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 06:57:19 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18206
	for <ENUM@ietf.org>; Sun, 23 Jul 2000 06:57:18 -0400 (EDT)
Received: from research.telcordia.com (uunet-14-232.cc.telcordia.com [128.96.14.232])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6NAuAR14803;
	Sun, 23 Jul 2000 06:56:11 -0400 (EDT)
Message-ID: <397ACF4C.C2B78C50@research.telcordia.com>
Date: Sun, 23 Jul 2000 06:56:12 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
CC: "Vaudreuil, Greg M (Greg)" <gregv@avaya.com>,
        "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>, ENUM@ietf.org
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
References: <6B57F36F4FF9D111B30A0008C7F4133703705290@exdal1.ons.octel.com> <p04320410b59fb8182bf7@[10.0.0.9]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

Hi, all,

I complete agree with Patrik on this, and I think we are getting there... on
classifying potential applications using ENUM according to the "fast" and "slow"
update required for a particular application. I really enjoy the discussions
thus far.

As an aside, I used  call forwarding as an example of fast update, not to
advocate that it should be done via ENUM directly. I agree that this should be
done in a network element closer to call control, such as a gatekeeper, an MGC
or a SIP proxy server. In fact, depending on implementation, it may not involved
ENUM at all. The call control function can do the substitution before querying
ENUM.

Cheers,

--Hong

Patrik Fältström wrote:

> At 13.13 -0500 00-07-21, Vaudreuil, Greg M (Greg) wrote:
> >I can agree that a 15 minute TTL for address assignment and service record
> >mapping is OK.  It is clearly not OK to wait 15 minutes for a
> >call-=forwarding action to take hold.  That should be nearly instantanious,
> >but again, I do not see that as an ENUM problem.
>
> ...and I would like to have text about this in your paper about enum
> operations. I.e. what is suitable for what, exactly like this thing
> you and I agree on.
>
>    paf


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 08:43:16 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14569
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 08:43:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23248;
	Sun, 23 Jul 2000 08:43:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23160
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 08:42:59 -0400 (EDT)
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14455
	for <ENUM@ietf.org>; Sun, 23 Jul 2000 08:42:55 -0400 (EDT)
Received: from computer.ix.netcom.com (pool-209-138-14-197.ipls.grid.net [209.138.14.197])
	by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id IAA04136;
	Sun, 23 Jul 2000 08:42:51 -0400 (EDT)
Message-Id: <4.3.1.2.20000723072337.00d90e70@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Sun, 23 Jul 2000 07:25:29 -0500
To: Hong Liu <lhong@research.telcordia.com>,
        Patrik 
 =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
Cc: "Vaudreuil, Greg M (Greg)" <gregv@avaya.com>,
        "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>, ENUM@ietf.org
In-Reply-To: <397ACF4C.C2B78C50@research.telcordia.com>
References: <6B57F36F4FF9D111B30A0008C7F4133703705290@exdal1.ons.octel.com>
 <p04320410b59fb8182bf7@[10.0.0.9]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org


>
>
>As an aside, I used  call forwarding as an example of fast update, not to
>advocate that it should be done via ENUM directly. I agree that this should be
>done in a network element closer to call control, such as a gatekeeper, an MGC
>or a SIP proxy server. In fact, depending on implementation, it may not 
>involved
>ENUM at all. The call control function can do the substitution before querying
>ENUM.
>
>Cheers,


This IMHO is clearly a function of the Call Control element ..aka the SIP 
proxy, gatekeeper etc.

ENUM is about Telephone Number to URL / service.


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 08:43:22 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14612
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 08:43:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23089;
	Sun, 23 Jul 2000 08:42:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23047
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 08:42:53 -0400 (EDT)
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14420
	for <ENUM@ietf.org>; Sun, 23 Jul 2000 08:42:50 -0400 (EDT)
Received: from computer.ix.netcom.com (pool-209-138-14-197.ipls.grid.net [209.138.14.197])
	by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id IAA27127;
	Sun, 23 Jul 2000 08:42:46 -0400 (EDT)
Message-Id: <4.3.1.2.20000723070731.00d91330@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Sun, 23 Jul 2000 07:11:15 -0500
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>,
        "Pfautz, Penn L, NNAD" <ppfautz@att.com>,
        Hong Liu <lhong@research.telcordia.com>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: RE: [Enum] draft-ietf-enum-operation-00.txt
Cc: ENUM@ietf.org
In-Reply-To: <p0432040fb59fb7d21b6c@[10.0.0.9]>
References: < <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
 <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA23048
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

At 01:43 PM 7/22/2000 -0700, Patrik Fältström wrote:
>At 12.43 -0400 00-07-21, Pfautz, Penn L, NNAD wrote:
>>Just to clarify, changes to the LNP SMS are supposed to be reflected in
>>carrier networks within 15 minutes of activation.
>
>Can you explain what "LNP SMS" is? If you have the time and energy, both 
>when you talk about a traditional telephony network, one based on SIP and 
>one based on H.323 (if there is a difference).
>
>   paf


LNP SMS is the Local Number Portability Service Management System. The 
system NeuStar operates to propagate Ported Numbers to Service Control 
Points within the North American IN.

The Service Requirements for Number Portability means that the change of 
carrier should be reflected within the Telephone system within 15 min.




 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 08:43:23 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14623
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 08:43:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23148;
	Sun, 23 Jul 2000 08:42:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23081
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 08:42:55 -0400 (EDT)
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14438
	for <ENUM@ietf.org>; Sun, 23 Jul 2000 08:42:52 -0400 (EDT)
Received: from computer.ix.netcom.com (pool-209-138-14-197.ipls.grid.net [209.138.14.197])
	by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id IAA24444;
	Sun, 23 Jul 2000 08:42:49 -0400 (EDT)
Message-Id: <4.3.1.2.20000723071157.00d90330@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Sun, 23 Jul 2000 07:22:15 -0500
To: Hong Liu <lhong@research.telcordia.com>,
        Patrik 
 =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
Cc: "Pfautz, Penn L, NNAD" <ppfautz@att.com>, ENUM@ietf.org
In-Reply-To: <397ACCB2.69A2B88B@research.telcordia.com>
References: <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
 <p0432040fb59fb7d21b6c@[10.0.0.9]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 06:45 AM 7/23/2000 -0400, Hong Liu wrote:
>Patrik and Pfautz,
>
>Though details may be a bit different, a more complete flow for porting a
>number  is as follows:
>
>(1) There is a lot of prep work that goes on between NPAC, the old (donor)
>service provider, and the new (recipient) service provider before portingis
>actually activated. At least they need to agree on a date and time for the
>number to be ported.

For those of you who need some translation...the NPAC is the Number 
Portability Administration Center operated by NeuStar Inc.

The function of the NPAC was mandated by order of the US FCC.


>Hence it is possible tha during those 15 minutes the old service provider
>may have turned
>off the service and the new service provider is not active yet.
>
>If we are to provide comparable services on the IP network using ENUM, ENUM
>may have to be subject to similar timing requirements for LNP updates. From
>the discussion thus far, it seems that 15 minutes may be achieveable using
>ENUM. It would be nice if DNS operations folks can provide some experimental
>data to back this up.


I completely agree here ... though I have considerable confidence DNS can 
achieve these goals we will need some limited operational testing on this 
issue and what is the level of optimal cacheing necessary for  DNS servers 
at the IPTel network edge.


We are coming very very close to discussion of administrative delegation 
issues in e164.arpa.

It is a useful reminder that A. these issues are out of scope for the WG. 
B. we do need to talk about them.

Some of us are working very hard to come up with some proposals in this 
area ...


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 08:43:25 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14648
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 08:43:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23206;
	Sun, 23 Jul 2000 08:43:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23155
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 08:42:58 -0400 (EDT)
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14457
	for <enum@ietf.org>; Sun, 23 Jul 2000 08:42:55 -0400 (EDT)
Received: from computer.ix.netcom.com (pool-209-138-14-197.ipls.grid.net [209.138.14.197])
	by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id IAA04442;
	Sun, 23 Jul 2000 08:42:54 -0400 (EDT)
Message-Id: <4.3.1.2.20000723073535.00d947b0@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Sun, 23 Jul 2000 07:44:04 -0500
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>,
        Hong Liu <lhong@research.telcordia.com>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
Cc: enum@ietf.org
In-Reply-To: <p04320402b59faceb8bf6@[10.0.0.9]>
References: <3977E0BC.6AB09145@research.telcordia.com>
 <4102273CEB77D211869200805FE6F5939EBD38@xch-phl-01.he.boeing.com>
 <p04320413b59d41b56e6b@[133.195.65.75]>
 <3977AB0A.4C19BF89@research.telcordia.com>
 <p04320409b59d794eaddb@[133.195.65.75]>
 <3977E0BC.6AB09145@research.telcordia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org


>
>Resolver service is responsible for among other things my number:
>
>   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN SOA ....
>   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NAPTR ....
>   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NAPTR ....
>   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NAPTR ....
>   1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NAPTR ....
>
>If I am unhappy with the service of Resolver Service Inc, I tell Number 
>Authority that my resolution is handled by some other authority, and 
>Number Authority changes the NS which points to Resolver Service Inc.


Or ... if I am an enterprise or a university etc I tell "Number Authority" 
to point to a NS under my direct control.

Which brings up the extremely sticky administrative problem ..which we 
cannot solve here ..which is what is the relationship between the 
"facilities based carrier" that issued the number in the first place and 
the "Resolver Service" or enterprise NS that is actually hosting the RR's.

The problem is the disconnect issue.  If PSTN service is terminated for a 
particular number ..the ENUM RR's must be _disconnected_ at the same time 
since the disconnected number will be quickly reissued to another 
individual....who may wish to provision ENUM services as well.


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 08:43:36 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14716
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 08:43:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23113;
	Sun, 23 Jul 2000 08:42:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23064
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 08:42:54 -0400 (EDT)
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14435
	for <enum@ietf.org>; Sun, 23 Jul 2000 08:42:51 -0400 (EDT)
Received: from computer.ix.netcom.com (pool-209-138-14-197.ipls.grid.net [209.138.14.197])
	by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id IAA29868
	for <enum@ietf.org>; Sun, 23 Jul 2000 08:42:53 -0400 (EDT)
Message-Id: <4.3.1.2.20000723072644.00d90d70@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Sun, 23 Jul 2000 07:29:34 -0500
To: enum@ietf.org
From: Richard Shockey <rshockey@ix.netcom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Enum] Final Reminder on Requirements..
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

	A reminder that I have placed our Requirements document into Last Call and 
the 2 week period is about to conclude.

	So one more time ...if you have any objections comments to this document 
speak up now.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-01.txt

I want to send this off to the AD's on Tuesday.



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 10:45:54 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13916
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 10:45:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24565;
	Sun, 23 Jul 2000 10:45:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24534
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 10:45:26 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13799
	for <ENUM@ietf.org>; Sun, 23 Jul 2000 10:45:26 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 98D0F193; Sun, 23 Jul 2000 16:44:56 +0200 (MET DST)
Received: from [10.0.0.2] ([171.70.221.21])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA18519;
	Sun, 23 Jul 2000 16:44:54 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com (Unverified)
Message-Id: <p0432040db5a0af423281@[10.0.0.14]>
In-Reply-To: <4.3.1.2.20000723070731.00d91330@127.0.0.1>
References: <
 <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
 <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
 <4.3.1.2.20000723070731.00d91330@127.0.0.1>
Date: Sun, 23 Jul 2000 07:21:00 -0700
To: Richard Shockey <rshockey@ix.netcom.com>,
        "Pfautz, Penn L, NNAD" <ppfautz@att.com>,
        Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: RE: [Enum] draft-ietf-enum-operation-00.txt
Cc: ENUM@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 07.11 -0500 00-07-23, Richard Shockey wrote:
>LNP SMS is the Local Number Portability Service Management System. 
>The system NeuStar operates to propagate Ported Numbers to Service 
>Control Points within the North American IN.
>
>The Service Requirements for Number Portability means that the 
>change of carrier should be reflected within the Telephone system 
>within 15 min.

Ok, then we talk about the North America situation again.

We don't in this wg. This is a wg which has to specify how to do this 
in all over the world.

How you solve things in North America have to be (if needed) written 
in a specific paper.

Looking at specific examples is not a bad thing, but it can not drive 
how things should be done in ENUM operations in the world.

    paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 10:46:01 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13947
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 10:46:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24475;
	Sun, 23 Jul 2000 10:45:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24445
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 10:45:21 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13781
	for <ENUM@ietf.org>; Sun, 23 Jul 2000 10:45:20 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 3274218C; Sun, 23 Jul 2000 16:44:51 +0200 (MET DST)
Received: from [10.0.0.2] ([171.70.221.21])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA18513;
	Sun, 23 Jul 2000 16:44:49 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com (Unverified)
Message-Id: <p0432040bb5a0ae2cf122@[10.0.0.14]>
In-Reply-To: <397ACCB2.69A2B88B@research.telcordia.com>
References: 
 <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
 <p0432040fb59fb7d21b6c@[10.0.0.9]>
 <397ACCB2.69A2B88B@research.telcordia.com>
Date: Sun, 23 Jul 2000 07:15:44 -0700
To: Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
Cc: "Pfautz, Penn L, NNAD" <ppfautz@att.com>, ENUM@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 06.45 -0400 00-07-23, Hong Liu wrote:
>If we are to provide comparable services on the IP network using ENUM, ENUM
>may have to be subject to similar timing requirements for LNP updates. From
>the discussion thus far, it seems that 15 minutes may be achieveable using
>ENUM. It would be nice if DNS operations folks can provide some experimental
>data to back this up.

I claim based on personal experience that if you have a TTL which is 
5 minutes, and update your record on a master in a cluster of 
authoritative servers which all handle NOTIFY, that the update will 
be done within 15 minutes.


    paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 10:46:11 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13999
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 10:46:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24441;
	Sun, 23 Jul 2000 10:45:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24412
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 10:45:18 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13765
	for <ENUM@ietf.org>; Sun, 23 Jul 2000 10:45:18 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 8737F18B; Sun, 23 Jul 2000 16:44:48 +0200 (MET DST)
Received: from [10.0.0.2] ([171.70.221.21])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA18510;
	Sun, 23 Jul 2000 16:44:46 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com (Unverified)
Message-Id: <p0432040ab5a0ada7d1cc@[10.0.0.14]>
In-Reply-To: <397ACCB2.69A2B88B@research.telcordia.com>
References: 
 <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
 <p0432040fb59fb7d21b6c@[10.0.0.9]>
 <397ACCB2.69A2B88B@research.telcordia.com>
Date: Sun, 23 Jul 2000 07:13:31 -0700
To: Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
Cc: "Pfautz, Penn L, NNAD" <ppfautz@att.com>, ENUM@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 06.45 -0400 00-07-23, Hong Liu wrote:
>Though details may be a bit different, a more complete flow for porting a
>number  is as follows:

In the US that is.

We can not make anything which is dependent on a terminology or 
process in one country.

What _can_ be created is "Enum operation in the countrycode 1", if we 
can not come up with more general descriptions.

Personally, I feel that Greg is writing general terms and conditions, 
and that is a good thing. We should continue to do that -- and then 
write specifics for each countrycode.

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 10:46:16 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14025
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 10:46:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24528;
	Sun, 23 Jul 2000 10:45:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24485
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 10:45:23 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13797
	for <enum@ietf.org>; Sun, 23 Jul 2000 10:45:23 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id BCEA418E; Sun, 23 Jul 2000 16:44:53 +0200 (MET DST)
Received: from [10.0.0.2] ([171.70.221.21])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA18516;
	Sun, 23 Jul 2000 16:44:51 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com (Unverified)
Message-Id: <p0432040cb5a0aeb310d3@[10.0.0.14]>
In-Reply-To: <E13GJOU-000DGA-00@rip.psg.com>
References: 
 <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
 <p0432040fb59fb7d21b6c@[10.0.0.9]>
 <397ACCB2.69A2B88B@research.telcordia.com> <E13GJOU-000DGA-00@rip.psg.com>
Date: Sun, 23 Jul 2000 07:18:23 -0700
To: Randy Bush <randy@psg.com>, Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
Cc: enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 03.54 -0700 00-07-23, Randy Bush wrote:
>but it would be nice (in the net.polite sense) if you used the knowledge to
>pre-schedule you mention to not crank the ttl down until before it will be
>needed.  i.e. use a long (e.g. an hour or four) ttl until the day before a
>scheduled number port.

Exactly. The normal way of changing things in DNS is:

- Use a long TTL, say "x"
- At time 3*x, turn down ttl to a short ttl, say "y"
- At some time, change content of the record
- Check after "y", 2*y and 3*y that things are ok
- Correct errors if needed
- Change TTL back to "x"

Normal values of x and y is 4-6 hours and 5 minutes (or shorter).

    paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 11:39:48 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27069
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 11:39:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25405;
	Sun, 23 Jul 2000 11:39:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25374
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 11:39:29 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26997
	for <enum@ietf.org>; Sun, 23 Jul 2000 11:39:28 -0400 (EDT)
Received: from research.telcordia.com (uunet-14-42.cc.telcordia.com [128.96.14.42])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6NFcLR21293;
	Sun, 23 Jul 2000 11:38:22 -0400 (EDT)
Message-ID: <397B116E.2A9E8EB4@research.telcordia.com>
Date: Sun, 23 Jul 2000 11:38:23 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
CC: Randy Bush <randy@psg.com>, enum@ietf.org
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
References: <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
	 <p0432040fb59fb7d21b6c@[10.0.0.9]>
	 <397ACCB2.69A2B88B@research.telcordia.com> <E13GJOU-000DGA-00@rip.psg.com> <p0432040cb5a0aeb310d3@[10.0.0.14]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

Patrik and Randy,

I really like the emails you both set out. It helped to clarify some concerns of
mine. I was told that it was what our DNS folks did when my company changed its
name from Bellcore to Telcordia. Your emails just confirmed that it is indeed a
common practice.

Cheers,

--Hong

Patrik Fältström wrote:

> At 03.54 -0700 00-07-23, Randy Bush wrote:
> >but it would be nice (in the net.polite sense) if you used the knowledge to
> >pre-schedule you mention to not crank the ttl down until before it will be
> >needed.  i.e. use a long (e.g. an hour or four) ttl until the day before a
> >scheduled number port.
>
> Exactly. The normal way of changing things in DNS is:
>
> - Use a long TTL, say "x"
> - At time 3*x, turn down ttl to a short ttl, say "y"
> - At some time, change content of the record
> - Check after "y", 2*y and 3*y that things are ok
> - Correct errors if needed
> - Change TTL back to "x"
>
> Normal values of x and y is 4-6 hours and 5 minutes (or shorter).
>
>     paf


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 11:57:00 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00936
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 11:57:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25535;
	Sun, 23 Jul 2000 11:56:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25505
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 11:56:43 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00855
	for <ENUM@ietf.org>; Sun, 23 Jul 2000 11:56:42 -0400 (EDT)
Received: from research.telcordia.com (uunet-14-42.cc.telcordia.com [128.96.14.42])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6NFu5R21688;
	Sun, 23 Jul 2000 11:56:05 -0400 (EDT)
Message-ID: <397B1597.34AD019E@research.telcordia.com>
Date: Sun, 23 Jul 2000 11:56:07 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
CC: Richard Shockey <rshockey@ix.netcom.com>,
        "Pfautz, Penn L, NNAD" <ppfautz@att.com>, ENUM@ietf.org
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
References: <
	 <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
	 <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
	 <4.3.1.2.20000723070731.00d91330@127.0.0.1> <p0432040db5a0af423281@[10.0.0.14]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

Patrik,

You brought up a very good point. We should NOT constrain ourselves to
North America only in ENUM. I expanded on Penn's email just to clarify
what that "15 minutes" means so that others will not get the idea that
LSMS is updated continuously and every update has to be done within the
15 minute delay bound. It was NOT my intent to get ENUM into the North
America LNP solution. On the other hand, it was a good example to show
that there are timing requirements regarding telephone number updates in
PSTN. Other countries may have a different scheme that has different
timing requirements. I think it would be good that people from other
countries speak up. It would be nice if ENUM can satisfy most, if not
all, of them. That will make ENUM a true solution all over the world and
it will make interworking easier.

The discussion thus far reminds me a bit of what was going on when
SIGTRAN first started when people talked about transporting SS7 over IP.
Timing requirements from SS7 did play an important role to justify a new
protocol than TCP for that purpose. The bottom line: PSTN number
administration folks ("Bell Heads") and IETF ENUM folks ("Net Heads")
need to communicate since interworking is inevitable, unless you want to
restrict ENUM to serve the IP side only.

--Hong

Patrik Fältström wrote:

> At 07.11 -0500 00-07-23, Richard Shockey wrote:
> >LNP SMS is the Local Number Portability Service Management System.
> >The system NeuStar operates to propagate Ported Numbers to Service
> >Control Points within the North American IN.
> >
> >The Service Requirements for Number Portability means that the
> >change of carrier should be reflected within the Telephone system
> >within 15 min.
>
> Ok, then we talk about the North America situation again.
>
> We don't in this wg. This is a wg which has to specify how to do this
> in all over the world.
>
> How you solve things in North America have to be (if needed) written
> in a specific paper.
>
> Looking at specific examples is not a bad thing, but it can not drive
> how things should be done in ENUM operations in the world.
>
>     paf
>
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 11:59:16 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01464
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 11:59:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25707;
	Sun, 23 Jul 2000 11:58:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25631
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 11:58:50 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01346
	for <ENUM@ietf.org>; Sun, 23 Jul 2000 11:58:49 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 72691F5; Sun, 23 Jul 2000 17:58:20 +0200 (MET DST)
Received: from [10.0.0.2] ([171.70.221.21])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA22430;
	Sun, 23 Jul 2000 17:58:17 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p04320407b5a0c66aa32c@[10.0.0.2]>
In-Reply-To: <397B1597.34AD019E@research.telcordia.com>
References: <	
 <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>	
 <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>	
 <4.3.1.2.20000723070731.00d91330@127.0.0.1>
 <p0432040db5a0af423281@[10.0.0.14]>
 <397B1597.34AD019E@research.telcordia.com>
Date: Sun, 23 Jul 2000 08:58:26 -0700
To: Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
Cc: Richard Shockey <rshockey@ix.netcom.com>,
        "Pfautz, Penn L, NNAD" <ppfautz@att.com>, ENUM@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 11.56 -0400 00-07-23, Hong Liu wrote:
>On the other hand, it was a good example to show
>that there are timing requirements regarding telephone number updates in
>PSTN.

Agreed. It is good bringing up examples.

>Other countries may have a different scheme that has different
>timing requirements. I think it would be good that people from other
>countries speak up.

They should definitely speak up (or at least while we write the 
operational spec check that we don't anything which is not valid in 
their model).

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 12:39:49 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11003
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 12:39:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26289;
	Sun, 23 Jul 2000 12:39:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26264
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 12:39:30 -0400 (EDT)
Received: from rip.psg.com (rip.psg.com [147.28.0.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10933
	for <enum@ietf.org>; Sun, 23 Jul 2000 12:39:28 -0400 (EDT)
Received: from randy by rip.psg.com with local (Exim 3.13 #1)
	id 13GOmm-0003wK-00; Sun, 23 Jul 2000 09:39:28 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Cc: enum@ietf.org
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
References: <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
	<p0432040fb59fb7d21b6c@[10.0.0.9]>
	<397ACCB2.69A2B88B@research.telcordia.com>
	<E13GJOU-000DGA-00@rip.psg.com>
	<p0432040cb5a0aeb310d3@[10.0.0.14]>
Message-Id: <E13GOmm-0003wK-00@rip.psg.com>
Date: Sun, 23 Jul 2000 09:39:28 -0700
Content-Transfer-Encoding: 7bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

> Exactly. The normal way of changing things in DNS is:
> - Use a long TTL, say "x"
> - At time 3*x, turn down ttl to a short ttl, say "y"
> - At some time, change content of the record
> - Check after "y", 2*y and 3*y that things are ok
> - Correct errors if needed
> - Change TTL back to "x"
> Normal values of x and y is 4-6 hours and 5 minutes (or shorter).

apologies that i was not sufficiently explicit for the non dns hacks here.

note that some implementations ignore ttl of less than five minutes.

and, from what little i know of this application, i would think x of a day
would be fine and make more net.friends which you could use when you crank
it down to y <= 15 minutes.

randy

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 16:22:17 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04962
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 16:22:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28431;
	Sun, 23 Jul 2000 16:19:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28403
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 16:19:17 -0400 (EDT)
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04311
	for <ENUM@ietf.org>; Sun, 23 Jul 2000 16:19:15 -0400 (EDT)
Received: from computer.ix.netcom.com ([209.138.9.11])
	by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id QAA17903;
	Sun, 23 Jul 2000 16:18:30 -0400 (EDT)
Message-Id: <4.3.1.2.20000723151022.00d9b9a0@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Sun, 23 Jul 2000 15:19:26 -0500
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>,
        Hong Liu <lhong@research.telcordia.com>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
Cc: "Pfautz, Penn L, NNAD" <ppfautz@att.com>, ENUM@ietf.org
In-Reply-To: <p0432040ab5a0ada7d1cc@[10.0.0.14]>
References: <397ACCB2.69A2B88B@research.telcordia.com>
 <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
 <p0432040fb59fb7d21b6c@[10.0.0.9]>
 <397ACCB2.69A2B88B@research.telcordia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA28404
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

At 07:13 AM 7/23/2000 -0700, Patrik Fältström wrote:
>At 06.45 -0400 00-07-23, Hong Liu wrote:
>>Though details may be a bit different, a more complete flow for porting a
>>number  is as follows:
>
>In the US that is.
>
>We can not make anything which is dependent on a terminology or process in 
>one country.


Exactly ...examples we have made of process in the US are just that 
..examples. Useful for reference purposes only.

We [ I ] should apologize for the often North American centric views that 
get expressed on this list from time to time.  Its the only solid frame of 
reference some of us have.


>What _can_ be created is "Enum operation in the countrycode 1", if we can 
>not come up with more general descriptions.
>
>Personally, I feel that Greg is writing general terms and conditions, and 
>that is a good thing. We should continue to do that -- and then write 
>specifics for each countrycode.

I agree again...Greg is certainly on the right track. Operational issues of 
the ENUM delegation will IMHO be specific to each country.

For instance ..in many countries telephone numbers are directly issued to 
subscribers, who then may choose their carrier of choice unlike North 
America and most Asian countries where TN's are issued by carriers to 
subscribers...its a subtle difference but rather important in the countries 
where this is common.


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 16:26:42 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05904
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 16:26:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28525;
	Sun, 23 Jul 2000 16:26:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28498
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 16:26:17 -0400 (EDT)
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05803
	for <enum@ietf.org>; Sun, 23 Jul 2000 16:26:16 -0400 (EDT)
Received: from computer.ix.netcom.com (pool-209-138-9-11.ipls.grid.net [209.138.9.11])
	by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id QAA24057;
	Sun, 23 Jul 2000 16:26:11 -0400 (EDT)
Message-Id: <4.3.1.2.20000723152051.00d4c8a0@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Sun, 23 Jul 2000 15:26:49 -0500
To: Randy Bush <randy@psg.com>,
        Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=
  <paf@cisco.com>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
Cc: enum@ietf.org
In-Reply-To: <E13GOmm-0003wK-00@rip.psg.com>
References: <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
 <p0432040fb59fb7d21b6c@[10.0.0.9]>
 <397ACCB2.69A2B88B@research.telcordia.com>
 <E13GJOU-000DGA-00@rip.psg.com>
 <p0432040cb5a0aeb310d3@[10.0.0.14]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 09:39 AM 7/23/2000 -0700, Randy Bush wrote:
> > Exactly. The normal way of changing things in DNS is:
> > - Use a long TTL, say "x"
> > - At time 3*x, turn down ttl to a short ttl, say "y"
> > - At some time, change content of the record
> > - Check after "y", 2*y and 3*y that things are ok
> > - Correct errors if needed
> > - Change TTL back to "x"
> > Normal values of x and y is 4-6 hours and 5 minutes (or shorter).
>
>apologies that i was not sufficiently explicit for the non dns hacks here.
>
>note that some implementations ignore ttl of less than five minutes.
>
>and, from what little i know of this application, i would think x of a day
>would be fine and make more net.friends which you could use when you crank
>it down to y <= 15 minutes.

Randy makes an unspoken point here that we all should consider as we move 
forward and might be a topic for our General Discussion in Pittsburgh.

Once we begin some operational testing of the ENUM scheme...we are IMHO 
going to need some well written Best Current Practice / Implementers Guide 
type documents in the future and that will require some rethinking of the 
current WG charter..... help from the DNS hack community will be most 
welcome !




 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 16:31:01 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06844
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 16:31:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28763;
	Sun, 23 Jul 2000 16:30:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28740
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 16:30:48 -0400 (EDT)
Received: from rip.psg.com (rip.psg.com [147.28.0.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06772
	for <enum@ietf.org>; Sun, 23 Jul 2000 16:30:46 -0400 (EDT)
Received: from randy by rip.psg.com with local (Exim 3.13 #1)
	id 13GSOb-0000r9-00; Sun, 23 Jul 2000 13:30:45 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Richard Shockey <rshockey@ix.netcom.com>
Cc: enum@ietf.org
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
References: <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
	<p0432040fb59fb7d21b6c@[10.0.0.9]>
	<397ACCB2.69A2B88B@research.telcordia.com>
	<E13GJOU-000DGA-00@rip.psg.com>
	<p0432040cb5a0aeb310d3@[10.0.0.14]>
	<4.3.1.2.20000723152051.00d4c8a0@127.0.0.1>
Message-Id: <E13GSOb-0000r9-00@rip.psg.com>
Date: Sun, 23 Jul 2000 13:30:45 -0700
Content-Transfer-Encoding: 7bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

> Once we begin some operational testing of the ENUM scheme...we are IMHO
> going to need some well written Best Current Practice / Implementers Guide
> type documents in the future and that will require some rethinking of the
> current WG charter..... help from the DNS hack community will be most
> welcome !

google for "pittsburgh sushi" has some hits.  so you might get at least some
cooperation. :-)

but, to be honest, paf knows the dns stuff more than well enough for this
application. 

randy

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 17:11:03 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15435
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 17:11:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29135;
	Sun, 23 Jul 2000 17:09:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29112
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 17:09:21 -0400 (EDT)
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15044
	for <enum@ietf.org>; Sun, 23 Jul 2000 17:09:19 -0400 (EDT)
Received: from computer.ix.netcom.com (pool-209-138-9-11.ipls.grid.net [209.138.9.11])
	by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA19774
	for <enum@ietf.org>; Sun, 23 Jul 2000 17:09:18 -0400 (EDT)
Message-Id: <4.3.1.2.20000723154254.00cfae70@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Sun, 23 Jul 2000 15:44:35 -0500
To: enum@ietf.org
From: Richard Shockey <rshockey@ix.netcom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Enum] FYI  VPIM use of ENUM
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org


In case you all had not seen these..these documents discuss the use of ENUM 
in the VPIM context.

#############


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Voice Profile for Internet Mail Working 
Group of the IETF.

	Title		: Voice Message Routing Service
	Author(s)	: G. Vaudreuil
	Filename	: draft-ietf-vpim-routing-00.txt
	Pages		: 10
	Date		: 20-Jul-00
	
Voice messaging is traditionally addressed using telephone number
addressing. This document describes two techniques for routing voice
messages based on a telephone number.  The VPIM Directory service
provides a mechanism to map between a telephone number and a VPIM
email address and confirm that the address is both valid and the
assocaited with the intended recipient.  However this service will
take time become widely deployed in the nearest term.  This document
also describes a more limited send-and-pray service useful simply to
route and deliver message using only the existing DNS mail routing
facilies, the ENUM telephone number resolution service, and a set of
pre-defined address creation rules.
Please send comments on this document to the VPIM working group
mailing list <vpim@lists.neystadt.org>

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-vpim-routing-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Voice Profile for Internet Mail Working 
Group of the IETF.

	Title		: Voice Messaging Directory Service
	Author(s)	: A. Brown, G. Vaudreuil
	Filename	: draft-ietf-vpim-vpimdir-00.txt
	Pages		: 11
	Date		: 20-Jul-00
	
This document provides details of the VPIM directory service.  The
service provides the email address of the recipient given a telephone
number.  It optionally provides the spoken name of the recipient and
the media capabilities of the recipient.
Please send comments on this document to the VPIM working group
mailing list <vpim@lists.neystadt.org>

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-vpim-vpimdir-00.txt



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:19:33 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22274
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:19:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01843;
	Sun, 23 Jul 2000 22:19:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01814
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:19:02 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22154
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:19:01 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-14.cc.telcordia.com [128.96.13.14])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6O2IOR06367;
	Sun, 23 Jul 2000 22:18:25 -0400 (EDT)
Message-ID: <397BA771.2187BF72@research.telcordia.com>
Date: Sun, 23 Jul 2000 22:18:25 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Richard Shockey <rshockey@ix.netcom.com>
CC: enum@ietf.org, arbrown@nortelnetworks.com, paf@cisco.com
Subject: Re: [Enum] Final Reminder on Requirements..
References: <4.3.1.2.20000723072644.00d90d70@127.0.0.1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

Richard, Anne and Patrik,

I will sending out a number of comments on the requirements document in subsequent
emails. First off, I would like to commend Anne for writing this important document. I
hope that my comments may help make the document better.

To faciliate the discussions on the list, I will send multiple emails, each addresses
a specific section or sections of the document. Some of them are just for
clarifications, others are related to the discussions we had in the last few days. I
apologize in advance if I miss anything that has already been resolved on the list, or
just by ignorance of DNS in general.

On a separate thread, I also will send out a sequence of comments regarding Patrik's
document draft-ietf-enum-e164-dns-02.txt. I guess it is also going through IESG last
call.

Best regards,

--Hong


Richard Shockey wrote:

>         A reminder that I have placed our Requirements document into Last Call and
> the 2 week period is about to conclude.
>
>         So one more time ...if you have any objections comments to this document
> speak up now.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-01.txt
>
> I want to send this off to the AD's on Tuesday.
>
>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Please Note New Contact Information:
>
> Richard Shockey
> Shockey Consulting LLC
> 5237 Sutherland
> St. Louis, MO 63109
> Voice 314.503.0640
> eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
> INTERNET Mail & IFAX : rshockey@ix.netcom.com
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:19:34 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22286
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:19:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01885;
	Sun, 23 Jul 2000 22:19:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01857
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:19:24 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22213
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:19:18 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-14.cc.telcordia.com [128.96.13.14])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6O2IiR06370;
	Sun, 23 Jul 2000 22:18:45 -0400 (EDT)
Message-ID: <397BA785.BCA4D6FF@research.telcordia.com>
Date: Sun, 23 Jul 2000 22:18:45 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: enum@ietf.org, arbrown@nortelnetworks.com
CC: rshockey@ix.netcom.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Enum] draft-ietf-enum-rqmts-01.txt: Section 3.3
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

Anne,

I have some questions regarding Section 3.3. In the second paragraph,

"The system SHOULD provide access to capabilities relevant to the
 telephone number in question.  The retrieval or negotiation of
 capabilities will depend on the outcome of the rescap work or work
 done in other groups. "

I may miss the early discussions. Could you explain when this would be
useful and why it is not in conflict with Section 3.2, when it says that
"The retrieval or negotiation of capabilities is beyond the scope of
the system."?

Thanks for the clarification,

--Hong




_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:20:00 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22388
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:19:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01938;
	Sun, 23 Jul 2000 22:19:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01913
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:19:38 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22308
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:19:36 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-14.cc.telcordia.com [128.96.13.14])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6O2IxR06373;
	Sun, 23 Jul 2000 22:18:59 -0400 (EDT)
Message-ID: <397BA795.2FFEB02B@research.telcordia.com>
Date: Sun, 23 Jul 2000 22:19:01 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: arbrown@nortelnetworks.com
CC: rshockey@ix.netcom.com, enum@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Enum] draft-ietf-enum-rqmts-01.txt: Section 3.5
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

Anne,

I have a number of questions regarding Section 3.5 of
draft-ietf-enum-rqmts-01.txt.

In the first paragraph,

"The protocol SHOULD also provide the ability to support corporate
numbering plan or competitive directory service  providers under
separate root domains.  It SHOULD NOT require an  additional centralized
administrator beyond that required for the
existing telephone number system."

The first sentence is a good one, but I am not sure how it relates to
"e164.arpa" being the only root domain discussed on the ENUM list so
far. Are we going to allow other root domains besides e164.arpa? I just
want to know whether this is what ENUM WG has in mind.

The second sentence is a bit too restricted to me, maybe I did not
understand it correctly. It seems to me that it implies that the
administration of E.164 numbers for both PSTN and ENUM be ONE entity,
which may not be what we want in the long run. I agree it is important
to keep the numbering space consistent across the two networks, however,
synchronization of changes may be achieved through other means instead
of requiring a single administrator.

In addition, it seems that these two requirements are not quite
consistent with each other, unless we assume the same administrator for
multiple root domains.

In the second paragraph,

"...In any case, the subscriber or enterprise is the ultimate authority
for service provisioning."

I guess this is confusing, given what is being done in PSTN today, at
least for individual subscribers. Do you mean "service provisioning" as
"self service provisioning", say through the web page? Will the change
be propagated in the ENUM hierarchy right away ("fast" update) or just
be logged into the system, which will be put into the system by the
administrator later on?

Thanks for the clarification,

--Hong

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:20:12 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22457
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:20:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01982;
	Sun, 23 Jul 2000 22:19:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01955
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:19:50 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22350
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:19:48 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-14.cc.telcordia.com [128.96.13.14])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6O2JBR06376;
	Sun, 23 Jul 2000 22:19:12 -0400 (EDT)
Message-ID: <397BA7A0.88DBC33F@research.telcordia.com>
Date: Sun, 23 Jul 2000 22:19:13 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: arbrown@nortelnetworks.com
CC: rshockey@ix.netcom.com, enum@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Enum] draft-ietf-enum-rqmts-01.txt: Section 3.6
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

Anne,

Section 3.6 deals with ENUM updates. Given the discussions on the list
in the last few days on draft-ietf-enum-operations-00.txt, it seems that
this section needs to be rewritten to reflect the outcome of the
discussion. For example, the "almost simultaneous update" may not be
possible due to DNS caching and TTL values.

I don't know what is the most efficient way to do this. Can other folks
jump in with suggestions?

--Hong

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:20:25 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22526
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:20:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02029;
	Sun, 23 Jul 2000 22:20:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02004
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:20:02 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22419
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:20:01 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-14.cc.telcordia.com [128.96.13.14])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6O2JOR06379;
	Sun, 23 Jul 2000 22:19:25 -0400 (EDT)
Message-ID: <397BA7AE.3A2655CA@research.telcordia.com>
Date: Sun, 23 Jul 2000 22:19:26 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: arbrown@nortelnetworks.com
CC: rshockey@ix.netcom.com, enum@ietf.org
References: <397B9979.505CD34F@research.telcordia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Enum] Re: draft-ietf-enum-rqmts-01.txt: Sections 3.7 and 3.10
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

Anne,

Sections 3.7 and 3.10 are related, so I raise my concerns about them in one
email.

It seems that Section 3.7 is too brief, in the sense that if 3.10 has
numbers on the performance of the system, then the timeout shall be set
consistent with that. Do you mean the response timeout set by the ENUM
client or among ENUM NSs? Do we need to consider timing requirements from
PSTN when the ENUM client is a switch?

I would like to know if the requirements set in Section 3.10 can be met by
the DNS technology or not. Maybe Patrik or Randy can comment on this. My
intent is that I don't want to tax the DNS with too strict requirements. On
the other hand, I am wondering if these numbers are derived from current SCP
requirements in the PSTN (I recall that the SCP has more stringent time
requirements on response time, but I need to double check with my
colleagues). Again, I do NOT intend to put all PSTN requirements on ENUM,
but just as a reference point.

A related point that is related to this is availability and/or reliability.
I would like to see it addressed in the ENUM requirements document, too.

--Hong


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:20:34 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22576
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:20:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02097;
	Sun, 23 Jul 2000 22:20:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02072
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:20:21 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22498
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:20:19 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-14.cc.telcordia.com [128.96.13.14])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6O2JgR06382;
	Sun, 23 Jul 2000 22:19:43 -0400 (EDT)
Message-ID: <397BA7C0.BA61035B@research.telcordia.com>
Date: Sun, 23 Jul 2000 22:19:44 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: arbrown@nortelnetworks.com, rshockey@ix.netcom.com, enum@ietf.org
References: <397B9979.505CD34F@research.telcordia.com> <397B9F03.CFB9934A@research.telcordia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Enum] Re: draft-ietf-enum-rqmts-01.txt: Section 3.12
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

Anne,

Section 3.12 "Privacy" says,

"The system MUST allow the owner of the telephone number to control  the
information which prospective callers may receive. "

I am not sure if this is within the scope of ENUM, since Section 3.17
says that service logic is outside of the scope.  You may want to
implement this feature in the server that ENUM points to, or in a call
control entity after the results are returned, but before the results
are passed back to the caller (e.g. caller-ID blocking). It is also
inconsistent with Section 3.4, which says information filtering based on
caller qualification is not required for ENUM.

--Hong



_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:20:54 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22671
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:20:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02174;
	Sun, 23 Jul 2000 22:20:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02149
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:20:33 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22559
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:20:31 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-14.cc.telcordia.com [128.96.13.14])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6O2JsR06385;
	Sun, 23 Jul 2000 22:19:55 -0400 (EDT)
Message-ID: <397BA7CC.6358DD7E@research.telcordia.com>
Date: Sun, 23 Jul 2000 22:19:56 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: arbrown@nortelnetworks.com
CC: rshockey@ix.netcom.com, enum@ietf.org
References: <397B9979.505CD34F@research.telcordia.com> <397B9F03.CFB9934A@research.telcordia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Enum] Re: draft-ietf-enum-rqmts-01.txt: Sections 3.13 and 3.14, and Section 4
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

Anne,

These two sections deals with ENUM security.  I would suggest that they
be put in Section 4 instead. In addition, I would like to see some text
on how DNSSEC is going to be used in these context, since DNSSEC is
mentioned in Section 5 of the protocol document
enum-ietf-enum-e164-dns-02.txt. It would be nice to harmonize these two
documents on security.

I would like to solicit experts of DNSSEC to comment whether
requirements 3.13 and 3.14 can be fulfilled by DNSSEC.

Patrik, are we assuming that DNSSEC is the only security mechanism
required for ENUM?

--Hong


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:21:39 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22856
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:21:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02355;
	Sun, 23 Jul 2000 22:21:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02322
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:21:17 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22763
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:21:16 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-14.cc.telcordia.com [128.96.13.14])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6O2KeR06388;
	Sun, 23 Jul 2000 22:20:41 -0400 (EDT)
Message-ID: <397BA7FA.F7859F71@research.telcordia.com>
Date: Sun, 23 Jul 2000 22:20:42 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: paf@cisco.com
CC: enum@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Enum] draft-ietf-enum-e164-dns-02.txt: RR types
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

Hi, all,

draft-ietf-enum-e164-dns-02.txt only mentions using NAPTR RR for ENUM.
Does this mean NAPTR is the default RR type for ENUM?  In passing, I
noticed that people also talked about SRV and DNAME RRs in the context
of ENUM, also in the recent operation draft
draft-ietf-enum-operation-00.txt.

I would like to get a sense on where we are in terms of using multiple
RR types for the purpose of ENUM, or whether rough consensus has been
reached on this topic. If so, it would nice to provide some guidelines
to what RR to use in what situations.

--Hong


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:21:42 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22881
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:21:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02409;
	Sun, 23 Jul 2000 22:21:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02378
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:21:30 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22810
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:21:29 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-14.cc.telcordia.com [128.96.13.14])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6O2KrR06391;
	Sun, 23 Jul 2000 22:20:54 -0400 (EDT)
Message-ID: <397BA807.2979705C@research.telcordia.com>
Date: Sun, 23 Jul 2000 22:20:55 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: paf@cisco.com
CC: enum@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Enum] draft-ietf-enum-e164-dns-02.txt: NAPTR algorithm
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

Patrik,

In draft-ietf-enum-e164-dns-02.txt, there are a number of places that
mention using the normalized E.164 number (with a + as the first char
followed by digits) as input to the NAPTR algorithm. It would be nice if
you could add some text explaining what the NAPTR algorithm means. May
be simply a pointer to the text in the NAPTR RR spec will suffice.

Cheers,

--Hong


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:21:59 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22957
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:21:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02485;
	Sun, 23 Jul 2000 22:21:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02441
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:21:45 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22893
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:21:44 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-14.cc.telcordia.com [128.96.13.14])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6O2L9R06400;
	Sun, 23 Jul 2000 22:21:10 -0400 (EDT)
Message-ID: <397BA811.86B5D41D@research.telcordia.com>
Date: Sun, 23 Jul 2000 22:21:05 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: paf@cisco.com
CC: enum@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Enum] draft-ietf-enum-e164-dns-02.txt: REGEXP problems in examples
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

Patrik,

I have a couple of questions in draft-ietf-enum-e164-dns-02.txt:

(1) 3.2.3 Example 3

   $ORIGIN 6.4.e164.arpa.
   * IN NAPTR 100 10 "u" "sip+E2U"
"!^+46(.*)$!ldap://ldap.example.se/cn=0$1!" .

Do you mean

   $ORIGIN 6.4.e164.arpa.
   * IN NAPTR 100 10 "u" "sip+E2U"
"!^+46(.*)$!ldap://ldap.example.se/cn=0\1!i" .

I understand you want to feed the trailing digits of the input to an
LDAP server, with 0 prepended. Maybe I misunderstood the NAPTR RR
syntax.

(2) In Appendix A. Scenario, in many cases, you use flag "a" in an NAPTR
RR. Do you mean "u" instead?

Thanks in advanced for the clarification,

--Hong


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:22:16 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23034
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:22:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02538;
	Sun, 23 Jul 2000 22:22:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02513
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:22:05 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22982
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:22:03 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-14.cc.telcordia.com [128.96.13.14])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6O2LRR06406;
	Sun, 23 Jul 2000 22:21:28 -0400 (EDT)
Message-ID: <397BA829.92C8D0B0@research.telcordia.com>
Date: Sun, 23 Jul 2000 22:21:29 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: paf@cisco.com
CC: enum@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Enum] draft-ietf-enum-e164-dns-02.txt: E2U and URI
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

Patrik,

I noticed the following changes made in draft-enum-e164-dns-02.txt, as
compared to draft-enum-e164-dns-00.txt:
(1) A new service type, E2U, is defined for ENUM, instead of using "N2R"

(2) The URIs returned are now in the regexp field of NAPTR, instead of
in the replacement field.

I see these are good changes that have addressed the two concerns I
raised regarding draft-enum-e164-dns-00.txt in an earlier email. I still
have some questions regarding these changes:
(A) What is the guideline for defining a new service type in NAPTR? What
I am trying to find out is whether there will be coordinations between
what we try to do in ENUM and what the URN group try to do in evolving
NAPTR. Is IANA involved in this process at all?
(B) The use of regexp field is a two-sided sword. It is powerful but is
also error prone if not used with care. It would help if you can
enumerate some well-defined templates in the document for the common
cases when using this mechanism .

Cheers,

--Hong


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:22:46 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23169
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:22:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02599;
	Sun, 23 Jul 2000 22:22:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02569
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:22:17 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23031
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:22:15 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-14.cc.telcordia.com [128.96.13.14])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6O2LeR06498;
	Sun, 23 Jul 2000 22:21:40 -0400 (EDT)
Message-ID: <397BA836.4CF65215@research.telcordia.com>
Date: Sun, 23 Jul 2000 22:21:42 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: paf@cisco.com
CC: enum@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Enum] draft-ietf-enum-e164-dns-02.txt: IANA Considerations
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

Patrik,

I noticed a completely new section in draft-enum-e164-dns-02.txt as
compared to draft-enum-e164-dns-00.txt:

"4. IANA considerations

   IANA is to create the E164.ARPA domain in the ARPA zone, and
   delegate names in the zone to parties according to the ITU
   recommendation E.164. The names allocated should be hierarchically
   allocated according to the description in this document, and the
   codes assigned in the E.164 recommendation by ITU.

   Delegations should be done after Expert Review, and the IESG will
   appoint a designated expert. "

Since this is a new section (and a non-trivial one), I would like to
start some discussions on the list before the IESG last call period
expires. Would you please clarify the intent of this section? I
personally have some concerns, but I would like to understand your
points first.

Thanks in advance for the clarifications,

--Hong



_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:31:42 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25843
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:31:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03018;
	Sun, 23 Jul 2000 22:30:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02991
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:30:29 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25001
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:30:27 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id E73B4109; Mon, 24 Jul 2000 04:29:57 +0200 (MET DST)
Received: from [10.0.0.2] ([171.70.221.21])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id EAA01534;
	Mon, 24 Jul 2000 04:29:55 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p04320428b5a1599fffed@[10.0.0.2]>
In-Reply-To: <397BA807.2979705C@research.telcordia.com>
References: <397BA807.2979705C@research.telcordia.com>
Date: Sun, 23 Jul 2000 19:28:16 -0700
To: Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Cc: enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: NAPTR algorithm
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 22.20 -0400 00-07-23, Hong Liu wrote:
>It would be nice if
>you could add some text explaining what the NAPTR algorithm means.

In the algorithm you use when you get back a rewrite rule in a NAPTR 
RR. Especially when you get back a non-terminal NAPTR RR.

See NAPTR specification for examples.

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:31:51 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25952
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:31:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02979;
	Sun, 23 Jul 2000 22:30:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02950
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:30:22 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24936
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:30:20 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 4249711A; Mon, 24 Jul 2000 04:29:51 +0200 (MET DST)
Received: from [10.0.0.2] ([171.70.221.21])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id EAA01531;
	Mon, 24 Jul 2000 04:29:48 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p04320427b5a15944ea84@[10.0.0.2]>
In-Reply-To: <397BA7FA.F7859F71@research.telcordia.com>
References: <397BA7FA.F7859F71@research.telcordia.com>
Date: Sun, 23 Jul 2000 19:25:21 -0700
To: Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Cc: enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: RR types
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 22.20 -0400 00-07-23, Hong Liu wrote:
>draft-ietf-enum-e164-dns-02.txt only mentions using NAPTR RR for ENUM.

Remember that ENUM is _only_ about fetching a URI given an E.164 
number. We only need NAPTR RRs for that feature.

Other RRs can be used for solving other problems than the one 
specified in the wg charter.

This has been explain several times...see mailing list archive for 
more extensive explanations.

    paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:32:03 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26085
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:32:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03067;
	Sun, 23 Jul 2000 22:30:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03032
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:30:36 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25086
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:30:35 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id A0C7C13A; Mon, 24 Jul 2000 04:30:05 +0200 (MET DST)
Received: from [10.0.0.2] ([171.70.221.21])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id EAA01608;
	Mon, 24 Jul 2000 04:30:02 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p04320429b5a159c40897@[10.0.0.2]>
In-Reply-To: <397BA811.86B5D41D@research.telcordia.com>
References: <397BA811.86B5D41D@research.telcordia.com>
Date: Sun, 23 Jul 2000 19:29:45 -0700
To: Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Cc: enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: REGEXP problems in examples
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 22.21 -0400 00-07-23, Hong Liu wrote:
>(1) 3.2.3 Example 3
>
>    $ORIGIN 6.4.e164.arpa.
>    * IN NAPTR 100 10 "u" "sip+E2U"
>"!^+46(.*)$!ldap://ldap.example.se/cn=0$1!" .
>
>Do you mean
>
>    $ORIGIN 6.4.e164.arpa.
>    * IN NAPTR 100 10 "u" "sip+E2U"
>"!^+46(.*)$!ldap://ldap.example.se/cn=0\1!i" .
>
>I understand you want to feed the trailing digits of the input to an
>LDAP server, with 0 prepended. Maybe I misunderstood the NAPTR RR
>syntax.

Yes. I have a mistake in the example. It should be \1 and not $1. The 
grammar in the NAPTR spec is:

    backref      = "\" 1POS_DIGIT

>(2) In Appendix A. Scenario, in many cases, you use flag "a" in an NAPTR
>RR. Do you mean "u" instead?

Yes. This is a mistake of mine still having "a" in those. It is a 
leftover because I have not found them all...sigh...hope to find them 
all next round of changes.

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:45:03 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28906
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:45:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03439;
	Sun, 23 Jul 2000 22:43:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03357
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:43:34 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28588
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:43:32 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 38FA9A7; Mon, 24 Jul 2000 04:43:03 +0200 (MET DST)
Received: from [10.0.0.2] ([171.70.221.21])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id EAA02776;
	Mon, 24 Jul 2000 04:42:54 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p0432042bb5a15b8f746a@[10.0.0.2]>
In-Reply-To: <397BA829.92C8D0B0@research.telcordia.com>
References: <397BA829.92C8D0B0@research.telcordia.com>
Date: Sun, 23 Jul 2000 19:39:57 -0700
To: Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Cc: enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: E2U and URI
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 22.21 -0400 00-07-23, Hong Liu wrote:
>I noticed the following changes made in draft-enum-e164-dns-02.txt, as
>compared to draft-enum-e164-dns-00.txt:
>(1) A new service type, E2U, is defined for ENUM, instead of using "N2R"

Correct. That was because this wg wanted to have that.

>(2) The URIs returned are now in the regexp field of NAPTR, instead of
>in the replacement field.

It must be according to the NAPTR spec. I missed that in early 
revisions. Michael Mealling pointed that out to me.

>(A) What is the guideline for defining a new service type in NAPTR? What
>I am trying to find out is whether there will be coordinations between
>what we try to do in ENUM and what the URN group try to do in evolving
>NAPTR. Is IANA involved in this process at all?

Specified in RFC 2483.

>(B) The use of regexp field is a two-sided sword. It is powerful but is
>also error prone if not used with care. It would help if you can
>enumerate some well-defined templates in the document for the common
>cases when using this mechanism .

You can always do misspellings in all different kind of RRs, which 
all point to catastrophic results. What do you think the impact is 
when someone at NSI misspelled the hostname of a nameserver for a 
ccTLD? Pretty bad that aswell...

    paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:53:53 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00849
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:53:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03582;
	Sun, 23 Jul 2000 22:52:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03559
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:52:42 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00574
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:52:41 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id A931FA7; Mon, 24 Jul 2000 04:52:11 +0200 (MET DST)
Received: from [10.0.0.2] ([171.70.221.21])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id EAA03392;
	Mon, 24 Jul 2000 04:52:09 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p0432042db5a15e000716@[10.0.0.2]>
In-Reply-To: <397BA795.2FFEB02B@research.telcordia.com>
References: <397BA795.2FFEB02B@research.telcordia.com>
Date: Sun, 23 Jul 2000 19:44:57 -0700
To: Hong Liu <lhong@research.telcordia.com>, arbrown@nortelnetworks.com
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: Re: [Enum] draft-ietf-enum-rqmts-01.txt: Section 3.5
Cc: rshockey@ix.netcom.com, enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 22.19 -0400 00-07-23, Hong Liu wrote:
>"The protocol SHOULD also provide the ability to support corporate
>numbering plan or competitive directory service  providers under
>separate root domains.  It SHOULD NOT require an  additional centralized
>administrator beyond that required for the
>existing telephone number system."
>
>The first sentence is a good one, but I am not sure how it relates to
>"e164.arpa" being the only root domain discussed on the ENUM list so
>far. Are we going to allow other root domains besides e164.arpa? I just
>want to know whether this is what ENUM WG has in mind.

What has been talked about in the corridors is the ability for 
individual companies in their private resolution use a different top 
domain for the resolution than E164.ARPA. The same algorithms.

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:53:53 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00860
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:53:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03543;
	Sun, 23 Jul 2000 22:52:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03518
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:52:26 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00510
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:52:24 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 06A2187; Mon, 24 Jul 2000 04:51:55 +0200 (MET DST)
Received: from [10.0.0.2] ([171.70.221.21])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id EAA03385;
	Mon, 24 Jul 2000 04:51:45 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p0432042cb5a15d08cd10@[10.0.0.2]>
In-Reply-To: <397BA836.4CF65215@research.telcordia.com>
References: <397BA836.4CF65215@research.telcordia.com>
Date: Sun, 23 Jul 2000 19:43:34 -0700
To: Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Cc: enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: IANA Considerations
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 22.21 -0400 00-07-23, Hong Liu wrote:
>Since this is a new section (and a non-trivial one), I would like to
>start some discussions on the list before the IESG last call period
>expires. Would you please clarify the intent of this section? I
>personally have some concerns, but I would like to understand your
>points first.

That IANA is to register that domain in the ARPA zone. It is up to 
IANA to come up with exactly how that is done. My personal guess is 
that IANA will delegate e164.arpa to ITU and let ITU take care of the 
subdelegation. IANA is though not part of the IETF and we can not 
tell IANA to do something more specific than this.

The actual wording in the I-D is verified with various parties, and 
especially IAB which is the party which instructed this wg to use 
this specific domain.

So, there is MUCH more thinking behind the text already than just 
words from my head. I am happy to answer more questions about it, but 
I would not think it will change much, due to the consensus which 
exists in IAB etc about the text. ITU is also informed, as is DoC and 
ICANN, and everyone belive this is the path that should be taken.

I can explain more in Pittsburgh.

    paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 22:54:04 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00917
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 22:54:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03629;
	Sun, 23 Jul 2000 22:52:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03600
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 22:52:47 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00604
	for <enum@ietf.org>; Sun, 23 Jul 2000 22:52:45 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 8ABC6AD; Mon, 24 Jul 2000 04:52:16 +0200 (MET DST)
Received: from [10.0.0.2] ([171.70.221.21])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id EAA03395;
	Mon, 24 Jul 2000 04:52:14 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p0432042eb5a15e91292b@[10.0.0.2]>
In-Reply-To: <397BA7AE.3A2655CA@research.telcordia.com>
References: <397B9979.505CD34F@research.telcordia.com>
 <397BA7AE.3A2655CA@research.telcordia.com>
Date: Sun, 23 Jul 2000 19:51:43 -0700
To: Hong Liu <lhong@research.telcordia.com>, arbrown@nortelnetworks.com
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: [Enum] Re: draft-ietf-enum-rqmts-01.txt: Sections 3.7 and 3.10
Cc: rshockey@ix.netcom.com, enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 22.19 -0400 00-07-23, Hong Liu wrote:
>I would like to know if the requirements set in Section 3.10 can be met by
>the DNS technology or not. Maybe Patrik or Randy can comment on this.

I don't see any problems with the values in the requirements 
document. You should though remember that DNS is a very distributed 
database, and doesn't use mirroring the same way as most Telco 
systems do. I.e. in DNS you always go to the source for knowing the 
answer (then you can cache the response of course). This means that 
you will get a fresh response all the time, and no mirroring 
(pre-loading of your database) is needed. On the other hand, if you 
don't run your DNS servers correctly, noone will be able to find 
_your_ ENUM NAPTRs.

Example, in Sweden I have seen during tests that about 20% of the 
zones in DNS is in some way not correctly set up, but, you will still 
get a response quite fast (less than 0.5 seconds + RTT) because at 
least one of the NS in the parent zone do respond.

Also, note that I don't feel these operational problems being too bad 
for ENUM, as people _have_ to be better on running their DNS, or 
their email, webserver, electronic commerce, telephone system etc etc 
will not work. DNS is the source of all routing on the Internet, 
regardless of whether the data can be found in DNS, in LDAP or via 
HTTP.

The problem we have is that DNS maybe is "too stable" and works "too 
good" even though the configuration is wrong.

Just like AppleTalk on Localtalk. IP on top of Ethernet is better in 
some sense, as if a cable is broken, it will not work. Localtalk sort 
of works even though it is not terminated correctly for example.

    paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 23:04:19 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03197
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 23:04:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04059;
	Sun, 23 Jul 2000 23:02:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04031
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 23:02:53 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02866
	for <enum@ietf.org>; Sun, 23 Jul 2000 23:02:51 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 93ACF8D; Mon, 24 Jul 2000 05:02:22 +0200 (MET DST)
Received: from [10.0.0.2] ([171.70.221.21])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id FAA03879;
	Mon, 24 Jul 2000 05:02:09 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p04320430b5a160869ee3@[10.0.0.2]>
In-Reply-To: <397BA7CC.6358DD7E@research.telcordia.com>
References: <397B9979.505CD34F@research.telcordia.com>
 <397B9F03.CFB9934A@research.telcordia.com>
 <397BA7CC.6358DD7E@research.telcordia.com>
Date: Sun, 23 Jul 2000 19:57:03 -0700
To: Hong Liu <lhong@research.telcordia.com>, arbrown@nortelnetworks.com
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: [Enum] Re: draft-ietf-enum-rqmts-01.txt: Sections 3.13 and 3.14,
 and Section 4
Cc: rshockey@ix.netcom.com, enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 22.19 -0400 00-07-23, Hong Liu wrote:
>In addition, I would like to see some text
>on how DNSSEC is going to be used in these context, since DNSSEC is
>mentioned in Section 5 of the protocol document
>enum-ietf-enum-e164-dns-02.txt.

When you use DNSSEC you can verify responses. With transaction 
signatures you can authenticate the peer which is sending the query. 
Information in DNS is public data, so if you need authenticated 
access (true such) you should protect the data in some other 
database, like LDAP, ensure that strong bind is needed, and handle 
authentication there.

    paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 23 23:04:23 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03228
	for <enum-archive@odin.ietf.org>; Sun, 23 Jul 2000 23:04:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04107;
	Sun, 23 Jul 2000 23:03:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04072
	for <enum@ns.ietf.org>; Sun, 23 Jul 2000 23:03:08 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02924
	for <enum@ietf.org>; Sun, 23 Jul 2000 23:03:06 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 68EBBA7; Mon, 24 Jul 2000 05:02:37 +0200 (MET DST)
Received: from [10.0.0.2] ([171.70.221.21])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id FAA03884;
	Mon, 24 Jul 2000 05:02:27 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p04320431b5a16108bda9@[10.0.0.2]>
In-Reply-To: <397BA7CC.6358DD7E@research.telcordia.com>
References: <397B9979.505CD34F@research.telcordia.com>
 <397B9F03.CFB9934A@research.telcordia.com>
 <397BA7CC.6358DD7E@research.telcordia.com>
Date: Sun, 23 Jul 2000 19:59:14 -0700
To: Hong Liu <lhong@research.telcordia.com>, arbrown@nortelnetworks.com
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: [Enum] Re: draft-ietf-enum-rqmts-01.txt: Sections 3.13 and 3.14,
 and Section 4
Cc: rshockey@ix.netcom.com, enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 22.19 -0400 00-07-23, Hong Liu wrote:
>Patrik, are we assuming that DNSSEC is the only security mechanism
>required for ENUM?

Yes, for fetching URIs.

I really want someone talking about how stuff is stored in an LDAP 
database, and maybe a beginning of this is in some documents that 
Greg has written (for example in the VPIM wg). What is there is 
though not sufficient to solve problems that DNS can not resolve 
already, it is unclear what query to issue etc etc.

So, I urge someone to write something about the following (fast) 
resolution mechanism:

   - E.164 -> Domainname
   - NAPTR RRs are fetched from DNS
   - LDAP URI is selected
   - LDAP is used for fetching accurate information
   - Whatever should happen happens

      paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 24 09:10:22 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21742
	for <enum-archive@odin.ietf.org>; Mon, 24 Jul 2000 09:10:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16752;
	Mon, 24 Jul 2000 09:09:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16721
	for <enum@ns.ietf.org>; Mon, 24 Jul 2000 09:09:00 -0400 (EDT)
Received: from mail2.itu.int (mail2.itu.ch [156.106.192.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21529
	for <enum@ietf.org>; Mon, 24 Jul 2000 09:08:57 -0400 (EDT)
Received: by mail2.itu.ch with Internet Mail Service (5.5.2650.21)
	id <M5YT8ZPL>; Mon, 24 Jul 2000 15:04:40 +0200
Message-ID: <DA5558CC09AED311ABE10000778D757F4C2E37@mailsrv.itu.ch>
From: "Shaw, Robert" <Robert.Shaw@itu.int>
To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <paf@cisco.com>,
        Hong Liu
	 <lhong@research.telcordia.com>
Cc: enum@ietf.org
Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: IANA Consideratio
	ns
Date: Mon, 24 Jul 2000 15:08:25 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

> That IANA is to register that domain in the ARPA zone. It is up to 
> IANA to come up with exactly how that is done. My personal guess is 
> that IANA will delegate e164.arpa to ITU and let ITU take care of the 
> subdelegation. IANA is though not part of the IETF and we can not 
> tell IANA to do something more specific than this.
>
> So, there is MUCH more thinking behind the text already than just 
> words from my head. I am happy to answer more questions about it, but 
> I would not think it will change much, due to the consensus which 
> exists in IAB etc about the text. ITU is also informed, as is DoC and 
> ICANN, and everyone belive this is the path that should be taken.
> 

To be clear, I think a more accurate statement is that the ITU 
related groups will be having now some additional discussion and 
probably need clarification on this issue before we have a specific 
consensus "belief" (although we've certainly noted the IAB view). 

This is the second time I've heard in the last couple of weeks that 
IANA (mmmm...ICANN) could "delegate" e164.arpa to the ITU for 
subdelegation redelegation and we certainly already recognized that 
this is one possible (and perhaps even reasonable) scenario but we 
need to reserve judgment until we've had a little more time 
to discuss in the relevant task force here. In other words, we're 
going to look at other scenarios including other trees...

One fly in the ointment is the reality that ICANN/IANA are 
basically under the patronage of US DoC for what looks like
many years to come so that introduces a certain nervousness over
a tree rooted in .arpa. If the ICANN thing folds (certainly in 
the realm of possibility), it looks to me that IANA currently 
folds with it. 
 
Not wanting to impede anything but when I hear "yes, we 
consulted with one ITU member state's government agency" for 
management of this international address space, I've got to 
admit that my absurdity alarm goes off (even if admire the 
relevant staff of DoC...).. 

And even if you look at this purely on a US domestic level, am I 
the only one who sees that if the one US agency responsible for 
regulatory numbering issues is not the same agency that is involved 
in DNS, doesn't that make you wonder whether we're already 
on shaky ground? (and in for considerable process evolution?)

yes, I know some of you think that's a feature and not a bug...

Bob
--
Robert Shaw <robert.shaw@itu.int>
ITU Internet Strategy and Policy Advisor
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 24 10:02:37 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01120
	for <enum-archive@odin.ietf.org>; Mon, 24 Jul 2000 10:02:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18013;
	Mon, 24 Jul 2000 10:01:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17982
	for <enum@ns.ietf.org>; Mon, 24 Jul 2000 10:01:43 -0400 (EDT)
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00980
	for <enum@ietf.org>; Mon, 24 Jul 2000 10:01:42 -0400 (EDT)
Received: from computer.ix.netcom.com (pool-209-138-8-226.ipls.grid.net [209.138.8.226])
	by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id KAA11839;
	Mon, 24 Jul 2000 10:01:34 -0400 (EDT)
Message-Id: <4.3.1.2.20000724080521.00cbb460@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 24 Jul 2000 08:14:48 -0500
To: Hong Liu <lhong@research.telcordia.com>, enum@ietf.org,
        arbrown@nortelnetworks.com
From: Richard Shockey <rshockey@ix.netcom.com>
In-Reply-To: <397BA785.BCA4D6FF@research.telcordia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Enum] Re: draft-ietf-enum-rqmts-01.txt: Section 3.3
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 10:18 PM 7/23/2000 -0400, Hong Liu wrote:
>Anne,

Let me try and answer some of these questions since Anne is on leave and if 
we need to make some clarifications to the text we need to settle this 
pretty quickly since I have a message to the IESG ready to post on the 
results of last call.


>I have some questions regarding Section 3.3. In the second paragraph,
>
>"The system SHOULD provide access to capabilities relevant to the
>  telephone number in question.  The retrieval or negotiation of
>  capabilities will depend on the outcome of the rescap work or work
>  done in other groups. "
>
>I may miss the early discussions. Could you explain when this would be
>useful and why it is not in conflict with Section 3.2, when it says that
>"The retrieval or negotiation of capabilities is beyond the scope of
>the system."?

It would be useful to eventually retrieve capabilities of end points before 
"call setup", however the methodology of retrieval and the syntax for the 
presentation of capability data is out of scope for ENUM and is the task of 
the RESCAP WG.

We have to assume that many endpoints will have multiple or limited 
capabilities for   processing  text, voice, video etc. We cannot assume 
that terminal devices will be simple "black phones".




>Thanks for the clarification,
>
>--Hong
>



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 24 10:02:51 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01150
	for <enum-archive@odin.ietf.org>; Mon, 24 Jul 2000 10:02:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18094;
	Mon, 24 Jul 2000 10:01:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18032
	for <enum@ns.ietf.org>; Mon, 24 Jul 2000 10:01:50 -0400 (EDT)
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01002
	for <enum@ietf.org>; Mon, 24 Jul 2000 10:01:49 -0400 (EDT)
Received: from computer.ix.netcom.com (pool-209-138-8-226.ipls.grid.net [209.138.8.226])
	by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id KAA31834;
	Mon, 24 Jul 2000 10:01:39 -0400 (EDT)
Message-Id: <4.3.1.2.20000724082626.00cbded0@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 24 Jul 2000 08:30:37 -0500
To: Hong Liu <lhong@research.telcordia.com>, arbrown@nortelnetworks.com
From: Richard Shockey <rshockey@ix.netcom.com>
Cc: enum@ietf.org, Greg Vaudreuil <gregv@lucent.com>
In-Reply-To: <397BA7AE.3A2655CA@research.telcordia.com>
References: <397B9979.505CD34F@research.telcordia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Enum] Re: draft-ietf-enum-rqmts-01.txt: Sections 3.7 and 3.10
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org


>
>
>I would like to know if the requirements set in Section 3.10 can be met by
>the DNS technology or not. Maybe Patrik or Randy can comment on this. My
>intent is that I don't want to tax the DNS with too strict requirements. On
>the other hand, I am wondering if these numbers are derived from current SCP
>requirements in the PSTN (I recall that the SCP has more stringent time
>requirements on response time, but I need to double check with my
>colleagues). Again, I do NOT intend to put all PSTN requirements on ENUM,
>but just as a reference point.
>
>A related point that is related to this is availability and/or reliability.
>I would like to see it addressed in the ENUM requirements document, too.


You have raised enough points here to push me into holding off going to 
IESG last call for a little while.

Let me see what I can do to have some clarifications put into the document.

Greg V and Anne Brown have worked together on many of these 
documents..perhaps he can clarify some of the language and then resubmit it 
on Anne's behalf. [ Greg is this possible? Do you support this? ]


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 24 10:02:58 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01178
	for <enum-archive@odin.ietf.org>; Mon, 24 Jul 2000 10:02:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18064;
	Mon, 24 Jul 2000 10:01:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18024
	for <enum@ns.ietf.org>; Mon, 24 Jul 2000 10:01:49 -0400 (EDT)
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00995
	for <enum@ietf.org>; Mon, 24 Jul 2000 10:01:48 -0400 (EDT)
Received: from computer.ix.netcom.com (pool-209-138-8-226.ipls.grid.net [209.138.8.226])
	by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id KAA21524;
	Mon, 24 Jul 2000 10:01:37 -0400 (EDT)
Message-Id: <4.3.1.2.20000724081606.00c9fb20@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 24 Jul 2000 08:25:17 -0500
To: Hong Liu <lhong@research.telcordia.com>, arbrown@nortelnetworks.com
From: Richard Shockey <rshockey@ix.netcom.com>
Cc: enum@ietf.org
In-Reply-To: <397BA795.2FFEB02B@research.telcordia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Enum] Re: draft-ietf-enum-rqmts-01.txt: Section 3.5
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 10:19 PM 7/23/2000 -0400, Hong Liu wrote:
>Anne,
>
>I have a number of questions regarding Section 3.5 of
>draft-ietf-enum-rqmts-01.txt.
>
>In the first paragraph,
>
>"The protocol SHOULD also provide the ability to support corporate
>numbering plan or competitive directory service  providers under
>separate root domains.  It SHOULD NOT require an  additional centralized
>administrator beyond that required for the
>existing telephone number system."
>
>The first sentence is a good one, but I am not sure how it relates to
>"e164.arpa" being the only root domain discussed on the ENUM list so
>far. Are we going to allow other root domains besides e164.arpa? I just
>want to know whether this is what ENUM WG has in mind.

Well companies have private _dialing_ plans for their endpoints and the 
ENUM scheme can accommodate those through the use of a separate resolution 
servers such as e164.bigco.com.  We can assume that proxies and gateways 
will have sufficient intelligence to distinguish between internal dialing 
and external e164 connections.

There may be a need for a separate ID on this subject in the future.


>The second sentence is a bit too restricted to me, maybe I did not
>understand it correctly. It seems to me that it implies that the
>administration of E.164 numbers for both PSTN and ENUM be ONE entity,
>which may not be what we want in the long run. I agree it is important
>to keep the numbering space consistent across the two networks, however,
>synchronization of changes may be achieved through other means instead
>of requiring a single administrator.


Yes I agree this is a touch unclear but the intent is that from the Country 
Code NS delegation multiple and competitive resolution service providers 
can exist. This does _not_ change or alter the actual e164 plan in any way.


>In addition, it seems that these two requirements are not quite
>consistent with each other, unless we assume the same administrator for
>multiple root domains.
>
>In the second paragraph,
>
>"...In any case, the subscriber or enterprise is the ultimate authority
>for service provisioning."
>
>I guess this is confusing, given what is being done in PSTN today, at
>least for individual subscribers. Do you mean "service provisioning" as
>"self service provisioning", say through the web page?

Yes ..though there is going to be some tricky AAA to deal with here.



>Will the change
>be propagated in the ENUM hierarchy right away ("fast" update) or just
>be logged into the system, which will be put into the system by the
>administrator later on?

Changes to RR's should be propagated as soon as possible given the nature 
of DNS itself ..earlier messages from Randy I think made this clear. That 
said we do need to engage in some operational testing of the environment.


>Thanks for the clarification,
>
>--Hong



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 24 13:26:57 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02614
	for <enum-archive@odin.ietf.org>; Mon, 24 Jul 2000 13:26:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21576;
	Mon, 24 Jul 2000 13:26:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21544
	for <enum@ns.ietf.org>; Mon, 24 Jul 2000 13:26:04 -0400 (EDT)
Received: from exchange.chaos.com ([206.5.17.8])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02299
	for <enum@ietf.org>; Mon, 24 Jul 2000 13:25:33 -0400 (EDT)
Received: from [216.168.250.182] by exchange.netmagic.com (NTMail 5.06.0014/NT2627.00.5ef58ba0) with ESMTP id iuxfaaaa for enum@ietf.org; Mon, 24 Jul 2000 13:24:18 -0400
Message-Id: <4.3.2.7.2.20000724130344.00b70750@mail.netmagic.com>
X-Sender: amr@mail.netmagic.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 24 Jul 2000 13:24:16 -0400
To: "Shaw, Robert" <Robert.Shaw@itu.int>,
        "'Patrik 
 =?iso-8859-1?Q?F=E4ltstr=F6m=27?=" <paf@cisco.com>,
        Hong Liu <lhong@research.telcordia.com>
From: "A.M. Rutkowski" <amr@netmagic.com>
Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: IANA
  Consideratio ns
Cc: enum@ietf.org
In-Reply-To: <DA5558CC09AED311ABE10000778D757F4C2E37@mailsrv.itu.ch>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_865632393==_.ALT"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

--=====================_865632393==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Bob,

>To be clear, I think a more accurate statement is that the ITU
>related groups will be having now some additional discussion and
>probably need clarification on this issue before we have a specific
>consensus "belief" (although we've certainly noted the IAB view).

Do you have any pointers to the relevant groups and
timing?

>Not wanting to impede anything but when I hear "yes, we
>consulted with one ITU member state's government agency" for
>management of this international address space, I've got to
>admit that my absurdity alarm goes off (even if admire the

I'm not aware that Carl Malamud and Marshall T Rose
consulted with the ITU or set off absurdity alarms
when TPC.INT was implemented.  What's different here?

best,
tony
--=====================_865632393==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>Hi Bob,<br>
<br>
<blockquote type=cite cite>To be clear, I think a more accurate statement
is that the ITU <br>
related groups will be having now some additional discussion and <br>
probably need clarification on this issue before we have a specific 
<br>
consensus &quot;belief&quot; (although we've certainly noted the IAB
view). </font></blockquote><br>
Do you have any pointers to the relevant groups and<br>
timing?<br>
<br>
<blockquote type=cite cite><font size=3>Not wanting to impede anything
but when I hear &quot;yes, we <br>
consulted with one ITU member state's government agency&quot; for <br>
management of this international address space, I've got to <br>
admit that my absurdity alarm goes off (even if admire the
</blockquote><br>
I'm not aware that Carl Malamud and Marshall T Rose<br>
consulted with the ITU or set off absurdity alarms <br>
when TPC.INT was implemented.&nbsp; What's different here?<br>
<br>
best,<br>
tony</font></html>

--=====================_865632393==_.ALT--


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Tue Jul 25 06:39:46 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25263
	for <enum-archive@odin.ietf.org>; Tue, 25 Jul 2000 06:39:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10622;
	Tue, 25 Jul 2000 06:38:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10593
	for <enum@ns.ietf.org>; Tue, 25 Jul 2000 06:38:31 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24816;
	Tue, 25 Jul 2000 06:38:29 -0400 (EDT)
Message-Id: <200007251038.GAA24816@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: enum@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 25 Jul 2000 06:38:29 -0400
Subject: [Enum] I-D ACTION:draft-ietf-enum-e164-gstn-np-00.txt
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title		: Number Portability in the GSTN: An Overview
	Author(s)	: M. Foster, T. McGarry, J. Yu
	Filename	: draft-ietf-enum-e164-gstn-np-00.txt
	Pages		: 34
	Date		: 24-Jul-00
	
This document provides an overview of E.164 telephone number
portability (NP) in the Global Switched Telephone Network (GSTN).
There are three types of number portability: service provider number
portability (SPNP), location portability, and service portability.
Service provider portability, the focus of the present draft, is a
regulatory imperative in many countries seeking to liberalize local
telephony service competition, by enabling end-users to retain pre-
existing telephone numbers while changing service providers.
Implementation of NP within national GSTN entails potentially
significant changes to numbering administration, network element
signaling, call routing and processing, billing, service management,
and other functions.  NP changes the fundamental nature of a dialed
E.164 number from a hierarchical physical routing address to a
virtual address, thereby requiring the transparent translation of
the later to the former.  In addition, there are various regulatory
constraints which establish relevant parameters for NP
implementation, most of which are not network technology specific.
Consequently, the implementation of NP behavior consistent with
applicable regulatory constraints, as well as the need for
interoperation with the existing GSTN NP implementations, are
relevant topics for numerous areas of IP telephony work-in-progress
at IETF.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-gstn-np-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-enum-e164-gstn-np-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-enum-e164-gstn-np-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000724142655.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-enum-e164-gstn-np-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-enum-e164-gstn-np-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000724142655.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Tue Jul 25 20:40:12 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07913
	for <enum-archive@odin.ietf.org>; Tue, 25 Jul 2000 20:40:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA23748;
	Tue, 25 Jul 2000 20:39:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA23717
	for <enum@ns.ietf.org>; Tue, 25 Jul 2000 20:39:16 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07687
	for <enum@ietf.org>; Tue, 25 Jul 2000 20:39:15 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-71.cc.telcordia.com [128.96.13.71])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6Q0cYR23969;
	Tue, 25 Jul 2000 20:38:35 -0400 (EDT)
Message-ID: <397E330C.629C7D60@research.telcordia.com>
Date: Tue, 25 Jul 2000 20:38:37 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Richard Shockey <rshockey@ix.netcom.com>
CC: arbrown@nortelnetworks.com, enum@ietf.org
References: <4.3.1.2.20000724081606.00c9fb20@127.0.0.1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Enum] Re: draft-ietf-enum-rqmts-01.txt: Section 3.5
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

Hi, Richard,

Thanks for the clarification. I still have some concerns. Please see my
comments below.

--Hong

Richard Shockey wrote:

> At 10:19 PM 7/23/2000 -0400, Hong Liu wrote:
> >Anne,
> >
> >I have a number of questions regarding Section 3.5 of
> >draft-ietf-enum-rqmts-01.txt.
> >
> >In the first paragraph,
> >
> >"The protocol SHOULD also provide the ability to support corporate
> >numbering plan or competitive directory service  providers under
> >separate root domains.  It SHOULD NOT require an  additional centralized
> >administrator beyond that required for the
> >existing telephone number system."
> >
> >The first sentence is a good one, but I am not sure how it relates to
> >"e164.arpa" being the only root domain discussed on the ENUM list so
> >far. Are we going to allow other root domains besides e164.arpa? I just
> >want to know whether this is what ENUM WG has in mind.
>
> Well companies have private _dialing_ plans for their endpoints and the
> ENUM scheme can accommodate those through the use of a separate resolution
> servers such as e164.bigco.com.  We can assume that proxies and gateways
> will have sufficient intelligence to distinguish between internal dialing
> and external e164 connections.
>

I assume what you said is the ENUM can also be used for private numbering
plans. If that is case, then the requirements on 3.18 should be either removed
or reworded:

"3.18    E.164 Numbers

   The system is not responsible for returning information on private
   numbering plans and non-E.164 numbers.  The system is responsible
   for returning information on 1-800 and other legitimate E.164
   numbers. "

I think the problem here is whether ENUM should be restricted to be used as a
public resolution service only or can also be used as an enterprise solution.
Technically, it should be the same in terms of populating the RRs for the phone
numbers within an enterprise. Either way, I think we need to clarify that.

On the other hand, if we do allow other root domains than e164.arpa, then we
need to make that clear in draft-ietf-enum-e164-dns-02.txt that e.164.arpa is
used as A root, not THE root for ENUM.

>
> There may be a need for a separate ID on this subject in the future.
>
> >The second sentence is a bit too restricted to me, maybe I did not
> >understand it correctly. It seems to me that it implies that the
> >administration of E.164 numbers for both PSTN and ENUM be ONE entity,
> >which may not be what we want in the long run. I agree it is important
> >to keep the numbering space consistent across the two networks, however,
> >synchronization of changes may be achieved through other means instead
> >of requiring a single administrator.
>
> Yes I agree this is a touch unclear but the intent is that from the Country
> Code NS delegation multiple and competitive resolution service providers
> can exist. This does _not_ change or alter the actual e164 plan in any way.
>

I would suggest that we either remove the second sentence or reword it as
something like "How that is accomplished is a national matter and is outside of
the scope of ENUM." I know that I am punting the issue since there are problems
that need to be addressed here if multiple roots are allowed.

I am curious about how domain names are being administered today. Do we have a
single administrator for, say the .com domain, or multiple administrators? If
the answer is the latter, then how that is being done may help to shed light on
the problem we are facing in ENUM. I would appreciate if someone can answer my
question here.

>
> >In addition, it seems that these two requirements are not quite
> >consistent with each other, unless we assume the same administrator for
> >multiple root domains.
> >
> >In the second paragraph,
> >
> >"...In any case, the subscriber or enterprise is the ultimate authority
> >for service provisioning."
> >
> >I guess this is confusing, given what is being done in PSTN today, at
> >least for individual subscribers. Do you mean "service provisioning" as
> >"self service provisioning", say through the web page?
>
> Yes ..though there is going to be some tricky AAA to deal with here.

I see. If that is the intent, then I would suggest that the text be changed to
something like "In any case, the subscriber or enterprise is the ultimate
authority for any changes regarding the RRs of their numbers. The system MAY
provide means for a subscriber or enterprise to modify the RRs of their numbers
by themselves, with appropriate security mechanisms."

The intent here is to be more specific about service provisioning since moving
a subtree from one service provider to another may involved more than just
changing the values in the parent RRs. Please see my separate response to
Patrik's email.

>
> >Will the change
> >be propagated in the ENUM hierarchy right away ("fast" update) or just
> >be logged into the system, which will be put into the system by the
> >administrator later on?
>
> Changes to RR's should be propagated as soon as possible given the nature
> of DNS itself ..earlier messages from Randy I think made this clear. That
> said we do need to engage in some operational testing of the environment.

I am not arguing against the capability of DNS to propagate changes, as was
addressed in Randy's email. The issue I would like to raise here is whether the
changes a subscriber made is a change request, which will be logged and then
executed by the service provider in a well-defined later time or the changes
are written into the DNS zone file immediately. In PSTN, we use the former. I
just don't know which one will be used for ENUM.


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Tue Jul 25 20:40:40 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08016
	for <enum-archive@odin.ietf.org>; Tue, 25 Jul 2000 20:40:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA23809;
	Tue, 25 Jul 2000 20:40:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA23774
	for <enum@ns.ietf.org>; Tue, 25 Jul 2000 20:40:14 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07916
	for <enum@ietf.org>; Tue, 25 Jul 2000 20:40:12 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-71.cc.telcordia.com [128.96.13.71])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6Q0dSR23976;
	Tue, 25 Jul 2000 20:39:28 -0400 (EDT)
Message-ID: <397E3342.CFBB9E8B@research.telcordia.com>
Date: Tue, 25 Jul 2000 20:39:30 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
CC: enum@ietf.org
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
References: <4102273CEB77D211869200805FE6F5939EBD38@xch-phl-01.he.boeing.com>	
		 <p04320413b59d41b56e6b@[133.195.65.75]>	
		 <3977AB0A.4C19BF89@research.telcordia.com>
		 <p04320409b59d794eaddb@[133.195.65.75]>
		 <3977E0BC.6AB09145@research.telcordia.com> <p04320402b59faceb8bf6@[10.0.0.9]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

Patrik,

Thanks for the clarification. Please see my comments below.

Cheers,

--Hong

Patrik Fältström wrote:

> It is not there, and that is what I want in the draft of Greg, i.e.
> the one about operation. That's why I wrote the first mail in this
> thread :-)

You have provided a very important guideline on what ENUM is expected to do. I
would like to capture that before it gets lost in the emails. Please correct me if
I miss anything:

"Propagation delays in ENUM RRs are bounded by a time interval of about 15 minutes.
Any service that involves dynamic update of ENUM RRs SHALL take this delay bound
into account in order to function properly. If a service requires dynamic update be
done faster than this upper bound, it is recommended that the corresponding ENUM RR
contain a pointer to another server that will be able to perform the updates while
satisfying the timing constraints. In this case, the pointer to the server is
static. How update will be done in the server is outside of the scope of ENUM."

> Number Authority is responsible for 1-234-567-xxxx
> They have:
>
>    7.6.5.4.3.2.1.e164.arpa. IN SOA ...
>    1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NS ns.resolver-service.com.
>
> I as a customer have the phone number 1-234-567-8901.
> I have told number-authority that the one handling the NAPTRs for me
> is Resolver Service Inc.
>
> Resolver service is responsible for among other things my number:
>
>    1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN SOA ....
>    1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NAPTR ....
>    1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NAPTR ....
>    1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NAPTR ....
>    1.0.9.8.7.6.5.4.3.2.1.e164.arpa. IN NAPTR ....
>
> If I am unhappy with the service of Resolver Service Inc, I tell
> Number Authority that my resolution is handled by some other
> authority, and Number Authority changes the NS which points to
> Resolver Service Inc.

Technically, this does work for a single subscriber. But it may be problematic when
the redirection happens in a higher level of the e164.arpa hierarchy, say an
enterprise with a large block of numbers assigned. The problem is that the new
service provider has to re-create the RRs for all the nodes in the ported subtree
from scratch, which is not a trivial task. It would be nice if the old service
provider can transfer the subtree to the new service provider (say as required by
agreements among service providers or by mandate from the government regulation.).

I am not saying that this is the only way. For example, you may just have a pointer
at service provider level to direct the queries to the enterprise ENUM server.
However, there are two problems with this approach. First, the enterprise may not
want to operate the ENUM server for its numbers for various reasons, such as
operational cost, staff expertise, or security concerns, etc. That is why they
outsource that function to a service provider. Second, if the enterprise is
managing its own ENUM server, they are better off having an RR at the parent level
(in this case, the Number Authority) to point to its ENUM server, without using the
service provider as another level of redirection.



_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Tue Jul 25 20:42:07 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08364
	for <enum-archive@odin.ietf.org>; Tue, 25 Jul 2000 20:42:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA23918;
	Tue, 25 Jul 2000 20:41:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA23885
	for <enum@ns.ietf.org>; Tue, 25 Jul 2000 20:41:25 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08214
	for <ENUM@ietf.org>; Tue, 25 Jul 2000 20:41:23 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-71.cc.telcordia.com [128.96.13.71])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6Q0e6R23983;
	Tue, 25 Jul 2000 20:40:07 -0400 (EDT)
Message-ID: <397E3368.E48BAF35@research.telcordia.com>
Date: Tue, 25 Jul 2000 20:40:08 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
CC: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>,
        "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>, ENUM@ietf.org
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
References: <6B57F36F4FF9D111B30A0008C7F413370370527A@exdal1.ons.octel.com>
		 <p04320414b59d43b8e794@[133.195.65.75]>
		 <3977B283.365F233C@research.telcordia.com> <p0432040ab59d7cbe7c8b@[133.195.65.75]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

Patrik Fältström wrote:

> At 22.16 -0400 00-07-20, Hong Liu wrote:
> >Note that domain names are generally not portable, hence we need to come
> >up with special guidelines for using DNS to handle portable E.164 numbers.
>
> This probably differs from country to country on how to do this.
>
>    paf
>

Patrik,

Can you elaborate on this a bit more? I would like to know some examples and
how this is done. Say my domain name is www.foo.xxx, whose DNS entry is hosted
by service provider A. Now I want it to be hosted by service provider B. Does
it mean that the top level domain xxx is jointly  maintained by both A and B,
each of which handles a (disjoint) subset of xxx? Thanks!

--Hong


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Tue Jul 25 20:48:26 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09745
	for <enum-archive@odin.ietf.org>; Tue, 25 Jul 2000 20:48:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAB24070;
	Tue, 25 Jul 2000 20:47:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24043
	for <enum@ns.ietf.org>; Tue, 25 Jul 2000 20:47:34 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09552
	for <enum@ietf.org>; Tue, 25 Jul 2000 20:47:32 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-71.cc.telcordia.com [128.96.13.71])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6Q0knR24258;
	Tue, 25 Jul 2000 20:46:50 -0400 (EDT)
Message-ID: <397E34FB.616613B4@research.telcordia.com>
Date: Tue, 25 Jul 2000 20:46:51 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
CC: enum@ietf.org
References: <397BA829.92C8D0B0@research.telcordia.com> <p0432042bb5a15b8f746a@[10.0.0.2]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: E2U and URI
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

Patrik,

I have a couple of comments regarding your reply.

Cheers,

--Hong

Patrik Fältström wrote:

> At 22.21 -0400 00-07-23, Hong Liu wrote:
> >I noticed the following changes made in draft-enum-e164-dns-02.txt, as
> >compared to draft-enum-e164-dns-00.txt:
> >(1) A new service type, E2U, is defined for ENUM, instead of using "N2R"
>
> Correct. That was because this wg wanted to have that.
>

I am for it. I just did not recall any discussions on the mailing list until
I saw it in the 01 draft. Again, I may miss the discussion.

> >(B) The use of regexp field is a two-sided sword. It is powerful but is
> >also error prone if not used with care. It would help if you can
> >enumerate some well-defined templates in the document for the common
> >cases when using this mechanism .
>
> You can always do misspellings in all different kind of RRs, which
> all point to catastrophic results. What do you think the impact is
> when someone at NSI misspelled the hostname of a nameserver for a
> ccTLD? Pretty bad that aswell...

It is assumed that DNS administrators shall be versed in populating DNS RRs.
They are expected to do it right, though I would argue that they do not have
to deal with regexps RRs until NAPTR. I assume that NSI has a well-defined
QMO rules in place concerning the changes made to their database.

ENUM is somewhat different, since individual subscribers may be able to
update his/her own RRs by themselves (see my email on this issue regarding
self service provisioning.). Even for average DNS administrators, the chance
of making a mistake with regexp is still quite high and these mistakes are
not easy to catch. That is why I suggest that your document provide some
templates for well-defined cases so that people can just cut and paste. Or
other DNS tools may be needed for simulating the substitution before it gets
into the database.


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Tue Jul 25 20:58:18 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11967
	for <enum-archive@odin.ietf.org>; Tue, 25 Jul 2000 20:58:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24281;
	Tue, 25 Jul 2000 20:57:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24252
	for <enum@ns.ietf.org>; Tue, 25 Jul 2000 20:57:45 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11826
	for <enum@ietf.org>; Tue, 25 Jul 2000 20:57:43 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id A3A045E; Wed, 26 Jul 2000 02:57:14 +0200 (MET DST)
Received: from [171.70.85.71] (dhcp-2sjc13-85-71.cisco.com [171.70.85.71])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id CAA09763;
	Wed, 26 Jul 2000 02:57:13 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p04320409b5a3e5dc1853@[171.70.85.71]>
In-Reply-To: <397E3342.CFBB9E8B@research.telcordia.com>
References: 
 <4102273CEB77D211869200805FE6F5939EBD38@xch-phl-01.he.boeing.com>			
 <p04320413b59d41b56e6b@[133.195.65.75]>			
 <3977AB0A.4C19BF89@research.telcordia.com>		
 <p04320409b59d794eaddb@[133.195.65.75]>		
 <3977E0BC.6AB09145@research.telcordia.com>
 <p04320402b59faceb8bf6@[10.0.0.9]>
 <397E3342.CFBB9E8B@research.telcordia.com>
Date: Tue, 25 Jul 2000 17:52:53 -0700
To: Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
Cc: enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 20.39 -0400 00-07-25, Hong Liu wrote:
>"Propagation delays in ENUM RRs are bounded by a time interval of 
>about 15 minutes.
>Any service that involves dynamic update of ENUM RRs SHALL take this 
>delay bound
>into account in order to function properly. If a service requires 
>dynamic update be
>done faster than this upper bound, it is recommended that the 
>corresponding ENUM RR
>contain a pointer to another server that will be able to perform the updates

...another service... [not server]

>while
>satisfying the timing constraints. In this case, the pointer to the server is
>static. How update will be done in the server is outside of the 
>scope of ENUM."
>
>It would be nice if the old service
>provider can transfer the subtree to the new service provider (say 
>as required by
>agreements among service providers or by mandate from the government 
>regulation.).

Of course that would be nice. Just like when you switch from one 
registrar to another one for your domainname in ".com".

This has though to do with contracts under which the various parties 
got their domainnames delegated to them in the first place, so I 
claim this is something one have to think about in each case in each 
country.

It would be preferrable if in the case of a move of delegation of 
numbers from one provider to another that the first one pass all data 
to the new provider. But, that is not a technical matter, and we can 
not do much about it in an RFC.

>I am not saying that this is the only way. For example, you may just 
>have a pointer
>at service provider level to direct the queries to the enterprise ENUM server.
>However, there are two problems with this approach. First, the 
>enterprise may not
>want to operate the ENUM server for its numbers for various reasons, such as
>operational cost, staff expertise, or security concerns, etc. That is why they
>outsource that function to a service provider. Second, if the enterprise is
>managing its own ENUM server, they are better off having an RR at 
>the parent level
>(in this case, the Number Authority) to point to its ENUM server, 
>without using the
>service provider as another level of redirection.

Maybe, these are other ways of solving the problem. Welcome to the DNS :-)

You can solve the same thing in different ways. What suits you(r part 
of the DNS tree) is up to you.

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Tue Jul 25 21:20:42 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17462
	for <enum-archive@odin.ietf.org>; Tue, 25 Jul 2000 21:20:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24981;
	Tue, 25 Jul 2000 21:20:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24952
	for <enum@ns.ietf.org>; Tue, 25 Jul 2000 21:20:00 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17212
	for <ENUM@ietf.org>; Tue, 25 Jul 2000 21:19:58 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id C4DF486; Wed, 26 Jul 2000 03:19:29 +0200 (MET DST)
Received: from [171.70.85.71] (dhcp-2sjc13-85-71.cisco.com [171.70.85.71])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id DAA12860;
	Wed, 26 Jul 2000 03:19:25 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p0432040ab5a3e6f45a36@[171.70.85.71]>
In-Reply-To: <397E3368.E48BAF35@research.telcordia.com>
References: 
 <6B57F36F4FF9D111B30A0008C7F413370370527A@exdal1.ons.octel.com>		
 <p04320414b59d43b8e794@[133.195.65.75]>		
 <3977B283.365F233C@research.telcordia.com>
 <p0432040ab59d7cbe7c8b@[133.195.65.75]>
 <397E3368.E48BAF35@research.telcordia.com>
Date: Tue, 25 Jul 2000 18:13:57 -0700
To: Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
Cc: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>,
        "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>, ENUM@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 20.40 -0400 00-07-25, Hong Liu wrote:
>Can you elaborate on this a bit more? I would like to know some examples and
>how this is done. Say my domain name is www.foo.xxx, whose DNS entry is hosted
>by service provider A. Now I want it to be hosted by service provider B. Does
>it mean that the top level domain xxx is jointly  maintained by both A and B,
>each of which handles a (disjoint) subset of xxx? Thanks!

You asked about ported numbers. That is something different from the 
case that you move your delegation (DNS resolution) from one party to 
another.

Now, if you have www.foo.xxx in your zone foo.xxx, which is hosted by 
A, and want it to be hosted by B, then you have to ask the one which 
hosts xxx to change the delegation of foo.xxx to B from A.

I.e. you have a C which hosts xxx which delegates the domain to first 
A, then B.

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Tue Jul 25 21:28:22 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19950
	for <enum-archive@odin.ietf.org>; Tue, 25 Jul 2000 21:28:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25165;
	Tue, 25 Jul 2000 21:27:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25141
	for <enum@ns.ietf.org>; Tue, 25 Jul 2000 21:27:51 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19764
	for <enum@ietf.org>; Tue, 25 Jul 2000 21:27:48 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id 4AD1F86; Wed, 26 Jul 2000 03:27:20 +0200 (MET DST)
Received: from [171.70.85.71] (dhcp-2sjc13-85-71.cisco.com [171.70.85.71])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id DAA13380;
	Wed, 26 Jul 2000 03:27:18 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p0432040bb5a3ec42993b@[171.70.85.71]>
In-Reply-To: <397E34FB.616613B4@research.telcordia.com>
References: <397BA829.92C8D0B0@research.telcordia.com>
 <p0432042bb5a15b8f746a@[10.0.0.2]>
 <397E34FB.616613B4@research.telcordia.com>
Date: Tue, 25 Jul 2000 18:19:34 -0700
To: Hong Liu <lhong@research.telcordia.com>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Cc: enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: E2U and URI
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 20.46 -0400 00-07-25, Hong Liu wrote:
>I am for it. I just did not recall any discussions on the mailing list until
>I saw it in the 01 draft. Again, I may miss the discussion.

It was a proposal on the mailing list to change the service, which 
Michael backed up (as creator of the NAPTR). I had some discussion 
with him which resulted in me being convinced that the only really 
good thing to do was to define the whole E.164->URI algorithm which 
uses NAPTRs. Remember that some other (URN-like) service might store 
NAPTRs with the same owner which you are not supposed to use when you 
do E.164->URI resolution, and you as the one querying DNS need to 
know which one of the NAPTRs you should use.

>ENUM is somewhat different, since individual subscribers may be able to
>update his/her own RRs by themselves (see my email on this issue regarding
>self service provisioning.). Even for average DNS administrators, the chance
>of making a mistake with regexp is still quite high and these mistakes are
>not easy to catch. That is why I suggest that your document provide some
>templates for well-defined cases so that people can just cut and paste. Or
>other DNS tools may be needed for simulating the substitution before it gets
>into the database.

I thought the examples were enough, but to be honest, I expect people 
not to run their own DNS servers. They do not do that today even. 
I.e. the large masses let their ISP handle the domain for them, and 
the ISPs have DNS servers aswell as tools which makes it possible for 
a customer to change the content of DNS.

I expect such tools at the service providers of DNS services, which 
can be ISPs, telcos, or redirection services, and if I were them, I 
would have a web based interface which helps the user construct the 
correct NAPTR.

    paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul 26 10:45:28 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21615
	for <enum-archive@odin.ietf.org>; Wed, 26 Jul 2000 10:45:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13533;
	Wed, 26 Jul 2000 10:43:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13506
	for <enum@ns.ietf.org>; Wed, 26 Jul 2000 10:43:49 -0400 (EDT)
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21388
	for <enum@ietf.org>; Wed, 26 Jul 2000 10:43:47 -0400 (EDT)
Received: from computer.ix.netcom.com (pool-209-138-13-180.ipls.grid.net [209.138.13.180])
	by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id KAA19182
	for <enum@ietf.org>; Wed, 26 Jul 2000 10:43:42 -0400 (EDT)
Message-Id: <4.3.1.2.20000726093911.00c77b50@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 26 Jul 2000 09:44:05 -0500
To: enum@ietf.org
From: Richard Shockey <rshockey@ix.netcom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Enum] Volunteer scribe needed for Pittsburgh
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org


I'm wondering is some kind soul out there would be so kind to volunteer to 
be a scribe for the upcoming meeting..

You get to sit up front and have a ring side seat to all the festivities.


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul 26 16:55:23 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16469
	for <enum-archive@odin.ietf.org>; Wed, 26 Jul 2000 16:55:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29144;
	Wed, 26 Jul 2000 16:45:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29101
	for <enum@ns.ietf.org>; Wed, 26 Jul 2000 16:45:57 -0400 (EDT)
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14893
	for <enum@ietf.org>; Wed, 26 Jul 2000 16:45:53 -0400 (EDT)
Received: from computer.ix.netcom.com (pool-209-138-13-180.ipls.grid.net [209.138.13.180])
	by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id QAA32160
	for <enum@ietf.org>; Wed, 26 Jul 2000 16:45:49 -0400 (EDT)
Message-Id: <4.3.1.2.20000726144443.00ba9ca0@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 26 Jul 2000 15:47:00 -0500
To: enum@ietf.org
From: Richard Shockey <rshockey@ix.netcom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Enum] ENUM FAQ
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Since our work may be entering a new phase ..I've taken the liberty to 
trying to pull together some thinking about ENUM into a FAQ.

This will probably not be a WG document but if any of you would like to 
contribute questions answers or comment on it generally you are welcome to 
do so.

################




ENUM Working Group                                              Richard Shockey
Internet-Draft: DRAFT-SHOCKEY-ENUM-FAQ-00.TXT           NeuStar, Inc
Expiration <1/2001>                                             July 26, 2000


                         FREQUENTLY ASKED QUESTIONS ABOUT ENUM

This is a very preliminary draft.  It has not been reviewed or accepted by 
the working group.  Comments are eagerly sought, as are suggestions for 
additional questions and alternative answers.

Status Of This Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups 
may also distribute working documents as Internet-Drafts.  Internet-Drafts 
are draft documents valid for a maximum of six months and may be updated, 
replaced, or obsoleted by other documents at any time.  It is inappropriate 
to use Internet-Drafts as reference material or to cite them other than as 
"work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This document and related documents are discussed on the IETF Enum mailing 
list. To join the list, send mail to <mailto:enum-
request@ietf.org?body=subscribe>.

To contribute to the discussion, send mail to  <mailto:enum@ietf.org> The 
Enum working group charter, including the current list of group documents, 
can be found at http://www.ietf.org/html.charters/enum-charter.html.


Copyright Notice
Copyright (C) The Internet Society (2000).  All Rights Reserved.

ABSTRACT

The IETF ENUM work group has been chartered to develop protocols that map 
telephone numbers to resources typically found on the Internet , such as 
URI's, using the Domain Name Service. It has been proposed that a global 
ENUM service be created in the e164.arpa domain. How e164.arpa should be 
organized and administered is now a serious issue confronting the Internet 
Community.  This document is provided as a list of common questions, and 
their answers, concerning E.164 numbers and their use on the 
Internet.  Knowledge of Domain
Name Service technology is assumed.

INTRODUCTION

The IETF ENUM work group has been chartered to develop protocols that map 
telephone numbers to Internet resources.  The working group charter is 
specified at:

<http://www.ietf.org/html.charters/enum-charter.html>

A Goals and Requirements specification is under active discussion.
The current draft is:

<http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-01.txt>

The central ENUM protocol document is:

<http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-02.txt>.

It describes the technique whereby a globally unique E.164 telephone number 
is placed under a single DNS administrative domain. Using classic DNS 
resolution, a client application could then discover resources associated 
with that number from NAPTR or SRV Resource Records.

Several application developers and telecommunications service providers 
have expressed interest in quickly deploying ENUM based services.

It has been proposed that a global ENUM service be created in the e164.arpa 
domain.

How e164.arpa should be organized and administered is now a serious issue 
confronting the Internet Community.

FREQUENTLY ASKED QUESTIONS

WHAT IS ENUM?

ENUM stands for Telephone Number Resolution. It is a chartered WG of the 
IETF <http://www.ietf.org>.  The reason the work group exists is detailed 
in its charter. The URL is listed above.

There have been numerous experimental trials of DNS based resolution of
telephone number resources. The most significant of those was the TPC.INT 
fax experiment described in RFC 1709. Many of the concepts use by ENUM came 
out of that early work


WHAT BENEFITS DOES ENUM GIVE TO USERS?

The main benefits are:

ENUM enables calling users or entities to make a selection from the range 
of services that are available especially over the Internet for
communicating with a particular person or entity when the calling user
knows only their telephone number.

ENUM enables users to access Internet based services and resources from
ordinary telephones where they are only be able to input digits

ENUM enables users to specify their preferences for receiving incoming
communications (eg specifying a preference for voicemail messages over live 
calls or indicating a destination for call forwarding). ENUM will give much 
improved user control over communications.

There are many potential applications for ENUM and some are discussed in 
this document.

WHAT IS E.164?

E.164 is the international telephone numbering plan [Document  ITU-T E.164] 
written and administered by the International Telecommunication Union (ITU) 
in Geneva <http://www.itu.int>. The plan specifies the format, structure, 
and administrative hierarchy of telephone numbers. At the root of the E.164 
administrative hierarchy, the ITU issues country codes to sovereign 
national entities and thereby allocates new telephony numbering resources 
as needed. In addition there are other allocations for services and 
networks.  Administration of telephone numbers within each country is 
officially governed by the appropriate national telecommunications 
regulatory agency (e.g. FCC in the US,
CRTC in Canada, Oftel in UK).  The regulator or their designated contractor 
performs the actual national number resource administration itself.

HOW DOES ENUM WORK?

The enum solution  is driven , in part by the fact that most telephony 
users have telephone keypads [ 12 digit ] to work with.

1. A phone number is translated intoE.164 form by in concluding country 
code or area/city code, e.g. 918-9020 dialed in St. Louis would be 
translated to +1-314-918-9020, where +1 is the North American country code.
2. Remove all character parts from the digits. Example: 13149189020
3. Reverse the order of the digits. Example: 02098194131
4. Put dots (".") between each digit. Example: 0.2.0.9.8.1.9.4.1.3.1
5. Append the domain "e164.arpa" to the end.  Example: 
0.2.0.9.8.1.9.4.1.3.1.e164.arpa
6. Perform a DNS query on this domain
7. Retrieve relevant NAPTR Resource records from the Name Server for this 
number and perform whatever relevant application required.

WHY THE FUNNY REVERSAL OF THE NUMBER AND WHAT ARE ALL OF THOSE DOTS FOR?

Each dot separates the number into administrative "domains" or zones in DNS 
terms. This accommodates delegation of authority at varying points 
throughout the e164.name space thereby avoiding the imposition of either a 
fixed delegation scheme worldwide or requiring clients to know that scheme 
in order to know where to put the dots. Delegation in a DNS name is 
structured from right to left. This
is very important. See: <http://www.rfc-editor.org/rfc/rfc2672.txt> for 
more details

AM I GOING TO HAVE TO TYPE IN THOSE DOTS AND REVERSED NUMBERS TO USE ENUM?

Definitely not!  Your application will take care of all of this for you. 
You just enter in a phone number like you always do, into whatever 
application or device that supports ENUM, and it  will take care of the 
conversion.

WHY THE .ARPA TOP LEVEL DOMAIN?

The .arpa domain has been designated to be used for Internet Infrastructure 
purposes. It is managed by the IANA in cooperation with the Internet 
technical community under the guidance of the Internet Architecture Board. 
The e164.arpa domain is believed to be the most appropriate place to host 
the e164 namespace on the Internet.  ENUM constitutes an infrastructure 
support function by virtue of it providing a set of DNS-based resource 
directories, referenced by phone
number, for use by various ENUM-enabled application clients (e.g. 
telephones, SIP servers, voice messaging systems).  ENUM will not be used 
directly by people as a new way of navigating to web sites.  Consequently, 
ENUM is an infrastructure application appropriate for use within the 
designated .arpa domain established for these purposes.

WHAT ARE SRV AND NAPTR RECORDS?

These are DNS Resource Records that will contain information about what 
Internet resources, services or applications that are associated with a 
particular phone number. Subscribers determine what those services are.

For more information, see:

SRV :  <http://www.rfc-editor.org/rfc/rfc2782.txt>
NAPTR  :  http://search.ietf.org/internet-drafts/draft-ietf-urn-naptr-rr-03.txt

WHAT KINDS OF APPLICATIONS COULD USE ENUM?

Since ENUM provides a generic way to perform telephone number-based 
resource discovery, there are lots of examples of ENUM-enabled 
applications, but several have come to the forefront. The voice messaging 
industry has been hard at work developing a comprehensive mechanism by 
which voice mail systems could exchange messages over IP networks. This 
work is called VPIM, or Voice Profile for Internet Messaging. 
http://www.ietf.org/html.charters/vpim-charter.html. The
industry has been looking for a way to discover the host name and domain 
for Internet based voice mail servers. The problem has been that a typical 
voice mail user only has a telephone number and a telephone keypad to work 
with. ENUM permits these VPIM servers to locate each other and exchange 
messages.

Clearly the most active interest in ENUM service has been in Internet 
Telephony. It has been a long standing goal of the Voice over IP (VoIP) 
industry to make a phone call over the Internet as simple to make as a 
regular PSTN call.

ENUM links a telephone number to a host or resources on the Internet that 
can connect the call, either end to end over IP networks or through a 
designated gateway to the PSTN. This would be very useful for connecting 
SIP <http://www.ietf.org/html.charters/sip-charter.html> or H.323-capable 
endpoints that exist across domain boundaries.

ENUM is general enough that multiple discrete services (applications) may 
all be associated with the same telephone number at the same time, each 
application associated with their own unique endpoint resources as 
provisioned in ENUM, assuming the subscriber has the appropriate clients 
supporting those services.  ENUM does not require that all such telephone 
number-based services be provided by the same service provider (telco, ISP, 
whatever), even though the subscriber's right to use that particular 
telephone number may only flow from their having subscribed to one of 
them.Won't ENUM telephone routing confuse the
regular, PSTN routing system?

ENUM facilitates the discovery of resources associated with a telephone 
number, and hence facilitates how various applications will identify 
appropriate peer servers associated with an intended end-user.  It does 
not, however, impact how those applications will operate once the location 
of an end-user associated application server has been 
established.  Consequently, ENUM doesn't affect application-level 
functions, such as call routing, signaling, etc., regardless
of the underlying application technology employed (ISUP, SIP, H.323).  . 
[For example, see TRIP 
<http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-02.txt>]. 
However it is possible that a telephone company call-routing mechanism 
could use ENUM technology as well.

It is a core principle that in providing a unified resource discovery 
service, that ENUM will not change the existing right-to-use rules and 
principles for telephone numbers.  ENUM is not intended to change how 
telephone numbers are administered, but instead facilitate a wide range of 
applications using phone numbers as subscriber names.  Lastly, ENUM will 
not interfere with existing PSTN functions and technology, such as circuit 
switching, SS7 (ISUP or TCAP), or IN (Intelligent Networking), where 
similar resource discovery activities are performed through the PSTN legacy 
technologies.

WHAT PROTOCOL DOES ENUM USE FOR INTERNET TELEPHONY?

ENUM itself is "protocol agnostic" because it's application agnostic.  It 
does not specify what applications a particular telephone number is 
associated with, but instead provides a unified way of discovering 
resources associated with it.  For example it can work with either H.323 or 
the Session Initiation Protocol [SIP].See 
<http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-00.txt>
for further details.

I'VE HEARD THIS VOICE OVER IP STUFF DOESN'T WORK.? THERE ARE LOTS OF 
ARTICLES IN THE TECHNICAL PRESS THAT SAY IT JUST DOESN'T WORK.

VoIP is an evolving technology that is in an early stage of development but 
rapidly improving. It is only a question of when, not if, Internet 
Telephony will become a reality, fully integrated with the existing, global 
telephone service.  This is an orthogonal issue to ENUM, as ENUM is not 
intended solely to facilitate VoIP, but a range of applications where a 
telephone number is used as a subscriber name.

DO I "OWN" MY PHONE NUMBER?

The ITU provides guidelines for the structure of phone numbers.  They 
allocate part of the structure of the phone number, the country code, to 
countries.  Each country's national regulatory agency (NRA) determines the 
remaining structure of the phone numbers within their country.  The NRA 
also designates a national number administrator (NNA), in many countries 
the NRA is the NNA.  The NNA allocates blocks of numbers to communications 
service providers.  Communications service providers allocate numbers to 
their users.  When a user disconnects
their service, after an appropriate aging interval, the number becomes an 
available resource to the service provider for the purposes of reassignment 
to a new or different user.

It is generally accepted that there are  no property rights associated with 
numbers. That means you cannot sell your telephone number to someone else, 
unlike the fact that you could sell an Internet domain name under your 
control.  As a matter of fact user's phone numbers get changed without 
their consent quite frequently.  In the US, for example, it results from an 
area code split, where the 3-digit area code prefix is changed in the 
user's geographic area, but usually not the last 7 digits.  However, when 
this happens, the user no longer
has the same 10-digit phone number they once had.

It is becoming more common for users to have more control over their phone 
numbers.  In many countries with rules and regulations about telephone 
number portability, you can take your telephone number from carrier to 
carrier or from service type to service type (e.g., land-line to mobile) as 
you wish. Regulations vary from country to country.

Within the ENUM community it is the general view that the telephone 
subscriber representatives [ISP's, carriers, etc],  would be allowed to
determine what resources are associated  with that telephone number within 
the ENUM service.


WHAT HAPPENS TO THE NUMBER WHEN A SUBSCRIBER PORTS FROM ONE SERVICE 
PROVIDER TO ANOTHER?

When a number ports, the service provider of record changes.  That is the 
industry now recognizes a different service provider as the holder for that 
particular number.  This is important for routing and billing purposes.

The subscriber should still be able to continue using their ENUM-enabled 
services, assuming their new service provider(s) support them.  Naturally, 
the actual location of server resources identified by ENUM will likely 
change as the subscriber changes any of the underlying service providers.

When the user disconnects the number goes back to the original service
provider's inventory, not to the new service provider's inventory.

WHAT HAPPENS TO THE ENUM SERVICES WHEN A SUBSCRIBER CANCELS TELEPHONE SERVICE?

As we now know the number returns to the communications service provider's 
inventory for the purposes of reassignment.  The subscriber that cancels 
their telephone service will have to cancel the associations that number 
has with all ENUM services, even those provided by other service 
providers.  If this was not done the new user of that telephone number 
could have a conflict with the old user.  On the other hand, where number 
portability is available, a user has the option of porting their number 
over to a new service provider instead of canceling their existing service 
and losing their current number.

COULD ENUM BE USED TO PROVIDE TELEPHONE NUMBER PORTABILITY?

In those countries that do not yet have a centralized database 
administration service, having a shared directory service like ENUM might 
be of interest.  However, ENUM is not intended to serve this function, as 
there are very
significant technical, regulatory, security, and operational limitations in 
using ENUM for this purpose.  ENUM is a shared resource discovery service, 
not an industry provisioning service.  In most countries where number 
portability is deployed, telephone service providers are generally required 
to comply with regulatory/industry processes, procedures, and systems, 
regardless of the underlying technology they employ for telephony service 
delivery (SIP, H.323, circuit-switched, or string-and-cans).  How ENUM is 
administered in those countries will also likely require mirroring of 
provisioning rules (e.g. anti-slamming) employed for number portability and 
number administration so as to ensure that service providers using 
ENUM-enabled services do not violate applicable regulatory rules or 
industry guidelines.  ENUM is another downstream use of numbering 
provisioning and administration activities, and will need to be deployed 
consistent with applicable national requirements, it does not create an 
alternate numbering universe with its own set of rules and policies.

HOW IS THE USER OF A NUMBER AUTHENTICATED?

Users could be corporations, individuals, government agencies, military, 
and hosts of other non-individual users.  Service providers typically 
assign large blocks of numbers to these entities.  The telecom manager 
within these entities then assigns numbers to users.  So even the service 
providers cannot identify the users for a very large portion of the 
allocated numbers.

This is an unresolved issue but one that must be resolved prior to 
deploying a robust and secure ENUM service.  It's likely that the service 
provider that allocated the number(s) to the user will be involved in the 
process of authentication.

WELL WHAT ABOUT PRIVATE NUMBERING PLANS WITHIN A COMPANY?

Excellent question. The ENUM protocol can be used in private numbering 
plans the same way it can be used in the public E.164 number plan.  The 
Internet Telephony gateway or proxy needs some intelligence to "decode" a 
particular dialing string and then decide how to look up resources for that 
particular number. Instead of looking for resources in e164.arpa the 
gateway or proxy would look for SRV or NAPTR records for private numbers 
under some other structure, such as
e164.bigcompany.com .

WHAT ABOUT EMERGENCY SERVICES LIKE 911 OR 112 [EUROPE]?

In general, emergency service numbers are "access codes" and not "E.164
numbers", and will not be part of ENUM services.

HOW WILL THE E164.ARPA DOMAIN BE ORGANIZED?

One convenient way of doing this would be to delegate according to the 243 
country codes designated by the ITU.  It's important to understand, 
however, that delegation in DNS can occur at any digit, or zone domain in 
DNS terms

So within the root e164.arpa there would be an NS listing for 1.e164.arpa 
representing the top level of the North American Numbering Plan. [US, 
Canada, and several Caribbean countries]

A NS listing for -.4.4.e164.arpa - representing the top level (44) of the UK
A NS listing for - 4.6.e164.arpa - representing the top level (46) 
of  Sweden.
A NS listing for - 8.1.e164.arpa - representing the top level (81) of Japan.
A NS listing for - 8.5.3.e164.arpa - representing the top level (358) of
Finland.

At the national TN/NS level further NS delegation [DNAME, CNAME, PTR] can 
occur to enterprises, TN/NS application service providers, carriers, and 
even individuals who have DNS servers in their house.

WHO WILL ADMINISTER THESE NATIONAL TELEPHONE NUMBER NAME SERVERS?

There are many competent companies or organizations that can operate these 
servers. A number of companies have already come forward to express their 
interest in running these servers, initially free of charge and on an 
experimental basis, until such time as consensus can be reached on how this 
system is to ultimately organize.

Some theories on how this system will be organized on a permanent basis 
will be discussed a little later in this FAQ.  There are a number of 
regulatory constraints in various countries that might apply on the ENUM 
administrator, name service operators, as well as delegation policies below 
the national level.  For example, where local telephony service competition 
and number portability are being deployed in a country, it is not unusual 
that a neutral third party is required to provide master database 
administration services, and a requirement for anti-slamming and 
non-reliance on competing carriers for routing or
resolution functions.

AM I ULTIMATELY GOING TO HAVE TO PAY TO HAVE MY TELEPHONE NUMBER ENUM
PROVISIONED?

Probably yes, but most likely the costs will be indirectly recovered 
through the underlying prices for ENUM-enabled services that subscribers 
pay. This is a DNS-based system. If you want a domain name registered in 
DNS someone must pay for that. Listing telephone numbers will be no 
different.  Whether the cost will be charged directly to the subscriber or 
will be an indirect charge as part of some larger services will depend on 
those offering the services.

Remember you do not have to ENUM list your phone number. ENUM would be a 
subscriber-controlled "opt-in" system to "announce", over the Internet, the 
availability of a particular telephone number to accept service sessions 
and how to manage those sessions as a result of having subscribed to an 
ENUM-enabled service. If you do not have an Internet telephony device or 
service you will likely not need to list your number.  On the other hand, 
subscribers may not necessarily be aware they've subscribed to such a 
service, and have had ENUM provisioned for that service by their service 
provider on their behalf.

AM I GOING TO HAVE CONTROL OVER HOW MY PHONE NUMBER IS USED IN THIS SYSTEM?

Ultimately yes. We want to repeat that the first principal in the creation 
and operation of a global ENUM service is that the phone number subscriber 
or their designated representatives is the ultimate decision maker on how a 
DNS record for a phone number is to be provisioned.

ARE THERE ANY EXAMPLES OF GLOBAL NAMESPACE DELEGATION THAT SHOULD BE 
CONSIDERED
AS MODELS?

The closest, technical equivalent is in-addr.arpa.  That domain provides a 
reverse mapping, from IP address to domain name.  It is used as part of the 
Internet infrastructure operation, to help authenticate an IP address and 
identify the operator associated with an IP address.  It is not seen 
directly by users.  The same is true for e164.arpa.  It will be for 
operational infrastructure, rather than for directl access by end users.

As with e164.arpa, in-addr.arpa, allocations are hierarchical, according to 
the infrastructure administrative structure.  For in-addr.arpa, the 
hierarchy uses the "CIDR" address allocation hierarchy.  For e164.arpa, the 
hierarchy will be based on the ITU E.164 Recommendation.

WHO CAN ADMINISTER THE ENUM REGISTRY IN THE NEAR-TERM?

ENUM is approaching the stage where the industry will want to start
interoperability testing.  And they will want to test using the e164.arpa 
domain.  The interoperability test would have the same principles that 
current ones do; no charge, sharing of information, etc..

A. One method of enabling the registry would be to develop an RFC that 
defines the interim delegation principles for IANA as well as principles 
for the transition to the permanent registry.

WHAT CAN BE DONE IN THE LONG TERM?

There will need to be a formal effort to define and establish the structure 
for this activity.  An example of the charter for that effort would be:

1. Define the global ENUM Service.
2. Perform the task of certifying organizations to IANA that wish to 
operate national TN/NS once they have been nominated by their respective 
nation states.
3. Coordinate technical standards for the operation of ENUM service in
cooperation with the IETF.
4. Establish guidelines and policies, which national TN/NS administrators 
operate.
5. Promote public policy on how ENUM resources should be used.

Oversight for this activity should be constituted that comprise several
constituencies, such as

1. The potential ENUM user community
2. The potential ENUM provider community
3. National governments, at least as an advisory
4. IAB-IESG representatives
5. others?

FORGET ALL THIS POLICY TALK...HOW IS ENUM GOING TO WORK FOR ME?  WHAT DOES 
THIS SYSTEM LOOK LIKE TO ME... JOHN DOE TELEPHONE SUBSCRIBER?  HOW WILL THE 
RIGHTS OF TELEPHONE NUMBER SUBSCRIBERS BE PROTECTED?

This is an essential question that must be resolved, but a clear statement 
of policy protecting subscribers should be part of any ENUM system charter.

A simple answer is by respecting existing regulatory and business rules
regarding number administration, slamming, non-reliance, etc.  Only by
replicating or re-implementing ENUM analogs to the existing rules of the 
road will we avoid a wide range of very serious administrative, operational 
and political conflicts.

HOW ARE YOU GOING TO PREVENT "SLAMMING" OR "HIJACKING"?

Slamming, or the involuntary transfer of service provider, must be avoided 
in any ENUM system.  However it is a serious problem in the PSTN and we 
must be careful not elsewhere. Note that anti-slamming fundamentally 
requires a neutral third party solution.  The US industry is grappling with 
this on long distance right now.  It was solved on number portability from 
the outset.  Authenticated subscriber access is not a total solution, 
because if a subscriber disconnects their telephony service, they lose 
rights to the phone number.  Consequently, some combination of originator 
authentication as well as telephone number rights validation, using 
existing new and existing validation sources, can be used to solve the 
problem, depending on the level of standard required.

WHAT IS THE EFFECT OF E164.ARPA DEPLOYMENT ON THE GLOBAL DNS SYSTEM?

We don't know. This is going to need research, such as the effect of "wrong 
dials" on the root of e164.  That is, caller specification of a wrong 
number can result in many additional queries to the e164.arpa root.

Additional work will be necessary in advising ENUM applications such things 
as the level of data caching necessary in order relieve stress  -- suppress 
escalating of poorly formed queries - mis-dials - or cache misses -- on the 
root structure.

For telephony applications, performance and load engineering is critical, 
as query volumes from small to medium size cities can easily reach many 
thousands per second alone.  Response times, as well as transaction loads, 
must be carefully considered.  Conventional DNS caching is of significantly 
reduced value in ENUM due to the huge size of the name space and relatively 
even distribution of queries into the space over arbitrary time 
intervals.  Unlike conventional DNS queries, calls volumes aren't highly 
concentrated into a popular small subset of the number space.

WHAT WILL BE THE EFFORT TO ADMINISTER THE ROOT OF THE E164.ARPA NAMESPACE?

Any solution ought to require little or no work on the part of the 
e164.arpa root administrator. Optimally the root of e164.arpa should 
contain a small listing of all of the national ENUM top level country code 
name servers as described above.

SECURITY CONSIDERATIONS:

Authentication of ENUM provisioning requests, validation of telephone 
number use rights where appropriate, and security of e164.arpa zone roots, 
poses the primary security concerns for ENUM.

ACKNOWLEDGEMENTS:

The author wants to acknowledge the following individuals in preparing this 
document, though any errors or omissions are the responsibility of the 
author. Thanks to :Dave Crocker, Mark Foster, Tom McGarry,  John Horrocks

REFERENCES:

AUTHOR:

Richard Shockey
Senior Technical Industry Liaison
NeuStar
1120 Vermont Ave  N.W.
Washington DC 20005
Tel: +1 314.503.0640
Fax: +1 815.333.1237
Email: rshockey@ix.netcom.com
rich.shockey@neustar.com





 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Jul 26 19:00:30 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21124
	for <enum-archive@odin.ietf.org>; Wed, 26 Jul 2000 19:00:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04921;
	Wed, 26 Jul 2000 18:59:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04888
	for <enum@ns.ietf.org>; Wed, 26 Jul 2000 18:59:48 -0400 (EDT)
Received: from joy.songbird.com (IDENT:root@joy.songbird.com [208.184.79.7])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20934
	for <enum@ietf.org>; Wed, 26 Jul 2000 18:59:46 -0400 (EDT)
Received: from dcrocker.dcrocker.net (free.88.106.bayarea.net [205.219.88.106])
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA17204;
	Wed, 26 Jul 2000 15:59:42 -0700
Message-Id: <4.3.2.20000726154840.00dcf7d0@joy.songbird.com>
X-Sender: dhc@joy.songbird.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Wed, 26 Jul 2000 15:53:44 -0700
To: Patrik Fältström <paf@cisco.com>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: Algorithm
Cc: enum@ietf.org
In-Reply-To: <p0432042cb5a15d08cd10@[10.0.0.2]>
References: <397BA836.4CF65215@research.telcordia.com>
 <397BA836.4CF65215@research.telcordia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Thought it might be worth adding a bit of technically mundane trivia, into 
all this high falutin' policy debate:

The algorithm in section 2 of the document would be better -- less work for 
the programmer, but with the same semantics -- if dots were added AFTER the 
string number reversal.

Hence I suggest swapping steps 4 and 5.

The Current step 5 should probably also say "Reverse the order" rather than 
"Change the order" in order (pun?) to be precise.

We now return you to your regularly scheduled Argument Of Great Significance...

d/


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul 27 07:54:12 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07633
	for <enum-archive@odin.ietf.org>; Thu, 27 Jul 2000 07:54:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23672;
	Thu, 27 Jul 2000 07:53:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23598
	for <enum@ns.ietf.org>; Thu, 27 Jul 2000 07:53:02 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07385
	for <enum@ietf.org>; Thu, 27 Jul 2000 07:53:00 -0400 (EDT)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by ertpg14e1.nortelnetworks.com; Thu, 27 Jul 2000 07:52:42 -0400
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id P4RR27N9; Thu, 27 Jul 2000 07:50:49 -0400
Received: from americasm01.nt.com (wcarh0aq.ca.nortel.com [47.209.16.117]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id PS4VAKYX; Thu, 27 Jul 2000 07:50:44 -0400
Message-ID: <39802288.3F5B88B3@americasm01.nt.com>
Date: Thu, 27 Jul 2000 07:52:40 -0400
From: "Nicholas Sauriol" <nsauriol@nortelnetworks.com>
Reply-To: "Nicholas Sauriol" <nsauriol@nortelnetworks.com>
Organization: Nortel Networks Corporation
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Crocker <dhc@dcrocker.net>
CC: m <paf@cisco.com>, enum@ietf.org
Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: Algorithm
References: <397BA836.4CF65215@research.telcordia.com> <397BA836.4CF65215@research.telcordia.com> <4.3.2.20000726154840.00dcf7d0@joy.songbird.com>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I have to agree with Dave on this one. Altough I'm sure most programmers
would make the change anyways, it seems logical to have it written in the
way it will be used.
<br>My apologies for the following question, I joined the group rather
late, but why remove extra characters and than the '+' in 2 steps, as opposed
to simply removing all non-numerical characters?
<p>Dave Crocker wrote:
<blockquote TYPE=CITE>Thought it might be worth adding a bit of technically
mundane trivia, into
<br>all this high falutin' policy debate:
<p>The algorithm in section 2 of the document would be better -- less work
for
<br>the programmer, but with the same semantics -- if dots were added AFTER
the
<br>string number reversal.
<p>Hence I suggest swapping steps 4 and 5.
<p>The Current step 5 should probably also say "Reverse the order" rather
than
<br>"Change the order" in order (pun?) to be precise.
<p>We now return you to your regularly scheduled Argument Of Great Significance...
<p>d/
<p>_______________________________________________
<br>enum mailing list
<br>enum@ietf.org
<br><a href="http://www1.ietf.org/mailman/listinfo/enum">http://www1.ietf.org/mailman/listinfo/enum</a></blockquote>

<p><br>--
<table BORDER COLS=1 WIDTH="100%" BGCOLOR="#FFFFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE>
<center><b><font face="Courier New,Courier"><font color="#000099"><font size=+2>Nicholas
Sauriol</font></font></font></b>
<br><b><font face="Courier New,Courier"><font color="#999999">1.613.763.1978</font></font></b>
<br><b><font face="Arial,Helvetica"><font color="#999999"><font size=+1>Succession
Solutions</font></font></font></b>
<br><b><font face="Courier New,Courier"><font color="#660000">www.nortelnetworks.com</font></font></b>
<br><b><font face="Courier New,Courier"><font color="#000099">Nortel Networks
Confidential</font></font></b></center>
</td>
</tr>
</table>

<br>&nbsp;</html>


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Jul 27 07:58:39 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08571
	for <enum-archive@odin.ietf.org>; Thu, 27 Jul 2000 07:58:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23797;
	Thu, 27 Jul 2000 07:58:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23770
	for <enum@ns.ietf.org>; Thu, 27 Jul 2000 07:58:16 -0400 (EDT)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08484
	for <enum@ietf.org>; Thu, 27 Jul 2000 07:58:14 -0400 (EDT)
Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14])
	by ogma.cisco.com (Postfix) with ESMTP
	id CA3C6A2; Thu, 27 Jul 2000 13:57:44 +0200 (MET DST)
Received: from [10.0.0.2] ([171.70.221.21])
	by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA28279;
	Thu, 27 Jul 2000 13:57:41 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: pfaltstr@nordic.cisco.com
Message-Id: <p04320406b5a5d3fbcb8e@[10.0.0.2]>
In-Reply-To: <39802288.3F5B88B3@americasm01.nt.com>
References: <397BA836.4CF65215@research.telcordia.com>
 <397BA836.4CF65215@research.telcordia.com>
 <4.3.2.20000726154840.00dcf7d0@joy.songbird.com>
 <39802288.3F5B88B3@americasm01.nt.com>
Date: Thu, 27 Jul 2000 04:57:31 -0700
To: "Nicholas Sauriol" <nsauriol@nortelnetworks.com>,
        Dave Crocker <dhc@dcrocker.net>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: Algorithm
Cc: enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 07.52 -0400 00-07-27, Nicholas Sauriol wrote:
>My apologies for the following question, I joined the group rather 
>late, but why remove extra characters and than the '+' in 2 steps, 
>as opposed to simply removing all non-numerical characters?

Because I wanted to keep the '+' for the algorithm in the NAPTR. One 
might in some other (similar) solutions have other characters in the 
phone number which the regular expression works on.

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 28 01:37:02 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16913
	for <enum-archive@odin.ietf.org>; Fri, 28 Jul 2000 01:37:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA22797;
	Fri, 28 Jul 2000 01:35:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA22767
	for <enum@ns.ietf.org>; Fri, 28 Jul 2000 01:35:28 -0400 (EDT)
Received: from joy.songbird.com (IDENT:root@joy.songbird.com [208.184.79.7])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15875
	for <enum@ietf.org>; Fri, 28 Jul 2000 01:35:28 -0400 (EDT)
Received: from dcrocker.dcrocker.net (mg-20425426-112.ricochet.net [204.254.26.112])
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id WAA31959;
	Thu, 27 Jul 2000 22:35:15 -0700
Message-Id: <4.3.2.20000727223402.00b40730@joy.songbird.com>
X-Sender: dhc@joy.songbird.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Thu, 27 Jul 2000 22:34:57 -0700
To: "A.M. Rutkowski" <amr@netmagic.com>
From: Dave Crocker <dhc@dcrocker.net>
Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: IANA
  Consideratio ns
Cc: enum@ietf.org
In-Reply-To: <4.3.2.7.2.20000724130344.00b70750@mail.netmagic.com>
References: <DA5558CC09AED311ABE10000778D757F4C2E37@mailsrv.itu.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Tony,

At INET, last week, a speaker from SAIC said you were no longer associated 
with NSI.

Where have you landed?

d/


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 28 05:30:47 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16421
	for <enum-archive@odin.ietf.org>; Fri, 28 Jul 2000 05:30:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26581;
	Fri, 28 Jul 2000 05:30:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26557
	for <enum@ns.ietf.org>; Fri, 28 Jul 2000 05:30:13 -0400 (EDT)
Received: from relay.cwplc.com (relay.cwplc.com [194.6.6.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16225
	for <enum@ietf.org>; Fri, 28 Jul 2000 05:30:10 -0400 (EDT)
Received: from gb-cwc-brt-msw2.isops.cwcom.co.uk ([148.185.176.7])
	by relay.cwplc.com (Pro-8.9.3/8.9.3) with ESMTP id KAA11521
	for <enum@ietf.org>; Fri, 28 Jul 2000 10:30:19 +0100 (BST)
Received: from gbcwcbrti002.isops.cwcom.co.uk (unverified) by gb-cwc-brt-msw2.isops.cwcom.co.uk
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0001113623@gb-cwc-brt-msw2.isops.cwcom.co.uk> for <enum@ietf.org>;
 Fri, 28 Jul 2000 10:25:04 +0100
Received: by gbcwcbrti002.isops.cwcom.co.uk with Internet Mail Service (5.5.2650.21)
	id <PXMRNZWX>; Fri, 28 Jul 2000 10:14:57 +0100
Message-Id: <29B7C7A8E3E4D111ABDB0000F8086400072BF331@gbcwcbrtm003.isops.cwcom.co.uk>
From: "Rosbotham, Paul" <Paul.Rosbotham@cwcom.co.uk>
To: enum@ietf.org
Subject: [ENUM] Comments to draft-ietf-enum-e164-gstn-np-00
Date: Fri, 28 Jul 2000 10:30:18 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

I have a series of comments to the raft-ietf-enum-e164-gstn-np-00.

Firstly I believe it is a good summary of the NP issues.  I note it has an
ENUM reference, but I'm not sure that the subject matter is covered within
then ENUM remit, indeed the issues the document raise cut across many areas
of study.  However, I understand the logic of introducing the document to
ENUM given NP has arisen extensively in our discussions.

Some detailled comments;

Section 5.2 QoR
It could be instructive to add text to explain why this approach is adopted,
ie to reduce the number of queries that the originating network has to make
to the NPDB (for QoR number of queries = 1 per call to ported number, for
ACQ number of queries = 1 per call to any number, ported or not).

I believe there is an error on Figure 2 as Query on Release is abbreviated
to QoS.

Section 5.4 OR
"This scheme is also called Remote Call Forwarding. "
I would say that Onward Routeing and Remote Call Forward are quite
different.  The former uses [network] datafill on the switch to reroute
calls.  The latter is a stop-gap measure which essentially uses GSTN switch
customer features to forward calls.  I'm not a signalling expert, but I
don't believe RCF is totally transparent, and I don't think it could be used
to access "non-diallable" routeing numbers and modify NOA parameters etc.
I'd prefer if the sentence in question was removed.

Section 5.5 Comparisons of the Four schemes
You've wandered into a minefield here...
The sentences I would query are
"The OR scheme is the least efficient in terms of using the network
resources. " , and
"The ACQ scheme is the most efficient in terms of using the switching and
transmission facilities for the call."

I would not argue with the statements in the context of transmission.
However the situation with GSTN switches varies dramatically according to
individual manufacturer and architecture.  Some switches are optimised
around making external queries (ie IN) and hence are well suited to ACQ
approaches.  On some, however, a significant overhead is incurred in
carrying out an external database lookup (not all are so bad, but on some it
can be 30-40% overhead).  As such, to do this on all calls (ACQ) can require
substantial extra capacity on the GSTN switches, which can outstrip the
additional resources required to onward route the relatively small
percentage of calls that are to ported numbers.  In summary, your statements
are correct in the context of transmission, the situation is not so
clear-cut for switching facilities.

Section 7.2 paragraph
"Please note that all those enhancements are for national use. This is
because number portability is supported within a nation. Within each nation,
the telecommunications industry or the regulatory bodies can decide which
method or methods to use. Number portability related parameters and coding
are never passed across the national boundaries."

This is a very important para, and potentially deserves a section in its own
right.  It must be recognised that the modified parameters, routeing numbers
etc are in general not internationally significant so cannot work across
international boundaries.  In practical terms, whenever "originating
network" is referred to in NP, it means "the first network in the call path
in the country of the ported number".  This has profound implications for
the IP world where the concept of national differences doesn't normally
apply so much.

Section 8
Netherlands : QoS is referred to when I believe QoR is meant.  I believe
that in practical terms calls may be onward routed via KPN (although the
responsibility for routeing lies with the originator), but think it may be
worth checking this.
Spain : Same comment regards QoS/QoR.  Again, in practical terms calls are
onward routed via the donor (although the responsibility for routeing lies
with the originator).

General
There is a section 9 on how NP facilitates number pooling.  It may be worth
having a section on how NP facilitates the introduction of Individual Number
Assignment (ie the assignment of individual numbers to operators for onward
assignment to customers, or even assignment directly to customers, bypassing
operators)

Hope all this is of value,

Paul Rosbotham

Cable & Wireless Plc

**********************************************************************
This message may contain information which is confidential or privileged.
If you are not the intended recipient, please advise the sender immediately
by reply e-mail and delete this message and any attachments
without retaining a copy.  

**********************************************************************

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 28 10:30:31 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01040
	for <enum-archive@odin.ietf.org>; Fri, 28 Jul 2000 10:30:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00304;
	Fri, 28 Jul 2000 10:29:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00270
	for <enum@ns.ietf.org>; Fri, 28 Jul 2000 10:29:47 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00788
	for <ENUM@ietf.org>; Fri, 28 Jul 2000 10:29:45 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-27.cc.telcordia.com [128.96.13.27])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6SESPR14059;
	Fri, 28 Jul 2000 10:28:26 -0400 (EDT)
Message-ID: <39819888.4EF8980A@research.telcordia.com>
Date: Fri, 28 Jul 2000 10:28:24 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Richard Shockey <rshockey@ix.netcom.com>
CC: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>,
        Pfautz@research.telcordia.com, Penn.L@research.telcordia.com,
        NNAD <ppfautz@att.com>, ENUM@ietf.org
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
References: < <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
	 <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com> <4.3.1.2.20000723070731.00d91330@127.0.0.1>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit



Richard Shockey wrote:

> At 01:43 PM 7/22/2000 -0700, Patrik Fältström wrote:
> >At 12.43 -0400 00-07-21, Pfautz, Penn L, NNAD wrote:
> >>Just to clarify, changes to the LNP SMS are supposed to be reflected in
> >>carrier networks within 15 minutes of activation.
> >
> >Can you explain what "LNP SMS" is? If you have the time and energy, both
> >when you talk about a traditional telephony network, one based on SIP and
> >one based on H.323 (if there is a difference).
> >
> >   paf
>
> LNP SMS is the Local Number Portability Service Management System. The
> system NeuStar operates to propagate Ported Numbers to Service Control
> Points within the North American IN.

Richard,

I would like to further clarify that in North America, LSMS is operated either
by the service provider itself or through a service bureau, NOT by the NPAC
administrator.  The NPAC administrator operates the regional NPACs, which also
has an SMS by itself. A regional NPAC SMS communicates with the LSMS systems
of that region. Once a request for update is sent from the NPAC SMS to a LSMS,
the update has to be completed within 15 minutes.

Cheers,

--Hong


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 28 10:50:27 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06117
	for <enum-archive@odin.ietf.org>; Fri, 28 Jul 2000 10:50:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00911;
	Fri, 28 Jul 2000 10:49:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00882
	for <enum@ns.ietf.org>; Fri, 28 Jul 2000 10:49:25 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05866
	for <ENUM@ietf.org>; Fri, 28 Jul 2000 10:49:21 -0400 (EDT)
Received: from research.telcordia.com (uunet-13-27.cc.telcordia.com [128.96.13.27])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6SEmeR14998;
	Fri, 28 Jul 2000 10:48:41 -0400 (EDT)
Message-ID: <39819D4A.601B46B@research.telcordia.com>
Date: Fri, 28 Jul 2000 10:48:42 -0400
From: Hong Liu <lhong@research.telcordia.com>
Organization: Telcordia Technologies Applied Research
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Richard Shockey <rshockey@ix.netcom.com>
CC: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>,
        Pfautz@research.telcordia.com, Penn.L@research.telcordia.com,
        NNAD <ppfautz@att.com>, ENUM@ietf.org
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt
References: <397ACCB2.69A2B88B@research.telcordia.com>
	 <012F722EA7AFD211860B00E0290C6C5B04A5EF3A@njc240po04.mt.att.com>
	 <p0432040fb59fb7d21b6c@[10.0.0.9]>
	 <397ACCB2.69A2B88B@research.telcordia.com> <4.3.1.2.20000723151022.00d9b9a0@127.0.0.1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

Richard,

I would like to know more about this. Do you have any examples? I assume that
you are not talking about personal 800 numbers or UPT numbers. Thanks!

--Hong

Richard Shockey wrote:

> For instance ..in many countries telephone numbers are directly issued to
> subscribers, who then may choose their carrier of choice unlike North
> America and most Asian countries where TN's are issued by carriers to
> subscribers...its a subtle difference but rather important in the countries
> where this is common.


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Jul 28 15:46:11 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27636
	for <enum-archive@odin.ietf.org>; Fri, 28 Jul 2000 15:46:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08028;
	Fri, 28 Jul 2000 15:31:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07997
	for <enum@ns.ietf.org>; Fri, 28 Jul 2000 15:31:50 -0400 (EDT)
Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22696
	for <enum@ietf.org>; Fri, 28 Jul 2000 15:31:47 -0400 (EDT)
Received: by dnspri.npac.com; id OAA27629; Fri, 28 Jul 2000 14:31:48 -0500 (CDT)
Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0)
	id xma027534; Fri, 28 Jul 00 14:31:34 -0500
Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0)
	id <PHQG7DMJ>; Fri, 28 Jul 2000 14:30:47 -0500
Message-ID: <ED88182BFF78D211A4D800A0C9E9435CB1C5F9@dc02.npac.com>
From: James Yu <james.yu@neustar.com>
To: "'Rosbotham, Paul'" <Paul.Rosbotham@cwcom.co.uk>
Cc: enum@ietf.org
Subject: RE: [ENUM] Comments to draft-ietf-enum-e164-gstn-np-00
Date: Fri, 28 Jul 2000 14:29:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Paul,

Thanks for the good comments.  Please see the responses below.

James

> -----Original Message-----
> From: Rosbotham, Paul [mailto:Paul.Rosbotham@cwcom.co.uk]
> Sent: Friday, July 28, 2000 5:30 AM
> To: enum@ietf.org
> Subject: [ENUM] Comments to draft-ietf-enum-e164-gstn-np-00
> 
> 
> I have a series of comments to the raft-ietf-enum-e164-gstn-np-00.
> 
> Firstly I believe it is a good summary of the NP issues.  I 
> note it has an
> ENUM reference, but I'm not sure that the subject matter is 
> covered within
> then ENUM remit, indeed the issues the document raise cut 
> across many areas
> of study.  However, I understand the logic of introducing the 
> document to
> ENUM given NP has arisen extensively in our discussions.
> 
> Some detailled comments;
> 
> Section 5.2 QoR
> It could be instructive to add text to explain why this 
> approach is adopted,
> ie to reduce the number of queries that the originating 
> network has to make
> to the NPDB (for QoR number of queries = 1 per call to ported 
> number, for
> ACQ number of queries = 1 per call to any number, ported or not).


Section 5.2 addresses the QoR scheme without any comments.  Your point on
the QoR scheme and the ACQ scheme can be found in the last paragraph of
Section 5.5 for ported numbers.  But it is certainly a good point to add a
discussion about the merit of not generating the NPDB queries for non-ported
numbers when using the QoR, dropback and OR schemes.

> 
> I believe there is an error on Figure 2 as Query on Release 
> is abbreviated
> to QoS.

Will correct.

> 
> Section 5.4 OR
> "This scheme is also called Remote Call Forwarding. "
> I would say that Onward Routeing and Remote Call Forward are quite
> different.  The former uses [network] datafill on the switch 
> to reroute
> calls.  The latter is a stop-gap measure which essentially 
> uses GSTN switch
> customer features to forward calls.  I'm not a signalling 
> expert, but I
> don't believe RCF is totally transparent, and I don't think 
> it could be used
> to access "non-diallable" routeing numbers and modify NOA 
> parameters etc.
> I'd prefer if the sentence in question was removed.

We'll remove the sentence.  In the U.S., it may be called Route Indexing
instead of Remote Call Forwarding.

> 
> Section 5.5 Comparisons of the Four schemes
> You've wandered into a minefield here...
> The sentences I would query are
> "The OR scheme is the least efficient in terms of using the network
> resources. " , and
> "The ACQ scheme is the most efficient in terms of using the 
> switching and
> transmission facilities for the call."
> 
> I would not argue with the statements in the context of transmission.
> However the situation with GSTN switches varies dramatically 
> according to
> individual manufacturer and architecture.  Some switches are optimised
> around making external queries (ie IN) and hence are well 
> suited to ACQ
> approaches.  On some, however, a significant overhead is incurred in
> carrying out an external database lookup (not all are so bad, 
> but on some it
> can be 30-40% overhead).  As such, to do this on all calls 
> (ACQ) can require
> substantial extra capacity on the GSTN switches, which can 
> outstrip the
> additional resources required to onward route the relatively small
> percentage of calls that are to ported numbers.  In summary, 
> your statements
> are correct in the context of transmission, the situation is not so
> clear-cut for switching facilities.

The discussion in this section is about the number of the switches and
transmission facilities involved in the four schemes; however, however we
understand your point and will add appropriate wording to the next version
of the draft.

 
> 
> Section 7.2 paragraph
> "Please note that all those enhancements are for national use. This is
> because number portability is supported within a nation. 
> Within each nation,
> the telecommunications industry or the regulatory bodies can 
> decide which
> method or methods to use. Number portability related 
> parameters and coding
> are never passed across the national boundaries."
> 
> This is a very important para, and potentially deserves a 
> section in its own
> right.  It must be recognised that the modified parameters, 
> routeing numbers
> etc are in general not internationally significant so cannot 
> work across
> international boundaries.  In practical terms, whenever "originating
> network" is referred to in NP, it means "the first network in 
> the call path
> in the country of the ported number".  This has profound 
> implications for
> the IP world where the concept of national differences 
> doesn't normally
> apply so much.

Yes.  Since IP has no national boundaries, the IP networks may get the
"national" routing numbers via the NPDB queries and need to route the calls
via the IP networks to the terminating GSTN GWs.  So a mechanism in the IP
(e.g., "tel" URL) is needed to carry NP related information across the IP
network and "international" routing numbers may need to be carried and used
by the IP networks to route the calls and make the GSTN GW selection (e.g.,
TRIP).  draft-yu-tel-url-00.txt [TEL] was submitted on 7/11, which proposes
how the NP related information can be carried in the enhanced "tel" and
"fax" URLs. 

> 
> Section 8
> Netherlands : QoS is referred to when I believe QoR is meant. 

Will correct.

>  I believe
> that in practical terms calls may be onward routed via KPN 
> (although the
> responsibility for routeing lies with the originator), but 
> think it may be
> worth checking this.
> Spain : Same comment regards QoS/QoR.  Again, in practical 
> terms calls are
> onward routed via the donor (although the responsibility for 
> routeing lies
> with the originator).

Will check.   All are welcomed to contact the authors for updating the
information that may be outdated, incomplete or incorrect.

> 
> General
> There is a section 9 on how NP facilitates number pooling.  
> It may be worth
> having a section on how NP facilitates the introduction of 
> Individual Number
> Assignment (ie the assignment of individual numbers to 
> operators for onward
> assignment to customers, or even assignment directly to 
> customers, bypassing
> operators)

We'll try to clarify that in the next version of the draft.

> 
> Hope all this is of value,
> 
> Paul Rosbotham
> 
> Cable & Wireless Plc
> 
> **********************************************************************
> This message may contain information which is confidential or 
> privileged.
> If you are not the intended recipient, please advise the 
> sender immediately
> by reply e-mail and delete this message and any attachments
> without retaining a copy.  
> 
> **********************************************************************
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum
> 

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Jul 29 11:06:47 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13567
	for <enum-archive@odin.ietf.org>; Sat, 29 Jul 2000 11:06:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25124;
	Sat, 29 Jul 2000 11:04:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25093
	for <enum@ns.ietf.org>; Sat, 29 Jul 2000 11:04:11 -0400 (EDT)
Received: from exchange.chaos.com ([206.5.17.8])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12746
	for <enum@ietf.org>; Sat, 29 Jul 2000 11:04:10 -0400 (EDT)
Received: from [206.169.243.90] by exchange.netmagic.com (NTMail 5.06.0014/NT2627.00.5ef58ba0) with ESMTP id shbgaaaa for enum@ietf.org; Sat, 29 Jul 2000 11:04:03 -0400
Message-Id: <4.3.2.7.2.20000729045545.03932868@mail.netmagic.com>
X-Sender: amr@mail.netmagic.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 29 Jul 2000 05:03:59 -1000
To: Dave Crocker <dhc@dcrocker.net>
From: "A.M.Rutkowski" <amr@netmagic.com>
Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: IANA
  Consideratio ns
Cc: enum@ietf.org
In-Reply-To: <4.3.2.20000727223402.00b40730@joy.songbird.com>
References: <4.3.2.7.2.20000724130344.00b70750@mail.netmagic.com>
 <DA5558CC09AED311ABE10000778D757F4C2E37@mailsrv.itu.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Dave,

>At INET, last week, a speaker from SAIC said you were no longer associated 
>with NSI.

You must have misunderstood.  He was no doubt
saying that NSI is no longer associated with
SAIC.  It's now owned by VeriSign, and we all
report to Stratton Sclavos.  There are significant
synergies between "VeriSign West" and VeriSign East"
which we expect to manifest in the ENUM arena.

best regards,
tony
V.P. for Internet Strategy
VeriSign-NSI


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Jul 29 11:26:06 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19472
	for <enum-archive@odin.ietf.org>; Sat, 29 Jul 2000 11:26:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25292;
	Sat, 29 Jul 2000 11:25:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25262
	for <enum@ns.ietf.org>; Sat, 29 Jul 2000 11:25:43 -0400 (EDT)
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19357
	for <enum@ietf.org>; Sat, 29 Jul 2000 11:25:43 -0400 (EDT)
Received: from computer.ix.netcom.com ([209.138.158.125])
	by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id LAA32445;
	Sat, 29 Jul 2000 11:25:42 -0400 (EDT)
Message-Id: <4.3.1.2.20000729095848.00c05750@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Sat, 29 Jul 2000 10:12:27 -0500
To: enum@ietf.org
From: Richard Shockey <rshockey@ix.netcom.com>
Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>,
        Scott Bradner <sob@harvard.edu>, klensin@jck.com, mankin@east.isi.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Enum] Revised ENUM FAQ
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org


On the basis of some more comments from people and the need to clarify the 
nature of the E.164 numbering plan. I've made a quick revision to the FAQ.

Some highlights are more detailed notes that there is no relation between 
the e.164 numbering plan and actual telephony routing and that the list of 
cc is rather static.

I've included information on the list of National Regulatory Authorities 
maintained by the ITU as possible contacts for national ENUM authorities 
and other minor edits.

At the request of the AD's future versions of this document will be split 
up into 1. ENUM Protocol and Operations 2. ENUM Administration and 
Delegation issues.

Rather than submit your mailboxes to another large file d/l Dave Crocker 
has been kind enough to lend some space on his server.

A copy of the revised faq is at 
<http://www.brandenburg.com/enum/draft-shockey-enum-faq-01.txt>.


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Jul 29 14:48:05 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02540
	for <enum-archive@odin.ietf.org>; Sat, 29 Jul 2000 14:48:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27223;
	Sat, 29 Jul 2000 14:46:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27145
	for <enum@ns.ietf.org>; Sat, 29 Jul 2000 14:46:11 -0400 (EDT)
Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02324
	for <enum@ietf.org>; Sat, 29 Jul 2000 14:46:10 -0400 (EDT)
From: john.loughney@nokia.com
Received: by esebh01nok with Internet Mail Service (5.5.2650.10)
	id <PZQMB1HV>; Sat, 29 Jul 2000 21:46:11 +0300
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE104A2C964@eseis04nok>
To: rshockey@ix.netcom.com, enum@ietf.org
Subject: RE: [Enum] ENUM FAQ
Date: Sat, 29 Jul 2000 21:46:09 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Richard,

Thanks for the FAQ.  I've only done a quick reading of it,
but I think it should be very useful.  One thing that I
would like added would be more about security / privacy.

Is there a way to grant/deny access to certain DNS
records?  I haven't seen any.  My 'fear' would be that
I would have many services in my personal ENUM DNS record
and then be harrassed by all sorts of new spam, SIP SPAM,
email SPAM, telemarketers, etc.

cheers,
John

> -----Original Message-----
> From: EXT Richard Shockey [mailto:rshockey@ix.netcom.com]
> Sent: July 26, 2000 23:47
> To: enum@ietf.org
> Subject: [Enum] ENUM FAQ
> 
> 
> Since our work may be entering a new phase ..I've taken the 
> liberty to 
> trying to pull together some thinking about ENUM into a FAQ.
> 
> This will probably not be a WG document but if any of you 
> would like to 
> contribute questions answers or comment on it generally you 
> are welcome to 
> do so.
> 
> ################
> 
> 
> 
> 
> ENUM Working Group                                            
>   Richard Shockey
> Internet-Draft: DRAFT-SHOCKEY-ENUM-FAQ-00.TXT           NeuStar, Inc
> Expiration <1/2001>                                           
>   July 26, 2000
> 
> 
>                          FREQUENTLY ASKED QUESTIONS ABOUT ENUM
> 
> This is a very preliminary draft.  It has not been reviewed 
> or accepted by 
> the working group.  Comments are eagerly sought, as are 
> suggestions for 
> additional questions and alternative answers.
> 
> Status Of This Memo
> 
> This document is an Internet-Draft and is in full conformance with all
> provisions of Section 10 of RFC2026.
> 
> Internet-Drafts are working documents of the Internet Engineering Task
> Force (IETF), its areas, and its working groups.  Note that 
> other groups 
> may also distribute working documents as Internet-Drafts.  
> Internet-Drafts 
> are draft documents valid for a maximum of six months and may 
> be updated, 
> replaced, or obsoleted by other documents at any time.  It is 
> inappropriate 
> to use Internet-Drafts as reference material or to cite them 
> other than as 
> "work in progress."
> 
> The list of current Internet-Drafts can be accessed at
> http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
> Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
> 
> This document and related documents are discussed on the IETF 
> Enum mailing 
> list. To join the list, send mail to <mailto:enum-
> request@ietf.org?body=subscribe>.
> 
> To contribute to the discussion, send mail to  
> <mailto:enum@ietf.org> The 
> Enum working group charter, including the current list of 
> group documents, 
> can be found at http://www.ietf.org/html.charters/enum-charter.html.
> 
> 
> Copyright Notice
> Copyright (C) The Internet Society (2000).  All Rights Reserved.
> 
> ABSTRACT
> 
> The IETF ENUM work group has been chartered to develop 
> protocols that map 
> telephone numbers to resources typically found on the 
> Internet , such as 
> URI's, using the Domain Name Service. It has been proposed 
> that a global 
> ENUM service be created in the e164.arpa domain. How 
> e164.arpa should be 
> organized and administered is now a serious issue confronting 
> the Internet 
> Community.  This document is provided as a list of common 
> questions, and 
> their answers, concerning E.164 numbers and their use on the 
> Internet.  Knowledge of Domain
> Name Service technology is assumed.
> 
> INTRODUCTION
> 
> The IETF ENUM work group has been chartered to develop 
> protocols that map 
> telephone numbers to Internet resources.  The working group 
> charter is 
> specified at:
> 
> <http://www.ietf.org/html.charters/enum-charter.html>
> 
> A Goals and Requirements specification is under active discussion.
> The current draft is:
> 
> <http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-01.txt>
> 
> The central ENUM protocol document is:
> 
> <http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-02.txt>.
> 
> It describes the technique whereby a globally unique E.164 
> telephone number 
> is placed under a single DNS administrative domain. Using classic DNS 
> resolution, a client application could then discover 
> resources associated 
> with that number from NAPTR or SRV Resource Records.
> 
> Several application developers and telecommunications service 
> providers 
> have expressed interest in quickly deploying ENUM based services.
> 
> It has been proposed that a global ENUM service be created in 
> the e164.arpa 
> domain.
> 
> How e164.arpa should be organized and administered is now a 
> serious issue 
> confronting the Internet Community.
> 
> FREQUENTLY ASKED QUESTIONS
> 
> WHAT IS ENUM?
> 
> ENUM stands for Telephone Number Resolution. It is a 
> chartered WG of the 
> IETF <http://www.ietf.org>.  The reason the work group exists 
> is detailed 
> in its charter. The URL is listed above.
> 
> There have been numerous experimental trials of DNS based 
> resolution of
> telephone number resources. The most significant of those was 
> the TPC.INT 
> fax experiment described in RFC 1709. Many of the concepts 
> use by ENUM came 
> out of that early work
> 
> 
> WHAT BENEFITS DOES ENUM GIVE TO USERS?
> 
> The main benefits are:
> 
> ENUM enables calling users or entities to make a selection 
> from the range 
> of services that are available especially over the Internet for
> communicating with a particular person or entity when the calling user
> knows only their telephone number.
> 
> ENUM enables users to access Internet based services and 
> resources from
> ordinary telephones where they are only be able to input digits
> 
> ENUM enables users to specify their preferences for receiving incoming
> communications (eg specifying a preference for voicemail 
> messages over live 
> calls or indicating a destination for call forwarding). ENUM 
> will give much 
> improved user control over communications.
> 
> There are many potential applications for ENUM and some are 
> discussed in 
> this document.
> 
> WHAT IS E.164?
> 
> E.164 is the international telephone numbering plan [Document 
>  ITU-T E.164] 
> written and administered by the International 
> Telecommunication Union (ITU) 
> in Geneva <http://www.itu.int>. The plan specifies the 
> format, structure, 
> and administrative hierarchy of telephone numbers. At the 
> root of the E.164 
> administrative hierarchy, the ITU issues country codes to sovereign 
> national entities and thereby allocates new telephony 
> numbering resources 
> as needed. In addition there are other allocations for services and 
> networks.  Administration of telephone numbers within each country is 
> officially governed by the appropriate national telecommunications 
> regulatory agency (e.g. FCC in the US,
> CRTC in Canada, Oftel in UK).  The regulator or their 
> designated contractor 
> performs the actual national number resource administration itself.
> 
> HOW DOES ENUM WORK?
> 
> The enum solution  is driven , in part by the fact that most 
> telephony 
> users have telephone keypads [ 12 digit ] to work with.
> 
> 1. A phone number is translated intoE.164 form by in 
> concluding country 
> code or area/city code, e.g. 918-9020 dialed in St. Louis would be 
> translated to +1-314-918-9020, where +1 is the North American 
> country code.
> 2. Remove all character parts from the digits. Example: 13149189020
> 3. Reverse the order of the digits. Example: 02098194131
> 4. Put dots (".") between each digit. Example: 0.2.0.9.8.1.9.4.1.3.1
> 5. Append the domain "e164.arpa" to the end.  Example: 
> 0.2.0.9.8.1.9.4.1.3.1.e164.arpa
> 6. Perform a DNS query on this domain
> 7. Retrieve relevant NAPTR Resource records from the Name 
> Server for this 
> number and perform whatever relevant application required.
> 
> WHY THE FUNNY REVERSAL OF THE NUMBER AND WHAT ARE ALL OF 
> THOSE DOTS FOR?
> 
> Each dot separates the number into administrative "domains" 
> or zones in DNS 
> terms. This accommodates delegation of authority at varying points 
> throughout the e164.name space thereby avoiding the 
> imposition of either a 
> fixed delegation scheme worldwide or requiring clients to 
> know that scheme 
> in order to know where to put the dots. Delegation in a DNS name is 
> structured from right to left. This
> is very important. See: 
> <http://www.rfc-editor.org/rfc/rfc2672.txt> for 
> more details
> 
> AM I GOING TO HAVE TO TYPE IN THOSE DOTS AND REVERSED NUMBERS 
> TO USE ENUM?
> 
> Definitely not!  Your application will take care of all of 
> this for you. 
> You just enter in a phone number like you always do, into whatever 
> application or device that supports ENUM, and it  will take 
> care of the 
> conversion.
> 
> WHY THE .ARPA TOP LEVEL DOMAIN?
> 
> The .arpa domain has been designated to be used for Internet 
> Infrastructure 
> purposes. It is managed by the IANA in cooperation with the Internet 
> technical community under the guidance of the Internet 
> Architecture Board. 
> The e164.arpa domain is believed to be the most appropriate 
> place to host 
> the e164 namespace on the Internet.  ENUM constitutes an 
> infrastructure 
> support function by virtue of it providing a set of DNS-based 
> resource 
> directories, referenced by phone
> number, for use by various ENUM-enabled application clients (e.g. 
> telephones, SIP servers, voice messaging systems).  ENUM will 
> not be used 
> directly by people as a new way of navigating to web sites.  
> Consequently, 
> ENUM is an infrastructure application appropriate for use within the 
> designated .arpa domain established for these purposes.
> 
> WHAT ARE SRV AND NAPTR RECORDS?
> 
> These are DNS Resource Records that will contain information 
> about what 
> Internet resources, services or applications that are 
> associated with a 
> particular phone number. Subscribers determine what those 
> services are.
> 
> For more information, see:
> 
> SRV :  <http://www.rfc-editor.org/rfc/rfc2782.txt>
> NAPTR  :  
> http://search.ietf.org/internet-drafts/draft-ietf-urn-naptr-rr-03.txt
> 
> WHAT KINDS OF APPLICATIONS COULD USE ENUM?
> 
> Since ENUM provides a generic way to perform telephone number-based 
> resource discovery, there are lots of examples of ENUM-enabled 
> applications, but several have come to the forefront. The 
> voice messaging 
> industry has been hard at work developing a comprehensive 
> mechanism by 
> which voice mail systems could exchange messages over IP 
> networks. This 
> work is called VPIM, or Voice Profile for Internet Messaging. 
> http://www.ietf.org/html.charters/vpim-charter.html. The
> industry has been looking for a way to discover the host name 
> and domain 
> for Internet based voice mail servers. The problem has been 
> that a typical 
> voice mail user only has a telephone number and a telephone 
> keypad to work 
> with. ENUM permits these VPIM servers to locate each other 
> and exchange 
> messages.
> 
> Clearly the most active interest in ENUM service has been in Internet 
> Telephony. It has been a long standing goal of the Voice over 
> IP (VoIP) 
> industry to make a phone call over the Internet as simple to 
> make as a 
> regular PSTN call.
> 
> ENUM links a telephone number to a host or resources on the 
> Internet that 
> can connect the call, either end to end over IP networks or through a 
> designated gateway to the PSTN. This would be very useful for 
> connecting 
> SIP <http://www.ietf.org/html.charters/sip-charter.html> or 
> H.323-capable 
> endpoints that exist across domain boundaries.
> 
> ENUM is general enough that multiple discrete services 
> (applications) may 
> all be associated with the same telephone number at the same 
> time, each 
> application associated with their own unique endpoint resources as 
> provisioned in ENUM, assuming the subscriber has the 
> appropriate clients 
> supporting those services.  ENUM does not require that all 
> such telephone 
> number-based services be provided by the same service 
> provider (telco, ISP, 
> whatever), even though the subscriber's right to use that particular 
> telephone number may only flow from their having subscribed to one of 
> them.Won't ENUM telephone routing confuse the
> regular, PSTN routing system?
> 
> ENUM facilitates the discovery of resources associated with a 
> telephone 
> number, and hence facilitates how various applications will identify 
> appropriate peer servers associated with an intended 
> end-user.  It does 
> not, however, impact how those applications will operate once 
> the location 
> of an end-user associated application server has been 
> established.  Consequently, ENUM doesn't affect application-level 
> functions, such as call routing, signaling, etc., regardless
> of the underlying application technology employed (ISUP, SIP, 
> H.323).  . 
> [For example, see TRIP 
> <http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-02.txt>]. 
> However it is possible that a telephone company call-routing 
> mechanism 
> could use ENUM technology as well.
> 
> It is a core principle that in providing a unified resource discovery 
> service, that ENUM will not change the existing right-to-use 
> rules and 
> principles for telephone numbers.  ENUM is not intended to change how 
> telephone numbers are administered, but instead facilitate a 
> wide range of 
> applications using phone numbers as subscriber names.  
> Lastly, ENUM will 
> not interfere with existing PSTN functions and technology, 
> such as circuit 
> switching, SS7 (ISUP or TCAP), or IN (Intelligent Networking), where 
> similar resource discovery activities are performed through 
> the PSTN legacy 
> technologies.
> 
> WHAT PROTOCOL DOES ENUM USE FOR INTERNET TELEPHONY?
> 
> ENUM itself is "protocol agnostic" because it's application 
> agnostic.  It 
> does not specify what applications a particular telephone number is 
> associated with, but instead provides a unified way of discovering 
> resources associated with it.  For example it can work with 
> either H.323 or 
> the Session Initiation Protocol [SIP].See 
> <http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-00.txt>
> for further details.
> 
> I'VE HEARD THIS VOICE OVER IP STUFF DOESN'T WORK.? THERE ARE LOTS OF 
> ARTICLES IN THE TECHNICAL PRESS THAT SAY IT JUST DOESN'T WORK.
> 
> VoIP is an evolving technology that is in an early stage of 
> development but 
> rapidly improving. It is only a question of when, not if, Internet 
> Telephony will become a reality, fully integrated with the 
> existing, global 
> telephone service.  This is an orthogonal issue to ENUM, as 
> ENUM is not 
> intended solely to facilitate VoIP, but a range of 
> applications where a 
> telephone number is used as a subscriber name.
> 
> DO I "OWN" MY PHONE NUMBER?
> 
> The ITU provides guidelines for the structure of phone numbers.  They 
> allocate part of the structure of the phone number, the 
> country code, to 
> countries.  Each country's national regulatory agency (NRA) 
> determines the 
> remaining structure of the phone numbers within their 
> country.  The NRA 
> also designates a national number administrator (NNA), in 
> many countries 
> the NRA is the NNA.  The NNA allocates blocks of numbers to 
> communications 
> service providers.  Communications service providers allocate 
> numbers to 
> their users.  When a user disconnects
> their service, after an appropriate aging interval, the 
> number becomes an 
> available resource to the service provider for the purposes 
> of reassignment 
> to a new or different user.
> 
> It is generally accepted that there are  no property rights 
> associated with 
> numbers. That means you cannot sell your telephone number to 
> someone else, 
> unlike the fact that you could sell an Internet domain name 
> under your 
> control.  As a matter of fact user's phone numbers get 
> changed without 
> their consent quite frequently.  In the US, for example, it 
> results from an 
> area code split, where the 3-digit area code prefix is changed in the 
> user's geographic area, but usually not the last 7 digits.  
> However, when 
> this happens, the user no longer
> has the same 10-digit phone number they once had.
> 
> It is becoming more common for users to have more control 
> over their phone 
> numbers.  In many countries with rules and regulations about 
> telephone 
> number portability, you can take your telephone number from 
> carrier to 
> carrier or from service type to service type (e.g., land-line 
> to mobile) as 
> you wish. Regulations vary from country to country.
> 
> Within the ENUM community it is the general view that the telephone 
> subscriber representatives [ISP's, carriers, etc],  would be 
> allowed to
> determine what resources are associated  with that telephone 
> number within 
> the ENUM service.
> 
> 
> WHAT HAPPENS TO THE NUMBER WHEN A SUBSCRIBER PORTS FROM ONE SERVICE 
> PROVIDER TO ANOTHER?
> 
> When a number ports, the service provider of record changes.  
> That is the 
> industry now recognizes a different service provider as the 
> holder for that 
> particular number.  This is important for routing and billing 
> purposes.
> 
> The subscriber should still be able to continue using their 
> ENUM-enabled 
> services, assuming their new service provider(s) support 
> them.  Naturally, 
> the actual location of server resources identified by ENUM 
> will likely 
> change as the subscriber changes any of the underlying 
> service providers.
> 
> When the user disconnects the number goes back to the original service
> provider's inventory, not to the new service provider's inventory.
> 
> WHAT HAPPENS TO THE ENUM SERVICES WHEN A SUBSCRIBER CANCELS 
> TELEPHONE SERVICE?
> 
> As we now know the number returns to the communications 
> service provider's 
> inventory for the purposes of reassignment.  The subscriber 
> that cancels 
> their telephone service will have to cancel the associations 
> that number 
> has with all ENUM services, even those provided by other service 
> providers.  If this was not done the new user of that 
> telephone number 
> could have a conflict with the old user.  On the other hand, 
> where number 
> portability is available, a user has the option of porting 
> their number 
> over to a new service provider instead of canceling their 
> existing service 
> and losing their current number.
> 
> COULD ENUM BE USED TO PROVIDE TELEPHONE NUMBER PORTABILITY?
> 
> In those countries that do not yet have a centralized database 
> administration service, having a shared directory service 
> like ENUM might 
> be of interest.  However, ENUM is not intended to serve this 
> function, as 
> there are very
> significant technical, regulatory, security, and operational 
> limitations in 
> using ENUM for this purpose.  ENUM is a shared resource 
> discovery service, 
> not an industry provisioning service.  In most countries where number 
> portability is deployed, telephone service providers are 
> generally required 
> to comply with regulatory/industry processes, procedures, and 
> systems, 
> regardless of the underlying technology they employ for 
> telephony service 
> delivery (SIP, H.323, circuit-switched, or string-and-cans).  
> How ENUM is 
> administered in those countries will also likely require mirroring of 
> provisioning rules (e.g. anti-slamming) employed for number 
> portability and 
> number administration so as to ensure that service providers using 
> ENUM-enabled services do not violate applicable regulatory rules or 
> industry guidelines.  ENUM is another downstream use of numbering 
> provisioning and administration activities, and will need to 
> be deployed 
> consistent with applicable national requirements, it does not 
> create an 
> alternate numbering universe with its own set of rules and policies.
> 
> HOW IS THE USER OF A NUMBER AUTHENTICATED?
> 
> Users could be corporations, individuals, government 
> agencies, military, 
> and hosts of other non-individual users.  Service providers typically 
> assign large blocks of numbers to these entities.  The 
> telecom manager 
> within these entities then assigns numbers to users.  So even 
> the service 
> providers cannot identify the users for a very large portion of the 
> allocated numbers.
> 
> This is an unresolved issue but one that must be resolved prior to 
> deploying a robust and secure ENUM service.  It's likely that 
> the service 
> provider that allocated the number(s) to the user will be 
> involved in the 
> process of authentication.
> 
> WELL WHAT ABOUT PRIVATE NUMBERING PLANS WITHIN A COMPANY?
> 
> Excellent question. The ENUM protocol can be used in private 
> numbering 
> plans the same way it can be used in the public E.164 number 
> plan.  The 
> Internet Telephony gateway or proxy needs some intelligence 
> to "decode" a 
> particular dialing string and then decide how to look up 
> resources for that 
> particular number. Instead of looking for resources in e164.arpa the 
> gateway or proxy would look for SRV or NAPTR records for 
> private numbers 
> under some other structure, such as
> e164.bigcompany.com .
> 
> WHAT ABOUT EMERGENCY SERVICES LIKE 911 OR 112 [EUROPE]?
> 
> In general, emergency service numbers are "access codes" and 
> not "E.164
> numbers", and will not be part of ENUM services.
> 
> HOW WILL THE E164.ARPA DOMAIN BE ORGANIZED?
> 
> One convenient way of doing this would be to delegate 
> according to the 243 
> country codes designated by the ITU.  It's important to understand, 
> however, that delegation in DNS can occur at any digit, or 
> zone domain in 
> DNS terms
> 
> So within the root e164.arpa there would be an NS listing for 
> 1.e164.arpa 
> representing the top level of the North American Numbering Plan. [US, 
> Canada, and several Caribbean countries]
> 
> A NS listing for -.4.4.e164.arpa - representing the top level 
> (44) of the UK
> A NS listing for - 4.6.e164.arpa - representing the top level (46) 
> of  Sweden.
> A NS listing for - 8.1.e164.arpa - representing the top level 
> (81) of Japan.
> A NS listing for - 8.5.3.e164.arpa - representing the top 
> level (358) of
> Finland.
> 
> At the national TN/NS level further NS delegation [DNAME, 
> CNAME, PTR] can 
> occur to enterprises, TN/NS application service providers, 
> carriers, and 
> even individuals who have DNS servers in their house.
> 
> WHO WILL ADMINISTER THESE NATIONAL TELEPHONE NUMBER NAME SERVERS?
> 
> There are many competent companies or organizations that can 
> operate these 
> servers. A number of companies have already come forward to 
> express their 
> interest in running these servers, initially free of charge and on an 
> experimental basis, until such time as consensus can be 
> reached on how this 
> system is to ultimately organize.
> 
> Some theories on how this system will be organized on a 
> permanent basis 
> will be discussed a little later in this FAQ.  There are a number of 
> regulatory constraints in various countries that might apply 
> on the ENUM 
> administrator, name service operators, as well as delegation 
> policies below 
> the national level.  For example, where local telephony 
> service competition 
> and number portability are being deployed in a country, it is 
> not unusual 
> that a neutral third party is required to provide master database 
> administration services, and a requirement for anti-slamming and 
> non-reliance on competing carriers for routing or
> resolution functions.
> 
> AM I ULTIMATELY GOING TO HAVE TO PAY TO HAVE MY TELEPHONE NUMBER ENUM
> PROVISIONED?
> 
> Probably yes, but most likely the costs will be indirectly recovered 
> through the underlying prices for ENUM-enabled services that 
> subscribers 
> pay. This is a DNS-based system. If you want a domain name 
> registered in 
> DNS someone must pay for that. Listing telephone numbers will be no 
> different.  Whether the cost will be charged directly to the 
> subscriber or 
> will be an indirect charge as part of some larger services 
> will depend on 
> those offering the services.
> 
> Remember you do not have to ENUM list your phone number. ENUM 
> would be a 
> subscriber-controlled "opt-in" system to "announce", over the 
> Internet, the 
> availability of a particular telephone number to accept 
> service sessions 
> and how to manage those sessions as a result of having 
> subscribed to an 
> ENUM-enabled service. If you do not have an Internet 
> telephony device or 
> service you will likely not need to list your number.  On the 
> other hand, 
> subscribers may not necessarily be aware they've subscribed to such a 
> service, and have had ENUM provisioned for that service by 
> their service 
> provider on their behalf.
> 
> AM I GOING TO HAVE CONTROL OVER HOW MY PHONE NUMBER IS USED 
> IN THIS SYSTEM?
> 
> Ultimately yes. We want to repeat that the first principal in 
> the creation 
> and operation of a global ENUM service is that the phone 
> number subscriber 
> or their designated representatives is the ultimate decision 
> maker on how a 
> DNS record for a phone number is to be provisioned.
> 
> ARE THERE ANY EXAMPLES OF GLOBAL NAMESPACE DELEGATION THAT SHOULD BE 
> CONSIDERED
> AS MODELS?
> 
> The closest, technical equivalent is in-addr.arpa.  That 
> domain provides a 
> reverse mapping, from IP address to domain name.  It is used 
> as part of the 
> Internet infrastructure operation, to help authenticate an IP 
> address and 
> identify the operator associated with an IP address.  It is not seen 
> directly by users.  The same is true for e164.arpa.  It will be for 
> operational infrastructure, rather than for directl access by 
> end users.
> 
> As with e164.arpa, in-addr.arpa, allocations are 
> hierarchical, according to 
> the infrastructure administrative structure.  For in-addr.arpa, the 
> hierarchy uses the "CIDR" address allocation hierarchy.  For 
> e164.arpa, the 
> hierarchy will be based on the ITU E.164 Recommendation.
> 
> WHO CAN ADMINISTER THE ENUM REGISTRY IN THE NEAR-TERM?
> 
> ENUM is approaching the stage where the industry will want to start
> interoperability testing.  And they will want to test using 
> the e164.arpa 
> domain.  The interoperability test would have the same 
> principles that 
> current ones do; no charge, sharing of information, etc..
> 
> A. One method of enabling the registry would be to develop an 
> RFC that 
> defines the interim delegation principles for IANA as well as 
> principles 
> for the transition to the permanent registry.
> 
> WHAT CAN BE DONE IN THE LONG TERM?
> 
> There will need to be a formal effort to define and establish 
> the structure 
> for this activity.  An example of the charter for that effort 
> would be:
> 
> 1. Define the global ENUM Service.
> 2. Perform the task of certifying organizations to IANA that wish to 
> operate national TN/NS once they have been nominated by their 
> respective 
> nation states.
> 3. Coordinate technical standards for the operation of ENUM service in
> cooperation with the IETF.
> 4. Establish guidelines and policies, which national TN/NS 
> administrators 
> operate.
> 5. Promote public policy on how ENUM resources should be used.
> 
> Oversight for this activity should be constituted that 
> comprise several
> constituencies, such as
> 
> 1. The potential ENUM user community
> 2. The potential ENUM provider community
> 3. National governments, at least as an advisory
> 4. IAB-IESG representatives
> 5. others?
> 
> FORGET ALL THIS POLICY TALK...HOW IS ENUM GOING TO WORK FOR 
> ME?  WHAT DOES 
> THIS SYSTEM LOOK LIKE TO ME... JOHN DOE TELEPHONE SUBSCRIBER? 
>  HOW WILL THE 
> RIGHTS OF TELEPHONE NUMBER SUBSCRIBERS BE PROTECTED?
> 
> This is an essential question that must be resolved, but a 
> clear statement 
> of policy protecting subscribers should be part of any ENUM 
> system charter.
> 
> A simple answer is by respecting existing regulatory and 
> business rules
> regarding number administration, slamming, non-reliance, etc.  Only by
> replicating or re-implementing ENUM analogs to the existing 
> rules of the 
> road will we avoid a wide range of very serious 
> administrative, operational 
> and political conflicts.
> 
> HOW ARE YOU GOING TO PREVENT "SLAMMING" OR "HIJACKING"?
> 
> Slamming, or the involuntary transfer of service provider, 
> must be avoided 
> in any ENUM system.  However it is a serious problem in the 
> PSTN and we 
> must be careful not elsewhere. Note that anti-slamming fundamentally 
> requires a neutral third party solution.  The US industry is 
> grappling with 
> this on long distance right now.  It was solved on number 
> portability from 
> the outset.  Authenticated subscriber access is not a total solution, 
> because if a subscriber disconnects their telephony service, 
> they lose 
> rights to the phone number.  Consequently, some combination 
> of originator 
> authentication as well as telephone number rights validation, using 
> existing new and existing validation sources, can be used to 
> solve the 
> problem, depending on the level of standard required.
> 
> WHAT IS THE EFFECT OF E164.ARPA DEPLOYMENT ON THE GLOBAL DNS SYSTEM?
> 
> We don't know. This is going to need research, such as the 
> effect of "wrong 
> dials" on the root of e164.  That is, caller specification of a wrong 
> number can result in many additional queries to the e164.arpa root.
> 
> Additional work will be necessary in advising ENUM 
> applications such things 
> as the level of data caching necessary in order relieve 
> stress  -- suppress 
> escalating of poorly formed queries - mis-dials - or cache 
> misses -- on the 
> root structure.
> 
> For telephony applications, performance and load engineering 
> is critical, 
> as query volumes from small to medium size cities can easily 
> reach many 
> thousands per second alone.  Response times, as well as 
> transaction loads, 
> must be carefully considered.  Conventional DNS caching is of 
> significantly 
> reduced value in ENUM due to the huge size of the name space 
> and relatively 
> even distribution of queries into the space over arbitrary time 
> intervals.  Unlike conventional DNS queries, calls volumes 
> aren't highly 
> concentrated into a popular small subset of the number space.
> 
> WHAT WILL BE THE EFFORT TO ADMINISTER THE ROOT OF THE 
> E164.ARPA NAMESPACE?
> 
> Any solution ought to require little or no work on the part of the 
> e164.arpa root administrator. Optimally the root of e164.arpa should 
> contain a small listing of all of the national ENUM top level 
> country code 
> name servers as described above.
> 
> SECURITY CONSIDERATIONS:
> 
> Authentication of ENUM provisioning requests, validation of telephone 
> number use rights where appropriate, and security of 
> e164.arpa zone roots, 
> poses the primary security concerns for ENUM.
> 
> ACKNOWLEDGEMENTS:
> 
> The author wants to acknowledge the following individuals in 
> preparing this 
> document, though any errors or omissions are the 
> responsibility of the 
> author. Thanks to :Dave Crocker, Mark Foster, Tom McGarry,  
> John Horrocks
> 
> REFERENCES:
> 
> AUTHOR:
> 
> Richard Shockey
> Senior Technical Industry Liaison
> NeuStar
> 1120 Vermont Ave  N.W.
> Washington DC 20005
> Tel: +1 314.503.0640
> Fax: +1 815.333.1237
> Email: rshockey@ix.netcom.com
> rich.shockey@neustar.com
> 
> 
> 
> 
> 
>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Please Note New Contact Information:
> 
> Richard Shockey
> Shockey Consulting LLC
> 5237 Sutherland
> St. Louis, MO 63109
> Voice 314.503.0640
> eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
> INTERNET Mail & IFAX : rshockey@ix.netcom.com
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> 
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum
> 

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Jul 29 15:04:03 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04546
	for <enum-archive@odin.ietf.org>; Sat, 29 Jul 2000 15:04:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27561;
	Sat, 29 Jul 2000 15:03:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27485
	for <enum@ns.ietf.org>; Sat, 29 Jul 2000 15:03:13 -0400 (EDT)
Received: from spitfire.law.miami.edu (postfix@spitfire.law.miami.edu [129.171.187.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04457
	for <enum@ietf.org>; Sat, 29 Jul 2000 15:03:12 -0400 (EDT)
Received: by spitfire.law.miami.edu (Postfix, from userid 1113)
	id C1F175C3B79; Sat, 29 Jul 2000 15:03:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by spitfire.law.miami.edu (Postfix) with ESMTP
	id AB4EB5D3AEF; Sat, 29 Jul 2000 15:03:13 -0400 (EDT)
Date: Sat, 29 Jul 2000 15:03:13 -0400 (EDT)
From: "Michael Froomkin - U.Miami School of Law" <froomkin@law.miami.edu>
To: john.loughney@nokia.com
Cc: rshockey@ix.netcom.com, enum@ietf.org
Subject: RE: [Enum] ENUM FAQ
In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE104A2C964@eseis04nok>
Message-ID: <Pine.LNX.4.10.10007291458430.27538-100000@spitfire.law.miami.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Currently ICANN's rules prohibit registrars and registries from
offering privacy-enhanced registration services akin to "unlisted"
phone numbers.  To be fair, this policy was inherited from the prior
regime (NFS/NSI), although ICANN's UDRP rules for removing domains from
registrants give the current policy much greater teeth than the old one
had. 

I have often wondered if the no-privacy policy contravenes European
privacy law. I certainly don't think it is a good rule, and efforts to get
ICANN to reform it will be welcome -- although they will be met with
reflexive cries of horror by the copyright lobby, which thinks that DNS
records help it trace copyright violators.  [I've never understood that
argument, since I would have thought what you need is the physical address
of the host machine, which is quite a separate matter, but there you go.]

I agree this is a major issue.

On Sat, 29 Jul 2000 john.loughney@nokia.com wrote:

> Richard,
> 
> Thanks for the FAQ.  I've only done a quick reading of it,
> but I think it should be very useful.  One thing that I
> would like added would be more about security / privacy.
> 
> Is there a way to grant/deny access to certain DNS
> records?  I haven't seen any.  My 'fear' would be that
> I would have many services in my personal ENUM DNS record
> and then be harrassed by all sorts of new spam, SIP SPAM,
> email SPAM, telemarketers, etc.
> 
> cheers,
> John
> 
> > -----Original Message-----
> > From: EXT Richard Shockey [mailto:rshockey@ix.netcom.com]
> > Sent: July 26, 2000 23:47
> > To: enum@ietf.org
> > Subject: [Enum] ENUM FAQ
> > 
> > 
> > Since our work may be entering a new phase ..I've taken the 
> > liberty to 
> > trying to pull together some thinking about ENUM into a FAQ.
> > 
> > This will probably not be a WG document but if any of you 
> > would like to 
> > contribute questions answers or comment on it generally you 
> > are welcome to 
> > do so.
> > 
> > ################
> > 
> > 
> > 
> > 
> > ENUM Working Group                                            
> >   Richard Shockey
> > Internet-Draft: DRAFT-SHOCKEY-ENUM-FAQ-00.TXT           NeuStar, Inc
> > Expiration <1/2001>                                           
> >   July 26, 2000
> > 
> > 
> >                          FREQUENTLY ASKED QUESTIONS ABOUT ENUM
> > 
> > This is a very preliminary draft.  It has not been reviewed 
> > or accepted by 
> > the working group.  Comments are eagerly sought, as are 
> > suggestions for 
> > additional questions and alternative answers.
> > 
> > Status Of This Memo
> > 
> > This document is an Internet-Draft and is in full conformance with all
> > provisions of Section 10 of RFC2026.
> > 
> > Internet-Drafts are working documents of the Internet Engineering Task
> > Force (IETF), its areas, and its working groups.  Note that 
> > other groups 
> > may also distribute working documents as Internet-Drafts.  
> > Internet-Drafts 
> > are draft documents valid for a maximum of six months and may 
> > be updated, 
> > replaced, or obsoleted by other documents at any time.  It is 
> > inappropriate 
> > to use Internet-Drafts as reference material or to cite them 
> > other than as 
> > "work in progress."
> > 
> > The list of current Internet-Drafts can be accessed at
> > http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
> > Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
> > 
> > This document and related documents are discussed on the IETF 
> > Enum mailing 
> > list. To join the list, send mail to <mailto:enum-
> > request@ietf.org?body=subscribe>.
> > 
> > To contribute to the discussion, send mail to  
> > <mailto:enum@ietf.org> The 
> > Enum working group charter, including the current list of 
> > group documents, 
> > can be found at http://www.ietf.org/html.charters/enum-charter.html.
> > 
> > 
> > Copyright Notice
> > Copyright (C) The Internet Society (2000).  All Rights Reserved.
> > 
> > ABSTRACT
> > 
> > The IETF ENUM work group has been chartered to develop 
> > protocols that map 
> > telephone numbers to resources typically found on the 
> > Internet , such as 
> > URI's, using the Domain Name Service. It has been proposed 
> > that a global 
> > ENUM service be created in the e164.arpa domain. How 
> > e164.arpa should be 
> > organized and administered is now a serious issue confronting 
> > the Internet 
> > Community.  This document is provided as a list of common 
> > questions, and 
> > their answers, concerning E.164 numbers and their use on the 
> > Internet.  Knowledge of Domain
> > Name Service technology is assumed.
> > 
> > INTRODUCTION
> > 
> > The IETF ENUM work group has been chartered to develop 
> > protocols that map 
> > telephone numbers to Internet resources.  The working group 
> > charter is 
> > specified at:
> > 
> > <http://www.ietf.org/html.charters/enum-charter.html>
> > 
> > A Goals and Requirements specification is under active discussion.
> > The current draft is:
> > 
> > <http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-01.txt>
> > 
> > The central ENUM protocol document is:
> > 
> > <http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-02.txt>.
> > 
> > It describes the technique whereby a globally unique E.164 
> > telephone number 
> > is placed under a single DNS administrative domain. Using classic DNS 
> > resolution, a client application could then discover 
> > resources associated 
> > with that number from NAPTR or SRV Resource Records.
> > 
> > Several application developers and telecommunications service 
> > providers 
> > have expressed interest in quickly deploying ENUM based services.
> > 
> > It has been proposed that a global ENUM service be created in 
> > the e164.arpa 
> > domain.
> > 
> > How e164.arpa should be organized and administered is now a 
> > serious issue 
> > confronting the Internet Community.
> > 
> > FREQUENTLY ASKED QUESTIONS
> > 
> > WHAT IS ENUM?
> > 
> > ENUM stands for Telephone Number Resolution. It is a 
> > chartered WG of the 
> > IETF <http://www.ietf.org>.  The reason the work group exists 
> > is detailed 
> > in its charter. The URL is listed above.
> > 
> > There have been numerous experimental trials of DNS based 
> > resolution of
> > telephone number resources. The most significant of those was 
> > the TPC.INT 
> > fax experiment described in RFC 1709. Many of the concepts 
> > use by ENUM came 
> > out of that early work
> > 
> > 
> > WHAT BENEFITS DOES ENUM GIVE TO USERS?
> > 
> > The main benefits are:
> > 
> > ENUM enables calling users or entities to make a selection 
> > from the range 
> > of services that are available especially over the Internet for
> > communicating with a particular person or entity when the calling user
> > knows only their telephone number.
> > 
> > ENUM enables users to access Internet based services and 
> > resources from
> > ordinary telephones where they are only be able to input digits
> > 
> > ENUM enables users to specify their preferences for receiving incoming
> > communications (eg specifying a preference for voicemail 
> > messages over live 
> > calls or indicating a destination for call forwarding). ENUM 
> > will give much 
> > improved user control over communications.
> > 
> > There are many potential applications for ENUM and some are 
> > discussed in 
> > this document.
> > 
> > WHAT IS E.164?
> > 
> > E.164 is the international telephone numbering plan [Document 
> >  ITU-T E.164] 
> > written and administered by the International 
> > Telecommunication Union (ITU) 
> > in Geneva <http://www.itu.int>. The plan specifies the 
> > format, structure, 
> > and administrative hierarchy of telephone numbers. At the 
> > root of the E.164 
> > administrative hierarchy, the ITU issues country codes to sovereign 
> > national entities and thereby allocates new telephony 
> > numbering resources 
> > as needed. In addition there are other allocations for services and 
> > networks.  Administration of telephone numbers within each country is 
> > officially governed by the appropriate national telecommunications 
> > regulatory agency (e.g. FCC in the US,
> > CRTC in Canada, Oftel in UK).  The regulator or their 
> > designated contractor 
> > performs the actual national number resource administration itself.
> > 
> > HOW DOES ENUM WORK?
> > 
> > The enum solution  is driven , in part by the fact that most 
> > telephony 
> > users have telephone keypads [ 12 digit ] to work with.
> > 
> > 1. A phone number is translated intoE.164 form by in 
> > concluding country 
> > code or area/city code, e.g. 918-9020 dialed in St. Louis would be 
> > translated to +1-314-918-9020, where +1 is the North American 
> > country code.
> > 2. Remove all character parts from the digits. Example: 13149189020
> > 3. Reverse the order of the digits. Example: 02098194131
> > 4. Put dots (".") between each digit. Example: 0.2.0.9.8.1.9.4.1.3.1
> > 5. Append the domain "e164.arpa" to the end.  Example: 
> > 0.2.0.9.8.1.9.4.1.3.1.e164.arpa
> > 6. Perform a DNS query on this domain
> > 7. Retrieve relevant NAPTR Resource records from the Name 
> > Server for this 
> > number and perform whatever relevant application required.
> > 
> > WHY THE FUNNY REVERSAL OF THE NUMBER AND WHAT ARE ALL OF 
> > THOSE DOTS FOR?
> > 
> > Each dot separates the number into administrative "domains" 
> > or zones in DNS 
> > terms. This accommodates delegation of authority at varying points 
> > throughout the e164.name space thereby avoiding the 
> > imposition of either a 
> > fixed delegation scheme worldwide or requiring clients to 
> > know that scheme 
> > in order to know where to put the dots. Delegation in a DNS name is 
> > structured from right to left. This
> > is very important. See: 
> > <http://www.rfc-editor.org/rfc/rfc2672.txt> for 
> > more details
> > 
> > AM I GOING TO HAVE TO TYPE IN THOSE DOTS AND REVERSED NUMBERS 
> > TO USE ENUM?
> > 
> > Definitely not!  Your application will take care of all of 
> > this for you. 
> > You just enter in a phone number like you always do, into whatever 
> > application or device that supports ENUM, and it  will take 
> > care of the 
> > conversion.
> > 
> > WHY THE .ARPA TOP LEVEL DOMAIN?
> > 
> > The .arpa domain has been designated to be used for Internet 
> > Infrastructure 
> > purposes. It is managed by the IANA in cooperation with the Internet 
> > technical community under the guidance of the Internet 
> > Architecture Board. 
> > The e164.arpa domain is believed to be the most appropriate 
> > place to host 
> > the e164 namespace on the Internet.  ENUM constitutes an 
> > infrastructure 
> > support function by virtue of it providing a set of DNS-based 
> > resource 
> > directories, referenced by phone
> > number, for use by various ENUM-enabled application clients (e.g. 
> > telephones, SIP servers, voice messaging systems).  ENUM will 
> > not be used 
> > directly by people as a new way of navigating to web sites.  
> > Consequently, 
> > ENUM is an infrastructure application appropriate for use within the 
> > designated .arpa domain established for these purposes.
> > 
> > WHAT ARE SRV AND NAPTR RECORDS?
> > 
> > These are DNS Resource Records that will contain information 
> > about what 
> > Internet resources, services or applications that are 
> > associated with a 
> > particular phone number. Subscribers determine what those 
> > services are.
> > 
> > For more information, see:
> > 
> > SRV :  <http://www.rfc-editor.org/rfc/rfc2782.txt>
> > NAPTR  :  
> > http://search.ietf.org/internet-drafts/draft-ietf-urn-naptr-rr-03.txt
> > 
> > WHAT KINDS OF APPLICATIONS COULD USE ENUM?
> > 
> > Since ENUM provides a generic way to perform telephone number-based 
> > resource discovery, there are lots of examples of ENUM-enabled 
> > applications, but several have come to the forefront. The 
> > voice messaging 
> > industry has been hard at work developing a comprehensive 
> > mechanism by 
> > which voice mail systems could exchange messages over IP 
> > networks. This 
> > work is called VPIM, or Voice Profile for Internet Messaging. 
> > http://www.ietf.org/html.charters/vpim-charter.html. The
> > industry has been looking for a way to discover the host name 
> > and domain 
> > for Internet based voice mail servers. The problem has been 
> > that a typical 
> > voice mail user only has a telephone number and a telephone 
> > keypad to work 
> > with. ENUM permits these VPIM servers to locate each other 
> > and exchange 
> > messages.
> > 
> > Clearly the most active interest in ENUM service has been in Internet 
> > Telephony. It has been a long standing goal of the Voice over 
> > IP (VoIP) 
> > industry to make a phone call over the Internet as simple to 
> > make as a 
> > regular PSTN call.
> > 
> > ENUM links a telephone number to a host or resources on the 
> > Internet that 
> > can connect the call, either end to end over IP networks or through a 
> > designated gateway to the PSTN. This would be very useful for 
> > connecting 
> > SIP <http://www.ietf.org/html.charters/sip-charter.html> or 
> > H.323-capable 
> > endpoints that exist across domain boundaries.
> > 
> > ENUM is general enough that multiple discrete services 
> > (applications) may 
> > all be associated with the same telephone number at the same 
> > time, each 
> > application associated with their own unique endpoint resources as 
> > provisioned in ENUM, assuming the subscriber has the 
> > appropriate clients 
> > supporting those services.  ENUM does not require that all 
> > such telephone 
> > number-based services be provided by the same service 
> > provider (telco, ISP, 
> > whatever), even though the subscriber's right to use that particular 
> > telephone number may only flow from their having subscribed to one of 
> > them.Won't ENUM telephone routing confuse the
> > regular, PSTN routing system?
> > 
> > ENUM facilitates the discovery of resources associated with a 
> > telephone 
> > number, and hence facilitates how various applications will identify 
> > appropriate peer servers associated with an intended 
> > end-user.  It does 
> > not, however, impact how those applications will operate once 
> > the location 
> > of an end-user associated application server has been 
> > established.  Consequently, ENUM doesn't affect application-level 
> > functions, such as call routing, signaling, etc., regardless
> > of the underlying application technology employed (ISUP, SIP, 
> > H.323).  . 
> > [For example, see TRIP 
> > <http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-02.txt>]. 
> > However it is possible that a telephone company call-routing 
> > mechanism 
> > could use ENUM technology as well.
> > 
> > It is a core principle that in providing a unified resource discovery 
> > service, that ENUM will not change the existing right-to-use 
> > rules and 
> > principles for telephone numbers.  ENUM is not intended to change how 
> > telephone numbers are administered, but instead facilitate a 
> > wide range of 
> > applications using phone numbers as subscriber names.  
> > Lastly, ENUM will 
> > not interfere with existing PSTN functions and technology, 
> > such as circuit 
> > switching, SS7 (ISUP or TCAP), or IN (Intelligent Networking), where 
> > similar resource discovery activities are performed through 
> > the PSTN legacy 
> > technologies.
> > 
> > WHAT PROTOCOL DOES ENUM USE FOR INTERNET TELEPHONY?
> > 
> > ENUM itself is "protocol agnostic" because it's application 
> > agnostic.  It 
> > does not specify what applications a particular telephone number is 
> > associated with, but instead provides a unified way of discovering 
> > resources associated with it.  For example it can work with 
> > either H.323 or 
> > the Session Initiation Protocol [SIP].See 
> > <http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-00.txt>
> > for further details.
> > 
> > I'VE HEARD THIS VOICE OVER IP STUFF DOESN'T WORK.? THERE ARE LOTS OF 
> > ARTICLES IN THE TECHNICAL PRESS THAT SAY IT JUST DOESN'T WORK.
> > 
> > VoIP is an evolving technology that is in an early stage of 
> > development but 
> > rapidly improving. It is only a question of when, not if, Internet 
> > Telephony will become a reality, fully integrated with the 
> > existing, global 
> > telephone service.  This is an orthogonal issue to ENUM, as 
> > ENUM is not 
> > intended solely to facilitate VoIP, but a range of 
> > applications where a 
> > telephone number is used as a subscriber name.
> > 
> > DO I "OWN" MY PHONE NUMBER?
> > 
> > The ITU provides guidelines for the structure of phone numbers.  They 
> > allocate part of the structure of the phone number, the 
> > country code, to 
> > countries.  Each country's national regulatory agency (NRA) 
> > determines the 
> > remaining structure of the phone numbers within their 
> > country.  The NRA 
> > also designates a national number administrator (NNA), in 
> > many countries 
> > the NRA is the NNA.  The NNA allocates blocks of numbers to 
> > communications 
> > service providers.  Communications service providers allocate 
> > numbers to 
> > their users.  When a user disconnects
> > their service, after an appropriate aging interval, the 
> > number becomes an 
> > available resource to the service provider for the purposes 
> > of reassignment 
> > to a new or different user.
> > 
> > It is generally accepted that there are  no property rights 
> > associated with 
> > numbers. That means you cannot sell your telephone number to 
> > someone else, 
> > unlike the fact that you could sell an Internet domain name 
> > under your 
> > control.  As a matter of fact user's phone numbers get 
> > changed without 
> > their consent quite frequently.  In the US, for example, it 
> > results from an 
> > area code split, where the 3-digit area code prefix is changed in the 
> > user's geographic area, but usually not the last 7 digits.  
> > However, when 
> > this happens, the user no longer
> > has the same 10-digit phone number they once had.
> > 
> > It is becoming more common for users to have more control 
> > over their phone 
> > numbers.  In many countries with rules and regulations about 
> > telephone 
> > number portability, you can take your telephone number from 
> > carrier to 
> > carrier or from service type to service type (e.g., land-line 
> > to mobile) as 
> > you wish. Regulations vary from country to country.
> > 
> > Within the ENUM community it is the general view that the telephone 
> > subscriber representatives [ISP's, carriers, etc],  would be 
> > allowed to
> > determine what resources are associated  with that telephone 
> > number within 
> > the ENUM service.
> > 
> > 
> > WHAT HAPPENS TO THE NUMBER WHEN A SUBSCRIBER PORTS FROM ONE SERVICE 
> > PROVIDER TO ANOTHER?
> > 
> > When a number ports, the service provider of record changes.  
> > That is the 
> > industry now recognizes a different service provider as the 
> > holder for that 
> > particular number.  This is important for routing and billing 
> > purposes.
> > 
> > The subscriber should still be able to continue using their 
> > ENUM-enabled 
> > services, assuming their new service provider(s) support 
> > them.  Naturally, 
> > the actual location of server resources identified by ENUM 
> > will likely 
> > change as the subscriber changes any of the underlying 
> > service providers.
> > 
> > When the user disconnects the number goes back to the original service
> > provider's inventory, not to the new service provider's inventory.
> > 
> > WHAT HAPPENS TO THE ENUM SERVICES WHEN A SUBSCRIBER CANCELS 
> > TELEPHONE SERVICE?
> > 
> > As we now know the number returns to the communications 
> > service provider's 
> > inventory for the purposes of reassignment.  The subscriber 
> > that cancels 
> > their telephone service will have to cancel the associations 
> > that number 
> > has with all ENUM services, even those provided by other service 
> > providers.  If this was not done the new user of that 
> > telephone number 
> > could have a conflict with the old user.  On the other hand, 
> > where number 
> > portability is available, a user has the option of porting 
> > their number 
> > over to a new service provider instead of canceling their 
> > existing service 
> > and losing their current number.
> > 
> > COULD ENUM BE USED TO PROVIDE TELEPHONE NUMBER PORTABILITY?
> > 
> > In those countries that do not yet have a centralized database 
> > administration service, having a shared directory service 
> > like ENUM might 
> > be of interest.  However, ENUM is not intended to serve this 
> > function, as 
> > there are very
> > significant technical, regulatory, security, and operational 
> > limitations in 
> > using ENUM for this purpose.  ENUM is a shared resource 
> > discovery service, 
> > not an industry provisioning service.  In most countries where number 
> > portability is deployed, telephone service providers are 
> > generally required 
> > to comply with regulatory/industry processes, procedures, and 
> > systems, 
> > regardless of the underlying technology they employ for 
> > telephony service 
> > delivery (SIP, H.323, circuit-switched, or string-and-cans).  
> > How ENUM is 
> > administered in those countries will also likely require mirroring of 
> > provisioning rules (e.g. anti-slamming) employed for number 
> > portability and 
> > number administration so as to ensure that service providers using 
> > ENUM-enabled services do not violate applicable regulatory rules or 
> > industry guidelines.  ENUM is another downstream use of numbering 
> > provisioning and administration activities, and will need to 
> > be deployed 
> > consistent with applicable national requirements, it does not 
> > create an 
> > alternate numbering universe with its own set of rules and policies.
> > 
> > HOW IS THE USER OF A NUMBER AUTHENTICATED?
> > 
> > Users could be corporations, individuals, government 
> > agencies, military, 
> > and hosts of other non-individual users.  Service providers typically 
> > assign large blocks of numbers to these entities.  The 
> > telecom manager 
> > within these entities then assigns numbers to users.  So even 
> > the service 
> > providers cannot identify the users for a very large portion of the 
> > allocated numbers.
> > 
> > This is an unresolved issue but one that must be resolved prior to 
> > deploying a robust and secure ENUM service.  It's likely that 
> > the service 
> > provider that allocated the number(s) to the user will be 
> > involved in the 
> > process of authentication.
> > 
> > WELL WHAT ABOUT PRIVATE NUMBERING PLANS WITHIN A COMPANY?
> > 
> > Excellent question. The ENUM protocol can be used in private 
> > numbering 
> > plans the same way it can be used in the public E.164 number 
> > plan.  The 
> > Internet Telephony gateway or proxy needs some intelligence 
> > to "decode" a 
> > particular dialing string and then decide how to look up 
> > resources for that 
> > particular number. Instead of looking for resources in e164.arpa the 
> > gateway or proxy would look for SRV or NAPTR records for 
> > private numbers 
> > under some other structure, such as
> > e164.bigcompany.com .
> > 
> > WHAT ABOUT EMERGENCY SERVICES LIKE 911 OR 112 [EUROPE]?
> > 
> > In general, emergency service numbers are "access codes" and 
> > not "E.164
> > numbers", and will not be part of ENUM services.
> > 
> > HOW WILL THE E164.ARPA DOMAIN BE ORGANIZED?
> > 
> > One convenient way of doing this would be to delegate 
> > according to the 243 
> > country codes designated by the ITU.  It's important to understand, 
> > however, that delegation in DNS can occur at any digit, or 
> > zone domain in 
> > DNS terms
> > 
> > So within the root e164.arpa there would be an NS listing for 
> > 1.e164.arpa 
> > representing the top level of the North American Numbering Plan. [US, 
> > Canada, and several Caribbean countries]
> > 
> > A NS listing for -.4.4.e164.arpa - representing the top level 
> > (44) of the UK
> > A NS listing for - 4.6.e164.arpa - representing the top level (46) 
> > of  Sweden.
> > A NS listing for - 8.1.e164.arpa - representing the top level 
> > (81) of Japan.
> > A NS listing for - 8.5.3.e164.arpa - representing the top 
> > level (358) of
> > Finland.
> > 
> > At the national TN/NS level further NS delegation [DNAME, 
> > CNAME, PTR] can 
> > occur to enterprises, TN/NS application service providers, 
> > carriers, and 
> > even individuals who have DNS servers in their house.
> > 
> > WHO WILL ADMINISTER THESE NATIONAL TELEPHONE NUMBER NAME SERVERS?
> > 
> > There are many competent companies or organizations that can 
> > operate these 
> > servers. A number of companies have already come forward to 
> > express their 
> > interest in running these servers, initially free of charge and on an 
> > experimental basis, until such time as consensus can be 
> > reached on how this 
> > system is to ultimately organize.
> > 
> > Some theories on how this system will be organized on a 
> > permanent basis 
> > will be discussed a little later in this FAQ.  There are a number of 
> > regulatory constraints in various countries that might apply 
> > on the ENUM 
> > administrator, name service operators, as well as delegation 
> > policies below 
> > the national level.  For example, where local telephony 
> > service competition 
> > and number portability are being deployed in a country, it is 
> > not unusual 
> > that a neutral third party is required to provide master database 
> > administration services, and a requirement for anti-slamming and 
> > non-reliance on competing carriers for routing or
> > resolution functions.
> > 
> > AM I ULTIMATELY GOING TO HAVE TO PAY TO HAVE MY TELEPHONE NUMBER ENUM
> > PROVISIONED?
> > 
> > Probably yes, but most likely the costs will be indirectly recovered 
> > through the underlying prices for ENUM-enabled services that 
> > subscribers 
> > pay. This is a DNS-based system. If you want a domain name 
> > registered in 
> > DNS someone must pay for that. Listing telephone numbers will be no 
> > different.  Whether the cost will be charged directly to the 
> > subscriber or 
> > will be an indirect charge as part of some larger services 
> > will depend on 
> > those offering the services.
> > 
> > Remember you do not have to ENUM list your phone number. ENUM 
> > would be a 
> > subscriber-controlled "opt-in" system to "announce", over the 
> > Internet, the 
> > availability of a particular telephone number to accept 
> > service sessions 
> > and how to manage those sessions as a result of having 
> > subscribed to an 
> > ENUM-enabled service. If you do not have an Internet 
> > telephony device or 
> > service you will likely not need to list your number.  On the 
> > other hand, 
> > subscribers may not necessarily be aware they've subscribed to such a 
> > service, and have had ENUM provisioned for that service by 
> > their service 
> > provider on their behalf.
> > 
> > AM I GOING TO HAVE CONTROL OVER HOW MY PHONE NUMBER IS USED 
> > IN THIS SYSTEM?
> > 
> > Ultimately yes. We want to repeat that the first principal in 
> > the creation 
> > and operation of a global ENUM service is that the phone 
> > number subscriber 
> > or their designated representatives is the ultimate decision 
> > maker on how a 
> > DNS record for a phone number is to be provisioned.
> > 
> > ARE THERE ANY EXAMPLES OF GLOBAL NAMESPACE DELEGATION THAT SHOULD BE 
> > CONSIDERED
> > AS MODELS?
> > 
> > The closest, technical equivalent is in-addr.arpa.  That 
> > domain provides a 
> > reverse mapping, from IP address to domain name.  It is used 
> > as part of the 
> > Internet infrastructure operation, to help authenticate an IP 
> > address and 
> > identify the operator associated with an IP address.  It is not seen 
> > directly by users.  The same is true for e164.arpa.  It will be for 
> > operational infrastructure, rather than for directl access by 
> > end users.
> > 
> > As with e164.arpa, in-addr.arpa, allocations are 
> > hierarchical, according to 
> > the infrastructure administrative structure.  For in-addr.arpa, the 
> > hierarchy uses the "CIDR" address allocation hierarchy.  For 
> > e164.arpa, the 
> > hierarchy will be based on the ITU E.164 Recommendation.
> > 
> > WHO CAN ADMINISTER THE ENUM REGISTRY IN THE NEAR-TERM?
> > 
> > ENUM is approaching the stage where the industry will want to start
> > interoperability testing.  And they will want to test using 
> > the e164.arpa 
> > domain.  The interoperability test would have the same 
> > principles that 
> > current ones do; no charge, sharing of information, etc..
> > 
> > A. One method of enabling the registry would be to develop an 
> > RFC that 
> > defines the interim delegation principles for IANA as well as 
> > principles 
> > for the transition to the permanent registry.
> > 
> > WHAT CAN BE DONE IN THE LONG TERM?
> > 
> > There will need to be a formal effort to define and establish 
> > the structure 
> > for this activity.  An example of the charter for that effort 
> > would be:
> > 
> > 1. Define the global ENUM Service.
> > 2. Perform the task of certifying organizations to IANA that wish to 
> > operate national TN/NS once they have been nominated by their 
> > respective 
> > nation states.
> > 3. Coordinate technical standards for the operation of ENUM service in
> > cooperation with the IETF.
> > 4. Establish guidelines and policies, which national TN/NS 
> > administrators 
> > operate.
> > 5. Promote public policy on how ENUM resources should be used.
> > 
> > Oversight for this activity should be constituted that 
> > comprise several
> > constituencies, such as
> > 
> > 1. The potential ENUM user community
> > 2. The potential ENUM provider community
> > 3. National governments, at least as an advisory
> > 4. IAB-IESG representatives
> > 5. others?
> > 
> > FORGET ALL THIS POLICY TALK...HOW IS ENUM GOING TO WORK FOR 
> > ME?  WHAT DOES 
> > THIS SYSTEM LOOK LIKE TO ME... JOHN DOE TELEPHONE SUBSCRIBER? 
> >  HOW WILL THE 
> > RIGHTS OF TELEPHONE NUMBER SUBSCRIBERS BE PROTECTED?
> > 
> > This is an essential question that must be resolved, but a 
> > clear statement 
> > of policy protecting subscribers should be part of any ENUM 
> > system charter.
> > 
> > A simple answer is by respecting existing regulatory and 
> > business rules
> > regarding number administration, slamming, non-reliance, etc.  Only by
> > replicating or re-implementing ENUM analogs to the existing 
> > rules of the 
> > road will we avoid a wide range of very serious 
> > administrative, operational 
> > and political conflicts.
> > 
> > HOW ARE YOU GOING TO PREVENT "SLAMMING" OR "HIJACKING"?
> > 
> > Slamming, or the involuntary transfer of service provider, 
> > must be avoided 
> > in any ENUM system.  However it is a serious problem in the 
> > PSTN and we 
> > must be careful not elsewhere. Note that anti-slamming fundamentally 
> > requires a neutral third party solution.  The US industry is 
> > grappling with 
> > this on long distance right now.  It was solved on number 
> > portability from 
> > the outset.  Authenticated subscriber access is not a total solution, 
> > because if a subscriber disconnects their telephony service, 
> > they lose 
> > rights to the phone number.  Consequently, some combination 
> > of originator 
> > authentication as well as telephone number rights validation, using 
> > existing new and existing validation sources, can be used to 
> > solve the 
> > problem, depending on the level of standard required.
> > 
> > WHAT IS THE EFFECT OF E164.ARPA DEPLOYMENT ON THE GLOBAL DNS SYSTEM?
> > 
> > We don't know. This is going to need research, such as the 
> > effect of "wrong 
> > dials" on the root of e164.  That is, caller specification of a wrong 
> > number can result in many additional queries to the e164.arpa root.
> > 
> > Additional work will be necessary in advising ENUM 
> > applications such things 
> > as the level of data caching necessary in order relieve 
> > stress  -- suppress 
> > escalating of poorly formed queries - mis-dials - or cache 
> > misses -- on the 
> > root structure.
> > 
> > For telephony applications, performance and load engineering 
> > is critical, 
> > as query volumes from small to medium size cities can easily 
> > reach many 
> > thousands per second alone.  Response times, as well as 
> > transaction loads, 
> > must be carefully considered.  Conventional DNS caching is of 
> > significantly 
> > reduced value in ENUM due to the huge size of the name space 
> > and relatively 
> > even distribution of queries into the space over arbitrary time 
> > intervals.  Unlike conventional DNS queries, calls volumes 
> > aren't highly 
> > concentrated into a popular small subset of the number space.
> > 
> > WHAT WILL BE THE EFFORT TO ADMINISTER THE ROOT OF THE 
> > E164.ARPA NAMESPACE?
> > 
> > Any solution ought to require little or no work on the part of the 
> > e164.arpa root administrator. Optimally the root of e164.arpa should 
> > contain a small listing of all of the national ENUM top level 
> > country code 
> > name servers as described above.
> > 
> > SECURITY CONSIDERATIONS:
> > 
> > Authentication of ENUM provisioning requests, validation of telephone 
> > number use rights where appropriate, and security of 
> > e164.arpa zone roots, 
> > poses the primary security concerns for ENUM.
> > 
> > ACKNOWLEDGEMENTS:
> > 
> > The author wants to acknowledge the following individuals in 
> > preparing this 
> > document, though any errors or omissions are the 
> > responsibility of the 
> > author. Thanks to :Dave Crocker, Mark Foster, Tom McGarry,  
> > John Horrocks
> > 
> > REFERENCES:
> > 
> > AUTHOR:
> > 
> > Richard Shockey
> > Senior Technical Industry Liaison
> > NeuStar
> > 1120 Vermont Ave  N.W.
> > Washington DC 20005
> > Tel: +1 314.503.0640
> > Fax: +1 815.333.1237
> > Email: rshockey@ix.netcom.com
> > rich.shockey@neustar.com
> > 
> > 
> > 
> > 
> > 
> >  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > Please Note New Contact Information:
> > 
> > Richard Shockey
> > Shockey Consulting LLC
> > 5237 Sutherland
> > St. Louis, MO 63109
> > Voice 314.503.0640
> > eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
> > INTERNET Mail & IFAX : rshockey@ix.netcom.com
> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> > 
> > 
> > _______________________________________________
> > enum mailing list
> > enum@ietf.org
> > http://www1.ietf.org/mailman/listinfo/enum
> > 
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum
> 

-- 
		Please visit http://www.icannwatch.org
A. Michael Froomkin   |    Professor of Law    |   froomkin@law.tm
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
                        -->It's hot here.<--


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Jul 29 15:18:00 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06232
	for <enum-archive@odin.ietf.org>; Sat, 29 Jul 2000 15:18:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27761;
	Sat, 29 Jul 2000 15:16:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27731
	for <enum@ns.ietf.org>; Sat, 29 Jul 2000 15:16:28 -0400 (EDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06046
	for <enum@ietf.org>; Sat, 29 Jul 2000 15:16:27 -0400 (EDT)
Received: from [10.81.77.12] (ssh.cisco.com [171.69.10.34])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id MAA06176;
	Sat, 29 Jul 2000 12:15:42 -0700 (PDT)
Mime-Version: 1.0
X-Sender: pfaltstr@127.0.0.1
Message-Id: <p0432040ab5a8dd1207e6@[10.81.77.12]>
In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE104A2C964@eseis04nok>
References: <01D91AFB08B6D211BFD00008C7EABAE104A2C964@eseis04nok>
Date: Sat, 29 Jul 2000 15:15:02 -0400
To: john.loughney@nokia.com, rshockey@ix.netcom.com, enum@ietf.org
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <paf@cisco.com>
Subject: RE: [Enum] ENUM FAQ
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 21.46 +0300 00-07-29, john.loughney@nokia.com wrote:
>Is there a way to grant/deny access to certain DNS
>records?  I haven't seen any.  My 'fear' would be that
>I would have many services in my personal ENUM DNS record
>and then be harrassed by all sorts of new spam, SIP SPAM,
>email SPAM, telemarketers, etc.

Nope, and I should add that to the security considerations section. 
I.e. we have been discussing several months ago this issue, and the 
conclusion was that IF you have sensitive information that should for 
example be stored in an LDAP database or something else which handle 
authentication, and an LDAP URI in DNS.

    paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Jul 29 15:35:02 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08236
	for <enum-archive@odin.ietf.org>; Sat, 29 Jul 2000 15:35:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28109;
	Sat, 29 Jul 2000 15:34:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28080
	for <enum@ns.ietf.org>; Sat, 29 Jul 2000 15:34:23 -0400 (EDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08161
	for <enum@ietf.org>; Sat, 29 Jul 2000 15:34:24 -0400 (EDT)
Received: from [10.81.77.12] (ssh.cisco.com [171.69.10.34])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id MAA07129;
	Sat, 29 Jul 2000 12:33:46 -0700 (PDT)
Mime-Version: 1.0
X-Sender: pfaltstr@127.0.0.1
Message-Id: <p04320410b5a8e1781058@[10.81.77.12]>
In-Reply-To: <p0432040ab5a8dd1207e6@[10.81.77.12]>
References: <01D91AFB08B6D211BFD00008C7EABAE104A2C964@eseis04nok>
 <p0432040ab5a8dd1207e6@[10.81.77.12]>
Date: Sat, 29 Jul 2000 15:33:37 -0400
To: john.loughney@nokia.com, rshockey@ix.netcom.com, enum@ietf.org
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <paf@cisco.com>
Subject: RE: [Enum] ENUM FAQ
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

At 15.15 -0400 00-07-29, Patrik Fältström wrote:
>At 21.46 +0300 00-07-29, john.loughney@nokia.com wrote:
>>Is there a way to grant/deny access to certain DNS
>>records?  I haven't seen any.  My 'fear' would be that
>>I would have many services in my personal ENUM DNS record
>>and then be harrassed by all sorts of new spam, SIP SPAM,
>>email SPAM, telemarketers, etc.
>
>Nope, and I should add that to the security considerations section. 
>I.e. we have been discussing several months ago this issue, and the 
>conclusion was that IF you have sensitive information that should 
>for example be stored in an LDAP database or something else which 
>handle authentication, and an LDAP URI in DNS.

I forgot one thing, a directory service like this can _never_ replace 
the authentication mechanism you use in whatever protocol you use for 
the actual transport. With the directory, you only get to know what 
endpoint to use.

Say that you don't want denial of service attacks on your (secret) 
webserver. Do you think you will be safe if you don't have a hostname 
in DNS, but only use an IP-address?

Not really...

The only thin we can talk about here is when the endpoint identifier 
itself have to be protected for various reasons, and that is when 
directory services protocols which do have strong authentication (and 
encryption) comes into mind.

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Jul 29 23:40:03 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07677
	for <enum-archive@odin.ietf.org>; Sat, 29 Jul 2000 23:40:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02532;
	Sat, 29 Jul 2000 23:39:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02501
	for <enum@ns.ietf.org>; Sat, 29 Jul 2000 23:39:26 -0400 (EDT)
Received: from europe.std.com (europe.std.com [199.172.62.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07549
	for <enum@ietf.org>; Sat, 29 Jul 2000 23:39:26 -0400 (EDT)
Received: from world.std.com (brunner@world-f.std.com [199.172.62.5])
	by europe.std.com (8.9.3/8.9.3) with ESMTP id XAA18758;
	Sat, 29 Jul 2000 23:39:25 -0400 (EDT)
Received: from localhost (brunner@localhost)
	by world.std.com (8.9.3/8.9.3) with SMTP id XAA20184;
	Sat, 29 Jul 2000 23:39:24 -0400 (EDT)
Message-Id: <200007300339.XAA20184@world.std.com>
X-Authentication-Warning: world.std.com: brunner@localhost didn't use HELO protocol
To: rshockey@ix.netcom.com
cc: enum@ietf.org, caseyja@gtlaw.com, Rpwgough@aol.com
Subject: Re: [Enum] ENUM FAQ
Date: Sat, 29 Jul 2000 23:39:23 -0400
From: Eric Brunner <brunner@world.std.com>
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Richard,

> WHAT IS E.164?
...
> At the root of the E.164
> administrative hierarchy, the ITU issues country codes to sovereign
> national entities and thereby allocates new telephony numbering resources
> as needed.

Not knowing the history of telephone numbering in Palestine or East Timor,
and knowing the history of telephone numbering in North America, I suggest
this be re-phrased to:

	At the root of the E.164 administrative hierarchy, the ITU
	allocates numeric labels (commonly referred to as "country
	codes") and thereby creates new telephony numbering resources
	as needed.

Indian Reserves and Reservations located in the interior of the Canada and
the US don't have "country codes", and the IETF has no obligation to get in
the business of deciding what is, or isn't a "country". We ran into this in
Domain Name System (DNS) IANA Considerations which recently went to BCP. It
has no dependency upon iso3166.

> HOW DOES ENUM WORK?

>                            ... where +1 is the North American country code.

Change to "where +1 is the value allocated to the United States of America."

> HOW WILL THE E164.ARPA DOMAIN BE ORGANIZED?
>
> One convenient way of doing this would be to delegate according to the 243
> country codes designated by the ITU.  It's important to understand,
> however, that delegation in DNS can occur at any digit, or zone domain in
> DNS terms

Please add a statement to the effect that adopting political geography in
the e164.arpa domain is likely to have the same effect it has had in the
DNS root domain, preventing Indigenous polities from equitable operational or
regulatory access to the resource.

> So within the root e164.arpa there would be an NS listing for 1.e164.arpa
> representing the top level of the North American Numbering Plan. [US,
> Canada, and several Caribbean countries]

Please change the parenthetical list to:

	[the US, Canada, several Caribbean countries, and the Indigenous
	 Nations of North America]

You may want to add periods for each of these two sentences.

> WHAT WILL BE THE EFFORT TO ADMINISTER THE ROOT OF THE E164.ARPA NAMESPACE?
..
> e164.arpa root administrator. Optimally the root of e164.arpa should
> contain a small listing of all of the national ENUM top level country code 

Just to scope the size of the top-level, adding Reserves and Reservations
in unaggregated form (not preferred) would expand the top-level by ~1K
entries. Adding Reserves and Reservations in aggregated form (preferred)
would expand the top-level by ~10 entries. Similar aggregations may apply
outside of North America, e.g., adding Aotearoa (New Zealand) would add but
one (aggregated) entry, not an entry for each Iwi in Aotearoa.

I only mention this to preclude the two usual arguments for exclusion (other
than lack of means). The proposal I made to Jon P. three years ago was to use
the X.121 regional identifiers to provide an escape mechanism from political
geography (iso3166 in the DNS root). The approach is viable for mapping e.164
to the DNS in the .arpa tld, and we don't have the ... err ... overhead of
the DNS root.

Number portability and shared resource discovery service within Indian Country
is desirable, and of course we are rather big on string-and-cans. ;-)

Eric

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 30 01:54:57 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21311
	for <enum-archive@odin.ietf.org>; Sun, 30 Jul 2000 01:54:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09107;
	Sun, 30 Jul 2000 01:54:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09078
	for <enum@ns.ietf.org>; Sun, 30 Jul 2000 01:54:30 -0400 (EDT)
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21129
	for <enum@ietf.org>; Sun, 30 Jul 2000 01:54:31 -0400 (EDT)
Received: from computer.ix.netcom.com (pool-207-205-220-221.pbgh.grid.net [207.205.220.221] (may be forged))
	by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id BAA14038;
	Sun, 30 Jul 2000 01:54:28 -0400 (EDT)
Message-Id: <4.3.1.2.20000730004313.00e20210@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Sun, 30 Jul 2000 00:49:52 -0500
To: "Michael Froomkin - U.Miami School of Law" <froomkin@law.miami.edu>,
        john.loughney@nokia.com
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: RE: [Enum] ENUM FAQ
Cc: enum@ietf.org
In-Reply-To: <Pine.LNX.4.10.10007291458430.27538-100000@spitfire.law.mia
 mi.edu>
References: <01D91AFB08B6D211BFD00008C7EABAE104A2C964@eseis04nok>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 03:03 PM 7/29/2000 -0400, Michael Froomkin - U.Miami School of Law wrote:
>Currently ICANN's rules prohibit registrars and registries from
>offering privacy-enhanced registration services akin to "unlisted"
>phone numbers.  To be fair, this policy was inherited from the prior
>regime (NFS/NSI), although ICANN's UDRP rules for removing domains from
>registrants give the current policy much greater teeth than the old one
>had.
>
>I have often wondered if the no-privacy policy contravenes European
>privacy law. I certainly don't think it is a good rule, and efforts to get
>ICANN to reform it will be welcome -- although they will be met with
>reflexive cries of horror by the copyright lobby, which thinks that DNS
>records help it trace copyright violators.  [I've never understood that
>argument, since I would have thought what you need is the physical address
>of the host machine, which is quite a separate matter, but there you go.]
>
>I agree this is a major issue.


It is my understanding that the policy does contravene European privacy 
laws and this topic came out at the Registrars meeting at ICANN at Yokohama 
in relation to domain names. It is the subject of much debate and possible 
review in the EC as it might relate to the requirements of law enforcement 
agencies among others.

One thing I have tried to say in the FAQ is that ENUM  is designed as a 
OPT-IN system.


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 30 02:17:35 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08550
	for <enum-archive@odin.ietf.org>; Sun, 30 Jul 2000 02:17:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09399;
	Sun, 30 Jul 2000 02:16:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09368
	for <enum@ns.ietf.org>; Sun, 30 Jul 2000 02:15:59 -0400 (EDT)
Received: from joy.songbird.com (IDENT:root@joy.songbird.com [208.184.79.7])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07752
	for <enum@ietf.org>; Sun, 30 Jul 2000 02:16:00 -0400 (EDT)
Received: from dcrocker.dcrocker.net (free.88.106.bayarea.net [205.219.88.106])
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id XAA21624;
	Sat, 29 Jul 2000 23:15:47 -0700
Message-Id: <4.3.2.20000729225721.00ccce10@joy.songbird.com>
X-Sender: dhc@joy.songbird.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Sat, 29 Jul 2000 23:00:16 -0700
To: Eric Brunner <brunner@world.std.com>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [Enum] ENUM FAQ
Cc: rshockey@ix.netcom.com, enum@ietf.org, caseyja@gtlaw.com, Rpwgough@aol.com
In-Reply-To: <200007300339.XAA20184@world.std.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 11:39 PM 7/29/00 -0400, Eric Brunner wrote:
>Not knowing the history of telephone numbering in Palestine or East Timor,
>and knowing the history of telephone numbering in North America, I suggest
>this be re-phrased to:

I think that the suggested change is perfectly fine.

It creates no confusion, is accurate and precise, and sidesteps the 
controversial issue that is raised.

Since we really do not need to resolve the point of controversy, for the 
purposes of this activity, what the heck.  Let's make the change.

d/


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 30 12:35:27 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01659
	for <enum-archive@odin.ietf.org>; Sun, 30 Jul 2000 12:35:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14637;
	Sun, 30 Jul 2000 12:32:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14606
	for <enum@ns.ietf.org>; Sun, 30 Jul 2000 12:31:59 -0400 (EDT)
Received: from spitfire.law.miami.edu (postfix@spitfire.law.miami.edu [129.171.187.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00882
	for <enum@ietf.org>; Sun, 30 Jul 2000 12:31:59 -0400 (EDT)
Received: by spitfire.law.miami.edu (Postfix, from userid 1113)
	id 28A815C3B0A; Sun, 30 Jul 2000 12:32:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by spitfire.law.miami.edu (Postfix) with ESMTP
	id 197BD5D3AEF; Sun, 30 Jul 2000 12:32:00 -0400 (EDT)
Date: Sun, 30 Jul 2000 12:32:00 -0400 (EDT)
From: "Michael Froomkin - U.Miami School of Law" <froomkin@law.miami.edu>
To: Eric Brunner <brunner@world.std.com>
Cc: rshockey@ix.netcom.com, enum@ietf.org, caseyja@gtlaw.com, Rpwgough@aol.com
Subject: Re: [Enum] ENUM FAQ
In-Reply-To: <200007300339.XAA20184@world.std.com>
Message-ID: <Pine.LNX.4.10.10007301227490.23036-100000@spitfire.law.miami.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

On Sat, 29 Jul 2000, Eric Brunner wrote:

> 
> >                            ... where +1 is the North American country code.
> 
> Change to "where +1 is the value allocated to the United States of America."


Someone please correct me if I am wrong, but I thought +1 was also used by
a small number of other countries.  Such as Canada and the Cayman Islands.

-- 
		Please visit http://www.icannwatch.org
A. Michael Froomkin   |    Professor of Law    |   froomkin@law.tm
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
                        -->It's hot here.<--


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 30 13:09:33 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12682
	for <enum-archive@odin.ietf.org>; Sun, 30 Jul 2000 13:09:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15128;
	Sun, 30 Jul 2000 13:09:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15101
	for <enum@ns.ietf.org>; Sun, 30 Jul 2000 13:09:04 -0400 (EDT)
Received: from europe.std.com (europe.std.com [199.172.62.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12458
	for <enum@ietf.org>; Sun, 30 Jul 2000 13:09:02 -0400 (EDT)
Received: from world.std.com (brunner@world-f.std.com [199.172.62.5])
	by europe.std.com (8.9.3/8.9.3) with ESMTP id NAA25682;
	Sun, 30 Jul 2000 13:08:21 -0400 (EDT)
Received: from localhost (brunner@localhost)
	by world.std.com (8.9.3/8.9.3) with SMTP id NAA01988;
	Sun, 30 Jul 2000 13:08:19 -0400 (EDT)
Message-Id: <200007301708.NAA01988@world.std.com>
X-Authentication-Warning: world.std.com: brunner@localhost didn't use HELO protocol
To: froomkin@law.tm
cc: rshockey@ix.netcom.com, enum@ietf.org, caseyja@gtlaw.com, Rpwgough@aol.com
Subject: Re: [Enum] ENUM FAQ
Date: Sun, 30 Jul 2000 13:08:19 -0400
From: Eric Brunner <brunner@world.std.com>
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Michael,

You are correct. Feel free to improve upon my suggested change.

Eric

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 30 13:27:57 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18961
	for <enum-archive@odin.ietf.org>; Sun, 30 Jul 2000 13:27:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15396;
	Sun, 30 Jul 2000 13:27:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15369
	for <enum@ns.ietf.org>; Sun, 30 Jul 2000 13:27:24 -0400 (EDT)
Received: from spitfire.law.miami.edu (postfix@spitfire.law.miami.edu [129.171.187.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18831
	for <enum@ietf.org>; Sun, 30 Jul 2000 13:27:23 -0400 (EDT)
Received: by spitfire.law.miami.edu (Postfix, from userid 1113)
	id 331405C3B0A; Sun, 30 Jul 2000 13:27:25 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by spitfire.law.miami.edu (Postfix) with ESMTP
	id 2FCD45D3AEF; Sun, 30 Jul 2000 13:27:25 -0400 (EDT)
Date: Sun, 30 Jul 2000 13:27:25 -0400 (EDT)
From: "Michael Froomkin - U.Miami School of Law" <froomkin@law.miami.edu>
To: Eric Brunner <brunner@world.std.com>
Cc: rshockey@ix.netcom.com, enum@ietf.org, caseyja@gtlaw.com, Rpwgough@aol.com
Subject: Re: [Enum] ENUM FAQ
In-Reply-To: <200007301708.NAA01988@world.std.com>
Message-ID: <Pine.LNX.4.10.10007301327100.23036-100000@spitfire.law.miami.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

I'll leave that to the pros....

On Sun, 30 Jul 2000, Eric Brunner wrote:

> Hi Michael,
> 
> You are correct. Feel free to improve upon my suggested change.
> 
> Eric
> 

-- 
		Please visit http://www.icannwatch.org
A. Michael Froomkin   |    Professor of Law    |   froomkin@law.tm
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
                        -->It's hot here.<--


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 30 17:11:20 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25717
	for <enum-archive@odin.ietf.org>; Sun, 30 Jul 2000 17:11:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18445;
	Sun, 30 Jul 2000 17:10:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18415
	for <enum@ns.ietf.org>; Sun, 30 Jul 2000 17:10:51 -0400 (EDT)
Received: from slb-smtpout-01.boeing.com ([12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25555
	for <enum@ietf.org>; Sun, 30 Jul 2000 17:10:51 -0400 (EDT)
Received: from slb-av-01.boeing.com ([129.172.13.4])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA19288
	for <enum@ietf.org>; Sun, 30 Jul 2000 14:10:50 -0700 (PDT)
Received: from slb-hub-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id OAA15243
	for <enum@ietf.org>; Sun, 30 Jul 2000 14:10:50 -0700 (PDT)
Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Sun, 30 Jul 2000 14:10:38 -0700
Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21)
	id <3GJSSZ9Z>; Sun, 30 Jul 2000 17:10:37 -0400
Message-Id: <4102273CEB77D211869200805FE6F5939EBD65@xch-phl-01.he.boeing.com>
From: "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>
To: "'Eric Brunner'" <brunner@world.std.com>, rshockey@ix.netcom.com
Cc: enum@ietf.org
Subject: RE: [Enum] ENUM FAQ
Date: Sun, 30 Jul 2000 17:10:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

> -----Original Message-----
> From: Eric Brunner [mailto:brunner@world.std.com]

> Not knowing the history of telephone numbering in Palestine 
> or East Timor,
> and knowing the history of telephone numbering in North 
> America, I suggest
> this be re-phrased to:
> 
> 	At the root of the E.164 administrative hierarchy, the ITU
> 	allocates numeric labels (commonly referred to as "country
> 	codes") and thereby creates new telephony numbering resources
> 	as needed.

To solve the +1 "country code" issue, since +1 refers to USA, Canada, and
the Bahamas, you might want to add:

     While the "country code" usually identifies the numbers of a
     single country, these codes in fact apply to:

     International public telecommunication number for geographic areas.

     International public telecommunication number for global services.

     International public telecommunication number for Networks.

> >  ... where +1 is the North
> > American country code.
> 
> Change to "where +1 is the value allocated to the United 
> States of America."

But it isn't.

Bert
albert.e.manfredi@boeing.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Jul 30 23:10:24 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22918
	for <enum-archive@odin.ietf.org>; Sun, 30 Jul 2000 23:10:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22650;
	Sun, 30 Jul 2000 23:08:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22621
	for <enum@ns.ietf.org>; Sun, 30 Jul 2000 23:08:41 -0400 (EDT)
Received: from cqmx.corp.comsat.com (cqmx.corp.comsat.com [134.133.184.25])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22540
	for <enum@ietf.org>; Sun, 30 Jul 2000 23:08:41 -0400 (EDT)
From: Andrew.Gallant@comsat.com
Received: from cqgate6.cmc.comsat.com ([134.133.162.21])
          by cqmx.corp.comsat.com (Post.Office MTA v3.5.3 release 223
          ID# 0-0U10L2S100V35) with ESMTP id com;
          Sun, 30 Jul 2000 23:07:13 -0400
Received: from ccMail by cqgate6.cmc.comsat.com
  (IMA Internet Exchange 3.13) id 00091122; Sun, 30 Jul 2000 23:14:17 -0400
Mime-Version: 1.0
Date: Sun, 30 Jul 2000 22:45:36 -0400
Message-ID: <00091122.C22219@comsat.com>
To: "'Eric Brunner'" <brunner@world.std.com>, rshockey@ix.netcom.com,
        "Manfredi; Albert E" <Albert.Manfredi@PHL.Boeing.com>
Cc: enum@ietf.org
Subject: Re[2]: [Enum] ENUM FAQ
Content-Type: multipart/mixed; boundary="IMA.Boundary.7523105690"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

--IMA.Boundary.7523105690
Content-Type: text/plain; charset="US-ASCII"
Content-Description: cc:Mail note part
Content-Transfer-Encoding: quoted-printable

FYI (for enum) w/r/t this thread, if it helps any, but first a disclaimer=
 (this =

is offered unofficially and is to be considered just as some data, and no=
t as an
opinion, either(!)):

(a) In Annex to ITU Operational Bulletin No. 717 - 1.VI.2000, "COMPLEMENT=
 TO =

ITU-T RECOMMENDATION E.164 (05/1997) -- LIST OF ITU-T RECOMMENDATION E.16=
4
ASSIGNED COUNTRY CODES (POSITION ON 1 JUNE 2000)," the numerical list inc=
ludes =

these entries:

Country code    Country, Geographical area or Global service    Note

        1       Anguilla                                          b
        1       Antigua and Barbuda                               b
        1       Bahamas (Commonwealth of the)                     b
        1       Barbados                                          b
        1       Bermuda                                           b
        1       British Virgin Islands                            b
        1       Canada                                            b
        1       Cayman Islands                                    b
        1       Dominica (Commonwealth of)                        b
        1       Dominican Republic                                b
        1       Grenada                                           b
        1       Guam                                              b
        1       Jamaica                                           b
        1       Montserrat                                        b
        1       Northern Mariana Islands (Commonwealth of the)    b
        1       Puerto Rico                                       b
        1       Saint Kitts and Nevis                             b
        1       Saint Lucia                                       b
        1       Saint Vincent and the Grenadines                  b
        1       Trinidad and Tobago                               b
        1       Turks and Caicos Islands                          b
        1       United States of America                          b
        1       United States Virgin Islands                      b

        7       Kazakstan (Republic of)                           b
        7       Russian Federation                                b

Note:

        b       Integrated numbering plan.

(b) In ITU-T Rec. E.164, "The international public telecommunication numb=
ering =

plan" (05/97), the list of definitions includes:

4.7     country code (CC) for geographic areas
        F:  indicatif de pays pour zones g=E9ographiques
        S:  indicativo de pa=EDs para =E1reas geogr=E1ficas

        The combination of one, two or three digits identifying a specifi=
c =

        country, countries in an integrated numbering plan, or a specific=
       =

        geographic area.

It also includes text like these fragments:

        "... a country (or group of countries included in one integrated
        numbering plan or a specific geographic area) ..."

        "... it [e.g., the term country] identifies a specific country, a=
 group =

        of countries in an integrated numbering plan or a specific geogra=
phical =

        area."

Good luck. =


-Andy Gallant

______________________________ Reply Separator __________________________=
_______
Subject: RE: [Enum] ENUM FAQ
Author:  "Manfredi; Albert E" <Albert.Manfredi@PHL.Boeing.com> at INTERNE=
T-IMA
Date:    7/30/00 5:10 PM


> -----Original Message-----
> From: Eric Brunner [mailto:brunner@world.std.com]

> Not knowing the history of telephone numbering in Palestine > or East T=
imor,
> and knowing the history of telephone numbering in North > America, I su=
ggest
> this be re-phrased to:
> =

>       At the root of the E.164 administrative hierarchy, the ITU >     =
  =

allocates numeric labels (commonly referred to as "country
>       codes") and thereby creates new telephony numbering resources >  =
     as
needed.

To solve the +1 "country code" issue, since +1 refers to USA, Canada, and=
 the =

Bahamas, you might want to add:

While the "country code" usually identifies the numbers of a single count=
ry, =

these codes in fact apply to:

International public telecommunication number for geographic areas.

International public telecommunication number for global services.

International public telecommunication number for Networks.

> >  ... where +1 is the North
> > American country code.
> =

> Change to "where +1 is the value allocated to the United > States of Am=
erica."

But it isn't.

Bert
albert.e.manfredi@boeing.com

_______________________________________________ enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

--IMA.Boundary.7523105690
Content-Type: text/plain; charset="US-ASCII"; name="RFC822 message headers"
Content-Description: cc:Mail note part
Content-Disposition: inline; filename="RFC822 message headers"
Content-Transfer-Encoding: 7bit

Received: from ro.ctd.comsat.com ([134.133.40.45]) by cqgate5.cmc.comsat.com
with SMTP
  (IMA Internet Exchange 3.13) id 000BB500; Sun, 30 Jul 2000 17:16:03 -0400
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ro.ctd.comsat.com with smtp (Exim 2.12 #8)
	id 13J0MV-00033R-00
	for andrew.gallant@comsat.com; Sun, 30 Jul 2000 17:11:07 -0400
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18445;
	Sun, 30 Jul 2000 17:10:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18415
	for <enum@ns.ietf.org>; Sun, 30 Jul 2000 17:10:51 -0400 (EDT)
Received: from slb-smtpout-01.boeing.com ([12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25555
	for <enum@ietf.org>; Sun, 30 Jul 2000 17:10:51 -0400 (EDT)
Received: from slb-av-01.boeing.com ([129.172.13.4])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA19288
	for <enum@ietf.org>; Sun, 30 Jul 2000 14:10:50 -0700 (PDT)
Received: from slb-hub-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id OAA15243
	for <enum@ietf.org>; Sun, 30 Jul 2000 14:10:50 -0700 (PDT)
Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP;
Sun, 30 Jul 2000 14:10:38 -0700
Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21)
	id <3GJSSZ9Z>; Sun, 30 Jul 2000 17:10:37 -0400
Message-Id: <4102273CEB77D211869200805FE6F5939EBD65@xch-phl-01.he.boeing.com>
From: "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>
To: "'Eric Brunner'" <brunner@world.std.com>, rshockey@ix.netcom.com
Cc: enum@ietf.org
Subject: RE: [Enum] ENUM FAQ
Date: Sun, 30 Jul 2000 17:10:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
--IMA.Boundary.7523105690--

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 31 01:49:27 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12859
	for <enum-archive@odin.ietf.org>; Mon, 31 Jul 2000 01:49:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29584;
	Mon, 31 Jul 2000 01:47:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29557
	for <enum@ns.ietf.org>; Mon, 31 Jul 2000 01:47:40 -0400 (EDT)
Received: from bfgbhome.inetint.com (IDENT:root@tnt-dal-194.dallas.net [209.44.41.194])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12108
	for <enum@ietf.org>; Mon, 31 Jul 2000 01:47:39 -0400 (EDT)
Received: (from brian@localhost)
	by bfgbhome.inetint.com (8.9.3/8.9.3) id AAA08116;
	Mon, 31 Jul 2000 00:47:36 -0500
Date: Mon, 31 Jul 2000 00:47:35 -0500
From: "Brian F. G. Bidulock" <bidulock@dallas.net>
To: Andrew.Gallant@comsat.com
Cc: enum@ietf.org
Subject: Re: Re[2]: [Enum] ENUM FAQ
Message-ID: <20000731004735.A8088@dallas.net>
Reply-To: bidulock@dallas.net
Mail-Followup-To: Andrew.Gallant@comsat.com, enum@ietf.org
References: <00091122.C22219@comsat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <00091122.C22219@comsat.com>; from Andrew.Gallant@comsat.com on Sun, Jul 30, 2000 at 10:45:36PM -0400
Organization: Brian F. G. Bidulock, P. Eng.
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Andrew,

Wow!  No wonder there has been so many pager scams in the NANP!

Andrew.Gallant@comsat.com wrote:   (Sun, 30 Jul 2000 22:45:36)
> (a) In Annex to ITU Operational Bulletin No. 717 - 1.VI.2000, "COMPLEMENT TO 
> ITU-T RECOMMENDATION E.164 (05/1997) -- LIST OF ITU-T RECOMMENDATION E.164
> ASSIGNED COUNTRY CODES (POSITION ON 1 JUNE 2000)," the numerical list includes 
> these entries:
> 
> Country code    Country, Geographical area or Global service    Note
> 
>         1       Anguilla                                          b
>         1       Antigua and Barbuda                               b
>         1       Bahamas (Commonwealth of the)                     b
>         1       Barbados                                          b
>         1       Bermuda                                           b
>         1       British Virgin Islands                            b
>         1       Canada                                            b
>         1       Cayman Islands                                    b
>         1       Dominica (Commonwealth of)                        b
>         1       Dominican Republic                                b
>         1       Grenada                                           b
>         1       Guam                                              b
>         1       Jamaica                                           b
>         1       Montserrat                                        b
>         1       Northern Mariana Islands (Commonwealth of the)    b
>         1       Puerto Rico                                       b
>         1       Saint Kitts and Nevis                             b
>         1       Saint Lucia                                       b
>         1       Saint Vincent and the Grenadines                  b
>         1       Trinidad and Tobago                               b
>         1       Turks and Caicos Islands                          b
>         1       United States of America                          b
>         1       United States Virgin Islands                      b
> 

-- 
Brian F. G. Bidulock
bidulock@dallas.net

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 31 08:18:55 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26105
	for <enum-archive@odin.ietf.org>; Mon, 31 Jul 2000 08:18:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03705;
	Mon, 31 Jul 2000 08:18:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03678
	for <enum@ns.ietf.org>; Mon, 31 Jul 2000 08:18:10 -0400 (EDT)
Received: from joy.songbird.com (IDENT:root@joy.songbird.com [208.184.79.7])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25958
	for <enum@ietf.org>; Mon, 31 Jul 2000 08:18:07 -0400 (EDT)
Received: from PPPa69-ResalePittsburgh2-4R7226.saturn.bbn.com (PPPa69-ResalePittsburgh2-4R7226.saturn.bbn.com [4.54.197.162])
	by joy.songbird.com (8.9.3/8.9.3) with SMTP id FAA01491;
	Mon, 31 Jul 2000 05:17:56 -0700
X-Authentication-Warning: joy.songbird.com: PPPa69-ResalePittsburgh2-4R7226.saturn.bbn.com [4.54.197.162] didn't use HELO protocol
Message-Id: <4.3.2.20000730132003.00b69f00@mail.bayarea.net>
X-Sender: dcrocker@mail.bayarea.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Mon, 31 Jul 2000 08:11:50 -0700
To: "Shaw, Robert" <Robert.Shaw@itu.int>
From: Dave Crocker <dcrocker@brandenburg.com>
Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: IANA
  Consideratio ns
Cc: "'Patrik Fältström'" <paf@cisco.com>,
        Hong Liu <lhong@research.telcordia.com>, enum@ietf.org
In-Reply-To: <DA5558CC09AED311ABE10000778D757F4C2E37@mailsrv.itu.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 11:08 PM 7/23/00 +0200, Shaw, Robert wrote:
>One fly in the ointment is the reality that ICANN/IANA are basically under 
>the patronage of US DoC for what looks like many years to come so that 
>introduces a certain nervousness over a tree rooted in .arpa. If the ICANN 
>thing folds (certainly in  the realm of possibility), it looks to me that 
>IANA currently folds with it.


Bob,

Let's back up a moment and take a look at these points.  On the surface, 
they are both factually correct and obviously and seriously valid.  However 
as you know -- more than most -- the REAL reality is a tad more complicated 
and interesting.  (Almost makes one wish for the relative simplicity and 
comfort of the IAHC days...)

1.  The Internet is already thoroughly dependent upon .arpa and IANA 
administration of it.  Without in-addr.arpa, the net would stop.

2.  As political, messy, noisy, etc. as the ICANN/IANA current situation 
is, in reality it represents a stable administration that has been in 
operation for 15 years.

3.  In spite of some efforts to try to characterize the recent ICANN 
meeting in Yokohama as controversial or lacking consensus, what was obvious 
to anyone attending was just the opposite.  As such, concern over ICANN's 
future is pretty clearly misplaced.

4.  Although some have forcefully stated that the US government has 
ultimate authority over ICANN, the IANA activity always has -- and 
continues to be -- valid only due to broad consensus by the Internet 
operations community.

5.  To whatever extent there IS reality to the claim that the US government 
has ultimate authority over ICANN, it has ALWAYS been true, so the 
allocation of e164.arpa to IANA does not create any  new issues about 
Internet authority.


d/

=-=-=-=-=
Dave Crocker  <dcrocker@brandenburg.com>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 31 09:31:50 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06277
	for <enum-archive@odin.ietf.org>; Mon, 31 Jul 2000 09:31:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04604;
	Mon, 31 Jul 2000 09:28:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04574
	for <enum@ns.ietf.org>; Mon, 31 Jul 2000 09:28:39 -0400 (EDT)
Received: from spitfire.law.miami.edu (postfix@spitfire.law.miami.edu [129.171.187.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05754
	for <enum@ietf.org>; Mon, 31 Jul 2000 09:28:36 -0400 (EDT)
Received: by spitfire.law.miami.edu (Postfix, from userid 1113)
	id 7DAD95C3B5A; Mon, 31 Jul 2000 09:28:36 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by spitfire.law.miami.edu (Postfix) with ESMTP
	id 763345D3AEF; Mon, 31 Jul 2000 09:28:36 -0400 (EDT)
Date: Mon, 31 Jul 2000 09:28:36 -0400 (EDT)
From: "Michael Froomkin - U.Miami School of Law" <froomkin@law.miami.edu>
To: Dave Crocker <dcrocker@brandenburg.com>
Cc: "Shaw, Robert" <Robert.Shaw@itu.int>,
        "=?ISO-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" <paf@cisco.com>,
        Hong Liu <lhong@research.telcordia.com>, enum@ietf.org
Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: IANA  Consideratio
 ns
In-Reply-To: <4.3.2.20000730132003.00b69f00@mail.bayarea.net>
Message-ID: <Pine.LNX.4.10.10007310916200.12057-100000@spitfire.law.miami.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Regarding Dave Crocker's five points:

I do not think there is a consensus on points 3 & 4; you will hear a lot
of people on both sides.  I certainly to do not subscribe to them
personally. I wasn't in Japan, but the Yokohama meeting I heard about had
serious divisions; that said it the odds of ICANN collapsing in the short
run seem small -- although bigger than they did six months ago. The first
half of point 5 is certainly true; I don't know if the second half
necessarily follows.

Point 2 is not quite correct.  There was a very substantial break about
two years ago when ICANN took over IANA from USC.  There has been
continuity of personnel, but the management now is Mike Roberts (& Co.)
instead of Jon Postel.  ICANN claims the authority to tell IANA what to
do, although it has entered into an agreement with the IETF not to use
(much of) that authority.  Not quite the same thing.

On Mon, 31 Jul 2000, Dave Crocker wrote:

> At 11:08 PM 7/23/00 +0200, Shaw, Robert wrote:
> >One fly in the ointment is the reality that ICANN/IANA are basically under 
> >the patronage of US DoC for what looks like many years to come so that 

This is clearly correct; see the recent GAO report.

> >introduces a certain nervousness over a tree rooted in .arpa. If the
ICANN 
> >thing folds (certainly in  the realm of possibility), it looks to me that 
> >IANA currently folds with it.
> 

Legally, quite correct.  Having said that, and I suspect in partial
agreement with Dave Crocker, I do think that the simple collapse of IANA
is somewhat unlikely; more likely if ICANN were to collapse, the
government would find a new contractor to take over the "IANA function".

> Bob,
> 
> Let's back up a moment and take a look at these points.  On the surface, 
> they are both factually correct and obviously and seriously valid.  However 
> as you know -- more than most -- the REAL reality is a tad more complicated 
> and interesting.  (Almost makes one wish for the relative simplicity and 
> comfort of the IAHC days...)

:>

> 
> 1.  The Internet is already thoroughly dependent upon .arpa and IANA 
> administration of it.  Without in-addr.arpa, the net would stop.
> 
> 2.  As political, messy, noisy, etc. as the ICANN/IANA current situation 
> is, in reality it represents a stable administration that has been in 
> operation for 15 years.
> 
> 3.  In spite of some efforts to try to characterize the recent ICANN 
> meeting in Yokohama as controversial or lacking consensus, what was obvious 
> to anyone attending was just the opposite.  As such, concern over ICANN's 
> future is pretty clearly misplaced.
> 
> 4.  Although some have forcefully stated that the US government has 
> ultimate authority over ICANN, the IANA activity always has -- and 
> continues to be -- valid only due to broad consensus by the Internet 
> operations community.
> 
> 5.  To whatever extent there IS reality to the claim that the US government 
> has ultimate authority over ICANN, it has ALWAYS been true, so the 
> allocation of e164.arpa to IANA does not create any  new issues about 
> Internet authority.
> 

-- 
		Please visit http://www.icannwatch.org
A. Michael Froomkin   |    Professor of Law    |   froomkin@law.tm
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
                        -->It's hot here.<--


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 31 14:19:26 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20153
	for <enum-archive@odin.ietf.org>; Mon, 31 Jul 2000 14:19:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09175;
	Mon, 31 Jul 2000 14:16:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09143
	for <enum@ns.ietf.org>; Mon, 31 Jul 2000 14:16:12 -0400 (EDT)
Received: from joy.songbird.com (IDENT:root@joy.songbird.com [208.184.79.7])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19785
	for <enum@ietf.org>; Mon, 31 Jul 2000 14:16:09 -0400 (EDT)
Received: from wireless-134-122.ietf.marconi.com (wireless-134-122.ietf.marconi.com [147.73.134.122])
	by joy.songbird.com (8.9.3/8.9.3) with SMTP id LAA04360;
	Mon, 31 Jul 2000 11:15:34 -0700
X-Authentication-Warning: joy.songbird.com: wireless-134-122.ietf.marconi.com [147.73.134.122] didn't use HELO protocol
Message-Id: <4.3.2.20000731140123.0441c4e0@mail.bayarea.net>
X-Sender: dcrocker@mail.bayarea.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Mon, 31 Jul 2000 14:15:06 -0400
To: "Michael Froomkin - U.Miami School of Law" <froomkin@law.miami.edu>
From: Dave Crocker <dcrocker@brandenburg.com>
Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: IANA 
  Consideratio ns
Cc: "Shaw, Robert" <Robert.Shaw@itu.int>, "'Patrik Fältström'" <paf@cisco.com>,
        Hong Liu <lhong@research.telcordia.com>, enum@ietf.org
In-Reply-To: <Pine.LNX.4.10.10007310916200.12057-100000@spitfire.law.mia
 mi.edu>
References: <4.3.2.20000730132003.00b69f00@mail.bayarea.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 09:28 AM 7/31/00 -0400, Michael Froomkin - U.Miami School of Law wrote:
>serious divisions; that said it the odds of ICANN collapsing in the short
>run seem small -- although bigger than they did six months ago. The first

That sweeping assessment, absent detailed listing of its basis, translates 
into a statement more of personal hope than meaningful analysis.


>half of point 5 is certainly true; I don't know if the second half
>necessarily follows.

My wording was not as careful as it should have been.

I meant that no new issues in IANA and DNS administration are raised.

To the extent that anyone does know if that assessment is true -- and they 
wish to claim that it is not -- they need to provide details which 
substantiate additional concern, besides the lack of their knowing the 
truth of the assessment.


>Point 2 is not quite correct.  There was a very substantial break about
>two years ago when ICANN took over IANA from USC.  There has been

And here my wording was careful.

In fact the administration has been continuous and stable.

The policy-level work has recently been erratic.  Different area of concern.

For those aware of the 15-year history, it is worth noting that the 
policy-level work has ALWAYS been erratic...


>instead of Jon Postel.  ICANN claims the authority to tell IANA what to
>do, although it has entered into an agreement with the IETF not to use
>(much of) that authority.  Not quite the same thing.

In fact, there IS an agreement with the IETF, but it is only with respect 
to those on-going administrative issues over which the IETF has authority.

My suspicion is that the intended reference, here, was to issues that have 
essentially never been an IETF matter.  My other suspicion is that the 
agreement to exclude/limit has not happened, so it would be
more than slightly helpful to see a reference to documentation that 
substantiates the claimed agreement.

d/

=-=-=-=-=
Dave Crocker  <dcrocker@brandenburg.com>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 31 14:28:13 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21133
	for <enum-archive@odin.ietf.org>; Mon, 31 Jul 2000 14:28:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09406;
	Mon, 31 Jul 2000 14:26:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09375
	for <enum@ns.ietf.org>; Mon, 31 Jul 2000 14:26:46 -0400 (EDT)
Received: from joy.songbird.com (IDENT:root@joy.songbird.com [208.184.79.7])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20967
	for <enum@ietf.org>; Mon, 31 Jul 2000 14:26:44 -0400 (EDT)
Received: from wireless-134-122.ietf.marconi.com (wireless-134-122.ietf.marconi.com [147.73.134.122])
	by joy.songbird.com (8.9.3/8.9.3) with SMTP id LAA04452;
	Mon, 31 Jul 2000 11:25:35 -0700
X-Authentication-Warning: joy.songbird.com: wireless-134-122.ietf.marconi.com [147.73.134.122] didn't use HELO protocol
Message-Id: <4.3.2.20000731142231.00e00c60@mail.bayarea.net>
X-Sender: dcrocker@mail.bayarea.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Mon, 31 Jul 2000 14:23:50 -0400
To: "Michael Froomkin - U.Miami School of Law" <froomkin@law.miami.edu>
From: Dave Crocker <dcrocker@brandenburg.com>
Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: IANA 
  Consideratio ns
Cc: "Shaw, Robert" <Robert.Shaw@itu.int>, "'Patrik Fältström'" <paf@cisco.com>,
        Hong Liu <lhong@research.telcordia.com>, enum@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

(typo corrected.)

At 09:28 AM 7/31/00 -0400, Michael Froomkin - U.Miami School of Law wrote:
>serious divisions; that said it the odds of ICANN collapsing in the short
>run seem small -- although bigger than they did six months ago. The first

That sweeping assessment, absent detailed listing of its basis, translates 
into a statement more of personal hope than meaningful analysis.


>half of point 5 is certainly true; I don't know if the second half
>necessarily follows.

My wording was not as careful as it should have been.

I meant that no new issues in IANA and DNS administration are raised.

To the extent that anyone *says they do not* know if that assessment is 
true -- and they wish to claim *or imply* that it is not -- they need to 
provide details which substantiate additional concern, besides the lack of 
their knowing the truth of the assessment.


>Point 2 is not quite correct.  There was a very substantial break about
>two years ago when ICANN took over IANA from USC.  There has been

And here my wording was careful.

In fact the administration has been continuous and stable.

The policy-level work has recently been erratic.  Different area of concern.

For those aware of the 15-year history, it is worth noting that the 
policy-level work has ALWAYS been erratic...


>instead of Jon Postel.  ICANN claims the authority to tell IANA what to
>do, although it has entered into an agreement with the IETF not to use
>(much of) that authority.  Not quite the same thing.

In fact, there IS an agreement with the IETF, but it is only with respect 
to those on-going administrative issues over which the IETF has authority.

My suspicion is that the intended reference, here, was to issues that have 
essentially never been an IETF matter.  My other suspicion is that the 
agreement to exclude/limit has not happened, so it would be
more than slightly helpful to see a reference to documentation that 
substantiates the claimed agreement.

d/

=-=-=-=-=
Dave Crocker  <dcrocker@brandenburg.com>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Jul 31 15:07:04 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26944
	for <enum-archive@odin.ietf.org>; Mon, 31 Jul 2000 15:07:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10248;
	Mon, 31 Jul 2000 15:05:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10218
	for <enum@ns.ietf.org>; Mon, 31 Jul 2000 15:05:10 -0400 (EDT)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26526
	for <enum@ietf.org>; Mon, 31 Jul 2000 15:05:07 -0400 (EDT)
Received: from [147.73.133.93] (ssh.cisco.com [171.69.10.34])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id MAA18962;
	Mon, 31 Jul 2000 12:04:12 -0700 (PDT)
Mime-Version: 1.0
X-Sender: pfaltstr@127.0.0.1
Message-Id: <p04320401b5ab78bcd4ea@[147.73.133.93]>
In-Reply-To: <4.3.2.20000731142231.00e00c60@mail.bayarea.net>
References: <4.3.2.20000731142231.00e00c60@mail.bayarea.net>
Date: Mon, 31 Jul 2000 15:02:53 -0400
To: Dave Crocker <dcrocker@brandenburg.com>,
        "Michael Froomkin - U.Miami School of Law" <froomkin@law.miami.edu>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <paf@cisco.com>
Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: IANA   
 Consideratio ns
Cc: "Shaw, Robert" <Robert.Shaw@itu.int>,
        Hong Liu <lhong@research.telcordia.com>, enum@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Friends, please stay friends. Let's not have yet-another-mailinglist 
which turns into something which looks like "how do we 
fix/replace/change/xxxx ICANN".

Also, the IAB has already asked the wg to use .ARPA for these kind of 
architectual discussions. Before you talk with IAB about your 
concerns, you should read 
http://www.iab.org/iab/statement-on-infrastructure-domains.txt, i.e. 
"IAB Statement on Infrastructure Domain and Subdomains".

Now, we can of course in the wg go back to IAB to say either of:

(1) We don't belive that the E164 numbers is something which falls 
into the category of domains which you talk about in your statement

(2) We don't agree with the IAB on their conclusions, and rather see 
that infrastructural things should be in some other place in the DNS 
hierarchy.

Regarding these, I personally think only (2) is something that can be 
discussed, as I belive (1) is true for the E.164 numbers. This 
because my belief is that the E.164 number -- with the wide knowledge 
people have about E.164 all over the world -- will be really 
important and used in various applications all over the place. Just 
look at the interest in ENUM!

Regarding (2), I have not been able to find a single place in the DNS 
tree which can be as stable as .arpa. This from an operational 
perspective (widely distributed stable home for the NS for the E164 
RR, regardless of parent zone owner). All alternatives I have found 
are not at all as easy to create as e164.arpa. For example, one 
alternative would be to create a new TLD....how long time and how 
much discussions, with how many bodies do you think is needed for 
that to happen? Directly under ".int"? Well, should/can/want we 
really touch the discussions regarding policy/home for .int in this 
wg? Under "itu.int"? Is it really wise to have infrastructural issues 
under the same domain as an organization, what is the risk of failure 
when they add www1.itu.int to the same zone? Etc etc etc...

The answer to all of these questions is NO, and that e164.arpa is the 
best place we can place things at the moment, exactly as IAB has 
already said.

   paf

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum