From mailnull@www1.ietf.org Sun Sep 1 05:35:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11304 for ; Sun, 1 Sep 2002 05:35:58 -0400 (EDT) From: mailnull@www1.ietf.org Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g819b0N13041 for enum-archive@odin.ietf.org; Sun, 1 Sep 2002 05:37:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g819b0o13038 for ; Sun, 1 Sep 2002 05:37:00 -0400 Date: Sun, 01 Sep 2002 05:37:00 -0400 Message-ID: <20020901093700.1916.61517.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder To: enum-web-archive@www.ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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@. Thanks! Passwords for enum-web-archive@www.ietf.org: List Password // URL ---- -------- enum@ietf.org i7hy https://www1.ietf.org/mailman/options/enum/enum-web-archive%40www.ietf.org From mailnull@www1.ietf.org Sun Sep 1 14:33:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25654 for ; Sun, 1 Sep 2002 14:33:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g81IZ5i03924 for enum-archive@odin.ietf.org; Sun, 1 Sep 2002 14:35:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81IYvo03915; Sun, 1 Sep 2002 14:34:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81IVOo03815 for ; Sun, 1 Sep 2002 14:31:24 -0400 Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25600 for ; Sun, 1 Sep 2002 14:29:42 -0400 (EDT) Received: from lawrence.srmr.co.uk ([193.118.192.111] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 5148u via TCP with SMTP; Sun, 01 Sep 2002 19:31:10 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Sun, 1 Sep 2002 19:31:05 +0100 To: enum@ietf.org From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] D3S details... Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Folks, a couple of clarifications on D3S//ENUM operation would be much appreciated. * For D3S operation with non-terminal NAPTRs, there's an empty flags field and a non-empty replacement domain field on the end. [[Usually, but see my posts on "enum:" and the alternative "tel:" 'enum=yes']] For the NAPTR to be considered it has to have some code in its service field to indicate the "D3S Application" (such as "E2U"). I have *ASSUMED* that this application doesn't change across a domain replacement, so that the "next" NAPTR in the chain should ALSO have the same "D3S Application" tag. However, where is this stated? (or am I wrong). * for a non-terminal, I have further *ASSUMED* that there is always a non-empty services field (i.e. one containing some enumservice tag or tags). Is this correct? I suspect that others will also find this interesting when they have to define corner test cases :) all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sun Sep 1 14:45:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25817 for ; Sun, 1 Sep 2002 14:45:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g81Il7o04782 for enum-archive@odin.ietf.org; Sun, 1 Sep 2002 14:47:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81Il5o04777; Sun, 1 Sep 2002 14:47:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81Iiho04705 for ; Sun, 1 Sep 2002 14:44:43 -0400 Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25782 for ; Sun, 1 Sep 2002 14:43:04 -0400 (EDT) Received: from lawrence.srmr.co.uk ([193.118.192.111] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 5155u via TCP with SMTP; Sun, 01 Sep 2002 19:44:31 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <15589567.1028193078@localhost> References: <15589567.1028193078@localhost> Date: Sun, 1 Sep 2002 19:44:22 +0100 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Rich From: Lawrence Conroy Subject: Re: [Enum] enum uri considered harmful? Cc: enum@ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g81Iiho04706 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit At 9:11 am +0200 1/8/02, Patrik Fältström wrote: >--On 2002-07-30 16.54 +0100 Lawrence Conroy wrote: > >> Well...Unless someone can give answers to these points, >> I am not happy with this - IMHO enum: is not the same as >> tel: ; enum=yes. > >And default is enum=yes I presume. Else we will not be able to start use >ENUM for existing tel: URI's out there. > > paf Hi again Patrik, Rich, folks, (sorry about the delayed response). As mentioned in my earlier post in this thread, that's my concern. -We- have two existing "tel:" URI processors, neither of which do enum lookups. I believe that Brett and the mob at Broadsoft have another one that also doesn't do enum lookups either. Thus, for -at least- two existing implementations, the default acts as if ';ENUM=NO'. This is not the same as James' URI parameters - you can be justified in believing that the clients connected to "infrastructure ENUM" processing these "tel:" URIs are new clients, and can handle the CIC/RN parameters. We're not so lucky with "basic" "tel:" clients "out there in the wild". That's one big reason for my worry - we won't even try an enum lookup with these existing clients, and there's no way to guess in advance what someone has sitting on their machine (unless there's yet another security hole in a certain manufacturer's OS and Web Browser :). Thus, I still think that we need an "enum:" URI. What am I missing? all the best, Lawreence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sun Sep 1 15:18:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26644 for ; Sun, 1 Sep 2002 15:18:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g81JJtc06232 for enum-archive@odin.ietf.org; Sun, 1 Sep 2002 15:19:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81JJro06227; Sun, 1 Sep 2002 15:19:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81JGXo06078 for ; Sun, 1 Sep 2002 15:16:33 -0400 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26551 for ; Sun, 1 Sep 2002 15:14:54 -0400 (EDT) Received: from xbe-lon-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g81JEsDs027857; Sun, 1 Sep 2002 21:14:55 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 1 Sep 2002 20:15:53 +0100 Received: from [192.168.1.9] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 1 Sep 2002 21:15:52 +0200 Date: Sun, 01 Sep 2002 21:13:49 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy , Rich cc: enum@ietf.org Subject: Re: [Enum] enum uri considered harmful? Message-ID: <35986814.1030914829@localhost> In-Reply-To: References: <15589567.1028193078@localhost> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 01 Sep 2002 19:15:53.0058 (UTC) FILETIME=[FD6A9420:01C251EB] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On 2002-09-01 19.44 +0100 Lawrence Conroy wrote: > That's one big reason for my worry - we won't even try an enum lookup > with these existing clients, and there's no way to guess in advance what > someone has sitting on their machine (unless there's yet another security > hole in a certain manufacturer's OS and Web Browser :). > > Thus, I still think that we need an "enum:" URI. What am I missing? That today ENUM lookup can be injected in the processing of an E.164 number at whatever node in the network which have that intelligence. I know of several implementations of IN nodes which look at starting doing ENUM lookups, and several SIP proxies and various gateways between PSTN and Internet which also do ENUM lookups. If a specific node which gets a destination in the form of E.164 number doesn't do ENUM processing, it will forward the call towards the destination according to whatever the E.164 routing says. Finally, the number will reach the "destination" and a clever holder of E.164 numbers (organisation which allocated the number in the first place) route the call to some IN node which _can_ do ENUM lookup. I.e. default for E.164 processing is to do ENUM. Saying in a tel URI that you do _not_ allow ENUM lookup is an exception to the standard mechanism and a hint to the processing. My view is that you still can not prohibit anyone from doing ENUM processing (especially when you start signalling using SS7 or whatever other protocol which can not forward the "no" message, only the E.164 number. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 2 03:46:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15849 for ; Mon, 2 Sep 2002 03:46:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g827lOT16893 for enum-archive@odin.ietf.org; Mon, 2 Sep 2002 03:47:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g827lFo16882; Mon, 2 Sep 2002 03:47:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g827fTo16708 for ; Mon, 2 Sep 2002 03:41:29 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15787 for ; Mon, 2 Sep 2002 03:39:43 -0400 (EDT) Subject: RE: [Enum] enum uri considered harmful? Date: Mon, 2 Sep 2002 09:43:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <06CF906FE3998C4E944213062009F162024753@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [Enum] enum uri considered harmful? Thread-Index: AcJR7V7QWOtxJgf/QOqj41X0jpSobAAXg37Q From: "Stastny Richard" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Lawrence Conroy" , "Rich" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g827fTo16709 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit My dear Patrik, I think your are on the wrong steamboat oops track ;-) > I.e. default for E.164 processing is to do ENUM. This is definetely NOT true for "User ENUM" in e164.arpa, although it will be true for "infrastructure ENUM" in another tree (see draft-stastny-enum-scenarios-00.txt). But there was not very much interest in the last IETF on this isssue :-( This is for two reasons: 1. ENUM in e164.arpa is opt-in for end-users (for the called AND and also for the calling user) 2. Currently there is not a single user in ENUM, one can expect maybe 5-10% within the next 2 years. Remark: The opt-in for the calling user implies, that it is up to the calling user if a query to "User ENUM" is made (either call-by-call or preselect similar to carrier selection). So it will NOT be possible to make an "User ENUM" query during the call-setup in any node as you assumed without the calling user knowing this. The only exception may be ENUM-only E.164 numbers, which has not been determined yet. What you are proposing in a kind of ACQ for at least a part of the number ranges at the destination. This does only make sense if all or at least the majority of the numbers in question is in ENUM. In "User ENUM" it will be never be possible to have all or even the majority of the numbers in ENUM for the above mentioned reason. This will only be possible in "Infrastructure ENUM" in an independant second golden tree, because there is no opt-in, so ALL numbers can be available for query on the service providers discretion. The second tree is also required if a number is inserted by a service provider for infrastructure reason and from the end-user itself. Since the end-user is able to select his own Tier 2 Nameserver Provider in all current administrative models, you get a clash here. Back to the enum URI: It is obvious, that the majority of entries in the "infrastructure ENUM" tree will contain tel URIs as defined by the James Yu draft. (RN, CIC, etc). Other types of URI may come later. The enum URI serves completely different purposes, it is IMHO mainly there for two reasons: 1. To allow the proud new ENUM customer to brag on his webpage and his e-mail signature to his friends and colleagues that he is really in the new cool service ENUM. This will also be a nice device to raise the awareness on ENUM. We will have to market and to sell ENUM and this will help. 2. to provide (again for the ENUM end-user) a simple tool to redirect one E.164 number completely with all entries to another E.164 number, without having to use constructs like CNAME. Best regards Richard Richard STASTNY OeFEG/Telekom Austria Box 147, A-1103 Vienna, Austria tel:+43 664 420 4100 fax:+43 1 797 80 13 mailto:richard.stastny@oefeg.at > -----Original Message----- > From: Patrik Fältström [mailto:paf@cisco.com] > Sent: Sunday, September 01, 2002 9:14 PM > To: Lawrence Conroy; Rich > Cc: enum@ietf.org > Subject: Re: [Enum] enum uri considered harmful? > > > --On 2002-09-01 19.44 +0100 Lawrence Conroy wrote: > > > That's one big reason for my worry - we won't even try an > enum lookup > > with these existing clients, and there's no way to guess in advance > > what someone has sitting on their machine (unless there's > yet another > > security hole in a certain manufacturer's OS and Web Browser :). > > > > Thus, I still think that we need an "enum:" URI. What am I missing? > > That today ENUM lookup can be injected in the processing of > an E.164 number at whatever node in the network which have > that intelligence. I know of several implementations of IN > nodes which look at starting doing ENUM lookups, and several > SIP proxies and various gateways between PSTN and Internet > which also do ENUM lookups. > > If a specific node which gets a destination in the form of > E.164 number doesn't do ENUM processing, it will forward the > call towards the destination according to whatever the E.164 > routing says. > > Finally, the number will reach the "destination" and a clever > holder of E.164 numbers (organisation which allocated the > number in the first place) route the call to some IN node > which _can_ do ENUM lookup. > > I.e. default for E.164 processing is to do ENUM. > > Saying in a tel URI that you do _not_ allow ENUM lookup is an > exception to the standard mechanism and a hint to the > processing. My view is that you still can not prohibit anyone > from doing ENUM processing (especially when you start > signalling using SS7 or whatever other protocol which can not > forward the "no" message, only the E.164 number. > > paf > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 2 04:13:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16458 for ; Mon, 2 Sep 2002 04:13:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g828EZY19098 for enum-archive@odin.ietf.org; Mon, 2 Sep 2002 04:14:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g828EXo19092; Mon, 2 Sep 2002 04:14:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g828BHo18972 for ; Mon, 2 Sep 2002 04:11:17 -0400 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16359 for ; Mon, 2 Sep 2002 04:09:33 -0400 (EDT) Received: from xbe-lon-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8288Y1i013864; Mon, 2 Sep 2002 10:09:35 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 2 Sep 2002 09:10:04 +0100 Received: from [192.168.1.9] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 2 Sep 2002 10:10:03 +0200 Date: Mon, 02 Sep 2002 10:08:50 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Stastny Richard , Lawrence Conroy , Rich cc: enum@ietf.org Subject: RE: [Enum] enum uri considered harmful? Message-ID: <38777010.1030961330@localhost> In-Reply-To: <06CF906FE3998C4E944213062009F162024753@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F162024753@oefeg-s02.oefeg.loc> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 02 Sep 2002 08:10:03.0945 (UTC) FILETIME=[244D7190:01C25258] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On 2002-09-02 09.43 +0200 Stastny Richard wrote: > My dear Patrik, > > I think your are on the wrong steamboat oops track ;-) Possibly. >> I.e. default for E.164 processing is to do ENUM. > > This is definetely NOT true for "User ENUM" in e164.arpa, although it > will be true for "infrastructure ENUM" in another tree (see > draft-stastny-enum-scenarios-00.txt). But there was not very much > interest in the last IETF on this isssue :-( The discussion was about the processing of an E.164 number, not about the registration process. > This is for two reasons: > > 1. ENUM in e164.arpa is opt-in for end-users (for the called AND and also > for the calling user) No, not for the calling user. The calling user can not tell all involved parties what kind of databases should be used during call setup. That is already the case today, and will be also with ENUM. There is no way I can tell the telcos whether they should use Informix or just MySQL databases in their IN systems, whether number portability should be used, whether call forwarding should be used or not. That is a decision of the called party, and the calling party is only requesting the call to go to the destination addressed by the E.164 number. The opt-in which has been discussed around ENUM is only about the called party. Whether a specific E.164 number should exists in DNS or not. > 2. Currently there is not a single user in ENUM, > one can expect maybe 5-10% within the next 2 years. I don't understand what this has to do with this discussion. > Remark: The opt-in for the calling user implies, that it is up to the > calling user if a query to "User ENUM" is made (either call-by-call or > preselect similar to carrier selection). So it will NOT be possible to > make an "User ENUM" query during the call-setup in any node as you > assumed without the calling user knowing this. The only exception may be > ENUM-only E.164 numbers, which has not been determined yet. See above. There is no opt-in for the calling user. > What you are proposing in a kind of ACQ for at least a part of the number > ranges at the destination. This does only make sense if all or at least > the majority of the numbers in question is in ENUM. I don't agree at all. > In "User ENUM" it will be never be possible to have all or even the > majority of the numbers in ENUM for the above mentioned reason. This will > only be possible in "Infrastructure ENUM" in an independant second golden > tree, because there is no opt-in, so ALL numbers can be available for > query on the service providers discretion. NXDOMAIN is a perfectly good response from DNS. The only difference between "User ENUM" and "Infrastucture ENUM" I have seen so far (except this mail) is whether a telco is allowed to store _some_ information in DNS by default, and that only some (but the majority) information (like email address, or other kind of URI schemes beside tel:), falls under the opt-in rule. A separate tree for people which agree on what that tree is have nothing to do with that discussion. It is orthogonal. > The second tree is also required if a number is inserted by a service > provider for infrastructure reason and from the end-user itself. Since > the end-user is able to select his own Tier 2 Nameserver Provider in all > current administrative models, you get a clash here. You mix up the selection of DNS provider for the NAPTR record and the telco owning the E.164 number. Those are two different entities, and doesn't have anything to do with each other. > Back to the enum URI: > > It is obvious, that the majority of entries in the "infrastructure ENUM" > tree will contain tel URIs as defined by the James Yu draft. (RN, CIC, > etc). Other types of URI may come later. > > The enum URI serves completely different purposes, it is IMHO mainly > there for two reasons: > > 1. To allow the proud new ENUM customer to brag on his webpage and his > e-mail signature to his friends and colleagues that he is really in the > new cool service ENUM. This will also be a nice device to raise the > awareness on ENUM. We will have to market and to sell ENUM and this will > help. Sort of ok, BUT, I ask myself if you have ever intriduced a new URI scheme before? It doesn't look like you have tried. Introduction is extremely hard, if nothing else if you just look at the software which parses URI's like all phones, web browsers and such. The ability to add handles for URI schemes is not easy at all. So, an ENUM URI will be completely useless before software implement the new scheme. > 2. to provide (again for the ENUM end-user) a simple tool to redirect one > E.164 number completely with all entries to another E.164 number, without > having to use constructs like CNAME. You mix up completely the ENUM database service with the database structure (DNS) which implements the storage. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 2 05:22:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17423 for ; Mon, 2 Sep 2002 05:22:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g829Npu22979 for enum-archive@odin.ietf.org; Mon, 2 Sep 2002 05:23:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g829Nno22974; Mon, 2 Sep 2002 05:23:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g829IZo22770 for ; Mon, 2 Sep 2002 05:18:35 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17348 for ; Mon, 2 Sep 2002 05:17:01 -0400 (EDT) content-class: urn:content-classes:message Date: Mon, 2 Sep 2002 11:20:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <06CF906FE3998C4E944213062009F162024755@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Opt-in principle for calling users and communications providers Thread-Index: AcJSWKp+KeW3w9J1T+mm1KjVwXjLVAABgiDw From: "Stastny Richard" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Lawrence Conroy" , "Rich" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g829Iao22771 Subject: [Enum] Opt-in principle for calling users and communications providers Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Patrik, let's clarify this issue first: Richard Stastny wrote: > > 1. ENUM in e164.arpa is opt-in for end-users (for the > called AND and > > also for the calling user) > To which Patrik replied: > No, not for the calling user. The calling user can not tell > all involved parties what kind of databases should be used > during call setup. That is already the case today, and will > be also with ENUM. There is no way I can tell the telcos > whether they should use Informix or just MySQL databases in > their IN systems, whether number portability should be used, > whether call forwarding should be used or not. > > That is a decision of the called party, and the calling party > is only requesting the call to go to the destination > addressed by the E.164 number. > > The opt-in which has been discussed around ENUM is only about > the called party. Whether a specific E.164 number should > exists in DNS or not. > Patrik, this is not up to your opinion, you cannot ignore the ITAC-T and ETSI. THE DEFAULT SERVICE IS THE EXISTING TELEPHONY SERVICE WITHOUT ENUM INVOLVEMENT. "Report of the Department of State ITAC-T Advisory Committee Study Group A Ad Hoc on ENUM - July 6th, 2001" Which states clearly in Section 4.4: "4.4 Opt-in service for calling user and service provider. The crucial part of Opt-in for the calling user and service provider is whether or not to query ENUM and then whether or not to make use of the results. The following approach is proposed for telephony services: 1. No originating party (e.g., a calling user or a service provider) is obligated to perform an ENUM query to complete a telephone call to an E.164 number. 2. A party making an ENUM query, whether a calling user or service provider, is not obligated to use any of the services in the NAPTR records returned. 3. All E.164 numbers must have a Public Switched Telephone Network (PSTN) point of interface. (For geographic numbers this would be an end office or tandem.) For non-telephony services an ENUM query may be necessary if the initiating party that wishes to communicate with the party that has ENUM service has only that party's E.164 number. For example, if the terminating party's e-mail address is user@foo.com, the initiating party will only be able to derive that address from the terminating party's E.164 number by accessing the corresponding ENUM NAPTR record." AND the ETSI TR 102 051 " ENUM Administration in Europe" (July 2002) Which states in section 7.3: "7.3 Principle for calling users and communications providers The default service delivered to the calling user who enters an E.164 number is the existing telephony service according to ITU-T recommendation E.105 [3] without ENUM involvement. This implies that: * No originating party (e.g., a calling user or a communications provider) is obligated to perform an ENUM query to complete a telephone call to an E.164 number. * A party making an ENUM query, whether a calling user or communication provider, is not obligated to use any of the services in the NAPTR records returned. * The specified number should be appropriately terminated for calls that originate on the PSTN/ISDN/PLMN. This termination could also be an announcement." Of course I cannot tell the telcos if they should use Informix, MySQL or ENUM technology within their IN-systems, but what is told the telcos is, e.g by the regulator, if and based on what principles and databases content e.g. NP is used. Best regards Richard Richard STASTNY OeFEG/Telekom Austria Box 147, A-1103 Vienna, Austria tel:+43 664 420 4100 fax:+43 1 797 80 13 mailto:richard.stastny@oefeg.at _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 2 05:30:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17567 for ; Mon, 2 Sep 2002 05:30:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g829VIa23436 for enum-archive@odin.ietf.org; Mon, 2 Sep 2002 05:31:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g829VIo23431; Mon, 2 Sep 2002 05:31:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g829SWo23254 for ; Mon, 2 Sep 2002 05:28:32 -0400 Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17521 for ; Mon, 2 Sep 2002 05:26:57 -0400 (EDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by internal.mail.demon.net with ESMTP id g829SaI01468; Mon, 2 Sep 2002 09:28:36 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 17lnVK-000K2k-00; Mon, 02 Sep 2002 10:28:18 +0100 Date: Mon, 2 Sep 2002 10:28:17 +0100 From: "Clive D.W. Feather" To: Stastny Richard Cc: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , Lawrence Conroy , Rich , enum@ietf.org Subject: Re: [Enum] Opt-in principle for calling users and communications providers Message-ID: <20020902092817.GU67781@demon.net> References: <06CF906FE3998C4E944213062009F162024755@oefeg-s02.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06CF906FE3998C4E944213062009F162024755@oefeg-s02.oefeg.loc> User-Agent: Mutt/1.4i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Stastny Richard said: > Richard Stastny wrote: > > > 1. ENUM in e164.arpa is opt-in for end-users (for the > > called AND and > > > also for the calling user) > > > To which Patrik replied: > > No, not for the calling user. The calling user can not tell > > all involved parties what kind of databases should be used > > during call setup. [...] You two are talking past each other. > Patrik, this is not up to your opinion, you cannot ignore the ITAC-T and ETSI. > > THE DEFAULT SERVICE IS THE EXISTING TELEPHONY SERVICE WITHOUT ENUM INVOLVEMENT. [...] > The following approach is proposed for telephony services: > 1. No originating party (e.g., a calling user or a service provider) is obligated to perform an ENUM query to complete a telephone call to an E.164 number. This does not prevent a service provider from using ENUM if they want to. It simply says they are not required to. Patrik is saying that an SP *can* use ENUM if they wish, and the calling user can't stop them. Two different matters entirely. -- Clive D.W. Feather | Work: | Tel: +44 20 8371 1138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | NOTE: fax number change _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 2 06:11:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18340 for ; Mon, 2 Sep 2002 06:11:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g82ACSB26217 for enum-archive@odin.ietf.org; Mon, 2 Sep 2002 06:12:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82ACQo26209; Mon, 2 Sep 2002 06:12:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82A9Ho26083 for ; Mon, 2 Sep 2002 06:09:17 -0400 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18081 for ; Mon, 2 Sep 2002 06:07:42 -0400 (EDT) Received: from xbe-lon-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g82A5q4l005782; Mon, 2 Sep 2002 12:07:10 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 2 Sep 2002 11:08:02 +0100 Received: from [192.168.1.9] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 2 Sep 2002 12:08:01 +0200 Date: Mon, 02 Sep 2002 12:04:04 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Clive D.W. Feather" , Stastny Richard cc: Lawrence Conroy , Rich , enum@ietf.org Subject: Re: [Enum] Opt-in principle for calling users and communications providers Message-ID: <39191855.1030968244@localhost> In-Reply-To: <20020902092817.GU67781@demon.net> References: <06CF906FE3998C4E944213062009F162024755@oefeg-s02.oefeg.loc> <20020902092817.GU67781@demon.net> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 02 Sep 2002 10:08:01.0722 (UTC) FILETIME=[9EFC81A0:01C25268] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On 2002-09-02 10.28 +0100 "Clive D.W. Feather" wrote: >> 1. No originating party (e.g., a calling user or a service provider) is >> obligated to perform an ENUM query to complete a telephone call to an >> E.164 number. > > This does not prevent a service provider from using ENUM if they want to. > It simply says they are not required to. > > Patrik is saying that an SP *can* use ENUM if they wish, and the calling > user can't stop them. Two different matters entirely. Yes, we were talking beside each other. I wrote a mail to Richard, my co-chair to help out so it was not viewed as I as wg co-chair was arguing with Richard. That is not the case. I am only arguing as Patrik. Clive has read the document the same way as I have. A originating party is not forced to use ENUM, but they can if they want to. My view of your proposal is that: (a) the enum URI MUST be used for ENUM lookups to happen (b) enum lookups MUST NOT be used for tel URI's This implies for me that "default" is that ENUM lookups MUST NOT be used, if not explicitly requested by the calling party. I.e. what you call "opt-in for the calling party". My view is instead: (a) Anyone MAY use ENUM lookups (b) Noone MUST do ENUM lookups (what the ETSI document say) (c) A parameter to the tel: URI scheme SHOULD indicate that ENUM lookup is not necessary, but still (a) rules (d) ENUM URI scheme is not needed, even though marketing wise it would be interesting -- the cost for a new URI scheme is extremely high, and given (a), a new scheme is not needed I can see need for (c) when for example a tel: URI is passed from one system to another when either ENUM lookup has been done, or something similar. I am still happy to be convinced about the need for an enum URI scheme, but have not seem the evidence. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 2 06:15:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18408 for ; Mon, 2 Sep 2002 06:15:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g82AG4Q26422 for enum-archive@odin.ietf.org; Mon, 2 Sep 2002 06:16:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82AG3o26417; Mon, 2 Sep 2002 06:16:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82ADpo26302 for ; Mon, 2 Sep 2002 06:13:51 -0400 Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18380 for ; Mon, 2 Sep 2002 06:12:16 -0400 (EDT) Received: from lawrence.srmr.co.uk ([193.118.192.111] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 5223u via TCP with SMTP; Mon, 02 Sep 2002 11:13:39 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Mon, 2 Sep 2002 11:13:33 +0100 To: paf@cisco.com, richard.stastny@oefeg.at, clive@demon.net From: Lawrence Conroy Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Enum - to be or not to be Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Patrik, Richard, Clive, folks, ouch! More coffee needed, IMHO, or maybe less. I'll leave the comments on phone teleservice specifications to other learned Fora, but... I do have 2 comments on how we might use an enum: URI scheme. It may be possible to use the "replacement domain" field of non-terminal NAPTRs to do the "re-sumbit the query at a different point in the (public) golden tree" re-direction. That rather depends on the answers to my earlier questions (on D3S details). Maybe, there may be a way to force a "fine grained" re-direction without requiring an "enum:" URI in the ENUM domain space. However... We still have the issue of a web page (or email) that includes a phone style URL. How is that processed? We're NOT talking about a SP (either a Central Office or an I.N. box) here. This is purely an end user receiving a web page or email with a URL containing an E.164 number string (Note...not a dial string :). An example may help. I have a tel: processor already - if I click on a tel: URL it will fire off a command (via a serial link - it's been around for a while :) to my steam phone, and this dials out. Your tel: processor may do an ENUM lookup and dial out using a new number it has retrieved, but mine doesn't. Now, if we had an enum: URL, then I can be sure that any processor for this URL *will* perform an ENUM lookup - that's the job of the enum: URL. It is NOT to dial out, but instead to resolve the contact info using ENUM. If the result is a phone number embedded in a NAPTR, then the *next* action may be to dial out (with or without a serial link to a steam phone). However, that's NOT the job of an enum: URI, but instead a processor for the URI I retrieve from the ENUM lookup. The "protocol" for the enum: URI is an ENUM lookup using DNS. The "protocol" for a tel: URL is whatever I use to initiate a phone call (or sms, or fax, or ...). Overloading tel: is a bit inelegant, but more importantly it isn't going to work with some clients "out there in the wild". all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 2 06:36:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18695 for ; Mon, 2 Sep 2002 06:36:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g82AbII27642 for enum-archive@odin.ietf.org; Mon, 2 Sep 2002 06:37:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82AbDo27507; Mon, 2 Sep 2002 06:37:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82AXbo27052 for ; Mon, 2 Sep 2002 06:33:37 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18660 for ; Mon, 2 Sep 2002 06:32:02 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Mon, 2 Sep 2002 12:35:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <06CF906FE3998C4E944213062009F162024757@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Opt-in principle for calling users and communications providers Thread-Index: AcJSY28mc3qHg7WeQAmwoFbctaVlAwAB0A7Q From: "Stastny Richard" To: "Clive D.W. Feather" Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Lawrence Conroy" , "Rich" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g82AXbo27053 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Clive wrote: > > The following approach is proposed for telephony services: > > 1. No originating party (e.g., a calling user or a service > provider) is obligated to perform an ENUM query to complete a > telephone call to an E.164 number. > > This does not prevent a service provider from using ENUM if > they want to. > It simply says they are not required to. I do not agree. If there has to be always a termination on the conventional network, and if the service provider may do as he likes, than there must be a way for the calling user to FORCE the phone system not to use ENUM. Otherwise it would make no sense to state: "All E.164 numbers must have a Public Switched Telephone Network (PSTN) point of interface." This statement of course may be discussed, but as long as it is there, we have to take it into account. Best regards Richard STASTNY OeFEG/Telekom Austria Box 147, A-1103 Vienna, Austria tel:+43 664 420 4100 fax:+43 1 797 80 13 mailto:richard.stastny@oefeg.at _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 2 07:00:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19037 for ; Mon, 2 Sep 2002 07:00:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g82B1ls28562 for enum-archive@odin.ietf.org; Mon, 2 Sep 2002 07:01:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82B1go28552; Mon, 2 Sep 2002 07:01:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82AwPo28442 for ; Mon, 2 Sep 2002 06:58:25 -0400 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18943 for ; Mon, 2 Sep 2002 06:56:50 -0400 (EDT) Received: from xbe-ams-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g82AuMRX014708; Mon, 2 Sep 2002 12:56:23 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 2 Sep 2002 12:57:01 +0200 Received: from [192.168.1.9] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 2 Sep 2002 12:57:00 +0200 Date: Mon, 02 Sep 2002 12:55:08 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Stastny Richard , "Clive D.W. Feather" cc: Lawrence Conroy , Rich , enum@ietf.org Subject: RE: [Enum] Opt-in principle for calling users and communications providers Message-ID: <39375682.1030971308@localhost> In-Reply-To: <06CF906FE3998C4E944213062009F162024757@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F162024757@oefeg-s02.oefeg.loc> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 02 Sep 2002 10:57:00.0492 (UTC) FILETIME=[76A138C0:01C2526F] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On 2002-09-02 12.35 +0200 Stastny Richard wrote: > I do not agree. If there has to be always a termination on the > conventional network, and if the service provider may do as he likes, > than there must be a way for the calling user to FORCE the phone system > not to use ENUM. > > Otherwise it would make no sense to state: > "All E.164 numbers must have a Public Switched Telephone Network (PSTN) > point of interface." No. It only means for me that if you dial on PSTN that number, you will get the phone connected to something. It might imply you hit a gateway to VoIP which in turn gateway the call to SIP, and you will get the call terminated. I.e. for me the sentence state that it must be possible to make a voice call using the E.164 number in question. Not that the termination point _for_the_voice_call_ must be on PSTN. Only that the point of interface is on PSTN, and that might be a gateway. This is already the case for many many E.164 numbers today which is IP based. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 2 07:56:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19869 for ; Mon, 2 Sep 2002 07:56:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g82BvKr31507 for enum-archive@odin.ietf.org; Mon, 2 Sep 2002 07:57:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82BvDo31493; Mon, 2 Sep 2002 07:57:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82Brno31321 for ; Mon, 2 Sep 2002 07:53:49 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19801 for ; Mon, 2 Sep 2002 07:52:12 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Mon, 2 Sep 2002 13:55:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <06CF906FE3998C4E944213062009F16202475A@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Opt-in principle for calling users and communications providers Thread-Index: AcJScAkOUw02zBAJRnyGYS7hdrk94gAAPLqw From: "Stastny Richard" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Clive D.W. Feather" Cc: "Lawrence Conroy" , "Rich" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g82Brno31322 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Comments inline > -----Original Message----- > From: Patrik Fältström [mailto:paf@cisco.com] > Sent: Monday, September 02, 2002 12:55 PM > To: Stastny Richard; Clive D.W. Feather > Cc: Lawrence Conroy; Rich; enum@ietf.org > Subject: RE: [Enum] Opt-in principle for calling users and > communications providers > > --On 2002-09-02 12.35 +0200 Stastny Richard > wrote: > > > I do not agree. If there has to be always a termination on the > > conventional network, and if the service provider may do as > he likes, > > than there must be a way for the calling user to FORCE the phone > > system not to use ENUM. > > > > Otherwise it would make no sense to state: > > "All E.164 numbers must have a Public Switched Telephone Network > > (PSTN) point of interface." > > No. It only means for me that if you dial on PSTN that > number, you will get the phone connected to something. It > might imply you hit a gateway to VoIP which in turn gateway > the call to SIP, and you will get the call terminated. > > I.e. for me the sentence state that it must be possible to > make a voice call using the E.164 number in question. Not > that the termination point _for_the_voice_call_ must be on > PSTN. Only that the point of interface is on PSTN, and that > might be a gateway. > > This is already the case for many many E.164 numbers today > which is IP based. Now we are at the point, why we need BOTH "user ENUM" and "infrastructure ENUM" independently. Of course you may have a termination on the PSTN which is really on VoIP, because the phone system is technology independant. And it is up to the service provider, how to find his users, and of course he may do this also with ENUM. This may be an internal DNS application or one in the "public" DNS under whatever tree. BUT, this ENUM cannot be the e164.arpa, because there the entries are controlled by the end-user and not by the service provider. I cannot imagine a service provider having a "routing" database which can be manipulated by the user, who may potentially break the service. Of course I do see your example that "you hit a gateway to VoIP which in turn gateway the call to SIP, and you will get the call terminated", but this is a two stage process: First the provider queries his ENUM to terminate the call e.g. on the provider supplied personal user agent (PUA). The subcriber may now have a normal SIP or H323 service and is currently attached to the Internet or not. If not, the call is terminating on an announcement or forwarded somewhere else. The provider may also offer the subscriber in parallel an sip or h323 ID, which may be used by the end-user independently on his own "user ENUM" entry in e164.arpa to terminate the call from the Internet on the same PUA (as envisaged with +87810) Alternatively the user may have an agreement with the service provider, that any call incoming from the PSTN via the gateway is first hitting the PUA (by querying "infrastructure ENUM", which in turn queries "User ENUM" and then forwards the call another SIP or H323 termination. This would BTW be a nice way to port a number from PSTN first to an IP based provider and then out on the Internet;-) Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 2 08:19:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20263 for ; Mon, 2 Sep 2002 08:19:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g82CKCj00589 for enum-archive@odin.ietf.org; Mon, 2 Sep 2002 08:20:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82CKBo00584; Mon, 2 Sep 2002 08:20:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82CHno00421 for ; Mon, 2 Sep 2002 08:17:49 -0400 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20189 for ; Mon, 2 Sep 2002 08:16:13 -0400 (EDT) Received: from xbe-ams-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g82CFitP027522; Mon, 2 Sep 2002 14:15:47 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 2 Sep 2002 14:16:26 +0200 Received: from [192.168.1.9] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 2 Sep 2002 14:16:25 +0200 Date: Mon, 02 Sep 2002 14:14:54 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Stastny Richard , "Clive D.W. Feather" cc: Lawrence Conroy , Rich , enum@ietf.org Subject: RE: [Enum] Opt-in principle for calling users and communications providers Message-ID: <39662847.1030976093@localhost> In-Reply-To: <06CF906FE3998C4E944213062009F16202475A@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F16202475A@oefeg-s02.oefeg.loc> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 02 Sep 2002 12:16:25.0965 (UTC) FILETIME=[8F12B1D0:01C2527A] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On 2002-09-02 13.55 +0200 Stastny Richard wrote: > BUT, this ENUM cannot be the e164.arpa, because there the entries are > controlled by the end-user and not by the service provider. I cannot > imagine a service provider having a "routing" database which can be > manipulated by the user, who may potentially break the service. This is a view which many service providers have, but remember that "voice application" is just like "email application" or anything else which ends up in ENUM. The user _must_ (as you say) see that the correct information for the service he subscribes to is in the ENUM service providers DNS of his choice. The user is in control, correct, and the application service provider is giving the information needed in ENUM to the user. In reality, my view is that what the user does is to tell the service provider what ENUM DNS provider he wants, and the service provider is passing information needed to the ENUM DNS provider. OR the Enum DNS provider collects the correct information on behalf of the user. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 2 08:37:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20645 for ; Mon, 2 Sep 2002 08:37:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g82CcH401878 for enum-archive@odin.ietf.org; Mon, 2 Sep 2002 08:38:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82CcGo01873; Mon, 2 Sep 2002 08:38:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82CZho01238 for ; Mon, 2 Sep 2002 08:35:43 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20606 for ; Mon, 2 Sep 2002 08:34:06 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g82C5gVg007898; Mon, 2 Sep 2002 08:05:42 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g82C5fDO007897; Mon, 2 Sep 2002 08:05:41 -0400 (EDT) Date: Mon, 2 Sep 2002 08:05:41 -0400 From: Michael Mealling To: Stastny Richard Cc: "Clive D.W. Feather" , Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , Lawrence Conroy , Rich , enum@ietf.org Subject: Re: [Enum] Opt-in principle for calling users and communications providers Message-ID: <20020902080540.H5086@bailey.dscga.com> Reply-To: Michael Mealling References: <06CF906FE3998C4E944213062009F162024757@oefeg-s02.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06CF906FE3998C4E944213062009F162024757@oefeg-s02.oefeg.loc> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Mon, Sep 02, 2002 at 12:35:39PM +0200, Stastny Richard wrote: > Clive wrote: > > > The following approach is proposed for telephony services: > > > 1. No originating party (e.g., a calling user or a service > > provider) is obligated to perform an ENUM query to complete a > > telephone call to an E.164 number. > > > > This does not prevent a service provider from using ENUM if > > they want to. > > It simply says they are not required to. > > I do not agree. If there has to be always a termination on the conventional network, and if the service provider may do as he likes, than there must be a way for the calling user to FORCE the phone system not to use ENUM. > > Otherwise it would make no sense to state: > "All E.164 numbers must have a Public Switched Telephone Network > (PSTN) point of interface." > > This statement of course may be discussed, but as long as it is > there, we have to take it into account. The statement is that all E.164 numbers must _have_ one. It doesn't say anything about it actually having to be used.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 2 11:11:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24238 for ; Mon, 2 Sep 2002 11:11:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g82FCAx10033 for enum-archive@odin.ietf.org; Mon, 2 Sep 2002 11:12:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82FC5o10026; Mon, 2 Sep 2002 11:12:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82FABo09940 for ; Mon, 2 Sep 2002 11:10:11 -0400 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 LAA24189 for ; Mon, 2 Sep 2002 11:08:34 -0400 (EDT) Received: from user-2ivek8r.dialup.mindspring.com ([165.247.81.27] helo=dick.ix.netcom.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 17lsq4-00053r-00 for enum@ietf.org; Mon, 02 Sep 2002 11:10:05 -0400 Message-Id: <5.1.0.14.2.20020901184416.01d556e0@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Sep 2002 11:18:41 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Revised WG Goals and Milestones Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , We have had a inquiry from our Area directors on updating our Goals and Milestones. What we have now is this. Goals and Milestones: Done Initial draft of Service ENUM Requirements Done Initial draft of ENUM Protocol Done Revised draft of ENUM Protocol Done Submit ENUM Protocol document to IESG for publication as Proposed JUN 02 Revise and update RFC 2916 appropriate to DDDS (revision of 2915) and advance to Draft Standard JUL 02 Document appropriate ENUM Registration and Provisioning Procedures (Informational) AUG 02 Document appropriate ENUM Operational Security, Privacy Issues and Procedures (Informational) I'd like to propose this. Done Initial draft of Service ENUM Requirements Done Initial draft of ENUM Protocol Done Revised draft of ENUM Protocol Done Submit ENUM Protocol document to IESG for publication as Proposed NOV 02 Revise and update RFC 2916 appropriate to DDDS (revision of 2915) DEC 02 Document appropriate ENUM Service Field Registrations [ Standards Track ] March 02 Document appropriate ENUM Provisioning Procedures (Informational ?) March 03 Advance revised RFC 2916 to Draft Standard June 03 Document appropriate ENUM Operational Security, Privacy Issues and Procedures (Informational) I want to note to the list that I'm personally aware of several national trials of ENUM that are beginning this fall and Winter we would hope that some of you who are working on those trials will assist the WG in documenting the funcitions during those trials to assist the WG in completing it task of taking 2916 forward to Draft standard. I think its also reasonable that we delay trying to work on provisioning, security and other issues until there are some clear results coming back from those trials. Comments? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 2 11:11:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24250 for ; Mon, 2 Sep 2002 11:11:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g82FCCM10068 for enum-archive@odin.ietf.org; Mon, 2 Sep 2002 11:12:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82FCCo10063; Mon, 2 Sep 2002 11:12:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82FAoo09962 for ; Mon, 2 Sep 2002 11:10:50 -0400 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 LAA24200 for ; Mon, 2 Sep 2002 11:09:14 -0400 (EDT) Received: from user-2ivek8r.dialup.mindspring.com ([165.247.81.27] helo=dick.ix.netcom.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 17lsqI-00053r-00; Mon, 02 Sep 2002 11:10:20 -0400 Message-Id: <5.1.0.14.2.20020902104454.03e343d0@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Sep 2002 11:08:24 -0400 To: "Stastny Richard" , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Clive D.W. Feather" From: Richard Shockey Subject: RE: [Enum] Opt-in principle for calling users and communications providers Cc: "Lawrence Conroy" , "Rich" , In-Reply-To: <06CF906FE3998C4E944213062009F16202475A@oefeg-s02.oefeg.loc > 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-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , I'm here but I still think we are talking across each other > > > > > I do not agree. If there has to be always a termination on the > > > conventional network, and if the service provider may do as > > he likes, > > > than there must be a way for the calling user to FORCE the phone > > > system not to use ENUM. > > > > > > Otherwise it would make no sense to state: > > > "All E.164 numbers must have a Public Switched Telephone Network > > > (PSTN) point of interface." > > > > No. It only means for me that if you dial on PSTN that > > number, you will get the phone connected to something. It > > might imply you hit a gateway to VoIP which in turn gateway > > the call to SIP, and you will get the call terminated. > > > > I.e. for me the sentence state that it must be possible to > > make a voice call using the E.164 number in question. Not > > that the termination point _for_the_voice_call_ must be on > > PSTN. Only that the point of interface is on PSTN, and that > > might be a gateway. > > > > This is already the case for many many E.164 numbers today > > which is IP based. > >Now we are at the point, why we need BOTH "user ENUM" and "infrastructure >ENUM" independently. > >Of course you may have a termination on the PSTN which is really on VoIP, >because the phone system is technology independant. And it is up to the >service provider, how to find his users, and of course he may do this also >with ENUM. This may be an internal DNS application or one in the "public" >DNS under whatever tree. I certainly see how a service provider may want to use DNS technology internally in his network for a "infrastructure ENUM". If a service provider begins to decompose his internal TDM network with IP based Inter-Machine Trunking or places significant numbers of Media Gateways withing their network then it makes more sense to use DNS for things like inter LATA routing than SS7. The more you use IP in a service provider network the more useless SS7 becomes, since service creation is at the edge and data routing is a function of BGP etc. These are private implementations that, I'm presuming, are not globally visible to the average user of the internet. The management of the e164.arpa namespace is specifically about what is globally visible. What is interesting to me in this converged architecture is how can a Class 5 switch determine IF the call can be terminated on a IP endpoint. At point of call ingress it is assumed that the switch has several databases available to it in order to make a call routing determination of which both a public globally visible ENUM AND a privately provisioned IP endpoint/GW database is available as well. However the choice of internal endpoint database may or may not be DNS .. it makes no difference since it is not globally viable. >BUT, this ENUM cannot be the e164.arpa, because there the entries are >controlled by the end-user and not by the service provider. I cannot >imagine a service provider having a "routing" database which can be >manipulated by the user, who may potentially break the service. Of course ... but where we seem to be crossing paths here is the difference is that one DNS tree is globally visible and the other is not. >Of course I do see your example that "you hit a gateway to VoIP which in >turn gateway the call to SIP, and you will get the call terminated", but >this is a two stage process: > >First the provider queries his ENUM to terminate the call e.g. on the >provider supplied personal user agent (PUA). The subcriber may now have a >normal SIP or H323 service and is currently attached to the Internet or >not. If not, the call is terminating on an announcement or forwarded >somewhere else. No problem here ..you are doing a internal network look up , a basic IF/THEN problem ..if there is no entry in the _internal_ endpoint database THEN query the golbal enum db. >The provider may also offer the subscriber in parallel an sip or h323 ID, >which may be used by the end-user independently on his own "user ENUM" >entry in e164.arpa to terminate the call from the Internet on the same PUA >(as envisaged with +87810) Or actually on his PSTN endpoint as well, this could work either way +87810 would not be necessary. This is a excellent point ..I do believe service providers will offer to their customers sip addresses mapped to their PSTN endpoints. There is a business case and service logic for doing this. The sip address simply maps to a GW which then rings the PSTN phone...this is then a called party pays or a personal freephone like service. >Alternatively the user may have an agreement with the service provider, >that any call incoming from the PSTN via the gateway is first hitting the >PUA (by querying "infrastructure ENUM", which in turn queries "User ENUM" >and then forwards the call another SIP or H323 termination. Exactly >This would BTW be a nice way to port a number from PSTN first to an IP >based provider and then out on the Internet;-) > >Richard >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 2 12:06:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25701 for ; Mon, 2 Sep 2002 12:06:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g82G7Ck13707 for enum-archive@odin.ietf.org; Mon, 2 Sep 2002 12:07:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82G7Bo13678; Mon, 2 Sep 2002 12:07:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82G6eo13275 for ; Mon, 2 Sep 2002 12:06:40 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25639 for ; Mon, 2 Sep 2002 12:05:01 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Mon, 2 Sep 2002 18:08:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <06CF906FE3998C4E944213062009F162024760@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Opt-in principle for calling users and communications providers Thread-Index: AcJSkz5ZPa7Mb6GbR+GjVBVffMUlZQAA3Duw From: "Stastny Richard" To: "Richard Shockey" , =?iso-8859-1?Q?Patrik__F=E4ltstr=F6m?= , "Clive D.W. Feather" Cc: "Lawrence Conroy" , "Rich" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g82G6fo13276 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Rich wrote: > What is interesting to me in this converged architecture is > how can a Class > 5 switch determine IF the call can be terminated on a IP > endpoint. At > point of call ingress it is assumed that the switch has > several databases > available to it in order to make a call routing determination > of which both > a public globally visible ENUM AND a privately provisioned IP > endpoint/GW > database is available as well. However the choice of internal > endpoint > database may or may not be DNS .. it makes no difference > since it is not > globally viable. I a converged architecture a originating class 5 switch could do this only if he is querying a globally available database, e.g. ENUM. Finally this will be an ACQ, but in the beginning there could be a pretranslation similar to NP (e.g. IP enabled CC NDC). In this database you either have an entry for every number or a wildcard for a numbering block, either pointing to a gateway directly or pointing to another database (e.g with an ldap URI). This is, I assume your _privately provisioned IP endpoint/GW database_. You could use e164.arpa ENUM for this, but the problem starts, if you have, as you mentioned, a _public/globally visible AND a privately provisioned IP endpoint/GW database_. As I already stated, both cannot be in the same ENUM database, first, because the user decides on the tier 2 registry and second and even more important, if the provider decides to have a wildcard in ENUM for all numbers in the block to point to a certain GW/database, and one user out of this block decides to go into ENUM on his own, the whole thing breaks apart. So I still have the opinion, that we need two ENUMs and the originating switch has to query them one after the other. My proposal is, that normally the class 5 switch is querying the infrastructure tree first and then maybe, to keep some people out there happy, the user ENUM. Only if the calling user subscribes an _ENUM Preselection_ or does a call-by-call _selection_, user ENUM is queried first. The reason: at least at the startup of ENUM you will get in most cases a _404_. Regards Richard Stastny Richard STASTNY OeFEG/Telekom Austria Box 147, A-1103 Vienna, Austria tel:+43 664 420 4100 fax:+43 1 797 80 13 mailto:richard.stastny@oefeg.at _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 2 16:32:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00857 for ; Mon, 2 Sep 2002 16:31:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g82KXAZ28362 for enum-archive@odin.ietf.org; Mon, 2 Sep 2002 16:33:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82KX4o28356; Mon, 2 Sep 2002 16:33:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82KVbo28290 for ; Mon, 2 Sep 2002 16:31:37 -0400 Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00813 for ; Mon, 2 Sep 2002 16:29:55 -0400 (EDT) Received: from user-2ivelet.dialup.mindspring.com ([165.247.85.221] helo=dick.ix.netcom.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17lxqv-00052n-00; Mon, 02 Sep 2002 16:31:18 -0400 Message-Id: <5.1.0.14.2.20020902160108.01ed15d8@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Sep 2002 16:37:46 -0400 To: "Stastny Richard" , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Clive D.W. Feather" From: Richard Shockey Subject: RE: [Enum] Opt-in principle for calling users and communications providers Cc: "Lawrence Conroy" , In-Reply-To: <06CF906FE3998C4E944213062009F162024760@oefeg-s02.oefeg.loc > 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-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 06:08 PM 9/2/2002 +0200, Stastny Richard wrote: >Rich wrote: > > > What is interesting to me in this converged architecture is > > how can a Class > > 5 switch determine IF the call can be terminated on a IP > > endpoint. At > > point of call ingress it is assumed that the switch has > > several databases > > available to it in order to make a call routing determination > > of which both > > a public globally visible ENUM AND a privately provisioned IP > > endpoint/GW > > database is available as well. However the choice of internal > > endpoint > > database may or may not be DNS .. it makes no difference > > since it is not > > globally viable. > >I a converged architecture a originating class 5 switch could do this only >if he is querying a globally available database, e.g. ENUM. Finally this >will be an ACQ, but in the beginning there could be a pretranslation >similar to NP (e.g. IP enabled CC NDC). In this database you either have >an entry for every number or a wildcard for a numbering block, either >pointing to a gateway directly or pointing to another database (e.g with >an ldap URI). This is, I assume your _privately provisioned IP endpoint/GW >database_. Correct .. but this could start out as a private database exchange between cooperating service providers. The problem statement you describe does not have to be a "end world hunger" solution in the beginning. You are correct that this has some similarities to the LNP problem. Cooperating service providers could exchange end point/GW data privately to provision local and non globally visable DNS servers using either end point URI's or as you suggest LDAP look up's etc. The exchange of data could occur by any number of means ..or as the N(2) problem occurs some arrangement could be made to aggrate the data and then redistribute it to service providers in a mutually acceptable manner which then updates the local non-visable DNS servers (aka the new new SCP's). If TRIP were introduced internally to a SP network then the global advertisement for endpoint resolution could be single hostname. TRIP then could hide the actual location of GW within the service providers domain boundry. >You could use e164.arpa ENUM for this, but the problem starts, if you >have, as you mentioned, a _public/globally visible AND a privately >provisioned IP endpoint/GW database_. Using e164.arpa for this is IMHO not a good idea since I ( as a service provider) would not want to expose business relationships between service providers in global DNS tree, should such data be exchanged. This goes now to the heart of the convergence problem ... the Internet operates on a transit/peering model (aka bill and keep) while global TDM telephony relies on reciprocal compensation. The optimal transaction/business model in IP Telephony keeps OSS billing costs to a minimum. >As I already stated, both cannot be in the same ENUM database, first, >because the user decides on the tier 2 registry and second and even more >important, if the provider decides to have a wildcard in ENUM for all >numbers in the block to point to a certain GW/database, and one user out >of this block decides to go into ENUM on his own, the whole thing breaks apart. Of course which always argues for the full resolution of the E.164 number before determining the NS of authority global or non-globally visable. >So I still have the opinion, that we need two ENUMs and the originating >switch has to query them one after the other. My proposal is, that >normally the class 5 switch is querying the infrastructure tree first and >then maybe, to keep some people out there happy, the user ENUM. Yes IMHO you are correct...a dual query model will need to be supported since it is clear that IP PBX's, for instance, will query e164.apra on their own and only require transit from their SP . Now the SP resolution model does not have to use DNS, LDAP might work ... its just useful since its there. I have heard discussions that some SP's might look for a trigger in SS7 first to then dump the call into a MG where the ENUM query would be done. I think you agree that there is much fruitful work to be done in this area. It is not clear to me at all how C5 elements will eventually discover that some endpoints can be reached over IP. We could certainly whiteboard out a dozen or more ways to do this for both the C5 elements and the exchange of GW endpoint data between SP's for hosted or network oriented services. That's why standards are wonderful ...there are so many of them! :-) >Only if the calling user subscribes an _ENUM Preselection_ or does a >call-by-call _selection_, user ENUM is queried first. Actually I think this is a _called party Preselection_ If I register my number in ENUM I have essentially stated that it is MY preference to have the call terminated to me on IP where I can establish more effective control..what the calling party want is irrelevant. This again goes back to the core issue we were dealing with in Yokohama ...where does call control reside. I have taken the view that for privacy reasons and various others it is the called party that actually is in control of the call session ..not the calling party. I choose not to expose any data in the global DNS except the absolute minimum necessary to establish a session between who is calling me and my endpoints. I delegate to my SIP proxy or other SRS/Presence server the control of how/when and by what manner I choose to be contacted. The opposite view ..is of course that the calling party wants control and want the maximum flexibility in selecting how and by what means the called party is contacted. This argues for what you and Ranali/Walter have proposed. Both are legitimate technival views but I submit it is up to the end user to decide. >The reason: at least at the startup of ENUM you will get in most cases a >_404_. Yes its chicken and egg but I have noticed the hen's hard at work. Best wishes. >Regards >Richard Stastny > > >Richard STASTNY >OeFEG/Telekom Austria >Box 147, A-1103 Vienna, Austria >tel:+43 664 420 4100 >fax:+43 1 797 80 13 >mailto:richard.stastny@oefeg.at >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 2 23:20:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06316 for ; Mon, 2 Sep 2002 23:20:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g833LPD15695 for enum-archive@odin.ietf.org; Mon, 2 Sep 2002 23:21:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g833LHo15690; Mon, 2 Sep 2002 23:21:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g833JHo15603 for ; Mon, 2 Sep 2002 23:19:17 -0400 Received: from whale.cnnic.net.cn ([159.226.6.187]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06277 for ; Mon, 2 Sep 2002 23:17:34 -0400 (EDT) Received: from DELL8100 ([159.226.7.65]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id H1UEK000.LKU; Tue, 3 Sep 2002 11:19:12 +0800 Message-ID: <000601c252f8$3237f410$4107e29f@DELL8100> From: "bill" To: "Richard Shockey" Cc: References: <5.1.0.14.2.20020901184416.01d556e0@popd.ix.netcom.com> Subject: Re: [Enum] Revised WG Goals and Milestones Date: Tue, 3 Sep 2002 11:15:46 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id g833JHo15604 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, folks, just some comments: > I want to note to the list that I'm personally aware of several national > trials of ENUM that are beginning this fall and Winter we would hope that > some of you who are working on those trials will assist the WG in > documenting the funcitions during those trials to assist the WG in > completing it task of taking 2916 forward to Draft standard. I learned the the ENUM trial will happen in the Europe and Asia, How about the US? The ENUM trial will be good for developing ENUM to a useful service to the end users, as well as the progress of standards. Several websites is set up for information about the enum trial but most of them are not in English, (e.g: www.enum.or.kr, http://www.pts.se/tele_niva3.asp?avdelning=lev3_enum&uavdelning=tele_niva3&u2avdelning=workshop&lang=&header=Can ). Should people who are working on those trial use this enum mailing list for sharing the information about the enum trial worldwide? > > I think its also reasonable that we delay trying to work on provisioning, > security and other issues until there are some clear results coming back > from those trials. > > > Comments? > Support Bill 2002/09/03 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 3 09:49:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26675 for ; Tue, 3 Sep 2002 09:49:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g83DogH25009 for enum-archive@odin.ietf.org; Tue, 3 Sep 2002 09:50:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83DoOo25001; Tue, 3 Sep 2002 09:50:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83Dm2o24864 for ; Tue, 3 Sep 2002 09:48:02 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26565 for ; Tue, 3 Sep 2002 09:46:23 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Tue, 3 Sep 2002 12:07:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <06CF906FE3998C4E944213062009F162024762@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Opt-in principle for calling users and communications providers Thread-Index: AcJSwBEtUeTzEZwjTpOiLriGP1nZdwAXUxoA From: "Stastny Richard" To: "Richard Shockey" , =?iso-8859-1?Q?Patrik___F=E4ltstr=F6m?= , "Clive D.W. Feather" Cc: "Lawrence Conroy" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g83Dm2o24865 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Rich, As we discussed this issue already, I think we both agree that this problem is very complex and in general I think we do not even know completely, what the problem is. And I see also from these discussions, that there are many different views and standpoints out there. So maybe we should take a step back and define the problem first and then discuss about solutions. Anyway, one thing is obvious, if we want to upgrade/migrate/replace the global public phone system, we have to provide at least onother global and public phone system and not a mess of private databases. This was BTW one of the reasons, that IN was never really available for global services. All IN systems where only available _privately_ in operators networks or in some cases nationally, but never globally. Rest of the comments inline Richard PS: I am still waiting for your input related to SG2 on service codes. Richard STASTNY OeFEG/Telekom Austria Box 147, A-1103 Vienna, Austria tel:+43 664 420 4100 fax:+43 1 797 80 13 mailto:richard.stastny@oefeg.at > -----Original Message----- > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > Sent: Monday, September 02, 2002 10:38 PM > To: Stastny Richard; Patrik Fältström; Clive D.W. Feather > Cc: Lawrence Conroy; enum@ietf.org > Subject: RE: [Enum] Opt-in principle for calling users and > communications providers > > > > Correct .. but this could start out as a private database > exchange between > cooperating service providers. The problem statement you > describe does not > have to be a "end world hunger" solution in the beginning. > You are correct > that this has some similarities to the LNP problem. > Cooperating service > providers could exchange end point/GW data privately to > provision local and > non globally visable DNS servers using either end point URI's > or as you > suggest LDAP look up's etc. The exchange of data could occur > by any number > of means ..or as the N(2) problem occurs some arrangement > could be made to > aggrate the data and then redistribute it to service providers in a > mutually acceptable manner which then updates the local > non-visable DNS > servers (aka the new new SCP's). > > If TRIP were introduced internally to a SP network then the global > advertisement for endpoint resolution could be single > hostname. TRIP then > could hide the actual location of GW within the service > providers domain > boundry. I even would not go into so much detail at the beginning, the first question is to give the originator a hint (pointer) where to find the destination (network or GW or whatever) for a given number. Thats what ENUM is for. The rest could then be done in your way (or in another). > > >You could use e164.arpa ENUM for this, but the problem starts, if you > >have, as you mentioned, a _public/globally visible AND a privately > >provisioned IP endpoint/GW database_. > > Using e164.arpa for this is IMHO not a good idea since I ( as > a service > provider) would not want to expose business relationships > between service > providers in global DNS tree, should such data be exchanged. > This goes now > to the heart of the convergence problem ... the Internet > operates on a > transit/peering model (aka bill and keep) while global TDM > telephony relies > on reciprocal compensation. The optimal transaction/business > model in IP > Telephony keeps OSS billing costs to a minimum. > The current model in TDM (for normal calls) is cascading, where the origination network bills the subscriber and cascades the money to the following networks, up to the destination network. Maybe this model has to change anyway: e.g. every user is paying for what he is reponsible for. We have this discussion currently with MNP, because we have no air-time and different charges to different mobile networks. So the origination subscriber pays to reach the destination network, but not the destination network itself. If he his paying nothing to reach the destination network (or only the access) fine. It is then up to the called user to pay to be reached where he wants to be reached. > > I think you agree that there is much fruitful work to be done > in this area. > It is not clear to me at all how C5 elements will eventually > discover that > some endpoints can be reached over IP. > > We could certainly whiteboard out a dozen or more ways to do > this for both > the C5 elements and the exchange of GW endpoint data between SP's for > hosted or network oriented services. > > That's why standards are wonderful ...there are so many of them! :-) Ok fine, where and when? > >Only if the calling user subscribes an _ENUM Preselection_ or does a > >call-by-call _selection_, user ENUM is queried first. > > Actually I think this is a _called party Preselection_ If I > register my > number in ENUM I have essentially stated that it is MY > preference to have > the call terminated to me on IP where I can establish more effective > control..what the calling party want is irrelevant. This is exactly what I said above: calling and called user should control and eventually pay for what they are responsible and what they can control. If you look at the TIPHON model (see Pauls presentation at the NGN-Summit in Brugge), you have an originating user attached to an originating serving (access) network) who is calling via his home network (signalling) hosting the PUA the home network (PUA) of the called user. The called user may also be attached to a serving destination network. Between each of the four networks there may be additional transit networks, the media could finally go directly from the orig serving network to the dest serving network. What is payed IMHO in the future is mainly the access on both sides (fixed, ADSL, cable, GPRS, WLAN, etc.) and the hosting of the Personal User Agents (PUA) on both sides. > This again goes back to the core issue we were dealing with > in Yokohama > ...where does call control reside. I have taken the view > that for privacy > reasons and various others it is the called party that actually is in > control of the call session ..not the calling party. I choose > not to expose > any data in the global DNS except the absolute minimum necessary to > establish a session between who is calling me and my > endpoints. I delegate > to my SIP proxy or other SRS/Presence server the control of > how/when and by > what manner I choose to be contacted. The privacy issues are handled by the PUAs, and you should consider that the calling party also have a PUA. In the UCI approach finally the PUAs will negotiate. > The opposite view ..is of course that the calling party wants > control and > want the maximum flexibility in selecting how and by what > means the called > party is contacted. This argues for what you and Ranali/Walter have > proposed. Both are legitimate technival views but I submit > it is up to the > end user to decide. I think both sides have their share, as stated above. Regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 3 10:02:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27521 for ; Tue, 3 Sep 2002 10:02:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g83E46A25677 for enum-archive@odin.ietf.org; Tue, 3 Sep 2002 10:04:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83E45o25670; Tue, 3 Sep 2002 10:04:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83E1go25584 for ; Tue, 3 Sep 2002 10:01:42 -0400 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27365 for ; Tue, 3 Sep 2002 10:00:03 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g83E0xD28561; Tue, 3 Sep 2002 14:01:00 GMT Message-Id: <5.1.0.14.2.20020903095855.04436e10@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 10:06:06 -0400 To: "bill" From: Richard Shockey Subject: Re: [Enum] Revised WG Goals and Milestones Cc: In-Reply-To: <000601c252f8$3237f410$4107e29f@DELL8100> References: <5.1.0.14.2.20020901184416.01d556e0@popd.ix.netcom.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-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 11:15 AM 9/3/2002 +0800, bill wrote: >Hi, folks, just some comments: > > > > I want to note to the list that I'm personally aware of several national > > trials of ENUM that are beginning this fall and Winter we would hope that > > some of you who are working on those trials will assist the WG in > > documenting the funcitions during those trials to assist the WG in > > completing it task of taking 2916 forward to Draft standard. > >I learned the the ENUM trial will happen in the Europe and Asia, How about >the US? The United States Government is continuing to take input from various groups both in and out of industry. There was a workshop on ENUM recently held at the US Dept of Commerce here in DC which was very well attended. >The ENUM trial will be good for developing ENUM to a useful service to the >end users, as well as the progress of standards. Several websites is set >up for information about the enum trial but most of them are not in >English, (e.g: www.enum.or.kr, >http://www.pts.se/tele_niva3.asp?avdelning=lev3_enum&uavdelning=tele_niva3&u2avdelning=workshop&lang=&header=Can >). Should people who are working on those trial use this enum mailing list >for sharing the information about the enum trial worldwide? Speaking for my Co-Chair the answer to your question is YES! I refer you to our charter.. http://www.ietf.org/html.charters/enum-charter.html and specifically to this paragraph .. "3. The Working Group will continue to maintain appropriate contact and liaison with standards bodies and groups, specifically ITU-T SG2, in order to provide technical or educational information as needed, such as the appropriate use of DNS. The Working Group will encourage the exchange of technical information within the emerging global ENUM community as well as documentation on practical experiences with implementations or administration of RFC 2916." People wishing to exchange technical information and URL's to relevant national ENUM trial documents are welcome to do so here. In particular ... the WG is very interested in seeing documentation on interoperable implementations of 2916 as part of its ongoing process to advance the Proposed Standard to Draft status. > > > > I think its also reasonable that we delay trying to work on provisioning, > > security and other issues until there are some clear results coming back > > from those trials. > > > > > > Comments? > > >Support > > >Bill > >2002/09/03 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 3 11:02:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29890 for ; Tue, 3 Sep 2002 11:02:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g83F3bf16660 for enum-archive@odin.ietf.org; Tue, 3 Sep 2002 11:03:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83F3Vo16653; Tue, 3 Sep 2002 11:03:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83F2ho16610 for ; Tue, 3 Sep 2002 11:02:43 -0400 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29856 for ; Tue, 3 Sep 2002 11:01:04 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g83F28D30745 for ; Tue, 3 Sep 2002 15:02:09 GMT Message-Id: <5.1.0.14.2.20020903110719.04410820@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 11:10:48 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] ENUM at IETF 55 in Atlanta Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Slot reservations for IETF 55 have opened and I have requested 1 2 hour slot. It looks like registration will open on Sep 9.. A reminder to you all on the draft cut off dates ...... October 28, Monday - Internet Draft cut-off for initial document (-00) submission at 09:00 ET November 4, Monday - Internet Draft final submission cut-off at 09:00 ET >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 3 11:09:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00288 for ; Tue, 3 Sep 2002 11:09:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g83FB4l17524 for enum-archive@odin.ietf.org; Tue, 3 Sep 2002 11:11:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83FB4o17518; Tue, 3 Sep 2002 11:11:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83FAqo17493 for ; Tue, 3 Sep 2002 11:10:52 -0400 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00198 for ; Tue, 3 Sep 2002 11:09:12 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g83FAHm11515 for ; Tue, 3 Sep 2002 11:10:17 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Sep 2002 10:10:17 -0500 Message-ID: <54E40201497DF142B06B27255953F7974B1FD4@il0015exch007.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Richard Shockey , Stastny Richard , =?iso-8859-1?Q?Patrik__F=E4ltstr=F6m?= , "Clive D.W. Feather" Cc: Lawrence Conroy , Rich , enum@ietf.org Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Tue, 3 Sep 2002 10:10:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g83FAuo17500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit One the most immediate uses of infrastructural ENUM does not have to do with voice calling at all. There are a host of existing, non-call associated IP services for which ENUM is enormously useful. Thse include SMS, store-and-forward fax, and voice messaging. These services need an inter-carrier routing system that can be shared between providers, but does not necessarily require end-user participation. I don't have a view as to whether these services require a separate root from the end-user services. However, I thought we beat the separate root per service (or class of services) down in favor of the NAPTR multi-service approach. Greg V. -----Original Message----- From: Richard Shockey [mailto:rshockey@ix.netcom.com] Sent: Monday, September 02, 2002 10:08 AM To: Stastny Richard; Patrik Fältström; Clive D.W. Feather Cc: Lawrence Conroy; Rich; enum@ietf.org Subject: RE: [Enum] Opt-in principle for calling users and communications providers I'm here but I still think we are talking across each other > > > > > I do not agree. If there has to be always a termination on the > > > conventional network, and if the service provider may do as > > he likes, > > > than there must be a way for the calling user to FORCE the phone > > > system not to use ENUM. > > > > > > Otherwise it would make no sense to state: > > > "All E.164 numbers must have a Public Switched Telephone Network > > > (PSTN) point of interface." > > > > No. It only means for me that if you dial on PSTN that > > number, you will get the phone connected to something. It > > might imply you hit a gateway to VoIP which in turn gateway > > the call to SIP, and you will get the call terminated. > > > > I.e. for me the sentence state that it must be possible to > > make a voice call using the E.164 number in question. Not > > that the termination point _for_the_voice_call_ must be on > > PSTN. Only that the point of interface is on PSTN, and that > > might be a gateway. > > > > This is already the case for many many E.164 numbers today > > which is IP based. > >Now we are at the point, why we need BOTH "user ENUM" and "infrastructure >ENUM" independently. > >Of course you may have a termination on the PSTN which is really on VoIP, >because the phone system is technology independant. And it is up to the >service provider, how to find his users, and of course he may do this also >with ENUM. This may be an internal DNS application or one in the "public" >DNS under whatever tree. I certainly see how a service provider may want to use DNS technology internally in his network for a "infrastructure ENUM". If a service provider begins to decompose his internal TDM network with IP based Inter-Machine Trunking or places significant numbers of Media Gateways withing their network then it makes more sense to use DNS for things like inter LATA routing than SS7. The more you use IP in a service provider network the more useless SS7 becomes, since service creation is at the edge and data routing is a function of BGP etc. These are private implementations that, I'm presuming, are not globally visible to the average user of the internet. The management of the e164.arpa namespace is specifically about what is globally visible. What is interesting to me in this converged architecture is how can a Class 5 switch determine IF the call can be terminated on a IP endpoint. At point of call ingress it is assumed that the switch has several databases available to it in order to make a call routing determination of which both a public globally visible ENUM AND a privately provisioned IP endpoint/GW database is available as well. However the choice of internal endpoint database may or may not be DNS .. it makes no difference since it is not globally viable. >BUT, this ENUM cannot be the e164.arpa, because there the entries are >controlled by the end-user and not by the service provider. I cannot >imagine a service provider having a "routing" database which can be >manipulated by the user, who may potentially break the service. Of course ... but where we seem to be crossing paths here is the difference is that one DNS tree is globally visible and the other is not. >Of course I do see your example that "you hit a gateway to VoIP which in >turn gateway the call to SIP, and you will get the call terminated", but >this is a two stage process: > >First the provider queries his ENUM to terminate the call e.g. on the >provider supplied personal user agent (PUA). The subcriber may now have a >normal SIP or H323 service and is currently attached to the Internet or >not. If not, the call is terminating on an announcement or forwarded >somewhere else. No problem here ..you are doing a internal network look up , a basic IF/THEN problem ..if there is no entry in the _internal_ endpoint database THEN query the golbal enum db. >The provider may also offer the subscriber in parallel an sip or h323 ID, >which may be used by the end-user independently on his own "user ENUM" >entry in e164.arpa to terminate the call from the Internet on the same PUA >(as envisaged with +87810) Or actually on his PSTN endpoint as well, this could work either way +87810 would not be necessary. This is a excellent point ..I do believe service providers will offer to their customers sip addresses mapped to their PSTN endpoints. There is a business case and service logic for doing this. The sip address simply maps to a GW which then rings the PSTN phone...this is then a called party pays or a personal freephone like service. >Alternatively the user may have an agreement with the service provider, >that any call incoming from the PSTN via the gateway is first hitting the >PUA (by querying "infrastructure ENUM", which in turn queries "User ENUM" >and then forwards the call another SIP or H323 termination. Exactly >This would BTW be a nice way to port a number from PSTN first to an IP >based provider and then out on the Internet;-) > >Richard >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 3 11:21:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01009 for ; Tue, 3 Sep 2002 11:21:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g83FMEW05614 for enum-archive@odin.ietf.org; Tue, 3 Sep 2002 11:22:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83FMCo05609; Tue, 3 Sep 2002 11:22:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83FJso05470 for ; Tue, 3 Sep 2002 11:19:54 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00834 for ; Tue, 3 Sep 2002 11:18:15 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g83FHMVg010988; Tue, 3 Sep 2002 11:17:22 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g83FHLpS010987; Tue, 3 Sep 2002 11:17:21 -0400 (EDT) Date: Tue, 3 Sep 2002 11:17:20 -0400 From: Michael Mealling To: "Vaudreuil, Greg M (Greg)" Cc: Richard Shockey , Stastny Richard , Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , "Clive D.W. Feather" , Lawrence Conroy , Rich , enum@ietf.org Subject: Re: [Enum] Opt-in principle for calling users and communications providers Message-ID: <20020903111720.C10701@bailey.dscga.com> Reply-To: Michael Mealling References: <54E40201497DF142B06B27255953F7974B1FD4@il0015exch007.ih.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E40201497DF142B06B27255953F7974B1FD4@il0015exch007.ih.lucent.com> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Tue, Sep 03, 2002 at 10:10:15AM -0500, Vaudreuil, Greg M (Greg) wrote: > I don't have a view as to whether these services > require a separate root from the end-user services. However, I thought > we beat the separate root per service (or class of services) down in > favor of the NAPTR multi-service approach. I thought we had too. In fact, I'd like someone to explain why simply designating "infrastructure" enum-services as opposed to "user-designated" enum-services isn't sufficient? When the user signs up with a service they explicitly delegate the ability for their infrastructure provider to insert "infrastructure" class NAPTR records in there for them but that "user-designated" enum-services are still at the users discretion.... What's wrong with that model? -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 3 13:43:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06730 for ; Tue, 3 Sep 2002 13:43:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g83HikZ08831 for enum-archive@odin.ietf.org; Tue, 3 Sep 2002 13:44:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83Hieo08825; Tue, 3 Sep 2002 13:44:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83HhYo08780 for ; Tue, 3 Sep 2002 13:43:34 -0400 Received: from auemail1.firewall.lucent.com ([192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06578 for ; Tue, 3 Sep 2002 13:41:55 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g83HgvX07570 for ; Tue, 3 Sep 2002 13:42:57 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Sep 2002 12:42:57 -0500 Message-ID: <54E40201497DF142B06B27255953F7974B215E@il0015exch007.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Michael Mealling , "Vaudreuil, Greg M (Greg)" Cc: Richard Shockey , Stastny Richard , Patrik Faltstrom , "Clive D.W. Feather" , Lawrence Conroy , Rich , enum@ietf.org Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Tue, 3 Sep 2002 12:42:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >On Tue, Sep 03, 2002 at 10:10:15AM -0500, Vaudreuil, Greg M (Greg) wrote: >> I don't have a view as to whether these services >> require a separate root from the end-user services. However, I thought >> we beat the separate root per service (or class of services) down in >> favor of the NAPTR multi-service approach. >I thought we had too. In fact, I'd like someone to explain why simply >designating "infrastructure" enum-services as opposed to "user-designated" >enum-services isn't sufficient? When the user signs up with a service >they explicitly delegate the ability for their infrastructure provider >to insert "infrastructure" class NAPTR records in there for them but >that "user-designated" enum-services are still at the users discretion.... >What's wrong with that model? A few problems come to mind... some we have been discussing for a while. 1) There is an opportunity to have too many NAPTR records for a single entry, requiring TCP and slowing down the retrieval. 2) The DNS does not provide an easy way to have separate authorities mastering some records and another authority mastering the others. Infrastructure records are likely to be mastered by a telco-ish entity and end-user records are likely to be a registrar-like entity. Making one dependant upon the other for updates makes initial deployment technically and politically messy. (Have we discussed this enough yet?) 3) It is tough to have separate access policies and privacy constraints for records in the same entry, i.e., Opt-in for end-user services, mandatory but privacy protected for infrastructure entries. It is easier to have diverging policies and control under different roots. Greg V. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 3 13:56:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07291 for ; Tue, 3 Sep 2002 13:56:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g83HvAo09339 for enum-archive@odin.ietf.org; Tue, 3 Sep 2002 13:57:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83Hv9o09332; Tue, 3 Sep 2002 13:57:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83HuAo09301 for ; Tue, 3 Sep 2002 13:56:10 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07239 for ; Tue, 3 Sep 2002 13:54:30 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g83HrcVg011464; Tue, 3 Sep 2002 13:53:38 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g83Hrbpb011463; Tue, 3 Sep 2002 13:53:37 -0400 (EDT) Date: Tue, 3 Sep 2002 13:53:37 -0400 From: Michael Mealling To: "Vaudreuil, Greg M (Greg)" Cc: Michael Mealling , Richard Shockey , Stastny Richard , Patrik Faltstrom , "Clive D.W. Feather" , Lawrence Conroy , Rich , enum@ietf.org Subject: Re: [Enum] Opt-in principle for calling users and communications providers Message-ID: <20020903135337.H10701@bailey.dscga.com> Reply-To: Michael Mealling References: <54E40201497DF142B06B27255953F7974B215E@il0015exch007.ih.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E40201497DF142B06B27255953F7974B215E@il0015exch007.ih.lucent.com> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Tue, Sep 03, 2002 at 12:42:46PM -0500, Vaudreuil, Greg M (Greg) wrote: > >On Tue, Sep 03, 2002 at 10:10:15AM -0500, Vaudreuil, Greg M (Greg) wrote: > >> I don't have a view as to whether these services > >> require a separate root from the end-user services. However, I thought > >> we beat the separate root per service (or class of services) down in > >> favor of the NAPTR multi-service approach. > > >I thought we had too. In fact, I'd like someone to explain why simply > >designating "infrastructure" enum-services as opposed to "user-designated" > >enum-services isn't sufficient? When the user signs up with a service > >they explicitly delegate the ability for their infrastructure provider > >to insert "infrastructure" class NAPTR records in there for them but > >that "user-designated" enum-services are still at the users discretion.... > > >What's wrong with that model? > > A few problems come to mind... some we have been discussing for a while. > > 1) There is an opportunity to have too many NAPTR records for a single > entry, requiring TCP and slowing down the retrieval. True, but a consideration for anything with DNS... > 2) The DNS does not provide an easy way to have separate authorities > mastering some records and another authority mastering the others. > Infrastructure records are likely to be mastered by a telco-ish entity > and end-user records are likely to be a registrar-like entity. Making > one dependant upon the other for updates makes initial deployment > technically and politically messy. (Have we discussed this enough yet?) The DNS doesn't but that's not DNS's job. We have solutions to this right now: My ISP puts things in my domain all the time: mx records, etc. But I can request them to put specific domains in there if I need them. Its the whole reason we have Technical Contacts seperate from Administrative Contacts, the Technical Contact has abilities and can be seperate from the Administrative. Seems easy enough to me.. > 3) It is tough to have separate access policies and privacy > constraints for records in the same entry, i.e., Opt-in for end-user > services, mandatory but privacy protected for infrastructure entries. > It is easier to have diverging policies and control under different > roots. All of those requirements have to do with how the record gets in the zone which DNS has _zero_ to do with. If you have policies and privacy issues with how records get into the zone then it sounds like you want some of the more interesting features of EPP to maintain how/when records get inserted. Given the fact that my ISP and I share the ability to edit my zone file I still can't see problem.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 3 14:22:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08212 for ; Tue, 3 Sep 2002 14:22:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g83INF013636 for enum-archive@odin.ietf.org; Tue, 3 Sep 2002 14:23:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83INDo13631; Tue, 3 Sep 2002 14:23:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83IMMo13596 for ; Tue, 3 Sep 2002 14:22:22 -0400 Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08192 for ; Tue, 3 Sep 2002 14:20:42 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g83IMFI29286 for ; Tue, 3 Sep 2002 14:22:16 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Sep 2002 13:22:15 -0500 Message-ID: <54E40201497DF142B06B27255953F7974B21B6@il0015exch007.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Michael Mealling , "Vaudreuil, Greg M (Greg)" Cc: Richard Shockey , Stastny Richard , Patrik Faltstrom , "Clive D.W. Feather" , Lawrence Conroy , Rich , enum@ietf.org Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Tue, 3 Sep 2002 13:22:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , You missed my point on the third item. Access control of records is not a natural DNS thing. If using a separate root, I can use split-horizon techniques or filtering or custom server code or whatever... to limit outside access to particular records. This is much harder to do with DNS technology with a single entry that covers entries subject to different privacy policies. Again, as I said earlier, I am somewhat neutral as to which approach is taken. My list was in response to your solicitation of negative aspects of the single-root approach. Greg V. >> 3) It is tough to have separate access policies and privacy >> constraints for records in the same entry, i.e., Opt-in for end-user >> services, mandatory but privacy protected for infrastructure entries. >> It is easier to have diverging policies and control under different >> roots. > >All of those requirements have to do with how the record gets in the zone >which DNS has _zero_ to do with. If you have policies and privacy issues >with how records get into the zone then it sounds like you want some of the >more interesting features of EPP to maintain how/when records get inserted. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 3 17:49:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15446 for ; Tue, 3 Sep 2002 17:49:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g83LoDx26608 for enum-archive@odin.ietf.org; Tue, 3 Sep 2002 17:50:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83LoAo26603; Tue, 3 Sep 2002 17:50:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83Lmho26502 for ; Tue, 3 Sep 2002 17:48:43 -0400 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15366 for ; Tue, 3 Sep 2002 17:46:59 -0400 (EDT) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g83LljD09570; Tue, 3 Sep 2002 21:47:45 GMT Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Sep 2002 17:48:50 -0400 Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E38B183@STNTEXCH1> From: "Yu, James" To: "'Michael Mealling'" Cc: enum@ietf.org Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Tue, 3 Sep 2002 17:47:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g83Lmho26503 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Mike, One problem is that number portability will impact ENUM even if the ENUM end user does not change the Tier 2 Nameserver Provider (one that provider NAPTR RR hosting service). Those NAPTR RRs associated with the old telephony SP must be removed and be replaced with those from the new telephony SP if it has use of ENUM. It would be a nightmare to do it over the ENUM provisioning process. Also another problem is who, the telephony SP or the ENUM end user, decides which Tier 2 Nameserver Provider to use for hosting the NAPTR RRs. Telephony SP would not want to have their critical NAPTR RRs on ENUM end user's nameservers (if may be just one nameserver if the ENUM end user chooses) located in the basement. James > -----Original Message----- > From: Michael Mealling [mailto:michael@neonym.net] > Sent: Tuesday, September 03, 2002 11:17 AM > To: Vaudreuil, Greg M (Greg) > Cc: Richard Shockey; Stastny Richard; Patrik Fältström; Clive D.W. > Feather; Lawrence Conroy; Rich; enum@ietf.org > Subject: Re: [Enum] Opt-in principle for calling users and > communications providers > > > On Tue, Sep 03, 2002 at 10:10:15AM -0500, Vaudreuil, Greg M > (Greg) wrote: > > I don't have a view as to whether these services > > require a separate root from the end-user services. > However, I thought > > we beat the separate root per service (or class of > services) down in > > favor of the NAPTR multi-service approach. > > I thought we had too. In fact, I'd like someone to explain why simply > designating "infrastructure" enum-services as opposed to > "user-designated" > enum-services isn't sufficient? When the user signs up with a service > they explicitly delegate the ability for their infrastructure provider > to insert "infrastructure" class NAPTR records in there for them but > that "user-designated" enum-services are still at the users > discretion.... > > What's wrong with that model? > > -MM > > -- > -------------------------------------------------------------- > ------------------ > Michael Mealling | Vote Libertarian! | urn:pin:1 > michael@neonym.net | | http://www.neonym.net ---------------------------------------------------------------------------- ---- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 04:11:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20082 for ; Wed, 4 Sep 2002 04:11:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g848Cde03257 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 04:12:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g848Cao03251; Wed, 4 Sep 2002 04:12:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83LvMo26928 for ; Tue, 3 Sep 2002 17:57:22 -0400 Received: from cypress.neustar.com (cypress.neustar.com [209.173.57.84]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15648 for ; Tue, 3 Sep 2002 17:55:42 -0400 (EDT) Received: from chiimc01.il.neustar.com (chiimc01.il.neustar.com [192.168.23.38]) by cypress.neustar.com (8.11.6/8.11.6) with ESMTP id g83LthM22091; Tue, 3 Sep 2002 21:55:43 GMT Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Sep 2002 16:55:43 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB158@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Stastny Richard'" , Richard Shockey , =?iso-8859-1?Q?Patrik___F=E4ltstr=F6m?= , "Clive D.W. Feather" Cc: Lawrence Conroy , enum@ietf.org Subject: enum URI (was RE: [Enum] Opt-in principle for calling users and communications providers) Date: Tue, 3 Sep 2002 16:55:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g83LvNo26929 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I think we know what at least one problem is: whether or not we need a new ENUM URI scheme. If this discussion has been intended, as it seemed at the outset, to illustrate that the distinction between 'carrier' and 'end-user' ENUM (or however we cast it) somehow motivates the ENUM URI, I missed the argument. I for one continue to believe that the ENUM URI is unnecessary. ENUM takes as its input a telephone number, not a URI, and ENUM tells you how to reach resources associated with that number on the Internet. The number I dial into an IP phone isn't a URI. The called party number field of an IAM that arrives at a PSTN-IP gateway doesn't contain a URI. Nothing about a telephone number tells you whether or not you should use ENUM (and by extension, when to use an ENUM URI), or indeed anything about how it should be handled on the Internet - telephone numbers are opaque. Hence in the absence of ENUM you need a tel URL, which is used as a bucket into which you dump raw telephone numbers that you don't know how to reach on the Internet. Devices like the ones I describe above would use tel URLs when they are unable to discover the URI of any Internet resource via an ENUM query for a raw telephone number. Of course, nothing prevents a user from typing in a URI containing a telephone number, for whatever reason. While one might choose to put a telephone number as contact information on an Internet document (say a web page, or an email sig), the idea of providing a telephone number in that fashion which can be ONLY be used to perform an ENUM query really misses the point of ENUM, I think. The ENUM URI in this case would be an opaque pointer to a set of communications records, but this requirement could be fulfilled by any number of existing URI schemes that have no bearing on telephone numbers (I'm sure DDDS would allow this in any number of ways). In fact, why do a query at all... you could just stick the communications records into the document itself and do away with the middleman telephone number - but a call arriving at a PSTN gateway does not have that option, it can only express a telephone number. That's why ENUM is important and necessary. Why broaden ENUM to encompass generic requirements that are already met by any number of protocols, rather than focusing on the unique requirement ENUM was designed to satisfy? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, September 03, 2002 3:08 AM > To: Richard Shockey; Patrik Fältström; Clive D.W. Feather > Cc: Lawrence Conroy; enum@ietf.org > Subject: RE: [Enum] Opt-in principle for calling users and > communications providers > > > Hi Rich, > > As we discussed this issue already, I think we both agree > that this problem is very complex and in general I think we > do not even know completely, what the problem is. And I see > also from these discussions, that there are many different > views and standpoints out there. So maybe we should take a > step back and define the problem first and then discuss about > solutions. > > Anyway, one thing is obvious, if we want to > upgrade/migrate/replace the global public phone system, we > have to provide at least onother global and public phone > system and not a mess of private databases. This was BTW one > of the reasons, that IN was never really available for global > services. All IN systems where only available _privately_ in > operators networks or in some cases nationally, but never globally. > > Rest of the comments inline > Richard > > PS: I am still waiting for your input related to SG2 on service codes. > > Richard STASTNY > OeFEG/Telekom Austria > Box 147, A-1103 Vienna, Austria > tel:+43 664 420 4100 > fax:+43 1 797 80 13 > mailto:richard.stastny@oefeg.at > > > -----Original Message----- > > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > > Sent: Monday, September 02, 2002 10:38 PM > > To: Stastny Richard; Patrik Fältström; Clive D.W. Feather > > Cc: Lawrence Conroy; enum@ietf.org > > Subject: RE: [Enum] Opt-in principle for calling users and > > communications providers > > > > > > > > Correct .. but this could start out as a private database > > exchange between > > cooperating service providers. The problem statement you > > describe does not > > have to be a "end world hunger" solution in the beginning. > > You are correct > > that this has some similarities to the LNP problem. > > Cooperating service > > providers could exchange end point/GW data privately to > > provision local and > > non globally visable DNS servers using either end point URI's > > or as you > > suggest LDAP look up's etc. The exchange of data could occur > > by any number > > of means ..or as the N(2) problem occurs some arrangement > > could be made to > > aggrate the data and then redistribute it to service providers in a > > mutually acceptable manner which then updates the local > > non-visable DNS > > servers (aka the new new SCP's). > > > > If TRIP were introduced internally to a SP network then the global > > advertisement for endpoint resolution could be single > > hostname. TRIP then > > could hide the actual location of GW within the service > > providers domain > > boundry. > > I even would not go into so much detail at the beginning, the > first question is to give the originator a hint (pointer) > where to find the destination (network or GW or whatever) for > a given number. Thats what ENUM is for. The rest could then > be done in your way (or in another). > > > > > >You could use e164.arpa ENUM for this, but the problem > starts, if you > > >have, as you mentioned, a _public/globally visible AND a privately > > >provisioned IP endpoint/GW database_. > > > > Using e164.arpa for this is IMHO not a good idea since I ( as > > a service > > provider) would not want to expose business relationships > > between service > > providers in global DNS tree, should such data be exchanged. > > This goes now > > to the heart of the convergence problem ... the Internet > > operates on a > > transit/peering model (aka bill and keep) while global TDM > > telephony relies > > on reciprocal compensation. The optimal transaction/business > > model in IP > > Telephony keeps OSS billing costs to a minimum. > > > The current model in TDM (for normal calls) is cascading, > where the origination network bills the subscriber and > cascades the money to the following networks, up to the > destination network. > Maybe this model has to change anyway: e.g. every user is > paying for what he is reponsible for. > We have this discussion currently with MNP, because we have > no air-time and different charges to different mobile networks. > > So the origination subscriber pays to reach the destination > network, but not the destination network itself. If he his > paying nothing to reach the destination network (or only the > access) fine. It is then up to the called user to pay to be > reached where he wants to be reached. > > > > > I think you agree that there is much fruitful work to be done > > in this area. > > It is not clear to me at all how C5 elements will eventually > > discover that > > some endpoints can be reached over IP. > > > > We could certainly whiteboard out a dozen or more ways to do > > this for both > > the C5 elements and the exchange of GW endpoint data > between SP's for > > hosted or network oriented services. > > > > That's why standards are wonderful ...there are so many of them! :-) > > Ok fine, where and when? > > > >Only if the calling user subscribes an _ENUM Preselection_ > or does a > > >call-by-call _selection_, user ENUM is queried first. > > > > Actually I think this is a _called party Preselection_ If I > > register my > > number in ENUM I have essentially stated that it is MY > > preference to have > > the call terminated to me on IP where I can establish more > effective > > control..what the calling party want is irrelevant. > > This is exactly what I said above: calling and called user > should control and eventually pay for what they are > responsible and what they can control. > > If you look at the TIPHON model (see Pauls presentation at > the NGN-Summit in Brugge), you have an originating user > attached to an originating serving (access) network) who is > calling via his home network (signalling) hosting the PUA the > home network (PUA) of the called user. The called user may > also be attached to a serving destination network. Between > each of the four networks there may be additional transit > networks, the media could finally go directly from the orig > serving network to the dest serving network. What is payed > IMHO in the future is mainly the access on both sides (fixed, > ADSL, cable, GPRS, WLAN, etc.) and the hosting of the > Personal User Agents (PUA) on both sides. > > > > This again goes back to the core issue we were dealing with > > in Yokohama > > ...where does call control reside. I have taken the view > > that for privacy > > reasons and various others it is the called party that > actually is in > > control of the call session ..not the calling party. I choose > > not to expose > > any data in the global DNS except the absolute minimum necessary to > > establish a session between who is calling me and my > > endpoints. I delegate > > to my SIP proxy or other SRS/Presence server the control of > > how/when and by > > what manner I choose to be contacted. > > The privacy issues are handled by the PUAs, and you should > consider that the calling party also have a PUA. In the UCI > approach finally the PUAs will negotiate. > > > The opposite view ..is of course that the calling party wants > > control and > > want the maximum flexibility in selecting how and by what > > means the called > > party is contacted. This argues for what you and Ranali/Walter have > > proposed. Both are legitimate technival views but I submit > > it is up to the > > end user to decide. > > I think both sides have their share, as stated above. > > Regards > Richard > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 06:11:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21677 for ; Wed, 4 Sep 2002 06:11:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84ACra09945 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 06:12:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84ACno09939; Wed, 4 Sep 2002 06:12:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84A9Uo09810 for ; Wed, 4 Sep 2002 06:09:30 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21619 for ; Wed, 4 Sep 2002 06:07:52 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [Enum] Opt-in principle for calling users and communications providers MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 4 Sep 2002 12:11:33 +0200 Message-ID: <06CF906FE3998C4E944213062009F162024766@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Opt-in principle for calling users and communications providers Thread-Index: AcJTlL+J8/dhEThYR0CmwMyfa3o0xgAXRb3A From: "Stastny Richard" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g84A9Uo09811 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit To summarize my view of this discussion: 1. I still think that shall be possible to have information related to end-users (_User ENUM_) AND information required by operators (_infrastructure ENUM_ ) in ENUM. 2. I also think, that a _global infrastructure ENUM_ is necessary, to avoid from the beginning the IN mess with different, non interworking databases. The information is distrubuted in ENUM anyway and may also point (e.g. via ldap) to other databases. For the avoidance of doubt, this does not prevent single operators or (con)federations or companies (PBX, private networks) to use within their networks what they want, even ENUM. 3. They usage of _infrastructure ENUM_ will be number portability (all types, even global) and advertisement of IP-based PoIs for various purposes (carrier bypass, reducing TDM-IP transits etc.), as described in draft-stastny-enum-scenarios-00.txt 4. Also for the avoidance of doubt, I do not request in any case a second golden tree, if somebody shows me exactly, how both scenarios can be implemented in the one e164.arpa tree. We have discussed the problem at lenght internally, and we have already some ideas, but we did not come up yet with a consistent solution to solve two important problems: A. Mixing of infrastructure information requested by an operator and the information requested and controlled by the user in the Tier 2 choosen by the subsciber. (Mike: I do not think your assumption works, if the TSP, the ISP(s) and the Tier 2 Nameserver provider are differnt entities - see also James administrative nightmare comment) B. Mixing of information related to numbering blocks (wildcard) and information related to a single number within this block. I understand, that IETF is currently not looking at the provisioning processes, but e.g. from the US ENUM forum documents one clearly can see, that it already complicated enough. Regards Richard Richard STASTNY OeFEG/Telekom Austria Box 147, A-1103 Vienna, Austria tel:+43 664 420 4100 fax:+43 1 797 80 13 mailto:richard.stastny@oefeg.at _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 09:21:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27428 for ; Wed, 4 Sep 2002 09:21:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84DN5a20638 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 09:23:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84DN1o20631; Wed, 4 Sep 2002 09:23:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84DLCo20490 for ; Wed, 4 Sep 2002 09:21:12 -0400 Received: from rainier.illuminet.com ([63.116.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27226 for ; Wed, 4 Sep 2002 09:19:34 -0400 (EDT) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id GAA19139; Wed, 4 Sep 2002 06:20:30 -0700 (PDT) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2656.59) id ; Wed, 4 Sep 2002 06:19:26 -0700 Message-ID: <7016B23F645D5F4B9A652F7A559698FE3B73F1@opwinexrec01.corp.illuminet.com> From: Kevin McCandless To: "'Yu, James'" Cc: enum@ietf.org, "'Michael Mealling'" Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Wed, 4 Sep 2002 06:19:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g84DLGo20498 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit James, I fail to see how NP impacts ENUM. If my number stays the same and that is the url people use to resolve to obtain my URIs, then what has changed? Kevin............... > -----Original Message----- > From: Yu, James [mailto:james.yu@neustar.biz] > Sent: Tuesday, September 03, 2002 4:48 PM > To: 'Michael Mealling' > Cc: enum@ietf.org > Subject: RE: [Enum] Opt-in principle for calling users and > communications providers > > > Mike, > > One problem is that number portability will impact ENUM even > if the ENUM end > user does not change the Tier 2 Nameserver Provider (one that > provider NAPTR > RR hosting service). Those NAPTR RRs associated with the old > telephony SP > must be removed and be replaced with those from the new > telephony SP if it > has use of ENUM. It would be a nightmare to do it over the ENUM > provisioning process. Also another problem is who, the > telephony SP or the > ENUM end user, decides which Tier 2 Nameserver Provider to > use for hosting > the NAPTR RRs. Telephony SP would not want to have their > critical NAPTR RRs > on ENUM end user's nameservers (if may be just one nameserver > if the ENUM > end user chooses) located in the basement. > > James > > > -----Original Message----- > > From: Michael Mealling [mailto:michael@neonym.net] > > Sent: Tuesday, September 03, 2002 11:17 AM > > To: Vaudreuil, Greg M (Greg) > > Cc: Richard Shockey; Stastny Richard; Patrik Fältström; Clive D.W. > > Feather; Lawrence Conroy; Rich; enum@ietf.org > > Subject: Re: [Enum] Opt-in principle for calling users and > > communications providers > > > > > > On Tue, Sep 03, 2002 at 10:10:15AM -0500, Vaudreuil, Greg M > > (Greg) wrote: > > > I don't have a view as to whether these services > > > require a separate root from the end-user services. > > However, I thought > > > we beat the separate root per service (or class of > > services) down in > > > favor of the NAPTR multi-service approach. > > > > I thought we had too. In fact, I'd like someone to explain > why simply > > designating "infrastructure" enum-services as opposed to > > "user-designated" > > enum-services isn't sufficient? When the user signs up with > a service > > they explicitly delegate the ability for their > infrastructure provider > > to insert "infrastructure" class NAPTR records in there for them but > > that "user-designated" enum-services are still at the users > > discretion.... > > > > What's wrong with that model? > > > > -MM > > > > -- > > -------------------------------------------------------------- > > ------------------ > > Michael Mealling | Vote Libertarian! | urn:pin:1 > > michael@neonym.net | | > http://www.neonym.net > -------------------------------------------------------------- > -------------- > ---- > !! The Trailblazer spacecraft is going to the Moon! And for > just $2500 a > gram !! > !! you can send something along with it! Business cards, > momentos, cremains, > !!|| anything! See http://www.transorbital.net for details! > !! > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 09:35:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28338 for ; Wed, 4 Sep 2002 09:35:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84Db3s22059 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 09:37:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Db2o22053; Wed, 4 Sep 2002 09:37:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84DZjo21955 for ; Wed, 4 Sep 2002 09:35:45 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28254 for ; Wed, 4 Sep 2002 09:34:06 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g84CtMVg013968; Wed, 4 Sep 2002 08:55:22 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g84CtLBd013967; Wed, 4 Sep 2002 08:55:21 -0400 (EDT) Date: Wed, 4 Sep 2002 08:55:21 -0400 From: Michael Mealling To: Stastny Richard Cc: enum@ietf.org Subject: Re: [Enum] Opt-in principle for calling users and communications providers Message-ID: <20020904085521.M10701@bailey.dscga.com> Reply-To: Michael Mealling References: <06CF906FE3998C4E944213062009F162024766@oefeg-s02.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06CF906FE3998C4E944213062009F162024766@oefeg-s02.oefeg.loc> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Wed, Sep 04, 2002 at 12:11:33PM +0200, Stastny Richard wrote: > A. Mixing of infrastructure information requested by an operator and the > information requested and controlled by the user in the Tier 2 choosen > by the subsciber. (Mike: I do not think your assumption works, if the > TSP, the ISP(s) and the Tier 2 Nameserver provider are differnt entities > - see also James administrative nightmare comment) But why does it matter that they're different entities? My ISP and I are two different entities and we manage pretty well. It might have a few hickups in the beginning but it'll work itself out... > I understand, that IETF is currently not looking at the provisioning > processes, but e.g. from the US ENUM forum documents one clearly can > see, that it already complicated enough. Its looking at provisioning from the standpoint of EPP which has ways of handling some of this stuff. I really don't see a problem that the IETF needs to deal with anyway: each combination of provider and end-user is going to have slightly different policies about how they interact with each other in that zone... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 09:53:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29635 for ; Wed, 4 Sep 2002 09:53:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84Dsa022932 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 09:54:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84DsWo22927; Wed, 4 Sep 2002 09:54:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Drgo22906 for ; Wed, 4 Sep 2002 09:53:42 -0400 Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29566 for ; Wed, 4 Sep 2002 09:52:03 -0400 (EDT) Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g84Dle46028995 for ; Wed, 4 Sep 2002 09:53:08 -0400 (EDT) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3CE519BE03122AAE; Wed, 4 Sep 2002 09:53:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Wed, 4 Sep 2002 09:53:07 -0400 Message-ID: <62DA45D4963FA747BA1B253E266760F903A90BC5@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Enum] Opt-in principle for calling users and communications providers Thread-Index: AcJUGQvN6Y7p2i3hTYG8q6AxpdW5dwAAHWQA From: "Pfautz, Penn L, ALVAP" To: "Michael Mealling" , "Stastny Richard" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g84Drgo22907 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Mike: The subscriber vs infrastructure issue gets rapped around the competition axle. We need to allow the subscriber to choose their Tier 2. But the TSP may not like the subscriber's choice of Dingbat's DNS and not want to rely on their service for infrastructure needs. In some of the early I-Ds we tried to work out how the TSP could have special records but in the e164.arpa tree at the the number assignee selected Tier 2. It *was* ugly and, since no one seemed anxious at the time to pursue the TSP record idea we dropped it. Penn -----Original Message----- From: Michael Mealling [mailto:michael@neonym.net] Sent: Wednesday, September 04, 2002 8:55 AM To: Stastny Richard Cc: enum@ietf.org Subject: Re: [Enum] Opt-in principle for calling users and communications providers On Wed, Sep 04, 2002 at 12:11:33PM +0200, Stastny Richard wrote: > A. Mixing of infrastructure information requested by an operator and the > information requested and controlled by the user in the Tier 2 choosen > by the subsciber. (Mike: I do not think your assumption works, if the > TSP, the ISP(s) and the Tier 2 Nameserver provider are differnt entities > - see also James administrative nightmare comment) But why does it matter that they're different entities? My ISP and I are two different entities and we manage pretty well. It might have a few hickups in the beginning but it'll work itself out... > I understand, that IETF is currently not looking at the provisioning > processes, but e.g. from the US ENUM forum documents one clearly can > see, that it already complicated enough. Its looking at provisioning from the standpoint of EPP which has ways of handling some of this stuff. I really don't see a problem that the IETF needs to deal with anyway: each combination of provider and end-user is going to have slightly different policies about how they interact with each other in that zone... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 10:00:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00108 for ; Wed, 4 Sep 2002 10:00:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84E25g23335 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 10:02:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84E24o23330; Wed, 4 Sep 2002 10:02:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84E19o23297 for ; Wed, 4 Sep 2002 10:01:09 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00039 for ; Wed, 4 Sep 2002 09:59:30 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Wed, 4 Sep 2002 16:03:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <06CF906FE3998C4E944213062009F16202476A@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Opt-in principle for calling users and communications providers Thread-Index: AcJUEt2e97aup7GmThypTmI5vR6PeAABaA3w From: "Stastny Richard" To: "Michael Mealling" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g84E19o23298 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit MM wrote: > But why does it matter that they're different entities? My > ISP and I are two different entities and we manage pretty > well. It might have a few hickups in the beginning but it'll > work itself out... I see e.g. two problems: If for example a TSP decides to use ENUM for pointing to his SIP Gateway for his subscribers, e.g. to point to fixed line phones in his network. He may nicely fill up ENUM domains for these numbers (he may even use a wildcard) in any Tier 2 Nameserver (preferably his own), entering one NAPTR for each number (or a one for a block) pointing to his gateway with a SIP URL to be used by other operators. He may also decide to query the ENUM database directly from his TDM network via an IN-mediation device to get some routing information (e.g. the CIC for ported numbers). In this case he would enter Tel URIs (eventually in addition to the previously entered SIP URIs). Since he entering this information without asking the subscribers (especially in the second case, because this information is useless for a normal user querying ENUM). Now the end-user, who has the number assigned, decides to opt-in to ENUM and selects another Tier 2 Nameserver provider. Now the NAPTRs have to be transferred to the new Tier 2 Nameserver Provider, taking the operators NAPTRs over. Fine, can be done, but the TSP now has to keep track of all transferred NAPTRs and the Tier 2 Nameservers. If he wants to change now the gateway for a block of numbers, he has to change it in n Tier 2 Nameserver providers one by one Furthermore, users querying ENUM see different SIP, h323 and Tel records, some of them not useable by them. So we would also need new ENUM services, e.g. E2U+foroperatoruseonly. regards Richard STASTNY OeFEG/Telekom Austria Box 147, A-1103 Vienna, Austria tel:+43 664 420 4100 fax:+43 1 797 80 13 mailto:richard.stastny@oefeg.at _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 10:15:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00824 for ; Wed, 4 Sep 2002 10:15:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84EG8n24071 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 10:16:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EG7o24066; Wed, 4 Sep 2002 10:16:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EFho24032 for ; Wed, 4 Sep 2002 10:15:43 -0400 Received: from rainier.illuminet.com ([63.116.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00801 for ; Wed, 4 Sep 2002 10:14:03 -0400 (EDT) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id HAA23522; Wed, 4 Sep 2002 07:15:06 -0700 (PDT) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2656.59) id ; Wed, 4 Sep 2002 07:14:02 -0700 Message-ID: <7016B23F645D5F4B9A652F7A559698FE3B73F3@opwinexrec01.corp.illuminet.com> From: Kevin McCandless To: "'Stastny Richard'" Cc: enum@ietf.org, Michael Mealling Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Wed, 4 Sep 2002 07:13:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Well, the problem could be your assumption that the TSP would provide the end user with infrastructure records, such as a SIP gateway address. Maybe the TSP would actual be smarter then this and provide only a pointer to the registrant. This pointer would be entered into their Tier II providers database. This pointer directs queries to the TSPs infrastructure database the contains records for their gateway addresses. Its all vapor ware right now ;-) Kevin................ > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, September 04, 2002 9:03 AM > To: Michael Mealling > Cc: enum@ietf.org > Subject: RE: [Enum] Opt-in principle for calling users and > communications providers > > > MM wrote: > > > But why does it matter that they're different entities? My > > ISP and I are two different entities and we manage pretty > > well. It might have a few hickups in the beginning but it'll > > work itself out... > > I see e.g. two problems: > > If for example a TSP decides to use ENUM for pointing to his > SIP Gateway > for his subscribers, > e.g. to point to fixed line phones in his network. > He may nicely fill up ENUM domains for these numbers (he may > even use a > wildcard) in any Tier 2 > Nameserver (preferably his own), entering one NAPTR for each > number (or > a one for a block) pointing to his gateway with a SIP URL to > be used by > other operators. > > He may also decide to query the ENUM database directly > from his TDM network via an IN-mediation device to get some routing > information (e.g. the CIC for ported numbers). In this case he would > enter Tel URIs (eventually in addition to the > previously entered SIP URIs). > > Since he entering this information without asking the subscribers > (especially in the second > case, because this information is useless for a normal user querying > ENUM). > > Now the end-user, who has the number assigned, decides to > opt-in to ENUM > and selects another > Tier 2 Nameserver provider. Now the NAPTRs have to be > transferred to the > new Tier 2 Nameserver > Provider, taking the operators NAPTRs over. Fine, can be done, but the > TSP now has to keep > track of all transferred NAPTRs and the Tier 2 Nameservers. > If he wants > to change now the > gateway for a block of numbers, he has to change it in n Tier 2 > Nameserver providers one by one > > Furthermore, users querying ENUM see different SIP, h323 and Tel > records, some of them not > useable by them. So we would also need new ENUM services, e.g. > E2U+foroperatoruseonly. > > regards > > Richard STASTNY > OeFEG/Telekom Austria > Box 147, A-1103 Vienna, Austria > tel:+43 664 420 4100 > fax:+43 1 797 80 13 > mailto:richard.stastny@oefeg.at > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 10:16:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00902 for ; Wed, 4 Sep 2002 10:16:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84EI3s24160 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 10:18:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EI3o24155; Wed, 4 Sep 2002 10:18:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EHIo24123 for ; Wed, 4 Sep 2002 10:17:18 -0400 Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00844 for ; Wed, 4 Sep 2002 10:15:39 -0400 (EDT) Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g84Dwi4x005707 for ; Wed, 4 Sep 2002 10:16:44 -0400 (EDT) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3CE519BE03124242; Wed, 4 Sep 2002 10:16:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Wed, 4 Sep 2002 10:16:43 -0400 Message-ID: <62DA45D4963FA747BA1B253E266760F903A90C29@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Enum] Opt-in principle for calling users and communications providers Thread-Index: AcJUF9ogrzFjJ+vSTje8GsdVydznmgABYpiA From: "Pfautz, Penn L, ALVAP" To: "Kevin McCandless" , "Yu, James" Cc: , "Michael Mealling" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g84EHIo24124 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Kevin: I think that James was making the point that IF TSPs get special record in enum THEN NP complicates things, like chaging those records when the user changes TSPs. I agree there should be nmo impact on the subscriber records. Penn -----Original Message----- From: Kevin McCandless [mailto:KMcCandless@verisign.com] Sent: Wednesday, September 04, 2002 9:19 AM To: 'Yu, James' Cc: enum@ietf.org; 'Michael Mealling' Subject: RE: [Enum] Opt-in principle for calling users and communications providers James, I fail to see how NP impacts ENUM. If my number stays the same and that is the url people use to resolve to obtain my URIs, then what has changed? Kevin............... > -----Original Message----- > From: Yu, James [mailto:james.yu@neustar.biz] > Sent: Tuesday, September 03, 2002 4:48 PM > To: 'Michael Mealling' > Cc: enum@ietf.org > Subject: RE: [Enum] Opt-in principle for calling users and > communications providers > > > Mike, > > One problem is that number portability will impact ENUM even > if the ENUM end > user does not change the Tier 2 Nameserver Provider (one that > provider NAPTR > RR hosting service). Those NAPTR RRs associated with the old > telephony SP > must be removed and be replaced with those from the new > telephony SP if it > has use of ENUM. It would be a nightmare to do it over the ENUM > provisioning process. Also another problem is who, the > telephony SP or the > ENUM end user, decides which Tier 2 Nameserver Provider to > use for hosting > the NAPTR RRs. Telephony SP would not want to have their > critical NAPTR RRs > on ENUM end user's nameservers (if may be just one nameserver > if the ENUM > end user chooses) located in the basement. > > James > > > -----Original Message----- > > From: Michael Mealling [mailto:michael@neonym.net] > > Sent: Tuesday, September 03, 2002 11:17 AM > > To: Vaudreuil, Greg M (Greg) > > Cc: Richard Shockey; Stastny Richard; Patrik Fältström; Clive D.W. > > Feather; Lawrence Conroy; Rich; enum@ietf.org > > Subject: Re: [Enum] Opt-in principle for calling users and > > communications providers > > > > > > On Tue, Sep 03, 2002 at 10:10:15AM -0500, Vaudreuil, Greg M > > (Greg) wrote: > > > I don't have a view as to whether these services > > > require a separate root from the end-user services. > > However, I thought > > > we beat the separate root per service (or class of > > services) down in > > > favor of the NAPTR multi-service approach. > > > > I thought we had too. In fact, I'd like someone to explain > why simply > > designating "infrastructure" enum-services as opposed to > > "user-designated" > > enum-services isn't sufficient? When the user signs up with > a service > > they explicitly delegate the ability for their > infrastructure provider > > to insert "infrastructure" class NAPTR records in there for them but > > that "user-designated" enum-services are still at the users > > discretion.... > > > > What's wrong with that model? > > > > -MM > > > > -- > > -------------------------------------------------------------- > > ------------------ > > Michael Mealling | Vote Libertarian! | urn:pin:1 > > michael@neonym.net | | > http://www.neonym.net > -------------------------------------------------------------- > -------------- > ---- > !! The Trailblazer spacecraft is going to the Moon! And for > just $2500 a > gram !! > !! you can send something along with it! Business cards, > momentos, cremains, > !!|| anything! See http://www.transorbital.net for details! > !! > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 10:19:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01045 for ; Wed, 4 Sep 2002 10:19:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84EL8p24402 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 10:21:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EL7o24397; Wed, 4 Sep 2002 10:21:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EKYo24342 for ; Wed, 4 Sep 2002 10:20:35 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01005 for ; Wed, 4 Sep 2002 10:18:55 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g84E8QVg014234; Wed, 4 Sep 2002 10:08:26 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g84E8P9M014233; Wed, 4 Sep 2002 10:08:25 -0400 (EDT) Date: Wed, 4 Sep 2002 10:08:25 -0400 From: Michael Mealling To: "Pfautz, Penn L, ALVAP" Cc: Michael Mealling , Stastny Richard , enum@ietf.org Subject: Re: [Enum] Opt-in principle for calling users and communications providers Message-ID: <20020904100825.O10701@bailey.dscga.com> Reply-To: Michael Mealling References: <62DA45D4963FA747BA1B253E266760F903A90BC5@OCCLUST04EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62DA45D4963FA747BA1B253E266760F903A90BC5@OCCLUST04EVS1.ugd.att.com> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Wed, Sep 04, 2002 at 09:53:07AM -0400, Pfautz, Penn L, ALVAP wrote: > Mike: > The subscriber vs infrastructure issue gets rapped around the > competition axle. I figured that was part of the problem... > We need to allow the subscriber to choose their Tier 2. Divorced from the number they have? I.e. I get a number from Verizon but I get Sprint to handle my DNS? Or are we talking about TSP's who are completely third party? I.e. neither the end-user or the number asigner. > But the TSP may not like the subscriber's choice of Dingbat's DNS > and not want to rely on their service for infrastructure needs. I was suggesting the opposite way: the TSP who assigned the number chooses the DNS provider and the customer and that TSP cooperate in provisioning the zone... > In some of the early I-Ds we tried to work out how the TSP could have > special records but in the e164.arpa tree at the the number assignee > selected Tier 2. It *was* ugly and, since no one seemed anxious at the > time to pursue the TSP record idea we dropped it. (I'm starting to fall all over the acronyms)... The logical method from my point of view is I call up Bellsouth and say I want a number and I want the co-provision option for that numbers DNS entries. Bellsouth gives me a web page and an ID and I create DNS entries for it. If Bellsouth is nice enough or if I buy the option they might even give me the ability to handle the nameserver. Anyway, if I want some third party service that needs to administer an particular NAPTR record in there I give them a special userid and password for doing that... I'm probably missing something important about telephony though. But that would work for me.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 10:24:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01341 for ; Wed, 4 Sep 2002 10:24:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84EPmj24698 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 10:25:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EPko24692; Wed, 4 Sep 2002 10:25:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EO4o24628 for ; Wed, 4 Sep 2002 10:24:04 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01200 for ; Wed, 4 Sep 2002 10:22:25 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g84EMIVg014291; Wed, 4 Sep 2002 10:22:18 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g84EMHd5014290; Wed, 4 Sep 2002 10:22:17 -0400 (EDT) Date: Wed, 4 Sep 2002 10:22:17 -0400 From: Michael Mealling To: Stastny Richard Cc: Michael Mealling , enum@ietf.org Subject: Re: [Enum] Opt-in principle for calling users and communications providers Message-ID: <20020904102217.P10701@bailey.dscga.com> Reply-To: Michael Mealling References: <06CF906FE3998C4E944213062009F16202476A@oefeg-s02.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06CF906FE3998C4E944213062009F16202476A@oefeg-s02.oefeg.loc> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Wed, Sep 04, 2002 at 04:03:09PM +0200, Stastny Richard wrote: > > But why does it matter that they're different entities? My > > ISP and I are two different entities and we manage pretty > > well. It might have a few hickups in the beginning but it'll > > work itself out... > > I see e.g. two problems: > > If for example a TSP decides to use ENUM for pointing to his SIP Gateway > for his subscribers, e.g. to point to fixed line phones in his network. > He may nicely fill up ENUM domains for these numbers (he may even use a > wildcard) in any Tier 2 Nameserver (preferably his own), entering one > NAPTR for each number (or a one for a block) pointing to his gateway with > a SIP URL to be used by other operators. Sure... My ISP puts an MX record maintained by them in my zone for handling my email. They're DNS management software doesn't let me edit that record... > He may also decide to query the ENUM database directly > from his TDM network via an IN-mediation device to get some routing > information (e.g. the CIC for ported numbers). In this case he would > enter Tel URIs (eventually in addition to the previously entered SIP URIs). Sure... same situation as above... > Since he entering this information without asking the subscribers > (especially in the second case, because this information is useless > for a normal user querying ENUM). > > Now the end-user, who has the number assigned, decides to opt-in to ENUM > and selects another Tier 2 Nameserver provider. Now the NAPTRs have to > be transferred to the new Tier 2 Nameserver Provider, taking the operators > NAPTRs over. Fine, can be done, but the TSP now has to keep > track of all transferred NAPTRs and the Tier 2 Nameservers. If he wants > to change now the gateway for a block of numbers, he has to change it in > n Tier 2 Nameserver providers one by one Ok, this is the part thats broken. The user doesn't get to select another Tier 2 provider unless that user agrees to maintain _all_ of that data themselves or to opt out of the original. I don't get to use my ISP's email without using his nameservers. He won't let me use someone else's DNS and then use him for email. If I don't like that I can go find another ISP. I think we're trying to make to many things portable for some phantom competition ghost that isn't going to manifest itself. You simply can't engineer a solution here that makes everything maintainable by some other party. The number belongs to the provider, if you don't like their policies then don't spend your money there.... > Furthermore, users querying ENUM see different SIP, h323 and Tel > records, some of them not > useable by them. So we would also need new ENUM services, e.g. > E2U+foroperatoruseonly. That was my suggestion. enum-services that are 'infrastructure only'.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 10:24:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01362 for ; Wed, 4 Sep 2002 10:24:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84EQ2F24737 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 10:26:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EQ2o24732; Wed, 4 Sep 2002 10:26:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EPCo24656 for ; Wed, 4 Sep 2002 10:25:12 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01244 for ; Wed, 4 Sep 2002 10:23:33 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Wed, 4 Sep 2002 16:27:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <06CF906FE3998C4E944213062009F16202BC33@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Opt-in principle for calling users and communications providers Thread-Index: AcJUHdYlQsfz2FrCQaKqtHclOCkSZwAAACxQ From: "Stastny Richard" To: "Kevin McCandless" Cc: , "Michael Mealling" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g84EPCo24657 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Kevin McCandless [mailto:KMcCandless@verisign.com] > Sent: Wednesday, September 04, 2002 4:14 PM > To: Stastny Richard > Cc: enum@ietf.org; Michael Mealling > Subject: RE: [Enum] Opt-in principle for calling users and > communications providers > > > Well, the problem could be your assumption that the TSP would > provide the end user with infrastructure records, such as a > SIP gateway address. Maybe the TSP would actual be smarter > then this and provide only a pointer to the registrant. This > pointer would be entered into their Tier II providers > database. This pointer directs queries to the TSPs > infrastructure database the contains records for their > gateway addresses. One possibility, of course, but this does not solve the problem of two enties with different interests in the same domain. I as an operator want to use ENUM for my purposes (whatever they are) and the End-User (Registrant) wants to use ENUM for his purposes. The operator does not want the user to fiddle around with his recors and vice versa. And there is still the question who decides the tier 2 selection. > > Its all vapor ware right now ;-) > > Kevin................ > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, September 04, 2002 9:03 AM > > To: Michael Mealling > > Cc: enum@ietf.org > > Subject: RE: [Enum] Opt-in principle for calling users and > > communications providers > > > > > > MM wrote: > > > > > But why does it matter that they're different entities? My > > > ISP and I are two different entities and we manage pretty > > > well. It might have a few hickups in the beginning but it'll > > > work itself out... > > > > I see e.g. two problems: > > > > If for example a TSP decides to use ENUM for pointing to his > > SIP Gateway > > for his subscribers, > > e.g. to point to fixed line phones in his network. > > He may nicely fill up ENUM domains for these numbers (he may > > even use a > > wildcard) in any Tier 2 > > Nameserver (preferably his own), entering one NAPTR for each > > number (or > > a one for a block) pointing to his gateway with a SIP URL to > > be used by > > other operators. > > > > He may also decide to query the ENUM database directly > > from his TDM network via an IN-mediation device to get some routing > > information (e.g. the CIC for ported numbers). In this case > he would > > enter Tel URIs (eventually in addition to the previously > entered SIP > > URIs). > > > > Since he entering this information without asking the subscribers > > (especially in the second case, because this information is useless > > for a normal user querying ENUM). > > > > Now the end-user, who has the number assigned, decides to > > opt-in to ENUM > > and selects another > > Tier 2 Nameserver provider. Now the NAPTRs have to be > > transferred to the > > new Tier 2 Nameserver > > Provider, taking the operators NAPTRs over. Fine, can be > done, but the > > TSP now has to keep > > track of all transferred NAPTRs and the Tier 2 Nameservers. > > If he wants > > to change now the > > gateway for a block of numbers, he has to change it in n Tier 2 > > Nameserver providers one by one > > > > Furthermore, users querying ENUM see different SIP, h323 and Tel > > records, some of them not useable by them. So we would also > need new > > ENUM services, e.g. > > E2U+foroperatoruseonly. > > > > regards > > > > Richard STASTNY > > OeFEG/Telekom Austria > > Box 147, A-1103 Vienna, Austria > > tel:+43 664 420 4100 > > fax:+43 1 797 80 13 > > mailto:richard.stastny@oefeg.at > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 10:28:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01593 for ; Wed, 4 Sep 2002 10:28:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84EU7I24962 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 10:30:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EU6o24956; Wed, 4 Sep 2002 10:30:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EQXo24778 for ; Wed, 4 Sep 2002 10:26:33 -0400 Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01363 for ; Wed, 4 Sep 2002 10:24:54 -0400 (EDT) Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g84E0oNF018188 for ; Wed, 4 Sep 2002 09:25:59 -0500 (CDT) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3CE519BE03124903; Wed, 4 Sep 2002 10:25:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Wed, 4 Sep 2002 10:25:58 -0400 Message-ID: <62DA45D4963FA747BA1B253E266760F903A90C4A@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Enum] Opt-in principle for calling users and communications providers Thread-Index: AcJUHjcD1syIdbo5Tu2BbVyR5nEOwgAAEBLQ From: "Pfautz, Penn L, ALVAP" To: "Michael Mealling" Cc: "Stastny Richard" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g84EQXo24779 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Mike: Indeed, the model you describe was one James and I considered, and I believe it may have been in the back of some minds in the initial thinking about ENUM. It certainly is simpler. But number portability and local service competition, at least on the US, seem likely to preclude it's implementation. -----Original Message----- From: Michael Mealling [mailto:michael@neonym.net] Sent: Wednesday, September 04, 2002 10:08 AM To: Pfautz, Penn L, ALVAP Cc: Michael Mealling; Stastny Richard; enum@ietf.org Subject: Re: [Enum] Opt-in principle for calling users and communications providers On Wed, Sep 04, 2002 at 09:53:07AM -0400, Pfautz, Penn L, ALVAP wrote: > Mike: > The subscriber vs infrastructure issue gets rapped around the > competition axle. I figured that was part of the problem... > We need to allow the subscriber to choose their Tier 2. Divorced from the number they have? I.e. I get a number from Verizon but I get Sprint to handle my DNS? Or are we talking about TSP's who are completely third party? I.e. neither the end-user or the number asigner. > But the TSP may not like the subscriber's choice of Dingbat's DNS > and not want to rely on their service for infrastructure needs. I was suggesting the opposite way: the TSP who assigned the number chooses the DNS provider and the customer and that TSP cooperate in provisioning the zone... > In some of the early I-Ds we tried to work out how the TSP could have > special records but in the e164.arpa tree at the the number assignee > selected Tier 2. It *was* ugly and, since no one seemed anxious at the > time to pursue the TSP record idea we dropped it. (I'm starting to fall all over the acronyms)... The logical method from my point of view is I call up Bellsouth and say I want a number and I want the co-provision option for that numbers DNS entries. Bellsouth gives me a web page and an ID and I create DNS entries for it. If Bellsouth is nice enough or if I buy the option they might even give me the ability to handle the nameserver. Anyway, if I want some third party service that needs to administer an particular NAPTR record in there I give them a special userid and password for doing that... I'm probably missing something important about telephony though. But that would work for me.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 10:29:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01606 for ; Wed, 4 Sep 2002 10:29:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84EU9624995 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 10:30:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EU8o24988; Wed, 4 Sep 2002 10:30:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EQmo24784 for ; Wed, 4 Sep 2002 10:26:48 -0400 Received: from rainier.illuminet.com ([63.116.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01384 for ; Wed, 4 Sep 2002 10:25:08 -0400 (EDT) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id HAA24274; Wed, 4 Sep 2002 07:25:22 -0700 (PDT) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2656.59) id ; Wed, 4 Sep 2002 07:24:18 -0700 Message-ID: <7016B23F645D5F4B9A652F7A559698FE3B73F4@opwinexrec01.corp.illuminet.com> From: Kevin McCandless To: "'Pfautz, Penn L, ALVAP'" Cc: enum@ietf.org, Michael Mealling , "Yu, James" Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Wed, 4 Sep 2002 07:24:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g84EQmo24785 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Penn: Glad you chimed into the thread. If TSPs are going to populate registrant records with authoritative database information, LNP for example, then there is a major risk that this information will no longer be authority if it becomes under the control of the registrant. Since the registrant can use any Tier II provider they want why would a TSP take this risk? My only suggestion is that the most a TSP would be willing to risk is a pointer in the registrants NAPTRs that would redirect the query to the TSPs authoritative database. This would allow the TSPs database to remain authoritative and remain COMPLETELY within their control. K............. > -----Original Message----- > From: Pfautz, Penn L, ALVAP [mailto:ppfautz@att.com] > Sent: Wednesday, September 04, 2002 9:17 AM > To: Kevin McCandless; Yu, James > Cc: enum@ietf.org; Michael Mealling > Subject: RE: [Enum] Opt-in principle for calling users and > communications providers > > > Kevin: > I think that James was making the point that IF TSPs get > special record in enum THEN NP complicates things, like > chaging those records when the user changes TSPs. I agree > there should be nmo impact on the subscriber records. > > Penn > > -----Original Message----- > From: Kevin McCandless [mailto:KMcCandless@verisign.com] > Sent: Wednesday, September 04, 2002 9:19 AM > To: 'Yu, James' > Cc: enum@ietf.org; 'Michael Mealling' > Subject: RE: [Enum] Opt-in principle for calling users and > communications providers > > > James, > > I fail to see how NP impacts ENUM. If my number stays the > same and that is > the url people use to resolve to obtain my URIs, then what > has changed? > > Kevin............... > > > -----Original Message----- > > From: Yu, James [mailto:james.yu@neustar.biz] > > Sent: Tuesday, September 03, 2002 4:48 PM > > To: 'Michael Mealling' > > Cc: enum@ietf.org > > Subject: RE: [Enum] Opt-in principle for calling users and > > communications providers > > > > > > Mike, > > > > One problem is that number portability will impact ENUM even > > if the ENUM end > > user does not change the Tier 2 Nameserver Provider (one that > > provider NAPTR > > RR hosting service). Those NAPTR RRs associated with the old > > telephony SP > > must be removed and be replaced with those from the new > > telephony SP if it > > has use of ENUM. It would be a nightmare to do it over the ENUM > > provisioning process. Also another problem is who, the > > telephony SP or the > > ENUM end user, decides which Tier 2 Nameserver Provider to > > use for hosting > > the NAPTR RRs. Telephony SP would not want to have their > > critical NAPTR RRs > > on ENUM end user's nameservers (if may be just one nameserver > > if the ENUM > > end user chooses) located in the basement. > > > > James > > > > > -----Original Message----- > > > From: Michael Mealling [mailto:michael@neonym.net] > > > Sent: Tuesday, September 03, 2002 11:17 AM > > > To: Vaudreuil, Greg M (Greg) > > > Cc: Richard Shockey; Stastny Richard; Patrik Fältström; Clive D.W. > > > Feather; Lawrence Conroy; Rich; enum@ietf.org > > > Subject: Re: [Enum] Opt-in principle for calling users and > > > communications providers > > > > > > > > > On Tue, Sep 03, 2002 at 10:10:15AM -0500, Vaudreuil, Greg M > > > (Greg) wrote: > > > > I don't have a view as to whether these services > > > > require a separate root from the end-user services. > > > However, I thought > > > > we beat the separate root per service (or class of > > > services) down in > > > > favor of the NAPTR multi-service approach. > > > > > > I thought we had too. In fact, I'd like someone to explain > > why simply > > > designating "infrastructure" enum-services as opposed to > > > "user-designated" > > > enum-services isn't sufficient? When the user signs up with > > a service > > > they explicitly delegate the ability for their > > infrastructure provider > > > to insert "infrastructure" class NAPTR records in there > for them but > > > that "user-designated" enum-services are still at the users > > > discretion.... > > > > > > What's wrong with that model? > > > > > > -MM > > > > > > -- > > > -------------------------------------------------------------- > > > ------------------ > > > Michael Mealling | Vote Libertarian! | urn:pin:1 > > > michael@neonym.net | | > > http://www.neonym.net > > -------------------------------------------------------------- > > -------------- > > ---- > > !! The Trailblazer spacecraft is going to the Moon! And for > > just $2500 a > > gram !! > > !! you can send something along with it! Business cards, > > momentos, cremains, > > !!|| anything! See http://www.transorbital.net for details! > > !! > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 10:36:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02089 for ; Wed, 4 Sep 2002 10:36:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84EbgN25448 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 10:37:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Ebeo25443; Wed, 4 Sep 2002 10:37:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EX8o25183 for ; Wed, 4 Sep 2002 10:33:08 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01788 for ; Wed, 4 Sep 2002 10:31:28 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Wed, 4 Sep 2002 16:35:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <06CF906FE3998C4E944213062009F16202476B@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Opt-in principle for calling users and communications providers Thread-Index: AcJUHpf+aUd0mtSpT66dxn9t/aOLdwAADtlQ From: "Stastny Richard" To: "Michael Mealling" , "Pfautz, Penn L, ALVAP" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g84EX8o25184 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit MM wrote: > > I was suggesting the opposite way: the TSP who assigned the > number chooses the DNS provider and the customer and that TSP > cooperate in provisioning the zone... But according to the models defined in ITU-T, ETSI and the US ENUM Forum it is currently the other way round: The End-User (Registrant) choses the Tier 2 Nameserver provider. Reason: Competition and what if Bellsouth, where you have your phone number is not providing a Tier 2 Service at all? So you have to change your TSP to get an ENUM Service. But maybe you should have a chat with the French regulator ;-) Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 10:43:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02695 for ; Wed, 4 Sep 2002 10:43:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84Ej7d26102 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 10:45:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Ej6o26097; Wed, 4 Sep 2002 10:45:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Ehso25937 for ; Wed, 4 Sep 2002 10:43:54 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02540 for ; Wed, 4 Sep 2002 10:42:15 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g84EbtVg014382; Wed, 4 Sep 2002 10:37:55 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g84Ebssq014381; Wed, 4 Sep 2002 10:37:54 -0400 (EDT) Date: Wed, 4 Sep 2002 10:37:54 -0400 From: Michael Mealling To: Stastny Richard Cc: Michael Mealling , "Pfautz, Penn L, ALVAP" , enum@ietf.org Subject: Re: [Enum] Opt-in principle for calling users and communications providers Message-ID: <20020904103754.R10701@bailey.dscga.com> Reply-To: Michael Mealling References: <06CF906FE3998C4E944213062009F16202476B@oefeg-s02.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06CF906FE3998C4E944213062009F16202476B@oefeg-s02.oefeg.loc> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Wed, Sep 04, 2002 at 04:35:09PM +0200, Stastny Richard wrote: > MM wrote: > > I was suggesting the opposite way: the TSP who assigned the > > number chooses the DNS provider and the customer and that TSP > > cooperate in provisioning the zone... > > But according to the models defined in ITU-T, ETSI and the US ENUM Forum > it is currently the other way round: > > The End-User (Registrant) choses the Tier 2 Nameserver provider. Reason: > Competition and what if Bellsouth, where you have your phone number is > not providing a Tier 2 Service at all? Fine. Then when that user decides who it is then they have to give the TSP limited access to provision the records it needs. If the user picks a Tier 2 provider that doesn't allow that function then the TSP is SOL. Its all just a database problem. How and why you get records in there is not ENUM's problem... > So you have to change your TSP to get an ENUM Service. > > But maybe you should have a chat with the French regulator ;-) I keep forgetting that this space is full of politicians and monopolists.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 10:44:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02724 for ; Wed, 4 Sep 2002 10:44:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84EjIN26159 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 10:45:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EjIo26154; Wed, 4 Sep 2002 10:45:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Eiao25968 for ; Wed, 4 Sep 2002 10:44:36 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02607 for ; Wed, 4 Sep 2002 10:42:57 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Wed, 4 Sep 2002 16:46:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <06CF906FE3998C4E944213062009F16202476C@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Opt-in principle for calling users and communications providers Thread-Index: AcJUF7+oCmQjFv2ASqCUrt9JiqI44wACKxzQ From: "Stastny Richard" To: "Kevin McCandless" , "Yu, James" Cc: , "Michael Mealling" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g84Eiao25969 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Kevin wrote: > James, > > I fail to see how NP impacts ENUM. If my number stays the > same and that is the url people use to resolve to obtain my > URIs, then what has changed? > There is always an ipmpact, but differnt depending on the Model used: In my model in User ENUM the party (TSP) reponsible for the validation changes, so it is an administrative issue. For infrastructure ENUM of course the domain name holder changes, the new TSP my not even use ENUM. In MMs model (mixed or TSP only in ENUM) it impacts even more, because the whole domain is ported also. Regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 10:54:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03226 for ; Wed, 4 Sep 2002 10:53:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84Et8126804 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 10:55:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Et7o26799; Wed, 4 Sep 2002 10:55:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Es1o26727 for ; Wed, 4 Sep 2002 10:54:01 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03154 for ; Wed, 4 Sep 2002 10:52:21 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Wed, 4 Sep 2002 16:56:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <06CF906FE3998C4E944213062009F16202476D@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Opt-in principle for calling users and communications providers Thread-Index: AcJUHxWC0qNgCWKWRk+LVG22d++3eAAAt3Yg From: "Stastny Richard" To: "Michael Mealling" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g84Es1o26728 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit MM wrote > > ENUM services, e.g. > > E2U+foroperatoruseonly. > > That was my suggestion. enum-services that are > 'infrastructure only'.... > Fine with me as an operator ;-) But then all groups both in the US,Europe and Geneva discussing _Administration of e164.arpa_ for two years ran 180 degrees in the wrong direction. Nice. We could have saved a lot of effort. Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 10:58:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03446 for ; Wed, 4 Sep 2002 10:58:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84ExBU27059 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 10:59:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84ExAo27052; Wed, 4 Sep 2002 10:59:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84EwEo26968 for ; Wed, 4 Sep 2002 10:58:14 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03368 for ; Wed, 4 Sep 2002 10:56:35 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g84EuSVg014500; Wed, 4 Sep 2002 10:56:28 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g84EuRqO014499; Wed, 4 Sep 2002 10:56:27 -0400 (EDT) Date: Wed, 4 Sep 2002 10:56:27 -0400 From: Michael Mealling To: Stastny Richard Cc: Michael Mealling , enum@ietf.org Subject: Re: [Enum] Opt-in principle for calling users and communications providers Message-ID: <20020904105627.T10701@bailey.dscga.com> Reply-To: Michael Mealling References: <06CF906FE3998C4E944213062009F16202476D@oefeg-s02.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06CF906FE3998C4E944213062009F16202476D@oefeg-s02.oefeg.loc> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Wed, Sep 04, 2002 at 04:56:02PM +0200, Stastny Richard wrote: > > > ENUM services, e.g. > > > E2U+foroperatoruseonly. > > > > That was my suggestion. enum-services that are > > 'infrastructure only'.... > > > Fine with me as an operator ;-) > > But then all groups both in the US,Europe and Geneva discussing > _Administration of e164.arpa_ for two years ran 180 degrees in the wrong > direction. Nice. > > We could have saved a lot of effort. Not our problem that policy wonks decided not to wait on the engineers... I'll be really glad when the last black plastic phone gets destroyed. Life will get a lot easier and way more interesting... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 11:04:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03784 for ; Wed, 4 Sep 2002 11:04:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84F67t27488 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 11:06:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84F66o27481; Wed, 4 Sep 2002 11:06:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84F53o27431 for ; Wed, 4 Sep 2002 11:05:03 -0400 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03721 for ; Wed, 4 Sep 2002 11:03:23 -0400 (EDT) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g84F4QD26636; Wed, 4 Sep 2002 15:04:26 GMT Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Sep 2002 11:05:31 -0400 Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E38B186@STNTEXCH1> From: "Yu, James" To: "'Kevin McCandless'" Cc: enum@ietf.org Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Wed, 4 Sep 2002 11:04:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Kevin, Using DNS to request for NAPTR RRs, there is no way to indicate that it is the TSP's or end user's NAPTR RRs that are to be retrieved. So you cannot have a pointer to point to the TSP's nameserver(s) for TSP's NAPTR RRs. The requestor will get all the NAPTR RRs for that particular phone number. James > -----Original Message----- > From: Kevin McCandless [mailto:KMcCandless@verisign.com] > Sent: Wednesday, September 04, 2002 10:14 AM > To: 'Stastny Richard' > Cc: enum@ietf.org; Michael Mealling > Subject: RE: [Enum] Opt-in principle for calling users and > communications providers > > > Well, the problem could be your assumption that the TSP would > provide the > end user with infrastructure records, such as a SIP gateway > address. Maybe > the TSP would actual be smarter then this and provide only a > pointer to the > registrant. This pointer would be entered into their Tier II > providers > database. This pointer directs queries to the TSPs > infrastructure database > the contains records for their gateway addresses. > > Its all vapor ware right now ;-) > > Kevin................ _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 11:24:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04773 for ; Wed, 4 Sep 2002 11:24:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84FPMJ28602 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 11:25:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84FPFo28594; Wed, 4 Sep 2002 11:25:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84FOYo28543 for ; Wed, 4 Sep 2002 11:24:34 -0400 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04696 for ; Wed, 4 Sep 2002 11:22:55 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g84FLcD27086; Wed, 4 Sep 2002 15:21:38 GMT Message-Id: <5.1.0.14.2.20020904111504.043f4e28@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 04 Sep 2002 11:29:44 -0400 To: Michael Mealling , "Pfautz, Penn L, ALVAP" From: Richard Shockey Subject: Re: [Enum] Opt-in principle for calling users and communications providers Cc: Stastny Richard , enum@ietf.org In-Reply-To: <20020904100825.O10701@bailey.dscga.com> References: <62DA45D4963FA747BA1B253E266760F903A90BC5@OCCLUST04EVS1.ugd.att.com> <62DA45D4963FA747BA1B253E266760F903A90BC5@OCCLUST04EVS1.ugd.att.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-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 10:08 AM 9/4/2002 -0400, Michael Mealling wrote: >On Wed, Sep 04, 2002 at 09:53:07AM -0400, Pfautz, Penn L, ALVAP wrote: > > Mike: > > The subscriber vs infrastructure issue gets rapped around the > > competition axle. > >I figured that was part of the problem... > > > We need to allow the subscriber to choose their Tier 2. > >Divorced from the number they have? I.e. I get a number from Verizon >but I get Sprint to handle my DNS? Or are we talking about TSP's who >are completely third party? I.e. neither the end-user or the number >asigner. Verizon may issue my telephone number but the ENUM national T1 provider points to a BIND server in my basement or I could purchase a SIP service along with DNS/NAPTR management from SPRINT. Both are perfectly valid ..what is essential is the incumbent is not in the provisioning path. > > But the TSP may not like the subscriber's choice of Dingbat's DNS > > and not want to rely on their service for infrastructure needs. > >I was suggesting the opposite way: the TSP who assigned the number >chooses the DNS provider and the customer and that TSP cooperate >in provisioning the zone... I don't think so :-) Can you spell "96 Act" ? Apologies to our European friends. That is a "US thing". > > In some of the early I-Ds we tried to work out how the TSP could have > > special records but in the e164.arpa tree at the the number assignee > > selected Tier 2. It *was* ugly and, since no one seemed anxious at the > > time to pursue the TSP record idea we dropped it. > >(I'm starting to fall all over the acronyms)... > >The logical method from my point of view is I call up Bellsouth and say >I want a number and I want the co-provision option for that numbers DNS >entries. First you cant get a US NANP number without the provisioning of PSTN service from a certified carrier... however you may be able to purchase valid e.164 numbers in the future .. aka 878 >Bellsouth gives me a web page and an ID and I create DNS entries >for it. If Bellsouth is nice enough or if I buy the option they might even >give me the ability to handle the nameserver. Anyway, if I want some third >party service that needs to administer an particular NAPTR record in there >I give them a special userid and password for doing that... That makes sense only if I am purchasing a valid service from Bell South that requires ENUM from howeverI can guarantee you that ATT and WCOM and SPRINT will not be too happy that the incumbent must be in the provisioning path for a ENUM service such as SIP. If I am buying a service, such as SIP, from ATT then I would logically expect ATT to offer such a fine web based interface such as you describe. >I'm probably missing something important about telephony though. But that >would work for me.... You are not missing anything important about telephony you are missing something important about the politics and competive environment that US and even most European carriers have to live in. >-MM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technicial Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 11:26:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04940 for ; Wed, 4 Sep 2002 11:26:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84FS7b28803 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 11:28:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84FS6o28797; Wed, 4 Sep 2002 11:28:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Eoso26557 for ; Wed, 4 Sep 2002 10:50:54 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03009 for ; Wed, 4 Sep 2002 10:49:14 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g84En7Vg014452; Wed, 4 Sep 2002 10:49:07 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g84En6nC014451; Wed, 4 Sep 2002 10:49:06 -0400 (EDT) Date: Wed, 4 Sep 2002 10:49:06 -0400 From: Michael Mealling To: Stastny Richard Cc: Kevin McCandless , "Yu, James" , enum@ietf.org, Michael Mealling Subject: Re: [Enum] Opt-in principle for calling users and communications providers Message-ID: <20020904104906.S10701@bailey.dscga.com> Reply-To: Michael Mealling References: <06CF906FE3998C4E944213062009F16202476C@oefeg-s02.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06CF906FE3998C4E944213062009F16202476C@oefeg-s02.oefeg.loc> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Wed, Sep 04, 2002 at 04:46:37PM +0200, Stastny Richard wrote: > Kevin wrote: > > James, > > I fail to see how NP impacts ENUM. If my number stays the > > same and that is the url people use to resolve to obtain my > > URIs, then what has changed? > > > > There is always an ipmpact, but differnt depending on the Model used: > > In my model in User ENUM the party (TSP) reponsible for the validation > changes, so it is an administrative issue. For infrastructure ENUM of > course the domain name holder changes, the new TSP my not even use ENUM. > > In MMs model (mixed or TSP only in ENUM) it impacts even more, because > the whole domain is ported also. Problems like this exist with today's DNS and registries/registrars and ISPs are able to deal with it just fine. There is no demand for another 'ISP only' DNS root for MX records. IMHO, the TSP, User and Tier 2 provider 'just need to work it out' on their own using their own policies. Why can't we all just get along and stop trying to have our cake and eat it too? Just eat the darn cake and get on with things... -MM -- -------------------------------------------------------------------------------- Michael Mealling | mailto:michael@research.netsol.com Advanced Naming Research Manager | go:Michael Mealling Verisign Applied Research | urn:pin:1 -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !! || anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 11:35:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05341 for ; Wed, 4 Sep 2002 11:35:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84FaFL29315 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 11:36:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84FaEo29309; Wed, 4 Sep 2002 11:36:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84FZHo29238 for ; Wed, 4 Sep 2002 11:35:17 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05295 for ; Wed, 4 Sep 2002 11:33:37 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Wed, 4 Sep 2002 17:37:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <06CF906FE3998C4E944213062009F16202476E@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Opt-in principle for calling users and communications providers Thread-Index: AcJUI9qP+C2LsJJ2TDOYTOjF2g+mgQAArqSg From: "Stastny Richard" To: "Michael Mealling" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g84FZHo29239 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit MM wrote: > > Not our problem that policy wonks decided not to wait on the > engineers... I'll be really glad when the last black plastic > phone gets destroyed. > Life will get a lot easier and way more interesting... We wonks waited and waited for two years and nothing came out. Up to now we do not even have _enum services_ defined for a trial. Don`t you think that you are a bit _praepotent_ (sorry, did not find the English word in the dictionary). And in all the discussions here I mainly got negative feedback (does not work, I do not like this, no, naah, this is not what is for, ...). I do not mind, if somebody tells me I am wrong, but then he should tell what is right or how it should be done. IMHO there is now way forward at the moment in ENUM. Regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 11:41:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05941 for ; Wed, 4 Sep 2002 11:41:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84Fh7R29761 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 11:43:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Fh6o29752; Wed, 4 Sep 2002 11:43:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Fgjo29729 for ; Wed, 4 Sep 2002 11:42:45 -0400 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05891 for ; Wed, 4 Sep 2002 11:41:05 -0400 (EDT) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g84Fg8D27613; Wed, 4 Sep 2002 15:42:08 GMT Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Sep 2002 11:43:14 -0400 Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E38B18B@STNTEXCH1> From: "Yu, James" To: "'Kevin McCandless'" Cc: "'enum@ietf.org'" Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Wed, 4 Sep 2002 11:42:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Kevin, On a second thought, one way to use the pointer is to use the "replacement" field to point to the TSP's server(s). This would require that the ENUM client to know that it wants to retrieve TSP's NAPTR RRs and will use the domain name in the replacement field to get to that place. There must be a clear indication in the ENUM service field that a particular NAPTR RR is a TSP's NAPTR RR so that the ENUM client can ignore the non-TSP's NAPTR RRs and try to go the next step to retrieve the TSP's NAPTR RRs (this point was raised in an early e-mail by Richard S.?). The order and preference values of the end user's and the TSP's NAPTR RRs further complicate the problem. Either one may want to set its NAPTR RRs to have a higher order/preference value. Need a rule to regulate how the end user and TSP sets those values for their NAPTR RRs and Tier 2 Nameserver Provider is the one to enforce the rule. Also if I remember it right, the processing of the NAPTR RRs starts with the order value. Unless the order value is the same for all the NAPTR RRs, some of the NAPTR RRs (TSP's or end user's) may never be used. James > -----Original Message----- > From: Yu, James > Sent: Wednesday, September 04, 2002 11:05 AM > To: 'Kevin McCandless' > Cc: enum@ietf.org > Subject: RE: [Enum] Opt-in principle for calling users and > communications providers > > > Kevin, > > Using DNS to request for NAPTR RRs, there is no way to > indicate that it is the TSP's or end user's NAPTR RRs that > are to be retrieved. So you cannot have a pointer to point > to the TSP's nameserver(s) for TSP's NAPTR RRs. The > requestor will get all the NAPTR RRs for that particular phone number. > > James > > > -----Original Message----- > > From: Kevin McCandless [mailto:KMcCandless@verisign.com] > > Sent: Wednesday, September 04, 2002 10:14 AM > > To: 'Stastny Richard' > > Cc: enum@ietf.org; Michael Mealling > > Subject: RE: [Enum] Opt-in principle for calling users and > > communications providers > > > > > > Well, the problem could be your assumption that the TSP would > > provide the > > end user with infrastructure records, such as a SIP gateway > > address. Maybe > > the TSP would actual be smarter then this and provide only a > > pointer to the > > registrant. This pointer would be entered into their Tier II > > providers > > database. This pointer directs queries to the TSPs > > infrastructure database > > the contains records for their gateway addresses. > > > > Its all vapor ware right now ;-) > > > > Kevin................ > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 11:55:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06676 for ; Wed, 4 Sep 2002 11:55:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84Fv6W30418 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 11:57:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Fv5o30413; Wed, 4 Sep 2002 11:57:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Fa8o29301 for ; Wed, 4 Sep 2002 11:36:08 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05332 for ; Wed, 4 Sep 2002 11:34:28 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g84FYFVg014682; Wed, 4 Sep 2002 11:34:16 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g84FYFcp014677; Wed, 4 Sep 2002 11:34:15 -0400 (EDT) Date: Wed, 4 Sep 2002 11:34:14 -0400 From: Michael Mealling To: "Yu, James" Cc: "'Kevin McCandless'" , enum@ietf.org Subject: Re: [Enum] Opt-in principle for calling users and communications providers Message-ID: <20020904113414.U10701@bailey.dscga.com> Reply-To: Michael Mealling References: <5E42C1C85C5D064A947CF92FADE6D82E38B186@STNTEXCH1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E42C1C85C5D064A947CF92FADE6D82E38B186@STNTEXCH1> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Wed, Sep 04, 2002 at 11:04:32AM -0400, Yu, James wrote: > > Using DNS to request for NAPTR RRs, there is no way to indicate that it is > the TSP's or end user's NAPTR RRs that are to be retrieved. So you cannot > have a pointer to point to the TSP's nameserver(s) for TSP's NAPTR RRs. The > requestor will get all the NAPTR RRs for that particular phone number. yes you can... Define an enumservice called "tspredirect" with the NAPTR record that looks like this: $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 10 10 "" "E2U+tspredirect" "" foo.tspdomain.com. -MM -- -------------------------------------------------------------------------------- Michael Mealling | mailto:michael@research.netsol.com Advanced Naming Research Manager | go:Michael Mealling Verisign Applied Research | urn:pin:1 -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !! || anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 11:57:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06766 for ; Wed, 4 Sep 2002 11:57:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84Fx5m30602 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 11:59:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Fx5o30597; Wed, 4 Sep 2002 11:59:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Fw4o30522 for ; Wed, 4 Sep 2002 11:58:04 -0400 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06701 for ; Wed, 4 Sep 2002 11:56:24 -0400 (EDT) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g84FvQD28012; Wed, 4 Sep 2002 15:57:26 GMT Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Sep 2002 11:58:32 -0400 Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E38B18C@STNTEXCH1> From: "Yu, James" To: Kevin McCandless Cc: enum@ietf.org Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Wed, 4 Sep 2002 11:57:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g84Fw4o30523 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Kevin, I want to emphasize one critical point about the impact of number portability on ENUM provisioning if both TSP's and ENUM end user's NAPTR RRs are collocated. Assume that the ENUM end user changes the telephony service from TSP-A to TSP-B. Things do not happen in one night. The loop to the end user's house must be reconnected to the TSP-B's switch and when that happens TSP-B informs the Number Portability Administration Center (NPAC). The NPAC then updates in real-time the SCP operators who operate the NP databases with the new network routing data (location routing number in the U.S.) via the LSMS interface. If the TSP's and end user's NAPTR RRs are all on the same Tier 2 nameservers, the Tier 2 Nameserver Provider must do the zone file update (with the TSP-B's NAPTR RRs replacing the TSP-A's NAPTR RRs) that is synchronized with the real-time update from the NPAC. Certainly not all the TSP's NAPTR RRs need to be handled that way (various degrees of impacts on the TSP's services). But at least the NP data must be updated at the same time. James > -----Original Message----- > From: Pfautz, Penn L, ALVAP [mailto:ppfautz@att.com] > Sent: Wednesday, September 04, 2002 10:17 AM > To: Kevin McCandless; Yu, James > Cc: enum@ietf.org; Michael Mealling > Subject: RE: [Enum] Opt-in principle for calling users and > communications providers > > > Kevin: > I think that James was making the point that IF TSPs get > special record in enum THEN NP complicates things, like > chaging those records when the user changes TSPs. I agree > there should be nmo impact on the subscriber records. > > Penn > > -----Original Message----- > From: Kevin McCandless [mailto:KMcCandless@verisign.com] > Sent: Wednesday, September 04, 2002 9:19 AM > To: 'Yu, James' > Cc: enum@ietf.org; 'Michael Mealling' > Subject: RE: [Enum] Opt-in principle for calling users and > communications providers > > > James, > > I fail to see how NP impacts ENUM. If my number stays the > same and that is > the url people use to resolve to obtain my URIs, then what > has changed? > > Kevin............... > > > -----Original Message----- > > From: Yu, James [mailto:james.yu@neustar.biz] > > Sent: Tuesday, September 03, 2002 4:48 PM > > To: 'Michael Mealling' > > Cc: enum@ietf.org > > Subject: RE: [Enum] Opt-in principle for calling users and > > communications providers > > > > > > Mike, > > > > One problem is that number portability will impact ENUM even > > if the ENUM end > > user does not change the Tier 2 Nameserver Provider (one that > > provider NAPTR > > RR hosting service). Those NAPTR RRs associated with the old > > telephony SP > > must be removed and be replaced with those from the new > > telephony SP if it > > has use of ENUM. It would be a nightmare to do it over the ENUM > > provisioning process. Also another problem is who, the > > telephony SP or the > > ENUM end user, decides which Tier 2 Nameserver Provider to > > use for hosting > > the NAPTR RRs. Telephony SP would not want to have their > > critical NAPTR RRs > > on ENUM end user's nameservers (if may be just one nameserver > > if the ENUM > > end user chooses) located in the basement. > > > > James > > > > > -----Original Message----- > > > From: Michael Mealling [mailto:michael@neonym.net] > > > Sent: Tuesday, September 03, 2002 11:17 AM > > > To: Vaudreuil, Greg M (Greg) > > > Cc: Richard Shockey; Stastny Richard; Patrik Fältström; Clive D.W. > > > Feather; Lawrence Conroy; Rich; enum@ietf.org > > > Subject: Re: [Enum] Opt-in principle for calling users and > > > communications providers > > > > > > > > > On Tue, Sep 03, 2002 at 10:10:15AM -0500, Vaudreuil, Greg M > > > (Greg) wrote: > > > > I don't have a view as to whether these services > > > > require a separate root from the end-user services. > > > However, I thought > > > > we beat the separate root per service (or class of > > > services) down in > > > > favor of the NAPTR multi-service approach. > > > > > > I thought we had too. In fact, I'd like someone to explain > > why simply > > > designating "infrastructure" enum-services as opposed to > > > "user-designated" > > > enum-services isn't sufficient? When the user signs up with > > a service > > > they explicitly delegate the ability for their > > infrastructure provider > > > to insert "infrastructure" class NAPTR records in there > for them but > > > that "user-designated" enum-services are still at the users > > > discretion.... > > > > > > What's wrong with that model? > > > > > > -MM > > > > > > -- > > > -------------------------------------------------------------- > > > ------------------ > > > Michael Mealling | Vote Libertarian! | urn:pin:1 > > > michael@neonym.net | | > > http://www.neonym.net > > -------------------------------------------------------------- > > -------------- > > ---- > > !! The Trailblazer spacecraft is going to the Moon! And for > > just $2500 a > > gram !! > > !! you can send something along with it! Business cards, > > momentos, cremains, > > !!|| anything! See http://www.transorbital.net for details! > > !! > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 13:41:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12516 for ; Wed, 4 Sep 2002 13:41:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84Hh0s04027 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 13:43:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Hgto04022; Wed, 4 Sep 2002 13:42:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84HZlo03714 for ; Wed, 4 Sep 2002 13:35:47 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12245 for ; Wed, 4 Sep 2002 13:34:07 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g84GciVg014937; Wed, 4 Sep 2002 12:38:44 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g84GchcV014936; Wed, 4 Sep 2002 12:38:43 -0400 (EDT) Date: Wed, 4 Sep 2002 12:38:43 -0400 From: Michael Mealling To: Stastny Richard Cc: Michael Mealling , enum@ietf.org Subject: Re: [Enum] Opt-in principle for calling users and communications providers Message-ID: <20020904123843.V10701@bailey.dscga.com> Reply-To: Michael Mealling References: <06CF906FE3998C4E944213062009F16202476E@oefeg-s02.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06CF906FE3998C4E944213062009F16202476E@oefeg-s02.oefeg.loc> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Wed, Sep 04, 2002 at 05:37:17PM +0200, Stastny Richard wrote: > MM wrote: > > Not our problem that policy wonks decided not to wait on the > > engineers... I'll be really glad when the last black plastic > > phone gets destroyed. > > Life will get a lot easier and way more interesting... > > We wonks waited and waited for two years and nothing came out. Up to now > we do not even have _enum services_ defined for a trial. It took a while, sure. I've been in working groups that have taken 3 years just to define their terms and understand the problem. I know its frustrating but technical solutions to these problems generally work better than mandated policy ones.... > Don`t you think that you are a bit _praepotent_ (sorry, did not find the > English word in the dictionary). I think its from the Latin meaning originally to "be powerful over". I think the current conotation would be "bullying". If so then I'm sorry to come across like that but what I'm trying to get at is that this isn't a DNS problem but a database problem. If there are current ways of doing things that make it really, really hard to even solve it on a database side then maybe its time to revisit those "ways of doing things" in light of new knowledge and systems.... > And in all the discussions here I mainly got negative feedback (does not > work, I do not like this, no, naah, this is not what is for, ...). I do > not mind, if somebody tells me I am wrong, but then he should tell what > is right or how it should be done. I think at least what I'm tryin to say is that you might want to rethink your assumptions: they may not apply here. Simply stating that "this is how we do it and thus how it must be in the future" is just as productive as me being praepotent. There might be technical solutions here that solve the problem. They might require a little work but IMHO a technical solution is probably better... > IMHO there is now way forward at the moment in ENUM. Now who's being praepotent! ;-) I think there's a way forward, it just requires being willing to do some extra work on the non-DNS backend. But that work might best be done elsewhere and not here, I'm not an expert enough to tell... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 15:35:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18108 for ; Wed, 4 Sep 2002 15:35:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84JaeQ11581 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 15:36:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84JaZo11575; Wed, 4 Sep 2002 15:36:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84JZmo11549 for ; Wed, 4 Sep 2002 15:35:48 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18003 for ; Wed, 4 Sep 2002 15:34:06 -0400 (EDT) Resent-From: michael@bailey.dscga.com Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g84IAbVg015308 for ; Wed, 4 Sep 2002 14:10:37 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g84IAaQO015307 for enum@ietf.org; Wed, 4 Sep 2002 14:10:36 -0400 (EDT) Resent-Message-Id: <200209041810.g84IAaQO015307@bailey.dscga.com> Date: Wed, 4 Sep 2002 12:38:43 -0400 From: Michael Mealling To: Stastny Richard Cc: Michael Mealling , enum@ietf.org Subject: Re: [Enum] Opt-in principle for calling users and communications providers Message-ID: <20020904123843.V10701@bailey.dscga.com> Reply-To: Michael Mealling References: <06CF906FE3998C4E944213062009F16202476E@oefeg-s02.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06CF906FE3998C4E944213062009F16202476E@oefeg-s02.oefeg.loc> User-Agent: Mutt/1.3.22.1i Resent-Date: Wed, 4 Sep 2002 14:10:36 -0400 Resent-To: enum@ietf.org Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Wed, Sep 04, 2002 at 05:37:17PM +0200, Stastny Richard wrote: > MM wrote: > > Not our problem that policy wonks decided not to wait on the > > engineers... I'll be really glad when the last black plastic > > phone gets destroyed. > > Life will get a lot easier and way more interesting... > > We wonks waited and waited for two years and nothing came out. Up to now > we do not even have _enum services_ defined for a trial. It took a while, sure. I've been in working groups that have taken 3 years just to define their terms and understand the problem. I know its frustrating but technical solutions to these problems generally work better than mandated policy ones.... > Don`t you think that you are a bit _praepotent_ (sorry, did not find the > English word in the dictionary). I think its from the Latin meaning originally to "be powerful over". I think the current conotation would be "bullying". If so then I'm sorry to come across like that but what I'm trying to get at is that this isn't a DNS problem but a database problem. If there are current ways of doing things that make it really, really hard to even solve it on a database side then maybe its time to revisit those "ways of doing things" in light of new knowledge and systems.... > And in all the discussions here I mainly got negative feedback (does not > work, I do not like this, no, naah, this is not what is for, ...). I do > not mind, if somebody tells me I am wrong, but then he should tell what > is right or how it should be done. I think at least what I'm tryin to say is that you might want to rethink your assumptions: they may not apply here. Simply stating that "this is how we do it and thus how it must be in the future" is just as productive as me being praepotent. There might be technical solutions here that solve the problem. They might require a little work but IMHO a technical solution is probably better... > IMHO there is now way forward at the moment in ENUM. Now who's being praepotent! ;-) I think there's a way forward, it just requires being willing to do some extra work on the non-DNS backend. But that work might best be done elsewhere and not here, I'm not an expert enough to tell... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 4 21:37:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26764 for ; Wed, 4 Sep 2002 21:37:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g851cac25638 for enum-archive@odin.ietf.org; Wed, 4 Sep 2002 21:38:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g851cWo25630; Wed, 4 Sep 2002 21:38:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g851bdo25561 for ; Wed, 4 Sep 2002 21:37:39 -0400 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 VAA26659 for ; Wed, 4 Sep 2002 21:35:55 -0400 (EDT) Received: from user-uivenjr.dsl.mindspring.com ([165.247.94.123] helo=dick.ix.netcom.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17mlaG-0005Yb-00; Wed, 04 Sep 2002 21:37:25 -0400 Message-Id: <5.1.0.14.2.20020904213620.01ff6d98@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 04 Sep 2002 21:44:10 -0400 To: "Stastny Richard" , "Michael Mealling" From: Richard Shockey Subject: RE: [Enum] Opt-in principle for calling users and communications providers Cc: In-Reply-To: <06CF906FE3998C4E944213062009F16202476E@oefeg-s02.oefeg.loc > 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-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , A >And in all the discussions here I mainly got negative feedback (does not >work, I do not like this, no, naah, this is not what is for, ...). I do >not mind, if somebody tells me I am wrong, but then he should tell what >is right or how it should be done. > >IMHO there is now way forward at the moment in ENUM. Now Richard I dont think you are being very charitable here ... all of us would like to see a revised enum service document combining the ideas from Ranali/Walter yours and Rudi Brandner fine work here. I have it on some good authority that a revised enumservice document for SIP will be available in due course. We had consensus that the generic ABNF syntax for the enumservice field would look like service_field = "E2U" 1*("+" enumservice) enumservice = token *[":" token ":" token] etc token = 1*32(ALPHA / DIGIT) the Fax WG is working on their document and I believe that the VPIM folks are advancing along.... Greg? BTW anyone that wants to work on H323 enumservice field ... now is the time! There is nothing stopping trials from moving forward with all deliberate speed. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technicial Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Sep 5 08:38:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17086 for ; Thu, 5 Sep 2002 08:38:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g85CdEj26360 for enum-archive@odin.ietf.org; Thu, 5 Sep 2002 08:39:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g85Cd9o26350; Thu, 5 Sep 2002 08:39:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g85CbBo26201 for ; Thu, 5 Sep 2002 08:37:11 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16985 for ; Thu, 5 Sep 2002 08:35:33 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [Enum] Opt-in principle for calling users and communications providers MIME-Version: 1.0 Date: Thu, 5 Sep 2002 14:39:12 +0200 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <06CF906FE3998C4E944213062009F162024774@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Opt-in principle for calling users and communications providers Thread-Index: AcJUSzk74SuHfWPfQpmxXoEi/LNKhgAgxnvg From: "Stastny Richard" To: "Michael Mealling" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g85CbBo26202 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit MM wrote: > > Don`t you think that you are a bit _praepotent_ (sorry, did > not find > > the English word in the dictionary). > > I think its from the Latin meaning originally to "be powerful > over". I think the current conotation would be "bullying". If > so then I'm sorry to come across like that but what I'm > trying to get at is that this isn't a DNS problem but a > database problem. I think what we have is a basic idea (ENUM) and different people have different views what can or may be done with this idea. I also think that the ENUM RFC should be generic and allow most of the view to be implemented, but the we need to discuss the different requirements first. And it is a DNS problem, because DNS is the database used and IMHO DNS is a special kind of database. >If there are current ways of doing things > that make it really, really hard to even solve it on a > database side then maybe its time to revisit those "ways of > doing things" in light of new knowledge and systems.... > Thats excactly what I am trying to do: I try to revisit how the things are done in the conv. telephony system "in light of new knowledge and systems" and try to merge/migrate/replace certain functions by moving to IP, having an eye also on legal and regulatory requirements, because there is a difference between greenfields and incumbents (espescially with Significant Market Power - what the term in Europe is). And there is a Differnce what you can do and what you are allowed to to - and there is no use to discuss this here. Regards Richard PS: I finally found the translation of praepotent/präpotent. The problem was, it is not German German, it is Austrian German, therefor was not in the normal dicitonary, and is has the meaning of arrogant and presumptuous ;-) _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Sep 5 09:26:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18589 for ; Thu, 5 Sep 2002 09:26:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g85DRtE00305 for enum-archive@odin.ietf.org; Thu, 5 Sep 2002 09:27:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g85DRro32756; Thu, 5 Sep 2002 09:27:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g85DQvo32693 for ; Thu, 5 Sep 2002 09:26:57 -0400 Received: from ihemail2.firewall.lucent.com ([192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18490 for ; Thu, 5 Sep 2002 09:25:18 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g85D81F02777 for ; Thu, 5 Sep 2002 09:08:01 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 08:08:01 -0500 Message-ID: <54E40201497DF142B06B27255953F7975CBF9A@il0015exch007.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Richard Shockey , Stastny Richard , Michael Mealling Cc: enum@ietf.org Subject: RE: [Enum] Opt-in principle for calling users and communications providers Date: Thu, 5 Sep 2002 08:07:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Greg here.... I have been waiting for the revised ENUM document with the revised ABNF syntax in something more stable than a view-graph. As soon as the new ENUM doc is posted, I will submit the VPIM routing draft. Greg V. -----Original Message----- From: Richard Shockey [mailto:rshockey@ix.netcom.com] Sent: Wednesday, September 04, 2002 8:44 PM To: Stastny Richard; Michael Mealling Cc: enum@ietf.org Subject: RE: [Enum] Opt-in principle for calling users and communications providers A >And in all the discussions here I mainly got negative feedback (does not >work, I do not like this, no, naah, this is not what is for, ...). I do >not mind, if somebody tells me I am wrong, but then he should tell what >is right or how it should be done. > >IMHO there is now way forward at the moment in ENUM. Now Richard I dont think you are being very charitable here ... all of us would like to see a revised enum service document combining the ideas from Ranali/Walter yours and Rudi Brandner fine work here. I have it on some good authority that a revised enumservice document for SIP will be available in due course. We had consensus that the generic ABNF syntax for the enumservice field would look like service_field = "E2U" 1*("+" enumservice) enumservice = token *[":" token ":" token] etc token = 1*32(ALPHA / DIGIT) the Fax WG is working on their document and I believe that the VPIM folks are advancing along.... Greg? BTW anyone that wants to work on H323 enumservice field ... now is the time! There is nothing stopping trials from moving forward with all deliberate speed. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technicial Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Sep 6 16:21:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20303 for ; Fri, 6 Sep 2002 16:21:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g86KMdV03918 for enum-archive@odin.ietf.org; Fri, 6 Sep 2002 16:22:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g86KM8X03893; Fri, 6 Sep 2002 16:22:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g86KJDX03778 for ; Fri, 6 Sep 2002 16:19:13 -0400 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20214 for ; Fri, 6 Sep 2002 16:17:30 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g86KIXD31454 for ; Fri, 6 Sep 2002 20:18:33 GMT Message-Id: <5.1.0.14.2.20020906161137.024653b8@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Sep 2002 16:20:48 -0400 To: enum@ietf.org From: Richard Shockey Subject: [Enum] Revised WG Goals and Milestones ..again 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-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , I posted a proposal for a Revised Goals and Milestones for the WG several days ago and that seemed to create a new thread ..but no discussion on deliverables. At the private suggestion of some folks I have added a separate document here on Privacy Considerations in ENUM. In discussions on ENUM in various forums there has been substantial discussion of privacy related issues in the context of what is entered into the DNS as well as what information is necessary to for a authenticated and valid registration. Again I'd like to propose the following deliverables and in the absence of further direct comment on this proposal I will consider silence consent and forward this on the the AD's. Done Initial draft of Service ENUM Requirements Done Initial draft of ENUM Protocol Done Revised draft of ENUM Protocol Done Submit ENUM Protocol document to IESG for publication as Proposed Jan 03 Revise and update RFC 2916 appropriate to DDDS (revision of 2915) Jan 03 Document appropriate ENUM Service Field Registrations [ Standards Track ] March 03 Document appropriate ENUM Provisioning Procedures (Informational ?) March 03 Advance revised RFC 2916 to Draft Standard June 03 Document appropriate Privacy Considerations in ENUM (Informaitonal) June 03 Document appropriate ENUM Operational SecurityProcedures (Informational) I want to note to the list that I'm personally aware of several national trials of ENUM that are beginning this fall and Winter we would hope that some of you who are working on those trials will assist the WG in documenting the funcitions during those trials to assist the WG in completing it task of taking 2916 forward to Draft standard. I think its also reasonable that we delay trying to work on provisioning, security and other issues until there are some clear results coming back from those trials. Comments? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 9 10:59:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05142 for ; Mon, 9 Sep 2002 10:59:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g89F0gv05684 for enum-archive@odin.ietf.org; Mon, 9 Sep 2002 11:00:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89F0Tv05675; Mon, 9 Sep 2002 11:00:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89ER9v02469 for ; Mon, 9 Sep 2002 10:27:09 -0400 Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12728 for ; Sun, 8 Sep 2002 21:16:23 -0400 (EDT) Received: from lawrence.srmr.co.uk ([193.118.192.111] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 6045u via TCP with SMTP; Mon, 09 Sep 2002 02:17:48 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Mon, 9 Sep 2002 02:17:43 +0100 To: enum@ietf.org, paf@cisco.com From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Clarification on 2916-bis ss 3.1.1 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi again Patrik, folks, I need some clarification urgently on section 3.1.1 (in 2916-bis-01). (I suspect so will anyone else trying to fulfil the meeting request for "concrete proposals" :) In section 3.1.1, the first paragraph states that an enumservice registration MUST specify "the URI which is the outcome of the use of it". The second paragraph states that the registration MUST also specify, when needed "other information which will have to be transfered into the URI resolution process itself (LDAP DNs, transferring of the AUS into the resulting URI, etc)". The first paragraph would seem to require that each enumservice was associated with exactly 1 URI scheme (or that the whacky 'bar' sub-field is the URI scheme. The second paragraph seems to suggest that an enumservice specification can override the REGEXP procedure/2916-bis algorithm for processing AUS to URI. Are these still intended as I interpret them? all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 9 11:00:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05311 for ; Mon, 9 Sep 2002 11:00:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g89F1WV06187 for enum-archive@odin.ietf.org; Mon, 9 Sep 2002 11:01:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89F1Wv06182; Mon, 9 Sep 2002 11:01:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89ERNv02654 for ; Mon, 9 Sep 2002 10:27:23 -0400 Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11513 for ; Sun, 8 Sep 2002 19:02:05 -0400 (EDT) Received: from lawrence.srmr.co.uk ([193.118.192.111] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 6017u via TCP with SMTP; Mon, 09 Sep 2002 00:03:37 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Mon, 9 Sep 2002 00:03:32 +0100 To: enum@ietf.org From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] 2916-bis-02? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Folks, When can we expect the -02 version of 2916-bis, with the syntax described in the YOK notes? Also, I'm puzzled; in -01 the last paragraph before 2.4.2.1 states that an empty string is valid, but this conflicts with the meeting notes and with the ABNF (both in -01 and at the YOK meeting). I did raise this on the list, but I guess folks were too busy with policy discussions to notice. => I ASSUME that this paragraph is gone and the new ABNF is as proposed at the meeting as the (A) option. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 9 15:12:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13922 for ; Mon, 9 Sep 2002 15:12:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g89JDqR25675 for enum-archive@odin.ietf.org; Mon, 9 Sep 2002 15:13:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89JDmv25670; Mon, 9 Sep 2002 15:13:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89JCjv25635 for ; Mon, 9 Sep 2002 15:12:45 -0400 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13891 for ; Mon, 9 Sep 2002 15:11:06 -0400 (EDT) Received: from xbe-ams-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g89JBEJr006853; Mon, 9 Sep 2002 21:11:14 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 9 Sep 2002 21:11:29 +0200 Received: from zx81.paf.se ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 9 Sep 2002 21:11:28 +0200 Date: Mon, 9 Sep 2002 21:11:27 +0200 Subject: Re: [Enum] 2916-bis-02? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: enum@ietf.org To: Lawrence Conroy From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) X-OriginalArrivalTime: 09 Sep 2002 19:11:28.0766 (UTC) FILETIME=[B330D1E0:01C25834] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Monday, September 9, 2002, at 01:03 AM, Lawrence Conroy wrote: > When can we expect the -02 version of 2916-bis, with the syntax > described in the YOK notes? IAB has requested, based on discussions with ITU-T, some slight wording changes in the IANA Consideration Section. When I have the exact words, I will make a new version available. Sorry for the delay. I needed vacation in August. Got it. Feel more relaxed. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 9 15:13:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13941 for ; Mon, 9 Sep 2002 15:13:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g89JEBv25718 for enum-archive@odin.ietf.org; Mon, 9 Sep 2002 15:14:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89JEBv25713; Mon, 9 Sep 2002 15:14:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89JDkv25663 for ; Mon, 9 Sep 2002 15:13:46 -0400 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13913 for ; Mon, 9 Sep 2002 15:12:06 -0400 (EDT) Received: from xbe-lon-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g89JCE9x006930; Mon, 9 Sep 2002 21:12:15 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 9 Sep 2002 20:10:15 +0100 Received: from zx81.paf.se ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 9 Sep 2002 21:10:14 +0200 Date: Mon, 9 Sep 2002 21:10:13 +0200 Subject: Re: [Enum] Clarification on 2916-bis ss 3.1.1 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: enum@ietf.org To: Lawrence Conroy From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) X-OriginalArrivalTime: 09 Sep 2002 19:10:14.0610 (UTC) FILETIME=[86FD8320:01C25834] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Monday, September 9, 2002, at 03:17 AM, Lawrence Conroy wrote: > I need some clarification urgently on section 3.1.1 (in 2916-bis-01). > (I suspect so will anyone else trying to fulfil the meeting request > for "concrete proposals" :) :-) > In section 3.1.1, the first paragraph states that an enumservice > registration MUST specify "the URI which is the outcome of the use of > it". > > The second paragraph states that the registration MUST also specify, > when needed > "other information which will have to be transfered into the URI > resolution > process itself (LDAP DNs, transferring of the AUS into the resulting > URI, etc)". > > The first paragraph would seem to require that each enumservice was > associated > with exactly 1 URI scheme (or that the whacky 'bar' sub-field is the > URI scheme. Well, I think it is my bad english which make these mistakes. We can not have one and only one URI scheme as a result. Especially if the service is to be use for something like "the web", because for "the web" one use either "http" or "https", so already there we have problems. My suggestion, but I need to know what the wg think, that the text should be changed so it is clear that the registration need to list the URI schemes (plural) which might appear. > The second paragraph seems to suggest that an enumservice > specification can override > the REGEXP procedure/2916-bis algorithm for processing AUS to URI. Then I need to fix it. The 2916bis algorithm can not be overridden. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 11 03:47:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00830 for ; Wed, 11 Sep 2002 03:47:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8B7moH29201 for enum-archive@odin.ietf.org; Wed, 11 Sep 2002 03:48:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8B7kXv29149; Wed, 11 Sep 2002 03:46:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8B7fHv28838 for ; Wed, 11 Sep 2002 03:41:17 -0400 Received: from mta0 ([61.144.161.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00475 for ; Wed, 11 Sep 2002 03:39:20 -0400 (EDT) Received: from Deepankar (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H29000SNJWJOV@mta0.huawei.com> for enum@ietf.org; Wed, 11 Sep 2002 15:38:45 +0800 (CST) Date: Wed, 11 Sep 2002 15:40:11 +0800 From: Deepankar To: enum@ietf.org Message-id: <012c01c25966$75ceab50$4d080b0a@Deepankar> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: multipart/alternative; boundary="Boundary_(ID_Bu2aV9u++YwGiq5BsgwCCA)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Enum] Detailed application examples Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_Bu2aV9u++YwGiq5BsgwCCA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Dear all, Where can I find detailed application examples of ENUM! Deeps --Boundary_(ID_Bu2aV9u++YwGiq5BsgwCCA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Dear all,
 
Where can I find detailed application examples of ENUM!
 
Deeps
--Boundary_(ID_Bu2aV9u++YwGiq5BsgwCCA)-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Sep 13 04:44:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28608 for ; Fri, 13 Sep 2002 04:44:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8D8kC509710 for enum-archive@odin.ietf.org; Fri, 13 Sep 2002 04:46:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8D8jfv09688; Fri, 13 Sep 2002 04:45:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8D8hKv09587 for ; Fri, 13 Sep 2002 04:43:20 -0400 Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28571 for ; Fri, 13 Sep 2002 04:41:26 -0400 (EDT) Received: from lawrence.srmr.co.uk ([193.118.205.14] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 7166u via TCP with SMTP; Fri, 13 Sep 2002 09:42:59 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Fri, 13 Sep 2002 09:42:53 +0100 To: enum@ietf.org, michael@neonym.net, paf@cisco.com From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] D3S details redux Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hello esteemed authors, folks, I did ask for a couple of clarifications on the operation of D3S. This was swamped by the policy discussion, so here's a slightly expanded list. (I think that anyone implementing ENUM will need to know these details). The questions are on the D3S algorithm when using DNS, and particularly using the ENUM D3S application (surprise, surprise :) * for a non-terminal NAPTR, it seems that the "replacement field" is not used to evaluate the "next round" of D3S processing - the regexp is used instead. => the regexp field has data => the replacement field is empty. Is this correct? * for a non-terminal NAPTR, when evaluating the next key for the ENUM algorithm, the usual order and precedence fields are used to prioritise processing as usual. Also, the service field is used to match against the end user's interests - i.e. the NAPTR is rejected if the service field is "E2U+beer" and the client is not interested in the enumservice "beer" (must be in the U.S., I guess :). Is this correct? * for a non-terminal NAPTR, I THINK that the result of regexp processing should be a "pure" E.164 number (e.g. "+441794833666", which means the next round should continue at the ENUM domain 6.6.6.3.3.4.9.7.1.4.4.e164.arpa). This fits with the flow diagram in the D3S Algorithm draft, and with the "output of first rule" section in RFC2916bis. Is this correct? I do need these clarified fairly quickly, as they have an impact not only on the implementation (you can't interwork without knowing what to put into the regexp) and as I don't know what the syntax should be in any "non-terminal" examples. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Sep 13 05:00:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29014 for ; Fri, 13 Sep 2002 05:00:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8D91DP10265 for enum-archive@odin.ietf.org; Fri, 13 Sep 2002 05:01:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8D91Cv10260; Fri, 13 Sep 2002 05:01:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8D90Jv10192 for ; Fri, 13 Sep 2002 05:00:19 -0400 Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28988 for ; Fri, 13 Sep 2002 04:58:37 -0400 (EDT) Received: from lawrence.srmr.co.uk ([193.118.205.14] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 7220u via TCP with SMTP; Fri, 13 Sep 2002 10:00:18 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Fri, 13 Sep 2002 10:00:10 +0100 To: enum@ietf.org, michael.mealling@neonym.net, paf@cisco.com From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] D3S clarification redux references Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi again esteemed authors, folks, Forgot to put the reference text I'm looking at into the "redux" post - duh! draft-ietf-urn-ddds-07.txt describes the "exact DDDS algorithm" (and is preceded in section 3 by a nice ascii art flow diagram for those - good work). Step 5 is the one in question. draft-ietf-enum-rfc2916bis-01.txt, in section 2.4, second paragraph, first sentence, describes the output of the "first well known rule" as the E.164 number minus any non-digit characters except for the +. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 16 07:48:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00950 for ; Mon, 16 Sep 2002 07:48:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8GBo7t25224 for enum-archive@odin.ietf.org; Mon, 16 Sep 2002 07:50:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GBnsv25202; Mon, 16 Sep 2002 07:49:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GBlwv25117 for ; Mon, 16 Sep 2002 07:47:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00699; Mon, 16 Sep 2002 07:46:11 -0400 (EDT) Message-Id: <200209161146.HAA00699@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 16 Sep 2002 07:46:10 -0400 Subject: [Enum] I-D ACTION:draft-bradner-pbk-frame-02.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Framework for Purpose Built Keys (PBK) Author(s) : S. Bradner, A. Mankin, J. Schiller Filename : draft-bradner-pbk-frame-02.txt Pages : 7 Date : 2002-9-13 This memo considers the need to authenticate the source of a network communication where the actual identity of the source is not important but it is important to be sure that the source can not be spoofed and that successive messages in the communication come from the same source. This memo defines the use of specially generated public/private key pairs, known as Purpose Built Keys (PBKs), to provide this assurance. This memo is not a full specification of a PBK protocol, but rather a model or framework for development of PBK in applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bradner-pbk-frame-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-bradner-pbk-frame-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bradner-pbk-frame-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-13143625.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bradner-pbk-frame-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-bradner-pbk-frame-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-13143625.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 16 08:22:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01912 for ; Mon, 16 Sep 2002 08:22:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8GCNNA27040 for enum-archive@odin.ietf.org; Mon, 16 Sep 2002 08:23:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GCNMv27035; Mon, 16 Sep 2002 08:23:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GCMXv26981 for ; Mon, 16 Sep 2002 08:22:33 -0400 Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01840 for ; Mon, 16 Sep 2002 08:20:46 -0400 (EDT) Received: from Hpy6467 ([194.136.227.254]) by fep06-app.kolumbus.fi with SMTP id <20020916122230.GKMI13915.fep06-app.kolumbus.fi@Hpy6467> for ; Mon, 16 Sep 2002 15:22:30 +0300 Message-ID: <000e01c25d7b$c399eac0$a441020a@hepunet.fi> From: "Tuomo Rostela" To: Date: Mon, 16 Sep 2002 15:22:45 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C25D94.E8A3FF40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [Enum] how to provide ENUM for all end users Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C25D94.E8A3FF40 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi folks! I think, all the previous discussions and scenarios assume that the = whole operative national number block is ENUM served but maybe I am = wrong. My question is, how should Tier 1 and Tier 2 organised if all = TSPs do not use ENUM and common intention is provide ENUM for all end = user? We can consider the following example.=20 A customer wants use VoIP and ENUM, but his/her TSP do not support ENUM. The used national hierarchy of ENUM could be: At Tier 1 the number blocks which are assigned to certain TSP points to = Tier 2 DNS maintained by these operators (or it is outsourced to another = entity). Golden tree and opt-in are used. Which are the possibilities of this customer to use ENUM? 1) the customer can't use ENUM, because number owner TSP do not have any = ENUM/DNS (later I call this operator as "no-ENUM TSP") 2) the customer change the number and operator 3) the customer change the operator and keep the old number (number = portability) The last alternative is the best from customer point of view, but how = should the number blocks organised at Tier 1? It is impossible to change the whole number block of "no-ENUM TSP" to = point this new operator "x", because another customer of "no-ENUM TSP" = could want use operator "y". Ok, of course its possible from technical = point of view but from business point of view it is highly unlikely. I = guess any opearator will not provide free ENUM/DNS service to the = customer of other rival operators. Lousy solutions: 1) these individual numbers are operated at Tier 1 2) a common Tier 2 ENUM/DNS are established for these number blocks (all = operators have a right to add individual numbers) 3) all the operators must participate to ENUM 4) some kind pseudonumbers are used in ENUM (as routing numbers on PSTN) 1 and 2 are poor solutions. If this "no-ENUM TSP" wants later give ENUM = services for its numbers, how should these systems (1 and 2) take down? Do you have any suggestion?=20 Best regards Tuomo ------=_NextPart_000_000B_01C25D94.E8A3FF40 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi folks!
 
I think, all the previous = discussions and=20 scenarios assume that the whole operative national number block is ENUM = served=20 but maybe I am wrong. My question is, how should Tier 1 and Tier 2 = organised if=20 all TSPs do not use ENUM and common intention is provide ENUM = for all=20 end user?
 
We can consider the following = example.=20
A customer wants use VoIP and ENUM, but his/her TSP do not support=20 ENUM.
The used national hierarchy of ENUM could be:
At Tier 1 the = number=20 blocks which are assigned to certain TSP points to Tier 2 DNS maintained = by=20 these operators (or it is outsourced to another entity). Golden tree and = opt-in=20 are used.
 
Which are the possibilities of = this=20 customer to use ENUM?
1) the customer can't use ENUM, because number = owner=20 TSP do not have any ENUM/DNS (later I call this operator as "no-ENUM = TSP")
2)=20 the customer change the number and operator
3) the customer change = the=20 operator and keep the old number (number portability)
 
The last alternative is the = best from=20 customer point of view, but how should the number blocks organised at = Tier=20 1?
It is impossible to change the whole number block of "no-ENUM TSP" = to=20 point this new operator "x", because another customer of "no-ENUM TSP" = could=20 want use operator "y". Ok, of course its possible from technical point = of view=20 but from business point of view it is highly unlikely. I guess any = opearator=20 will not provide free ENUM/DNS service to the customer of other rival=20 operators.
 
Lousy solutions:
1) these individual numbers are = operated at=20 Tier 1
2) a common Tier 2 ENUM/DNS are established for these number = blocks=20 (all operators have a right to add individual numbers)
3) all the = operators=20 must participate to ENUM
4) some kind pseudonumbers are used in ENUM = (as=20 routing numbers on PSTN)
 
1 and 2 are poor solutions. If = this=20 "no-ENUM TSP" wants later give ENUM services for its numbers, how should = these=20 systems (1 and 2) take down?
 
Do you have any suggestion? =
 
Best regards=20 Tuomo
------=_NextPart_000_000B_01C25D94.E8A3FF40-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 16 10:02:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05572 for ; Mon, 16 Sep 2002 10:02:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8GE3qd00589 for enum-archive@odin.ietf.org; Mon, 16 Sep 2002 10:03:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GE3mv00584; Mon, 16 Sep 2002 10:03:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GE2ov00546 for ; Mon, 16 Sep 2002 10:02:50 -0400 Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05541 for ; Mon, 16 Sep 2002 10:01:02 -0400 (EDT) Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g8GDCnah006888 for ; Mon, 16 Sep 2002 09:02:12 -0500 (CDT) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (6.5.019) id 3D81149A000C42E3; Mon, 16 Sep 2002 10:02:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25D89.A4A520FD" Subject: RE: [Enum] how to provide ENUM for all end users Date: Mon, 16 Sep 2002 10:02:07 -0400 Message-ID: <62DA45D4963FA747BA1B253E266760F903D1734C@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Enum] how to provide ENUM for all end users Thread-Index: AcJdgP7JiRIIKeeIQIGNqMCg5CqbIgAB0MtQ From: "Pfautz, Penn L, ALVAP" To: "Tuomo Rostela" , Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C25D89.A4A520FD Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Tuomo: I'm not sure if the scope of your issue is ENUM use by carriers or more = generally. If it's the latter I think there's a problem with what you = suggest. The IETF has assumed that the subscriber is the arbiter of ENUM = service and that the he/she can have VOIP even if his or her TSP isn't = interested. I have a broadband ISP connection to the net and I can = choose to have ENUM direct calls to my SIP-enabled PC instead of through = the TSP from which I got (or to which I ported) my phone number. (In the US at least I still have to keep PSTN service on the number to = keep it, but that said, I can use ENUM to have calls from ENUM-enable = originators routed however I want.) The conseqence is that number blocks can't be delegated per TSP (in the = US and wherever else you have number portability) but the Tier 1 must = represent the full number and point to a correct Tier 2 where the NAPTR = records reside. This is the path the ENUM Forum is pursuing in the US: a = cooperative Tier 1 infrastructure with a competitive Tier 2 to maximize = customer choice. =20 Penn Pfautz -----Original Message----- From: Tuomo Rostela [mailto:tuomo.rostela@kolumbus.fi] Sent: Monday, September 16, 2002 8:23 AM To: enum@ietf.org Subject: [Enum] how to provide ENUM for all end users Hi folks! =20 I think, all the previous discussions and scenarios assume that the = whole operative national number block is ENUM served but maybe I am = wrong. My question is, how should Tier 1 and Tier 2 organised if all = TSPs do not use ENUM and common intention is provide ENUM for all end = user? =20 We can consider the following example.=20 A customer wants use VoIP and ENUM, but his/her TSP do not support ENUM. The used national hierarchy of ENUM could be: At Tier 1 the number blocks which are assigned to certain TSP points to = Tier 2 DNS maintained by these operators (or it is outsourced to another = entity). Golden tree and opt-in are used. =20 Which are the possibilities of this customer to use ENUM? 1) the customer can't use ENUM, because number owner TSP do not have any = ENUM/DNS (later I call this operator as "no-ENUM TSP") 2) the customer change the number and operator 3) the customer change the operator and keep the old number (number = portability) =20 The last alternative is the best from customer point of view, but how = should the number blocks organised at Tier 1? It is impossible to change the whole number block of "no-ENUM TSP" to = point this new operator "x", because another customer of "no-ENUM TSP" = could want use operator "y". Ok, of course its possible from technical = point of view but from business point of view it is highly unlikely. I = guess any opearator will not provide free ENUM/DNS service to the = customer of other rival operators. =20 Lousy solutions: 1) these individual numbers are operated at Tier 1 2) a common Tier 2 ENUM/DNS are established for these number blocks (all = operators have a right to add individual numbers) 3) all the operators must participate to ENUM 4) some kind pseudonumbers are used in ENUM (as routing numbers on PSTN) =20 1 and 2 are poor solutions. If this "no-ENUM TSP" wants later give ENUM = services for its numbers, how should these systems (1 and 2) take down? =20 Do you have any suggestion?=20 =20 Best regards Tuomo ------_=_NextPart_001_01C25D89.A4A520FD Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Tuomo:
I'm=20 not sure if the scope of your issue is ENUM use by carriers or more = generally.=20 If it's the latter I think there's a problem with what you suggest. The = IETF has=20 assumed that the subscriber is the arbiter of ENUM service and that the = he/she=20 can have VOIP even if his or her TSP isn't interested. I have a = broadband ISP=20 connection to the net and I can choose to have ENUM direct calls to my=20 SIP-enabled PC instead of through the TSP from which I got (or to which = I=20 ported) my phone number.
(In=20 the US at least I still have to keep PSTN service on the number to keep = it, but=20 that said, I can use ENUM to have calls from ENUM-enable originators = routed=20 however I want.)
The=20 conseqence is that number blocks can't be delegated per TSP (in the US = and=20 wherever else you have number portability) but the Tier 1 must represent = the=20 full number and point to a correct Tier 2 where the NAPTR records = reside. This=20 is the path the ENUM Forum is pursuing in the US: a cooperative Tier 1=20 infrastructure with a competitive Tier 2 to maximize customer=20 choice.
 
Penn=20 Pfautz
-----Original Message-----
From: Tuomo Rostela=20 [mailto:tuomo.rostela@kolumbus.fi]
Sent: Monday, September = 16, 2002=20 8:23 AM
To: enum@ietf.org
Subject: [Enum] how to = provide=20 ENUM for all end users

Hi folks!
 
I think, all the previous = discussions and=20 scenarios assume that the whole operative national number block is = ENUM served=20 but maybe I am wrong. My question is, how should Tier 1 and Tier 2 = organised=20 if all TSPs do not use ENUM and common intention is provide = ENUM for=20 all end user?
 
We can consider the following = example.=20
A customer wants use VoIP and ENUM, but his/her TSP do not support = ENUM.
The used national hierarchy of ENUM could be:
At Tier 1 = the number=20 blocks which are assigned to certain TSP points to Tier 2 DNS = maintained by=20 these operators (or it is outsourced to another entity). Golden tree = and=20 opt-in are used.
 
Which are the possibilities = of this=20 customer to use ENUM?
1) the customer can't use ENUM, because = number owner=20 TSP do not have any ENUM/DNS (later I call this operator as "no-ENUM=20 TSP")
2) the customer change the number and operator
3) the = customer=20 change the operator and keep the old number (number = portability)
 
The last alternative is the = best from=20 customer point of view, but how should the number blocks organised at = Tier=20 1?
It is impossible to change the whole number block of "no-ENUM = TSP" to=20 point this new operator "x", because another customer of "no-ENUM TSP" = could=20 want use operator "y". Ok, of course its possible from technical point = of view=20 but from business point of view it is highly unlikely. I guess any = opearator=20 will not provide free ENUM/DNS service to the customer of other rival=20 operators.
 
Lousy solutions:
1) these individual numbers = are operated=20 at Tier 1
2) a common Tier 2 ENUM/DNS are established for these = number=20 blocks (all operators have a right to add individual numbers)
3) = all the=20 operators must participate to ENUM
4) some kind pseudonumbers are = used in=20 ENUM (as routing numbers on PSTN)
 
1 and 2 are poor solutions. = If this=20 "no-ENUM TSP" wants later give ENUM services for its numbers, how = should these=20 systems (1 and 2) take down?
 
Do you have any suggestion? =
 
Best regards=20 Tuomo
------_=_NextPart_001_01C25D89.A4A520FD-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 16 16:57:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17152 for ; Mon, 16 Sep 2002 16:57:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8GKx3U23097 for enum-archive@odin.ietf.org; Mon, 16 Sep 2002 16:59:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GKx0v23092; Mon, 16 Sep 2002 16:59:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GKtxv22992 for ; Mon, 16 Sep 2002 16:55:59 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17080 for ; Mon, 16 Sep 2002 16:54:07 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g8GKrxnB007103; Mon, 16 Sep 2002 16:53:59 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g8GKrwvN007102; Mon, 16 Sep 2002 16:53:58 -0400 (EDT) Date: Mon, 16 Sep 2002 16:53:58 -0400 From: Michael Mealling To: Lawrence Conroy Cc: enum@ietf.org, michael@neonym.net, paf@cisco.com Message-ID: <20020916165358.D640@bailey.dscga.com> Reply-To: Michael Mealling References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Subject: [Enum] Re: D3S details redux Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Fri, Sep 13, 2002 at 09:42:53AM +0100, Lawrence Conroy wrote: > Hello esteemed authors, folks, > I did ask for a couple of clarifications on the operation of D3S. > This was swamped by the policy discussion, so here's a slightly expanded > list. > (I think that anyone implementing ENUM will need to know these details). > > The questions are on the D3S algorithm when using DNS, and particularly > using the ENUM D3S application (surprise, surprise :) > > * for a non-terminal NAPTR, it seems that the "replacement field" > is not used > to evaluate the "next round" of D3S processing - the regexp is > used instead. > => the regexp field has data => the replacement field is empty. > > Is this correct? Close but not exactly. Either the regexp field or the replacement field are empty. If the regexp field is empty then the replacement field will contain the next key. The replacement field is a shortcut way of saying this: /^.*$/example.com/ and was required by the DNS folks so that domain-names could be compressed. Since then 'per-field' compression is out and if we had the ability to predict the future we wouldn't have had a replacement field.... > * for a non-terminal NAPTR, when evaluating the next key for the > ENUM algorithm, > the usual order and precedence fields are used to prioritise > processing as usual. > Also, the service field is used to match against the end user's interests > - i.e. the NAPTR is rejected if the service field is "E2U+beer" > and the client > is not interested in the enumservice "beer" (must be in the > U.S., I guess :). > > Is this correct? Correct. There is an assumption in the document that any subsequent NAPTR records requested will also adhere to the "E2U+beer" service statement but it isn't clear if ENUM has that requirement or not. > * for a non-terminal NAPTR, I THINK that the result of regexp > processing should > be a "pure" E.164 number (e.g. "+441794833666", which means the next round > should continue at the ENUM domain 6.6.6.3.3.4.9.7.1.4.4.e164.arpa). This > fits with the flow diagram in the D3S Algorithm draft, and with > the "output > of first rule" section in RFC2916bis. > > Is this correct? Not really. The key has to be database specific. If this wasn't the case then it would be very hard to use ENUM with other databases beyond DNS. > I do need these clarified fairly quickly, as they have an impact not > only on the implementation (you can't interwork without knowing what to > put into the regexp) and as I don't know what the syntax should be in > any "non-terminal" examples. I'm finally back from vacation so fire away with the questions. Sorry it took so long but Alaska was particularly beautiful this time of year: http://bailey.neonym.net/vacation/ -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 17 07:35:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10635 for ; Tue, 17 Sep 2002 07:35:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HBavH07586 for enum-archive@odin.ietf.org; Tue, 17 Sep 2002 07:36:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HBaov07577; Tue, 17 Sep 2002 07:36:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HBZVv07529 for ; Tue, 17 Sep 2002 07:35:31 -0400 Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10606 for ; Tue, 17 Sep 2002 07:33:41 -0400 (EDT) Received: from lawrence.srmr.co.uk ([193.118.205.14] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 7461u via TCP with SMTP; Tue, 17 Sep 2002 12:34:20 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Tue, 17 Sep 2002 12:34:16 +0100 To: michael@neonym.net, paf@cisco.com From: Lawrence Conroy Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] E2U replacement field usage Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Michael, Patrik, folks, I contend that a D3S application will not change, in mid-search, to another D3S application. Thus, if an E2U search has been initiated, the valid outputs will either be a terminal rule OR a non-terminal rule, both of which MUST have E2U within their service field. Given that rfc2916bis specifies both a particular D3S application AND the application-specific usage of DNS, why can't we simply specify that the replacement field MUST be empty, and the regexp field MUST be non-empty? This simplifies the processing, test cases, and so on. It also removes the one place where there is a database-specific item "outside" the rule retrieval process. It also avoids a quirk in the D3S algorithm/D3S database/ ENUM (E2U Application)/ specifications. The conversion from key to DNS domain is "hidden" inside the rule retrieval step. If there is no replacement field, then there's no need to bypass this conversion when looping back from a non-terminal NAPTR as we won't have a domain name already. Thus the question is: - can we specify that the replacement field is ALWAYS empty for ENUM (the E2U D3S Application), and if not, why not? all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 17 08:00:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11344 for ; Tue, 17 Sep 2002 08:00:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HC22I09037 for enum-archive@odin.ietf.org; Tue, 17 Sep 2002 08:02:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HC1mv09025; Tue, 17 Sep 2002 08:01:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HC0uv08969 for ; Tue, 17 Sep 2002 08:00:56 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10989; Tue, 17 Sep 2002 07:59:03 -0400 (EDT) Message-Id: <200209171159.HAA10989@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 17 Sep 2002 07:59:03 -0400 Subject: [Enum] I-D ACTION:draft-brandner-enumservices-compendium-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : 'A compendium of enumservice registrations' Author(s) : R. Brandner et al. Filename : draft-brandner-enumservices-compendium-00.txt Pages : 0 Date : 2002-9-16 This document includes a basic set of enumservice descriptions that are intended for use in deployments of ENUM. These descriptions form a set of enumservice registration requests, as laid out in section 3 of draft-ietf-enum-rfc2916bis-01.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enumservices-compendium-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-brandner-enumservices-compendium-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-brandner-enumservices-compendium-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-16151759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brandner-enumservices-compendium-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-brandner-enumservices-compendium-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-16151759.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 17 08:28:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12149 for ; Tue, 17 Sep 2002 08:28:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HCTSu10585 for enum-archive@odin.ietf.org; Tue, 17 Sep 2002 08:29:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HCTQv10580; Tue, 17 Sep 2002 08:29:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HCSYv10545 for ; Tue, 17 Sep 2002 08:28:34 -0400 Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12137 for ; Tue, 17 Sep 2002 08:26:47 -0400 (EDT) Received: from lawrence.srmr.co.uk ([193.118.205.14] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 7495u via TCP with SMTP; Tue, 17 Sep 2002 13:28:30 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <20020916165358.D640@bailey.dscga.com> References: <20020916165358.D640@bailey.dscga.com> Date: Tue, 17 Sep 2002 13:28:27 +0100 To: Michael Mealling From: Lawrence Conroy Cc: enum@ietf.org, paf@cisco.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: D3S details redux Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 4:53 pm -0400 16/9/02, Michael Mealling wrote: >On Fri, Sep 13, 2002 at 09:42:53AM +0100, Lawrence Conroy wrote: > > * for a non-terminal NAPTR, it seems that the "replacement >field" is not used > > to evaluate the "next round" of D3S processing - the regexp >is used instead. > > => the regexp field has data => the replacement field is empty. >> >> Is this correct? > >Close but not exactly. Either the regexp field or the replacement field >are empty. If the regexp field is empty then the replacement field >will contain the next key. The replacement field is a shortcut way >of saying this: > >/^.*$/example.com/ If it were that simple :) - a better (and valid for ENUM) example would be /^.*$/6.6.6.3.3.4.9.7.1.4.4.e164.arpa/ See my other mail on "E2U replacement field usage" for more on this. > > * for a non-terminal NAPTR, I THINK that the result of regexp >processing should > > be a "pure" E.164 number (e.g. "+441794833666", which means >the next round > > should continue at the ENUM domain >6.6.6.3.3.4.9.7.1.4.4.e164.arpa). This > > fits with the flow diagram in the D3S Algorithm draft, and >with the "output > > of first rule" section in RFC2916bis. >> >> Is this correct? > >Not really. The key has to be database specific. If this wasn't the case >then it would be very hard to use ENUM with other databases beyond DNS. This has me perplexed - I don't think I understand the answer. I think that the key should NOT be database-specific as generated by the output of the first well known rule and the output of non-terminal regexp processing. Otherwise, it's very hard to use another database, which is a major feature of D3S. No data hiding is bad design, IMHO, and D3S was meant to partition the issues so that one could data hide - e.g. the database-specific forms are hidden within the rule retrieval step (step 2 in section 3.3 of ddds-07.txt). That includes the re-write from a "stripped" E.164 number to a domain name - it's the first thing that the rule retrieval function does. If we do want to expose this database-specific format, then I guess what your comment means is that the regexp output for a non-terminal will be a domain name, and rfc2916 needs a re-write to explain that the "domain name translation" is actually part of the first well known rule rather than the start of the rule retrieval process (as does section 6.2 of dns-ddds-database-09.txt). I have to say I HATE this interpretation - writing a regular expression to convert from the AUS to a domain name is non-trivial and very prone to error (and makes the NAPTR much longer). All the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 17 08:50:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12974 for ; Tue, 17 Sep 2002 08:50:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HCqFa11852 for enum-archive@odin.ietf.org; Tue, 17 Sep 2002 08:52:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HCqDv11846; Tue, 17 Sep 2002 08:52:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HCpHv11810 for ; Tue, 17 Sep 2002 08:51:17 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12797 for ; Tue, 17 Sep 2002 08:49:29 -0400 (EDT) Content-Class: urn:content-classes:message Subject: AW: [Enum] Re: D3S details redux MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Tue, 17 Sep 2002 14:53:22 +0200 Message-ID: <06CF906FE3998C4E944213062009F1620247A2@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Re: D3S details redux Thread-Index: AcJeRyFtewQyk9oZTDyBaDwH+CU0MwAAJif7 From: "Stastny Richard" To: "Lawrence Conroy" , "Michael Mealling" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id g8HCpHv11811 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit MM and Lawrence wrote: >Not really. The key has to be database specific. If this wasn't the case >then it would be very hard to use ENUM with other databases beyond DNS. This has me perplexed - I don't think I understand the answer. Richard: Me too. I think that the key should NOT be database-specific as generated by the output of the first well known rule and the output of non-terminal regexp processing. Otherwise, it's very hard to use another database, which is a major feature of D3S. No data hiding is bad design, IMHO, and D3S was meant to partition the issues so that one could data hide - e.g. the database-specific forms are hidden within the rule retrieval step (step 2 in section 3.3 of ddds-07.txt). Richard Just siiting in the ITU SG2/Q1 Rapp Meeting and discussing alternate Roots or TLDs for ENUM, I do not want to see .e164.arpa IN the tree, even if I myself prefer e164.arpa. But if the ENUM root changes, I normally would not care in the Tier 1 and 2. But in the case I have references to the root, I have a problem. This is not modular design. regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 17 09:53:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14928 for ; Tue, 17 Sep 2002 09:53:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HDsfU15225 for enum-archive@odin.ietf.org; Tue, 17 Sep 2002 09:54:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HDsZv15219; Tue, 17 Sep 2002 09:54:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HDqZv15110 for ; Tue, 17 Sep 2002 09:52:35 -0400 Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14866 for ; Tue, 17 Sep 2002 09:50:46 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA04187; Tue, 17 Sep 2002 15:52:20 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA12257; Tue, 17 Sep 2002 15:52:19 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2656.59) id ; Tue, 17 Sep 2002 15:52:19 +0200 Message-ID: From: Brandner Rudolf To: "'enum@ietf.org'" Cc: =?ISO-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , "'Richard Shockey'" Subject: AW: [Enum] I-D ACTION:draft-brandner-enumservices-compendium-00.t xt Date: Tue, 17 Sep 2002 15:52:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g8HDqZv15111 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, After the draft is out I would like to mention that this is a proposal and that examples have been intentionally left out. Conrete examples will have to wait until we know what the syntax is going to be. I would like to refer to the thread "D3S details redux". Examples will then be in a next version. Many thanks, Rudi P.S.: Sorry if duplicated, but I had an e-mail address change recently. > -----Ursprüngliche Nachricht----- > Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Gesendet: Dienstag, 17. September 2002 13:59 > Cc: enum@ietf.org > Betreff: [Enum] I-D > ACTION:draft-brandner-enumservices-compendium-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : 'A compendium of enumservice registrations' > Author(s) : R. Brandner et al. > Filename : draft-brandner-enumservices-compendium-00.txt > Pages : 0 > Date : 2002-9-16 > > This document includes a basic set of enumservice descriptions that > are intended for use in deployments of ENUM. These descriptions form > a set of enumservice registration requests, as laid out in section 3 > of draft-ietf-enum-rfc2916bis-01.txt. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-brandner-enumservice > s-compendium-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > 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-brandner-enumservices-compendium-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-brandner-enumservices-compendium-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 17 10:33:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16927 for ; Tue, 17 Sep 2002 10:33:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HEYRg17486 for enum-archive@odin.ietf.org; Tue, 17 Sep 2002 10:34:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HEYQv17480; Tue, 17 Sep 2002 10:34:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HEV6v17323 for ; Tue, 17 Sep 2002 10:31:06 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16796 for ; Tue, 17 Sep 2002 10:29:17 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g8HET6nB011537; Tue, 17 Sep 2002 10:29:07 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g8HET61v011536; Tue, 17 Sep 2002 10:29:06 -0400 (EDT) Date: Tue, 17 Sep 2002 10:29:05 -0400 From: Michael Mealling To: Lawrence Conroy Cc: michael@neonym.net, paf@cisco.com, enum@ietf.org Message-ID: <20020917102905.K640@bailey.dscga.com> Reply-To: Michael Mealling References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Subject: [Enum] Re: E2U replacement field usage Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Tue, Sep 17, 2002 at 12:34:16PM +0100, Lawrence Conroy wrote: > Hi Michael, Patrik, folks, > > I contend that a D3S application will not change, in mid-search, to > another D3S application. Thus, if an E2U search has been initiated, > the valid outputs will either be a terminal rule OR a non-terminal > rule, both of which MUST have E2U within their service field. That is correct. Changing application inside the algorithm is absolutely illegal (I wouldn't know where to begin in figuring out that one!) > Given that rfc2916bis specifies both a particular D3S application > AND the application-specific usage of DNS, why can't we simply specify > that the replacement field MUST be empty, and the regexp field MUST > be non-empty? You can do that. The replacement field is an easy, BIND-checked way of handling the simple regexp case though. BIND will even include records about anything in the replacement field as additional data. > This simplifies the processing, test cases, and so on. It also removes > the one place where there is a database-specific item "outside" the > rule retrieval process. True... > It also avoids a quirk in the D3S algorithm/D3S database/ ENUM (E2U > Application)/ specifications. The conversion from key to DNS domain > is "hidden" inside the rule retrieval step. If there is no replacement > field, then there's no need to bypass this conversion when looping > back from a non-terminal NAPTR as we won't have a domain name already. You won't have a domain-name? A non-terminal NAPTR will have to produce a domain-name either as the output of the regexp or be found in the replacement field. Even if you specify that the replacement field is always blank then a non-terminal NAPTR will still have to produce a valid domain-name for the next set of records. Or did I read that last paragraph wrong? > Thus the question is: > - can we specify that the replacement field is ALWAYS empty for ENUM > (the E2U D3S Application), and if not, why not? Yes. You can tie the replacement field down as always null since the regexp can still produce the same value. Since we don't have per-field compression anymore anyway you really won't take a hit on the packet size. The only feature you won't get is BIND 8 and 9 have a default behavior where they _always_ insert additional information about domain-names when they are inserted into a response packet. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 17 10:48:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17460 for ; Tue, 17 Sep 2002 10:48:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HEo8e18614 for enum-archive@odin.ietf.org; Tue, 17 Sep 2002 10:50:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HEo7v18608; Tue, 17 Sep 2002 10:50:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HEn4v18558 for ; Tue, 17 Sep 2002 10:49:04 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17430 for ; Tue, 17 Sep 2002 10:47:14 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g8HEktnB011601; Tue, 17 Sep 2002 10:46:55 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g8HEkshw011600; Tue, 17 Sep 2002 10:46:54 -0400 (EDT) Date: Tue, 17 Sep 2002 10:46:54 -0400 From: Michael Mealling To: Lawrence Conroy Cc: Michael Mealling , enum@ietf.org, paf@cisco.com Message-ID: <20020917104654.L640@bailey.dscga.com> Reply-To: Michael Mealling References: <20020916165358.D640@bailey.dscga.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Subject: [Enum] Re: D3S details redux Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Tue, Sep 17, 2002 at 01:28:27PM +0100, Lawrence Conroy wrote: > At 4:53 pm -0400 16/9/02, Michael Mealling wrote: > >On Fri, Sep 13, 2002 at 09:42:53AM +0100, Lawrence Conroy wrote: > > > * for a non-terminal NAPTR, it seems that the "replacement > >field" is not used > > > to evaluate the "next round" of D3S processing - the regexp > >is used instead. > > > => the regexp field has data => the replacement field is empty. > >> > >> Is this correct? > > > >Close but not exactly. Either the regexp field or the replacement field > >are empty. If the regexp field is empty then the replacement field > >will contain the next key. The replacement field is a shortcut way > >of saying this: > > > >/^.*$/example.com/ > > If it were that simple :) - a better (and valid for ENUM) example would > be /^.*$/6.6.6.3.3.4.9.7.1.4.4.e164.arpa/ Actually, it was that simple. Remember, the replacement field on a non-terminal NAPTR is never seen or used beyond that cycle in the algorithm. Just as long as the resulting domain-name has the correct NAPTR records associated with it. I.e. First loop produces a query for 2.3.7.0.7.1.7.0.7.7.1.e164.arpa that returns a NAPTR that is non-terminal and has "neonym.net" in its replacement field. "neonym.net" is queried for NAPTRs and it gets back a series of NAPTR records with the correct ENUM NAPTRs that contain the valid terminal records... > > > * for a non-terminal NAPTR, I THINK that the result of regexp > >processing should > > > be a "pure" E.164 number (e.g. "+441794833666", which means > >the next round > > > should continue at the ENUM domain > >6.6.6.3.3.4.9.7.1.4.4.e164.arpa). This > > > fits with the flow diagram in the D3S Algorithm draft, and > >with the "output > > > of first rule" section in RFC2916bis. > >> > >> Is this correct? > > > >Not really. The key has to be database specific. If this wasn't the case > >then it would be very hard to use ENUM with other databases beyond DNS. > > This has me perplexed - I don't think I understand the answer. > > I think that the key should NOT be database-specific as generated by the > output of the first well known rule and the output of non-terminal regexp > processing. Keys are internal to the algorithm. You should never see or use them outside it. The input to the algorithm is the Application Unique String and the output is the output of the last matching rule. Keys are internal and database dependent. > Otherwise, it's very hard to use another database, which is a major feature > of D3S. No data hiding is bad design, IMHO, and D3S was meant to partition > the issues so that one could data hide - e.g. the database-specific forms > are hidden within the rule retrieval step (step 2 in section 3.3 of > ddds-07.txt). Its the Rules that are mostly database independent. They still must produce a key that is meaningful to the database, but the semantics are somewhat portable (not that some databases may have interesting 'semantics' like DNS that impact Rules). I looked at how other databases would be used and it became immediately clear that keys (and to some extent Rules) had to be database dependent. Its the inputs and outputs that are visible. All the data hiding is internal to the algorithm. Once you get beyond the First Well Known Rule you should consider DDDS to be a black box.... > That includes the re-write from a "stripped" E.164 number to a domain name - > it's the first thing that the rule retrieval function does. One of the requirements built into DDDS was that the output of one rule is not allowed to be the input of another rule. All Rules must only ever consider the AUS. What I think you are suggesting is that a non-terminal Rule be able to produce a telephone number and not a domain-name. The only value I can see in doing that is being able to switch database types mid-algorithm which would, IMHO, be a bad thing. If you really need to do it then there is the old 'p' flag from the URI Resolution application. > If we do want to expose this database-specific format, Actually, I don't want to expose it. It should never be seen outside the algorithm.... > then I guess what your comment means is that the regexp output for a > non-terminal will be a domain name, and rfc2916 needs a re-write to explain > that the "domain name translation" is actually part of the first well known > rule rather than the start of the rule > retrieval process (as does section 6.2 of dns-ddds-database-09.txt). Correct. I'll go correct what I wrote latter today... > I have to say I HATE this interpretation - writing a regular expression to > convert from the AUS to a domain name is non-trivial and very prone to error > (and makes the NAPTR much longer). Nope. You won't ever need to use a regexp to convert an AUS into a domain-name. Remember, internal to the algorithm the domain-name can be _anything_. > Even blue-er than the pictures made it look. Its a shade I've never really seen before. Very stricking... and _cold_. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 17 11:02:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17899 for ; Tue, 17 Sep 2002 11:02:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HF45F19208 for enum-archive@odin.ietf.org; Tue, 17 Sep 2002 11:04:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HF42v19200; Tue, 17 Sep 2002 11:04:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HF2Lv19151 for ; Tue, 17 Sep 2002 11:02:21 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17847 for ; Tue, 17 Sep 2002 11:00:31 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g8HF0NnB011641; Tue, 17 Sep 2002 11:00:23 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g8HF0Mwp011640; Tue, 17 Sep 2002 11:00:22 -0400 (EDT) Date: Tue, 17 Sep 2002 11:00:21 -0400 From: Michael Mealling To: Stastny Richard Cc: Lawrence Conroy , Michael Mealling , enum@ietf.org, paf@cisco.com Subject: Re: [Enum] Re: D3S details redux Message-ID: <20020917110021.M640@bailey.dscga.com> Reply-To: Michael Mealling References: <06CF906FE3998C4E944213062009F1620247A2@oefeg-s02.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06CF906FE3998C4E944213062009F1620247A2@oefeg-s02.oefeg.loc> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Tue, Sep 17, 2002 at 02:53:22PM +0200, Stastny Richard wrote: > MM and Lawrence wrote: > >>>Not really. The key has to be database specific. If this wasn't the case >>>then it would be very hard to use ENUM with other databases beyond DNS. > >>This has me perplexed - I don't think I understand the answer. > > > Richard: Me too. > >> I think that the key should NOT be database-specific as generated by the >> output the first well known rule and the output of non-terminal regexp >> processing. > >> Otherwise, it's very hard to use another database, which is a major feature >> of D3S. No data hiding is bad design, IMHO, and D3S was meant to partition >> the issues so that one could data hide - e.g. the database-specific forms >> are hidden within the rule retrieval step (step 2 in section 3.3 of >> ddds-07.txt). > > Richard Just siiting in the ITU SG2/Q1 Rapp Meeting and discussing > alternate Roots or TLDs for ENUM, I do not want to see .e164.arpa IN > the tree, even if I myself prefer e164.arpa. But if the ENUM root changes, > I normally would not care in the Tier 1 and 2. But in the case I have > references to the root, I have a problem. This is not modular design. You shouldn't have 'e164.arpa' internal to your tree. You can but you don't need to. What we're talking about here are non-terminal NAPTRs. If you NAPTR is terminal then the output of the regexp is the URI you wanted. If you want to delegate further then just use an NS record for the delegation. Non-terminal NAPTRs in most cases do the same thing an NS record does. The exception is that there is an actual rewrite of the domain-name being queried (much like what DNAME can do). I.e. if you had an NS record delegation the nameserver being delegated to would have to be authoritative for the domain. But with a non-terminal NAPTR you can send the client off to "bugglewort.its-really-cold-here.aq" to get the next set of NAPTRs. Either way, you never have to have the root in a NAPTR rewrite field unless you really want it for some unknown reason. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 17 11:16:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18420 for ; Tue, 17 Sep 2002 11:16:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HFIGl20310 for enum-archive@odin.ietf.org; Tue, 17 Sep 2002 11:18:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HFIFv20305; Tue, 17 Sep 2002 11:18:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HFFtv20191 for ; Tue, 17 Sep 2002 11:15:55 -0400 Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18269 for ; Tue, 17 Sep 2002 11:14:06 -0400 (EDT) Received: from lawrence.srmr.co.uk ([193.118.205.14] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 7516u via TCP with SMTP; Tue, 17 Sep 2002 16:15:48 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Tue, 17 Sep 2002 16:15:46 +0100 To: michael@neonym.net From: Lawrence Conroy Cc: enum@ietf.org, richard.stastny@oefeg.at Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] ENUM root shift Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Michael, Folks, In response to my earlier comment, At 10:46 am -0400 17/9/02, Michael Mealling wrote: > > If it were that simple :) - a better (and valid for ENUM) example would >> be /^.*$/6.6.6.3.3.4.9.7.1.4.4.e164.arpa/ > >Actually, it was that simple. Remember, the replacement field on a >non-terminal >NAPTR is never seen or used beyond that cycle in the algorithm. Just as >long as the resulting domain-name has the correct NAPTR records associated >with it. I.e. > >First loop produces a query for 2.3.7.0.7.1.7.0.7.7.1.e164.arpa that >returns a NAPTR that is non-terminal and has "neonym.net" in its >replacement field. "neonym.net" is queried for NAPTRs and it gets back >a series of NAPTR records with the correct ENUM NAPTRs that contain >the valid terminal records... In the words of many an ITU rec, FFS. The E2U application is specified specifically for use within the e164.arpa domain space. Good timing. It may be the wish of some companies that this not be the case, but we have been through this argument before. Anywhere other than e164.arpa. is specifically excluded for the E2U Application. One can have an ENUM-like service on any root (or set of alternative roots) one wants, but ENUM is rooted in one domain space. Neonym.net (or siemens.com) is not it. most sincerely, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Sep 17 11:29:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18934 for ; Tue, 17 Sep 2002 11:29:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HFV7A20845 for enum-archive@odin.ietf.org; Tue, 17 Sep 2002 11:31:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HFV6v20839; Tue, 17 Sep 2002 11:31:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HFSav20684 for ; Tue, 17 Sep 2002 11:28:36 -0400 Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18832 for ; Tue, 17 Sep 2002 11:26:46 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g8HFQlnB011700; Tue, 17 Sep 2002 11:26:47 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g8HFQkA6011699; Tue, 17 Sep 2002 11:26:46 -0400 (EDT) Date: Tue, 17 Sep 2002 11:26:46 -0400 From: Michael Mealling To: Lawrence Conroy Cc: michael@neonym.net, enum@ietf.org, richard.stastny@oefeg.at Subject: Re: [Enum] ENUM root shift Message-ID: <20020917112646.N640@bailey.dscga.com> Reply-To: Michael Mealling References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Tue, Sep 17, 2002 at 04:15:46PM +0100, Lawrence Conroy wrote: > In response to my earlier comment, > At 10:46 am -0400 17/9/02, Michael Mealling wrote: > > > If it were that simple :) - a better (and valid for ENUM) example would > >> be /^.*$/6.6.6.3.3.4.9.7.1.4.4.e164.arpa/ > > > >Actually, it was that simple. Remember, the replacement field on a > >non-terminal > >NAPTR is never seen or used beyond that cycle in the algorithm. Just as > >long as the resulting domain-name has the correct NAPTR records associated > >with it. I.e. > > > >First loop produces a query for 2.3.7.0.7.1.7.0.7.7.1.e164.arpa that > >returns a NAPTR that is non-terminal and has "neonym.net" in its > >replacement field. "neonym.net" is queried for NAPTRs and it gets back > >a series of NAPTR records with the correct ENUM NAPTRs that contain > >the valid terminal records... > > In the words of many an ITU rec, FFS. > > The E2U application is specified specifically for use > within the e164.arpa domain space. And it is. But we're talking about _internal_ to the algorithm. Not where the First Well Known Rule is rooted. > Good timing. It may be the wish of some companies that this > not be the case, but we have been through this argument before. I am not one of those. I'm speaking personally at this point: ENUM is intended to have one root. DDDS can't work without that requirement being adhered to rigourously. But the DDDS _is_ built so that the actual domain-name being used as a key internal to the algorithm is _opaque_. It can literally be any valid domain-name. > Anywhere other than e164.arpa. is specifically excluded for > the E2U Application. One can have an ENUM-like service on > any root (or set of alternative roots) one wants, but ENUM > is rooted in one domain space. Neonym.net (or siemens.com) > is not it. Woah Nelly.... We have to be very clear here. ENUM is _rooted_ in E164.ARPA. Once you're inside the algorithm, non-terminal NAPTRs can point you anywhere. But you still start out in the e164.arpa space and delegate down authoritatively. Its the same thing as an NS record but it uses a domain-name instead of a IP address. This discussion is _not_ about alternative roots. If there is a misunderstanding about that it then we are really talking past each other... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net -------------------------------------------------------------------------------- !! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !! !! you can send something along with it! Business cards, momentos, cremains, !!|| anything! See http://www.transorbital.net for details! !! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 18 10:41:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15777 for ; Wed, 18 Sep 2002 10:41:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8IEgT721996 for enum-archive@odin.ietf.org; Wed, 18 Sep 2002 10:42:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8IEgBv21972; Wed, 18 Sep 2002 10:42:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8IEcFv21754 for ; Wed, 18 Sep 2002 10:38:15 -0400 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15501 for ; Wed, 18 Sep 2002 10:36:26 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g8IEbTG17969; Wed, 18 Sep 2002 14:37:29 GMT Message-Id: <5.1.0.14.2.20020918103602.043f5e08@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 18 Sep 2002 10:38:30 -0400 To: Michael Mealling , Lawrence Conroy From: Richard Shockey Subject: Re: [Enum] ENUM root shift Cc: enum@ietf.org, richard.stastny@oefeg.at In-Reply-To: <20020917112646.N640@bailey.dscga.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > > >Woah Nelly.... We have to be very clear here. ENUM is _rooted_ in >E164.ARPA. Once you're inside the algorithm, non-terminal NAPTRs >can point you anywhere. But you still start out in the e164.arpa >space and delegate down authoritatively. Its the same thing as >an NS record but it uses a domain-name instead of a IP address. > >This discussion is _not_ about alternative roots. If there is >a misunderstanding about that it then we are really talking >past each other... Really .... now there is nothing to prevent anyone from developing a internal DDDS application for an internal corporate dialing plan ... and if the internal well known rules just happen to match the syntax of the enumservice fields we develop the net police will not come knocking on the door. >-MM > >-- >-------------------------------------------------------------------------------- >Michael Mealling | Vote Libertarian! | urn:pin:1 >michael@neonym.net | | http://www.neonym.net >-------------------------------------------------------------------------------- >!! The Trailblazer spacecraft is going to the Moon! And for just $2500 a >gram !! >!! you can send something along with it! Business cards, momentos, >cremains, !!|| anything! See http://www.transorbital.net for >details! !! > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 18 18:12:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01924 for ; Wed, 18 Sep 2002 18:12:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8IME8o15100 for enum-archive@odin.ietf.org; Wed, 18 Sep 2002 18:14:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8IME3v15095; Wed, 18 Sep 2002 18:14:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8IMCev15054 for ; Wed, 18 Sep 2002 18:12:40 -0400 Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01865 for ; Wed, 18 Sep 2002 18:10:42 -0400 (EDT) Received: from lawrence.srmr.co.uk ([193.118.205.14] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 7580u via TCP with SMTP; Wed, 18 Sep 2002 23:12:03 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <5.1.0.14.2.20020918103602.043f5e08@popd.ix.netcom.com> References: <5.1.0.14.2.20020918103602.043f5e08@popd.ix.netcom.com> Date: Wed, 18 Sep 2002 23:11:57 +0100 To: Richard Shockey , Michael Mealling From: Lawrence Conroy Subject: Re: [Enum] ENUM root shift Cc: enum@ietf.org, richard.stastny@oefeg.at Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 10:38 am -0400 18/9/02, Richard Shockey wrote, in response to MMs' clarification of my earlier comment: >>Woah Nelly.... We have to be very clear here. ENUM is _rooted_ in >>E164.ARPA. Once you're inside the algorithm, non-terminal NAPTRs >>can point you anywhere. But you still start out in the e164.arpa >>space and delegate down authoritatively. Its the same thing as >>an NS record but it uses a domain-name instead of a IP address. >> >>This discussion is _not_ about alternative roots. If there is >>a misunderstanding about that it then we are really talking >>past each other... > > >Really .... now there is nothing to prevent anyone from developing a >internal DDDS application for an internal corporate dialing plan ... >and if the internal well known rules just happen to match the syntax >of the enumservice fields we develop the net police will not come >knocking on the door. > Hi Folks, as the initiator of this by my misunderstanding, I'm really happy that we are all in furious agreement - and that, yes, one can use a different root, and if it's an internal D3S scheme then the net police won't get ya. Of course, it may be illegal - with the volume of law that seems to pass 'nourdays, you never know. I trust the IAB/ISOC at least won't arrest the perps in your CIO's office for contravening clause 2.4-3 of RFC2916bis. This isn't SIP, after all. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Sep 18 18:19:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02056 for ; Wed, 18 Sep 2002 18:19:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8IMLGb15311 for enum-archive@odin.ietf.org; Wed, 18 Sep 2002 18:21:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8IMLGv15306; Wed, 18 Sep 2002 18:21:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8IMKov15290 for ; Wed, 18 Sep 2002 18:20:50 -0400 Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02051 for ; Wed, 18 Sep 2002 18:18:56 -0400 (EDT) Received: from lawrence.srmr.co.uk ([193.118.205.14] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 7605u via TCP with SMTP; Wed, 18 Sep 2002 23:20:36 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: References: <5.1.0.14.2.20020918103602.043f5e08@popd.ix.netcom.com> Date: Wed, 18 Sep 2002 23:20:32 +0100 To: Richard Shockey , Michael Mealling From: Lawrence Conroy Subject: Re: [Enum] ENUM root shift Cc: enum@ietf.org, richard.stastny@oefeg.at Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi again Folks, >perps in your CIO's office for contravening clause 2.4-3 of RFC2916bis. Oops! that should , of course, have been clause 2.4-4. atb, Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Sep 19 03:46:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23003 for ; Thu, 19 Sep 2002 03:46:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8J7luh19932 for enum-archive@odin.ietf.org; Thu, 19 Sep 2002 03:47:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8J7lqv19927; Thu, 19 Sep 2002 03:47:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8ILW7v12848 for ; Wed, 18 Sep 2002 17:32:07 -0400 Received: from pinochet.cityline.ru (pinochet.cityline.ru [195.46.160.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00727; Wed, 18 Sep 2002 17:30:13 -0400 (EDT) Received: from 1 (ts22-a65.dial.sovam.com [212.46.232.65] (may be forged)) by pinochet.cityline.ru (8.11.6/t/08-Oct-1998) with SMTP id g8ILTbo27457; Thu, 19 Sep 2002 01:29:38 +0400 (MSD) Message-ID: <02ae01c25f5a$3b119aa0$26e92ed4@1> From: =?koi8-r?B?8MHXxcwg8tHCycvP1w==?= <2519636@mail.ru> To: , , , Date: Thu, 19 Sep 2002 01:27:33 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A9_01C25F7B.BB870780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Enum] comments for Connect! world of communication magazine (www.connect.ru_ Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_02A9_01C25F7B.BB870780 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Good day I'm freelance rusian journalist/ Once I found for myself, that number = login =3Dphone=3Ddomain is a very comfortable in my professionn. one my colleague (mailto:vsev@ripn.net) has sent me reference to ENUM = project of your organization/I gonna write little article about = practical benefit of this possibilty usage/ But I don't undderstand one thing: as i can understand, ENUM advaces a = specisl web arcitecture for this (?), I've got no education in IT, and = ENUM 's project sense is not quite clear for me/=20 ) Are you gonna realize any practical measures for advertizing of = obvious benefits login=3Dtelephone=3Ddomain names or specialize in = technical aspects of this thing? (But even for me,not advanced user = even, quite clear principles and benefits of number logins regisration/ p.s/ sorry for my english, thankful in advance for the answers Pavel. ------=_NextPart_000_02A9_01C25F7B.BB870780 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Good day
I'm freelance rusian journalist/ = Once I found=20 for myself, that number login =3Dphone=3Ddomain is a very comfortable in = my=20 professionn.
one my colleague (mailto:vsev@ripn.net) has sent me = reference to=20 ENUM project of your organization/I gonna write little article about = practical=20 benefit of this possibilty usage/
But I don't undderstand one = thing: as i can=20 understand, ENUM advaces a specisl web arcitecture for this (?), I've = got no=20 education in IT, and ENUM 's project sense is not quite clear for me/=20
) Are you gonna realize any = practical=20 measures for advertizing of obvious benefits login=3Dtelephone=3Ddomain = names or=20 specialize in technical aspects of this thing? (But even for me,not = advanced=20 user even, quite clear principles and benefits of  number logins=20 regisration/
p.s/ sorry for my english, = thankful in=20 advance for the answers
Pavel.
------=_NextPart_000_02A9_01C25F7B.BB870780-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Sep 19 13:28:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15361 for ; Thu, 19 Sep 2002 13:28:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8JHUJn24429 for enum-archive@odin.ietf.org; Thu, 19 Sep 2002 13:30:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8JHU9v24416; Thu, 19 Sep 2002 13:30:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8JHSLv24308 for ; Thu, 19 Sep 2002 13:28:21 -0400 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15275 for ; Thu, 19 Sep 2002 13:26:29 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g8JHRjG28667 for ; Thu, 19 Sep 2002 17:27:45 GMT Message-Id: <5.1.0.14.2.20020919132721.041b58c0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 19 Sep 2002 13:27:53 -0400 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-odoherty-sipping-pstn-number-association-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , There is a bit of a debate going on in the SIPPING WG about this you'all might want to take a look at it. >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-odoherty-sipping-pstn-number-association-00.txt >Date: Thu, 19 Sep 2002 07:46:57 -0400 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : SIP PSTN Number Association > Author(s) : M. O'Doherty, M. Ashworth > Filename : > draft-odoherty-sipping-pstn-number-association-00.txt > Pages : 5 > Date : 2002-9-18 > >This document describes a specific requirement for associating >SIP endpoints with PSTN (Public switched telephony Network) >endpoints, not for the SIP endpoint to replace the PSTN endpoint, >but to allow them to be used together. It outlines some potential >ways of addressing this requirement and proposes one of the >options as the best case approach. >Additionally, it describes a general requirement that fell out >from this scenario and that might be a good candidate for further >study. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-odoherty-sipping-pstn-number-association-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-odoherty-sipping-pstn-number-association-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-odoherty-sipping-pstn-number-association-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: <2002-9-18151222.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-odoherty-sipping-pstn-number-association-00.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Sep 19 13:29:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15374 for ; Thu, 19 Sep 2002 13:29:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8JHUMx24456 for enum-archive@odin.ietf.org; Thu, 19 Sep 2002 13:30:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8JHUMv24451; Thu, 19 Sep 2002 13:30:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8JHSLv24311 for ; Thu, 19 Sep 2002 13:28:21 -0400 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15274 for ; Thu, 19 Sep 2002 13:26:29 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g8JHRkG28673 for ; Thu, 19 Sep 2002 17:27:46 GMT Message-Id: <5.1.0.14.2.20020919132933.0412da08@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 19 Sep 2002 13:29:57 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: RE: [Sipping] Associating SIP sessions with PSTN calls Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , FYI from the sipping list.. >Date: Thu, 19 Sep 2002 11:41:34 -0400 >From: "David R. Oran" >To: "Michael O'Doherty" , > "'Alan Johnston'" , > "'Tom_Gray@Mitel.COM'" >cc: "'sipping@ietf.org'" >Subject: RE: [Sipping] Associating SIP sessions with PSTN calls >X-Mailer: Mulberry/3.0.0b3 (Win32) >Sender: sipping-admin@ietf.org >X-BeenThere: sipping@ietf.org >X-Mailman-Version: 2.0.12 >List-Unsubscribe: , > >List-Id: SIPPING Working Group (applications of SIP) >List-Post: >List-Help: >List-Subscribe: , > > >--On Thursday, September 19, 2002 11:20 AM +0100 Michael O'Doherty > wrote: > >> >>Alan, >> >>Couple of comments on this approach: >> >>- firstly, I think this would mean that the proxy would have to look at >>the body to decide what type of call it was handling. >Why, pray tell? What is missing from the SIP headers that is needed? > >>I did'nt think >>proxy's were allowed to do this (although I admit I could'nt see anything >>in a quick span of the proxy behaviour scetion of the RFC). >Some proxies look at bodies. They'd better not depend on it though, >because once end-to-end SMIME shows up all they'll see is ciphertext. > >>- assuming we get around the above point somehow, this solution means >>that the callee is effectively choosing the point where the call breaks >>out form the SIP network to the PSTN. >Not necessarily. All the callee's proxy is deciding is whether the call >goes to a contact (or contacts) on the IP network, or to a contact (or >contacts) on the PSTN. Where the call actually exits to the PSTN is a >routing issue dealt with by gateway routing protocols like TRIP. > >>In some cases it may be more efficient for the caller to decide the >>breakout point (if the callee is located someplace where they can't get >>good enough QoS for voice but it is fine for whiteboarding applications >>etc and they want to force the caller to break out to the PSTN as soon as >>possible. >You're mixing signaling and media here. It doesn't matter one whit if the >SIP signaling goes half-way around the world as long as the right exit >gateway is selected based on where the call came in (if it came in from >the PSTN) and where it's going (if it exits to the PSTN). Again, this is >part of routing, not part of ENUM directories or proxy forking policy. > >>Or they might just want the caller to incur any costs >>associated with the SIP to PSTN breakout ...). >Billing is a separate thorny issue. One thing I'm pretty confident of is >that ENUM is not the place to be putting policy about billing. > >One meta-comment I will make is that the issues you raise are all related >to ROUTING - i.e. the selection of the path between A&B rather than >whether A talks to B or C, or D. Routing needs routing protocols (e.g >TRIP, TGRP). ENUM is a *directory* scheme, which means it depends on the >destination only, not the source, and hence cannot do much of what is >needed to solve the routing problem. > >Dave. > >>Cheers, >> >>Mick. >> >>-----Original Message----- >>From: Alan Johnston [mailto:alan.johnston@wcom.com] >>Sent: 18 September 2002 19:59 >>To: O'Doherty, Michael [MDN05:MD01:EXCH]; 'Tom_Gray@Mitel.COM' >>Cc: 'sipping@ietf.org' >>Subject: RE: [Sipping] Associating SIP sessions with PSTN calls >> >>Michael, >> >>Tom is right - ENUM is the right solution to this. Here is how it could >>work: >> >>If the PSTN number is dialed in the PSTN, it routes as normally and rings >>the user's PSTN phone, which is what you want. >> >>If the PSTN number is dialed in a SIP network which does not query ENUM, >>the call will be routed to a PSTN gateway and ring the user's PSTN phone, >>which again is a success. >> >>If the PSTN number is dialed in a SIP network that does query ENUM, it >>returns a SIP URI for the endpoint. An INVITE is then sent to the proxy >>in the domain of the SIP URI, which presumably is the service provider >>for the user. The proxy knows that this user wishes to receive calls on >>their PSTN phone (for some reason), so it routes the call to a PSTN >>gateway and rings the user's phone. >> >>Any SIP requests which are for other media sessions or any other purpose >>are routed using ENUM to the proxy, which forwards them to the SIP User >>Agent, which establishes the associated session you are after (whatever >>that is). >> >>You are right, however, in noting that this sort of use is not described >>in any of the ENUM documents - they mainly describe a whole set of >>questionable uses for ENUM that simply don't work. I would encourage you >>to bring this up on the ENUM list, as this is exactly what ENUM was >>designed to do. >> >>Thanks, >>Alan Johnston >>sip:alan@digitalari.com >> >>At 07:16 PM 9/18/2002 +0100, Michael O'Doherty wrote: >> >>>Tom, >>> >>>The first option in the draft below looks at ENUM. >>> >>>The main problem is if the user wants to use their PSTN phone for voice >>>calls (even from SIP phones) and their SIP device for other media >>>sessions (like PSTN associated sessions). >>> >>>How do we indicate with an ENUM response that voice calls should go to >>>the PSTN number and other media/mixed media calls to a SIP device (one >>>suggestion here was that if ENUM returns a tel URL as one of the options >>>for routing then that option MUST be used if the call is a voice call) ? >>> >>>We couldn't see any nice clean way to do this with ENUM as it stands >>>today - option 4 in the draft (using a well know domain to do the CLI >>>lookup) just seemed to be less messy and more obvious. >>> >>>Comments ? >>> >>>Cheers, >>> >>>Mick. >>> >>> >>>-----Original Message----- >>>From: Tom_Gray@Mitel.COM >>>[mailto:Tom_Gray@Mitel.COM] >>>Sent: 18 September 2002 18:35 >>>To: O'Doherty, Michael [MDN05:MD01:EXCH] >>>Cc: 'sipping@ietf.org' >>>Subject: Re: [Sipping] Associating SIP sessions with PSTN calls >>> >>> >>> >>>Why can't the answer to this be ENUM? >>> >>> >>> >>> >>> >>>"Michael O'Doherty" @ietf.org on 09/18/2002 >>>11:43:55 AM >>> >>>Sent by: sipping-admin@ietf.org >>> >>>To: "'sipping@ietf.org'" >>>cc: >>>Subject: [Sipping] Associating SIP sessions with PSTN calls >>> >>> >>> >>>Hi, >>> >>>The draft below describes a number of schemes to allow a SIP session be >>>associated with a PSTN call, plus the authors choice of the best >>>approach from the options briefly described. >>> >>>We'd be interested to see if anyone has any comments, in particular if >>>there are any options we missed. >>> >>>Additionally, looking at this problem domain threw up a more general >>>requirement also: >>> >>> - the ability to route a SIP request differently depending on the media >>>service that the request is requesting >>> >>>Do people feel this is a valid requirement in a SIP networks and if so >>>has anybody any thoughts on how it might be addressed ? >>> >>>Cheers, >>> >>>Mick. >>> >>>The draft can be retrieved form the link below until it shows up in the >>>archives: >>> >>>> >>>tion-01.txt>http://ties.itu.int/~watsonm/draft-odoherty-sipping-pstn-num >>>ber-association-01.txt >> >>> >>> > >------------------------ >David R. Oran >Cisco Systems >7 Ladyslipper Lane >Acton, MA 01720 >Office: +1 978 264 2048 >VoIP: +1 408 571 4576 >Email: oran@cisco.com >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Sep 19 13:29:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15387 for ; Thu, 19 Sep 2002 13:29:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8JHUOP24487 for enum-archive@odin.ietf.org; Thu, 19 Sep 2002 13:30:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8JHUOv24478; Thu, 19 Sep 2002 13:30:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8JHSXv24329 for ; Thu, 19 Sep 2002 13:28:33 -0400 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15302; Thu, 19 Sep 2002 13:26:41 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g8JHRjG28670; Thu, 19 Sep 2002 17:27:45 GMT Message-Id: <5.1.0.14.2.20020919132609.041ba1c0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 19 Sep 2002 13:28:49 -0400 To: Alan Johnston , "Michael O'Doherty" , "'Tom_Gray@Mitel.COM'" From: Richard Shockey Cc: "'sipping@ietf.org'" , enum@ietf.org In-Reply-To: <5.1.1.6.0.20020918134845.02745bf8@pop.mcit.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] RE: [Sipping] Associating SIP sessions with PSTN calls Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 01:58 PM 9/18/2002 -0500, Alan Johnston wrote: >Michael, > >Tom is right - ENUM is the right solution to this. Here is how it could work: > >If the PSTN number is dialed in the PSTN, it routes as normally and rings >the user's PSTN phone, which is what you want. > >If the PSTN number is dialed in a SIP network which does not query ENUM, >the call will be routed to a PSTN gateway and ring the user's PSTN phone, >which again is a success. > >If the PSTN number is dialed in a SIP network that does query ENUM, it >returns a SIP URI for the endpoint. An INVITE is then sent to the proxy >in the domain of the SIP URI, which presumably is the service provider for >the user. The proxy knows that this user wishes to receive calls on their >PSTN phone (for some reason), so it routes the call to a PSTN gateway and >rings the user's phone. > >Any SIP requests which are for other media sessions or any other purpose >are routed using ENUM to the proxy, which forwards them to the SIP User >Agent, which establishes the associated session you are after (whatever >that is). > >You are right, however, in noting that this sort of use is not described >in any of the ENUM documents - they mainly describe a whole set of >questionable uses for ENUM that simply don't work. I would encourage you >to bring this up on the ENUM list, as this is exactly what ENUM was >designed to do. Yes please .. as your friendly neighborhood ENUM WG -co chair I encourage this. I will cross post the document to my list ASAP. We've been over a lot of this ground already. >Thanks, >Alan Johnston >sip:alan@digitalari.com > > >At 07:16 PM 9/18/2002 +0100, Michael O'Doherty wrote: > >>Tom, >> >>The first option in the draft below looks at ENUM. >> >>The main problem is if the user wants to use their PSTN phone for voice >>calls (even from SIP phones) and their SIP device for other media >>sessions (like PSTN associated sessions). >> >>How do we indicate with an ENUM response that voice calls should go to >>the PSTN number and other media/mixed media calls to a SIP device (one >>suggestion here was that if ENUM returns a tel URL as one of the options >>for routing then that option MUST be used if the call is a voice call) ? >> >>We couldn't see any nice clean way to do this with ENUM as it stands >>today - option 4 in the draft (using a well know domain to do the CLI >>lookup) just seemed to be less messy and more obvious. >> >>Comments ? >> >>Cheers, >> >>Mick. >> >> >>-----Original Message----- >>From: Tom_Gray@Mitel.COM >>[mailto:Tom_Gray@Mitel.COM] >>Sent: 18 September 2002 18:35 >>To: O'Doherty, Michael [MDN05:MD01:EXCH] >>Cc: 'sipping@ietf.org' >>Subject: Re: [Sipping] Associating SIP sessions with PSTN calls >> >> >> >>Why can't the answer to this be ENUM? >> >> >> >> >> >>"Michael O'Doherty" @ietf.org on 09/18/2002 >>11:43:55 AM >> >>Sent by: sipping-admin@ietf.org >> >>To: "'sipping@ietf.org'" >>cc: >>Subject: [Sipping] Associating SIP sessions with PSTN calls >> >> >> >>Hi, >> >>The draft below describes a number of schemes to allow a SIP session be >>associated with a PSTN call, plus the authors choice of the best approach >>from the options briefly described. >> >>We'd be interested to see if anyone has any comments, in particular if >>there are any options we missed. >> >>Additionally, looking at this problem domain threw up a more general >>requirement also: >> >> - the ability to route a SIP request differently depending on the media >>service that the request is requesting >> >>Do people feel this is a valid requirement in a SIP networks and if so has >>anybody any thoughts on how it might be addressed ? >> >>Cheers, >> >>Mick. >> >>The draft can be retrieved form the link below until it shows up in the >>archives: >> >>http://ties.itu.int/~watsonm/draft-odoherty-sipping-pstn-number-association-01.txt >> >> > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Sep 20 03:43:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15540 for ; Fri, 20 Sep 2002 03:43:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8K7jBr13192 for enum-archive@odin.ietf.org; Fri, 20 Sep 2002 03:45:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8K7j5v13187; Fri, 20 Sep 2002 03:45:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8K7iDv13133 for ; Fri, 20 Sep 2002 03:44:13 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15489; Fri, 20 Sep 2002 03:40:28 -0400 (EDT) Subject: AW: [Enum] RE: [Sipping] Associating SIP sessions with PSTN calls Date: Fri, 20 Sep 2002 09:44:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-ID: <06CF906FE3998C4E944213062009F1620247BD@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [Enum] RE: [Sipping] Associating SIP sessions with PSTN calls Thread-Index: AcJgA8gE0roCVaiFRfeuF0Gy9x0CQwAcXlcl From: "Stastny Richard" To: "Richard Shockey" , "Alan Johnston" , "Michael O'Doherty" , "Tom_Gray@Mitel.COM" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id g8K7iDv13135 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Thank you Richard for forwarding this discussion to the ENUM list. As you stated below, the topic has already been discussed (;-) sigh) at the ENUM list. There is also existing my draft-stastny-enum-scenarios-00.txt which beside other issues dealing with this problem. Furthermore I want to point out that exactly the discribed scenario is one of the main topics of our ENUM-trials, especially the VISIONng ENUM-trial dealing with +87810 UPT. In the case of personal numbers the calls are routed as described below on the PSTN in the normal way to a gateway. In addition, a GW (either SIP or H323) exists on the Internet. The ENUM entry contains a pointer to this gateway. Anybody querying ENUM may directly route the call to this gateway and the call is terminating in the same way as if it would come from the PSTN. The termination could either be on an IP-based client or on the PSTN or a mobile terminal, if forwarded. Of course the same may happen for any normal termination on the PSTN, ported or not, if a GW aka point-of- interconnect (PoI) exists on the Internet, and this PoI is annonced e.g. via ENUM. In the draft-brandner-enumservices-compendium-00.txt the ivoice service is introduced "as an convenient way of indicating that the resource indicated by the associated URI is connected to an IP network ..." The main discussion up to now is, if in addition to User-ENUM a second tree called Infrastructure ENUM is existing, because not all numbers of a given range may exist in user ENUM because of the opt-in principle and the potential problems caused by a clash of responsibilities in the Tier 2. This second tree is also proposed in draft-ietf-enum-e164-gstn-np-05.txt Anyway, I am currently working on an I-D putting together the above mentioned documents, draft-yu-sip-np, draft-yu-tel-url and draft-brandner-tel-svc for a consistent application of ENUM on NP, Freephone and other routing issues. Finally it should be possible to announce the destination (GW, PoI, PSTN route) of ANY phone number in ENUM, to by queried by the origination (user and/or network) directly. HEALTH WARNING: If you are not aware already, this will obsolete carriers and transit networksand allow global number portability for any E.164 number, even for geographic numbers. And I fully agree to the statement below from Alan, that this is the real application for ENUM: a globally available, scaleable, performant IN-Service. regards Richard Stastny -----Ursprüngliche Nachricht----- Von: Richard Shockey [mailto:rich.shockey@NeuStar.com] Gesendet: Do 19.09.2002 19:28 An: Alan Johnston; Michael O'Doherty; 'Tom_Gray@Mitel.COM' Cc: 'sipping@ietf.org'; enum@ietf.org Betreff: [Enum] RE: [Sipping] Associating SIP sessions with PSTN calls At 01:58 PM 9/18/2002 -0500, Alan Johnston wrote: >Michael, > >Tom is right - ENUM is the right solution to this. Here is how it could work: > >If the PSTN number is dialed in the PSTN, it routes as normally and rings >the user's PSTN phone, which is what you want. > >If the PSTN number is dialed in a SIP network which does not query ENUM, >the call will be routed to a PSTN gateway and ring the user's PSTN phone, >which again is a success. > >If the PSTN number is dialed in a SIP network that does query ENUM, it >returns a SIP URI for the endpoint. An INVITE is then sent to the proxy >in the domain of the SIP URI, which presumably is the service provider for >the user. The proxy knows that this user wishes to receive calls on their >PSTN phone (for some reason), so it routes the call to a PSTN gateway and >rings the user's phone. > >Any SIP requests which are for other media sessions or any other purpose >are routed using ENUM to the proxy, which forwards them to the SIP User >Agent, which establishes the associated session you are after (whatever >that is). > >You are right, however, in noting that this sort of use is not described >in any of the ENUM documents - they mainly describe a whole set of >questionable uses for ENUM that simply don't work. I would encourage you >to bring this up on the ENUM list, as this is exactly what ENUM was >designed to do. Yes please .. as your friendly neighborhood ENUM WG -co chair I encourage this. I will cross post the document to my list ASAP. We've been over a lot of this ground already. >Thanks, >Alan Johnston >sip:alan@digitalari.com > > >At 07:16 PM 9/18/2002 +0100, Michael O'Doherty wrote: > >>Tom, >> >>The first option in the draft below looks at ENUM. >> >>The main problem is if the user wants to use their PSTN phone for voice >>calls (even from SIP phones) and their SIP device for other media >>sessions (like PSTN associated sessions). >> >>How do we indicate with an ENUM response that voice calls should go to >>the PSTN number and other media/mixed media calls to a SIP device (one >>suggestion here was that if ENUM returns a tel URL as one of the options >>for routing then that option MUST be used if the call is a voice call) ? >> >>We couldn't see any nice clean way to do this with ENUM as it stands >>today - option 4 in the draft (using a well know domain to do the CLI >>lookup) just seemed to be less messy and more obvious. >> >>Comments ? >> >>Cheers, >> >>Mick. >> >> >>-----Original Message----- >>From: Tom_Gray@Mitel.COM >>[mailto:Tom_Gray@Mitel.COM] >>Sent: 18 September 2002 18:35 >>To: O'Doherty, Michael [MDN05:MD01:EXCH] >>Cc: 'sipping@ietf.org' >>Subject: Re: [Sipping] Associating SIP sessions with PSTN calls >> >> >> >>Why can't the answer to this be ENUM? >> >> >> >> >> >>"Michael O'Doherty" @ietf.org on 09/18/2002 >>11:43:55 AM >> >>Sent by: sipping-admin@ietf.org >> >>To: "'sipping@ietf.org'" >>cc: >>Subject: [Sipping] Associating SIP sessions with PSTN calls >> >> >> >>Hi, >> >>The draft below describes a number of schemes to allow a SIP session be >>associated with a PSTN call, plus the authors choice of the best approach >>from the options briefly described. >> >>We'd be interested to see if anyone has any comments, in particular if >>there are any options we missed. >> >>Additionally, looking at this problem domain threw up a more general >>requirement also: >> >> - the ability to route a SIP request differently depending on the media >>service that the request is requesting >> >>Do people feel this is a valid requirement in a SIP networks and if so has >>anybody any thoughts on how it might be addressed ? >> >>Cheers, >> >>Mick. >> >>The draft can be retrieved form the link below until it shows up in the >>archives: >> >>http://ties.itu.int/~watsonm/draft-odoherty-sipping-pstn-number-association-01.txt >> >> > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Sep 20 04:36:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16330 for ; Fri, 20 Sep 2002 04:36:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8K8cGc16283 for enum-archive@odin.ietf.org; Fri, 20 Sep 2002 04:38:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8K8cEv16278; Fri, 20 Sep 2002 04:38:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8K8TWv15418 for ; Fri, 20 Sep 2002 04:29:32 -0400 Received: from mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16187; Fri, 20 Sep 2002 04:27:33 -0400 (EDT) Subject: AW: [Enum] RE: [Sipping] Associating SIP sessions with PSTN calls Date: Fri, 20 Sep 2002 10:31:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-ID: <06CF906FE3998C4E944213062009F1620247BF@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [Enum] RE: [Sipping] Associating SIP sessions with PSTN calls Thread-Index: AcJgA8gE0roCVaiFRfeuF0Gy9x0CQwAeq3iG From: "Stastny Richard" To: "Richard Shockey" , "Alan Johnston" , "Michael O'Doherty" , "Tom_Gray@Mitel.COM" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id g8K8TXv15420 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Add-on after reading (quick scan) the O'Doherty draft, which is an additional function, having two separate calls in parallel, (funny how new ideas pop up constantly with ENUM). Question: why not use the second call for voice also and drop the first? Anyway, as one likes: thats exactly what the enumservices are for. With enumservices voice and ivoice you MAY give different routings for PSTN and IP. If one has a PSTN call esatblished, he may also use the enumservice video specificly selected for the second call. Also the approach described below from Alan works if one uses srs and let sip negotiate. I do not see any problems with the current set of proposals set out for enumservices. regards Richard -----Ursprüngliche Nachricht----- Von: Richard Shockey [mailto:rich.shockey@NeuStar.com] Gesendet: Do 19.09.2002 19:28 An: Alan Johnston; Michael O'Doherty; 'Tom_Gray@Mitel.COM' Cc: 'sipping@ietf.org'; enum@ietf.org Betreff: [Enum] RE: [Sipping] Associating SIP sessions with PSTN calls At 01:58 PM 9/18/2002 -0500, Alan Johnston wrote: >Michael, > >Tom is right - ENUM is the right solution to this. Here is how it could work: > >If the PSTN number is dialed in the PSTN, it routes as normally and rings >the user's PSTN phone, which is what you want. > >If the PSTN number is dialed in a SIP network which does not query ENUM, >the call will be routed to a PSTN gateway and ring the user's PSTN phone, >which again is a success. > >If the PSTN number is dialed in a SIP network that does query ENUM, it >returns a SIP URI for the endpoint. An INVITE is then sent to the proxy >in the domain of the SIP URI, which presumably is the service provider for >the user. The proxy knows that this user wishes to receive calls on their >PSTN phone (for some reason), so it routes the call to a PSTN gateway and >rings the user's phone. > >Any SIP requests which are for other media sessions or any other purpose >are routed using ENUM to the proxy, which forwards them to the SIP User >Agent, which establishes the associated session you are after (whatever >that is). > >You are right, however, in noting that this sort of use is not described >in any of the ENUM documents - they mainly describe a whole set of >questionable uses for ENUM that simply don't work. I would encourage you >to bring this up on the ENUM list, as this is exactly what ENUM was >designed to do. Yes please .. as your friendly neighborhood ENUM WG -co chair I encourage this. I will cross post the document to my list ASAP. We've been over a lot of this ground already. >Thanks, >Alan Johnston >sip:alan@digitalari.com > > >At 07:16 PM 9/18/2002 +0100, Michael O'Doherty wrote: > >>Tom, >> >>The first option in the draft below looks at ENUM. >> >>The main problem is if the user wants to use their PSTN phone for voice >>calls (even from SIP phones) and their SIP device for other media >>sessions (like PSTN associated sessions). >> >>How do we indicate with an ENUM response that voice calls should go to >>the PSTN number and other media/mixed media calls to a SIP device (one >>suggestion here was that if ENUM returns a tel URL as one of the options >>for routing then that option MUST be used if the call is a voice call) ? >> >>We couldn't see any nice clean way to do this with ENUM as it stands >>today - option 4 in the draft (using a well know domain to do the CLI >>lookup) just seemed to be less messy and more obvious. >> >>Comments ? >> >>Cheers, >> >>Mick. >> >> >>-----Original Message----- >>From: Tom_Gray@Mitel.COM >>[mailto:Tom_Gray@Mitel.COM] >>Sent: 18 September 2002 18:35 >>To: O'Doherty, Michael [MDN05:MD01:EXCH] >>Cc: 'sipping@ietf.org' >>Subject: Re: [Sipping] Associating SIP sessions with PSTN calls >> >> >> >>Why can't the answer to this be ENUM? >> >> >> >> >> >>"Michael O'Doherty" @ietf.org on 09/18/2002 >>11:43:55 AM >> >>Sent by: sipping-admin@ietf.org >> >>To: "'sipping@ietf.org'" >>cc: >>Subject: [Sipping] Associating SIP sessions with PSTN calls >> >> >> >>Hi, >> >>The draft below describes a number of schemes to allow a SIP session be >>associated with a PSTN call, plus the authors choice of the best approach >>from the options briefly described. >> >>We'd be interested to see if anyone has any comments, in particular if >>there are any options we missed. >> >>Additionally, looking at this problem domain threw up a more general >>requirement also: >> >> - the ability to route a SIP request differently depending on the media >>service that the request is requesting >> >>Do people feel this is a valid requirement in a SIP networks and if so has >>anybody any thoughts on how it might be addressed ? >> >>Cheers, >> >>Mick. >> >>The draft can be retrieved form the link below until it shows up in the >>archives: >> >>http://ties.itu.int/~watsonm/draft-odoherty-sipping-pstn-number-association-01.txt >> >> > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Sep 20 08:38:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20236 for ; Fri, 20 Sep 2002 08:38:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8KCeBD27687 for enum-archive@odin.ietf.org; Fri, 20 Sep 2002 08:40:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KCe8v27682; Fri, 20 Sep 2002 08:40:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KAcGv22185 for ; Fri, 20 Sep 2002 06:38:16 -0400 Received: from znsgs01r.europe.nortel.com (h8s128a211n47.user.nortelnetworks.com [47.211.128.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17943; Fri, 20 Sep 2002 06:36:26 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8KAb4s27098; Fri, 20 Sep 2002 11:37:04 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Sep 2002 11:37:04 +0100 Message-ID: From: "Michael O'Doherty" To: "'Stastny Richard'" , "'Richard Shockey'" , "'Alan Johnston'" , "'Tom_Gray@Mitel.COM'" Cc: "'sipping@ietf.org'" , "'enum@ietf.org'" Subject: RE: [Enum] RE: [Sipping] Associating SIP sessions with PSTN calls Date: Fri, 20 Sep 2002 11:37:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26091.A86AE59C" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26091.A86AE59C Content-Type: text/plain; charset="utf-8" All, I am confused here so I want to make sure I am not missing something. At it's simplest the requirement is for a callee to be able to ensure that if someone sets up a SIP call to them using the callee's PSTN phone number as a SIP address (as a FQDN as outlined in ENUM) that the call be routed as follows: - If the call is a voice call the call it should be routed to the users PSTN phone - If the call is a non-voice (or mixed media) call it should be routed to the users SIP device As far as I can see the best way to do this with ENUM is: - the caller uses the ENUM lookup to return the callee's SIP URI as first choice and a tel url as second choice - the call is routed to the callee's SIP device - the SIP device sees it is a voice call and redirects the call to a tel URL with the users PSTN number (or just fails the call and the second choice from the ENUM lookup is used) - the caller uses the tel URL to break out to the PSTN network Is there another/better way to achieve the same thing using ENUM ? Cheers, Mick. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: 20 September 2002 08:44 To: Richard Shockey; Alan Johnston; O'Doherty, Michael [MDN05:MD01:EXCH]; Tom_Gray@Mitel.COM Cc: sipping@ietf.org; enum@ietf.org Subject: AW: [Enum] RE: [Sipping] Associating SIP sessions with PSTN calls Thank you Richard for forwarding this discussion to the ENUM list. As you stated below, the topic has already been discussed (;-) sigh) at the ENUM list. There is also existing my draft-stastny-enum-scenarios-00.txt which beside other issues dealing with this problem. Furthermore I want to point out that exactly the discribed scenario is one of the main topics of our ENUM-trials, especially the VISIONng ENUM-trial dealing with +87810 UPT. In the case of personal numbers the calls are routed as described below on the PSTN in the normal way to a gateway. In addition, a GW (either SIP or H323) exists on the Internet. The ENUM entry contains a pointer to this gateway. Anybody querying ENUM may directly route the call to this gateway and the call is terminating in the same way as if it would come from the PSTN. The termination could either be on an IP-based client or on the PSTN or a mobile terminal, if forwarded. Of course the same may happen for any normal termination on the PSTN, ported or not, if a GW aka point-of- interconnect (PoI) exists on the Internet, and this PoI is annonced e.g. via ENUM. In the draft-brandner-enumservices-compendium-00.txt the ivoice service is introduced "as an convenient way of indicating that the resource indicated by the associated URI is connected to an IP network ..." The main discussion up to now is, if in addition to User-ENUM a second tree called Infrastructure ENUM is existing, because not all numbers of a given range may exist in user ENUM because of the opt-in principle and the potential problems caused by a clash of responsibilities in the Tier 2. This second tree is also proposed in draft-ietf-enum-e164-gstn-np-05.txt Anyway, I am currently working on an I-D putting together the above mentioned documents, draft-yu-sip-np, draft-yu-tel-url and draft-brandner-tel-svc for a consistent application of ENUM on NP, Freephone and other routing issues. Finally it should be possible to announce the destination (GW, PoI, PSTN route) of ANY phone number in ENUM, to by queried by the origination (user and/or network) directly. HEALTH WARNING: If you are not aware already, this will obsolete carriers and transit networksand allow global number portability for any E.164 number, even for geographic numbers. And I fully agree to the statement below from Alan, that this is the real application for ENUM: a globally available, scaleable, performant IN-Service. regards Richard Stastny -----Ursprüngliche Nachricht----- Von: Richard Shockey [mailto:rich.shockey@NeuStar.com] Gesendet: Do 19.09.2002 19:28 An: Alan Johnston; Michael O'Doherty; 'Tom_Gray@Mitel.COM' Cc: 'sipping@ietf.org'; enum@ietf.org Betreff: [Enum] RE: [Sipping] Associating SIP sessions with PSTN calls At 01:58 PM 9/18/2002 -0500, Alan Johnston wrote: >Michael, > >Tom is right - ENUM is the right solution to this. Here is how it could work: > >If the PSTN number is dialed in the PSTN, it routes as normally and rings >the user's PSTN phone, which is what you want. > >If the PSTN number is dialed in a SIP network which does not query ENUM, >the call will be routed to a PSTN gateway and ring the user's PSTN phone, >which again is a success. > >If the PSTN number is dialed in a SIP network that does query ENUM, it >returns a SIP URI for the endpoint. An INVITE is then sent to the proxy >in the domain of the SIP URI, which presumably is the service provider for >the user. The proxy knows that this user wishes to receive calls on their >PSTN phone (for some reason), so it routes the call to a PSTN gateway and >rings the user's phone. > >Any SIP requests which are for other media sessions or any other purpose >are routed using ENUM to the proxy, which forwards them to the SIP User >Agent, which establishes the associated session you are after (whatever >that is). > >You are right, however, in noting that this sort of use is not described >in any of the ENUM documents - they mainly describe a whole set of >questionable uses for ENUM that simply don't work. I would encourage you >to bring this up on the ENUM list, as this is exactly what ENUM was >designed to do. Yes please .. as your friendly neighborhood ENUM WG -co chair I encourage this. I will cross post the document to my list ASAP. We've been over a lot of this ground already. >Thanks, >Alan Johnston >sip:alan@digitalari.com > > >At 07:16 PM 9/18/2002 +0100, Michael O'Doherty wrote: > >>Tom, >> >>The first option in the draft below looks at ENUM. >> >>The main problem is if the user wants to use their PSTN phone for voice >>calls (even from SIP phones) and their SIP device for other media >>sessions (like PSTN associated sessions). >> >>How do we indicate with an ENUM response that voice calls should go to >>the PSTN number and other media/mixed media calls to a SIP device (one >>suggestion here was that if ENUM returns a tel URL as one of the options >>for routing then that option MUST be used if the call is a voice call) ? >> >>We couldn't see any nice clean way to do this with ENUM as it stands >>today - option 4 in the draft (using a well know domain to do the CLI >>lookup) just seemed to be less messy and more obvious. >> >>Comments ? >> >>Cheers, >> >>Mick. >> >> >>-----Original Message----- >>From: Tom_Gray@Mitel.COM >>[mailto:Tom_Gray@Mitel.COM] >>Sent: 18 September 2002 18:35 >>To: O'Doherty, Michael [MDN05:MD01:EXCH] >>Cc: 'sipping@ietf.org' >>Subject: Re: [Sipping] Associating SIP sessions with PSTN calls >> >> >> >>Why can't the answer to this be ENUM? >> >> >> >> >> >>"Michael O'Doherty" @ietf.org on 09/18/2002 >>11:43:55 AM >> >>Sent by: sipping-admin@ietf.org >> >>To: "'sipping@ietf.org'" >>cc: >>Subject: [Sipping] Associating SIP sessions with PSTN calls >> >> >> >>Hi, >> >>The draft below describes a number of schemes to allow a SIP session be >>associated with a PSTN call, plus the authors choice of the best approach >>from the options briefly described. >> >>We'd be interested to see if anyone has any comments, in particular if >>there are any options we missed. >> >>Additionally, looking at this problem domain threw up a more general >>requirement also: >> >> - the ability to route a SIP request differently depending on the media >>service that the request is requesting >> >>Do people feel this is a valid requirement in a SIP networks and if so has >>anybody any thoughts on how it might be addressed ? >> >>Cheers, >> >>Mick. >> >>The draft can be retrieved form the link below until it shows up in the >>archives: >> >>http://ties.itu.int/~watsonm/draft-odoherty-sipping-pstn-number-as sociation-01.txt >> >> > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01C26091.A86AE59C Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [Enum] RE: [Sipping] Associating SIP sessions with PSTN = calls

All,

I am confused here so I want to make sure I am not = missing something.

At it's simplest the requirement is for a callee to = be able to ensure that if someone sets up a  SIP call to them = using the callee's PSTN phone number as a SIP address (as a FQDN as = outlined in ENUM) that the call be routed as follows:

- If the call is a voice call the call it should be = routed to the users PSTN phone

- If the call is a non-voice (or mixed media) call it = should be routed to the users SIP device

As far as I can see the best way to do this with ENUM = is:

- the caller uses the ENUM lookup to return the = callee's SIP URI as first choice and a tel url as second choice
- the call is routed to the callee's SIP = device
- the SIP device sees it is a voice call and = redirects the call to a tel URL with the users PSTN number (or just = fails the call and the second choice from the ENUM lookup is = used)

- the caller uses the tel URL to break out to the = PSTN network

Is there another/better way to achieve the same thing = using ENUM ?

Cheers,

Mick.









-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny@oefeg.at= ]
Sent: 20 September 2002 08:44
To: Richard Shockey; Alan Johnston; O'Doherty, = Michael
[MDN05:MD01:EXCH]; Tom_Gray@Mitel.COM
Cc: sipping@ietf.org; enum@ietf.org
Subject: AW: [Enum] RE: [Sipping] Associating SIP = sessions with PSTN
calls


Thank you Richard for forwarding this discussion to = the ENUM list.
 
As you stated below, the topic has already been = discussed (;-) sigh) at
the ENUM list. There is also existing my = draft-stastny-enum-scenarios-00.txt
which beside other issues dealing with this = problem.
 
Furthermore I want to point out that exactly the = discribed scenario is
one of the main topics of our ENUM-trials, = especially the VISIONng
ENUM-trial dealing with +87810 UPT. In the case of = personal numbers
the calls are routed as described below on the PSTN = in the normal
way to a gateway. In addition, a GW (either SIP or = H323) exists on the
Internet. The ENUM entry contains a pointer to this = gateway. Anybody
querying ENUM may directly route the call to this = gateway and the call
is terminating in the same way as if it would come = from the PSTN. The
termination could either be on an IP-based client or = on the PSTN or a
mobile terminal, if forwarded. Of course the same = may happen for any
normal termination on the PSTN, ported or not, if a = GW aka point-of-
interconnect (PoI) exists on the Internet, and this = PoI is annonced e.g. via
ENUM.
 
In the draft-brandner-enumservices-compendium-00.txt = the ivoice service
is introduced "as an convenient way of = indicating that the resource indicated
by the associated URI is connected to an IP network = ..."
 
The main discussion up to now is, if in addition to = User-ENUM a second
tree called Infrastructure ENUM is existing, because = not all numbers of
a given range may exist in user ENUM because of the = opt-in principle and
the potential problems caused by a clash of = responsibilities in the Tier 2.
This second tree is also proposed in = draft-ietf-enum-e164-gstn-np-05.txt
 
Anyway, I am currently working on an I-D putting = together the above
mentioned documents, draft-yu-sip-np, = draft-yu-tel-url and draft-brandner-tel-svc
for a consistent application of ENUM on NP, = Freephone and other routing issues.
 
Finally it should be possible to announce the = destination (GW, PoI, PSTN route) of
ANY phone number in ENUM, to by queried by the = origination (user and/or network)
directly.
 
HEALTH WARNING: If you are not aware already, this = will obsolete carriers and
transit networksand allow global number portability = for any E.164 number, even for
geographic numbers.
 
And I fully agree to the statement below from Alan, = that this is the real
application for ENUM: a globally available, = scaleable, performant IN-Service.
 
regards
Richard Stastny

        -----Urspr=C3=BCngliche Nachricht-----
        Von: = Richard Shockey [mailto:rich.shockey@NeuStar.com= ]
        Gesendet: = Do 19.09.2002 19:28
        An: Alan = Johnston; Michael O'Doherty; 'Tom_Gray@Mitel.COM'
        Cc: = 'sipping@ietf.org'; enum@ietf.org
        Betreff: = [Enum] RE: [Sipping] Associating SIP sessions with PSTN calls
       =20
       =20

        At 01:58 = PM 9/18/2002 -0500, Alan Johnston wrote:
        >Michael,
        >
        >Tom = is right - ENUM is the right solution to this.  Here is how it = could work:
        >
        >If = the PSTN number is dialed in the PSTN, it routes as normally and = rings
        >the = user's PSTN phone, which is what you want.
        >
        >If = the PSTN number is dialed in a SIP network which does not query = ENUM,
        >the = call will be routed to a PSTN gateway and ring the user's PSTN = phone,
        >which = again is a success.
        >
        >If = the PSTN number is dialed in a SIP network that does query ENUM, = it
        >returns a SIP URI for the endpoint.  An INVITE is = then sent to the proxy
        >in = the domain of the SIP URI, which presumably is the service provider = for
        >the = user.  The proxy knows that this user wishes to receive calls on = their
        >PSTN = phone (for some reason), so it routes the call to a PSTN gateway = and
        >rings = the user's phone.
        >
        >Any = SIP requests which are for other media sessions or any other = purpose
        >are = routed using ENUM to the proxy, which forwards them to the SIP = User
        >Agent, which establishes the associated session you are = after (whatever
        >that = is).
        >
        >You = are right, however, in noting that this sort of use is not = described
        >in = any of the ENUM documents - they mainly describe a whole set of
        >questionable uses for ENUM that simply don't work.  I = would encourage you
        >to = bring this up on the ENUM list, as this is exactly what ENUM was
        >designed to do.
       =20
       =20
        Yes = please  .. as your friendly neighborhood ENUM WG -co chair I = encourage
        this.
       =20
        I will = cross post the document to my list ASAP.
       =20
        We've = been over a lot of this ground already.
       =20
       =20
        >Thanks,
        >Alan = Johnston
        >sip:alan@digitalari.com
        >
        >
        >At = 07:16 PM 9/18/2002 +0100, Michael O'Doherty wrote:
        >
        >>Tom,
        >>
        >>The first option in the draft below looks at = ENUM.
        >>
        >>The main problem is if the user wants to use their = PSTN phone for voice
        >>calls (even from SIP phones) and their SIP device for = other media
        >>sessions (like PSTN associated sessions).
        >>
        >>How do we indicate with an ENUM response that voice = calls should go to
        >>the PSTN number and other media/mixed media calls to a = SIP device (one
        >>suggestion here was that if ENUM returns a tel URL as = one of the options
        >>for routing then that option MUST be used if the call = is a voice call) ?
        >>
        >>We couldn't see any nice clean way to do this with = ENUM as it stands
        >>today - option 4 in the draft (using a well know = domain to do the CLI
        >>lookup) just seemed to be less messy and more = obvious.
        >>
        >>Comments ?
        >>
        >>Cheers,
        >>
        >>Mick.
        >>
        >>
        >>-----Original Message-----
        >>From: Tom_Gray@Mitel.COM
        >>[<mailto:Tom_Gray@Mitel.COM>mailto:Tom_Gray@Mitel.COM]=
        >>Sent: 18 September 2002 18:35
        >>To: O'Doherty, Michael [MDN05:MD01:EXCH]
        >>Cc: 'sipping@ietf.org'
        >>Subject: Re: [Sipping] Associating SIP sessions with = PSTN calls
        >>
        >>
        >>
        >>Why can't the answer to this be ENUM?
        >>
        >>
        >>
        >>
        >>
        >>&q= uot;Michael O'Doherty" = <mdoherty@nortelnetworks.com>@ietf.org on 09/18/2002
        >>11:43:55 AM
        >>
        >>Sent by:  sipping-admin@ietf.org
        >>
        >>To:   "'sipping@ietf.org'" = <sipping@ietf.org>
        >>cc:
        >>Subject:  [Sipping] Associating SIP sessions with = PSTN calls
        >>
        >>
        >>
        >>Hi,
        >>
        >>The draft below describes a number of schemes to allow = a SIP session be
        >>associated with a PSTN call, plus the authors choice = of the best approach
        >>from the options briefly described.
        >>
        >>We'd be interested to see if anyone has any comments, = in particular if
        >>there are any options we missed.
        >>
        >>Additionally, looking at this problem domain threw up = a more general
        >>requirement also:
        >>
        >>  - the ability to route a SIP request = differently depending on the media
        >>service that the request is requesting
        >>
        >>Do people feel this is a valid requirement in a  = SIP networks and if so has
        >>anybody any thoughts on how it might be addressed = ?
        >>
        >>Cheers,
        >>
        >>Mick.
        >>
        >>The draft can be retrieved form the link below until = it shows up in the
        >>archives:
        >>
        >><http://ties.itu.int/~watsonm/draft-odoherty-sipping-ps= tn-number-association-01.txt>http://ties.itu.int/~watsonm/draft-odoherty-sipping-ps= tn-number-association-01.txt

        >>
        >>
        >
        >_______________________________________________
        >Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
        >This = list is for NEW development of the application of SIP
        >Use = sip-implementors@cs.columbia.edu for questions on current sip
        >Use = sip@ietf.org for new developments of core SIP
       =20
       =20
         = >>>>>>>>>>>>>>>>>>= >>>>>>>>>>>>>>>>>>= >>>>>>>>>>>>>>>>>
        Richard = Shockey, Senior Manager, Strategic Technology Initiatives
        NeuStar = Inc.
        46000 = Center Oak Plaza   Bldg 10    Sterling, = VA  20166
        Voice +1 = 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
        <mailto:richard@shockey.us> or = <mailto:rich.shockey@neustar.biz= >
        <http://shockey.us > = ; <http://www.neustar.biz> ; <http://www.enum.org>
        <<<<<<<<<<<<<<<<= ;<<<<<<<<<<<<<<<<<<= ;<<<<<<<<<<<<<<<<<<= ;<
       =20
        _______________________________________________
        enum = mailing list
        enum@ietf.org
        https://www1.ietf.org/mailman/listinfo/enum=
       =20

------_=_NextPart_001_01C26091.A86AE59C-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Sep 20 10:40:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24325 for ; Fri, 20 Sep 2002 10:40:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8KEg8J02503 for enum-archive@odin.ietf.org; Fri, 20 Sep 2002 10:42:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KEg5v02497; Fri, 20 Sep 2002 10:42:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KEe9v02412 for ; Fri, 20 Sep 2002 10:40:09 -0400 Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24244 for ; Fri, 20 Sep 2002 10:38:19 -0400 (EDT) Received: from lawrence.srmr.co.uk ([193.118.205.14] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 8087u via TCP with SMTP; Fri, 20 Sep 2002 15:39:47 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 20 Sep 2002 15:39:47 +0100 To: "Michael O'Doherty" , "'Stastny Richard'" , "'Richard Shockey'" , "'Alan Johnston'" , "'Tom_Gray@Mitel.COM'" From: Lawrence Conroy Subject: RE: [Enum] Associating SIP sessions with PSTN calls Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 11:37 am +0100 20/9/02, Michael O'Doherty wrote: >All, > >I am confused here so I want to make sure I am not missing something. > >At it's simplest the requirement is for a callee to be able to >ensure that if someone sets up a SIP call to them using the >callee's PSTN phone number as a SIP address (as a FQDN as outlined >in ENUM) that the call be routed as follows: > >- If the call is a voice call the call it should be routed to the >users PSTN phone > >- If the call is a non-voice (or mixed media) call it should be >routed to the users SIP device > >As far as I can see the best way to do this with ENUM is: > >- the caller uses the ENUM lookup to return the callee's SIP URI as >first choice and a tel url as second choice >- the call is routed to the callee's SIP device >- the SIP device sees it is a voice call and redirects the call to a >tel URL with the users PSTN number (or just fails the call and the >second choice from the ENUM lookup is used) > >- the caller uses the tel URL to break out to the PSTN network > >Is there another/better way to achieve the same thing using ENUM ? > >Cheers, > >Mick. > Hi Mick, folks, If I understand the above, then "It just works (tm)". I think that the Callee (Registrant) puts the following into ENUM (DNS) space: $ORIGIN 6.6.6.3.3.8.4.9.7.1.4.4.e164.arpa. . NAPTR 10 10 'u' 'E2U+ivoice+video+srs' '!^.*$!sip:4833666@siptest.wcom.com' . . NAPTR 10 10 'u' 'E2U+voice' '!^.*$!tel:+441794833666' . Both of these NAPTRs "fit" - there is no second or first choice here as they both have the same order and preference values. No worries, as ... The Caller (or their agent) does an ENUM lookup. In ENUM queries, the caller registers an interest in some enumservice(s) and this is used by their local ENUM client 'engine' to filter out the NAPTRs that are appropriate. (The caller could pass these "interests" as parameters when running their ENUM client). If the caller is interested in a voice call, then the second of these will match, whilst the first will be less preferable, but will act as a fallback. If the caller is interested in the video call, then the first will match. Likewise, if the caller prefers to make a call using VoIP then they would have registered an interest in ivoice as well. Again, the first one matches. If the caller is happy to leave a "service resolution service" to deal with the negotiations (basically, leave it to SIP), then again the first record will match. Once the record has been chosen, it's up to the caller's client to execute an action based on the generated URI in the record they have selected. In the first one has been selected, then I guess the result is to fire up their trusty SIP UAC. If the second one has been selected, then (for some) the result is firing up their local dialler program (and this will dial out over the PSTN). Thus, where's the problem? all the best, Lawrenece -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Sep 20 10:59:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25022 for ; Fri, 20 Sep 2002 10:59:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8KF0Ll03363 for enum-archive@odin.ietf.org; Fri, 20 Sep 2002 11:00:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KF0Hv03354; Fri, 20 Sep 2002 11:00:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KExBv03273 for ; Fri, 20 Sep 2002 10:59:11 -0400 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24959 for ; Fri, 20 Sep 2002 10:57:20 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g8KEwTG27370; Fri, 20 Sep 2002 14:58:29 GMT Message-Id: <5.1.0.14.2.20020920105914.044cbf20@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 20 Sep 2002 11:01:36 -0400 To: Lawrence Conroy , "Michael O'Doherty" , "'Stastny Richard'" , "'Richard Shockey'" , "'Alan Johnston'" , "'Tom_Gray@Mitel.COM'" From: Richard Shockey Subject: RE: [Enum] Associating SIP sessions with PSTN calls Cc: enum@ietf.org In-Reply-To: References: < Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At >I think that the Callee (Registrant) puts the following into ENUM (DNS) space: > >$ORIGIN 6.6.6.3.3.8.4.9.7.1.4.4.e164.arpa. >. NAPTR 10 10 'u' 'E2U+ivoice+video+srs' >'!^.*$!sip:4833666@siptest.wcom.com' . or just NAPTR 10 10 'u' 'E2U+sip' '!^.*$!sip:4833666@siptest.wcom.com' . Larry you knew I was going to point this out. :-) >. NAPTR 10 10 'u' 'E2U+voice' '!^.*$!tel:+441794833666' . > >Both of these NAPTRs "fit" - there is no second or first choice here as >they both have the same order and preference values. No worries, as ... > >T >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Sep 20 13:09:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00041 for ; Fri, 20 Sep 2002 13:09:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8KHAhn11540 for enum-archive@odin.ietf.org; Fri, 20 Sep 2002 13:10:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KHAYv11531; Fri, 20 Sep 2002 13:10:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KH9nv11452 for ; Fri, 20 Sep 2002 13:09:49 -0400 Received: from znsgs01r.europe.nortel.com (h16s128a211n47.user.nortelnetworks.com [47.211.128.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29967 for ; Fri, 20 Sep 2002 13:07:51 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8KH8Ns24366; Fri, 20 Sep 2002 18:08:25 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Sep 2002 18:08:23 +0100 Message-ID: From: "Michael O'Doherty" To: "'Lawrence Conroy'" , "'Stastny Richard'" , "'Richard Shockey'" , "'Alan Johnston'" , "'Tom_Gray@Mitel.COM'" Cc: "'enum@ietf.org'" , "Mark Ashworth" , "Mark Watson" Subject: RE: [Enum] Associating SIP sessions with PSTN calls Date: Fri, 20 Sep 2002 18:08:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C260C8.52F9C8E4" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C260C8.52F9C8E4 Content-Type: text/plain; charset="iso-8859-1" Lawrence, All, Firstly a comment - in trying to understand this answer I was lucky enough to stumble across the ENUM service analysis draft which explained a lot of the thinking - it would be a big help if this was on the ENUN Charter site ! A couple of questions (if any of the questions don't make sense, you can take it that I am a bit confused at this stage !): The reason the second record below results in the caller firing up their local dialer program (rather than doing another ENUM lookup) is because of the comment in the ENUM RFC saying that the client is responsible for loop detection - is this right or it there some more explicit reason ? Using the 'E2U' parameter in the service field to indicate that this record belongs to the ENUM system, does not match the definition of this field in the NAPTR RFC and is quite confusing - should this field not simply list services available down this rewrite path and optionally the protocol that is used to speak to the services ? The NAPTR RFC refers to 'protocols' and 'rs' in the service field - the service analysis draft seem to refer to URI schemes. Are we assuming that 'protocol' in the former mapps to 'URI scheme in the latter ? I think I understood that the definition of the services (or 'rs' fields) is to be done on a per protocol basis, plus some general ones constructed by using the scheme URI and a general service type - if so is this not tying the service to a particular protocol ? The example below seems to do the opposite (i.e. not tie the service to a protocol) with the use of 'voice' and 'ivoice' services ? If the URI scheme is to be used as the start of the service name, would it be a good idea to have some sort of delimiter before the rest of the service name - I think this would make it a lot clearer. What does the term 'enumservices' mean - these services are not really enumservices, they are services which happen to be reached using an ENUM lookup, or am I not understanding this correctly ? I'll stop there as other questions I have my be addressed by the answers to the above (plus it is late here ...). Cheers, Mick. -----Original Message----- From: Lawrence Conroy [mailto:lwc@roke.co.uk] Sent: 20 September 2002 15:40 To: O'Doherty, Michael [MDN05:MD01:EXCH]; 'Stastny Richard'; 'Richard Shockey'; 'Alan Johnston'; 'Tom_Gray@Mitel.COM' Cc: enum@ietf.org Subject: RE: [Enum] Associating SIP sessions with PSTN calls At 11:37 am +0100 20/9/02, Michael O'Doherty wrote: >All, > >I am confused here so I want to make sure I am not missing something. > >At it's simplest the requirement is for a callee to be able to >ensure that if someone sets up a SIP call to them using the >callee's PSTN phone number as a SIP address (as a FQDN as outlined >in ENUM) that the call be routed as follows: > >- If the call is a voice call the call it should be routed to the >users PSTN phone > >- If the call is a non-voice (or mixed media) call it should be >routed to the users SIP device > >As far as I can see the best way to do this with ENUM is: > >- the caller uses the ENUM lookup to return the callee's SIP URI as >first choice and a tel url as second choice >- the call is routed to the callee's SIP device >- the SIP device sees it is a voice call and redirects the call to a >tel URL with the users PSTN number (or just fails the call and the >second choice from the ENUM lookup is used) > >- the caller uses the tel URL to break out to the PSTN network > >Is there another/better way to achieve the same thing using ENUM ? > >Cheers, > >Mick. > Hi Mick, folks, If I understand the above, then "It just works (tm)". I think that the Callee (Registrant) puts the following into ENUM (DNS) space: $ORIGIN 6.6.6.3.3.8.4.9.7.1.4.4.e164.arpa. . NAPTR 10 10 'u' 'E2U+ivoice+video+srs' '!^.*$!sip:4833666@siptest.wcom.com' . . NAPTR 10 10 'u' 'E2U+voice' '!^.*$!tel:+441794833666' . Both of these NAPTRs "fit" - there is no second or first choice here as they both have the same order and preference values. No worries, as ... The Caller (or their agent) does an ENUM lookup. In ENUM queries, the caller registers an interest in some enumservice(s) and this is used by their local ENUM client 'engine' to filter out the NAPTRs that are appropriate. (The caller could pass these "interests" as parameters when running their ENUM client). If the caller is interested in a voice call, then the second of these will match, whilst the first will be less preferable, but will act as a fallback. If the caller is interested in the video call, then the first will match. Likewise, if the caller prefers to make a call using VoIP then they would have registered an interest in ivoice as well. Again, the first one matches. If the caller is happy to leave a "service resolution service" to deal with the negotiations (basically, leave it to SIP), then again the first record will match. Once the record has been chosen, it's up to the caller's client to execute an action based on the generated URI in the record they have selected. In the first one has been selected, then I guess the result is to fire up their trusty SIP UAC. If the second one has been selected, then (for some) the result is firing up their local dialler program (and this will dial out over the PSTN). Thus, where's the problem? all the best, Lawrenece -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. ------_=_NextPart_001_01C260C8.52F9C8E4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Enum] Associating SIP sessions with PSTN calls

Lawrence, All,

Firstly a comment - in trying to understand this = answer I was lucky enough to stumble across the ENUM service analysis = draft which explained a lot of the thinking - it would be a big help if = this was on the ENUN Charter site !

A couple of questions (if any of the questions don't = make sense, you can take it that I am a bit confused at this stage = !):

The reason the second record below results in the = caller firing up their local dialer program (rather than doing another = ENUM lookup) is because of the comment in the ENUM RFC saying that the = client is responsible for loop detection - is this right or it there = some more explicit reason ?

Using the 'E2U' parameter in the service field to = indicate that this record belongs to the ENUM system, does not match = the definition of this field in the NAPTR RFC and is quite confusing - = should this field not simply list services available down this rewrite = path and optionally the protocol that is used to speak to the services = ?

The NAPTR RFC refers to 'protocols' and 'rs' in the = service field - the service analysis draft seem to refer to URI = schemes. Are we assuming that 'protocol' in the former mapps to 'URI = scheme in the latter ?

I think I understood that the definition of the = services (or 'rs' fields) is to be done on a per protocol basis, plus = some general ones constructed by using the scheme URI and a general = service type - if so is this not tying the service to a particular = protocol ? The example below seems to do the opposite (i.e. not tie the = service to a protocol) with the use of 'voice' and 'ivoice' services = ?

If the URI scheme is to be used as the start of the = service name, would it be a good idea to have some sort of delimiter = before the rest of the service name - I think this would make it a lot = clearer.

What does the term 'enumservices' mean - these = services are not really enumservices, they are services which happen to = be reached using an ENUM lookup, or am I not understanding this = correctly ?

I'll stop there as other questions I have my be = addressed by the answers to the above (plus it is late here = ...).

Cheers,

Mick.


-----Original Message-----
From: Lawrence Conroy [mailto:lwc@roke.co.uk]
Sent: 20 September 2002 15:40
To: O'Doherty, Michael [MDN05:MD01:EXCH]; 'Stastny = Richard'; 'Richard
Shockey'; 'Alan Johnston'; = 'Tom_Gray@Mitel.COM'
Cc: enum@ietf.org
Subject: RE: [Enum] Associating SIP sessions with = PSTN calls


At 11:37 am +0100 20/9/02, Michael O'Doherty = wrote:
>All,
>
>I am confused here so I want to make sure I am = not missing something.
>
>At it's simplest the requirement is for a callee = to be able to
>ensure that if someone sets up a  SIP call = to them using the
>callee's PSTN phone number as a SIP address (as = a FQDN as outlined
>in ENUM) that the call be routed as = follows:
>
>- If the call is a voice call the call it should = be routed to the
>users PSTN phone
>
>- If the call is a non-voice (or mixed media) = call it should be
>routed to the users SIP device
>
>As far as I can see the best way to do this with = ENUM is:
>
>- the caller uses the ENUM lookup to return the = callee's SIP URI as
>first choice and a tel url as second = choice
>- the call is routed to the callee's SIP = device
>- the SIP device sees it is a voice call and = redirects the call to a
>tel URL with the users PSTN number (or just = fails the call and the
>second choice from the ENUM lookup is = used)
>
>- the caller uses the tel URL to break out to = the PSTN network
>
>Is there another/better way to achieve the same = thing using ENUM ?
>
>Cheers,
>
>Mick.
>

Hi Mick, folks,
   If I understand the above, then = "It just works (tm)".

I think that the Callee (Registrant) puts the = following into ENUM (DNS) space:

$ORIGIN 6.6.6.3.3.8.4.9.7.1.4.4.e164.arpa.
.  NAPTR 10 10 'u' 'E2U+ivoice+video+srs' =
'!^.*$!sip:4833666@siptest.wcom.com'  .
.  NAPTR 10 10 'u' 'E2U+voice' = '!^.*$!tel:+441794833666'  .

Both of these NAPTRs "fit" - there is no = second or first choice here as
they both have the same order and preference values. = No worries, as ...

The Caller (or their agent) does an ENUM = lookup.
In ENUM queries, the caller registers an interest in = some enumservice(s)
and this is used by their local ENUM client 'engine' = to filter out the
NAPTRs that are appropriate. (The caller could pass = these "interests"
as parameters when running their ENUM = client).

If the caller is interested in a voice call, then the = second of these will
match, whilst the first will be less preferable, but = will act as a fallback.

If the caller is interested in the video call, then = the first will match.

Likewise, if the caller prefers to make a call using = VoIP then they would
have registered an interest in ivoice as well. = Again, the first one matches.

If the caller is happy to leave a "service = resolution service" to deal
with the negotiations (basically, leave it to SIP), = then again the first
record will match.

Once the record has been chosen, it's up to the = caller's client to execute
an action based on the generated URI in the record = they have selected.

In the first one has been selected, then I guess the = result is to fire
up their trusty SIP UAC.

If the second one has been selected, then (for some) = the result is firing
up their local dialler program (and this will dial = out over the PSTN).

Thus, where's the problem?

all the best,
    Lawrenece
--
---------------------------------------------------------------= --------
Roke Manor Research    : This = information is provided "as is" and is not
<mailto:lwc@roke.co.uk>: intended = to create any contractual or legal
<tel:+441794833666>    : = relationship.

------_=_NextPart_001_01C260C8.52F9C8E4-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sat Sep 21 06:18:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08490 for ; Sat, 21 Sep 2002 06:18:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8LAJxm00686 for enum-archive@odin.ietf.org; Sat, 21 Sep 2002 06:19:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8LAJnv00680; Sat, 21 Sep 2002 06:19:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8LAH3v00639 for ; Sat, 21 Sep 2002 06:17:03 -0400 Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08440 for ; Sat, 21 Sep 2002 06:15:13 -0400 (EDT) Received: from lawrence.srmr.co.uk ([193.118.205.14] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 8213u via TCP with SMTP; Sat, 21 Sep 2002 11:16:37 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: References: Date: Sat, 21 Sep 2002 11:15:39 +0100 To: "Michael O'Doherty" , "'Stastny Richard'" , "'Richard Shockey'" , "'Alan Johnston'" , "'Tom_Gray@Mitel.COM'" From: Lawrence Conroy Subject: RE: [Enum] Associating SIP sessions with PSTN calls Cc: "'enum@ietf.org'" , Mark Ashworth , Mark Watson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Mick, folks, Yup - I can understand the confusion (you'll fit right in to this group :). ---- For examples of potential enumservices, Rudi Brandner has produced a draft that gives descriptions for SOME of these: This obsoletes/subsumes the earlier "categorical enumservices" draft. There's also a draft describing an ifax service: These matches the latest update to the ENUM RFC: . I'm promised that there will be an updated 'sip' enumservice draft out real soon now, and some VPIM-style enumservices. ---- Good question as to why these and others are not linked from the charter page. Our esteemed co-chairs can clarify, but I think that, strictly, the charter focuses on the "framework" rather than the specific enumservice definitions. Thus 2916bis must be there, but the sip enumservice document isn't; nor is the enumservice-compendium (nor draft-stastny-enum-scenarios-00.txt?). ---- The compendium draft is intended to fit with the syntax of rfc2916bis-01, as does the faxservice draft. As the service field syntax has changed somewhat from the original RFC2916, it makes the older drafts obsolete :-\ Notably, Rudi's 'tel' enumservice draft no longer fits with ENUM syntax (nor does the sip enumservice draft, I think). Most other drafts are suspect as well - hey ho - that's the price of progress. ---- As highlighted in rfc2916bis-01, the 'protocol' sub-field need not define the IP protocol to be used with the URI. Nor does it merely duplicate the URI scheme. The service field of a NAPTR describes the services with which this record may be used. Thus, your guess that an enumservice is actually a service that can be realised using the NAPTR retrieved using an ENUM look up is spot on. To paraphrase Humpty Dumpty, "a service means what I want it to mean". See 2.4.2.1 of RFC2916bis-01 for the official word. Each enumservice definition document should have a description of the kind of behaviour and expected result from executing the 'service', so you need to look there. (See section 3 of rfc2916bis for details of what these drafts should define). The definition also includes the URI schemes with which this enumservice is associated, and what is expected to happen when a particular URI scheme is encountered with a given enumservice. Note that this is "harris about apex" relative to the "choose URI scheme, then choose service" that you guessed might be happening. With ENUM, one looks at the service field to see if the NAPTR is interesting, and THEN looks at the processed URI to execute the service - now, you could process all of the NAPTRs, look at each of their generated URI schemes, and then look at the NAPTR service fields, but this is NOT the expected way that a client would operate. ---- Looping is a whole different issue, so I'll defer this to another posting. Hope this helps. all the best, Lawrence At 6:08 pm +0100 20/9/02, Michael O'Doherty wrote: >Lawrence, All, > >Firstly a comment - in trying to understand this answer I was lucky >enough to stumble across the ENUM service analysis draft which >explained a lot of the thinking - it would be a big help if this was >on the ENUN Charter site ! > >A couple of questions (if any of the questions don't make sense, you >can take it that I am a bit confused at this stage !): > >The reason the second record below results in the caller firing up >their local dialer program (rather than doing another ENUM lookup) >is because of the comment in the ENUM RFC saying that the client is >responsible for loop detection - is this right or it there some more >explicit reason ? > >Using the 'E2U' parameter in the service field to indicate that this >record belongs to the ENUM system, does not match the definition of >this field in the NAPTR RFC and is quite confusing - should this >field not simply list services available down this rewrite path and >optionally the protocol that is used to speak to the services ? > >The NAPTR RFC refers to 'protocols' and 'rs' in the service field - >the service analysis draft seem to refer to URI schemes. Are we >assuming that 'protocol' in the former mapps to 'URI scheme in the >latter ? > >I think I understood that the definition of the services (or 'rs' >fields) is to be done on a per protocol basis, plus some general >ones constructed by using the scheme URI and a general service type >- if so is this not tying the service to a particular protocol ? The >example below seems to do the opposite (i.e. not tie the service to >a protocol) with the use of 'voice' and 'ivoice' services ? > >If the URI scheme is to be used as the start of the service name, >would it be a good idea to have some sort of delimiter before the >rest of the service name - I think this would make it a lot clearer. > >What does the term 'enumservices' mean - these services are not >really enumservices, they are services which happen to be reached >using an ENUM lookup, or am I not understanding this correctly ? > >I'll stop there as other questions I have my be addressed by the >answers to the above (plus it is late here ...). (6PM isn't late :). >Cheers, > >Mick. > In response to my post: >I think that the Callee (Registrant) puts the following into ENUM (DNS) space: > >$ORIGIN 6.6.6.3.3.8.4.9.7.1.4.4.e164.arpa. >. NAPTR 10 10 'u' 'E2U+ivoice+video+srs' >'!^.*$!sip:4833666@siptest.wcom.com' . >. NAPTR 10 10 'u' 'E2U+voice' '!^.*$!tel:+441794833666' . > (to which our esteemed co-chair Rich Schockey pointed out that one could use the following in place of the first: . NAPTR 10 10 'u' E2U+sip' '!^.*$!sip:4833666@siptest.wcom.com' . ) -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 30 11:28:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07977 for ; Mon, 30 Sep 2002 11:28:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8UFU2q12547 for enum-archive@odin.ietf.org; Mon, 30 Sep 2002 11:30:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8UFTgv12525; Mon, 30 Sep 2002 11:29:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8UFRov12438 for ; Mon, 30 Sep 2002 11:27:50 -0400 Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07793 for ; Mon, 30 Sep 2002 11:25:51 -0400 (EDT) Received: from percy.roke.co.uk ([193.118.205.14] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 9028u via TCP with SMTP; Mon, 30 Sep 2002 16:27:30 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Mon, 30 Sep 2002 16:27:26 +0100 To: michael@neonym.net, richard.stastny@oefeg.at From: Lawrence Conroy Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Relief Area Codes and REGEXP Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Learned Author, folks, Picking up on the non-terminal question... I understand from the D3S DNS Database draft that the REGEXP is applied to the AUS. I understand from RFC2916bis that, in the ENUM case, the AUS is an E164 number with the initial '+' character. I understand from the D3S DNS Database draft that this remains through a non-terminal sequence - each subsequent NAPTR will apply its REGEXP to this initial value. I understand from the previous mails that the output of non-terminal NAPTR REGEXP processing will be a domain name. However... If the intention is to continue a query within the golden tree then I don't know how to define the REGEXP code so that it works with variable length numbers. This should NOT be dismissed as a requirement. Relief Area Codes may be introduced and, in this case, there will be some period during which both the "old" and the "new" numbers are valid. Both of these sets of numbers will be within the golden tree and so we need to map from an AUS holding the "old" number into an ENUM domain name. So...how do I convert an AUS (E164 number) into an ENUM domain name? If this can't be done using REGEXP, then we will need to find alternatives. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 30 11:45:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08842 for ; Mon, 30 Sep 2002 11:45:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8UFl9V13960 for enum-archive@odin.ietf.org; Mon, 30 Sep 2002 11:47:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8UFl8v13955; Mon, 30 Sep 2002 11:47:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8UFkGv13909 for ; Mon, 30 Sep 2002 11:46:16 -0400 Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08746 for ; Mon, 30 Sep 2002 11:44:17 -0400 (EDT) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 9087E137F0A; Mon, 30 Sep 2002 08:45:42 -0700 (PDT) To: Lawrence Conroy Cc: michael@neonym.net, richard.stastny@oefeg.at, enum@ietf.org Subject: Re: [Enum] Relief Area Codes and REGEXP In-Reply-To: Message from Lawrence Conroy of "Mon, 30 Sep 2002 16:27:26 BST." Date: Mon, 30 Sep 2002 08:45:42 -0700 Message-ID: <78864.1033400742@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Lawrence" == Lawrence Conroy writes: Lawrence> Relief Area Codes may be introduced and, in this case, Lawrence> there will be some period during which both the "old" Lawrence> and the "new" numbers are valid. Both of these sets of Lawrence> numbers will be within the golden tree and so we need to Lawrence> map from an AUS holding the "old" number into an ENUM Lawrence> domain name. Lawrence> So...how do I convert an AUS (E164 number) into an ENUM Lawrence> domain name? Won't DNAME -- RFC2672: Non-Terminal DNS Name Redirection -- solve this problem? I can't recall if DNAME got shunted to Experimental Status along with A6 records. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 30 12:13:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10299 for ; Mon, 30 Sep 2002 12:13:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8UGETk15880 for enum-archive@odin.ietf.org; Mon, 30 Sep 2002 12:14:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8UGESv15875; Mon, 30 Sep 2002 12:14:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8UGAiv15639 for ; Mon, 30 Sep 2002 12:10:44 -0400 Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09979 for ; Mon, 30 Sep 2002 12:08:44 -0400 (EDT) Received: from [128.177.194.136] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id E1088137F05; Mon, 30 Sep 2002 09:10:09 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 30 Sep 2002 09:11:30 -0700 Subject: Re: [Enum] Relief Area Codes and REGEXP From: David Conrad To: Jim Reid , Lawrence Conroy Cc: , , enum wg Message-ID: In-Reply-To: <78864.1033400742@shell.nominum.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 9/30/02 8:45 AM, "Jim Reid" wrote: > Won't DNAME -- RFC2672: Non-Terminal DNS Name Redirection -- solve > this problem? I can't recall if DNAME got shunted to Experimental > Status along with A6 records. No, it didn't. The use of DNAME with bitstring labels did (since bitstring labels got the axe). Rgds, -drc _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 30 12:15:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10429 for ; Mon, 30 Sep 2002 12:15:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8UGH3b16019 for enum-archive@odin.ietf.org; Mon, 30 Sep 2002 12:17:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8UGH3v16014; Mon, 30 Sep 2002 12:17:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8UGG2v15983 for ; Mon, 30 Sep 2002 12:16:02 -0400 Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10350 for ; Mon, 30 Sep 2002 12:14:02 -0400 (EDT) Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g8UDuMUK024413 for ; Mon, 30 Sep 2002 12:15:28 -0400 (EDT) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (6.5.019) id 3D8B5605002F6184; Mon, 30 Sep 2002 12:15:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Enum] Relief Area Codes and REGEXP Date: Mon, 30 Sep 2002 12:15:26 -0400 Message-ID: <62DA45D4963FA747BA1B253E266760F903F7B270@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Enum] Relief Area Codes and REGEXP Thread-Index: AcJomQI7foNBayLSTUGoF9Gv/WNN/wAAwMFw From: "Pfautz, Penn L, ALVAP" To: "Jim Reid" , "Lawrence Conroy" Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g8UGG2v15984 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Some may think it ugly but the US ENUM Forum is planning to handle permissive dialing during code relief by having two records for each number in the Tier 1 and, at Tier 2 either duplicate NAPTR records with old and new numbers or use of CNAME. Penn Pfautz -----Original Message----- From: Jim Reid [mailto:Jim.Reid@nominum.com] Sent: Monday, September 30, 2002 11:46 AM To: Lawrence Conroy Cc: michael@neonym.net; richard.stastny@oefeg.at; enum@ietf.org Subject: Re: [Enum] Relief Area Codes and REGEXP >>>>> "Lawrence" == Lawrence Conroy writes: Lawrence> Relief Area Codes may be introduced and, in this case, Lawrence> there will be some period during which both the "old" Lawrence> and the "new" numbers are valid. Both of these sets of Lawrence> numbers will be within the golden tree and so we need to Lawrence> map from an AUS holding the "old" number into an ENUM Lawrence> domain name. Lawrence> So...how do I convert an AUS (E164 number) into an ENUM Lawrence> domain name? Won't DNAME -- RFC2672: Non-Terminal DNS Name Redirection -- solve this problem? I can't recall if DNAME got shunted to Experimental Status along with A6 records. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Sep 30 12:58:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12517 for ; Mon, 30 Sep 2002 12:58:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8UGxeQ08803 for enum-archive@odin.ietf.org; Mon, 30 Sep 2002 12:59:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8UGxbv08796; Mon, 30 Sep 2002 12:59:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8UGwNv08751 for ; Mon, 30 Sep 2002 12:58:23 -0400 Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12460 for ; Mon, 30 Sep 2002 12:56:22 -0400 (EDT) Received: from percy.roke.co.uk ([193.118.205.14] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 9096u via TCP with SMTP; Mon, 30 Sep 2002 17:58:07 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <62DA45D4963FA747BA1B253E266760F903F7B270@OCCLUST04EVS1.ugd.att.com> References: <62DA45D4963FA747BA1B253E266760F903F7B270@OCCLUST04EVS1.ugd.att.com> Date: Mon, 30 Sep 2002 17:58:00 +0100 To: "Pfautz, Penn L, ALVAP" , Jim Reid From: Lawrence Conroy Subject: RE: [Enum] Relief Area Codes and REGEXP Cc: michael@neonym.net, richard.stastny@oefeg.at, enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Jim originally wrote in answer to my query on Relief Area Code support::- >Won't DNAME -- RFC2672: Non-Terminal DNS Name Redirection -- solve >this problem? I can't recall if DNAME got shunted to Experimental >Status along with A6 records. Then, at 12:15 pm -0400 30/9/02, Penn Pfautz wrote: >Some may think it ugly but the US ENUM Forum is planning to handle >permissive dialing during code relief by having two records for each >number in the Tier 1 and, at Tier 2 either duplicate NAPTR records >with old and new numbers or use of CNAME. > >Penn Pfautz to which I reply: Hi Folks, ...whilst some may think that VERY ugly :). Yes, it CAN be done by duplicate T1 entries pointing to common T2 entries, but that's a lot of data population to be done (and maintained). It's also a challenge if the ENUM registrant wants to change their T2 provider. In answer to Jim's question, yes, DNAME should work fine, IMHO. It avoids the issues with NAPTRs (like "how do you reverse an arbitrary set of digits in a REGEXP"?) whilst allowing a single RR. Question - does DNAME have an implication on use of DNSSEC? all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum