From enum-admin@ietf.org Wed Dec 1 03:27:00 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07872 for ; Wed, 1 Dec 1999 03:27:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA23469; Wed, 1 Dec 1999 03:24:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA23438 for ; Wed, 1 Dec 1999 03:24:29 -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 DAA06821 for ; Wed, 1 Dec 1999 03:24:55 -0500 (EST) From: Wolfgang.Lautenschlager@alcatel.de Received: from slsas5.stgl.netd.alcatel.de by mailrelay2.alcatel.de with SMTP (XT-PP); Wed, 1 Dec 1999 09:23:33 +0100 Received: by slsas5.stgl.netd.alcatel.de(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id C125683A.002E1D83 ; Wed, 1 Dec 1999 09:23:42 +0100 X-Lotus-FromDomain: ALCATEL To: enum@ietf.org cc: rshockey@ix.netcom.com, arbrown@nortelnetworks.com, Melinda.Shore@nokia.com Message-ID: Date: Wed, 1 Dec 1999 09:23:42 +0100 Subject: RE: [Enum] ENUM Requirements Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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 would like to provide you with some comments giving some additional information on number structures marked with *WL. Melinda.Shore@nokia.com on 30.11.99 21:25:35 To: rshockey@ix.netcom.com, arbrown@nortelnetworks.com, enum@ietf.org cc: (bcc: Wolfgang LAUTENSCHLAGER/DE/ALCATEL) Subject: RE: [Enum] ENUM Requirements > Are 1 800 numbers or the UK version of toll free legitimate > e164 numbers or is this national numbering plan specific. > I agree these numbers are essential to resolve but what > other classes of numbers must resolve as well... 900 ? Freephone numbers are not E.164 addresses, but I think it's pretty clear that the mechanism developed by enum will work just as well in other domains (say, nanpa.int). The problem, of course, is that applications would need to be able to determine whether a number exists within the E.164 domain or a national numbering plan domain. *WL: I disagree that Freephone numbers are NO E.164 addresses. Freephone and any other service numbers are E.164 numbers as well. If you look on the E.164 number structure, it consists of CC (not relevant in this case as it is a national number), the NDC and the SN (subscriber number). According to E.164 a NDC as such can be a trunk code, ..., and a service code as well. 800 numbers and 900 numbers and other digit strings which identify a specific service (as defined by the national regulatory body) are a NDC. > Is it appropriate at this time to formally Require ENUM to coordinate > efforts with ITU SG2 etc? Require? I should think not. At any right, the only body I know of which now has a work item on E.164->IP address resolution is ETSI Project TIPHON. Eurescom has a very large telecoms database project, but I think that it's scoped somewhat differently. Melinda -- Melinda Shore Member of the Scientific Staff Nokia IP Telephony 127 West State Street Ithaca, NY 14850 +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 _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Dec 1 03:55:33 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21155 for ; Wed, 1 Dec 1999 03:55:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA26472; Wed, 1 Dec 1999 03:54:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA26432 for ; Wed, 1 Dec 1999 03:54:26 -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 DAA20880 for ; Wed, 1 Dec 1999 03:54:56 -0500 (EST) From: Wolfgang.Lautenschlager@alcatel.de Received: from slsas5.stgl.netd.alcatel.de by mailrelay2.alcatel.de with SMTP (XT-PP); Wed, 1 Dec 1999 09:53:53 +0100 Received: by slsas5.stgl.netd.alcatel.de(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id C125683A.0030E61B ; Wed, 1 Dec 1999 09:54:06 +0100 X-Lotus-FromDomain: ALCATEL To: enum@ietf.org cc: rshockey@ix.netcom.com, arbrown@nortelnetworks.com, Melinda.Shore@nokia.com Message-ID: Date: Wed, 1 Dec 1999 09:54:05 +0100 Subject: RE: [Enum] ENUM Requirements Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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 Sorry, one more time,I have forgotten to introduce myself: Wolfgang L. -- Wolfgang Lautenschlager Product Management Alcatel SEL AG Lorenzstr. 10 D70435 Stuttgart Germany +49 711 821 47652 (office) +49 711 821 43273 (fax) Wolfgang.Lautenschlager@alcatel.de Wolfgang LAUTENSCHLAGER 01.12.99 09:23 To: enum@ietf.org cc: rshockey@ix.netcom.com, arbrown@nortelnetworks.com, Melinda.Shore@nokia.com Subject: RE: [Enum] ENUM Requirements (Document link: Wolfgang LAUTENSCHLAGER) I would like to provide you with some comments giving some additional information on number structures marked with *WL. Melinda.Shore@nokia.com on 30.11.99 21:25:35 To: rshockey@ix.netcom.com, arbrown@nortelnetworks.com, enum@ietf.org cc: (bcc: Wolfgang LAUTENSCHLAGER/DE/ALCATEL) Subject: RE: [Enum] ENUM Requirements > Are 1 800 numbers or the UK version of toll free legitimate > e164 numbers or is this national numbering plan specific. > I agree these numbers are essential to resolve but what > other classes of numbers must resolve as well... 900 ? Freephone numbers are not E.164 addresses, but I think it's pretty clear that the mechanism developed by enum will work just as well in other domains (say, nanpa.int). The problem, of course, is that applications would need to be able to determine whether a number exists within the E.164 domain or a national numbering plan domain. *WL: I disagree that Freephone numbers are NO E.164 addresses. Freephone and any other service numbers are E.164 numbers as well. If you look on the E.164 number structure, it consists of CC (not relevant in this case as it is a national number), the NDC and the SN (subscriber number). According to E.164 a NDC as such can be a trunk code, ..., and a service code as well. 800 numbers and 900 numbers and other digit strings which identify a specific service (as defined by the national regulatory body) are a NDC. > Is it appropriate at this time to formally Require ENUM to coordinate > efforts with ITU SG2 etc? Require? I should think not. At any right, the only body I know of which now has a work item on E.164->IP address resolution is ETSI Project TIPHON. Eurescom has a very large telecoms database project, but I think that it's scoped somewhat differently. Melinda -- Melinda Shore Member of the Scientific Staff Nokia IP Telephony 127 West State Street Ithaca, NY 14850 +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 _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Dec 1 08:12:35 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19919 for ; Wed, 1 Dec 1999 08:12:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id IAA07949; Wed, 1 Dec 1999 08:11:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id IAA07911 for ; Wed, 1 Dec 1999 08:11:18 -0500 (EST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19507 for ; Wed, 1 Dec 1999 08:11:45 -0500 (EST) Received: from laptop (stl-mo15-10.ix.netcom.com [207.222.133.138]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id IAA20686 for ; Wed, 1 Dec 1999 08:11:44 -0500 (EST) Message-Id: <4.2.0.58.19991201070325.00a3fca0@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, 01 Dec 1999 07:04:36 -0600 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: I-D ACTION:draft-vaudreuil-vpimdir-principles-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I happened to run across this today ...contained within the draft is a discussion of the 164 service as it might apply to voice mail systems. >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-vaudreuil-vpimdir-principles-00.txt >Date: Wed, 01 Dec 1999 06:59:29 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Voice Messaging Directory Service: Principles of > Operation > Author(s) : G. Vaudreuil > Filename : draft-vaudreuil-vpimdir-principles-00.txt > Pages : 12 > Date : 30-Nov-99 > >General electronic mail (email) provides a facility for exchanging >messages of seemingly arbitrary content. In common email usage, text >is the primary media with one or more attachments. >A class of special-purpose computers has evolved to provide voice- >messaging services. These machines generally interface to a telephone >switch and provide call answering and voice messaging services. >Message exchange between these voice-mail only systems can best be >achieved using VPIM Version 2. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-vaudreuil-vpimdir-principles-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-vaudreuil-vpimdir-principles-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-vaudreuil-vpimdir-principles-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <19991130123911.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-vaudreuil-vpimdir-principles-00.txt > >xt> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Dec 1 12:39:23 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01913 for ; Wed, 1 Dec 1999 12:39:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA19716; Wed, 1 Dec 1999 12:38:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA19679 for ; Wed, 1 Dec 1999 12:38:27 -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 MAA01665 for ; Wed, 1 Dec 1999 12:38:56 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Wed, 1 Dec 1999 18:39:21 +0100 Message-ID: <98388C05D464D111B61800805F1504160123E326@p-ibis.issy.cnet.fr> From: BARNOLE Valerie CNET/DAC/ISS To: "'Richard Shockey'" , Melinda.Shore@nokia.com, arbrown@nortelnetworks.com, enum@ietf.org Cc: "'Fred Gaechter'" Subject: RE: [Enum] ENUM Requirements Date: Wed, 1 Dec 1999 18:39:20 +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 MAA19680 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 As a delegate in Q.1/2 in SG2, I would like to give some comments on the issues raised in Richard's and Melinda's mails : Please see my comments in italic letters inserted in the mail below. I apologize if I just say things that everybody knows. Valérie Barnole FT.BD/CNET/DAC/ARS tel. : + 33 1 45 29 58 39 fax : + 33 1 46 29 31 42 valerie.barnole@cnet.francetelecom.fr -----Message d'origine----- De: Richard Shockey [ mailto:rshockey@ix.netcom.com ] Date: mardi 30 novembre 1999 22:10 À: Melinda.Shore@nokia.com; arbrown@nortelnetworks.com; enum@ietf.org Objet: RE: [Enum] ENUM Requirements At 02:25 PM 11/30/1999 -0600, Melinda.Shore@nokia.com wrote: > > Are 1 800 numbers or the UK version of toll free legitimate > > e164 numbers or is this national numbering plan specific. > > I agree these numbers are essential to resolve but what > > other classes of numbers must resolve as well... 900 ? > >Freephone numbers are not E.164 addresses, but I think >it's pretty clear that the mechanism developed by enum >will work just as well in other domains (say, nanpa.int). >The problem, of course, is that applications would need >to be able to determine whether a number exists >within the E.164 domain or a national numbering plan >domain. > I don't think this is a problem. Its clear to me now that specific national numbering plan features could be zoned specifically for that purpose in much the way you suggest if the zone .1 points to a specific delegation for .8.0.0. or .8.8.8 etc. What I was not clear of originally was that multiple digits could combined in this way. I think we all want to avoid clients having any prior knowledge of national plan specific features. 1 800 numbers are E.164 numbers. I explain : an E.164 number (max length = 15 digits) has the following structure : CC (country code, 1 to 3 digits = 1 for the USA) followed by a NSN (national significant number, max length = 12 digits, here = 800....). But they are names, and not addresses, so in order to reach the endpoint, such a number (with the function of a name) has to be translated into an address, currently another E.164 number (with the function of an address). > > Is it appropriate at this time to formally Require ENUM to coordinate > > efforts with ITU SG2 etc? > >Require? I should think not. At any right, the only >body I know of which now has a work item on E.164->IP >address resolution is ETSI Project TIPHON. Eurescom has >a very large telecoms database project, but I think >that it's scoped somewhat differently. You're right .. require is not the right word though I think this proposal will closely examined by IETF "sister" standards bodies. ITU-T Question 1/2 ("applications of numbering and addressing plans for fixed and mobile services", will deal also with naming) is part of the Working Party 1/2 ("numbering, routing and global mobility") which is itself part of Study Group 2 ("network and service operation). During our last WP1/2 at the end of september 99, meeting, we created a project named "Numbering, naming and addressing for interworking between E.164 and IP address-based networks". We also discuss the need of coordinating our work with entities like IETF and ICANN. In this view, with inputs from the ITU policy and strategy department, we proposed the ITU to invite a meeting "IP and Telecoms Interworking Workshop" from 25 to 27th january 2000, in Geneva, focussed on numbering, naming, addressing and routing for convergence of telecoms and IP. This meeting is widely open to IETF, ICANN or others involved in the topic. I do not know if some official invitation has been already sent, but we hope IP people to attend in order to meet, identify key issues and progress together.We also expect IETF and ICANN to give us inputs on an agenda item. I agree that "require" is not a correct and happy word to start a fruitful coordination ! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Wed Dec 1 13:44:38 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04202 for ; Wed, 1 Dec 1999 13:44:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA11321; Wed, 1 Dec 1999 13:43:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA11256 for ; Wed, 1 Dec 1999 13:43:31 -0500 (EST) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03863 for ; Wed, 1 Dec 1999 13:43:59 -0500 (EST) Received: from laptop (stl-mo15-10.ix.netcom.com [207.222.133.138]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id NAA25907; Wed, 1 Dec 1999 13:43:33 -0500 (EST) Message-Id: <4.2.0.58.19991201123515.00a4eb60@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, 01 Dec 1999 12:41:47 -0600 To: BARNOLE Valerie CNET/DAC/ISS From: Richard Shockey Subject: RE: [Enum] ENUM Requirements Cc: enum@ietf.org In-Reply-To: <98388C05D464D111B61800805F1504160123E326@p-ibis.issy.cnet. fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Thank you for writing! > ITU-T Question 1/2 ("applications of numbering and addressing plans for >fixed and mobile services", will deal also with naming) is part of the >Working Party 1/2 ("numbering, routing and global mobility") which is itself >part of Study Group 2 ("network and service operation). During our last >WP1/2 at the end of september 99, meeting, we created a project named >"Numbering, naming and addressing for interworking between E.164 and IP >address-based networks". Is there any documentation on the project scope? >We also discuss the need of coordinating our work with entities like IETF >and ICANN. In this view, with inputs from the ITU policy and strategy >department, we proposed the ITU to invite a meeting "IP and Telecoms >Interworking Workshop" from 25 to 27th january 2000, in Geneva, focussed on >numbering, naming, addressing and routing for convergence of telecoms and >IP. This meeting is widely open to IETF, ICANN or others involved in the >topic. > >I do not know if some official invitation has been already sent, but we hope >IP people to attend in order to meet, identify key issues and progress >together.We also expect IETF and ICANN to give us inputs on an agenda item. >I agree that "require" is not a correct and happy word to start a fruitful >coordination ! This is the first I've heard of a meeting... If there is a formal announcement of this it would be very appropriate to post on the main IETF discussion list [ ietf@ietf.org ] after checking with the ENUM AD and official IETF liaison with the ITU Scott Bradner [ sob@harvard.edu ] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Dec 1 16:11:29 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16759 for ; Wed, 1 Dec 1999 16:11:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA07532; Wed, 1 Dec 1999 16:09:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA07492 for ; Wed, 1 Dec 1999 16:08:59 -0500 (EST) Received: from firewall.hypercom.com (firewall-user@firewall.hypercom.com [208.248.82.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15776 for ; Wed, 1 Dec 1999 16:09:27 -0500 (EST) Received: by firewall.hypercom.com; id OAA20439; Wed, 1 Dec 1999 14:08:47 -0700 (MST) Received: from citadel.hypercom.com(10.0.2.39) by firewall.hypercom.com via smap (4.1) id xma017535; Wed, 1 Dec 99 14:03:32 -0700 Received: from smtp.hypercom.com (smtp.hypercom.com [10.0.2.36]) by citadel.hypercom.com (8.8.8/8.8.8) with SMTP id OAA08457; Wed, 1 Dec 1999 14:04:00 -0700 (MST) Received: from POP3 Client by smtp.hypercom.com (ccMail Link to SMTP R8.30.00.7) id AA944082058; Wed, 01 Dec 1999 14:00:59 -0700 Message-Id: <9912019440.AA944082058@smtp.hypercom.com> X-Mailer: ccMail Link to SMTP R8.30.00.7 Date: Wed, 01 Dec 1999 13:58:35 -0700 From: Larry Cox To: Cc: Subject: RE: [Enum] ENUM Requirements MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" 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 --simple boundary Content-Type: text/plain; charset=US-ASCII Content-Description: "cc:Mail Note Part" Content-Transfer-Encoding: 7bit It may be important to re-evaluate some of the mapping strategy in relation to E.164 numbers. It is important to keep in mind that an E.164 number is a numeric name constrained to a specific hierarchical pattern, not an address, and is translated into an address progressively based on country codes, a national numbering plan, and local configuration. For numbers such as emergency call (typically 911 in North America) and toll free (800 or ..), the address may vary depending on the location where it is translated, the time of day, or other variables. Since what we are translating is a name, not an address, we must be careful to not constrain our system too tightly. If the address associated with an E.164 number changes at 6 hour intervals (for toll free numbers this is not uncommon), we must not route calls irrationally. We should also not break the system that chooses a destination for the call based on the calling party number if this can be avoided. If I call an 800 number to order a pizza and due to the way the call is routed I find myself talking to someone in Los Angeles when I want my pizza delivered in Atlanta, the functionality of the system has been compromised. Larry At 03:09 PM 11/30/99 -0600, you wrote: >At 02:25 PM 11/30/1999 -0600, Melinda.Shore@nokia.com wrote: >> > Are 1 800 numbers or the UK version of toll free legitimate >> > e164 numbers or is this national numbering plan specific. >> > I agree these numbers are essential to resolve but what >> > other classes of numbers must resolve as well... 900 ? >> >>Freephone numbers are not E.164 addresses, but I think >>it's pretty clear that the mechanism developed by enum >>will work just as well in other domains (say, nanpa.int). >>The problem, of course, is that applications would need >>to be able to determine whether a number exists >>within the E.164 domain or a national numbering plan >>domain. >> > >I don't think this is a problem. Its clear to me now that specific national >numbering plan features could be zoned specifically for that purpose in >much the way you suggest if the zone .1 points to a specific delegation for >.8.0.0. or .8.8.8 etc. What I was not clear of originally was that >multiple digits could combined in this way. > >I think we all want to avoid clients having any prior knowledge of national >plan specific features. > >> > Is it appropriate at this time to formally Require ENUM to coordinate >> > efforts with ITU SG2 etc? >> >>Require? I should think not. At any right, the only >>body I know of which now has a work item on E.164->IP >>address resolution is ETSI Project TIPHON. Eurescom has >>a very large telecoms database project, but I think >>that it's scoped somewhat differently. > >You're right .. require is not the right word though I think this proposal >will closely examined by IETF "sister" standards bodies. > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >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 ====================================== Larry Cox Senior Software Engineer Hypercom Network Systems Inc. Phone: (602) 504-4657 2851 West Kathleen Road Fax: (602) 504-4711 Phoenix, AZ 85053 Web: www.hypercom.com USA --simple boundary-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Dec 2 11:37:58 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15101 for ; Thu, 2 Dec 1999 11:37:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA18683; Thu, 2 Dec 1999 11:36:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA18609 for ; Thu, 2 Dec 1999 11:36:39 -0500 (EST) Received: from ingate.uk.neceur.com (ingate.uk.neceur.com [193.116.254.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14681 for ; Thu, 2 Dec 1999 11:37:07 -0500 (EST) Received: from internal-mail.uk.neceur.com by ingate.uk.neceur.com id 6vA20W+d6XZvf; Thu, 2 Dec 1999 16:35:52 GMT Received: from tokyo.ttd.neceur.com by internal-mail.uk.neceur.com id DHf30S+d6XZH11; Thu, 2 Dec 1999 16:35:52 GMT from tokyo.ttd.neceur.com (localhost [127.0.0.1]) id DHf30S+d6XZH11 for (3.3.2/3.1.31); Thu, 2 Dec 1999 16:35:52 GMT Received: by tokyo.ttd.neceur.com with Internet Mail Service (5.5.1960.3) id ; Thu, 2 Dec 1999 16:35:53 -0000 Message-ID: <3B9AA5E712DCD011AAD500609770A0E933B77D@tokyo.ttd.neceur.com> From: "GATTA, Matteo" To: "'enum@ietf.org'" Date: Thu, 2 Dec 1999 16:35:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) 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 LAA18610 Subject: [Enum] IETF 46th Enum minute meeting ? 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 Hi all,   Does anybody know whether or not is already available somewhere the minute of the meeting of Enum session of Washington DC?   Regards _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Dec 2 15:18:44 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05899 for ; Thu, 2 Dec 1999 15:18:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA13318; Thu, 2 Dec 1999 15:18:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA13264 for ; Thu, 2 Dec 1999 15:18:02 -0500 (EST) Received: from sheffield.cnchost.com (sheffield.concentric.net [207.155.252.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05771 for ; Thu, 2 Dec 1999 15:18:29 -0500 (EST) Received: from scott.metatel.office (metatel.ne.mediaone.net [24.128.100.134]) by sheffield.cnchost.com id PAA18151; Thu, 2 Dec 1999 15:18:25 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Date: Thu, 2 Dec 1999 14:53:17 -0500 (EST) From: Scott Petrack X-Sender: scott.petrack@adsl-151-203-17-31.bellatlantic.net To: enum@ietf.org cc: Vern Paxson , sob@harvard.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Enum] Summary and Minutes of ENUM in Washington 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 following summary and minutes of the ENUM working group are long overdue. Thanks to Jonathan Rosenberg and Willi Wimmreuter for providing their notes to me. Please review and correct if I under- or mis-represented you. Scott (Petrack) Short Summary of ENUM WG meeting -- Washington DC Nov 1999 The ENUM working group had its first meeting in Washington Nov 1999. The meeting reviewed the basic charter and scope, which is to map from telephone numbers into a set of URLs (or the information contained in set of URLs). ENUM will concentrate on using DNS for mapping queries and responses: the "back-end" services, such as administrative questions of how the data gets into the DNS, is outside the scope of ENUM. Patrik Falsrom presented his I-D draft-faltstrom-e164-03.txt, and the group discussed the suitability of this draft as a basis for ENUM's work. It seems that there was rough consensus that the approach taken in the draft is reasonable enough, and a new draft, incorporating comments from the WG meeting, will be prepared. The draft should at the very least be reworked to present a more generic mapping service, rather than a set of examples narrowly focusssed on implementing number portability. Detailed minutes follow. Scott Petrack Minutes for the ENUM WG (Telephone Number Mapping) meeting Place: Omni Shoreham Hotel Washington DC, Date: Nov. 8. 1999, from 15:00 - 17:30 Reported By: Wilhelm Wimmreuter Prepared By: Scott Petrack The ENUM working group session was held on Monday afternoon with about 120 people attending. The working group was chaired by Scott Petrack. DESCRIPTION: This working group will define an architecture and protocols for mapping a telephone number to a set of URLs which can be used to contact a resource associated with that number. AGENDA: 1. Agenda bashing 5 minutes 2. presentation of proposed charter 15 minutes 3. Requirements by Anne Brown (new) 4. presentation of I-D by Pattrick Falstrom 15 minutes draft-faltstrom-e164-03.txt 5. discussion of suitability of this draft as basis 25 minutes 1. AGENDA BASHING: In addition to the original agenda, Anne Brown was assigned to present and discuss a list of requirement for ENUM. 2. CHARTER and SCOPE Scott Petrack presented various examples that fit in the scope of ENUM: - "sending Email to a telephone" (smtp used to send text to pagers) need to map telephone number to mailto: URL - translation to SIP URL, Mailto, fax, .... In general ENUM is to translate phone numbers as names to IP addresses and other auxillary information. Therefore, the use of DNS based solution is reasonable. Other approaches are possible, but this working group is chartered to produce a DNS-based solution. Our goal is to specify the best DNS-based solution we can find, and document its capabilities and weaknesses. The definition of new RR's (extension of DNS) is a lower priority. The working group is NOT chartered to discuss how the data is inserted into the DNS, only how to access the data. Finally, the chair presented some open issues: - performance - Capability Announcements The following questions where raised by the audience. * Christian Huitema raised a concern that it must be possible to retrieve the data from multiple sources. * Wilhelm Wimmreuters stated, that Reverse lookup is required and therefore some kind of PTR records shall be used to accomplish this function * Melinda Shore raised the concern that operational procedures are absolutely critical. For example, it may be necessary to ensure that NS records can be inserted by one provider for another. Scott Bradner replied that indeed operations is indeed critical, but not for this group. Scott Petrack replied that it is within scope to decide (for example) that an NS record pointing to a new name server shall be used to enable "porting the phone number" from one information provider to another. What is not within scope is just how the owners of the databases are incented to do that. * Bjorn Marshal from Ericsson mentioned, that billing for lookups will be an issue in future and ENUM might be the place to discuss that. Scott Bradner replied that accounting within the database is outside the scope of ENUM (anything internal to a database is outside ENUM scope). However, security based access controls is certainly within scope. The question was raised if this could be a placeholder for later discussion on accounting for phone calls. Lawrence Conroy mentioned that an E164 number is not a billable entity in any case. Scott Bradner repeated that it is entirely irrelevant to ENUM if lookups or anything else costs money. Scott Petrack repeated that it is within scope to provide the security neccessary to authorize requests, and perhaps to enable non-repudiation that the request occured. * Scott Petrack made the comment that there was enough common interest just in the problem of "looking up phone numbers", and enough people wanted to see a DNS solution, that it is worth first deciding how to do this basic task. There was some discussion on the suitability of other protocols like LDAP for this purpose. Scott Bradner concluded this discussion with the statement that the IESG will give consideration to other working groups based on other technologies. But work on non-DNS solutions will not happen in ENUM. * Scott Petrack made the comment that it is important that we document the applications for which DNS is clearly NOT appropriate. For example, it is probable (may be?) that DNS is not good for highly dynamic data, since propogation of data is not very fast. 3. Requirements by Anne Brown Anne Presented a list of requirements and invided the audience for further discussion. a. Basic endpoint address lookup: have phone number, want endpoint address. There seemed to be agreement that the output should be essentially a URL. (The actual response may or may not contain an actual URL, but it should be possible to construct (possibly multiple) URL(s) from the response. b. Retrieval and negotiation of additional info. Richard Shockey said that retrieval should be in scope, while negotiation should be out of scope. Dave Oran said that rescap is doing this work, and so probably it should be out of scope for ENUM. Scott Bradner said that certainly ENUM should look at that work and see if it is appropriate, although ENUM could decide that it's not. Anne agreed that capability announcement was in scope. Jonathan Rosenberg asked if the size of the responses would be a problem for DNS, because it runs over UDP. He also asked if there one could just return an LDAP URL within the response to get further info such as capabilities. Patrik answered that this is entirely possible. In any case, ENUM would never define a new URL. If ENUM decides that one is needed, it would go to the appropriate working group to have them make one. Jonathan Lennox asked if there is a difference between saying "Give me the SIP server for this number" and "give me the directory server for this number". Scott Petrack replied that the difference is that you speak SIP to a SIP server and LDAP to an LDAP server. The two servers have different URLs. It must be possible to get back both in a response (if they both exist of course). c. Qualification of a request (this means having the server apply some filter to a response. There may be many URLs in the repsonse, and the requestor is only interested in some subset). Scott Petrack said that they are out of scope, unless there is some problem with network bandwidth and they are required to make the responses fit within a UDP packet. f. Provisioning of the Listing Information Scott Bradner said that this is generally out of scope for ENUM, and will go into some other group. Patrik Falstrom said that his presentation covers some aspect of this. g. Security Anne said that we should point to DNS-sec, except that any E164 specific stuff would be within scope. Scott Bradner pointed out that the IESG requires WG to think about security. h. Response time and timeouts Anne said that clearly performance requirements are in. Christian Huitema said that since we have committed to DNS, we have no choice but to live with its performance. Anne replied that we will certainly need to document performance. Someone (?) noted that DNS "experts" differ wildly on what performance DNS technology can achieve. Scott Petrack said that it is not assumed a priori that the ENUM solution will run on the public DNS infrastructure. i. Number portability Anne Brown said that there may be more than one provider who wants to provide a given number. This can't be done by a telephone number tree. Someone (?) said that who "owns" the telephone number is out of scope. Dave Oran noted that if you stay within the IP world, portability comes for free. He asked if the requirement is that the ENUM solution should replace the existing system for global number portability? Melinda Shore said that there will be a conflict between number portability and performance requirements. Someone (?) that to be useful the ENUM solution must fit within the time budget for Call setup times. j. Miscellaneous comments Milo Orsic said tha mobility should be out of scope. There was general agreement that the dynamic nature of information needed to support mobility made it difficult to use DNS for everything, although the ENUM solution might fit in with a more general mobile service. Jonathan Rosenberg wanted an explicit non-requirement that ENUM would not be used for gateway selection. David Gurle asked to review the reasons for the assumption of a DNS-based solution. Scott P said that there was agreement that DNS was one reasonable approach, and this group was chartered to see if it would really work. Scott Bradner made the comment that the IESG felt that there would never be real agreement between the various base approaches, so that it was most appropriate to develop each one separately. Someone (?) stated that such a server must serve different networks and therefore the service might use different protocols Scott Petrack answers, that we shall not do everything, and look only for things that can be done with DNS. 4. Patrik Falstrom's Presentation: draft-faltstrom-e164-03.txt Patrik Falstrom presented his draft. He mentioned that it is flavored by portability, which was its original purpose. It is based on the standard set of indirections used throughout the Internet: URL->domain name->IP address->routing DNS is a database, good at lookups and distributed delegation. DNS is not good for searches. Ericssn has already replaced done work replacing an IN database by DNS lookups for number portability. It was further stated, that DNS Naming schemes are already defined for E-Mail to FAX translations. Patrik's solution uses the specific resource records: NAPTR: domain name to a list of services. SRV: service to list of domain names. Patrik proposes a listing service, that makes use of DNS. There followed some "animated discussion" on the subject of how one can tell if a given number is part of the E164 domain or if it belongs to some other domain: Dave Oran asked how the client could know if a given number belongs to e164.int or something else. Scott Petrack said that this is within the scope of ENUM. Scott Bradner said that we don't want to spend time on what goes on the "right hand side of the @ sign". Let's say that it's in some magic configuration file. Christian said that there have been advances in DNS. We might be able to discover the correct zone in some way. Patrik pointed out that his draft can be used to map from one zone to another. David Gurle pointed out that there is a distinction between E164 numbers and private number. Scott Petrack replied that one could put something else besides e164.int, but that the WG would have to either pretend that the base domain is already a given, or specify some way to determine the base domain. Anne Brown asked if "I have two service providers, who lists my information." Scott Petrack replied that Patrik's draft distributes the information among multiple places in any case. Christian Huitema said that this was not enough -- the root of the information itself must not be unique. Scott Petrack asked that this discussion get carried to the list. In any case, we must provide a solution for the case where the base domain is decided. There was a question about why one put a dot in between each digit. Why couldn't it be instead a unique email address? The answer is that this group has been chartered to look at phone numbers. Christian Huitema mentioned that the CNAME could be used to point you somewhere else. Willi Wimmreuter pointed out that numbering subdomains don't always match administrative boundaries. Milo asked about using 800 numbers. Scott Petrack claimed that all these problems are similar to just having numbers from different numbering spaces. 800 numbers are not international E164 numbers. Mo Zonoun asked about retrieving carrier access codes. Scott Petrack said that they are out of scope. These are merely numbers that are dialed for access to certain providers. Dave Oran said that given that this is a listing service, we don't need number portability, if someone defines his own zone. Patrik replied that in order to port, the ported-from domain simply places an NS record pointing to the new name server, in whose zone there is the listing service for the number. There can be complete separation between the location of the NS information, the NAPTR information, the SRV information, and the DNS resolution information. Scott Petrack strongly suggested that everyone read the complete definition of the 4 resource records used in Patrik's draft, in order to determine if they were appropriate or not. Anne Brown asked if it is possible to stop someone from listing a number for her phone number if she so desired. Patrick replied that this is normally handled either by contractual arrangements or one-way pointers. DNS spoofing is a "well known" problem. Scott Petrack mentioned that certain RRs ma need to be signed. Scott Bradner said that any problem concerning how data is provisioned into the system is out of scope. Scott Petrack mentioned that in the worst case where everyone ports a number, every number would require an NS record in the DNS. Dean Willis reminded us that there is both a forward and reverse look-up, and every dialing/numbering plan has its own root. Scott Petrack _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Dec 2 17:11:25 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02102 for ; Thu, 2 Dec 1999 17:11:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA03498; Thu, 2 Dec 1999 17:10:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA03339 for ; Thu, 2 Dec 1999 17:10:06 -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 RAA01713 for ; Thu, 2 Dec 1999 17:10:32 -0500 (EST) Received: from stl-hub-01.boeing.com ([192.76.190.51]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id QAA22765 for ; Thu, 2 Dec 1999 16:10:32 -0600 (CST) Received: from [199.191.48.146] by stl-hub-01.boeing.com for enum@ietf.org; Thu, 2 Dec 1999 16:10:31 -0600 Received: by engr03.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Thu, 2 Dec 1999 17:09:32 -0500 Reply-To: From: "Albert Manfredi" To: "Scott Petrack" , Subject: RE: [Enum] Summary and Minutes of ENUM in Washington Date: Thu, 2 Dec 1999 17:10:25 -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: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 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 > There followed some "animated discussion" on the subject > of how one > can tell if a given number is part of the E164 domain or > if it belongs > to some other domain: > > Dave Oran asked how the client could know if a > given number belongs > to e164.int or something else. > > Scott Petrack said that this is within the scope of ENUM. > > Scott Bradner said that we don't want to spend time > on what goes > on the "right hand side of the @ sign". One point that wasn't mentioned in the minutes. This discussion took place at the close of the session. As I understand it, the DNS today has a peer field to the IP address which is an ATM End System Address (AESA). Is this so? If this is so, then why not use that field for E.164, which is after all already an accepted format, encapsulated by the 20-byte AESA frame? Now you don't have to worry about the incredibly long series of numbers and dots to the left of an @ symbol. You simply have a third field to search on. So a name can be mapped to an IP address and an AESA (which incorporates E.164). Christian Huitema brought up the question, "How do you know you have an E.164 number?" My first answer _was_ that it is preceded by a + symbol. But in fact, a much better answer is that the 20-byte AESA field has an AFI (Authority and Format Identifier) byte as its first byte, and that is used to identify E.164. There are also two other possible formulations of the 20-byte AESA already standardized, which could be used here as well. And potentially many more, including possible multicast or even portable telephone numbers. (Okay, this is outside the enum scope.) What's wrong with this approach, given that DNS already is set up for the AESA? Bert albert.e.manfredi@boeing.com _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Dec 2 18:30:02 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09548 for ; Thu, 2 Dec 1999 18:30:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA23925; Thu, 2 Dec 1999 18:29:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA23864 for ; Thu, 2 Dec 1999 18:29:12 -0500 (EST) Received: from mail.mandarin.com (mail.mandarin.com [212.212.92.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09255 for ; Thu, 2 Dec 1999 18:29:26 -0500 (EST) Received: from mandarin.com ([127.0.0.1]) by mail.mandarin.com with SMTP (NetNow!/3.0.0.999) id ML5927027A for enum@ietf.org; Thu, 02 Dec 1999 23:25:22 -0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 2 Dec 1999 23:25 +0000 (Penarth Winter Time) From: Management@numbering.com (Richard D G Cox) Subject: RE: [Enum] ENUM Requirements To: enum@ietf.org In-Reply-To: <199912021700.MAA10005@optimus.ietf.org> Reply-To: management@numbering.com Message-Id: Organization: Mandarin Technology Limited Precedence: Special-Delivery X-Hops: 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 Larry Cox wrote: > For numbers such as emergency call (typically 911 in North America) and > toll free (800 or ..), the address may vary depending on the location > where it is translated, the time of day, or other variables. Most people would prefer to say the address associated with the number does not vary; more commonly, the /routing/ or /translation/ will vary according to several factors - such as include the location of the caller (derived from the (network) A-number in the case of landlines, but also from the radio site data in the case of mobile terminals). From a global, rather than North American, standpoint, this is an important distinction. I guess most people will be familiar with the proposals for more accurate location of cellphones in the USA, but similar proposals are unlikely to be replicated in other countries for a while, mainly due to the high cost. > If the address associated with an E.164 number changes at 6 hour > intervals (for toll free numbers this is not uncommon), The situation is far more complex than that. Globally, routings will be changed on a dynamic basis according to the call loadings on individual call centres. A TV ad running in one time zone may create a sudden demand for answering resources from several call centres, while calls from other locations may then be assigned different handling algorithms because their otherwise-first-choice call centre is subject to a higher load than normal at that time. This can result in the routings changing on a minute-to-minute basis. There is a need to define - unambiguously, but of necessity on an address-by-address basis - how and where the routing decision-making is to be implemented, and whether those routing decisions are to be transmitted back down the line to be implemented at an earlier point. > We should also not break the system that chooses a destination for > the call based on the calling party number if this can be avoided. > If I call an 800 number to order a pizza and due to the way the call > is routed I find myself talking to someone in Los Angeles when I want > my pizza delivered in Atlanta, the functionality of the system has > been compromised. While some services still see the location as a priority, in the majority of cases the main requirement is speed of answer in a compatible language; existing data networks can then transfer the order-taker's information to the appropriate point of delivery. Richard D G Cox Mandarin Technology, Penarth, Wales: +44 29 2031 (voice) 1131 (fax) 1110. Specialising in Telecommunications Interconnection and Numbering services. _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Dec 3 10:00:14 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03444 for ; Fri, 3 Dec 1999 10:00:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA16705; Fri, 3 Dec 1999 09:59:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA16622 for ; Fri, 3 Dec 1999 09:59:02 -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 JAA03061 for ; Fri, 3 Dec 1999 09:59:29 -0500 (EST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Fri, 3 Dec 1999 08:58:36 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 3 Dec 1999 08:58:22 -0600 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24919B33@bcarua63.ca.nortel.com> From: "Anne Brown" To: "'enum@ietf.org'" Subject: RE: [Enum] Capabilities - Was ENUM Requirements Date: Fri, 3 Dec 1999 08:58:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF3D9E.D669F5BE" 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_01BF3D9E.D669F5BE Content-Type: text/plain; charset="ISO-8859-1" Richard, After double-checking my meeting notes I see that you are correct about capabilities being in the scope. My mistake. As you suggest, we decided to have to capability to point to either a directory server, or whatever rescap comes up with. Version 2 of the requirements will contain this change. Regards, Anne ------_=_NextPart_001_01BF3D9E.D669F5BE Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Enum] Capabilities - Was ENUM Requirements

Richard,

After double-checking my meeting notes = I see that you are correct about capabilities being in the scope.  = My mistake.  As you suggest, we decided to have to capability to = point to either a directory server, or whatever rescap comes up = with.  Version 2 of the requirements will contain this = change.

Regards,
Anne

------_=_NextPart_001_01BF3D9E.D669F5BE-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Dec 3 10:01:56 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04417 for ; Fri, 3 Dec 1999 10:01:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA19137; Fri, 3 Dec 1999 10:01:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA19046 for ; Fri, 3 Dec 1999 10:00:58 -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 KAA04136 for ; Fri, 3 Dec 1999 10:01:24 -0500 (EST) Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprtp.ntcom.nortel.net; Fri, 3 Dec 1999 09:59:18 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 3 Dec 1999 09:59:19 -0500 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24919B34@bcarua63.ca.nortel.com> From: "Anne Brown" To: "'ENUM'" Subject: E: [Enum] Standards Coordination - Was ENUM Requirements Date: Fri, 3 Dec 1999 09:59:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF3D9E.F8E1BC76" 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_01BF3D9E.F8E1BC76 Content-Type: text/plain; charset="iso-8859-1" Richard I understood from an email Patrik sent to you, Scott and myself on November 18, that he may be attending the next SG2 meeting. I will be attending the TIPHON WG4 meeting next week. While not an official liaison, I can at the very least socialize the work. As well I know of people from both SG2 and TIPHON who monitor the ENUM list. Patrik, Will you be an official liaison at the SG2 meeting? Regards, Anne ------_=_NextPart_001_01BF3D9E.F8E1BC76 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable E: [Enum] Standards Coordination - Was ENUM Requirements

Richard

I understood from an  email = Patrik sent to you, Scott and myself on November 18, that he may be = attending the next SG2 meeting.

I will be attending the TIPHON WG4 = meeting next week.  While not an official liaison, I can at the = very least socialize the work.

As well I know of people from both SG2 = and TIPHON who monitor the ENUM list.

Patrik,
Will you be an official liaison at = the SG2 meeting?

Regards,
Anne

------_=_NextPart_001_01BF3D9E.F8E1BC76-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Dec 3 10:13:45 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10840 for ; Fri, 3 Dec 1999 10:13:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA05767; Fri, 3 Dec 1999 10:12:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA05610 for ; Fri, 3 Dec 1999 10:12:52 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10566 for ; Fri, 3 Dec 1999 10:13:19 -0500 (EST) Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprtp1.ntcom.nortel.net; Fri, 3 Dec 1999 10:12:52 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 3 Dec 1999 10:12:52 -0500 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24919B35@bcarua63.ca.nortel.com> From: "Anne Brown" To: "'ENUM'" Subject: FW: [Enum] ENUM Requirements Date: Fri, 3 Dec 1999 10:12:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF3DA0.DE3B31CA" 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_01BF3DA0.DE3B31CA Content-Type: text/plain; charset="iso-8859-1" Christian, -----Original Message----- From: Christian Huitema [mailto:huitema@research.telcordia.com] Sent: November 30, 1999 5:40 PM To: Richard Shockey; Melinda.Shore@nokia.com; Brown, Anne [NORSE:6L47-I:EXCH]; enum@ietf.org Subject: RE: [Enum] ENUM Requirements At 03:09 PM 11/30/99 -0600, Richard Shockey wrote: > [.. snip ..] >I think we all want to avoid clients having any prior knowledge of national >plan specific features. We debated this at length in DC, and we also debated it in previous instantiations of the BOF. Dial plans are here to stay, and it is very important to accomodate them. Joe User or Jane Average have no idea of what E.164 means. Frankly, how many times do you see phone numbers on business cards written with the explicit "+" convention, as in "+1 973 829 5555"? You are much more likely to see the number printed exactly as the person would have dialed it, using the local plan. And you may bet that these numbers would be the most likely input to any translation system. I don't think that we can expect a global mapping service to have in its scope how local or private numbers are mapped to global numbers. As well, the ENUM service should not require querying clients to have knowledge of all numbering plans and structures, only its local plan. I think that the right architecture should assume that dial-plans, be they national or private, are mapped into specific subtrees of the DNS, and that the number resolution software is parametrized by the name of the "translation root." Then, we have to make sure that we can use the right technique, e.g. point *.0.0.dial-plan.fr to *.e164.int using DNS aliasing. Is this not a local matter, and thus not subject to standardization? Or are you proposing that we design a method, but its application is for other groups? The usage of an explicit parametrization of the subtree has another advantage. It allows for the user to choose between parallel mapping trees, thus allowing for competition between different mapping systems and avoiding the monopoly capture of a single root. This facility is important. However, I still think the scope of this is national or even regional and perhaps not for the ENUM group. How each sub-tree is mapped should be done in some other group. I would suggest even outside the IETF. * Christian Huitema _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum Regards, Anne Brown Nortel Networks ------_=_NextPart_001_01BF3DA0.DE3B31CA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [Enum] ENUM Requirements

Christian,

-----Original = Message-----
From:   Christian = Huitema [mailto:huitema@research.telcordia.com]
Sent:   November 30, 1999 5:40 PM
To:     Richard Shockey; Melinda.Shore@nokia.com; Brown, Anne [NORSE:6L47-I:EXCH]; enum@ietf.org
Subject:       = RE: [Enum] ENUM Requirements

At 03:09 PM 11/30/99 -0600, Richard = Shockey wrote:

    > [.. snip ..]
    >I think we all want to avoid = clients having any prior knowledge of national
    >plan specific = features.

We debated this at length in DC, and = we also debated it in previous instantiations of = the BOF. Dial plans are here to stay, and it is very important = to accomodate them.  Joe User or Jane Average have no idea = of what E.164 means. Frankly, how many times do you see = phone numbers on business cards written with the explicit = "+" convention, as in "+1 973 = 829 5555"? You are much more likely to see the number = printed exactly as the = person would have dialed it, using the = local plan. And you may bet that these numbers = would be the most likely input to any translation = system.

I don't think that we can expect a = global mapping service to have in its scope how local or private numbers are = mapped to global numbers.  As well, the = ENUM service should not = require querying clients to have knowledge of all numbering plans and = structures, only its local = plan.

I think that the right architecture = should assume that dial-plans, be they national or = private, are mapped into specific subtrees of the DNS, and = that the number resolution software is parametrized by the = name of the "translation root." Then, we have to = make sure that we can use the right technique, e.g. = point *.0.0.dial-plan.fr to *.e164.int using DNS = aliasing.

Is this not a local matter, and = thus not subject to standardization?  Or are you proposing that we design a method, but = its application is for other groups?

The usage of an explicit = parametrization of the subtree has another advantage.  = It allows for the user to choose between parallel mapping trees, = thus allowing for competition between different mapping systems = and avoiding the monopoly capture of a single = root.

This facility is = important.  However, I = still think the scope of = this is national or even regional and perhaps not for the ENUM group.  How each sub-tree = is mapped should be done in = some other group.  I would suggest even outside the = IETF.

  • Christian Huitema

_______________________________________________
enum mailing list
enum@ietf.org
http://www.ietf.org/mailman/listinfo/enum<= U>

Regards,

Anne Brown
Nortel Networks

------_=_NextPart_001_01BF3DA0.DE3B31CA-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Dec 3 10:24:09 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16368 for ; Fri, 3 Dec 1999 10:24:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA17747; Fri, 3 Dec 1999 10:22:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA17707 for ; Fri, 3 Dec 1999 10:22:43 -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 KAA15837 for ; Fri, 3 Dec 1999 10:23:10 -0500 (EST) Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprtp.ntcom.nortel.net; Fri, 3 Dec 1999 10:22:38 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 3 Dec 1999 10:22:37 -0500 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24919B36@bcarua63.ca.nortel.com> From: "Anne Brown" To: "'ENUM'" Subject: FW: [Enum] Geneval Workshop - Was ENUM Requirements Date: Fri, 3 Dec 1999 10:22:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF3DA2.3A279B76" 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_01BF3DA2.3A279B76 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Valerie, Thank you for your clarification on E.164 numbers. =20 I have also seen the workshop invitation and intend to go, if it is = still on. Due to its large scope, however, I think the most we can hope for = out if it is to have some plan for how to handle coordination of the ENUM = work. Regards, Anne Brown Nortel Networks -----Original Message----- From: BARNOLE Valerie CNET/DAC/ISS [mailto:valerie.barnole@cnet.francetelecom.fr] =20 Sent: December 01, 1999 12:39 PM To: 'Richard Shockey'; Melinda.Shore@nokia.com; Brown, Anne [NORSE:6L47-I:EXCH]; enum@ietf.org =20 Cc: 'Fred Gaechter' Subject: RE: [Enum] ENUM Requirements As a delegate in Q.1/2 in SG2, I would like to give some comments on = the issues raised in Richard's and Melinda's mails : Please see my comments in italic letters inserted in the mail below. I apologize if I just say things that everybody knows. Val=E9rie 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 =20 -----Message d'origine----- De: Richard Shockey [ mailto:rshockey@ix.netcom.com =20 > ] Date: mardi 30 novembre 1999 22:10 =C0: Melinda.Shore@nokia.com; arbrown@nortelnetworks.com; enum@ietf.org =20 Objet: RE: [Enum] ENUM Requirements At 02:25 PM 11/30/1999 -0600, Melinda.Shore@nokia.com wrote: > > Are 1 800 numbers or the UK version of toll free legitimate > > e164 numbers or is this national numbering plan specific. > > I agree these numbers are essential to resolve but what > > other classes of numbers must resolve as well... 900 ? > >Freephone numbers are not E.164 addresses, but I think >it's pretty clear that the mechanism developed by enum >will work just as well in other domains (say, nanpa.int). >The problem, of course, is that applications would need >to be able to determine whether a number exists >within the E.164 domain or a national numbering plan >domain. > I don't think this is a problem. Its clear to me now that specific = national numbering plan features could be zoned specifically for that purpose in = much the way you suggest if the zone .1 points to a specific delegation for .8.0.0. or .8.8.8 etc. What I was not clear of originally was that = multiple digits could combined in this way. I think we all want to avoid clients having any prior knowledge of = national plan specific features. 1 800 numbers are E.164 numbers. I explain : an E.164 number (max = length =3D 15 digits) has the following structure : CC (country code, 1 to 3 digits =3D 1 for the USA) followed by a NSN = (national significant number, max length =3D 12 digits, here =3D 800....). But = they are names, and not addresses, so in order to reach the endpoint, such a = number (with the function of a name) has to be translated into an address, currently another E.164 number (with the function of an address). =20 > > Is it appropriate at this time to formally Require ENUM to coordinate > > efforts with ITU SG2 etc? > >Require? I should think not. At any right, the only >body I know of which now has a work item on E.164->IP >address resolution is ETSI Project TIPHON. Eurescom has >a very large telecoms database project, but I think >that it's scoped somewhat differently. You're right .. require is not the right word though I think this = proposal will closely examined by IETF "sister" standards bodies. ITU-T Question =BD ("applications of numbering and addressing plans for = fixed and mobile services", will deal also with naming) is part of the = Working Party =BD ("numbering, routing and global mobility") which is itself = part of Study Group 2 ("network and service operation). During our last WP1/2 = at the end of september 99, meeting, we created a project named "Numbering, = naming and addressing for interworking between E.164 and IP address-based networks".=20 We also discuss the need of coordinating our work with entities like = IETF and ICANN. In this view, with inputs from the ITU policy and strategy department, we proposed the ITU to invite a meeting "IP and Telecoms Interworking Workshop" from 25 to 27th january 2000, in Geneva, = focussed on numbering, naming, addressing and routing for convergence of telecoms = and IP. This meeting is widely open to IETF, ICANN or others involved in = the topic. I do not know if some official invitation has been already sent, but we = hope IP people to attend in order to meet, identify key issues and progress together.We also expect IETF and ICANN to give us inputs on an agenda = item. I agree that "require" is not a correct and happy word to start a = fruitful coordination ! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 =20 GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org =20 http://www.ietf.org/mailman/listinfo/enum =20 >=20 _______________________________________________ enum mailing list enum@ietf.org =20 http://www.ietf.org/mailman/listinfo/enum =20 ------_=_NextPart_001_01BF3DA2.3A279B76 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [Enum] Geneval Workshop - Was ENUM Requirements

Valerie,

Thank you for your clarification on = E.164 numbers. 

I have also seen the workshop = invitation and intend to go, if it is still on.  Due to its large = scope, however, I think the most we can hope for out if it is to have = some plan for how to handle coordination of the ENUM work.

Regards,
Anne Brown
Nortel Networks

-----Original = Message-----
From:   BARNOLE Valerie = CNET/DAC/ISS [mailto:valerie.barnole@cnet.francetelecom.fr]=
Sent:   December 01, 1999 12:39 PM
To:     'Richard = Shockey'; Melinda.Shore@nokia.com; Brown, Anne [NORSE:6L47-I:EXCH]; enum@ietf.org
Cc:     'Fred = Gaechter'
Subject:       = RE: [Enum] ENUM Requirements

As a delegate in Q.1/2 in SG2, I would = like to give some comments on the issues raised in = Richard's and Melinda's mails = :

Please see my comments in italic = letters inserted in the mail below. I apologize if I = just say things that everybody knows.

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

valerie.barnole@cnet.francetelecom.fr


-----Message d'origine-----
De:     = Richard Shockey [ mailto:rshockey@ix.netcom.com
<mailto:rshockey@ix.netcom.com> ]
Date:   mardi 30 novembre 1999 22:10
=C0:      Melinda.Shore@nokia.com; arbrown@nortelnetworks.com; enum@ietf.org
Objet:  RE: [Enum] ENUM Requirements


At 02:25 PM 11/30/1999 -0600, = Melinda.Shore@nokia.com wrote:

      > > = Are 1 800 numbers or = the UK version of toll free legitimate
      > > = e164 numbers or is this = national numbering plan specific.
      > > = I agree these numbers = are essential to resolve but what
      > > = other classes of = numbers must resolve as well... 900 ?

    >
    >Freephone numbers are not = E.164 addresses, but I think
    >it's pretty clear that the = mechanism developed by enum
    >will work just as well in = other domains (say, nanpa.int).
    >The problem, of course, is = that applications would need
    >to be able to determine = whether a number exists
    >within the E.164 domain or a = national numbering plan
    >domain.
    >

I don't think this is a = problem. Its clear to me now that specific national numbering = plan features could be zoned specifically for that purpose = in much the way you suggest if the zone .1 points to a = specific delegation for = .8.0.0.  or .8.8.8 etc. What I was = not clear of originally was that multiple digits = could combined in this way.

I think we all want to avoid clients = having any prior knowledge of national plan specific = features.

1 800 numbers are E.164 numbers. I = explain : an E.164 number (max length =3D 15 digits) has the = following structure :
CC (country code, 1 to 3 digits =3D 1 = for the USA) followed by a NSN (national significant = number, max length =3D 12 digits, here =3D 800....).  But = they are names, and not addresses, so in order to reach the = endpoint, such a number (with the function of a name) has to be = translated into an address, currently another E.164 number (with = the function of an address).

 

      > > = Is it appropriate at = this time to formally Require ENUM to coordinate
      > > = efforts with ITU SG2 = etc?

    >
    >Require?  I should think = not.  At any right, the only
    >body I know of which now has = a work item on E.164->IP
    >address resolution is ETSI = Project TIPHON.  Eurescom has
    >a very large telecoms = database project, but I think
    >that it's scoped somewhat = differently.

You're right .. = require is not the right word though I think this proposal will = closely examined by  IETF "sister" = standards bodies.

ITU-T Question =BD ("applications of numbering and addressing plans = for fixed and mobile services", will deal also = with naming) is part of the = Working Party =BD ("numbering, routing and global mobility") which = is itself part of Study Group 2 ("network and = service operation). During our last WP1/2 at the end = of september 99, meeting, we created a project named "Numbering, naming and addressing for interworking = between E.164 and IP address-based networks".

We also discuss the need of = coordinating our work with entities like IETF and ICANN. In this = view, with inputs from the ITU policy and strategy department, we = proposed the ITU to invite a meeting "IP and = Telecoms Interworking Workshop" from 25 to = 27th january 2000, in Geneva, focussed = on numbering, naming, addressing and routing for = convergence of telecoms and = IP. This meeting is widely open to IETF, = ICANN or others involved in the topic.

I do not know if some official = invitation has been already sent, but we hope IP people to = attend in order to meet, identify key issues and progress together.We also expect IETF and ICANN to give us inputs = on an agenda item.  = I agree that "require" is not a correct = and happy word to start a fruitful coordination = !

 >>>>>>>>>>>>>= ;>>>>>>>>>>>>>>>>>>= ;>>>>>>>
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
<<<<<<<<<<<<<<&= lt;<<<<<<<<<<<<<<<<<&= lt;<<<<<

_______________________________________________
enum mailing list
enum@ietf.org
http://www.ietf.org/mailman/listinfo/enum
<http://www.ietf.org/mailman/listinfo/enum<= FONT SIZE=3D2 FACE=3D"Arial">>



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

------_=_NextPart_001_01BF3DA2.3A279B76-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Dec 3 10:35:46 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22781 for ; Fri, 3 Dec 1999 10:35:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA00653; Fri, 3 Dec 1999 10:33:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA00525 for ; Fri, 3 Dec 1999 10:33:07 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21526 for ; Fri, 3 Dec 1999 10:33:29 -0500 (EST) Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprtp1.ntcom.nortel.net; Fri, 3 Dec 1999 10:30:46 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 3 Dec 1999 10:30:47 -0500 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24919B37@bcarua63.ca.nortel.com> From: "Anne Brown" To: "'ENUM'" Subject: FW: [Enum] Summary and Minutes of ENUM in Washington Date: Fri, 3 Dec 1999 10:30:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF3DA3.5EBACDCC" 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_01BF3DA3.5EBACDCC Content-Type: text/plain; charset="iso-8859-1" Alfred, In response to Christian's question "How do you know you have an E.164 number?", a person today is expected to know the difference between a local and an E.164 number in order to make a phone call. In the future we, or an application on our behalf, will be able to lookup a telephone number, given some input information. I would hope that an E.164 number is returned, if the request was to a global service (i.e., not a request to a local service or directory). I would also hope that the user would never see the number, but only verify the intended recipient before commencing with the session. Regards, Anne -----Original Message----- From: Albert Manfredi [mailto:albert.e.manfredi@boeing.com] Sent: December 02, 1999 5:10 PM To: Scott Petrack; enum Subject: RE: [Enum] Summary and Minutes of ENUM in Washington > There followed some "animated discussion" on the subject > of how one > can tell if a given number is part of the E164 domain or > if it belongs > to some other domain: > > Dave Oran asked how the client could know if a > given number belongs > to e164.int or something else. > > Scott Petrack said that this is within the scope of ENUM. > > Scott Bradner said that we don't want to spend time > on what goes > on the "right hand side of the @ sign". One point that wasn't mentioned in the minutes. This discussion took place at the close of the session. As I understand it, the DNS today has a peer field to the IP address which is an ATM End System Address (AESA). Is this so? If this is so, then why not use that field for E.164, which is after all already an accepted format, encapsulated by the 20-byte AESA frame? Now you don't have to worry about the incredibly long series of numbers and dots to the left of an @ symbol. You simply have a third field to search on. So a name can be mapped to an IP address and an AESA (which incorporates E.164). Christian Huitema brought up the question, "How do you know you have an E.164 number?" My first answer _was_ that it is preceded by a + symbol. But in fact, a much better answer is that the 20-byte AESA field has an AFI (Authority and Format Identifier) byte as its first byte, and that is used to identify E.164. There are also two other possible formulations of the 20-byte AESA already standardized, which could be used here as well. And potentially many more, including possible multicast or even portable telephone numbers. (Okay, this is outside the enum scope.) What's wrong with this approach, given that DNS already is set up for the AESA? Bert albert.e.manfredi@boeing.com _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01BF3DA3.5EBACDCC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [Enum] Summary and Minutes of ENUM in Washington

Alfred,

In response to Christian's = question "How do you know you have = an E.164 number?",  a person = today is expected to know the difference between a local and an E.164 = number in order to make a phone call.  In the future we, or an = application on our behalf, will be able to lookup a telephone number, = given some input information.  I would hope that an E.164 number = is returned, if the request was to a global service (i.e., not a = request to a local service or directory).  I would also hope that = the user would never see the number, but only verify the intended = recipient before commencing with the session.

Regards,
Anne

-----Original = Message-----
From:   Albert = Manfredi [mailto:albert.e.manfredi@boeing.com]<= B>
Sent:   December 02, 1999 5:10 PM
To:     Scott Petrack; enum
Subject:       = RE: [Enum] Summary and Minutes of = ENUM in Washington

    > There followed some = "animated = discussion"  on the subject
    > of how one
    > can tell if a given number is = part of the E164 domain or
    > if it belongs
    > to some other domain:
    >
    > =       Dave Oran asked how the client could know if a
    > given number belongs
    > to e164.int or something = else.
    >
    > =       Scott Petrack said that this is within the scope of = ENUM.
    >
    > =       Scott Bradner said that we don't want to spend time
    > on what goes
    > on the "right hand side of the @ = sign".

One point that wasn't = mentioned in the minutes. This discussion took place at the close = of the session.
As I understand it, the DNS today has = a peer field to the IP address which is an ATM = End System Address (AESA). Is this so?

If this is so, then why not use that = field for E.164, which is after all already an = accepted format, encapsulated by the 20-byte AESA frame?

Now you don't have to worry = about the incredibly long series of numbers and dots = to the left of an @ symbol. You simply have a third field to = search on. So a name can be mapped to an IP address and an AESA = (which incorporates E.164).

Christian Huitema brought up the = question, "How do you know you have an E.164 = number?" My first answer _was_ that it is = preceded by a + symbol. But in fact, a much better answer is = that the 20-byte AESA field has an AFI (Authority and Format = Identifier) byte as its first byte, and that is = used to identify E.164. There are also two other possible = formulations of the 20-byte AESA already standardized, which = could be used here as well. And potentially many more, including = possible multicast or even portable telephone numbers.  (Okay, this is outside the enum scope.)

What's wrong with this = approach, given that DNS already is set up for the = AESA?
Bert
albert.e.manfredi@boeing.com


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

------_=_NextPart_001_01BF3DA3.5EBACDCC-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Dec 3 12:02:17 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07119 for ; Fri, 3 Dec 1999 12:02:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA19133; Fri, 3 Dec 1999 12:01:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA19071 for ; Fri, 3 Dec 1999 12:00:58 -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 MAA06625 for ; Fri, 3 Dec 1999 12:01:24 -0500 (EST) Received: from stl-hub-01.boeing.com ([192.76.190.51]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA22096 for ; Fri, 3 Dec 1999 11:01:25 -0600 (CST) Received: from [199.191.48.134] by stl-hub-01.boeing.com for enum@ietf.org; Fri, 3 Dec 1999 11:01:22 -0600 Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Fri, 3 Dec 1999 12:00:23 -0500 Reply-To: From: "Albert Manfredi" To: "Anne Brown" , "'ENUM'" Subject: RE: [Enum] Summary and Minutes of ENUM in Washington Date: Fri, 3 Dec 1999 12:01:16 -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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 In-Reply-To: <31AF4D00A662D211B6D10000F8BCBC24919B37@bcarua63.ca.nortel.com> Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Anne, I'm not sure your response addresses Christian's concern. Maybe it does, but I took it differently. To me, the question is "how does a host send a DNS request, with an E.164 telephone number in it, in such a way that the DNS knows that the number is in fact E.164?" To understand the question, it was one reaction to my suggestion of making the E.164 number a field that is _peer_ to the IP address. Not part of an IP name, as has been proposed here. Since I believe that the 20-byte AESA field already exists in the DNS database format, I also believe that the answer to Christian's concern should be quite elegant. When you request a resolution of an E.164 number, the field used in the request is the AESA field. The number is encoded as an encapsulated E.164 address, the AFI byte up front is set to 0x45, and there is no ambiguity. And this is expandable in the future. In other words, this is a different scheme from the one discussed in DC. Telephone numbers get their own field, using the field allocated now to AESAs. Bert albert.e.manfredi@boeing.com -----Original Message----- From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of Anne Brown Sent: Friday, December 03, 1999 10:31 AM To: 'ENUM' Subject: FW: [Enum] Summary and Minutes of ENUM in Washington Alfred, In response to Christian's question "How do you know you have an E.164 number?", a person today is expected to know the difference between a local and an E.164 number in order to make a phone call. In the future we, or an application on our behalf, will be able to lookup a telephone number, given some input information. I would hope that an E.164 number is returned, if the request was to a global service (i.e., not a request to a local service or directory). I would also hope that the user would never see the number, but only verify the intended recipient before commencing with the session. Regards, Anne -----Original Message----- From: Albert Manfredi [mailto:albert.e.manfredi@boeing.com] Sent: December 02, 1999 5:10 PM To: Scott Petrack; enum Subject: RE: [Enum] Summary and Minutes of ENUM in Washington > There followed some "animated discussion" on the subject > of how one > can tell if a given number is part of the E164 domain or > if it belongs > to some other domain: > > Dave Oran asked how the client could know if a > given number belongs > to e164.int or something else. > > Scott Petrack said that this is within the scope of ENUM. > > Scott Bradner said that we don't want to spend time > on what goes > on the "right hand side of the @ sign". One point that wasn't mentioned in the minutes. This discussion took place at the close of the session. As I understand it, the DNS today has a peer field to the IP address which is an ATM End System Address (AESA). Is this so? If this is so, then why not use that field for E.164, which is after all already an accepted format, encapsulated by the 20-byte AESA frame? Now you don't have to worry about the incredibly long series of numbers and dots to the left of an @ symbol. You simply have a third field to search on. So a name can be mapped to an IP address and an AESA (which incorporates E.164). Christian Huitema brought up the question, "How do you know you have an E.164 number?" My first answer _was_ that it is preceded by a + symbol. But in fact, a much better answer is that the 20-byte AESA field has an AFI (Authority and Format Identifier) byte as its first byte, and that is used to identify E.164. There are also two other possible formulations of the 20-byte AESA already standardized, which could be used here as well. And potentially many more, including possible multicast or even portable telephone numbers. (Okay, this is outside the enum scope.) What's wrong with this approach, given that DNS already is set up for the AESA? 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 Dec 3 16:40:35 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25975 for ; Fri, 3 Dec 1999 16:40:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA02133; Fri, 3 Dec 1999 16:39:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA02079 for ; Fri, 3 Dec 1999 16:39:41 -0500 (EST) Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25695 for ; Fri, 3 Dec 1999 16:40:08 -0500 (EST) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by breeze.research.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA24609; Fri, 3 Dec 1999 16:39:32 -0500 (EST) Received: from seascape.research.telcordia.com (pptpdhcp25.research.telcordia.com [192.4.9.250]) by mailee.research.telcordia.com (8.8.8/8.8.8) with SMTP id QAA05815; Fri, 3 Dec 1999 16:39:32 -0500 (EST) Message-Id: <4.1.19991203162355.009f4f00@mailee.research.telcordia.com> X-Sender: huitema@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 03 Dec 1999 16:35:50 -0500 To: , "Anne Brown" , "'ENUM'" From: Christian Huitema Subject: RE: [Enum] Summary and Minutes of ENUM in Washington In-Reply-To: References: <31AF4D00A662D211B6D10000F8BCBC24919B37@bcarua63.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 12:01 PM 12/3/99 -0500, Albert Manfredi wrote: >Since I believe that the 20-byte AESA field already exists in the >DNS database format, I also believe that the answer to Christian's >concern should be quite elegant. When you request a resolution of an >E.164 number, the field used in the request is the AESA field. The >number is encoded as an encapsulated E.164 address, the AFI byte up >front is set to 0x45, and there is no ambiguity. And this is >expandable in the future. Alfred, I am afraid that you are mixing several elements of the DNS systems. I was not really aware of the 20 byte AESA field, and I don't know whether there is more than minimal experimental use of it. In any case, AESA provides an encoding for records, not for names, much like the A record encodes the IP addresses. The names themselves are encoded as sequences of tokens, usually represented in txt forms such as "a.b.c.com". My remark was that most users don't know that they are using E.164. They never heard of that standard. They are most likely to use the locally defined dialing plan to which they are used. If I designed a mapping system, I would make damn sure that it could be parameterized with a local dial plan. For example, if I have to map "#699 4267" (a valid number in our own plan), I woul probably map it to something like "7.6.2.4.9.9.6.#.local-dial-plan.telcordia.com" and I would then use "Non-Terminal DNS Name Redirection" (RFC 2672) to redirect branches of that subtree towards other subtrees, some of which could be definitions of "plain e.164." In fact, an "e.164" tree does not need to contain much more than a list of country codes pointing to various national subtrees. This allows for easy management, delegation, etc. And it does not mandate that we have a single root! -- Christian Huitema _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Dec 3 17:20:43 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16644 for ; Fri, 3 Dec 1999 17:20:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA21514; Fri, 3 Dec 1999 17:19:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA21418 for ; Fri, 3 Dec 1999 17:19:32 -0500 (EST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16288 for ; Fri, 3 Dec 1999 17:20:00 -0500 (EST) Received: from laptop (stl-mo14-42.ix.netcom.com [207.222.133.42]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA24954; Fri, 3 Dec 1999 17:19:55 -0500 (EST) Message-Id: <4.2.0.58.19991203160720.00a44ea0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 03 Dec 1999 16:17:44 -0600 To: Christian Huitema , "'ENUM'" From: Richard Shockey Subject: RE: [Enum] Summary and Minutes of ENUM in Washington In-Reply-To: <4.1.19991203162355.009f4f00@mailee.research.telcordia.com> References: <31AF4D00A662D211B6D10000F8BCBC24919B37@bcarua63.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > >In fact, an "e.164" tree does not need to contain much more than a list of >country codes pointing to various national subtrees. This allows for easy >management, delegation, etc. And it does not mandate that we have a single >root! And that can be easily cashed locally. Christian .. I did notice on the main IETF list you've pointed out some interesting statistics on DNS performance based on some monitoring of your local workstation. I hate to ask ..but do you have any thoughts on possible DNS performance expectations with ENUM in the picture above and beyond the 20% re transmission rates you experienced ? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Dec 3 23:18:17 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17292 for ; Fri, 3 Dec 1999 23:18:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id XAA12446; Fri, 3 Dec 1999 23:17:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id XAA12257 for ; Fri, 3 Dec 1999 23:17:29 -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 XAA17141 for ; Fri, 3 Dec 1999 23:17:57 -0500 (EST) Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhsbx15902; Sat, 4 Dec 1999 04:15:08 GMT Received: from dynamicsoft.com (1Cust195.tnt2.freehold.nj.da.uu.net [63.17.114.195]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id XAA19850; Fri, 3 Dec 1999 23:17:41 -0500 (EST) Message-ID: <384896F5.8E77209E@dynamicsoft.com> Date: Fri, 03 Dec 1999 23:22:13 -0500 From: Jonathan Rosenberg Organization: Dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: management@numbering.com CC: enum@ietf.org Subject: Re: [Enum] ENUM Requirements 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 Richard D G Cox wrote: > > > If the address associated with an E.164 number changes at 6 hour > > intervals (for toll free numbers this is not uncommon), > > The situation is far more complex than that. Globally, routings will be > changed on a dynamic basis according to the call loadings on individual > call centres. A TV ad running in one time zone may create a sudden demand > for answering resources from several call centres, while calls from other > locations may then be assigned different handling algorithms because their > otherwise-first-choice call centre is subject to a higher load than normal > at that time. > > This can result in the routings changing on a minute-to-minute basis. > > There is a need to define - unambiguously, but of necessity on an > address-by-address basis - how and where the routing decision-making > is to be implemented, and whether those routing decisions are to be > transmitted back down the line to be implemented at an earlier point. Remember, that the enum solution does not necessarily map a number to the actual destination host. Rather, it maps it to a URL, which may be a server that has the kind of logic you are talking about. For example, if I dial 800-123-4567, this may get translated to sip:8001234567@800numberservices.com. This turns out to be a large SIP server that is programmed with time of day routing capabilities. IMHO, what goes in enum is the most static piece of information possible. It points you to the server that knows how to handle the number further. -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 Sun Dec 5 09:15:50 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18522 for ; Sun, 5 Dec 1999 09:15:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA00936; Sun, 5 Dec 1999 09:14:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA00891 for ; Sun, 5 Dec 1999 09:14:39 -0500 (EST) Received: from sheffield.cnchost.com (sheffield.concentric.net [207.155.252.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18164 for ; Sun, 5 Dec 1999 09:15:08 -0500 (EST) Received: from adsl-151-203-17-31.bellatlantic.net (adsl-151-203-17-31.bellatlantic.net [151.203.17.31]) by sheffield.cnchost.com id JAA09224; Sun, 5 Dec 1999 09:14:57 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Date: Sun, 5 Dec 1999 08:49:53 -0500 (EST) From: Scott Petrack X-Sender: scott.petrack@adsl-151-203-17-31.bellatlantic.net To: Dean Willis cc: iptel@lists.research.bell-labs.com, enum@ietf.org Subject: Re: [ENUM] Dynamics -- was RE: Human readable Route descriptors In-Reply-To: <000501bf2c78$a2a0ad40$9f168082@fh.ietf.innovationslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Catching up on almost a month of email over the next 2 days... On Thu, 11 Nov 1999, Dean Willis wrote: > Part of my initial adverse reaction to ENUM is my belief that the > association of IP addresses to phone numbers is an exceptionally dynamic > relationship, and that this relationship could not be adequately expressed > in a relatively static and cached DNS. > Yes, but the relationship of phone numbers to URLs is likely to be less dynamic. So one high-level service that you might need is "phone number --> sip: URL". Another might be "phone number --> tel: URL". It might even be that the sip signalling that ensues as a result of the first mapping might lead to a SIP redirect to the tel: URL. ... > > For example -- (all names and numbers fictitious) I as a phone user might > rent a phone number from a carrier, perhaps 13045551212 from BPI (Big Phone > Inc). The NANP NS delegates to the 304 area NS, which delegates exchange 555 > to the SBC NS. The SBC NS might contain a record pointing .1212 towards > sip:3045551212@sip.bpi.net;user=phone. As part of my rental fee for the > phone number, SBC allows me to either use sip.sbc.net as a registrar, or to > provision contacts into it using a web interface. In the simplest mode, > assume I use the registration services. When I turn my phone on, it sends a > SIP REGISTER to sip.bpi.net on behalf of 3045551212 listing the phone's > current IP address as a Contact:. > > Calls from the GSTN to my phone resolve in the following way: The call > enters the GSTN as a sequence of dialed digits. The carrier switching system > follows the standard PSTN routing to the nearest BPI switch registered as > handling my exchange (30555). BPI hands the call to an IP gateway. The > gateway does a DNS lookup on 3045551212, which resolves to > 3045551212@sip.bpi.net. The GW then sends an INVITE to sip.bpi.net and is > proxied or redirected to my phone. Note that nobody ever looked in the TRIP > routes to resolve the call. > Even in the scenario you give, there is a step: "BPI hands the call to an IP gateway". In a standards-based world this is what TRIP is used for. Even if the BPI switch knows that 3045551212 is a BPI number, it might decide to use TRIP to find a gateway. > In the event that I place a call to the PSTN, 19153627878, things happen in > a very different fashion. > > In this sequence, my phone does a DNS lookup on the dialed number. Perhaps > it does not resolve (It's not an IP or LNP registered phone number). My > phone then sends an INVITE to sip.bpi.net with a request-URI of > tel:9153627878, perhaps with some sort of scope specifier. Next sip.bpi.net > consults its TRIP routing table to find one or more egress gateways and > either proxies or redirects my call. > > Alternative: > My phone could be configured to always send my calls to my outgoung proxy > sip.bpi.net. In this case, it sends the INVITE tel:9153627878. The proxy > does a DNS lookup, finds that the name does not resolve, consults TRIP, and > proxies or forwards the call. > > These scenarios work pretty well. But, I haven't been able to figure out a > scenario for local number portability from within DNS -- theoretcially, one > of the ENUM possibilities. Anybody want to tackle that? I'm concerned that > LNP is more like NAT than it is a 302: redirect . . . > There are many different kinds of number portability, and many different ways to implement each kind. I think that it might be useful to produce an informative draft with a few examples. Scott _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sun Dec 5 18:43:09 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07267 for ; Sun, 5 Dec 1999 18:43:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA01719; Sun, 5 Dec 1999 18:42:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA01664 for ; Sun, 5 Dec 1999 18:42: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 SAA06969 for ; Sun, 5 Dec 1999 18:42:32 -0500 (EST) Received: from slb-hub-01.boeing.com ([129.172.13.51]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA13352 for ; Sun, 5 Dec 1999 15:42:33 -0800 (PST) Received: from [199.191.48.146] by slb-hub-01.boeing.com for enum@ietf.org; Sun, 5 Dec 1999 15:42:20 -0800 Received: by engr03.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Sun, 5 Dec 1999 18:41:22 -0500 Reply-To: From: "Albert Manfredi" To: "Jonathan Rosenberg" Cc: Subject: RE: [Enum] ENUM Requirements Date: Sun, 5 Dec 1999 18:42:16 -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) In-Reply-To: <384896F5.8E77209E@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 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 It's interesting to me that enum has decided to go this way; i.e. to combine the telephone number with the _name_ field of the DNS, and to use the name part to implicitly identify the numbering _plan_ used for the telephone number. One thing to worry about is that this could result in a lot of different entries for any one telephone number, when only one E.164 would suffice? Is this not true? I mean, doesn't this potentially list any globally unique E.164 number in the numbering plans of 150-odd countries? For example, the local Rome number 3295887 would potentially be listed as: 7885932@numerolocaleroma.it 788593206@numeriitalia.it 78859320639@inte164numbers.org 78859320639011@intcallsus.com and a host of other options for each of the other numbering plans extant. Using the approach of a peer field for the E.164 number (a peer with the name and the IP address), the onus of translating between numbering plan and E.164 could be placed on the host. And the host could, without too much difficulty, translate to its native numbering plan based on the host's own address location? (A mobile host could ultimately even use whatever local plan applies, if it can be located in real time with something like GPS. For example, it could have two options: use the local numbering plan or use your "home" numbering plan.) Bert albert.e.manfredi@boeing.com P.S. For clarity, what I'm talking about is that the DNS would be structured as follows (which it already is, I believe): name field IP address field AESA field A search on any one will return the other two. The AESA field can be and encapsulated E.164 number, or other options exist. The name field applies equally to AESA or IP addresses. At times, one or two of the three fields might be blank. Jonathan Rosenberg wrote: > > Richard D G Cox wrote: > > > > > If the address associated with an E.164 number > changes at 6 hour > > > intervals (for toll free numbers this is not uncommon), > > > > The situation is far more complex than that. Globally, > routings will be > > changed on a dynamic basis according to the call > loadings on individual > > call centres. A TV ad running in one time zone may > create a sudden demand > > for answering resources from several call centres, > while calls from other > > locations may then be assigned different handling > algorithms because their > > otherwise-first-choice call centre is subject to a > higher load than normal > > at that time. > > > > This can result in the routings changing on a > minute-to-minute basis. > > > > There is a need to define - unambiguously, but of > necessity on an > > address-by-address basis - how and where the routing > decision-making > > is to be implemented, and whether those routing > decisions are to be > > transmitted back down the line to be implemented at an > earlier point. > > Remember, that the enum solution does not necessarily map > a number to > the actual destination host. Rather, it maps it to a URL, > which may be a > server that has the kind of logic you are talking about. > For example, if > I dial 800-123-4567, this may get translated to > sip:8001234567@800numberservices.com. This turns out to > be a large SIP > server that is programmed with time of day routing capabilities. > > IMHO, what goes in enum is the most static piece of information > possible. It points you to the server that knows how to handle the > number further. > > -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 Dec 6 06:04:31 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22318 for ; Mon, 6 Dec 1999 06:04:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id GAA26553; Mon, 6 Dec 1999 06:03:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id GAA26483 for ; Mon, 6 Dec 1999 06:03:12 -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 GAA22049 for ; Mon, 6 Dec 1999 06:03:38 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Mon, 6 Dec 1999 12:03:23 +0100 Message-ID: <98388C05D464D111B61800805F1504160123E33E@p-ibis.issy.cnet.fr> From: BARNOLE Valerie CNET/DAC/ISS To: "'Anne Brown'" , "'ENUM'" Subject: RE: [Enum] Geneval Workshop - Was ENUM Requirements Date: Mon, 6 Dec 1999 12:03:21 +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 GAA26493 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 Anne, thanks for your kind answer. I'm affraid my clarification was not so clear because I did not explicitly mention that nationally dialled 1 800 numbers, with the US prefix 1 (not to confuse with the US country code = 1), were not strictly speaking E.164 numbers due to the fact that E.164 numbering plan does not include national prefixes (national prefixes belong to dialling plan). Anyway ! I am happy to see we share the same thoughts about launching coordination and I 'm ready to help from SG2 side. I take the opportunity of this mail to ask you if the mailing list "e164-to-ip" is still alive, because I could not subscribe. Regards. Valerie. 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: Anne Brown [mailto:arbrown@nortelnetworks.com] Date: vendredi 3 décembre 1999 16:23 À: 'ENUM' Objet: FW: [Enum] Geneval Workshop - Was ENUM Requirements Valerie, Thank you for your clarification on E.164 numbers. I have also seen the workshop invitation and intend to go, if it is still on. Due to its large scope, however, I think the most we can hope for out if it is to have some plan for how to handle coordination of the ENUM work. Regards, Anne Brown Nortel Networks BM__MailData-----Original Message----- From: BARNOLE Valerie CNET/DAC/ISS [mailto:valerie.barnole@cnet.francetelecom.fr] Sent: December 01, 1999 12:39 PM To: 'Richard Shockey'; Melinda.Shore@nokia.com; Brown, Anne [NORSE:6L47-I:EXCH]; enum@ietf.org Cc: 'Fred Gaechter' Subject: RE: [Enum] ENUM Requirements As a delegate in Q.1/2 in SG2, I would like to give some comments on the issues raised in Richard's and Melinda's mails : Please see my comments in italic letters inserted in the mail below. I apologize if I just say things that everybody knows. Valérie Barnole FT.BD/CNET/DAC/ARS tel. : + 33 1 45 29 58 39 fax : + 33 1 46 29 31 42 valerie.barnole@cnet.francetelecom.fr -----Message d'origine----- De: Richard Shockey [ mailto:rshockey@ix.netcom.com < mailto:rshockey@ix.netcom.com> ] Date: mardi 30 novembre 1999 22:10 À: Melinda.Shore@nokia.com; arbrown@nortelnetworks.com; enum@ietf.org Objet: RE: [Enum] ENUM Requirements At 02:25 PM 11/30/1999 -0600, Melinda.Shore@nokia.com wrote: > > Are 1 800 numbers or the UK version of toll free legitimate > > e164 numbers or is this national numbering plan specific. > > I agree these numbers are essential to resolve but what > > other classes of numbers must resolve as well... 900 ? > >Freephone numbers are not E.164 addresses, but I think >it's pretty clear that the mechanism developed by enum >will work just as well in other domains (say, nanpa.int). >The problem, of course, is that applications would need >to be able to determine whether a number exists >within the E.164 domain or a national numbering plan >domain. > I don't think this is a problem. Its clear to me now that specific national numbering plan features could be zoned specifically for that purpose in much the way you suggest if the zone .1 points to a specific delegation for .8.0.0. or .8.8.8 etc. What I was not clear of originally was that multiple digits could combined in this way. I think we all want to avoid clients having any prior knowledge of national plan specific features. 1 800 numbers are E.164 numbers. I explain : an E.164 number (max length = 15 digits) has the following structure : CC (country code, 1 to 3 digits = 1 for the USA) followed by a NSN (national significant number, max length = 12 digits, here = 800....). But they are names, and not addresses, so in order to reach the endpoint, such a number (with the function of a name) has to be translated into an address, currently another E.164 number (with the function of an address). > > Is it appropriate at this time to formally Require ENUM to coordinate > > efforts with ITU SG2 etc? > >Require? I should think not. At any right, the only >body I know of which now has a work item on E.164->IP >address resolution is ETSI Project TIPHON. Eurescom has >a very large telecoms database project, but I think >that it's scoped somewhat differently. You're right .. require is not the right word though I think this proposal will closely examined by IETF "sister" standards bodies. ITU-T Question ½ ("applications of numbering and addressing plans for fixed and mobile services", will deal also with naming) is part of the Working Party ½ ("numbering, routing and global mobility") which is itself part of Study Group 2 ("network and service operation). During our last WP1/2 at the end of september 99, meeting, we created a project named "Numbering, naming and addressing for interworking between E.164 and IP address-based networks". We also discuss the need of coordinating our work with entities like IETF and ICANN. In this view, with inputs from the ITU policy and strategy department, we proposed the ITU to invite a meeting "IP and Telecoms Interworking Workshop" from 25 to 27th january 2000, in Geneva, focussed on numbering, naming, addressing and routing for convergence of telecoms and IP. This meeting is widely open to IETF, ICANN or others involved in the topic. I do not know if some official invitation has been already sent, but we hope IP people to attend in order to meet, identify key issues and progress together.We also expect IETF and ICANN to give us inputs on an agenda item. I agree that "require" is not a correct and happy word to start a fruitful coordination ! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 < 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 Dec 6 10:17:47 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27538 for ; Mon, 6 Dec 1999 10:17:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA08198; Mon, 6 Dec 1999 10:16:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA08052 for ; Mon, 6 Dec 1999 10:16:24 -0500 (EST) Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27066 for ; Mon, 6 Dec 1999 10:16:52 -0500 (EST) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by breeze.research.telcordia.com (8.9.3/8.9.3) with ESMTP id KAA12054; Mon, 6 Dec 1999 10:16:18 -0500 (EST) Received: from seascape.research.telcordia.com (pptpdhcp25.research.telcordia.com [192.4.9.250]) by mailee.research.telcordia.com (8.8.8/8.8.8) with SMTP id KAA27898; Mon, 6 Dec 1999 10:16:16 -0500 (EST) Message-Id: <4.1.19991206100201.009ce100@mailee.research.telcordia.com> X-Sender: huitema@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 06 Dec 1999 10:12:45 -0500 To: Richard Shockey , "'ENUM'" From: Christian Huitema Subject: RE: [Enum] Summary and Minutes of ENUM in Washington In-Reply-To: <4.2.0.58.19991203160720.00a44ea0@127.0.0.1> References: <4.1.19991203162355.009f4f00@mailee.research.telcordia.com> <31AF4D00A662D211B6D10000F8BCBC24919B37@bcarua63.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 04:17 PM 12/3/99 -0600, Richard Shockey wrote: >I hate to ask ..but do you have any thoughts on possible DNS performance >expectations with ENUM in the picture above and beyond the 20% re >transmission rates you experienced ? Basically, good design + improved quality of the DNS service. Good design means a structure that maximises the value of caching -- i.e. rather hierarchical than flat. It also means a structure that facilitates management, i.e. a structure in which local information is kept and updated locally. There is no question however that the performance issue is important. I have no proof that my measurements are representative of the current state of the Internet, albeit a couple of private replies pointed to very similar performance data acquired at other locations. If that is the case, then we can expect today a failure rate of 3 to 6% for any "request-response" Internet-wide transaction. Note that this failure rate would not be specific to the DNS. There would be similar failures for any transaction based protocol, such as for example LDAP over UDP. And don't say that we should just use TCP -- the initial SYN exchange of TCP would experience the same loss rate as UDP, and, if the TCP connection actually carries isolated transactions, these transactions would also be repeated, at the TCP level, with performances that would not be very different from UDP. The transaction failure rate implies that we should minimize the number of transactions that are required in order to resolve a phone number, and that we should prefer local transactions with a local server over Internet-wide transactions. If we use the DNS, that means that the structure should be amenable to easy replication and efficient caching. -- Christian Huitema _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Dec 6 11:57:41 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19639 for ; Mon, 6 Dec 1999 11:57:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA14798; Mon, 6 Dec 1999 11:56:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA14635 for ; Mon, 6 Dec 1999 11:56:32 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19400 for ; Mon, 6 Dec 1999 11:56:59 -0500 (EST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprtp1.ntcom.nortel.net; Mon, 6 Dec 1999 10:52:09 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 6 Dec 1999 09:52:01 -0600 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24919B38@bcarua63.ca.nortel.com> From: "Anne Brown" To: "'ENUM'" Subject: FW: [Enum] Summary and Minutes of ENUM in Washington Date: Mon, 6 Dec 1999 09:51:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF4001.D4DDE9A2" 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_01BF4001.D4DDE9A2 Content-Type: text/plain; charset="ISO-8859-1" Alfred, Given the fact that DNS queries for E.164 numbers will have e164.int or something similar as a top level domain name, thus leaving no ambiguity as to whether the number is an E.164 number, I am not sure what problem the AESA field solves. Regards, Anne -----Original Message----- From: Albert Manfredi [mailto:albert.e.manfredi@boeing.com] Sent: December 03, 1999 12:01 PM To: Brown, Anne [NORSE:6L47-I:EXCH]; 'ENUM' Subject: RE: [Enum] Summary and Minutes of ENUM in Washington Anne, I'm not sure your response addresses Christian's concern. Maybe it does, but I took it differently. To me, the question is "how does a host send a DNS request, with an E.164 telephone number in it, in such a way that the DNS knows that the number is in fact E.164?" To understand the question, it was one reaction to my suggestion of making the E.164 number a field that is _peer_ to the IP address. Not part of an IP name, as has been proposed here. Since I believe that the 20-byte AESA field already exists in the DNS database format, I also believe that the answer to Christian's concern should be quite elegant. When you request a resolution of an E.164 number, the field used in the request is the AESA field. The number is encoded as an encapsulated E.164 address, the AFI byte up front is set to 0x45, and there is no ambiguity. And this is expandable in the future. In other words, this is a different scheme from the one discussed in DC. Telephone numbers get their own field, using the field allocated now to AESAs. Bert albert.e.manfredi@boeing.com -----Original Message----- From: enum-admin@ietf.org [mailto:enum-admin@ietf.org] On Behalf Of Anne Brown Sent: Friday, December 03, 1999 10:31 AM To: 'ENUM' Subject: FW: [Enum] Summary and Minutes of ENUM in Washington Alfred, In response to Christian's question "How do you know you have an E.164 number?", a person today is expected to know the difference between a local and an E.164 number in order to make a phone call. In the future we, or an application on our behalf, will be able to lookup a telephone number, given some input information. I would hope that an E.164 number is returned, if the request was to a global service (i.e., not a request to a local service or directory). I would also hope that the user would never see the number, but only verify the intended recipient before commencing with the session. Regards, Anne -----Original Message----- From: Albert Manfredi [mailto:albert.e.manfredi@boeing.com] Sent: December 02, 1999 5:10 PM To: Scott Petrack; enum Subject: RE: [Enum] Summary and Minutes of ENUM in Washington > There followed some "animated discussion" on the subject > of how one > can tell if a given number is part of the E164 domain or > if it belongs > to some other domain: > > Dave Oran asked how the client could know if a > given number belongs > to e164.int or something else. > > Scott Petrack said that this is within the scope of ENUM. > > Scott Bradner said that we don't want to spend time > on what goes > on the "right hand side of the @ sign". One point that wasn't mentioned in the minutes. This discussion took place at the close of the session. As I understand it, the DNS today has a peer field to the IP address which is an ATM End System Address (AESA). Is this so? If this is so, then why not use that field for E.164, which is after all already an accepted format, encapsulated by the 20-byte AESA frame? Now you don't have to worry about the incredibly long series of numbers and dots to the left of an @ symbol. You simply have a third field to search on. So a name can be mapped to an IP address and an AESA (which incorporates E.164). Christian Huitema brought up the question, "How do you know you have an E.164 number?" My first answer _was_ that it is preceded by a + symbol. But in fact, a much better answer is that the 20-byte AESA field has an AFI (Authority and Format Identifier) byte as its first byte, and that is used to identify E.164. There are also two other possible formulations of the 20-byte AESA already standardized, which could be used here as well. And potentially many more, including possible multicast or even portable telephone numbers. (Okay, this is outside the enum scope.) What's wrong with this approach, given that DNS already is set up for the AESA? 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 ------_=_NextPart_001_01BF4001.D4DDE9A2 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable FW: [Enum] Summary and Minutes of ENUM in Washington

Alfred,

Given the fact that DNS queries for = E.164 numbers will have e164.int or something similar as a top level = domain name, thus leaving no ambiguity as to whether the number is an = E.164 number,  I am not sure what problem the AESA field solves. =

Regards,
Anne

-----Original = Message-----
From:   Albert = Manfredi [mailto:albert.e.manfredi@boeing.com]<= B>
Sent:   December 03, 1999 12:01 PM
To:     Brown, Anne [NORSE:6L47-I:EXCH]; 'ENUM'
Subject:       = RE: [Enum] Summary and Minutes of = ENUM in Washington

Anne,

I'm not sure your = response addresses Christian's concern. Maybe = it does, but I took it differently.
To me, the question is "how does = a host send a DNS request, with an E.164 telephone = number in it, in such a way that the DNS knows that the = number is in fact E.164?" To understand the = question, it was one reaction to my suggestion of making the E.164 = number a field that is = _peer_ to the IP = address. Not part of an IP name, as has been proposed = here.

Since I believe that the 20-byte AESA = field already exists in the = DNS database format, I also believe that = the answer to Christian's concern = should be quite elegant. When you request a resolution of = an E.164 number, the field used in the request is the AESA = field. The number is encoded as an encapsulated E.164 address, the = AFI byte up front is set to 0x45, and there is no ambiguity. And = this is expandable in the future.

In other words, this is a different = scheme from the one discussed in DC. Telephone = numbers get their own field, using the field allocated now to = AESAs.

Bert
albert.e.manfredi@boeing.com

-----Original Message-----
From:   enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of
        Anne Brown
Sent:   Friday, December 03, 1999 10:31 AM
To:     = 'ENUM'
Subject:       = FW: [Enum] Summary and Minutes of ENUM = in Washington


Alfred,
In response to Christian's = question "How do you know you have an E.164 = number?",  a person today is expected to know the = difference between a local and an E.164 number in order to make a = phone call.  In the future we, or an application on our = behalf, will be able to = lookup a telephone number, given some = input information.  I would hope that an E.164 = number is returned, if the request was to a global service = (i.e., not a request to a local service or directory).  = I would also hope that the user would never see the number, = but only verify the intended recipient before commencing with the = session.

Regards,
Anne
-----Original Message-----
From:   Albert Manfredi [mailto:albert.e.manfredi@boeing.com]<= B>
Sent:   December 02, 1999 5:10 PM
To:     = Scott Petrack; enum
Subject:       = RE: [Enum] Summary and Minutes of ENUM = in Washington

    > There followed some = "animated = discussion"  on the subject
    > of how one
    > can tell if a given number is = part of the E164 domain or
    > if it belongs
    > to some other domain:
    >
    >       Dave Oran asked how the = client could know if a
    > given number belongs
    > to e164.int or something = else.
    >
    >       Scott Petrack said that this = is within the scope of ENUM.
    >
    >       Scott Bradner said that we = don't want to spend time
    > on what goes
    > on the "right hand side of the @ = sign".

One point that wasn't = mentioned in the minutes. This discussion took place at the close = of the session.
As I understand it, the DNS today has = a peer field to the IP address which is an ATM = End System Address (AESA). Is this so?  If this is = so, then why not use that field for E.164, which is after all = already an accepted format, encapsulated by the 20-byte = AESA frame?

Now you don't have to worry = about the incredibly long series of numbers and dots = to the left of an @ symbol. You simply have a third field to = search on. So a name can be mapped to an IP address and an AESA = (which incorporates E.164).

Christian Huitema brought up the = question, "How do you know you have an E.164 = number?" My first answer _was_ that it is = preceded by a + symbol. But in fact, a much better answer is = that the 20-byte AESA field has an AFI (Authority and Format = Identifier) byte as its first byte, and that is = used to identify E.164. There are also two other possible = formulations of the 20-byte AESA already standardized, which = could be used here as well. And potentially many more, including = possible multicast or even portable telephone numbers.  (Okay, this is outside the enum scope.)

What's wrong with this = approach, given that DNS already is set up for the = AESA?
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

------_=_NextPart_001_01BF4001.D4DDE9A2-- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Dec 6 14:04:53 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05760 for ; Mon, 6 Dec 1999 14:04:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA20597; Mon, 6 Dec 1999 14:02:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA20555 for ; Mon, 6 Dec 1999 14:02:08 -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 OAA04799 for ; Mon, 6 Dec 1999 14:02:36 -0500 (EST) Received: from slb-hub-01.boeing.com ([129.172.13.51]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA24203 for ; Mon, 6 Dec 1999 11:02:23 -0800 (PST) Received: from [199.191.48.146] by slb-hub-01.boeing.com for enum@ietf.org; Mon, 6 Dec 1999 11:02:11 -0800 Received: by engr03.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Mon, 6 Dec 1999 14:01:12 -0500 Reply-To: From: "Albert Manfredi" To: "Anne Brown" , "'ENUM'" Subject: RE: [Enum] Summary and Minutes of ENUM in Washington Date: Mon, 6 Dec 1999 14:02:04 -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) In-reply-to: <31AF4D00A662D211B6D10000F8BCBC24919B38@bcarua63.ca.nortel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 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 Well, you have a point, Anne. Why even bring this up [the idea of using the AESA field in the DNS to carry E.164 numbers, instead of the "name" field with number before the @ symbol]? Perhaps I have three answers to this question: 1. It formalizes the E.164 number (and any other numbering scheme such as DCC or ICD, or potential future numbering schemes) in a structure that already exists, ensuring that duplication of telephone numbers under numerous _name_ field listings will not occur in DNS. 2. This might be controversial, but such a scheme would combine the functions of the DNS and the ANS into possibly the same set of servers. Or viewed another way, it incorporates other addressing schemes within the Internet, with (I believe?) minimal bother. It allows one to dial a number, as easily as one now types in the IP address or name. All you have to know is the number. After all, it should be as globally unique as an IP address, right? 3. It just seems like a logical alternative to be considered. Query based on one of those fields, response provides all other identifiers for the target host. I guess I was surprised when it hadn't been (as far as I could tell) examined as a possibility. I would agree that none of these is compelling to the point that "no other way would work." However, it just seems that some of the kludge factor is eliminated? Bert albert.e.manfredi@boeing.com -----Original Message----- From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of Anne Brown Sent: Monday, December 06, 1999 10:52 AM To: 'ENUM' Subject: FW: [Enum] Summary and Minutes of ENUM in Washington Alfred, Given the fact that DNS queries for E.164 numbers will have e164.int or something similar as a top level domain name, thus leaving no ambiguity as to whether the number is an E.164 number, I am not sure what problem the AESA field solves. Regards, Anne -----Original Message----- From: Albert Manfredi [mailto:albert.e.manfredi@boeing.com] Sent: December 03, 1999 12:01 PM To: Brown, Anne [NORSE:6L47-I:EXCH]; 'ENUM' Subject: RE: [Enum] Summary and Minutes of ENUM in Washington Anne, I'm not sure your response addresses Christian's concern. Maybe it does, but I took it differently. To me, the question is "how does a host send a DNS request, with an E.164 telephone number in it, in such a way that the DNS knows that the number is in fact E.164?" To understand the question, it was one reaction to my suggestion of making the E.164 number a field that is _peer_ to the IP address. Not part of an IP name, as has been proposed here. Since I believe that the 20-byte AESA field already exists in the DNS database format, I also believe that the answer to Christian's concern should be quite elegant. When you request a resolution of an E.164 number, the field used in the request is the AESA field. The number is encoded as an encapsulated E.164 address, the AFI byte up front is set to 0x45, and there is no ambiguity. And this is expandable in the future. In other words, this is a different scheme from the one discussed in DC. Telephone numbers get their own field, using the field allocated now to AESAs. 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 Dec 7 03:40:02 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27764 for ; Tue, 7 Dec 1999 03:40:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA08382; Tue, 7 Dec 1999 03:39:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA08337 for ; Tue, 7 Dec 1999 03:39:15 -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 DAA27645 for ; Tue, 7 Dec 1999 03:39:45 -0500 (EST) Received: by mail1.itu.ch with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Dec 1999 09:39:39 +0100 Message-ID: <48129F10B08ED3119DB00000F831E85F1A6ADB@mailsrv1.itu.ch> From: "Shaw, Robert" To: "'enum@ietf.org'" Cc: "'sob@harvard.edu'" , "Tar, John" Date: Tue, 7 Dec 1999 09:39:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] First Call Announcement on Geneva Workshop Jan 25-27, 2000 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 Here is the first call announcement on the Workshop "IP and Telecoms Interworking Workshop: Focus on Numbering, Naming, Addressing and Routing Issues" planned for Jan 25-27, 2000 at ITU in Geneva. Scott, I'll assume that you'll forward this onto the relevant IESG/IAB folks or WGs. Note that we would like for an IETF relevant expert to co-chair the meeting which I would assume should be coordinated through you as our official liaison. Bob -- Robert Shaw ITU Internet Strategy and Policy Advisor International Telecommunication Union Place des Nations, 1211 Geneva, Switzerland -------------------------------------------------------------- Dear All, 1. Background At its recent meeting, 25-29 October 1999, the International Telecommunication Union's (ITU) Telecommunication Standardization Advisory Group (TSAG) endorsed a proposal presented by ITU-T Working Party 1/2 (Numbering, Routing, Global Mobility) from its Stockholm meeting (22-29 September 1999) that the ITU host a Workshop titled: "IP and Telecoms Interworking Workshop: Focus on Numbering, Naming, Addressing and Routing Issues". The goal of the workshop is for all involved technical fora to identify interworking issues, from their unique perspective, solely with regard to Numbering, Naming, Addressing, and Routing, so that a joint work plan can be developed for timely and complete issue resolution. This Workshop is scheduled to take place at ITU Headquarters in Geneva, 25-27 January 2000. 2. Mr. Roy Blane, the Vice-Chairman of ITU-T Study Group 2 and Chairman of Working Party 1/2, has recently undergone surgery, so is unable to continue with the preparations for this Workshop, for which he was one of the instigators and the driving force. However, it is hoped that Mr. Blane will recover in time to take an active part in the Workshop itself. The Workshop will be managed by two co-moderators: Mr. Fred Gaechter, Rapporteur of ITU-T Q1/2 (Numbering, Naming and Addressing) and [IETF, Title]. (To be decided)? As a result of the positive support of a number of Study Group 2 members, both in person (thanks Andy and Mark) and via email, and thanks to the collaboration of Mr. Robert Shaw of the ITU Strategic Planning Unit, we have developed a preliminary draft work plan, which we submit for your comments, as follows: Day 1, 25 January - Welcome, Keynote addresses (IETF and ITU-T) - Terms of reference: focus on Numbering, Naming, Addressing and Routing (NNAR) - Relevant NNAR elements of ITU-T - Relevant NNAR elements of IETF - Relevant NNAR elements of other related organizations (Please help identify any such additional and appropriate organizations). Day 2, 26 January - IETF technical issues (within scope of NNAR) - ITU-T technical issues (within scope of NNAR) - Other organizations' technical issues (within scope of NNAR) - Drafting Groups issues' identification, definition, and timeline - Joint issue prioritization Day 3, 27 January - Proposals for allocating the work - Schedules, work plans and progress tracking - Next steps to ensure appropriate conclusions - Review of Workshop output 3.1 Mr. Andy Gallant, in collaboration with Mr. Gaechter, are in the process of preparing a more detailed agenda based on the above work plan structure and taking into account the comments received from Study Group 2 members. However, this agenda cannot be fleshed out until we receive some feedback from both the IETF and ITU-T communities, (specifically, from experts in numbering, naming, addressing and routing) as to their availability as presenters and their intention to participate in the Workshop. 3.2 We envisage two keynote addresses, one each from the IETF and ITU-T sides. 3.3 We also envisage a handful of presenters from the IETF, ITU-T, and other pertinent organizations, focusing on the technical issues of NNAR, as well as active participation from 30-40 technical experts, and a number of observers. 3.4 Accordingly, we kindly invite you to respond by Friday, 17 December 1999 if you are willing to be a presenter, an active participant or observer at this Workshop. We also solicit comments on the Seminar's scope, goal and draft agenda. Responses should be sent to John Tar at: john.tar@itu.int Please feel free to forward this message to anyone you think would be interested and willing to contribute material to, or take active part in the Workshop. Based on your responses, a detailed agenda will then be issued, which will accompany the Final Call Notice to be dispatched before the end of December. Upon request, a preliminary draft agenda can be sent to you in advance. Thank you, in anticipation of your cooperation. Zoltan J. Tar Head, Deptartment TSB/SAO and Counsellor, ITU-T Study Group 2 _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Dec 8 03:05:32 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01513 for ; Wed, 8 Dec 1999 03:05:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA01774; Wed, 8 Dec 1999 03:04:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA01692 for ; Wed, 8 Dec 1999 03:04:46 -0500 (EST) Received: from fogerty.ericsson.fi (mail.ericsson.fi [194.89.206.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01359 for ; Wed, 8 Dec 1999 03:05:15 -0500 (EST) From: Kimmo.Rantanen@lmf.ericsson.se Received: from greymse1.lmf.ericsson.se ([131.160.1.6]) by fogerty.ericsson.fi (8.9.3+Sun/8.9.3) with ESMTP id KAA04810; Wed, 8 Dec 1999 10:05:20 +0200 (EET) Received: from localhost (root@localhost) by greymse1.lmf.ericsson.se (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA25723; Wed, 8 Dec 1999 10:04:41 +0200 (EET) X-OpenMail-Hops: 1 Date: Wed, 8 Dec 1999 10:04:32 +0200 Message-Id: In-Reply-To: <4.1.19991203162355.009f4f00@mailee.research.telcordia.com> Subject: RE: [Enum] Summary and Minutes of ENUM in Washington MIME-Version: 1.0 TO: huitema@research.telcordia.com CC: albert.e.manfredi@boeing.com, arbrown@nortelnetworks.com, enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; name="RE:" Content-Disposition: inline; filename="RE:" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Hello Christian. Maybe I didn't understood everything what you are discussing, but anyway why we don't use the same numbering system as in GSM network has been widely used, so: If the first mark, what you got from subscriber is + then follows E.164 number, otherwise it is national form. Both of format always are available, then not necessary to know how E.164 number will be cat for national use. Originally this "plus" was indication about international access code and it still on, but nowadays it could be used for this purpose too. Question is how generate "plus" with old-fashioned telephone, but perhaps instead of it could be used # as you maybe mentioned ? Kimmo Rantanen Ericsson Finland +358 9 2992957 > At 12:01 PM 12/3/99 -0500, Albert Manfredi wrote: > > >Since I believe that the 20-byte AESA field already exists in the > >DNS database format, I also believe that the answer to Christian's > >concern should be quite elegant. When you request a resolution of an > >E.164 number, the field used in the request is the AESA field. The > >number is encoded as an encapsulated E.164 address, the AFI byte up > >front is set to 0x45, and there is no ambiguity. And this is > >expandable in the future. > > Alfred, > > I am afraid that you are mixing several elements of the DNS systems. I was not > really aware of the 20 byte AESA field, and I don't know whether there is more > than minimal experimental use of it. In any case, AESA provides an encoding > for records, not for names, much like the A record encodes the IP addresses. > The names themselves are encoded as sequences of tokens, usually represented in > txt forms such as "a.b.c.com". > > My remark was that most users don't know that they are using E.164. They never > heard of that standard. They are most likely to use the locally defined dialing > plan to which they are used. If I designed a mapping system, I would make damn > sure that it could be parameterized with a local dial plan. For example, if I > have to map "#699 4267" (a valid number in our own plan), I woul probably map > it to something like "7.6.2.4.9.9.6.#.local-dial-plan.telcordia.com" and I > would then use "Non-Terminal DNS Name Redirection" (RFC 2672) to redirect > branches of that subtree towards other subtrees, some of which could be > definitions of "plain e.164." > > In fact, an "e.164" tree does not need to contain much more than a list of > country codes pointing to various national subtrees. This allows for easy > management, delegation, etc. And it does not mandate that we have a single > root! > -- Christian Huitema > > _______________________________________________ > 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 Dec 8 03:39:06 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17855 for ; Wed, 8 Dec 1999 03:39:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA13347; Wed, 8 Dec 1999 03:38:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA13290 for ; Wed, 8 Dec 1999 03:38:22 -0500 (EST) Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17764 for ; Wed, 8 Dec 1999 03:38:53 -0500 (EST) Received: by dnspri.npac.com; id AA178802332; Wed, 8 Dec 1999 02:38:52 -0600 Received: from chi02.npac.com(208.143.39.132) by dnspri.npac.com via smap (3.2) id xma017870; Wed, 8 Dec 99 02:38:24 -0600 Received: by chi02.npac.com with Internet Mail Service (5.5.2232.9) id ; Wed, 8 Dec 1999 02:34:22 -0600 Message-Id: From: James Yu To: Anne Brown Cc: "'enum@ietf.org'" Date: Wed, 8 Dec 1999 02:32:08 -0600 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) 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 DAA13293 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 Content-Transfer-Encoding: 8bit NeuStar suggests to revise sectoins 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 support 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. The system SHOULD be designed to meet the requirements set by the regulatory bodies.   3.9 Query Performance The system is not expected to respond to queries with the same performance levels as current PSTN queries; however, the DNS process SHOULD not significantly increase the post dialing delay as percieved by the caller or specified by the regulatory bodies.   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? _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Dec 8 11:00:07 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02711 for ; Wed, 8 Dec 1999 11:00:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA20721; Wed, 8 Dec 1999 10:59:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA20658 for ; Wed, 8 Dec 1999 10:59:23 -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 KAA02547 for ; Wed, 8 Dec 1999 10:59:52 -0500 (EST) Received: from slb-hub-01.boeing.com ([129.172.13.51]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA24342 for ; Wed, 8 Dec 1999 07:59:51 -0800 (PST) Received: from [199.191.48.146] by slb-hub-01.boeing.com for enum@ietf.org; Wed, 8 Dec 1999 07:59:48 -0800 Received: by engr03.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Wed, 8 Dec 1999 10:58:49 -0500 Reply-To: From: "Albert Manfredi" To: Cc: Subject: RE: [Enum] Summary and Minutes of ENUM in Washington Date: Wed, 8 Dec 1999 10:59:42 -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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 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 won't answer for Christian, but I'll offer an answer. I think that there are too many different national numbering plans to be able to say that anything without a "+" prefix is just a national plan. Now you're still left with the problem of identifying which national plan. So the + solution is only a partial solution anyway. Also, the scheme which puts the telephone number in front of a domain name makes the + prefix unnecessary, and greatly increases overall flexibility. However, it also could potentially make the DNS database considerably bigger. Which is in part why I thought something a little more "integrated" would be nice. Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: Kimmo.Rantanen@lmf.ericsson.se > > Hello Christian. > > Maybe I didn't understood everything what you are > discussing, but anyway > why we don't use the same numbering system as in GSM > network has been > widely used, so: > > If the first mark, what you got from subscriber is + then > follows E.164 > number, otherwise it is national form. Both of format always are > available, then not necessary to know how E.164 number > will be cat for > national use. > > Originally this "plus" was indication about international > access code > and it still on, but nowadays it could be used for this > purpose too. > > Question is how generate "plus" with old-fashioned telephone, but > perhaps instead of it could be used # as you maybe mentioned ? > > Kimmo Rantanen > Ericsson Finland > +358 9 2992957 > > > At 12:01 PM 12/3/99 -0500, Albert Manfredi wrote: > > > > >Since I believe that the 20-byte AESA field already > exists in the > > >DNS database format, I also believe that the answer to > Christian's > > >concern should be quite elegant. When you request a > resolution of an > > >E.164 number, the field used in the request is the > AESA field. The > > >number is encoded as an encapsulated E.164 address, > the AFI byte up > > >front is set to 0x45, and there is no ambiguity. And this is > > >expandable in the future. > > > > Alfred, > > > > I am afraid that you are mixing several elements of the > DNS systems. I > was not > > really aware of the 20 byte AESA field, and I don't > know whether there > is more > > than minimal experimental use of it. In any case, AESA > provides an > encoding > > for records, not for names, much like the A record > encodes the IP > addresses. > > The names themselves are encoded as sequences of tokens, usually > represented in > > txt forms such as "a.b.c.com". > > > > My remark was that most users don't know that they are > using E.164. > They never > > heard of that standard. They are most likely to use the locally > defined dialing > > plan to which they are used. If I designed a mapping > system, I would > make damn > > sure that it could be parameterized with a local dial plan. For > example, if I > > have to map "#699 4267" (a valid number in our own plan), I woul > probably map > > it to something like > "7.6.2.4.9.9.6.#.local-dial-plan.telcordia.com" > and I > > would then use "Non-Terminal DNS Name Redirection" (RFC 2672) to > redirect > > branches of that subtree towards other subtrees, some > of which could > be > > definitions of "plain e.164." > > > > In fact, an "e.164" tree does not need to contain much > more than a > list of > > country codes pointing to various national subtrees. > This allows for > easy > > management, delegation, etc. And it does not mandate > that we have a > single > > root! > > -- Christian Huitema > > > > _______________________________________________ > > 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 Dec 8 11:16:50 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11678 for ; Wed, 8 Dec 1999 11:16:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA11507; Wed, 8 Dec 1999 11:16:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA11428 for ; Wed, 8 Dec 1999 11:16:09 -0500 (EST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11562 for ; Wed, 8 Dec 1999 11:16:38 -0500 (EST) Received: from slb-hub-01.boeing.com ([129.172.13.51]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id IAA04284 for ; Wed, 8 Dec 1999 08:16:38 -0800 (PST) Received: from [199.191.48.146] by slb-hub-01.boeing.com for enum@ietf.org; Wed, 8 Dec 1999 08:16:25 -0800 Received: by engr03.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Wed, 8 Dec 1999 11:15:24 -0500 Reply-To: From: "Albert Manfredi" To: "James Yu" Cc: Subject: RE: [Enum] ENUM Requirements Date: Wed, 8 Dec 1999 11:16:17 -0500 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Related to number portability, without answering the specific question, I would say that portable numbers _do_ make sense in the name field of the DNS. Because a portable number is nothing but an arbitrary ID, identical in concept to an Internet name. The portable number is mapped to a "real" number, hierarchical and used for routing, just like an IP name is mapped to an IP address. So in my view, one possible way to support portable "telephone numbers" is to map that arbitrary number to a "real" telephone number (possibly in the AESA field), an IP address, or both. To support mobile users, the DNS is not fast enough to track the MS. In that case, the portable number could point to the "real" telephone number of the _home server_, which in turn is keeping track of the MS (via updates from the foreign agents). Or, of course, one could imagine a real-time DNS, where the databases are kept synchronized via satellite, but that's a whole other program. albert.e.manfredi@boeing.com James Yu wrote: > NeuStar suggests to revise sectoins 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 support 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. The system SHOULD be designed to > meet the requirements > set by the regulatory bodies. > > > > 3.9 Query Performance > > The system is not expected to respond to queries with the > same performance > levels as current PSTN queries; however, the DNS process > SHOULD not > significantly increase the post dialing delay as > percieved by the caller or > specified by the regulatory bodies. > > > > 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? > > > _______________________________________________ > 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 Dec 8 17:34:25 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01239 for ; Wed, 8 Dec 1999 17:34:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA27117; Wed, 8 Dec 1999 17:33:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA27059 for ; Wed, 8 Dec 1999 17:33:41 -0500 (EST) Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01093 for ; Wed, 8 Dec 1999 17:34:06 -0500 (EST) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by breeze.research.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA01643; Wed, 8 Dec 1999 17:33:00 -0500 (EST) Received: from seascape.research.telcordia.com (pptpdhcp25.research.telcordia.com [192.4.9.250]) by mailee.research.telcordia.com (8.8.8/8.8.8) with SMTP id RAA12972; Wed, 8 Dec 1999 17:32:57 -0500 (EST) Message-Id: <4.1.19991208172745.009cb180@mailee.research.telcordia.com> X-Sender: huitema@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 08 Dec 1999 17:29:12 -0500 To: Kimmo.Rantanen@lmf.ericsson.se From: Christian Huitema Subject: RE: [Enum] Summary and Minutes of ENUM in Washington Cc: albert.e.manfredi@boeing.com, arbrown@nortelnetworks.com, enum@ietf.org In-Reply-To: References: <4.1.19991203162355.009f4f00@mailee.research.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 10:04 AM 12/8/99 +0200, Kimmo.Rantanen@lmf.ericsson.se wrote: >If the first mark, what you got from subscriber is + then follows E.164 >number, otherwise it is national form. Both of format always are >available, then not necessary to know how E.164 number will be cat for >national use. There are all kinds of possible conventions, "+" being just one of them. I would rather use conventions where they belong, i.e. in the design of the user interface. -- Christian Huitema _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Dec 9 03:38:08 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14379 for ; Thu, 9 Dec 1999 03:38:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA19468; Thu, 9 Dec 1999 03:35:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA19407 for ; Thu, 9 Dec 1999 03:35:28 -0500 (EST) Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13282 for ; Thu, 9 Dec 1999 03:35:56 -0500 (EST) Received: by dnspri.npac.com; id AA016278557; Thu, 9 Dec 1999 02:35:57 -0600 Received: from chi02.npac.com(208.143.39.132) by dnspri.npac.com via smap (3.2) id xma001623; Thu, 9 Dec 99 02:35:31 -0600 Received: by chi02.npac.com with Internet Mail Service (5.5.2232.9) id ; Thu, 9 Dec 1999 02:31:25 -0600 Message-Id: From: James Yu To: albert.e.manfredi@boeing.com Cc: enum@ietf.org Subject: RE: [Enum] ENUM Requirements Date: Thu, 9 Dec 1999 02:29:11 -0600 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) 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, I don't have any preferenece on how to get things done so long as the scheme meets the requirements. The "subscriber number (if connected with SCN)" is used to find out the "routing number" which can be a routing prefix or the Location Routing Number (in the U.S. and Canada). That information then is used to determine the proper GW(s) to go to based on routing information from TRIP. It is possible to combine the above into one step where the information returned can be the GW(s)' IP address(es). However, the routing prefix or LRN information and/or the associated indicator (either the Nature of Address (NOA) or the Forward Call Indicators) must be available to the terminating GW so as to avoid another NPDB dip. James -----Original Message----- From: Albert Manfredi [mailto:albert.e.manfredi@boeing.com] Sent: Wednesday, December 08, 1999 11:16 AM To: James Yu Cc: enum@ietf.org Subject: RE: [Enum] ENUM Requirements Related to number portability, without answering the specific question, I would say that portable numbers _do_ make sense in the name field of the DNS. Because a portable number is nothing but an arbitrary ID, identical in concept to an Internet name. The portable number is mapped to a "real" number, hierarchical and used for routing, just like an IP name is mapped to an IP address. So in my view, one possible way to support portable "telephone numbers" is to map that arbitrary number to a "real" telephone number (possibly in the AESA field), an IP address, or both. To support mobile users, the DNS is not fast enough to track the MS. In that case, the portable number could point to the "real" telephone number of the _home server_, which in turn is keeping track of the MS (via updates from the foreign agents). Or, of course, one could imagine a real-time DNS, where the databases are kept synchronized via satellite, but that's a whole other program. albert.e.manfredi@boeing.com James Yu wrote: > NeuStar suggests to revise sectoins 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 support 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. The system SHOULD be designed to > meet the requirements > set by the regulatory bodies. > > > > 3.9 Query Performance > > The system is not expected to respond to queries with the > same performance > levels as current PSTN queries; however, the DNS process > SHOULD not > significantly increase the post dialing delay as > percieved by the caller or > specified by the regulatory bodies. > > > > 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? > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Dec 9 17:28:50 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21558 for ; Thu, 9 Dec 1999 17:28:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA21245; Thu, 9 Dec 1999 17:27:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA21078 for ; Thu, 9 Dec 1999 17:27:23 -0500 (EST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21015 for ; Thu, 9 Dec 1999 17:27:47 -0500 (EST) Received: from blv-hub-01.boeing.com ([192.48.21.11]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA07689 for ; Thu, 9 Dec 1999 14:27:48 -0800 (PST) Received: from [199.191.48.134] by blv-hub-01.boeing.com for enum@ietf.org; Thu, 9 Dec 1999 14:27:43 -0800 Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Thu, 9 Dec 1999 17:26:39 -0500 Reply-To: From: "Albert Manfredi" To: "James Yu" Cc: Subject: RE: [Enum] ENUM Requirements Date: Thu, 9 Dec 1999 17:27:27 -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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 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 [james.yu@neustar.com] wrote: > Bert, > > I don't have any preferenece on how to get things done so > long as the scheme > meets the requirements. The "subscriber number (if > connected with SCN)" is > used to find out the "routing number" which can be a > routing prefix or the > Location Routing Number (in the U.S. and Canada). This is in response to my suggestion for portable numbers (included below). Yes. That would be the effect. The portable number, when dialed from an Internet appliance, might be dialed in as 123456...@stablenumbers.org where the calling Internet appliance can be designed to add the @ symbol and the rest by default. (Out of scope of enum: From a dumb telephone device, dialing these portable numbers would be a matter of using a prefix first. Different numbering plans would employ different prefixes, as usually happens. The PSTN would keep its own number translation databases, or it could use the DNS.) Back at the Internet appliance, if this query goes to the DNS, and if the DNS is set up with the E.164 encapsulated within its AESA field as a _peer_ to the IP address field, then the DNS would reply to the Internet appliance with whatever field(s) it has filled in. It could be _just_ the AESA (a relatively dumb device perhaps), or it could also be an IP address for e-mail or other possibilities. Those more knowledgable about the DNS will have more creative thoughts on this. But more than that. The "portable (stable) telephone number" can just as easily be translated to a "portable telephone name." Why not? If you're using an appliance with a keyboard, there's nothing to prevent that IP address/AESA combination from being listed with several different IP names, right? One "name" could be that 123456....@stablenumbers.org described above. But another name could be JamesYuWashDcUSA@stablenumbers.org. This would typically be a shorter string of characters than the numbers format. So when you're dialing from a dumb telephone with just a keypad, you have no choice. The numbers are used. Otherwise, you can use the name. The essential thing is to make the number to the left of the @ symbol globally unique. This permits the PSTN to use the same permanent number. And again, I think mobility can be assumed to work by means of home servers which keep track of mobile stations' locations. Basically what happens now with mobile stations. Doesn't that meet the enum draft requirments? Bert albert.e.manfredi@boeing.com That > information then is > used to determine the proper GW(s) to go to based on > routing information > from TRIP. It is possible to combine the above into one > step where the > information returned can be the GW(s)' IP address(es). > However, the routing > prefix or LRN information and/or the associated indicator > (either the Nature > of Address (NOA) or the Forward Call Indicators) must be > available to the > terminating GW so as to avoid another NPDB dip. > > James > -----Original Message----- > From: Albert Manfredi [mailto:albert.e.manfredi@boeing.com] > Sent: Wednesday, December 08, 1999 11:16 AM > To: James Yu > Cc: enum@ietf.org > Subject: RE: [Enum] ENUM Requirements > > > Related to number portability, without answering the specific > question, I would say that portable numbers _do_ make sense in the > name field of the DNS. Because a portable number is nothing but an > arbitrary ID, identical in concept to an Internet name. > > The portable number is mapped to a "real" number, hierarchical and > used for routing, just like an IP name is mapped to an IP address. > > So in my view, one possible way to support portable "telephone > numbers" is to map that arbitrary number to a "real" telephone > number (possibly in the AESA field), an IP address, or both. > > To support mobile users, the DNS is not fast enough to > track the MS. > In that case, the portable number could point to the "real" > telephone number of the _home server_, which in turn is keeping > track of the MS (via updates from the foreign agents). > > Or, of course, one could imagine a real-time DNS, where the > databases are kept synchronized via satellite, but that's a whole > other program. > > albert.e.manfredi@boeing.com > > > James Yu wrote: > > > NeuStar suggests to revise sectoins 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 support 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. The system SHOULD be designed to > > meet the requirements > > set by the regulatory bodies. > > > > > > > > 3.9 Query Performance > > > > The system is not expected to respond to queries with the > > same performance > > levels as current PSTN queries; however, the DNS process > > SHOULD not > > significantly increase the post dialing delay as > > percieved by the caller or > > specified by the regulatory bodies. > > > > > > > > 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? > > > > > > _______________________________________________ > > 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 Dec 10 12:28:58 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28271 for ; Fri, 10 Dec 1999 12:28:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA11961; Fri, 10 Dec 1999 12:26:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA11910 for ; Fri, 10 Dec 1999 12:26:50 -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 MAA28265 for ; Fri, 10 Dec 1999 12:27:19 -0500 (EST) Received: from blv-av-01.boeing.com ([192.54.3.60]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA03787 for ; Fri, 10 Dec 1999 09:27:18 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.2/8.9.2-MAV1) with ESMTP id JAA26131 for ; Fri, 10 Dec 1999 09:27:14 -0800 (PST) Received: from [199.191.48.134] by blv-hub-01.boeing.com for enum@ietf.org; Fri, 10 Dec 1999 09:27:03 -0800 Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Fri, 10 Dec 1999 12:26:10 -0500 Reply-To: From: "Albert Manfredi" To: Date: Fri, 10 Dec 1999 12:26:59 -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) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Enum] Other implications of enum Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit By the way, I wanted to add that if this issue of incorporating E.164 numbers within the DNS is accomplished right, it could have implications on other aspects of IP -- such as IP over ATM. Let's just consider for a moment that my suggestion is used, i.e. that the E.164 number is provided within the AESA field of the DNS (the structure of DNS therefore being IP name/IPaddress/AESA). _If_ this is the case, then potentially that solution would also help in finding a shortcut through an ATM infrastructure to that host. This is a subject of interest to the ION WG. An IP host might be ATM-connected, with a telephone number, an ATM address, _and_ an IP address. If a DNS query returns the IP address as well as any other AESA that might apply, RFC 2332 (Next Hop Resolution Protocol) could be improved. To establish a shortcut, the source could first try a direct ATM VC to the destination's ATM address, before going through the IP routing routine described in RFC 2332. No guarantee that this first attempt will work, though, because the likelihood is that the ATM network of the destination is not contiguous with the ATM network of the source. But between routers sharing the same ATM infrastructure, this would be pretty slick. And if telcos deploy ATM more universally, the payoff would be good. 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 Dec 13 01:21:41 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18159 for ; Mon, 13 Dec 1999 01:21:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA29134; Mon, 13 Dec 1999 01:20:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA29075 for ; Mon, 13 Dec 1999 01:20:56 -0500 (EST) Received: from fogerty.ericsson.fi (mail.ericsson.fi [194.89.206.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18141 for ; Mon, 13 Dec 1999 01:21:26 -0500 (EST) From: Kimmo.Rantanen@lmf.ericsson.se Received: from greymse1.lmf.ericsson.se ([131.160.1.6]) by fogerty.ericsson.fi (8.9.3+Sun/8.9.3) with ESMTP id IAA16995; Mon, 13 Dec 1999 08:21:32 +0200 (EET) Received: from localhost (root@localhost) by greymse1.lmf.ericsson.se (8.8.6 (PHNE_17135)/8.8.6) with SMTP id IAA29628; Mon, 13 Dec 1999 08:20:53 +0200 (EET) X-OpenMail-Hops: 1 Date: Mon, 13 Dec 1999 08:20:45 +0200 Message-Id: In-Reply-To: Subject: RE: [Enum] Summary and Minutes of ENUM in Washington MIME-Version: 1.0 TO: albert.e.manfredi@boeing.com CC: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; name="RE:" Content-Disposition: inline; filename="RE:" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Hello. Yes, I see your point, but I am just thinking how GSM works over the world. International number is very good e.g. in case when someone doesn't know national/local numbering plans then one can use international plan. It makes easier to do some kind of mobility e.g. "fixed roaming" etc. Anyway, I thing that everybody needs own international number or otherwise interworking with PSTN is difficult to organize without new "NAS" solution. Am I right ? /Kimmo > I won't answer for Christian, but I'll offer an answer. I think that > there are too many different national numbering plans to be able to > say that anything without a "+" prefix is just a national plan. Now > you're still left with the problem of identifying which national > plan. So the + solution is only a partial solution anyway. > > Also, the scheme which puts the telephone number in front of a > domain name makes the + prefix unnecessary, and greatly increases > overall flexibility. However, it also could potentially make the DNS > database considerably bigger. Which is in part why I thought > something a little more "integrated" would be nice. > > Bert > albert.e.manfredi@boeing.com > > > > -----Original Message----- > > From: Kimmo.Rantanen@lmf.ericsson.se > > > > Hello Christian. > > > > Maybe I didn't understood everything what you are > > discussing, but anyway > > why we don't use the same numbering system as in GSM > > network has been > > widely used, so: > > > > If the first mark, what you got from subscriber is + then > > follows E.164 > > number, otherwise it is national form. Both of format always are > > available, then not necessary to know how E.164 number > > will be cat for > > national use. > > > > Originally this "plus" was indication about international > > access code > > and it still on, but nowadays it could be used for this > > purpose too. > > > > Question is how generate "plus" with old-fashioned telephone, but > > perhaps instead of it could be used # as you maybe mentioned ? > > > > Kimmo Rantanen > > Ericsson Finland > > +358 9 2992957 > > > > > At 12:01 PM 12/3/99 -0500, Albert Manfredi wrote: > > > > > > >Since I believe that the 20-byte AESA field already > > exists in the > > > >DNS database format, I also believe that the answer to > > Christian's > > > >concern should be quite elegant. When you request a > > resolution of an > > > >E.164 number, the field used in the request is the > > AESA field. The > > > >number is encoded as an encapsulated E.164 address, > > the AFI byte up > > > >front is set to 0x45, and there is no ambiguity. And this is > > > >expandable in the future. > > > > > > Alfred, > > > > > > I am afraid that you are mixing several elements of the > > DNS systems. I > > was not > > > really aware of the 20 byte AESA field, and I don't > > know whether there > > is more > > > than minimal experimental use of it. In any case, AESA > > provides an > > encoding > > > for records, not for names, much like the A record > > encodes the IP > > addresses. > > > The names themselves are encoded as sequences of tokens, usually > > represented in > > > txt forms such as "a.b.c.com". > > > > > > My remark was that most users don't know that they are > > using E.164. > > They never > > > heard of that standard. They are most likely to use the locally > > defined dialing > > > plan to which they are used. If I designed a mapping > > system, I would > > make damn > > > sure that it could be parameterized with a local dial plan. For > > example, if I > > > have to map "#699 4267" (a valid number in our own plan), I woul > > probably map > > > it to something like > > "7.6.2.4.9.9.6.#.local-dial-plan.telcordia.com" > > and I > > > would then use "Non-Terminal DNS Name Redirection" (RFC 2672) to > > redirect > > > branches of that subtree towards other subtrees, some > > of which could > > be > > > definitions of "plain e.164." > > > > > > In fact, an "e.164" tree does not need to contain much > > more than a > > list of > > > country codes pointing to various national subtrees. > > This allows for > > easy > > > management, delegation, etc. And it does not mandate > > that we have a > > single > > > root! > > > -- Christian Huitema > > > > > > _______________________________________________ > > > 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 Dec 13 10:21:21 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08979 for ; Mon, 13 Dec 1999 10:21:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA00612; Mon, 13 Dec 1999 10:20:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA00551 for ; Mon, 13 Dec 1999 10:20:02 -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 KAA08957 for ; Mon, 13 Dec 1999 10:20:31 -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 HAA20289 for ; Mon, 13 Dec 1999 07:20:31 -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-MAV1) with ESMTP id HAA22579 for ; Mon, 13 Dec 1999 07:20:30 -0800 (PST) Received: from [199.191.48.134] by slb-hub-01.boeing.com for enum@ietf.org; Mon, 13 Dec 1999 07:20:16 -0800 Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Mon, 13 Dec 1999 10:19:22 -0500 Reply-To: From: "Albert Manfredi" To: Cc: Subject: RE: [Enum] Summary and Minutes of ENUM in Washington Date: Mon, 13 Dec 1999 10:20:10 -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) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 In-Reply-To: Importance: 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 guess this is a topic for the enum WG. Specifically: 1. Should enum support direct entry of telephone numbers in national numbering plan format within its database (e.g. within DNS), in addition to the E.164 format, or 2. Should enum limit itself to listing numbers in E.164 format within the DNS, and let hosts do whatever manipulation necessary to accept local plan dialing from a user? In my opinion, both 1 and 2 can be supported without too much trouble, if we are willing to accommodate a potentially long list of alternative formats for each E.164 number within the DNS (or whatever database is ultimately selected for this). And it seems that #1 is what the group is assuming will be the case. Also, this decision can be made irrespective of whether the AESA field of DNS is used, as I proposed. I think the decision is orthogonal to this other topic. Bert albert.e.manfredi@boeing.com Kimmo Rantanen wrote: > Hello. > > Yes, I see your point, but I am just thinking how GSM > works over the > world. > International number is very good e.g. in case when > someone doesn't know > national/local numbering plans then one can use > international plan. > > It makes easier to do some kind of mobility e.g. "fixed > roaming" etc. > > Anyway, I thing that everybody needs own international number or > otherwise interworking with PSTN is difficult to organize > without new > "NAS" solution. Am I right ? > > /Kimmo > > > > I won't answer for Christian, but I'll offer an answer. > I think that > > there are too many different national numbering plans > to be able to > > say that anything without a "+" prefix is just a > national plan. Now > > you're still left with the problem of identifying which national > > plan. So the + solution is only a partial solution anyway. > > > > Also, the scheme which puts the telephone number in front of a > > domain name makes the + prefix unnecessary, and greatly > increases > > overall flexibility. However, it also could potentially > make the DNS > > database considerably bigger. Which is in part why I thought > > something a little more "integrated" would be nice. > > > > Bert > > albert.e.manfredi@boeing.com > > > > > > > -----Original Message----- > > > From: Kimmo.Rantanen@lmf.ericsson.se > > > > > > Hello Christian. > > > > > > Maybe I didn't understood everything what you are > > > discussing, but anyway > > > why we don't use the same numbering system as in GSM > > > network has been > > > widely used, so: > > > > > > If the first mark, what you got from subscriber is + then > > > follows E.164 > > > number, otherwise it is national form. Both of format > always are > > > available, then not necessary to know how E.164 number > > > will be cat for > > > national use. > > > > > > Originally this "plus" was indication about international > > > access code > > > and it still on, but nowadays it could be used for this > > > purpose too. > > > > > > Question is how generate "plus" with old-fashioned > telephone, but > > > perhaps instead of it could be used # as you maybe mentioned ? > > > > > > Kimmo Rantanen > > > Ericsson Finland > > > +358 9 2992957 > > > > > > > At 12:01 PM 12/3/99 -0500, Albert Manfredi wrote: > > > > > > > > >Since I believe that the 20-byte AESA field already > > > exists in the > > > > >DNS database format, I also believe that the answer to > > > Christian's > > > > >concern should be quite elegant. When you request a > > > resolution of an > > > > >E.164 number, the field used in the request is the > > > AESA field. The > > > > >number is encoded as an encapsulated E.164 address, > > > the AFI byte up > > > > >front is set to 0x45, and there is no ambiguity. > And this is > > > > >expandable in the future. > > > > > > > > Alfred, > > > > > > > > I am afraid that you are mixing several elements of the > > > DNS systems. I > > > was not > > > > really aware of the 20 byte AESA field, and I don't > > > know whether there > > > is more > > > > than minimal experimental use of it. In any case, AESA > > > provides an > > > encoding > > > > for records, not for names, much like the A record > > > encodes the IP > > > addresses. > > > > The names themselves are encoded as sequences of > tokens, usually > > > represented in > > > > txt forms such as "a.b.c.com". > > > > > > > > My remark was that most users don't know that they are > > > using E.164. > > > They never > > > > heard of that standard. They are most likely to use > the locally > > > defined dialing > > > > plan to which they are used. If I designed a mapping > > > system, I would > > > make damn > > > > sure that it could be parameterized with a local > dial plan. For > > > example, if I > > > > have to map "#699 4267" (a valid number in our own > plan), I woul > > > probably map > > > > it to something like > > > "7.6.2.4.9.9.6.#.local-dial-plan.telcordia.com" > > > and I > > > > would then use "Non-Terminal DNS Name Redirection" > (RFC 2672) to > > > redirect > > > > branches of that subtree towards other subtrees, some > > > of which could > > > be > > > > definitions of "plain e.164." > > > > > > > > In fact, an "e.164" tree does not need to contain much > > > more than a > > > list of > > > > country codes pointing to various national subtrees. > > > This allows for > > > easy > > > > management, delegation, etc. And it does not mandate > > > that we have a > > > single > > > > root! > > > > -- Christian Huitema > > > > > > > > _______________________________________________ > > > > 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 Dec 13 11:29:23 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10777 for ; Mon, 13 Dec 1999 11:29:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA25169; Mon, 13 Dec 1999 11:27:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA24889 for ; Mon, 13 Dec 1999 11:26:53 -0500 (EST) Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10681 for ; Mon, 13 Dec 1999 11:27:20 -0500 (EST) Received: by dnspri.npac.com; id AA111072432; Mon, 13 Dec 1999 10:27:12 -0600 Received: from chi02.npac.com(208.143.39.132) by dnspri.npac.com via smap (3.2) id xma011088; Mon, 13 Dec 99 10:26:51 -0600 Received: by chi02.npac.com with Internet Mail Service (5.5.2232.9) id ; Mon, 13 Dec 1999 10:22:47 -0600 Message-Id: From: James Yu To: "'sip@lists.research.bell-labs.com'" Cc: "'enum@ietf.org'" Date: Mon, 13 Dec 1999 10:20:23 -0600 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] Nation-Specific ISUP implementations, Overlap Signaling & Number Portability Database Queries 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 following discussions focus on SCN-IP-SCN calls. There are nation-specific variatoins in ISUP implementations. I don't know whether this issue has been discussed (I'm new to IETF). When we have only a few GWs, it is fine that those GWs support many ISUP implementations. But when many GWs are deployed, it is not likely that every GW will support many ISUP implementations. Some may be used only for domestic use. So it is likely that an international call may need to be routed to an "international" GW (or more than one) that interworks between two nation-specific ISUP implementations. To fully use the IP network, then the "international" GW will further route the call to a "domestic" GW (destination GW) that terminates the call into the SCN. The call can certainly be routed to the destination SCN but the call charge may be higher. This would seem to be inefficient that the user traffic must be routed through additional GW(s). ISUP interworking probably can be done via a pure signaling conversion/mapping so that the user traffic can be routed directly to the destination GW. If we need to perform number portability queries, then a good place would be the destination "international" GW because it is close to the destination country and supports the destination country's Number Portability Database (NPDB) interface. In that case, simple ISUP interworking mentioned above won't be sufficient. A NPDB query also needs to be launched. The response to the NPDB query will decide the destination GW that should terminate the call. Due to number portability, the called party's serving SCN switch changes when the called user switches to a new service provider. Whenever that happens, the NPDB will reflect the current new serving switch or network information (via Location Routing Number in the North America or Routing Prefix in the Europe), and the "destination" GW that can reach the serving switch or network may change. So a NPDB query is required to determine the correct GW to terminate the call. At ENUM, we have been discussing where to perform the NPDB queries. The originating GW needs to support all nation-specific NPDB interfaces if it is to query those NPDBs. This would be expensive. Also there is an issue about the encapsulated ISUP message in the SIP if originating GW's nationa-specific ISUP message is encapsulated (may be everyone should use ITU-T ISUP that is used between international switches for communicating among the entities in the IP domain). The destination GW can support specific NPDB interface; however, it may be the wrong GW because it cannot reach the serving switch in the SCN that serves the called party. Overlap signaling would make the issue more complicate. If the call routing decision is to route to the "international" GW, it is fine because number portability is confined within a national domain. That "international" GW will then wait for additional address information and performs the NPDB query, if required. But if the call is to be routed directly to the destination GW, and if the originating GW is the one to perform the NPDB, then it has to collect all the address information before it can launch the query. But the issue is that the originating GW may not know it has collected all the address digits. It seems that the best entity that knows that it has collected all the digits and can perform the NPDB query would be the destination "international" GW. I have linked several issues (nation-specific ISUP implementations, number portability, and user traffic routing efficiency) together that need to be addressed as a whole. There may be other issues. It is hoped that one or more solutions can be identified and finalized. _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Dec 13 12:10:09 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11979 for ; Mon, 13 Dec 1999 12:10:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA17289; Mon, 13 Dec 1999 12:09:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA17224 for ; Mon, 13 Dec 1999 12:09:00 -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 MAA11960 for ; Mon, 13 Dec 1999 12:09:30 -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 JAA25936 for ; Mon, 13 Dec 1999 09:09:31 -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-MAV1) with ESMTP id JAA29407 for ; Mon, 13 Dec 1999 09:09:31 -0800 (PST) Received: from [199.191.48.134] by slb-hub-01.boeing.com for enum@ietf.org; Mon, 13 Dec 1999 09:08:51 -0800 Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Mon, 13 Dec 1999 12:07:55 -0500 Reply-To: From: "Albert Manfredi" To: "James Yu" , Cc: Subject: RE: [Enum] Nation-Specific ISUP implementations, Overlap Signaling & NumberPortability Database Queries Date: Mon, 13 Dec 1999 12:08:42 -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) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 In-Reply-To: Importance: 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 don't think I understand all the issues you're raising. But, on the number portability database (NPDB) question, why not just map each portable number only to an E.164 number in the NPDB? The DNS could do that job quite well, I think. For simple telephony devices, when a user dials a portable number, the central office starts by querying the DNS or other similar database. The reply is E.164, and the central office knows whether this number is local, long distance, or international with respect to itself. It knows this because it is programmed to know its own country code and area code. So it knows how to translate that E.164 number into something it can dial. And it dials accordingly, changing nothing from current practice. Smart terminals can query the NPDB (DNS) directly and translate the E.164 number returned into something in the local dialing plan. Or use the IP address, if available. The simplest way to accommodate mobile terminals is to have them operate through a home server, as if they are always at that home location. This seems wasteful when one is roaming. Alternatively, the mobile station, when accessing the the NPDB via its roaming access base station, can have that base station translate the E.164 number returned by the NPDB into the local dialing plan. But I don't think that most of these issues are enum wg issues. I could be wrong. Also, I don't understand all the acronyms you use, but maybe that's just me. Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On > Behalf Of James > Yu > Sent: Monday, December 13, 1999 11:20 AM > To: 'sip@lists.research.bell-labs.com' > Cc: 'enum@ietf.org' > Subject: [Enum] Nation-Specific ISUP implementations, > Overlap Signaling > & NumberPortability Database Queries > > > The following discussions focus on SCN-IP-SCN calls. > > There are nation-specific variatoins in ISUP > implementations. I don't know > whether this issue has been discussed (I'm new to IETF). > When we have only > a few GWs, it is fine that those GWs support many ISUP > implementations. But > when many GWs are deployed, it is not likely that every > GW will support many > ISUP implementations. Some may be used only for domestic > use. So it is > likely that an international call may need to be routed to an > "international" GW (or more than one) that interworks between two > nation-specific ISUP implementations. To fully use the > IP network, then the > "international" GW will further route the call to a "domestic" GW > (destination GW) that terminates the call into the SCN. > The call can > certainly be routed to the destination SCN but the call > charge may be > higher. > > This would seem to be inefficient that the user traffic > must be routed > through additional GW(s). ISUP interworking probably can > be done via a pure > signaling conversion/mapping so that the user traffic can > be routed directly > to the destination GW. > > If we need to perform number portability queries, then a > good place would be > the destination "international" GW because it is close to > the destination > country and supports the destination country's Number > Portability Database > (NPDB) interface. In that case, simple ISUP interworking > mentioned above > won't be sufficient. A NPDB query also needs to be > launched. The response > to the NPDB query will decide the destination GW that > should terminate the > call. > > Due to number portability, the called party's serving SCN > switch changes > when the called user switches to a new service provider. > Whenever that > happens, the NPDB will reflect the current new serving > switch or network > information (via Location Routing Number in the North > America or Routing > Prefix in the Europe), and the "destination" GW that can > reach the serving > switch or network may change. So a NPDB query is > required to determine the > correct GW to terminate the call. > > At ENUM, we have been discussing where to perform the > NPDB queries. The > originating GW needs to support all nation-specific NPDB > interfaces if it is > to query those NPDBs. This would be expensive. Also > there is an issue > about the encapsulated ISUP message in the SIP if originating GW's > nationa-specific ISUP message is encapsulated (may be > everyone should use > ITU-T ISUP that is used between international switches > for communicating > among the entities in the IP domain). The destination GW > can support > specific NPDB interface; however, it may be the wrong GW > because it cannot > reach the serving switch in the SCN that serves the called party. > > Overlap signaling would make the issue more complicate. > If the call routing > decision is to route to the "international" GW, it is > fine because number > portability is confined within a national domain. That > "international" GW > will then wait for additional address information and > performs the NPDB > query, if required. But if the call is to be routed > directly to the > destination GW, and if the originating GW is the one to > perform the NPDB, > then it has to collect all the address information before > it can launch the > query. But the issue is that the originating GW may not > know it has > collected all the address digits. > > It seems that the best entity that knows that it has > collected all the > digits and can perform the NPDB query would be the destination > "international" GW. > > I have linked several issues (nation-specific ISUP > implementations, number > portability, and user traffic routing efficiency) > together that need to be > addressed as a whole. There may be other issues. It is > hoped that one or > more solutions can be identified and finalized. > > _______________________________________________ > 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 Dec 13 15:07:01 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18042 for ; Mon, 13 Dec 1999 15:07:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA23990; Mon, 13 Dec 1999 15:05:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA23937 for ; Mon, 13 Dec 1999 15:05:52 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18036 for ; Mon, 13 Dec 1999 15:06:23 -0500 (EST) Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by smtprtp1.ntcom.nortel.net; Mon, 13 Dec 1999 15:04:31 -0500 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Y5QASCWT; Mon, 13 Dec 1999 12:03:32 -0800 Received: from nortelnetworks.com (msquire-1.corpeast.baynetworks.com [132.245.252.65]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id WMJAHQ9J; Mon, 13 Dec 1999 15:03:24 -0500 Message-ID: <38555078.7FE67754@nortelnetworks.com> Date: Mon, 13 Dec 1999 15:00:56 -0500 From: "Matt Squire" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: James Yu CC: "'sip@lists.research.bell-labs.com'" , "'enum@ietf.org'" Subject: Re: [Enum] Nation-Specific ISUP implementations, Overlap Signaling & Number Portability Database Queries 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 You certainly seem to pack alot of things into this note. An attempt to summarize: (a) ISUP interworking between gateways (b) Call routing decisions based on ISUP capabilities (c) Timing/location of portability query (d) Complexity of originating switch performing NPDB queries due to national variants (e) Overlap signalling and its complexities to call signalling, particularly international Here's a 2-bit opinion on some of these things... (a) ISUP interworking was discusesed for a bit in IPTEL, and it looked like the consensus was that gateways must be ready to fall back to some common denominator ISUP capability set if they don't support any common ISUP variation. (b) Right now, the call routing portion of the solution (TRIP) is not considering ISUP variations when making call routing decisions. It was discussed, but the consensus appeared to be that falling to a common international capability set was an acceptable solution. So it looks like ISUP variations won't impact the route the call takes to a destination gateway. (c) By just reading the notes, it looks like there might be consensus to perform the portability query before initiating the call and accessing things like call routing. (d) I would hope that enum does not require the querier to know all of the possible national variants to NPDB queries. Enum should define a common query mechanism that is independent of national variants. The system should be a superset of the national variants and be able to coordinate the information across nation's boundries. Without this, the whole thing seems like very unhelpful. Enum queries really have to be international. (e) About a month ago there was alot of discussion on overlap signalling in SIP. If you haven't read the discussion, you might want to review it. There were several proposals on how to handle it. I don't recall how well the interaction between overlap signalling and LNP was discussed, but I recall it being mentioned a few times. I'm sure others can provide further elaboration of those discussions. James Yu wrote: > > The following discussions focus on SCN-IP-SCN calls. > > There are nation-specific variatoins in ISUP implementations. I don't know > whether this issue has been discussed (I'm new to IETF). When we have only > a few GWs, it is fine that those GWs support many ISUP implementations. But > when many GWs are deployed, it is not likely that every GW will support many > ISUP implementations. Some may be used only for domestic use. So it is > likely that an international call may need to be routed to an > "international" GW (or more than one) that interworks between two > nation-specific ISUP implementations. To fully use the IP network, then the > "international" GW will further route the call to a "domestic" GW > (destination GW) that terminates the call into the SCN. The call can > certainly be routed to the destination SCN but the call charge may be > higher. > > This would seem to be inefficient that the user traffic must be routed > through additional GW(s). ISUP interworking probably can be done via a pure > signaling conversion/mapping so that the user traffic can be routed directly > to the destination GW. > > If we need to perform number portability queries, then a good place would be > the destination "international" GW because it is close to the destination > country and supports the destination country's Number Portability Database > (NPDB) interface. In that case, simple ISUP interworking mentioned above > won't be sufficient. A NPDB query also needs to be launched. The response > to the NPDB query will decide the destination GW that should terminate the > call. > > Due to number portability, the called party's serving SCN switch changes > when the called user switches to a new service provider. Whenever that > happens, the NPDB will reflect the current new serving switch or network > information (via Location Routing Number in the North America or Routing > Prefix in the Europe), and the "destination" GW that can reach the serving > switch or network may change. So a NPDB query is required to determine the > correct GW to terminate the call. > > At ENUM, we have been discussing where to perform the NPDB queries. The > originating GW needs to support all nation-specific NPDB interfaces if it is > to query those NPDBs. This would be expensive. Also there is an issue > about the encapsulated ISUP message in the SIP if originating GW's > nationa-specific ISUP message is encapsulated (may be everyone should use > ITU-T ISUP that is used between international switches for communicating > among the entities in the IP domain). The destination GW can support > specific NPDB interface; however, it may be the wrong GW because it cannot > reach the serving switch in the SCN that serves the called party. > > Overlap signaling would make the issue more complicate. If the call routing > decision is to route to the "international" GW, it is fine because number > portability is confined within a national domain. That "international" GW > will then wait for additional address information and performs the NPDB > query, if required. But if the call is to be routed directly to the > destination GW, and if the originating GW is the one to perform the NPDB, > then it has to collect all the address information before it can launch the > query. But the issue is that the originating GW may not know it has > collected all the address digits. > > It seems that the best entity that knows that it has collected all the > digits and can perform the NPDB query would be the destination > "international" GW. > > I have linked several issues (nation-specific ISUP implementations, number > portability, and user traffic routing efficiency) together that need to be > addressed as a whole. There may be other issues. It is hoped that one or > more solutions can be identified and finalized. > > _______________________________________________ > 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 Dec 13 15:24:22 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18362 for ; Mon, 13 Dec 1999 15:24:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA15490; Mon, 13 Dec 1999 15:23:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA15333 for ; Mon, 13 Dec 1999 15:23:19 -0500 (EST) Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18347 for ; Mon, 13 Dec 1999 15:23:49 -0500 (EST) Received: by dnspri.npac.com; id AA204736616; Mon, 13 Dec 1999 14:23:36 -0600 Received: from chi02.npac.com(208.143.39.132) by dnspri.npac.com via smap (3.2) id xma020464; Mon, 13 Dec 99 14:23:33 -0600 Received: by chi02.npac.com with Internet Mail Service (5.5.2232.9) id ; Mon, 13 Dec 1999 14:19:29 -0600 Message-Id: From: James Yu To: "'Matt Squire'" Cc: "'sip@lists.research.bell-labs.com'" , "'enum@ietf.org'" , "'iptel@lists.research.bell-labs.com'" Subject: RE: [Enum] Nation-Specific ISUP implementations, Overlap Signalin g & Number Portability Database Queries Date: Mon, 13 Dec 1999 14:17:05 -0600 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) 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 Matt, It is a good summary of the key points. You mentioned iptel that I forgot to cc to. So I'm adding it to the cc list. My point is that the WGs should address their respective agendas while keeping those issues in mind so that the solution(s) developed by each individual WG can all work together. James -----Original Message----- From: Matt Squire [mailto:msquire@nortelnetworks.com] Sent: Monday, December 13, 1999 3:01 PM To: James Yu Cc: 'sip@lists.research.bell-labs.com'; 'enum@ietf.org' Subject: Re: [Enum] Nation-Specific ISUP implementations, Overlap Signaling & Number Portability Database Queries You certainly seem to pack alot of things into this note. An attempt to summarize: (a) ISUP interworking between gateways (b) Call routing decisions based on ISUP capabilities (c) Timing/location of portability query (d) Complexity of originating switch performing NPDB queries due to national variants (e) Overlap signalling and its complexities to call signalling, particularly international Here's a 2-bit opinion on some of these things... (a) ISUP interworking was discusesed for a bit in IPTEL, and it looked like the consensus was that gateways must be ready to fall back to some common denominator ISUP capability set if they don't support any common ISUP variation. (b) Right now, the call routing portion of the solution (TRIP) is not considering ISUP variations when making call routing decisions. It was discussed, but the consensus appeared to be that falling to a common international capability set was an acceptable solution. So it looks like ISUP variations won't impact the route the call takes to a destination gateway. (c) By just reading the notes, it looks like there might be consensus to perform the portability query before initiating the call and accessing things like call routing. (d) I would hope that enum does not require the querier to know all of the possible national variants to NPDB queries. Enum should define a common query mechanism that is independent of national variants. The system should be a superset of the national variants and be able to coordinate the information across nation's boundries. Without this, the whole thing seems like very unhelpful. Enum queries really have to be international. (e) About a month ago there was alot of discussion on overlap signalling in SIP. If you haven't read the discussion, you might want to review it. There were several proposals on how to handle it. I don't recall how well the interaction between overlap signalling and LNP was discussed, but I recall it being mentioned a few times. I'm sure others can provide further elaboration of those discussions. James Yu wrote: > > The following discussions focus on SCN-IP-SCN calls. > > There are nation-specific variatoins in ISUP implementations. I don't know > whether this issue has been discussed (I'm new to IETF). When we have only > a few GWs, it is fine that those GWs support many ISUP implementations. But > when many GWs are deployed, it is not likely that every GW will support many > ISUP implementations. Some may be used only for domestic use. So it is > likely that an international call may need to be routed to an > "international" GW (or more than one) that interworks between two > nation-specific ISUP implementations. To fully use the IP network, then the > "international" GW will further route the call to a "domestic" GW > (destination GW) that terminates the call into the SCN. The call can > certainly be routed to the destination SCN but the call charge may be > higher. > > This would seem to be inefficient that the user traffic must be routed > through additional GW(s). ISUP interworking probably can be done via a pure > signaling conversion/mapping so that the user traffic can be routed directly > to the destination GW. > > If we need to perform number portability queries, then a good place would be > the destination "international" GW because it is close to the destination > country and supports the destination country's Number Portability Database > (NPDB) interface. In that case, simple ISUP interworking mentioned above > won't be sufficient. A NPDB query also needs to be launched. The response > to the NPDB query will decide the destination GW that should terminate the > call. > > Due to number portability, the called party's serving SCN switch changes > when the called user switches to a new service provider. Whenever that > happens, the NPDB will reflect the current new serving switch or network > information (via Location Routing Number in the North America or Routing > Prefix in the Europe), and the "destination" GW that can reach the serving > switch or network may change. So a NPDB query is required to determine the > correct GW to terminate the call. > > At ENUM, we have been discussing where to perform the NPDB queries. The > originating GW needs to support all nation-specific NPDB interfaces if it is > to query those NPDBs. This would be expensive. Also there is an issue > about the encapsulated ISUP message in the SIP if originating GW's > nationa-specific ISUP message is encapsulated (may be everyone should use > ITU-T ISUP that is used between international switches for communicating > among the entities in the IP domain). The destination GW can support > specific NPDB interface; however, it may be the wrong GW because it cannot > reach the serving switch in the SCN that serves the called party. > > Overlap signaling would make the issue more complicate. If the call routing > decision is to route to the "international" GW, it is fine because number > portability is confined within a national domain. That "international" GW > will then wait for additional address information and performs the NPDB > query, if required. But if the call is to be routed directly to the > destination GW, and if the originating GW is the one to perform the NPDB, > then it has to collect all the address information before it can launch the > query. But the issue is that the originating GW may not know it has > collected all the address digits. > > It seems that the best entity that knows that it has collected all the > digits and can perform the NPDB query would be the destination > "international" GW. > > I have linked several issues (nation-specific ISUP implementations, number > portability, and user traffic routing efficiency) together that need to be > addressed as a whole. There may be other issues. It is hoped that one or > more solutions can be identified and finalized. > > _______________________________________________ > 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 Dec 13 15:29:15 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18487 for ; Mon, 13 Dec 1999 15:29:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA21895; Mon, 13 Dec 1999 15:28:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA21819 for ; Mon, 13 Dec 1999 15:28:34 -0500 (EST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18468 for ; Mon, 13 Dec 1999 15:29:04 -0500 (EST) Received: from laptop (stl-mo14-35.ix.netcom.com [207.222.133.35]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id PAA19987 for ; Mon, 13 Dec 1999 15:28:54 -0500 (EST) Message-Id: <4.2.0.58.19991213142544.00aa8d50@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, 13 Dec 1999 14:26:53 -0600 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: I-D ACTION:draft-shockey-e164toifax-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org The following is a draft that describes the "simple" mode of ENUM where the resolution is to a service or set of services associated with a fax number. >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-shockey-e164toifax-00.txt >Date: Mon, 13 Dec 1999 07:02:38 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : The use of DNS based e164 Resolution Services by > Internet Fax > Author(s) : R. Shockey > Filename : draft-shockey-e164toifax-00.txt > Pages : 6 > Date : 10-Dec-99 > >There has been substantial work within the IETF to define Internet Fax >services based on an SMTP based store and forward model. This >transmission model has imposed some limitations of the quality and type >of content transmitted. > >A secondary issue with email based Internet fax is the inherent >difficulty of ascertaining the capabilities of a recipient in advance of >sending. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-shockey-e164toifax-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-shockey-e164toifax-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-shockey-e164toifax-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <19991210144842.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-shockey-e164toifax-00.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Dec 15 09:54:08 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03858 for ; Wed, 15 Dec 1999 09:54:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA25313; Wed, 15 Dec 1999 09:52:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA25219 for ; Wed, 15 Dec 1999 09:52:17 -0500 (EST) Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03850 for ; Wed, 15 Dec 1999 09:52:46 -0500 (EST) Received: by dnspri.npac.com; id AA264669561; Wed, 15 Dec 1999 08:52:41 -0600 Received: from chi02.npac.com(208.143.39.132) by dnspri.npac.com via smap (3.2) id xma026445; Wed, 15 Dec 99 08:52:35 -0600 Received: by chi02.npac.com with Internet Mail Service (5.5.2232.9) id ; Wed, 15 Dec 1999 08:48:31 -0600 Message-Id: From: James Yu To: "'albert.e.manfredi@boeing.com'" Cc: enum@ietf.org, sip@lists.research.bell-labs.com Subject: RE: [Enum] Nation-Specific ISUP implementations, Overlap Signalin g & NumberPortability Database Queries Date: Wed, 15 Dec 1999 08:46:13 -0600 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) 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 inserts marked by ****. James -----Original Message----- From: Albert Manfredi [mailto:albert.e.manfredi@boeing.com] Sent: Monday, December 13, 1999 12:09 PM To: James Yu; sip@lists.research.bell-labs.com Cc: enum@ietf.org Subject: RE: [Enum] Nation-Specific ISUP implementations, Overlap Signaling & NumberPortability Database Queries I don't think I understand all the issues you're raising. But, on the number portability database (NPDB) question, why not just map each portable number only to an E.164 number in the NPDB? The DNS could do that job quite well, I think. **** It is not clear what "why not just map each portable number only to an E.164 number in the NPDB?" means. Please clarify. **** For simple telephony devices, when a user dials a portable number, the central office starts by querying the DNS or other similar database. The reply is E.164, and the central office knows whether this number is local, long distance, or international with respect to itself. It knows this because it is programmed to know its own country code and area code. So it knows how to translate that E.164 number into something it can dial. And it dials accordingly, changing nothing from current practice. **** I assume that the "E.164" in the reply means the routing prefix or the LRN (with country code). **** Smart terminals can query the NPDB (DNS) directly and translate the E.164 number returned into something in the local dialing plan. Or use the IP address, if available. **** It is not clear why "local dialing plan" is involved in this example if the smart device is already connected with the internet. If the smart terminal uses the internet to get the routing prefix or LRN but accesses the SCN for call initiation, there is no way this "smart terminal" can provide both the dialed number and the routing prefix/LRN to the SCN. **** The simplest way to accommodate mobile terminals is to have them operate through a home server, as if they are always at that home location. This seems wasteful when one is roaming. Alternatively, the mobile station, when accessing the the NPDB via its roaming access base station, can have that base station translate the E.164 number returned by the NPDB into the local dialing plan. **** It won't be a "base station" performing that function. Either a mobile (services) switching center (MSC) or some interworking function will perform that function. But it is not clear why a mobile station will need to access the NPDB directly unless it is the "smart terminal" you mentioned earlier and is using Internet to reach the called party. **** But I don't think that most of these issues are enum wg issues. I could be wrong. Also, I don't understand all the acronyms you use, but maybe that's just me. **** Please list those acronyms. I can provide the info. They might have been provided in earlier messages. **** Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On > Behalf Of James > Yu > Sent: Monday, December 13, 1999 11:20 AM > To: 'sip@lists.research.bell-labs.com' > Cc: 'enum@ietf.org' > Subject: [Enum] Nation-Specific ISUP implementations, > Overlap Signaling > & NumberPortability Database Queries > > > The following discussions focus on SCN-IP-SCN calls. > > There are nation-specific variatoins in ISUP > implementations. I don't know > whether this issue has been discussed (I'm new to IETF). > When we have only > a few GWs, it is fine that those GWs support many ISUP > implementations. But > when many GWs are deployed, it is not likely that every > GW will support many > ISUP implementations. Some may be used only for domestic > use. So it is > likely that an international call may need to be routed to an > "international" GW (or more than one) that interworks between two > nation-specific ISUP implementations. To fully use the > IP network, then the > "international" GW will further route the call to a "domestic" GW > (destination GW) that terminates the call into the SCN. > The call can > certainly be routed to the destination SCN but the call > charge may be > higher. > > This would seem to be inefficient that the user traffic > must be routed > through additional GW(s). ISUP interworking probably can > be done via a pure > signaling conversion/mapping so that the user traffic can > be routed directly > to the destination GW. > > If we need to perform number portability queries, then a > good place would be > the destination "international" GW because it is close to > the destination > country and supports the destination country's Number > Portability Database > (NPDB) interface. In that case, simple ISUP interworking > mentioned above > won't be sufficient. A NPDB query also needs to be > launched. The response > to the NPDB query will decide the destination GW that > should terminate the > call. > > Due to number portability, the called party's serving SCN > switch changes > when the called user switches to a new service provider. > Whenever that > happens, the NPDB will reflect the current new serving > switch or network > information (via Location Routing Number in the North > America or Routing > Prefix in the Europe), and the "destination" GW that can > reach the serving > switch or network may change. So a NPDB query is > required to determine the > correct GW to terminate the call. > > At ENUM, we have been discussing where to perform the > NPDB queries. The > originating GW needs to support all nation-specific NPDB > interfaces if it is > to query those NPDBs. This would be expensive. Also > there is an issue > about the encapsulated ISUP message in the SIP if originating GW's > nationa-specific ISUP message is encapsulated (may be > everyone should use > ITU-T ISUP that is used between international switches > for communicating > among the entities in the IP domain). The destination GW > can support > specific NPDB interface; however, it may be the wrong GW > because it cannot > reach the serving switch in the SCN that serves the called party. > > Overlap signaling would make the issue more complicate. > If the call routing > decision is to route to the "international" GW, it is > fine because number > portability is confined within a national domain. That > "international" GW > will then wait for additional address information and > performs the NPDB > query, if required. But if the call is to be routed > directly to the > destination GW, and if the originating GW is the one to > perform the NPDB, > then it has to collect all the address information before > it can launch the > query. But the issue is that the originating GW may not > know it has > collected all the address digits. > > It seems that the best entity that knows that it has > collected all the > digits and can perform the NPDB query would be the destination > "international" GW. > > I have linked several issues (nation-specific ISUP > implementations, number > portability, and user traffic routing efficiency) > together that need to be > addressed as a whole. There may be other issues. It is > hoped that one or > more solutions can be identified and finalized. > > _______________________________________________ > 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 Dec 15 14:47:22 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11836 for ; Wed, 15 Dec 1999 14:47:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA02933; Wed, 15 Dec 1999 14:46:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA02838 for ; Wed, 15 Dec 1999 14:46:25 -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 OAA11828 for ; Wed, 15 Dec 1999 14:46:56 -0500 (EST) Received: from blv-av-01.boeing.com ([192.54.3.60]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA15033 for ; Wed, 15 Dec 1999 13:39:29 -0600 (CST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.2/8.9.2-MAV1) with ESMTP id LAA21471 for ; Wed, 15 Dec 1999 11:36:02 -0800 (PST) Received: from [199.191.48.146] by blv-hub-01.boeing.com for enum@ietf.org; Wed, 15 Dec 1999 11:35:48 -0800 Received: by engr03.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Wed, 15 Dec 1999 14:34:43 -0500 Reply-To: From: "Albert Manfredi" To: "James Yu" Cc: , Subject: RE: [Enum] Nation-Specific ISUP implementations, Overlap Signaling & NumberPortability Database Queries Date: Wed, 15 Dec 1999 14:35:36 -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) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: 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 James Yu [mailto:james.yu@neustar.com] wrote: > > Bert, > > Please see inserts marked by ****. > > James > > **** It is not clear what "why not just map each portable > number only to an > E.164 number in the NPDB?" means. Please clarify. **** I was suggesting here that the number portability database (NPDB) would be a database which maps portable number <---> E.164 "home" number, in its simplest incarnation, and that therefore putting this function within the existing DNS, as in portable no.(as Internet name) <--> IP addr <--> E.164 (in AESA) ought to work. A portable number is just a globally unique arbitrary ID, after all, much like the Internet name is. > **** I assume that the "E.164" in the reply means the > routing prefix or the > LRN (with country code). **** It means the standard E.164 format, with country code etc., but not in any one national dialing plan. In the US, for instance, you would have to add "011" in front of it to dial out. > Smart terminals can query the NPDB (DNS) directly and > translate the > E.164 number returned into something in the local dialing plan. Or > use the IP address, if available. > > **** It is not clear why "local dialing plan" is involved > in this example if > the smart device is already connected with the internet. **** Because it is possible that the destination side is not IP-connected. In the general case, the smart terminal might have to initiate a telephone call, and the local dialing plan would be needed. Or are you assuming the use of MEGACO or something like that? > **** If the smart > terminal uses the internet to get the routing prefix or > LRN but accesses the > SCN for call initiation, there is no way this "smart > terminal" can provide > both the dialed number and the routing prefix/LRN to the SCN. **** Not sure what this means. > The simplest way to accommodate mobile terminals is to have them > operate through a home server, as if they are always at that home > location. This seems wasteful when one is roaming. > > Alternatively, the mobile station, when accessing the the NPDB via > its roaming access base station, can have that base station > translate the E.164 number returned by the NPDB into the local > dialing plan. > > > **** It won't be a "base station" performing that > function. Either a mobile > (services) switching center (MSC) or some interworking > function will perform > that function. **** Good point. > **** But it is not clear why a mobile station > will need to access > the NPDB directly unless it is the "smart terminal" you > mentioned earlier > and is using Internet to reach the called party. **** Good point again, but again, the smart user might need to call a dumb telephone. Take the case where I fly from Wash DC to Paris with my roaming host, and want to dial a portable number of my French buddy, who happens to be located in Paris. I want the number returned from the NPDB to be translated into the local Paris numbering plan. (Perhaps this is not a problem if we assume MEGACO.) I would not want to make that local Paris call via Wash DC. In any event, if a roaming mobile station needs to dial a non-IP called party with portable number, that destination portable number will need to be translated into the roaming station's _current_ national numbering plan. That was the only point I was trying to make. Someone has to translate the E.164 number returned by the NPDB into something that can be dialed locally. (This is not an enum issue, though.) > **** Please list those acronyms. I can provide the info. > They might have > been provided in earlier messages. **** SCN, LRN, and GW. I think GW means gateway. The others are obviously telephone number formats. 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 Dec 15 17:46:41 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18965 for ; Wed, 15 Dec 1999 17:46:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA14298; Wed, 15 Dec 1999 17:45:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA14257 for ; Wed, 15 Dec 1999 17:45:43 -0500 (EST) Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18959 for ; Wed, 15 Dec 1999 17:46:13 -0500 (EST) Received: by dnspri.npac.com; id AA113727975; Wed, 15 Dec 1999 16:46:15 -0600 Received: from chi02.npac.com(208.143.39.132) by dnspri.npac.com via smap (3.2) id xma011364; Wed, 15 Dec 99 16:46:03 -0600 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Wed, 15 Dec 1999 16:41:58 -0600 Message-Id: From: James Yu To: "'albert.e.manfredi@boeing.com'" Cc: enum@ietf.org, sip@lists.research.bell-labs.com Subject: RE: [Enum] Nation-Specific ISUP implementations, Overlap Signalin g & Number Portability Database Queries Date: Wed, 15 Dec 1999 16:39:40 -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, I misunderstood the term "portable no." in your previous message. I thought it was an E.164 number that can be dialed. But you mentioned "as Internet name" so it is something like 4.3.2.1.3.3.5.2.0.2.1.e164.int or 12025331234@e164.int. But you mentioned after NPDB query, so the E.164 number would be a routing prefix or LRN (with country code). The routing prefix or LRN can assist in call routing to the serving network or switch, but it is the dialed number that can be used by the serving switch to terminate the call. Please inserts below for other comments/inputs. James > -----Original Message----- > From: Albert Manfredi [mailto:albert.e.manfredi@boeing.com] > Sent: Wednesday, December 15, 1999 2:36 PM > To: James Yu > Cc: enum@ietf.org; sip@lists.research.bell-labs.com > Subject: RE: [Enum] Nation-Specific ISUP implementations, Overlap > Signaling & NumberPortability Database Queries > > > James Yu [mailto:james.yu@neustar.com] wrote: > > > > > Bert, > > > > Please see inserts marked by ****. > > > > James > > > > **** It is not clear what "why not just map each portable > > number only to an > > E.164 number in the NPDB?" means. Please clarify. **** > > I was suggesting here that the number portability database (NPDB) > would be a database which maps > > portable number <---> E.164 "home" number, > > in its simplest incarnation, and that therefore putting this > function within the existing DNS, as in > > portable no.(as Internet name) <--> IP addr <--> E.164 (in AESA) > > ought to work. A portable number is just a globally unique arbitrary > ID, after all, much like the Internet name is. > > > **** I assume that the "E.164" in the reply means the > > routing prefix or the > > LRN (with country code). **** > > It means the standard E.164 format, with country code etc., but not > in any one national dialing plan. In the US, for instance, you would > have to add "011" in front of it to dial out. > > > Smart terminals can query the NPDB (DNS) directly and > > translate the > > E.164 number returned into something in the local dialing plan. Or > > use the IP address, if available. > > > > **** It is not clear why "local dialing plan" is involved > > in this example if > > the smart device is already connected with the internet. **** > > Because it is possible that the destination side is not > IP-connected. In the general case, the smart terminal might have to > initiate a telephone call, and the local dialing plan would be > needed. Or are you assuming the use of MEGACO or something like > that? If NPDB query is done, then the E.164 number would be a routing number. The smart terminal won't be able to use that number to dial out via the SCN. The SCN will treat that number as the dialed number and a NPDB query will be performed if it is a ported number. If the smart terminal is to dial out from Internet (e.g., via a SIP server), then "dialing plan" won't be involved. > > > **** If the smart > > terminal uses the internet to get the routing prefix or > > LRN but accesses the > > SCN for call initiation, there is no way this "smart > > terminal" can provide > > both the dialed number and the routing prefix/LRN to the SCN. **** > > Not sure what this means. See the comment above. > > > The simplest way to accommodate mobile terminals is to have them > > operate through a home server, as if they are always at that home > > location. This seems wasteful when one is roaming. > > > > Alternatively, the mobile station, when accessing the the NPDB via > > its roaming access base station, can have that base station > > translate the E.164 number returned by the NPDB into the local > > dialing plan. > > > > > > **** It won't be a "base station" performing that > > function. Either a mobile > > (services) switching center (MSC) or some interworking > > function will perform > > that function. **** > > Good point. > > > **** But it is not clear why a mobile station > > will need to access > > the NPDB directly unless it is the "smart terminal" you > > mentioned earlier > > and is using Internet to reach the called party. **** > > Good point again, but again, the smart user might need to call a > dumb telephone. Take the case where I fly from Wash DC to Paris with > my roaming host, and want to dial a portable number of my French > buddy, who happens to be located in Paris. I want the number > returned from the NPDB to be translated into the local Paris > numbering plan. (Perhaps this is not a problem if we assume MEGACO.) > I would not want to make that local Paris call via Wash DC. > > In any event, if a roaming mobile station needs to dial a non-IP > called party with portable number, that destination portable number > will need to be translated into the roaming station's _current_ > national numbering plan. That was the only point I was trying to > make. Someone has to translate the E.164 number returned by the NPDB > into something that can be dialed locally. (This is not an enum > issue, though.) I don't quite get your point. The "translation" you mentioned is a feature called "optimal routing" in GSM (European cellular standards). Technically, it can be done. The requirement is for the originating switch (or intermediate switch) to query the dialed mobile station's "home location register (HLR)" which gets a routing number (called Mobile Station Roaming Number in GSM or Temporary Local Directory Number in U.S. ANSI (American National Standards Institute)-41 standard) from the "visitor location register (VLR)/Mobile Switching Cetner(MSC)(MSC)" of the the cellular system that currently serves the roaming mobile station. If this originating or intermediate switch is a wireline switch, it means that it needs to check for every outgoing call to see whether it is "mobile"-terminated (not a small task in many cases) and to support Mobile Application Part (MAP) that is specific to the dialed mobile station's "home" system (e.g., GSM or ANSI-41). The MAP interface to be supported is the one between the Gateway MSC and the HLR that requests for routing information. The other problem is charging. What if you are calling a mobile station that is not in Paris but in Africa. If the call charge from Paris to Africa is much higher than the call from Paris to U.S., the caller would not be happy if he thinks it is a Paris to U.S. call (e.g., $0.20/min) but ends up paying a much higher rate ($.60/min). Those are the main reasons why the optimal routing method for mobile-terminated calls has not been supported. Also, you used "portable number" for the mobile directory number. The mobile directory numbers are E.164 numbers, and they reveal some physical location information such as a particular country, a cellular network (e.g., with nation-wide coverage), or a cellular switch/system in a specific geographic area (e.g., my mobile directory number is +1-202-256-1200 which is in D.C.). > > > **** Please list those acronyms. I can provide the info. > > They might have > > been provided in earlier messages. **** > > SCN, LRN, and GW. I think GW means gateway. The others are obviously > telephone number formats. SCN - Switched Circuit Network LRN - Location Routing Number. Every local exchange (with access line termiations to the users) in the North America that is required to support number portability is assinged a LRN (format is NPA+NXX+0000). It is used by the SCN to route a call in the number portability environment. You can access NeuStar's web site (http://www.neustar.com) for the official definition of LRN and some other number portability or North American Numbering Plan related information. GW - Gateway > Bert > albert.e.manfredi@boeing.com > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Dec 16 15:59:09 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09894 for ; Thu, 16 Dec 1999 15:59:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA04385; Thu, 16 Dec 1999 15:57:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA04160 for ; Thu, 16 Dec 1999 15:57:14 -0500 (EST) Received: from witbier.cisco.com (witbier.cisco.com [171.71.152.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09864 for ; Thu, 16 Dec 1999 15:56:34 -0500 (EST) Received: from mramalho-nt1 (ssh.cisco.com [171.69.10.34]) by witbier.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id MAA21982; Thu, 16 Dec 1999 12:54:26 -0800 (PST) Message-Id: <4.1.19991216112549.00a4cb50@localhost> X-Sender: mramalho@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 16 Dec 1999 15:54:32 -0500 To: Henning Schulzrinne , Dean Willis From: "Michael A. Ramalho" Cc: Jonathan Rosenberg , John Mainwaring , "Mark D. Foster" , "'James Yu'" , sip@lists.research.bell-labs.com, enum@ietf.org In-Reply-To: <38585DD4.EDF31D88@cs.columbia.edu> References: <001e01bf466d$373d3140$d19623a6@mcit.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Enum] Re: URL Generalization for Portability (was TRIP) 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 All, Re: Tel URL grammar stuff like ... >> INVITE premiumservice@gateway.carrier.com >> To: tel:5551212;trans=lnp?gdbs I've been waiting for some discussion about the accuracy of the time period in which the translation has been performed to come up. Virtually all of these telephony-centric LNP-type issues revolve about databases which get updated on the order of once a day. If LNP dips cost the service provider money (and external LNP queries do) .... the service provider has a strong economic incentive to cache the resolved numbers for use in subsequent calls. [There is also a performance benefit for using cached data]. Shouldn't we provide a mechanism to at least give us a hint that we are using potentially stale information (some mechanism to deal with the soft-state issues from a variety of governmental and/or service provider administered portability data bases). Perhaps a tag that says when the "originally cached dip" was performed to give a hint to a subsequent proxy how stale the information may be. Any subsequent proxy could do what it wished (i.e, do another database dip, if desired). An evil service provider could forward an Invite with quite old information instead of doing the remote dip itself .... but in the case of frequently updated databases .... subsequent proxies may have more accurate access to the current translation (perhaps in it's cache, because it is more likely to service more calls to this particular user). This will surely kick off a discussion of how DNS solves this issue vs. the GSTN ... but for the LNP issue ... we should recognize the economic incentive for cashing information from LNP databases that are updated relatively infrequently AND that requirements for these updates are likely to change in the future AND that it is highly likely that each database administrator may have different policies regarding the frequency and timing of database updates. Does anyone know if such GSTN mobility/portability databases are mandated (by ITU-T edict or defacto standard) to have a globally understood update period (e.g., something like +x hours from midnight GMT for a particular originating country code)? Darn these legacy issues ... could we get the ITU-T to mandate LNP/Mobility updates for ALL service providers to be accessed through a DNS-like mechanism? I would doubt it, as it ruins the present model of charging other service providers for such information. The present charging model will die soon anyway ... perhaps we can help accelerate the change? Lastly, does anyone know if TIPHON has useful thoughts on this issue? I apologize in advance for the subsequent discussion thread, Michael Ramalho At 10:34 PM 12/15/99 -0500, Henning Schulzrinne wrote: >Dean Willis wrote: >> > >> > Its possible that we might even see things besides phone numbers as user >> > names that are valid across multiple domains. An example is (heaven >> > forbid), social security numbers (in the US, at least): > >In a few years, Microsoft will assign every human being a GUID :-) > >> >> The underlying problem here is differentiating between a phone-number and a >> service-name-which-looks-like-a-number. Yes, the user=phone gives a hint on >> nature od address, the "+" encodding gives a hint on the scope of address, >> but it is still muddy. > >A phone number in a SIP URL is indeed of local significance, within the >scope of the proxy or gateway. Thus, > >INVITE 4012@gw.acme.com SIP/2.0 >To: tel:+12015554012 > >might be used when dialing a number that turns out to be a "tie line" or >voice VPN. > >> >> There was some discussion of this problem wrt DCS during the November >> interim meeting. It was suggested that a cross-domain destination which is a >> phone number could be better represented by a tel: URL than by confusing the >> scope of the user part of a sip: URL. This simplilifies life greatly. >> >> Something like >> >> INVITE premiumservice@gateway.carrier.com >> To: tel:5551212;trans=lnp?gdbs >> >> could be used to indicate to gateway.carrier.com that premium gateway >> service is requested towards the PSTN location identified by telephone >> number 5551212, that LNP and GDBS translation have been applied, and that >> the phone number is of local scope for the gateway. Incidentally, I think I >> just noticed a minor anomaly in the tel-url grammar -- don't see how to >> encode more than one future-extension field . . . > >Is somebody talking to the author of the tel: URL Internet Draft to make >sure this discussion doesn't get lost? > >> >> -- >> Dean > >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > Michael A. Ramalho, Ph.D. Cisco Systems 1802 Rue de la Port Wall Township, NJ 07719-3784 Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.732.449.5762 Cell: +1.732.809.0188 Pager: +1.800.365.4578 _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Dec 16 16:26:46 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10137 for ; Thu, 16 Dec 1999 16:26:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA09260; Thu, 16 Dec 1999 16:25:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA09129 for ; Thu, 16 Dec 1999 16:25:41 -0500 (EST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10112 for ; Thu, 16 Dec 1999 16:26:12 -0500 (EST) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA07981 for ; Thu, 16 Dec 1999 13:26:08 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id NAA10972 for ; Thu, 16 Dec 1999 13:25:42 -0800 (PST) Received: from [199.191.48.146] by blv-hub-01.boeing.com for enum@ietf.org; Thu, 16 Dec 1999 13:24:42 -0800 Received: by engr03.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Thu, 16 Dec 1999 16:23:28 -0500 Reply-To: From: "Albert Manfredi" To: "Michael A. Ramalho" Cc: , Subject: RE: [Enum] Re: URL Generalization for Portability (was TRIP) Date: Thu, 16 Dec 1999 16:24:21 -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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 In-Reply-To: <4.1.19991216112549.00a4cb50@localhost> 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 On update time periods, my reading is that the DNS and the NPDB (number portability database) have update periods on the order of several hours. Maybe 8 hours or more. And that mobility databases are updated in minute(s). Which is another indication that the DNS could fill the role of the NPDB, if it comes to that, or certainly that the DNS could provide that role for IP users wanting to access portable telephone numbers. I've seen studies that address the rapid synchronization of huge database systems (D. Lam, Y. Cui, D. Cox, J. Widom, "A Location Management Technique to Support Lifelong Numbering in Personal Communications Services," Proceedings of 1997 IEEE Global Telecommunications Conference, Volume 3, pp. 704-710, 1997), and I suppose ultimately the DNS could migrate to that sort of structure. But for now, the speed required for mobility updates is handled by keeping those tables in very few servers (distributed according to service provider). Bert albert.e.manfredi@boeing.com Michael A. Ramalho wrote: > I've been waiting for some discussion about the accuracy > of the time period in which the translation has been performed > to come up. > > Virtually all of these telephony-centric LNP-type issues revolve > about databases which get updated on the order of once a day. > > If LNP dips cost the service provider money (and external LNP > queries do) .... the service provider has a strong economic > incentive to cache the resolved numbers for use in subsequent > calls. [There is also a performance benefit for using > cached data]. > > Shouldn't we provide a mechanism to at least give us a hint > that we are using potentially stale information (some mechanism > to deal with the soft-state issues from a variety of governmental > and/or service provider administered portability data bases). > > Perhaps a tag that says when the "originally cached dip" was > performed to give a hint to a subsequent proxy how stale the > information may be. Any subsequent proxy could do what it > wished (i.e, do another database dip, if desired). > > An evil service provider could forward an Invite with quite old > information instead of doing the remote dip itself .... but in the > case of frequently updated databases .... subsequent proxies > may have more accurate access to the current translation > (perhaps in it's cache, because it is more likely to service > more calls to this particular user). > > This will surely kick off a discussion of how DNS solves this > issue vs. the GSTN ... but for the LNP issue ... we should > recognize the economic incentive for cashing information from > LNP databases that are updated relatively infrequently > AND that requirements for these updates are likely to change > in the future AND that it is highly likely that each database > administrator may have different policies regarding the frequency > and timing of database updates. > > Does anyone know if such GSTN mobility/portability databases > are mandated (by ITU-T edict or defacto standard) to have a > globally understood update period (e.g., something like +x hours > from midnight GMT for a particular originating country code)? > > Darn these legacy issues ... could we get the ITU-T to mandate > LNP/Mobility updates for ALL service providers to be accessed > through a DNS-like mechanism? I would doubt it, as it ruins the > present model of charging other service providers for > such information. > The present charging model will die soon anyway ... perhaps we can > help accelerate the change? > > Lastly, does anyone know if TIPHON has useful thoughts on > this issue? > > I apologize in advance for the subsequent discussion thread, > > Michael Ramalho > > > At 10:34 PM 12/15/99 -0500, Henning Schulzrinne wrote: > >Dean Willis wrote: > >> > > > >> > Its possible that we might even see things besides > phone numbers as user > >> > names that are valid across multiple domains. An > example is (heaven > >> > forbid), social security numbers (in the US, at least): > > > >In a few years, Microsoft will assign every human being > a GUID :-) > > > >> > >> The underlying problem here is differentiating between > a phone-number and a > >> service-name-which-looks-like-a-number. Yes, the > user=phone gives a hint on > >> nature od address, the "+" encodding gives a hint on > the scope of address, > >> but it is still muddy. > > > >A phone number in a SIP URL is indeed of local > significance, within the > >scope of the proxy or gateway. Thus, > > > >INVITE 4012@gw.acme.com SIP/2.0 > >To: tel:+12015554012 > > > >might be used when dialing a number that turns out to be > a "tie line" or > >voice VPN. > > > >> > >> There was some discussion of this problem wrt DCS > during the November > >> interim meeting. It was suggested that a cross-domain > destination which is a > >> phone number could be better represented by a tel: URL > than by confusing the > >> scope of the user part of a sip: URL. This > simplilifies life greatly. > >> > >> Something like > >> > >> INVITE premiumservice@gateway.carrier.com > >> To: tel:5551212;trans=lnp?gdbs > >> > >> could be used to indicate to gateway.carrier.com that > premium gateway > >> service is requested towards the PSTN location > identified by telephone > >> number 5551212, that LNP and GDBS translation have > been applied, and that > >> the phone number is of local scope for the gateway. > Incidentally, I think I > >> just noticed a minor anomaly in the tel-url grammar -- > don't see how to > >> encode more than one future-extension field . . . > > > >Is somebody talking to the author of the tel: URL > Internet Draft to make > >sure this discussion doesn't get lost? > > > >> > >> -- > >> Dean > > > >-- > >Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > > > Michael A. Ramalho, Ph.D. > Cisco Systems > 1802 Rue de la Port > Wall Township, NJ 07719-3784 > Office email: mramalho@cisco.com > Personal email: mar42@cornell.edu > Office: +1.732.449.5762 > Cell: +1.732.809.0188 > Pager: +1.800.365.4578 > > _______________________________________________ > 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 Dec 17 21:09:56 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16997 for ; Fri, 17 Dec 1999 21:09:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA22110; Fri, 17 Dec 1999 21:02:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA21608 for ; Fri, 17 Dec 1999 21:01:59 -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 VAA16936 for ; Fri, 17 Dec 1999 21:02:30 -0500 (EST) Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhubg13084; Sat, 18 Dec 1999 02:00:43 GMT Received: from dynamicsoft.com (1Cust60.tnt3.freehold.nj.da.uu.net [63.25.172.60]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id VAA18378; Fri, 17 Dec 1999 21:02:28 -0500 (EST) Message-ID: <385AEC8A.AD332C12@dynamicsoft.com> Date: Fri, 17 Dec 1999 21:08:10 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Michael A. Ramalho" CC: Henning Schulzrinne , Dean Willis , John Mainwaring , "Mark D. Foster" , "'James Yu'" , sip@lists.research.bell-labs.com, enum@ietf.org References: <001e01bf466d$373d3140$d19623a6@mcit.com> <4.1.19991216112549.00a4cb50@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] Re: URL Generalization for Portability (was TRIP) 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 "Michael A. Ramalho" wrote: > > Virtually all of these telephony-centric LNP-type issues revolve > about databases which get updated on the order of once a day. > > If LNP dips cost the service provider money (and external LNP > queries do) .... the service provider has a strong economic > incentive to cache the resolved numbers for use in subsequent > calls. [There is also a performance benefit for using cached data]. > > Shouldn't we provide a mechanism to at least give us a hint > that we are using potentially stale information (some mechanism > to deal with the soft-state issues from a variety of governmental > and/or service provider administered portability data bases). > > Perhaps a tag that says when the "originally cached dip" was > performed to give a hint to a subsequent proxy how stale the > information may be. Any subsequent proxy could do what it > wished (i.e, do another database dip, if desired). This merely seems to be passing the buck. If there are issues with data staleness, ought we not solve them at the database (i.e., DNS) level, rather than within SIP? -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 Dec 20 01:16:09 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16406 for ; Mon, 20 Dec 1999 01:16:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA27638; Mon, 20 Dec 1999 01:14:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA27349 for ; Mon, 20 Dec 1999 01:13:58 -0500 (EST) Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16275 for ; Mon, 20 Dec 1999 01:14:30 -0500 (EST) Received: by dnspri.npac.com; id AA125510469; Mon, 20 Dec 1999 00:14:29 -0600 Received: from unknown(208.143.39.196) by dnspri.npac.com via smap (3.2) id xma012546; Mon, 20 Dec 99 00:14:01 -0600 From: "Mark D. Foster" To: "'Jonathan Rosenberg'" , "'Michael A. Ramalho'" Cc: "'Henning Schulzrinne'" , "'Dean Willis'" , "'John Mainwaring'" , "'James Yu'" , , Subject: RE: [Enum] Re: URL Generalization for Portability (was TRIP) Date: Mon, 20 Dec 1999 01:11:49 -0500 Message-Id: <002001bf4ab1$7d28dcc0$c4278fd0@loudoun.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <385AEC8A.AD332C12@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > "Michael A. Ramalho" wrote: > > > > Virtually all of these telephony-centric LNP-type issues revolve > > about databases which get updated on the order of once a day. > > This may be true in some countries today, but not in those with IN-based LNP. In the US and Canada, updates to the LNP database are broadcast in real-time to service provider systems, with contractually mandated broadcast and transaction response times (e.g. 3 seconds max) for example. Part of the reason for this type of quick turnaround is that stale LNP data can cause looping of SS7 messages, and therefore de-stablize carrier's signaling backbones, to say nothing of customer's not having any inbound telephony service until database updates are propagated and calls properly routed. Neither of these factors will change with iptel. For example, the LNP database will be needed to route SS7 TCAP messages using telephone number-based GTTs, regardless of whether the lower layers are MTP or M3UA+RTSP+IP. > > If LNP dips cost the service provider money (and external LNP > > queries do) .... the service provider has a strong economic > > incentive to cache the resolved numbers for use in subsequent > > calls. [There is also a performance benefit for using cached data]. > > Caching is not an effective answer, because unlike domain name lookups, the lookup frequency of geographic numbers by value is uniformly flat and uncorrelated, and the TTLs must be set to relatively short intervals to keep looping probabilities managably low. Consequently, telcos today either host a copy of the entire database associated with their service area (by subscribing to the NPAC database update feeds), or buy query transactions from someone else who does. > > Shouldn't we provide a mechanism to at least give us a hint > > that we are using potentially stale information (some mechanism > > to deal with the soft-state issues from a variety of governmental > > and/or service provider administered portability data bases). > > > > Perhaps a tag that says when the "originally cached dip" was > > performed to give a hint to a subsequent proxy how stale the > > information may be. Any subsequent proxy could do what it > > wished (i.e, do another database dip, if desired). > > This merely seems to be passing the buck. If there are issues > with data > staleness, > ought we not solve them at the database (i.e., DNS) level, rather than > within SIP? > I agree with Jonathan here. Fortunately, there is no staleness problem with the databases today, nor do we have to introduce one where it doesn't exist. Avoiding stale data is also consistent with the FCC requirement of not relying on the donor network for call-related (in this case, database query) processing. Service providers must be free to choose who will host the database their resolvers will consult. 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 _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Dec 20 14:06:48 1999 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12186 for ; Mon, 20 Dec 1999 14:06:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA14362; Mon, 20 Dec 1999 14:05:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA14298 for ; Mon, 20 Dec 1999 14:05:44 -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 OAA12168 for ; Mon, 20 Dec 1999 14:06:17 -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 NAA11767 for ; Mon, 20 Dec 1999 13:06:17 -0600 (CST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id NAA09047 for ; Mon, 20 Dec 1999 13:06:22 -0600 (CST) Received: from [199.191.48.146] by stl-hub-01.boeing.com for enum@ietf.org; Mon, 20 Dec 1999 13:06:07 -0600 Received: by engr03.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha); Mon, 20 Dec 1999 14:04:48 -0500 Reply-To: From: "Albert Manfredi" To: "Mark D. Foster" Cc: , Subject: RE: [Enum] Re: URL Generalization for Portability (was TRIP) Date: Mon, 20 Dec 1999 14:05:40 -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 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3155.0 In-Reply-To: <002001bf4ab1$7d28dcc0$c4278fd0@loudoun.com> Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Mark D. Foster wrote: > > "Michael A. Ramalho" wrote: > > > > > > Virtually all of these telephony-centric LNP-type > issues revolve > > > about databases which get updated on the order of once a day. > > This may be true in some countries today, but not in > those with IN-based > LNP. In the US and Canada, updates to the LNP database > are broadcast in > real-time to service provider systems, with contractually > mandated broadcast > and transaction response times (e.g. 3 seconds max) for > example. Part of > the reason for this type of quick turnaround is that > stale LNP data can > cause looping of SS7 messages, and therefore de-stablize > carrier's signaling > backbones, to say nothing of customer's not having any > inbound telephony > service until database updates are propagated and calls > properly routed. > Neither of these factors will change with iptel. For > example, the LNP > database will be needed to route SS7 TCAP messages using telephone > number-based GTTs, regardless of whether the lower layers > are MTP or > M3UA+RTSP+IP. Maybe then this LNP database is comparable to IP routing tables distributed throughout routers. At least, functionally, since it is required for routing of telephone calls. (By the way, I didn't know that the LNP database entries are broadcast. Interesting. This compares with the propagation of info in schemes like OSPF or RIP, which is asynchronous, and only between neighbors.) > Caching is not an effective answer, because unlike domain > name lookups, the > lookup frequency of geographic numbers by value is > uniformly flat and > uncorrelated, and the TTLs must be set to relatively > short intervals to keep > looping probabilities managably low. Just as long-term caching of routing tables is not effective in the Internet. I don't think this is comparable to the DNS, though, because the DNS does not have information that is used in routing. The DNS does not need to respond, for example, to any temporary breaks in the infrastructure. The DNS is more like a telephone _directory_. > Fortunately, there is no > staleness problem with > the databases today, nor do we have to introduce one > where it doesn't exist. > Avoiding stale data is also consistent with the FCC > requirement of not > relying on the donor network for call-related (in this > case, database query) > processing. Service providers must be free to choose who > will host the > database their resolvers will consult. The staleness issue is not an issue in what I thought we were discussing, unless I missed something. The DNS used in the role of number portability database or in the role of IP-to-E.164 number translation database is not used in a time-critical role at all, as far as I can see. For real-time routing roles, such as tracking of _mobile_ stations or the maintaining of routing tables, I think everyone agrees that the DNS is not the correct solution. Bert albert.e.manfredi@boeing.com _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum