From mailman-owner@ietf.org Tue Feb 1 05:16:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10093 for ; Tue, 1 Feb 2000 05:16: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 FAA26931 for ; Tue, 1 Feb 2000 05:14:59 -0500 (EST) Date: Tue, 1 Feb 2000 05:14:59 -0500 (EST) From: mailman-owner@ietf.org Message-Id: <200002011014.FAA26931@optimus.ietf.org> Subject: ietf.org mailing list memberships reminder To: enum-web-archive@optimus.ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, enum-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for enum-web-archive@www.ietf.org: List Password // URL ---- -------- enum@ietf.org vYyt http://www.ietf.org/mailman/options/enum/enum-web-archive@www.ietf.org From enum-admin@ietf.org Tue Feb 1 06:43:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11418 for ; Tue, 1 Feb 2000 06:43: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 GAA05175; Tue, 1 Feb 2000 06:39:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05148 for ; Tue, 1 Feb 2000 06:39:49 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11249; Tue, 1 Feb 2000 06:41:10 -0500 (EST) Message-Id: <200002011141.GAA11249@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-e164-dns@imc.org, enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 01 Feb 2000 06:41:10 -0500 Subject: [Enum] I-D ACTION:draft-faltstrom-e164-05.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : E.164 number and DNS Author(s) : P. Faltstrom Filename : draft-faltstrom-e164-05.txt Pages : 12 Date : 31-Jan-00 This document discusses the use of DNS for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. Routing of the actual connection using the service selected using these methods is not discussed. Discussion on this Internet-Draft is to be held on the mailing list ietf-e164-dns@imc.org, which is hosted by the Internet Mail Consortium. To subscribe, send an email to ietf-e164-dns-request@imc.org, with the text 'subscribe' as the only word in the body of the mail. There is an archive of the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-faltstrom-e164-05.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-faltstrom-e164-05.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-faltstrom-e164-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000131133922.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-faltstrom-e164-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-faltstrom-e164-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000131133922.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Feb 1 17:01: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 RAA06461 for ; Tue, 1 Feb 2000 17:01: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 QAA24897; Tue, 1 Feb 2000 16:59:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24870 for ; Tue, 1 Feb 2000 16:59:27 -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 RAA06356 for ; Tue, 1 Feb 2000 17:00:46 -0500 (EST) Received: by dnspri.npac.com; id QAA20574; Tue, 1 Feb 2000 16:00:45 -0600 (CST) Received: from nodnsquery(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma020497; Tue, 1 Feb 00 15:59:49 -0600 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Tue, 1 Feb 2000 15:55:28 -0600 Message-ID: From: James Yu To: "'paf@swip.net'" Cc: "'enum@ietf.org'" Date: Tue, 1 Feb 2000 15:52:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] draft-faltstrom-e164-05.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Patrik, Just a quick comment on the example in Appendix A. The call is originated from a PSTN/SCN phone, then suddenly an SCP looks up the NAPTR record. More detail steps would be helpful for the real world situation, although I know that this document does not intend to address those details. You removed the two diagrams sowing the SSP/STP/SCP/IN-Database and SSP/STP/SCP/DNS so the another term other than "SCP" may be better. 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 Wed Feb 2 10:43: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 KAA12947 for ; Wed, 2 Feb 2000 10:43: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 KAA06987; Wed, 2 Feb 2000 10:39:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06955 for ; Wed, 2 Feb 2000 10:39:12 -0500 (EST) Received: from mail1.itu.int (mail1.itu.ch [156.106.192.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12892 for ; Wed, 2 Feb 2000 10:40:34 -0500 (EST) Received: by mail1.itu.ch with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Feb 2000 16:41:18 +0100 Message-ID: From: "Shaw, Robert" To: "'enum@ietf.org'" Date: Wed, 2 Feb 2000 16:40:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] IP-Telecoms Interworking Workshop 25-27 January 2000 at ITU Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Material, PowerPoint presentations, and results are at http://www.itu.int/ITU-T/ip-telecoms/ip-telecoms.htm bob -- Robert Shaw ITU Internet Strategy and Policy Advisor International Telecommunication Union Place des Nations, 1211 Geneva, Switzerland _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Feb 2 12:56: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 MAA16852 for ; Wed, 2 Feb 2000 12:56:34 -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 MAA11481; Wed, 2 Feb 2000 12:53: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 MAA11450 for ; Wed, 2 Feb 2000 12:53:29 -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 MAA16809 for ; Wed, 2 Feb 2000 12:54:52 -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 JAA16803 for ; Wed, 2 Feb 2000 09:54:26 -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 JAA05949 for ; Wed, 2 Feb 2000 09:54:47 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Wed, 2 Feb 2000 09:54:23 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Wed, 2 Feb 2000 12:54:22 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDC8@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'enum@ietf.org'" Cc: "'p.hicks@trl.telstra.com.au'" Subject: RE: [Enum] IP-Telecoms Interworking Workshop 25-27 January 2000 at ITU Date: Wed, 2 Feb 2000 12:54:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Shaw, Robert [mailto:Robert.Shaw@itu.int] wrote: > Material, PowerPoint presentations, and results are at > http://www.itu.int/ITU-T/ip-telecoms/ip-telecoms.htm The very interesting "Interworking Between Public Data Networks and the Internet" presentation by Peter Hicks I think lays out the whole problem that enum has to work to support (not solve per se, but support other efforts that will solve this generic interworking problem). I suggest that what the above presentation is asking for is precisely the opposite (photographic negative) of the Next Hop Resolution Protocol (RFC 2332). NHRP assumes the end user can be any old IP host, connected even to a standard Ethernet/IP net, and that an intervening ATM network can either carry the IP datagrams part way to the final destination, or perhaps the final destination is an IP over ATM host. Peter Hicks' problem is to have a telephone call over the Public Data Network (PDN), say ATM or FR, perhaps travel to the destination over an IP network, and (I suggest) the end station may or may _not_ be an IP host. It should not be mandatory that the destination be IP for the call to be carried over an IP net -- perhaps only part way between source and destination. How does NHRP solve the reverse problem? By supporting a network of VCs between ATM switches which are also IP routers. The ingress switch, when it sees the first IP packet arrive, uses the IP destination address to find an efficient IP route across the ATM net, using standard IP routing. Then, when the closest ATM switch to the final IP destination is reached (which might not be connected to the destination host), this final ATM switch sends back an NHRP reply to the ingress switch, with its (the egress switch's) ATM address. Now the ingress ATM switch establishes a direct ATM SVC to this ATM switch closest to the IP destination. The data packets are then sent on this direct path SVC. Where alternate routes are possible, the route which directly supports the longest IP prefix toward the destination IP address is used. Note that NHRP does not mandate that the final destination be ATM-connected. ATM can just be an island net between source and destination hosts. But _if_ the destination were ATM-connected, with an ATM address (AESA), and _if_ the DNS could directly respond with such an address when queried by the ingress ATM switch, then some of this NHRP process could be eliminated. The direct SVC could be established more quickly. The inverse could be done here. The PDN signaling message is intercepted by an E.164-aware IP router at the ingress of the IP net. Assuming enum is a fact, the ingress router queries DNS to see if the destination E.164 number has an IP address as well. If it does, then all PDN PDUs are encapsulated in UDP/IP packets and sent to that destination, presumably with some preparatory "signaling" packets to indicate that a streaming audio session is about to begin. This can all be best effort or diffserv, or maybe the PDN signaling message can be used to initiate an RSVP PATH/RESV transaction somehow. But I don't think we should obsess over RSVP. The presumption here is that a connectionless method, best effort or diffserv, will suffice to provide the QoS needed. If the DNS enum does _not_ provide an IP address for that E.164 destination, the the IP network maintains a routing table of E.164 (hierarchical) numbers and best IP egress router for that number (the opposite of the network of VCs between IP routers in the ATM case). The PDN PDUs are sent through the IP network, and the egress E.164-aware router has the task of generating the PDN signaling sequence to the destination PDN host, and forwarding the PDUs on this circuit. The role enum is pretty limited with respect to the whole problem, but I think the DNS can fairly easily support this useful role. Also, if the calling party on the PDN has strict QoS requirements in his SETUP message, it is perfectly fair to bypass the IP network entirely _if_ the IP ingress router deems the QoS requirement to be beyond what it can handle. Bert albert.e.manfredi@boeing.com _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Feb 2 15:00: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 PAA19770 for ; Wed, 2 Feb 2000 15:00:36 -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 OAA15818; Wed, 2 Feb 2000 14:58: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 OAA15785 for ; Wed, 2 Feb 2000 14:58:38 -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 PAA19743 for ; Wed, 2 Feb 2000 15:00:01 -0500 (EST) Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQiarv24600; Wed, 2 Feb 2000 19:59:59 GMT Message-ID: <38988D5E.9DD5EA90@dynamicsoft.com> Date: Wed, 02 Feb 2000 15:02:38 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: "'enum@ietf.org'" , "'p.hicks@trl.telstra.com.au'" Subject: Re: [Enum] IP-Telecoms Interworking Workshop 25-27 January 2000 at ITU References: <4102273CEB77D211869200805FE6F59356EDC8@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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit "Manfredi, Albert E" wrote: > > > The inverse could be done here. The PDN signaling message is intercepted by > an E.164-aware IP router at the ingress of the IP net. Assuming enum is a > fact, the ingress router queries DNS to see if the destination E.164 number > has an IP address as well. If it does, then all PDN PDUs are encapsulated in > UDP/IP packets and sent to that destination, presumably with some > preparatory "signaling" packets to indicate that a streaming audio session > is about to begin. This can all be best effort or diffserv, or maybe the PDN > signaling message can be used to initiate an RSVP PATH/RESV transaction > somehow. But I don't think we should obsess over RSVP. The presumption here > is that a connectionless method, best effort or diffserv, will suffice to > provide the QoS needed. I do not agree here, for two reasons. First, I think you are a layer below where we need to be. The e.164 resolution process is not for some kind of layer 3 routing function, as you imply. It is for applications. Thats why enum returns a URI, not an IP address. Secondly, the function you are seeking here is more of a routing function; I know that I need to get to some PSTN terminal with some e.164 number, and I need a gateway to get there. This is handled by TRIP, not enum. Furthermore, corrupting the IP routing infrastructure with E.164 addresses, as you suggest (I think) below, is a sure way to crash the Internet. No thanks. We debated that on the iptel list and is was unanimously rejected. > > If the DNS enum does _not_ provide an IP address for that E.164 destination, > the the IP network maintains a routing table of E.164 (hierarchical) numbers > and best IP egress router for that number (the opposite of the network of > VCs between IP routers in the ATM case). The PDN PDUs are sent through the > IP network, and the egress E.164-aware router has the task of generating the > PDN signaling sequence to the destination PDN host, and forwarding the PDUs > on this circuit. -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 Thu Feb 3 04:28: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 EAA12553 for ; Thu, 3 Feb 2000 04:28: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 EAA16785; Thu, 3 Feb 2000 04:22: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 EAA16751 for ; Thu, 3 Feb 2000 04:22:37 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12544 for ; Thu, 3 Feb 2000 04:23:58 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id LAA21730; Thu, 3 Feb 2000 11:23:24 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (esebh03nok.ntc.nokia.com [131.228.118.244]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id LAA07955; Thu, 3 Feb 2000 11:23:18 +0200 (EET) Received: by esebh03nok with Internet Mail Service (5.5.2650.10) id ; Thu, 3 Feb 2000 11:13:51 +0200 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE101486C01@eseis04nok> To: Albert.Manfredi@PHL.Boeing.com, enum@ietf.org Cc: p.hicks@trl.telstra.com.au Subject: RE: [Enum] IP-Telecoms Interworking Workshop 25-27 January 2000 a t ITU Date: Thu, 3 Feb 2000 11:13:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi all, Very interesting discussion. I've joined ENUM, but am most active in the SIGTRAN group. Somme comments & questions. [some text clipped] > The inverse could be done here. The PDN signaling message is > intercepted by an E.164-aware IP router at the ingress of the > IP net. Assuming enum is a fact, the ingress router queries > DNS to see if the destination E.164 number has an IP address > as well. If it does, then all PDN PDUs are encapsulated in > UDP/IP packets and sent to that destination, presumably with some > preparatory "signaling" packets to indicate that a streaming > audio session is about to begin. This can all be best effort > or diffserv, or maybe the PDN signaling message can be used to > initiate an RSVP PATH/RESV transaction somehow. But I don't > think we should obsess over RSVP. The presumption here > is that a connectionless method, best effort or diffserv, > will suffice to provide the QoS needed. > > If the DNS enum does _not_ provide an IP address for that > E.164 destination, the the IP network maintains a routing table > of E.164 (hierarchical) numbers and best IP egress router for > that number (the opposite of the network of VCs between IP routers > in the ATM case). The PDN PDUs are sent through the > IP network, and the egress E.164-aware router has the task of > generating the PDN signaling sequence to the destination PDN > host, and forwarding the PDUs on this circuit. SIGTRAN is defining signaling transport over IP. A new protocol, SCTP, has been developed. SCTP can be thought of as an improved, more robust TCP. Also being specified are adaptation layers to support SS7 signaling (adaptation layers for Q.921, MTP2 and MTP3). I myself, am writing a draft on an SCCP layer. The adaptation layers + SCTP support the transport of the SS7 application layers. For example, an SCCP adaptation layer could carry MAP or CAP signaling over TCAP. In such a scenario, E.164 numbers may be present. I am thinking that the work being done here in ENUM could then be used as a resolve the E.164 number to a IP address. If this is relevant to the discussion at hand, I can supply more comments. I'd also appreciate feedback to my ideas. best regards, John Loughney _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Feb 3 13:43: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 NAA26481 for ; Thu, 3 Feb 2000 13:43: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 NAA07972 for ; Thu, 3 Feb 2000 13:42:05 -0500 (EST) Date: Thu, 3 Feb 2000 13:42:05 -0500 (EST) From: enum-admin@ietf.org Message-Id: <200002031842.NAA07972@optimus.ietf.org> Subject: enum@ietf.org mailing list reminder To: enum-web-archive@optimus.ietf.org Errors-To: enum-admin@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List This is a reminder of how to unsubscribe or change your configuration for the address "enum-web-archive@www.ietf.org" on the mailing list enum. You need to have your password for these things. YOUR enum PASSWORD IS: vYyt To make changes to your subscription, use the password on your options World Wide Web page: http://www.ietf.org/mailman/options/enum/enum-web-archive@www.ietf.org You can also make such changes via email - send a message to: enum-request@ietf.org with the text "help" in the subject or body, and you will be emailed instructions. Questions or comments? Please send them to enum-admin@ietf.org. From enum-admin@ietf.org Fri Feb 4 08:46: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 IAA26285 for ; Fri, 4 Feb 2000 08:46:33 -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 IAA24089; Fri, 4 Feb 2000 08:41:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24060 for ; Fri, 4 Feb 2000 08:41:34 -0500 (EST) Received: from xn1-gw (xn1-b.atlas.fr [194.51.9.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25970; Fri, 4 Feb 2000 08:35:49 -0500 (EST) From: alain.doisneau@art-telecom.fr X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Fri, 4 Feb 2000 14:34:39 +0100 X400-Received: by mta xn1-gw.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Fri, 4 Feb 2000 14:34:39 +0100 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Fri, 4 Feb 2000 14:34:42 +0100 X400-Received: by /PRMD=art-telecom/ADMD=atlas/C=fr/; Relayed; Fri, 4 Feb 2000 14:37:29 +0100 Date: Fri, 4 Feb 2000 14:37:29 +0100 X400-Originator: alain.doisneau@art-telecom.fr X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=art-telecom/ADMD=atlas/C=fr/;<000b01bf6f14$fbdda820$01001200>] Original-Encoded-Information-Types: teletex X400-Content-Type: P2-1988 (22) Content-Identifier: Structure of ... Message-ID: <000b01bf6f14Sfbdda820S01040b8baadu*@MHS> To: enum@ietf.org, itu+ietf@ietf.org Cc: rshockey@ix.netcom.com Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA24061 Subject: [Enum] Structure of DNS entry for ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Dear All, I attended the last ITU+IETF workshop (Geneva 25-27 Jan 2000) and I have still a question regarding the presentation made by R. Shockey. It's about the linkage between E.164 resources and IP names (or addresses here ?) He gave an example : "query for 2.8.0.4.6.2.6.5.8.6.4.e164.int" I understand that "e164.int" might become a new global TLD, but what do mean the digits of the E.164 number as they are i.e separated by a dot and therefore, I suppose, having to point out INDIVIDUALLY to certain IP addresses. In the example, the E.164 number is a number in Sweden, country whose E.164 country code is 46, therefore, "46" has a meaning (i.e. look at the swedish numbering plan, not to another one), but the digits "4" and "6" taken one at a time do not mean anything. Could somebody explain me this issue ? Thank you in advance Alain Doisneau : mailto alain.doisneau@art-telecom.fr _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Feb 4 08:59:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26615 for ; Fri, 4 Feb 2000 08:59:16 -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 IAA24511; Fri, 4 Feb 2000 08:53: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 IAA24484 for ; Fri, 4 Feb 2000 08:53:43 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26225; Fri, 4 Feb 2000 08:44:32 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id IAA03403; Fri, 4 Feb 2000 08:44:22 -0500 (EST) Date: Fri, 4 Feb 2000 08:44:22 -0500 (EST) From: Scott Bradner Message-Id: <200002041344.IAA03403@newdev.harvard.edu> To: alain.doisneau@art-telecom.fr, enum@ietf.org, itu+ietf@ietf.org Cc: rshockey@ix.netcom.com Subject: [Enum] Re: Structure of DNS entry for ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > I understand that "e164.int" might become a new global TLD, in the above ".int" is the TLD, e164 is a second level domain .int is already a existing TLD Scott _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Feb 4 09:22:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27741 for ; Fri, 4 Feb 2000 09:22:10 -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 JAA25450; Fri, 4 Feb 2000 09:19: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 JAA25417 for ; Fri, 4 Feb 2000 09:19:02 -0500 (EST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26819; Fri, 4 Feb 2000 09:02:16 -0500 (EST) Received: from mo3980r1.ems.att.com ([135.38.12.14]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id JAA16161; Fri, 4 Feb 2000 09:01:46 -0500 (EST) Received: from njb140bh1.ems.att.com by mo3980r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id IAA08999; Fri, 4 Feb 2000 08:57:43 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2448.0) id <1H9ZXR8C>; Fri, 4 Feb 2000 09:01:46 -0500 Message-ID: From: "Lind, Steven D, ALARC" To: "'alain.doisneau@art-telecom.fr'" , enum@ietf.org, itu+ietf@ietf.org Cc: rshockey@ix.netcom.com Date: Fri, 4 Feb 2000 09:01:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Subject: [Enum] RE: Structure of DNS entry for ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Cher Alain, I will try to impart my understanding of the issue. What the ENUM group has proposed is to take an E.164 number and convert it into a domain name. As I further understand it, domain names are always parsed "backwards;" that is the most significant piece of information is at the end of the name, e.g., "int" then "e164", etc. That would mean that the E.164 number would be "spelled" backwards since the most significant digit would immediately preceed the "e164.int". The proposal that you illustrate takes the most simplistic approach at converting the number into a domain name, by inserting periods between every digit. One could insert the periods around logical groupings of digits, but that would require additional intelligence within the end systems to do that. They, like most telephone companies in the past, have said let the end systems not worry about digit grouping and let the network servers, in this case DNS, parse the digits and associate "...6.4.e164.int" with a Swedish country code. I hope this helps. Steve Lind --------------------------------------------------------------- Steven D. Lind Tel: (973) 236-6787 AT&T Fax: (973) 236-6452 180 Park Ave., Bldg. 2 e-mail: sdlind@att.com Florham Park, NJ 07932 --------------------------------------------------------------- > -----Original Message----- > From: alain.doisneau@art-telecom.fr [SMTP:alain.doisneau@art-telecom.fr] > Sent: Friday, February 04, 2000 8:37 AM > To: enum@ietf.org; itu+ietf@ietf.org > Cc: rshockey@ix.netcom.com > Subject: Structure of DNS entry for ENUM > > Dear All, > > I attended the last ITU+IETF workshop (Geneva 25-27 Jan 2000) and I have > still a question regarding the presentation made by R. Shockey. > > It's about the linkage between E.164 resources and IP names (or addresses > here ?) > > He gave an example : > "query for 2.8.0.4.6.2.6.5.8.6.4.e164.int" > I understand that "e164.int" might become a new global TLD, but what do > mean > the digits of the E.164 number as they are i.e separated by a dot and > therefore, I suppose, having to point out INDIVIDUALLY to certain IP > addresses. > In the example, the E.164 number is a number in Sweden, country whose > E.164 > country code is 46, therefore, "46" has a meaning (i.e. look at the > swedish > numbering plan, not to another one), but the digits "4" and "6" taken one > at > a time do not mean anything. > > Could somebody explain me this issue ? > > Thank you in advance > > Alain Doisneau : mailto alain.doisneau@art-telecom.fr _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Feb 4 10:05: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 KAA29355 for ; Fri, 4 Feb 2000 10:05: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 KAA29088; Fri, 4 Feb 2000 10:02:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29057 for ; Fri, 4 Feb 2000 10:02:52 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28408; Fri, 4 Feb 2000 09:41:18 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA16853; Fri, 4 Feb 2000 09:41:25 -0500 (EST) Message-Id: <200002041441.JAA16853@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alain.doisneau@art-telecom.fr cc: enum@ietf.org, itu+ietf@ietf.org, rshockey@ix.netcom.com In-reply-to: Your message of "Fri, 04 Feb 2000 14:37:29 +0100." <000b01bf6f14Sfbdda820S01040b8baadu*@MHS> Date: Fri, 04 Feb 2000 09:41:25 -0500 Subject: [Enum] Re: Structure of DNS entry for ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > He gave an example : > "query for 2.8.0.4.6.2.6.5.8.6.4.e164.int" > I understand that "e164.int" might become a new global TLD, but what do mean > the digits of the E.164 number as they are i.e separated by a dot and > therefore, I suppose, having to point out INDIVIDUALLY to certain IP > addresses. it is not necessary that an IP address be assigned for each level in the hierarchy. a query for 2.8.0.4.6.2.6.5.8.6.4.e164.int might produce an IP address, (or more likely, one or more SRV records) if it corresponds to a legitimate phone number. a query for IP addresses or SRV records under 4.e164.int, or 6.4.e164.int, or any of the other prefixes of that phone number, would result in no matching records. (though it might include additional information of the form "if you want to look up DNS names ending with this suffix, consult these DNS servers..." it would not try to return IP addresses or SRV records as if "4" or "46" were valid phone numbers) > In the example, the E.164 number is a number in Sweden, country whose E.164 > country code is 46, therefore, "46" has a meaning (i.e. look at the swedish > numbering plan, not to another one), but the digits "4" and "6" taken one at > a time do not mean anything. presumably "4.e164.int" would be delegated to the same DNS servers as for "e164.int" since there are multiple country prefixes beginning with "4". "6.4.e164.int" would presumably be delegated to the set of DNS servers for the top level of Swedish phone numbers. Keith _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Feb 4 10:16: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 KAA29701 for ; Fri, 4 Feb 2000 10:16: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 KAA29483; Fri, 4 Feb 2000 10:14:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29450 for ; Fri, 4 Feb 2000 10:14:16 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29395; Fri, 4 Feb 2000 10:05:53 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12GkIs-0003u1-00; Fri, 04 Feb 2000 07:05:46 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: alain.doisneau@art-telecom.fr Cc: enum@ietf.org, itu+ietf@ietf.org, rshockey@ix.netcom.com References: <000b01bf6f14Sfbdda820S01040b8baadu*@MHS> Message-Id: Date: Fri, 04 Feb 2000 07:05:46 -0800 Content-Transfer-Encoding: 7bit Subject: [Enum] Re: Structure of DNS entry for ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > I understand that "e164.int" might become a new global TLD, but what do mean > the digits of the E.164 number as they are i.e separated by a dot and > therefore, I suppose, having to point out INDIVIDUALLY to certain IP > addresses. it is the phone number reversed and the dots are added in a way that allows dns delegation at any level in that phone number. e.g. phone number is +1 206 780 0431 look up 1.3.4.0.0.8.7.6.0.2.1.e164.int this allows the dns 'owner' of 6.0.2.1.e164.int (+1 206 all of the seattle area) to delegate 0.8.7.6.0.2.1.e164.int to the server set which just handles +1 206 780, bainbridge island. this is so it distributes well and hence scales well. randy _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Feb 4 11:33:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01916 for ; Fri, 4 Feb 2000 11:33: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 LAA02723; Fri, 4 Feb 2000 11:31: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 LAA02647 for ; Fri, 4 Feb 2000 11:31:33 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01884; Fri, 4 Feb 2000 11:32:56 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12GlfB-0004VN-00; Fri, 04 Feb 2000 08:32:53 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Manfredi, Albert E" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [Enum] Re: Structure of DNS entry for ENUM References: <4102273CEB77D211869200805FE6F59356EDCF@xch-phl-01.he.boeing.com> Message-Id: Date: Fri, 04 Feb 2000 08:32:53 -0800 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > However, it's not clear to me why the fields of the E.164 number which are > clearly delineated, such as country code and city/area code, could not at > least have been kept together, delimited by dots. The long series of dots > seems a bit excessive? because only north americans think country codes and city codes are clearly delineatable in a universal way? randy _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Feb 4 11:37:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02006 for ; Fri, 4 Feb 2000 11:37: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 LAA02941; Fri, 4 Feb 2000 11:35:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02867 for ; Fri, 4 Feb 2000 11:35:13 -0500 (EST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02000; Fri, 4 Feb 2000 11:36:37 -0500 (EST) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA28707; Fri, 4 Feb 2000 10:36:38 -0600 (CST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id KAA06979; Fri, 4 Feb 2000 10:37:09 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 4 Feb 2000 08:36:18 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 11:36:17 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDD0@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Randy Bush'" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 4 Feb 2000 11:36:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Randy Bush [mailto:randy@psg.com] wrote: > > However, it's not clear to me why the fields of the E.164 > number which are > > clearly delineated, such as country code and city/area > code, could not at > > least have been kept together, delimited by dots. The long > series of dots > > seems a bit excessive? > > because only north americans think country codes and city > codes are clearly > delineatable in a universal way? Not so. That's what I tried to point out using the European number example. And if some E.164 number in the future becomes hierarched(??), you can always add in dots. The result will never be ambiguous. 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 Feb 4 11:38:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02061 for ; Fri, 4 Feb 2000 11:38:05 -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 LAA02416; Fri, 4 Feb 2000 11:28:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02358 for ; Fri, 4 Feb 2000 11:28:26 -0500 (EST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01758; Fri, 4 Feb 2000 11:29:49 -0500 (EST) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA23516; Fri, 4 Feb 2000 10:29:50 -0600 (CST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id KAA00244; Fri, 4 Feb 2000 10:30:21 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 4 Feb 2000 08:29:35 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 11:29:34 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDCF@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Randy Bush'" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 4 Feb 2000 11:29:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Randy Bush [mailto:randy@psg.com] wrote: > > I understand that "e164.int" might become a new global TLD, > but what do mean > > the digits of the E.164 number as they are i.e separated by > a dot and > > therefore, I suppose, having to point out INDIVIDUALLY to certain IP > > addresses. > > it is the phone number reversed and the dots are added in a > way that allows > dns delegation at any level in that phone number. e.g. > > phone number is +1 206 780 0431 > > look up 1.3.4.0.0.8.7.6.0.2.1.e164.int > > this allows the dns 'owner' of > > 6.0.2.1.e164.int > > (+1 206 all of the seattle area) to delegate > > 0.8.7.6.0.2.1.e164.int > > to the server set which just handles +1 206 780, bainbridge island. > > this is so it distributes well and hence scales well. True, and the reverse order is used because, as Steven Lind pointed out, the hierarchy in the names is opposite that of the E.164 numbers (and also opposite that of the IP addresses, I might add). However, it's not clear to me why the fields of the E.164 number which are clearly delineated, such as country code and city/area code, could not at least have been kept together, delimited by dots. The long series of dots seems a bit excessive? One might _also_ argue that as long as e164.int is used in the DNS name field, the convention for the stuff up front be in accordance with E.164? I think it would be far clearer, and no tremendous problem, to show +1 206 780 0431 as 1.206.7800431.e164.int, and a euro-style number like 39 06 3295887 as 39.06.3295887.e164.int. I mean, the whole point of DNS names was that they be clear to a human, yes? I still think, though, that using the DNS field for AESAs, peer to the IP address field, would be a useful feature in addition to this naming convention. 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 Feb 4 11:40:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02166 for ; Fri, 4 Feb 2000 11:40: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 LAA03148; Fri, 4 Feb 2000 11:38:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03076 for ; Fri, 4 Feb 2000 11:38:44 -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 LAA02156; Fri, 4 Feb 2000 11:40: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 IAA29144; Fri, 4 Feb 2000 08:39:44 -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 IAA29609; Fri, 4 Feb 2000 08:40:07 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 4 Feb 2000 08:39:56 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 11:39:55 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDD1@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Randy Bush'" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 4 Feb 2000 11:39:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Manfredi, Albert E [mailto:Albert.Manfredi@phl.boeing.com] wrote: > > because only north americans think country codes and city > > codes are clearly > > delineatable in a universal way? > > Not so. That's what I tried to point out using the European > number example. > > And if some E.164 number in the future becomes hierarched(??), you can > always add in dots. The result will never be ambiguous. What I meant was, "And if some E.164 number in the future becomes even _more_ hierarched, ..." Adding dots, as long as the numbers are in consistent order, is no problem at all. 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 Feb 4 11:45:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02344 for ; Fri, 4 Feb 2000 11:45:43 -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 LAA03374; Fri, 4 Feb 2000 11:43: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 LAA03308 for ; Fri, 4 Feb 2000 11:43:55 -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 LAA02326; Fri, 4 Feb 2000 11:45:17 -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 LAA04270; Fri, 4 Feb 2000 11:44:19 -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 LAA00636; Fri, 4 Feb 2000 11:44:22 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id <1JCTTPB7>; Fri, 4 Feb 2000 11:41:06 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF20888E@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "'Manfredi, Albert E'" , "'Randy Bush'" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 4 Feb 2000 11:44:19 -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 X-BeenThere: enum@ietf.org This whole thing starts to fall apart when LNP is introduced. If the EU ever mandated LNP between countries, even that would break down. I guess the issue is: we know that the structure of E.164 is breaking down, we can only speculate how fast it disintegrates. We know that it eventually disintegrates into a data dip on the entire E.164, so should ENUM define something that works for some undefined interim time period or not? If we decide that it should optimize some level of structure, how deep should it go? It seems to me that it is NOT a good idea to have something between 2.1.2.1.5.5.5.2.1.2.1.e164.int and 12125551212.e164.int, because as the structure disintegrates, both mechanisms continue to work, but an intermediate one -- say 5551212.212.1.e164.int -- fails when cross area code LNP is mandated. The problem is that even if the DNS were reorganized, the CLIENTS would have to be reprogrammed, since they have to know to form the query as, say 2125551212.1.e164.int. Not a good plan IMO. Brian > -----Original Message----- > From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] > Sent: Friday, February 04, 2000 11:30 AM > To: 'Randy Bush' > Cc: enum@ietf.org; itu+ietf@ietf.org > Subject: RE: [Enum] Re: Structure of DNS entry for ENUM > > > Randy Bush [mailto:randy@psg.com] wrote: > > > > I understand that "e164.int" might become a new global TLD, > > but what do mean > > > the digits of the E.164 number as they are i.e separated by > > a dot and > > > therefore, I suppose, having to point out INDIVIDUALLY to > certain IP > > > addresses. > > > > it is the phone number reversed and the dots are added in a > > way that allows > > dns delegation at any level in that phone number. e.g. > > > > phone number is +1 206 780 0431 > > > > look up 1.3.4.0.0.8.7.6.0.2.1.e164.int > > > > this allows the dns 'owner' of > > > > 6.0.2.1.e164.int > > > > (+1 206 all of the seattle area) to delegate > > > > 0.8.7.6.0.2.1.e164.int > > > > to the server set which just handles +1 206 780, bainbridge island. > > > > this is so it distributes well and hence scales well. > > True, and the reverse order is used because, as Steven Lind > pointed out, the > hierarchy in the names is opposite that of the E.164 numbers (and also > opposite that of the IP addresses, I might add). > > However, it's not clear to me why the fields of the E.164 > number which are > clearly delineated, such as country code and city/area code, > could not at > least have been kept together, delimited by dots. The long > series of dots > seems a bit excessive? > > One might _also_ argue that as long as e164.int is used in > the DNS name > field, the convention for the stuff up front be in accordance > with E.164? > > I think it would be far clearer, and no tremendous problem, to show > > +1 206 780 0431 > > as 1.206.7800431.e164.int, > > and a euro-style number like > > 39 06 3295887 as > > 39.06.3295887.e164.int. > > I mean, the whole point of DNS names was that they be clear > to a human, yes? > > I still think, though, that using the DNS field for AESAs, > peer to the IP > address field, would be a useful feature in addition to this naming > convention. > > Bert > albert.e.manfredi@boeing.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 Fri Feb 4 11:53:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02562 for ; Fri, 4 Feb 2000 11:53: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 LAA03871; Fri, 4 Feb 2000 11:51:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03794 for ; Fri, 4 Feb 2000 11:51:27 -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 LAA02538; Fri, 4 Feb 2000 11:52:50 -0500 (EST) Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQiayt15777; Fri, 4 Feb 2000 16:52:49 GMT Message-ID: <389B048B.7B4ACD08@dynamicsoft.com> Date: Fri, 04 Feb 2000 11:55:39 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: "'Randy Bush'" , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [Enum] Re: Structure of DNS entry for ENUM References: <4102273CEB77D211869200805FE6F59356EDD0@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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit "Manfredi, Albert E" wrote: > > Randy Bush [mailto:randy@psg.com] wrote: > > > > However, it's not clear to me why the fields of the E.164 > > number which are > > > clearly delineated, such as country code and city/area > > code, could not at > > > least have been kept together, delimited by dots. The long > > series of dots > > > seems a bit excessive? > > > > because only north americans think country codes and city > > codes are clearly > > delineatable in a universal way? > > Not so. That's what I tried to point out using the European number example. > > And if some E.164 number in the future becomes hierarched(??), you can > always add in dots. The result will never be ambiguous. This is unworkable, IMHO. It requires the clients of the system to have knowledge of the numbering plan for every single country. The dot-between-each-digit moves this knowledge into the DNS zone delegations, which is where it belongs. -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 Fri Feb 4 12: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 MAA02838 for ; Fri, 4 Feb 2000 12:02:01 -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 LAA04476; Fri, 4 Feb 2000 11:59: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 LAA04412 for ; Fri, 4 Feb 2000 11:59:55 -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 MAA02785; Fri, 4 Feb 2000 12:01:18 -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 JAA27583; Fri, 4 Feb 2000 09:00:56 -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 JAA20066; Fri, 4 Feb 2000 09:01:13 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 4 Feb 2000 09:01:04 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 12:01:02 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDD2@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Jonathan Rosenberg'" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 4 Feb 2000 12:01:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] wrote: > > And if some E.164 number in the future becomes > > even more hierarched(??), you can > > always add in dots. The result will never be ambiguous. > > This is unworkable, IMHO. It requires the clients of the > system to have > knowledge of the numbering plan for every single country. The > dot-between-each-digit moves this knowledge into the DNS zone > delegations, which is where it belongs. I guess I'm baffled by this statement. Domain names don't have to be all in identical hierarchy. I can have a machine called engr.boeing.com and another one called engr.arl.boeing.com, and no one will bat an eye. Simlarly, I can have a phone number-made-name show up as 1.703.4126735.e164.int and another one 39.06.3295887.e164.int and in some other country's scheme perhaps 123.06.329.528076.e164.int As long as the e.164 number itself is consistent within e.164, the DNS name should never present a problem. 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 Feb 4 12:21:21 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 MAA03571 for ; Fri, 4 Feb 2000 12:21:16 -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 MAA05637; Fri, 4 Feb 2000 12:18: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 MAA05575 for ; Fri, 4 Feb 2000 12:18:52 -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 MAA03519; Fri, 4 Feb 2000 12:20:15 -0500 (EST) Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQiayv17575; Fri, 4 Feb 2000 17:20:15 GMT Message-ID: <389B0AFA.838A1EDB@dynamicsoft.com> Date: Fri, 04 Feb 2000 12:23:06 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: enum@ietf.org, itu+ietf@ietf.org Subject: Re: [Enum] Re: Structure of DNS entry for ENUM References: <4102273CEB77D211869200805FE6F59356EDD2@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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit "Manfredi, Albert E" wrote: > > I guess I'm baffled by this statement. > > Domain names don't have to be all in identical hierarchy. I can have a > machine called engr.boeing.com and another one called engr.arl.boeing.com, > and no one will bat an eye. > > Simlarly, I can have a phone number-made-name show up as > > 1.703.4126735.e164.int > > and another one > > 39.06.3295887.e164.int > > and in some other country's scheme perhaps > > 123.06.329.528076.e164.int > > As long as the e.164 number itself is consistent within e.164, the DNS name > should never present a problem. You are presuming that the form in which the numbers are entered or accessed by users already has these dots. This means that when users enter numbers, they must know the numbering plan of the country for the numbers they enter, or the software must know the numbering plan in order to place the dots into just a digit sequence entered by a user. Both of these are unworkable. End users cannot be expected to have to correctly enter the dots in phone numbers. Today, in the PSTN, I do not need to enter in these separators. When I call Belarus, I enter "375172214841" after the international dial prefix (011). I have NO IDEA what the breakdown of this number is. Having the software do the breakdown is also unworkable. It means the software in a standalone phone would need to be configured with the worlds numbering plans. -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 Fri Feb 4 12:46:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04490 for ; Fri, 4 Feb 2000 12:46:50 -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 MAA06305; Fri, 4 Feb 2000 12:36:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06240 for ; Fri, 4 Feb 2000 12:36:13 -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 MAA04178; Fri, 4 Feb 2000 12:37:36 -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 JAA14639; Fri, 4 Feb 2000 09:37:14 -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 JAA03890; Fri, 4 Feb 2000 09:37:34 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 4 Feb 2000 09:37:02 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 12:37:00 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDD3@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Jonathan Rosenberg'" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 4 Feb 2000 12:36:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] wrote: > You are presuming that the form in which the numbers are entered or > accessed by users already has these dots. This means that when users > enter numbers, they must know the numbering plan of the > country for the > numbers they enter, or the software must know the numbering plan in > order to place the dots into just a digit sequence entered by a user. > Both of these are unworkable. End users cannot be expected to have to > correctly enter the dots in phone numbers. Today, in the > PSTN, I do not > need to enter in these separators. When I call Belarus, I enter > "375172214841" after the international dial prefix (011). I > have NO IDEA > what the breakdown of this number is. Guys, look. Within the e.164 scheme, people have _never_ truly needed to know the hierarchy. It is only there as a mnemonic aid, fundamentally. Which only makes this problem easier, not harder. If I give out my phone number as 1.703.4126735, a client elsewhere can use that hierarchy, but he doesn't _have_ to. He can just dial the digits. So if I write the DNS name as 1.703.4126735.e164.int, ultimately that number will be used by a public phone system. The phone system, when it sees e164.int, knows full well that the dots between the numbers are utterly irrelevant anyway. They are there just as a mnemonic aid. Perhaps it would help if we establish this simple rule within DNS servers: For all names in the e.164.int domain, the dot symbols to the left of "e164" are ignored if used. 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 Feb 4 12:48:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04541 for ; Fri, 4 Feb 2000 12:48:36 -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 MAA06423; Fri, 4 Feb 2000 12:38:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06360 for ; Fri, 4 Feb 2000 12:38:20 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04283; Fri, 4 Feb 2000 12:39:43 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12Gmhq-0004xY-00; Fri, 04 Feb 2000 09:39:42 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Manfredi, Albert E" Cc: "'Jonathan Rosenberg'" , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <4102273CEB77D211869200805FE6F59356EDD3@xch-phl-01.he.boeing.com> Message-Id: Date: Fri, 04 Feb 2000 09:39:42 -0800 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > Perhaps it would help if we establish this simple rule within DNS servers: > > For all names in the e.164.int domain, the dot symbols to the left of "e164" > are ignored if used. ROFL! _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Feb 4 13:00:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04877 for ; Fri, 4 Feb 2000 13:00:04 -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 MAA06860; Fri, 4 Feb 2000 12:55:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06788 for ; Fri, 4 Feb 2000 12:55:02 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04771; Fri, 4 Feb 2000 12:56:27 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12Gmxy-00054M-00; Fri, 04 Feb 2000 09:56:22 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Manfredi, Albert E" , "'Jonathan Rosenberg'" , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <4102273CEB77D211869200805FE6F59356EDD3@xch-phl-01.he.boeing.com> Message-Id: Date: Fri, 04 Feb 2000 09:56:22 -0800 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit >> Perhaps it would help if we establish this simple rule within DNS >> servers: For all names in the e.164.int domain, the dot symbols to the >> left of "e164" are ignored if used. > ROFL! a friend pointed out that i could have been less terse. :-) the first problem is that it would be exceedingly unlikely that dns protocol folk would be at all sympathetic with special hacks for some specific domain as there would soon be 1,000 specific donains that wanted special treatment. but this does not even work for the one domain. it directly implies that the entire domain for all of planet earth is flat and in a single zone file. this is the opposite of 'rational' as used in internet design. randy _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Feb 4 13:09: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 NAA05232 for ; Fri, 4 Feb 2000 13:09: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 NAA07393; Fri, 4 Feb 2000 13:05: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 NAA07324 for ; Fri, 4 Feb 2000 13:05:38 -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 NAA05157; Fri, 4 Feb 2000 13:07:03 -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 KAA25687; Fri, 4 Feb 2000 10:06:39 -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 KAA10481; Fri, 4 Feb 2000 10:07:01 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 4 Feb 2000 10:06:45 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 13:06:43 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDD4@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Randy Bush'" , enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 4 Feb 2000 13:06:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Randy Bush [mailto:randy@psg.com] wrote > a friend pointed out that i could have been less terse. :-) > > the first problem is that it would be exceedingly unlikely > that dns protocol > folk would be at all sympathetic with special hacks for some > specific domain > as there would soon be 1,000 specific donains that wanted > special treatment. > > but this does not even work for the one domain. it directly > implies that > the entire domain for all of planet earth is flat and in a > single zone file. > this is the opposite of 'rational' as used in internet design. Fair enough. The point is, when you dial an international number, you the client in fact know full well that there is a country code (at very least). So _that_ much can be delimeted by a dot without undue hardship. All countries also use a city/area code of some kind. It's not too much to ask to delimit that as well. What I think is truly "unworkable" (a favorite word here) is the current plan, which requires every normal human to write down the phone number on a piece of paper before being able to type it in, in reverse order, with all the dots. Business cards show international phone numbers with some semblance of hierarchy. Country code alone might be enough? 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 Feb 4 13:10: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 NAA05302 for ; Fri, 4 Feb 2000 13:10: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 NAA07548; Fri, 4 Feb 2000 13:08: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 NAA07476 for ; Fri, 4 Feb 2000 13:08:34 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05244; Fri, 4 Feb 2000 13:09:59 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12GnB8-0005AX-00; Fri, 04 Feb 2000 10:09:58 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Manfredi, Albert E" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <4102273CEB77D211869200805FE6F59356EDD4@xch-phl-01.he.boeing.com> Message-Id: Date: Fri, 04 Feb 2000 10:09:58 -0800 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > What I think is truly "unworkable" (a favorite word here) is the current > plan, which requires every normal human to write down the phone number on a > piece of paper before being able to type it in, in reverse order, with all > the dots. nope. as the rule is exceedingly simple, o have full country+city+local number o reverse the order of the digits o put a dot between each one o append .foo.bar clients can do it simply, coded once, and work universally. this same hack has worked for tpc.int for many years. randy _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Feb 4 13:31: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 NAA05783 for ; Fri, 4 Feb 2000 13:31: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 NAA08152; Fri, 4 Feb 2000 13:25: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 NAA08091 for ; Fri, 4 Feb 2000 13:25:35 -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 NAA05635; Fri, 4 Feb 2000 13:26:57 -0500 (EST) Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQiayz25276; Fri, 4 Feb 2000 18:26:52 GMT Message-ID: <389B1A97.A494D861@dynamicsoft.com> Date: Fri, 04 Feb 2000 13:29:43 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: "'Randy Bush'" , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <4102273CEB77D211869200805FE6F59356EDD4@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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit "Manfredi, Albert E" wrote: > > The point is, when you dial an international number, you the client in fact > know full well that there is a country code (at very least). So _that_ much > can be delimeted by a dot without undue hardship. All countries also use a > city/area code of some kind. It's not too much to ask to delimit that as > well. > > What I think is truly "unworkable" (a favorite word here) is the current > plan, which requires every normal human to write down the phone number on a > piece of paper before being able to type it in, in reverse order, with all > the dots. Wrong. The human user doesn't do this unless the UI on your phone/software is really bad. Most likely you'll enter the number, hit return, and the host will perform this translation. As Randy pointed out, its been going on for a while now... -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 Fri Feb 4 13:31:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05787 for ; Fri, 4 Feb 2000 13:31: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 NAA07825; Fri, 4 Feb 2000 13:15:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07757 for ; Fri, 4 Feb 2000 13:15:49 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05432; Fri, 4 Feb 2000 13:17:13 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA17811; Fri, 4 Feb 2000 13:17:21 -0500 (EST) Message-Id: <200002041817.NAA17811@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Manfredi, Albert E" cc: "'Randy Bush'" , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: Your message of "Fri, 04 Feb 2000 13:06:42 EST." <4102273CEB77D211869200805FE6F59356EDD4@xch-phl-01.he.boeing.com> Date: Fri, 04 Feb 2000 13:17:21 -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > The point is, when you dial an international number, you the client in fact > know full well that there is a country code (at very least). no. you don't even know that. you just dial the international prefix followed by the digits that are on someone's business card. or, soon, you click on a tel: URL link and the dialing gets done for you. except for some knowledge of local prefix rules, users don't have to know the structure of phone numbers in order to use them. that's a feature, not a bug. Keith _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Feb 4 13:40: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 NAA06071 for ; Fri, 4 Feb 2000 13:40:29 -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 NAA08547; Fri, 4 Feb 2000 13:33: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 NAA08484 for ; Fri, 4 Feb 2000 13:33:30 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05877; Fri, 4 Feb 2000 13:34:54 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id NAA04767; Fri, 4 Feb 2000 13:34:49 -0500 (EST) Date: Fri, 4 Feb 2000 13:34:49 -0500 (EST) From: Scott Bradner Message-Id: <200002041834.NAA04767@newdev.harvard.edu> To: Albert.Manfredi@PHL.Boeing.com, enum@ietf.org, itu+ietf@ietf.org, randy@psg.com Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > What I think is truly "unworkable" (a favorite word here) is the current > plan, which requires every normal human to write down the phone number on a > piece of paper before being able to type it in, in reverse order, with all > the dots. oh, here is the basic disconnect - the all-them-dots version is what is sent to the DNS it does not have to be what the user types (in fact it would be quite broken if the user had to type any of this) Scott _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Feb 4 15:35: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 PAA09653 for ; Fri, 4 Feb 2000 15:35:13 -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 PAA11645; Fri, 4 Feb 2000 15:33:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11583 for ; Fri, 4 Feb 2000 15:33:25 -0500 (EST) Received: from relay.cwplc.com ([194.6.6.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09627; Fri, 4 Feb 2000 15:34:44 -0500 (EST) Received: from gb-cwc-wtn-msw4 ([148.185.175.64]) by relay.cwplc.com (Pro-8.9.3/8.9.3) with ESMTP id UAA09792; Fri, 4 Feb 2000 20:34:39 GMT Received: from gb-cwc-wtn-i02.isops.mercury.co.uk (unverified) by gb-cwc-wtn-msw4 (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 04 Feb 2000 15:08:51 +0000 Received: by gb-cwc-wtn-io2.isops.cwcom.co.uk with Internet Mail Service (5.5.2650.21) id <12XKV91C>; Fri, 4 Feb 2000 14:58:48 -0000 Message-Id: <29B7C7A8E3E4D111ABDB0000F80864000318FE89@gbcwcbrtm003.isops.cwcom.co.uk> From: "Rosbotham, Paul" To: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [Enum] Structure of DNS entry for ENUM Date: Fri, 4 Feb 2000 15:12:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Alain, My understanding is that it was chosen to use dots between each individual digit in order that the client software does not need to have a detailed knowledge of E.164. For example, if you were to break the number below into administrative "domains", you would have 2804.6265.8.46.e164.int (I think), on the basis that; 46 is country code for Sweden 8 is area code for Stockholm 6265 identifies the exchange (Tele2 I guess) 2804 identifies the line on the exchange. However, to do this you'd need to know that 46 is a 2 digit country code, that area code 8 within Sweden is a 1 digit code etc, which would be far too onerous. On the other hand, if you dot each individual digit of the E.164 number, the client software won't need to know the E.164 structure, and the routeing to the correct server would be handled by DNS, eg the server for .164.int would know that .4.6.e164.int should be sent to a Swedish server, which in turn would know that .8.4.6.e164.int would be handled by a Stockholm server. Hope this clarifies (hope it's correct!) Paul > -----Original Message----- > From: alain.doisneau@art-telecom.fr [SMTP:alain.doisneau@art-telecom.fr] > Sent: Friday, February 04, 2000 1:37 PM > To: enum@ietf.org; itu+ietf@ietf.org > Cc: rshockey@ix.netcom.com > Subject: [Enum] Structure of DNS entry for ENUM > > Dear All, > > I attended the last ITU+IETF workshop (Geneva 25-27 Jan 2000) and I have > still a question regarding the presentation made by R. Shockey. > > It's about the linkage between E.164 resources and IP names (or addresses > here ?) > > He gave an example : > "query for 2.8.0.4.6.2.6.5.8.6.4.e164.int" > I understand that "e164.int" might become a new global TLD, but what do > mean > the digits of the E.164 number as they are i.e separated by a dot and > therefore, I suppose, having to point out INDIVIDUALLY to certain IP > addresses. > In the example, the E.164 number is a number in Sweden, country whose > E.164 > country code is 46, therefore, "46" has a meaning (i.e. look at the > swedish > numbering plan, not to another one), but the digits "4" and "6" taken one > at > a time do not mean anything. > > Could somebody explain me this issue ? > > Thank you in advance > > Alain Doisneau : mailto alain.doisneau@art-telecom.fr > > > _______________________________________________ > 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 Fri Feb 4 17:29:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11896 for ; Fri, 4 Feb 2000 17:29: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 RAA14595; Fri, 4 Feb 2000 17:26: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 RAA14539 for ; Fri, 4 Feb 2000 17:26:55 -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 RAA11876; Fri, 4 Feb 2000 17:28:17 -0500 (EST) Received: by dnspri.npac.com; id QAA07457; Fri, 4 Feb 2000 16:28:16 -0600 (CST) Received: from nodnsquery(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma007385; Fri, 4 Feb 00 16:27:41 -0600 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 16:23:19 -0600 Message-ID: From: Mark Foster To: "Rosen, Brian" , "'Manfredi, Albert E'" , "'Randy Bush'" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 4 Feb 2000 16:19:57 -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 X-BeenThere: enum@ietf.org IMHO, it already has started to disintegrate at the country code level for certain countries. In a few weeks, the FCC is expected to release a number conservation order that will mandate number pooling in the US. This will mean that all new number block assignments to carriers will be made in smaller increments using LNP as the activation means, instead of by unique NPA-NXX level assignments in the LERG. This will dramatically increase the proportion of numbers routed via the LNP database over and above those simply resulting from service provider competition. While the actual zone delegation scheme is presumably out of ENUM scope, I certainly agree with the notion of isolating clients from the details of the structure, as it will certainly evolve. The default option is to make no delegation structure assumptions and always place a dot between every digit. R, Mark ------------------------------------------------------------- Mark D. Foster | EMAIL: mark.foster@neustar.com CTO | NeuStar, Inc. TEL: +1 202 533 2800/2702 | FAX: +1 202 533 2975 1120 Vermont Ave NW, Suite 550 | Washington, DC 20005 -----Original Message----- From: Rosen, Brian [mailto:brosen@fore.com] Sent: Friday, February 04, 2000 11:44 AM To: 'Manfredi, Albert E'; 'Randy Bush' Cc: enum@ietf.org; itu+ietf@ietf.org Subject: RE: [Enum] Re: Structure of DNS entry for ENUM This whole thing starts to fall apart when LNP is introduced. If the EU ever mandated LNP between countries, even that would break down. I guess the issue is: we know that the structure of E.164 is breaking down, we can only speculate how fast it disintegrates. We know that it eventually disintegrates into a data dip on the entire E.164, so should ENUM define something that works for some undefined interim time period or not? If we decide that it should optimize some level of structure, how deep should it go? It seems to me that it is NOT a good idea to have something between 2.1.2.1.5.5.5.2.1.2.1.e164.int and 12125551212.e164.int, because as the structure disintegrates, both mechanisms continue to work, but an intermediate one -- say 5551212.212.1.e164.int -- fails when cross area code LNP is mandated. The problem is that even if the DNS were reorganized, the CLIENTS would have to be reprogrammed, since they have to know to form the query as, say 2125551212.1.e164.int. Not a good plan IMO. Brian > -----Original Message----- > From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] > Sent: Friday, February 04, 2000 11:30 AM > To: 'Randy Bush' > Cc: enum@ietf.org; itu+ietf@ietf.org > Subject: RE: [Enum] Re: Structure of DNS entry for ENUM > > > Randy Bush [mailto:randy@psg.com] wrote: > > > > I understand that "e164.int" might become a new global TLD, > > but what do mean > > > the digits of the E.164 number as they are i.e separated by > > a dot and > > > therefore, I suppose, having to point out INDIVIDUALLY to > certain IP > > > addresses. > > > > it is the phone number reversed and the dots are added in a > > way that allows > > dns delegation at any level in that phone number. e.g. > > > > phone number is +1 206 780 0431 > > > > look up 1.3.4.0.0.8.7.6.0.2.1.e164.int > > > > this allows the dns 'owner' of > > > > 6.0.2.1.e164.int > > > > (+1 206 all of the seattle area) to delegate > > > > 0.8.7.6.0.2.1.e164.int > > > > to the server set which just handles +1 206 780, bainbridge island. > > > > this is so it distributes well and hence scales well. > > True, and the reverse order is used because, as Steven Lind > pointed out, the > hierarchy in the names is opposite that of the E.164 numbers (and also > opposite that of the IP addresses, I might add). > > However, it's not clear to me why the fields of the E.164 > number which are > clearly delineated, such as country code and city/area code, > could not at > least have been kept together, delimited by dots. The long > series of dots > seems a bit excessive? > > One might _also_ argue that as long as e164.int is used in > the DNS name > field, the convention for the stuff up front be in accordance > with E.164? > > I think it would be far clearer, and no tremendous problem, to show > > +1 206 780 0431 > > as 1.206.7800431.e164.int, > > and a euro-style number like > > 39 06 3295887 as > > 39.06.3295887.e164.int. > > I mean, the whole point of DNS names was that they be clear > to a human, yes? > > I still think, though, that using the DNS field for AESAs, > peer to the IP > address field, would be a useful feature in addition to this naming > convention. > > Bert > albert.e.manfredi@boeing.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 _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Feb 4 17:42:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12096 for ; Fri, 4 Feb 2000 17:42:52 -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 RAA14974; Fri, 4 Feb 2000 17:39: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 RAA14916 for ; Fri, 4 Feb 2000 17:39:41 -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 RAA12071; Fri, 4 Feb 2000 17:41:03 -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 OAA03924; Fri, 4 Feb 2000 14:40:41 -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 OAA08536; Fri, 4 Feb 2000 14:41:04 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 4 Feb 2000 14:40:47 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 17:40:46 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDD8@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Mark Foster'" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 4 Feb 2000 17:40:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Mark Foster [mailto:mark.foster@neustar.com] wrote: > While the actual zone delegation scheme is presumably out of > ENUM scope, I > certainly agree with the notion of isolating clients from the > details of the > structure, as it will certainly evolve. The default option > is to make no > delegation structure assumptions and always place a dot > between every digit. But is this strictly true? I mean, is whatever evolution that's about to befall on us going to make individual country codes hierarchical among themselves, for example? I'm asking because I don't know. As things are now, a 4 most significant digit can indicate Sweden, the Czech Republic, or the UK. A 2 can indicate Morocco, Egypt, or Greenland(!?). A 3 can indicate France, the Netherlands, or Italy. So the question is, will the individual-digit hierarchy be meaningful or not in the future? I guess the general consensus is that it will be making more sense, rather than less sense than it already makes? A dot between digits requires each digit to be meaningful hierarchically, yes? 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 Feb 4 18:37:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12838 for ; Fri, 4 Feb 2000 18:37:25 -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 SAA16712; Fri, 4 Feb 2000 18:35:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16640 for ; Fri, 4 Feb 2000 18:35:15 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12807; Fri, 4 Feb 2000 18:36:38 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id SAA18785; Fri, 4 Feb 2000 18:36:47 -0500 (EST) Message-Id: <200002042336.SAA18785@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Manfredi, Albert E" cc: "'Mark Foster'" , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: Your message of "Fri, 04 Feb 2000 17:40:45 EST." <4102273CEB77D211869200805FE6F59356EDD8@xch-phl-01.he.boeing.com> Date: Fri, 04 Feb 2000 18:36:47 -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > So the question is, will the individual-digit hierarchy be meaningful or not > in the future? yes. you will always be able to represent the E.164 delegation hierarchy using a DNS tree where each digit is a separate DNS label. this would not necessarily be the case for a DNS tree where there were some multiple digit labels. that's why the one-digit-per-label representation is preferred. the nice thing about doing it this way is that the structure of phone numbers is reflected in the DNS tree, and can change from time to time, rather than being embedded either in lookup software or in users' minds. so for an example, to look up +1 865 974 3126 1. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to the DNS root <<< DNS root returns "I have no answers for you, but domains ending in .e164.net can be looked up at any of the following servers..." (list of servers for lookup of top-level e.164 prefixes follows) (this assumes that the root server also serves .net, as is currently the case for at least some of the root servers) 2. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the DNS servers listed for .e164.net <<< that server returns "I have no answers for you, but domains ending in .1.e164.net can be looked up at any of the following servers..." (list of servers for north america follows) 3. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the DNS servers listed for .1.e164.net <<< that server returns "I have no answers for you, but domains ending in .5.6.8.1.e164.net can be looked up at any of the following servers..." (list of servers for Knoxville area, Tennessee, US follows) 4. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the DNS servers listed for .5.6.8.1.e164.net <<< that server returns "I have no answers for you, but domains ending in 3.4.7.9.5.6.8.1.e164.net can be looked up at any of the following servers..." (list of servers for the University of Tennessee, Knoxville campus, follows) 5. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the DNS servers listed for 3.4.7.9.5.6.8.1.e164.net <<< that server returns "here are the records for 6.2.1.3.4.7.9.5.6.8.1.e164.net" note that a) the query is the same at every step b) it's not necessary to make a separate query for each digit - each server returns a referral for the longest DNS suffix matching the query. c) if the structure of e.164 delegation changes, this change can be reflected in DNS without any changes whatsoever to client code. for instance, another level of delegation could be added for the +1 865 974- prefix, or the e164.net servers could be taught to lookup north american numbering plan area codes under +1, and delegate each area code to to the appropriate country's DNS servers, or directly to servers for those area codes. the client code doesn't have to know or care how this is done. d) in practice, the results of the first two or three or four queries are likely to be in a local cache, thus most lookup will not require that many queries. _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 05:51: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 FAA01765 for ; Mon, 7 Feb 2000 05:51: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 FAA12773; Mon, 7 Feb 2000 05:47:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12713 for ; Mon, 7 Feb 2000 05:47:27 -0500 (EST) Received: from xn1-gw (xn1-b.atlas.fr [194.51.9.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01737; Mon, 7 Feb 2000 05:48:50 -0500 (EST) From: alain.doisneau@art-telecom.fr X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Mon, 7 Feb 2000 11:47:39 +0100 X400-Received: by mta xn1-gw.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Mon, 7 Feb 2000 11:47:39 +0100 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Mon, 7 Feb 2000 11:47:44 +0100 X400-Received: by /PRMD=art-telecom/ADMD=atlas/C=fr/; Relayed; Mon, 7 Feb 2000 11:50:34 +0100 Date: Mon, 7 Feb 2000 11:50:34 +0100 X400-Originator: alain.doisneau@art-telecom.fr X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=art-telecom/ADMD=atlas/C=fr/;<003c01bf7159$29993e00$01046182>] Original-Encoded-Information-Types: teletex X400-Content-Type: P2-1988 (22) Content-Identifier: Re: -ITU+IETF... Message-ID: <003c01bf7159S29993e00S01040b8baadu*@MHS> To: moore@cs.utk.edu, Albert.Manfredi@PHL.Boeing.com Cc: mark.foster@neustar.com, enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA12716 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Dear All, As I launched this debate, i first of all thank you who had given your answers and comments. Among all of them, I appreciate the following for it thoroughly clarified the issue to me (with the exception of the .net suffix which looks strange - shouldn'it have been .int instead ?). Regards Alain Doisneau : alain.doisneau@art-telecom.fr -----Message d'origine----- De : moore@cs.utk.edu À : Albert.Manfredi@PHL.Boeing.com Cc : mark.foster@neustar.com ; enum@ietf.org ; itu+ietf@ietf.org Date : samedi 5 février 2000 01:48 Objet : Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM >> So the question is, will the individual-digit hierarchy be meaningful or not >> in the future? > >yes. you will always be able to represent the E.164 delegation hierarchy >using a DNS tree where each digit is a separate DNS label. this would >not necessarily be the case for a DNS tree where there were some >multiple digit labels. that's why the one-digit-per-label representation >is preferred. > >the nice thing about doing it this way is that the structure of phone >numbers is reflected in the DNS tree, and can change from time to time, >rather than being embedded either in lookup software or in users' minds. > >so for an example, to look up +1 865 974 3126 > >1. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to the DNS root > ><<< DNS root returns "I have no answers for you, but domains > ending in .e164.net can be looked up at any of the following servers..." > > (list of servers for lookup of top-level e.164 prefixes follows) > > (this assumes that the root server also serves .net, as is > currently the case for at least some of the root servers) > >2. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the > DNS servers listed for .e164.net > ><<< that server returns "I have no answers for you, but domains > ending in .1.e164.net can be looked up at any of the following > servers..." > > (list of servers for north america follows) > >3. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the > DNS servers listed for .1.e164.net > > ><<< that server returns "I have no answers for you, but domains > ending in .5.6.8.1.e164.net can be looked up at any of the > following servers..." > > (list of servers for Knoxville area, Tennessee, US follows) > >4. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the > DNS servers listed for .5.6.8.1.e164.net > ><<< that server returns "I have no answers for you, but domains > ending in 3.4.7.9.5.6.8.1.e164.net can be looked up at any of > the following servers..." > > (list of servers for the University of Tennessee, Knoxville > campus, follows) > >5. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the > DNS servers listed for 3.4.7.9.5.6.8.1.e164.net > ><<< that server returns "here are the records for > 6.2.1.3.4.7.9.5.6.8.1.e164.net" > >note that > >a) the query is the same at every step >b) it's not necessary to make a separate query for each digit - > each server returns a referral for the longest DNS suffix > matching the query. >c) if the structure of e.164 delegation changes, this change > can be reflected in DNS without any changes whatsoever > to client code. for instance, another level of delegation > could be added for the +1 865 974- prefix, or the e164.net > servers could be taught to lookup north american numbering > plan area codes under +1, and delegate each area code to > to the appropriate country's DNS servers, or directly to > servers for those area codes. the client code doesn't have > to know or care how this is done. >d) in practice, the results of the first two or three or four > queries are likely to be in a local cache, thus most lookup > will not require that many queries. > > >_______________________________________________ >ITU+IETF mailing list >ITU+IETF@ietf.org >http://www.ietf.org/mailman/listinfo/itu+ietf > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 08:12:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05806 for ; Mon, 7 Feb 2000 08:12: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 IAA16129; Mon, 7 Feb 2000 08:08: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 IAA16062 for ; Mon, 7 Feb 2000 08:08:42 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05720; Mon, 7 Feb 2000 08:10:07 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id IAA19422; Mon, 7 Feb 2000 08:09:49 -0500 (EST) Message-Id: <200002071309.IAA19422@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alain.doisneau@art-telecom.fr cc: moore@cs.utk.edu, Albert.Manfredi@PHL.Boeing.com, mark.foster@neustar.com, enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: Your message of "Mon, 07 Feb 2000 11:50:34 +0100." <003c01bf7159S29993e00S01040b8baadu*@MHS> Date: Mon, 07 Feb 2000 08:09:49 -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > As I launched this debate, i first of all thank you who had given your > answers and comments. > Among all of them, I appreciate the following for it thoroughly clarified > the issue to me thanks for the compliment! > (with the exception of the .net suffix which looks strange - > shouldn'it have been .int instead ?). it could be either .int or .net and still work just as well. (assuming that nobody has bought e164.net by then!) I did not suggest .int because some people consider it controversial, and I didn't want a debate about .int to cloud the explanation of how DNS lookups of E.164 numbers would work. And I haven't been closely following the enum discussion, so I don't know what's been decided about this. But if the people who run .int have no objection to defining e164.int, then neither do I. Keith _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 08:37: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 IAA07677 for ; Mon, 7 Feb 2000 08:37: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 IAA16901; Mon, 7 Feb 2000 08:36: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 IAA16826 for ; Mon, 7 Feb 2000 08:36:09 -0500 (EST) Received: from mail1.itu.int (mail1.itu.ch [156.106.192.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07644; Mon, 7 Feb 2000 08:37:35 -0500 (EST) Received: by mail1.itu.ch with Internet Mail Service (5.5.2650.21) id ; Mon, 7 Feb 2000 14:38:23 +0100 Message-ID: From: "Shaw, Robert" To: "'Keith Moore'" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 14:37:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, February 07, 2000 2:10 PM > To: alain.doisneau@art-telecom.fr > Cc: moore@cs.utk.edu; Albert.Manfredi@PHL.Boeing.com; > mark.foster@neustar.com; enum@ietf.org; itu+ietf@ietf.org > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry > for ENUM > > > it could be either .int or .net and still work just as well. > (assuming that nobody has bought e164.net by then!) > hmmm... some folks called netnumber.com have e164.com Peter Lothberg has e164.net Lucent has e164.org I wonder what would be the result of a UDRP challenge to these names (I think I'm joking...) Bob _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 09:32:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10590 for ; Mon, 7 Feb 2000 09:32:59 -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 JAA18466; Mon, 7 Feb 2000 09:29: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 JAA18434 for ; Mon, 7 Feb 2000 09:29:16 -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 JAA10480 for ; Mon, 7 Feb 2000 09:30:39 -0500 (EST) Received: by dnspri.npac.com; id IAA06452; Mon, 7 Feb 2000 08:30:30 -0600 (CST) Received: from nodnsquery(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma006344; Mon, 7 Feb 00 08:29:43 -0600 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Feb 2000 08:25:20 -0600 Message-ID: From: James Yu To: "'arbrown@nortelnetworks.com'" Cc: "'enum@ietf.org'" Date: Mon, 7 Feb 2000 08:22:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] ENUM Requirements Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Ann, NeuStar submitted some proposed revisions to the draft-ietf-enum-rqmts-00.on 12/8. Since it did not generate any discussion, we are resubmitting the proposed changes but with some modifications. We suggest that the discussion be based on the changes proposed in this message and have the changes incorporated into the enum requirements document. People familiar with the post dialing delays please help in identifying the post dialing delay requirement for the international calls in the GSTN today. The reason is that the same post dialing delay requirement will apply to the scenario where a call is originated from the GSTN to the GSTN via the Internet. We suggest to revise sections 3.7 and 3.9 (see proposed texts below) and clarify 3.11 in draft-ietf-enum-rqmts-00. 3.7 Number Portability The system MUST take into consideration of all the existing local number portability mechanisms that allow the subscribers to keep their phone numbers when switching from one local access service provider to another, where applicable. It is RECOMMENDED that the system not be designed in such a way as to impede future number portability that allows the subscribers to keep their phone numbers when moving from one physical location to another or changing their subscribed services within or across those systems that use E.164 numbers to identify the end users or terminals/devices. 3.9 Query Performance The system is not expected to respond to queries with the same performance levels as current GSTN queries; however, the DNS process SHOULD not significantly increase the post dialing delay as perceived by the caller or specified by the regulatory bodies (e.g., 10 seconds for domestic calls). Please clarify "the owner of the telephone number" in Section 3.11. Is it the subscriber that is assigned the telephone number or the service provider that currently serves that number? James 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 Mon Feb 7 09:44:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11154 for ; Mon, 7 Feb 2000 09:44:05 -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 JAA19015; Mon, 7 Feb 2000 09:41:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18953 for ; Mon, 7 Feb 2000 09:41:31 -0500 (EST) Received: from smtprtp.ntcom.nortel.net (smtprtp.ntcom.nortel.net [137.118.22.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11100; Mon, 7 Feb 2000 09:42:55 -0500 (EST) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Mon, 7 Feb 2000 09:41:53 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id <1NWN5JB6>; Mon, 7 Feb 2000 09:41:54 -0500 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24919BD0@bcarua63.ca.nortel.com> From: "Anne Brown" To: "'Shaw, Robert'" , "'Keith Moore'" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 09:41:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7179.7936D4A2" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7179.7936D4A2 Content-Type: text/plain; charset="iso-8859-1" FYI. I believe Lucent established e164.org for enum development testing and would be willing to give it up to whomever it makes sense to do so. Regards, Anne -----Original Message----- From: Shaw, Robert [mailto:Robert.Shaw@itu.int] Sent: February 07, 2000 8:37 AM To: 'Keith Moore' Cc: enum@ietf.org; itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, February 07, 2000 2:10 PM > To: alain.doisneau@art-telecom.fr > Cc: moore@cs.utk.edu; Albert.Manfredi@PHL.Boeing.com; > mark.foster@neustar.com; enum@ietf.org; itu+ietf@ietf.org > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry > for ENUM > > > it could be either .int or .net and still work just as well. > (assuming that nobody has bought e164.net by then!) > hmmm... some folks called netnumber.com have e164.com Peter Lothberg has e164.net Lucent has e164.org I wonder what would be the result of a UDRP challenge to these names (I think I'm joking...) Bob _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf ------_=_NextPart_001_01BF7179.7936D4A2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for = ENUM

FYI.  I believe Lucent = established e164.org for enum development testing and would be willing = to give it up to whomever it makes sense to do so.

Regards,
Anne

      -----Original = Message-----
      From:   Shaw, Robert [mailto:Robert.Shaw@itu.int]
      Sent:   February 07, 2000 8:37 AM
      To:     'Keith Moore'
      Cc:     enum@ietf.org; itu+ietf@ietf.org
      Subject:       = RE: [ITU+IETF] RE: [Enum] Re: = Structure of DNS entry for ENUM

      > -----Original Message-----
      > From: Keith Moore [mailto:moore@cs.utk.edu]
      > Sent: Monday, February 07, 2000 = 2:10 PM
      > To: = alain.doisneau@art-telecom.fr
      > Cc: moore@cs.utk.edu; = Albert.Manfredi@PHL.Boeing.com;
      > mark.foster@neustar.com; = enum@ietf.org; itu+ietf@ietf.org
      > Subject: Re: [ITU+IETF] RE: = [Enum] Re: Structure of DNS entry
      > for ENUM
      >
      >
      > it could be either .int or .net = and still work just as well.
      > (assuming that nobody has bought = e164.net by then!)
      >

      hmmm...

      some folks called netnumber.com have = e164.com

      Peter Lothberg has e164.net

      Lucent has e164.org

      I wonder what would be the result of a = UDRP challenge
      to these names (I think I'm = joking...)

      Bob


      _______________________________________________
      ITU+IETF mailing list
      ITU+IETF@ietf.org
      http://www.ietf.org/mailman/listinfo/itu+ietf

------_=_NextPart_001_01BF7179.7936D4A2-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 09:51:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11356 for ; Mon, 7 Feb 2000 09:51:56 -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 JAA19333; Mon, 7 Feb 2000 09:48:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19271 for ; Mon, 7 Feb 2000 09:48:40 -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 JAA11303; Mon, 7 Feb 2000 09:50:02 -0500 (EST) Received: from laptop (stl-mo15-09.ix.netcom.com [207.222.133.137]) by smtp7.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id JAA03396; Mon, 7 Feb 2000 09:49:28 -0500 (EST) Message-Id: <4.2.0.58.20000207083841.00b30ed0@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, 07 Feb 2000 08:48:39 -0600 To: Keith Moore , alain.doisneau@art-telecom.fr From: Richard Shockey Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Cc: moore@cs.utk.edu, Albert.Manfredi@PHL.Boeing.com, mark.foster@neustar.com, enum@ietf.org, itu+ietf@ietf.org In-Reply-To: <200002071309.IAA19422@astro.cs.utk.edu> References: 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 X-BeenThere: enum@ietf.org > >I did not suggest .int because some people consider it controversial, >and I didn't want a debate about .int to cloud the explanation of >how DNS lookups of E.164 numbers would work. And I haven't been >closely following the enum discussion, so I don't know what's been >decided about this. But if the people who run .int have no objection >to defining e164.int, then neither do I. > >Keith An realistically we can use any domain and TLD we can agree on.... [number].domain.foo. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Feb 7 09:55:43 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 JAA11528 for ; Mon, 7 Feb 2000 09:55:43 -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 JAA19518; Mon, 7 Feb 2000 09:51: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 JAA19455 for ; Mon, 7 Feb 2000 09:51:47 -0500 (EST) Received: from p-voyageur.issy.cnet.fr (p-voyageur.issy.cnet.fr [139.100.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11425; Mon, 7 Feb 2000 09:53:06 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id <1F227ZDM>; Mon, 7 Feb 2000 15:53:52 +0100 Message-ID: <98388C05D464D111B61800805F1504160123E51F@p-ibis.issy.cnet.fr> From: BARNOLE Valerie CNET/DAC/ISS To: "'Shaw, Robert'" , "'Keith Moore'" , "'Alain DOISNEAU'" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 15:53:52 +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 JAA19456 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit I do not know where is the right place to discuss about the e164.foo to choose, but the discussion will have to take place somewhere one of these days. From Bob Shaw's answer, it seems to me that the easy solution is to use e164.int, because I think that ITU, which has been allocated .int (I think so), is not using it by now. Am I right ? Politically, from a naive point of view, it should hurt nobody because ITU is already in charge of the international E.164 numbering plan (I do not omit the delegation to the different regulating authorities through the allocation of the geographical country codes). but maybe I am missing something ? As I have no real IP naming background or experience with IP names problems, I wonder if it is safe to use e164.foo if the domain e164 has already been bought by other entities under other GTLDs. Your comments are welcome. 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: Shaw, Robert [mailto:Robert.Shaw@itu.int] Date: lundi 7 février 2000 14:37 À: 'Keith Moore' Cc: enum@ietf.org; itu+ietf@ietf.org Objet: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, February 07, 2000 2:10 PM > To: alain.doisneau@art-telecom.fr > Cc: moore@cs.utk.edu; Albert.Manfredi@PHL.Boeing.com; > mark.foster@neustar.com; enum@ietf.org; itu+ietf@ietf.org > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry > for ENUM > > > it could be either .int or .net and still work just as well. > (assuming that nobody has bought e164.net by then!) > hmmm... some folks called netnumber.com have e164.com Peter Lothberg has e164.net Lucent has e164.org I wonder what would be the result of a UDRP challenge to these names (I think I'm joking...) Bob _______________________________________________ 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 Feb 7 10:15:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12189 for ; Mon, 7 Feb 2000 10:15: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 KAA20353; Mon, 7 Feb 2000 10:11:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20283 for ; Mon, 7 Feb 2000 10:11:16 -0500 (EST) Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12107 for ; Mon, 7 Feb 2000 10:12:33 -0500 (EST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Mon, 7 Feb 2000 09:12:13 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1F2TLXP9>; Mon, 7 Feb 2000 09:11:27 -0600 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24919BD1@bcarua63.ca.nortel.com> From: "Anne Brown" To: "'James Yu'" Cc: "'enum@ietf.org'" Subject: RE: [Enum] ENUM Requirements Date: Mon, 7 Feb 2000 09:11:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF717D.9A4FD6BC" X-Orig: Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF717D.9A4FD6BC Content-Type: text/plain; charset="iso-8859-1" James, My comments below. Regards, Anne -----Original Message----- From: James Yu [mailto:james.yu@neustar.com] Sent: February 07, 2000 9:22 AM To: Brown, Anne [NORSE:5N00:EXCH] Cc: 'enum@ietf.org' Subject: [Enum] ENUM Requirements Ann, NeuStar submitted some proposed revisions to the draft-ietf-enum-rqmts-00.on 12/8. Since it did not generate any discussion, we are resubmitting the proposed changes but with some modifications. We suggest that the discussion be based on the changes proposed in this message and have the changes incorporated into the enum requirements document. People familiar with the post dialing delays please help in identifying the post dialing delay requirement for the international calls in the GSTN today. The reason is that the same post dialing delay requirement will apply to the scenario where a call is originated from the GSTN to the GSTN via the Internet. We suggest to revise sections 3.7 and 3.9 (see proposed texts below) and clarify 3.11 in draft-ietf-enum-rqmts-00. 3.7 Number Portability The system MUST take into consideration of all the existing local number portability mechanisms that allow the subscribers to keep their phone numbers when switching from one local access service provider to another, where applicable. It is RECOMMENDED that the system not be designed in such a way as to impede future number portability that allows the subscribers to keep their phone numbers when moving from one physical location to another or changing their subscribed services within or across those systems that use E.164 numbers to identify the end users or terminals/devices. I don't believe that the ENUM service (or protocol or solution) should have to be aware of all existing LNP mechanisms, which is implied by your text. The solution should, however, support the lookup of ported E.164 numbers. Would you agree on the following text: 3.7 Number Portability The system MUST support the retrieval of information, based on an E.164 number, regardless of whether or not the E.164 number is a locally or globally ported number. It is RECOMMENDED that the system..... 3.9 Query Performance The system is not expected to respond to queries with the same performance levels as current GSTN queries; however, the DNS process SHOULD not significantly increase the post dialing delay as perceived by the caller or specified by the regulatory bodies (e.g., 10 seconds for domestic calls). Define "significantly"? I recommend removing the word significantly and changing the text "SHOULD not" to "SHOULD NOT" as per RFC 2119. Please clarify "the owner of the telephone number" in Section 3.11. Is it the subscriber that is assigned the telephone number or the service provider that currently serves that number? Section 3.11 on Privacy states that "The system MUST allow the owner of the telephone number to control the information which prospective callers may receive." I recommend replacing the text with "The system MUST allow the user to whom the telephone number was assigned, the ability to control the information...". James 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 ------_=_NextPart_001_01BF717D.9A4FD6BC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Enum] ENUM Requirements

James,

My comments below.

Regards,
Anne


      -----Original = Message-----
      From:   James Yu [mailto:james.yu@neustar.com]
      Sent:   February 07, 2000 9:22 AM
      To:     Brown, Anne [NORSE:5N00:EXCH]
      Cc:     'enum@ietf.org'
      Subject:       = [Enum] ENUM Requirements

      Ann,
      NeuStar submitted some proposed = revisions to the draft-ietf-enum-rqmts-00.on
      12/8.  Since it did not generate = any discussion, we are resubmitting the
      proposed changes but with some = modifications.  We suggest that the
      discussion be based on the changes = proposed in this message and have the
      changes incorporated into the enum = requirements document.  People familiar
      with the post dialing delays please = help in identifying the post dialing
      delay requirement for the = international calls in the GSTN today.  The reason
      is that the same post dialing delay = requirement will apply to the scenario
      where a call is originated from the = GSTN to the GSTN via the Internet.
      We suggest to revise sections 3.7 and = 3.9 (see proposed texts below) and
      clarify 3.11 in = draft-ietf-enum-rqmts-00.
      3.7 Number Portability
      The system MUST take into = consideration of all the existing local number
      portability mechanisms that allow the = subscribers to keep their phone
      numbers when switching from one local = access service provider to another,
      where applicable. It is RECOMMENDED = that the system not be designed in such
      a way as to impede future number = portability that allows the subscribers to
      keep their phone numbers when moving = from one physical location to another
      or changing their subscribed services = within or across those systems that
      use E.164 numbers to identify the end = users or terminals/devices.

I don't believe that the ENUM = service (or protocol or solution) should have to be aware of all = existing LNP mechanisms, which is implied by your text.  The = solution should, however, support the lookup of ported E.164 = numbers.  Would you agree on the following text:

3.7 Number Portability
The system MUST support the = retrieval of information, based on an E.164 number, regardless of = whether or not the E.164 number is a locally or globally ported number. = It is RECOMMENDED that the system.....


      3.9 Query Performance
      The system is not expected to respond = to queries with the same performance
      levels as current GSTN queries; = however, the DNS process SHOULD not
      significantly increase the post = dialing delay as perceived by the caller or
      specified by the regulatory bodies = (e.g., 10 seconds for domestic calls).

Define "significantly"?  I = recommend removing the = word significantly = and changing the text = "SHOULD not" to "SHOULD NOT" as per = RFC 2119. 



      Please clarify "the owner of the = telephone number" in Section 3.11. Is it
      the subscriber that is assigned the = telephone number or the service provider
      that currently serves that = number?

Section 3.11 on Privacy states = that "The = system MUST allow the owner of the telephone number to control the = information which prospective callers may receive."  I recommend replacing = the text with "The system MUST allow the user to whom the telephone number was = assigned, the ability to = control the = information...".

      James

      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

------_=_NextPart_001_01BF717D.9A4FD6BC-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 11:00:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13386 for ; Mon, 7 Feb 2000 11:00: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 KAA21892; Mon, 7 Feb 2000 10:57:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21859 for ; Mon, 7 Feb 2000 10:57:30 -0500 (EST) Received: from roam.psg.com ([216.33.132.75]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13345 for ; Mon, 7 Feb 2000 10:58:53 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12HqZ5-00012d-00; Mon, 07 Feb 2000 07:59:03 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: James Yu Cc: enum wg Subject: Re: [Enum] ENUM Requirements References: Message-Id: Date: Mon, 07 Feb 2000 07:59:03 -0800 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > NeuStar submitted some proposed revisions to the draft-ietf-enum-rqmts-00.on > 12/8. as ietf is made up of individual experts, not companies, governments, ... i doubt it. randy _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 11:08:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13624 for ; Mon, 7 Feb 2000 11:08: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 LAA22293; Mon, 7 Feb 2000 11:04:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22220 for ; Mon, 7 Feb 2000 11:04:35 -0500 (EST) Received: from roam.psg.com ([216.33.132.75]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13556; Mon, 7 Feb 2000 11:05:58 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12Hqed-00012p-00; Mon, 07 Feb 2000 08:04:47 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Richard Shockey Cc: enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <4.2.0.58.20000207083841.00b30ed0@127.0.0.1> Message-Id: Date: Mon, 07 Feb 2000 08:04:47 -0800 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > An realistically we can use any domain and TLD we can agree on.... > [number].domain.foo. actually, we don't have to agree. there can be consortia/conspiracies/ brokerages, each covering all or part of the global phone space and each using its own domain appendage. an outbound call would try to resolve in each of the consortia/domains in which it participates in order of preference. randy _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 11:12:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13690 for ; Mon, 7 Feb 2000 11:12:11 -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 LAA22481; Mon, 7 Feb 2000 11:09:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22453 for ; Mon, 7 Feb 2000 11:09:15 -0500 (EST) Received: from bastiont.npac.com (firewall-user@bastiont.npac.com [208.143.34.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13655 for ; Mon, 7 Feb 2000 11:10:38 -0500 (EST) Received: by bastiont.npac.com; id LAA12856; Mon, 7 Feb 2000 11:10:38 -0500 (EST) Received: from nodnsquery(208.143.39.132) by bastiont.npac.com via smap (V5.0) id xma012760; Mon, 7 Feb 00 11:10:17 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Feb 2000 10:05:54 -0600 Message-ID: From: James Yu To: "'Randy Bush'" Cc: enum wg Subject: RE: [Enum] ENUM Requirements Date: Mon, 7 Feb 2000 10:01:38 -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 X-BeenThere: enum@ietf.org Randy, Agree. It will be from me then. Thanks. James > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, February 07, 2000 10:59 AM > To: James Yu > Cc: enum wg > Subject: Re: [Enum] ENUM Requirements > > > > NeuStar submitted some proposed revisions to the > draft-ietf-enum-rqmts-00.on > > 12/8. > > as ietf is made up of individual experts, not companies, > governments, ... > i doubt it. > > randy > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 11:16: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 LAA13881 for ; Mon, 7 Feb 2000 11:16: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 LAA22707; Mon, 7 Feb 2000 11:14:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22630 for ; Mon, 7 Feb 2000 11:14:14 -0500 (EST) Received: from bastiont.npac.com (firewall-user@bastiont.npac.com [208.143.34.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13851; Mon, 7 Feb 2000 11:15:38 -0500 (EST) Received: by bastiont.npac.com; id LAA13595; Mon, 7 Feb 2000 11:15:39 -0500 (EST) Received: from nodnsquery(208.143.39.132) by bastiont.npac.com via smap (V5.0) id xma013464; Mon, 7 Feb 00 11:14:48 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Feb 2000 10:10:24 -0600 Message-ID: From: James Yu To: "'Randy Bush'" Cc: Richard Shockey , enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 10:07:31 -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 X-BeenThere: enum@ietf.org This means that the client would need to know which consortium/domain to use when sending the DNS query. It may be fine if the client only handles calls within a consortium/domain. But it won't be true for all the clients. James > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, February 07, 2000 11:05 AM > To: Richard Shockey > Cc: enum@ietf.org; itu+ietf@ietf.org > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry > for ENUM > > > > An realistically we can use any domain and TLD we can agree on.... > > [number].domain.foo. > > actually, we don't have to agree. there can be > consortia/conspiracies/ > brokerages, each covering all or part of the global phone > space and each > using its own domain appendage. an outbound call would try > to resolve in > each of the consortia/domains in which it participates in order of > preference. > > randy > > _______________________________________________ > ITU+IETF mailing list > ITU+IETF@ietf.org > http://www.ietf.org/mailman/listinfo/itu+ietf > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 11:26:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14160 for ; Mon, 7 Feb 2000 11:26:11 -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 LAA22988; Mon, 7 Feb 2000 11:23:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22957 for ; Mon, 7 Feb 2000 11:23:19 -0500 (EST) Received: from bastiont.npac.com (firewall-user@bastiont.npac.com [208.143.34.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14115 for ; Mon, 7 Feb 2000 11:24:41 -0500 (EST) Received: by bastiont.npac.com; id LAA15440; Mon, 7 Feb 2000 11:24:40 -0500 (EST) Received: from nodnsquery(208.143.39.132) by bastiont.npac.com via smap (V5.0) id xma015322; Mon, 7 Feb 00 11:24:03 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Feb 2000 10:19:40 -0600 Message-ID: From: James Yu To: "'Anne Brown'" Cc: "'enum@ietf.org'" Subject: RE: [Enum] ENUM Requirements Date: Mon, 7 Feb 2000 10:15:13 -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 X-BeenThere: enum@ietf.org Ann, The need to be aware of the existing LNP implementations will ensure that the ENUM scheme will provide a common mechanism for retrieving the information that currently reside on various LNP databases. I have no problem with the last two comments. James -----Original Message----- From: Anne Brown [mailto:arbrown@nortelnetworks.com] Sent: Monday, February 07, 2000 10:11 AM To: 'James Yu' Cc: 'enum@ietf.org' Subject: RE: [Enum] ENUM Requirements James, My comments below. Regards, Anne BM__MailData-----Original Message----- From: James Yu [ mailto:james.yu@neustar.com ] Sent: February 07, 2000 9:22 AM To: Brown, Anne [NORSE:5N00:EXCH] Cc: 'enum@ietf.org' Subject: [Enum] ENUM Requirements Ann, NeuStar submitted some proposed revisions to the draft-ietf-enum-rqmts-00.on 12/8. Since it did not generate any discussion, we are resubmitting the proposed changes but with some modifications. We suggest that the discussion be based on the changes proposed in this message and have the changes incorporated into the enum requirements document. People familiar with the post dialing delays please help in identifying the post dialing delay requirement for the international calls in the GSTN today. The reason is that the same post dialing delay requirement will apply to the scenario where a call is originated from the GSTN to the GSTN via the Internet. We suggest to revise sections 3.7 and 3.9 (see proposed texts below) and clarify 3.11 in draft-ietf-enum-rqmts-00. 3.7 Number Portability The system MUST take into consideration of all the existing local number portability mechanisms that allow the subscribers to keep their phone numbers when switching from one local access service provider to another, where applicable. It is RECOMMENDED that the system not be designed in such a way as to impede future number portability that allows the subscribers to keep their phone numbers when moving from one physical location to another or changing their subscribed services within or across those systems that use E.164 numbers to identify the end users or terminals/devices. I don't believe that the ENUM service (or protocol or solution) should have to be aware of all existing LNP mechanisms, which is implied by your text. The solution should, however, support the lookup of ported E.164 numbers. Would you agree on the following text: 3.7 Number Portability The system MUST support the retrieval of information, based on an E.164 number, regardless of whether or not the E.164 number is a locally or globally ported number. It is RECOMMENDED that the system..... 3.9 Query Performance The system is not expected to respond to queries with the same performance levels as current GSTN queries; however, the DNS process SHOULD not significantly increase the post dialing delay as perceived by the caller or specified by the regulatory bodies (e.g., 10 seconds for domestic calls). Define "significantly"? I recommend removing the word significantly and changing the text "SHOULD not" to "SHOULD NOT" as per RFC 2119. Please clarify "the owner of the telephone number" in Section 3.11. Is it the subscriber that is assigned the telephone number or the service provider that currently serves that number? Section 3.11 on Privacy states that "The system MUST allow the owner of the telephone number to control the information which prospective callers may receive." I recommend replacing the text with "The system MUST allow the user to whom the telephone number was assigned, the ability to control the information...". James 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 _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 12:09: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 MAA15555 for ; Mon, 7 Feb 2000 12:09:33 -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 MAA25128; Mon, 7 Feb 2000 12:07:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25061 for ; Mon, 7 Feb 2000 12:07:11 -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 MAA15524; Mon, 7 Feb 2000 12:08:37 -0500 (EST) Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQibjw06695; Mon, 7 Feb 2000 17:08:36 GMT Message-ID: <389EFCD2.71C1E55E@dynamicsoft.com> Date: Mon, 07 Feb 2000 12:11:46 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Yu CC: "'Randy Bush'" , Richard Shockey , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit James Yu wrote: > > This means that the client would need to know which consortium/domain to use > when sending the DNS query. It may be fine if the client only handles calls > within a consortium/domain. But it won't be true for all the clients. I don't think we're trying to solve all aspects of the general problem here. I think our job is to start with a tld, and from there, figure out how to formulate the query to get back some kind of useful response. Deciding who owns these tld's, and how to configure them in clients, is important but not what we are solving here. -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 Feb 7 12:29:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16130 for ; Mon, 7 Feb 2000 12:29:07 -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 MAA25727; Mon, 7 Feb 2000 12:27: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 MAA25656 for ; Mon, 7 Feb 2000 12:27:01 -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 MAA16082; Mon, 7 Feb 2000 12:28:27 -0500 (EST) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id JAA24226; Mon, 7 Feb 2000 09:28:23 -0800 (PST) From: Bill Manning Message-Id: <200002071728.JAA24226@boreas.isi.edu> Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM To: randy@psg.com (Randy Bush) Date: Mon, 7 Feb 2000 09:28:23 -0800 (PST) Cc: rshockey@ix.netcom.com (Richard Shockey), enum@ietf.org, itu+ietf@ietf.org In-Reply-To: from "Randy Bush" at Feb 07, 2000 08:04:47 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit % % > An realistically we can use any domain and TLD we can agree on.... % > [number].domain.foo. % % actually, we don't have to agree. there can be consortia/conspiracies/ % brokerages, each covering all or part of the global phone space and each % using its own domain appendage. an outbound call would try to resolve in % each of the consortia/domains in which it participates in order of % preference. % % randy hum, so this method works well for the IP space as well, yes? your consortia can anchor its IPv4 space in seattle.wa.us. and I can stick my address space in shockwave.com; e.g. 16.172.seattle.wa.us & 24.172.shockwave.com and all will be well? I find this hard to fathom. --bill _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 12:31:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16307 for ; Mon, 7 Feb 2000 12:31:55 -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 MAA25887; Mon, 7 Feb 2000 12:29: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 MAA25827 for ; Mon, 7 Feb 2000 12:29:37 -0500 (EST) Received: from roam.psg.com (t75.nanog.exodus.net [216.33.132.75] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16222; Mon, 7 Feb 2000 12:31:01 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12Hs0D-0001I0-00; Mon, 07 Feb 2000 09:31:09 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bill Manning Cc: rshockey@ix.netcom.com (Richard Shockey), enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <200002071728.JAA24226@boreas.isi.edu> Message-Id: Date: Mon, 07 Feb 2000 09:31:09 -0800 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > I find this hard to fathom. i am not surprised randy _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 12:33: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 MAA16354 for ; Mon, 7 Feb 2000 12:33: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 MAA26140; Mon, 7 Feb 2000 12:32:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26077 for ; Mon, 7 Feb 2000 12:32:00 -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 MAA16333; Mon, 7 Feb 2000 12:33:25 -0500 (EST) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id JAA24984; Mon, 7 Feb 2000 09:32:01 -0800 (PST) From: Bill Manning Message-Id: <200002071732.JAA24984@boreas.isi.edu> Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM To: randy@psg.com (Randy Bush) Date: Mon, 7 Feb 2000 09:32:01 -0800 (PST) Cc: bmanning@isi.edu (Bill Manning), rshockey@ix.netcom.com (Richard Shockey), enum@ietf.org, itu+ietf@ietf.org In-Reply-To: from "Randy Bush" at Feb 07, 2000 09:31:09 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit % % > I find this hard to fathom. % % i am not surprised % % randy % You should be. -- --bill _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 12:41:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16598 for ; Mon, 7 Feb 2000 12:41:46 -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 MAA26434; Mon, 7 Feb 2000 12: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 MAA26360 for ; Mon, 7 Feb 2000 12:39:45 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16461; Mon, 7 Feb 2000 12:39:56 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA20580; Mon, 7 Feb 2000 12:36:06 -0500 (EST) Message-Id: <200002071736.MAA20580@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Bush cc: Richard Shockey , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: Your message of "Mon, 07 Feb 2000 08:04:47 PST." Date: Mon, 07 Feb 2000 12:36:06 -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > An realistically we can use any domain and TLD we can agree on.... > > [number].domain.foo. > > actually, we don't have to agree. there can be consortia/conspiracies/ > brokerages, each covering all or part of the global phone space and each > using its own domain appendage. an outbound call would try to resolve in > each of the consortia/domains in which it participates in order of > preference. certainly a possible outcome. not necessarily a favorable one. (some folks would disagree about this) but I've always regarded this as the biggest problem facing enum - will it be politically possible to map the e.164 number space onto a single federated database (like DNS) such that: a) the result is reasonably consistent with the real e.164 world, (and also consistent from one client to another), and b) the results returned from a lookup of a phone number are under control of the owner of that phone number (perhaps via a proxy) i.e. mostly a technical problem rather than a political one. but it does make sense to tackle the technical problem first. Keith _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 12:52:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17118 for ; Mon, 7 Feb 2000 12:52: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 MAA26818; Mon, 7 Feb 2000 12:50:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26751 for ; Mon, 7 Feb 2000 12:50:44 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17082; Mon, 7 Feb 2000 12:52:08 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA20656; Mon, 7 Feb 2000 12:43:06 -0500 (EST) Message-Id: <200002071743.MAA20656@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Bush cc: Bill Manning , rshockey@ix.netcom.com (Richard Shockey), enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: Your message of "Mon, 07 Feb 2000 09:31:09 PST." Date: Mon, 07 Feb 2000 12:43:06 -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > I find this hard to fathom. > > i am not surprised well, it would seem odd for IETF to insist on consistency of meaning for IP numbers (modulo private address space) but not care about consistency of meaning for E.164 numbers. seems like users' interests are best served by having a consistent meaning, everywhere, for both kinds of address. Keith _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 12:54:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17156 for ; Mon, 7 Feb 2000 12:54:05 -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 MAA26944; Mon, 7 Feb 2000 12:52: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 MAA26884 for ; Mon, 7 Feb 2000 12:52:10 -0500 (EST) Received: from roam.psg.com (t75.nanog.exodus.net [216.33.132.75] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17133; Mon, 7 Feb 2000 12:53:37 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12HsLg-0001K7-00; Mon, 07 Feb 2000 09:53:20 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Keith Moore Cc: enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <200002071743.MAA20656@astro.cs.utk.edu> Message-Id: Date: Mon, 07 Feb 2000 09:53:20 -0800 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > seems like users' interests are best served by having a consistent > meaning, everywhere, for both kinds of address. so that's why the internet phyical topology is a simple dag. wow. never thought of that. the meaning of a phone number or an ip address is the endpoint, not the routing, not the billing, not how i derive the path to the endpoint, not .... randy _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 12:54:48 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17193 for ; Mon, 7 Feb 2000 12:54: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 MAA27040; Mon, 7 Feb 2000 12:52: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 MAA27009 for ; Mon, 7 Feb 2000 12:52:56 -0500 (EST) Received: from PMESMTP01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17167 for ; Mon, 7 Feb 2000 12:54:22 -0500 (EST) Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FPK00IKHN11KG@firewall.mcit.com> for enum@ietf.org; Mon, 7 Feb 2000 17:53:25 +0000 (GMT) Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2]) by omzrelay.mcit.com (8.8.7/) with ESMTP id RAA18499 for ; Mon, 07 Feb 2000 17:53:32 +0000 (GMT) Received: from dwillispc8 ([166.35.225.166]) by omta1.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000207175243.RMXL31786@dwillispc8> for ; Mon, 07 Feb 2000 11:52:43 -0600 Date: Mon, 07 Feb 2000 11:52:27 -0600 From: Dean Willis Subject: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM To: IETF Enum Message-id: <001d01bf7194$18c18f20$a6e123a6@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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit I second Jonathan's position. I think that there will by necessity be a generalization of ENUM to allow for privately administered dialing plans. The obvious way to do this is to define another domain for each private numbering plan. How a client knows which one to use is somebody else's problem. Before anyone can get traction there, ENUM needs to move further along the single-domain E.164 solution path. On the other hand, we do need to keep in mind the assumption that there WILL be other domains, and not make any design choices which preclude such an approach. -- Dean > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: Monday, February 07, 2000 11:12 AM > To: James Yu > Cc: 'Randy Bush'; Richard Shockey; enum@ietf.org; itu+ietf@ietf.org > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > > > James Yu wrote: > > > > This means that the client would need to know which > consortium/domain to use > > when sending the DNS query. It may be fine if the client only > handles calls > > within a consortium/domain. But it won't be true for all the clients. > > I don't think we're trying to solve all aspects of the general problem > here. I think our job is to start with a tld, and from there, figure out > how to formulate the query to get back some kind of useful response. > Deciding who owns these tld's, and how to configure them in clients, is > important but not what we are solving here. > > -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 > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 12:58: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 MAA17269 for ; Mon, 7 Feb 2000 12:58:01 -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 MAA27186; Mon, 7 Feb 2000 12:55:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27111 for ; Mon, 7 Feb 2000 12:55:34 -0500 (EST) Received: from bastiont.npac.com (firewall-user@bastiont.npac.com [208.143.34.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17231; Mon, 7 Feb 2000 12:57:02 -0500 (EST) Received: by bastiont.npac.com; id MAA01380; Mon, 7 Feb 2000 12:57:02 -0500 (EST) Received: from nodnsquery(208.143.39.132) by bastiont.npac.com via smap (V5.0) id xma001184; Mon, 7 Feb 00 12:56:22 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Feb 2000 11:51:58 -0600 Message-ID: From: James Yu To: "'Jonathan Rosenberg'" Cc: "'Randy Bush'" , Richard Shockey , enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 11:48:16 -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 X-BeenThere: enum@ietf.org I agree. But I'm replying to Randy's message that each consortium/domain may use one TLD (or including the 2nd level domain) for its own use. That consortium/domain may only handle certain phone numbers, not all of them. We should be looking for a scheme that can cover the aspects we can think of. James > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, February 07, 2000 12:12 PM > To: James Yu > Cc: 'Randy Bush'; Richard Shockey; enum@ietf.org; itu+ietf@ietf.org > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > > > James Yu wrote: > > > > This means that the client would need to know which > consortium/domain to use > > when sending the DNS query. It may be fine if the client > only handles calls > > within a consortium/domain. But it won't be true for all > the clients. > > I don't think we're trying to solve all aspects of the general problem > here. I think our job is to start with a tld, and from there, > figure out > how to formulate the query to get back some kind of useful response. > Deciding who owns these tld's, and how to configure them in > clients, is > important but not what we are solving here. > > -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 Feb 7 12:59: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 MAA17367 for ; Mon, 7 Feb 2000 12:59: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 MAA27322; Mon, 7 Feb 2000 12:57:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27254 for ; Mon, 7 Feb 2000 12:56:59 -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 MAA17315; Mon, 7 Feb 2000 12:58:25 -0500 (EST) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id JAA28227; Mon, 7 Feb 2000 09:58:18 -0800 (PST) From: Bill Manning Message-Id: <200002071758.JAA28227@boreas.isi.edu> Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM To: randy@psg.com (Randy Bush) Date: Mon, 7 Feb 2000 09:58:18 -0800 (PST) Cc: moore@cs.utk.edu (Keith Moore), enum@ietf.org, itu+ietf@ietf.org In-Reply-To: from "Randy Bush" at Feb 07, 2000 09:53:20 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit % % > seems like users' interests are best served by having a consistent % > meaning, everywhere, for both kinds of address. % % so that's why the internet phyical topology is a simple dag. wow. never % thought of that. % % the meaning of a phone number or an ip address is the endpoint, not the % routing, not the billing, not how i derive the path to the endpoint, not % .... % % randy % then just use the e164 RR and go home, your job here is done. -- --bill _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 12:59: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 MAA17419 for ; Mon, 7 Feb 2000 12:59:29 -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 MAA27437; Mon, 7 Feb 2000 12:57: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 MAA27364 for ; Mon, 7 Feb 2000 12:57:37 -0500 (EST) Received: from bastiont.npac.com (firewall-user@bastiont.npac.com [208.143.34.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17377; Mon, 7 Feb 2000 12:59:03 -0500 (EST) Received: by bastiont.npac.com; id MAA02118; Mon, 7 Feb 2000 12:59:02 -0500 (EST) Received: from nodnsquery(208.143.39.132) by bastiont.npac.com via smap (V5.0) id xma001962; Mon, 7 Feb 00 12:58:37 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Feb 2000 11:54:13 -0600 Message-ID: From: James Yu To: "'Randy Bush'" Cc: enum@ietf.org, itu+ietf@ietf.org, Keith Moore Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 11:51:21 -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 X-BeenThere: enum@ietf.org Randy, Shouldn't those be handled by the NAPTRs/SRVs instead of TLDs? James > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, February 07, 2000 12:53 PM > To: Keith Moore > Cc: enum@ietf.org; itu+ietf@ietf.org > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry > for ENUM > > > > seems like users' interests are best served by having a consistent > > meaning, everywhere, for both kinds of address. > > so that's why the internet phyical topology is a simple dag. > wow. never > thought of that. > > the meaning of a phone number or an ip address is the > endpoint, not the > routing, not the billing, not how i derive the path to the > endpoint, not > .... > > randy > > _______________________________________________ > ITU+IETF mailing list > ITU+IETF@ietf.org > http://www.ietf.org/mailman/listinfo/itu+ietf > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 13:03: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 NAA17653 for ; Mon, 7 Feb 2000 13:03:05 -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 MAA27586; Mon, 7 Feb 2000 12:59:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27515 for ; Mon, 7 Feb 2000 12:59:52 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17550; Mon, 7 Feb 2000 13:01:16 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA20955; Mon, 7 Feb 2000 13:00:47 -0500 (EST) Message-Id: <200002071800.NAA20955@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Bush cc: Keith Moore , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: Your message of "Mon, 07 Feb 2000 09:53:20 PST." Date: Mon, 07 Feb 2000 13:00:47 -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > seems like users' interests are best served by having a consistent > > meaning, everywhere, for both kinds of address. > > so that's why the internet phyical topology is a simple dag. wow. never > thought of that. I think you're missing the point. > the meaning of a phone number or an ip address is the endpoint, not the > routing, not the billing, not how i derive the path to the endpoint, not > .... I agree, but you appear to be confusing the multipath routing problem with the database consistency problem. I have no problem in principle with having multiple ways to look up phone numbers as long as, in practice, the meanings are reasonably consistent and up-to-date. but I suspect that it's easier to figure out how to get multiple parties to share a single federation tree than to keep several mutually autonomous trees consistent with one another. Keith _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 13:05:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17755 for ; Mon, 7 Feb 2000 13:05:11 -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 NAA27855; Mon, 7 Feb 2000 13:03:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27788 for ; Mon, 7 Feb 2000 13:03:12 -0500 (EST) Received: from roam.psg.com (t75.nanog.exodus.net [216.33.132.75] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17711; Mon, 7 Feb 2000 13:04:38 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12HsWf-0001LZ-00; Mon, 07 Feb 2000 10:04:41 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: James Yu Cc: enum@ietf.org, itu+ietf@ietf.org, Keith Moore Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: Message-Id: Date: Mon, 07 Feb 2000 10:04:41 -0800 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > Shouldn't those be handled by the NAPTRs/SRVs instead of TLDs? different tlds allow non-interaction/coordination between consortia. and these are really the same service using different provicers. randy _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 13:05:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17781 for ; Mon, 7 Feb 2000 13:05:36 -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 NAA27921; Mon, 7 Feb 2000 13:03:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27888 for ; Mon, 7 Feb 2000 13:03:36 -0500 (EST) Received: from bastiont.npac.com (firewall-user@bastiont.npac.com [208.143.34.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17747 for ; Mon, 7 Feb 2000 13:05:03 -0500 (EST) Received: by bastiont.npac.com; id NAA03453; Mon, 7 Feb 2000 13:05:03 -0500 (EST) Received: from nodnsquery(208.143.39.132) by bastiont.npac.com via smap (V5.0) id xma003378; Mon, 7 Feb 00 13:04:07 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Feb 2000 11:59:43 -0600 Message-ID: From: James Yu To: "'Dean Willis'" Cc: IETF Enum Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 11:55:12 -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 X-BeenThere: enum@ietf.org Dean, Agree with what you said; however, I don't consider private numbering plans part of E.164. We are addressing E.164 numbers defined by ITU-TS. Other private numbering plans using different domains is a separate issue. James > -----Original Message----- > From: Dean Willis [mailto:dean.willis@wcom.com] > Sent: Monday, February 07, 2000 12:52 PM > To: IETF Enum > Subject: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > > I second Jonathan's position. I think that there will by > necessity be a > generalization of ENUM to allow for privately administered > dialing plans. > The obvious way to do this is to define another domain for > each private > numbering plan. How a client knows which one to use is somebody else's > problem. Before anyone can get traction there, ENUM needs to > move further > along the single-domain E.164 solution path. On the other > hand, we do need > to keep in mind the assumption that there WILL be other > domains, and not > make any design choices which preclude such an approach. > > -- > Dean > > > -----Original Message----- > > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > > Jonathan Rosenberg > > Sent: Monday, February 07, 2000 11:12 AM > > To: James Yu > > Cc: 'Randy Bush'; Richard Shockey; enum@ietf.org; itu+ietf@ietf.org > > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS > entry for ENUM > > > > > > > > > > James Yu wrote: > > > > > > This means that the client would need to know which > > consortium/domain to use > > > when sending the DNS query. It may be fine if the client only > > handles calls > > > within a consortium/domain. But it won't be true for all > the clients. > > > > I don't think we're trying to solve all aspects of the > general problem > > here. I think our job is to start with a tld, and from > there, figure out > > how to formulate the query to get back some kind of useful response. > > Deciding who owns these tld's, and how to configure them in > clients, is > > important but not what we are solving here. > > > > -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 > > > > > _______________________________________________ > 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 Feb 7 13:08: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 NAA17840 for ; Mon, 7 Feb 2000 13:08: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 NAA28059; Mon, 7 Feb 2000 13:06: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 NAA27993 for ; Mon, 7 Feb 2000 13:06:36 -0500 (EST) Received: from roam.psg.com (t75.nanog.exodus.net [216.33.132.75] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17816; Mon, 7 Feb 2000 13:08:02 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12HsZd-0001Lf-00; Mon, 07 Feb 2000 10:07:45 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Keith Moore Cc: enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <200002071800.NAA20955@astro.cs.utk.edu> Message-Id: Date: Mon, 07 Feb 2000 10:07:45 -0800 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > I have no problem in principle with having multiple ways to look up > phone numbers as long as, in practice, the meanings are reasonably > consistent and up-to-date. 411? 611? i.e. for varying values of consistent. and that's the point. [ spoil your lunch and think of the interaction of this with dname, but it may help your consistency desires ] randy _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 13:17:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18028 for ; Mon, 7 Feb 2000 13:17:07 -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 NAA28317; Mon, 7 Feb 2000 13:14:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28269 for ; Mon, 7 Feb 2000 13:14:28 -0500 (EST) Received: from mandarin.com (mail.mandarin.com [212.212.92.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17999; Mon, 7 Feb 2000 13:15:53 -0500 (EST) Received: from mandarin.com ([127.0.0.1]) by mandarin.com with SMTP (NetNow!/3.0.0.999) id MNDR75300445; Mon, 07 Feb 2000 18:13:55 -0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 7 Feb 2000 18:13 +0000 (GMT Standard Time) From: Management@numbering.com (Richard D G Cox) To: enum@ietf.org In-Reply-To: <200002071511.KAA20311@optimus.ietf.org> Reply-To: Management@numbering.com Message-Id: X-Hops: 1 Subject: [Enum] Re: Structure of DNS entry for ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Richard Shockey wrote: > realistically we can use any domain and TLD we can agree on.... Indeed. Using e164 is something of a hostage to fortune; it's not _that_ long since the standard was E.163 rather than E.164! At any time ITU-T could propose a new set of standards and a new E. number to go with them. Perhaps - given the significance of this - we should consider whether a separate (virtual) country-TLD is called for here? Of course, there's nothing to stop us continuing to use the e164.int as a placeholder in our discussions in ENUM! Anne Brown replied to : >> Please clarify "the owner of the telephone number" in Section 3.11. >> Is it the subscriber that is assigned the telephone number or the >> service provider that currently serves that number? > Section 3.11 on Privacy states that "The system MUST allow the owner > of the telephone number to control the information which prospective > callers may receive." I recommend replacing the text with "The system > MUST allow the user to whom the telephone number was assigned, the > ability to control the information...". This potato is hotter than you might have realised: we haven't yet defined the "user" (of the telephone network services) with sufficient clarity to avoid the sort of dispute that some of us are expecting/dreading. I don't have an answer to offer that I'm happy with, but give thought to the sort of situation where a paging bureau, message bureau, fax-to-email service etc. set up facilities and then offer them to downstream users. The bureau (or service provider) may not (depending on the country) be subject to the mandatory number portability requirement, but will normally have been assigned a block of telephone numbers (usually delivered using DNIS/DDI over a T1 or an E1) which they then sub-allocate to users. Which is to be the "user" for the purposes of Section 3.11? It's possible to make an arbitrary decision based on any one specific circumstance, but far harder to define an algorithmic rule that scales up or down to fit all the circumstances we are likely to come across! Richard Cox Mandarin Technology, Penarth, UK +44 (29) 2031 1131 _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 13:28:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18232 for ; Mon, 7 Feb 2000 13:28: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 NAA28751; Mon, 7 Feb 2000 13:25:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28679 for ; Mon, 7 Feb 2000 13:25:38 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18184; Mon, 7 Feb 2000 13:27:05 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA21129; Mon, 7 Feb 2000 13:26:57 -0500 (EST) Message-Id: <200002071826.NAA21129@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Bush cc: Keith Moore , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: Your message of "Mon, 07 Feb 2000 10:07:45 PST." Date: Mon, 07 Feb 2000 13:26:57 -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > I have no problem in principle with having multiple ways to look up > > phone numbers as long as, in practice, the meanings are reasonably > > consistent and up-to-date. > > 411? 611? i.e. for varying values of consistent. and that's the point. these are not e164 numbers. perhaps it's a good idea to handle these things, but that is not a compelling argument for multiple lookup services for e164 space. in general I would consider such things to be more akin to prefix handling (i.e. how do you map local dialling conventions onto real phone numbers) than to phone number lookup. Keith _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 13:31:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18313 for ; Mon, 7 Feb 2000 13:31:01 -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 NAA28867; Mon, 7 Feb 2000 13:27:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28832 for ; Mon, 7 Feb 2000 13:27:47 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18253 for ; Mon, 7 Feb 2000 13:29:14 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA21143; Mon, 7 Feb 2000 13:29:00 -0500 (EST) Message-Id: <200002071829.NAA21143@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Management@numbering.com cc: enum@ietf.org In-reply-to: Your message of "Mon, 07 Feb 2000 18:13:00 GMT." X-SUBJECT-MSG-FROM: Management@numbering.com (Richard D G Cox) Date: Mon, 07 Feb 2000 13:29:00 -0500 Subject: [Enum] Re: [ITU+IETF] Re: Structure of DNS entry for ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > Perhaps - given the significance of this - we should consider whether a > separate (virtual) country-TLD is called for here? seems like a rathole. design the scheme right and it can use any DNS name as its root. trying to figure out how to get a new TLD approved by ICANN would not be an effective use of this group's time. Keith _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 13:37:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18485 for ; Mon, 7 Feb 2000 13:37:04 -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 NAA29236; Mon, 7 Feb 2000 13:34:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29202 for ; Mon, 7 Feb 2000 13:34:54 -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 NAA18467 for ; Mon, 7 Feb 2000 13:36:21 -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 KAA24957 for ; Mon, 7 Feb 2000 10:35:57 -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 KAA29035 for ; Mon, 7 Feb 2000 10:36:19 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP for enum@ietf.org; Mon, 7 Feb 2000 10:36:11 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Feb 2000 13:36:10 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDDF@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: enum@ietf.org Date: Mon, 7 Feb 2000 13:36:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Enum] Q on portable numbers Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Since portable numbers don't themselves imply any sort of routing hierarchy, I think of them as being more analogous to MAC addresses than to IP addresses. (The NPDB does the translation to a real E.164 number?) What's the accepted policy on these? Are they still considered to be E.164? If you move between countries, are you allowed to keep your portable number? This should not impact enum, since one might not know whether the number is portable or not? Bert albert.e.manfredi@boeing.com _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 14:32:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19768 for ; Mon, 7 Feb 2000 14:32:36 -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 OAA00877; Mon, 7 Feb 2000 14:28: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 OAA00818 for ; Mon, 7 Feb 2000 14:28:34 -0500 (EST) Received: from hubbub.cisco.com (hubbub.cisco.com [171.69.11.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19654; Mon, 7 Feb 2000 14:29:57 -0500 (EST) Received: from ORANLT ([171.69.210.5]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id LAA17735; Mon, 7 Feb 2000 11:28:20 -0800 (PST) From: "David Oran" To: "Keith Moore" , "Randy Bush" Cc: "Bill Manning" , "Richard Shockey" , , Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 14:28:20 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200002071743.MAA20656@astro.cs.utk.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Perhaps because some people want to use enum for resolving telephone numbers other than e.164 globally-unique numbers, such as: 800 numbers (really names) 700 numbers (really names) private numbering plans I agree that if something is really truly a globally unique E.164 number there should be ony and only one root for resolving them. Unfortunately, you can't look at a string of digits and know that, unlike an IP address. > -----Original Message----- > From: itu+ietf-admin@ietf.org [mailto:itu+ietf-admin@ietf.org]On Behalf > Of Keith Moore > Sent: Monday, February 07, 2000 12:43 PM > To: Randy Bush > Cc: Bill Manning; Richard Shockey; enum@ietf.org; itu+ietf@ietf.org > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > > > I find this hard to fathom. > > > > i am not surprised > > well, it would seem odd for IETF to insist on consistency of > meaning for IP numbers (modulo private address space) but not > care about consistency of meaning for E.164 numbers. > > seems like users' interests are best served by having a consistent > meaning, everywhere, for both kinds of address. > > Keith > > _______________________________________________ > ITU+IETF mailing list > ITU+IETF@ietf.org > http://www.ietf.org/mailman/listinfo/itu+ietf > > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 14:36:21 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 OAA19955 for ; Mon, 7 Feb 2000 14:36: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 OAA01174; Mon, 7 Feb 2000 14:33:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01108 for ; Mon, 7 Feb 2000 14:32:59 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19917; Mon, 7 Feb 2000 14:34:25 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA21355; Mon, 7 Feb 2000 14:33:07 -0500 (EST) Message-Id: <200002071933.OAA21355@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "David Oran" cc: "Keith Moore" , "Randy Bush" , "Bill Manning" , "Richard Shockey" , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: Your message of "Mon, 07 Feb 2000 14:28:20 EST." Date: Mon, 07 Feb 2000 14:33:06 -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > Perhaps because some people want to use enum for resolving telephone numbers > other than e.164 globally-unique numbers, such as: > 800 numbers (really names) > 700 numbers (really names) > private numbering plans > > I agree that if something is really truly a globally unique E.164 number > there should be ony and only one root for resolving them. Unfortunately, you > can't look at a string of digits and know that, unlike an IP address. and I agree that local/regional dialing conventions have to be supported. but I was assuming that they would be supported by some mechanism other than the DNS tree used for global E.164 numbers. And while you can probably use DNS tricks to handle a lot of local dialing conventions, it's not clear that you want to standardize on that approach. (how do you do intermediate dial tones, for instance?) Keith _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 14:38:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19995 for ; Mon, 7 Feb 2000 14:38:05 -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 OAA01344; Mon, 7 Feb 2000 14:35:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01273 for ; Mon, 7 Feb 2000 14:35:53 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19972; Mon, 7 Feb 2000 14:37:17 -0500 (EST) From: Melinda.Shore@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id VAA19916; Mon, 7 Feb 2000 21:37:13 +0200 (EET) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id VAA16044; Mon, 7 Feb 2000 21:37:12 +0200 (EET) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Feb 2000 13:36:39 -0600 Message-ID: To: randy@psg.com Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 13:36:57 -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 X-BeenThere: enum@ietf.org > the meaning of a phone number or an ip address is the > endpoint, not the routing, not the billing, not how i > derive the path to the endpoint, not .... Alas, it's just not that simple anymore, especially when you take things like NAT into account. An E.164 address represents an endpoint (or user), but it unfortunately cannot reliably represent an IP address. There's a great big disconnect there, but fortunately if we accept the notion that the E.164 address is mapping to something else (like an H.323 gatekeeper), it gives us a leg up on the NAT problem. Melinda -- Melinda Shore Nokia IP Telephony 127 West State Street "Software longa, Ithaca, NY 14850 hardware brevis" +1 607 273 0724 (office) +1 607 275 3610 (fax) +1 607 227 4096 (mobile) melinda.shore@nokia.com _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Feb 7 15:21:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20850 for ; Mon, 7 Feb 2000 15:21: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 PAA02930; Mon, 7 Feb 2000 15:18: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 PAA02814 for ; Mon, 7 Feb 2000 15:18:34 -0500 (EST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20778; Mon, 7 Feb 2000 15:19:47 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id PAA22227; Mon, 7 Feb 2000 15:19:13 -0500 (EST) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id PAA22001; Mon, 7 Feb 2000 15:18:36 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2448.0) id <1H1F0VWH>; Mon, 7 Feb 2000 15:19:10 -0500 Message-ID: From: "Lind, Steven D, ALARC" To: "'David Oran'" , Keith Moore , Randy Bush Cc: Bill Manning , Richard Shockey , enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 15:19:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Perhaps because some people want to use enum for resolving telephone numbers other than e.164 globally-unique numbers, such as: 800 numbers (really names) 700 numbers (really names) private numbering plans 800 and 700 numbers are E.164 numbers. Fully qualified, they would be +1 800 xxx xxxx or +1 700 xxx xxxx. Other countries have similar free phone services with their own set of E.164 numbers. Steve Lind --------------------------------------------------------------- Steven D. Lind Tel: (973) 236-6787 AT&T Fax: (973) 236-6452 180 Park Ave., Bldg. 2 e-mail: sdlind@att.com Florham Park, NJ 07932 --------------------------------------------------------------- > -----Original Message----- > From: David Oran [SMTP:oran@cisco.com] > Sent: Monday, February 07, 2000 2:28 PM > To: Keith Moore; Randy Bush > Cc: Bill Manning; Richard Shockey; enum@ietf.org; itu+ietf@ietf.org > Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for > ENUM > > Perhaps because some people want to use enum for resolving telephone > numbers > other than e.164 globally-unique numbers, such as: > 800 numbers (really names) > 700 numbers (really names) > private numbering plans > > I agree that if something is really truly a globally unique E.164 number > there should be ony and only one root for resolving them. Unfortunately, > you > can't look at a string of digits and know that, unlike an IP address. > > > -----Original Message----- > > From: itu+ietf-admin@ietf.org [mailto:itu+ietf-admin@ietf.org]On Behalf > > Of Keith Moore > > Sent: Monday, February 07, 2000 12:43 PM > > To: Randy Bush > > Cc: Bill Manning; Richard Shockey; enum@ietf.org; itu+ietf@ietf.org > > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > > > > > > I find this hard to fathom. > > > > > > i am not surprised > > > > well, it would seem odd for IETF to insist on consistency of > > meaning for IP numbers (modulo private address space) but not > > care about consistency of meaning for E.164 numbers. > > > > seems like users' interests are best served by having a consistent > > meaning, everywhere, for both kinds of address. > > > > Keith > > > > _______________________________________________ > > ITU+IETF mailing list > > ITU+IETF@ietf.org > > http://www.ietf.org/mailman/listinfo/itu+ietf > > > > > > > _______________________________________________ > 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 Feb 7 15: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 PAA20897 for ; Mon, 7 Feb 2000 15: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 PAA03100; Mon, 7 Feb 2000 15:22:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03063 for ; Mon, 7 Feb 2000 15:21:59 -0500 (EST) Received: from bastiont.npac.com (firewall-user@bastiont.npac.com [208.143.34.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20889 for ; Mon, 7 Feb 2000 15:23:26 -0500 (EST) Received: by bastiont.npac.com; id PAA02179; Mon, 7 Feb 2000 15:23:27 -0500 (EST) Received: from nodnsquery(208.143.39.132) by bastiont.npac.com via smap (V5.0) id xma002105; Mon, 7 Feb 00 15:22:57 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Feb 2000 14:18:33 -0600 Message-ID: From: James Yu To: "'Manfredi, Albert E'" Cc: enum@ietf.org Subject: RE: [Enum] Q on portable numbers Date: Mon, 7 Feb 2000 14:15:06 -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 X-BeenThere: enum@ietf.org Bert, Please see my responses. James > -----Original Message----- > From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] > Sent: Monday, February 07, 2000 1:36 PM > To: enum@ietf.org > Subject: [Enum] Q on portable numbers > > > Since portable numbers don't themselves imply any sort of > routing hierarchy, > I think of them as being more analogous to MAC addresses than to IP > addresses. (The NPDB does the translation to a real E.164 number?) The NPDB maps an end user's E.164 number to a routing number. In the North American, it is called Location Routing Number (LRN), a ten-digit North American Numbering Plan Number (e.g., a national E.164 number, or an E.164 number without country code 1). The "routing number" is Europe is called a routing prefix. Its length may vary depending on the country and it identifies either the serving network (another DB query at the serving network may be needed to determine the serving switch) or a serving switch. The dialed E.164 number is analogous to the domain name instead of the MAC address. The LRN or routing prefix (adding the country code to have the "international" flavor) may be analogous to the IP address but is not quite the same. Because in many cases, an IP address identifies an end point (e.g., host). If NAT is used, then that NAT's IP address is analogous to the LRN or Routing prefix. The MAC address is analogous to the line card at the GSTN switch. > > What's the accepted policy on these? Are they still > considered to be E.164? > If you move between countries, are you allowed to keep your > portable number? Number portability supported today is called service provider portability. No location change. Location portability will happen eventually. For example, in the U.S., it may first begin at the state level, then at the region level (U.S. is divided into seven regiions based on the seven Regional Bell Operating Companies' serving areas), then whole nation. But international number portability for the "regular" E.164 numbers (e.g., numbers assigned to typical phone users) may be a long way to go. ITU-TS has defined some country codes for services such as Universal Personal Telecommunications (UPT) service. Country code 878 has been assigned. E.168 has the information about the UPT numbering plan. 878+878 has been reserved as a global code (to be used across national boundaries) and 878 + country code is assigned to each country for assignment within that country. An administration process may be required to support the global code assignment and to allow number portability. > > This should not impact enum, since one might not know whether > the number is > portable or not? ENUM is supposed to retrieve the information related to E.164 numbers, ported or not, so that a client can make use of the information for call routing, e-mail delivery or to go to other places for more information (e.g., LDAP database). > > Bert > albert.e.manfredi@boeing.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 Tue Feb 8 03:32: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 DAA12415 for ; Tue, 8 Feb 2000 03:32: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 DAA28219; Tue, 8 Feb 2000 03:26:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28193 for ; Tue, 8 Feb 2000 03:26:37 -0500 (EST) Received: from mailrelay2.alcatel.de (mailrelay3.alcatel.de [194.113.59.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12325 for ; Tue, 8 Feb 2000 03:28:04 -0500 (EST) From: M.Muench@alcatel.de Received: from slsms2a.stgl.netd.alcatel.de by mailrelay2.alcatel.de with SMTP (XT-PP) with ESMTP; Tue, 8 Feb 2000 09:24:58 +0100 Received: from localhost (root@localhost) by slsms2a.stgl.netd.alcatel.de (8.8.6 (PHNE_15509)/8.8.6) with SMTP id JAA28115; Tue, 8 Feb 2000 09:25:14 +0100 (MET) X-OpenMail-Hops: 1 Date: Tue, 8 Feb 2000 09:25:08 +0100 Message-Id: Subject: RE: [Enum] Q on portable numbers MIME-Version: 1.0 TO: james.yu@neustar.com, Albert.Manfredi@PHL.Boeing.com CC: enum@ietf.org Content-Type: text/plain; charset=US-ASCII; name="RE:" Content-Disposition: inline; filename="RE:" 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Hello all, I am Monika Muench from Alcatel Germany. I was involved in the standardisation work on Number Portabiltiy in Europe (ETSI) but also worldwide (ITU-T). I want to make small corrections to James' reply regarding the NP solution in Europe. In Europe and in the ITU-T standard the routing number is called "network routing number" and *not* "routing prefix". The dialled number is called "directory number", that is the number which can be found in the telephone directory. Regards, Monika ------------------------------------------------ Monika Muench email: m.muench@alcatel.de Alcatel Germany D-70430 Stuttgart ---------- From: james.yu@neustar.com To: Albert.Manfredi@PHL.Boeing.com Cc: enum@ietf.org Subject: RE: [Enum] Q on portable numbers Date: Monday, February 07, 2000 9:15PM Bert, Please see my responses. James > -----Original Message----- > From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] > Sent: Monday, February 07, 2000 1:36 PM > To: enum@ietf.org > Subject: [Enum] Q on portable numbers > > > Since portable numbers don't themselves imply any sort of > routing hierarchy, > I think of them as being more analogous to MAC addresses than to IP > addresses. (The NPDB does the translation to a real E.164 number?) The NPDB maps an end user's E.164 number to a routing number. In the North American, it is called Location Routing Number (LRN), a ten-digit North American Numbering Plan Number (e.g., a national E.164 number, or an E.164 number without country code 1). The "routing number" is Europe is called a routing prefix. Its length may vary depending on the country and it identifies either the serving network (another DB query at the serving network may be needed to determine the serving switch) or a serving switch. The dialed E.164 number is analogous to the domain name instead of the MAC address. The LRN or routing prefix (adding the country code to have the "international" flavor) may be analogous to the IP address but is not quite the same. Because in many cases, an IP address identifies an end point (e.g., host). If NAT is used, then that NAT's IP address is analogous to the LRN or Routing prefix. The MAC address is analogous to the line card at the GSTN switch. > > What's the accepted policy on these? Are they still > considered to be E.164? > If you move between countries, are you allowed to keep your > portable number? Number portability supported today is called service provider portability. No location change. Location portability will happen eventually. For example, in the U.S., it may first begin at the state level, then at the region level (U.S. is divided into seven regiions based on the seven Regional Bell Operating Companies' serving areas), then whole nation. But international number portability for the "regular" E.164 numbers (e.g., numbers assigned to typical phone users) may be a long way to go. ITU-TS has defined some country codes for services such as Universal Personal Telecommunications (UPT) service. Country code 878 has been assigned. E.168 has the information about the UPT numbering plan. 878+878 has been reserved as a global code (to be used across national boundaries) and 878 + country code is assigned to each country for assignment within that country. An administration process may be required to support the global code assignment and to allow number portability. > > This should not impact enum, since one might not know whether > the number is > portable or not? ENUM is supposed to retrieve the information related to E.164 numbers, ported or not, so that a client can make use of the information for call routing, e-mail delivery or to go to other places for more information (e.g., LDAP database). > > Bert > albert.e.manfredi@boeing.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 _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Feb 8 03:32:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12426 for ; Tue, 8 Feb 2000 03:32: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 DAA28282; Tue, 8 Feb 2000 03:27:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28252 for ; Tue, 8 Feb 2000 03:27:29 -0500 (EST) Received: from relay.cwplc.com ([194.6.6.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12328 for ; Tue, 8 Feb 2000 03:28:51 -0500 (EST) Received: from gb-cwc-wtn-msw4 ([148.185.175.64]) by relay.cwplc.com (Pro-8.9.3/8.9.3) with ESMTP id IAA10052 for ; Tue, 8 Feb 2000 08:28:44 GMT Received: from gb-cwc-wtn-i02.isops.mercury.co.uk (unverified) by gb-cwc-wtn-msw4 (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 08 Feb 2000 08:28:16 +0000 Received: by gb-cwc-wtn-io2.isops.cwcom.co.uk with Internet Mail Service (5.5.2650.21) id <1NCGXPFD>; Tue, 8 Feb 2000 08:18:08 -0000 Message-Id: <29B7C7A8E3E4D111ABDB0000F80864000318FE98@gbcwcbrtm003.isops.cwcom.co.uk> From: "Rosbotham, Paul" To: "'James Yu'" , "'Anne Brown'" Cc: "'enum@ietf.org'" Subject: RE: [Enum] ENUM Requirements Date: Tue, 8 Feb 2000 08:33:53 -0000 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 X-BeenThere: enum@ietf.org Regarding portability: Agreed that there needs to be some kind of mechanism for dealing with LNP/GNP/Service Provider portability (different names for the same thing). In principle, there is no reason why Enum shouldn't need to cope with E.164 numbers being ported * between a circuit switched and an IP network * within an IP network * between an IP network and a circuit switched network Given that ENUM converts from a E.164 number to a set of mechanisms of locating that number (SIP, potscall etc), in principle it should accommodate the above. However, for the first porting case, the call is incoming from the GSTN and the trigger is not in fact an E.164 number, but an "E.164-like" number. In the USA solution, a LRN is applied, in Europe a (non-internationally significant) routeing prefix is used etc. I don't think this discredits ENUM, insofar as the scope of the work is specifically about conversion from E.164; what it means is that ENUM will not accommodate portability as it is currently scoped. The two solutions around this that I see are that either ENUM is expanded in scope, or "ENUM-like" techniques are used on a separate tld to accommodate in-ported numbers. For example, if a UK routeing number of 51234501344713246 were to be received, this could be accommodated by triggering an ENUM-like mechanism with 6.4.2.3.1.7.4.4.3.1.0.5.4.3.2.1.5.uk.ported.e164.int. There is an issue that the client would need to know that the input number was a routeing number versus an E.164, but in general such things are conveyed in the (GSTN) signalling. As such, if the first approach is taken (expand ENUM), then James' text is best. If the latter approach, then Anne's proposed change is acceptable but once we get ENUM to generally acceptable state, then we could do with an EPORT... Regards Paul -----Original Message----- From: James Yu [SMTP:james.yu@neustar.com] Sent: Monday, February 07, 2000 4:15 PM To: 'Anne Brown' Cc: 'enum@ietf.org' Subject: RE: [Enum] ENUM Requirements Ann, The need to be aware of the existing LNP implementations will ensure that the ENUM scheme will provide a common mechanism for retrieving the information that currently reside on various LNP databases. I have no problem with the last two comments. James -----Original Message----- From: Anne Brown [mailto:arbrown@nortelnetworks.com] Sent: Monday, February 07, 2000 10:11 AM To: 'James Yu' Cc: 'enum@ietf.org' Subject: RE: [Enum] ENUM Requirements James, My comments below. Regards, Anne BM__MailData-----Original Message----- From: James Yu [ mailto:james.yu@neustar.com ] Sent: February 07, 2000 9:22 AM To: Brown, Anne [NORSE:5N00:EXCH] Cc: 'enum@ietf.org' Subject: [Enum] ENUM Requirements Ann, NeuStar submitted some proposed revisions to the draft-ietf-enum-rqmts-00.on 12/8. Since it did not generate any discussion, we are resubmitting the proposed changes but with some modifications. We suggest that the discussion be based on the changes proposed in this message and have the changes incorporated into the enum requirements document. People familiar with the post dialing delays please help in identifying the post dialing delay requirement for the international calls in the GSTN today. The reason is that the same post dialing delay requirement will apply to the scenario where a call is originated from the GSTN to the GSTN via the Internet. We suggest to revise sections 3.7 and 3.9 (see proposed texts below) and clarify 3.11 in draft-ietf-enum-rqmts-00. 3.7 Number Portability The system MUST take into consideration of all the existing local number portability mechanisms that allow the subscribers to keep their phone numbers when switching from one local access service provider to another, where applicable. It is RECOMMENDED that the system not be designed in such a way as to impede future number portability that allows the subscribers to keep their phone numbers when moving from one physical location to another or changing their subscribed services within or across those systems that use E.164 numbers to identify the end users or terminals/devices. I don't believe that the ENUM service (or protocol or solution) should have to be aware of all existing LNP mechanisms, which is implied by your text. The solution should, however, support the lookup of ported E.164 numbers. Would you agree on the following text: 3.7 Number Portability The system MUST support the retrieval of information, based on an E.164 number, regardless of whether or not the E.164 number is a locally or globally ported number. It is RECOMMENDED that the system..... 3.9 Query Performance The system is not expected to respond to queries with the same performance levels as current GSTN queries; however, the DNS process SHOULD not significantly increase the post dialing delay as perceived by the caller or specified by the regulatory bodies (e.g., 10 seconds for domestic calls). Define "significantly"? I recommend removing the word significantly and changing the text "SHOULD not" to "SHOULD NOT" as per RFC 2119. Please clarify "the owner of the telephone number" in Section 3.11. Is it the subscriber that is assigned the telephone number or the service provider that currently serves that number? Section 3.11 on Privacy states that "The system MUST allow the owner of the telephone number to control the information which prospective callers may receive." I recommend replacing the text with "The system MUST allow the user to whom the telephone number was assigned, the ability to control the information...". James 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 _______________________________________________ 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 Tue Feb 8 08:37: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 IAA19634 for ; Tue, 8 Feb 2000 08:37:01 -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 IAA06894; Tue, 8 Feb 2000 08:34: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 IAA06859 for ; Tue, 8 Feb 2000 08:34:31 -0500 (EST) Received: from bastiont.npac.com (firewall-user@bastiont.npac.com [208.143.34.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19562 for ; Tue, 8 Feb 2000 08:35:59 -0500 (EST) Received: by bastiont.npac.com; id IAA23253; Tue, 8 Feb 2000 08:35:58 -0500 (EST) Received: from nodnsquery(208.143.39.132) by bastiont.npac.com via smap (V5.0) id xma023192; Tue, 8 Feb 00 08:35:11 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Tue, 8 Feb 2000 07:30:47 -0600 Message-ID: From: James Yu To: "'M.Muench@alcatel.de'" Cc: enum@ietf.org Subject: RE: [Enum] Q on portable numbers Date: Tue, 8 Feb 2000 07:27:22 -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 X-BeenThere: enum@ietf.org Monica, Thanks for providing the correct terms used in the ITU-T. We should try to use the standard terms as much as possible. James > -----Original Message----- > From: M.Muench@alcatel.de [mailto:M.Muench@alcatel.de] > Sent: Tuesday, February 08, 2000 3:25 AM > To: james.yu@neustar.com; Albert.Manfredi@PHL.Boeing.com > Cc: enum@ietf.org > Subject: RE: [Enum] Q on portable numbers > > > Hello all, > > I am Monika Muench from Alcatel Germany. I was involved in the > standardisation work on Number Portabiltiy in Europe (ETSI) but also > worldwide (ITU-T). > > I want to make small corrections to James' reply regarding the NP > solution in Europe. > > In Europe and in the ITU-T standard the routing number is called > "network routing number" and *not* "routing prefix". > The dialled number is called "directory number", that is the number > which can be found in the telephone directory. > > Regards, > > Monika > > ------------------------------------------------ > Monika Muench email: m.muench@alcatel.de > Alcatel Germany > D-70430 Stuttgart > > > ---------- > From: james.yu@neustar.com > To: Albert.Manfredi@PHL.Boeing.com > Cc: enum@ietf.org > Subject: RE: [Enum] Q on portable numbers > Date: Monday, February 07, 2000 9:15PM > > Bert, > > Please see my responses. > > James > > -----Original Message----- > > From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] > > Sent: Monday, February 07, 2000 1:36 PM > > To: enum@ietf.org > > Subject: [Enum] Q on portable numbers > > > > > > Since portable numbers don't themselves imply any sort of > > routing hierarchy, > > I think of them as being more analogous to MAC addresses than to IP > > addresses. (The NPDB does the translation to a real E.164 number?) > > The NPDB maps an end user's E.164 number to a routing number. > In the North > American, it is called Location Routing Number (LRN), a > ten-digit North > American Numbering Plan Number (e.g., a national E.164 > number, or an E.164 > number without country code 1). The "routing number" is > Europe is called a > routing prefix. Its length may vary depending on the country and it > identifies either the serving network (another DB query at the serving > network may be needed to determine the serving switch) or a > serving switch. > The dialed E.164 number is analogous to the domain name > instead of the MAC > address. The LRN or routing prefix (adding the country code > to have the > "international" flavor) may be analogous to the IP address > but is not quite > the same. Because in many cases, an IP address identifies an > end point > (e.g., host). If NAT is used, then that NAT's IP address is > analogous to the > LRN or Routing prefix. The MAC address is analogous to the > line card at the > GSTN switch. > > > > > What's the accepted policy on these? Are they still > > considered to be E.164? > > If you move between countries, are you allowed to keep your > > portable number? > > Number portability supported today is called service provider > portability. > No location change. Location portability will happen eventually. For > example, in the U.S., it may first begin at the state level, > then at the > region level (U.S. is divided into seven regiions based on the seven > Regional Bell Operating Companies' serving areas), then whole > nation. But > international number portability for the "regular" E.164 > numbers (e.g., > numbers assigned to typical phone users) may be a long way to go. > > ITU-TS has defined some country codes for services such as Universal > Personal Telecommunications (UPT) service. Country code 878 has been > assigned. E.168 has the information about the UPT numbering > plan. 878+878 > has been reserved as a global code (to be used across > national boundaries) > and 878 + country code is assigned to each country for > assignment within > that country. An administration process may be required to > support the > global code assignment and to allow number portability. > > > > > This should not impact enum, since one might not know whether > > the number is > > portable or not? > > ENUM is supposed to retrieve the information related to E.164 numbers, > ported or not, so that a client can make use of the > information for call > routing, e-mail delivery or to go to other places for more information > (e.g., LDAP database). > > > > > Bert > > albert.e.manfredi@boeing.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 > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Feb 8 08:54: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 IAA20818 for ; Tue, 8 Feb 2000 08:54: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 IAA07582; Tue, 8 Feb 2000 08:52:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07553 for ; Tue, 8 Feb 2000 08:52:30 -0500 (EST) Received: from bastiont.npac.com (firewall-user@bastiont.npac.com [208.143.34.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20800 for ; Tue, 8 Feb 2000 08:53:59 -0500 (EST) Received: by bastiont.npac.com; id IAA24618; Tue, 8 Feb 2000 08:53:58 -0500 (EST) Received: from nodnsquery(208.143.39.132) by bastiont.npac.com via smap (V5.0) id xma024582; Tue, 8 Feb 00 08:53:12 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Tue, 8 Feb 2000 07:48:48 -0600 Message-ID: From: James Yu To: "'Rosbotham, Paul'" Cc: "'enum@ietf.org'" , "'Anne Brown'" Subject: RE: [Enum] ENUM Requirements Date: Tue, 8 Feb 2000 07:44:51 -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 X-BeenThere: enum@ietf.org Paul, For the first porting case, there are two scenarios: (1) NPDB query has been performed at the GSTN before the call is routed to the Internet, and (2) NPDB query has not been performed. You discussed the scenario (1). If both the "network routing number" and "directory number" are passed to the Internet, the network element that handles the call (e.g., GW, GK, or SIP server) should know the existence of both numbers. If DNS scheme is still used for call routing/handling, then the "directory number" would be used to formulate the DNS query. Whether and how the "network routing number" is used by the DNS scheme is to be seen. With the "network routing number," that network element also knows that "NPDB has been performed" so it will not perform a NPDB query even if the DNS scheme returns information about where to get the network routing number information (if the DNS scheme is used to provide that information).] For scenario (2), only the directory number is passed, the DNS scheme will use it to get information about call routing/handling. James > -----Original Message----- > From: Rosbotham, Paul [mailto:Paul.Rosbotham@cwcom.co.uk] > Sent: Tuesday, February 08, 2000 3:34 AM > To: 'James Yu'; 'Anne Brown' > Cc: 'enum@ietf.org' > Subject: RE: [Enum] ENUM Requirements > > > Regarding portability: > Agreed that there needs to be some kind of mechanism for dealing with > LNP/GNP/Service Provider portability (different names for the > same thing). > In principle, there is no reason why Enum shouldn't need to > cope with E.164 > numbers being ported > > * between a circuit switched and an IP network > * within an IP network > * between an IP network and a circuit switched network > > Given that ENUM converts from a E.164 number to a set of mechanisms of > locating that number (SIP, potscall etc), in principle it > should accommodate > the above. However, for the first porting case, the call is > incoming from > the GSTN and the trigger is not in fact an E.164 number, but > an "E.164-like" > number. In the USA solution, a LRN is applied, in Europe a > (non-internationally significant) routeing prefix is used > etc. I don't > think this discredits ENUM, insofar as the scope of the work > is specifically > about conversion from E.164; what it means is that ENUM will > not accommodate > portability as it is currently scoped. > > The two solutions around this that I see are that either ENUM > is expanded in > scope, or "ENUM-like" techniques are used on a separate tld > to accommodate > in-ported numbers. For example, if a UK routeing number of > 51234501344713246 were to be received, this could be accommodated by > triggering an ENUM-like mechanism with > 6.4.2.3.1.7.4.4.3.1.0.5.4.3.2.1.5.uk.ported.e164.int. There > is an issue > that the client would need to know that the input number was > a routeing > number versus an E.164, but in general such things are conveyed in the > (GSTN) signalling. > > As such, if the first approach is taken (expand ENUM), then > James' text is > best. If the latter approach, then Anne's proposed change is > acceptable but > once we get ENUM to generally acceptable state, then we could > do with an > EPORT... > > Regards > > Paul > > -----Original Message----- > From: James Yu [SMTP:james.yu@neustar.com] > Sent: Monday, February 07, 2000 4:15 PM > To: 'Anne Brown' > Cc: 'enum@ietf.org' > Subject: RE: [Enum] ENUM Requirements > > Ann, > > The need to be aware of the existing LNP > implementations will ensure > that > the ENUM scheme will provide a common mechanism for > retrieving the > information that currently reside on various LNP > databases. I have > no > problem with the last two comments. > > James > > -----Original Message----- > From: Anne Brown [mailto:arbrown@nortelnetworks.com] > Sent: Monday, February 07, 2000 10:11 AM > To: 'James Yu' > Cc: 'enum@ietf.org' > Subject: RE: [Enum] ENUM Requirements > > > > James, > > My comments below. > > Regards, > Anne > > > BM__MailData-----Original Message----- > From: James Yu [ mailto:james.yu@neustar.com > > ] > Sent: February 07, 2000 9:22 AM > To: Brown, Anne [NORSE:5N00:EXCH] > Cc: 'enum@ietf.org' > Subject: [Enum] ENUM Requirements > > Ann, > NeuStar submitted some proposed revisions to the > draft-ietf-enum-rqmts-00.on > > 12/8. Since it did not generate any discussion, we are > resubmitting > the > proposed changes but with some modifications. We > suggest that the > discussion be based on the changes proposed in this > message and have > the > changes incorporated into the enum requirements > document. People > familiar > with the post dialing delays please help in identifying the post > dialing > delay requirement for the international calls in the GSTN today. > The reason > > is that the same post dialing delay requirement will > apply to the > scenario > where a call is originated from the GSTN to the GSTN via the > Internet. > We suggest to revise sections 3.7 and 3.9 (see proposed > texts below) > and > clarify 3.11 in draft-ietf-enum-rqmts-00. > 3.7 Number Portability > The system MUST take into consideration of all the > existing local > number > portability mechanisms that allow the subscribers to keep their > phone > numbers when switching from one local access service provider to > another, > where applicable. It is RECOMMENDED that the system not > be designed > in such > a way as to impede future number portability that allows the > subscribers to > keep their phone numbers when moving from one physical > location to > another > or changing their subscribed services within or across > those systems > that > use E.164 numbers to identify the end users or > terminals/devices. > > I don't believe that the ENUM service (or protocol or solution) > should have > to be aware of all existing LNP mechanisms, which is > implied by your > text. > The solution should, however, support the lookup of ported E.164 > numbers. > Would you agree on the following text: > > 3.7 Number Portability > The system MUST support the retrieval of information, > based on an > E.164 > number, regardless of whether or not the E.164 number > is a locally > or > globally ported number. It is RECOMMENDED that the system..... > > > 3.9 Query Performance > The system is not expected to respond to queries with the same > performance > levels as current GSTN queries; however, the DNS > process SHOULD not > significantly increase the post dialing delay as > perceived by the > caller or > specified by the regulatory bodies (e.g., 10 seconds > for domestic > calls). > > Define "significantly"? I recommend removing the word > significantly > and > changing the text "SHOULD not" to "SHOULD NOT" as per > RFC 2119. > > > > Please clarify "the owner of the telephone number" in > Section 3.11. > Is it > the subscriber that is assigned the telephone number or > the service > provider > > that currently serves that number? > > Section 3.11 on Privacy states that "The system MUST > allow the owner > of the > telephone number to control the information which prospective > callers may > receive." I recommend replacing the text with "The system MUST > allow the > user to whom the telephone number was assigned, the ability to > control the > information...". > > James > > 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 > > > > _______________________________________________ > 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 Tue Feb 8 10:41: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 KAA27956 for ; Tue, 8 Feb 2000 10:41: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 KAA12812; Tue, 8 Feb 2000 10:38: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 KAA12781 for ; Tue, 8 Feb 2000 10:38:32 -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 KAA27876 for ; Tue, 8 Feb 2000 10:40:01 -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 HAA11132 for ; Tue, 8 Feb 2000 07:39:37 -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 HAA20509 for ; Tue, 8 Feb 2000 07:40:01 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Tue, 8 Feb 2000 07:39:49 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Tue, 8 Feb 2000 10:39:48 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDE5@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'m.muench@alcatel.de'" Cc: enum@ietf.org Subject: RE: [Enum] Q on portable numbers Date: Tue, 8 Feb 2000 10:39:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org M.Muench@alcatel.de [mailto:M.Muench@alcatel.de] wrote: > Hello all, > > I am Monika Muench from Alcatel Germany. I was involved in the > standardisation work on Number Portabiltiy in Europe (ETSI) but also > worldwide (ITU-T). > > I want to make small corrections to James' reply regarding the NP > solution in Europe. > > In Europe and in the ITU-T standard the routing number is called > "network routing number" and *not* "routing prefix". > The dialled number is called "directory number", that is the number > which can be found in the telephone directory. That makes sense to me. It says that the directory number is basically an arbitrary number, used only for lookup purposes. As far as routing goes, it is as flat as a MAC address is (compared with IP or other Layer 3 address). Using a portable phone number would be a process sort of analogous to RARP (Reverse ARP: station has its MAC address and has to acquire its IP address from a server somewhere in the LAN). Only in this case, it is the routable address of the destination that one is searching for. I was wondering if, and why, these portable numbers would be called E.164, and I guess the answer is that they are not, or soon will not be. So they are outside the scope of this discussion. But just to carry this on slightly longer, supporting truly globally portable telephone numbers seems to me to be well within the capabilities of the DNS. If these portable numbers can be identified, and they must be identifiable, they can either be placed in the same database as e164.int or they can be placed in exxx.int. No? Yes? Even the telephone community could use the DNS for this, I would think. Bert albert.e.manfredi@boeing.com _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Feb 8 12:35: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 MAA03798 for ; Tue, 8 Feb 2000 12:35: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 MAA18976; Tue, 8 Feb 2000 12:33: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 MAA18919 for ; Tue, 8 Feb 2000 12:33:33 -0500 (EST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03724; Tue, 8 Feb 2000 12:35:01 -0500 (EST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Tue, 8 Feb 2000 11:33:41 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id <1QNDPBNZ>; Tue, 8 Feb 2000 11:33:38 -0600 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24919BD3@bcarua63.ca.nortel.com> From: "Anne Brown" To: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Tue, 8 Feb 2000 11:33:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF725A.A10CC9FA" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF725A.A10CC9FA Content-Type: text/plain; charset="iso-8859-1" For clarification on the reasoning for the single-digit separation of E.164 digits for lookup purposes: This strategy was conceived in September 1996 with the following goals in mind: 1. Implementable by both DNS and LDAP and other repositories (at the same time, with partitioning depending on service and application requirements) 2. Allows lookups -vs- searching (both DNS and LDAP). A record or entry can be pin-pointed without white-pages type searching. 3. Supports distribution of E.164 resolution data by both blocks of numbers and by individual numbers. The strategy allows this distribution to be changed, when required, to reflect current realities. 4. Alleviates clients from having to know or be able to derive numbering plan structures and lengths (What a user types or dials is out of the problem scope) 5. Isolation from changes to numbering plan structures and lengths 6. Supports use of extensions, if required Regards, Anne -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: February 04, 2000 6:37 PM To: Manfredi, Albert E Cc: 'Mark Foster'; enum@ietf.org; itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > So the question is, will the individual-digit hierarchy be meaningful or not > in the future? yes. you will always be able to represent the E.164 delegation hierarchy using a DNS tree where each digit is a separate DNS label. this would not necessarily be the case for a DNS tree where there were some multiple digit labels. that's why the one-digit-per-label representation is preferred. the nice thing about doing it this way is that the structure of phone numbers is reflected in the DNS tree, and can change from time to time, rather than being embedded either in lookup software or in users' minds. so for an example, to look up +1 865 974 3126 1. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to the DNS root <<< DNS root returns "I have no answers for you, but domains ending in .e164.net can be looked up at any of the following servers..." (list of servers for lookup of top-level e.164 prefixes follows) (this assumes that the root server also serves .net, as is currently the case for at least some of the root servers) 2. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the DNS servers listed for .e164.net <<< that server returns "I have no answers for you, but domains ending in .1.e164.net can be looked up at any of the following servers..." (list of servers for north america follows) 3. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the DNS servers listed for .1.e164.net <<< that server returns "I have no answers for you, but domains ending in .5.6.8.1.e164.net can be looked up at any of the following servers..." (list of servers for Knoxville area, Tennessee, US follows) 4. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the DNS servers listed for .5.6.8.1.e164.net <<< that server returns "I have no answers for you, but domains ending in 3.4.7.9.5.6.8.1.e164.net can be looked up at any of the following servers..." (list of servers for the University of Tennessee, Knoxville campus, follows) 5. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the DNS servers listed for 3.4.7.9.5.6.8.1.e164.net <<< that server returns "here are the records for 6.2.1.3.4.7.9.5.6.8.1.e164.net" note that a) the query is the same at every step b) it's not necessary to make a separate query for each digit - each server returns a referral for the longest DNS suffix matching the query. c) if the structure of e.164 delegation changes, this change can be reflected in DNS without any changes whatsoever to client code. for instance, another level of delegation could be added for the +1 865 974- prefix, or the e164.net servers could be taught to lookup north american numbering plan area codes under +1, and delegate each area code to to the appropriate country's DNS servers, or directly to servers for those area codes. the client code doesn't have to know or care how this is done. d) in practice, the results of the first two or three or four queries are likely to be in a local cache, thus most lookup will not require that many queries. _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01BF725A.A10CC9FA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for = ENUM

For clarification on the reasoning for = the single-digit separation of E.164 digits for lookup purposes:

This strategy was conceived in = September 1996 with the following goals in mind:

  1. Implementable by both = DNS and LDAP and other repositories (at the same time, with = partitioning depending on service and application = requirements)
  2. Allows lookups -vs- searching (both = DNS and LDAP).  A record or entry can be pin-pointed without = white-pages type searching.
  3. Supports distribution of E.164 = resolution data by both blocks of numbers and by individual = numbers.  The strategy allows this distribution to be changed, = when required, to reflect current realities.
  4. Alleviates clients from having to = know or be able to derive numbering plan structures and lengths (What a = user types or dials is out of the problem scope)   =
  5. Isolation from changes to numbering = plan structures and lengths
  6. Supports use of extensions, if = required

Regards,
Anne


      -----Original = Message-----
      From:   Keith Moore [mailto:moore@cs.utk.edu]=
      Sent:   February 04, 2000 6:37 PM
      To:     Manfredi, Albert E
      Cc:     'Mark Foster'; enum@ietf.org; itu+ietf@ietf.org
      Subject:       = Re: [ITU+IETF] RE: [Enum] Re: = Structure of DNS entry for ENUM

      > So the question is, will the = individual-digit hierarchy be meaningful or not
      > in the future?

      yes.  you will always be able to = represent the E.164 delegation hierarchy
      using a DNS tree where each digit is = a separate DNS label.   this would
      not necessarily be the case for a DNS = tree where there were some
      multiple digit labels.  that's = why the one-digit-per-label representation
      is preferred.

      the nice thing about doing it this way = is that the structure of phone
      numbers is reflected in the DNS tree, = and can change from time to time,
      rather than being embedded either in = lookup software or in users' minds.

      so for an example, to look up +1 865 = 974 3126

      1. send a query for = 6.2.1.3.4.7.9.5.6.8.1.e164.net to the DNS root

      <<< DNS root returns "I = have no answers for you, but domains
          ending in = .e164.net can be looked up at any of the following = servers..."

          (list of servers = for lookup of top-level e.164 prefixes follows)

          (this assumes that = the root server also serves .net, as is
           currently = the case for at least some of the root servers)

      2. send a query for = 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the
         DNS servers listed for = .e164.net

      <<< that server returns = "I have no answers for you, but domains
          ending in = .1.e164.net can be looked up at any of the following
          = servers..."

          (list of servers = for north america follows)

      3. send a query for = 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the
         DNS servers listed for = .1.e164.net


      <<< that server returns = "I have no answers for you, but domains
          ending in = .5.6.8.1.e164.net can be looked up at any of the
          following = servers..."

          (list of servers = for Knoxville area, Tennessee, US follows)

      4. send a query for = 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the
         DNS servers listed for = .5.6.8.1.e164.net

      <<< that server returns = "I have no answers for you, but domains
          ending in = 3.4.7.9.5.6.8.1.e164.net can be looked up at any of
          the following = servers..."

          (list of servers = for the University of Tennessee, Knoxville
           campus, = follows)

      5. send a query for = 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the
         DNS servers listed for = 3.4.7.9.5.6.8.1.e164.net

      <<< that server returns = "here are the records for
          = 6.2.1.3.4.7.9.5.6.8.1.e164.net"

      note that

      a) the query is the same at every = step
      b) it's not necessary to make a = separate query for each digit -
         each server returns a = referral for the longest DNS suffix
         matching the = query.
      c) if the structure of e.164 = delegation changes, this change
         can be reflected in DNS = without any changes whatsoever
         to client = code.    for instance, another level of = delegation
         could be added for the = +1 865 974- prefix, or the e164.net
         servers could be taught = to lookup north american numbering
         plan area codes under = +1, and delegate each area code to
         to the appropriate = country's DNS servers, or directly to
         servers for those area = codes.  the client code doesn't have
         to know or care how this = is done.
      d) in practice, the results of the = first two or three or four
         queries are likely to be = in a local cache, thus most lookup
         will not require that = many queries.
       

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

------_=_NextPart_001_01BF725A.A10CC9FA-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Feb 16 19:28: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 TAA19028 for ; Wed, 16 Feb 2000 19:28:40 -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 TAA09684; Wed, 16 Feb 2000 19:25: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 TAA09649 for ; Wed, 16 Feb 2000 19:25:35 -0500 (EST) Received: from PMESMTP01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19020 for ; Wed, 16 Feb 2000 19:27:13 -0500 (EST) Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FQ100FDZT8IGK@firewall.mcit.com> for enum@ietf.org; Thu, 17 Feb 2000 00:26:42 +0000 (GMT) Received: from omzmta01.mcit.com (omzmta01.mcit.com [166.37.194.119]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id AAA01597; Thu, 17 Feb 2000 00:27:25 +0000 (GMT) Received: from dwillispc8 ([166.35.148.173]) by omzmta01.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000217002642.ILJL10975@dwillispc8>; Thu, 17 Feb 2000 00:26:42 +0000 Date: Wed, 16 Feb 2000 18:25:44 -0600 From: Dean Willis Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: To: James Yu Cc: IETF Enum Message-id: <001401bf78dd$87233400$ad9423a6@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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Yep. Just don't screw the design down in such a way as to PRECLUDE use of enum techniques for dealing with those separate issues. -- Dean > -----Original Message----- > From: James Yu [mailto:james.yu@neustar.com] > Sent: Monday, February 07, 2000 11:55 AM > To: 'Dean Willis' > Cc: IETF Enum > Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > Dean, > > Agree with what you said; however, I don't consider private > numbering plans > part of E.164. We are addressing E.164 numbers defined by ITU-TS. Other > private numbering plans using different domains is a separate issue. > > James > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@wcom.com] > > Sent: Monday, February 07, 2000 12:52 PM > > To: IETF Enum > > Subject: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > > > > > > I second Jonathan's position. I think that there will by > > necessity be a > > generalization of ENUM to allow for privately administered > > dialing plans. > > The obvious way to do this is to define another domain for > > each private > > numbering plan. How a client knows which one to use is somebody else's > > problem. Before anyone can get traction there, ENUM needs to > > move further > > along the single-domain E.164 solution path. On the other > > hand, we do need > > to keep in mind the assumption that there WILL be other > > domains, and not > > make any design choices which preclude such an approach. > > > > -- > > Dean > > > > > -----Original Message----- > > > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > > > Jonathan Rosenberg > > > Sent: Monday, February 07, 2000 11:12 AM > > > To: James Yu > > > Cc: 'Randy Bush'; Richard Shockey; enum@ietf.org; itu+ietf@ietf.org > > > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS > > entry for ENUM > > > > > > > > > > > > > > > James Yu wrote: > > > > > > > > This means that the client would need to know which > > > consortium/domain to use > > > > when sending the DNS query. It may be fine if the client only > > > handles calls > > > > within a consortium/domain. But it won't be true for all > > the clients. > > > > > > I don't think we're trying to solve all aspects of the > > general problem > > > here. I think our job is to start with a tld, and from > > there, figure out > > > how to formulate the query to get back some kind of useful response. > > > Deciding who owns these tld's, and how to configure them in > > clients, is > > > important but not what we are solving here. > > > > > > -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 > > > > > > > > > _______________________________________________ > > 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 Wed Feb 16 21:36: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 VAA20283 for ; Wed, 16 Feb 2000 21:36:40 -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 VAA14021; Wed, 16 Feb 2000 21:33: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 VAA13993 for ; Wed, 16 Feb 2000 21:33:52 -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 VAA20264 for ; Wed, 16 Feb 2000 21:35:27 -0500 (EST) Received: from laptop ([209.138.9.157]) by smtp7.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id VAA05935; Wed, 16 Feb 2000 21:35:17 -0500 (EST) Message-Id: <4.2.0.58.20000216202102.00a5e4f0@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, 16 Feb 2000 20:34:56 -0600 To: Dean Willis , James Yu From: Richard Shockey Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Cc: IETF Enum In-Reply-To: <001401bf78dd$87233400$ad9423a6@mcit.com> References: 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 X-BeenThere: enum@ietf.org At 06:25 PM 2/16/2000 -0600, Dean Willis wrote: >Yep. Just don't screw the design down in such a way as to PRECLUDE use of >enum techniques for dealing with those separate issues. > >-- Point well raised Dean. I see this as another form of delegation. Internal private numbering plans could be resolved within separate zones within the appropriate domain. lets say x.x.x.x.x.x.x.x.x.x.x.e164.domain.com Internal gateways or intelligent telephony devices would have some logic that understands that certain _dialing_ strings...resolve against a different _numbering_ domain than the global E164 proposed by ENUM. I think this has hung up some people before. Dialing and numbering are two distinct things. The protocol usage would be the same. One Internal ..One Global. Maybe this should be documented more clearly. >Dean > > > -----Original Message----- > > From: James Yu [mailto:james.yu@neustar.com] > > Sent: Monday, February 07, 2000 11:55 AM > > To: 'Dean Willis' > > Cc: IETF Enum > > Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > > > > Dean, > > > > Agree with what you said; however, I don't consider private > > numbering plans > > part of E.164. We are addressing E.164 numbers defined by ITU-TS. Other > > private numbering plans using different domains is a separate issue. > > > > James > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@wcom.com] > > > Sent: Monday, February 07, 2000 12:52 PM > > > To: IETF Enum > > > Subject: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > > > > > > > > > > I second Jonathan's position. I think that there will by > > > necessity be a > > > generalization of ENUM to allow for privately administered > > > dialing plans. > > > The obvious way to do this is to define another domain for > > > each private > > > numbering plan. How a client knows which one to use is somebody else's > > > problem. Before anyone can get traction there, ENUM needs to > > > move further > > > along the single-domain E.164 solution path. On the other > > > hand, we do need > > > to keep in mind the assumption that there WILL be other > > > domains, and not > > > make any design choices which preclude such an approach. > > > > > > -- > > > Dean > > > > > > > -----Original Message----- > > > > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > > > > Jonathan Rosenberg > > > > Sent: Monday, February 07, 2000 11:12 AM > > > > To: James Yu > > > > Cc: 'Randy Bush'; Richard Shockey; enum@ietf.org; itu+ietf@ietf.org > > > > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS > > > entry for ENUM > > > > > > > > > > > > > > > > > > > > James Yu wrote: > > > > > > > > > > This means that the client would need to know which > > > > consortium/domain to use > > > > > when sending the DNS query. It may be fine if the client only > > > > handles calls > > > > > within a consortium/domain. But it won't be true for all > > > the clients. > > > > > > > > I don't think we're trying to solve all aspects of the > > > general problem > > > > here. I think our job is to start with a tld, and from > > > there, figure out > > > > how to formulate the query to get back some kind of useful response. > > > > Deciding who owns these tld's, and how to configure them in > > > clients, is > > > > important but not what we are solving here. > > > > > > > > -Jonathan R. > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Feb 17 19:23:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28030 for ; Thu, 17 Feb 2000 19:23:59 -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 TAA27867; Thu, 17 Feb 2000 19:21:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27835 for ; Thu, 17 Feb 2000 19:21:00 -0500 (EST) Received: from evds.voicedomain (www.evds.com [208.146.135.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28021 for ; Thu, 17 Feb 2000 19:22:34 -0500 (EST) Received: from seagal ([192.168.10.2]) by evds.voicedomain (Netscape Messaging Server 3.62) with SMTP id 379; Thu, 17 Feb 2000 19:21:59 -0500 Message-ID: <008001bf79a6$08e01b20$020aa8c0@seagal.voicedomain> From: "David P. Peek" To: "Dean Willis" , "James Yu" , "Richard Shockey" Cc: "IETF Enum" Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Thu, 17 Feb 2000 19:21:00 -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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit >At 06:25 PM 2/16/2000 -0600, Dean Willis wrote: > >>Yep. Just don't screw the design down in such a way as to PRECLUDE use of >>enum techniques for dealing with those separate issues. >> >>-- > >Point well raised Dean. I see this as another form of delegation. Internal >private numbering plans could be resolved within separate zones within the >appropriate domain. > >lets say x.x.x.x.x.x.x.x.x.x.x.e164.domain.com > >Internal gateways or intelligent telephony devices would have some logic >that understands that certain _dialing_ strings...resolve against a >different _numbering_ domain than the global E164 proposed by ENUM. > >I think this has hung up some people before. Dialing and numbering are two >distinct things. > >The protocol usage would be the same. > >One Internal ..One Global. > Very good point raised here. However, I believe we should continue to focus exclusively on the One Global solution and not try to solve the Internal methods to solve private numbering plans using this DNS solution. It certainly is possible but wouldn't it require us to define additional NAPTR records and even then maybe not solve the entire private numbering requirements? For example, I believe the private numbering solution should be capable of support down to the user level. This will require the identification of the source making a query and DNS isn't really good for that. A method discussed with memebers of the VMA Technical Working Group is one that addresses the private numbering solution at the second tier or ADS (Authoritative Directory Server) by making an LDAP query. This internal private query made by a communication's platform will retrieve the E164 number associated with the private number dialed and then perform a DNS query as described in this "One Global" solution. An Internet Draft is being prepared now which describes more details of the two-tiered approach that supports the DNS solution we are talking about here in ENUM. When available I'll make sure this group is notified. Dave >Maybe this should be documented more clearly. > > >>Dean >> >> > -----Original Message----- >> > From: James Yu [mailto:james.yu@neustar.com] >> > Sent: Monday, February 07, 2000 11:55 AM >> > To: 'Dean Willis' >> > Cc: IETF Enum >> > Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM >> > >> > >> > Dean, >> > >> > Agree with what you said; however, I don't consider private >> > numbering plans >> > part of E.164. We are addressing E.164 numbers defined by ITU-TS. Other >> > private numbering plans using different domains is a separate issue. >> > >> > James >> > >> > > -----Original Message----- >> > > From: Dean Willis [mailto:dean.willis@wcom.com] >> > > Sent: Monday, February 07, 2000 12:52 PM >> > > To: IETF Enum >> > > Subject: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM >> > > >> > > >> > > >> > > I second Jonathan's position. I think that there will by >> > > necessity be a >> > > generalization of ENUM to allow for privately administered >> > > dialing plans. >> > > The obvious way to do this is to define another domain for >> > > each private >> > > numbering plan. How a client knows which one to use is somebody else's >> > > problem. Before anyone can get traction there, ENUM needs to >> > > move further >> > > along the single-domain E.164 solution path. On the other >> > > hand, we do need >> > > to keep in mind the assumption that there WILL be other >> > > domains, and not >> > > make any design choices which preclude such an approach. >> > > >> > > -- >> > > Dean >> > > >> > > > -----Original Message----- >> > > > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of >> > > > Jonathan Rosenberg >> > > > Sent: Monday, February 07, 2000 11:12 AM >> > > > To: James Yu >> > > > Cc: 'Randy Bush'; Richard Shockey; enum@ietf.org; itu+ietf@ietf.org >> > > > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS >> > > entry for ENUM >> > > > >> > > > >> > > > >> > > > >> > > > James Yu wrote: >> > > > > >> > > > > This means that the client would need to know which >> > > > consortium/domain to use >> > > > > when sending the DNS query. It may be fine if the client only >> > > > handles calls >> > > > > within a consortium/domain. But it won't be true for all >> > > the clients. >> > > > >> > > > I don't think we're trying to solve all aspects of the >> > > general problem >> > > > here. I think our job is to start with a tld, and from >> > > there, figure out >> > > > how to formulate the query to get back some kind of useful response. >> > > > Deciding who owns these tld's, and how to configure them in >> > > clients, is >> > > > important but not what we are solving here. >> > > > >> > > > -Jonathan R. >> > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >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 Fri Feb 18 09:40:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24147 for ; Fri, 18 Feb 2000 09:40:55 -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 JAA00643; Fri, 18 Feb 2000 09:37:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00616 for ; Fri, 18 Feb 2000 09:37:04 -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 JAA24103 for ; Fri, 18 Feb 2000 09:38:41 -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 GAA11014 for ; Fri, 18 Feb 2000 06:38:09 -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 GAA26867 for ; Fri, 18 Feb 2000 06:38:38 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 18 Feb 2000 06:38:31 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Fri, 18 Feb 2000 09:38:29 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EE2B@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'David P. Peek'" Cc: IETF Enum Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 18 Feb 2000 09:38:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org David P. Peek wrote: > For example, I believe the private numbering solution > should be > capable of support down to the user level. This will require the > identification of the source > making a query and DNS isn't really good for that. A method > discussed > with memebers of the VMA Technical Working Group is one that > addresses the > private numbering solution at the second tier or ADS (Authoritative > Directory Server) by > making an LDAP query. This internal private query made by a > communication's > platform will retrieve the E164 number associated with the > private number > dialed > and then perform a DNS query as described in this "One > Global" solution. This makes perfect sense to me. And one clean way to support the "second tier" numbering solution might also be to use domains that are unique to the country where that numbering plan is in effect. For example, .telnumbers.fr would accept numbers in the French plan. So even if you move your appliance around the world, you can continue to use the numbering plan that appliance is set up to use? 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 Feb 18 11:10:43 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 LAA26005 for ; Fri, 18 Feb 2000 11:10:43 -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 LAA03243; Fri, 18 Feb 2000 11:06:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03212 for ; Fri, 18 Feb 2000 11:06:47 -0500 (EST) Received: from gw1.octel.com (gw1.octel.com [206.189.47.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25917 for ; Fri, 18 Feb 2000 11:08:23 -0500 (EST) Received: from curly.eng.octel.com (curly.eng.octel.com [148.147.200.26]) by gw1.octel.com (8.9.3/8.9.3) with ESMTP id IAA10316; Fri, 18 Feb 2000 08:07:57 -0800 (PST) Received: from buzz.ons.octel.com (buzz.ons.octel.com [155.184.13.4]) by curly.eng.octel.com (8.9.3/8.9.3) with ESMTP id IAA17562; Fri, 18 Feb 2000 08:07:56 -0800 (PST) Received: from exdal1.ons.octel.com (exdal1 [155.184.13.201]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id KAA13159; Fri, 18 Feb 2000 10:07:54 -0600 (CST) Received: by exdal1.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 18 Feb 2000 10:15:54 -0600 Message-ID: <6B57F36F4FF9D111B30A0008C7F4133702E4D95D@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: "Manfredi, Albert E" , "'David P. Peek'" Cc: IETF Enum Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 18 Feb 2000 10:15:53 -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 X-BeenThere: enum@ietf.org I recognise this work is out of scope for the current ENUM project, but it is important contextwe need to be aware of. Private numbering is used both in public virtual private networks or centrex, and inter-PBX numbering plans with leased or virtual tie lines. From the public network side, the virtual private numbering plans is reached by entering an access code prior to the virtual telephone number. This access code may itself be a PSTN number, or simply a magic sequence caught by the serving switch. The ingress switch either 1) uses the access code to translate the dialed VPN number into a valid E.164 number, in effect resolving the alias, or 2) uses the access code to determine the context of the number and treats the number as a routeable number within a separate private network. The access code is not always explicitly dialed by the user. Digit analysis or a short-code coupled with the senders class-of-service information may note that a single digit prefix (for instance 8) should really translate into an access code for the subscriber VPN. In this case, what results if I dial 8-1212 will be different than if you dial 8-1212 if we are served by separate VPN numbers. The mapping the dialed numbers into a context and number is frequently called a "dial plan". In enum space, it would be up to the client to determine that the dialed number was other than E.164 and determine which numbering plan (DNS suffix) it belonged to. Standards and auxillary directory services to make a network-based dialed digit analysis function to map access codes to domain names may be a future project. However, it seems that the result of any local or standard approach will take the initial digits, number length, and local configuration to determine the domain name suffix to append to the dotted digits. From that point the mechanics and protocol are identical for E.164 and private spaces. Assuming the domain name suffix was part of the public DNS space, the private numbering plan would be world-accessable, i.e., my phone could be reached at 2.2.7.2.dallas-dev.lucent.com. Interestingly, there is no national numbering authority involved, so a multi-national corporation can easily use a single, unified, short-digit numbering plan. Closed networks are another tier to the problem, and one which the DNS-based proposals are not naturally suitable. That is, the caller outside a given community may not be authorized to send to a given address in a private address plan. I also believe this functionality is best addressed by other directory services (LDAP, TCAP) or using trial-and-error, enforced at service establishment time. Greg V. -----Original Message----- From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] Sent: Friday, February 18, 2000 8:38 AM To: 'David P. Peek' Cc: IETF Enum Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM David P. Peek wrote: > For example, I believe the private numbering solution > should be > capable of support down to the user level. This will require the > identification of the source > making a query and DNS isn't really good for that. A method > discussed > with memebers of the VMA Technical Working Group is one that > addresses the > private numbering solution at the second tier or ADS (Authoritative > Directory Server) by > making an LDAP query. This internal private query made by a > communication's > platform will retrieve the E164 number associated with the > private number > dialed > and then perform a DNS query as described in this "One > Global" solution. This makes perfect sense to me. And one clean way to support the "second tier" numbering solution might also be to use domains that are unique to the country where that numbering plan is in effect. For example, .telnumbers.fr would accept numbers in the French plan. So even if you move your appliance around the world, you can continue to use the numbering plan that appliance is set up to use? Bert albert.e.manfredi@boeing.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 Fri Feb 18 11:56: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 LAA27072 for ; Fri, 18 Feb 2000 11:56: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 LAA04541; Fri, 18 Feb 2000 11:52: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 LAA04511 for ; Fri, 18 Feb 2000 11:52:14 -0500 (EST) Received: from reddot.dynamicsoft.com (reddot.dynamicsoft.com [216.89.83.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27007 for ; Fri, 18 Feb 2000 11:53:49 -0500 (EST) Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA22949; Fri, 18 Feb 2000 11:53:47 -0500 (EST) Message-ID: <38AD7A08.A59C392C@dynamicsoft.com> Date: Fri, 18 Feb 2000 11:57:44 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vaudreuil, Greg M (Greg)" CC: "Manfredi, Albert E" , "'David P. Peek'" , IETF Enum Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <6B57F36F4FF9D111B30A0008C7F4133702E4D95D@exdal1.ons.octel.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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit "Vaudreuil, Greg M (Greg)" wrote: > > In enum space, it would be up to the client to determine that the dialed > number was other than E.164 and determine which numbering plan (DNS suffix) > it belonged to. Standards and auxillary directory services to make a > network-based dialed digit analysis function to map access codes to domain > names may be a future project. However, it seems that the result of any > local or standard approach will take the initial digits, number length, and > local configuration to determine the domain name suffix to append to the > dotted digits. From that point the mechanics and protocol are identical for > E.164 and private spaces. Exactly. Another way to look at it is that the system enum is defining takes two things as input: a phone number AND a domain suffix, and then returns a list of URIs. -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 Fri Feb 18 14:45: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 OAA29985 for ; Fri, 18 Feb 2000 14:45: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 OAA09041; Fri, 18 Feb 2000 14:42: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 OAA09008 for ; Fri, 18 Feb 2000 14:42:34 -0500 (EST) Received: from evds.voicedomain (www.evds.com [208.146.135.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29957 for ; Fri, 18 Feb 2000 14:44:12 -0500 (EST) Received: from seagal ([192.168.10.2]) by evds.voicedomain (Netscape Messaging Server 3.62) with SMTP id 469; Fri, 18 Feb 2000 14:42:37 -0500 Message-ID: <003101bf7a48$305257c0$020aa8c0@seagal.voicedomain> From: "David P. Peek" To: "Jonathan Rosenberg" , "Vaudreuil, Greg M (Greg)" Cc: "Manfredi, Albert E" , "IETF Enum" Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 18 Feb 2000 14:41:45 -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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > > >"Vaudreuil, Greg M (Greg)" wrote: >> >> In enum space, it would be up to the client to determine that the dialed >> number was other than E.164 and determine which numbering plan (DNS suffix) >> it belonged to. Standards and auxillary directory services to make a >> network-based dialed digit analysis function to map access codes to domain >> names may be a future project. However, it seems that the result of any >> local or standard approach will take the initial digits, number length, and >> local configuration to determine the domain name suffix to append to the >> dotted digits. From that point the mechanics and protocol are identical for >> E.164 and private spaces. > >Exactly. Another way to look at it is that the system enum is defining >takes two things as input: a phone number AND a domain suffix, and then >returns a list of URIs. Do we really want to require two things (phone number and domain suffix) as input to the ENUM global solution? Greg's description of private numbering requires the domain suffix if a DNS solution is to be used to solve the private dialing plan. This is certainly one way to support private dialing plans. The other way is by utilizing LDAP directories as was also mentioned in other private environments. I believe Greg's statement that it is up to the client to determine that the number dialed is not an E164 number and do what is necessary to obtain the E164 number. If the client system wishes to query a private DNS domain that it is aware of to locate the real E164 number then thats a perfect solution. If the client wishes to query a private ADS (LDAP server) to obtain the final E164 number than that is another solution. Once the E164 number is obtained this number should be used to query the ENUM "One Global" solution requiring only one input (the E164 number). Comments? Dave > >-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 > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Feb 18 15:05: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 PAA00757 for ; Fri, 18 Feb 2000 15:05: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 PAA09508; Fri, 18 Feb 2000 15:02: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 PAA09473 for ; Fri, 18 Feb 2000 15:02:30 -0500 (EST) Received: from reddot.dynamicsoft.com (reddot.dynamicsoft.com [216.89.83.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00746 for ; Fri, 18 Feb 2000 15:04:03 -0500 (EST) Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA23402; Fri, 18 Feb 2000 15:02:18 -0500 (EST) Message-ID: <38ADA636.260EA7FE@dynamicsoft.com> Date: Fri, 18 Feb 2000 15:06:14 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "David P. Peek" CC: "Vaudreuil, Greg M (Greg)" , "Manfredi, Albert E" , IETF Enum Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <003101bf7a48$305257c0$020aa8c0@seagal.voicedomain> 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit "David P. Peek" wrote: > > >Exactly. Another way to look at it is that the system enum is defining > >takes two things as input: a phone number AND a domain suffix, and then > >returns a list of URIs. > > Do we really want to require two things (phone number and domain suffix) as > input > to the ENUM global solution? Greg's description of private numbering > requires the > domain suffix if a DNS solution is to be used to solve the private dialing > plan. > This is certainly one way to support private dialing plans. My point was that our system works for both the global and private space. For the global case, the application will know to append e164.int or whatever, and for applications that are using private plans, some other suffix is supplied by the application. As far as the enum component goes, it gets a domain suffix and a phone number. How the application decides what that suffix is, whether its e164.int or not, is irrelevant for the enum component. It takes that suffix and the number, constructs a domain name as per the document, and then goes to DNS and gets back URIs for the services available. -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 Fri Feb 18 15:36: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 PAA01415 for ; Fri, 18 Feb 2000 15:36: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 PAA10115; Fri, 18 Feb 2000 15:33:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10088 for ; Fri, 18 Feb 2000 15:33:46 -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 PAA01373 for ; Fri, 18 Feb 2000 15:35:23 -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 MAA23057 for ; Fri, 18 Feb 2000 12:34:54 -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 MAA00732 for ; Fri, 18 Feb 2000 12:35:23 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 18 Feb 2000 12:35:09 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Fri, 18 Feb 2000 15:35:08 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EE30@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Jonathan Rosenberg'" Cc: IETF Enum Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 18 Feb 2000 15:35:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Jonathan Rosenberg wrote: > My point was that our system works for both the global and private > space. For the global case, the application will know to > append e164.int > or whatever, and for applications that are using private plans, some > other suffix is supplied by the application. As far as the enum > component goes, it gets a domain suffix and a phone number. How the > application decides what that suffix is, whether its e164.int > or not, is > irrelevant for the enum component. It takes that suffix and > the number, > constructs a domain name as per the document, and then goes to DNS and > gets back URIs for the services available. But what's more, it is possible that some of these local numbering plan queries will never be translated over to a query for the e164.int domain at all. For example, why not permit 911 calls from an Internet applicance, as long as you're in the US? I guess that if this scheme works for more than just e.164, more power to enum. 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 Feb 18 15:47: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 PAA01615 for ; Fri, 18 Feb 2000 15:47:34 -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 PAA10376; Fri, 18 Feb 2000 15:45:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10345 for ; Fri, 18 Feb 2000 15:44:54 -0500 (EST) Received: from evds.voicedomain (www.evds.com [208.146.135.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01602 for ; Fri, 18 Feb 2000 15:46:32 -0500 (EST) Received: from seagal ([192.168.10.2]) by evds.voicedomain (Netscape Messaging Server 3.62) with SMTP id 446; Fri, 18 Feb 2000 15:45:38 -0500 Message-ID: <004501bf7a50$fd081180$020aa8c0@seagal.voicedomain> From: "David P. Peek" To: "Jonathan Rosenberg" Cc: "Vaudreuil, Greg M (Greg)" , "Manfredi, Albert E" , "IETF Enum" Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 18 Feb 2000 15:44:44 -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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit -----Original Message----- From: Jonathan Rosenberg To: David P. Peek Cc: Vaudreuil, Greg M (Greg) ; Manfredi, Albert E ; IETF Enum Date: Friday, February 18, 2000 3:08 PM Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > >"David P. Peek" wrote: >> >> >Exactly. Another way to look at it is that the system enum is defining >> >takes two things as input: a phone number AND a domain suffix, and then >> >returns a list of URIs. >> >> Do we really want to require two things (phone number and domain suffix) as >> input >> to the ENUM global solution? Greg's description of private numbering >> requires the >> domain suffix if a DNS solution is to be used to solve the private dialing >> plan. >> This is certainly one way to support private dialing plans. > >My point was that our system works for both the global and private >space. For the global case, the application will know to append e164.int >or whatever, and for applications that are using private plans, some >other suffix is supplied by the application. As far as the enum >component goes, it gets a domain suffix and a phone number. How the >application decides what that suffix is, whether its e164.int or not, is >irrelevant for the enum component. It takes that suffix and the number, >constructs a domain name as per the document, and then goes to DNS and >gets back URIs for the services available. > >-Jonathan R. > Thanks for clarifying that. My fear was opening a can of worms if we started to address the private space. I agree with your statement here. Thanks - Dave >-- >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 > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Feb 18 16:09:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01940 for ; Fri, 18 Feb 2000 16:09:46 -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 QAA10911; Fri, 18 Feb 2000 16:07:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10880 for ; Fri, 18 Feb 2000 16:07:37 -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 QAA01936 for ; Fri, 18 Feb 2000 16:09:12 -0500 (EST) Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FQ50028D9E3EO@firewall.mcit.com> for enum@ietf.org; Fri, 18 Feb 2000 21:08:28 +0000 (GMT) Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id VAA14181; Fri, 18 Feb 2000 21:08:37 +0000 (GMT) Received: from dwillispc8 ([166.35.225.166]) by omzmta02.mcit.com (InterMail v03.02.05 118 120) with SMTP id <20000218210826.PSSZ105@[166.35.225.166]>; Fri, 18 Feb 2000 21:08:26 +0000 Date: Fri, 18 Feb 2000 15:07:31 -0600 From: Dean Willis Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: <4102273CEB77D211869200805FE6F59356EE30@xch-phl-01.he.boeing.com> To: "Manfredi, Albert E" , "'Jonathan Rosenberg'" Cc: IETF Enum Message-id: <001e01bf7a54$2b5697c0$a6e123a6@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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Bert wrote: > But what's more, it is possible that some of these local numbering plan > queries will never be translated over to a query for the e164.int > domain at > all. For example, why not permit 911 calls from an Internet applicance, as > long as you're in the US? > > I guess that if this scheme works for more than just e.164, more power to ENUM Yes! That's exactly what I meant. Thank you! -- Dean _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Feb 18 16:16:00 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01989 for ; Fri, 18 Feb 2000 16:15:59 -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 QAA11062; Fri, 18 Feb 2000 16:14:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11034 for ; Fri, 18 Feb 2000 16:14:04 -0500 (EST) Received: from gw1.octel.com (gw1.octel.com [206.189.47.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01985 for ; Fri, 18 Feb 2000 16:15:41 -0500 (EST) Received: from curly.eng.octel.com (curly.eng.octel.com [148.147.200.26]) by gw1.octel.com (8.9.3/8.9.3) with ESMTP id NAA13497; Fri, 18 Feb 2000 13:15:20 -0800 (PST) Received: from buzz.ons.octel.com (buzz.ons.octel.com [155.184.13.4]) by curly.eng.octel.com (8.9.3/8.9.3) with ESMTP id NAA29822; Fri, 18 Feb 2000 13:15:19 -0800 (PST) Received: from exdal1.ons.octel.com (exdal1 [155.184.13.201]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id PAA27914; Fri, 18 Feb 2000 15:15:18 -0600 (CST) Received: by exdal1.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 18 Feb 2000 15:23:18 -0600 Message-ID: <6B57F36F4FF9D111B30A0008C7F4133702E4D97D@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: "Manfredi, Albert E" , "'Jonathan Rosenberg'" Cc: IETF Enum Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 18 Feb 2000 15:23:17 -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 X-BeenThere: enum@ietf.org As other emails discussed, the 411, 911, 611, *9, and other north-american short-code information services provided by local telco's are not part of the E.164 or local _numbering plan_. They are part of the local _dialing_ plan. One important characteristic of each of these services is that the end-point varies by the "location" of the dialer. It is the client (or client's agent in the case of a POTS phone connected to a telco switch) that maps from a dialing plan to a numbering plan. If you dial 911, you certianly want a geographically local emergency response department! These dialing plans have a use in Internet space, but they need to be provided by a service better equipped than ENUM to do geographical location. This can be performed by the client (enter an e164 alias for 911), or a query to the geographically (emergency response) / politically (city services) / contractually (phone repair) "local" remapping service for the current clients definition of "local". Greg V. -----Original Message----- From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] Sent: Friday, February 18, 2000 2:35 PM To: 'Jonathan Rosenberg' Cc: IETF Enum Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Jonathan Rosenberg wrote: > My point was that our system works for both the global and private > space. For the global case, the application will know to > append e164.int > or whatever, and for applications that are using private plans, some > other suffix is supplied by the application. As far as the enum > component goes, it gets a domain suffix and a phone number. How the > application decides what that suffix is, whether its e164.int > or not, is > irrelevant for the enum component. It takes that suffix and > the number, > constructs a domain name as per the document, and then goes to DNS and > gets back URIs for the services available. But what's more, it is possible that some of these local numbering plan queries will never be translated over to a query for the e164.int domain at all. For example, why not permit 911 calls from an Internet applicance, as long as you're in the US? I guess that if this scheme works for more than just e.164, more power to enum. Bert albert.e.manfredi@boeing.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 Fri Feb 18 18:12: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 SAA03713 for ; Fri, 18 Feb 2000 18:12:40 -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 SAA13461; Fri, 18 Feb 2000 18:09: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 SAA13428 for ; Fri, 18 Feb 2000 18:09:55 -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 SAA03702 for ; Fri, 18 Feb 2000 18:11:31 -0500 (EST) Received: by dnspri.npac.com; id RAA24181; Fri, 18 Feb 2000 17:11:32 -0600 (CST) Received: from nodnsquery(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma024110; Fri, 18 Feb 00 17:11:04 -0600 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Fri, 18 Feb 2000 17:11:19 -0600 Message-ID: From: James Yu To: "'Vaudreuil, Greg M (Greg)'" Cc: IETF Enum , "Manfredi, Albert E" , "'Jonathan Rosenberg'" Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 18 Feb 2000 17:11:24 -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 X-BeenThere: enum@ietf.org I agree with Greg that 411, 911, 611 or *XX, #XX like numbers are non-E.164 numbers. Those numbers currently are handled by the GSTN switches (local matters if we exclude the mobile roaming scenario). If IP based networks are to support those service codes or abbreviated dialing codes, the network entity that receives the requests (e.g., the SIP server or GK) must know how to handle those codes if they are "local matters." In Internet, it may be a problem if there are no standardized procedures in handling those codes. If the end users can switch the service providers or servers freely and each SP/server may handle the codes differently, there will be end user confusion. The end users may perceive different treatment/handling or are required to dial different codes when accessing different SPs/servers. But those are not enum issues. The enum issue may be whether DNS is needed to resolve those codes. If handling of those codes are "local matters," the client that is to resolve the code may need to append a domain name belonging to the service provider. If it is a service provider's network entity that is to resolve the code, it probably can resolve it without using the DNS or it can append its domain name if DNS is used. In this case, no suffix is required. Unless those codes are standardized and "shared" NSs are used to resolve them, then a suffix different from e164.foo and those for private numbering plans as suggested by Johnathan can be used if DNS is used. DNS can be used to point to the "shared" NSs that has the information about the codes. The problem is what if the information is location dependent (e.g., 911 call is to be handled by a PSAP that has the jurisdiction for the caller's/client's geo. location)? The network (e.g., the SIP server) or client may have pre-provisioned client location/address. The issue is that the caller/client may call from anywhere other than the default location/address. In that case, neither the network entity nor the client itself has any clue about the client's current location/address. Again, this is not an enum issue but an issue for the IP telephony. James > -----Original Message----- > From: Vaudreuil, Greg M (Greg) [mailto:gregv@lucent.com] > Sent: Friday, February 18, 2000 4:23 PM > To: Manfredi, Albert E; 'Jonathan Rosenberg' > Cc: IETF Enum > Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > > As other emails discussed, the 411, 911, 611, *9, and other > north-american > short-code information services provided by local telco's are > not part of > the E.164 or local _numbering plan_. They are part of the > local _dialing_ > plan. One important characteristic of each of these services > is that the > end-point varies by the "location" of the dialer. It is the > client (or > client's agent in the case of a POTS phone connected to a > telco switch) that > maps from a dialing plan to a numbering plan. If you dial 911, you > certianly want a geographically local emergency response department! > > These dialing plans have a use in Internet space, but they need to be > provided by a service better equipped than ENUM to do > geographical location. > This can be performed by the client (enter an e164 alias for > 911), or a > query to the geographically (emergency response) / politically (city > services) / contractually (phone repair) "local" remapping > service for the > current clients definition of "local". > > Greg V. > > -----Original Message----- > From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] > Sent: Friday, February 18, 2000 2:35 PM > To: 'Jonathan Rosenberg' > Cc: IETF Enum > Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > Jonathan Rosenberg wrote: > > > My point was that our system works for both the global and private > > space. For the global case, the application will know to > > append e164.int > > or whatever, and for applications that are using private plans, some > > other suffix is supplied by the application. As far as the enum > > component goes, it gets a domain suffix and a phone number. How the > > application decides what that suffix is, whether its e164.int > > or not, is > > irrelevant for the enum component. It takes that suffix and > > the number, > > constructs a domain name as per the document, and then goes > to DNS and > > gets back URIs for the services available. > > But what's more, it is possible that some of these local > numbering plan > queries will never be translated over to a query for the > e164.int domain at > all. For example, why not permit 911 calls from an Internet > applicance, as > long as you're in the US? > > I guess that if this scheme works for more than just e.164, > more power to > enum. > > Bert > albert.e.manfredi@boeing.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 > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Feb 18 18:37:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03891 for ; Fri, 18 Feb 2000 18:37:35 -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 SAA15468; Fri, 18 Feb 2000 18:35: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 SAA15418 for ; Fri, 18 Feb 2000 18:35:27 -0500 (EST) Received: from PMESMTP01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03888 for ; Fri, 18 Feb 2000 18:37:03 -0500 (EST) Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FQ500G3HG8X6I@firewall.mcit.com> for enum@ietf.org; Fri, 18 Feb 2000 23:36:34 +0000 (GMT) Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120]) by omzrelay.mcit.com (8.8.7/) with ESMTP id XAA05901; Fri, 18 Feb 2000 23:36:34 +0000 (GMT) Received: from dwillispc8 ([166.35.225.166]) by omzmta02.mcit.com (InterMail v03.02.05 118 120) with SMTP id <20000218233633.QVEA105@[166.35.225.166]>; Fri, 18 Feb 2000 23:36:33 +0000 Date: Fri, 18 Feb 2000 17:35:35 -0600 From: Dean Willis Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: To: James Yu , "'Vaudreuil, Greg M (Greg)'" Cc: IETF Enum , "Manfredi, Albert E" , "'Jonathan Rosenberg'" Message-id: <002a01bf7a68$dadd8000$a6e123a6@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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit For E.164 numbers, I see ENUM as providing a means to find a SIP server or gatekeeper that knows how to resolve the given e.164 number. We know pretty much how this works. DNS solves local problems as awell as global ones. We do this with a split-DNS model, or with shadow servers, or local subdomains, or other techniques. The question is, how does ENUM help you find a SIP server or gatekeeper that knows how to resolve the funky local numbers? I suspect that we know how this works, too -- one simply makes an ENUM query in an appropriate local domain. How? By using the same techniques that apply for local DNS. And that's not an ENUM problem, as long as ENUM provides a way for the number-to-server-within-a-domain-context problem to be resolved. The current proposal seems to handle this nicely. I suggest we cease trying to make the problem harder than it is, and simply accept the obvious conclusion that the ENUM representation can be used in ANY name context with some utility. -- Dean > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of James > Yu > Sent: Friday, February 18, 2000 5:11 PM > To: 'Vaudreuil, Greg M (Greg)' > Cc: IETF Enum; Manfredi, Albert E; 'Jonathan Rosenberg' > Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > I agree with Greg that 411, 911, 611 or *XX, #XX like numbers are > non-E.164 > numbers. Those numbers currently are handled by the GSTN switches (local > matters if we exclude the mobile roaming scenario). If IP based networks > are to support those service codes or abbreviated dialing codes, > the network > entity that receives the requests (e.g., the SIP server or GK) > must know how > to handle those codes if they are "local matters." In Internet, > it may be a > problem if there are no standardized procedures in handling those > codes. If > the end users can switch the service providers or servers freely and each > SP/server may handle the codes differently, there will be end user > confusion. The end users may perceive different treatment/handling or are > required to dial different codes when accessing different > SPs/servers. But > those are not enum issues. The enum issue may be whether DNS is needed to > resolve those codes. > > If handling of those codes are "local matters," the client that is to > resolve the code may need to append a domain name belonging to the service > provider. If it is a service provider's network entity that is to resolve > the code, it probably can resolve it without using the DNS or it > can append > its domain name if DNS is used. In this case, no suffix is required. > > Unless those codes are standardized and "shared" NSs are used to resolve > them, then a suffix different from e164.foo and those for private > numbering > plans as suggested by Johnathan can be used if DNS is used. DNS > can be used > to point to the "shared" NSs that has the information about the > codes. The > problem is what if the information is location dependent (e.g., > 911 call is > to be handled by a PSAP that has the jurisdiction for the > caller's/client's > geo. location)? The network (e.g., the SIP server) or client may have > pre-provisioned client location/address. The issue is that the > caller/client may call from anywhere other than the default > location/address. In that case, neither the network entity nor the client > itself has any clue about the client's current location/address. Again, > this is not an enum issue but an issue for the IP telephony. > > James > > -----Original Message----- > > From: Vaudreuil, Greg M (Greg) [mailto:gregv@lucent.com] > > Sent: Friday, February 18, 2000 4:23 PM > > To: Manfredi, Albert E; 'Jonathan Rosenberg' > > Cc: IETF Enum > > Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > > > > > > As other emails discussed, the 411, 911, 611, *9, and other > > north-american > > short-code information services provided by local telco's are > > not part of > > the E.164 or local _numbering plan_. They are part of the > > local _dialing_ > > plan. One important characteristic of each of these services > > is that the > > end-point varies by the "location" of the dialer. It is the > > client (or > > client's agent in the case of a POTS phone connected to a > > telco switch) that > > maps from a dialing plan to a numbering plan. If you dial 911, you > > certianly want a geographically local emergency response department! > > > > These dialing plans have a use in Internet space, but they need to be > > provided by a service better equipped than ENUM to do > > geographical location. > > This can be performed by the client (enter an e164 alias for > > 911), or a > > query to the geographically (emergency response) / politically (city > > services) / contractually (phone repair) "local" remapping > > service for the > > current clients definition of "local". > > > > Greg V. > > > > -----Original Message----- > > From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] > > Sent: Friday, February 18, 2000 2:35 PM > > To: 'Jonathan Rosenberg' > > Cc: IETF Enum > > Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > > > > Jonathan Rosenberg wrote: > > > > > My point was that our system works for both the global and private > > > space. For the global case, the application will know to > > > append e164.int > > > or whatever, and for applications that are using private plans, some > > > other suffix is supplied by the application. As far as the enum > > > component goes, it gets a domain suffix and a phone number. How the > > > application decides what that suffix is, whether its e164.int > > > or not, is > > > irrelevant for the enum component. It takes that suffix and > > > the number, > > > constructs a domain name as per the document, and then goes > > to DNS and > > > gets back URIs for the services available. > > > > But what's more, it is possible that some of these local > > numbering plan > > queries will never be translated over to a query for the > > e164.int domain at > > all. For example, why not permit 911 calls from an Internet > > applicance, as > > long as you're in the US? > > > > I guess that if this scheme works for more than just e.164, > > more power to > > enum. > > > > Bert > > albert.e.manfredi@boeing.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 > > > > _______________________________________________ > 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 Sat Feb 19 17:12:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28194 for ; Sat, 19 Feb 2000 17:12:52 -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 RAA14991; Sat, 19 Feb 2000 17: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 RAA14962 for ; Sat, 19 Feb 2000 17:09:47 -0500 (EST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28179 for ; Sat, 19 Feb 2000 17:11:24 -0500 (EST) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id QAA23750 for ; Sat, 19 Feb 2000 16:11:24 -0600 (CST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id QAA27207 for ; Sat, 19 Feb 2000 16:11:23 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Sat, 19 Feb 2000 14:11:12 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Sat, 19 Feb 2000 17:11:11 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EE33@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Dean Willis'" Cc: IETF Enum Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Sat, 19 Feb 2000 17:11:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Agree with Dean. The IP naming convention, for example, already is set up for identifying locations. You use the city.state.us convention, for example. So what's wrong with numbers like 911 being followed by telnumbers.fairfax.va.us, just for example? Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: Dean Willis [mailto:dean.willis@wcom.com] > Sent: Friday, February 18, 2000 6:36 PM > To: James Yu; 'Vaudreuil, Greg M (Greg)' > Cc: IETF Enum; Manfredi, Albert E; 'Jonathan Rosenberg' > Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > > For E.164 numbers, I see ENUM as providing a means to find a > SIP server or > gatekeeper that knows how to resolve the given e.164 number. > We know pretty > much how this works. > > DNS solves local problems as awell as global ones. We do this with a > split-DNS model, or with shadow servers, or local subdomains, or other > techniques. > > The question is, how does ENUM help you find a SIP server or > gatekeeper that > knows how to resolve the funky local numbers? I suspect that > we know how > this works, too -- one simply makes an ENUM query in an > appropriate local > domain. How? By using the same techniques that apply for > local DNS. And > that's not an ENUM problem, as long as ENUM provides a way for the > number-to-server-within-a-domain-context problem to be > resolved. The current > proposal seems to handle this nicely. > > I suggest we cease trying to make the problem harder than it > is, and simply > accept the obvious conclusion that the ENUM representation > can be used in > ANY name context with some utility. > > -- > Dean > > > -----Original Message----- > > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On > Behalf Of James > > Yu > > Sent: Friday, February 18, 2000 5:11 PM > > To: 'Vaudreuil, Greg M (Greg)' > > Cc: IETF Enum; Manfredi, Albert E; 'Jonathan Rosenberg' > > Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS > entry for ENUM > > > > > > I agree with Greg that 411, 911, 611 or *XX, #XX like numbers are > > non-E.164 > > numbers. Those numbers currently are handled by the GSTN > switches (local > > matters if we exclude the mobile roaming scenario). If IP > based networks > > are to support those service codes or abbreviated dialing codes, > > the network > > entity that receives the requests (e.g., the SIP server or GK) > > must know how > > to handle those codes if they are "local matters." In Internet, > > it may be a > > problem if there are no standardized procedures in handling those > > codes. If > > the end users can switch the service providers or servers > freely and each > > SP/server may handle the codes differently, there will be end user > > confusion. The end users may perceive different > treatment/handling or are > > required to dial different codes when accessing different > > SPs/servers. But > > those are not enum issues. The enum issue may be whether > DNS is needed to > > resolve those codes. > > > > If handling of those codes are "local matters," the client > that is to > > resolve the code may need to append a domain name belonging > to the service > > provider. If it is a service provider's network entity > that is to resolve > > the code, it probably can resolve it without using the DNS or it > > can append > > its domain name if DNS is used. In this case, no suffix is > required. > > > > Unless those codes are standardized and "shared" NSs are > used to resolve > > them, then a suffix different from e164.foo and those for private > > numbering > > plans as suggested by Johnathan can be used if DNS is used. DNS > > can be used > > to point to the "shared" NSs that has the information about the > > codes. The > > problem is what if the information is location dependent (e.g., > > 911 call is > > to be handled by a PSAP that has the jurisdiction for the > > caller's/client's > > geo. location)? The network (e.g., the SIP server) or > client may have > > pre-provisioned client location/address. The issue is that the > > caller/client may call from anywhere other than the default > > location/address. In that case, neither the network entity > nor the client > > itself has any clue about the client's current > location/address. Again, > > this is not an enum issue but an issue for the IP telephony. > > > > James > > > -----Original Message----- > > > From: Vaudreuil, Greg M (Greg) [mailto:gregv@lucent.com] > > > Sent: Friday, February 18, 2000 4:23 PM > > > To: Manfredi, Albert E; 'Jonathan Rosenberg' > > > Cc: IETF Enum > > > Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS > entry for ENUM > > > > > > > > > > > > As other emails discussed, the 411, 911, 611, *9, and other > > > north-american > > > short-code information services provided by local telco's are > > > not part of > > > the E.164 or local _numbering plan_. They are part of the > > > local _dialing_ > > > plan. One important characteristic of each of these services > > > is that the > > > end-point varies by the "location" of the dialer. It is the > > > client (or > > > client's agent in the case of a POTS phone connected to a > > > telco switch) that > > > maps from a dialing plan to a numbering plan. If you > dial 911, you > > > certianly want a geographically local emergency response > department! > > > > > > These dialing plans have a use in Internet space, but > they need to be > > > provided by a service better equipped than ENUM to do > > > geographical location. > > > This can be performed by the client (enter an e164 alias for > > > 911), or a > > > query to the geographically (emergency response) / > politically (city > > > services) / contractually (phone repair) "local" remapping > > > service for the > > > current clients definition of "local". > > > > > > Greg V. > > > > > > -----Original Message----- > > > From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] > > > Sent: Friday, February 18, 2000 2:35 PM > > > To: 'Jonathan Rosenberg' > > > Cc: IETF Enum > > > Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS > entry for ENUM > > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > My point was that our system works for both the global > and private > > > > space. For the global case, the application will know to > > > > append e164.int > > > > or whatever, and for applications that are using > private plans, some > > > > other suffix is supplied by the application. As far as the enum > > > > component goes, it gets a domain suffix and a phone > number. How the > > > > application decides what that suffix is, whether its e164.int > > > > or not, is > > > > irrelevant for the enum component. It takes that suffix and > > > > the number, > > > > constructs a domain name as per the document, and then goes > > > to DNS and > > > > gets back URIs for the services available. > > > > > > But what's more, it is possible that some of these local > > > numbering plan > > > queries will never be translated over to a query for the > > > e164.int domain at > > > all. For example, why not permit 911 calls from an Internet > > > applicance, as > > > long as you're in the US? > > > > > > I guess that if this scheme works for more than just e.164, > > > more power to > > > enum. > > > > > > Bert > > > albert.e.manfredi@boeing.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 > > > > > > > _______________________________________________ > > 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 Feb 21 09:50: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 JAA08435 for ; Mon, 21 Feb 2000 09:50: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 JAA17134; Mon, 21 Feb 2000 09:45:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17104 for ; Mon, 21 Feb 2000 09:45:38 -0500 (EST) Received: from reddot.dynamicsoft.com (reddot.dynamicsoft.com [216.89.83.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08383 for ; Mon, 21 Feb 2000 09:44:49 -0500 (EST) Received: from dynamicsoft.com (1Cust228.tnt1.freehold.nj.da.uu.net [63.17.113.228]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA24758; Mon, 21 Feb 2000 09:44:48 -0500 (EST) Message-ID: <38B1505F.22E27DAD@dynamicsoft.com> Date: Mon, 21 Feb 2000 09:49:03 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Yu CC: "'Vaudreuil, Greg M (Greg)'" , IETF Enum , "Manfredi, Albert E" Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: 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 X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit James Yu wrote: > > Unless those codes are standardized and "shared" NSs are used to resolve > them, then a suffix different from e164.foo and those for private numbering > plans as suggested by Johnathan can be used if DNS is used. DNS can be used > to point to the "shared" NSs that has the information about the codes. The > problem is what if the information is location dependent (e.g., 911 call is > to be handled by a PSAP that has the jurisdiction for the caller's/client's > geo. location)? The network (e.g., the SIP server) or client may have > pre-provisioned client location/address. The issue is that the > caller/client may call from anywhere other than the default > location/address. In that case, neither the network entity nor the client > itself has any clue about the client's current location/address. Again, > this is not an enum issue but an issue for the IP telephony. 911 in a pure IP context is a mega-hard problem (I believe its probably material for at least two solid PhD dissertations). It encapsulates QoS issues, naming and resolution issues, anycast issues, caller identification issues, etc. We are not going to solve them here. However, when we do figure the whole thing out, the way enum fits is easy - you resolve 911 in DNS with enum, and it gives you back some server that you contact that will actually perform the hard geographical-locale based location. For example, this may be a sip server. When it receives an INVITE, it takes the source IP address, looks for an LOC (aka ICBM) RR (see rfc1876) in DNS, and get get the geographic locale of the caller (assuming we have figured out how to update the DNS with this information). I do not want to try and add location dependent resolution or anything like that into enum. -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 Tue Feb 22 01:37:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26648 for ; Tue, 22 Feb 2000 01:37: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 BAA18392; Tue, 22 Feb 2000 01:35: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 BAA18365 for ; Tue, 22 Feb 2000 01:35:23 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26605 for ; Tue, 22 Feb 2000 01:37:04 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id IAA26330; Tue, 22 Feb 2000 08:36:52 +0200 (EET) Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id IAA28257; Tue, 22 Feb 2000 08:36:51 +0200 (EET) Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id <1L6H6YHW>; Tue, 22 Feb 2000 08:36:51 +0200 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE101486CC7@eseis04nok> To: jdrosen@dynamicsoft.com, james.yu@neustar.com Cc: gregv@lucent.com, enum@ietf.org, Albert.Manfredi@PHL.Boeing.com Date: Tue, 22 Feb 2000 08:36:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] 911 Location Issues Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi all, > I do not want to try and add location dependent resolution or anything > like that into enum. There will be a BOF in Adelaide on location related issues. It is the Internet Spatial Location Forum. Below is some info. Already one draft has been writen. It sounds like such a scheme when paired with some address resolution will help with this problem. best regards, John Loughney ------------------------ message for the public ---------------- Dear Colleagues: Internet Spatial Location Forum, a discussion list on IP-related location issues is now active. The setting up of the forum is sparked by the huge practical value and the unreadiness of the spatial location capability for the Internet. The missing capability becomes even more demanded with the integration of IP and various network technologies including cellular and mobile systems. The forum is thus set up after our discussions with the leaders and some other members of IETF. It serves as a pre-BOF mailing list for applying a BOF in 47th IETF to address those location issues. The detailed description can be found at 'http://www-nrc.nokia.com/ip-location'. Its immediate goals are: (1) Collect the interests, concerns, and suggestions on an IP spatial location protocol, (2) Identify the further requirements of the location protocol, (3) Seek partners and enthusiasts for the joint effort, (4) Invite volunteers for their presentations on the location issues, and (5) Prepare the BOF charter for the location protocol. In brief, there is now a well-evaluated concept in its pregnancy. Please add your own influences onto its progress. To subscribe to the list, just email 'majordomo@research.nokia.com' with 'subscribe ext-ip-location' in the mail body. To discuss , just email the mailing list 'ext-ip-location@research.nokia.com'. More information (detailed forum description, mailing list archive, etc.) can be found at the web page 'http://www-nrc.nokia.com/ip-location'. Thank you for reading this far! Please forward this mail to anyone else who may be interested. Please visit the forum's web page and contribute by sending email to the mailing list. Thanks again! Yours truly, Haitao Tang / Eric Brunner _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Feb 29 17:05: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 RAA03600 for ; Tue, 29 Feb 2000 17:05: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 RAA00284; Tue, 29 Feb 2000 17:02: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 RAA00249 for ; Tue, 29 Feb 2000 17:02:04 -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 RAA03589 for ; Tue, 29 Feb 2000 17:03:50 -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 OAA05362 for ; Tue, 29 Feb 2000 14:03:16 -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 OAA27637 for ; Tue, 29 Feb 2000 14:03:49 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Tue, 29 Feb 2000 14:03:34 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Tue, 29 Feb 2000 17:03:33 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EE74@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'enum@ietf.org'" Cc: "ION Group (E-mail)" Date: Tue, 29 Feb 2000 17:03:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] Portable unique identifiers Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org A short time ago, the topic of how to formulate portable identifiers relating to E.164 numbers was broached, and someone mentioned using RFC 2486 for this purpose. RFC 2486 seems appropriate at first glance, because it addresses a similar problem, for roaming terminals. But I don't think it is the right approach for this application. RFC 2486 defines something called Network Access Identifier (NAI), which is a location-independent unique ID for a user. And the NAI makes use of the same naming convention used in e-mail addressing: username@realm. This is nice because it's a familiar and user-friendly format, but it has two drawbacks for our purposes: 1. It is next to impossible to use such a scheme from a small appliance, provided with keypad entry only (e.g. cell phone), and 2. The realm part of the unique ID ties the user to some service provider, making the scheme less than totally portable. Instead, I propose that a number, perhaps 15 digits long, identified by a unique prefix, would be about right. This would work with the enum scheme already scoped out. It could even more easily work with the existing ATM End System Identifier (AESA) scheme defined in ATM. In the enum world, one might use a domain other than e164.int. This is not, after all, an E.164 number. In the AESA world, one could either define a specific Address and Format Identifier (AFI) prefix for these AESAs, _or_ one can use the AFI for the existing embedded E.164 format, and then make use of parts of that 20-byte frame that are currently unused (the HO-DSP and ESI, for example). It seems possible to give these portable numbers some sort of hierarchy that is not geographically based, so as to even the load among several servers. Not unlike what happens now with E.164. As you go down the digits, the search is sent off to different servers. For fancy IP appliances that have a keyboard, RFC 2486 would still be usable, of course. But there must also be a solution for the smaller appliance, I think. Bert albert.e.manfredi@boeing.com _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum