From enum-admin@ietf.org  Fri Jan  7 12:09: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 MAA22861
	for <enum-archive@ietf.org>; Fri, 7 Jan 2000 12:09:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12120;
	Fri, 7 Jan 2000 12:07:48 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12089
	for <enum@optimus.ietf.org>; Fri, 7 Jan 2000 12:07:45 -0500 (EST)
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 MAA22834
	for <enum@ietf.org>; Fri, 7 Jan 2000 12:08:30 -0500 (EST)
Received: by dnspri.npac.com; id KAA29686; Fri, 7 Jan 2000 10:18:46 -0600 (CST)
Received: from nodnsquery(208.143.39.132) by dnspri.npac.com via smap (V5.0)
	id xma029635; Fri, 7 Jan 00 10:17:55 -0600
Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0)
	id <Z0P3JPX1>; Fri, 7 Jan 2000 10:13:43 -0600
Message-ID: <ED88182BFF78D211A4D800A0C9E9435C3BE9EB@dc02.npac.com>
From: James Yu <james.yu@neustar.com>
To: enum@ietf.org
Date: Fri, 7 Jan 2000 10:11:13 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Enum] DNS for E.164-IP Address Mapping
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 SCN, the same E.164 number (a national number in the US) can be
mapped to different Signaling System 7 addresses (e.g., point codes)
depending on the applications.  For example, an E.164 number is mapped to a
Line Information Database (LIDB) point code for caller ID and caller name
services, and to an end office (class 5 switch) that serves the E.164 number
for Call Completion to Busy Subscriber (CCBS) service.  

The same will apply to the E.164 to IP address mapping.  So far, enum has
focused on the voice calls only.  There are other services that will require
mapping between the E.164 number and the IP address of a server/database
depending on the applications.

One application that I have identified is the Inter-Company Voice
Mail/Messaging where a voice mail/messaging server's IP address is to be
mapped to a particular E.164 number.  There will be others.   If DNS is to
be used for all the services for E.164 to IP address mapping, we may need
the ability to indicate the "application/service" type in the DNS query so
that specific records can be returned.  Another may is just to return all
the records that may be associated with the associated E.164 number with
different record types for different applications/services and let the DNS
query sender decide which one or ones to use.   Any comments?

James Yu
Principal Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue, NW,
Suite 550
Washington, D.C. 20005
USA
+1-202-533-2814 (B)
+1-202-533-2975 (Fax)
+1-202-256-1200 (Mobile)
james.yu@neustar.com
http://www.neustar.com


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


From enum-admin@ietf.org  Fri Jan  7 12:15: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 MAA23124
	for <enum-archive@ietf.org>; Fri, 7 Jan 2000 12:15:40 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12264;
	Fri, 7 Jan 2000 12:14:25 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12230
	for <enum@optimus.ietf.org>; Fri, 7 Jan 2000 12:14:23 -0500 (EST)
Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23109
	for <enum@ietf.org>; Fri, 7 Jan 2000 12:15:20 -0500 (EST)
Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.72.186.2])
	id QQhwzl07950;
	Fri, 7 Jan 2000 17:15:17 GMT
Received: from dynamicsoft.com (1Cust170.tnt1.freehold.nj.da.uu.net [63.17.113.170])
	by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id MAA17697;
	Fri, 7 Jan 2000 12:15:15 -0500 (EST)
Message-ID: <387620EA.9F78B92E@dynamicsoft.com>
Date: Fri, 07 Jan 2000 12:22:50 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: James Yu <james.yu@neustar.com>
CC: enum@ietf.org
Subject: Re: [Enum] DNS for E.164-IP Address Mapping
References: <ED88182BFF78D211A4D800A0C9E9435C3BE9EB@dc02.npac.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit

This is already addressed by the current solution. You can obtain a
variety of URL types (sip, ldap, mailto) from the DNS. Enum is actually
better described as a phone number to URL mapping solution.

-Jonathan R.

James Yu wrote:
> 
> In the SCN, the same E.164 number (a national number in the US) can be
> mapped to different Signaling System 7 addresses (e.g., point codes)
> depending on the applications.  For example, an E.164 number is mapped to a
> Line Information Database (LIDB) point code for caller ID and caller name
> services, and to an end office (class 5 switch) that serves the E.164 number
> for Call Completion to Busy Subscriber (CCBS) service.
> 
> The same will apply to the E.164 to IP address mapping.  So far, enum has
> focused on the voice calls only.  There are other services that will require
> mapping between the E.164 number and the IP address of a server/database
> depending on the applications.
> 
> One application that I have identified is the Inter-Company Voice
> Mail/Messaging where a voice mail/messaging server's IP address is to be
> mapped to a particular E.164 number.  There will be others.   If DNS is to
> be used for all the services for E.164 to IP address mapping, we may need
> the ability to indicate the "application/service" type in the DNS query so
> that specific records can be returned.  Another may is just to return all
> the records that may be associated with the associated E.164 number with
> different record types for different applications/services and let the DNS
> query sender decide which one or ones to use.   Any comments?
> 
> James Yu
> Principal Technical Industry Liaison
> NeuStar Inc.
> 1120 Vermont Avenue, NW,
> Suite 550
> Washington, D.C. 20005
> USA
> +1-202-533-2814 (B)
> +1-202-533-2975 (Fax)
> +1-202-256-1200 (Mobile)
> james.yu@neustar.com
> http://www.neustar.com
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www.ietf.org/mailman/listinfo/enum

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

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


From enum-admin@ietf.org  Fri Jan  7 13:17: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 NAA24556
	for <enum-archive@ietf.org>; Fri, 7 Jan 2000 13:17:34 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13524;
	Fri, 7 Jan 2000 13:15:36 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13493
	for <enum@optimus.ietf.org>; Fri, 7 Jan 2000 13:15:34 -0500 (EST)
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 NAA24541
	for <enum@ietf.org>; Fri, 7 Jan 2000 13:16:22 -0500 (EST)
Received: by dnspri.npac.com; id MAA18130; Fri, 7 Jan 2000 12:16:02 -0600 (CST)
Received: from nodnsquery(208.143.39.132) by dnspri.npac.com via smap (V5.0)
	id xma018056; Fri, 7 Jan 00 12:15:34 -0600
Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0)
	id <Z0P3JQFQ>; Fri, 7 Jan 2000 12:11:22 -0600
Message-ID: <ED88182BFF78D211A4D800A0C9E9435C3BE9ED@dc02.npac.com>
From: James Yu <james.yu@neustar.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: enum@ietf.org
Subject: RE: [Enum] DNS for E.164-IP Address Mapping
Date: Fri, 7 Jan 2000 12:08:47 -0600 
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 assume that the "scheme" or "mechanism" is there by using different URL
types.  Would appreciate if you can briefly describe the scheme/mechanism or
point to some documents.  For services/applications that are not yet
supported by the identified URL types, I assume that new URL types must be
defined.  Is it correct?

James

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Friday, January 07, 2000 12:23 PM
> To: James Yu
> Cc: enum@ietf.org
> Subject: Re: [Enum] DNS for E.164-IP Address Mapping
> 
> 
> This is already addressed by the current solution. You can obtain a
> variety of URL types (sip, ldap, mailto) from the DNS. Enum 
> is actually
> better described as a phone number to URL mapping solution.
> 
> -Jonathan R.
> 
> James Yu wrote:
> > 
> > In the SCN, the same E.164 number (a national number in the 
> US) can be
> > mapped to different Signaling System 7 addresses (e.g., point codes)
> > depending on the applications.  For example, an E.164 
> number is mapped to a
> > Line Information Database (LIDB) point code for caller ID 
> and caller name
> > services, and to an end office (class 5 switch) that serves 
> the E.164 number
> > for Call Completion to Busy Subscriber (CCBS) service.
> > 
> > The same will apply to the E.164 to IP address mapping.  So 
> far, enum has
> > focused on the voice calls only.  There are other services 
> that will require
> > mapping between the E.164 number and the IP address of a 
> server/database
> > depending on the applications.
> > 
> > One application that I have identified is the Inter-Company Voice
> > Mail/Messaging where a voice mail/messaging server's IP 
> address is to be
> > mapped to a particular E.164 number.  There will be others. 
>   If DNS is to
> > be used for all the services for E.164 to IP address 
> mapping, we may need
> > the ability to indicate the "application/service" type in 
> the DNS query so
> > that specific records can be returned.  Another may is just 
> to return all
> > the records that may be associated with the associated 
> E.164 number with
> > different record types for different applications/services 
> and let the DNS
> > query sender decide which one or ones to use.   Any comments?
> > 
> > James Yu
> > Principal Technical Industry Liaison
> > NeuStar Inc.
> > 1120 Vermont Avenue, NW,
> > Suite 550
> > Washington, D.C. 20005
> > USA
> > +1-202-533-2814 (B)
> > +1-202-533-2975 (Fax)
> > +1-202-256-1200 (Mobile)
> > james.yu@neustar.com
> > http://www.neustar.com
> > 
> > _______________________________________________
> > enum mailing list
> > enum@ietf.org
> > http://www.ietf.org/mailman/listinfo/enum
> 
> -- 
> Jonathan D. Rosenberg                       200 Executive Drive
> Chief Scientist                             Suite 120 
> dynamicsoft                                 West Orange, NJ 07052
> jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
> 

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


From enum-admin@ietf.org  Fri Jan  7 13:38: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 NAA24906
	for <enum-archive@ietf.org>; Fri, 7 Jan 2000 13:38:00 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14072;
	Fri, 7 Jan 2000 13:36:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14039
	for <enum@optimus.ietf.org>; Fri, 7 Jan 2000 13:36:41 -0500 (EST)
Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24887
	for <enum@ietf.org>; Fri, 7 Jan 2000 13:37:40 -0500 (EST)
Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.72.186.2])
	id QQhwzq21259;
	Fri, 7 Jan 2000 18:37:40 GMT
Received: from dynamicsoft.com (1Cust170.tnt1.freehold.nj.da.uu.net [63.17.113.170])
	by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id NAA17741;
	Fri, 7 Jan 2000 13:37:37 -0500 (EST)
Message-ID: <38763438.F32B1369@dynamicsoft.com>
Date: Fri, 07 Jan 2000 13:45:12 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: James Yu <james.yu@neustar.com>
CC: enum@ietf.org
Subject: Re: [Enum] DNS for E.164-IP Address Mapping
References: <ED88182BFF78D211A4D800A0C9E9435C3BE9ED@dc02.npac.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit

I used the work "mechanism" when URI scheme is the correct term. Check
rfc2396 for a general discussion. There are many URI schemes defined;
I'm not sure if there is an IANA procedure somewhere defined for
registering them. 

-Jonathan R.

James Yu wrote:
> 
> I assume that the "scheme" or "mechanism" is there by using different URL
> types.  Would appreciate if you can briefly describe the scheme/mechanism or
> point to some documents.  For services/applications that are not yet
> supported by the identified URL types, I assume that new URL types must be
> defined.  Is it correct?
> 
> James
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > Sent: Friday, January 07, 2000 12:23 PM
> > To: James Yu
> > Cc: enum@ietf.org
> > Subject: Re: [Enum] DNS for E.164-IP Address Mapping
> >
> >
> > This is already addressed by the current solution. You can obtain a
> > variety of URL types (sip, ldap, mailto) from the DNS. Enum
> > is actually
> > better described as a phone number to URL mapping solution.
> >
> > -Jonathan R.
> >
> > James Yu wrote:
> > >
> > > In the SCN, the same E.164 number (a national number in the
> > US) can be
> > > mapped to different Signaling System 7 addresses (e.g., point codes)
> > > depending on the applications.  For example, an E.164
> > number is mapped to a
> > > Line Information Database (LIDB) point code for caller ID
> > and caller name
> > > services, and to an end office (class 5 switch) that serves
> > the E.164 number
> > > for Call Completion to Busy Subscriber (CCBS) service.
> > >
> > > The same will apply to the E.164 to IP address mapping.  So
> > far, enum has
> > > focused on the voice calls only.  There are other services
> > that will require
> > > mapping between the E.164 number and the IP address of a
> > server/database
> > > depending on the applications.
> > >
> > > One application that I have identified is the Inter-Company Voice
> > > Mail/Messaging where a voice mail/messaging server's IP
> > address is to be
> > > mapped to a particular E.164 number.  There will be others.
> >   If DNS is to
> > > be used for all the services for E.164 to IP address
> > mapping, we may need
> > > the ability to indicate the "application/service" type in
> > the DNS query so
> > > that specific records can be returned.  Another may is just
> > to return all
> > > the records that may be associated with the associated
> > E.164 number with
> > > different record types for different applications/services
> > and let the DNS
> > > query sender decide which one or ones to use.   Any comments?
> > >
> > > James Yu
> > > Principal Technical Industry Liaison
> > > NeuStar Inc.
> > > 1120 Vermont Avenue, NW,
> > > Suite 550
> > > Washington, D.C. 20005
> > > USA
> > > +1-202-533-2814 (B)
> > > +1-202-533-2975 (Fax)
> > > +1-202-256-1200 (Mobile)
> > > james.yu@neustar.com
> > > http://www.neustar.com
> > >
> > > _______________________________________________
> > > enum mailing list
> > > enum@ietf.org
> > > http://www.ietf.org/mailman/listinfo/enum
> >
> > --
> > Jonathan D. Rosenberg                       200 Executive Drive
> > Chief Scientist                             Suite 120
> > dynamicsoft                                 West Orange, NJ 07052
> > jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
> > http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> > http://www.dynamicsoft.com
> >

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

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


From enum-admin@ietf.org  Fri Jan  7 14:35: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 OAA25727
	for <enum-archive@ietf.org>; Fri, 7 Jan 2000 14:35:28 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15264;
	Fri, 7 Jan 2000 14:34:11 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15235
	for <enum@optimus.ietf.org>; Fri, 7 Jan 2000 14:34:10 -0500 (EST)
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25710
	for <enum@ietf.org>; Fri, 7 Jan 2000 14:35:05 -0500 (EST)
Received: from laptop (stl-mo16-50.ix.netcom.com [207.222.134.50])
	by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id OAA25363;
	Fri, 7 Jan 2000 14:34:57 -0500 (EST)
Message-Id: <4.2.0.58.20000107132445.00a18210@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 07 Jan 2000 13:34:18 -0600
To: James Yu <james.yu@neustar.com>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: Re: [Enum] DNS for E.164-IP Address Mapping
Cc: enum@ietf.org, jdrosen@dynamicsoft.com, paf@swip.net
In-Reply-To: <38763438.F32B1369@dynamicsoft.com>
References: <ED88182BFF78D211A4D800A0C9E9435C3BE9ED@dc02.npac.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 01:45 PM 1/7/2000 -0500, Jonathan Rosenberg wrote:
>I used the work "mechanism" when URI scheme is the correct term. Check
>rfc2396 for a general discussion. There are many URI schemes defined;
>I'm not sure if there is an IANA procedure somewhere defined for
>registering them.
>
>-Jonathan R.


Well for telephony applications there is a draft outlining how the URL's 
should be defined. I'm sure if there were other types of applications that 
need to be referenced in NAPTR records... Universal Messaging Servers, 
T.38, it should be no trouble defining a simple registration procedure.

Jonathan.... one of the things I'm increasingly concerned about is DNS 
security here. Do you have any thoughts on how much of DNSSEC we might have 
to require?


Title           : URLs for Telephone Calls
         Author(s)       : A. Vaha-Sipila
         Filename        : draft-antti-telephony-url-12.txt
         Pages           : 22
         Date            : 29-Dec-99

This document specifies URL (Uniform Resource Locator) schemes
'tel', 'fax' and 'modem' for specifying the location of a
terminal in the phone network and the connection types (modes of
operation) that can be used to connect to that entity. This
specification covers voice calls (normal phone calls, answering
machines and voice messaging systems), facsimile (telefax) calls and
data calls, both for POTS and digital/mobile subscribers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-antti-telephony-url-12.txt



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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


From enum-admin@ietf.org  Mon Jan 10 01:37: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 BAA17642
	for <enum-archive@ietf.org>; Mon, 10 Jan 2000 01:37:37 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20948;
	Mon, 10 Jan 2000 01:34:25 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20913
	for <enum@optimus.ietf.org>; Mon, 10 Jan 2000 01:34:18 -0500 (EST)
Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17596
	for <enum@ietf.org>; Mon, 10 Jan 2000 01:35:13 -0500 (EST)
Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.72.186.2])
	id QQhxiw18870;
	Mon, 10 Jan 2000 06:35:10 GMT
Received: from dynamicsoft.com (1Cust121.tnt1.freehold.nj.da.uu.net [63.17.113.121])
	by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id BAA18434;
	Mon, 10 Jan 2000 01:35:08 -0500 (EST)
Message-ID: <38797F73.84C2F430@dynamicsoft.com>
Date: Mon, 10 Jan 2000 01:42:59 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Richard Shockey <rshockey@ix.netcom.com>
CC: James Yu <james.yu@neustar.com>, enum@ietf.org, paf@swip.net
Subject: Re: [Enum] DNS for E.164-IP Address Mapping
References: <ED88182BFF78D211A4D800A0C9E9435C3BE9ED@dc02.npac.com> <4.2.0.58.20000107132445.00a18210@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 Shockey wrote:
> 
> Jonathan.... one of the things I'm increasingly concerned about is DNS
> security here. Do you have any thoughts on how much of DNSSEC we might have
> to require?

Not really... I hope some real security experts can provide guidance on
that. Clearly the DNS SIG record is most important for us; I presume we
would need to provide signatures on both the NS and SRV (with NS really
important). I'd love to hear from folks whether dnssec is deployed and
used anywhere - is it in bind?

-Jonathan R.


-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

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


From enum-admin@ietf.org  Mon Jan 10 02:05: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 CAA25978
	for <enum-archive@ietf.org>; Mon, 10 Jan 2000 02:05:49 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA21793;
	Mon, 10 Jan 2000 02:02:33 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA21760
	for <enum@optimus.ietf.org>; Mon, 10 Jan 2000 02:02:31 -0500 (EST)
Received: from nix.swip.net (nix.swip.net [192.71.220.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23670
	for <enum@ietf.org>; Mon, 10 Jan 2000 02:03:32 -0500 (EST)
Received: from 192.168.124.51 (workstation1.swip.net [130.244.254.1]) 
          by nix.swip.net (8.8.8/8.8.8) with ESMTP 
          id IAA08185; 
          Mon, 10 Jan 2000 08:01:36 +0100 (MET)
Date: Mon, 10 Jan 2000 08:01:48 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@swip.net>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Richard Shockey <rshockey@ix.netcom.com>
cc: James Yu <james.yu@neustar.com>, enum@ietf.org
Subject: Re: [Enum] DNS for E.164-IP Address Mapping
Message-ID: <6025635.3156480108@[192.168.124.51]>
In-Reply-To: <38797F73.84C2F430@dynamicsoft.com>
X-Mailer: Mulberry (MacOS) [2.0.0b7, s/n U-301169]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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

--On 2000-01-10 01.42 -0500, Jonathan Rosenberg <jdrosen@dynamicsoft.com> 
wrote:

>> Jonathan.... one of the things I'm increasingly concerned about is DNS
>> security here. Do you have any thoughts on how much of DNSSEC we might
>> have to require?
>
> Not really... I hope some real security experts can provide guidance on
> that. Clearly the DNS SIG record is most important for us; I presume we
> would need to provide signatures on both the NS and SRV (with NS really
> important). I'd love to hear from folks whether dnssec is deployed and
> used anywhere - is it in bind?

Some part is in bind already, but not to a level that it scales so one can 
use it in operations. The signing process and some other things makes 
operations very difficult. We also need some resolver library additions 
which can verify the chain of keys/sig, aswell as some secure connection 
between the client resolver and the host which verifies the keys.

Note though that I don't see that we need more security here than what we 
have on DNS in general. I.e. if the ENUM resolution ends up with an 
interaction using SIP, H.323 or some other protocol on top of IP, that will 
be as insecure as the ENUM resolution. I.e. strengthening the ENUM part 
will not help until all parts are stronger.

So, because of this, I definitely think we should point to, and find it 
being enough that, DNSSEC is what should be used to secure DNS. I.e. this 
whole thing of securing DNS is someone elses problem :-)

It is VERY easy to say, but this time I think it is the only reasonable 
thing to say.

   paf




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


From enum-admin@ietf.org  Tue Jan 11 10:43: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 KAA13275
	for <enum-archive@ietf.org>; Tue, 11 Jan 2000 10:43:19 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20136;
	Tue, 11 Jan 2000 10:39:51 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20104
	for <enum@optimus.ietf.org>; Tue, 11 Jan 2000 10:39:45 -0500 (EST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13167
	for <enum@ietf.org>; Tue, 11 Jan 2000 10:40:48 -0500 (EST)
Received: from zed.isi.edu (zed-e.isi.edu [128.9.160.57])
	by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id HAA13261;
	Tue, 11 Jan 2000 07:40:39 -0800 (PST)
From: Bill Manning <bmanning@ISI.EDU>
Received: (from bmanning@localhost)
	by zed.isi.edu (8.8.7/8.8.6) id HAA09383;
	Tue, 11 Jan 2000 07:40:35 -0800 (PST)
Message-Id: <200001111540.HAA09383@zed.isi.edu>
Subject: Re: [Enum] DNS for E.164-IP Address Mapping
To: jdrosen@dynamicsoft.com (Jonathan Rosenberg)
Date: Tue, 11 Jan 2000 07:40:35 -0800 (PST)
Cc: rshockey@ix.netcom.com (Richard Shockey), james.yu@neustar.com (James Yu),
        enum@ietf.org, paf@swip.net
In-Reply-To: <38797F73.84C2F430@dynamicsoft.com> from "Jonathan Rosenberg" at Jan 10, 2000 01:42:59 AM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
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 Shockey wrote:
% > 
% > Jonathan.... one of the things I'm increasingly concerned about is DNS
% > security here. Do you have any thoughts on how much of DNSSEC we might have
% > to require?
% 
% Not really... I hope some real security experts can provide guidance on
% that. Clearly the DNS SIG record is most important for us; I presume we
% would need to provide signatures on both the NS and SRV (with NS really
% important). I'd love to hear from folks whether dnssec is deployed and
% used anywhere - is it in bind?

DNSSEC is not deployed widely and is still only used in testbeds. It's been
in BIND for some time but is not always backward compatable.  The current
release will sign both NS and SRV records.

--bill

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


From enum-admin@ietf.org  Tue Jan 11 10:49: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 KAA13392
	for <enum-archive@ietf.org>; Tue, 11 Jan 2000 10:49:21 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20410;
	Tue, 11 Jan 2000 10:47:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20374
	for <enum@optimus.ietf.org>; Tue, 11 Jan 2000 10:47:42 -0500 (EST)
Received: from typhoon.mail.pipex.net (typhoon.mail.pipex.net [158.43.128.27])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13360
	for <enum@ietf.org>; Tue, 11 Jan 2000 10:48:44 -0500 (EST)
Received: (qmail 15954 invoked from network); 11 Jan 2000 15:48:30 -0000
Received: from userbk39.uk.uudial.com (HELO gk-vaio) (62.188.144.47)
  by smtp.dial.pipex.com with SMTP; 11 Jan 2000 15:48:30 -0000
Message-Id: <4.2.2.20000111112914.00aa6240@pop.dial.pipex.com>
X-Sender: maiw03@pop.dial.pipex.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Tue, 11 Jan 2000 11:33:10 +0000
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
From: Graham Klyne <GK@Dial.pipex.com>
Subject: Re: [Enum] DNS for E.164-IP Address Mapping
Cc: James Yu <james.yu@neustar.com>, enum@ietf.org
In-Reply-To: <38763438.F32B1369@dynamicsoft.com>
References: <ED88182BFF78D211A4D800A0C9E9435C3BE9ED@dc02.npac.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 01:45 PM 1/7/00 -0500, Jonathan Rosenberg wrote:
>I used the work "mechanism" when URI scheme is the correct term. Check
>rfc2396 for a general discussion. There are many URI schemes defined;
>I'm not sure if there is an IANA procedure somewhere defined for
>registering them.
>
>-Jonathan R.

There is now:

A new Request for Comments is now available in online RFC libraries.

         BCP 35
         RFC 2717

         Title:      Registration Procedures for URL Scheme Names
         Author(s):  R. Petke, I. King
         Status:     Best Current Practice
         Date:       November 1999
         Mailbox:    rpetke@wcom.net, iking@microsoft.com
         Pages:      10
         Characters: 19780
         Updates/Obsoletes/See Also: None
         I-D Tag:    draft-ietf-urlreg-procedures-08.txt

         URL:        ftp://ftp.isi.edu/in-notes/rfc2717.txt

#g

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


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


From enum-admin@ietf.org  Tue Jan 11 11:29: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 LAA14454
	for <enum-archive@ietf.org>; Tue, 11 Jan 2000 11:29:22 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21536;
	Tue, 11 Jan 2000 11:26:22 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21506
	for <enum@optimus.ietf.org>; Tue, 11 Jan 2000 11:26:21 -0500 (EST)
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 LAA14395
	for <enum@ietf.org>; Tue, 11 Jan 2000 11:27:24 -0500 (EST)
Received: from laptop (stl-mo14-01.ix.netcom.com [207.222.133.1])
	by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA22996
	for <enum@ietf.org>; Tue, 11 Jan 2000 11:27:22 -0500 (EST)
Message-Id: <4.2.0.58.20000111102333.00a8d9d0@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 11 Jan 2000 10:25:18 -0600
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] Fwd: I-D ACTION:draft-ietf-ldapext-locate-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


For our general reference... the combination of 164 to service in 
combination with a LDAP query has a number of interesting applications.


>To: IETF-Announce: ;
>Cc: ietf-ldapext@NETSCAPE.COM
>From: Internet-Drafts@ietf.org
>Reply-to: Internet-Drafts@ietf.org
>Subject: I-D ACTION:draft-ietf-ldapext-locate-01.txt
>Date: Fri, 07 Jan 2000 06:39:40 -0500
>Sender: nsyracus@cnri.reston.va.us
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the LDAP Extension Working Group of the IETF.
>
>         Title           : Discovering LDAP Services with DNS
>         Author(s)       : M. Armijo, L. Esibov, P. Leach
>         Filename        : draft-ietf-ldapext-locate-01.txt
>         Pages           : 3
>         Date            : 06-Jan-00
>
>This draft defines a way that native Internet LDAP servers can make
>use of the DNS's knowledge base to provide clients a method to
>resolve LDAP services for a given domain.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-ldapext-locate-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-ldapext-locate-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-ldapext-locate-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.
>Content-Type: text/plain
>Content-ID:     <20000106145049.I-D@ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-ldapext-locate-01.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ldapext-locate-01.txt>



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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


From enum-admin@ietf.org  Mon Jan 17 08:23: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 IAA00874
	for <enum-archive@ietf.org>; Mon, 17 Jan 2000 08:23:54 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14104;
	Mon, 17 Jan 2000 08:21:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14073
	for <enum@optimus.ietf.org>; Mon, 17 Jan 2000 08:21:06 -0500 (EST)
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 IAA00852
	for <enum@ietf.org>; Mon, 17 Jan 2000 08:22:07 -0500 (EST)
Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0)
	id <C16YMWB5>; Mon, 17 Jan 2000 14:22:11 +0100
Message-ID: <98388C05D464D111B61800805F1504160123E47D@p-ibis.issy.cnet.fr>
From: BARNOLE Valerie CNET/DAC/ISS <valerie.barnole@cnet.francetelecom.fr>
To: "'Richard Shockey'" <rshockey@ix.netcom.com>,
        James Yu
	 <james.yu@neustar.com>
Cc: enum@ietf.org, jdrosen@dynamicsoft.com, paf@swip.net
Subject: RE: [Enum] DNS for E.164-IP Address Mapping
Date: Mon, 17 Jan 2000 14:22:10 +0100
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 IAA14074
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 read the Vaha-Sipila draft and I had trouble with understanding if it was
pertinent to have such distinct URLs due to the fact that a same E.164
number can correspond to a fax or to a phone. In that case, would the number
be part of two URL schemes, .tel and .fax ?
I thought it would have been more convenient to stick to one URL like P.
Faltstrom's .e164.int in his "E.164 number and DNS draft" and different
protocols. But maybe I totally misunderstood each draft ? And .e164.int is
not a URL scheme as .tel, .fax and .modem are ?
Thanks for giving me some lightson this issue.

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

Valérie Barnole
FT.BD/CNET/DAC/ARS
tel. : + 33 1 45 29 58 39
fax : + 33 1 46 29 31 42

valerie.barnole@cnet.francetelecom.fr



-----Message d'origine-----
De: Richard Shockey [mailto:rshockey@ix.netcom.com]
Date: vendredi 7 janvier 2000 20:34
Ā: James Yu
Cc: enum@ietf.org; jdrosen@dynamicsoft.com; paf@swip.net
Objet: Re: [Enum] DNS for E.164-IP Address Mapping


At 01:45 PM 1/7/2000 -0500, Jonathan Rosenberg wrote:
>I used the work "mechanism" when URI scheme is the correct term. Check
>rfc2396 for a general discussion. There are many URI schemes defined;
>I'm not sure if there is an IANA procedure somewhere defined for
>registering them.
>
>-Jonathan R.


Well for telephony applications there is a draft outlining how the URL's 
should be defined. I'm sure if there were other types of applications that 
need to be referenced in NAPTR records... Universal Messaging Servers, 
T.38, it should be no trouble defining a simple registration procedure.

Jonathan.... one of the things I'm increasingly concerned about is DNS 
security here. Do you have any thoughts on how much of DNSSEC we might have 
to require?


Title           : URLs for Telephone Calls
         Author(s)       : A. Vaha-Sipila
         Filename        : draft-antti-telephony-url-12.txt
         Pages           : 22
         Date            : 29-Dec-99

This document specifies URL (Uniform Resource Locator) schemes
'tel', 'fax' and 'modem' for specifying the location of a
terminal in the phone network and the connection types (modes of
operation) that can be used to connect to that entity. This
specification covers voice calls (normal phone calls, answering
machines and voice messaging systems), facsimile (telefax) calls and
data calls, both for POTS and digital/mobile subscribers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-antti-telephony-url-12.txt



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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

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


From enum-admin@ietf.org  Mon Jan 17 13:51: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 NAA05609
	for <enum-archive@ietf.org>; Mon, 17 Jan 2000 13:51:03 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24953;
	Mon, 17 Jan 2000 13:46:24 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24925
	for <enum@optimus.ietf.org>; Mon, 17 Jan 2000 13:46:22 -0500 (EST)
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05455
	for <enum@ietf.org>; Mon, 17 Jan 2000 13:47:30 -0500 (EST)
Received: from laptop (stl-mo14-48.ix.netcom.com [207.222.133.48])
	by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id NAA07270;
	Mon, 17 Jan 2000 13:47:15 -0500 (EST)
Message-Id: <4.2.0.58.20000117123609.00a28510@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 17 Jan 2000 12:46:41 -0600
To: BARNOLE Valerie CNET/DAC/ISS <valerie.barnole@cnet.francetelecom.fr>,
        James Yu <james.yu@neustar.com>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: RE: [Enum] DNS for E.164-IP Address Mapping
Cc: enum@ietf.org, jdrosen@dynamicsoft.com, paf@swip.net
In-Reply-To: <98388C05D464D111B61800805F1504160123E47D@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 02:22 PM 1/17/2000 +0100, BARNOLE Valerie CNET/DAC/ISS wrote:
>I read the Vaha-Sipila draft and I had trouble with understanding if it was
>pertinent to have such distinct URLs due to the fact that a same E.164
>number can correspond to a fax or to a phone. In that case, would the number
>be part of two URL schemes, .tel and .fax ?
>I thought it would have been more convenient to stick to one URL like P.
>Faltstrom's .e164.int in his "E.164 number and DNS draft" and different
>protocols. But maybe I totally misunderstood each draft ? And .e164.int is
>not a URL scheme as .tel, .fax and .modem are ?
>Thanks for giving me some lightson this issue.


Well the VahaSipila draft came out of different requirements than that of 
ENUM specifically. It is useful to distinguish the form of communication in 
the URL for applications such as VPIM [Voice Profile for Internet Mail].

How this might work in ENUM is clearly subject to further debate.

In the FAX application it may be necessary to distinguish the preferred 
protocol and destination based on subscriber requirements. The concept of 
"fax" is no longer one protocol. It could be GSTN/T.30, SMTP, ITU/T.38, IPP 
or SIP. If so the URL scheme for each protocol used might be different. If 
the preferred form of connection is purely SIP this will be easier since 
there is already discussion of Caller Preference models in SIP where such 
data will be stored.



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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


From enum-admin@ietf.org  Tue Jan 18 04:58: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 EAA27335
	for <enum-archive@ietf.org>; Tue, 18 Jan 2000 04:58:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24812;
	Tue, 18 Jan 2000 04:55:57 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24781
	for <enum@optimus.ietf.org>; Tue, 18 Jan 2000 04:55:55 -0500 (EST)
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 EAA27321
	for <enum@ietf.org>; Tue, 18 Jan 2000 04:57:02 -0500 (EST)
Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0)
	id <C16YM9Q2>; Tue, 18 Jan 2000 10:58:12 +0100
Message-ID: <98388C05D464D111B61800805F1504160123E487@p-ibis.issy.cnet.fr>
From: BARNOLE Valerie CNET/DAC/ISS <valerie.barnole@cnet.francetelecom.fr>
To: "'Richard Shockey'" <rshockey@ix.netcom.com>
Cc: enum@ietf.org, "'paf@swip.net'" <paf@swip.net>,
        "'James Yu'"
	 <james.yu@neustar.com>
Subject: RE: [Enum] DNS for E.164-IP Address Mapping
Date: Tue, 18 Jan 2000 10:58:11 +0100
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 EAA24782
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

So, in the FAX application you quote, wouldn't it be just enough to have in
NAPTR records (see Patrick's draft §3.1), with different priorities, the
service fields "GSTN/T.30+FAX" and "SMTP+FAX" and "ITU/T.38+FAX" ?

For instance, if the fax number is + 33 1 46 29 31 42 :

2.8.0.4.6.2.6.5.8.6.4.e164.int
IN NAPTR 10  10 s "SIP+FAX" "sip:paf@swip.net"
IN NAPTR 10 100 s "SMTP+FAX" "smtp._tcp.tele2.se"
IN NAPTR 10 102 s "ITU/T.38+FAX" "t38._tcp.tele2.se"
IN NAPTR 10 104 s "GSTN/T.30+FAX" "t30._tcp.tele2.se"
IN NAPTR 10 106 s "IPP+FAX" "ipp._tcp.tele2.se"
(I apologize, I may have written quite stupid replacement fields for the 3
last items). 

Excuse me for sticking to this question. To me, it looks a little strange to
categorize E.164 numbers (names) according to the technology (pots, isdn,
fax, maybe GSM or PCS, which does not appear in Vaha-Sipila draft but might,
why not). I tend to consider URLs as names compared to IP addresses, so I
tend to disconnect them from any technology. But maybe I am  wrong in
considering URLs as names ?



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

Valérie Barnole
FT.BD/CNET/DAC/ARS
tel. : + 33 1 45 29 58 39
fax : + 33 1 46 29 31 42

valerie.barnole@cnet.francetelecom.fr



-----Message d'origine-----
De: Richard Shockey [mailto:rshockey@ix.netcom.com]
Date: lundi 17 janvier 2000 19:47
Ā: BARNOLE Valerie CNET/DAC/ISS; James Yu
Cc: enum@ietf.org; jdrosen@dynamicsoft.com; paf@swip.net
Objet: RE: [Enum] DNS for E.164-IP Address Mapping


At 02:22 PM 1/17/2000 +0100, BARNOLE Valerie CNET/DAC/ISS wrote:
>I read the Vaha-Sipila draft and I had trouble with understanding if it was
>pertinent to have such distinct URLs due to the fact that a same E.164
>number can correspond to a fax or to a phone. In that case, would the
number
>be part of two URL schemes, .tel and .fax ?
>I thought it would have been more convenient to stick to one URL like P.
>Faltstrom's .e164.int in his "E.164 number and DNS draft" and different
>protocols. But maybe I totally misunderstood each draft ? And .e164.int is
>not a URL scheme as .tel, .fax and .modem are ?
>Thanks for giving me some lightson this issue.


Well the VahaSipila draft came out of different requirements than that of 
ENUM specifically. It is useful to distinguish the form of communication in 
the URL for applications such as VPIM [Voice Profile for Internet Mail].

How this might work in ENUM is clearly subject to further debate.

In the FAX application it may be necessary to distinguish the preferred 
protocol and destination based on subscriber requirements. The concept of 
"fax" is no longer one protocol. It could be GSTN/T.30, SMTP, ITU/T.38, IPP 
or SIP. If so the URL scheme for each protocol used might be different. If 
the preferred form of connection is purely SIP this will be easier since 
there is already discussion of Caller Preference models in SIP where such 
data will be stored.



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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


From enum-admin@ietf.org  Tue Jan 18 11:07: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 LAA01690
	for <enum-archive@ietf.org>; Tue, 18 Jan 2000 11:07:38 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03736;
	Tue, 18 Jan 2000 11:05:36 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03708
	for <enum@optimus.ietf.org>; Tue, 18 Jan 2000 11:05:35 -0500 (EST)
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 LAA01680
	for <enum@ietf.org>; Tue, 18 Jan 2000 11:06:41 -0500 (EST)
Received: from laptop (stl-mo15-37.ix.netcom.com [207.222.133.165])
	by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA26863;
	Tue, 18 Jan 2000 11:06:33 -0500 (EST)
Message-Id: <4.2.0.58.20000118095440.00b27a40@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 18 Jan 2000 10:05:56 -0600
To: BARNOLE Valerie CNET/DAC/ISS <valerie.barnole@cnet.francetelecom.fr>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: RE: [Enum] DNS for E.164-IP Address Mapping
Cc: enum@ietf.org, "'paf@swip.net'" <paf@swip.net>,
        "'James Yu'" <james.yu@neustar.com>
In-Reply-To: <98388C05D464D111B61800805F1504160123E487@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 LAA03709
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 10:58 AM 1/18/2000 +0100, BARNOLE Valerie CNET/DAC/ISS wrote:
>So, in the FAX application you quote, wouldn't it be just enough to have in
>NAPTR records (see Patrick's draft §3.1), with different priorities, the
>service fields "GSTN/T.30+FAX" and "SMTP+FAX" and "ITU/T.38+FAX" ?
>
>For instance, if the fax number is + 33 1 46 29 31 42 :
>
>2.8.0.4.6.2.6.5.8.6.4.e164.int
>IN NAPTR 10  10 s "SIP+FAX" "sip:paf@swip.net"
>IN NAPTR 10 100 s "SMTP+FAX" "smtp._tcp.tele2.se"
>IN NAPTR 10 102 s "ITU/T.38+FAX" "t38._tcp.tele2.se"
>IN NAPTR 10 104 s "GSTN/T.30+FAX" "t30._tcp.tele2.se"
>IN NAPTR 10 106 s "IPP+FAX" "ipp._tcp.tele2.se"
>(I apologize, I may have written quite stupid replacement fields for the 3
>last items).

Yes you are quite correct the above scenario would be apprporiate for a 
future kind of multi-modal "fax machine"


>Excuse me for sticking to this question. To me, it looks a little strange to
>categorize E.164 numbers (names) according to the technology (pots, isdn,
>fax, maybe GSM or PCS, which does not appear in Vaha-Sipila draft but might,
>why not). I tend to consider URLs as names compared to IP addresses, so I
>tend to disconnect them from any technology. But maybe I am  wrong in
>considering URLs as names ?

I look at a URL as a name of a resource. Within that name are the 
assumptions of what protocols are to be used to access.  If the "fax" 
resource preference was IPP for instance and the NAPTR record contained the 
entry "ipp.foo.com/richard_shockey" the rewrite would under IPP 
rules  ipp://ipp.foo.com/richard_shockey. It is then assumed that the ENUM 
client resolver knows what IPP is (HTTP) or the client must either send the 
"fax" over the GSTN.

Maybe I'm not making myself too clear either....


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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


From enum-admin@ietf.org  Tue Jan 18 22:04: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 WAA09818
	for <enum-archive@ietf.org>; Tue, 18 Jan 2000 22:04:48 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23798;
	Tue, 18 Jan 2000 22:01:51 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23762
	for <enum@optimus.ietf.org>; Tue, 18 Jan 2000 22:01:49 -0500 (EST)
Received: from nix.swip.net (nix.swip.net [192.71.220.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09815
	for <enum@ietf.org>; Tue, 18 Jan 2000 22:02:57 -0500 (EST)
Received: from 192.168.111.25 (workstation1.swip.net [130.244.254.1]) 
          by nix.swip.net (8.8.8/8.8.8) with ESMTP 
          id EAA24043; 
          Wed, 19 Jan 2000 04:00:47 +0100 (MET)
Date: Wed, 19 Jan 2000 04:00:43 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@swip.net>
To: Richard Shockey <rshockey@ix.netcom.com>,
        "BARNOLE Valerie CNET/DAC/ISS" <valerie.barnole@cnet.francetelecom.fr>
cc: enum@ietf.org, "'James Yu'" <james.yu@neustar.com>
Subject: RE: [Enum] DNS for E.164-IP Address Mapping
Message-ID: <971949.3157243243@[192.168.111.25]>
In-Reply-To: <4.2.0.58.20000118095440.00b27a40@127.0.0.1>
X-Mailer: Mulberry (MacOS) [2.0.0b7, s/n U-301169]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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

--On 2000-01-18 10.05 -0600, Richard Shockey <rshockey@ix.netcom.com> wrote:

> If the "fax" resource preference was IPP for instance and the NAPTR
> record contained the entry "ipp.foo.com/richard_shockey" the rewrite
> would under IPP rules  ipp://ipp.foo.com/richard_shockey. It is then
> assumed that the ENUM client resolver knows what IPP is (HTTP) or the
> client must either send the "fax" over the GSTN.

The ideas with a scheme name in the URI is that the client can make a
descision whether he "knows what to do with the scheme-specific data or
not". The scheme therefore distinguishes between services, methods to use,
what the data after "//" is, etc. Or combination thereof.

I personally rather see different schemes for different services, than
overloading existing ones, but I guess that is an extremely foggy answer to
what you talk about...

I guess a better answer is that yes, you do not have to have different
schemes if the algorithms via NAPTR/SRV in my draft are in use, as that by
itself tells what services exists, but it is also the case that it doesn't
hurt having different schemes either, or does it? I.e. I would not like to
have different schemes for "voice telephony" depending on what transmission
mechanism is in use (IP telephony, plain telephony etc). I would at the
same time not want to have different schemes depending on whether the fax
is in color or black&white.

   paf




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


From enum-admin@ietf.org  Wed Jan 19 04:35: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 EAA25075
	for <enum-archive@ietf.org>; Wed, 19 Jan 2000 04:35:31 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14037;
	Wed, 19 Jan 2000 04:33:29 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14006
	for <enum@optimus.ietf.org>; Wed, 19 Jan 2000 04:33:28 -0500 (EST)
Received: from malmo.trab.se (malmo.trab.se [131.115.48.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25069
	for <enum@ietf.org>; Wed, 19 Jan 2000 04:34:37 -0500 (EST)
Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.9.1/TRAB-primary-2) with ESMTP id KAA22362; Wed, 19 Jan 2000 10:34:33 +0100 (MET)
Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0)
	id <C29KJ2NT>; Wed, 19 Jan 2000 10:34:32 +0100
Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D01DE498F@trab-hermes.haninge.trab.se>
From: =?ISO-8859-1?Q?S=F6ren_Nyckelg=E5rd?= <Soren.M.Nyckelgard@telia.se>
To: enum@ietf.org
Cc: =?ISO-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <paf@swip.net>
Date: Wed, 19 Jan 2000 10:34:32 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [Enum] New DNS record class values?
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's draft <draft-faltstrom-e164> suggests a SRV record format for the
"potscall" service where the SRV target host name is the reversed telephone
number. A problem with this solution is that RFC2052 (and
draft-ietf-dnsind-rfc2052bis-04) states that the target host name in a SRV
record MUST have an address record (an A record) and RFC1034 shows that an A
record can only refer to a 32-bit IP address, which is not very useful for a
"potscall" service. I can think of at least two solutions to this problem.

The first solution (1) would be not to use SRV records for non-internet
services, like the the "potscall" service. I believe that it's sufficient if
the NAPTR record indicates that the queried domain (QNAME) supports
"potscall" and that it provides an appropriate rewrite address. I'll soon
get back to this.

The second solution (2) would be to use SRV records as suggested in Patrik's
draft, but make the record indicate, in some way, that there is no A record
for the target host name.

Back again to the first solution (1) and let's use a NAPTR line from
Patrik's draft for an example:

  IN NAPTR 102 10 s potscall+N2R "" _potscall._tcp.paf.swip.net.   

I believe this NAPTR line ought to look something like this if we want to
omit the SRV record:

  IN NAPTR 102 10 p potscall+N2R ""
_potscall._tcp.2.8.0.4.6.2.6.5.8.6.4.e164.int.

I'm not quite happy with the format above since "potscall" is not an
internet service, although the CLASS parameter (class=IN) says so. Further
more, the protocol that the "potscall" service uses is a SCN-protocol like
ISUP, not TCP. 

RFC1034 defines some classes other than IN, but I guess the network types
they refer to don't exist anymore. Since we now try to make the DNS handle
non-internet addresses and targets, it might be adequate to define some new
classes. What about "SC" for Switched Circuit networks, "FR" for Frame Relay
networks and "AT" for ATM networks? Then we wouldn't be forced to put
irrelevant information in the record just to make it look "internetish".
Instead the NAPTR record could provide information that is adequate for a
non-internet target. The NAPTR line above could then look something like
this instead:

  SC NAPTR 102 10 p potscall+N2R "" _potscall._inap.46856264028.

or maybe like this (which I personally prefer):

  SC NAPTR 102 10 u potscall+N2R "" 46856264028.

Note the use of flags "p" and "u" instead of "s" in the NAPTR lines above.
This should be appropriate unless I've misunderstood RFC2219.

The ENUM requirement draft says that "The system MUST support existing local
number portability mechanisms" and should not "impede future global number
portability" So, does the solution above support number portability?

Well, the NAPTR record can rewrite a dialed number and, for instance, add a
routing prefix. However, global routing prefixes are seldom appreciated by
SCN operators since they often interfear with local number plans and local
routing prefix schemes. It's probably better to specify the terminating SCN
operator explicitly and let the operator map it to locally significant
routing information. The NAPTR record might then look something like this:

  SC NAPTR 102 10 u potscall+N2R "" 4685626400@tele2.se.

Personally, I'd prefer a solution like the one above, but let's anyway go
back to the initial SRV record problem and the second solution (2) that I
mentioned. Solution (2) suggests that we use the SRV record, as Patrik's
draft says, but we indicate to the client and the DNS mechanism that there
is no A record to search for. 

Setting CLASS=SC in the SRV record would be a good indicator that there is
no A record available since SC class targets don't use A records. To show
what I mean, I first pick a SRV line from Patrik's draft: 

  _potscall._tcp.tele2.se.  IN SRV 1 1 0 0.0.0.4.6.2.6.5.8.6.4.e164.int.

Using CLASS=SC enables us to provide information that is more adequate for a
non-internet target. The SRV record could look like this: 

  _potscall._inap.tele2.se.  SC SRV 1 1 0 4685626400@tele2.se.

The SRV record format includes by definition a "port" number. It has here
been set to "0" since "port" makes no sence for a SCN target. Further more,
the target name above is not the "domain name of the target host" as RFC2052
(and draft-ietf-dnsind-rfc2052bis-04) specifies, rather a kind of URL. 

As a final comment, please note that RFC1034 states that QCLASS can be set
to "*" (class value 255) in a DNS query, thus making the DNS return both IN
records and SC records. This, of cause, includes both NAPTR and SRV records.



I'm looking forward to see your comments on these suggestions. 

--
Sören Nyckelgård, Telia Research 

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


From enum-admin@ietf.org  Wed Jan 19 10:15: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 KAA00487
	for <enum-archive@ietf.org>; Wed, 19 Jan 2000 10:15:24 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20449;
	Wed, 19 Jan 2000 10:09:49 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20417
	for <enum@optimus.ietf.org>; Wed, 19 Jan 2000 10:09:47 -0500 (EST)
Received: from monsoon.mail.pipex.net (monsoon.mail.pipex.net [158.43.128.69])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00425
	for <enum@ietf.org>; Wed, 19 Jan 2000 10:10:55 -0500 (EST)
Received: (qmail 2367 invoked from network); 19 Jan 2000 15:10:39 -0000
Received: from userm186.uk.uudial.com (HELO gk-vaio) (193.149.77.236)
  by smtp.dial.pipex.com with SMTP; 19 Jan 2000 15:10:39 -0000
Message-Id: <4.2.2.20000119121820.00b16280@pop.dial.pipex.com>
X-Sender: maiw03@pop.dial.pipex.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 19 Jan 2000 12:29:18 +0000
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@swip.net>
From: Graham Klyne <GK@Dial.pipex.com>
Subject: RE: [Enum] DNS for E.164-IP Address Mapping
Cc: enum@ietf.org
In-Reply-To: <971949.3157243243@[192.168.111.25]>
References: <4.2.0.58.20000118095440.00b27a40@127.0.0.1>
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 KAA20418
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:00 AM 1/19/00 +0100, Patrik Fältström wrote:
>The ideas with a scheme name in the URI is that the client can make a
>descision whether he "knows what to do with the scheme-specific data or
>not". The scheme therefore distinguishes between services, methods to use,
>what the data after "//" is, etc. Or combination thereof.
>
>I personally rather see different schemes for different services, than
>overloading existing ones,

<cheer>

>I guess a better answer is that yes, you do not have to have different
>schemes if the algorithms via NAPTR/SRV in my draft are in use, as that by
>itself tells what services exists, but it is also the case that it doesn't
>hurt having different schemes either, or does it? I.e. I would not like to
>have different schemes for "voice telephony" depending on what transmission
>mechanism is in use (IP telephony, plain telephony etc). I would at the
>same time not want to have different schemes depending on whether the fax
>is in color or black&white.

Did you really NOT want different schemes for different "voice telephony" 
transmission mechanisms?  (That looks like a typo to me :-)

I would suggest that different schemes ARE appropriate for different 
transfer mechanisms, but are NOT appropriate for distinguishing content types.

I think the case of telephony vs fax (via POTS) is interesting, because it 
could be viewed either way:  both use a standard telephone circuit.  BUT, I 
would suggest that fax is different than voice, because it uses additional 
layers of transfer protocol (T30, etc.) on top of the underlying circuit.

Also, there is a different interaction style involved:  voice transfers an 
isochronous real-time information stream;  fax transfers a message (by 
which I mean a data object whose information content is fully determined 
prior to transmission start -- you don't get to change your mind about what 
you are saying as a result of information coming back in the same 
communication session).

Another example:  I think the SAME scheme would be appropriate for fax and 
vice-messages transferred via e-mail protocols.

Just some thoughts.

#g

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


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


From enum-admin@ietf.org  Wed Jan 19 11:26: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 LAA01454
	for <enum-archive@ietf.org>; Wed, 19 Jan 2000 11:26:17 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22521;
	Wed, 19 Jan 2000 11:23:20 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22482
	for <enum@optimus.ietf.org>; Wed, 19 Jan 2000 11:23:13 -0500 (EST)
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 LAA01425
	for <enum@ietf.org>; Wed, 19 Jan 2000 11:24:21 -0500 (EST)
Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0)
	id <D2F4MSHS>; Wed, 19 Jan 2000 17:24:57 +0100
Message-ID: <98388C05D464D111B61800805F1504160123E4A0@p-ibis.issy.cnet.fr>
From: BARNOLE Valerie CNET/DAC/ISS <valerie.barnole@cnet.francetelecom.fr>
To: "'Richard Shockey'" <rshockey@ix.netcom.com>,
        "'paf@swip.net'"
	 <paf@swip.net>,
        "'GK@dial.pipex.com'" <GK@dial.pipex.com>
Cc: enum@ietf.org
Subject: RE: [Enum] DNS for E.164-IP Address Mapping
Date: Wed, 19 Jan 2000 17:24:56 +0100
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 LAA22489
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

Hope I won't get too lost among the schemes !

If I try to have a clear idea, in the E.164 numbers mapping to URLs
according to Patrick's draft, I see two types of URLs:
Type 1- the first one is the .e164.int URL type, which provides the
infrastructure to store E.164 numbers and looks more like a name, because it
infers nothing on the technology or the service (phone, pots or isdn or
VoIP, fax, modem...).
I confess that even if I do not want to exclude other schemes here, this
e164.int URL scheme looks good to me because of this "name" look. If an
e.164 number becomes portable from pots to another service, this part of the
infrastructure of the mapping will not have to be changed.
Type 2- the second one is the "protocol" type in the rewrite rule field,
with as much schemes as there are different protocols, which indicates which
protocol to use to access the terminal(s). this protocol indication (IIP or
other)is necessary. 

When Patrick and Graham talk about appropriateness or not of different
schemes, is it about type 1 or type 2 ?

By the way, it seems that there are already a few proposed URL schemes, like
the Vaha-Sipila's, the Kurrasch's and probably others. 


Thanks for clarification.

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

Valérie Barnole
FT.BD/CNET/DAC/ARS
tel. : + 33 1 45 29 58 39
fax : + 33 1 46 29 31 42

valerie.barnole@cnet.francetelecom.fr



-----Message d'origine-----
De: Richard Shockey [mailto:rshockey@ix.netcom.com]
Date: mardi 18 janvier 2000 17:06
Ā: BARNOLE Valerie CNET/DAC/ISS
Cc: enum@ietf.org; 'paf@swip.net'; 'James Yu'
Objet: RE: [Enum] DNS for E.164-IP Address Mapping


At 10:58 AM 1/18/2000 +0100, BARNOLE Valerie CNET/DAC/ISS wrote:
>So, in the FAX application you quote, wouldn't it be just enough to have in
>NAPTR records (see Patrick's draft §3.1), with different priorities, the
>service fields "GSTN/T.30+FAX" and "SMTP+FAX" and "ITU/T.38+FAX" ?
>
>For instance, if the fax number is + 33 1 46 29 31 42 :
>
>2.8.0.4.6.2.6.5.8.6.4.e164.int
>IN NAPTR 10  10 s "SIP+FAX" "sip:paf@swip.net"
>IN NAPTR 10 100 s "SMTP+FAX" "smtp._tcp.tele2.se"
>IN NAPTR 10 102 s "ITU/T.38+FAX" "t38._tcp.tele2.se"
>IN NAPTR 10 104 s "GSTN/T.30+FAX" "t30._tcp.tele2.se"
>IN NAPTR 10 106 s "IPP+FAX" "ipp._tcp.tele2.se"
>(I apologize, I may have written quite stupid replacement fields for the 3
>last items).

Yes you are quite correct the above scenario would be apprporiate for a 
future kind of multi-modal "fax machine"


>Excuse me for sticking to this question. To me, it looks a little strange
to
>categorize E.164 numbers (names) according to the technology (pots, isdn,
>fax, maybe GSM or PCS, which does not appear in Vaha-Sipila draft but
might,
>why not). I tend to consider URLs as names compared to IP addresses, so I
>tend to disconnect them from any technology. But maybe I am  wrong in
>considering URLs as names ?

I look at a URL as a name of a resource. Within that name are the 
assumptions of what protocols are to be used to access.  If the "fax" 
resource preference was IPP for instance and the NAPTR record contained the 
entry "ipp.foo.com/richard_shockey" the rewrite would under IPP 
rules  ipp://ipp.foo.com/richard_shockey. It is then assumed that the ENUM 
client resolver knows what IPP is (HTTP) or the client must either send the 
"fax" over the GSTN.

Maybe I'm not making myself too clear either....


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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


From enum-admin@ietf.org  Wed Jan 19 11:34: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 LAA01634
	for <enum-archive@ietf.org>; Wed, 19 Jan 2000 11:34:32 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22883;
	Wed, 19 Jan 2000 11:32:15 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22852
	for <enum@optimus.ietf.org>; Wed, 19 Jan 2000 11:32:13 -0500 (EST)
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 LAA01617
	for <enum@ietf.org>; Wed, 19 Jan 2000 11:33:23 -0500 (EST)
Received: from laptop (stl-mo15-38.ix.netcom.com [207.222.133.166])
	by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA30783;
	Wed, 19 Jan 2000 11:33:18 -0500 (EST)
Message-Id: <4.2.0.58.20000119101531.00a32ca0@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 19 Jan 2000 10:32:41 -0600
To: =?iso-8859-1?Q?S=F6ren?= =?iso-8859-1?Q?_Nyckelg=E5rd?=
  <Soren.M.Nyckelgard@telia.se>,
        enum@ietf.org
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: Re: [Enum] New DNS record class values?
Cc: "'Patrik =?iso-8859-1?Q?F=E4ltstr=F6m=27?=" <paf@swip.net>
In-Reply-To: <778DFE9B4E3BD111A74E08002BA3DC0D01DE498F@trab-hermes.hanin
 ge.trab.se>
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


>
>
>Back again to the first solution (1) and let's use a NAPTR line from
>Patrik's draft for an example:
>
>   IN NAPTR 102 10 s potscall+N2R "" _potscall._tcp.paf.swip.net.
>
>I believe this NAPTR line ought to look something like this if we want to
>omit the SRV record:
>
>   IN NAPTR 102 10 p potscall+N2R ""
>_potscall._tcp.2.8.0.4.6.2.6.5.8.6.4.e164.int.
>
>I'm not quite happy with the format above since "potscall" is not an
>internet service, although the CLASS parameter (class=IN) says so. Further
>more, the protocol that the "potscall" service uses is a SCN-protocol like
>ISUP, not TCP.


I must agree with your basic premise. I've never been too happy with the 
place holder syntax myself. Your suggestions are most welcome.



>The ENUM requirement draft says that "The system MUST support existing local
>number portability mechanisms" and should not "impede future global number
>portability" So, does the solution above support number portability?
>
>Well, the NAPTR record can rewrite a dialed number and, for instance, add a
>routing prefix. However, global routing prefixes are seldom appreciated by
>SCN operators since they often interfear with local number plans and local
>routing prefix schemes. It's probably better to specify the terminating SCN
>operator explicitly and let the operator map it to locally significant
>routing information. The NAPTR record might then look something like this:
>
>   SC NAPTR 102 10 u potscall+N2R "" 4685626400@tele2.se.

Now this is also very interesting. In private conversations I've heard talk 
about the possibility of the DNS record actually carrying the LRN [ 
Location Routing Number ] for the terminating switch or somehow creating a 
pointer to a database [LDAP?] for retrieving that data.

In your opinion what might be the best approach to this?




 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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


From enum-admin@ietf.org  Wed Jan 19 20:53: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 UAA07295
	for <enum-archive@ietf.org>; Wed, 19 Jan 2000 20:53:02 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05939;
	Wed, 19 Jan 2000 20:50:11 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05910
	for <enum@optimus.ietf.org>; Wed, 19 Jan 2000 20:50:08 -0500 (EST)
Received: from malmo.trab.se (malmo.trab.se [131.115.48.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07292
	for <enum@ietf.org>; Wed, 19 Jan 2000 20:51:17 -0500 (EST)
Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.9.1/TRAB-primary-2) with ESMTP id CAA17160; Thu, 20 Jan 2000 02:51:13 +0100 (MET)
Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0)
	id <C29KJKM7>; Thu, 20 Jan 2000 02:51:12 +0100
Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D01DE4994@trab-hermes.haninge.trab.se>
From: =?ISO-8859-1?Q?S=F6ren_Nyckelg=E5rd?= <Soren.M.Nyckelgard@telia.se>
To: "'Richard Shockey'" <rshockey@ix.netcom.com>, enum@ietf.org
Cc: =?ISO-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <paf@swip.net>
Subject: RE: [Enum] New DNS record class values?
Date: Thu, 20 Jan 2000 02:51:08 +0100
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 UAA05911
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



> >The ENUM requirement draft says that "The system MUST 
> support existing local
> >number portability mechanisms" and should not "impede future 
> global number
> >portability" So, does the solution above support number portability?
> >
> >Well, the NAPTR record can rewrite a dialed number and, for 
> instance, add a
> >routing prefix. However, global routing prefixes are seldom 
> appreciated by
> >SCN operators since they often interfear with local number 
> plans and local
> >routing prefix schemes. It's probably better to specify the 
> terminating SCN
> >operator explicitly and let the operator map it to locally 
> significant
> >routing information. The NAPTR record might then look 
> something like this:
> >
> >   SC NAPTR 102 10 u potscall+N2R "" 4685626400@tele2.se.
> 
> Now this is also very interesting. In private conversations 
> I've heard talk 
> about the possibility of the DNS record actually carrying the LRN [ 
> Location Routing Number ] for the terminating switch or 
> somehow creating a 
> pointer to a database [LDAP?] for retrieving that data.
> 
> In your opinion what might be the best approach to this?


I don't think one approach excludes the other. It's rather a matter 
of optimization: 

a) We might impose too much delay in the call setup process if we 
first use the DNS to locate an LDAP server, which we then query for 
the termination point information (LRN in America). Users seem to 
accept more or less delay depending on which kind of network they are 
connected to. GSM and IP-telephony users are fairly tolerant whereas 
PSTN and ISDN users are not.

b) If an E.164 number identifies a terminal such as a phone or a fax, 
then the termination point information is fairly static and could be 
carried by the DNS record (record format TBD). If instead the E.164 
number identifies a user that might move between different terminals, 
then the DNS record preferably should point to an address data 
repository that can be dynamically updated. 

My oppinion is hence that the DNS should support both alternatives. 
The usage of the number determines if the DNS record shall carry the 
termination point information itself or reference a service like LDAP.

I noted that you put a question mark after LDAP in your question above. 
A press release from last year signed Telia and Nortel mentions both
"Number Portability" and "SIP". I can't yet reveal any details but
you are of cause free to use your imagination :-) 

---

Sören Nyckelgård, Telia Research
 

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


From enum-admin@ietf.org  Wed Jan 19 23:30: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 XAA10185
	for <enum-archive@ietf.org>; Wed, 19 Jan 2000 23:30:14 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09199;
	Wed, 19 Jan 2000 23:28:04 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09165
	for <enum@optimus.ietf.org>; Wed, 19 Jan 2000 23:27:59 -0500 (EST)
Received: from mail.bit-net.com (mail.bit-net.com [208.146.132.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10136
	for <enum@ietf.org>; Wed, 19 Jan 2000 23:29:08 -0500 (EST)
Received: from seagal (www.evds.com [208.146.135.202])
	by mail.bit-net.com (8.9.3/8.9.2) with SMTP id XAA92807;
	Wed, 19 Jan 2000 23:29:07 -0500 (EST)
	(envelope-from peek@bit-net.com)
Message-ID: <00b101bf62fe$c69daa60$020aa8c0@seagal.voicedomain>
From: "David P. Peek" <peek@bit-net.com>
To: "Richard Shockey" <rshockey@ix.netcom.com>, <enum@ietf.org>,
        "=?iso-8859-1?B?U/ZyZW4gIE55Y2tlbGflcmQ=?=" <Soren.M.Nyckelgard@telia.se>
Cc: "=?iso-8859-1?B?J1BhdHJpayBG5Gx0c3Ry9m0n?=" <paf@swip.net>
Subject: Re: [Enum] New DNS record class values?
Date: Wed, 19 Jan 2000 23:28:16 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
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

I'd like to comment on this issue now that a pointer to LDAP has been
brought up. (For those that dont know me I've been working with the
VMA (Voice Messaging Assoication) as the technical working group chairman.
We have been sponsoring VPIM voice messaging demonstrations with eight major
VMS vendors worldwide including a global directory service...the last
demonstration was
at Telecom 99 in Geneva. )  I feel we have learned a lot about
communications and messaging
over the last 18 months and I'd like to share a few key issues.

Services such as voice messaging (VPIM) and enhanced messaging systems
(unified messaging) will require additional information that can't be
supplied by a DNS server alone.  (e.g. Spoken-Name, preferred codecs,
individual preferences, vCards, LATA values, etc.)   For IP-PBX IP-Telephony
servers
and gateways they may not always be static depending upon service level
agreements
and individual gateway capabilities.  Service operators and network
operators are faced
with delivering large/global services where the users expectations are based
on high featured
local communications environments.   Our solutions must enabled the support
of these
features that require more knowledge then is available at the DNS level
alone.
With the use of LDAP external systems can query these attributes and
capabilities or even
retrieve rerouting information to support dynamic environments.

We have also found that service providers demand more control over access to
their data. Service providers and network operators want to control who has
access to entries down to the attribute level and service level.  This is
difficult to do with DNS alone.  Security of information such as what is
public and what is private can be eloquently supported using LDAP servers
with access control information.


A solution today that is gaining acceptance from large service providers and
messaging vendors is a two tiered model that uses both DNS and LDAP.   DNS
is being used as a Directory Locator Service (DLS) which really what this
group has brought up.  This DLS points to an Authoritative Directory Server
(ADS) containing specific information based on an E.164 number that is
controlled by large service providers and network operators. These ADS(s)
contain information needed for multiple services that need to be integrated
into communications and messaging platforms.  Integration is being driven by
service providers that need to deliver expanding services.  Performance is
also a concern with all proposed solutions and any ADS is expected to be
fast, highly available, fault tolerate, and redundant in order to provide an
expected quality of service.

The specific implementation is being debated and this ENUM work group can
clearly add value to
this for the DLS.

I look forward to hearing your comments about this two-tier approach that
combines DNS and LDAP.

>
>>
>>
>>Back again to the first solution (1) and let's use a NAPTR line from
>>Patrik's draft for an example:
>>
>>   IN NAPTR 102 10 s potscall+N2R "" _potscall._tcp.paf.swip.net.
>>
>>I believe this NAPTR line ought to look something like this if we want to
>>omit the SRV record:
>>
>>   IN NAPTR 102 10 p potscall+N2R ""
>>_potscall._tcp.2.8.0.4.6.2.6.5.8.6.4.e164.int.
>>
>>I'm not quite happy with the format above since "potscall" is not an
>>internet service, although the CLASS parameter (class=IN) says so. Further
>>more, the protocol that the "potscall" service uses is a SCN-protocol like
>>ISUP, not TCP.
>
>
>I must agree with your basic premise. I've never been too happy with the
>place holder syntax myself. Your suggestions are most welcome.
>
>
>
>>The ENUM requirement draft says that "The system MUST support existing
local
>>number portability mechanisms" and should not "impede future global number
>>portability" So, does the solution above support number portability?
>>
>>Well, the NAPTR record can rewrite a dialed number and, for instance, add
a
>>routing prefix. However, global routing prefixes are seldom appreciated by
>>SCN operators since they often interfear with local number plans and local
>>routing prefix schemes. It's probably better to specify the terminating
SCN
>>operator explicitly and let the operator map it to locally significant
>>routing information. The NAPTR record might then look something like this:
>>
>>   SC NAPTR 102 10 u potscall+N2R "" 4685626400@tele2.se.
>
>Now this is also very interesting. In private conversations I've heard talk
>about the possibility of the DNS record actually carrying the LRN

>Location Routing Number ] for the terminating switch or somehow creating a
>pointer to a database [LDAP?] for retrieving that data.
>
>In your opinion what might be the best approach to this?
>
>
>
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>Richard Shockey
>Shockey Consulting LLC
>8045 Big Bend Blvd. Suite 110
>St. Louis, MO 63119
>Voice 314.918.9020
>eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
>INTERNET Mail & IFAX : rshockey@ix.netcom.com
>GSTN Fax 314.918.9015
>MediaGate iPost VoiceMail and Fax 800.260.4464
><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
>_______________________________________________
>enum mailing list
>enum@ietf.org
>http://www.ietf.org/mailman/listinfo/enum
>



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


From enum-admin@ietf.org  Thu Jan 20 00:54: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 AAA11194
	for <enum-archive@ietf.org>; Thu, 20 Jan 2000 00:54:23 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11299;
	Thu, 20 Jan 2000 00:49:59 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11272
	for <enum@optimus.ietf.org>; Thu, 20 Jan 2000 00:49:57 -0500 (EST)
Received: from nix.swip.net (nix.swip.net [192.71.220.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11179
	for <enum@ietf.org>; Thu, 20 Jan 2000 00:51:08 -0500 (EST)
Received: from 192.168.111.25 (workstation1.swip.net [130.244.254.1]) 
          by nix.swip.net (8.8.8/8.8.8) with ESMTP 
          id GAA06797; 
          Thu, 20 Jan 2000 06:48:54 +0100 (MET)
Date: Thu, 20 Jan 2000 06:48:50 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@swip.net>
To: "David P. Peek" <peek@bit-net.com>,
        Richard Shockey <rshockey@ix.netcom.com>, enum@ietf.org,
        =?ISO-8859-1?Q?S=F6ren__Nyckelg=E5rd?= <Soren.M.Nyckelgard@telia.se>
Subject: Re: [Enum] New DNS record class values?
Message-ID: <3405093.3157339730@[192.168.111.25]>
In-Reply-To: <00b101bf62fe$c69daa60$020aa8c0@seagal.voicedomain>
X-Mailer: Mulberry (MacOS) [2.0.0b7, s/n U-301169]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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

--On 2000-01-19 23.28 -0500, "David P. Peek" <peek@bit-net.com> wrote:

> I look forward to hearing your comments about this two-tier approach that
> combines DNS and LDAP.

That is one way of spreading/collecting more information about an E.164
number.

The charter for the ENUM working group have though limited the scope  of
their work to only work with the basic listing service, and not go into the
discussion of where to store spoken name and other higher-level attributes.
Discussions about those imply that things like access control must be
resolved, which is not an easy task across boundaries between legal bodies
(such as two ISPs).

So, my personal view is that we will have exactly this two-tier approach
which you talk about. A basic listing service so I very easilly can get
information about what services exists so I can initiate the next step in
call setup, routing exploration, getting more information about peer etc.
This second layer can though often be different between different protocols
or type of endpoints (one way in VOICE, one way for FAX, one way in the
local environment etc).

ENUM is though not the place to discuss it, but Scott should probably say
that :-) 

   paf




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


From enum-admin@ietf.org  Thu Jan 20 00:56: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 AAA11214
	for <enum-archive@ietf.org>; Thu, 20 Jan 2000 00:56:58 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11422;
	Thu, 20 Jan 2000 00:55:27 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11386
	for <enum@optimus.ietf.org>; Thu, 20 Jan 2000 00:55:25 -0500 (EST)
Received: from nix.swip.net (nix.swip.net [192.71.220.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11209
	for <enum@ietf.org>; Thu, 20 Jan 2000 00:56:36 -0500 (EST)
Received: from 192.168.111.25 (workstation1.swip.net [130.244.254.1]) 
          by nix.swip.net (8.8.8/8.8.8) with ESMTP 
          id GAA06847; 
          Thu, 20 Jan 2000 06:54:25 +0100 (MET)
Date: Thu, 20 Jan 2000 06:54:20 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@swip.net>
To: =?ISO-8859-1?Q?S=F6ren_Nyckelg=E5rd?= <Soren.M.Nyckelgard@telia.se>,
        "'Richard Shockey'" <rshockey@ix.netcom.com>, enum@ietf.org
Subject: RE: [Enum] New DNS record class values?
Message-ID: <3424995.3157340060@[192.168.111.25]>
In-Reply-To: <778DFE9B4E3BD111A74E08002BA3DC0D01DE4994@trab-hermes.haninge.trab.se>
X-Mailer: Mulberry (MacOS) [2.0.0b7, s/n U-301169]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA11387
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 2000-01-20 02.51 +0100, Sören Nyckelgård <Soren.M.Nyckelgard@telia.se>
wrote:

> If instead the E.164 
> number identifies a user that might move between different terminals, 
> then the DNS record preferably should point to an address data 
> repository that can be dynamically updated. 

Or, we update the DNS to hold the correct record. I.e. it all depends on
what timeframes you talk about. DNS refresh values which are minutes is no
problem at all. Seconds are a problem because of cacheing. I.e. having
inconsitencies over a few minutes is not (today) so strange.

But, when I leave the office and redirect my phone to the phone switch, it
still takes me a few minutes to grab all my stuff and actually leave the
building, so a few minutes delay is no problem for me.

That said, DNS will NOT be able to be updated atomically, but neither will
a distributed/replicated LDAP solution. Forcing always a query to the
authoritative source will be costly, regardless of protocol (but of course
more problematic in DNS because of client-side cacheing).

So, as long as one _know_ what delays the protocol inject in the resolution
process, it is possible to build services which match those services.

    Patrik


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


From enum-admin@ietf.org  Thu Jan 20 08:21: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 IAA27431
	for <enum-archive@ietf.org>; Thu, 20 Jan 2000 08:21:48 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27395;
	Thu, 20 Jan 2000 08:18:29 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27363
	for <enum@optimus.ietf.org>; Thu, 20 Jan 2000 08:18:28 -0500 (EST)
Received: from msw.mimesweeper.com (msw.mimesweeper.com [194.168.90.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27332
	for <enum@ietf.org>; Thu, 20 Jan 2000 08:19:37 -0500 (EST)
Received: from bell.mimesweeper.com (unverified) by msw.mimesweeper.com
 (Content Technologies SMTPRS 4.1.2) with ESMTP id <Bc2a85a1249dbef48cd@msw.mimesweeper.com>;
 Thu, 20 Jan 2000 13:21:44 +0000
Received: from gk-vaio (dhcp-180.mimesweeper.com [194.168.90.180]) by bell.mimesweeper.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id DDXNY9FA; Thu, 20 Jan 2000 13:21:10 -0000
Message-Id: <4.2.2.20000120115924.00afad60@pop.dial.pipex.com>
X-Sender: maiw03@pop.dial.pipex.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 20 Jan 2000 12:01:18 +0000
To: "David P. Peek" <peek@bit-net.com>
From: Graham Klyne <GK@dial.pipex.com>
Subject: Re: [Enum] New DNS record class values?
Cc: <enum@ietf.org>
In-Reply-To: <00b101bf62fe$c69daa60$020aa8c0@seagal.voicedomain>
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:28 PM 1/19/00 -0500, David P. Peek wrote:
>I look forward to hearing your comments about this two-tier approach that
>combines DNS and LDAP.

A similar, but very much more lightweight, approach currently under 
consideration is RESCAP.

#g

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


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


From enum-admin@ietf.org  Thu Jan 20 09:21: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 JAA29886
	for <enum-archive@ietf.org>; Thu, 20 Jan 2000 09:21:44 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29149;
	Thu, 20 Jan 2000 09:19:45 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29120
	for <enum@optimus.ietf.org>; Thu, 20 Jan 2000 09:19:43 -0500 (EST)
Received: from mail.bit-net.com (mail.bit-net.com [208.146.132.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29857
	for <enum@ietf.org>; Thu, 20 Jan 2000 09:20:51 -0500 (EST)
Received: from seagal (www.evds.com [208.146.135.202])
	by mail.bit-net.com (8.9.3/8.9.2) with SMTP id JAA24898;
	Thu, 20 Jan 2000 09:20:45 -0500 (EST)
	(envelope-from peek@bit-net.com)
Message-ID: <002801bf6351$6c6dcfe0$020aa8c0@seagal.voicedomain>
From: "David P. Peek" <peek@bit-net.com>
To: "=?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?=" <paf@swip.net>,
        "Richard Shockey" <rshockey@ix.netcom.com>, <enum@ietf.org>,
        "=?iso-8859-1?B?U/ZyZW4gIE55Y2tlbGflcmQ=?=" <Soren.M.Nyckelgard@telia.se>
Subject: Re: [Enum] New DNS record class values?
Date: Thu, 20 Jan 2000 09:19:53 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
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



>--On 2000-01-19 23.28 -0500, "David P. Peek" <peek@bit-net.com> wrote:
>
>> I look forward to hearing your comments about this two-tier approach that
>> combines DNS and LDAP.
>
>That is one way of spreading/collecting more information about an E.164
>number.
>
>The charter for the ENUM working group have though limited the scope  of
>their work to only work with the basic listing service, and not go into the
>discussion of where to store spoken name and other higher-level attributes.
>Discussions about those imply that things like access control must be
>resolved, which is not an easy task across boundaries between legal bodies
>(such as two ISPs).
>

I agree and understand those issues are outside the ENUM charter.

>So, my personal view is that we will have exactly this two-tier approach
>which you talk about. A basic listing service so I very easilly can get
>information about what services exists so I can initiate the next step in
>call setup, routing exploration, getting more information about peer etc.
>This second layer can though often be different between different protocols
>or type of endpoints (one way in VOICE, one way for FAX, one way in the
>local environment etc).
>
In keeping with ENUM's scope and the current
discussion how would we define this authoriative directory server
(ADS)  pointer using DNS?   Would we followi the current method being
dicussed
and use a NAPTR record?
If so, what would that look like?   A very simply approach for this ADS
discovery, do I
dare say, is to use the A-record in DNS for an E-164 host name.  Avoiding
multiple queries
to DNS and avoiding the use of DNS field parsers is a motivation since we
are dealing
with a potentially long process already (in some cases anyway).  Maybe a
NAPTR record
also exists in conjuction with defining an A-record?   Am I way off here? -
dpp

>ENUM is though not the place to discuss it, but Scott should probably say
>that :-)
>
>   paf
>
>
>
>
>_______________________________________________
>enum mailing list
>enum@ietf.org
>http://www.ietf.org/mailman/listinfo/enum
>


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


From enum-admin@ietf.org  Thu Jan 20 11:07: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 LAA04764
	for <enum-archive@ietf.org>; Thu, 20 Jan 2000 11:07:21 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02509;
	Thu, 20 Jan 2000 11:05:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02451
	for <enum@optimus.ietf.org>; Thu, 20 Jan 2000 11:05:04 -0500 (EST)
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 LAA04701
	for <enum@ietf.org>; Thu, 20 Jan 2000 11:06:09 -0500 (EST)
Received: from laptop (stl-mo14-08.ix.netcom.com [207.222.133.8])
	by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA00895;
	Thu, 20 Jan 2000 11:05:55 -0500 (EST)
Message-Id: <4.2.0.58.20000120095321.00a68290@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 20 Jan 2000 09:58:24 -0600
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@swip.net>,
        "David P. Peek" <peek@bit-net.com>, enum@ietf.org,
        =?iso-8859-1?Q?S=F6ren?=
 =?iso-8859-1?Q?__Nyckelg=E5rd?= <Soren.M.Nyckelgard@telia.se>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: Re: [Enum] New DNS record class values?
In-Reply-To: <3405093.3157339730@[192.168.111.25]>
References: <00b101bf62fe$c69daa60$020aa8c0@seagal.voicedomain>
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


>he charter for the ENUM working group have though limited the scope  of
>their work to only work with the basic listing service, and not go into the
>discussion of where to store spoken name and other higher-level attributes.
>Discussions about those imply that things like access control must be
>resolved, which is not an easy task across boundaries between legal bodies
>(such as two ISPs).

Which is why Local Number Portability data is maintained by 3rd parties :-)


>So, my personal view is that we will have exactly this two-tier approach
>which you talk about. A basic listing service so I very easilly can get
>information about what services exists so I can initiate the next step in
>call setup, routing exploration, getting more information about peer etc.
>This second layer can though often be different between different protocols
>or type of endpoints (one way in VOICE, one way for FAX, one way in the
>local environment etc).


I agree completely agree with Patrik. I'm convinced the 2 tier approach is 
the one that will be  globally deployed.  I have read all of  Greg 
Vaudreuil's excellent vpimdir ID's on this subject and have found them very 
instructive on what goals and requirements the voice messaging industry has.


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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


From enum-admin@ietf.org  Thu Jan 20 11:07: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 LAA04785
	for <enum-archive@ietf.org>; Thu, 20 Jan 2000 11:07:31 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02496;
	Thu, 20 Jan 2000 11:05:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02445
	for <enum@optimus.ietf.org>; Thu, 20 Jan 2000 11:05:03 -0500 (EST)
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 LAA04703
	for <enum@ietf.org>; Thu, 20 Jan 2000 11:06:10 -0500 (EST)
Received: from laptop (stl-mo14-08.ix.netcom.com [207.222.133.8])
	by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA07729;
	Thu, 20 Jan 2000 11:06:01 -0500 (EST)
Message-Id: <4.2.0.58.20000120095854.00a65370@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 20 Jan 2000 10:05:16 -0600
To: Graham Klyne <GK@dial.pipex.com>, "David P. Peek" <peek@bit-net.com>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: Re: [Enum] New DNS record class values?
Cc: <enum@ietf.org>
In-Reply-To: <4.2.2.20000120115924.00afad60@pop.dial.pipex.com>
References: <00b101bf62fe$c69daa60$020aa8c0@seagal.voicedomain>
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 12:01 PM 1/20/2000 +0000, Graham Klyne wrote:
>At 11:28 PM 1/19/00 -0500, David P. Peek wrote:
>>I look forward to hearing your comments about this two-tier approach that
>>combines DNS and LDAP.
>
>A similar, but very much more lightweight, approach currently under 
>consideration is RESCAP.

I wish we had it NOW so we could consider its use. I still have questions 
about the speed of LDAP response during call setup.

Even if RESCAP were ready we would then still have to have a SRV record 
pointing to the host where the RECSAP data is maintained. I've begun to 
reject the idea that RESCAP data could be contained within the 164 DNS data 
record...even if you used the "kitchen sink" RR.  I think we would be very 
close to pushing the 256 byte limit.


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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


From enum-admin@ietf.org  Thu Jan 20 12:08: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 MAA07540
	for <enum-archive@ietf.org>; Thu, 20 Jan 2000 12:08:42 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06736;
	Thu, 20 Jan 2000 12:05:11 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06707
	for <enum@optimus.ietf.org>; Thu, 20 Jan 2000 12:05:09 -0500 (EST)
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 MAA07488
	for <enum@ietf.org>; Thu, 20 Jan 2000 12:06:16 -0500 (EST)
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 JAA07086
	for <enum@ietf.org>; Thu, 20 Jan 2000 09:05:58 -0800 (PST)
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 JAA10159
	for <enum@ietf.org>; Thu, 20 Jan 2000 09:06:13 -0800 (PST)
Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Thu, 20 Jan 2000 09:05:57 -0800
Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0)
	id <CC4351J8>; Thu, 20 Jan 2000 12:05:55 -0500
Message-Id: <4102273CEB77D211869200805FE6F59356ED82@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@swip.net>, enum@ietf.org
Subject: RE: [Enum] New DNS record class values?
Date: Thu, 20 Jan 2000 12:05:55 -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 MAA06708
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:
> --On 2000-01-20 02.51 +0100, Sören Nyckelgård 
> <Soren.M.Nyckelgard@telia.se>
> wrote:
> 
> > If instead the E.164 
> > number identifies a user that might move between different 
> terminals, 
> > then the DNS record preferably should point to an address data 
> > repository that can be dynamically updated. 
> 
> Or, we update the DNS to hold the correct record. I.e. it all 
> depends on
> what timeframes you talk about. DNS refresh values which are 
> minutes is no
> problem at all. Seconds are a problem because of cacheing. I.e. having
> inconsitencies over a few minutes is not (today) so strange.

The DNS system updates slowly, though, so you don't want to use it for
keeping track of mobile stations. You can expect hours for all DNS servers
to get synched up.

> But, when I leave the office and redirect my phone to the 
> phone switch, it
> still takes me a few minutes to grab all my stuff and 
> actually leave the
> building, so a few minutes delay is no problem for me.
> 
> That said, DNS will NOT be able to be updated atomically, but 
> neither will
> a distributed/replicated LDAP solution. Forcing always a query to the
> authoritative source will be costly, regardless of protocol 
> (but of course
> more problematic in DNS because of client-side cacheing).
> 
> So, as long as one _know_ what delays the protocol inject in 
> the resolution
> process, it is possible to build services which match those services.

I'm not sure about mobile telephones, but if they operate similar to mobile
IP and mobile ATM, you'll need the DNS to point to a "home server" of some
sort, which keeps track of the current location of the mobile host?

Bert
albert.e.manfredi@boeing.com

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


From enum-admin@ietf.org  Thu Jan 20 13:29: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 NAA11227
	for <enum-archive@ietf.org>; Thu, 20 Jan 2000 13:29:22 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08865;
	Thu, 20 Jan 2000 13:26:55 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08835
	for <enum@optimus.ietf.org>; Thu, 20 Jan 2000 13:26:53 -0500 (EST)
Received: from nix.swip.net (nix.swip.net [192.71.220.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11165
	for <enum@ietf.org>; Thu, 20 Jan 2000 13:28:03 -0500 (EST)
Received: from 192.168.111.25 (workstation1.swip.net [130.244.254.1]) 
          by nix.swip.net (8.8.8/8.8.8) with ESMTP 
          id TAA06531; 
          Thu, 20 Jan 2000 19:25:50 +0100 (MET)
Date: Thu, 20 Jan 2000 19:25:37 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@swip.net>
To: "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>, enum@ietf.org
Subject: RE: [Enum] New DNS record class values?
Message-ID: <4941221.3157385137@[192.168.111.25]>
In-Reply-To: <4102273CEB77D211869200805FE6F59356ED82@xch-phl-01.he.boeing.com>
X-Mailer: Mulberry (MacOS) [2.0.0b7, s/n U-301169]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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

--On 2000-01-20 12.05 -0500, "Manfredi, Albert E"
<Albert.Manfredi@PHL.Boeing.com> wrote:

> The DNS system updates slowly, though, so you don't want to use it for
> keeping track of mobile stations. You can expect hours for all DNS servers
> to get synched up.

Nope, not any longer. Newer versions of bind, and many other implementors
servers:

(1) Have individual TTL on each record, and not on all records in the zone,
i.e. TTL in the SOA is no longer "default"

(2) Have the TTL shorter than 15 minutes (earlier implementations sometimes
had problems with this)

(3) Have the primary server sending notifications to secondaries when the
zone is updated

All of this works so well in todays internet, so I would say that DNS
servers today are in sync modulo a few seconds, and TTL is set by the
master server -- which by this is in total control of how long the delay is
before the records are in sync.

   paf


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


From enum-admin@ietf.org  Thu Jan 20 13:39: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 NAA11652
	for <enum-archive@ietf.org>; Thu, 20 Jan 2000 13:39:58 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09205;
	Thu, 20 Jan 2000 13:38:27 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09173
	for <enum@optimus.ietf.org>; Thu, 20 Jan 2000 13:38:25 -0500 (EST)
Received: from nix.swip.net (nix.swip.net [192.71.220.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11641
	for <enum@ietf.org>; Thu, 20 Jan 2000 13:39:35 -0500 (EST)
Received: from 192.168.111.25 (workstation1.swip.net [130.244.254.1]) 
          by nix.swip.net (8.8.8/8.8.8) with ESMTP 
          id TAA06927; 
          Thu, 20 Jan 2000 19:37:21 +0100 (MET)
Date: Thu, 20 Jan 2000 19:37:14 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@swip.net>
To: "David P. Peek" <peek@bit-net.com>,
        Richard Shockey <rshockey@ix.netcom.com>, enum@ietf.org,
        =?ISO-8859-1?Q?S=F6ren__Nyckelg=E5rd?= <Soren.M.Nyckelgard@telia.se>
Subject: Re: [Enum] New DNS record class values?
Message-ID: <4983107.3157385834@[192.168.111.25]>
In-Reply-To: <002801bf6351$6c6dcfe0$020aa8c0@seagal.voicedomain>
X-Mailer: Mulberry (MacOS) [2.0.0b7, s/n U-301169]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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

--On 2000-01-20 09.19 -0500, "David P. Peek" <peek@bit-net.com> wrote:

> Would we followi the current method being
> dicussed
> and use a NAPTR record?

Define that one can have one of the NAPTR records for the E.164 number
pointing to an LDAP URL.

  paf




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


From enum-admin@ietf.org  Thu Jan 20 15:29: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 PAA14647
	for <enum-archive@ietf.org>; Thu, 20 Jan 2000 15:29:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11798;
	Thu, 20 Jan 2000 15:26:51 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11770
	for <enum@optimus.ietf.org>; Thu, 20 Jan 2000 15:26:45 -0500 (EST)
Received: from PMESMTP02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14597
	for <enum@ietf.org>; Thu, 20 Jan 2000 15:27:52 -0500 (EST)
Received: from omzrelay.mcit.com ([166.37.204.49])
 by firewall.mcit.com (PMDF V5.2-32 #41713)
 with ESMTP id <0FON00955HXRND@firewall.mcit.com> for enum@ietf.org; Thu,
 20 Jan 2000 20:22:39 +0000 (GMT)
Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120])
 by omzrelay.mcit.com (8.8.7/) with ESMTP	id UAA17419; Thu,
 20 Jan 2000 20:22:34 +0000 (GMT)
Received: from dwillispc8 ([166.35.226.47])
 by omzmta02.mcit.com (InterMail v03.02.05 118 120)
 with SMTP id <20000120202230.LYMH6722@[166.35.226.47]>; Thu,
 20 Jan 2000 20:22:31 +0000
Date: Thu, 20 Jan 2000 14:21:30 -0600
From: Dean Willis <dean.willis@wcom.com>
Subject: More Knowledge than DNS (was RE: [Enum] New DNS record class values?)
In-reply-to: <00b101bf62fe$c69daa60$020aa8c0@seagal.voicedomain>
To: "David P. Peek" <peek@bit-net.com>,
        Richard Shockey <rshockey@ix.netcom.com>, enum@ietf.org,
        =?iso-8859-1?Q?S=F6ren__Nyckelg=E5rd?= <Soren.M.Nyckelgard@telia.se>
Cc: "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" <paf@swip.net>
Message-id: <001301bf6383$f0022040$2fe223a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
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

David mentioned:
> Services such as voice messaging (VPIM) and enhanced messaging systems
> (unified messaging) will require additional information that can't be
> supplied by a DNS server alone.  (e.g. Spoken-Name, preferred codecs,
> individual preferences, vCards, LATA values, etc.)   For IP-PBX
> IP-Telephony
> servers
> and gateways they may not always be static depending upon service level
> agreements
> and individual gateway capabilities.  Service operators and network
> operators are faced
> with delivering large/global services where the users
> expectations are based
> on high featured
> local communications environments.   Our solutions must enabled
> the support
> of these
> features that require more knowledge then is available at the DNS level
> alone.

I'd like to point out that one way to transmit the additional information is
in the context of a URI.

This approach is proposed in:

http://www.ietf.org/internet-drafts/draft-campbell-sip-service-control-00.tx
t

If rather than LDAP, one uses ENUM approaches to locate the SIP server
responsible for dealing with a number, then this kind of URI-loading can be
brought to bear.

--
Dean


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


From enum-admin@ietf.org  Thu Jan 20 20: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 UAA17848
	for <enum-archive@ietf.org>; Thu, 20 Jan 2000 20:24:15 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA20383;
	Thu, 20 Jan 2000 20:20:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA20355
	for <enum@optimus.ietf.org>; Thu, 20 Jan 2000 20:20:25 -0500 (EST)
Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17799
	for <enum@ietf.org>; Thu, 20 Jan 2000 20:21:32 -0500 (EST)
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12])
	by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id UAA26815;
	Thu, 20 Jan 2000 20:20:59 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
	by mailman.fore.com (8.9.3/8.9.3) with ESMTP id UAA12763;
	Thu, 20 Jan 2000 20:21:03 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21)
	id <C7JH3YFJ>; Thu, 20 Jan 2000 20:18:10 -0500
Message-ID: <4FBEA8857476D311A03300204840E1CF1A0ADC@whq-msgusr-02.fore.com>
From: "Rosen, Brian" <brosen@fore.com>
To: "David P. Peek" <peek@bit-net.com>, enum@ietf.org
Subject: RE: [Enum] New DNS record class values?
Date: Thu, 20 Jan 2000 20:20:58 -0500
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

Insert standard disclaimer about not being an ENUM subject

> We have also found that service providers demand more control 
> over access to
> their data. Service providers and network operators want to 
> control who has
> access to entries down to the attribute level and service 
> level.  This is
> difficult to do with DNS alone.  Security of information such 
> as what is
> public and what is private can be eloquently supported using 
> LDAP servers
> with access control information.

Most, but not all, of this information is MINE, not a service provider's.
I own in, I want to control it.  It may be that service providers
have some information they keep for their own internal purposes (as
long as they disclose such purposes to me), so the problem is not anywhere
near
as simple as -an- LDAP query. I also will undoubtedly have multiple service
providers.  As a result, I may need multiple entries to do parallel 
searches in the DNS record. The question turns on whether any of the
information
a service provider needs to complete a call to another service provider
is in the service provider's database, thus requiring public record lookup,
or whether the information needed is all mine, and I can choose to release
portions of it depending on access controls.  The latter gets the problem
simpler, but I suspect the former is more likely, probably more due to 
intrangicence rather than need. 

I probably have at least two Voice mailboxes - personal and office, and I
might
have a shared home one too.  I would want a single configuration, where
common data is entered once, and VM service provider value-add data is
entered
separately, if possible on one web page.  The call forwarding logic of my
(cell,
home, work) telephony service provider may result in a call being handled
by
one of my VM service providers, handed off by any of my telephony service
providers.  
For example some one calls me personally, my home phone and my cell phone
ring
simultaneously, first answer gets the call, no answer forwards to my
personal
VM box.  I want, as much as possible, to have them behave the same, use the 
same basic configuration, etc.  My DNS record (it's mine, or possibly my
employer's) 
might be getting big, but so what?  

Brian
------------
Brian Rosen, Principal Engineer
Marconi (Formerly FORE Systems)
1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:brosen@eng.fore.com 


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


From enum-admin@ietf.org  Thu Jan 20 21:56: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 VAA19516
	for <enum-archive@ietf.org>; Thu, 20 Jan 2000 21:56:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22477;
	Thu, 20 Jan 2000 21:47:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22448
	for <enum@optimus.ietf.org>; Thu, 20 Jan 2000 21:47:40 -0500 (EST)
Received: from mail.bit-net.com (mail.bit-net.com [208.146.132.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19488
	for <enum@ietf.org>; Thu, 20 Jan 2000 21:48:44 -0500 (EST)
Received: from seagal (www.evds.com [208.146.135.202])
	by mail.bit-net.com (8.9.3/8.9.2) with SMTP id VAA15930;
	Thu, 20 Jan 2000 21:48:30 -0500 (EST)
	(envelope-from peek@bit-net.com)
Message-ID: <013801bf63b9$dab11080$020aa8c0@seagal.voicedomain>
From: "David P. Peek" <peek@bit-net.com>
To: "Rosen, Brian" <brosen@fore.com>, <enum@ietf.org>
Subject: Re: [Enum] New DNS record class values?
Date: Thu, 20 Jan 2000 21:47:25 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
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


-----Original Message-----
From: Rosen, Brian <brosen@fore.com>
To: David P. Peek <peek@bit-net.com>; enum@ietf.org <enum@ietf.org>
Date: Thursday, January 20, 2000 8:24 PM
Subject: RE: [Enum] New DNS record class values?


>Insert standard disclaimer about not being an ENUM subject
>
>> We have also found that service providers demand more control
>> over access to
>> their data. Service providers and network operators want to
>> control who has
>> access to entries down to the attribute level and service
>> level.  This is
>> difficult to do with DNS alone.  Security of information such
>> as what is
>> public and what is private can be eloquently supported using
>> LDAP servers
>> with access control information.
>
>Most, but not all, of this information is MINE, not a service provider's.
>I own in, I want to control it.  It may be that service providers
>have some information they keep for their own internal purposes (as
>long as they disclose such purposes to me), so the problem is not anywhere
>near
>as simple as -an- LDAP query. I also will undoubtedly have multiple service
>providers.  As a result, I may need multiple entries to do parallel
>searches in the DNS record. The question turns on whether any of the
>information
>a service provider needs to complete a call to another service provider
>is in the service provider's database, thus requiring public record lookup,
>or whether the information needed is all mine, and I can choose to release
>portions of it depending on access controls.  The latter gets the problem
>simpler, but I suspect the former is more likely, probably more due to
>intrangicence rather than need.
>
>I probably have at least two Voice mailboxes - personal and office, and I
>might
>have a shared home one too.  I would want a single configuration, where
>common data is entered once, and VM service provider value-add data is
>entered
>separately, if possible on one web page.  The call forwarding logic of my
>(cell,
>home, work) telephony service provider may result in a call being handled
>by
>one of my VM service providers, handed off by any of my telephony service
>providers.
>For example some one calls me personally, my home phone and my cell phone
>ring
>simultaneously, first answer gets the call, no answer forwards to my
>personal
>VM box.  I want, as much as possible, to have them behave the same, use the
>same basic configuration, etc.  My DNS record (it's mine, or possibly my
>employer's)
>might be getting big, but so what?

The services you describe are exactly the reasons for a two-tiered approach.
The data values are indeed yours and you (through your service
provider(s) ) may adjust these values and determine who gets access and how
your
services are configured.  The competition to supply enhanced services will
create
more sophisticated  second-tier servers capable of delivering the control
and special
features users want.  Using DNS alone wont give this type of flexibility and
control that you demand.  DNS is a very good technology for what it does and
it continues to be a critical component to the solution.

I'd be glad to continue this conversation offline since we are getting
outside the scope of
ENUM as was mentioned.  Your example of controlling multiple mailboxes was
demonstrated
in a VMA demonstration in Helsinki in June of 1999 with the use of a global
directory service.
I think your examples are very accurate and should be taken into
consideration while we are
all creating the infrustructure. -dpp


>
>Brian
>------------
>Brian Rosen, Principal Engineer
>Marconi (Formerly FORE Systems)
>1000 FORE Drive, Warrendale, PA 15086
>(724) 742-6826  mailto:brosen@eng.fore.com
>
>
>_______________________________________________
>enum mailing list
>enum@ietf.org
>http://www.ietf.org/mailman/listinfo/enum
>


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


From enum-admin@ietf.org  Thu Jan 20 22:16: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 WAA19678
	for <enum-archive@ietf.org>; Thu, 20 Jan 2000 22:16:08 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23111;
	Thu, 20 Jan 2000 22:13:32 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23079
	for <enum@optimus.ietf.org>; Thu, 20 Jan 2000 22:13:30 -0500 (EST)
Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net [207.69.128.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19667
	for <enum@ietf.org>; Thu, 20 Jan 2000 22:14:38 -0500 (EST)
Received: from laptop (stl-mo17-31.ix.netcom.com [207.222.134.159])
	by smtp7.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id WAA15039;
	Thu, 20 Jan 2000 22:14:27 -0500 (EST)
Message-Id: <4.2.0.58.20000120210922.00a3e6f0@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 20 Jan 2000 21:13:49 -0600
To: "David P. Peek" <peek@bit-net.com>, "Rosen, Brian" <brosen@fore.com>,
        <enum@ietf.org>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: Re: [Enum] New DNS record class values?
In-Reply-To: <013801bf63b9$dab11080$020aa8c0@seagal.voicedomain>
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


>
>I'd be glad to continue this conversation offline since we are getting
>outside the scope of
>ENUM as was mentioned.  Your example of controlling multiple mailboxes was
>demonstrated
>in a VMA demonstration in Helsinki in June of 1999 with the use of a global
>directory service.
>I think your examples are very accurate and should be taken into
>consideration while we are
>all creating the infrustructure. -dpp


There are going to be lots of "out of scope" issues related to ENUM that 
folks may want to discuss. Maybe we should get a new list started. I would 
like to participate in these discussions as well.

  Patrik ... good idea?  .. [ our WG chair is out sick so we can rely on 
Patrik's judgement :-) ]


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey@ix.netcom.com
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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


From enum-admin@ietf.org  Fri Jan 21 10:22: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 KAA11623
	for <enum-archive@ietf.org>; Fri, 21 Jan 2000 10:22:31 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17950;
	Fri, 21 Jan 2000 10:18:58 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17919
	for <enum@optimus.ietf.org>; Fri, 21 Jan 2000 10:18:57 -0500 (EST)
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 KAA11570
	for <enum@ietf.org>; Fri, 21 Jan 2000 10:20:07 -0500 (EST)
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 HAA19066
	for <enum@ietf.org>; Fri, 21 Jan 2000 07:19:52 -0800 (PST)
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 HAA10407
	for <enum@ietf.org>; Fri, 21 Jan 2000 07:20:08 -0800 (PST)
Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP for enum@ietf.org; Fri, 21 Jan 2000 07:20:00 -0800
Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0)
	id <CC435QPC>; Fri, 21 Jan 2000 10:19:58 -0500
Message-Id: <4102273CEB77D211869200805FE6F59356ED8D@xch-phl-01.he.boeing.com>
From: "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>
To: enum@ietf.org
Date: Fri, 21 Jan 2000 10:19:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [Enum] DNS for mobility support
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 Shockey wrote:

> There are going to be lots of "out of scope" issues related 
> to ENUM that 
> folks may want to discuss. Maybe we should get a new list 
> started. I would 
> like to participate in these discussions as well.

Whatever makes sense.

But I have a question. Assuming that the DNS is indeed capable of updating
itself globally within seconds, why can't it be used directly to support
mobile stations, both IP and telephony? The second tier servers, to support
all the proprietary features each service provider offers would still exist,
and makes a lot of sense, but why can't the DNS be queried directly to
localize a mobile host?

I am pretty amazed that a global update in seconds is possible, since
yesterday was the first time I saw this mentioned. Why shouldn't that
feature be put to good use? It sure beats the way it's done now, doesn't it?

Whether it's to translate between a _portable_ telephone number and a
_routable_ and stationary number, _or_ between a portable number and the
current routable number of a mobile host, such a rapid DNS should satisfy
everyone. Not so? The fields the DNS currently supports would be sufficient
for this task, I believe?

Sorry if I don't use the correct telephony jargon.

Bert
albert.e.manfredi@boeing.com

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


From enum-admin@ietf.org  Fri Jan 21 10:48: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 KAA12131
	for <enum-archive@ietf.org>; Fri, 21 Jan 2000 10:48:30 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18519;
	Fri, 21 Jan 2000 10:46:24 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18491
	for <enum@optimus.ietf.org>; Fri, 21 Jan 2000 10:46:23 -0500 (EST)
Received: from mex.italtel.it (mex.italtel.it [138.132.117.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12115
	for <enum@ietf.org>; Fri, 21 Jan 2000 10:47:33 -0500 (EST)
Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id QAA25269
Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP
 id QAA27602
Received: from ic8u32.settimo.italtel.it (ic8u32.settimo.italtel.it [138.132.1.1])
	by mix.italtel.it (8.9.3/8.9.3) with SMTP id QAA10511;
	Fri, 21 Jan 2000 16:45:04 +0100 (MET)
Received: by ic8u32.settimo.italtel.it id AA13979; Fri, 21 Jan 2000 17:02:31 +0100
Received: from ic1daj.settimo.italtel.it by ilt9h01.settimo.italtel.it with SMTP
	(1.38.193.5/16.2) id AA01747; Fri, 21 Jan 2000 16:39:20 +0100
Message-Id: <38887E79.24D1B239@italtel.it>
Date: Fri, 21 Jan 2000 16:42:50 +0100
From: Giuseppe Ricagni <giuseppe.ricagni@italtel.it>
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
Mime-Version: 1.0
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@swip.net>
Cc: "Manfredi, Albert E" <Albert.Manfredi@phl.boeing.com>, enum@ietf.org
Subject: Re: [Enum] New DNS record class values?
References: <4941221.3157385137@[192.168.111.25]>
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

Patrick,

Patrik Fdltstrvm wrote:

> --On 2000-01-20 12.05 -0500, "Manfredi, Albert E"
> <Albert.Manfredi@PHL.Boeing.com> wrote:
>
> > The DNS system updates slowly, though, so you don't want to use it for
> > keeping track of mobile stations. You can expect hours for all DNS servers
> > to get synched up.
>
> Nope, not any longer. Newer versions of bind, and many other implementors
> servers:
>
> (1) Have individual TTL on each record, and not on all records in the zone,
> i.e. TTL in the SOA is no longer "default"
>
> (2) Have the TTL shorter than 15 minutes (earlier implementations sometimes
> had problems with this)
>
> (3) Have the primary server sending notifications to secondaries when the
> zone is updated
>
> All of this works so well in todays internet, so I would say that DNS
> servers today are in sync modulo a few seconds

I' m not a DNS expert.
The only thing I am sure of is that I kept getting hits on my old web server for
at least four days when I  changed the IP address associated to my domain name.
This happened in June 1999.

Something must have changed in these last six months...

Giuseppe



----------------------------------------------------------
Giuseppe RICAGNI
System Architecture and Product Planning
Broadband Networks
Italtel
via Reiss Romoli - C10
20019 Castelletto di Settimo Milanese (MILANO)
ITALY

mailto:giuseppe.ricagni@italtel.it
----------------------------------------------------------



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


From enum-admin@ietf.org  Fri Jan 21 10:59: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 KAA12281
	for <enum-archive@ietf.org>; Fri, 21 Jan 2000 10:59:06 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18761;
	Fri, 21 Jan 2000 10:56:39 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18728
	for <enum@optimus.ietf.org>; Fri, 21 Jan 2000 10:56:37 -0500 (EST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12269
	for <enum@ietf.org>; Fri, 21 Jan 2000 10:57:48 -0500 (EST)
Received: from zed.isi.edu (zed-e.isi.edu [128.9.160.57])
	by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id HAA25187;
	Fri, 21 Jan 2000 07:57:46 -0800 (PST)
From: Bill Manning <bmanning@isi.edu>
Received: (from bmanning@localhost)
	by zed.isi.edu (8.8.7/8.8.6) id HAA20789;
	Fri, 21 Jan 2000 07:57:42 -0800 (PST)
Message-Id: <200001211557.HAA20789@zed.isi.edu>
Subject: Re: [Enum] New DNS record class values?
To: giuseppe.ricagni@italtel.it (Giuseppe Ricagni)
Date: Fri, 21 Jan 2000 07:57:42 -0800 (PST)
Cc: paf@swip.net (Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=),
        Albert.Manfredi@phl.boeing.com (Manfredi Albert E), enum@ietf.org
In-Reply-To: <38887E79.24D1B239@italtel.it> from "Giuseppe Ricagni" at Jan 21, 2000 04:42:50 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
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

% > All of this works so well in todays internet, so I would say that DNS
% > servers today are in sync modulo a few seconds
% 
% I' m not a DNS expert.
% The only thing I am sure of is that I kept getting hits on my old web server for
% at least four days when I  changed the IP address associated to my domain name.
% This happened in June 1999.
% 
% Something must have changed in these last six months...
% 
% Giuseppe

	Based on the size and frequency of the update, patrick is correct,
	syncronization occurs in seconds.  However, the historical methods
	involve manual, out-of-band coordination with the parents and children
	of a zone. So it may take you four weeks to contact me and for me
	to update the data on my servers. Once I do however, the change is
	done in seconds.

-- 
--bill

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


From enum-admin@ietf.org  Fri Jan 21 11:02: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 LAA12441
	for <enum-archive@ietf.org>; Fri, 21 Jan 2000 11:02:00 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18857;
	Fri, 21 Jan 2000 10:59:40 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18832
	for <enum@optimus.ietf.org>; Fri, 21 Jan 2000 10:59:39 -0500 (EST)
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12378
	for <enum@ietf.org>; Fri, 21 Jan 2000 11:00:50 -0500 (EST)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprtp1.ntcom.nortel.net; Fri, 21 Jan 2000 10:59:58 -0500
Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id DKPQG1KJ; Fri, 21 Jan 2000 10:59:57 -0500
Received: from nortelnetworks.com (msquire-1.corpeast.baynetworks.com [132.245.252.65]) 
          by zbl6c008.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id D17VNX97; Fri, 21 Jan 2000 10:59:56 -0500
Message-ID: <38888275.CD71EBC3@nortelnetworks.com>
Date: Fri, 21 Jan 2000 10:59:49 -0500
From: "Matt Squire" <msquire@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>
CC: enum@ietf.org
Subject: Re: [Enum] DNS for mobility support
References: <4102273CEB77D211869200805FE6F59356ED8D@xch-phl-01.he.boeing.com>
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


> Whatever makes sense.
> 
> But I have a question. Assuming that the DNS is indeed capable of updating
> itself globally within seconds, why can't it be used directly to support
> mobile stations, both IP and telephony? The second tier servers, to support
> all the proprietary features each service provider offers would still exist,
> and makes a lot of sense, but why can't the DNS be queried directly to
> localize a mobile host?
> 

A personal guess/opinion...

I think DNS is capable of updating within seconds.... on a small scale. 
This kind of granularity on a large scale would obliterate the ability
to cache many/most DNS responses, and without caching the load on the
DNS infrastructure would be vastly different than it is today, which, in
turn, would probably eliminate the ability for the update to actually
happen in seconds.   

- Matt

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


From enum-admin@ietf.org  Fri Jan 21 11:05: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 LAA12543
	for <enum-archive@ietf.org>; Fri, 21 Jan 2000 11:05:31 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19062;
	Fri, 21 Jan 2000 11:03:48 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19029
	for <enum@optimus.ietf.org>; Fri, 21 Jan 2000 11:03:46 -0500 (EST)
Received: from nix.swip.net (nix.swip.net [192.71.220.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12536
	for <enum@ietf.org>; Fri, 21 Jan 2000 11:04:55 -0500 (EST)
Received: from 192.168.124.51 (workstation1.swip.net [130.244.254.1]) 
          by nix.swip.net (8.8.8/8.8.8) with ESMTP 
          id RAA15701; 
          Fri, 21 Jan 2000 17:02:39 +0100 (MET)
Date: Fri, 21 Jan 2000 17:02:36 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@swip.net>
To: Giuseppe Ricagni <giuseppe.ricagni@italtel.it>
cc: "Manfredi, Albert E" <Albert.Manfredi@phl.boeing.com>, enum@ietf.org
Subject: Re: [Enum] New DNS record class values?
Message-ID: <8012357.3157462956@[192.168.124.51]>
In-Reply-To: <38887E79.24D1B239@italtel.it>
X-Mailer: Mulberry (MacOS) [2.0.0b7, s/n U-301169]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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

--On 2000-01-21 16.42 +0100, Giuseppe Ricagni <giuseppe.ricagni@italtel.it>
wrote:

> The only thing I am sure of is that I kept getting hits on my old web
> server for at least four days when I  changed the IP address associated
> to my domain name. This happened in June 1999.

You might have hit two different problems here, and which it is in this
case I can not tell given your information:

(1) You have your own domainname, and moved the domain by contacting the
registry for the parent domain of yours, and the holder of _that_ DNS
didn't update his DNS, or did have misconfigured things in his DNS

(2) You have changed the A record in your DNS server for the web server,
but you have not correct TTL's -- misconfigured slave servers etc

Things have been relative fine regarding DNS updates since version 8 of
bind came out, which I guess was some 3 years ago.

I.e. I don't think the problems of yours was the DNS server itself, but
configuration issues. If you tell me the domainname in question, and the
name of the A-record you changed, I can have a look.

   paf




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


From enum-admin@ietf.org  Fri Jan 21 11: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 LAA13172
	for <enum-archive@ietf.org>; Fri, 21 Jan 2000 11:25:08 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19492;
	Fri, 21 Jan 2000 11:23:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19463
	for <enum@optimus.ietf.org>; Fri, 21 Jan 2000 11:23:10 -0500 (EST)
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 LAA13157
	for <enum@ietf.org>; Fri, 21 Jan 2000 11:24:21 -0500 (EST)
Received: from seascape.research.telcordia.com (pptpdhcp25 [192.4.9.250])
	by thumper.research.telcordia.com (8.9.3/8.9.3) with SMTP id LAA10432;
	Fri, 21 Jan 2000 11:22:23 -0500 (EST)
Message-Id: <4.1.20000121104638.009b35b0@mailee.research.telcordia.com>
X-Sender: huitema@mailee.research.telcordia.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 21 Jan 2000 11:17:44 -0500
To: "Rosen, Brian" <brosen@fore.com>, "David P. Peek" <peek@bit-net.com>,
        enum@ietf.org
From: Christian Huitema <huitema@research.telcordia.com>
Subject: RE: [Enum] New DNS record class values?
In-Reply-To: <4FBEA8857476D311A03300204840E1CF1A0ADC@whq-msgusr-02.fore.
 com>
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 think that Brian hits the nail on the head, and outlines the fundamental
problem with using phone numbers as DNS keys: you have to be able to tell
to whom the number belongs, so you can determine who has authority on the
record. This authority can vary depending on the way you look at it.
Candidates are:

1) The local provider of the phone service for that number. Looks
legitimate, but then it conflicts with the possibility to change providers
(local number portability) or, in the future, the possibility to be
multi-homed through several providers.

2) The owner of the phone. Again, this looks legitimate, but in many cases
you don't really own a phone number. You merely lease it, and you loose it
when you move to another city, or if you stop paying your bills.

3) A third party, such as the local authority in charge of regulation of
the telephone service. This type of authority varies with the locale, with
the government regime, etc.

A natural way to solve the problem is to provide a layer of indirection.
(Isn't that computer's science true and only tool?) In the case of the DNS,
the layer of indirection is the "Non-Terminal DNS Name Redirection"
mechanism described in RFC 2672 (Proposed Standard.) Using that mechanism,
a local telephone company could have the authority over a name such as:
	1.2.3.4.5.6.7.8.9.0.1.example.net
but it would at that point place a DNAME record refering further searches
to the owner's domain. For example, if the DNAME is defined as:
	1.2.3.4.5.6.7.8.9.0.1.example.net IN DNAME myphone.brian.brian-s-domain.net
the DNS request for:
	fax.tcp.1.2.3.4.5.6.7.8.9.0.1.example.net IN SRV
would return the value of:
	fax.tcp.myphone.brian.brian-s-domain.net  IN SRV
that was specified by Brian.

Defining that we will use this procedure is quite powerful. It allows us to
solve monopoly issues (there can be several numbering trees pointing to the
same subtree), multi-homing issues, delegation issues (If I trus my phone
company, I start with its tree). 
	
-- Christian Huitema

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


From enum-admin@ietf.org  Fri Jan 21 11: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 LAA13435
	for <enum-archive@ietf.org>; Fri, 21 Jan 2000 11:40:20 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19899;
	Fri, 21 Jan 2000 11:36:37 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19868
	for <enum@optimus.ietf.org>; Fri, 21 Jan 2000 11:36:35 -0500 (EST)
Received: from mex.italtel.it (mex.italtel.it [138.132.117.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13415
	for <enum@ietf.org>; Fri, 21 Jan 2000 11:37:44 -0500 (EST)
Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id RAA28471
Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP
 id RAA00862
Received: from ic8u32.settimo.italtel.it (ic8u32.settimo.italtel.it [138.132.1.1])
	by mix.italtel.it (8.9.3/8.9.3) with SMTP id RAA17318;
	Fri, 21 Jan 2000 17:35:27 +0100 (MET)
Received: by ic8u32.settimo.italtel.it id AA14158; Fri, 21 Jan 2000 17:52:55 +0100
Received: from ic1daj.settimo.italtel.it by ilt9h01.settimo.italtel.it with SMTP
	(1.38.193.5/16.2) id AA02110; Fri, 21 Jan 2000 17:29:44 +0100
Message-Id: <38888A49.160D1F32@italtel.it>
Date: Fri, 21 Jan 2000 17:33:14 +0100
From: Giuseppe Ricagni <giuseppe.ricagni@italtel.it>
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
Mime-Version: 1.0
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@swip.net>
Cc: enum@ietf.org
Subject: Re: [Enum] New DNS record class values?
References: <8012357.3157462956@[192.168.124.51]>
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 Fdltstrvm wrote:

> --On 2000-01-21 16.42 +0100, Giuseppe Ricagni <giuseppe.ricagni@italtel.it>
> wrote:
>
> > The only thing I am sure of is that I kept getting hits on my old web
> > server for at least four days when I  changed the IP address associated
> > to my domain name. This happened in June 1999.
>
> You might have hit two different problems here, and which it is in this
> case I can not tell given your information:
>
> (1) You have your own domainname, and moved the domain by contacting the
> registry for the parent domain of yours, and the holder of _that_ DNS
> didn't update his DNS, or did have misconfigured things in his DNS
>

Not possible: I was getting hits on BOTH addresses: the new one and the old
one.
I don' t even believe in misconfiguration: I think they know what they are
doing at nic.it.

My much simpler explanation is the same one that Bill provided:

        Based on the size and frequency of the update, patrick is correct,
        syncronization occurs in seconds.  However, the historical methods
        involve manual, out-of-band coordination with the parents and children
        of a zone. So it may take you four weeks to contact me and for me
        to update the data on my servers.

That is to say: in theory you might be right, but if we use the word "Internet"
to mean the "Big Internet", there is a legacy of "historical methods" that will
take years to disappear.

To summarize, in the "Big Internet" as it is today, it still takes days before
all the DNS servers in the world sync, and we don' t really know whn this is
really going to change.

Giuseppe

BTW...

> If you tell me the domainname in question, and the
> name of the A-record you changed, I can have a look.

....it was my personal domain name (ricagni.it), but I think it's better if we
take this off-line !

--
----------------------------------------------------------
Giuseppe RICAGNI
System Architecture and Product Planning
Broadband Networks
Italtel
via Reiss Romoli - C10
20019 Castelletto di Settimo Milanese (MILANO)
ITALY

mailto:giuseppe.ricagni@italtel.it
----------------------------------------------------------



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


From enum-admin@ietf.org  Sun Jan 23 09:20: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 JAA09218
	for <enum-archive@ietf.org>; Sun, 23 Jan 2000 09:20:57 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23245;
	Sun, 23 Jan 2000 09:18:46 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23216
	for <enum@optimus.ietf.org>; Sun, 23 Jan 2000 09:18:44 -0500 (EST)
Received: from nix.swip.net (nix.swip.net [192.71.220.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09184
	for <enum@ietf.org>; Sun, 23 Jan 2000 09:19:58 -0500 (EST)
Received: from 192.168.111.25 (workstation1.swip.net [130.244.254.1]) 
          by nix.swip.net (8.8.8/8.8.8) with ESMTP 
          id PAA05576; 
          Sun, 23 Jan 2000 15:17:43 +0100 (MET)
Date: Sun, 23 Jan 2000 15:17:38 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@swip.net>
To: Giuseppe Ricagni <giuseppe.ricagni@italtel.it>
cc: enum@ietf.org
Subject: Re: [Enum] New DNS record class values?
Message-ID: <263224.3157629458@[192.168.111.25]>
In-Reply-To: <38888A49.160D1F32@italtel.it>
X-Mailer: Mulberry (MacOS) [2.0.0b7, s/n U-301169]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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

--On 2000-01-21 17.33 +0100, Giuseppe Ricagni <giuseppe.ricagni@italtel.it>
wrote:

> To summarize, in the "Big Internet" as it is today, it still takes days
> before all the DNS servers in the world sync, and we don' t really know
> whn this is really going to change.

You have still not told me _what_ you wanted to change. It is not clear if
you are refering to a problematic manual re-delegation of a zone, or if it
is an update of a record in your zone.

What I claim is that the latter nowadays do work and the zones and records
will be updated within seconds. What Bill talks about is the former, the
manual process regarding updates of delegation points of zones, and the
manual processes which too far often lead to lame delegation.

What we talk about in the ENUM group is the changes in one zone, which does
not involve any manual work at all, given that the primary zone server is
updated correctly (serial number is changed in the SOA etc). Not the
problem Bill talks about.

   Patrik


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


From enum-admin@ietf.org  Mon Jan 24 17:15: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 RAA26926
	for <enum-archive@ietf.org>; Mon, 24 Jan 2000 17:15:06 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27622;
	Mon, 24 Jan 2000 17:12:10 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27593
	for <enum@optimus.ietf.org>; Mon, 24 Jan 2000 17:12:09 -0500 (EST)
Received: from fep13-svc.tin.it (mta13-acc.tin.it [212.216.176.44])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26867
	for <enum@ietf.org>; Mon, 24 Jan 2000 17:13:19 -0500 (EST)
Received: from italtel.it ([212.216.18.100]) by fep13-svc.tin.it
          (InterMail vM.4.01.02.00 201-229-116) with ESMTP
          id <20000124221244.SRSX10000.fep13-svc.tin.it@italtel.it>;
          Mon, 24 Jan 2000 23:12:44 +0100
Message-ID: <388CCEC5.39496EDB@italtel.it>
Date: Mon, 24 Jan 2000 23:14:29 +0100
From: Giuseppe Ricagni <giuseppe.ricagni@italtel.it>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@swip.net>
CC: enum@ietf.org
Subject: Re: [Enum] New DNS record class values?
References: <263224.3157629458@[192.168.111.25]>
Content-Type: multipart/mixed;
 boundary="------------5089D88450CB377FFB29E51E"
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.
--------------5089D88450CB377FFB29E51E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------5089D88450CB377FFB29E51E
Content-Type: text/html; charset=us-ascii;
 name="msgdns.htm"
Content-Disposition: inline;
 filename="msgdns.htm"
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="GENERATOR" content="Mozilla/4.51 [en] (WinNT; I) [Netscape]">
</head>
<body>
I suggested to take it off-line, but....
<p>Patrik F&auml;ltstr&ouml;m wrote:
<blockquote TYPE=CITE>--On 2000-01-21 17.33 +0100, Giuseppe Ricagni &lt;giuseppe.ricagni@italtel.it>
<br>wrote:
<p>> To summarize, in the "Big Internet" as it is today, it still takes
days
<br>> before all the DNS servers in the world sync, and we don' t really
know
<br>> whn this is really going to change.
<p>You have still not told me _what_ you wanted to change. It is not clear
if
<br>you are refering to a problematic manual re-delegation of a zone, or
if it
<br>is an update of a record in your zone.
<p>What I claim is that the latter nowadays do work and the zones and records
<br>will be updated within seconds. What Bill talks about is the former,
the
<br>manual process regarding updates of delegation points of zones, and
the
<br>manual processes which too far often lead to lame delegation.
<br>&nbsp;</blockquote>
you are right, I was re-delegating a zone, which might&nbsp; be not the
same thing we need to do in ENUM.
<p>Nevertheless, today, the TTL of the record we've been discussing about
is 2 days. It seems to me this is a fairly common value in the nowadays
Internet. (RFC 1034: While short TTLs can be used to minimize caching,
and a zero TTL prohibits caching, the realities of Internet performance
suggest that these times should be on the order of days for the typical
host)
<p>That means that I still need 2 days to be sure all the resolutions of
the domain go to the new IP, should I decide to change IP.
<p>My question now are:
<br>&nbsp;
<ul>
<li>
can anybody point us to any paper/BCP RFC/document of any kind reporting
an analysis in term of performance requirements on the authoritative DNS
servers and on other "bottleneck" DNS servers in the Big Internet adopting
TTLs in the order of a few seconds, for a number of records comparable
to the Enum users (1E5, 1E7, more ?)</li>
</ul>

<ul>
<li>
can anybody point us to any paper/BCP RFC/document of any kind reporting
an analysis in term of traffic in the Big Internet adopting TTLs in the
order of a few seconds, for a number of records comparable to the Enum
users</li>
</ul>

<ul>
<li>
What RFC are you referring to when you claim we can "Have the primary server
sending notifications to secondaries when the zone is updated".</li>
</ul>

<ul>
<li>
Has anybody any idea of the percentage of DNS servers in the Internet that
comply with such RFC ?</li>
</ul>

<p><br>Then, if we recognize that, given the number of Enum users,&nbsp;
performance is not an issue, I will be the first one to be interested in
DNS-based mobility applications.
<br>&nbsp;
<p>Best Regards
<br>Giuseppe Ricagni
<br>&nbsp;
<br>&nbsp;
<p>----------------------------------------------------------
<br>Giuseppe RICAGNI
<br>System Architecture and Product Planning
<br>Broadband Networks
<br>Italtel
<br>via Reiss Romoli - C10
<br>20019 Castelletto di Settimo Milanese (MILANO)
<br>ITALY
<p><a href="mailto:giuseppe.ricagni@italtel.it">mailto:giuseppe.ricagni@italtel.it</a>
<br>----------------------------------------------------------
<br>&nbsp;
<br>&nbsp;
</body>
</html>

--------------5089D88450CB377FFB29E51E--



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


From enum-admin@ietf.org  Tue Jan 25 00:51: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 AAA07093
	for <enum-archive@ietf.org>; Tue, 25 Jan 2000 00:51:02 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12493;
	Tue, 25 Jan 2000 00:49:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12461
	for <enum@optimus.ietf.org>; Tue, 25 Jan 2000 00:49:11 -0500 (EST)
Received: from nix.swip.net (nix.swip.net [192.71.220.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07078
	for <enum@ietf.org>; Tue, 25 Jan 2000 00:50:27 -0500 (EST)
Received: from 192.168.110.6 (workstation1.swip.net [130.244.254.1]) 
          by nix.swip.net (8.8.8/8.8.8) with ESMTP 
          id GAA07171; 
          Tue, 25 Jan 2000 06:47:58 +0100 (MET)
Date: Tue, 25 Jan 2000 06:46:20 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@swip.net>
To: Giuseppe Ricagni <giuseppe.ricagni@italtel.it>
cc: enum@ietf.org
Subject: Re: [Enum] New DNS record class values?
Message-ID: <794091.3157771580@localhost>
In-Reply-To: <388CCEC5.39496EDB@italtel.it>
X-Mailer: Mulberry (MacOS) [2.0.0b7, s/n U-301169]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA12462
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 2000-01-24 23.14 +0100, Giuseppe Ricagni <giuseppe.ricagni@italtel.it>
wrote:

> I suggested to take it off-line, but.... 

Yes, but it is important to discuss some of these things so we all
understand where the bottlenecks are. As Bill said, there are some
bottlenecks! There are other places which are not bottlenecks.

> you are right, I was re-delegating a zone, which might  be not the same
> thing we need to do in ENUM. 

I think not. I might be wrong, but we need to, as there is a manual process
regarding changing zone delegations, be careful when designing this thing
so we don't force people into manual handshaking when doing day-to-day
operations.

> Nevertheless, today, the TTL of the record we've been discussing about is
> 2 days. It seems to me this is a fairly common value in the nowadays
> Internet. (RFC 1034: While short TTLs can be used to minimize caching,
> and a zero TTL prohibits caching, the realities of Internet performance
> suggest that these times should be on the order of days for the typical
> host) 
> 
> That means that I still need 2 days to be sure all the resolutions of the
> domain go to the new IP, should I decide to change IP. 

You should set a TTL which is say 2 minutes. If then both the primary and
secondary servers support RFC 1996, the zone will be updated and kept up to
date between the servers within seconds of the change in the primary
server. The only issue then is the 2 minute caching in the client issue. I
claim that this value _nowadays_ can be very low, but still not zero.

> My question now are: 
>   
>   ˇ can anybody point us to any paper/BCP RFC/document of any kind
>   reporting an analysis in term of performance requirements on the
>   authoritative DNS servers and on other "bottleneck" DNS servers in the
>   Big Internet adopting TTLs in the order of a few seconds, for a number
>   of records comparable to the Enum users (1E5, 1E7, more ?) 

No. I have tried to get some people working on this issue, but have not
found anyone being able to _really_ looking at the problem. Note that we
only talk about the records at the leaves of the DNS tree, and I claim that
the individual records which are stored there had a time before which was
about 3 hours. I further claim that the same entity do not often call the
same party (use the same E.164 number) two times or more within that time
period. Because of that, it doesn't matter if the TTL is 3 hours or 2
minutes. One will still very seldom reuse the cached value.

The _real_ gain regarding updates in DNS is the syncronization between
primary and secondaries, and before NOTIFY (RFC 1996) one had to have a
very short refresh value, which increased the load on the primary server.
Now, the primary server will push information to the secondary, and
together with  RFC 1995, incremental zone transfer, the servers are kept in
sync in a very efficient and bandwidth-saving way.
 
>   ˇ can anybody point us to any paper/BCP RFC/document of any kind
>   reporting an analysis in term of traffic in the Big Internet adopting
>   TTLs in the order of a few seconds, for a number of records comparable
>   to the Enum users 

See above. No, but I guess that TTLs which are short will not change the
number of lookups. The query have to go to an authoritative source anyways.
So, in calculations we do (if someone starts) have to work on the
assumption that queries have to be done to the authoritative source, where
the TTL for intermediate nodes (NS records) are long, but TTLs on leaf
nodes are short.

>   ˇ What RFC are you referring to when you claim we can "Have the primary
>   server sending notifications to secondaries when the zone is updated". 

RFC 1996, and then 1995 for incremental updates.

>   ˇ Has anybody any idea of the percentage of DNS servers in the Internet
>   that comply with such RFC ? 

I know that Bind do, since a number of versions back. I don't have the bind
history in front of me, but it was implemented quite soon after the RFCs
was published, if not before even. The RFCs are dated august 1996.

> Then, if we recognize that, given the number of Enum users,  performance
> is not an issue, I will be the first one to be interested in DNS-based
> mobility applications. 

Well, note that I am talking about having a TTL of a minute or so, and that
secondaries and masters are only kept in sync within seconds. That means
that you still have an interval where one do not have correct information
on the net after an update. The interval is though nowadays 1 minute or so,
and not several hours (or days). In many applications 1 minute out of sync
is bad, really bad, but in others it is fairly ok. So, for general
redirection service, I think this is a service level which is kind of ok,
but serious IN systems still have to be updated simoultanously, and I would
implement that by having the DNS always point to the IN system, which in
turn gives back a good response.

Conclusion, DNS is better than what many people belive, but it is not 100%
correct. Minute-delay happens, but not much more.

   Patrik


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