From mailman-owner@ietf.org Wed Nov 1 05:15:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17557 for ; Wed, 1 Nov 2000 05:15:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02070 for ; Wed, 1 Nov 2000 05:15:48 -0500 (EST) Date: Wed, 1 Nov 2000 05:15:48 -0500 (EST) Message-Id: <200011011015.FAA02070@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: enum-web-archive@ns.ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, enum-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for enum-web-archive@www.ietf.org: List Password // URL ---- -------- enum@ietf.org i7hy http://www1.ietf.org/mailman/options/enum/enum-web-archive@www.ietf.org From enum-admin@ietf.org Thu Nov 2 00:05:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20029 for ; Thu, 2 Nov 2000 00:05:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24359; Thu, 2 Nov 2000 00:02:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24329 for ; Thu, 2 Nov 2000 00:02:11 -0500 (EST) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19266 for ; Thu, 2 Nov 2000 00:02:09 -0500 (EST) Received: from computer.ix.netcom.com (user-2ivek8i.dialup.mindspring.com [165.247.81.18]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id AAA21303; Thu, 2 Nov 2000 00:02:04 -0500 (EST) Message-Id: <5.0.0.25.2.20001101233724.0269ea80@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 01 Nov 2000 23:47:04 -0500 To: "Robert H. Walter" , From: Richard Shockey Subject: Re: [Enum] Standard DNS Delegation or CNAME/DNAME Redirection Cc: "Vaudreuil, Greg M \(Greg\)" , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Randy Bush" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 12:56 PM 10/31/2000 -0500, Robert H. Walter wrote: >Greg, Ann, > >Please clarify why you believe CNAME and DNAME resource records >are required to redirect the DNS query from the designated >authority to the service registrar? Why re-issue, reform the >query when standard DNS delegation will suffice? Consider the >following scenarios that assume the designated authority for >1.e164.arpa has provisioned the fully specified E.164 domain >name 2.1.2.1.5.5.5.0.0.8.1.e164.arpa on behalf of the service >registrar ACME: This is a serious issue this list needs to come to consensus on ASAP. The terms of RFC 2916 have been implemented in a IMHO historic agreement between the IAB and the ITU and it is fair to assume that there needs to be and will be operational testing in the e164.arpa name space shortly. We have an obligation to continue to move forward and communicate our work to SG2/Q1 as necessary. We must assist Greg and Anne on the Operational document NOW. Those who believe CNAME or DNAME or other delegation RR are appropriate need to speak up in advance of potential implementers. What are the advantages of each approach? What are the risks? Is there a single optimal solution.. these issues need to be aired out here .. Is a MIB necessary? _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 2 06:49:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20514 for ; Thu, 2 Nov 2000 06:48:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04898; Thu, 2 Nov 2000 06:47:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04867 for ; Thu, 2 Nov 2000 06:47:26 -0500 (EST) Received: from exchange.chaos.com ([206.5.17.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20088 for ; Thu, 2 Nov 2000 06:47:25 -0500 (EST) Received: from [206.5.17.2] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id clriaaaa for enum@ietf.org; Thu, 2 Nov 2000 06:47:24 -0500 Message-Id: <5.0.1.3.2.20001102063645.00a88dc0@mail.netmagic.com> X-Sender: amr@mail.netmagic.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1.3 (Beta) Date: Thu, 02 Nov 2000 06:46:56 -0500 To: Richard Shockey , "Robert H. Walter" , From: "A.M.Rutkowski" Subject: Re: [Enum] Standard DNS Delegation or CNAME/DNAME Redirection Cc: "Vaudreuil, Greg M \(Greg\)" , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Randy Bush" In-Reply-To: <5.0.0.25.2.20001101233724.0269ea80@127.0.0.1> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Richard, >This is a serious issue this list needs to come to consensus on ASAP. The >terms of RFC 2916 have been implemented in a IMHO historic agreement >between the IAB and the ITU and it is fair to assume that there needs to >be and will be operational testing in the e164.arpa name space shortly. In light of the approval necessary by national authorities under the agreement, might not operational testing in non e164.arpa space occur more quickly? Does it make any difference at this point? >We have an obligation to continue to move forward and communicate our work >to SG2/Q1 as necessary. > >We must assist Greg and Anne on the Operational document NOW. An important related issue is the one you raised in Berlin, namely the importance of a Level 1 Registry-Registrar interface, which would also dispose of C interface in the Pfaust-Yu ID. How do you want to proceed? --tony _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 2 09:53:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11050 for ; Thu, 2 Nov 2000 09:53:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07171; Thu, 2 Nov 2000 09:52:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07140 for ; Thu, 2 Nov 2000 09:52:27 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10690 for ; Thu, 2 Nov 2000 09:52:26 -0500 (EST) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA18458 for ; Thu, 2 Nov 2000 09:52:27 -0500 (EST) Received: from mx0003exch001p.wins.lucent.com (h135-107-128-31.lucent.com [135.107.128.31]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA18435 for ; Thu, 2 Nov 2000 09:52:26 -0500 (EST) Received: by MX0003EXCH001P with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Nov 2000 08:52:26 -0600 Message-ID: <808BCB95E77CD21188DB00805F6F99C70587627A@txdj00exch005u.micro.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: "Robert H. Walter" , enum@ietf.org Cc: Patrik Faltstrom , Randy Bush Date: Thu, 2 Nov 2000 08:52:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] RE: Standard DNS Delegation or CNAME/DNAME Redirection Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org The key is your statement "Why re-issue, reform the query when standard DNS delegation will suffice". Where it is sufficient, it clearly preferable to use NS records to delegate authority. For the simple examples you have provided, the NS records are clearly sufficient and return more quickly. In a previous response, I have described a number of topologies where NS records are not sufficient to represent existing numbering plan topologies. Unless we decide otherwise, Dname / CNAME are useful and standard DNS facilities. As such they are part of the toolbox of an ENUM system administrator, must be supported by clients, and whose negative interactions with NAPTR must be well understood. Greg V. -----Original Message----- From: Robert H. Walter [mailto:rwalter@netnumber.com] Sent: Tuesday, October 31, 2000 11:57 AM To: enum@ietf.org Cc: Vaudreuil, Greg M (Greg); Patrik Faltstrom; Randy Bush Subject: Standard DNS Delegation or CNAME/DNAME Redirection Greg, Ann, Please clarify why you believe CNAME and DNAME resource records are required to redirect the DNS query from the designated authority to the service registrar? Why re-issue, reform the query when standard DNS delegation will suffice? Consider the following scenarios that assume the designated authority for 1.e164.arpa has provisioned the fully specified E.164 domain name 2.1.2.1.5.5.5.0.0.8.1.e164.arpa on behalf of the service registrar ACME: Scenario 1: Use NS and A glue records to delegate authority for the fully specified E.164 domain name to the registered name server. This approach has the advantage of not requiring client resolvers and/or foreign name servers to additionally query for the A records associated with the defined name servers. Using glue records has the additional restriction that the delegated name servers MUST be children of the 1.e164.arpa sub-domain, but results in reduced resolution time because there are fewer queries and network traversals required. Notice the extended domain names for acmes name servers. 2.1.2.1.5.5.5.0.0.8.1.e164.arpa. IN NS ns1.acme.1.e164.arpa. IN NS ns2.acme.1.e164.arpa. ns1.acme.1.e164.arpa. IN A 192.249.249.1 ns2.acme.1.e164.arpa. IN A 192.249.249.2 Scenario 2: Use only NS records to delegate authority for the fully specified E.164 domain name to the registered name server. This approach has the disadvantage of requiring client resolvers and/or foreign name servers to additionally query for the A records associated with the defined name servers. By not using glue records, the delegated name servers are not required to be children of the 1.e164.arpa sub-domain. The result is increased resolution time due to additional queries and network traversals. 2.1.2.1.5.5.5.0.0.8.1.e164.arpa. IN NS ns1.acme.com. IN NS ns2.acme.com. In either scenario, the delegated name server must be minimally provisioned with an e164.arpa zone that contains the associated NAPTR records. It may be more conventional that the delegated name server be provisioned with the zone at the cut boundary (1.e164.arpa), but this is not a requirement. Are you attempting to avoid having the service registrar provision the e164.arpa zone on their name server? Bob _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 2 09:56:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12612 for ; Thu, 2 Nov 2000 09:56:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07226; Thu, 2 Nov 2000 09:53:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07198 for ; Thu, 2 Nov 2000 09:53:03 -0500 (EST) Received: from spitfire.law.miami.edu (postfix@spitfire.law.miami.edu [129.171.187.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10969 for ; Thu, 2 Nov 2000 09:53:02 -0500 (EST) Received: from spitfire.law.miami.edu (localhost [127.0.0.1]) by spitfire.law.miami.edu (Postfix) with ESMTP id 13D935C3AA2; Thu, 2 Nov 2000 09:53:04 -0500 (EST) Received: by spitfire.law.miami.edu (Postfix, from userid 1113) id 27B525C3AA2; Thu, 2 Nov 2000 09:53:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by spitfire.law.miami.edu (Postfix) with ESMTP id 1EBA45D3AF0; Thu, 2 Nov 2000 09:53:03 -0500 (EST) Date: Thu, 2 Nov 2000 09:53:03 -0500 (EST) From: "Michael Froomkin - U.Miami School of Law" To: Richard Shockey Cc: "Robert H. Walter" , enum@ietf.org, "Vaudreuil, Greg M (Greg)" , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Randy Bush Subject: Re: [Enum] Standard DNS Delegation or CNAME/DNAME Redirection In-Reply-To: <5.0.0.25.2.20001101233724.0269ea80@127.0.0.1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I am somewhat concerned by this. Can you please spell out in more detail what you propose? If I follow this, you are pushing for a quick decision on something basically irrevocable, correct? Or perhaps I misunderstood? On Wed, 1 Nov 2000, Richard Shockey wrote: > At 12:56 PM 10/31/2000 -0500, Robert H. Walter wrote: > >Greg, Ann, > > > >Please clarify why you believe CNAME and DNAME resource records > >are required to redirect the DNS query from the designated > >authority to the service registrar? Why re-issue, reform the > >query when standard DNS delegation will suffice? Consider the > >following scenarios that assume the designated authority for > >1.e164.arpa has provisioned the fully specified E.164 domain > >name 2.1.2.1.5.5.5.0.0.8.1.e164.arpa on behalf of the service > >registrar ACME: > > > This is a serious issue this list needs to come to consensus on ASAP. The > terms of RFC 2916 have been implemented in a IMHO historic agreement > between the IAB and the ITU and it is fair to assume that there needs to be > and will be operational testing in the e164.arpa name space shortly. > > We have an obligation to continue to move forward and communicate our work > to SG2/Q1 as necessary. > > We must assist Greg and Anne on the Operational document NOW. > > Those who believe CNAME or DNAME or other delegation RR are appropriate > need to speak up in advance of potential implementers. > > What are the advantages of each approach? What are the risks? Is there a > single optimal solution.. these issues need to be aired out here .. > > Is a MIB necessary? > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > -- Please visit http://www.icannwatch.org A. Michael Froomkin | Professor of Law | froomkin@law.tm U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | http://www.law.tm -->It's warm here.<-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 2 10:23:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22065 for ; Thu, 2 Nov 2000 10:23:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07940; Thu, 2 Nov 2000 10:19:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07913 for ; Thu, 2 Nov 2000 10:19:22 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20855 for ; Thu, 2 Nov 2000 10:19:21 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13rM94-0005PC-00; Thu, 02 Nov 2000 07:19:14 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Vaudreuil, Greg M (Greg)" Cc: "Robert H. Walter" , enum@ietf.org, Patrik Faltstrom References: <808BCB95E77CD21188DB00805F6F99C70587627A@txdj00exch005u.micro.lucent.com> Message-Id: Date: Thu, 02 Nov 2000 07:19:14 -0800 Content-Transfer-Encoding: 7bit Subject: [Enum] RE: Standard DNS Delegation or CNAME/DNAME Redirection Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > In a previous response, I have described a number of topologies where NS > records are not sufficient to represent existing numbering plan > topologies. the example in your document does not sustain that point, and the point has yet to be agreed in any circumstance. > Unless we decide otherwise, Dname / CNAME are useful and standard DNS > facilities. with very large warning signs on them. randy _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 2 10:25:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22590 for ; Thu, 2 Nov 2000 10:25:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08095; Thu, 2 Nov 2000 10:24:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08065 for ; Thu, 2 Nov 2000 10:24:32 -0500 (EST) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22376 for ; Thu, 2 Nov 2000 10:24:31 -0500 (EST) Received: by dnspri.npac.com; id JAA24844; Thu, 2 Nov 2000 09:24:28 -0600 (CST) Received: from unknown(192.168.20.149) by dnspri.npac.com via smap (V5.0) id xmaa24644; Thu, 2 Nov 00 09:23:49 -0600 Message-Id: <5.0.0.25.2.20001102101450.020f6170@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 02 Nov 2000 10:25:51 -0500 To: "A.M.Rutkowski" , "Robert H. Walter" , From: Richard Shockey Subject: Re: [Enum] Standard DNS Delegation or CNAME/DNAME Redirection Cc: "Vaudreuil, Greg M \(Greg\)" , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Randy Bush" In-Reply-To: <5.0.1.3.2.20001102063645.00a88dc0@mail.netmagic.com> References: <5.0.0.25.2.20001101233724.0269ea80@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 06:46 AM 11/2/2000 -0500, A.M.Rutkowski wrote: >Hi Richard, > >>This is a serious issue this list needs to come to consensus on >>ASAP. The terms of RFC 2916 have been implemented in a IMHO historic >>agreement between the IAB and the ITU and it is fair to assume that there >>needs to be and will be operational testing in the e164.arpa name space >>shortly. > >In light of the approval necessary by national >authorities under the agreement, might not operational >testing in non e164.arpa space occur more quickly? >Does it make any difference at this point? No ..testing can occur using any domain. >>We have an obligation to continue to move forward and communicate our >>work to SG2/Q1 as necessary. >> >>We must assist Greg and Anne on the Operational document NOW. > >An important related issue is the one you raised in Berlin, >namely the importance of a Level 1 Registry-Registrar interface, >which would also dispose of C interface in the Pfaust-Yu ID. > >How do you want to proceed? That is a purely operational issue out of scope for this WG...however I am aware of the desire to have a Registry Registrar BOF in San Diego..which I support and I will attend and actively participate in. You are correct ...the Pfautz-Yu draft practically cries out for a extensiable Registry-Registrar protocol. It will be my argument at that BOF that the current Hollenbeck (which IMHO is excellent ) draft be rewritten to be sufficiently generic to work with other application environments..aka ENUM ######## Title : Generic Registry-Registrar Protocol Requirements Author(s) : S. Hollenbeck Filename : draft-hollenbeck-grrp-reqs-05.txt Pages : 23 Date : 09-Oct-00 This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in shared Top Level Domain (TLD) registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and registrar operational models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hollenbeck-grrp-reqs-05.txt >--tony >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 202.533.2811 Fax to EMail 815.333.1237 (Preferred for Fax) Cell : 314.503.0640 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 2 10:25:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22611 for ; Thu, 2 Nov 2000 10:25:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08136; Thu, 2 Nov 2000 10:24:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08064 for ; Thu, 2 Nov 2000 10:24:32 -0500 (EST) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22375 for ; Thu, 2 Nov 2000 10:24:31 -0500 (EST) Received: by dnspri.npac.com; id JAA24843; Thu, 2 Nov 2000 09:24:28 -0600 (CST) Received: from unknown(192.168.20.149) by dnspri.npac.com via smap (V5.0) id xma024644; Thu, 2 Nov 00 09:23:47 -0600 Message-Id: <5.0.0.25.2.20001102100738.020f2b30@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 02 Nov 2000 10:14:33 -0500 To: "Michael Froomkin - U.Miami School of Law" From: Richard Shockey Subject: Re: [Enum] Standard DNS Delegation or CNAME/DNAME Redirection Cc: "Robert H. Walter" , enum@ietf.org, "Vaudreuil, Greg M (Greg)" , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Randy Bush In-Reply-To: References: <5.0.0.25.2.20001101233724.0269ea80@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 09:53 AM 11/2/2000 -0500, Michael Froomkin - U.Miami School of Law wrote: >I am somewhat concerned by this. Can you please spell out in more detail >what you propose? If I follow this, you are pushing for a quick decision >on something basically irrevocable, correct? Or perhaps I misunderstood? No Michael ... what I was pushing for was a proper airing of the issue here..this is a very technical issue involving what is the optimal method in DNS by which, for instance, a national delegation authority, aka .4.4 points to the NS of authority for a particular Telephone Number. There are several methods available ..the question is which is technically optimal for the ENUM application. The issue of delegation is not the question ..only how is the result achieved and that answer needs to come from the "Gods of DNS" >On Wed, 1 Nov 2000, Richard Shockey wrote: > > > At 12:56 PM 10/31/2000 -0500, Robert H. Walter wrote: > > >Greg, Ann, > > > > > >Please clarify why you believe CNAME and DNAME resource records > > >are required to redirect the DNS query from the designated > > >authority to the service registrar? Why re-issue, reform the > > >query when standard DNS delegation will suffice? Consider the > > >following scenarios that assume the designated authority for > > >1.e164.arpa has provisioned the fully specified E.164 domain > > >name 2.1.2.1.5.5.5.0.0.8.1.e164.arpa on behalf of the service > > >registrar ACME: > > > > > > This is a serious issue this list needs to come to consensus on ASAP. The > > terms of RFC 2916 have been implemented in a IMHO historic agreement > > between the IAB and the ITU and it is fair to assume that there needs > to be > > and will be operational testing in the e164.arpa name space shortly. > > > > We have an obligation to continue to move forward and communicate our work > > to SG2/Q1 as necessary. > > > > We must assist Greg and Anne on the Operational document NOW. > > > > Those who believe CNAME or DNAME or other delegation RR are appropriate > > need to speak up in advance of potential implementers. > > > > What are the advantages of each approach? What are the risks? Is there a > > single optimal solution.. these issues need to be aired out here .. > > > > Is a MIB necessary? > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > http://www1.ietf.org/mailman/listinfo/enum > > > >-- > Please visit http://www.icannwatch.org >A. Michael Froomkin | Professor of Law | froomkin@law.tm >U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA >+1 (305) 284-4285 | +1 (305) 284-6506 (fax) | http://www.law.tm > -->It's warm here.<-- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 202.533.2811 Fax to EMail 815.333.1237 (Preferred for Fax) Cell : 314.503.0640 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 2 11:25:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08809 for ; Thu, 2 Nov 2000 11:25:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09693; Thu, 2 Nov 2000 11:20:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09664 for ; Thu, 2 Nov 2000 11:20:56 -0500 (EST) Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07744 for ; Thu, 2 Nov 2000 11:20:54 -0500 (EST) Received: from rwalter ([38.136.73.76]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001102162054.CDLD1216.hvmta01-stg@rwalter>; Thu, 2 Nov 2000 11:20:54 -0500 From: "Robert H. Walter" To: "Vaudreuil, Greg M \(Greg\)" , Cc: "Patrik Faltstrom" , "Randy Bush" Date: Thu, 2 Nov 2000 11:21:28 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <808BCB95E77CD21188DB00805F6F99C70587627A@txdj00exch005u.micro.lucent.com> Content-Transfer-Encoding: 7bit Subject: [Enum] RE: Standard DNS Delegation or CNAME/DNAME Redirection Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > In a previous response, I have described a number of topologies where NS > records are not sufficient to represent existing numbering plan topologies. Can you be more explicit about which topology? I'm looking to support your position on the use of CNAME/DNAME, but can't justify its application. What issue are you attempting to solve by the use of CNAME/DNAME? Are you simply attempting to avoid having a delegated name server provision an e164.arpa zone by redirecting to an alternate name space, e.g. enum.company.com? Bob -----Original Message----- From: Vaudreuil, Greg M (Greg) [mailto:gregv@lucent.com] Sent: Thursday, November 02, 2000 9:52 AM To: Robert H. Walter; enum@ietf.org Cc: Patrik Faltstrom; Randy Bush Subject: RE: Standard DNS Delegation or CNAME/DNAME Redirection The key is your statement "Why re-issue, reform the query when standard DNS delegation will suffice". Where it is sufficient, it clearly preferable to use NS records to delegate authority. For the simple examples you have provided, the NS records are clearly sufficient and return more quickly. In a previous response, I have described a number of topologies where NS records are not sufficient to represent existing numbering plan topologies. Unless we decide otherwise, Dname / CNAME are useful and standard DNS facilities. As such they are part of the toolbox of an ENUM system administrator, must be supported by clients, and whose negative interactions with NAPTR must be well understood. Greg V. -----Original Message----- From: Robert H. Walter [mailto:rwalter@netnumber.com] Sent: Tuesday, October 31, 2000 11:57 AM To: enum@ietf.org Cc: Vaudreuil, Greg M (Greg); Patrik Faltstrom; Randy Bush Subject: Standard DNS Delegation or CNAME/DNAME Redirection Greg, Ann, Please clarify why you believe CNAME and DNAME resource records are required to redirect the DNS query from the designated authority to the service registrar? Why re-issue, reform the query when standard DNS delegation will suffice? Consider the following scenarios that assume the designated authority for 1.e164.arpa has provisioned the fully specified E.164 domain name 2.1.2.1.5.5.5.0.0.8.1.e164.arpa on behalf of the service registrar ACME: Scenario 1: Use NS and A glue records to delegate authority for the fully specified E.164 domain name to the registered name server. This approach has the advantage of not requiring client resolvers and/or foreign name servers to additionally query for the A records associated with the defined name servers. Using glue records has the additional restriction that the delegated name servers MUST be children of the 1.e164.arpa sub-domain, but results in reduced resolution time because there are fewer queries and network traversals required. Notice the extended domain names for acmes name servers. 2.1.2.1.5.5.5.0.0.8.1.e164.arpa. IN NS ns1.acme.1.e164.arpa. IN NS ns2.acme.1.e164.arpa. ns1.acme.1.e164.arpa. IN A 192.249.249.1 ns2.acme.1.e164.arpa. IN A 192.249.249.2 Scenario 2: Use only NS records to delegate authority for the fully specified E.164 domain name to the registered name server. This approach has the disadvantage of requiring client resolvers and/or foreign name servers to additionally query for the A records associated with the defined name servers. By not using glue records, the delegated name servers are not required to be children of the 1.e164.arpa sub-domain. The result is increased resolution time due to additional queries and network traversals. 2.1.2.1.5.5.5.0.0.8.1.e164.arpa. IN NS ns1.acme.com. IN NS ns2.acme.com. In either scenario, the delegated name server must be minimally provisioned with an e164.arpa zone that contains the associated NAPTR records. It may be more conventional that the delegated name server be provisioned with the zone at the cut boundary (1.e164.arpa), but this is not a requirement. Are you attempting to avoid having the service registrar provision the e164.arpa zone on their name server? Bob _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 2 11:31:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10319 for ; Thu, 2 Nov 2000 11:31:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09956; Thu, 2 Nov 2000 11:29:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09928 for ; Thu, 2 Nov 2000 11:29:24 -0500 (EST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09719 for ; Thu, 2 Nov 2000 11:29:23 -0500 (EST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 Nov 2000 08:29:04 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Thu, 2 Nov 2000 08:29:04 -0800 Message-ID: From: Christian Huitema To: "'Richard Shockey'" , "Michael Froomkin - U.Miami School of Law" Cc: "Robert H. Walter" , enum@ietf.org, "Vaudreuil, Greg M (Greg)" , Patrik Faltstrom , Randy Bush Subject: RE: [Enum] Standard DNS Delegation or CNAME/DNAME Redirection Date: Thu, 2 Nov 2000 08:28:51 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I support the use of DNAME in ENUM. I believe ENUM faces a major deployment problem, that of finding the authoritative publisher of an information. There are basically two solutions to this problem, bureaucratic management and competition. DNAME enables competition. If we have a single tree, we will end up with a set of regional monopolies deciding what goes in the mapping. At the top, we will indeed find the ITU, then the various local authorities, then the various phone providers. At each level, there will be confusion and power struggles. For example, look at "1.e164.arpa." Who has authority? The area is actually shared between several North American countries; even within the US, the delegation to the ITU is managed by the State Department while the regulation of telephony is managed by the FCC. If you go down to the area code level, the matter is not any clearer. Who has authority over "2.1.2.1.e164.arpa"? Is this the New York State public utilities commission, Bell Atlantic, or a third party? The matter only becomes kind of clearer at the lower level of the hierarchy, where "x.x.x.2.1.2.1.e164.arpa" corresponds to a bloc of addresses, the current unit of management for assignment of numbers to local competitive carriers, and also for LNP. (The most likely result is that each PUC will hire a contractor that manages the listing.) But then, a potential use of ENUM is to bypass the local carrier, for example to send documents as e-mail instead of faxes; this means, potentially, a loss of revenues. So, while the users of phone numbers have an interest in listing their numbers, the phone companies are conflicted. Expect some interesting developments. IMHO, the only way out is to allow a competition, have a forest instead of a tree, so that we could get alternative services such as "2.1.2.1.joe-s-listings.com." The clients that decide to use Joe's listings know what they get: Joe's idea of who owns what number; they can trade bureaucratic certainty and pace for rapid updates and potential mistakes. DNAME allows us to build forests instead of tree; Joe's listing may use the DNAME technology to point at branches managed by other servers, maybe even to point back to the main tree for some countries. Another interesting case is that of enterprises, who manage a local dial plan. If an enterprise uses 4 digits extensions, then it is much more natural to resolve "x1234" through "4.3.2.1.local-plan.example.com" than to go back all the way to the e164.arpa root. But then, it is also useful to store any piece of data only once, so there is no point in replicating the records of the local plan under "4.3.2.1.a.b.c.d.e.f.g.e164.arpa." This is a case where DNAME are very interesting. By the way, this works both ways. If the enterprise's dial plan has an escape code for international codes, say "00", and if it contracts with Joe's Listing company for the ENUM service, then it can enter a DNAME pointing "0.0.local-plan.example.com" to "joe-s-listings.com." In short, DNAME allow for a forest instead of a tree. A forest looks scary for bureaucrats, but it enables competition. And it also enables local management of resources without replication of records, smooth transitions between local dial plans and global registries. In any case, the tool is in the box, so the debate is a little bit futile... -- Christian Huitema _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 2 13:45:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14714 for ; Thu, 2 Nov 2000 13:45:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12026; Thu, 2 Nov 2000 13:44:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11999 for ; Thu, 2 Nov 2000 13:44:32 -0500 (EST) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14371 for ; Thu, 2 Nov 2000 13:44:31 -0500 (EST) Received: by dnspri.npac.com; id MAA21249; Thu, 2 Nov 2000 12:44:29 -0600 (CST) Received: from unknown(192.168.20.149) by dnspri.npac.com via smap (V5.0) id xma021064; Thu, 2 Nov 00 12:43:53 -0600 Message-Id: <5.0.0.25.2.20001102134444.02bbd7f0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 02 Nov 2000 13:45:32 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] FYI - ID on IETF-ISOC Liaison Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Liaison to IETF/ISOC on ENUM Author(s) : R. Blane Filename : draft-blane-sg2-liason-enum-00.txt Pages : 7 Date : 01-Nov-00 Working Party 1/2, of the International Telecommunication Union P Telecommunication Standardization Sector (ITU-T) held a meeting of its collaborators in Berlin Germany 19-26 October 2000. The agenda of the meeting contained several contributions regarding RFC 2916: 'E.164 Number and DNS' from the Internet Engineering Task Force's (IETF) ENUM Working Group - more specifically, the method for administering and maintaining the E.164-based resources in the Domain Name System (DNS) as related to the ENUM protocol. Consequently, in addition to the WP1/2 collaborators, there were several members of the IETF present to assist with the discussion of issues contained in the aforementioned contributions A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-blane-sg2-liason-enum-00.txt _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 2 13:59:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17812 for ; Thu, 2 Nov 2000 13:59:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12273; Thu, 2 Nov 2000 13:58:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12246 for ; Thu, 2 Nov 2000 13:58:14 -0500 (EST) Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17574 for ; Thu, 2 Nov 2000 13:58:13 -0500 (EST) Received: from thinkingcat.com ([64.229.192.102]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001102185744.IKOT625.tomts8-srv.bellnexxia.net@thinkingcat.com>; Thu, 2 Nov 2000 13:57:44 -0500 Message-ID: <3A01B8C2.31A7F776@thinkingcat.com> Date: Thu, 02 Nov 2000 13:56:02 -0500 From: Leslie Daigle Organization: ThinkingCat Enterprises X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vaudreuil, Greg M (Greg)" CC: "Robert H. Walter" , enum@ietf.org, Patrik Faltstrom , Randy Bush Subject: Re: [Enum] RE: Standard DNS Delegation or CNAME/DNAME Redirection References: <808BCB95E77CD21188DB00805F6F99C70587627A@txdj00exch005u.micro.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit I am in danger of having completely missed the point, but it strikes me that: . the "traditional" view of ENUM has been for "top-down" resolution, following a delegation path, and for that the NS/NAPTR route is appropriate/adequate. . your examples seem to treat "bottom-up" resolution -- working resolution from a local context outwards to the closest applicable scope. In that case, you don't want to/it would perhaps be difficult to engineer top-down resolution that would find the appropriate level for your resolution These are two different problems, and probably bear 2 different solutions -- but ones that need to be properly integrated or else we will wind up with "islands" of enum telephony (where you can't work your way out to "the" global registry). Leslie. "Vaudreuil, Greg M (Greg)" wrote: > > The key is your statement "Why re-issue, reform the query when standard DNS > delegation will suffice". Where it is sufficient, it clearly preferable to > use NS records to delegate authority. For the simple examples you have > provided, the NS records are clearly sufficient and return more quickly. > > In a previous response, I have described a number of topologies where NS > records are not sufficient to represent existing numbering plan topologies. > > Unless we decide otherwise, Dname / CNAME are useful and standard DNS > facilities. As such they are part of the toolbox of an ENUM system > administrator, must be supported by clients, and whose negative interactions > with NAPTR must be well understood. > > Greg V. > > -----Original Message----- > From: Robert H. Walter [mailto:rwalter@netnumber.com] > Sent: Tuesday, October 31, 2000 11:57 AM > To: enum@ietf.org > Cc: Vaudreuil, Greg M (Greg); Patrik Faltstrom; Randy Bush > Subject: Standard DNS Delegation or CNAME/DNAME Redirection > > Greg, Ann, > > Please clarify why you believe CNAME and DNAME resource records > are required to redirect the DNS query from the designated > authority to the service registrar? Why re-issue, reform the > query when standard DNS delegation will suffice? Consider the > following scenarios that assume the designated authority for > 1.e164.arpa has provisioned the fully specified E.164 domain > name 2.1.2.1.5.5.5.0.0.8.1.e164.arpa on behalf of the service > registrar ACME: > > Scenario 1: Use NS and A glue records to delegate authority for > the fully specified E.164 domain name to the registered name > server. This approach has the advantage of not requiring client > resolvers and/or foreign name servers to additionally query for > the A records associated with the defined name servers. Using > glue records has the additional restriction that the delegated > name servers MUST be children of the 1.e164.arpa sub-domain, > but results in reduced resolution time because there are fewer > queries and network traversals required. Notice the extended > domain names for acmes name servers. > > 2.1.2.1.5.5.5.0.0.8.1.e164.arpa. IN NS ns1.acme.1.e164.arpa. > IN NS ns2.acme.1.e164.arpa. > > ns1.acme.1.e164.arpa. IN A 192.249.249.1 > ns2.acme.1.e164.arpa. IN A 192.249.249.2 > > Scenario 2: Use only NS records to delegate authority for the > fully specified E.164 domain name to the registered name server. > This approach has the disadvantage of requiring client resolvers > and/or foreign name servers to additionally query for the A > records associated with the defined name servers. By not using > glue records, the delegated name servers are not required to be > children of the 1.e164.arpa sub-domain. The result is increased > resolution time due to additional queries and network traversals. > > 2.1.2.1.5.5.5.0.0.8.1.e164.arpa. IN NS ns1.acme.com. > IN NS ns2.acme.com. > > In either scenario, the delegated name server must be minimally > provisioned with an e164.arpa zone that contains the associated > NAPTR records. It may be more conventional that the delegated > name server be provisioned with the zone at the cut boundary > (1.e164.arpa), but this is not a requirement. Are you attempting > to avoid having the service registrar provision the e164.arpa > zone on their name server? > > Bob > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum -- ------------------------------------------------------------------- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 2 14:06:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20055 for ; Thu, 2 Nov 2000 14:06:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12612; Thu, 2 Nov 2000 14:05:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12583 for ; Thu, 2 Nov 2000 14:05:07 -0500 (EST) Received: from shell.nominum.com (shell.nominum.com [204.152.187.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19605 for ; Thu, 2 Nov 2000 14:05:06 -0500 (EST) Received: from drc-toshiba.nominum.com (shell.nominum.com [204.152.187.59]) by shell.nominum.com (Postfix) with ESMTP id EB2583190C; Thu, 2 Nov 2000 11:04:36 -0800 (PST) Message-Id: <5.0.0.25.2.20001102110408.00ae8058@localhost> X-Sender: drc@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 02 Nov 2000 11:04:36 -0800 To: Randy Bush , "Vaudreuil, Greg M (Greg)" From: "David R. Conrad" Subject: Re: [Enum] RE: Standard DNS Delegation or CNAME/DNAME Redirection Cc: "Robert H. Walter" , enum@ietf.org, Patrik Faltstrom In-Reply-To: References: <808BCB95E77CD21188DB00805F6F99C70587627A@txdj00exch005u.micro.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 07:19 AM 11/2/2000 -0800, Randy Bush wrote: > > Unless we decide otherwise, Dname / CNAME are useful and standard DNS > > facilities. >with very large warning signs on them. Which warning signs are those? Rgds, -drc _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 2 14:49:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02073 for ; Thu, 2 Nov 2000 14:49:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13185; Thu, 2 Nov 2000 14:48:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13155 for ; Thu, 2 Nov 2000 14:48:42 -0500 (EST) Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01797 for ; Thu, 2 Nov 2000 14:48:40 -0500 (EST) Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA13083 for ; Thu, 2 Nov 2000 14:48:41 -0500 (EST) Received: from pai820exch001h.wins.lucent.com (h135-14-3-59.lucent.com [135.14.3.59]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA13042 for ; Thu, 2 Nov 2000 14:48:40 -0500 (EST) Received: by pai820exch001h.micro.lucent.com with Internet Mail Service (5.5.2650.21) id <46J9Y7MT>; Thu, 2 Nov 2000 14:48:39 -0500 Message-ID: <808BCB95E77CD21188DB00805F6F99C70590041B@txdj00exch005u.micro.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Leslie Daigle Cc: "Robert H. Walter" , enum@ietf.org, Patrik Faltstrom , Randy Bush Subject: RE: [Enum] RE: Standard DNS Delegation or CNAME/DNAME Redirection Date: Thu, 2 Nov 2000 14:48:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Dname/Cname are clearly useful for bottom-up ENUM services, but that is not why I suggest their use. There are a number of top-down topologies which would benefit operationally from the ability to re-point one number tree to another or to re-point one address to another. Greg V. -----Original Message----- From: Leslie Daigle [mailto:leslie@thinkingcat.com] Sent: Thursday, November 02, 2000 12:56 PM To: Vaudreuil, Greg M (Greg) Cc: Robert H. Walter; enum@ietf.org; Patrik Faltstrom; Randy Bush Subject: Re: [Enum] RE: Standard DNS Delegation or CNAME/DNAME Redirection I am in danger of having completely missed the point, but it strikes me that: . the "traditional" view of ENUM has been for "top-down" resolution, following a delegation path, and for that the NS/NAPTR route is appropriate/adequate. . your examples seem to treat "bottom-up" resolution -- working resolution from a local context outwards to the closest applicable scope. In that case, you don't want to/it would perhaps be difficult to engineer top-down resolution that would find the appropriate level for your resolution These are two different problems, and probably bear 2 different solutions -- but ones that need to be properly integrated or else we will wind up with "islands" of enum telephony (where you can't work your way out to "the" global registry). Leslie. "Vaudreuil, Greg M (Greg)" wrote: > > The key is your statement "Why re-issue, reform the query when standard DNS > delegation will suffice". Where it is sufficient, it clearly preferable to > use NS records to delegate authority. For the simple examples you have > provided, the NS records are clearly sufficient and return more quickly. > > In a previous response, I have described a number of topologies where NS > records are not sufficient to represent existing numbering plan topologies. > > Unless we decide otherwise, Dname / CNAME are useful and standard DNS > facilities. As such they are part of the toolbox of an ENUM system > administrator, must be supported by clients, and whose negative interactions > with NAPTR must be well understood. > > Greg V. > > -----Original Message----- > From: Robert H. Walter [mailto:rwalter@netnumber.com] > Sent: Tuesday, October 31, 2000 11:57 AM > To: enum@ietf.org > Cc: Vaudreuil, Greg M (Greg); Patrik Faltstrom; Randy Bush > Subject: Standard DNS Delegation or CNAME/DNAME Redirection > > Greg, Ann, > > Please clarify why you believe CNAME and DNAME resource records > are required to redirect the DNS query from the designated > authority to the service registrar? Why re-issue, reform the > query when standard DNS delegation will suffice? Consider the > following scenarios that assume the designated authority for > 1.e164.arpa has provisioned the fully specified E.164 domain > name 2.1.2.1.5.5.5.0.0.8.1.e164.arpa on behalf of the service > registrar ACME: > > Scenario 1: Use NS and A glue records to delegate authority for > the fully specified E.164 domain name to the registered name > server. This approach has the advantage of not requiring client > resolvers and/or foreign name servers to additionally query for > the A records associated with the defined name servers. Using > glue records has the additional restriction that the delegated > name servers MUST be children of the 1.e164.arpa sub-domain, > but results in reduced resolution time because there are fewer > queries and network traversals required. Notice the extended > domain names for acmes name servers. > > 2.1.2.1.5.5.5.0.0.8.1.e164.arpa. IN NS ns1.acme.1.e164.arpa. > IN NS ns2.acme.1.e164.arpa. > > ns1.acme.1.e164.arpa. IN A 192.249.249.1 > ns2.acme.1.e164.arpa. IN A 192.249.249.2 > > Scenario 2: Use only NS records to delegate authority for the > fully specified E.164 domain name to the registered name server. > This approach has the disadvantage of requiring client resolvers > and/or foreign name servers to additionally query for the A > records associated with the defined name servers. By not using > glue records, the delegated name servers are not required to be > children of the 1.e164.arpa sub-domain. The result is increased > resolution time due to additional queries and network traversals. > > 2.1.2.1.5.5.5.0.0.8.1.e164.arpa. IN NS ns1.acme.com. > IN NS ns2.acme.com. > > In either scenario, the delegated name server must be minimally > provisioned with an e164.arpa zone that contains the associated > NAPTR records. It may be more conventional that the delegated > name server be provisioned with the zone at the cut boundary > (1.e164.arpa), but this is not a requirement. Are you attempting > to avoid having the service registrar provision the e164.arpa > zone on their name server? > > Bob > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum -- ------------------------------------------------------------------- "Reality with a delicate splash of the imaginary... ... or was that the other way around?" -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Nov 3 02:17:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26173 for ; Fri, 3 Nov 2000 02:17:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25272; Fri, 3 Nov 2000 02:16:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25241 for ; Fri, 3 Nov 2000 02:16:18 -0500 (EST) Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25620 for ; Fri, 3 Nov 2000 02:16:18 -0500 (EST) From: john.loughney@nokia.com Received: by esebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 3 Nov 2000 09:16:17 +0200 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DF2AD@eseis04nok> To: huitema@microsoft.com Cc: enum@ietf.org Subject: RE: [Enum] Standard DNS Delegation or CNAME/DNAME Redirection Date: Fri, 3 Nov 2000 09:16:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi All, I am not as much of an expert on DNS as maybe I should be, but I would like to put in my requirements. > I support the use of DNAME in ENUM. I believe ENUM faces a > major deployment problem, that of finding the authoritative > publisher of an information. There are basically two solutions > to this problem, bureaucratic management and competition. DNAME > enables competition. I beleive that Christian is correct in saying that competition should be encouraged. The scenario I have is in the coming 3G networks. In these networks, there may be the oportunity to associate many services with a phone number: SIP services, voice messaging, video messaging, streaming media, web page, email and so on. I see ENUM as a great way to wrap up many 'identities' of a user. My worry is that if a service provider is the ENUM service, it may be difficult to change the service provider of some or all of the services. Currently, there are companies within 3GPP who are suggesting the use of ENUM in the 3GPP networks, so this is an issue that we may want to consider. About the use of DNAME/CNAME, I will defer that discussion to those more expert with DNS. best regards, John _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Nov 3 07:29:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26178 for ; Fri, 3 Nov 2000 07:29:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27994; Fri, 3 Nov 2000 07:13:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27967 for ; Fri, 3 Nov 2000 07:12:58 -0500 (EST) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22444 for ; Fri, 3 Nov 2000 07:12:57 -0500 (EST) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 8A313101; Fri, 3 Nov 2000 13:12:26 +0100 (MET) Received: from [10.83.97.99] (rtp-dial-2-8.cisco.com [10.83.96.8]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA14441; Fri, 3 Nov 2000 13:12:20 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: References: Date: Fri, 3 Nov 2000 06:42:21 -0500 To: Christian Huitema , "'Richard Shockey'" , "Michael Froomkin - U.Miami School of Law" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] Standard DNS Delegation or CNAME/DNAME Redirection Cc: "Robert H. Walter" , enum@ietf.org, "Vaudreuil, Greg M (Greg)" , Randy Bush Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 08.28 -0800 00-11-02, Christian Huitema wrote: >I support the use of DNAME in ENUM. I believe ENUM faces a major deployment >problem, that of finding the authoritative publisher of an information. >There are basically two solutions to this problem, bureaucratic management >and competition. DNAME enables competition. I think you have to be VERY careful here. As a person which have a E.164 number delegated to me (secondary delegation as it is called in Sweden), I don't want to know what listing service you use, and what I have to do so you find information about my number. The key thing is that I as the holder of the E.164 number should be able to choose service provider for the service, and _regardless_ of what service provider I choose, you should find the record. If you with competition include the risk that if you query two different listing services you get different results for my E.164 number, then I claim we have failed. Patrik _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Nov 3 09:34:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27868 for ; Fri, 3 Nov 2000 09:34:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29285; Fri, 3 Nov 2000 09:27:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29260 for ; Fri, 3 Nov 2000 09:27:02 -0500 (EST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26172 for ; Fri, 3 Nov 2000 09:27:00 -0500 (EST) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.3) with ESMTP id JAA14267; Fri, 3 Nov 2000 09:26:29 -0500 (EST) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id JAA10515; Fri, 3 Nov 2000 09:25:30 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Fri, 3 Nov 2000 09:26:28 -0500 Message-ID: <1B08859602C8D211B66F0000C0769CFA041D8B3E@njc240po03.mt.att.com> From: "Pfautz, Penn L, NNAD" To: Christian Huitema Cc: enum@ietf.org Subject: RE: [Enum] Standard DNS Delegation or CNAME/DNAME Redirection Date: Fri, 3 Nov 2000 09:25:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Chriatian: Some comments, less directed at CNAME/DNAME, than the more general issues you raise. -----Original Message----- From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Thursday, November 02, 2000 11:29 AM To: 'Richard Shockey'; Michael Froomkin - U.Miami School of Law Cc: Robert H. Walter; enum@ietf.org; Vaudreuil, Greg M (Greg); Patrik Faltstrom; Randy Bush Subject: RE: [Enum] Standard DNS Delegation or CNAME/DNAME Redirection I support the use of DNAME in ENUM. I believe ENUM faces a major deployment problem, that of finding the authoritative publisher of an information. There are basically two solutions to this problem, bureaucratic management and competition. DNAME enables competition. If we have a single tree, we will end up with a set of regional monopolies deciding what goes in the mapping. At the top, we will indeed find the ITU, then the various local authorities, then the various phone providers. At each level, there will be confusion and power struggles. For example, look at "1.e164.arpa." Who has authority? The area is actually shared between several North American countries; even within the US, the delegation to the ITU is managed by the State Department while the regulation of telephony is managed by the FCC. If you go down to the area code level, the matter is not any clearer. Who has authority over "2.1.2.1.e164.arpa"? Is this the New York State public utilities commission, Bell Atlantic, or a third party? The matter only becomes kind of clearer at the lower level of the hierarchy, where "x.x.x.2.1.2.1.e164.arpa" corresponds to a bloc of addresses, the current unit of management for assignment of numbers to local competitive carriers, and also for LNP. (The most likely result is that each PUC will hire a contractor that manages the listing.) But then, a potential use of ENUM is to bypass the local carrier, for example to send documents as e-mail instead of faxes; this means, potentially, a loss of revenues. So, while the users of phone numbers have an interest in listing their numbers, the phone companies are conflicted. Expect some interesting developments. >> I don't think that *this* part of the tree will be that much of a problem. >> If the other participants in the NANP don't want to join the US in ENUM administration >> RIPE, who will maintain the top e164.arpa domain, will provision down to the NPA level >> in their DNS. I envision, as James Yu and I have laid out in our I-D, that there >> will need to be some federally chartered entity that maintains a 1.e164.arpa >> (or us-npa.e164.arpa) level DNS that points for each number to the appropriate service >> registar. It's at the service registrar level that I hope competition can occur. I >> don't see states administering their own NPAs nor do I see telcos having delegation >> for ther LERG-assigned number blocks, though it is possible that telcos will have >> delegation for the numbers they actually provide service for. IMHO, the only way out is to allow a competition, have a forest instead of a tree, so that we could get alternative services such as "2.1.2.1.joe-s-listings.com." The clients that decide to use Joe's listings know what they get: Joe's idea of who owns what number; they can trade bureaucratic certainty and pace for rapid updates and potential mistakes. DNAME allows us to build forests instead of tree; Joe's listing may use the DNAME technology to point at branches managed by other servers, maybe even to point back to the main tree for some countries. >> The problem with the "joe's listings" approach is it doesn't guarantee me >> control over my telephone number's domain. At the end of the day Joe will have >> to verify TN ownership. Otherwise, someone may register a number they don't own >> with Joe, get calls/messages/etc that belong to someone else, and Joe, possibly >> along with any registry that Joe uses, will get sued. When people's calls get stolen, >> which is worse than slamming, the bureaucrats will get involved with a vengance. >> That's why we need to build in safeguards to begin with, even if it drags the process >> out. >> There is also the problem Patrik points out: if folks need to figure out what >> listing sevice to use, ENUM will be that much less useful. Another interesting case is that of enterprises, who manage a local dial plan. If an enterprise uses 4 digits extensions, then it is much more natural to resolve "x1234" through "4.3.2.1.local-plan.example.com" than to go back all the way to the e164.arpa root. But then, it is also useful to store any piece of data only once, so there is no point in replicating the records of the local plan under "4.3.2.1.a.b.c.d.e.f.g.e164.arpa." This is a case where DNAME are very interesting. By the way, this works both ways. If the enterprise's dial plan has an escape code for international codes, say "00", and if it contracts with Joe's Listing company for the ENUM service, then it can enter a DNAME pointing "0.0.local-plan.example.com" to "joe-s-listings.com." >> I see no problem for folks who want to do *some* resolution using the ENUM protocol >> in domains other than e164.arpa for their own private numbering plans. In short, DNAME allow for a forest instead of a tree. A forest looks scary for bureaucrats, but it enables competition. And it also enables local management of resources without replication of records, smooth transitions between local dial plans and global registries. In any case, the tool is in the box, so the debate is a little bit futile... >> Penn Pfautz -- Christian Huitema _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Nov 3 16:39:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02933 for ; Fri, 3 Nov 2000 16:39:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04405; Fri, 3 Nov 2000 16:25:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04378 for ; Fri, 3 Nov 2000 16:25:21 -0500 (EST) Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net [38.202.36.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29249 for ; Fri, 3 Nov 2000 16:25:19 -0500 (EST) Received: from rwalter ([38.136.73.76]) by hvmta03-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001103212450.QSCI24415.hvmta03-stg@rwalter>; Fri, 3 Nov 2000 16:24:50 -0500 From: "Robert H. Walter" To: "Christian Huitema" Cc: Subject: RE: [Enum] Standard DNS Delegation or CNAME/DNAME Redirection Date: Fri, 3 Nov 2000 16:25:25 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Hi Christian, Thank you for your insights... I'd like to follow-up with you. > I support the use of DNAME in ENUM. I believe ENUM faces a major deployment > problem, that of finding the authoritative publisher of an information. > There are basically two solutions to this problem, bureaucratic management > and competition. DNAME enables competition. I totally agree with your first statement about two solutions, but fail to see how CNAME/DNAME enables competition. > If we have a single tree, we will end up with a set of regional monopolies > deciding what goes in the mapping. At the top, we will indeed find the ITU, > then the various local authorities, then the various phone providers. At > each level, there will be confusion and power struggles. For example, look > at "1.e164.arpa." Who has authority? The area is actually shared between > several North American countries; even within the US, the delegation to the > ITU is managed by the State Department while the regulation of telephony is > managed by the FCC. If you go down to the area code level, the matter is not > any clearer. Who has authority over "2.1.2.1.e164.arpa"? Is this the New > York State public utilities commission, Bell Atlantic, or a third party? The > matter only becomes kind of clearer at the lower level of the hierarchy, > where "x.x.x.2.1.2.1.e164.arpa" corresponds to a bloc of addresses, the > current unit of management for assignment of numbers to local competitive > carriers, and also for LNP. (The most likely result is that each PUC will > hire a contractor that manages the listing.) But then, a potential use of > ENUM is to bypass the local carrier, for example to send documents as e-mail > instead of faxes; this means, potentially, a loss of revenues. So, while the > users of phone numbers have an interest in listing their numbers, the phone > companies are conflicted. Expect some interesting developments. Again, I agree with you that exclusive distribution the authority of the first tier across multiple, potentially conflicting operating authorities restricts competition and is wrought with all sorts of complexities. > IMHO, the only way out is to allow a competition, have a forest instead of a > tree, so that we could get alternative services such as > "2.1.2.1.joe-s-listings.com." The clients that decide to use Joe's listings > know what they get: Joe's idea of who owns what number; they can trade > bureaucratic certainty and pace for rapid updates and potential mistakes. > DNAME allows us to build forests instead of tree; Joe's listing may use the > DNAME technology to point at branches managed by other servers, maybe even > to point back to the main tree for some countries. As I understand it, DNAME enables an entire subdomain to be mapped to a different subdomain. This is very similar to what CNAME provides for a single domain name. I see how CNAME/DNAME can be leveraged in the first tier to facilitate dialing plan changes during the transition period, but this does not address the issue of delegation to the second tier or competition. This is a well understood DNS administrative trick of the trade. Are you proposing that a single E.164 domain name entry be provisioned in the first tier with multiple CNAME/DNAME records? For example: 2.1.2.1.5.5.5.0.0.8.1.e164.arpa. IN CNAME 2.1.2.1.5.5.5.0.0.8.1.joes.com. IN CNAME 2.1.2.1.5.5.5.0.0.8.1.anns.com. IN CNAME 2.1.2.1.5.5.5.0.0.8.1.ikes.com. I'm going out on a limb and assuming an ENUM resolver would query directly for the CNAME records and then re-write/re-issue the query using the canonical name. DNAME could be used similarly for blocks of numbers registered in the first tier. How would the resolver choose which service registrar to re-issue the query too? Would it simply use DNS rotation? Please help me out here and further elaborate on how CNAME/DNAME can be leveraged to increase competition. > Another interesting case is that of enterprises, who manage a local dial > plan. If an enterprise uses 4 digits extensions, then it is much more > natural to resolve "x1234" through "4.3.2.1.local-plan.example.com" than to > go back all the way to the e164.arpa root. But then, it is also useful to > store any piece of data only once, so there is no point in replicating the > records of the local plan under "4.3.2.1.a.b.c.d.e.f.g.e164.arpa." This is a > case where DNAME are very interesting. By the way, this works both ways. If > the enterprise's dial plan has an escape code for international codes, say > "00", and if it contracts with Joe's Listing company for the ENUM service, > then it can enter a DNAME pointing "0.0.local-plan.example.com" to > "joe-s-listings.com." I must be missing the point. This appears to be a second tier issue, hence the delegation from the first tier to the second has already been performed. It is reasonable that an enterprise would run it's DNS in a split configuration where CNAME/DNAME is used internally to map to a publically operated e164.arpa zone. IMHO, if an enterprise chooses to privately provision it's DNS servers with CNAME/DNAME it's completely up to them. > In short, DNAME allow for a forest instead of a tree. A forest looks scary > for bureaucrats, but it enables competition. And it also enables local > management of resources without replication of records, smooth transitions > between local dial plans and global registries. In any case, the tool is in > the box, so the debate is a little bit futile... More power to eliminating duplication of records and smoothing transitions between local plans and global registries! Long live CNAME/DNAME, but how does CNAME/DNAME support competition at the first and/or second tiers? Thanks, Bob _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Nov 6 16:42:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09869 for ; Mon, 6 Nov 2000 16:42:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25302; Mon, 6 Nov 2000 16:39:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25271 for ; Mon, 6 Nov 2000 16:39:25 -0500 (EST) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08957 for ; Mon, 6 Nov 2000 16:39:21 -0500 (EST) Received: by dnspri.npac.com; id PAA27772; Mon, 6 Nov 2000 15:39:22 -0600 (CST) Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0) id xma027590; Mon, 6 Nov 00 15:39:20 -0600 Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 15:37:02 -0600 Message-ID: From: James Yu To: "'enum@ietf.org'" Cc: "John Loughney (E-mail)" Date: Mon, 6 Nov 2000 15:39:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] draft-loughney-enum-roaming-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org It has been quiet on this particular I-D. At the last ENUM meeting, some people commented that ENUM was not appropriate for the cellular roaming use. This is to clarify why ENUM can be used between two cellular/PCS networks. When a roamer appears in the visited cellular network, it registers itself using its International Mobile Station Identity (IMSI). I'll use a simple case by assuming that Temporary Mobile Station Identity (TMSI) is not involved. This IMSI (E.212 recommendation) is first converted to a mobile global title described in E.214 recommendation by the Visitor Location Register (VLR). The SS7 networks uses the E.214 number in the Signaling System Number 7 (SS7) Signaling Connection Control Part (SCCP) Called Party Address parameter to perform global title translations (GTTs) and eventually reaches the Home Location Register (HLR) of the roamer. In the Mobile Application Part (MAP) layer (e.g., GSM MAP), an E.164 number identifier called VLRID is present that tells the HLR to use that VLRID to route the response back (the VLRID is also in the SCCP Calling Party Address parameter of the 1st message from the VLR to the HLR. The key point is that the first message uses an E.214 number (actually it is very similar to an E.164 number) but the subsequent messages all use E.164 numbers (VLRID and HLRID) to transport SS7 messages between the HLR and VLR. Since ENUM deals with E.164 numbers only, "ROAM" service in this I-D allows the cellular nodes to allocate the HLR or VLR associated with a roamer. The resolution of E.214 numbers (or directly using the E.212 numbers) may require another ENUM-like process (e.g., e214.arpa). There are certainly ways that can avoid the use of ENUM. But here we are discussing how ENUM can be used. The HLRID and VLRID can be E.164 numbers not assigned to the end users. This is what I called 'network-related service" in the draft-pfautz-yu-enum-adm.00.txt, "ENUM Administrative Process in the U.S.A." One reason that GTT is used in SS7 message transport is because the message routing in many cases involve two cellular networks in different countries. A SS7 point code in U.K. cannot be used directly by a SS7 node in France to send a SS7 message to. IP will change that because IP is global. This is just one example of use of ENUM. Another example is to identify the message center that serves a particular cellular subscriber when there is a short message destined towards that subscriber. In this example, the E.164 number is assigned to an cellular subscriber; however, the service that uses ENUM is again a "network-related service." John and I would like to hear from you to see whether they is any problem to move this I-D forward. Thanks. James Yu Principal Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue, NW, Suite 550 Washington, D.C. 20005 USA +1-202-533-2814 (B) +1-202-285-8326 (Mobile) +1-202-533-2976 (Fax) james.yu@neustar.com http://www.neustar.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 7 02:35:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05272 for ; Tue, 7 Nov 2000 02:35:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06851; Tue, 7 Nov 2000 02:34:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06820 for ; Tue, 7 Nov 2000 02:34:37 -0500 (EST) Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04807 for ; Tue, 7 Nov 2000 02:34:35 -0500 (EST) From: john.loughney@nokia.com Received: by esebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 7 Nov 2000 09:34:35 +0200 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DF2E3@eseis04nok> To: james.yu@neustar.com, enum@ietf.org Cc: john.loughney@nokia.com Date: Tue, 7 Nov 2000 09:34:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] RE: draft-loughney-enum-roaming-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi James & everyone, > One reason that GTT is used in SS7 message transport is > because the message routing in many cases involve two > cellular networks in different countries. A SS7 point code > in U.K. cannot be used directly by a SS7 node in France to > send a SS7 message to. IP will change that because IP is > global. This is just one example of use of ENUM. Another > example is to identify the message center that serves a > particular cellular subscriber when there is a short > message destined towards that subscriber. In this example, > the E.164 number is assigned to an cellular subscriber; > however, the service that uses ENUM is again a "network-related > service." Thanks for summarizing the intention of this draft. You did a much better job that what I did at Pittsburgh :) I also want to mention that this issues will get much more complicated in the proposed 3G networks. There will be operators implementing all of their networks over IP. In your scenario, there will need to be some negotiation/ mapping between the SS7 addresses and IP address that will be assigned for the VLR/HLR. One further complication is that there may be AAA servers providing the same functionality for 3G cellular subscribers. I would like to think that ENUM could be a techology that is used to promote interoperability/interworking for this purpose. > John and I would like to hear from you to see whether they is > any problem to move this I-D forward. thanks, John _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Nov 13 20:33:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03183 for ; Mon, 13 Nov 2000 20:33:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15842; Mon, 13 Nov 2000 20:31:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15813 for ; Mon, 13 Nov 2000 20:31:57 -0500 (EST) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02865 for ; Mon, 13 Nov 2000 20:31:58 -0500 (EST) Received: from computer.ix.netcom.com (tfx-us15-60.ix.netcom.com [207.94.236.60]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id UAA09263 for ; Mon, 13 Nov 2000 20:31:53 -0500 (EST) Message-Id: <5.0.0.25.2.20001113203057.02868560@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 13 Nov 2000 20:32:13 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Reminder that the 17th is coming up for drafts Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org If you plan on submissions the first cut is the 17th and the last is the 24. We should be using these submissions as the basis for the agenda etc. Please plan accordingly. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 202.533.2811 Fax to EMail 815.333.1237 (Preferred for Fax) Cell : 314.503.0640 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sun Nov 19 20:31:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14141 for ; Sun, 19 Nov 2000 20:31:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07362; Sun, 19 Nov 2000 20:30:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07331 for ; Sun, 19 Nov 2000 20:30:31 -0500 (EST) Received: from adsl-151-203-17-31.bellatlantic.net (root@adsl-151-203-17-31.bostma.adsl.bellatlantic.net [151.203.17.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14119 for ; Sun, 19 Nov 2000 20:30:28 -0500 (EST) Received: from localhost (scott.petrack@localhost) by adsl-151-203-17-31.bellatlantic.net (8.9.3/8.9.3) with ESMTP id RAA04454 for ; Sun, 19 Nov 2000 17:01:48 -0500 X-Authentication-Warning: adsl-151-203-17-31.bellatlantic.net: scott.petrack owned process doing -bs Date: Sun, 19 Nov 2000 17:01:48 -0500 (EST) From: Scott Petrack X-Sender: scott.petrack@adsl-151-203-17-31.bellatlantic.net To: enum@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Enum] Message from soon-to-be-former chair Scott Petrack Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Friends, As many of you have noticed, I simply have not been nearly as active as I would have liked over the past many months on the list or behind the scenes. As important as I think the ENUM activities are, and as proud as I am to have helped get them off the ground and moving in the correct direction, my responsibilities at eDial have been simply overwhelming. The only honorable thing to do seems to be to relinquish in fact what has been the case in practise: I will not be co-chairing ENUM at the San Diego IETF. I hope very much to continue supporting the work of ENUM in any way I can, and hope that you'll let me take some responsibilities on in the future when eDial needs less than my constant attention. My thanks go to Richard for moving things along when I wasn't. Scott Petrack You may go to the following URL to get me on the phone: http://800.edial.com/scott.petrack@edial.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Nov 20 14:44:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02411 for ; Mon, 20 Nov 2000 14:44:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27761; Mon, 20 Nov 2000 14:43:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27730 for ; Mon, 20 Nov 2000 14:43:45 -0500 (EST) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02330 for ; Mon, 20 Nov 2000 14:43:44 -0500 (EST) Received: by dnspri.npac.com; id NAA09236; Mon, 20 Nov 2000 13:43:44 -0600 (CST) Received: from unknown(192.168.20.106) by dnspri.npac.com via smap (V5.0) id xma009063; Mon, 20 Nov 00 13:43:16 -0600 Message-Id: <5.0.0.25.2.20001120141246.02cbcdc0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 20 Nov 2000 14:46:05 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Draft Agenda.... IETF 49 ENUM WG Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Its been very quiet here but we still have some things to discuss in San Diego. Reminder we are meeting on thrusday afternoon for 2 1/2 hours ... Jay Hilton has once again kindly offered to scribe the meeting for us. 1. Agenda Bashing (5 min) 2. Thanks to our former co-chair Scott Petrak ( 5 min) 3. ENUM Administration in the United States - Penn Pfautz - James Yu (20 min) 4. ENUM Call Flows - Steve Lind (15 Min) 5. ENUM Operations - Greg Vardureuil (20 min + ) I'm putting this toward the end since I would like us to read very carefully the document here and be prepared to discuss some of the issue involved in the Delegation matter. I've asked the list to discuss some of the pro's and con's of the DNAME vs CNAME vs other alternatives and we have not seen a full discussion as of yet. Perhaps we can take the opportunity to move to consensus. 6. WG next steps . ENUM MIB? 10 min + 7. Further Updates on IETF-ITU discussions coming out of ITU Study Group 2 meetings in Berlin. ( Chair - Others ) 8. Open Discussion Did I forget anything? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 202.533.2811 Fax to EMail 815.333.1237 (Preferred for Fax) Cell : 314.503.0640 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Nov 24 18:29:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26728 for ; Fri, 24 Nov 2000 18:29:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29479; Fri, 24 Nov 2000 18:28:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29451 for ; Fri, 24 Nov 2000 18:28:24 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26449; Fri, 24 Nov 2000 18:28:21 -0500 (EST) Message-Id: <200011242328.SAA26449@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: Fri, 24 Nov 2000 18:28:21 -0500 Subject: [Enum] I-D ACTION:draft-ietf-enum-e164-gstn-np-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : Number Portability in the GSTN: An Overview Author(s) : M. Foster, T. McGarry, J. Yu Filename : draft-ietf-enum-e164-gstn-np-00.txt Pages : 34 Date : 22-Nov-00 This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). There are three types of number portability: service provider number portability (SPNP), location portability, and service portability. Service provider portability, the focus of the present draft, is a regulatory imperative in many countries seeking to liberalize local telephony service competition, by enabling end-users to retain pre- existing telephone numbers while changing service providers. Implementation of NP within national GSTN entails potentially significant changes to numbering administration, network element signaling, call routing and processing, billing, service management, and other functions. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints which establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony work-in-progress at IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-gstn-np-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-e164-gstn-np-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-e164-gstn-np-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <20001122150232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-e164-gstn-np-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-e164-gstn-np-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122150232.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sat Nov 25 10:04:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04431 for ; Sat, 25 Nov 2000 10:04:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14064; Sat, 25 Nov 2000 10:03:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14033 for ; Sat, 25 Nov 2000 10:03:29 -0500 (EST) Received: from exchange.chaos.com (exchange.chaos.com [206.5.17.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04175 for ; Sat, 25 Nov 2000 10:03:25 -0500 (EST) Received: from [206.5.17.17] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id vicjaaaa for enum@ietf.org; Sat, 25 Nov 2000 10:03:26 -0500 Message-Id: <5.0.1.3.2.20001125092648.00a764e0@mail.netmagic.com> X-Sender: amr@mail.netmagic.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1.3 (Beta) Date: Sat, 25 Nov 2000 10:03:26 -0500 To: enum@ietf.org From: "A.M.Rutkowski" In-Reply-To: <5.0.0.25.2.20001113203057.02868560@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] draft-ietf-enum-e164-gstn-np-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org The mew Foster/McGarry/Yu NeuStar informational ID states as a conclusion that: NP certainly must be considered at the first level because the telephony service providers do not "own" or control the telephone numbers under the NP environment; therefore, they may not be the proper entities to have the authority for a given E.164 number. Not only that, the donor network should not be relied on to reach the delegated authority during the DNS process because there is a regulatory requirement on NP in some countries. RFC2916 provides for the "transformation of E.164 numbers into DNS names" by "holders" of those numbers. It is a good, limited construct. This new ID speaks of "ownership" and "authority for a given E.164 number" in terms that imply some fundamental constraints on who can or cannot provide Level 1 DNS services - at least in the e164.arpa domain. This would derivatively make the e164.arpa domain subject to the jurisdiction of telecom regulatory authorities and raises significant antitrust concerns. Compare this to the unfettered use of E.164 numbers for more than 8 years under the tpc.int domain pursuant to RFCs 1528-1530 Might not it be better to return to the RFC2916 construct and simply deal with the problem of an open interface for authenticating "holders" - rather than notions of ownership that are bound to authority. -amr _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sat Nov 25 11:31:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27310 for ; Sat, 25 Nov 2000 11:31:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14671; Sat, 25 Nov 2000 11:29:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14642 for ; Sat, 25 Nov 2000 11:29:27 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26901 for ; Sat, 25 Nov 2000 11:29:24 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA04073; Sat, 25 Nov 2000 08:29:23 -0800 Message-Id: <5.0.1.4.2.20001125081342.032e5d20@joy.songbird.com> X-Sender: dhc@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Sat, 25 Nov 2000 08:26:05 -0800 To: "A.M.Rutkowski" From: Dave Crocker Subject: Re: [Enum] draft-ietf-enum-e164-gstn-np-00.txt Cc: enum@ietf.org In-Reply-To: <5.0.1.3.2.20001125092648.00a764e0@mail.netmagic.com> References: <5.0.0.25.2.20001113203057.02868560@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 10:03 AM 11/25/00 -0500, A.M.Rutkowski wrote: >Compare this to the unfettered use of E.164 numbers for >more than 8 years under the tpc.int domain pursuant to >RFCs 1528-1530 Let's be very clear about the nature of tpc.int experience: It has never been more than a minuscule activity, excellent as an experiment to show proof of concept for a basic mapping mechanism. It offers NO insight into Internet-scale administration and operation, particularly with regard to maintaining synchronization between "telephone" assignment of numbers and e.164.arpa assignment. It also offers no insight into the more general e164.arpa goal of supporting a range of different services, through multiple DNS RR records under a given 3164.arpa number. From the ICANN wg-c mailing list: At 02:44 PM 11/25/00 +0100, Harald Alvestrand wrote: >I believe that letting customers claim rights to a number in e164.com when >they have lost all rights to the same number in the real telephone number >space will lead to much confusion and no gain. >The telephone number space is the reality, and all spaces that mirror it, >whether e164.com or e164.arpa, are its shadows (to misuse Platon's imagery). >Having shadows that linger when the reality is gone benefits nobody. Internet-scale administration and operation must deal with transitions, such as reassignment of a telephone number and, therefore, either re-assignment or resulting conflict of the corresponding e164.arpa number. This requirement means that the company assigning telephone numbers may well have different interests from the USER (assignee) of the number. Indeed the assignee might have entries in their e164.arpa for services that compete with the company assignign the telephone number. An independent third-party administrator suffers no such potential conflict. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sat Nov 25 11:51:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01704 for ; Sat, 25 Nov 2000 11:51:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15014; Sat, 25 Nov 2000 11:50:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14983 for ; Sat, 25 Nov 2000 11:50:51 -0500 (EST) Received: from exchange.chaos.com (exchange.chaos.com [206.5.17.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01600 for ; Sat, 25 Nov 2000 11:50:48 -0500 (EST) Received: from [206.5.17.17] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id fjcjaaaa for enum@ietf.org; Sat, 25 Nov 2000 11:50:44 -0500 Message-Id: <5.0.1.3.2.20001125113856.00afff08@mail.netmagic.com> X-Sender: amr@mail.netmagic.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1.3 (Beta) Date: Sat, 25 Nov 2000 11:50:44 -0500 To: Dave Crocker From: "A.M.Rutkowski" Subject: Re: [Enum] draft-ietf-enum-e164-gstn-np-00.txt Cc: enum@ietf.org In-Reply-To: <5.0.1.4.2.20001125081342.032e5d20@joy.songbird.com> References: <5.0.1.3.2.20001125092648.00a764e0@mail.netmagic.com> <5.0.0.25.2.20001113203057.02868560@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11:26 AM 11/25/2000, Dave Crocker wrote: >This requirement means that the company assigning telephone numbers may >well have different interests from the USER (assignee) of the >number. Indeed the assignee might have entries in their e164.arpa for >services that compete with the company assignign the telephone number. However, the problem of authenticating the a user's use to an E.164 number in 1.e164.arpa, 1.e164.com, etc, is separable (and should be separate) from the matter of who administers the zone. -amr _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sat Nov 25 16:23:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13847 for ; Sat, 25 Nov 2000 16:23:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17500; Sat, 25 Nov 2000 16:22:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17471 for ; Sat, 25 Nov 2000 16:22:01 -0500 (EST) Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13522 for ; Sat, 25 Nov 2000 16:21:58 -0500 (EST) Received: from computer.ix.netcom.com (user-2ivek4r.dialup.mindspring.com [165.247.80.155]) by mclean.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id QAA25350; Sat, 25 Nov 2000 16:21:56 -0500 (EST) Message-Id: <5.0.0.25.2.20001125160322.02cf79e0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 25 Nov 2000 16:24:50 -0500 To: "A.M.Rutkowski" , Dave Crocker From: Richard Shockey Subject: Re: [Enum] draft-ietf-enum-e164-gstn-np-00.txt Cc: enum@ietf.org In-Reply-To: <5.0.1.3.2.20001125113856.00afff08@mail.netmagic.com> References: <5.0.1.4.2.20001125081342.032e5d20@joy.songbird.com> <5.0.1.3.2.20001125092648.00a764e0@mail.netmagic.com> <5.0.0.25.2.20001113203057.02868560@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11:50 AM 11/25/2000 -0500, A.M.Rutkowski wrote: >At 11:26 AM 11/25/2000, Dave Crocker wrote: >>This requirement means that the company assigning telephone numbers may >>well have different interests from the USER (assignee) of the >>number. Indeed the assignee might have entries in their e164.arpa for >>services that compete with the company assignign the telephone number. Exactly ..thank you Dave. >However, the problem of authenticating the a user's use to an >E.164 number in 1.e164.arpa, 1.e164.com, etc, is separable (and >should be separate) from the matter of who administers the zone. But remember that the account data necessary to authenticate the users right to use the E.164 number is currently held ( in the US ) by the carrier that issued the number as part of PSTN service or to the carrier that the number has been ported to. This does _not_ imply carrier control. The purpose of the e164.arpa namespace is to be "athoritive" as opposed to any other domain. There is certainly nothing stopping anyone from putting number strings in FOO.NET or whatever for the purpose of defining some private service or services. Consequently the administrative model for determining correct holder of a E.164 number within e164.arpa must by definition follow the appropriate national numbering plan. That is what RFC2916 states and that is what the ITU has agreed to as well. The purpose of a proper administrative model for e16.arpa is to insure that a consumers or businesses does not have their number hijacked, slammed, crammed or whatever by malicious 3rd parties. We certainly do not want to recreate the problems in either the current TLD or PSTN environment. >-amr > > > >_______________________________________________ >enum mailing list >enum@ietf.org >http://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 202.533.2811 Fax to EMail 815.333.1237 (Preferred for Fax) Cell : 314.503.0640 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sat Nov 25 16:36:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17340 for ; Sat, 25 Nov 2000 16:36:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17782; Sat, 25 Nov 2000 16:35:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17751 for ; Sat, 25 Nov 2000 16:35:04 -0500 (EST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17042 for ; Sat, 25 Nov 2000 16:35:01 -0500 (EST) Received: from computer.ix.netcom.com (user-2ivek4r.dialup.mindspring.com [165.247.80.155]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id QAA06038 for ; Sat, 25 Nov 2000 16:34:58 -0500 (EST) Message-Id: <5.0.0.25.2.20001125162812.02cf7090@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 25 Nov 2000 16:29:45 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: Last Call: Dynamic Delegation Discovery System (DDDS) to Proposed Standard Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org FYI this last call affects RFC2915 which defines NAPTR Resource Records as used by RFC2916. >To: IETF-Announce: ; >Cc: urn-ietf@lists.netsol.com >From: The IESG >SUBJECT: Last Call: Dynamic Delegation Discovery System (DDDS) to > Proposed Standard >Reply-to: iesg@ietf.org >Date: Fri, 24 Nov 2000 19:55:16 -0500 >Sender: scoya@cnri.reston.va.us > > >The IESG has received a request from the Uniform Resource Names Working >Group to consider the following Internet-Drafts as Proposed Standards: > > o Dynamic Delegation Discovery System (DDDS) > > > o A DDDS Database Using The Domain Name System > > > o URI Resolution using the Dynamic Delegation Discovery System > > >Together, they will obsolete RFC2915 and RFC2168. > > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by December 8, 2000. > >Files can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-urn-ddds-03.txt >http://www.ietf.org/internet-drafts/draft-ietf-urn-dns-ddds-database-02.txt >http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-02.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 202.533.2811 Fax to EMail 815.333.1237 (Preferred for Fax) Cell : 314.503.0640 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sat Nov 25 16:59:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22899 for ; Sat, 25 Nov 2000 16:59:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18597; Sat, 25 Nov 2000 16:56:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18562 for ; Sat, 25 Nov 2000 16:56:27 -0500 (EST) Received: from exchange.chaos.com (exchange.chaos.com [206.5.17.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22191 for ; Sat, 25 Nov 2000 16:56:22 -0500 (EST) Received: from [206.5.17.17] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id pkcjaaaa for enum@ietf.org; Sat, 25 Nov 2000 16:56:24 -0500 Message-Id: <5.0.1.3.2.20001125162801.00ae3cd0@mail.netmagic.com> X-Sender: amr@mail.netmagic.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1.3 (Beta) Date: Sat, 25 Nov 2000 16:56:23 -0500 To: Richard Shockey , Dave Crocker From: "A.M.Rutkowski" Subject: Re: [Enum] draft-ietf-enum-e164-gstn-np-00.txt Cc: enum@ietf.org In-Reply-To: <5.0.0.25.2.20001125160322.02cf79e0@127.0.0.1> References: <5.0.1.3.2.20001125113856.00afff08@mail.netmagic.com> <5.0.1.4.2.20001125081342.032e5d20@joy.songbird.com> <5.0.1.3.2.20001125092648.00a764e0@mail.netmagic.com> <5.0.0.25.2.20001113203057.02868560@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Richard, >The purpose of the e164.arpa namespace is to be "athoritive" as opposed to >any other domain. There is certainly nothing stopping anyone from putting >number strings in FOO.NET or whatever for the purpose of defining some >private service or services. Consequently the administrative model for >determining correct holder of a E.164 number within e164.arpa must by >definition follow the appropriate national numbering plan. That is what >RFC2916 states and that is what the ITU has agreed to as well. Thanks for the clarification. Where in RFC2916 is there a specification that "the e164.arpa namespace is to be 'authoritive' as opposed to any other domain?" What ITU-T Study Group 2 agreed was that this subject was a national matter. Is there anything to prevent each of these national authorities from establishing a neutral authentication interface and maintaining a level playing field among competitive providers? Do you expect the FCC to begin a proceeding concerning their portion of 1.164.arpa.? Could they decide they don't want a regulated zone or that this is anticompetitive, and leave it to e164.com and others via an authoritative authentication mechanism? --amr _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sat Nov 25 20:13:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17503 for ; Sat, 25 Nov 2000 20:13:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21381; Sat, 25 Nov 2000 20:12:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21350 for ; Sat, 25 Nov 2000 20:12:01 -0500 (EST) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17281 for ; Sat, 25 Nov 2000 20:12:00 -0500 (EST) Received: from computer.ix.netcom.com (user-2ivel1j.dialup.mindspring.com [165.247.84.51]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id UAA25501; Sat, 25 Nov 2000 20:11:57 -0500 (EST) Message-Id: <5.0.0.25.2.20001125200125.028292f0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 25 Nov 2000 20:14:52 -0500 To: "A.M.Rutkowski" , Dave Crocker From: Richard Shockey Subject: Re: [Enum] draft-ietf-enum-e164-gstn-np-00.txt Cc: enum@ietf.org In-Reply-To: <5.0.1.3.2.20001125162801.00ae3cd0@mail.netmagic.com> References: <5.0.0.25.2.20001125160322.02cf79e0@127.0.0.1> <5.0.1.3.2.20001125113856.00afff08@mail.netmagic.com> <5.0.1.4.2.20001125081342.032e5d20@joy.songbird.com> <5.0.1.3.2.20001125092648.00a764e0@mail.netmagic.com> <5.0.0.25.2.20001113203057.02868560@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 04:56 PM 11/25/2000 -0500, A.M.Rutkowski wrote: >Hi Richard, > >>The purpose of the e164.arpa namespace is to be "athoritive" as opposed >>to any other domain. There is certainly nothing stopping anyone from >>putting number strings in FOO.NET or whatever for the purpose of defining >>some private service or services. Consequently the administrative model >>for determining correct holder of a E.164 number within e164.arpa must by >>definition follow the appropriate national numbering plan. That is what >>RFC2916 states and that is what the ITU has agreed to as well. > >Thanks for the clarification. > >Where in RFC2916 is there a specification that >"the e164.arpa namespace is to be 'authoritive' >as opposed to any other domain?" read the specification in RFC 2916..... 2. E.164 numbers and DNS The domain "e164.arpa" is being populated in order to provide the infrastructure in DNS for storage of E.164 numbers. In order to facilitate distributed operations, this domain is divided into subdomains. Holders of E.164 numbers which want to be listed in DNS should contact the appropriate zone administrator in order to be listed, by examining the SOA resource record associated with the zone, just like in normal DNS operations. What do'nt you understand? >What ITU-T Study Group 2 agreed was that this subject >was a national matter. Is there anything to prevent >each of these national authorities from establishing >a neutral authentication interface and maintaining a >level playing field among competitive providers? You have read the liaison statement it seems quite clear on what rights and responsibilities are here. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-itu-sg2-liaison-enum-00.txt >Do you expect the FCC to begin a proceeding concerning >their portion of 1.164.arpa.? Could they decide they >don't want a regulated zone or that this is anticompetitive, >and leave it to e164.com and others via an authoritative >authentication mechanism? I do not presume, nor would I dare to speak for the United States Government, the British, the French, the Swedish or South African government or any other sovereign nation state. I'm a poor simple IETF Work Group chair. >--amr > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 202.533.2811 Fax to EMail 815.333.1237 (Preferred for Fax) Cell : 314.503.0640 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sat Nov 25 20:34:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19904 for ; Sat, 25 Nov 2000 20:34:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21816; Sat, 25 Nov 2000 20:34:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21787 for ; Sat, 25 Nov 2000 20:34:26 -0500 (EST) Received: from exchange.chaos.com (exchange.chaos.com [206.5.17.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19869 for ; Sat, 25 Nov 2000 20:34:24 -0500 (EST) Received: from [206.5.17.17] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id dlcjaaaa for enum@ietf.org; Sat, 25 Nov 2000 20:34:19 -0500 Message-Id: <5.0.1.3.2.20001125202112.00ae63f8@mail.netmagic.com> X-Sender: amr@mail.netmagic.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1.3 (Beta) Date: Sat, 25 Nov 2000 20:34:18 -0500 To: Richard Shockey From: "A.M.Rutkowski" Subject: Re: [Enum] draft-ietf-enum-e164-gstn-np-00.txt Cc: enum@ietf.org In-Reply-To: <5.0.0.25.2.20001125200125.028292f0@127.0.0.1> References: <5.0.1.3.2.20001125162801.00ae3cd0@mail.netmagic.com> <5.0.0.25.2.20001125160322.02cf79e0@127.0.0.1> <5.0.1.3.2.20001125113856.00afff08@mail.netmagic.com> <5.0.1.4.2.20001125081342.032e5d20@joy.songbird.com> <5.0.1.3.2.20001125092648.00a764e0@mail.netmagic.com> <5.0.0.25.2.20001113203057.02868560@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 08:14 PM 11/25/2000, Richard Shockey wrote: >2. E.164 numbers and DNS The domain "e164.arpa" is being populated in >order to provide the infrastructure in DNS for storage of E.164 numbers. >In order to facilitate distributed operations, this domain is divided into >subdomains. Holders of E.164 numbers which want to be listed in DNS should >contact the appropriate zone administrator in order to be listed, by >examining the SOA resource record associated with the zone, just like in >normal DNS operations. > >What do'nt you understand? Hi Richard, Can end users or their level 2 providers choose to store their E.164 numbers exclusively in a zone other than e164.arpa on fair and equal basis, and can that zone be regarded as authoritative for the number? It's called competition. --amr _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sun Nov 26 02:34:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16635 for ; Sun, 26 Nov 2000 02:34:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02255; Sun, 26 Nov 2000 02:33:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02227 for ; Sun, 26 Nov 2000 02:33:13 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15863 for ; Sun, 26 Nov 2000 02:33:12 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id XAA13851; Sat, 25 Nov 2000 23:33:06 -0800 Message-Id: <5.0.1.4.2.20001125171709.00ac5380@joy.songbird.com> X-Sender: dhc@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Sat, 25 Nov 2000 23:26:49 -0800 To: "A.M.Rutkowski" From: Dave Crocker Subject: Re: [Enum] draft-ietf-enum-e164-gstn-np-00.txt Cc: enum@ietf.org In-Reply-To: <5.0.1.3.2.20001125113856.00afff08@mail.netmagic.com> References: <5.0.1.4.2.20001125081342.032e5d20@joy.songbird.com> <5.0.1.3.2.20001125092648.00a764e0@mail.netmagic.com> <5.0.0.25.2.20001113203057.02868560@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11:50 AM 11/25/00 -0500, A.M.Rutkowski wrote: However, the problem of authenticating the a user's use to an >E.164 number in 1.e164.arpa, 1.e164.com, etc, is separable (and >should be separate) from the matter of who administers the zone. Exactly my point. The agency doing the initial assignment -- eg, a local phone company -- is typically not going to be appropriate for maintaining the assigned record, since the record is likely to contain information pertaining to the local phone company's competitors. That's why a neutral third-party is appropriate for the maintenance function, distinct from the initial assignment function. At 08:34 PM 11/25/00 -0500, A.M.Rutkowski wrote: >Can end users or their level 2 providers choose to store their E.164 >numbers exclusively in a zone other than e164.arpa on fair and equal >basis, and can that zone be regarded as authoritative for the number? Of course they can, just as they can register domain names independent of the ICANN/IANA root. The benefit of such independence is dubious, at best, but Internet standards are for fostering interoperability, not preventing silliness. >It's called competition. That's fine. If you wish to invent and administer an independent numbering plan for telephony you are free to do so. Best of luck. d/ ps. Perhaps you have something different in mind? If so, please clarify. Your original note protested statements of ownership that were not made and protested 'authority' over number assignments, as if multiple assignments of the same number would be viable. No doubt you meant something insightful and the confusion was just in your choice of words. =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sun Nov 26 08:41:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01210 for ; Sun, 26 Nov 2000 08:41:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05259; Sun, 26 Nov 2000 08:40:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05230 for ; Sun, 26 Nov 2000 08:40:01 -0500 (EST) Received: from exchange.chaos.com (exchange.chaos.com [206.5.17.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00754 for ; Sun, 26 Nov 2000 08:39:58 -0500 (EST) Received: from [206.5.17.17] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id smcjaaaa for enum@ietf.org; Sun, 26 Nov 2000 08:39:54 -0500 Message-Id: <5.0.1.3.2.20001126083002.00acb818@mail.netmagic.com> X-Sender: amr@mail.netmagic.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1.3 (Beta) Date: Sun, 26 Nov 2000 08:39:53 -0500 To: Dave Crocker From: "A.M.Rutkowski" Subject: Re: [Enum] draft-ietf-enum-e164-gstn-np-00.txt Cc: enum@ietf.org In-Reply-To: <5.0.1.4.2.20001125171709.00ac5380@joy.songbird.com> References: <5.0.1.3.2.20001125113856.00afff08@mail.netmagic.com> <5.0.1.4.2.20001125081342.032e5d20@joy.songbird.com> <5.0.1.3.2.20001125092648.00a764e0@mail.netmagic.com> <5.0.0.25.2.20001113203057.02868560@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >However, the problem of authenticating the a user's use to an >>E.164 number in 1.e164.arpa, 1.e164.com, etc, is separable (and >>should be separate) from the matter of who administers the zone. > > Exactly my point. The agency doing the initial assignment -- eg, > a local phone company -- is typically not going to be appropriate for > maintaining the assigned record, since the record is likely to contain > information pertaining to the local phone company's competitors. If I'm not mistaken, unless the number has been ported, the phone company is going to be the only entity that has the assignment record. It's relatively simple for them to provide an authentication service - they already do it pursuant to the 1986 Computer III requirements. >That's why a neutral third-party is appropriate for the maintenance >function, distinct from the initial assignment function. A single monolithic North American monopoly ENUM Level 1 maintainer doesn't seem appropriate, IMHO. --amr _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sun Nov 26 10:19:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27781 for ; Sun, 26 Nov 2000 10:19:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05965; Sun, 26 Nov 2000 10:17:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05934 for ; Sun, 26 Nov 2000 10:17:40 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27247 for ; Sun, 26 Nov 2000 10:17:40 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id HAA18407; Sun, 26 Nov 2000 07:17:08 -0800 Message-Id: <5.0.1.4.2.20001126071734.02bef730@joy.songbird.com> X-Sender: dhc@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Sun, 26 Nov 2000 07:18:17 -0800 To: "A.M.Rutkowski" From: Dave Crocker Subject: Re: [Enum] draft-ietf-enum-e164-gstn-np-00.txt Cc: enum@ietf.org In-Reply-To: <5.0.1.3.2.20001126083002.00acb818@mail.netmagic.com> References: <5.0.1.4.2.20001125171709.00ac5380@joy.songbird.com> <5.0.1.3.2.20001125113856.00afff08@mail.netmagic.com> <5.0.1.4.2.20001125081342.032e5d20@joy.songbird.com> <5.0.1.3.2.20001125092648.00a764e0@mail.netmagic.com> <5.0.0.25.2.20001113203057.02868560@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 08:39 AM 11/26/00 -0500, A.M.Rutkowski wrote: >>That's why a neutral third-party is appropriate for the maintenance >>function, distinct from the initial assignment function. > >A single monolithic North American monopoly ENUM Level 1 maintainer >doesn't seem appropriate, IMHO. Absolutely correct. We should have a different maintainer for each digit. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sun Nov 26 11:42:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20610 for ; Sun, 26 Nov 2000 11:42:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06659; Sun, 26 Nov 2000 11:40:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06631 for ; Sun, 26 Nov 2000 11:40:33 -0500 (EST) Received: from roam.psg.com ([206.163.43.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20099 for ; Sun, 26 Nov 2000 11:40:32 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 1404rg-0002FX-00; Sun, 26 Nov 2000 08:41:20 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dave Crocker Cc: enum@ietf.org Subject: Re: [Enum] draft-ietf-enum-e164-gstn-np-00.txt References: <5.0.1.4.2.20001125081342.032e5d20@joy.songbird.com> <5.0.1.3.2.20001125092648.00a764e0@mail.netmagic.com> <5.0.0.25.2.20001113203057.02868560@127.0.0.1> <5.0.1.4.2.20001125171709.00ac5380@joy.songbird.com> Message-Id: Date: Sun, 26 Nov 2000 08:41:20 -0800 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit you may want to review the archive of this mailing list randy _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sun Nov 26 11:54:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24700 for ; Sun, 26 Nov 2000 11:54:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06804; Sun, 26 Nov 2000 11:48:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06777 for ; Sun, 26 Nov 2000 11:48:25 -0500 (EST) Received: from roam.psg.com ([206.163.43.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22543 for ; Sun, 26 Nov 2000 11:48:18 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 1404xy-0002J6-00; Sun, 26 Nov 2000 08:47:50 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dave Crocker Cc: "A.M.Rutkowski" , enum@ietf.org Subject: Re: [Enum] draft-ietf-enum-e164-gstn-np-00.txt References: <5.0.1.4.2.20001125171709.00ac5380@joy.songbird.com> <5.0.1.3.2.20001125113856.00afff08@mail.netmagic.com> <5.0.1.4.2.20001125081342.032e5d20@joy.songbird.com> <5.0.1.3.2.20001125092648.00a764e0@mail.netmagic.com> <5.0.0.25.2.20001113203057.02868560@127.0.0.1> <5.0.1.4.2.20001126071734.02bef730@joy.songbird.com> Message-Id: Date: Sun, 26 Nov 2000 08:47:50 -0800 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit >> A single monolithic North American monopoly ENUM Level 1 maintainer >> doesn't seem appropriate, IMHO. > We should have a different maintainer for each digit. you folk may want to look into dns delegation and the difference between admin and tech poc. as each itu e.164 delegatee will determine the policies for their numbering system, you may want to take the conversation of the politics of power/greed games in the +1 space to the wherever the na numbering plan folk congregate, and that ain't here. randy _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sun Nov 26 13:18:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24978 for ; Sun, 26 Nov 2000 13:18:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07964; Sun, 26 Nov 2000 13:16:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07939 for ; Sun, 26 Nov 2000 13:16:38 -0500 (EST) Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net [38.202.36.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24484 for ; Sun, 26 Nov 2000 13:16:36 -0500 (EST) Received: from orion ([64.6.163.33]) by hvmta03-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001126181607.ETVP24415.hvmta03-stg@orion>; Sun, 26 Nov 2000 13:16:07 -0500 Reply-To: From: "Robert H. Walter - CTO, VP Development and Operations" To: "Dave Crocker" , "A.M.Rutkowski" Cc: Subject: RE: [Enum] draft-ietf-enum-e164-gstn-np-00.txt Date: Sun, 26 Nov 2000 13:14:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.0.1.4.2.20001126071734.02bef730@joy.songbird.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit At 10:18 AM 11/26/00 -0500, Dave Crocker wrote: >>>That's why a neutral third-party is appropriate for the maintenance >>function, distinct from the initial assignment function. >> >>A single monolithic North American monopoly ENUM Level 1 maintainer >>doesn't seem appropriate, IMHO. > >Absolutely correct. > >We should have a different maintainer for each digit. With all due respect, partitioning and delegating the E.164 name space across different maintainers at each digit raises a serious absurdity flag. It is one thing to speak of political and bureaucratic theory, it is another to actually operate a realistic, reliable, secure and scalable tier-1 ENUM registry service. Ignoring the more complex aspects of running a tier-1 ENUM registry (registration, conflict resolution and whois services) let us assume there ARE different maintainers for each digit in the E.164 name space. An initial query will require approximately 12+ DNS delegations to be processed. This means 12+ round-trip hops across various Internet segments. Need I say more? Sincerely, Bob _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sun Nov 26 14:23:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19483 for ; Sun, 26 Nov 2000 14:23:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09213; Sun, 26 Nov 2000 14:21:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09185 for ; Sun, 26 Nov 2000 14:21:38 -0500 (EST) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18816 for ; Sun, 26 Nov 2000 14:21:36 -0500 (EST) Received: from computer.ix.netcom.com (user-2ivekj2.dialup.mindspring.com [165.247.82.98]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id OAA03994 for ; Sun, 26 Nov 2000 14:21:37 -0500 (EST) Message-Id: <5.0.0.25.2.20001126135230.02bd3870@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 26 Nov 2000 13:53:22 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Subject: I-D ACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This draft made the Announce list but was not cross posted... To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt Date: Wed, 22 Nov 2000 06:13:04 -0500 Sender: nsyracus@cnri.reston.va.us A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Tier-1 ENUM System Roles and Responsibilities Author(s) : D. Ranalli, D. Peek, R. Walters Filename : draft-ranalli-peek-walter-enum-t1roles-00.txt Pages : 9 Date : 21-Nov-00 This document describes the actors in a global Tier-1 ENUM System and the roles and responsibilities that each of the actors fulfills. In this context, a 'Tier-1 ENUM System' refers to a holistic system for registering E.164 telephone numbers in a DNS top-level domain. The population of NAPTR records with URI's in a Tier-2 ENUM System as described in RFC 2916 [4] is not discussed in this draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ranalli-peek-walter-enum-t1roles-00.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 202.533.2811 Fax to EMail 815.333.1237 (Preferred for Fax) Cell : 314.503.0640 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sun Nov 26 15:00:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01975 for ; Sun, 26 Nov 2000 15:00:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10027; Sun, 26 Nov 2000 14:58:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10000 for ; Sun, 26 Nov 2000 14:58:43 -0500 (EST) Received: from hvmta02-stg.us.psimail.psi.net (hvmta02-ext.us.psimail.psi.net [38.202.36.30]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01613 for ; Sun, 26 Nov 2000 14:58:40 -0500 (EST) Received: from orion ([64.6.163.33]) by hvmta02-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001126195811.VLIG11307.hvmta02-stg@orion>; Sun, 26 Nov 2000 14:58:11 -0500 Reply-To: From: "Robert H. Walter - CTO, VP Development and Operations" To: "Dave Crocker" , "A.M.Rutkowski" Cc: Subject: RE: [Enum] draft-ietf-enum-e164-gstn-np-00.txt Date: Sun, 26 Nov 2000 14:56:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.0.1.4.2.20001125081342.032e5d20@joy.songbird.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit At 02:44 PM 11/25/00 +0100, David Crocker wrote: > From the ICANN wg-c mailing list: > >At 02:44 PM 11/25/00 +0100, Harald Alvestrand wrote: >>I believe that letting customers claim rights to a number in e164.com when >>they have lost all rights to the same number in the real telephone number >>space will lead to much confusion and no gain. >>The telephone number space is the reality, and all spaces that mirror it, >>whether e164.com or e164.arpa, are its shadows (to misuse Platon's imagery). >>Having shadows that linger when the reality is gone benefits nobody. The premise of Harald Alvestrands statement is incorrect... A customer that loses all rights to a number in the "real telephone number space" implicitly loses all rights to the associated E.164 domain name registered in e164.com. This is a fundamental administrative principle for tier-1 ENUM registry operated under e164.com. As Harald accurately points out, "The telephone number space is the reality". Bob -----Original Message----- From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of Dave Crocker Sent: Saturday, November 25, 2000 11:26 AM To: A.M.Rutkowski Cc: enum@ietf.org Subject: Re: [Enum] draft-ietf-enum-e164-gstn-np-00.txt At 10:03 AM 11/25/00 -0500, A.M.Rutkowski wrote: >Compare this to the unfettered use of E.164 numbers for >more than 8 years under the tpc.int domain pursuant to >RFCs 1528-1530 Let's be very clear about the nature of tpc.int experience: It has never been more than a minuscule activity, excellent as an experiment to show proof of concept for a basic mapping mechanism. It offers NO insight into Internet-scale administration and operation, particularly with regard to maintaining synchronization between "telephone" assignment of numbers and e.164.arpa assignment. It also offers no insight into the more general e164.arpa goal of supporting a range of different services, through multiple DNS RR records under a given 3164.arpa number. From the ICANN wg-c mailing list: At 02:44 PM 11/25/00 +0100, Harald Alvestrand wrote: >I believe that letting customers claim rights to a number in e164.com when >they have lost all rights to the same number in the real telephone number >space will lead to much confusion and no gain. >The telephone number space is the reality, and all spaces that mirror it, >whether e164.com or e164.arpa, are its shadows (to misuse Platon's imagery). >Having shadows that linger when the reality is gone benefits nobody. Internet-scale administration and operation must deal with transitions, such as reassignment of a telephone number and, therefore, either re-assignment or resulting conflict of the corresponding e164.arpa number. This requirement means that the company assigning telephone numbers may well have different interests from the USER (assignee) of the number. Indeed the assignee might have entries in their e164.arpa for services that compete with the company assignign the telephone number. An independent third-party administrator suffers no such potential conflict. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sun Nov 26 15:17:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06702 for ; Sun, 26 Nov 2000 15:17:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10630; Sun, 26 Nov 2000 15:16:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10600 for ; Sun, 26 Nov 2000 15:16:09 -0500 (EST) Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06255 for ; Sun, 26 Nov 2000 15:16:06 -0500 (EST) Received: from worldnet ([12.88.172.104]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20001126201538.OWDI5130.mtiwmhc22.worldnet.att.net@worldnet>; Sun, 26 Nov 2000 20:15:38 +0000 From: "Judith Oppenheimer" To: "'A.M.Rutkowski'" , "'Dave Crocker'" Cc: Subject: RE: [Enum] draft-ietf-enum-e164-gstn-np-00.txt Date: Sun, 26 Nov 2000 15:13:11 -0500 Message-ID: <001701c057e5$4dc29920$68ac580c@att.net.icbtollfree.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <5.0.1.3.2.20001126083002.00acb818@mail.netmagic.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Not so, at least in the case of toll free numbers; not all carriers are RespOrgs, and not all RespOrgs are carriers. Judith Judith Oppenheimer, 212 684-7210, 1 800 The Expert Publisher, http://www.ICBTollFreeNews.com President, http://www.1800TheExpert.com FREE 800/Domain Classifieds, http://ICBclassifieds.com Domain Name & 800 News, Intelligence, Analysis > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > A.M.Rutkowski > Sent: Sunday, November 26, 2000 8:40 AM > To: Dave Crocker > Cc: enum@ietf.org > Subject: Re: [Enum] draft-ietf-enum-e164-gstn-np-00.txt > > > > >However, the problem of authenticating the a user's use to an > >>E.164 number in 1.e164.arpa, 1.e164.com, etc, is separable (and > >>should be separate) from the matter of who administers the zone. > > > > Exactly my point. The agency doing the initial > assignment -- eg, > > a local phone company -- is typically not going to be > appropriate for > > maintaining the assigned record, since the record is likely > to contain > > information pertaining to the local phone company's competitors. > > If I'm not mistaken, unless the number has been ported, the > phone company is going to be the only entity that has > the assignment record. It's relatively simple for them to > provide an authentication service - they already do it > pursuant to the 1986 Computer III requirements. > > > >That's why a neutral third-party is appropriate for the maintenance > >function, distinct from the initial assignment function. > > A single monolithic North American monopoly ENUM Level 1 maintainer > doesn't seem appropriate, IMHO. > > --amr > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sun Nov 26 19:23:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05884 for ; Sun, 26 Nov 2000 19:23:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12796; Sun, 26 Nov 2000 19:15:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12765 for ; Sun, 26 Nov 2000 19:15:40 -0500 (EST) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04113 for ; Sun, 26 Nov 2000 19:15:39 -0500 (EST) Received: from computer.ix.netcom.com (user-2iveksu.dialup.mindspring.com [165.247.83.158]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id TAA11045; Sun, 26 Nov 2000 19:15:24 -0500 (EST) Message-Id: <5.0.0.25.2.20001126140634.02bdb130@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 26 Nov 2000 19:18:15 -0500 To: "A.M.Rutkowski" , Dave Crocker From: Richard Shockey Subject: Re: [Enum] draft-ietf-enum-e164-gstn-np-00.txt Cc: enum@ietf.org In-Reply-To: <5.0.1.3.2.20001126083002.00acb818@mail.netmagic.com> References: <5.0.1.4.2.20001125171709.00ac5380@joy.songbird.com> <5.0.1.3.2.20001125113856.00afff08@mail.netmagic.com> <5.0.1.4.2.20001125081342.032e5d20@joy.songbird.com> <5.0.1.3.2.20001125092648.00a764e0@mail.netmagic.com> <5.0.0.25.2.20001113203057.02868560@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >>That's why a neutral third-party is appropriate for the maintenance >>function, distinct from the initial assignment function. > >A single monolithic North American monopoly ENUM Level 1 maintainer >doesn't seem appropriate, IMHO. Can we get off this class of subject please. This is degenerating into a purely political debate that is a bit out of scope here. Discussions of what is or is not appropriate in the United States are best left to other forums...what is appropriate are discussions of the general technical requirements of Tier 1 Tier 2 entities as it might apply in the general case. Lets not forget that the real issue is the not who is or is not a Tier 1 entity ..that is a discussion for nation-states to decide within the geographic E.164 plan. It is who is or is not the holder of NAPTR resource records for a e164 telephone number in e164.arpa. From time to time I've asked the list to consider some of these technical questions as it might relate to the delegation issue within DNS itself CNAME ..PTR etc. But I've not seen sufficient discussion to suggest that consensus exists. Plus we can assume that there needs to be some validation testing of RFC2916 as part of the IETF standards process here and it might be useful to define some operational metrics to look at etc. Ongoing technical discussions are always welcome. ################################## Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 202.533.2811 Fax to EMail 815.333.1237 (Preferred for Fax) Cell : 314.503.0640 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sun Nov 26 19:37:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08958 for ; Sun, 26 Nov 2000 19:37:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13180; Sun, 26 Nov 2000 19:36:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13153 for ; Sun, 26 Nov 2000 19:36:27 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08641 for ; Sun, 26 Nov 2000 19:36:26 -0500 (EST) Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id QAA24833; Sun, 26 Nov 2000 16:35:53 -0800 Message-Id: <5.0.1.4.2.20001126163511.02bffd50@joy.songbird.com> X-Sender: dhc@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Sun, 26 Nov 2000 16:36:52 -0800 To: From: Dave Crocker Subject: RE: [Enum] draft-ietf-enum-e164-gstn-np-00.txt Cc: "A.M.Rutkowski" , In-Reply-To: References: <5.0.1.4.2.20001126071734.02bef730@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 01:14 PM 11/26/00 -0500, Robert H. Walter - CTO, VP Development and Operations wrote: >With all due respect, partitioning and delegating the E.164 name >space across different maintainers at each digit raises a serious >absurdity flag. That was the goal. Please forgive my excessive subtlety. I was trying to respond to a line of query in a manner that took it to its logical conclusion. d/ ps. And, yes, now we should return to our regularly scheduled technical programming. =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sun Nov 26 21:13:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04389 for ; Sun, 26 Nov 2000 21:13:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14100; Sun, 26 Nov 2000 21:11:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14069 for ; Sun, 26 Nov 2000 21:11:26 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03892 for ; Sun, 26 Nov 2000 21:11:24 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 140Dl6-0008cB-00; Sun, 26 Nov 2000 18:11:08 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dave Crocker Cc: , "A.M.Rutkowski" , Subject: RE: [Enum] draft-ietf-enum-e164-gstn-np-00.txt References: <5.0.1.4.2.20001126071734.02bef730@joy.songbird.com> <5.0.1.4.2.20001126163511.02bffd50@joy.songbird.com> Message-Id: Date: Sun, 26 Nov 2000 18:11:08 -0800 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > Please forgive my excessive subtlety. I was trying to respond to a line > of query in a manner that took it to its logical conclusion. and please excuse my resposes being to: you. your mail filter seems to let crazies and sickos through which mine does not. randy _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Nov 27 12:57:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03936 for ; Mon, 27 Nov 2000 12:57:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04674; Mon, 27 Nov 2000 12:56:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04643 for ; Mon, 27 Nov 2000 12:56:43 -0500 (EST) Received: from heron.verisign.com ([216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03570 for ; Mon, 27 Nov 2000 12:56:44 -0500 (EST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA24151 for ; Mon, 27 Nov 2000 12:46:03 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 12:53:18 -0500 Message-ID: From: "Conley, Pat" To: enum@ietf.org Date: Mon, 27 Nov 2000 12:53:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] RE: draft-ranalli-peek-walter-enum-t1roles-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Doug, I particularly like this document in the way that it clearly separates out the various functional roles that exist in an ENUM implementation. However, I suggest that one of the responsibilities that you assign to the registrant may be mis-placed. Is it reasonable to expect that a registrant will "notify the Registrar of dialing plan changes". Might this responsibility be more efficiently ascribed to the TSP... similar, if not the same as the service termination? pat ----------------------------------------------------- Patrick J. Conley Director of Business Development Telecommunications Sector VeriSign Global Registry Services +1 703 887-3716 pconley@verisign.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Nov 27 12:57:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03963 for ; Mon, 27 Nov 2000 12:57:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04477; Mon, 27 Nov 2000 12:51:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04450 for ; Mon, 27 Nov 2000 12:51:04 -0500 (EST) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01497; Mon, 27 Nov 2000 12:51:03 -0500 (EST) Received: by dnspri.npac.com; id LAA10180; Mon, 27 Nov 2000 11:50:55 -0600 (CST) Received: from unknown(192.168.20.106) by dnspri.npac.com via smap (V5.0) id xma009992; Mon, 27 Nov 00 11:50:35 -0600 Message-Id: <5.0.0.25.2.20001122122703.0263eeb0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 27 Nov 2000 11:53:17 -0500 To: enum@ietf.org From: Richard Shockey Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] FINAL AGENDA.... IETF 49 ENUM WG Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org FINAL AGENDA: we are meeting on Thursday afternoon for 2 1/2 hours. 1. Agenda Bashing (5 min) 2. Thanks to our former co-chair Scott Petrak ( 5 min) 3. ENUM Administration in the United States - Penn Pfautz - James Yu (20 min) http://www.ietf.org/internet-drafts/draft-pfautz-yu-enum-adm-00.txt 4. ENUM - T1 Roles-00.txt (10-15 Min) - Doug Ranali http://www.ietf.org/internet-drafts/draft-ranalli-peek-walter-enum-t1roles-00.txt 5. ENUM Call Flows - Steve Lind (15 Min) http://www.ietf.org/internet-drafts/draft-lind-enum-callflows-01.txt 6. ENUM Operations - Greg Vardureuil (20 min + ) I'm putting this toward the end since I would like us to read very carefully the document here and be prepared to discuss some of the issue involved in the Delegation matter. I've asked the list to discuss some of the pro's and con's of the DNS delagation alternatives and we have not seen a full discussion as of yet. Perhaps we can take the opportunity to move to consensus. http://www.ietf.org/internet-drafts/draft-ietf-enum-operation-01.txt 7. Further Updates on IETF-ITU discussions coming out of ITU Study Group 2 meetings in Berlin. ( Chair - Others ) 10 min + Preview upcoming SG2 work... http://www.ietf.org/internet-drafts/draft-itu-sg2-liason-enum-01.txt 8. WG next steps . ENUM MIB? 10 min + 9. Open Discussion Additional Reference Documents: These have been submitted but will not be presented at the meeting. Number Portability in the GSTN http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-gstn-np-00.txt Number Portability in the United States http://www.ietf.org/internet-drafts/draft-foster-e164-gstn-npusa-00.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 202.533.2811 Fax to EMail 815.333.1237 (Preferred for Fax) Cell : 314.503.0640 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Nov 27 17:22:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29070 for ; Mon, 27 Nov 2000 17:22:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12118; Mon, 27 Nov 2000 17:21:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12090 for ; Mon, 27 Nov 2000 17:21:29 -0500 (EST) Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28803 for ; Mon, 27 Nov 2000 17:21:28 -0500 (EST) Received: from worldnet ([12.88.171.220]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20001127222058.BISP5130.mtiwmhc22.worldnet.att.net@worldnet> for ; Mon, 27 Nov 2000 22:20:58 +0000 From: "Judith Oppenheimer" To: Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt Date: Mon, 27 Nov 2000 17:18:30 -0500 Message-ID: <005501c058bf$f9a1c420$42ac580c@att.net.icbtollfree.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.0.0.25.2.20001126135230.02bd3870@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Is this system meant to accomodate U.S. toll free numbers? Judith Judith Oppenheimer, 212 684-7210, 1 800 The Expert Publisher, http://www.ICBTollFreeNews.com President, http://www.1800TheExpert.com FREE 800/Domain Classifieds, http://ICBclassifieds.com Domain Name & 800 News, Intelligence, Analysis > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > Richard Shockey > Sent: Sunday, November 26, 2000 1:53 PM > To: enum@ietf.org > Subject: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > This draft made the Announce list but was not cross posted... > > To: IETF-Announce: ; > From: Internet-Drafts@ietf.org > Reply-to: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > Date: Wed, 22 Nov 2000 06:13:04 -0500 > Sender: nsyracus@cnri.reston.va.us > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Tier-1 ENUM System Roles and > Responsibilities > Author(s) : D. Ranalli, D. Peek, R. Walters > Filename : > draft-ranalli-peek-walter-enum-t1roles-00.txt > Pages : 9 > Date : 21-Nov-00 > > This document describes the actors in a global Tier-1 ENUM System > and the roles and responsibilities that each of the actors fulfills. > In this context, a 'Tier-1 ENUM System' refers to a holistic system > for registering E.164 telephone numbers in a DNS top-level domain. > The population of NAPTR records with URI's in a Tier-2 ENUM System > as described in RFC 2916 [4] is not discussed in this draft. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ranalli-peek-walter- enum-t1roles-00.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 202.533.2811 Fax to EMail 815.333.1237 (Preferred for Fax) Cell : 314.503.0640 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Nov 27 17:22:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29204 for ; Mon, 27 Nov 2000 17:22:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12079; Mon, 27 Nov 2000 17:21:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12050 for ; Mon, 27 Nov 2000 17:21:23 -0500 (EST) Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28669 for ; Mon, 27 Nov 2000 17:21:09 -0500 (EST) Received: from dranalli ([38.136.73.90]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001127222029.PRMK1216.hvmta01-stg@dranalli> for ; Mon, 27 Nov 2000 17:20:29 -0500 Message-ID: <019801c058bf$ccf4ffa0$5a498826@netnumber.com> Reply-To: "Douglas Ranalli" From: "Douglas Ranalli" To: Subject: Re: [Enum] RE: draft-ranalli-peek-walter-enum-t1roles-00.txt Date: Mon, 27 Nov 2000 17:17:14 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0195_01C05895.E2F4F690" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0195_01C05895.E2F4F690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pat, Thank you for your comment regarding the role of TSP's in dialing plan changes. A key design principle behind our proposed Tier-1 ENUM System = has been to "actively embrace" TSP's as primary players in the system = without mandating their participation. You made the suggestion to allow TSP's to make "Dialing Plan Updates" = the same way as the draft allows TSP's to make "Service Termination = Updates". Dialing Plan changes are indeed a specialized case of service = termination. The TSP is effectively terminating service on the existing = number and replacing the service with a new number. Thank you for this = suggestion, I'll make the change in the next version of the draft that = will be published immediately following the December IETF meeting. - TSP's to be given the "authority" (but not the responsibility) to = initiate dialing plan changes in the Tier-1 ENUM service. - Registrars to be responsible for validating TSP control over the e164 number(s) being changed. - Registry to be responsible for supporting a "dialing plan update" = feature under the Registry "Registration Service". If I understood your comment correctly, you also suggest removing the dialing plan update "responsibility" from the Registrant. The TSP is = both well positioned and likely to handle dialing plan changes in the = ENUM System but what happens if the TSP doesn't "choose" to participate? = If the TSP does not "choose" to participate in the ENUM System then the = Subscriber is ultimately "responsible" for updating the dialing plan = change. I advise leaving the ultimate responsibility with the = Registrant for this reason. Please respond back with further thoughts and thank you again for your feedback. Regards, Doug Douglas J. Ranalli Founder, Chief Strategy Officer NetNumber dranalli@netnumber.com 978-454-4210 ext 22 > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of = Conley, Pat > Sent: Monday, November 27, 2000 12:53 PM > To: enum@ietf.org > Subject: [Enum] RE: draft-ranalli-peek-walter-enum-t1roles-00.txt > > > Doug, > > I particularly like this document in the way that it > clearly separates out the various functional roles > that exist in an ENUM implementation. > > However, I suggest that one of the responsibilities > that you assign to the registrant may be mis-placed. > > Is it reasonable to expect that a registrant will > "notify the Registrar of dialing plan changes". Might > this responsibility be more efficiently ascribed to > the TSP... similar, if not the same as the service > termination? > > pat > > ----------------------------------------------------- > > Patrick J. Conley > Director of Business Development > Telecommunications Sector > VeriSign Global Registry Services > +1 703 887-3716 > pconley@verisign.com > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum ------=_NextPart_000_0195_01C05895.E2F4F690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Pat,

Thank you for your comment = regarding=20 the role of TSP's in dialing plan
changes.  A key design = principle=20 behind our proposed Tier-1 ENUM System has been to "actively embrace" = TSP's as=20 primary players in the system without mandating their = participation.

You=20 made the suggestion to allow TSP's to make "Dialing Plan Updates" the = same way=20 as the draft allows TSP's to make "Service Termination Updates".  = Dialing=20 Plan changes are indeed a specialized case of service termination.  = The TSP=20 is effectively terminating service on the existing number and replacing = the=20 service with a new number.  Thank you for this suggestion, I'll = make the=20 change in the next version of the draft that will be published = immediately=20 following the December IETF meeting.

- TSP's to be given the = "authority"=20 (but not the responsibility) to initiate
dialing plan changes in the = Tier-1=20 ENUM service.

- Registrars to be responsible for validating TSP = control=20 over the e164
number(s) being changed.

- Registry to be = responsible=20 for supporting a "dialing plan update" feature under the Registry = "Registration=20 Service".

If I understood your comment correctly, you also = suggest=20 removing the
dialing plan update "responsibility" from the=20 Registrant.  The TSP is both well positioned and likely to = handle=20 dialing plan changes in the ENUM System but what happens if the TSP = doesn't=20 "choose" to participate?  If the TSP does not "choose" to = participate in=20 the ENUM System then the Subscriber is ultimately "responsible" for = updating the=20 dialing plan change.  I advise leaving the ultimate responsibility = with the=20 Registrant for this reason.

Please respond back with further = thoughts and=20 thank you again for=20 your
feedback.

Regards,

Doug
Douglas J. Ranalli
Founder, Chief Strategy = Officer
NetNumber
dranalli@netnumber.com<= /DIV>
978-454-4210 ext 22

> -----Original = Message-----
> From:=20 enum-admin@ietf.org [mailto:enum-admin@ietf.org]On = Behalf=20 Of Conley, Pat
> Sent: Monday, November 27, 2000 12:53 = PM
> To:=20 enum@ietf.org
> Subject: = [Enum] RE:=20 draft-ranalli-peek-walter-enum-t1roles-00.txt
>
>
>=20 Doug,
>
> I particularly like this document in the way that=20 it
> clearly separates out the various functional roles
> = that exist=20 in an ENUM implementation.
>
> However, I suggest that one = of the=20 responsibilities
> that you assign to the registrant may be=20 mis-placed.
>
> Is it reasonable to expect that a registrant = will
> "notify the Registrar of dialing plan changes".  = Might
>=20 this responsibility be more efficiently ascribed to
> the TSP... = similar,=20 if not the same as the service
> termination?
>
>=20 pat
>
>=20 -----------------------------------------------------
>
> = Patrick J.=20 Conley
> Director of Business Development
> = Telecommunications=20 Sector
> VeriSign Global Registry Services
> +1 703 = 887-3716
>=20 pconley@verisign.com
>
= >=20 _______________________________________________
> enum mailing=20 list
> enum@ietf.org
> = http://www1.ietf.org/= mailman/listinfo/enum
------=_NextPart_000_0195_01C05895.E2F4F690-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Nov 27 17:51:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07852 for ; Mon, 27 Nov 2000 17:51:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13965; Mon, 27 Nov 2000 17:50:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13936 for ; Mon, 27 Nov 2000 17:50:47 -0500 (EST) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07731 for ; Mon, 27 Nov 2000 17:50:46 -0500 (EST) Received: by dnspri.npac.com; id QAA20430; Mon, 27 Nov 2000 16:50:47 -0600 (CST) Received: from unknown(192.168.20.106) by dnspri.npac.com via smap (V5.0) id xma020406; Mon, 27 Nov 00 16:50:42 -0600 Message-Id: <5.0.0.25.2.20001127174818.027601c0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 27 Nov 2000 17:51:30 -0500 To: "Judith Oppenheimer" From: Richard Shockey Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt Cc: enum@ietf.org In-Reply-To: <005501c058bf$f9a1c420$42ac580c@att.net.icbtollfree.com> References: <5.0.0.25.2.20001126135230.02bd3870@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 05:18 PM 11/27/2000 -0500, you wrote: >Is this system meant to accomodate U.S. toll free numbers? > >Judith Any national ENUM system has to accommodate toll free numbers. 800 - 877 etc, numbers in the US are E.164 numbers. Its just that the authority for authorization ( record holder ) is different. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Nov 27 18:00:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10369 for ; Mon, 27 Nov 2000 18:00:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14403; Mon, 27 Nov 2000 17:59:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14376 for ; Mon, 27 Nov 2000 17:59:55 -0500 (EST) Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10115 for ; Mon, 27 Nov 2000 17:59:52 -0500 (EST) Received: from worldnet ([12.88.171.220]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20001127225923.BUXE5130.mtiwmhc22.worldnet.att.net@worldnet>; Mon, 27 Nov 2000 22:59:23 +0000 From: "Judith Oppenheimer" To: "'Richard Shockey'" Cc: Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt Date: Mon, 27 Nov 2000 17:56:54 -0500 Message-ID: <006101c058c5$57188440$42ac580c@att.net.icbtollfree.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.0.0.25.2.20001127174818.027601c0@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit I do not see where this draft anticipates that the "service provider" for a toll free number may not be a TSP, but rather a so-called "RespOrg" (stands for Responsible Organization.) For that matter, the calls may not resolve to the end user subscriber either. One or more TSPs (programmed to be used at varying times of day for cheapest rates, for example) can simply be used as a provisioning tool, sending calls to one or multiple locations, none of which are the controlling party of the toll free number. Judith Judith Oppenheimer, 212 684-7210, 1 800 The Expert Publisher, http://www.ICBTollFreeNews.com President, http://www.1800TheExpert.com FREE 800/Domain Classifieds, http://ICBclassifieds.com Domain Name & 800 News, Intelligence, Analysis > -----Original Message----- > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > Sent: Monday, November 27, 2000 5:52 PM > To: Judith Oppenheimer > Cc: enum@ietf.org > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > At 05:18 PM 11/27/2000 -0500, you wrote: > >Is this system meant to accomodate U.S. toll free numbers? > > > >Judith > > Any national ENUM system has to accommodate toll free > numbers. 800 - 877 > etc, numbers in the US are E.164 numbers. Its just that the > authority for > authorization ( record holder ) is different. > > _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Nov 27 21:31:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29742 for ; Mon, 27 Nov 2000 21:31:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19502; Mon, 27 Nov 2000 21:31:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19471 for ; Mon, 27 Nov 2000 21:31:06 -0500 (EST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29585 for ; Mon, 27 Nov 2000 21:31:05 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id eAS2UYh10983; Mon, 27 Nov 2000 21:30:34 -0500 (EST) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id VAA03970; Mon, 27 Nov 2000 21:29:32 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Mon, 27 Nov 2000 21:30:33 -0500 Message-ID: <1B08859602C8D211B66F0000C0769CFA046A10B5@njc240po03.mt.att.com> From: "Pfautz, Penn L, NNAD" To: Judith Oppenheimer , "'Richard Shockey'" Cc: enum@ietf.org Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Date: Mon, 27 Nov 2000 21:30:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Judith: I agree that the toll-free case is more complex and proposed in my earlier I-D (draft-pfautz-na-enum-01.txt) that the ENUM record for the toll-free number be controlled by the RespOrg. I think the model proposed works if you view the RespOrg as End User or User Agent. The RespOrg can work with their chosen Service Resgistrar to change the NAPTR record as needed to point to different carriers as appropriate, but that is really outside of the ENUM protocol per se. In terms of call allocation features, this logic too will not reside in the DNS, but perhaps in some server that the NAPTR record would point to. (Some of this was discussed at the ITU working party meeting in Berlin in the context of international freephone). It's also important to remember that ENUM remains an optional functionality - carriers and users are not obligated to use it but can always complete calls through the PSTN. Penn Pfautz -----Original Message----- From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] Sent: Monday, November 27, 2000 5:57 PM To: 'Richard Shockey' Cc: enum@ietf.org Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt I do not see where this draft anticipates that the "service provider" for a toll free number may not be a TSP, but rather a so-called "RespOrg" (stands for Responsible Organization.) For that matter, the calls may not resolve to the end user subscriber either. One or more TSPs (programmed to be used at varying times of day for cheapest rates, for example) can simply be used as a provisioning tool, sending calls to one or multiple locations, none of which are the controlling party of the toll free number. Judith Judith Oppenheimer, 212 684-7210, 1 800 The Expert Publisher, http://www.ICBTollFreeNews.com President, http://www.1800TheExpert.com FREE 800/Domain Classifieds, http://ICBclassifieds.com Domain Name & 800 News, Intelligence, Analysis > -----Original Message----- > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > Sent: Monday, November 27, 2000 5:52 PM > To: Judith Oppenheimer > Cc: enum@ietf.org > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > At 05:18 PM 11/27/2000 -0500, you wrote: > >Is this system meant to accomodate U.S. toll free numbers? > > > >Judith > > Any national ENUM system has to accommodate toll free > numbers. 800 - 877 > etc, numbers in the US are E.164 numbers. Its just that the > authority for > authorization ( record holder ) is different. > > _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Nov 27 21:43:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04510 for ; Mon, 27 Nov 2000 21:43:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19889; Mon, 27 Nov 2000 21:42:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19861 for ; Mon, 27 Nov 2000 21:42:26 -0500 (EST) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04272 for ; Mon, 27 Nov 2000 21:42:24 -0500 (EST) Received: from computer.ix.netcom.com (user-2ivek93.dialup.mindspring.com [165.247.81.35]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id VAA22884; Mon, 27 Nov 2000 21:42:13 -0500 (EST) Message-Id: <5.0.0.25.2.20001127211626.02b5c940@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 27 Nov 2000 21:43:35 -0500 To: "Judith Oppenheimer" From: Richard Shockey Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt Cc: In-Reply-To: <006101c058c5$57188440$42ac580c@att.net.icbtollfree.com> References: <5.0.0.25.2.20001127174818.027601c0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 05:56 PM 11/27/2000 -0500, Judith Oppenheimer wrote: >I do not see where this draft anticipates that the "service provider" for a >toll free number may not be a TSP, but rather a so-called "RespOrg" (stands >for Responsible Organization.) For that matter, the calls may not resolve >to the end user subscriber either. > >One or more TSPs (programmed to be used at varying times of day for >cheapest rates, for example) can simply be used as a provisioning tool, >sending calls to one or multiple locations, none of which are the >controlling party of the toll free number. > >Judith Hello Judith.. Let me try and clear up a few things here. You are right that many of the drafts discussed here do not adequately or address the specific requirements and functions of the Toll Free System but I can assure you that those needs are are understood and being met. The "controlling party" of the Toll Free number is just as important .. as any telephone number. If there is a problem it is one of semantics and understanding the new service logic of Internet Telephony. Assume the case of 1 800 DOG-BONES that wishes to provision ENUM services to accept calls using SIP. That number has been delegated to that "subscriber" under the normal terms and conditions of 800 service ..so the "controlling party" is known to the 800 SMS and can be verified. The key to ENUM authority is that this verification can be successfully accomplished and that proper authorization can be delegated from the T1 to the T2 entity that actually holds the Resource Records that provision real service. Once this is accomplished we can assume that 1 800 DOG-BONES resolves to a SIP URL either under the direct control of the "controlling party", to use your terms, or to a T2 ENUM service provider that maintains these records under contract for this service under various SLA's etc. The SIP proxy that ENUM resolves to will maintain the real service logic of call routing necessary to complete the call based on the numbers "controlling party" requirements.[ time of day etc] And the syntax of that service logic is defined by the IPTEL WG as Call Progress Language. http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-04.txt The CPL is the real provisioning tool for Call Progress and routing as you outline. And the promise of this whole exercise in standards development is that service logic now resides within the complete control of the 1 800 number holder ..and not the carrier from whom service was delivered. ENUM is very simple in its abstraction. Number In ..URL Out. Its the URL that really controls the call and what that URL is. It is the URL that must be controlled by the number holder. Is this a touch clearer? > > > > At 05:18 PM 11/27/2000 -0500, you wrote: > > >Is this system meant to accomodate U.S. toll free numbers? > > > > > >Judith > > > > Any national ENUM system has to accommodate toll free > > numbers. 800 - 877 > > etc, numbers in the US are E.164 numbers. Its just that the > > authority for > > authorization ( record holder ) is different. > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 202.533.2811 Fax to EMail 815.333.1237 (Preferred for Fax) Cell : 314.503.0640 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Nov 27 21:50:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07051 for ; Mon, 27 Nov 2000 21:50:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20242; Mon, 27 Nov 2000 21:49:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20211 for ; Mon, 27 Nov 2000 21:49:38 -0500 (EST) Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06821 for ; Mon, 27 Nov 2000 21:49:37 -0500 (EST) Received: from worldnet ([12.88.171.220]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20001128024907.ESCI5130.mtiwmhc22.worldnet.att.net@worldnet>; Tue, 28 Nov 2000 02:49:07 +0000 From: "Judith Oppenheimer" To: "'Pfautz, Penn L, NNAD'" , "'Richard Shockey'" Cc: Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt Date: Mon, 27 Nov 2000 21:46:37 -0500 Message-ID: <008301c058e5$6e1ca520$42ac580c@att.net.icbtollfree.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <1B08859602C8D211B66F0000C0769CFA046A10B5@njc240po03.mt.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: High Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > I think the model > proposed works if you > view the RespOrg as End User This is legally inaccurate. If the model is that inflexible, the more logical alternative is to view the RespOrg as the TSP. *********** 4.3 Subscriber - Entity with day-to-day control over an E.164 number. 1. Individual that has been assigned an E.164 number by a TSP. 2. Enterprise that has been assign a pool of E.164 numbers by a TSP. ************ 4.3 is a fundamental principle of ENUM. It should not be compromised in order to crush a round peg into a square hole. Judith Judith Oppenheimer, 212 684-7210, 1 800 The Expert Publisher, http://www.ICBTollFreeNews.com President, http://www.1800TheExpert.com FREE 800/Domain Classifieds, http://ICBclassifieds.com Domain Name & 800 News, Intelligence, Analysis > -----Original Message----- > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > Sent: Monday, November 27, 2000 9:31 PM > To: Judith Oppenheimer; 'Richard Shockey' > Cc: enum@ietf.org > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > Judith: > I agree that the toll-free case is more complex and proposed > in my earlier > I-D (draft-pfautz-na-enum-01.txt) that the ENUM record for > the toll-free > number be controlled by the RespOrg. I think the model > proposed works if you > view the RespOrg as End User or User Agent. The RespOrg can > work with their > chosen Service Resgistrar to change the NAPTR record as > needed to point to > different carriers as appropriate, but that is really outside > of the ENUM > protocol per se. In terms of call allocation features, this > logic too will > not reside in the DNS, but perhaps in some server that the > NAPTR record > would point to. > (Some of this was discussed at the ITU working party meeting > in Berlin in > the context of international freephone). > It's also important to remember that ENUM remains an optional > functionality > - carriers and users are not obligated to use it but can > always complete > calls through the PSTN. > > Penn Pfautz > > > -----Original Message----- > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > Sent: Monday, November 27, 2000 5:57 PM > To: 'Richard Shockey' > Cc: enum@ietf.org > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > I do not see where this draft anticipates that the "service > provider" for a > toll free number may not be a TSP, but rather a so-called > "RespOrg" (stands > for Responsible Organization.) For that matter, the calls > may not resolve > to the end user subscriber either. > > One or more TSPs (programmed to be used at varying times of day for > cheapest rates, for example) can simply be used as a > provisioning tool, > sending calls to one or multiple locations, none of which are the > controlling party of the toll free number. > > Judith > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > Publisher, http://www.ICBTollFreeNews.com > President, http://www.1800TheExpert.com > FREE 800/Domain Classifieds, http://ICBclassifieds.com > Domain Name & 800 News, Intelligence, Analysis > > > > -----Original Message----- > > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > > Sent: Monday, November 27, 2000 5:52 PM > > To: Judith Oppenheimer > > Cc: enum@ietf.org > > Subject: RE: [Enum] Subject: > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > At 05:18 PM 11/27/2000 -0500, you wrote: > > >Is this system meant to accomodate U.S. toll free numbers? > > > > > >Judith > > > > Any national ENUM system has to accommodate toll free > > numbers. 800 - 877 > > etc, numbers in the US are E.164 numbers. Its just that the > > authority for > > authorization ( record holder ) is different. > > > > > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Nov 27 22:49:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22809 for ; Mon, 27 Nov 2000 22:49:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22162; Mon, 27 Nov 2000 22:49:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22086 for ; Mon, 27 Nov 2000 22:49:01 -0500 (EST) Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22612 for ; Mon, 27 Nov 2000 22:48:59 -0500 (EST) Received: from worldnet ([12.88.171.220]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20001128034829.FMKR5130.mtiwmhc22.worldnet.att.net@worldnet>; Tue, 28 Nov 2000 03:48:29 +0000 From: "Judith Oppenheimer" To: "'Richard Shockey'" Cc: Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt Date: Mon, 27 Nov 2000 22:45:58 -0500 Message-ID: <008401c058ed$b9149080$42ac580c@att.net.icbtollfree.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.0.0.25.2.20001127211626.02b5c940@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id WAA22162 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA22809 > That number has been delegated to that "subscriber" under the > normal terms > and conditions of 800 service ..so the "controlling party" is > known to the > 800 SMS and can be verified. The key to ENUM authority is that this > verification can be successfully accomplished and that proper > authorization > can be delegated from the T1 to the T2 entity that actually holds the > Resource Records that provision real service. The subscriber -- the "controlling party" -- is *not* known to the SMS800. In most instances this information is considered to be proprietary to the RespOrg or RespOrg/TSP and not housed in any external data base. > The key to ENUM authority is that this > verification can be successfully accomplished and that proper > authorization > can be delegated Most RespOrg/carriers (versus RespOrgs that aren't TSP's) simply don’t know who a fair portion of their subscribers are. With operational origins in pre-portability provisioning, RespOrg/carrier records are maintained based on who pays the bill -- not who the authorized subscriber is. For example, subscriber identity is not included in RespOrg/carrier reseller-sold records, because RespOrg/carriers consider the reseller to be the customer, even though FCC regulations stipulate that the end user is the legally-recognized subscriber of record. In April '98 the FCC order the RespOrgs to identify and notify the toll free customers affected by the right-of-first-refusal process for 888 replications -- ** a simple verification process. ** Only 370,000 toll free numbers were involved. In December '98 the FCC published that only 34 of 179 RespOrgs complied fully, and 52 did not comply at all. (AT&T had a 36.1% compliance rate; MCI, 40%, and Sprint, 35.1%.) The FCC charged the carriers were "warehousing set-aside 888 numbers or the corresponding 800 numbers, or ... falsely indicating ... identified subscribers for those numbers." These suspicions had some legitimacy, but I can tell you firsthand that at SNAC meetings throughout that period, all I heard from harried carrier execs, especially from the largest carriers, was "we just don't know who the subscribers are." They begged the FCC for more time to find their subscribers - and were turned down, resulting in a full two thirds of the original 370,000 set-aside 888 numbers, ultimately going unclaimed. (see p.s. below) So the "key to ENUM authority" may not so easily fit the U.S. 800 master locks. J P.S. On April 5, 1999 the unclaimed set-aside 888 toll free numbers were released to spare (available) status, by order of the FCC. In its March 23 press statement announcing the release, the FCC advised the public that there would be 140,000 vanity 888 numbers made available to the public, on a first come first serve basis. Anna Gomez of the FCC's Common Carrier Bureau, advised that the 140,000 figure was supplied to the agency by Database Services Management Inc. (DSMI.) But the actual amount of 888 numbers released on April 5 was over twice the published figure: 289,943, per the April 12, 1999 SMS/800 weekly report, which is printed by DSMI. A DSMI executive also confirmed that the 289,943 figure was accurate, noting that a full two thirds of the original 370,000 set-aside 888 numbers, ultimately went unclaimed and were released on April 5. Asked by a different reporter to explain the discrepancy between the two figures, another DSMI representative maintained that there was none, and that only 140,000 numbers were released. Judith Oppenheimer, 212 684-7210, 1 800 The Expert Publisher, http://www.ICBTollFreeNews.com President, http://www.1800TheExpert.com FREE 800/Domain Classifieds, http://ICBclassifieds.com Domain Name & 800 News, Intelligence, Analysis > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > Richard Shockey > Sent: Monday, November 27, 2000 9:44 PM > To: Judith Oppenheimer > Cc: enum@ietf.org > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > At 05:56 PM 11/27/2000 -0500, Judith Oppenheimer wrote: > >I do not see where this draft anticipates that the "service > provider" for a > >toll free number may not be a TSP, but rather a so-called > "RespOrg" (stands > >for Responsible Organization.) For that matter, the calls > may not resolve > >to the end user subscriber either. > > > >One or more TSPs (programmed to be used at varying times of day for > >cheapest rates, for example) can simply be used as a > provisioning tool, > >sending calls to one or multiple locations, none of which are the > >controlling party of the toll free number. > > > >Judith > > Hello Judith.. > > Let me try and clear up a few things here. You are right that > many of the > drafts discussed here do not adequately or address the specific > requirements and functions of the Toll Free System but I can > assure you > that those needs are are understood and being met. > > The "controlling party" of the Toll Free number is just as > important .. as > any telephone number. > > If there is a problem it is one of semantics and > understanding the new > service logic of Internet Telephony. > > Assume the case of 1 800 DOG-BONES that wishes to provision > ENUM services > to accept calls using SIP. > > That number has been delegated to that "subscriber" under the > normal terms > and conditions of 800 service ..so the "controlling party" is > known to the > 800 SMS and can be verified. The key to ENUM authority is that this > verification can be successfully accomplished and that proper > authorization > can be delegated from the T1 to the T2 entity that actually holds the > Resource Records that provision real service. > > Once this is accomplished we can assume that 1 800 DOG-BONES > resolves to a > SIP URL either under the direct control of the "controlling > party", to use > your terms, or to a T2 ENUM service provider that maintains > these records > under contract for this service under various SLA's etc. > > The SIP proxy that ENUM resolves to will maintain the real > service logic of > call routing necessary to complete the call based on the numbers > "controlling party" requirements.[ time of day etc] And the > syntax of that > service logic is defined by the IPTEL WG as Call Progress Language. > > http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-04.txt > > The CPL is the real provisioning tool for Call Progress and > routing as you > outline. And the promise of this whole exercise in standards > development is > that service logic now resides within the complete control > of the 1 800 > number holder ..and not the carrier from whom service was delivered. > > ENUM is very simple in its abstraction. Number In ..URL Out. > Its the URL > that really controls the call and what that URL is. It is the > URL that must > be controlled by the number holder. > > Is this a touch clearer? > > > > > > > > At 05:18 PM 11/27/2000 -0500, you wrote: > > > >Is this system meant to accomodate U.S. toll free numbers? > > > > > > > >Judith > > > > > > Any national ENUM system has to accommodate toll free > > > numbers. 800 - 877 > > > etc, numbers in the US are E.164 numbers. Its just that the > > > authority for > > > authorization ( record holder ) is different. > > > > > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Richard Shockey > Senior Technical Industry Liaison > NeuStar Inc. > 1120 Vermont Avenue N.W. > Suite 550 > Washington DC. 20005 > Voice 202.533.2811 > Fax to EMail 815.333.1237 (Preferred for Fax) > Cell : 314.503.0640 > INTERNET Mail & IFAX : rich.shockey@neustar.com > or rshockey@ix.netcom.com > http://www.neustar.com > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 28 09:15:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19885 for ; Tue, 28 Nov 2000 09:15:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09381; Tue, 28 Nov 2000 09:08:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09354 for ; Tue, 28 Nov 2000 09:08:46 -0500 (EST) Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16523 for ; Tue, 28 Nov 2000 09:08:47 -0500 (EST) Received: from worldnet ([12.88.173.90]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20001128140815.NHIT25510.mtiwmhc25.worldnet.att.net@worldnet>; Tue, 28 Nov 2000 14:08:15 +0000 From: "Judith Oppenheimer" To: "'Pfautz, Penn L, NNAD'" Cc: Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt Date: Tue, 28 Nov 2000 09:05:44 -0500 Message-ID: <016101c05944$4d32d8c0$5aad580c@att.net.icbtollfree.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <1B08859602C8D211B66F0000C0769CFA046A119A@njc240po03.mt.att.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit The RespOrg is empowered by tariff *only* to follow the subscriber's instructions. It may *not* make decisions on the subscriber's behalf. Big difference. And yes, RespOrgs may be subscribers as well. For example, MCI, a RespOrg and TSP, is the subscriber for 1 800 COLLECT, as is AT&T for 1 800 CALL ATT. Judith Judith Oppenheimer, 212 684-7210, 1 800 The Expert Publisher, http://www.ICBTollFreeNews.com President, http://www.1800TheExpert.com FREE 800/Domain Classifieds, http://ICBclassifieds.com Domain Name & 800 News, Intelligence, Analysis > -----Original Message----- > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > Sent: Tuesday, November 28, 2000 8:40 AM > To: Judith Oppenheimer > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > Judith: > But isn't the RespOrg the User Agent who is empowered to act > on the user's > behalf in the role of the subscriber? > I said subscriber only because in the model the actions of > the user agent > and subscriber are the same even though, > as you point out, legal control rests with the subscriber. > RespOrgs may be > TSPs or ASPs but may also be subscribers. > > > Penn > -----Original Message----- > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > Sent: Monday, November 27, 2000 9:47 PM > To: Pfautz, Penn L, NNAD; 'Richard Shockey' > Cc: enum@ietf.org > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > Importance: High > > > > I think the model > > proposed works if you > > view the RespOrg as End User > > This is legally inaccurate. > > If the model is that inflexible, the more logical alternative > is to view > the RespOrg as the TSP. > > *********** > 4.3 Subscriber > > - Entity with day-to-day control over an E.164 number. > > 1. Individual that has been assigned an E.164 > number by a TSP. > > 2. Enterprise that has been assign a pool of > E.164 numbers > by a TSP. > ************ > 4.3 is a fundamental principle of ENUM. It should not be > compromised in > order to crush a round peg into a square hole. > > Judith > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > Publisher, http://www.ICBTollFreeNews.com > President, http://www.1800TheExpert.com > FREE 800/Domain Classifieds, http://ICBclassifieds.com > Domain Name & 800 News, Intelligence, Analysis > > > > -----Original Message----- > > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > > Sent: Monday, November 27, 2000 9:31 PM > > To: Judith Oppenheimer; 'Richard Shockey' > > Cc: enum@ietf.org > > Subject: RE: [Enum] Subject: > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > Judith: > > I agree that the toll-free case is more complex and proposed > > in my earlier > > I-D (draft-pfautz-na-enum-01.txt) that the ENUM record for > > the toll-free > > number be controlled by the RespOrg. I think the model > > proposed works if you > > view the RespOrg as End User or User Agent. The RespOrg can > > work with their > > chosen Service Resgistrar to change the NAPTR record as > > needed to point to > > different carriers as appropriate, but that is really outside > > of the ENUM > > protocol per se. In terms of call allocation features, this > > logic too will > > not reside in the DNS, but perhaps in some server that the > > NAPTR record > > would point to. > > (Some of this was discussed at the ITU working party meeting > > in Berlin in > > the context of international freephone). > > It's also important to remember that ENUM remains an optional > > functionality > > - carriers and users are not obligated to use it but can > > always complete > > calls through the PSTN. > > > > Penn Pfautz > > > > > > -----Original Message----- > > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > > Sent: Monday, November 27, 2000 5:57 PM > > To: 'Richard Shockey' > > Cc: enum@ietf.org > > Subject: RE: [Enum] Subject: > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > I do not see where this draft anticipates that the "service > > provider" for a > > toll free number may not be a TSP, but rather a so-called > > "RespOrg" (stands > > for Responsible Organization.) For that matter, the calls > > may not resolve > > to the end user subscriber either. > > > > One or more TSPs (programmed to be used at varying times of day for > > cheapest rates, for example) can simply be used as a > > provisioning tool, > > sending calls to one or multiple locations, none of which are the > > controlling party of the toll free number. > > > > Judith > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > Publisher, http://www.ICBTollFreeNews.com > > President, http://www.1800TheExpert.com > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > -----Original Message----- > > > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > > > Sent: Monday, November 27, 2000 5:52 PM > > > To: Judith Oppenheimer > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] Subject: > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > At 05:18 PM 11/27/2000 -0500, you wrote: > > > >Is this system meant to accomodate U.S. toll free numbers? > > > > > > > >Judith > > > > > > Any national ENUM system has to accommodate toll free > > > numbers. 800 - 877 > > > etc, numbers in the US are E.164 numbers. Its just that the > > > authority for > > > authorization ( record holder ) is different. > > > > > > > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 28 09:42:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01877 for ; Tue, 28 Nov 2000 09:42:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10064; Tue, 28 Nov 2000 09:41:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10035 for ; Tue, 28 Nov 2000 09:41:39 -0500 (EST) Received: from hvmta02-stg.us.psimail.psi.net (hvmta02-ext.us.psimail.psi.net [38.202.36.30]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01648 for ; Tue, 28 Nov 2000 09:41:35 -0500 (EST) Received: from dranalli ([38.136.73.90]) by hvmta02-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001128144105.BBXU11307.hvmta02-stg@dranalli>; Tue, 28 Nov 2000 09:41:05 -0500 Message-ID: <005001c05948$c8590b10$5a498826@netnumber.com> Reply-To: "Douglas Ranalli" From: "Douglas Ranalli" To: "Judith Oppenheimer" Cc: References: <016101c05944$4d32d8c0$5aad580c@att.net.icbtollfree.com> Subject: Re: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt Date: Tue, 28 Nov 2000 09:37:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Judith, Thank you for the focus on this issue. If I understand your comments correctly, the draft creates some confusion by using the term "Telephone Service Provider" to describe the role that is being played by the "Responsible Organization" in the Toll-Free world. The term "Responsible Organization" is certainly more generic. Please confirm if Section 4.2 accurately describes the role of a Responsible Organization in the context of a Tier-1 ENUM System. If so, then I propose simply changing the term TSP to RespOrg. Doug ----- Original Message ----- From: Judith Oppenheimer To: 'Pfautz, Penn L, NNAD' Cc: Sent: Tuesday, November 28, 2000 9:05 AM Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > The RespOrg is empowered by tariff *only* to follow the subscriber's > instructions. > > It may *not* make decisions on the subscriber's behalf. Big difference. > > And yes, RespOrgs may be subscribers as well. For example, MCI, a RespOrg > and TSP, is the subscriber for 1 800 COLLECT, as is AT&T for 1 800 CALL > ATT. > > Judith > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > Publisher, http://www.ICBTollFreeNews.com > President, http://www.1800TheExpert.com > FREE 800/Domain Classifieds, http://ICBclassifieds.com > Domain Name & 800 News, Intelligence, Analysis > > > > -----Original Message----- > > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > > Sent: Tuesday, November 28, 2000 8:40 AM > > To: Judith Oppenheimer > > Subject: RE: [Enum] Subject: > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > Judith: > > But isn't the RespOrg the User Agent who is empowered to act > > on the user's > > behalf in the role of the subscriber? > > I said subscriber only because in the model the actions of > > the user agent > > and subscriber are the same even though, > > as you point out, legal control rests with the subscriber. > > RespOrgs may be > > TSPs or ASPs but may also be subscribers. > > > > > > Penn > > -----Original Message----- > > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > > Sent: Monday, November 27, 2000 9:47 PM > > To: Pfautz, Penn L, NNAD; 'Richard Shockey' > > Cc: enum@ietf.org > > Subject: RE: [Enum] Subject: > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > Importance: High > > > > > > > I think the model > > > proposed works if you > > > view the RespOrg as End User > > > > This is legally inaccurate. > > > > If the model is that inflexible, the more logical alternative > > is to view > > the RespOrg as the TSP. > > > > *********** > > 4.3 Subscriber > > > > - Entity with day-to-day control over an E.164 number. > > > > 1. Individual that has been assigned an E.164 > > number by a TSP. > > > > 2. Enterprise that has been assign a pool of > > E.164 numbers > > by a TSP. > > ************ > > 4.3 is a fundamental principle of ENUM. It should not be > > compromised in > > order to crush a round peg into a square hole. > > > > Judith > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > Publisher, http://www.ICBTollFreeNews.com > > President, http://www.1800TheExpert.com > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > -----Original Message----- > > > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > > > Sent: Monday, November 27, 2000 9:31 PM > > > To: Judith Oppenheimer; 'Richard Shockey' > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] Subject: > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > Judith: > > > I agree that the toll-free case is more complex and proposed > > > in my earlier > > > I-D (draft-pfautz-na-enum-01.txt) that the ENUM record for > > > the toll-free > > > number be controlled by the RespOrg. I think the model > > > proposed works if you > > > view the RespOrg as End User or User Agent. The RespOrg can > > > work with their > > > chosen Service Resgistrar to change the NAPTR record as > > > needed to point to > > > different carriers as appropriate, but that is really outside > > > of the ENUM > > > protocol per se. In terms of call allocation features, this > > > logic too will > > > not reside in the DNS, but perhaps in some server that the > > > NAPTR record > > > would point to. > > > (Some of this was discussed at the ITU working party meeting > > > in Berlin in > > > the context of international freephone). > > > It's also important to remember that ENUM remains an optional > > > functionality > > > - carriers and users are not obligated to use it but can > > > always complete > > > calls through the PSTN. > > > > > > Penn Pfautz > > > > > > > > > -----Original Message----- > > > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > > > Sent: Monday, November 27, 2000 5:57 PM > > > To: 'Richard Shockey' > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] Subject: > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > I do not see where this draft anticipates that the "service > > > provider" for a > > > toll free number may not be a TSP, but rather a so-called > > > "RespOrg" (stands > > > for Responsible Organization.) For that matter, the calls > > > may not resolve > > > to the end user subscriber either. > > > > > > One or more TSPs (programmed to be used at varying times of day for > > > cheapest rates, for example) can simply be used as a > > > provisioning tool, > > > sending calls to one or multiple locations, none of which are the > > > controlling party of the toll free number. > > > > > > Judith > > > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > > Publisher, http://www.ICBTollFreeNews.com > > > President, http://www.1800TheExpert.com > > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > > > > -----Original Message----- > > > > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > > > > Sent: Monday, November 27, 2000 5:52 PM > > > > To: Judith Oppenheimer > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] Subject: > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > At 05:18 PM 11/27/2000 -0500, you wrote: > > > > >Is this system meant to accomodate U.S. toll free numbers? > > > > > > > > > >Judith > > > > > > > > Any national ENUM system has to accommodate toll free > > > > numbers. 800 - 877 > > > > etc, numbers in the US are E.164 numbers. Its just that the > > > > authority for > > > > authorization ( record holder ) is different. > > > > > > > > > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > http://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 28 10:13:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15144 for ; Tue, 28 Nov 2000 10:13:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11145; Tue, 28 Nov 2000 10:12:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11112 for ; Tue, 28 Nov 2000 10:12:31 -0500 (EST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14862 for ; Tue, 28 Nov 2000 10:12:30 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id eASFBwh10636; Tue, 28 Nov 2000 10:11:59 -0500 (EST) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA00120; Tue, 28 Nov 2000 10:10:56 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Tue, 28 Nov 2000 10:11:53 -0500 Message-ID: <1B08859602C8D211B66F0000C0769CFA046A13E1@njc240po03.mt.att.com> From: "Pfautz, Penn L, NNAD" To: Douglas Ranalli , Judith Oppenheimer Cc: enum@ietf.org Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Date: Tue, 28 Nov 2000 10:11:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Doug: Be aware that RespOrg is a role specific to toll-free numbers. You'll need a TSP role in any case for geographic numbers. The questions are "Who controls the ENUM record for a toll-free number" and "Does the model need to be altered to specifcally incorporate different roles for toll-free numbers." Penn -----Original Message----- From: Douglas Ranalli [mailto:dranalli@netnumber.com] Sent: Tuesday, November 28, 2000 9:38 AM To: Judith Oppenheimer Cc: enum@ietf.org Subject: Re: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt Judith, Thank you for the focus on this issue. If I understand your comments correctly, the draft creates some confusion by using the term "Telephone Service Provider" to describe the role that is being played by the "Responsible Organization" in the Toll-Free world. The term "Responsible Organization" is certainly more generic. Please confirm if Section 4.2 accurately describes the role of a Responsible Organization in the context of a Tier-1 ENUM System. If so, then I propose simply changing the term TSP to RespOrg. Doug ----- Original Message ----- From: Judith Oppenheimer To: 'Pfautz, Penn L, NNAD' Cc: Sent: Tuesday, November 28, 2000 9:05 AM Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > The RespOrg is empowered by tariff *only* to follow the subscriber's > instructions. > > It may *not* make decisions on the subscriber's behalf. Big difference. > > And yes, RespOrgs may be subscribers as well. For example, MCI, a RespOrg > and TSP, is the subscriber for 1 800 COLLECT, as is AT&T for 1 800 CALL > ATT. > > Judith > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > Publisher, http://www.ICBTollFreeNews.com > President, http://www.1800TheExpert.com > FREE 800/Domain Classifieds, http://ICBclassifieds.com > Domain Name & 800 News, Intelligence, Analysis > > > > -----Original Message----- > > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > > Sent: Tuesday, November 28, 2000 8:40 AM > > To: Judith Oppenheimer > > Subject: RE: [Enum] Subject: > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > Judith: > > But isn't the RespOrg the User Agent who is empowered to act > > on the user's > > behalf in the role of the subscriber? > > I said subscriber only because in the model the actions of > > the user agent > > and subscriber are the same even though, > > as you point out, legal control rests with the subscriber. > > RespOrgs may be > > TSPs or ASPs but may also be subscribers. > > > > > > Penn > > -----Original Message----- > > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > > Sent: Monday, November 27, 2000 9:47 PM > > To: Pfautz, Penn L, NNAD; 'Richard Shockey' > > Cc: enum@ietf.org > > Subject: RE: [Enum] Subject: > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > Importance: High > > > > > > > I think the model > > > proposed works if you > > > view the RespOrg as End User > > > > This is legally inaccurate. > > > > If the model is that inflexible, the more logical alternative > > is to view > > the RespOrg as the TSP. > > > > *********** > > 4.3 Subscriber > > > > - Entity with day-to-day control over an E.164 number. > > > > 1. Individual that has been assigned an E.164 > > number by a TSP. > > > > 2. Enterprise that has been assign a pool of > > E.164 numbers > > by a TSP. > > ************ > > 4.3 is a fundamental principle of ENUM. It should not be > > compromised in > > order to crush a round peg into a square hole. > > > > Judith > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > Publisher, http://www.ICBTollFreeNews.com > > President, http://www.1800TheExpert.com > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > -----Original Message----- > > > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > > > Sent: Monday, November 27, 2000 9:31 PM > > > To: Judith Oppenheimer; 'Richard Shockey' > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] Subject: > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > Judith: > > > I agree that the toll-free case is more complex and proposed > > > in my earlier > > > I-D (draft-pfautz-na-enum-01.txt) that the ENUM record for > > > the toll-free > > > number be controlled by the RespOrg. I think the model > > > proposed works if you > > > view the RespOrg as End User or User Agent. The RespOrg can > > > work with their > > > chosen Service Resgistrar to change the NAPTR record as > > > needed to point to > > > different carriers as appropriate, but that is really outside > > > of the ENUM > > > protocol per se. In terms of call allocation features, this > > > logic too will > > > not reside in the DNS, but perhaps in some server that the > > > NAPTR record > > > would point to. > > > (Some of this was discussed at the ITU working party meeting > > > in Berlin in > > > the context of international freephone). > > > It's also important to remember that ENUM remains an optional > > > functionality > > > - carriers and users are not obligated to use it but can > > > always complete > > > calls through the PSTN. > > > > > > Penn Pfautz > > > > > > > > > -----Original Message----- > > > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > > > Sent: Monday, November 27, 2000 5:57 PM > > > To: 'Richard Shockey' > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] Subject: > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > I do not see where this draft anticipates that the "service > > > provider" for a > > > toll free number may not be a TSP, but rather a so-called > > > "RespOrg" (stands > > > for Responsible Organization.) For that matter, the calls > > > may not resolve > > > to the end user subscriber either. > > > > > > One or more TSPs (programmed to be used at varying times of day for > > > cheapest rates, for example) can simply be used as a > > > provisioning tool, > > > sending calls to one or multiple locations, none of which are the > > > controlling party of the toll free number. > > > > > > Judith > > > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > > Publisher, http://www.ICBTollFreeNews.com > > > President, http://www.1800TheExpert.com > > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > > > > -----Original Message----- > > > > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > > > > Sent: Monday, November 27, 2000 5:52 PM > > > > To: Judith Oppenheimer > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] Subject: > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > At 05:18 PM 11/27/2000 -0500, you wrote: > > > > >Is this system meant to accomodate U.S. toll free numbers? > > > > > > > > > >Judith > > > > > > > > Any national ENUM system has to accommodate toll free > > > > numbers. 800 - 877 > > > > etc, numbers in the US are E.164 numbers. Its just that the > > > > authority for > > > > authorization ( record holder ) is different. > > > > > > > > > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > http://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 28 11:15:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11772 for ; Tue, 28 Nov 2000 11:15:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15259; Tue, 28 Nov 2000 11:14:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15184 for ; Tue, 28 Nov 2000 11:14:17 -0500 (EST) Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net [38.202.36.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11344 for ; Tue, 28 Nov 2000 11:14:16 -0500 (EST) Received: from dranalli ([38.136.73.90]) by hvmta03-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001128161346.EWOM24415.hvmta03-stg@dranalli>; Tue, 28 Nov 2000 11:13:46 -0500 Message-ID: <00c101c05955$bb114fa0$5a498826@netnumber.com> Reply-To: "Douglas Ranalli" From: "Douglas Ranalli" To: "Pfautz, Penn L, NNAD" Cc: References: <1B08859602C8D211B66F0000C0769CFA046A13E1@njc240po03.mt.att.com> Subject: Re: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt Date: Tue, 28 Nov 2000 11:10:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Penn, Thanks for the quick reply. Interesting terminology question. I agree that both "Responsible Organization" and "Telephone Service Provider" present challenges from a terminology standpoint because they both have meaning beyond the context of an ENUM System. Here's the challenge: Within the ENUM System there is a role for an entity that has contractual control over a block of E.164 numbers and plays the role of assigning those numbers to Subscribers. (See section 4.2) The draft uses the term "Telephone Service Provider" to define the entity that fulfills this role in the ENUM System. Judith Oppenheimer has pointed out that this role can be provided by "non-TSP" entities like "Responsible Organizations" in the toll-free context. Neither term is perfect for the job but "Responsible Organization" is certainly a broader term that can encompass a "Telephone Service Provider". My preference has been to work with existing terms rather than to define new terms specifically for ENUM but the tradeoff is clear. Can you recommend alternative names for the ENUM entity described in Section 4.2? Doug ----- Original Message ----- From: Pfautz, Penn L, NNAD To: Douglas Ranalli ; Judith Oppenheimer Cc: Sent: Tuesday, November 28, 2000 10:11 AM Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > Doug: > Be aware that RespOrg is a role specific to toll-free numbers. You'll need a > TSP role in any case for geographic numbers. > The questions are "Who controls the ENUM record for a toll-free number" and > "Does the model need to be altered to specifcally incorporate different > roles for toll-free numbers." > > Penn > > -----Original Message----- > From: Douglas Ranalli [mailto:dranalli@netnumber.com] > Sent: Tuesday, November 28, 2000 9:38 AM > To: Judith Oppenheimer > Cc: enum@ietf.org > Subject: Re: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > Judith, > > Thank you for the focus on this issue. If I understand your comments > correctly, the draft creates some confusion by using the term "Telephone > Service Provider" to describe the role that is being played by the > "Responsible Organization" in the Toll-Free world. The term "Responsible > Organization" is certainly more generic. Please confirm if Section 4.2 > accurately describes the role of a Responsible Organization in the context > of a Tier-1 ENUM System. If so, then I propose simply changing the term TSP > to RespOrg. > > Doug > > ----- Original Message ----- > From: Judith Oppenheimer > To: 'Pfautz, Penn L, NNAD' > Cc: > Sent: Tuesday, November 28, 2000 9:05 AM > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > The RespOrg is empowered by tariff *only* to follow the subscriber's > > instructions. > > > > It may *not* make decisions on the subscriber's behalf. Big difference. > > > > And yes, RespOrgs may be subscribers as well. For example, MCI, a RespOrg > > and TSP, is the subscriber for 1 800 COLLECT, as is AT&T for 1 800 CALL > > ATT. > > > > Judith > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > Publisher, http://www.ICBTollFreeNews.com > > President, http://www.1800TheExpert.com > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > -----Original Message----- > > > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > > > Sent: Tuesday, November 28, 2000 8:40 AM > > > To: Judith Oppenheimer > > > Subject: RE: [Enum] Subject: > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > Judith: > > > But isn't the RespOrg the User Agent who is empowered to act > > > on the user's > > > behalf in the role of the subscriber? > > > I said subscriber only because in the model the actions of > > > the user agent > > > and subscriber are the same even though, > > > as you point out, legal control rests with the subscriber. > > > RespOrgs may be > > > TSPs or ASPs but may also be subscribers. > > > > > > > > > Penn > > > -----Original Message----- > > > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > > > Sent: Monday, November 27, 2000 9:47 PM > > > To: Pfautz, Penn L, NNAD; 'Richard Shockey' > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] Subject: > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > Importance: High > > > > > > > > > > I think the model > > > > proposed works if you > > > > view the RespOrg as End User > > > > > > This is legally inaccurate. > > > > > > If the model is that inflexible, the more logical alternative > > > is to view > > > the RespOrg as the TSP. > > > > > > *********** > > > 4.3 Subscriber > > > > > > - Entity with day-to-day control over an E.164 number. > > > > > > 1. Individual that has been assigned an E.164 > > > number by a TSP. > > > > > > 2. Enterprise that has been assign a pool of > > > E.164 numbers > > > by a TSP. > > > ************ > > > 4.3 is a fundamental principle of ENUM. It should not be > > > compromised in > > > order to crush a round peg into a square hole. > > > > > > Judith > > > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > > Publisher, http://www.ICBTollFreeNews.com > > > President, http://www.1800TheExpert.com > > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > > > > -----Original Message----- > > > > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > > > > Sent: Monday, November 27, 2000 9:31 PM > > > > To: Judith Oppenheimer; 'Richard Shockey' > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] Subject: > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > Judith: > > > > I agree that the toll-free case is more complex and proposed > > > > in my earlier > > > > I-D (draft-pfautz-na-enum-01.txt) that the ENUM record for > > > > the toll-free > > > > number be controlled by the RespOrg. I think the model > > > > proposed works if you > > > > view the RespOrg as End User or User Agent. The RespOrg can > > > > work with their > > > > chosen Service Resgistrar to change the NAPTR record as > > > > needed to point to > > > > different carriers as appropriate, but that is really outside > > > > of the ENUM > > > > protocol per se. In terms of call allocation features, this > > > > logic too will > > > > not reside in the DNS, but perhaps in some server that the > > > > NAPTR record > > > > would point to. > > > > (Some of this was discussed at the ITU working party meeting > > > > in Berlin in > > > > the context of international freephone). > > > > It's also important to remember that ENUM remains an optional > > > > functionality > > > > - carriers and users are not obligated to use it but can > > > > always complete > > > > calls through the PSTN. > > > > > > > > Penn Pfautz > > > > > > > > > > > > -----Original Message----- > > > > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > > > > Sent: Monday, November 27, 2000 5:57 PM > > > > To: 'Richard Shockey' > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] Subject: > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > I do not see where this draft anticipates that the "service > > > > provider" for a > > > > toll free number may not be a TSP, but rather a so-called > > > > "RespOrg" (stands > > > > for Responsible Organization.) For that matter, the calls > > > > may not resolve > > > > to the end user subscriber either. > > > > > > > > One or more TSPs (programmed to be used at varying times of day for > > > > cheapest rates, for example) can simply be used as a > > > > provisioning tool, > > > > sending calls to one or multiple locations, none of which are the > > > > controlling party of the toll free number. > > > > > > > > Judith > > > > > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > > > Publisher, http://www.ICBTollFreeNews.com > > > > President, http://www.1800TheExpert.com > > > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > > > > > > > -----Original Message----- > > > > > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > > > > > Sent: Monday, November 27, 2000 5:52 PM > > > > > To: Judith Oppenheimer > > > > > Cc: enum@ietf.org > > > > > Subject: RE: [Enum] Subject: > > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > > > > At 05:18 PM 11/27/2000 -0500, you wrote: > > > > > >Is this system meant to accomodate U.S. toll free numbers? > > > > > > > > > > > >Judith > > > > > > > > > > Any national ENUM system has to accommodate toll free > > > > > numbers. 800 - 877 > > > > > etc, numbers in the US are E.164 numbers. Its just that the > > > > > authority for > > > > > authorization ( record holder ) is different. > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > http://www1.ietf.org/mailman/listinfo/enum > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > http://www1.ietf.org/mailman/listinfo/enum > > > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 28 11:20:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14269 for ; Tue, 28 Nov 2000 11:20:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15781; Tue, 28 Nov 2000 11:19:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15742 for ; Tue, 28 Nov 2000 11:19:51 -0500 (EST) Received: from mx.cwplc.com (mx.cwplc.com [194.6.6.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13937 for ; Tue, 28 Nov 2000 11:19:49 -0500 (EST) Received: from gb-cwc-brt-msw2.isops.cwcom.co.uk ([148.185.176.7]) by mx.cwplc.com (Switch-2.0.6/Switch-2.0.6) with ESMTP id eASGGIJ02022 for ; Tue, 28 Nov 2000 16:16:18 GMT Received: from gbcwcbrti002.isops.cwcom.co.uk (unverified) by gb-cwc-brt-msw2.isops.cwcom.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 28 Nov 2000 16:10:34 +0000 Received: by gbcwcbrti002.isops.cwcom.co.uk with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Nov 2000 16:18:55 -0000 Message-Id: <29B7C7A8E3E4D111ABDB0000F8086400072BF676@gbcwcbrtm003.isops.cwcom.co.uk> From: "Rosbotham, Paul" To: enum@ietf.org Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Date: Tue, 28 Nov 2000 16:20:08 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Penn, Doug & Judith It think that a lot of the confusion/concern arises due to using terms that have specific meanings in the PSTN world (or at least in some regulatory environments) or IP world. For example, TSP is being taken by some readers to have the same meaning as the term within the US telecoms regime. In the UK, in contrast, a "service provider" is simply an entity that provides telecoms services to an end customer. They could have a network, but (particularly in the mobile arena) they could simply resell the services of a network operator. I don't know enough about the US scenario to know whether a RespOrg is just involved in setting up an 800 number or ongoing manages the service for the customer, but it seems to me that if the latter is the case then in the context of this discussion a RespOrg would be a particular type of service provider that doesn't own their own network. I'd propose the following; - Try to make the responsibilities generic rather than slipping into US-specific issues - At an IETF level stick to functional responsibilities, and worry about how these map onto each national telecoms environments at an appropriate national body - Where possible, name the functional entities within the document such that they don't clash with physical entities in eg the USA/Swedish/French/UK market hence avoid the conclusion. I appreciate this point is difficult to do universally, plus could lead to a challenge with coming up with a term that adequately expresses what an entity is. I wouldn't be at all happy with RespOrgs being entities in the document, because so far as I know, this is a concept unique to the US market. Regards Paul > -----Original Message----- > From: Pfautz, Penn L, NNAD [SMTP:ppfautz@att.com] > Sent: Tuesday, November 28, 2000 3:12 PM > To: Douglas Ranalli; Judith Oppenheimer > Cc: enum@ietf.org > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt > > Doug: > Be aware that RespOrg is a role specific to toll-free numbers. You'll need > a > TSP role in any case for geographic numbers. > The questions are "Who controls the ENUM record for a toll-free number" > and > "Does the model need to be altered to specifcally incorporate different > roles for toll-free numbers." > > Penn > > -----Original Message----- > From: Douglas Ranalli [mailto:dranalli@netnumber.com] > Sent: Tuesday, November 28, 2000 9:38 AM > To: Judith Oppenheimer > Cc: enum@ietf.org > Subject: Re: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > Judith, > > Thank you for the focus on this issue. If I understand your comments > correctly, the draft creates some confusion by using the term "Telephone > Service Provider" to describe the role that is being played by the > "Responsible Organization" in the Toll-Free world. The term "Responsible > Organization" is certainly more generic. Please confirm if Section 4.2 > accurately describes the role of a Responsible Organization in the context > of a Tier-1 ENUM System. If so, then I propose simply changing the term > TSP > to RespOrg. > > Doug > > ----- Original Message ----- > From: Judith Oppenheimer > To: 'Pfautz, Penn L, NNAD' > Cc: > Sent: Tuesday, November 28, 2000 9:05 AM > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > The RespOrg is empowered by tariff *only* to follow the subscriber's > > instructions. > > > > It may *not* make decisions on the subscriber's behalf. Big difference. > > > > And yes, RespOrgs may be subscribers as well. For example, MCI, a > RespOrg > > and TSP, is the subscriber for 1 800 COLLECT, as is AT&T for 1 800 CALL > > ATT. > > > > Judith > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > Publisher, http://www.ICBTollFreeNews.com > > President, http://www.1800TheExpert.com > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > -----Original Message----- > > > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > > > Sent: Tuesday, November 28, 2000 8:40 AM > > > To: Judith Oppenheimer > > > Subject: RE: [Enum] Subject: > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > Judith: > > > But isn't the RespOrg the User Agent who is empowered to act > > > on the user's > > > behalf in the role of the subscriber? > > > I said subscriber only because in the model the actions of > > > the user agent > > > and subscriber are the same even though, > > > as you point out, legal control rests with the subscriber. > > > RespOrgs may be > > > TSPs or ASPs but may also be subscribers. > > > > > > > > > Penn > > > -----Original Message----- > > > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > > > Sent: Monday, November 27, 2000 9:47 PM > > > To: Pfautz, Penn L, NNAD; 'Richard Shockey' > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] Subject: > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > Importance: High > > > > > > > > > > I think the model > > > > proposed works if you > > > > view the RespOrg as End User > > > > > > This is legally inaccurate. > > > > > > If the model is that inflexible, the more logical alternative > > > is to view > > > the RespOrg as the TSP. > > > > > > *********** > > > 4.3 Subscriber > > > > > > - Entity with day-to-day control over an E.164 number. > > > > > > 1. Individual that has been assigned an E.164 > > > number by a TSP. > > > > > > 2. Enterprise that has been assign a pool of > > > E.164 numbers > > > by a TSP. > > > ************ > > > 4.3 is a fundamental principle of ENUM. It should not be > > > compromised in > > > order to crush a round peg into a square hole. > > > > > > Judith > > > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > > Publisher, http://www.ICBTollFreeNews.com > > > President, http://www.1800TheExpert.com > > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > > > > -----Original Message----- > > > > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > > > > Sent: Monday, November 27, 2000 9:31 PM > > > > To: Judith Oppenheimer; 'Richard Shockey' > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] Subject: > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > Judith: > > > > I agree that the toll-free case is more complex and proposed > > > > in my earlier > > > > I-D (draft-pfautz-na-enum-01.txt) that the ENUM record for > > > > the toll-free > > > > number be controlled by the RespOrg. I think the model > > > > proposed works if you > > > > view the RespOrg as End User or User Agent. The RespOrg can > > > > work with their > > > > chosen Service Resgistrar to change the NAPTR record as > > > > needed to point to > > > > different carriers as appropriate, but that is really outside > > > > of the ENUM > > > > protocol per se. In terms of call allocation features, this > > > > logic too will > > > > not reside in the DNS, but perhaps in some server that the > > > > NAPTR record > > > > would point to. > > > > (Some of this was discussed at the ITU working party meeting > > > > in Berlin in > > > > the context of international freephone). > > > > It's also important to remember that ENUM remains an optional > > > > functionality > > > > - carriers and users are not obligated to use it but can > > > > always complete > > > > calls through the PSTN. > > > > > > > > Penn Pfautz > > > > > > > > > > > > -----Original Message----- > > > > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > > > > Sent: Monday, November 27, 2000 5:57 PM > > > > To: 'Richard Shockey' > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] Subject: > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > I do not see where this draft anticipates that the "service > > > > provider" for a > > > > toll free number may not be a TSP, but rather a so-called > > > > "RespOrg" (stands > > > > for Responsible Organization.) For that matter, the calls > > > > may not resolve > > > > to the end user subscriber either. > > > > > > > > One or more TSPs (programmed to be used at varying times of day for > > > > cheapest rates, for example) can simply be used as a > > > > provisioning tool, > > > > sending calls to one or multiple locations, none of which are the > > > > controlling party of the toll free number. > > > > > > > > Judith > > > > > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > > > Publisher, http://www.ICBTollFreeNews.com > > > > President, http://www.1800TheExpert.com > > > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > > > > > > > -----Original Message----- > > > > > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > > > > > Sent: Monday, November 27, 2000 5:52 PM > > > > > To: Judith Oppenheimer > > > > > Cc: enum@ietf.org > > > > > Subject: RE: [Enum] Subject: > > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > > > > At 05:18 PM 11/27/2000 -0500, you wrote: > > > > > >Is this system meant to accomodate U.S. toll free numbers? > > > > > > > > > > > >Judith > > > > > > > > > > Any national ENUM system has to accommodate toll free > > > > > numbers. 800 - 877 > > > > > etc, numbers in the US are E.164 numbers. Its just that the > > > > > authority for > > > > > authorization ( record holder ) is different. > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > http://www1.ietf.org/mailman/listinfo/enum > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > http://www1.ietf.org/mailman/listinfo/enum > > > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum ********************************************************************** This message may contain information which is confidential or privileged. If you are not the intended recipient, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy. ********************************************************************** _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 28 12:03:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01704 for ; Tue, 28 Nov 2000 12:03:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18811; Tue, 28 Nov 2000 12:01:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18781 for ; Tue, 28 Nov 2000 12:01:24 -0500 (EST) Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01174 for ; Tue, 28 Nov 2000 12:01:21 -0500 (EST) Received: from seagal ([208.146.135.202]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001128170043.SHO1216.hvmta01-stg@seagal>; Tue, 28 Nov 2000 12:00:43 -0500 From: "David P. Peek" To: "Douglas Ranalli" , "Pfautz, Penn L, NNAD" Cc: Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt Date: Tue, 28 Nov 2000 12:00:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <00c101c05955$bb114fa0$5a498826@netnumber.com> Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit >Can you recommend alternative names for the ENUM entity described in Section 4.2? In an effort to avoid names that have preconceived meanings and one that describes what we are trying to achieve in Section 4.2 I propose to use a new term. Are there any objections to: "Telephone Number Provider" (TNP) This would be an inclusive term for entities that provide E.164 numbers. A TNP may take on multiple roles that not only provides E.164 numbers but may also be a subscriber as in Judith's example. Dave. > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > Douglas Ranalli > Sent: Tuesday, November 28, 2000 11:10 AM > To: Pfautz, Penn L, NNAD > Cc: enum@ietf.org > Subject: Re: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > Penn, > > Thanks for the quick reply. Interesting terminology question. I > agree that > both "Responsible Organization" and "Telephone Service Provider" present > challenges from a terminology standpoint because they both have meaning > beyond the context of an ENUM System. Here's the challenge: > > Within the ENUM System there is a role for an entity that has contractual > control over a block of E.164 numbers and plays the role of > assigning those > numbers to Subscribers. (See section 4.2) > > The draft uses the term "Telephone Service Provider" to define the entity > that fulfills this role in the ENUM System. Judith Oppenheimer > has pointed > out that this role can be provided by "non-TSP" entities like "Responsible > Organizations" in the toll-free context. > > Neither term is perfect for the job but "Responsible Organization" is > certainly a broader term that can encompass a "Telephone Service > Provider". > > My preference has been to work with existing terms rather than to > define new > terms specifically for ENUM but the tradeoff is clear. Can you recommend > alternative names for the ENUM entity described in Section 4.2? > > Doug > > ----- Original Message ----- > From: Pfautz, Penn L, NNAD > To: Douglas Ranalli ; Judith Oppenheimer > > Cc: > Sent: Tuesday, November 28, 2000 10:11 AM > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > Doug: > > Be aware that RespOrg is a role specific to toll-free numbers. > You'll need > a > > TSP role in any case for geographic numbers. > > The questions are "Who controls the ENUM record for a toll-free number" > and > > "Does the model need to be altered to specifcally incorporate different > > roles for toll-free numbers." > > > > Penn > > > > -----Original Message----- > > From: Douglas Ranalli [mailto:dranalli@netnumber.com] > > Sent: Tuesday, November 28, 2000 9:38 AM > > To: Judith Oppenheimer > > Cc: enum@ietf.org > > Subject: Re: [Enum] Subject: > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > Judith, > > > > Thank you for the focus on this issue. If I understand your comments > > correctly, the draft creates some confusion by using the term "Telephone > > Service Provider" to describe the role that is being played by the > > "Responsible Organization" in the Toll-Free world. The term > "Responsible > > Organization" is certainly more generic. Please confirm if Section 4.2 > > accurately describes the role of a Responsible Organization in > the context > > of a Tier-1 ENUM System. If so, then I propose simply changing the term > TSP > > to RespOrg. > > > > Doug > > > > ----- Original Message ----- > > From: Judith Oppenheimer > > To: 'Pfautz, Penn L, NNAD' > > Cc: > > Sent: Tuesday, November 28, 2000 9:05 AM > > Subject: RE: [Enum] Subject: > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > The RespOrg is empowered by tariff *only* to follow the subscriber's > > > instructions. > > > > > > It may *not* make decisions on the subscriber's behalf. Big > difference. > > > > > > And yes, RespOrgs may be subscribers as well. For example, MCI, a > RespOrg > > > and TSP, is the subscriber for 1 800 COLLECT, as is AT&T for > 1 800 CALL > > > ATT. > > > > > > Judith > > > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > > Publisher, http://www.ICBTollFreeNews.com > > > President, http://www.1800TheExpert.com > > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > > > > -----Original Message----- > > > > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > > > > Sent: Tuesday, November 28, 2000 8:40 AM > > > > To: Judith Oppenheimer > > > > Subject: RE: [Enum] Subject: > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > Judith: > > > > But isn't the RespOrg the User Agent who is empowered to act > > > > on the user's > > > > behalf in the role of the subscriber? > > > > I said subscriber only because in the model the actions of > > > > the user agent > > > > and subscriber are the same even though, > > > > as you point out, legal control rests with the subscriber. > > > > RespOrgs may be > > > > TSPs or ASPs but may also be subscribers. > > > > > > > > > > > > Penn > > > > -----Original Message----- > > > > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > > > > Sent: Monday, November 27, 2000 9:47 PM > > > > To: Pfautz, Penn L, NNAD; 'Richard Shockey' > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] Subject: > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > Importance: High > > > > > > > > > > > > > I think the model > > > > > proposed works if you > > > > > view the RespOrg as End User > > > > > > > > This is legally inaccurate. > > > > > > > > If the model is that inflexible, the more logical alternative > > > > is to view > > > > the RespOrg as the TSP. > > > > > > > > *********** > > > > 4.3 Subscriber > > > > > > > > - Entity with day-to-day control over an E.164 number. > > > > > > > > 1. Individual that has been assigned an E.164 > > > > number by a TSP. > > > > > > > > 2. Enterprise that has been assign a pool of > > > > E.164 numbers > > > > by a TSP. > > > > ************ > > > > 4.3 is a fundamental principle of ENUM. It should not be > > > > compromised in > > > > order to crush a round peg into a square hole. > > > > > > > > Judith > > > > > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > > > Publisher, http://www.ICBTollFreeNews.com > > > > President, http://www.1800TheExpert.com > > > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > > > > > > > -----Original Message----- > > > > > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > > > > > Sent: Monday, November 27, 2000 9:31 PM > > > > > To: Judith Oppenheimer; 'Richard Shockey' > > > > > Cc: enum@ietf.org > > > > > Subject: RE: [Enum] Subject: > > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > > > > Judith: > > > > > I agree that the toll-free case is more complex and proposed > > > > > in my earlier > > > > > I-D (draft-pfautz-na-enum-01.txt) that the ENUM record for > > > > > the toll-free > > > > > number be controlled by the RespOrg. I think the model > > > > > proposed works if you > > > > > view the RespOrg as End User or User Agent. The RespOrg can > > > > > work with their > > > > > chosen Service Resgistrar to change the NAPTR record as > > > > > needed to point to > > > > > different carriers as appropriate, but that is really outside > > > > > of the ENUM > > > > > protocol per se. In terms of call allocation features, this > > > > > logic too will > > > > > not reside in the DNS, but perhaps in some server that the > > > > > NAPTR record > > > > > would point to. > > > > > (Some of this was discussed at the ITU working party meeting > > > > > in Berlin in > > > > > the context of international freephone). > > > > > It's also important to remember that ENUM remains an optional > > > > > functionality > > > > > - carriers and users are not obligated to use it but can > > > > > always complete > > > > > calls through the PSTN. > > > > > > > > > > Penn Pfautz > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > > > > > Sent: Monday, November 27, 2000 5:57 PM > > > > > To: 'Richard Shockey' > > > > > Cc: enum@ietf.org > > > > > Subject: RE: [Enum] Subject: > > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > > > > I do not see where this draft anticipates that the "service > > > > > provider" for a > > > > > toll free number may not be a TSP, but rather a so-called > > > > > "RespOrg" (stands > > > > > for Responsible Organization.) For that matter, the calls > > > > > may not resolve > > > > > to the end user subscriber either. > > > > > > > > > > One or more TSPs (programmed to be used at varying times > of day for > > > > > cheapest rates, for example) can simply be used as a > > > > > provisioning tool, > > > > > sending calls to one or multiple locations, none of which are the > > > > > controlling party of the toll free number. > > > > > > > > > > Judith > > > > > > > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > > > > Publisher, http://www.ICBTollFreeNews.com > > > > > President, http://www.1800TheExpert.com > > > > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > > > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > > > > > > Sent: Monday, November 27, 2000 5:52 PM > > > > > > To: Judith Oppenheimer > > > > > > Cc: enum@ietf.org > > > > > > Subject: RE: [Enum] Subject: > > > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > > > > > > > At 05:18 PM 11/27/2000 -0500, you wrote: > > > > > > >Is this system meant to accomodate U.S. toll free numbers? > > > > > > > > > > > > > >Judith > > > > > > > > > > > > Any national ENUM system has to accommodate toll free > > > > > > numbers. 800 - 877 > > > > > > etc, numbers in the US are E.164 numbers. Its just that the > > > > > > authority for > > > > > > authorization ( record holder ) is different. > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > enum mailing list > > > > > enum@ietf.org > > > > > http://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > http://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > http://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > http://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 28 12:11:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04153 for ; Tue, 28 Nov 2000 12:11:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19261; Tue, 28 Nov 2000 12:08:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19228 for ; Tue, 28 Nov 2000 12:08:31 -0500 (EST) Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03331 for ; Tue, 28 Nov 2000 12:08:28 -0500 (EST) Received: from worldnet ([12.88.173.90]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20001128170757.PHCN25510.mtiwmhc25.worldnet.att.net@worldnet>; Tue, 28 Nov 2000 17:07:57 +0000 From: "Judith Oppenheimer" To: "'Rosbotham, Paul'" , Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Date: Tue, 28 Nov 2000 12:05:26 -0500 Message-ID: <018001c0595d$6723bd80$5aad580c@att.net.icbtollfree.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <29B7C7A8E3E4D111ABDB0000F8086400072BF676@gbcwcbrtm003.isops.cwcom.co.uk> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > I wouldn't be at all happy with RespOrgs being entities in > the document, > because so far as I know, this is a concept unique to the US market. It is a concept unique to portability that recognizes subscriber control, solely, of the E.164 number. The RespOrg's sole function is to act as the subscriber's agent into the SMS/800 database for the acquisition and provisioning instructions of toll free numbers. It is a completely separate function with distinct legal obligations, from that of the TSP (reseller or switched), who provisions traffic based on the instructions programmed into the database, and who bills for that traffic. The subscriber instructs the RespOrg, who instructs the service provider (whether that entity exists within the same company or not.) ***This is the flow of information and service orders both legally, and technically.*** Only the subscriber can issue instructions to port the number to another RespOrg or carrier (or both), or to change routing or restrict inbound access, etc. And only the subscriber's RespOrg (not its TSP), can accept, and then execute those instructions in the SMS database. Where the RespOrg is also the carrier, it is the RespOrg division of the carrier, operating according to specific FCC and tariff instructions, that executes the subscriber's orders. This is not semantics, it is a legal distinction recognizing the subscriber as the *only* controlling entity of the toll free E.164 number, a concept, perhaps, that some of you may not be familiar with. But given the size and activity of the U.S. toll free market, I would suggest that ENUM would be foolish to ignore it. Judith Judith Oppenheimer, 212 684-7210, 1 800 The Expert Publisher, http://www.ICBTollFreeNews.com President, http://www.1800TheExpert.com FREE 800/Domain Classifieds, http://ICBclassifieds.com Domain Name & 800 News, Intelligence, Analysis > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > Rosbotham, Paul > Sent: Tuesday, November 28, 2000 11:20 AM > To: enum@ietf.org > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt > > > Penn, Doug & Judith > > It think that a lot of the confusion/concern arises due to > using terms that > have specific meanings in the PSTN world (or at least in some > regulatory > environments) or IP world. > > For example, TSP is being taken by some readers to have the > same meaning as > the term within the US telecoms regime. In the UK, in > contrast, a "service > provider" is simply an entity that provides telecoms services > to an end > customer. They could have a network, but (particularly in > the mobile arena) > they could simply resell the services of a network operator. > I don't know > enough about the US scenario to know whether a RespOrg is > just involved in > setting up an 800 number or ongoing manages the service for > the customer, > but it seems to me that if the latter is the case then in the > context of > this discussion a RespOrg would be a particular type of > service provider > that doesn't own their own network. > > I'd propose the following; > > - Try to make the responsibilities generic rather than slipping into > US-specific issues > - At an IETF level stick to functional responsibilities, and > worry about how > these map onto each national telecoms environments at an appropriate > national body > - Where possible, name the functional entities within the > document such that > they don't clash with physical entities in eg the > USA/Swedish/French/UK > market hence avoid the conclusion. I appreciate this point > is difficult to > do universally, plus could lead to a challenge with coming up > with a term > that adequately expresses what an entity is. > > I wouldn't be at all happy with RespOrgs being entities in > the document, > because so far as I know, this is a concept unique to the US market. > > Regards > > Paul > > > -----Original Message----- > > From: Pfautz, Penn L, NNAD [SMTP:ppfautz@att.com] > > Sent: Tuesday, November 28, 2000 3:12 PM > > To: Douglas Ranalli; Judith Oppenheimer > > Cc: enum@ietf.org > > Subject: RE: [Enum] Subject: > > I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt > > > > Doug: > > Be aware that RespOrg is a role specific to toll-free > numbers. You'll need > > a > > TSP role in any case for geographic numbers. > > The questions are "Who controls the ENUM record for a > toll-free number" > > and > > "Does the model need to be altered to specifcally > incorporate different > > roles for toll-free numbers." > > > > Penn > > > > -----Original Message----- > > From: Douglas Ranalli [mailto:dranalli@netnumber.com] > > Sent: Tuesday, November 28, 2000 9:38 AM > > To: Judith Oppenheimer > > Cc: enum@ietf.org > > Subject: Re: [Enum] Subject: > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > Judith, > > > > Thank you for the focus on this issue. If I understand > your comments > > correctly, the draft creates some confusion by using the > term "Telephone > > Service Provider" to describe the role that is being played by the > > "Responsible Organization" in the Toll-Free world. The > term "Responsible > > Organization" is certainly more generic. Please confirm if > Section 4.2 > > accurately describes the role of a Responsible Organization > in the context > > of a Tier-1 ENUM System. If so, then I propose simply > changing the term > > TSP > > to RespOrg. > > > > Doug > > > > ----- Original Message ----- > > From: Judith Oppenheimer > > To: 'Pfautz, Penn L, NNAD' > > Cc: > > Sent: Tuesday, November 28, 2000 9:05 AM > > Subject: RE: [Enum] Subject: > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > The RespOrg is empowered by tariff *only* to follow the > subscriber's > > > instructions. > > > > > > It may *not* make decisions on the subscriber's behalf. > Big difference. > > > > > > And yes, RespOrgs may be subscribers as well. For example, MCI, a > > RespOrg > > > and TSP, is the subscriber for 1 800 COLLECT, as is AT&T > for 1 800 CALL > > > ATT. > > > > > > Judith > > > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > > Publisher, http://www.ICBTollFreeNews.com > > > President, http://www.1800TheExpert.com > > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > > > > -----Original Message----- > > > > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > > > > Sent: Tuesday, November 28, 2000 8:40 AM > > > > To: Judith Oppenheimer > > > > Subject: RE: [Enum] Subject: > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > Judith: > > > > But isn't the RespOrg the User Agent who is empowered to act > > > > on the user's > > > > behalf in the role of the subscriber? > > > > I said subscriber only because in the model the actions of > > > > the user agent > > > > and subscriber are the same even though, > > > > as you point out, legal control rests with the subscriber. > > > > RespOrgs may be > > > > TSPs or ASPs but may also be subscribers. > > > > > > > > > > > > Penn > > > > -----Original Message----- > > > > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > > > > Sent: Monday, November 27, 2000 9:47 PM > > > > To: Pfautz, Penn L, NNAD; 'Richard Shockey' > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] Subject: > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > Importance: High > > > > > > > > > > > > > I think the model > > > > > proposed works if you > > > > > view the RespOrg as End User > > > > > > > > This is legally inaccurate. > > > > > > > > If the model is that inflexible, the more logical alternative > > > > is to view > > > > the RespOrg as the TSP. > > > > > > > > *********** > > > > 4.3 Subscriber > > > > > > > > - Entity with day-to-day control over an > E.164 number. > > > > > > > > 1. Individual that has been assigned an E.164 > > > > number by a TSP. > > > > > > > > 2. Enterprise that has been assign a pool of > > > > E.164 numbers > > > > by a TSP. > > > > ************ > > > > 4.3 is a fundamental principle of ENUM. It should not be > > > > compromised in > > > > order to crush a round peg into a square hole. > > > > > > > > Judith > > > > > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > > > Publisher, http://www.ICBTollFreeNews.com > > > > President, http://www.1800TheExpert.com > > > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > > > > > > > -----Original Message----- > > > > > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > > > > > Sent: Monday, November 27, 2000 9:31 PM > > > > > To: Judith Oppenheimer; 'Richard Shockey' > > > > > Cc: enum@ietf.org > > > > > Subject: RE: [Enum] Subject: > > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > > > > Judith: > > > > > I agree that the toll-free case is more complex and proposed > > > > > in my earlier > > > > > I-D (draft-pfautz-na-enum-01.txt) that the ENUM record for > > > > > the toll-free > > > > > number be controlled by the RespOrg. I think the model > > > > > proposed works if you > > > > > view the RespOrg as End User or User Agent. The RespOrg can > > > > > work with their > > > > > chosen Service Resgistrar to change the NAPTR record as > > > > > needed to point to > > > > > different carriers as appropriate, but that is really outside > > > > > of the ENUM > > > > > protocol per se. In terms of call allocation features, this > > > > > logic too will > > > > > not reside in the DNS, but perhaps in some server that the > > > > > NAPTR record > > > > > would point to. > > > > > (Some of this was discussed at the ITU working party meeting > > > > > in Berlin in > > > > > the context of international freephone). > > > > > It's also important to remember that ENUM remains an optional > > > > > functionality > > > > > - carriers and users are not obligated to use it but can > > > > > always complete > > > > > calls through the PSTN. > > > > > > > > > > Penn Pfautz > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > > > > > Sent: Monday, November 27, 2000 5:57 PM > > > > > To: 'Richard Shockey' > > > > > Cc: enum@ietf.org > > > > > Subject: RE: [Enum] Subject: > > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > > > > I do not see where this draft anticipates that the "service > > > > > provider" for a > > > > > toll free number may not be a TSP, but rather a so-called > > > > > "RespOrg" (stands > > > > > for Responsible Organization.) For that matter, the calls > > > > > may not resolve > > > > > to the end user subscriber either. > > > > > > > > > > One or more TSPs (programmed to be used at varying > times of day for > > > > > cheapest rates, for example) can simply be used as a > > > > > provisioning tool, > > > > > sending calls to one or multiple locations, none of > which are the > > > > > controlling party of the toll free number. > > > > > > > > > > Judith > > > > > > > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > > > > Publisher, http://www.ICBTollFreeNews.com > > > > > President, http://www.1800TheExpert.com > > > > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > > > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > > > > > > Sent: Monday, November 27, 2000 5:52 PM > > > > > > To: Judith Oppenheimer > > > > > > Cc: enum@ietf.org > > > > > > Subject: RE: [Enum] Subject: > > > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > > > > > > > At 05:18 PM 11/27/2000 -0500, you wrote: > > > > > > >Is this system meant to accomodate U.S. toll free numbers? > > > > > > > > > > > > > >Judith > > > > > > > > > > > > Any national ENUM system has to accommodate toll free > > > > > > numbers. 800 - 877 > > > > > > etc, numbers in the US are E.164 numbers. Its just that the > > > > > > authority for > > > > > > authorization ( record holder ) is different. > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > enum mailing list > > > > > enum@ietf.org > > > > > http://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > http://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > http://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > http://www1.ietf.org/mailman/listinfo/enum > > ********************************************************************** > This message may contain information which is confidential or > privileged. > If you are not the intended recipient, please advise the > sender immediately > by reply e-mail and delete this message and any attachments > without retaining a copy. > > ********************************************************************** > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 28 12:28:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08879 for ; Tue, 28 Nov 2000 12:28:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20617; Tue, 28 Nov 2000 12:27:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20545 for ; Tue, 28 Nov 2000 12:27:29 -0500 (EST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08609 for ; Tue, 28 Nov 2000 12:27:29 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id eASHOpr00710; Tue, 28 Nov 2000 12:24:54 -0500 (EST) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id MAA27833; Tue, 28 Nov 2000 12:23:45 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Tue, 28 Nov 2000 12:24:45 -0500 Message-ID: <1B08859602C8D211B66F0000C0769CFA046A16B9@njc240po03.mt.att.com> From: "Pfautz, Penn L, NNAD" To: "David P. Peek" , Douglas Ranalli , "Rosbotham, Paul" Cc: enum@ietf.org Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Date: Tue, 28 Nov 2000 12:24:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I've no objection to this terminology but want to point out some issues that remain: -For authentication purposes, the TNP needs to be the entity that knows who the end user is - i.e. has the customer account. This could, as Paul Rosbotham points out, be a reseller. In some nations this will raise additional questions of authentication if number administration structures do not directly interface with resellers: The TNP (reseller) can tell me what customer the number is assigned to. Do I need to verify that the reseller has been delegated the number set from the underlying carrier to which number was originally delegated or ported? Paul- can you comment from a UK perspective? Penn -----Original Message----- From: David P. Peek [mailto:dpeek@netnumber.com] Sent: Tuesday, November 28, 2000 12:01 PM To: Douglas Ranalli; Pfautz, Penn L, NNAD Cc: enum@ietf.org Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt >Can you recommend alternative names for the ENUM entity described in Section 4.2? In an effort to avoid names that have preconceived meanings and one that describes what we are trying to achieve in Section 4.2 I propose to use a new term. Are there any objections to: "Telephone Number Provider" (TNP) This would be an inclusive term for entities that provide E.164 numbers. A TNP may take on multiple roles that not only provides E.164 numbers but may also be a subscriber as in Judith's example. Dave. > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > Douglas Ranalli > Sent: Tuesday, November 28, 2000 11:10 AM > To: Pfautz, Penn L, NNAD > Cc: enum@ietf.org > Subject: Re: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > Penn, > > Thanks for the quick reply. Interesting terminology question. I > agree that > both "Responsible Organization" and "Telephone Service Provider" present > challenges from a terminology standpoint because they both have meaning > beyond the context of an ENUM System. Here's the challenge: > > Within the ENUM System there is a role for an entity that has contractual > control over a block of E.164 numbers and plays the role of > assigning those > numbers to Subscribers. (See section 4.2) > > The draft uses the term "Telephone Service Provider" to define the entity > that fulfills this role in the ENUM System. Judith Oppenheimer > has pointed > out that this role can be provided by "non-TSP" entities like "Responsible > Organizations" in the toll-free context. > > Neither term is perfect for the job but "Responsible Organization" is > certainly a broader term that can encompass a "Telephone Service > Provider". > > My preference has been to work with existing terms rather than to > define new > terms specifically for ENUM but the tradeoff is clear. Can you recommend > alternative names for the ENUM entity described in Section 4.2? > > Doug > > ----- Original Message ----- > From: Pfautz, Penn L, NNAD > To: Douglas Ranalli ; Judith Oppenheimer > > Cc: > Sent: Tuesday, November 28, 2000 10:11 AM > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > Doug: > > Be aware that RespOrg is a role specific to toll-free numbers. > You'll need > a > > TSP role in any case for geographic numbers. > > The questions are "Who controls the ENUM record for a toll-free number" > and > > "Does the model need to be altered to specifcally incorporate different > > roles for toll-free numbers." > > > > Penn > > > > -----Original Message----- > > From: Douglas Ranalli [mailto:dranalli@netnumber.com] > > Sent: Tuesday, November 28, 2000 9:38 AM > > To: Judith Oppenheimer > > Cc: enum@ietf.org > > Subject: Re: [Enum] Subject: > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > Judith, > > > > Thank you for the focus on this issue. If I understand your comments > > correctly, the draft creates some confusion by using the term "Telephone > > Service Provider" to describe the role that is being played by the > > "Responsible Organization" in the Toll-Free world. The term > "Responsible > > Organization" is certainly more generic. Please confirm if Section 4.2 > > accurately describes the role of a Responsible Organization in > the context > > of a Tier-1 ENUM System. If so, then I propose simply changing the term > TSP > > to RespOrg. > > > > Doug > > > > ----- Original Message ----- > > From: Judith Oppenheimer > > To: 'Pfautz, Penn L, NNAD' > > Cc: > > Sent: Tuesday, November 28, 2000 9:05 AM > > Subject: RE: [Enum] Subject: > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > The RespOrg is empowered by tariff *only* to follow the subscriber's > > > instructions. > > > > > > It may *not* make decisions on the subscriber's behalf. Big > difference. > > > > > > And yes, RespOrgs may be subscribers as well. For example, MCI, a > RespOrg > > > and TSP, is the subscriber for 1 800 COLLECT, as is AT&T for > 1 800 CALL > > > ATT. > > > > > > Judith > > > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > > Publisher, http://www.ICBTollFreeNews.com > > > President, http://www.1800TheExpert.com > > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > > > > -----Original Message----- > > > > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > > > > Sent: Tuesday, November 28, 2000 8:40 AM > > > > To: Judith Oppenheimer > > > > Subject: RE: [Enum] Subject: > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > Judith: > > > > But isn't the RespOrg the User Agent who is empowered to act > > > > on the user's > > > > behalf in the role of the subscriber? > > > > I said subscriber only because in the model the actions of > > > > the user agent > > > > and subscriber are the same even though, > > > > as you point out, legal control rests with the subscriber. > > > > RespOrgs may be > > > > TSPs or ASPs but may also be subscribers. > > > > > > > > > > > > Penn > > > > -----Original Message----- > > > > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > > > > Sent: Monday, November 27, 2000 9:47 PM > > > > To: Pfautz, Penn L, NNAD; 'Richard Shockey' > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] Subject: > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > Importance: High > > > > > > > > > > > > > I think the model > > > > > proposed works if you > > > > > view the RespOrg as End User > > > > > > > > This is legally inaccurate. > > > > > > > > If the model is that inflexible, the more logical alternative > > > > is to view > > > > the RespOrg as the TSP. > > > > > > > > *********** > > > > 4.3 Subscriber > > > > > > > > - Entity with day-to-day control over an E.164 number. > > > > > > > > 1. Individual that has been assigned an E.164 > > > > number by a TSP. > > > > > > > > 2. Enterprise that has been assign a pool of > > > > E.164 numbers > > > > by a TSP. > > > > ************ > > > > 4.3 is a fundamental principle of ENUM. It should not be > > > > compromised in > > > > order to crush a round peg into a square hole. > > > > > > > > Judith > > > > > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > > > Publisher, http://www.ICBTollFreeNews.com > > > > President, http://www.1800TheExpert.com > > > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > > > > > > > -----Original Message----- > > > > > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > > > > > Sent: Monday, November 27, 2000 9:31 PM > > > > > To: Judith Oppenheimer; 'Richard Shockey' > > > > > Cc: enum@ietf.org > > > > > Subject: RE: [Enum] Subject: > > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > > > > Judith: > > > > > I agree that the toll-free case is more complex and proposed > > > > > in my earlier > > > > > I-D (draft-pfautz-na-enum-01.txt) that the ENUM record for > > > > > the toll-free > > > > > number be controlled by the RespOrg. I think the model > > > > > proposed works if you > > > > > view the RespOrg as End User or User Agent. The RespOrg can > > > > > work with their > > > > > chosen Service Resgistrar to change the NAPTR record as > > > > > needed to point to > > > > > different carriers as appropriate, but that is really outside > > > > > of the ENUM > > > > > protocol per se. In terms of call allocation features, this > > > > > logic too will > > > > > not reside in the DNS, but perhaps in some server that the > > > > > NAPTR record > > > > > would point to. > > > > > (Some of this was discussed at the ITU working party meeting > > > > > in Berlin in > > > > > the context of international freephone). > > > > > It's also important to remember that ENUM remains an optional > > > > > functionality > > > > > - carriers and users are not obligated to use it but can > > > > > always complete > > > > > calls through the PSTN. > > > > > > > > > > Penn Pfautz > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com] > > > > > Sent: Monday, November 27, 2000 5:57 PM > > > > > To: 'Richard Shockey' > > > > > Cc: enum@ietf.org > > > > > Subject: RE: [Enum] Subject: > > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > > > > I do not see where this draft anticipates that the "service > > > > > provider" for a > > > > > toll free number may not be a TSP, but rather a so-called > > > > > "RespOrg" (stands > > > > > for Responsible Organization.) For that matter, the calls > > > > > may not resolve > > > > > to the end user subscriber either. > > > > > > > > > > One or more TSPs (programmed to be used at varying times > of day for > > > > > cheapest rates, for example) can simply be used as a > > > > > provisioning tool, > > > > > sending calls to one or multiple locations, none of which are the > > > > > controlling party of the toll free number. > > > > > > > > > > Judith > > > > > > > > > > Judith Oppenheimer, 212 684-7210, 1 800 The Expert > > > > > Publisher, http://www.ICBTollFreeNews.com > > > > > President, http://www.1800TheExpert.com > > > > > FREE 800/Domain Classifieds, http://ICBclassifieds.com > > > > > Domain Name & 800 News, Intelligence, Analysis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > > > > > > Sent: Monday, November 27, 2000 5:52 PM > > > > > > To: Judith Oppenheimer > > > > > > Cc: enum@ietf.org > > > > > > Subject: RE: [Enum] Subject: > > > > > > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > > > > > > > At 05:18 PM 11/27/2000 -0500, you wrote: > > > > > > >Is this system meant to accomodate U.S. toll free numbers? > > > > > > > > > > > > > >Judith > > > > > > > > > > > > Any national ENUM system has to accommodate toll free > > > > > > numbers. 800 - 877 > > > > > > etc, numbers in the US are E.164 numbers. Its just that the > > > > > > authority for > > > > > > authorization ( record holder ) is different. > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > enum mailing list > > > > > enum@ietf.org > > > > > http://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > http://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > http://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > http://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 28 13:57:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07768 for ; Tue, 28 Nov 2000 13:57:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27296; Tue, 28 Nov 2000 13:57:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27271 for ; Tue, 28 Nov 2000 13:56:59 -0500 (EST) Received: from exchange.chaos.com (exchange.chaos.com [206.5.17.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07494 for ; Tue, 28 Nov 2000 13:56:57 -0500 (EST) Received: from [216.168.250.52] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id fpdjaaaa for enum@ietf.org; Tue, 28 Nov 2000 13:56:49 -0500 Message-Id: <5.0.2.1.2.20001128133614.02711ee0@mail.netmagic.com> X-Sender: amr@mail.netmagic.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 28 Nov 2000 13:56:46 -0500 To: "David P. Peek" , "Douglas Ranalli" , "Pfautz, Penn L, NNAD" From: "A.M. Rutkowski" Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt Cc: In-Reply-To: References: <00c101c05955$bb114fa0$5a498826@netnumber.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_599119017==_.ALT" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --=====================_599119017==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:00 PM 11/28/2000, David P. Peek wrote: > "Telephone Number Provider" (TNP) Hi David, If you use the term, it should probably read "Telecommunications" rather than "Telephone" to comport with E.164's title and scope. Another option is to provide for a level of indirection and simply define an interface to a number "authenticator." This would allow both for substantially different national and marketplace approaches, and for unencumbered evolution of the specification. It's not apparent than anything more than authentication or a right to use the number for ENUM purposes is required. best, tony --=====================_599119017==_.ALT Content-Type: text/html; charset="us-ascii" At 12:00 PM 11/28/2000, David P. Peek wrote:
        "Telephone Number Provider"   (TNP)

Hi David,

If you use the term, it should probably read "Telecommunications"
rather than "Telephone" to comport with E.164's title and scope.

Another option is to provide for a level of indirection
and simply define an interface to a number "authenticator."
This would allow both for substantially different national
and marketplace approaches, and for unencumbered evolution
of the specification.  It's not apparent than anything more
than authentication or a right to use the number for ENUM
purposes is required.

best,
tony --=====================_599119017==_.ALT-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 28 14:35:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18274 for ; Tue, 28 Nov 2000 14:35:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29057; Tue, 28 Nov 2000 14:34:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29028 for ; Tue, 28 Nov 2000 14:34:40 -0500 (EST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18050 for ; Tue, 28 Nov 2000 14:34:34 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id eASJY3G01959; Tue, 28 Nov 2000 14:34:03 -0500 (EST) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id OAA10687; Tue, 28 Nov 2000 14:33:02 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Tue, 28 Nov 2000 14:34:02 -0500 Message-ID: <1B08859602C8D211B66F0000C0769CFA03A95151@njc240po03.mt.att.com> From: "Ash, Gerald R (Jerry), ALCOO" To: "'Richard Shockey'" Cc: "Ash, Gerald R (Jerry), ALCOO" , enum@ietf.org Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Date: Tue, 28 Nov 2000 14:33:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 9:44 PM 11/27/2000, Richard Shockey wrote: > If there is a problem it is one of semantics and understanding the new > service logic of Internet Telephony. > > Assume the case of 1 800 DOG-BONES that wishes to provision ENUM services > to accept calls using SIP. > > That number has been delegated to that "subscriber" under the normal terms > and conditions of 800 service ..so the "controlling party" is known to the > 800 SMS and can be verified. The key to ENUM authority is that this > verification can be successfully accomplished and that proper authorization > can be delegated from the T1 to the T2 entity that actually holds the > Resource Records that provision real service. > > Once this is accomplished we can assume that 1 800 DOG-BONES resolves to a > SIP URL either under the direct control of the "controlling party", to use > your terms, or to a T2 ENUM service provider that maintains these records > under contract for this service under various SLA's etc. > > The SIP proxy that ENUM resolves to will maintain the real service logic of > call routing necessary to complete the call based on the numbers > "controlling party" requirements.[ time of day etc] And the syntax of that > service logic is defined by the IPTEL WG as Call Progress Language. > > http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-04.txt > > The CPL is the real provisioning tool for Call Progress and routing as you > outline. And the promise of this whole exercise in standards development is > that service logic now resides within the complete control of the 1 800 > number holder ..and not the carrier from whom service was delivered. Is CPL the only choice for service logic? Suppose the number holder wants service logic retained in IN/SCP, as is normal today for 800-time-of-day routing; how does that work (e.g., with a SIP URL)? Jerry Ash _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 28 15:03:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26831 for ; Tue, 28 Nov 2000 15:03:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00250; Tue, 28 Nov 2000 15:02:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00216 for ; Tue, 28 Nov 2000 15:02:24 -0500 (EST) Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26493 for ; Tue, 28 Nov 2000 15:02:25 -0500 (EST) Received: from worldnet ([12.88.173.90]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20001128200154.RCGE25510.mtiwmhc25.worldnet.att.net@worldnet>; Tue, 28 Nov 2000 20:01:54 +0000 From: "Judith Oppenheimer" To: "'Ash, Gerald R (Jerry), ALCOO'" , "'Richard Shockey'" Cc: Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt Date: Tue, 28 Nov 2000 14:59:23 -0500 Message-ID: <01b501c05975$b4dcf880$5aad580c@att.net.icbtollfree.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <1B08859602C8D211B66F0000C0769CFA03A95151@njc240po03.mt.att.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > That number has been delegated to that "subscriber" under the normal terms > and conditions of 800 service ..so the "controlling party" is known to the > 800 SMS and can be verified. NO. The "controlling party" is the subscriber. The subscriber is not known to the 800 SMS. Judith Oppenheimer, 212 684-7210, 1 800 The Expert Publisher, http://www.ICBTollFreeNews.com President, http://www.1800TheExpert.com FREE 800/Domain Classifieds, http://ICBclassifieds.com Domain Name & 800 News, Intelligence, Analysis > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On > Behalf Of Ash, > Gerald R (Jerry), ALCOO > Sent: Tuesday, November 28, 2000 2:34 PM > To: 'Richard Shockey' > Cc: Ash, Gerald R (Jerry), ALCOO; enum@ietf.org > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > At 9:44 PM 11/27/2000, Richard Shockey wrote: > > > If there is a problem it is one of semantics and > understanding the new > > service logic of Internet Telephony. > > > > Assume the case of 1 800 DOG-BONES that wishes to provision > ENUM services > > to accept calls using SIP. > > > > That number has been delegated to that "subscriber" under > the normal terms > > > and conditions of 800 service ..so the "controlling party" > is known to the > > > 800 SMS and can be verified. The key to ENUM authority is > that this > > verification can be successfully accomplished and that proper > authorization > > can be delegated from the T1 to the T2 entity that actually > holds the > > Resource Records that provision real service. > > > > Once this is accomplished we can assume that 1 800 > DOG-BONES resolves to a > > > SIP URL either under the direct control of the "controlling > party", to use > > > your terms, or to a T2 ENUM service provider that maintains > these records > > under contract for this service under various SLA's etc. > > > > The SIP proxy that ENUM resolves to will maintain the real > service logic > of > > call routing necessary to complete the call based on the numbers > > "controlling party" requirements.[ time of day etc] And > the syntax of > that > > service logic is defined by the IPTEL WG as Call Progress Language. > > > > http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-04.txt > > > > The CPL is the real provisioning tool for Call Progress and > routing as you > > > outline. And the promise of this whole exercise in > standards development > is > > that service logic now resides within the complete control > of the 1 800 > > number holder ..and not the carrier from whom service was delivered. > > > Is CPL the only choice for service logic? Suppose the number > holder wants > service logic retained in IN/SCP, as is normal today for > 800-time-of-day > routing; how does that work (e.g., with a SIP URL)? > > Jerry Ash > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 28 23:28:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09403 for ; Tue, 28 Nov 2000 23:28:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14321; Tue, 28 Nov 2000 23:27:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14293 for ; Tue, 28 Nov 2000 23:27:37 -0500 (EST) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09110 for ; Tue, 28 Nov 2000 23:27:36 -0500 (EST) Received: from computer.ix.netcom.com (user-2ivelvn.dialup.mindspring.com [165.247.87.247]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id XAA08328; Tue, 28 Nov 2000 23:26:48 -0500 (EST) Message-Id: <5.0.0.25.2.20001128230258.02778eb0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 28 Nov 2000 23:28:04 -0500 To: "Pfautz, Penn L, NNAD" , "David P. Peek" , Douglas Ranalli , "Rosbotham, Paul" From: Richard Shockey Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Cc: enum@ietf.org In-Reply-To: <1B08859602C8D211B66F0000C0769CFA046A16B9@njc240po03.mt.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 12:24 PM 11/28/2000 -0500, Pfautz, Penn L, NNAD wrote: >I've no objection to this terminology but want to point out some issues that >remain: > >-For authentication purposes, the TNP needs to be the entity that knows who >the end user is - i.e. has the customer account. This could, as Paul >Rosbotham points out, be a reseller. In some nations this will raise >additional questions of authentication if number administration structures >do not directly interface with resellers: The TNP (reseller) can tell me >what customer the number is assigned to. Do I need to verify that the >reseller has been delegated the number set from the underlying carrier to >which number was originally delegated or ported? > >Paul- can you comment from a UK perspective? Please do. ... It seems we have a classic clash of NetHeads vs BellHeads here and if we are ever going to try and explain all of this to our poor over worked, underpaid and under appreciated national regulators we really should agree on common definitions. AKA ..TNP "Telephone Number Provider" TNP "Telephone Number Holder" etc. I've had one comment to me privately that "EU" in the Pfautz-Yu draft looks like " European Union" .. so maybe that may not be the best term. We need to explain ourselves to a new and rather diverse group of people ..of which Judith is a good example. Common ground means common definitions ..so any attempt at defining terms here is most welcome. The Liaison Statement from ITU-SG2-Q1 is quite clear. Delegation of authority for the e164.arpa space for geographic codes is the prerogative of nation-states and they will, presumably, be looking to this group and this list for answers to their questions. I have taken the position that administrative drafts should be discussed here at length, but within the context of technical issues. If you all read the WG charter ...we are bending the rules to a considerable extent but under the unique and frankly historical circumstances that RFC 2916 poses, this course of action seems reasonable. This begs the question of how far should this work go..and that poses the question of the direction the WG should take. What therefore, are the next steps? Your Chair... >Penn > >-----Original Message----- >From: David P. Peek [mailto:dpeek@netnumber.com] >Sent: Tuesday, November 28, 2000 12:01 PM >To: Douglas Ranalli; Pfautz, Penn L, NNAD >Cc: enum@ietf.org >Subject: RE: [Enum] Subject: >I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > >Can you recommend alternative names for the ENUM entity described in >Section 4.2? > > >In an effort to avoid names that have preconceived meanings and one that >describes what we are trying to achieve in Section 4.2 I propose to use a >new term. Are there any objections to: > > "Telephone Number Provider" (TNP) > >This would be an inclusive term for entities that provide E.164 numbers. A >TNP may take on multiple roles that not only provides E.164 numbers but may >also be a subscriber as in Judith's example. > >Dave. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Nov 28 23:32:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA11055 for ; Tue, 28 Nov 2000 23:32:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14634; Tue, 28 Nov 2000 23:31:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14603 for ; Tue, 28 Nov 2000 23:31:54 -0500 (EST) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA10960 for ; Tue, 28 Nov 2000 23:31:54 -0500 (EST) Received: from computer.ix.netcom.com (user-2ivelvn.dialup.mindspring.com [165.247.87.247]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id XAA10480; Tue, 28 Nov 2000 23:31:47 -0500 (EST) Message-Id: <5.0.0.25.2.20001128152151.022fede0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 28 Nov 2000 15:26:33 -0500 To: "Ash, Gerald R (Jerry), ALCOO" From: Richard Shockey Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Cc: enum@ietf.org In-Reply-To: <1B08859602C8D211B66F0000C0769CFA03A95151@njc240po03.mt.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > > The CPL is the real provisioning tool for Call Progress and routing as you > > > outline. And the promise of this whole exercise in standards development >is > > that service logic now resides within the complete control of the 1 800 > > number holder ..and not the carrier from whom service was delivered. > > >Is CPL the only choice for service logic? Suppose the number holder wants >service logic retained in IN/SCP, as is normal today for 800-time-of-day >routing; how does that work (e.g., with a SIP URL)? In SIP CPL is the language for service logic presuming an IP model. Presumably the SIP proxy under the control of the 800 "number holder" could use some method to acquire IN/SCP logic but I'm not aware of what that interface would be ..that is a good question for some of our SIGTRAN fiends. >Jerry Ash > >_______________________________________________ >enum mailing list >enum@ietf.org >http://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 202.533.2811 Fax to EMail 815.333.1237 (Preferred for Fax) Cell : 314.503.0640 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Nov 29 02:03:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25332 for ; Wed, 29 Nov 2000 02:03:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23499; Wed, 29 Nov 2000 02:02:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23468 for ; Wed, 29 Nov 2000 02:02:49 -0500 (EST) Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24504 for ; Wed, 29 Nov 2000 02:02:48 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA21601; Wed, 29 Nov 2000 02:05:09 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 02:00:45 -0500 Message-ID: From: Jonathan Rosenberg To: "'Richard Shockey'" , "Ash, Gerald R (Jerry), ALCOO" Cc: enum@ietf.org Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Date: Wed, 29 Nov 2000 02:00:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > -----Original Message----- > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > Sent: Tuesday, November 28, 2000 3:27 PM > To: Ash, Gerald R (Jerry), ALCOO > Cc: enum@ietf.org > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt > > > > > > > > The CPL is the real provisioning tool for Call Progress > and routing as you > > > > > outline. And the promise of this whole exercise in > standards development > >is > > > that service logic now resides within the complete > control of the 1 800 > > > number holder ..and not the carrier from whom service was > delivered. > > > > > >Is CPL the only choice for service logic? Suppose the > number holder wants > >service logic retained in IN/SCP, as is normal today for > 800-time-of-day > >routing; how does that work (e.g., with a SIP URL)? > > In SIP CPL is the language for service logic presuming an IP model. > Presumably the SIP proxy under the control of the 800 "number > holder" could > use some method to acquire IN/SCP logic but I'm not aware of > what that > interface would be ..that is a good question for some of our > SIGTRAN fiends. CPL isn't the only choice. IETF doesn't mandate these things in any case. Beyond CPL, there are IETF efforts like SIP servlets and SIP CGI, IN/SCP integration efforts like those discussed at the sin bof at the last IETF, and other industry APIs such as Parlay, JAIN, and so on. Just thought I'd clarify. Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Nov 29 04:26:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06655 for ; Wed, 29 Nov 2000 04:26:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25300; Wed, 29 Nov 2000 04:26:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25271 for ; Wed, 29 Nov 2000 04:26:00 -0500 (EST) Received: from mx.cwplc.com (mx.cwplc.com [194.6.6.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06413 for ; Wed, 29 Nov 2000 04:25:58 -0500 (EST) Received: from gb-cwc-brt-msw2.isops.cwcom.co.uk ([148.185.176.7]) by mx.cwplc.com (Switch-2.0.6/Switch-2.0.6) with ESMTP id eAT9MSU01838 for ; Wed, 29 Nov 2000 09:22:28 GMT Received: from gbcwcbrti002.isops.cwcom.co.uk (unverified) by gb-cwc-brt-msw2.isops.cwcom.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 29 Nov 2000 09:16:43 +0000 Received: by gbcwcbrti002.isops.cwcom.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 09:25:02 -0000 Message-Id: <29B7C7A8E3E4D111ABDB0000F8086400072BF678@gbcwcbrtm003.isops.cwcom.co.uk> From: "Rosbotham, Paul" To: enum@ietf.org Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Date: Wed, 29 Nov 2000 09:26:16 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org It seems to me that this matter needs a great deal of thought. At an IETF level, I think we're probably best taking a "functional entity" approach, and abstracting things to such a level that national arrangements can be made to map onto the overall international framework. To a degree, this is what has happened at ITU with the terms that Valerie Barnole highlighted. I like Tony Rutkowski's idea of replacing TNP/TSP with the functional entity "Authenticator". How this is enacted physically in each national environment will vary; - In the "simple" geographic number case with no resellers involved, then the Authenticator will be the Telephone Service Provider. - Where resellers are involved, matters would be more complex. I can't remember the precise solution and my guru isn't in the office this morning, but I think the UK tied itself in knots over authentication for number portability where you have a reseller involved in the value chain. I think we ended up with a process involving verification of the customer's number ownership from the reseller, but in turn the reseller having to show documentation to prove assignment from the network provider (ie secondary documentation to prove their qualification to validate). Suffice to say that for our purposes, the national implementation would be a two stage authentication with the "Authenticator" having to first prove their credentials to provide this role and then subsequently validating the requst. (In reality, if you say that the reseller is the Telecoms Service Provider, then this is actually the same as the simple case, with the only difference being that the database to map the number to a given TSP is a two phase lookup, being from the National Numbering Plan Administrator via a network operator rather than direct from the NPPA as in the simple case). - In the US 800 system, the Authenticator function would involve the RespOrg. Without knowing the details of the process, I don't know for sure whether the RespOrg would be the Authenticator, or whether the functions would be split across the RespOrg and one or more TSPs. - In the ITU-T Universal International Freephone Service (country code 800), the Authenticator may have to be the ITU themselves, as only they have visibility of which customer a number is assigned to. For information, it is quite plausible for UIFS for a given number to be served my multiple TSPs, say on a continent by continent basis. This means that for the secondary function of the Authenticator relating to Termination, a single network operator could possibly not (at least under the existing processes - the situation will change under forthcoming revisions) have visibility of whether a customer has ceased service with them alone, or with all providers hence returned the number - only the ITU would know this. Unfortunately, I'm only in the office for half an hour today and then out for a few days, so I haven't had chance to see if the proposed changes would flow correctly through the I-D. However, I was conscious that a couple of people had asked for input from me and didn't want to hold up the debate via my schedule! Regards Paul > -----Original Message----- > From: Richard Shockey [SMTP:rshockey@ix.netcom.com] > Sent: Wednesday, November 29, 2000 4:28 AM > To: Pfautz, Penn L, NNAD; David P. Peek; Douglas Ranalli; Rosbotham, > Paul > Cc: enum@ietf.org > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt > > At 12:24 PM 11/28/2000 -0500, Pfautz, Penn L, NNAD wrote: > >I've no objection to this terminology but want to point out some issues > that > >remain: > > > >-For authentication purposes, the TNP needs to be the entity that knows > who > >the end user is - i.e. has the customer account. This could, as Paul > >Rosbotham points out, be a reseller. In some nations this will raise > >additional questions of authentication if number administration > structures > >do not directly interface with resellers: The TNP (reseller) can tell me > >what customer the number is assigned to. Do I need to verify that the > >reseller has been delegated the number set from the underlying carrier to > >which number was originally delegated or ported? > > > >Paul- can you comment from a UK perspective? > > > Please do. ... It seems we have a classic clash of NetHeads vs BellHeads > here and if we are ever going to try and explain all of this to our poor > over worked, underpaid and under appreciated national regulators we really > > should agree on common definitions. > > AKA ..TNP "Telephone Number Provider" > > TNP "Telephone Number Holder" etc. > > I've had one comment to me privately that "EU" in the Pfautz-Yu draft > looks > like " European Union" .. so maybe that may not be the best term. > > We need to explain ourselves to a new and rather diverse group of people > ..of which Judith is a good example. > > Common ground means common definitions ..so any attempt at defining terms > here is most welcome. > > The Liaison Statement from ITU-SG2-Q1 is quite clear. Delegation of > authority for the e164.arpa space for geographic codes is the prerogative > of nation-states and they will, presumably, be looking to this group and > this list for answers to their questions. > > I have taken the position that administrative drafts should be discussed > here at length, but within the context of technical issues. If you all > read the WG charter ...we are bending the rules to a considerable extent > but under the unique and frankly historical circumstances that RFC 2916 > poses, this course of action seems reasonable. > > This begs the question of how far should this work go..and that poses the > question of the direction the WG should take. > > What therefore, are the next steps? > > > Your Chair... > > > >Penn > > > >-----Original Message----- > >From: David P. Peek [mailto:dpeek@netnumber.com] > >Sent: Tuesday, November 28, 2000 12:01 PM > >To: Douglas Ranalli; Pfautz, Penn L, NNAD > >Cc: enum@ietf.org > >Subject: RE: [Enum] Subject: > >I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > >Can you recommend alternative names for the ENUM entity described in > >Section 4.2? > > > > > >In an effort to avoid names that have preconceived meanings and one that > >describes what we are trying to achieve in Section 4.2 I propose to use a > >new term. Are there any objections to: > > > > "Telephone Number Provider" (TNP) > > > >This would be an inclusive term for entities that provide E.164 numbers. > A > >TNP may take on multiple roles that not only provides E.164 numbers but > may > >also be a subscriber as in Judith's example. > > > >Dave. ********************************************************************** This message may contain information which is confidential or privileged. If you are not the intended recipient, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy. ********************************************************************** _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Nov 29 06:30:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01367 for ; Wed, 29 Nov 2000 06:30:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26831; Wed, 29 Nov 2000 06:28:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26801 for ; Wed, 29 Nov 2000 06:28:10 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00045; Wed, 29 Nov 2000 06:28:10 -0500 (EST) Message-Id: <200011291128.GAA00045@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: Wed, 29 Nov 2000 06:28:09 -0500 Subject: [Enum] I-D ACTION:draft-lind-enum-callflows-01.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ENUM Call Flows for VoIP Interworking Author(s) : S. Lind Filename : draft-lind-enum-callflows-01.txt Pages : 11 Date : 28-Nov-00 This document provides illustrations of the use of ENUM functionality and identifies issues associated with such use. To accomplish this objective, the document presents service-level call flows for Voice over IP communication where interworking between the PSTN and IP-based networks are necessary to complete a call. Details are presented for simple calls made on a 'direct dial' basis. For more complicated calls, requiring number portability or freephone call processing, the issues are described with the intent of working through those issues in subsequent drafts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lind-enum-callflows-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lind-enum-callflows-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lind-enum-callflows-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <20001128133743.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lind-enum-callflows-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-lind-enum-callflows-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128133743.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Nov 29 12:11:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14980 for ; Wed, 29 Nov 2000 12:11:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03082; Wed, 29 Nov 2000 12:10:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03049 for ; Wed, 29 Nov 2000 12:10:33 -0500 (EST) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14575 for ; Wed, 29 Nov 2000 12:10:28 -0500 (EST) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 18:09:25 +0100 Message-ID: <98388C05D464D111B61800805F1504160233A100@p-ibis.issy.cnet.fr> From: BARNOLE Valerie FTRD/DAC/ISS To: "'john.loughney@nokia.com'" , james.yu@neustar.com, enum@ietf.org Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt Date: Wed, 29 Nov 2000 18:09:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA03050 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id MAA03082 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14980 John, I am sorry, I can't retrieve your draft-loughney-enum-roaming-00.txt. Can you send it, please ? I suppose that in this draft, you populate the DNS with E.212 or E.214 numbers. I do not have your draft to see how you deal with the confidentiality of the IMSI, but my first idea is that mobile operators should be very reluctant to populate the DNS with such confidential data. Thank you for sending me your draft. Regards, Valerie. end of message _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Valérie Barnole FTR&D/DAC/ACE tel. : + 33 1 45 29 58 39 fax : + 33 1 46 29 31 42 mail to : valerie.barnole@francetelecom.fr -----Message d'origine----- De : john.loughney@nokia.com [mailto:john.loughney@nokia.com] Envoyé : mardi 7 novembre 2000 08:34 Ŕ : james.yu@neustar.com; enum@ietf.org Cc : john.loughney@nokia.com Objet : [Enum] RE: draft-loughney-enum-roaming-00.txt Hi James & everyone, > One reason that GTT is used in SS7 message transport is > because the message routing in many cases involve two > cellular networks in different countries. A SS7 point code > in U.K. cannot be used directly by a SS7 node in France to > send a SS7 message to. IP will change that because IP is > global. This is just one example of use of ENUM. Another > example is to identify the message center that serves a > particular cellular subscriber when there is a short > message destined towards that subscriber. In this example, > the E.164 number is assigned to an cellular subscriber; > however, the service that uses ENUM is again a "network-related > service." Thanks for summarizing the intention of this draft. You did a much better job that what I did at Pittsburgh :) I also want to mention that this issues will get much more complicated in the proposed 3G networks. There will be operators implementing all of their networks over IP. In your scenario, there will need to be some negotiation/ mapping between the SS7 addresses and IP address that will be assigned for the VLR/HLR. One further complication is that there may be AAA servers providing the same functionality for 3G cellular subscribers. I would like to think that ENUM could be a techology that is used to promote interoperability/interworking for this purpose. > John and I would like to hear from you to see whether they is > any problem to move this I-D forward. thanks, John _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Nov 29 12:12:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15457 for ; Wed, 29 Nov 2000 12:12:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03186; Wed, 29 Nov 2000 12:11:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03153 for ; Wed, 29 Nov 2000 12:11:45 -0500 (EST) Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15035 for ; Wed, 29 Nov 2000 12:11:43 -0500 (EST) Received: from worldnet ([12.88.174.57]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20001129171113.WGCQ20084.mtiwmhc26.worldnet.att.net@worldnet>; Wed, 29 Nov 2000 17:11:13 +0000 From: "Judith Oppenheimer" To: "'Rosbotham, Paul'" , Subject: RE: [Enum] Subject: I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Date: Wed, 29 Nov 2000 12:08:39 -0500 Message-ID: <027801c05a27$05372ba0$39ae580c@att.net.icbtollfree.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <29B7C7A8E3E4D111ABDB0000F8086400072BF678@gbcwcbrtm003.isops.cwcom.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > - In the US 800 system, the Authenticator function would involve the > RespOrg. Without knowing the details of the process, I don't > know for sure > whether the RespOrg would be the Authenticator, or whether > the functions > would be split across the RespOrg and one or more TSPs. > Suffice to say > that for our purposes, the national implementation would be a > two stage > authentication with the "Authenticator" having to first prove their > credentials to provide this role and then subsequently validating the > requst. Only the RespOrg can verify toll free number assignment and would therefore be the Authenticator, but would have to show two sets of credentials as well: 1. an LOA - Letter of Assignment - signed by the subscriber of the toll free number. Note that it is the subscriber of the toll free number, not a TSP, who authorizes the RespOrg to function in this capacity. 2. AND verification from the 800 SMS reflecting matching RespOrg ID status for that number in the 800 SMS database. While slamming receives all the press, 800 number "loss" and theft by RespOrgs, TSP's and subscribers large and small, is not an uncommon occurrence in the U.S. (Overzealous account execs like to use vanity 800 numbers to keep existing corporate clients, and as incentives to sign new ones. Forged LOA's and "manipulated" invoices are just two of the many ways this is done. I actually have a letter on file from a Sprint regulatory attorney explaining why (he thought) it was within Sprint's rights to take an 800 number newly ported into the company from a small customer, and give it to a larger (existing Sprint customer) competitor of that new customer. He didn't even recognize it as theft. The CEO's office did: eight months after the theft, the number was returned to the rightful subscriber.) That said, it should be noted that RespOrgs which are also carriers, like to use phone bills as proof of subscribership. This is useful *if* the subscriber is the billing party, BUT it is a limited verification method since the subscriber is not always the billing party, and visa versa. Judith Judith Oppenheimer, 212 684-7210, 1 800 The Expert Publisher, http://www.ICBTollFreeNews.com President, http://www.1800TheExpert.com FREE 800/Domain Classifieds, http://ICBclassifieds.com Domain Name & 800 News, Intelligence, Analysis > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > Rosbotham, Paul > Sent: Wednesday, November 29, 2000 4:26 AM > To: enum@ietf.org > Subject: RE: [Enum] Subject: > I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt > > > It seems to me that this matter needs a great deal of > thought. At an IETF > level, I think we're probably best taking a "functional > entity" approach, > and abstracting things to such a level that national > arrangements can be > made to map onto the overall international framework. To a > degree, this is > what has happened at ITU with the terms that Valerie Barnole > highlighted. > > I like Tony Rutkowski's idea of replacing TNP/TSP with the > functional entity > "Authenticator". How this is enacted physically in each national > environment will vary; > > - In the "simple" geographic number case with no resellers > involved, then > the Authenticator will be the Telephone Service Provider. > > - Where resellers are involved, matters would be more > complex. I can't > remember the precise solution and my guru isn't in the office > this morning, > but I think the UK tied itself in knots over authentication for number > portability where you have a reseller involved in the value > chain. I think > we ended up with a process involving verification of the > customer's number > ownership from the reseller, but in turn the reseller having to show > documentation to prove assignment from the network provider > (ie secondary > documentation to prove their qualification to validate). > Suffice to say > that for our purposes, the national implementation would be a > two stage > authentication with the "Authenticator" having to first prove their > credentials to provide this role and then subsequently validating the > requst. (In reality, if you say that the reseller is the > Telecoms Service > Provider, then this is actually the same as the simple case, > with the only > difference being that the database to map the number to a > given TSP is a two > phase lookup, being from the National Numbering Plan > Administrator via a > network operator rather than direct from the NPPA as in the > simple case). > > - In the US 800 system, the Authenticator function would involve the > RespOrg. Without knowing the details of the process, I don't > know for sure > whether the RespOrg would be the Authenticator, or whether > the functions > would be split across the RespOrg and one or more TSPs. > > - In the ITU-T Universal International Freephone Service > (country code 800), > the Authenticator may have to be the ITU themselves, as only they have > visibility of which customer a number is assigned to. For > information, it > is quite plausible for UIFS for a given number to be served > my multiple > TSPs, say on a continent by continent basis. This means that for the > secondary function of the Authenticator relating to > Termination, a single > network operator could possibly not (at least under the > existing processes - > the situation will change under forthcoming revisions) have > visibility of > whether a customer has ceased service with them alone, or > with all providers > hence returned the number - only the ITU would know this. > > Unfortunately, I'm only in the office for half an hour today > and then out > for a few days, so I haven't had chance to see if the > proposed changes would > flow correctly through the I-D. However, I was conscious > that a couple of > people had asked for input from me and didn't want to hold up > the debate via > my schedule! > > Regards > > Paul > > -----Original Message----- > > From: Richard Shockey [SMTP:rshockey@ix.netcom.com] > > Sent: Wednesday, November 29, 2000 4:28 AM > > To: Pfautz, Penn L, NNAD; David P. Peek; Douglas Ranalli; Rosbotham, > > Paul > > Cc: enum@ietf.org > > Subject: RE: [Enum] Subject: > > I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt > > > > At 12:24 PM 11/28/2000 -0500, Pfautz, Penn L, NNAD wrote: > > >I've no objection to this terminology but want to point > out some issues > > that > > >remain: > > > > > >-For authentication purposes, the TNP needs to be the > entity that knows > > who > > >the end user is - i.e. has the customer account. This > could, as Paul > > >Rosbotham points out, be a reseller. In some nations this > will raise > > >additional questions of authentication if number administration > > structures > > >do not directly interface with resellers: The TNP > (reseller) can tell me > > >what customer the number is assigned to. Do I need to > verify that the > > >reseller has been delegated the number set from the > underlying carrier to > > >which number was originally delegated or ported? > > > > > >Paul- can you comment from a UK perspective? > > > > > > Please do. ... It seems we have a classic clash of NetHeads > vs BellHeads > > here and if we are ever going to try and explain all of > this to our poor > > over worked, underpaid and under appreciated national > regulators we really > > > > should agree on common definitions. > > > > AKA ..TNP "Telephone Number Provider" > > > > TNP "Telephone Number Holder" etc. > > > > I've had one comment to me privately that "EU" in the > Pfautz-Yu draft > > looks > > like " European Union" .. so maybe that may not be the best term. > > > > We need to explain ourselves to a new and rather diverse > group of people > > ..of which Judith is a good example. > > > > Common ground means common definitions ..so any attempt at > defining terms > > here is most welcome. > > > > The Liaison Statement from ITU-SG2-Q1 is quite clear. > Delegation of > > authority for the e164.arpa space for geographic codes is > the prerogative > > of nation-states and they will, presumably, be looking to > this group and > > this list for answers to their questions. > > > > I have taken the position that administrative drafts should > be discussed > > here at length, but within the context of technical issues. > If you all > > read the WG charter ...we are bending the rules to a > considerable extent > > but under the unique and frankly historical circumstances > that RFC 2916 > > poses, this course of action seems reasonable. > > > > This begs the question of how far should this work go..and > that poses the > > question of the direction the WG should take. > > > > What therefore, are the next steps? > > > > > > Your Chair... > > > > > > >Penn > > > > > >-----Original Message----- > > >From: David P. Peek [mailto:dpeek@netnumber.com] > > >Sent: Tuesday, November 28, 2000 12:01 PM > > >To: Douglas Ranalli; Pfautz, Penn L, NNAD > > >Cc: enum@ietf.org > > >Subject: RE: [Enum] Subject: > > >I-DACTION:draft-ranalli-peek-walter-enum-t1roles-00.txt > > > > > > > > > > > > > > > >Can you recommend alternative names for the ENUM entity > described in > > >Section 4.2? > > > > > > > > >In an effort to avoid names that have preconceived > meanings and one that > > >describes what we are trying to achieve in Section 4.2 I > propose to use a > > >new term. Are there any objections to: > > > > > > "Telephone Number Provider" (TNP) > > > > > >This would be an inclusive term for entities that provide > E.164 numbers. > > A > > >TNP may take on multiple roles that not only provides > E.164 numbers but > > may > > >also be a subscriber as in Judith's example. > > > > > >Dave. > > ********************************************************************** > This message may contain information which is confidential or > privileged. > If you are not the intended recipient, please advise the > sender immediately > by reply e-mail and delete this message and any attachments > without retaining a copy. > > ********************************************************************** > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Nov 29 12:48:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29819 for ; Wed, 29 Nov 2000 12:48:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04388; Wed, 29 Nov 2000 12:48:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04359 for ; Wed, 29 Nov 2000 12:48:20 -0500 (EST) Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29569 for ; Wed, 29 Nov 2000 12:48:15 -0500 (EST) Received: from dranalli ([38.136.73.90]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001129174742.QIUH1216.hvmta01-stg@dranalli> for ; Wed, 29 Nov 2000 12:47:42 -0500 Message-ID: <010801c05a2c$032ebf30$5a498826@netnumber.com> Reply-To: "Douglas Ranalli" From: "Douglas Ranalli" To: Date: Wed, 29 Nov 2000 12:44:24 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0105_01C05A02.1A1BAE30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [Enum] I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0105_01C05A02.1A1BAE30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Great comments on terminology. Here's an initial attempt to achieve = closure on the terminology for the entity described under Section 4.2 = that issues an E.164 number to a Subscriber: "Section 4.2: Telecommunications Number Provider (TNP):" Reason #1: The term is perfectly descriptive for the role defined under = Section 4.2. =20 Reason #2: The term is broad enough to encompass multiple types of = organizations that might provide this role in the context of an ENUM = System. For example: Telephone Service Providers, Application Service = Providers, Responsible Organizations, Resellers, etc. Reason #3: The term seemed to achieve a certain level of support from = the group. Reason #4: The alternate proposal of "authenticator" may have a = tendency to create confusion with the "Registrar" role described under = Section 4.7.=20 Please respond back if you'd like to continue the discussion on the use = of this term. Otherwise, I'll make the change in the next turn of the = draft. Doug Douglas J. Ranalli Founder & Chief Strategy Officer NetNumber 650 Suffolk Street, Suite 307 Lowell, MA 01854 dranalli@netnumber.com www.netnumber.com 978-454-4210 ext 22 978-454-5044 (fax) ------=_NextPart_000_0105_01C05A02.1A1BAE30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Great comments on terminology.  Here's an initial attempt to = achieve=20 closure on the terminology for the entity described under Section 4.2 = that=20 issues an E.164 number to a Subscriber:

"Section 4.2:  Telecommunications Number = Provider=20 (TNP):"

Reason #1:  = The=20 term is perfectly descriptive for the role=20 defined under Section 4.2. 

Reason #2:  = The=20 term is broad enough to encompass multiple types of organizations that = might=20 provide this role in the context of an ENUM System.  For example:  Telephone Service Providers, = Application=20 Service Providers, Responsible Organizations, Resellers, etc.

Reason #3:  = The=20 term seemed to achieve a certain level of support from the group.

Reason #4:  = The=20 alternate proposal of "authenticator" may have a tendency to create = confusion=20 with the "Registrar" role described under Section 4.7.

Please respond back if you'd like to continue the=20 discussion on the use of this = term. =20 Otherwise, I'll make the change in the next turn of the = draft.

Doug

Douglas J. Ranalli
Founder & = Chief Strategy=20 Officer
NetNumber
650 Suffolk Street, Suite 307
Lowell, = MA =20 01854
dranalli@netnumber.com
www.netnumber.com
978-454-4210 = ext=20 22
978-454-5044 (fax)
------=_NextPart_000_0105_01C05A02.1A1BAE30-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Nov 29 13:10:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05866 for ; Wed, 29 Nov 2000 13:10:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05159; Wed, 29 Nov 2000 13:09:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05132 for ; Wed, 29 Nov 2000 13:09:54 -0500 (EST) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05573 for ; Wed, 29 Nov 2000 13:09:50 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 19:08:04 +0100 Message-ID: <98388C05D464D111B61800805F1504160233A103@p-ibis.issy.cnet.fr> From: BARNOLE Valerie FTRD/DAC/ISS To: "'Douglas Ranalli'" , enum@ietf.org Subject: RE: [Enum] I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.t xt Date: Wed, 29 Nov 2000 19:07:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05A2F.4EBDACB0" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C05A2F.4EBDACB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Douglas, as i think my former message didnot reach the ENUM list because of the = files attached, I copy it here. It is a proposal of mapping of terminology = with some terms used in ITU rec on UIFN. =20 It proposes either to use "Service Access Provider" either to quote a mapping with the ITU terminology in order everybody understand from the "Bellheads" :-) =20 I'd like to be sure that the term RespOrg will not be understood or flavoured as "Regulator", because at the end of the day, except from resources directly given by the ITU, they are the one entity who = provide the telecommunication numbers. =20 ***************Copy of my former mail : =20 Judith,Paul, do you see any possible use of the terminology used through ITU recommendations E.152, E.169 (universal international freephone = service) or any possible mapping between the entities you describe and the ones who = play a part in these recommendations ? This could provide a universal understanding. For instance, =A74.3 of Rec. E.152 defines "Service Provider A" as = having a role quite similar to that of RespOrg.=20 SP A has recently be changed to "International Freephone Service access provider", after a contribution from Teledenmark to add portability guidelines, (UIFNportb057_ww9.doc that I join here). Valerie. =20 end of message=20 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _=20 Val=E9rie Barnole=20 FTR&D/DAC/ACE=20 tel. : + 33 1 45 29 58 39=20 fax : + 33 1 46 29 31 42=20 mail to : valerie.barnole@francetelecom.fr=20 -----Message d'origine----- De : Douglas Ranalli [mailto:dranalli@netnumber.com] Envoy=E9 : mercredi 29 novembre 2000 18:44 =C0 : enum@ietf.org Objet : [Enum] I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Great comments on terminology. Here's an initial attempt to achieve = closure on the terminology for the entity described under Section 4.2 that = issues an E.164 number to a Subscriber:=20 "Section 4.2: Telecommunications Number Provider (TNP):" Reason #1: The term is perfectly descriptive for the role defined = under Section 4.2. =20 Reason #2: The term is broad enough to encompass multiple types of organizations that might provide this role in the context of an ENUM = System. For example: Telephone Service Providers, Application Service = Providers, Responsible Organizations, Resellers, etc. Reason #3: The term seemed to achieve a certain level of support from = the group. Reason #4: The alternate proposal of "authenticator" may have a = tendency to create confusion with the "Registrar" role described under Section 4.7. = Please respond back if you'd like to continue the discussion on the use = of this term. Otherwise, I'll make the change in the next turn of the = draft. Doug Douglas J. Ranalli Founder & Chief Strategy Officer NetNumber 650 Suffolk Street, Suite 307 Lowell, MA 01854 dranalli@netnumber.com =20 www.netnumber.com =20 978-454-4210 ext 22 978-454-5044 (fax) ------_=_NextPart_001_01C05A2F.4EBDACB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Douglas,
as i=20 think my former message didnot reach the ENUM list because of the files = attached, I copy it here. It is a proposal of mapping of terminology = with some=20 terms used in ITU rec on UIFN.
 
It=20 proposes either to use "Service Access Provider" either to quote  = a mapping=20 with the ITU terminology in order everybody understand from the = "Bellheads"=20 :-)
 
I'd=20 like to be sure that the term RespOrg will not be understood or = flavoured as=20 "Regulator", because at the end of the day, except from resources = directly given=20 by the ITU, they are the one entity who provide the telecommunication=20 numbers.
 
***************Copy of my former mail=20 :
 

Judith,Paul,

do you see any possible use of the terminology used through ITU=20 recommendations E.152, E.169 (universal international freephone = service) or any=20 possible mapping between the entities you describe and the ones who = play a part=20 in these recommendations ? This could provide a universal = understanding.

For instance, =A74.3 of Rec. E.152 defines "Service Provider A" as = having a=20 role quite similar to that of RespOrg.

SP A has recently be changed to "International Freephone Service = access=20 provider", after a contribution from Teledenmark to add portability = guidelines,=20 (UIFNportb057_ww9.doc that I join here).

Valerie.

 

end of message =
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ = _=20

Val=E9rie Barnole =

FTR&D/DAC/ACE

tel. : +=20 33 1 45 29 58 39
fax : = + 33 1 46 29 31 42

mail to : valerie.barnole@francetelecom.fr

-----Message d'origine-----
De : Douglas = Ranalli=20 [mailto:dranalli@netnumber.com]
Envoy=E9 : mercredi 29 = novembre=20 2000 18:44
=C0 : enum@ietf.org
Objet : = [Enum]=20 I-DACTION:draft-ranalli-peek-walter-enum-t1ro = les-00.txt

Great comments on terminology.  Here's an initial attempt = to achieve=20 closure on the terminology for the entity described under Section 4.2 = that=20 issues an E.164 number to a Subscriber:=20

"Section 4.2:  Telecommunications Number = Provider=20 (TNP):"

Reason #1:  The=20 term is perfectly descriptive for the role=20 defined under Section 4.2. 

Reason #2:  The=20 term is broad enough to encompass multiple types of organizations = that might=20 provide this role in the context of an ENUM System.  For example:  Telephone Service = Providers,=20 Application Service Providers, Responsible Organizations, Resellers, = etc.

Reason #3:  The=20 term seemed to achieve a certain level of support from the group.

Reason #4:  The=20 alternate proposal of "authenticator" may have a tendency to create = confusion=20 with the "Registrar" role described under Section 4.7.

Please respond back if you'd like to continue = the=20 discussion on the use of this = term. =20 Otherwise, I'll make the change in the next turn of the = draft.

Doug

Douglas J. Ranalli
Founder & = Chief=20 Strategy Officer
NetNumber
650 Suffolk Street, Suite = 307
Lowell,=20 MA  01854
dranalli@netnumber.com
www.netnumber.com
978-454-4210 = ext=20 22
978-454-5044 (fax)
------_=_NextPart_001_01C05A2F.4EBDACB0-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Nov 29 13:24:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09438 for ; Wed, 29 Nov 2000 13:23:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05548; Wed, 29 Nov 2000 13:23:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05474 for ; Wed, 29 Nov 2000 13:23:20 -0500 (EST) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09270 for ; Wed, 29 Nov 2000 13:23:19 -0500 (EST) Received: by dnspri.npac.com; id MAA12261; Wed, 29 Nov 2000 12:23:18 -0600 (CST) Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0) id xma011868; Wed, 29 Nov 00 12:22:20 -0600 Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 12:20:40 -0600 Message-ID: From: James Yu To: "'BARNOLE Valerie FTRD/DAC/ISS'" Cc: enum@ietf.org, "'john.loughney@nokia.com'" Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt Date: Wed, 29 Nov 2000 12:26:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA05475 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id NAA05548 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA09438 Valerie, enum is for E.164 number so E.212 (IMSI) or E.214 (mobile global title) needs to use something else such as e212.arpa or e214.arpa. The reason E.214 is used today in the GSM has reasons due to SS7 message routing across national boundaries. IMHO, we probably only need e212.arpa. One thing good about IMSI is that it is not portable (e.g., there is a mobile network code that belongs to the cellular carrier) and the cellular carriers are the ones that control those numbers (e.g., they can be the T2E for their own IMSIs). So there is no need to populate individual IMSIs at the T1E. A block of IMSIs will do the job. For example, the T1E can point to a T2E based on the first six digits of the IMSI. The T2E returns the NAPTR RRs for the associated IMSI. The draft is for cases when E.164 numbers are used to identify cellular node (e.g., HLR, VLR and message center, etc.). James > -----Original Message----- > From: BARNOLE Valerie FTRD/DAC/ISS > [mailto:valerie.barnole@rd.francetelecom.fr] > Sent: Wednesday, November 29, 2000 12:09 PM > To: 'john.loughney@nokia.com'; james.yu@neustar.com; enum@ietf.org > Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt > > > John, > I am sorry, I can't retrieve your > draft-loughney-enum-roaming-00.txt. Can > you send it, please ? > > I suppose that in this draft, you populate the DNS with E.212 or E.214 > numbers. I do not have your draft to see how you deal with the > confidentiality of the IMSI, but my first idea is that mobile > operators > should be very reluctant to populate the DNS with such > confidential data. > Thank you for sending me your draft. > > Regards, > > Valerie. > > end of message > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > Valérie Barnole > > FTR&D/DAC/ACE > > tel. : + 33 1 45 29 58 39 > fax : + 33 1 46 29 31 42 > > mail to : valerie.barnole@francetelecom.fr > > > > -----Message d'origine----- > De : john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Envoyé : mardi 7 novembre 2000 08:34 > Ŕ : james.yu@neustar.com; enum@ietf.org > Cc : john.loughney@nokia.com > Objet : [Enum] RE: draft-loughney-enum-roaming-00.txt > > > Hi James & everyone, > > > One reason that GTT is used in SS7 message transport is > > because the message routing in many cases involve two > > cellular networks in different countries. A SS7 point code > > in U.K. cannot be used directly by a SS7 node in France to > > send a SS7 message to. IP will change that because IP is > > global. This is just one example of use of ENUM. Another > > example is to identify the message center that serves a > > particular cellular subscriber when there is a short > > message destined towards that subscriber. In this example, > > the E.164 number is assigned to an cellular subscriber; > > however, the service that uses ENUM is again a "network-related > > service." > > Thanks for summarizing the intention of this draft. You did > a much better job that what I did at Pittsburgh :) > > I also want to mention that this issues will get much more > complicated in the proposed 3G networks. There will be > operators implementing all of their networks over IP. In > your scenario, there will need to be some negotiation/ > mapping between the SS7 addresses and IP address that will > be assigned for the VLR/HLR. > > One further complication is that there may be AAA servers > providing the same functionality for 3G cellular subscribers. > > I would like to think that ENUM could be a techology that is > used to promote interoperability/interworking for this > purpose. > > > John and I would like to hear from you to see whether they is > > any problem to move this I-D forward. > > thanks, > John > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 30 11:56:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03952 for ; Thu, 30 Nov 2000 11:56:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15082; Thu, 30 Nov 2000 11:55:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15044 for ; Thu, 30 Nov 2000 11:55:10 -0500 (EST) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03441 for ; Thu, 30 Nov 2000 11:55:07 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 17:53:27 +0100 Message-ID: <98388C05D464D111B61800805F1504160233A10D@p-ibis.issy.cnet.fr> From: BARNOLE Valerie FTRD/DAC/ISS To: "'Douglas Ranalli'" Cc: "'enum@ietf.org'" Subject: RE: [Enum] I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.t xt Date: Thu, 30 Nov 2000 17:53:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA15047 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id LAA15082 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA03952 Douglas and all, from my european point of view, "Telephone number provider" has a strong flavor of administration system, which is not the purpose of the draft because both types of entities are clearly separated within it. This term sounds connected to Number Pooling, that you already have in the States due to your implementation of Number portability but that studies showed inadequate to most of Europe countries for the time being. So, on this basis, I would prefer the former term TSP. I can offer another proposal, which is SAP (Service access Provider) and comes from an ITU Recommendation, in order to provide a kind of universal understanding if it is possible :-). In the ITU E.152 (International Freephone Service) definition, the SAP is responsible to ensure the establishment of access to the international freephone number in the country of origin of the call. It is also what was called ROA A (or service provider A, which is close to the TSP term) and renamed SAP. ROA A has the responsability of processing all applications received on behalf of their IFS customer. So it will obtain from the ITU the numbers requested by the customer and notifies him the "rules of the game" (no trading nor licensing of the numbers). Important note : this is not what "bellheads" call assignment of numbers, because the ITU_does_the assignment. It is an indirect allocation from the ITU to the subscriber via the SAP (not even a suballocation from the SAP to the subscriber). ROA A (SAP) is the interface with the customer and has overall control responsabilities to ensure the completion of the service order for initiation, change, suspension and disconnection of service. Of course, the E.152 exemple looks simplistic compared to the definitions of the draft : in E.152, the SAP act simultaneously as a TSP, an Agent and a registrant. A second point in §4.2, as a "bellhead", I think that the first quoted role of the TSP is misworded (see my important note above). So I would reword it E.164 indirect allocation (fit for services numbers like freephone) or E.164 suballocation (fit for geogaphical numbers) and describe it as "suballocates E.164 numbers received from the administration system to subscribers". A third point I just saw : in the 2nd role of TSP, the words "to terminate" and "termination" might be misunderstood as "to accomplish a call" and "completion". I suggest to use "to disconnect" and "disconnection", if I am not the only one to think this misunderstanding is possible. To sum up : - I agree on TSP or SAP, mentionning in the first role "E.164 Suballocation : suballocates E.164 numbers received from the administration system to subscribers" instead of "E.164 Assignment : Assigns E.164 numbers to Subscribers". - According to the forementionned reasons, I tend to disagree with "Telephone Number Provider". - I suggest to use "to disconnect" and "disconnection"instead of "to terminate" and "termination" Valerie. end of message _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Valérie Barnole FTR&D/DAC/ACE tel. : + 33 1 45 29 58 39 fax : + 33 1 46 29 31 42 mail to : valerie.barnole@francetelecom.fr _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 30 12:19:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13411 for ; Thu, 30 Nov 2000 12:19:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15942; Thu, 30 Nov 2000 12:18:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15913 for ; Thu, 30 Nov 2000 12:18:35 -0500 (EST) Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13100 for ; Thu, 30 Nov 2000 12:18:32 -0500 (EST) Received: from dranalli ([38.136.73.90]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001130171803.FNOR1216.hvmta01-stg@dranalli>; Thu, 30 Nov 2000 12:18:03 -0500 Message-ID: <00d601c05af1$08940370$5a498826@netnumber.com> Reply-To: "Douglas Ranalli" From: "Douglas Ranalli" To: "BARNOLE Valerie FTRD/DAC/ISS" Cc: References: <98388C05D464D111B61800805F1504160233A10D@p-ibis.issy.cnet.fr> Subject: Re: [Enum] I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Date: Thu, 30 Nov 2000 12:14:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id MAA15942 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA13411 Valerie, Thank you for posting this note. The primary reason that we published this draft was to help the group gain agreement on a common framework of "actors" in the ENUM system for use by future contributors. Clarifying appropriate names for the actors is an important part of the process. Let's see how the group responds to SAP as an alternative to TNP. Douglas ----- Original Message ----- From: BARNOLE Valerie FTRD/DAC/ISS To: 'Douglas Ranalli' Cc: Sent: Thursday, November 30, 2000 11:53 AM Subject: RE: [Enum] I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Douglas and all, from my european point of view, "Telephone number provider" has a strong flavor of administration system, which is not the purpose of the draft because both types of entities are clearly separated within it. This term sounds connected to Number Pooling, that you already have in the States due to your implementation of Number portability but that studies showed inadequate to most of Europe countries for the time being. So, on this basis, I would prefer the former term TSP. I can offer another proposal, which is SAP (Service access Provider) and comes from an ITU Recommendation, in order to provide a kind of universal understanding if it is possible :-). In the ITU E.152 (International Freephone Service) definition, the SAP is responsible to ensure the establishment of access to the international freephone number in the country of origin of the call. It is also what was called ROA A (or service provider A, which is close to the TSP term) and renamed SAP. ROA A has the responsability of processing all applications received on behalf of their IFS customer. So it will obtain from the ITU the numbers requested by the customer and notifies him the "rules of the game" (no trading nor licensing of the numbers). Important note : this is not what "bellheads" call assignment of numbers, because the ITU_does_the assignment. It is an indirect allocation from the ITU to the subscriber via the SAP (not even a suballocation from the SAP to the subscriber). ROA A (SAP) is the interface with the customer and has overall control responsabilities to ensure the completion of the service order for initiation, change, suspension and disconnection of service. Of course, the E.152 exemple looks simplistic compared to the definitions of the draft : in E.152, the SAP act simultaneously as a TSP, an Agent and a registrant. A second point in §4.2, as a "bellhead", I think that the first quoted role of the TSP is misworded (see my important note above). So I would reword it E.164 indirect allocation (fit for services numbers like freephone) or E.164 suballocation (fit for geogaphical numbers) and describe it as "suballocates E.164 numbers received from the administration system to subscribers". A third point I just saw : in the 2nd role of TSP, the words "to terminate" and "termination" might be misunderstood as "to accomplish a call" and "completion". I suggest to use "to disconnect" and "disconnection", if I am not the only one to think this misunderstanding is possible. To sum up : - I agree on TSP or SAP, mentionning in the first role "E.164 Suballocation : suballocates E.164 numbers received from the administration system to subscribers" instead of "E.164 Assignment : Assigns E.164 numbers to Subscribers". - According to the forementionned reasons, I tend to disagree with "Telephone Number Provider". - I suggest to use "to disconnect" and "disconnection"instead of "to terminate" and "termination" Valerie. end of message _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Valérie Barnole FTR&D/DAC/ACE tel. : + 33 1 45 29 58 39 fax : + 33 1 46 29 31 42 mail to : valerie.barnole@francetelecom.fr _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 30 13:02:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02124 for ; Thu, 30 Nov 2000 13:02:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17054; Thu, 30 Nov 2000 13:02:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17023 for ; Thu, 30 Nov 2000 13:02:17 -0500 (EST) Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01897 for ; Thu, 30 Nov 2000 13:02:17 -0500 (EST) Received: from worldnet ([12.88.173.34]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20001130180144.PTZK25510.mtiwmhc25.worldnet.att.net@worldnet>; Thu, 30 Nov 2000 18:01:44 +0000 From: "Judith Oppenheimer" To: "'BARNOLE Valerie FTRD/DAC/ISS'" , "'Douglas Ranalli'" Cc: Subject: RE: [Enum] I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Date: Thu, 30 Nov 2000 12:59:10 -0500 Message-ID: <01de01c05af7$3e1ec600$22ad580c@att.net.icbtollfree.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <98388C05D464D111B61800805F1504160233A10D@p-ibis.issy.cnet.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id NAA17054 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA02124 > A third point I just saw : in the 2nd role of TSP, the words > "to terminate" > and "termination" might be misunderstood as "to accomplish a call" and > "completion". I suggest to use "to disconnect" and > "disconnection", if I am > not the only one to think this misunderstanding is possible. I agree. > Important note : this is not what "bellheads" call assignment > of numbers, > because the ITU_does_the assignment. It is an indirect > allocation from the > ITU to the subscriber via the SAP (not even a suballocation > from the SAP to > the subscriber). This description parallels that of the RespOrg and its relationship to the 800 SMS and the subscriber, except that the RespOrg maintains the subscriber ID records, not the 800 SMS. (Because FCC regs and the tariff stipulate that a RespOrg must have a customer for every number it reserves, I don't think it would be considered a suballocation either.) > So I > would reword it > E.164 indirect allocation (fit for services numbers like > freephone) or E.164 > suballocation (fit for geogaphical numbers) and describe it > as "suballocates > E.164 numbers received from the administration system to subscribers". This makes sense. Re acronyms, it depends if you consider the verification process telephone number-centric or subscriber-centric. In the first case TNA for Telephone Number Allocator or TNV for Telephone Number Verifier would make sense. If the latter, SA, for Subscriber Agent, since that is the function of an SAP or RespOrg: an agency function on behalf of the subscriber solely for management of the number. On another general point, the North American Numbering Council's It should be noted that the toll free system is far larger and more complex than the LNP system. This is due to the fact that the LNP system provides the ability only to identify the service provider to complete a call to a telephone number; while the toll free system provides capabilities (e.g., time-of-day routing, routing based on the point of origination, routing based on pre-established call loads, etc.) far greater than anything contemplated for LNP. Judith Oppenheimer, 212 684-7210, 1 800 The Expert Publisher, http://www.ICBTollFreeNews.com President, http://www.1800TheExpert.com FREE 800/Domain Classifieds, http://ICBclassifieds.com Domain Name & 800 News, Intelligence, Analysis > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > BARNOLE Valerie FTRD/DAC/ISS > Sent: Thursday, November 30, 2000 11:53 AM > To: 'Douglas Ranalli' > Cc: 'enum@ietf.org' > Subject: RE: [Enum] I-DACTION:draft-ranalli-peek-walter-enum-t1ro > les-00.txt > > > Douglas and all, > from my european point of view, "Telephone number provider" > has a strong > flavor of administration system, which is not the purpose of the draft > because both types of entities are clearly separated within > it. This term > sounds connected to Number Pooling, that you already have in > the States due > to your implementation of Number portability but that studies showed > inadequate to most of Europe countries for the time being. > So, on this basis, I would prefer the former term TSP. I can > offer another > proposal, which is SAP (Service access Provider) and comes from an ITU > Recommendation, in order to provide a kind of universal > understanding if it > is possible :-). > In the ITU E.152 (International Freephone Service) > definition, the SAP is > responsible to ensure the establishment of access to the international > freephone number in the country of origin of the call. It is > also what was > called ROA A (or service provider A, which is close to the > TSP term) and > renamed SAP. ROA A has the responsability of processing all > applications > received on behalf of their IFS customer. So it will obtain > from the ITU the > numbers requested by the customer and notifies him the "rules > of the game" > (no trading nor licensing of the numbers). > Important note : this is not what "bellheads" call assignment > of numbers, > because the ITU_does_the assignment. It is an indirect > allocation from the > ITU to the subscriber via the SAP (not even a suballocation > from the SAP to > the subscriber). > ROA A (SAP) is the interface with the customer and has overall control > responsabilities to ensure the completion of the service order for > initiation, change, suspension and disconnection of service. > Of course, the E.152 exemple looks simplistic compared to the > definitions of > the draft : in E.152, the SAP act simultaneously as a TSP, an > Agent and a > registrant. > A second point in §4.2, as a "bellhead", I think that the > first quoted role > of the TSP is misworded (see my important note above). So I > would reword it > E.164 indirect allocation (fit for services numbers like > freephone) or E.164 > suballocation (fit for geogaphical numbers) and describe it > as "suballocates > E.164 numbers received from the administration system to subscribers". > A third point I just saw : in the 2nd role of TSP, the words > "to terminate" > and "termination" might be misunderstood as "to accomplish a call" and > "completion". I suggest to use "to disconnect" and > "disconnection", if I am > not the only one to think this misunderstanding is possible. > To sum up : > - I agree on TSP or SAP, mentionning in the first role > "E.164 Suballocation > : suballocates E.164 numbers received from the administration > system to > subscribers" instead of "E.164 Assignment : Assigns E.164 numbers to > Subscribers". > - According to the forementionned reasons, I tend to disagree with > "Telephone Number Provider". > - I suggest to use "to disconnect" and "disconnection"instead of "to > terminate" and "termination" > > Valerie. > > > > > end of message > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > Valérie Barnole > > FTR&D/DAC/ACE > > tel. : + 33 1 45 29 58 39 > fax : + 33 1 46 29 31 42 > > mail to : valerie.barnole@francetelecom.fr > > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 30 13:09:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04664 for ; Thu, 30 Nov 2000 13:09:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17260; Thu, 30 Nov 2000 13:08:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17231 for ; Thu, 30 Nov 2000 13:08:36 -0500 (EST) Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04453 for ; Thu, 30 Nov 2000 13:08:36 -0500 (EST) Received: from worldnet ([12.88.173.34]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20001130180804.PVWN25510.mtiwmhc25.worldnet.att.net@worldnet>; Thu, 30 Nov 2000 18:08:04 +0000 From: "Judith Oppenheimer" To: "'BARNOLE Valerie FTRD/DAC/ISS'" , "'Douglas Ranalli'" Cc: Subject: CORRECTION RE: [Enum] I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt Date: Thu, 30 Nov 2000 13:05:29 -0500 Message-ID: <01df01c05af8$2068c420$22ad580c@att.net.icbtollfree.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <98388C05D464D111B61800805F1504160233A10D@p-ibis.issy.cnet.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id NAA17260 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA04664 My last post went out incomplete (my keyboard sometimes has a mind of its own ) ... > A third point I just saw : in the 2nd role of TSP, the words > "to terminate" > and "termination" might be misunderstood as "to accomplish a call" and > "completion". I suggest to use "to disconnect" and > "disconnection", if I am > not the only one to think this misunderstanding is possible. I agree. > Important note : this is not what "bellheads" call assignment > of numbers, > because the ITU_does_the assignment. It is an indirect > allocation from the > ITU to the subscriber via the SAP (not even a suballocation > from the SAP to > the subscriber). This description parallels that of the RespOrg and its relationship to the 800 SMS and the subscriber, except that the RespOrg maintains the subscriber ID records, not the 800 SMS. (Because FCC regs and the tariff stipulate that a RespOrg must have a customer for every number it reserves, I don't think it would be considered a suballocation either.) > So I > would reword it > E.164 indirect allocation (fit for services numbers like > freephone) or E.164 > suballocation (fit for geogaphical numbers) and describe it > as "suballocates > E.164 numbers received from the administration system to subscribers". This makes sense. Re acronyms, it depends if you consider the verification process telephone number-centric or subscriber-centric. In the first case TNA for Telephone Number Allocator or TNV for Telephone Number Verifier would make sense. If the latter, SA, for Subscriber Agent, since that is the function of an SAP or RespOrg: an agency function on behalf of the subscriber solely for management of the number. On another general point, the North American Numbering Council's Chair John R. Hoffman points out this week to the FCC, "It should be noted that the toll free system is far larger and more complex than the LNP system. This is due to the fact that the LNP system provides the ability only to identify the service provider to complete a call to a telephone number; while the toll free system provides capabilities (e.g., time-of-day routing, routing based on the point of origination, routing based on pre-established call loads, etc.) far greater than anything contemplated for LNP." I point out this distinction to help clarify the difference between local number portability, and toll free portability, which has much more complex provisioning and contact variables attached to it. Judith Judith Oppenheimer, 212 684-7210, 1 800 The Expert Publisher, http://www.ICBTollFreeNews.com President, http://www.1800TheExpert.com FREE 800/Domain Classifieds, http://ICBclassifieds.com Domain Name & 800 News, Intelligence, Analysis > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > BARNOLE Valerie FTRD/DAC/ISS > Sent: Thursday, November 30, 2000 11:53 AM > To: 'Douglas Ranalli' > Cc: 'enum@ietf.org' > Subject: RE: [Enum] I-DACTION:draft-ranalli-peek-walter-enum-t1ro > les-00.txt > > > Douglas and all, > from my european point of view, "Telephone number provider" > has a strong > flavor of administration system, which is not the purpose of the draft > because both types of entities are clearly separated within > it. This term > sounds connected to Number Pooling, that you already have in > the States due > to your implementation of Number portability but that studies showed > inadequate to most of Europe countries for the time being. > So, on this basis, I would prefer the former term TSP. I can > offer another > proposal, which is SAP (Service access Provider) and comes from an ITU > Recommendation, in order to provide a kind of universal > understanding if it > is possible :-). > In the ITU E.152 (International Freephone Service) > definition, the SAP is > responsible to ensure the establishment of access to the international > freephone number in the country of origin of the call. It is > also what was > called ROA A (or service provider A, which is close to the > TSP term) and > renamed SAP. ROA A has the responsability of processing all > applications > received on behalf of their IFS customer. So it will obtain > from the ITU the > numbers requested by the customer and notifies him the "rules > of the game" > (no trading nor licensing of the numbers). > Important note : this is not what "bellheads" call assignment > of numbers, > because the ITU_does_the assignment. It is an indirect > allocation from the > ITU to the subscriber via the SAP (not even a suballocation > from the SAP to > the subscriber). > ROA A (SAP) is the interface with the customer and has overall control > responsabilities to ensure the completion of the service order for > initiation, change, suspension and disconnection of service. > Of course, the E.152 exemple looks simplistic compared to the > definitions of > the draft : in E.152, the SAP act simultaneously as a TSP, an > Agent and a > registrant. > A second point in §4.2, as a "bellhead", I think that the > first quoted role > of the TSP is misworded (see my important note above). So I > would reword it > E.164 indirect allocation (fit for services numbers like > freephone) or E.164 > suballocation (fit for geogaphical numbers) and describe it > as "suballocates > E.164 numbers received from the administration system to subscribers". > A third point I just saw : in the 2nd role of TSP, the words > "to terminate" > and "termination" might be misunderstood as "to accomplish a call" and > "completion". I suggest to use "to disconnect" and > "disconnection", if I am > not the only one to think this misunderstanding is possible. > To sum up : > - I agree on TSP or SAP, mentionning in the first role > "E.164 Suballocation > : suballocates E.164 numbers received from the administration > system to > subscribers" instead of "E.164 Assignment : Assigns E.164 numbers to > Subscribers". > - According to the forementionned reasons, I tend to disagree with > "Telephone Number Provider". > - I suggest to use "to disconnect" and "disconnection"instead of "to > terminate" and "termination" > > Valerie. > > > > > end of message > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > Valérie Barnole > > FTR&D/DAC/ACE > > tel. : + 33 1 45 29 58 39 > fax : + 33 1 46 29 31 42 > > mail to : valerie.barnole@francetelecom.fr > > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > Judith Oppenheimer, 212 684-7210, 1 800 The Expert Publisher, http://www.ICBTollFreeNews.com President, http://www.1800TheExpert.com FREE 800/Domain Classifieds, http://ICBclassifieds.com Domain Name & 800 News, Intelligence, Analysis > _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 30 16:10:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17913 for ; Thu, 30 Nov 2000 16:10:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20798; Thu, 30 Nov 2000 16:09:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20771 for ; Thu, 30 Nov 2000 16:09:43 -0500 (EST) Received: from mail2.itu.int (mail2.itu.ch [156.106.192.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17590 for ; Thu, 30 Nov 2000 16:09:40 -0500 (EST) Received: by mail2.itu.ch with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 22:04:11 +0100 Message-ID: From: "Shaw, Robert" To: "'enum@ietf.org'" Date: Thu, 30 Nov 2000 22:09:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA20772 Subject: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Makers, and Numb ering Authorities - January 17, 2001 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id QAA20798 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA17913 List members: This is an initial heads-up that ITU is organizing an ENUM Workshop: "Issues for Regulators, Policy Makers, and Numbering Authorities" on January 17, 2001. The meeting will be in Geneva, Switzerland at the ITU. The target audience is the latter group and the objective is to provide better understanding of the technical/regulatory/competition policy implications of the ENUM protocol for those who will be involved in related "country-code" level policy decisions at both the sub-cc E.164 DNS and NAPTR provisioning/deprovisioning levels. This date was chosen since an experts meeting related to an ITU Policy Forum on IP telephony (in which ENUM is also a topic) will be held on January 18/19 as well as a normal ITU-T Study Group 2 for the following two weeks in Geneva. IETF's ENUM Chair, Richard Shockey, Patrik Fältström, author of RFC 2916, and Mirjam Kuehne from RIPE NCC have also already agreed to participate on the 17th. We will work with Richard on a synthesis of the discussions on the list and from various drafts and discussions in San Diego to provide some generic reference models for possible national or integrated numbering plan level consideration as an input to this meeting. The meeting will be open, within space limitations of about 100 seats, and as soon as there is more detail and a registration form available, I'll announce it on the list for those who may wish to participate and also post it to www.itu.int/infocom/enum/. Bob -- Robert Shaw ITU Internet Strategy and Policy Advisor International Telecommunication Union Place des Nations, 1211 Geneva, Switzerland _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 30 17:14:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12563 for ; Thu, 30 Nov 2000 17:14:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22143; Thu, 30 Nov 2000 17:14:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22111 for ; Thu, 30 Nov 2000 17:14:07 -0500 (EST) Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12293 for ; Thu, 30 Nov 2000 17:14:00 -0500 (EST) Received: from dranalli ([38.136.73.90]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001130221331.JJCG1216.hvmta01-stg@dranalli>; Thu, 30 Nov 2000 17:13:31 -0500 Message-ID: <018701c05b1a$4ef4d780$5a498826@netnumber.com> Reply-To: "Douglas Ranalli" From: "Douglas Ranalli" To: , References: Subject: Re: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Makers, and Numbering Authorities - January 17, 2001 Date: Thu, 30 Nov 2000 17:09:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id RAA22143 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA12563 Richard and ENUM list-group, I'm writing to follow-up on the note from Robert Shaw regarding the upcoming ITU workshop on ENUM implementation. My thought is that the "Roles & Responsibilities" draft that we've been discussing on the list group is a core document for ENUM and the ITU discussion. The process of gaining agreement on the set of "actors" in the ENUM System and the "roles and responsibilities" of those actors is a foundation for all follow-on ENUM work. Based on this, I'd like to propose that we consider making the "Roles & Responsibilities" draft a standards track document so that we can all work to gain consensus on a common framework for advancing ENUM. Please let me know your thoughts. Regards, Doug ----- Original Message ----- From: Shaw, Robert To: Sent: Thursday, November 30, 2000 4:09 PM Subject: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Makers, and Numbering Authorities - January 17, 2001 List members: This is an initial heads-up that ITU is organizing an ENUM Workshop: "Issues for Regulators, Policy Makers, and Numbering Authorities" on January 17, 2001. The meeting will be in Geneva, Switzerland at the ITU. The target audience is the latter group and the objective is to provide better understanding of the technical/regulatory/competition policy implications of the ENUM protocol for those who will be involved in related "country-code" level policy decisions at both the sub-cc E.164 DNS and NAPTR provisioning/deprovisioning levels. This date was chosen since an experts meeting related to an ITU Policy Forum on IP telephony (in which ENUM is also a topic) will be held on January 18/19 as well as a normal ITU-T Study Group 2 for the following two weeks in Geneva. IETF's ENUM Chair, Richard Shockey, Patrik Fältström, author of RFC 2916, and Mirjam Kuehne from RIPE NCC have also already agreed to participate on the 17th. We will work with Richard on a synthesis of the discussions on the list and from various drafts and discussions in San Diego to provide some generic reference models for possible national or integrated numbering plan level consideration as an input to this meeting. The meeting will be open, within space limitations of about 100 seats, and as soon as there is more detail and a registration form available, I'll announce it on the list for those who may wish to participate and also post it to www.itu.int/infocom/enum/. Bob -- Robert Shaw ITU Internet Strategy and Policy Advisor International Telecommunication Union Place des Nations, 1211 Geneva, Switzerland _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 30 18:03:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12564 for ; Thu, 30 Nov 2000 18:03:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23224; Thu, 30 Nov 2000 18:03:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23196 for ; Thu, 30 Nov 2000 18:03:06 -0500 (EST) Received: from exchange.chaos.com (exchange.chaos.com [206.5.17.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12383 for ; Thu, 30 Nov 2000 18:03:01 -0500 (EST) Received: from [216.168.250.52] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id rlfjaaaa for enum@ietf.org; Thu, 30 Nov 2000 18:03:02 -0500 Message-Id: <5.0.2.1.2.20001130174943.02797390@mail.netmagic.com> X-Sender: amr@mail.netmagic.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 30 Nov 2000 18:03:01 -0500 To: "Shaw, Robert" , "'enum@ietf.org'" From: "A.M. Rutkowski" Subject: Re: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Makers, and Numb ering Authorities - January 17, 2001 In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_786697140==_.ALT" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --=====================_786697140==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:09 PM 11/30/2000, Shaw, Robert wrote: >available, I'll announce it on the list for those who may wish to >participate and also post it to www.itu.int/infocom/enum/. The site says: The Internet Architecture Board (IAB) and ITU-T Study Group 2 are working together on the operational, administration and delegation issues related to deployment of ENUM protocol-based services. Could someone indicate: 1) the respective authority to do this, and 2) the basis, process and availability of materials or dialogue associated with this activity? --tony --=====================_786697140==_.ALT Content-Type: text/html; charset="us-ascii" At 04:09 PM 11/30/2000, Shaw, Robert wrote:
available, I'll announce it on the list for those who may wish to
participate and also post it to www.itu.int/infocom/enum/.

The site says:

  The Internet Architecture Board (IAB) and ITU-T
  Study Group 2 are working together on the operational,
  administration and delegation issues related to
  deployment of ENUM protocol-based services.

Could someone indicate:

1) the respective authority to do this, and
2) the basis, process and availability of materials
   or dialogue associated with this activity?

--tony

 --=====================_786697140==_.ALT-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Nov 30 19:24:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20063 for ; Thu, 30 Nov 2000 19:24:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27179; Thu, 30 Nov 2000 19:23:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27148 for ; Thu, 30 Nov 2000 19:23:43 -0500 (EST) Received: from heron.verisign.com ([216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19773 for ; Thu, 30 Nov 2000 19:23:42 -0500 (EST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id TAA03551; Thu, 30 Nov 2000 19:12:59 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 19:20:07 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Douglas Ranalli'" , rich.shockey@neustar.com, enum@ietf.org Subject: RE: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Maker s, and Numbering Authorities - January 17, 2001 Date: Thu, 30 Nov 2000 19:20:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Doug, I don't believe that the "Roles & Responsibilities" draft lends itself to the evolutionary standards track maturity levels (Proposed Standard, Draft Standard, Standard) as described in RFC 2026. However, the definition of the Best Current Practice (BCP) series describes the benefit of identifying "common guidelines for policies and operations", so perhaps targeting BCP would be appropriate. Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Douglas Ranalli [mailto:dranalli@netnumber.com] Sent: Thursday, November 30, 2000 5:10 PM To: rich.shockey@neustar.com; enum@ietf.org Subject: Re: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Makers, and Numbering Authorities - January 17, 2001 Richard and ENUM list-group, I'm writing to follow-up on the note from Robert Shaw regarding the upcoming ITU workshop on ENUM implementation. My thought is that the "Roles & Responsibilities" draft that we've been discussing on the list group is a core document for ENUM and the ITU discussion. The process of gaining agreement on the set of "actors" in the ENUM System and the "roles and responsibilities" of those actors is a foundation for all follow-on ENUM work. Based on this, I'd like to propose that we consider making the "Roles & Responsibilities" draft a standards track document so that we can all work to gain consensus on a common framework for advancing ENUM. Please let me know your thoughts. Regards, Doug _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum