From mailman-owner@ietf.org Wed Mar 1 05:16:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27064 for ; Wed, 1 Mar 2000 05:16:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06086 for ; Wed, 1 Mar 2000 05:14:59 -0500 (EST) Date: Wed, 1 Mar 2000 05:14:59 -0500 (EST) From: mailman-owner@ietf.org Message-Id: <200003011014.FAA06086@optimus.ietf.org> Subject: ietf.org mailing list memberships reminder To: enum-web-archive@optimus.ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, enum-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for enum-web-archive@www.ietf.org: List Password // URL ---- -------- enum@ietf.org aUvt http://www.ietf.org/mailman/options/enum/enum-web-archive@www.ietf.org From enum-admin@ietf.org Thu Mar 2 14:20:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23204 for ; Thu, 2 Mar 2000 14:20:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13568; Thu, 2 Mar 2000 14:16:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13536 for ; Thu, 2 Mar 2000 14:16:07 -0500 (EST) Received: from PMESMTP01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23151 for ; Thu, 2 Mar 2000 14:17:54 -0500 (EST) Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FQT00B7J6EKRF@firewall.mcit.com> for enum@ietf.org; Thu, 2 Mar 2000 19:06:21 +0000 (GMT) Received: from omzmta01.mcit.com (omzmta01.mcit.com [166.37.194.119]) by omzrelay.mcit.com (8.8.7/) with ESMTP id TAA06657; Thu, 02 Mar 2000 19:06:05 +0000 (GMT) Received: from dwillispc8 ([166.35.148.173]) by omzmta01.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000302190604.DKEI22761@dwillispc8>; Thu, 02 Mar 2000 19:06:04 +0000 Date: Thu, 02 Mar 2000 13:05:15 -0600 From: Dean Willis Subject: RE: [Enum] Portable unique identifiers In-reply-to: <4102273CEB77D211869200805FE6F59356EE74@xch-phl-01.he.boeing.com> To: "Manfredi, Albert E" , enum@ietf.org Cc: "ION Group (E-mail)" Message-id: <001501bf847a$3e2bd600$ad9423a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Two points: 1) I enter domain addresses with some regularity on the 6-key pad of my Glenayre pager and the somewhat larger keypads of my Nokia cellphone and the (CLASSIFIED) sipphone on my desk at home. Seems to work OK. 2) Attempts to define the "One True Name" tend to be fraught with peril. Joke: Why not just make everyone in the world a US Taxpayer and use their Taxpayer ID Number (also called Social Security Number) as their Universal ID? But this points out the real problem -- Who will be the root source of Universal Identity? ICANN? Will any choice be acceptable to the great mass of users? We've even seen the single-root fight going on in DNS regularly . . . RFC 2486 seems to recognize that the answer to #2 is "no" -- there will be many sources of identity (domains) and many users or devices will demand multiple identities. I think that to make it really operable requires a single-root registry of domains, like DNS. I seem to remember proposals a while back to do a name-to-number mapping, such that any DNS name could be represented numerically using a "tumbler" (as coined by Ted Nelson) notation, dotted number sequences. This was proposed as a way to simplify twelve-key entry for analog phones. Perhaps some revival of that approach might be feasible for our needs as well? -- Dean > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > Manfredi, Albert E > Sent: Tuesday, February 29, 2000 4:04 PM > To: 'enum@ietf.org' > Cc: ION Group (E-mail) > Subject: [Enum] Portable unique identifiers > > > A short time ago, the topic of how to formulate portable identifiers > relating to E.164 numbers was broached, and someone mentioned > using RFC 2486 > for this purpose. RFC 2486 seems appropriate at first glance, because it > addresses a similar problem, for roaming terminals. But I don't > think it is > the right approach for this application. > > RFC 2486 defines something called Network Access Identifier > (NAI), which is > a location-independent unique ID for a user. And the NAI makes use of the > same naming convention used in e-mail addressing: username@realm. This is > nice because it's a familiar and user-friendly format, but it has two > drawbacks for our purposes: > > 1. It is next to impossible to use such a scheme from a small appliance, > provided with keypad entry only (e.g. cell phone), and > > 2. The realm part of the unique ID ties the user to some service provider, > making the scheme less than totally portable. > > Instead, I propose that a number, perhaps 15 digits long, identified by a > unique prefix, would be about right. This would work with the enum scheme > already scoped out. It could even more easily work with the > existing ATM End > System Identifier (AESA) scheme defined in ATM. > > In the enum world, one might use a domain other than e164.int. > This is not, > after all, an E.164 number. > > In the AESA world, one could either define a specific Address and Format > Identifier (AFI) prefix for these AESAs, _or_ one can use the AFI for the > existing embedded E.164 format, and then make use of parts of that 20-byte > frame that are currently unused (the HO-DSP and ESI, for example). > > It seems possible to give these portable numbers some sort of > hierarchy that > is not geographically based, so as to even the load among several servers. > Not unlike what happens now with E.164. As you go down the digits, the > search is sent off to different servers. > > For fancy IP appliances that have a keyboard, RFC 2486 would still be > usable, of course. But there must also be a solution for the smaller > appliance, I think. > > Bert > albert.e.manfredi@boeing.com > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Mar 2 14:55:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23930 for ; Thu, 2 Mar 2000 14:55:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16000; Thu, 2 Mar 2000 14:51:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15968 for ; Thu, 2 Mar 2000 14:51:12 -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 OAA23897 for ; Thu, 2 Mar 2000 14:53:03 -0500 (EST) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA06389 for ; Thu, 2 Mar 2000 11:52:25 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id LAA29860 for ; Thu, 2 Mar 2000 11:53:00 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Thu, 2 Mar 2000 11:52:54 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Thu, 2 Mar 2000 14:52:52 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EE81@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Dean Willis'" , enum@ietf.org Cc: "ION Group (E-mail)" Subject: RE: [Enum] Portable unique identifiers Date: Thu, 2 Mar 2000 14:52:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org 1. An authority that manages globally unique IDs of a geographically "flat" address space exists already: the IEEE. I think that they could manage portable IDs as they manage MAC addresses. It's a similar problem, and no one seems to attribute partisanship there. 2. A name-to-number mapping would work too. I proposed such a scheme to the ATMF (atmf 98-0383) a couple of years ago. Any number of schemes could be adopted to do such a thing. Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: Dean Willis [mailto:dean.willis@wcom.com] > Sent: Thursday, March 02, 2000 2:05 PM > To: Manfredi, Albert E; enum@ietf.org > Cc: ION Group (E-mail) > Subject: RE: [Enum] Portable unique identifiers > > > > Two points: > > 1) I enter domain addresses with some regularity on the 6-key > pad of my > Glenayre pager and the somewhat larger keypads of my Nokia > cellphone and the > (CLASSIFIED) sipphone on my desk at home. Seems to work OK. > > 2) Attempts to define the "One True Name" tend to be fraught > with peril. > Joke: Why not just make everyone in the world a US Taxpayer > and use their > Taxpayer ID Number (also called Social Security Number) as > their Universal > ID? But this points out the real problem -- Who will be the > root source of > Universal Identity? ICANN? Will any choice be acceptable to > the great mass > of users? We've even seen the single-root fight going on in > DNS regularly . > . . > > RFC 2486 seems to recognize that the answer to #2 is "no" -- > there will be > many sources of identity (domains) and many users or devices > will demand > multiple identities. I think that to make it really operable > requires a > single-root registry of domains, like DNS. > > I seem to remember proposals a while back to do a > name-to-number mapping, > such that any DNS name could be represented numerically using > a "tumbler" > (as coined by Ted Nelson) notation, dotted number sequences. This was > proposed as a way to simplify twelve-key entry for analog > phones. Perhaps > some revival of that approach might be feasible for our needs as well? > > -- > Dean > > > -----Original Message----- > > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > > Manfredi, Albert E > > Sent: Tuesday, February 29, 2000 4:04 PM > > To: 'enum@ietf.org' > > Cc: ION Group (E-mail) > > Subject: [Enum] Portable unique identifiers > > > > > > A short time ago, the topic of how to formulate portable identifiers > > relating to E.164 numbers was broached, and someone mentioned > > using RFC 2486 > > for this purpose. RFC 2486 seems appropriate at first > glance, because it > > addresses a similar problem, for roaming terminals. But I don't > > think it is > > the right approach for this application. > > > > RFC 2486 defines something called Network Access Identifier > > (NAI), which is > > a location-independent unique ID for a user. And the NAI > makes use of the > > same naming convention used in e-mail addressing: > username@realm. This is > > nice because it's a familiar and user-friendly format, but > it has two > > drawbacks for our purposes: > > > > 1. It is next to impossible to use such a scheme from a > small appliance, > > provided with keypad entry only (e.g. cell phone), and > > > > 2. The realm part of the unique ID ties the user to some > service provider, > > making the scheme less than totally portable. > > > > Instead, I propose that a number, perhaps 15 digits long, > identified by a > > unique prefix, would be about right. This would work with > the enum scheme > > already scoped out. It could even more easily work with the > > existing ATM End > > System Identifier (AESA) scheme defined in ATM. > > > > In the enum world, one might use a domain other than e164.int. > > This is not, > > after all, an E.164 number. > > > > In the AESA world, one could either define a specific > Address and Format > > Identifier (AFI) prefix for these AESAs, _or_ one can use > the AFI for the > > existing embedded E.164 format, and then make use of parts > of that 20-byte > > frame that are currently unused (the HO-DSP and ESI, for example). > > > > It seems possible to give these portable numbers some sort of > > hierarchy that > > is not geographically based, so as to even the load among > several servers. > > Not unlike what happens now with E.164. As you go down the > digits, the > > search is sent off to different servers. > > > > For fancy IP appliances that have a keyboard, RFC 2486 > would still be > > usable, of course. But there must also be a solution for the smaller > > appliance, I think. > > > > Bert > > albert.e.manfredi@boeing.com > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > http://www.ietf.org/mailman/listinfo/enum > > > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Mar 2 15:08:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24508 for ; Thu, 2 Mar 2000 15:08:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16902; Thu, 2 Mar 2000 15:06:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16867 for ; Thu, 2 Mar 2000 15:06:08 -0500 (EST) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24494 for ; Thu, 2 Mar 2000 15:08:00 -0500 (EST) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQieuy23962; Thu, 2 Mar 2000 20:07:56 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA05819; Thu, 2 Mar 00 15:05:01 EST Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id PAA22152; Thu, 2 Mar 2000 15:07:55 -0500 Date: Thu, 2 Mar 2000 15:07:55 -0500 Message-Id: <200003022007.PAA22152@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Albert.Manfredi@PHL.Boeing.com Cc: dean.willis@wcom.com, enum@ietf.org, ion@sunroof.eng.sun.com Subject: Re: (ION) RE: [Enum] Portable unique identifiers References: <4102273CEB77D211869200805FE6F59356EE81@xch-phl-01.he.boeing.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid 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 get the feeling I dropped into the middle of a long discussion (did it only just recently get redirected to include the ion list?). If the goal is to get unique identifiers that are easily administered and have no geographic significance, I agree with Bert that solutions to this have been around for a long time. IEEE, of course, assigns OUIs, which can be used to form MAC addresses. They can also be used to form new things, all you have to do is define that they start with the OUI as administered by IEEE. There are others. Object identifiers are globally unique, non-geographic, and hierarchically administered. They are variable length, which may be the wrong thing here. Several AESA choices are also suitable. DCD format AESAs are at least as flexible as IEEE OUI based IDs. In spite of what you might think, they do NOT have geographic significance. (The fact that a DCD starts with country code 840 means it was assigned by ANSI, but it says nothing whatsoever about the location of the entity identified by that number). So while I don't believe the issue of a single root is a real problem (the DNS "single root fight" claim doesn't sound like it is real), you in fact have several places to pick from already. paul _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Mar 2 15:27:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25474 for ; Thu, 2 Mar 2000 15:27:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17332; Thu, 2 Mar 2000 15:22:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17298 for ; Thu, 2 Mar 2000 15:22:40 -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 PAA25277 for ; Thu, 2 Mar 2000 15:24:32 -0500 (EST) Received: from laptop.ix.netcom.com (pool-209-138-15-203.ipls.grid.net [209.138.15.203]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id PAA04488; Thu, 2 Mar 2000 15:22:49 -0500 (EST) Message-Id: <4.3.2.20000302134352.00b7a720@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 02 Mar 2000 13:47:32 -0600 To: Dean Willis , "Manfredi, Albert E" , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] Portable unique identifiers Cc: "ION Group (E-mail)" In-Reply-To: <001501bf847a$3e2bd600$ad9423a6@mcit.com> References: <4102273CEB77D211869200805FE6F59356EE74@xch-phl-01.he.boeing.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 > >2) Attempts to define the "One True Name" tend to be fraught with peril. >Joke: Why not just make everyone in the world a US Taxpayer and use their >Taxpayer ID Number (also called Social Security Number) as their Universal >ID? But this points out the real problem -- Who will be the root source of >Universal Identity? ICANN? ICANT opps ICANN.. God forbid.... >I seem to remember proposals a while back to do a name-to-number mapping, >such that any DNS name could be represented numerically using a "tumbler" >(as coined by Ted Nelson) notation, dotted number sequences. This was >proposed as a way to simplify twelve-key entry for analog phones. Perhaps >some revival of that approach might be feasible for our needs as well? > >-- >Dean I think the place to watch for this kind of solution is ITU SG2 where there has been a ongoing debate over the ESTI-TIPHON proposal for a global unique personal or IP oriented Country Code [878] +12 digits that could be given to every man woman and child on the planet. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Mar 2 16:13:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27311 for ; Thu, 2 Mar 2000 16:13:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19060; Thu, 2 Mar 2000 16:04:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19027 for ; Thu, 2 Mar 2000 16:04:32 -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 QAA27006 for ; Thu, 2 Mar 2000 16:06:23 -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 PAA07786 for ; Thu, 2 Mar 2000 15:06:18 -0600 (CST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id PAA25290 for ; Thu, 2 Mar 2000 15:06:17 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Thu, 2 Mar 2000 13:06:08 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Thu, 2 Mar 2000 16:06:07 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EE83@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Paul Koning'" Cc: enum@ietf.org, ion@sunroof.eng.sun.com Subject: RE: (ION) RE: [Enum] Portable unique identifiers Date: Thu, 2 Mar 2000 16:06:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Paul Koning wrote: > I get the feeling I dropped into the middle of a long discussion (did > it only just recently get redirected to include the ion list?). Hi Paul. This is a spin-off of a similar discussion, which I think applies to enum and to ion. I am forwarding below a mailing made today on the "parent" thread. Agree on all your points, btw. Bert albert.e.manfredi@boeing.com ------ Forwarded message ------- From: Petri Bernhard [mailto:Bernhard.Petri@icn.siemens.de] Sent: Thursday, March 02, 2000 5:02 AM To: 'Gabriel Montenegro' Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; 'ion@sunroof.eng.sun.com' Subject: (ION) RE: [MOBILE-IP] Private addressing reference in rfc2002-bis ? Hi Gabriel, my proposal wasn't to take oui's as another name space. Instead, I think, the basic question is whether to solve the handling of private IP addresses in Mobile IP by a kind of dns/nai-like solution or by something more directly related to the IP level itself. NAIs are currently used for authentication and identification purposes, and by using them, you can benefit from the existing DNS infrastructure. However, I currently don't see yet, how they could efficiently be inserted into every IP packet, e.g. between FA and HA (the HA somehow has to find the realm, a private IP address received in an IP packet belongs to). I would be very interested in your ideas about this. With regard to your questions on OUIs and realms, please note that not the OUI, but the whole VPN-ID (= OUI + index value, see RFC 2685) would be used to identify an IP address realm. This allows for various possibile uses or allocation algorithms, e.g.: - a big company runs its own corporate network, and uses one or more private address realms. In this case, the company may use its own OUI, and may allocate various identifiers for the particular realms - small companies may use the services of a network operator or service provider. If they use a private addressing realm, they may retrieve an index value from their operator or service provider - there's also the possibility that IANA acts as a neutral source for the allocation realm-IDs based on IANA's own OUI (0x00-00-5E). Although this is just a single OUI, it would allow IANA to allocate as much realm-IDs as we currently have IP addresses (4 byte value). Your suggestion to use AS numbers for the VPN-ID, and its implication of having one VPN-ID / realm ID per AS domain, was also discussed in the ION group at that time. The agreed format of the VPN-ID somehow reflects a compromise on this. While most people want to have their VPN-IDs / realm-IDs to be independent from the specific BGP-4 protocol domains, some in fact wanted to have 1 realm-ID per BGP-4 domain. The latter was the reason for the extension of the initial 3-octet index value (as in current MAC addresses) to 4-octets; this allows to sub-structure the index-values for a particular OUI into: 2-octet ASN + 2 octet ASN-specific index value. Looking forward to some more talks on this in Adelaide Kind regards - Bernhard Bernhard Petri, Siemens Tel: +49 89 722-34578 Fax: +49 89 722-29098 bernhard.petri@icn.siemens.de ______________________________ > -----Original Message----- > From: Gabriel Montenegro [SMTP:gab@eng.sun.com] > Sent: Saturday, February 26, 2000 1:59 AM > To: Petri Bernhard > Cc: 'Gabriel Montenegro'; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; > 'ion@sunroof.eng.sun.com' > Subject: RE: [MOBILE-IP] Private addressing reference in rfc2002-bis > ? > > interesting, thanks for the pointer to the vpn-id stuff. > hmmm... oui's are another name space... > > what i like about realm names is that there is no extra > administration overhead and they are already used within the > nai. from rfc2486 (nai): > > This document defines a new namespace that will need to be > administered, namely the NAI realm namespace. In order to to avoid > creating any new administrative procedures, administration of the NAI > realm namespace will piggyback on the administration of the DNS > namespace. > > NAI realm names are required to be unique and the rights to use a > given NAI realm for roaming purposes are obtained coincident with > acquiring the rights to use a particular fully qualified domain name > (FQDN). Those wishing to use an NAI realm name should first acquire > the rights to use the corresponding FQDN. Using an NAI realm without > ownership of the corresponding FQDN creates the possibility of > conflict and therefore is to be discouraged. > > also, what is the oui for the root realm? > > not all realms will map to a unique oui. in order to specify different > realms (for example for small/informal/impromptu/soho), owners of oui's > might > have to get in the business of further administering the subsequent > 4 byte octet index value in the vpn-id, to avoid collisions. it gets > messy, specially because the small network operators (driving forces > behind nats and rsip applications) now have to ask a much larger > corporation (large enough to own an oui) to allocate some vpn-id > space for them. perhaps oui's work best at the high-end, with large > corporations and ISP's. not sure they're a good easy thing to use > for smaller networks, where a DNS domain name may be simpler. > > by the way, if the idea is to use a fixed size binary representation > for a "vpn-id", did the ion working group consider > > in addition to this: > > 3 octet oui + 4 octet index value > > this?: > > 2 octet ASN (autonomous system number) + 4 octet index value > > saves you one byte, but most importantly, it reuses stuff that's > already needed as a precondition to getting on the internet. > seems like both oui and asn variations could be useful. > > regards, > > -gabriel _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sat Mar 4 13:32:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06686 for ; Sat, 4 Mar 2000 13:32:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11001 for ; Sat, 4 Mar 2000 13:30:05 -0500 (EST) Date: Sat, 4 Mar 2000 13:30:05 -0500 (EST) From: enum-admin@ietf.org Message-Id: <200003041830.NAA11001@optimus.ietf.org> Subject: enum@ietf.org mailing list reminder To: enum-web-archive@optimus.ietf.org Errors-To: enum-admin@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List This is a reminder of how to unsubscribe or change your configuration for the address "enum-web-archive@www.ietf.org" on the mailing list enum. You need to have your password for these things. YOUR enum PASSWORD IS: aUvt To make changes to your subscription, use the password on your options World Wide Web page: http://www.ietf.org/mailman/options/enum/enum-web-archive@www.ietf.org You can also make such changes via email - send a message to: enum-request@ietf.org with the text "help" in the subject or body, and you will be emailed instructions. Questions or comments? Please send them to enum-admin@ietf.org. From enum-admin@ietf.org Thu Mar 16 13:25:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18974 for ; Thu, 16 Mar 2000 13:25:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08618; Thu, 16 Mar 2000 13:20:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08584 for ; Thu, 16 Mar 2000 13:20:09 -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 NAA17847 for ; Thu, 16 Mar 2000 13:22:08 -0500 (EST) Received: from laptop.ix.netcom.com ([209.138.6.92]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id NAA05379 for ; Thu, 16 Mar 2000 13:21:59 -0500 (EST) Message-Id: <4.3.2.20000316113440.00b242c0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 16 Mar 2000 11:35:29 -0600 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Agenda... 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 Do we have a agenda ready for Oz? The deadlines are rapidly approaching. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Mar 16 15:13:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27920 for ; Thu, 16 Mar 2000 15:13:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14754; Thu, 16 Mar 2000 15:09:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14728 for ; Thu, 16 Mar 2000 15:09:49 -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 PAA27497 for ; Thu, 16 Mar 2000 15:11:50 -0500 (EST) Received: from laptop.ix.netcom.com ([209.138.158.115]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id PAA04743 for ; Thu, 16 Mar 2000 15:11:47 -0500 (EST) Message-Id: <4.3.2.20000316141136.00b93bd0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 16 Mar 2000 14:11:46 -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-enum-e164dir-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 >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-vaudreuil-enum-e164dir-00.txt >Date: Fri, 10 Mar 2000 06:28:53 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Telephone Number Based Directory Service > Author(s) : A. Brown, G. Vaudreuil > Filename : draft-vaudreuil-enum-e164dir-00.txt > Pages : 13 > Date : 09-Mar-00 > >This document outlines the principles for the operation of a >telephone number directory service. This service provides for the >resolution of telephone numbers into Internet domain name addresses >and service specific directory discovery. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-vaudreuil-enum-e164dir-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-enum-e164dir-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-enum-e164dir-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: <20000309140139.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-vaudreuil-enum-e164dir-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 Fri Mar 17 13:05:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16412 for ; Fri, 17 Mar 2000 13:05:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28026; Fri, 17 Mar 2000 13:02:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27967 for ; Fri, 17 Mar 2000 13:02:18 -0500 (EST) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16096; Fri, 17 Mar 2000 13:04:22 -0500 (EST) Received: from laptop.ix.netcom.com ([209.138.9.218]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA23422; Fri, 17 Mar 2000 13:04:20 -0500 (EST) Message-Id: <4.3.2.20000317120322.00ba5e70@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 17 Mar 2000 12:04:10 -0600 To: enum@ietf.org From: Richard Shockey Cc: itu+ietf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] FYI - Fwd: I-D ACTION:draft-foster-e164-gstn-np-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-foster-e164-gstn-np-00.txt >Date: Fri, 17 Mar 2000 08:22:10 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Number Portability in the GSTN: An Overview > Author(s) : M. Foster, J. Yu, T. McGarry > Filename : draft-foster-e164-gstn-np-00.txt > Pages : 28 > Date : 16-Mar-00 > >This document provides an overview of E.164 telephone number >portability (NP) in the Global Switched Telephone Network (GSTN). >There are three types of number portability: service provider >portability (SPNP), location portability, and service portability. >Service provider portability, the focus of the present draft, is a >regulatory imperative in many countries seeking to liberalize local >telephony service competition, by enabling end-users to retain pre- >existing telephone numbers while changing service providers. >Implementation of NP within national GSTN entails potentially >significant changes to numbering administration, network element >signaling, call routing and processing, billing, service management, >and other functions. NP changes the fundamental nature of a dialed >E.164 number from a hierarchical physical routing address to a >virtual address, thereby requiring the transparent translation of >the later to the former. In addition, there are various regulatory >constraints which establish relevant parameters for NP >implementation, most of which are not network technology specific. >Consequently, the implementation of NP behavior consistent with >applicable regulatory constraints, as well as the need for >interoperation with the existing GSTN NP implementations, are >relevant topics for numerous areas of IP telephony work-in-progress >at IETF. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-foster-e164-gstn-np-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-foster-e164-gstn-np-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-foster-e164-gstn-np-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20000316144422.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-foster-e164-gstn-np-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 Mon Mar 20 23:22:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14734 for ; Mon, 20 Mar 2000 23:22:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04218; Mon, 20 Mar 2000 23:17:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04188 for ; Mon, 20 Mar 2000 23:17:47 -0500 (EST) Received: from nic.cafax.se (IDENT:root@nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13729 for ; Mon, 20 Mar 2000 23:19:51 -0500 (EST) Received: from 192.168.110.8 (workstation1.swip.net [130.244.254.1]) by nic.cafax.se (8.9.1a/8.9.1) with ESMTP id FAA11051; Tue, 21 Mar 2000 05:19:25 +0100 (MET) Date: Mon, 20 Mar 2000 15:06:36 -0800 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Vaudreuil, Greg M (Greg)" , Richard Shockey , gregv@lucent.com, enum@ietf.org Message-ID: <185411.3162553596@localhost> In-Reply-To: <6B57F36F4FF9D111B30A0008C7F4133702E4DE83@exdal1.ons.octel.com> X-Mailer: Mulberry/2.0.0b12 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Enum] draft-vaudreuil-enum-e164dir-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 Content-Transfer-Encoding: 7bit --On 2000-03-20 10.18 -0600, "Vaudreuil, Greg M (Greg)" wrote: > The differences in > goals underlying this document and Patrik's should be fodder for > interesting debate. :-) There are immediately some comments I have to your draft. First two general ones: (1) There is not much difference between your and mine paper. I only talk about how to translate from E.164 into a DNS name. How that DNS name is out of scope for my paper, and I will if people want to, remove examples from the paper. I am though of the view that one can not forbid use of any existing service which is based on DNS names to also use these DNS names which are created by doing this translation. I.e. if I am putting an explicit SRV for SIP or SMTP in the tree where the E.164 PTR is in your case, I don't see why it should not work. (2) I would like you to remove some generic talk about DNS from your paper. Several issues are discussed in the DNSOP wg, and "guesses" about when and why TTL of zero is needed etc is probably not needed in your paper. Now more specifics about section 5: > 5.1 Telephone Number to Domain Name Mapping > > For the purposes of discussion and example, this document assumes > the e164.int domain as the root for the telephone numbering > hierarchy. In operation, it can be something else to be determined > later. It might be the case that the domain will be different than this, but I'll be back on this. > Example: > > 1.e164.int > 1.1.1.1.3.3.7.2.7.9 PTR ServiceProvider.net ; for +1 972 733 1111 > 1.1.1.1.3.2.8.4.1.2 PTR ServiceProvider.net ; for +1 214 823 1111 As I said above, I don't want to exclude of putting other record types where the PTR RR is. It is also the case that I am not really sure if PTR is the correct RR type to use. I need to think about this, and talk with some DNS people. > 5.1.1 Example: Simple Service Requiring Only First Level Query > > One example is a hypothetical > service that uses SMTP for the transport mechanism and well > understood rules for the construction of an SMTP address. For > example, using a telephone number in the local-part and using the > domain name from the first level query in the domain-part (e.g., > service-abc=14161234567@bigco.com. The separate Mail Exchange (MX) > service record provides adequate information to route the message > once the email address has been constructed. This scenario would be > useful in services such as the above, if additional information and > capabilities were not required in order to send a message. I definitely we should minimize the number of ways we given a DNS name, turn that DNS name + wishes on services, turn that into an identifier which is used by the specific service. Because of this, I don't like the idea having several applications each inventing their own way of doing this. So, I don't like the example. (The generic case is though ok, see below, but should be done via NAPTRs like in my paper, and not by out-of-band communication aka specifications per service.) > Note that there can be only a single instance of a service for each > telephone number. Nope. The SRV record explicitely allows multiple instances of services for each name in DNS. So this statement above is not correct. Not even in the case of generic telephony. > Sample configuration for numbers sub-delegated from > ServiceProviderA.net: > > *.2.1.5.5.5.3.1.6.1.e164.int. PTR Zcorporation.com. > ;for 613 555 12XX Wildcards in DNS should be avoided at all costs. DNSSEC and other things will not be able to handle it. So, the wildcard is from my perspective here made so it is easier to configure the DNS server, and that can be done by other means. > Sample service-specific queries and responses: > > Query: _reachme._tcp. 2.1.2.1.5.5.5.3.1.6.1.Zcorporation.com > Response: SRV=ldap.Zcorporation.net weight=10 > preference=10 port=389 > > The client can then use LDAP with the reachme schema to determine > the set of communications technologies available for +1 613 555 > 1212. This is NOT a good idea. The problem is that you then can get different responses depending on in what DNS hierarchy you are looking up the SRV record. In this case, you query the DNS server for zcorporation.com, and in some other cases you query the DNS server for tele2.se. I think the goal of you example would be to have the _reachme._tcp SRV record for the given E.164 number refer to an authoritative LDAP service which is the reachme service? Can you explain why each ISP should (potentially) be able to have SRV records for the _same_ E.164 record refering to different LDAP servers in this case? IF different ISPs should have different view on how to route the call, then this is the wrong place in the hierarchy to handle the redirection. It is also the case that the lookup process in DNS will be much more expensive, and you have to go to a different place in the DNS tree before getting the "referral" from DNS into LDAP. It is much more effective to put the SRV in the correct space in the tree immediately. > SIPphonecall service-specific queries and responses: > > Query: > > _sipphonecall._tcp.3.1.3.1.5.5.5.2.7.9.1.ServiceProviderB.net > Response: SRV=sipgw1.ServiceProviderB.net weight=1 > preference=10 port=100 > > The client can now use the SIP protocols to contact the SIP gateway > to initiate a phone call. This is something I also don't like, as a different ISP might refer the number somewhere else. As ServiceProviderB.net is already authoritative for that number, I don't see why you have to suffix the E.164 number with the domain of the serviceprovider? You could aswell put the SRV in the hierarchy of the E.164 directly. What have I not understood? Patrik _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Mar 21 03:11:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20855 for ; Tue, 21 Mar 2000 03:11:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13072; Tue, 21 Mar 2000 03:08:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13003 for ; Tue, 21 Mar 2000 03:08:28 -0500 (EST) Received: from venus.kdd.co.jp (venus.kdd.co.jp [211.4.169.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20688; Tue, 21 Mar 2000 03:10:32 -0500 (EST) From: to-tamura@kdd.co.jp Received: by venus.kdd.co.jp; id RAA23930; Tue, 21 Mar 2000 17:10:02 +0900 (JST) Received: from em01sjk.kdd.co.jp (localhost [127.0.0.1]) by jupiter.kdd.co.jp (8.8.8/3.6W) with ESMTP id RAA14240; Tue, 21 Mar 2000 17:10:01 +0900 (JST) Received: from localhost (root@localhost) by kdd.co.jp (8.8.6) with SMTP id RAA29196; Tue, 21 Mar 2000 17:10:00 +0900 (JST) X-OpenMail-Hops: 1 Date: Tue, 21 Mar 2000 17:09:47 +0900 Message-Id: MIME-Version: 1.0 TO: itu+ietf@ietf.org CC: enum@ietf.org Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Subject: [Enum] NNAR Workshop Issues 4 and 5 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 Participants in Question 1 (Numbering) of ITU-T Study Group 2 have put together some information relevant to E.164-DNS interworking (for Issue 4) during their recent meeting, and I am providing an ASCII text version of the Carrier Selection supplement to E.164 (for Issue 5). These files may be found at the following URLs: http://www.itu.int/ITU-T/ip-telecoms/nnar/nnar-e164-dns-iw-info.txt and http://www.itu.int/ITU-T/ip-telecoms/nnar/nnar-carrier-sel-supp.txt -Toshiyuki Tamura KDD Japan _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Mar 21 11:45:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21473 for ; Tue, 21 Mar 2000 11:45:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17855; Tue, 21 Mar 2000 11:42:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17826 for ; Tue, 21 Mar 2000 11:42:48 -0500 (EST) Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21215 for ; Tue, 21 Mar 2000 11:44:56 -0500 (EST) Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA13070 for ; Tue, 21 Mar 2000 11:44:57 -0500 (EST) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id LAA13008; Tue, 21 Mar 2000 11:44:55 -0500 (EST) Received: from buzz.ons.octel.com by ihrh1.emsr.lucent.com (SMI-8.6/EMS-1.5 Solaris/emsr) id KAA04653 for ; Tue, 21 Mar 2000 10:44:37 -0600 Received: from exdal1.ons.octel.com (exdal1 [155.184.13.201]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id KAA08042; Tue, 21 Mar 2000 10:44:38 -0600 (CST) Received: by exdal1.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 21 Mar 2000 10:43:57 -0600 Message-ID: <6B57F36F4FF9D111B30A0008C7F4133702E4DEB0@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , enum@ietf.org Subject: RE: [Enum] draft-vaudreuil-enum-e164dir-00.txt Date: Tue, 21 Mar 2000 10:43:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Thanks for the review. I will try to address your points. 1) The ENUM service needs to be sufficiently defined for a client to retreive the necessary information to initiate a communications session. Because this information varies by communication medium, it is not possible to define a fully general scheme that provides sufficient information. The approach in this submission is to issolate the telephone number to domain name service such that any client for any communciations medium can use this service with a high likelihood of interoperability. It is our assertion that communication medium specific services need to be defined in separate work items that address the specific needs of that meduim. Further, this service-specific definition needs to be sufficiently independent that the basic ENUM service does not need to be upgraded for each new service that is created. Use of the NAPTR records in the telephone number tree provides excessive flexiblity without providing any clear advantage for clients wishing to initiate a communication. Further, such a construct requires the entity providing telephone number to responsible domain to provide many anticilary services such as service registration and dispute resolution without explicit administative support. We have chosen to separarate the service-specific information into another DNS branch under the direct administative responsibility of the responsible domain. What may fundamentally underly our differing approaches is the administative model. We note that that telephone number hierarchy is a top-down delegation hierarchy with clear administative procedures and explicit authentication to ensure that numbers are not duplicately assigned or falsely asserted by hostite entities. Similarly, domain names are hierarchically assigned with clear procedures. We assert that the ENUM service conceptually links the phone number to the domain name. As such, the ENUM service should be an adjunct to the existing telphone number management infrastructure. I believe Patrick's proposal reflects a bottoms-up, or domain-name centric view. In this view the domain name holder registers the telephone number with one or more registration services. In this bottoms-up model, it makes sense for the end-user to specify their service-specific information to the registration entity at the time the phone number is registered. In our model, the phone number management infrastrucure has no basis to accept or manage this service specific information beyond simply mapping the phone number to the domain name of the responsible entity. 2) The operational constraints and TTL discussion should move someplace else. There is a bit of confusion in the sequencing of documents. Much of this discussion is in support of requirements not currently in the requirements document. From my vantage point, the ENUM service is a core infrastructural component for many important services and should TARGET performance, reliability, and anti-looping parity with the existing phone network. Designs inconsisent with this goal should be rejected. The discussion of TTL and caching is my justification of the design relative to these requirements. If individual services can be substantially slower and less reliable, so be it. 3) The PTR record meets the specific need and is widely deployed in clients and servers. SIP and NAPTR records require more information than a top-level phone number to domain name mapping service is likely to have. Supporting multiple record types for the same function makes client development much harder and less likely to be interoperable. 4) I believe each service should define for itself how it will use the ENUM service. The services vary widely in their requirements for information. The first messaging example illustrates a possible use of ENUM where service-specific configuration information combined with the ENUM returned data is sufficient. This is unlikely to be the case for many other services. I don't see how NAPTR is general enough to be used for all services without this per-service definition. 5) While you can have multiple instances of SRV records for a given service per a given domain name, I believe the semantics are such that they are assumed to be functionality identical services. The idea of multiple SRV records of a given service type is to provide redundancy and load-ballancing, not act as a capabilities negotiation mechanism between the sender and recipient. 6) Wildcards in DNS... I don't get it. I need to learn more to address this issue. My guess is that this is a error in my example writing. 7) Telephone number in second level query: The intent of using the telephone number in the second query is to permit individualized responses without requiring the first level ENUM to return separate domains for each telephone number. This was a late addition to the proposal and is inadequately explained. Thanks, Greg V. -----Original Message----- From: Patrik Fältström [mailto:paf@swip.net] Sent: Monday, March 20, 2000 5:07 PM To: Vaudreuil, Greg M (Greg); Richard Shockey; gregv@lucent.com; enum@ietf.org Subject: [Enum] draft-vaudreuil-enum-e164dir-00.txt --On 2000-03-20 10.18 -0600, "Vaudreuil, Greg M (Greg)" wrote: > The differences in > goals underlying this document and Patrik's should be fodder for > interesting debate. :-) There are immediately some comments I have to your draft. First two general ones: (1) There is not much difference between your and mine paper. I only talk about how to translate from E.164 into a DNS name. How that DNS name is out of scope for my paper, and I will if people want to, remove examples from the paper. I am though of the view that one can not forbid use of any existing service which is based on DNS names to also use these DNS names which are created by doing this translation. I.e. if I am putting an explicit SRV for SIP or SMTP in the tree where the E.164 PTR is in your case, I don't see why it should not work. (2) I would like you to remove some generic talk about DNS from your paper. Several issues are discussed in the DNSOP wg, and "guesses" about when and why TTL of zero is needed etc is probably not needed in your paper. Now more specifics about section 5: 3) > 5.1 Telephone Number to Domain Name Mapping > > For the purposes of discussion and example, this document assumes > the e164.int domain as the root for the telephone numbering > hierarchy. In operation, it can be something else to be determined > later. It might be the case that the domain will be different than this, but I'll be back on this. > Example: > > 1.e164.int > 1.1.1.1.3.3.7.2.7.9 PTR ServiceProvider.net ; for +1 972 733 1111 > 1.1.1.1.3.2.8.4.1.2 PTR ServiceProvider.net ; for +1 214 823 1111 As I said above, I don't want to exclude of putting other record types where the PTR RR is. It is also the case that I am not really sure if PTR is the correct RR type to use. I need to think about this, and talk with some DNS people. 4) > 5.1.1 Example: Simple Service Requiring Only First Level Query > > One example is a hypothetical > service that uses SMTP for the transport mechanism and well > understood rules for the construction of an SMTP address. For > example, using a telephone number in the local-part and using the > domain name from the first level query in the domain-part (e.g., > service-abc=14161234567@bigco.com. The separate Mail Exchange (MX) > service record provides adequate information to route the message > once the email address has been constructed. This scenario would be > useful in services such as the above, if additional information and > capabilities were not required in order to send a message. I definitely we should minimize the number of ways we given a DNS name, turn that DNS name + wishes on services, turn that into an identifier which is used by the specific service. Because of this, I don't like the idea having several applications each inventing their own way of doing this. So, I don't like the example. (The generic case is though ok, see below, but should be done via NAPTRs like in my paper, and not by out-of-band communication aka specifications per service.) > Note that there can be only a single instance of a service for each > telephone number. 5) Nope. The SRV record explicitely allows multiple instances of services for each name in DNS. So this statement above is not correct. Not even in the case of generic telephony. > Sample configuration for numbers sub-delegated from > ServiceProviderA.net: > > *.2.1.5.5.5.3.1.6.1.e164.int. PTR Zcorporation.com. > ;for 613 555 12XX 6) Wildcards in DNS should be avoided at all costs. DNSSEC and other things will not be able to handle it. So, the wildcard is from my perspective here made so it is easier to configure the DNS server, and that can be done by other means. 7) > Sample service-specific queries and responses: > > Query: _reachme._tcp. 2.1.2.1.5.5.5.3.1.6.1.Zcorporation.com > Response: SRV=ldap.Zcorporation.net weight=10 > preference=10 port=389 > > The client can then use LDAP with the reachme schema to determine > the set of communications technologies available for +1 613 555 > 1212. This is NOT a good idea. The problem is that you then can get different responses depending on in what DNS hierarchy you are looking up the SRV record. In this case, you query the DNS server for zcorporation.com, and in some other cases you query the DNS server for tele2.se. I think the goal of you example would be to have the _reachme._tcp SRV record for the given E.164 number refer to an authoritative LDAP service which is the reachme service? Can you explain why each ISP should (potentially) be able to have SRV records for the _same_ E.164 record refering to different LDAP servers in this case? IF different ISPs should have different view on how to route the call, then this is the wrong place in the hierarchy to handle the redirection. It is also the case that the lookup process in DNS will be much more expensive, and you have to go to a different place in the DNS tree before getting the "referral" from DNS into LDAP. It is much more effective to put the SRV in the correct space in the tree immediately. > SIPphonecall service-specific queries and responses: > > Query: > > _sipphonecall._tcp.3.1.3.1.5.5.5.2.7.9.1.ServiceProviderB.net > Response: SRV=sipgw1.ServiceProviderB.net weight=1 > preference=10 port=100 > > The client can now use the SIP protocols to contact the SIP gateway > to initiate a phone call. This is something I also don't like, as a different ISP might refer the number somewhere else. As ServiceProviderB.net is already authoritative for that number, I don't see why you have to suffix the E.164 number with the domain of the serviceprovider? You could aswell put the SRV in the hierarchy of the E.164 directly. What have I not understood? Patrik _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Mar 21 12:44:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12906 for ; Tue, 21 Mar 2000 12:44:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18953; Tue, 21 Mar 2000 12:41:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18911 for ; Tue, 21 Mar 2000 12:41:31 -0500 (EST) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12699 for ; Tue, 21 Mar 2000 12:43:38 -0500 (EST) Received: from laptop.ix.netcom.com ([209.138.179.204]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA16747; Tue, 21 Mar 2000 12:43:27 -0500 (EST) Message-Id: <4.3.2.20000320224709.00b0bec0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 21 Mar 2000 11:42:24 -0600 To: enum@ietf.org From: Richard Shockey Cc: Scott Bradner Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Potential Agenda for ENUM Adelide 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 the interests of moving the work along I'd like to suggest a possible agenda for next week. We do have a 2 1/2 hour session and there is much to discuss. If you have any additions or suggestions... NOW is the time. TUESDAY, March 28, 2000 0800-1700 IETF Registration - Foyer 1 0800-0900 Continental Breakfast - Foyer and Circulation Area 0900-1130 Morning Sessions Hall D TSV enum Telephone Number Mapping WG Agenda Bashing - 5 Min Appoint Scribe - Volunteers needed !!! Review of Problem Statement - 2 Min Report on IETF-ITU Joint meeting in Geneva .. where ENUM was presented and discussed at some length - 10 Min Communication from ITU-SG2/Q1 15 Min SG2/Q1 which deals with numbering issues has been kind enough to forward some information that should be relevant to our discussions. Please attempt to review this material for comments. http://www.itu.int/ITU-T/ip-telecoms/nnar/nnar-e164-dns-iw-info.txt http://www.itu.int/ITU-T/ip-telecoms/nnar/nnar-carrier-sel-supp.txt Drafts for Review: ENUM Requirements (raft-ietf-enum-rqmts-00.txt 20 Min Additions Subtractions ??? E.164 number and DNS draft-faltstrom-e164-05.txt 10 Min Telephone Number Based Directory Service draft-vaudreuil-enum-e164dir-00.txt 1 Hour ++ Number Portability in the GSTN: An Overview draft-foster-e164-gstn-np-00.txt [no discussion ] Note the Number Portability draft is informational. It is not directly ENUM charter but the information is useful in understanding the context numbering plays in the GSTN. General discussion. Future steps and directions. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Mar 21 13:46:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06440 for ; Tue, 21 Mar 2000 13:46:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19717; Tue, 21 Mar 2000 13:43:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19685 for ; Tue, 21 Mar 2000 13:43:23 -0500 (EST) Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05882 for ; Tue, 21 Mar 2000 13:45:03 -0500 (EST) Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA04093; Tue, 21 Mar 2000 13:44:30 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA13013; Tue, 21 Mar 2000 13:44:31 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Mar 2000 13:40:04 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF208B3E@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "'Richard Shockey'" , enum@ietf.org Subject: RE: [Enum] Potential Agenda for ENUM Adelide Date: Tue, 21 Mar 2000 13:43:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Why don't we move draft-foster-e164-gstn-np-00.txt up before anything with discussion. I think we can keep the Q21 material short - it's pretty self explanatory. I'm not sure we can get through draft-faltstrom-e164-05.txt in 10 minutes. Brian > -----Original Message----- > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > Sent: Tuesday, March 21, 2000 12:42 PM > To: enum@ietf.org > Cc: Scott Bradner > Subject: [Enum] Potential Agenda for ENUM Adelide > > > > In the interests of moving the work along I'd like to suggest > a possible > agenda for next week. > > We do have a 2 1/2 hour session and there is much to discuss. > > If you have any additions or suggestions... NOW is the time. > > > TUESDAY, March 28, 2000 0800-1700 IETF Registration - Foyer 1 > 0800-0900 Continental Breakfast - Foyer and Circulation Area > 0900-1130 Morning Sessions > > Hall D TSV enum Telephone Number Mapping WG > > > Agenda Bashing - 5 Min > > Appoint Scribe - Volunteers needed !!! > > Review of Problem Statement - 2 Min > > Report on IETF-ITU Joint meeting in Geneva .. where ENUM was > presented and > discussed at some length - 10 Min > > Communication from ITU-SG2/Q1 15 Min > > SG2/Q1 which deals with numbering issues has been kind enough > to forward > some information that should be relevant to our discussions. > Please attempt > to review this material for comments. > > > http://www.itu.int/ITU-T/ip-telecoms/nnar/nnar-e164-dns-iw-info.txt > > http://www.itu.int/ITU-T/ip-telecoms/nnar/nnar-carrier-sel-supp.txt > > > Drafts for Review: > > ENUM Requirements (raft-ietf-enum-rqmts-00.txt 20 Min > > Additions Subtractions ??? > > E.164 number and DNS draft-faltstrom-e164-05.txt 10 Min > > Telephone Number Based Directory Service > draft-vaudreuil-enum-e164dir-00.txt 1 Hour ++ > > Number Portability in the GSTN: An Overview > draft-foster-e164-gstn-np-00.txt > [no discussion ] Note the Number Portability draft is > informational. It is > not directly ENUM charter but the information is useful in > understanding > the context numbering plays in the GSTN. > > General discussion. > > Future steps and directions. > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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 Tue Mar 21 21:30:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29908 for ; Tue, 21 Mar 2000 21:30:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09141; Tue, 21 Mar 2000 21:27:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09110 for ; Tue, 21 Mar 2000 21:27:55 -0500 (EST) Received: from adsl-151-203-17-31.metatel.office (root@adsl-151-203-17-31.bellatlantic.net [151.203.17.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29562 for ; Tue, 21 Mar 2000 21:29:59 -0500 (EST) Received: from localhost (scott.petrack@localhost) by adsl-151-203-17-31.metatel.office (8.9.3/8.9.3) with ESMTP id PAA00926 for ; Tue, 21 Mar 2000 15:30:12 -0500 X-Authentication-Warning: adsl-151-203-17-31.metatel.office: scott.petrack owned process doing -bs Date: Tue, 21 Mar 2000 15:30:12 -0500 (EST) From: Scott Petrack X-Sender: scott.petrack@adsl-151-203-17-31.metatel.office To: enum@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Enum] Agenda for ENUM and Adelaide - The WG chair comes clean 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 Dear Friends: I wish to explain and apologize for my almost complete lack of presence during the last few months. What happened is quite simple: I became extremely ill in early January; this took up almost my entire time throughout the month and much of February. The time since then has been spent recovering my day job. I'm pretty much recovered now, but the end result of all of this is that I've pretty much been completely out of commission for exactly one "IETF-period". I fully realize that ENUM has been having some very interesting discussions without me, but my absence has really hurt the progression of the two drafts, of Anne and of Patrik. The good news is that our currently chartered work is of sufficiently narrow scope that I feel sure we can progress to a summer close. The bad news is that because of me, much time has been lost. I can only give my committment and the commitment of my company that I shall be absolutely be able to allocate the needed time and attention to get the job done. It is not appropriate to get into my personal details of the past few months; suffice it to say that it seems certain that what I had will no longer interfere with the performance of my duties. Here is how I suggest that we get back on track: 1. I propose the following agenda for Adelaide: a. discussion of draft-ietf-enum-rqmts-00.txt issues from the list b. discussion of draft-faltstrom-e164-05.txt issues from the list(s) c. Greg Vaudreuil has asked for time to present his point of view d. discussion of some other issues from the list Should someone else need to speak, I will be at the Hyatt in Adelaide from Friday on, and I am now fully back in email. 2. I intend to work double-time over the next few weeks to resolve the open issues of how ENUM fits into to other related groups. This is something I had no choice but to ignore during the past few months, as I could barely read email. Once again, apologies to all those who have been annoyed or frustrated by my lack of communication over the past few months. Such nonsense is over now. Since the last IETF, I see that many people have woken up to the tremendous potential that ENUM has. Scott _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Mar 21 23:23:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13296 for ; Tue, 21 Mar 2000 23:23:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA10024; Tue, 21 Mar 2000 23:20:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09994 for ; Tue, 21 Mar 2000 23:20:48 -0500 (EST) Received: from nic.cafax.se (IDENT:root@nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13181 for ; Tue, 21 Mar 2000 23:22:55 -0500 (EST) Received: from 192.168.110.8 (workstation1.swip.net [130.244.254.1]) by nic.cafax.se (8.9.1a/8.9.1) with ESMTP id FAA23303; Wed, 22 Mar 2000 05:22:44 +0100 (MET) Date: Tue, 21 Mar 2000 20:13:21 -0800 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Rosen, Brian" , "'Richard Shockey'" , enum@ietf.org Subject: RE: [Enum] Potential Agenda for ENUM Adelide Message-ID: <2292963.3162658401@localhost> In-Reply-To: <4FBEA8857476D311A03300204840E1CF208B3E@whq-msgusr-02.fore.com> X-Mailer: Mulberry/2.0.0b12 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2000-03-21 13.43 -0500, "Rosen, Brian" wrote: > I'm not sure we can get through draft-faltstrom-e164-05.txt in > 10 minutes. I am sorry if the text in the draft is confusing. The text talk about two things, and the latter probably should be deleted, as it is confusing people: (1) How to do a mechanical transformation of one E.164 number into a domainname which can be stored in DNS (2) Give examples of existing services defined for use given arbitrary DNS names (including the ones defined under (1) above) It is only (1) above which is important. The second thing is that when having E.164 numbers as DNS names, that they try to guess/experiment/try what things can be done given _existing_ operations and data that can be stored. It should not be in a draft only talking about the E.164<->DNS transformation though, and I am happy to remove that text. It is already described in other RFCs and doesn't have to / should not be repeated. Patrik _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Mar 22 01:15:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01020 for ; Wed, 22 Mar 2000 01:15:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15646; Wed, 22 Mar 2000 01:12:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15616 for ; Wed, 22 Mar 2000 01:12:05 -0500 (EST) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00280 for ; Wed, 22 Mar 2000 01:14:12 -0500 (EST) Received: from laptop.ix.netcom.com ([209.138.6.165]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id BAA17838; Wed, 22 Mar 2000 01:14:03 -0500 (EST) Message-Id: <4.3.2.20000321235323.00b79670@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 22 Mar 2000 00:04:00 -0600 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Rosen, Brian" , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] Potential Agenda for ENUM Adelide In-Reply-To: <2292963.3162658401@localhost> References: <4FBEA8857476D311A03300204840E1CF208B3E@whq-msgusr-02.fore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA15617 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 At 08:13 PM 3/21/2000 -0800, Patrik Fältström wrote: >--On 2000-03-21 13.43 -0500, "Rosen, Brian" wrote: > > > I'm not sure we can get through draft-faltstrom-e164-05.txt in > > 10 minutes. > >I am sorry if the text in the draft is confusing. The text talk about two >things, and the latter probably should be deleted, as it is confusing >people: > >(1) How to do a mechanical transformation of one E.164 number into a >domainname which can be stored in DNS Oh yes.. I get it now. Patrik you are on to something fundamentally correct here. There will have to be multiple RFC here but the core is TN to >domain of authority as Greg outlines. At least hint to references to service provisioning. Second level is service provisioning which may or may not require 3rd level resolution to LDAP authority. Am I making sense here? >(2) Give examples of existing services defined for use given arbitrary DNS >names (including the ones defined under (1) above) > >It is only (1) above which is important. The second thing is that when >having E.164 numbers as DNS names, that they try to guess/experiment/try >what things can be done given _existing_ operations and data that can be >stored. > >It should not be in a draft only talking about the E.164<->DNS >transformation though, and I am happy to remove that text. It is already >described in other RFCs and doesn't have to / should not be repeated. Examples in the primary ENUM resolution document may be useful but not binding on others wishing to demonstrate service provision. Am I making sense here? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Mar 22 13:18:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01522 for ; Wed, 22 Mar 2000 13:18:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22269; Wed, 22 Mar 2000 13:15:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22238 for ; Wed, 22 Mar 2000 13:15:21 -0500 (EST) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01208 for ; Wed, 22 Mar 2000 13:17:28 -0500 (EST) Received: from dhcp-10.innosoft.com (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id TAA02461; Wed, 22 Mar 2000 19:16:39 +0100 (MET) Date: Wed, 22 Mar 2000 06:33:48 -0800 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Richard Shockey , "Rosen, Brian" , enum@ietf.org Subject: RE: [Enum] Potential Agenda for ENUM Adelide Message-ID: <821082.3162695628@localhost> In-Reply-To: <4.3.2.20000321235323.00b79670@127.0.0.1> X-Mailer: Mulberry/2.0.0b12 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2000-03-22 00.04 -0600, Richard Shockey wrote: > Second level is service provisioning which may or may not require 3rd > level resolution to LDAP authority. > > Am I making sense here? Yes. As soon as you have a domain name, you can do with that name whatever you want which is defined in other RFCs (which I am using in part (2) in my paper) and/or define special algorithms (which Greg is doing via the PTR record) for specific ENUM-related services. This has nothing to do with the mapping between E.164 and domainname though. This is service provisioning. > Examples in the primary ENUM resolution document may be useful but not > binding on others wishing to demonstrate service provision. Am I making > sense here? Yes. As the draft talks about DNS, I thought it was ok to have examples on how to use other DNS RR types already defined for VOIP services given the definition of E.164->DNS names. I will rewrite that part of the paper. Too late for the IETF though. paf _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Mar 22 13:52:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13570 for ; Wed, 22 Mar 2000 13:52:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22652; Wed, 22 Mar 2000 13:50:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22621 for ; Wed, 22 Mar 2000 13:50:02 -0500 (EST) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13464 for ; Wed, 22 Mar 2000 13:52:09 -0500 (EST) Received: from laptop.ix.netcom.com ([209.138.152.165]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA25030; Wed, 22 Mar 2000 13:52:00 -0500 (EST) Message-Id: <4.3.2.20000322124655.00bc2ad0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 22 Mar 2000 12:51:39 -0600 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Rosen, Brian" , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] Potential Agenda for ENUM Adelide In-Reply-To: <821082.3162695628@localhost> References: <4.3.2.20000321235323.00b79670@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA22622 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 At 06:33 AM 3/22/2000 -0800, Patrik Fältström wrote: >--On 2000-03-22 00.04 -0600, Richard Shockey wrote: > > > Second level is service provisioning which may or may not require 3rd > > level resolution to LDAP authority. > > > > Am I making sense here? > >Yes. > >As soon as you have a domain name, you can do with that name whatever you >want which is defined in other RFCs (which I am using in part (2) in my >paper) and/or define special algorithms (which Greg is doing via the PTR >record) for specific ENUM-related services. > >This has nothing to do with the mapping between E.164 and domainname >though. This is service provisioning. So the basic issue we need to sort out in defining 1st level resolution ..Is the PTR RR the most appropriate RR for the purpose of of discovering the "domain of authority" for the number? Right ?? ...everything else is service specific provisioning. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Sun Mar 26 07:28:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09986 for ; Sun, 26 Mar 2000 07:28:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26818; Sun, 26 Mar 2000 07:24:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26787 for ; Sun, 26 Mar 2000 07:24:23 -0500 (EST) Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09425 for ; Sun, 26 Mar 2000 07:26:35 -0500 (EST) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id HAA02854 for ; Sun, 26 Mar 2000 07:26:01 -0500 (EST) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852568AE.00444AC9 ; Sun, 26 Mar 2000 07:25:55 -0500 X-Lotus-FromDomain: TELCORDIA From: "Jay R. Hilton" To: enum@ietf.org Message-ID: <852568AE.004448DE.00@notes949.cc.telcordia.com> Date: Sun, 26 Mar 2000 07:25:27 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Enum] Availability of T1 TRQ's for LNP 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 Greetings: I just wanted to make sure that all ENUM participants were aware that the ANSI T1 Technical Requirements documents (TRQs) for Local Number Portability are available as a free downloads from http://www.t1.org/html/trs.htm. The document titles are: TRQ No. 01, April 1999 - Number Portability Operator Services Switching Systems TRQ No. 02, April 1999 - Number Portability Switching Systems TRQ No. 03, April 1999 - Number Portability Database and Global Title Translation TRQ No. 04, July 1999 - Thousand Block Number Pooling Using Number Portability This work was completed by Working Group T1S1.6, Number Portability. In 2000, T1S1.6 is focusing on Issue 2 of Number Portability including: a) Double tandeming issues, b) Originating switch query of IXC routed calls, and c) Interworking with wireless number portability requirements. T1S1's next meeting will be May 22-26, 2000, in Red Bank, NJ. The official meeting announcement should be available within the next week at the Committee T1 Website at http://www.t1.org , under Notices, Agendas and Minutes. Regards, Jay Hilton Chairman, T1S1 - Services, Architectures and Signaling Telcordia Technologies Tel: (972) 774-7173 14800 Quorum Dr, Suite 320 Fax: (972) 774-8884 Dallas, TX 75240 jhilton@telcordia.com _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Mar 27 20:49:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29266 for ; Mon, 27 Mar 2000 20:49:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21910; Mon, 27 Mar 2000 20:41:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21881 for ; Mon, 27 Mar 2000 20:41:41 -0500 (EST) Received: from msglite.sun.telia.se (kerlite2.sun.telia.se [193.44.164.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29015 for ; Mon, 27 Mar 2000 20:43:53 -0500 (EST) Received: from TRAB2054 (dhcp-192-36.ietf.connect.com.au [169.208.192.36]) by msglite.sun.telia.se (8.9.3/8.9.3) with SMTP id DAA02494 for ; Tue, 28 Mar 2000 03:43:07 +0200 (MET DST) Message-ID: <000d01bebbf1$b3d13fa0$24c0d0a9@trab.se> From: =?iso-8859-1?B?U/ZyZW4gTnlja2VsZ+VyZA==?= To: Date: Mon, 21 Jun 1999 16:23:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 8bit Subject: [Enum] Overlap dialing, again 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 At the ENUM meeting in Adelaide, the overlap dialing issue was rised again. The specific issue was that the lenght of the number might not be known by the client, thus forcing the client to query the DNS for every new digit entered by the user. In this case we assume that the call is made from a terminal, like a conventional black phone, that does not require an 'end-of-number' kind of button to be pushed to complete the number. The chairs were not aware of this particular hazle so the suggestion was to bring up the issue on the list again. So, here it comes... Would it be possible for the DNS to, in some way, drop a hint of the length of the number, e.g. exact length or a minimum length, in order to avoid querying the DNS inbetween every digit? / Sören Nyckelgård, Telia Research _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Mar 27 22:59:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02958 for ; Mon, 27 Mar 2000 22:59:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23278; Mon, 27 Mar 2000 22:55:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23247 for ; Mon, 27 Mar 2000 22:55:43 -0500 (EST) Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02945 for ; Mon, 27 Mar 2000 22:57:54 -0500 (EST) Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id WAA08965; Mon, 27 Mar 2000 22:57:20 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id WAA14043; Mon, 27 Mar 2000 22:57:22 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Mar 2000 22:52:45 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF6780A7@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: =?iso-8859-1?Q?=27S=F6ren_Nyckelg=E5rd=27?= , enum@ietf.org Subject: RE: [Enum] Overlap dialing, again Date: Mon, 27 Mar 2000 22:57:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA23248 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit I'm confused about why this issue comes up. In most systems there is a "dialing plan", which determines how many digits to collect. The local system applies this dialing plan as the first step. When it discovers the terminal digit (by algorithm or timeout), the entire result is subjected to routing. The dialed number it is NOT submitted, digit by digit, to the call routing mechanism. Why should we should we be trying to change this? Brian > -----Original Message----- > From: Sören Nyckelgård [mailto:nyckelgard@dof.se] > Sent: Monday, June 21, 1999 10:23 AM > To: enum@ietf.org > Subject: [Enum] Overlap dialing, again > > > At the ENUM meeting in Adelaide, the overlap dialing issue > was rised again. > The specific issue was that the lenght of the number might > not be known by > the client, thus forcing the client to query the DNS for > every new digit > entered by the user. In this case we assume that the call is > made from a > terminal, like a conventional black phone, that does not require an > 'end-of-number' kind of button to be pushed to complete the number. > > The chairs were not aware of this particular hazle so the > suggestion was to > bring up the issue on the list again. So, here it comes... > > Would it be possible for the DNS to, in some way, drop a hint > of the length > of the number, e.g. exact length or a minimum length, in > order to avoid > querying the DNS inbetween every digit? > > > / Sören Nyckelgård, Telia Research > > > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Mar 28 00:42:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04735 for ; Tue, 28 Mar 2000 00:42:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24467; Tue, 28 Mar 2000 00:38:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24438 for ; Tue, 28 Mar 2000 00:38:47 -0500 (EST) Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04719 for ; Tue, 28 Mar 2000 00:40:57 -0500 (EST) Received: from dhcp-193-37.ietf.connect.com.au [169.208.193.37] by mail.iagu.net (8.8.5/AndrewR-19990125) with SMTP id PAA03190 return ; Tue, 28 Mar 2000 15:10:51 +0930 (CST) Reply-To: From: "Michael Welser" To: Cc: "Rosen, Brian" Subject: RE: [Enum] Overlap dialing, again Date: Tue, 28 Mar 2000 07:42:45 +0200 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: <4FBEA8857476D311A03300204840E1CF6780A7@whq-msgusr-02.fore.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal 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 E.g. Germany and Austria have variable-length numbers (there may be more such countries). There, "classical" POTS access equipment MUST support overlap sending (the only other way would have been to force customers to enter # at the end of the dialling process, which nobody dared enforce - we are talking about the dark past). Of course, there is also a timeout, but this is quite high (I could find out the actual value, it should be around 7 sec) and therefore not really useable... Michael ------------------------------------------------------------ mailto:mwelser@highway.telekom.at Telekom Austria AG > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > Rosen, Brian > Sent: Tuesday, March 28, 2000 5:57 AM > To: 'Sören Nyckelgård'; enum@ietf.org > Subject: RE: [Enum] Overlap dialing, again > > > I'm confused about why this issue comes up. > > In most systems there is a "dialing plan", which determines > how many digits to collect. The local system applies > this dialing plan as the first step. When it discovers > the terminal digit (by algorithm or timeout), the entire > result is subjected to routing. The dialed number it is > NOT submitted, digit by digit, to the call routing > mechanism. > > Why should we should we be trying to change this? > > Brian > > > > -----Original Message----- > > From: Sören Nyckelgård [mailto:nyckelgard@dof.se] > > Sent: Monday, June 21, 1999 10:23 AM > > To: enum@ietf.org > > Subject: [Enum] Overlap dialing, again > > > > > > At the ENUM meeting in Adelaide, the overlap dialing issue > > was rised again. > > The specific issue was that the lenght of the number might > > not be known by > > the client, thus forcing the client to query the DNS for > > every new digit > > entered by the user. In this case we assume that the call is > > made from a > > terminal, like a conventional black phone, that does not require an > > 'end-of-number' kind of button to be pushed to complete the number. > > > > The chairs were not aware of this particular hazle so the > > suggestion was to > > bring up the issue on the list again. So, here it comes... > > > > Would it be possible for the DNS to, in some way, drop a hint > > of the length > > of the number, e.g. exact length or a minimum length, in > > order to avoid > > querying the DNS inbetween every digit? > > > > > > / Sören Nyckelgård, Telia Research > > > > > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > http://www.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Mar 28 01:04:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05131 for ; Tue, 28 Mar 2000 01:04:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24927; Tue, 28 Mar 2000 01:01:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24899 for ; Tue, 28 Mar 2000 01:01:38 -0500 (EST) Received: from magic.kuis.kyoto-u.ac.jp (dhcp-32-75.ietf.connect.com.au [169.208.32.75]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05113 for ; Tue, 28 Mar 2000 01:03:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by magic.kuis.kyoto-u.ac.jp (8.9.3/8.9.3) with ESMTP id PAA04232 for ; Tue, 28 Mar 2000 15:02:22 +0900 (JST) (envelope-from fujikawa@real-internet.org) To: enum@ietf.org X-Mailer: Mew version 1.93 on XEmacs 20.4 (Emerald) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Mar_28_14:59:17_2000_756)--" Content-Transfer-Encoding: 7bit Message-Id: <20000328150221A.fujikawa@real-internet.org> Date: Tue, 28 Mar 2000 15:02:21 +0900 From: FUJIKAWA Kenji X-Dispatcher: imput version 990731(IM118) Lines: 53 Subject: [Enum] My Presentation Slide 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 ----Next_Part(Tue_Mar_28_14:59:17_2000_756)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I understand the following slide is basically out of scope of ENUM WG. However, this information is meaningful for ENUM WG, since some peaple are concerning how the ENUM mechanism coordinates with a local policy. I believe this can be one of solutions. Thank you again for giving me the presentation time. --------------------------------------------------------------- FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan WWW: http://www.lab1.kuis.kyoto-u.ac.jp/~fujikawa/index-e.html TEL +81 75-753-5387 FAX +81 75-751-0482 E-mail fujikawa@real-internet.org ----Next_Part(Tue_Mar_28_14:59:17_2000_756)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit One Idea for Coordinating Local Policy K. Fujikawa @ Kyoto Univ. Japan Problem: There is a case where a local policy is required One solution: Query a directory server with HTTP If the number 1234567 should be processed LOCALLY Query by HTTP (GET /?1234567) Client --------------> Directory Server <------------- |^ Answer by HTTP V| (sip:foo@bar) Local Database If the number 7654321 should be processed GLOBALLY ENUM Mechanism Query by HTTP (GET /?7654321) DNS query Client --------------> Directory Server ----------> DNS Server <------------- <--------- Answer by HTTP DNS response (sip:bar@foo) (sip:bar@foo) ----Next_Part(Tue_Mar_28_14:59:17_2000_756)---- _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Mar 28 01:14:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06411 for ; Tue, 28 Mar 2000 01:14:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29816; Tue, 28 Mar 2000 01:11:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29785 for ; Tue, 28 Mar 2000 01:11:15 -0500 (EST) Received: from venus.kdd.co.jp (venus.kdd.co.jp [211.4.169.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06313 for ; Tue, 28 Mar 2000 01:13:28 -0500 (EST) From: to-tamura@kdd.co.jp Received: by venus.kdd.co.jp; id PAA22136; Tue, 28 Mar 2000 15:12:58 +0900 (JST) Received: from em01sjk.kdd.co.jp (localhost [127.0.0.1]) by jupiter.kdd.co.jp (8.8.8/3.6W) with ESMTP id PAA14732 for ; Tue, 28 Mar 2000 15:12:57 +0900 (JST) Received: from localhost (root@localhost) by kdd.co.jp (8.8.6) with SMTP id PAA22519 for enum@ietf.org; Tue, 28 Mar 2000 15:12:56 +0900 (JST) X-OpenMail-Hops: 1 Date: Tue, 28 Mar 2000 15:12:50 +0900 Message-Id: In-Reply-To: Subject: Re:RE: [Enum] Overlap dialing, again MIME-Version: 1.0 TO: enum@ietf.org Content-Type: text/plain; charset=ISO-2022-JP 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 Support of overlap sending does not necessarily depend on variable or fixed. Japan has variable-length E.164 numbering plan but does not support overlap sending. Local switches have both a capability to send digits en-bloc when maximum number of digits are dialed, and a timer (about 4 sec). Interworking with overlap-sending countries is also supported at international interface. I still don't know if information about existing PSTN capability helps solution of future issues.... Toshiyuki Tamura to-tamura@kdd.co.jp >E.g. Germany and Austria have variable-length numbers (there may be more such >countries). There, "classical" POTS access equipment MUST support overlap >sending (the only other way would have been to force customers to enter # at the >end of the dialling process, which nobody dared enforce - we are talking about >the dark past). > >Of course, there is also a timeout, but this is quite high (I could find out the >actual value, it should be around 7 sec) and therefore not really useable... > >Michael > >------------------------------------------------------------ >mailto:mwelser@highway.telekom.at Telekom Austria AG > > >> -----Original Message----- >> From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of >> Rosen, Brian >> Sent: Tuesday, March 28, 2000 5:57 AM >> To: 'S(Iv(Jren Nyckelg$BiS(Jd'; enum@ietf.org >> Subject: RE: [Enum] Overlap dialing, again >> >> >> I'm confused about why this issue comes up. >> >> In most systems there is a "dialing plan", which determines >> how many digits to collect. The local system applies >> this dialing plan as the first step. When it discovers >> the terminal digit (by algorithm or timeout), the entire >> result is subjected to routing. The dialed number it is >> NOT submitted, digit by digit, to the call routing >> mechanism. >> >> Why should we should we be trying to change this? >> >> Brian >> >> >> > -----Original Message----- >> > From: S(Iv(Jren Nyckelg$BiS(Jd [mailto:nyckelgard@dof.se] >> > Sent: Monday, June 21, 1999 10:23 AM >> > To: enum@ietf.org >> > Subject: [Enum] Overlap dialing, again >> > >> > >> > At the ENUM meeting in Adelaide, the overlap dialing issue >> > was rised again. >> > The specific issue was that the lenght of the number might >> > not be known by >> > the client, thus forcing the client to query the DNS for >> > every new digit >> > entered by the user. In this case we assume that the call is >> > made from a >> > terminal, like a conventional black phone, that does not require an >> > 'end-of-number' kind of button to be pushed to complete the number. >> > >> > The chairs were not aware of this particular hazle so the >> > suggestion was to >> > bring up the issue on the list again. So, here it comes... >> > >> > Would it be possible for the DNS to, in some way, drop a hint >> > of the length >> > of the number, e.g. exact length or a minimum length, in >> > order to avoid >> > querying the DNS inbetween every digit? >> > >> > >> > / S(Iv(Jren Nyckelg$BiS(Jd, Telia Research >> > >> > >> > >> > >> > _______________________________________________ >> > enum mailing list >> > enum@ietf.org >> > http://www.ietf.org/mailman/listinfo/enum >> > >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> http://www.ietf.org/mailman/listinfo/enum >> > > >_______________________________________________ >enum mailing list >enum@ietf.org >http://www.ietf.org/mailman/listinfo/enum > > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Mar 28 01:29:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08597 for ; Tue, 28 Mar 2000 01:29:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00113; Tue, 28 Mar 2000 01:26:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00084 for ; Tue, 28 Mar 2000 01:26:37 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08526 for ; Tue, 28 Mar 2000 01:28:51 -0500 (EST) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id WAA28567; Mon, 27 Mar 2000 22:24:51 -0800 (PST) From: Bill Manning Message-Id: <200003280624.WAA28567@boreas.isi.edu> Subject: Re: [Enum] Overlap dialing, again To: brosen@fore.com (Rosen, Brian) Date: Mon, 27 Mar 2000 22:24:51 -0800 (PST) Cc: nyckelgard@dof.se (=?iso-8859-1?Q?=27S=F6ren_Nyckelg=E5rd=27?=), enum@ietf.org In-Reply-To: <4FBEA8857476D311A03300204840E1CF6780A7@whq-msgusr-02.fore.com> from "Rosen, Brian" at Mar 27, 2000 10:57:10 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit % % I'm confused about why this issue comes up. % % In most systems there is a "dialing plan", which determines % how many digits to collect. The local system applies % this dialing plan as the first step. When it discovers % the terminal digit (by algorithm or timeout), the entire % result is subjected to routing. The dialed number it is % NOT submitted, digit by digit, to the call routing % mechanism. Most, not all. % Why should we should we be trying to change this? We shouldn't, this is how the DNS works. % Brian % % % > -----Original Message----- % > From: Sören Nyckelgård [mailto:nyckelgard@dof.se] % > Sent: Monday, June 21, 1999 10:23 AM % > To: enum@ietf.org % > Subject: [Enum] Overlap dialing, again % > % > % > At the ENUM meeting in Adelaide, the overlap dialing issue % > was rised again. % > The specific issue was that the lenght of the number might % > not be known by % > the client, thus forcing the client to query the DNS for % > every new digit % > entered by the user. In this case we assume that the call is % > made from a % > terminal, like a conventional black phone, that does not require an % > 'end-of-number' kind of button to be pushed to complete the number. % > % > The chairs were not aware of this particular hazle so the % > suggestion was to % > bring up the issue on the list again. So, here it comes... % > % > Would it be possible for the DNS to, in some way, drop a hint % > of the length % > of the number, e.g. exact length or a minimum length, in % > order to avoid % > querying the DNS inbetween every digit? % > % > % > / Sören Nyckelgård, Telia Research % > % > % > % > % > _______________________________________________ % > 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 % -- --bill _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Mar 28 06:35:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19808 for ; Tue, 28 Mar 2000 06:35:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04226; Tue, 28 Mar 2000 06:32:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04170 for ; Tue, 28 Mar 2000 06:32:09 -0500 (EST) Received: from cqmx.corp.comsat.com (cqmx.corp.comsat.com [134.133.184.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19781; Tue, 28 Mar 2000 06:34:24 -0500 (EST) From: Andrew.Gallant@comsat.com Received: from cqgate6.cmc.comsat.com ([134.133.162.21]) by cqmx.corp.comsat.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Tue, 28 Mar 2000 06:33:05 -0500 Received: from ccMail by cqgate6.cmc.comsat.com (IMA Internet Exchange 3.13) id 00023F93; Tue, 28 Mar 2000 06:38:54 -0500 Mime-Version: 1.0 Date: Tue, 28 Mar 2000 06:26:57 -0500 Message-ID: <00023F93.C22219@comsat.com> To: enum@ietf.org, itu+ietf@ietf.org Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Transfer-Encoding: 7bit Subject: [Enum] NP Info Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit For your information, a text version of the Number Portability Supplement to E.164 is now available at: http://www.itu.int/ITU-T/ip-telecoms/nnar/nnar-number-port-supp.txt -Andy Gallant _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Mar 28 10:00:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21725 for ; Tue, 28 Mar 2000 10:00:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06481; Tue, 28 Mar 2000 09:49:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06453 for ; Tue, 28 Mar 2000 09:49:54 -0500 (EST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21653 for ; Tue, 28 Mar 2000 09:52:08 -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 GAA07341 for ; Tue, 28 Mar 2000 06:51:20 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id GAA11016 for ; Tue, 28 Mar 2000 06:52:08 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Tue, 28 Mar 2000 06:51:56 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 09:51:55 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EEFD@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: =?iso-8859-1?Q?=27S=F6ren_Nyckelg=E5rd=27?= , enum@ietf.org Subject: RE: [Enum] Overlap dialing, again Date: Tue, 28 Mar 2000 09:51:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA06454 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 When does the appliance decide to query the DNS? Does the appliance not have to append the "e164.int" to the phone number before the query is sent? Somehow, doesn't this imply that the complete number has been entered, before the query? Or are you saying that if the user is slow at entering digits, the appliance might send out multiple DNS requests? Interesting twist. Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: Sören Nyckelgård [mailto:nyckelgard@dof.se] > Sent: Monday, June 21, 1999 10:23 AM > To: enum@ietf.org > Subject: [Enum] Overlap dialing, again > > > At the ENUM meeting in Adelaide, the overlap dialing issue > was rised again. > The specific issue was that the lenght of the number might > not be known by > the client, thus forcing the client to query the DNS for > every new digit > entered by the user. In this case we assume that the call is > made from a > terminal, like a conventional black phone, that does not require an > 'end-of-number' kind of button to be pushed to complete the number. > > The chairs were not aware of this particular hazle so the > suggestion was to > bring up the issue on the list again. So, here it comes... > > Would it be possible for the DNS to, in some way, drop a hint > of the length > of the number, e.g. exact length or a minimum length, in > order to avoid > querying the DNS inbetween every digit? _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Mar 28 10:30:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22157 for ; Tue, 28 Mar 2000 10:30:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07074; Tue, 28 Mar 2000 10:27:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07049 for ; Tue, 28 Mar 2000 10:27:05 -0500 (EST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22131 for ; Tue, 28 Mar 2000 10:29:14 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id KAA26895; Tue, 28 Mar 2000 10:28:31 -0500 (EST) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA23756; Tue, 28 Mar 2000 10:26:45 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 10:27:33 -0500 Message-ID: From: "Lind, Steven D, ALARC" To: "'Manfredi, Albert E'" , =?iso-8859-1?Q?=27S=F6ren_Nyckelg=E5rd=27?= , enum@ietf.org Subject: RE: [Enum] Overlap dialing, again Date: Tue, 28 Mar 2000 10:27:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA07050 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit I would assume that "an appliance," smart enough to perform the front end of the enum functionality, would have some sort of local directory function that would already contain the complete E.164 number. A "dumb" terminal, i.e., a plain old telephone, would attach through some network (e.g., the PSTN) to a gateway. The existing dialing plan and associated timeouts would govern the progress of the call to the gateway, where the enum functionality would occur after receiving the complete E.164 number. If there is a dumb phone attached to an IP access network (e.g., cable telephony), then the interface to the IP access network would have to simulate the dialing plan/timeouts existing as general practice or standards within the specific geopolitical area. Steve Lind --------------------------------------------------------------- Steven D. Lind Tel: (973) 236-6787 AT&T Fax: (973) 236-6452 180 Park Ave., Bldg. 2 e-mail: sdlind@att.com Florham Park, NJ 07932 --------------------------------------------------------------- > -----Original Message----- > From: Manfredi, Albert E [SMTP:Albert.Manfredi@PHL.Boeing.com] > Sent: Tuesday, March 28, 2000 9:52 AM > To: 'Sören Nyckelgård'; enum@ietf.org > Subject: RE: [Enum] Overlap dialing, again > > When does the appliance decide to query the DNS? Does the appliance not > have > to append the "e164.int" to the phone number before the query is sent? > Somehow, doesn't this imply that the complete number has been entered, > before the query? > > Or are you saying that if the user is slow at entering digits, the > appliance > might send out multiple DNS requests? Interesting twist. > > Bert > albert.e.manfredi@boeing.com > > > > -----Original Message----- > > From: Sören Nyckelgård [mailto:nyckelgard@dof.se] > > Sent: Monday, June 21, 1999 10:23 AM > > To: enum@ietf.org > > Subject: [Enum] Overlap dialing, again > > > > > > At the ENUM meeting in Adelaide, the overlap dialing issue > > was rised again. > > The specific issue was that the lenght of the number might > > not be known by > > the client, thus forcing the client to query the DNS for > > every new digit > > entered by the user. In this case we assume that the call is > > made from a > > terminal, like a conventional black phone, that does not require an > > 'end-of-number' kind of button to be pushed to complete the number. > > > > The chairs were not aware of this particular hazle so the > > suggestion was to > > bring up the issue on the list again. So, here it comes... > > > > Would it be possible for the DNS to, in some way, drop a hint > > of the length > > of the number, e.g. exact length or a minimum length, in > > order to avoid > > querying the DNS inbetween every digit? > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Mar 28 20:10:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00847 for ; Tue, 28 Mar 2000 20:10:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13596; Tue, 28 Mar 2000 20:07:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13567 for ; Tue, 28 Mar 2000 20:07:20 -0500 (EST) Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00839 for ; Tue, 28 Mar 2000 20:09:34 -0500 (EST) Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id UAA16889 for ; Tue, 28 Mar 2000 20:09:36 -0500 (EST) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id UAA16875; Tue, 28 Mar 2000 20:09:34 -0500 (EST) Received: from buzz.ons.octel.com by ihrh1.emsr.lucent.com (SMI-8.6/EMS-1.5 Solaris/emsr) id TAA12861 for ; Tue, 28 Mar 2000 19:09:29 -0600 Received: from exdal1.ons.octel.com (exdal1 [155.184.13.201]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id TAA19947; Tue, 28 Mar 2000 19:09:29 -0600 (CST) Received: by exdal1.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 28 Mar 2000 19:08:24 -0600 Message-ID: <6B57F36F4FF9D111B30A0008C7F413370370446E@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: "Lind, Steven D, ALARC" , "'Manfredi, Albert E'" , =?iso-8859-1?Q?=27S=F6ren_Nyckelg=E5?= =?iso-8859-1?Q?rd=27?= , enum@ietf.org Subject: RE: [Enum] Overlap dialing, again Date: Tue, 28 Mar 2000 19:08:22 -0600 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 UAA13568 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 In the GSTN, most switches support two types of digit analysis, I will call them deterministic and non-deterministic. For the local/in-country dial plan, the switch has a list of valid prefixes, the expected number of digits to collect, and any digit translations necessary to "fully qualify" the number. This table maps from the dialed number (such as a private dial plan) into a unique national/international number. This prefix list varies switch-to-switch (and often within a switch) based on the local dialing plan in effect for the caller. With this list, a number can be determined to be invalid before all the digits are entered. For out-of-country telephone numbers, an international escape code is dialed which simply informs the switch that the local digit analysis rules do not apply. The switch then collects digits until either a time-out or a pounds termination is dialed. In Internet space, it is somewhat unreasonable for end-node clients to independently administer a local copy of the often-changing national dialing plan. Further, I suggest that dialing-time, digit-by-digit validation over a network protocol will be excessively taxing on both the server and the client. I definitely recommend against using DNS to provide this function. If local dial-plans must be supported, either to eliminate the time-out or pre-validate a dialed number, they should be provided by the local client, using a standardized and downloadable digit-analysis configuration file (such as a web proxy list). Greg V. -----Original Message----- From: Lind, Steven D, ALARC [mailto:sdlind@att.com] Sent: Tuesday, March 28, 2000 9:27 AM To: 'Manfredi, Albert E'; 'Sören Nyckelgård'; enum@ietf.org Subject: RE: [Enum] Overlap dialing, again I would assume that "an appliance," smart enough to perform the front end of the enum functionality, would have some sort of local directory function that would already contain the complete E.164 number. A "dumb" terminal, i.e., a plain old telephone, would attach through some network (e.g., the PSTN) to a gateway. The existing dialing plan and associated timeouts would govern the progress of the call to the gateway, where the enum functionality would occur after receiving the complete E.164 number. If there is a dumb phone attached to an IP access network (e.g., cable telephony), then the interface to the IP access network would have to simulate the dialing plan/timeouts existing as general practice or standards within the specific geopolitical area. Steve Lind --------------------------------------------------------------- Steven D. Lind Tel: (973) 236-6787 AT&T Fax: (973) 236-6452 180 Park Ave., Bldg. 2 e-mail: sdlind@att.com Florham Park, NJ 07932 --------------------------------------------------------------- > -----Original Message----- > From: Manfredi, Albert E [SMTP:Albert.Manfredi@PHL.Boeing.com] > Sent: Tuesday, March 28, 2000 9:52 AM > To: 'Sören Nyckelgård'; enum@ietf.org > Subject: RE: [Enum] Overlap dialing, again > > When does the appliance decide to query the DNS? Does the appliance not > have > to append the "e164.int" to the phone number before the query is sent? > Somehow, doesn't this imply that the complete number has been entered, > before the query? > > Or are you saying that if the user is slow at entering digits, the > appliance > might send out multiple DNS requests? Interesting twist. > > Bert > albert.e.manfredi@boeing.com > > > > -----Original Message----- > > From: Sören Nyckelgård [mailto:nyckelgard@dof.se] > > Sent: Monday, June 21, 1999 10:23 AM > > To: enum@ietf.org > > Subject: [Enum] Overlap dialing, again > > > > > > At the ENUM meeting in Adelaide, the overlap dialing issue > > was rised again. > > The specific issue was that the lenght of the number might > > not be known by > > the client, thus forcing the client to query the DNS for > > every new digit > > entered by the user. In this case we assume that the call is > > made from a > > terminal, like a conventional black phone, that does not require an > > 'end-of-number' kind of button to be pushed to complete the number. > > > > The chairs were not aware of this particular hazle so the > > suggestion was to > > bring up the issue on the list again. So, here it comes... > > > > Would it be possible for the DNS to, in some way, drop a hint > > of the length > > of the number, e.g. exact length or a minimum length, in > > order to avoid > > querying the DNS inbetween every digit? > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Mar 29 10:03:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21660 for ; Wed, 29 Mar 2000 10:03:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26623; Wed, 29 Mar 2000 09:58:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26592 for ; Wed, 29 Mar 2000 09:58:43 -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 KAA21583 for ; Wed, 29 Mar 2000 10:00:59 -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 JAA25443 for ; Wed, 29 Mar 2000 09:00:55 -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 JAA12597 for ; Wed, 29 Mar 2000 09:00:55 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Wed, 29 Mar 2000 09:00:42 -0600 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Mar 2000 10:00:41 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EF04@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Vaudreuil, Greg M (Greg)'" , enum@ietf.org Subject: RE: [Enum] Overlap dialing, again Date: Wed, 29 Mar 2000 10:00:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA26593 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 FWIW, I completely agree with Greg. Also, in any DNS query situation involving enum, whatever appliance or server is making this query must know to append the "e164.int" domain to the number anyway, as this scheme being defined in this wg. Therefore, the appliance or server _must_ be smart enough to know when the e.164 number is complete. Or at least, this appliance/server must make a guess as to when the e.164 number being queried is complete, even if in reality it isn't, and the query will end up with an error message. For example, in a cell phone, one typically has to push the "send" button after having entered the telephone number. I think that it isn't too much to ask that the appliance which is using enum has this same sort of functionality? Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: Vaudreuil, Greg M (Greg) [mailto:gregv@lucent.com] > Sent: Tuesday, March 28, 2000 8:08 PM > To: Lind, Steven D, ALARC; 'Manfredi, Albert E'; 'Sören Nyckelgård'; > enum@ietf.org > Subject: RE: [Enum] Overlap dialing, again > > > > In the GSTN, most switches support two types of digit > analysis, I will call > them deterministic and non-deterministic. For the > local/in-country dial > plan, the switch has a list of valid prefixes, the expected > number of digits > to collect, and any digit translations necessary to "fully > qualify" the > number. This table maps from the dialed number (such as a > private dial > plan) into a unique national/international number. This > prefix list varies > switch-to-switch (and often within a switch) based on the > local dialing plan > in effect for the caller. With this list, a number can be > determined to be > invalid before all the digits are entered. > > For out-of-country telephone numbers, an international escape > code is dialed > which simply informs the switch that the local digit analysis > rules do not > apply. The switch then collects digits until either a > time-out or a pounds > termination is dialed. > > In Internet space, it is somewhat unreasonable for end-node clients to > independently administer a local copy of the often-changing > national dialing > plan. Further, I suggest that dialing-time, digit-by-digit > validation over > a network protocol will be excessively taxing on both the > server and the > client. I definitely recommend against using DNS to provide > this function. > If local dial-plans must be supported, either to eliminate > the time-out or > pre-validate a dialed number, they should be provided by the > local client, > using a standardized and downloadable digit-analysis > configuration file > (such as a web proxy list). > > Greg V. > > -----Original Message----- > From: Lind, Steven D, ALARC [mailto:sdlind@att.com] > Sent: Tuesday, March 28, 2000 9:27 AM > To: 'Manfredi, Albert E'; 'Sören Nyckelgård'; enum@ietf.org > Subject: RE: [Enum] Overlap dialing, again > > > I would assume that "an appliance," smart enough to perform > the front end of > the enum functionality, would have some sort of local > directory function > that would already contain the complete E.164 number. A > "dumb" terminal, > i.e., a plain old telephone, would attach through some > network (e.g., the > PSTN) to a gateway. The existing dialing plan and associated > timeouts would > govern the progress of the call to the gateway, where the > enum functionality > would occur after receiving the complete E.164 number. > > If there is a dumb phone attached to an IP access network (e.g., cable > telephony), then the interface to the IP access network would have to > simulate the dialing plan/timeouts existing as general > practice or standards > within the specific geopolitical area. > > Steve Lind > > > --------------------------------------------------------------- > Steven D. Lind Tel: (973) 236-6787 > AT&T Fax: (973) 236-6452 > 180 Park Ave., Bldg. 2 e-mail: sdlind@att.com > Florham Park, NJ 07932 > --------------------------------------------------------------- > > > > -----Original Message----- > > From: Manfredi, Albert E [SMTP:Albert.Manfredi@PHL.Boeing.com] > > Sent: Tuesday, March 28, 2000 9:52 AM > > To: 'Sören Nyckelgård'; enum@ietf.org > > Subject: RE: [Enum] Overlap dialing, again > > > > When does the appliance decide to query the DNS? Does the > appliance not > > have > > to append the "e164.int" to the phone number before the > query is sent? > > Somehow, doesn't this imply that the complete number has > been entered, > > before the query? > > > > Or are you saying that if the user is slow at entering digits, the > > appliance > > might send out multiple DNS requests? Interesting twist. > > > > Bert > > albert.e.manfredi@boeing.com > > > > > > > -----Original Message----- > > > From: Sören Nyckelgård [mailto:nyckelgard@dof.se] > > > Sent: Monday, June 21, 1999 10:23 AM > > > To: enum@ietf.org > > > Subject: [Enum] Overlap dialing, again > > > > > > > > > At the ENUM meeting in Adelaide, the overlap dialing issue > > > was rised again. > > > The specific issue was that the lenght of the number might > > > not be known by > > > the client, thus forcing the client to query the DNS for > > > every new digit > > > entered by the user. In this case we assume that the call is > > > made from a > > > terminal, like a conventional black phone, that does not > require an > > > 'end-of-number' kind of button to be pushed to complete > the number. > > > > > > The chairs were not aware of this particular hazle so the > > > suggestion was to > > > bring up the issue on the list again. So, here it comes... > > > > > > Would it be possible for the DNS to, in some way, drop a hint > > > of the length > > > of the number, e.g. exact length or a minimum length, in > > > order to avoid > > > querying the DNS inbetween every digit? > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > http://www.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Mar 29 14:00:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23508 for ; Wed, 29 Mar 2000 14:00:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29467; Wed, 29 Mar 2000 13:57:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29438 for ; Wed, 29 Mar 2000 13:56:59 -0500 (EST) Received: from msglite.sun.telia.se (kerlite2.sun.telia.se [193.44.164.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23497 for ; Wed, 29 Mar 2000 13:59:15 -0500 (EST) Received: from TRAB2054 (WYBH-T-002-p-140-83.tmns.net.au [139.134.140.83]) by msglite.sun.telia.se (8.9.3/8.9.3) with SMTP id UAA15403; Wed, 29 Mar 2000 20:57:49 +0200 (MET DST) Message-ID: <001b01bebd4b$68312280$538c868b@trab.se> From: =?iso-8859-1?B?U/ZyZW4gTnlja2VsZ+VyZA==?= To: "Manfredi, Albert E" , "'Vaudreuil, Greg M (Greg)'" , References: <4102273CEB77D211869200805FE6F59356EF04@xch-phl-01.he.boeing.com> Subject: Re: [Enum] Overlap dialing, again Date: Wed, 23 Jun 1999 09:38:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 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 Firtst of all, I'd like to clarify that I'm not in favour of adding any functions to the DNS that are not already there. I just want to address the issue of the client knowing or not knowing the length of the number. Some countries/regions have fixed number lengths, some have number series depending number length and yet others have variable number length. Okey, if the number length is not fixed, some contries/regions generally accept inter-digit timeout as the mechanism to determine 'end-of-number', others only accept that mechanism for international calls. In the latter case, customers are customed to get a ringtone immediately after they type the last digit when they make local or national calls. In this case, callers generally don't accept any noticable post-dial delay. Ann inter-digit time-out mechanism is hence not acceptable here. This is, in fact the situation in Sweden and several other countries. There are several ways for a client, local exchange, PBX, etc. to determine the length of a local or national number. A table with number series / number length tuples is one way of doing it, as long as there are means to keep the table dynamically updated, which unfortunately is rarely the case. Number lengths are being canged rather frequently in some countries/regions due to lack of telephone numbers. Since updating of routing tables and number analysis functions in all nodes is a time-consuming process, a mechanism commonly applied is based on the knowledge of a 'minimum length' for the number series in concern, i.e. the routing table or number analysis function can at least determine the minimum length of the number. What happens when a call is made is that the node will collect digits until the minimum length has been reached and then call the next node. If no 'address complete' message is immediately returned, then the sending node will assume a transparent mode, passing on all succeding digits received from the user until it finally gets an 'address complete' message in return. I just want to establish the fact that in several cases, the client, local exchange, PBX, etc. will be unaware of the exact length of the number and hence forced to repetedly query the DNS until the desired response is received. Maybe later on we should address the number lengt issue again in order to find ways to distribute number lengh information but I don't consider this to be an issue for the ENUM WG. Cheers, Sören --------------------------------------- Sören Nyckelgård, Telia Research AB soren.m.nyckelgard@telia.se --------------------------------------- ----- Original Message ----- From: Manfredi, Albert E To: 'Vaudreuil, Greg M (Greg)' ; Sent: Wednesday, March 29, 2000 5:00 PM Subject: RE: [Enum] Overlap dialing, again > > > > ---------- > > From: Manfredi, Albert E[SMTP:ALBERT.MANFREDI@PHL.BOEING.COM] > > Sent: Wednesday, March 29, 2000 5:00:41 PM > > To: 'Vaudreuil, Greg M (Greg)'; enum@ietf.org > > Subject: RE: [Enum] Overlap dialing, again > > Auto forwarded by a Rule > > > FWIW, I completely agree with Greg. Also, in any DNS query situation > involving enum, whatever appliance or server is making this query must know > to append the "e164.int" domain to the number anyway, as this scheme being > defined in this wg. Therefore, the appliance or server _must_ be smart > enough to know when the e.164 number is complete. > > Or at least, this appliance/server must make a guess as to when the e.164 > number being queried is complete, even if in reality it isn't, and the query > will end up with an error message. > > For example, in a cell phone, one typically has to push the "send" button > after having entered the telephone number. I think that it isn't too much to > ask that the appliance which is using enum has this same sort of > functionality? > > Bert > albert.e.manfredi@boeing.com > > > > -----Original Message----- > > From: Vaudreuil, Greg M (Greg) [mailto:gregv@lucent.com] > > Sent: Tuesday, March 28, 2000 8:08 PM > > To: Lind, Steven D, ALARC; 'Manfredi, Albert E'; 'Sören Nyckelgård'; > > enum@ietf.org > > Subject: RE: [Enum] Overlap dialing, again > > > > > > > > In the GSTN, most switches support two types of digit > > analysis, I will call > > them deterministic and non-deterministic. For the > > local/in-country dial > > plan, the switch has a list of valid prefixes, the expected > > number of digits > > to collect, and any digit translations necessary to "fully > > qualify" the > > number. This table maps from the dialed number (such as a > > private dial > > plan) into a unique national/international number. This > > prefix list varies > > switch-to-switch (and often within a switch) based on the > > local dialing plan > > in effect for the caller. With this list, a number can be > > determined to be > > invalid before all the digits are entered. > > > > For out-of-country telephone numbers, an international escape > > code is dialed > > which simply informs the switch that the local digit analysis > > rules do not > > apply. The switch then collects digits until either a > > time-out or a pounds > > termination is dialed. > > > > In Internet space, it is somewhat unreasonable for end-node clients to > > independently administer a local copy of the often-changing > > national dialing > > plan. Further, I suggest that dialing-time, digit-by-digit > > validation over > > a network protocol will be excessively taxing on both the > > server and the > > client. I definitely recommend against using DNS to provide > > this function. > > If local dial-plans must be supported, either to eliminate > > the time-out or > > pre-validate a dialed number, they should be provided by the > > local client, > > using a standardized and downloadable digit-analysis > > configuration file > > (such as a web proxy list). > > > > Greg V. > > > > -----Original Message----- > > From: Lind, Steven D, ALARC [mailto:sdlind@att.com] > > Sent: Tuesday, March 28, 2000 9:27 AM > > To: 'Manfredi, Albert E'; 'Sören Nyckelgård'; enum@ietf.org > > Subject: RE: [Enum] Overlap dialing, again > > > > > > I would assume that "an appliance," smart enough to perform > > the front end of > > the enum functionality, would have some sort of local > > directory function > > that would already contain the complete E.164 number. A > > "dumb" terminal, > > i.e., a plain old telephone, would attach through some > > network (e.g., the > > PSTN) to a gateway. The existing dialing plan and associated > > timeouts would > > govern the progress of the call to the gateway, where the > > enum functionality > > would occur after receiving the complete E.164 number. > > > > If there is a dumb phone attached to an IP access network (e.g., cable > > telephony), then the interface to the IP access network would have to > > simulate the dialing plan/timeouts existing as general > > practice or standards > > within the specific geopolitical area. > > > > Steve Lind > > > > > > --------------------------------------------------------------- > > Steven D. Lind Tel: (973) 236-6787 > > AT&T Fax: (973) 236-6452 > > 180 Park Ave., Bldg. 2 e-mail: sdlind@att.com > > Florham Park, NJ 07932 > > --------------------------------------------------------------- > > > > > > > -----Original Message----- > > > From: Manfredi, Albert E [SMTP:Albert.Manfredi@PHL.Boeing.com] > > > Sent: Tuesday, March 28, 2000 9:52 AM > > > To: 'Sören Nyckelgård'; enum@ietf.org > > > Subject: RE: [Enum] Overlap dialing, again > > > > > > When does the appliance decide to query the DNS? Does the > > appliance not > > > have > > > to append the "e164.int" to the phone number before the > > query is sent? > > > Somehow, doesn't this imply that the complete number has > > been entered, > > > before the query? > > > > > > Or are you saying that if the user is slow at entering digits, the > > > appliance > > > might send out multiple DNS requests? Interesting twist. > > > > > > Bert > > > albert.e.manfredi@boeing.com > > > > > > > > > > -----Original Message----- > > > > From: Sören Nyckelgård [mailto:nyckelgard@dof.se] > > > > Sent: Monday, June 21, 1999 10:23 AM > > > > To: enum@ietf.org > > > > Subject: [Enum] Overlap dialing, again > > > > > > > > > > > > At the ENUM meeting in Adelaide, the overlap dialing issue > > > > was rised again. > > > > The specific issue was that the lenght of the number might > > > > not be known by > > > > the client, thus forcing the client to query the DNS for > > > > every new digit > > > > entered by the user. In this case we assume that the call is > > > > made from a > > > > terminal, like a conventional black phone, that does not > > require an > > > > 'end-of-number' kind of button to be pushed to complete > > the number. > > > > > > > > The chairs were not aware of this particular hazle so the > > > > suggestion was to > > > > bring up the issue on the list again. So, here it comes... > > > > > > > > Would it be possible for the DNS to, in some way, drop a hint > > > > of the length > > > > of the number, e.g. exact length or a minimum length, in > > > > order to avoid > > > > querying the DNS inbetween every digit? > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > http://www.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > http://www.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Mar 29 20:36:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26815 for ; Wed, 29 Mar 2000 20:36:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03197; Wed, 29 Mar 2000 20:33:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03169 for ; Wed, 29 Mar 2000 20:33:48 -0500 (EST) Received: from evds.voicedomain (www.evds.com [208.146.135.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26812 for ; Wed, 29 Mar 2000 20:36:04 -0500 (EST) Received: from dpeek ([208.146.135.250]) by evds.voicedomain (Netscape Messaging Server 3.62) with SMTP id 466 for ; Wed, 29 Mar 2000 20:34:28 -0500 From: "David P. Peek" To: Subject: [ENUM] NAPTR record Date: Wed, 29 Mar 2000 18:47:49 -0600 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 V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Hello Enum, It has been brought to my attention that the NAPTR replacement field may only allow fully qualified domain names. (?) After re-reading RFC 2168 I only see references to the replacement field as a domain name and it wasn't clear that the replacement field could be used in this manner. Can anyone help me to confirm that the replacement field can be used to store information other then a FQDN? Has anyone tried to request NAPTR records with this type of data stored in the replacement field? Thanks- dp _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Mar 30 17:34:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22706 for ; Thu, 30 Mar 2000 17:34:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25119; Thu, 30 Mar 2000 17:30:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25090 for ; Thu, 30 Mar 2000 17:30:43 -0500 (EST) Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22670 for ; Thu, 30 Mar 2000 17:32:58 -0500 (EST) Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA29009 for ; Thu, 30 Mar 2000 17:33:00 -0500 (EST) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id RAA28967; Thu, 30 Mar 2000 17:32:58 -0500 (EST) Received: from buzz.ons.octel.com by ihrh1.emsr.lucent.com (SMI-8.6/EMS-1.5 Solaris/emsr) id QAA22210 for ; Thu, 30 Mar 2000 16:32:56 -0600 Received: from exdal1.ons.octel.com (exdal1 [155.184.13.201]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id QAA02937; Thu, 30 Mar 2000 16:32:56 -0600 (CST) Received: by exdal1.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 30 Mar 2000 16:31:36 -0600 Message-ID: <6B57F36F4FF9D111B30A0008C7F41337037044CB@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: =?iso-8859-1?Q?S=F6ren_Nyckelg=E5rd?= , "Manfredi, Albert E" , "'Vaudreuil, Greg M (Greg)'" , enum@ietf.org Subject: RE: [Enum] Overlap dialing, again Date: Thu, 30 Mar 2000 16:31:34 -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 It is important to note that the determination of digit length is application specific. What is fixed-length in PSTN calling is not necessarily so in telephone addressed messaging. In the telephone network, the E.164 sub-address is not generally dialed. The E.164 sub-address is variable length from 0-4 digits in addition to the directory number. In PSTN calling, extension numbers are generally entered after connecting to an automated (or given to a human) attendent. For store-and-forward telephone addressed messaging application, the ability to use an automated attendent to route is not possible. The sub-address can identify the messaging recipient in a corporation by an extension number behind a single main number. This is a critical requirement where direct inward dial numbers are not assigned to all employees reachable behind the main number. Similarly, in residential usage, it is common to assign sub-mailboxes for each resident of a given household. Greg V. _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum