From enum-admin@ietf.org Fri Jun 2 12:28:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06629 for ; Fri, 2 Jun 2000 12:28:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17317; Fri, 2 Jun 2000 12:27:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17292 for ; Fri, 2 Jun 2000 12:27:55 -0400 (EDT) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06617; Fri, 2 Jun 2000 12:27:51 -0400 (EDT) Received: from computer.ix.netcom.com ([209.138.179.44]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA19364; Fri, 2 Jun 2000 12:27:52 -0400 (EDT) Message-Id: <4.3.1.2.20000602112141.00dff7a0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 02 Jun 2000 11:28:49 -0500 To: agenda@ietf.org From: Richard Shockey Cc: enum@ietf.org, Scott Bradner , mankin@east.isi.edu, Scott Petrack In-Reply-To: <200005241732.NAA09724@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Re: 48th IETF: ENUM Working Group/BOF Scheduling 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:32 PM 5/24/2000 -0400, you wrote: >Meeting Dates: July 30 - August 4, 2000 > >We will be taking scheduling requests for ALL Working Groups and >BOFs starting today. The cut-off for requesting a slot is Friday, >July 7 at 5:00 PM ET. The agenda for the working group is due by >Monday, July 24 at 5:00 PM ET, please submit the agenda to: > agenda@ietf.org The ENUM WG in the Transport area requests one single 2 1/2 hour session similar to the session scheduled in Australia. We would anticipate a similar audience for the group [150+] Conflicts to avoid would be: VPIM, DNSEXT, DNSOPS, SIP ( if possible), IPTEL. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please Note New Contact Information: Richard Shockey Shockey Consulting LLC 5237 Sutherland St. Louis, MO 63109 Voice 314.503.0640 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Jun 8 12:18:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10839 for ; Thu, 8 Jun 2000 12:18:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18180; Thu, 8 Jun 2000 12:16:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18102 for ; Thu, 8 Jun 2000 12:16:55 -0400 (EDT) Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10756 for ; Thu, 8 Jun 2000 12:16:53 -0400 (EDT) From: zainprov@swbell.net Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00DNGF4Q3B@mta5.rcsntx.swbell.net> for enum@ietf.org; Thu, 8 Jun 2000 11:06:17 -0500 (CDT) Date: Thu, 08 Jun 2000 11:06:17 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net To: enum@ietf.org Message-id: <0FVU00DHMFEE3B@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Subject: [Enum] Shocking LOSE 10-100lbs. DESTINY 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 Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Jun 9 12:14:00 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14320 for ; Fri, 9 Jun 2000 12:14:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11212; Fri, 9 Jun 2000 12:13:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11182 for ; Fri, 9 Jun 2000 12:13:12 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14300 for ; Fri, 9 Jun 2000 12:12:58 -0400 (EDT) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e59GCBd10899; Fri, 9 Jun 2000 12:12:11 -0400 (EDT) Received: from research.telcordia.com (lhong-pc [192.4.8.89]) by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id MAA03789; Fri, 9 Jun 2000 12:12:10 -0400 (EDT) Message-ID: <39411759.CB920970@research.telcordia.com> Date: Fri, 09 Jun 2000 12:12:09 -0400 From: Hong Liu X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: paf@swip.net, enum@ietf.org CC: lhong@research.telcordia.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] NAPTR Record Replacement Field 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, Patrik, I have two questions regarding your ENUM draft. In "draft-ietf-enum-e164-dns-00.txt", you use the replacement field of the NAPTR RR to store the the URLs for the answer of an E.164 query, such as a SIP URL "sip:paf@swip.net". When I looked through the NAPTR RR documents, both RFC2168 and "draft-ietf-urn-naptr-rr-03.txt" say that the replacement field MUST be a fully qualified domain name. Maybe I am missing something. Could you explain the difference here? The second question is regarding the service field "N2R". According to RFC2168, "N2R" is a service that maps an URN to an instance of resource. Since an ENUM query returns a set of URLs, will that be "N2L" instead? Thanks in advance for your clarification. --Hong _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Jun 9 12:56:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15125 for ; Fri, 9 Jun 2000 12:56:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11741; Fri, 9 Jun 2000 12:56:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11710 for ; Fri, 9 Jun 2000 12:55:59 -0400 (EDT) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15100 for ; Fri, 9 Jun 2000 12:55:59 -0400 (EDT) Received: from computer.ix.netcom.com ([209.138.179.12]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA08084; Fri, 9 Jun 2000 12:55:46 -0400 (EDT) Message-Id: <4.3.1.2.20000609115220.00c9a200@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 09 Jun 2000 11:56:50 -0500 To: Hong Liu , paf@swip.net, enum@ietf.org From: Richard Shockey Subject: Re: [Enum] NAPTR Record Replacement Field Cc: lhong@research.telcordia.com In-Reply-To: <39411759.CB920970@research.telcordia.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:12 PM 6/9/2000 -0400, Hong Liu wrote: >Hi, Patrik, > >I have two questions regarding your ENUM draft. > >In "draft-ietf-enum-e164-dns-00.txt", you use the replacement field of >the NAPTR RR to store the the URLs for the answer of an E.164 query, >such as a SIP URL "sip:paf@swip.net". When I looked through the NAPTR RR >documents, both RFC2168 and "draft-ietf-urn-naptr-rr-03.txt" say that >the replacement field MUST be a fully qualified domain name. Maybe I am >missing something. Could you explain the difference here? > >The second question is regarding the service field "N2R". According to >RFC2168, "N2R" is a service that maps an URN to an instance of resource. >Since an ENUM query returns a set of URLs, will that be "N2L" instead? Thanks for your message...one thing I think we should make clear is that ENUM is "application agnostic". Namely how various applications use ENUM is essentially up to them. We should not attempt to define how SIP or VPIM or other applications use ENUM. The examples in Patrik's document are _examples_. The use of NAPTR is certainly one method..but we should start to make clear that other work groups need to begin thinking about specific ID's of how to implement ENUM. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please Note New Contact Information: Richard Shockey Shockey Consulting LLC 5237 Sutherland St. Louis, MO 63109 Voice 314.503.0640 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sat Jun 10 08:43: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 ESMTP id IAA08246 for ; Sat, 10 Jun 2000 08:43:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27695; Sat, 10 Jun 2000 08:41:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27668 for ; Sat, 10 Jun 2000 08:41:57 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08237 for ; Sat, 10 Jun 2000 08:41:56 -0400 (EDT) Received: from [192.168.124.95] (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id OAA13204; Sat, 10 Jun 2000 14:41:29 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@nix.swip.net Message-Id: In-Reply-To: <4.3.1.2.20000609115220.00c9a200@127.0.0.1> References: <4.3.1.2.20000609115220.00c9a200@127.0.0.1> Date: Sat, 10 Jun 2000 14:26:50 +0200 To: Richard Shockey , Hong Liu , enum@ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Enum] NAPTR Record Replacement Field Cc: lhong@research.telcordia.com 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.56 -0500 00-06-09, Richard Shockey wrote: >The use of NAPTR is certainly one method..but we should start to >make clear that other work groups need to begin thinking about >specific ID's of how to implement ENUM. But, the way NAPTR RRs are used must be unique and specified in this draft. I.e. what a non-terminal regexp operates on must be unique for the ENUM process. I have tried to define that, and if it is unclear, I have to do some changes. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sat Jun 10 08:43: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 ESMTP id IAA08249 for ; Sat, 10 Jun 2000 08:43:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27656; Sat, 10 Jun 2000 08:41:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27628 for ; Sat, 10 Jun 2000 08:41:48 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08234 for ; Sat, 10 Jun 2000 08:41:47 -0400 (EDT) Received: from [192.168.124.95] (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id OAA13153; Sat, 10 Jun 2000 14:41:13 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@nix.swip.net Message-Id: In-Reply-To: <39411759.CB920970@research.telcordia.com> References: <39411759.CB920970@research.telcordia.com> Date: Sat, 10 Jun 2000 14:25:47 +0200 To: Hong Liu , enum@ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: lhong@research.telcordia.com, Michael Mealling Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: NAPTR Record Replacement Field 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.12 -0400 00-06-09, Hong Liu wrote: >In "draft-ietf-enum-e164-dns-00.txt", you use the replacement field of >the NAPTR RR to store the the URLs for the answer of an E.164 query, >such as a SIP URL "sip:paf@swip.net". When I looked through the NAPTR RR >documents, both RFC2168 and "draft-ietf-urn-naptr-rr-03.txt" say that >the replacement field MUST be a fully qualified domain name. Maybe I am >missing something. Could you explain the difference here? First, it is a mistake that the flag field is not "U" as it should (according to draft-ietf-urn-naptr-rr-03.txt). Secondly, as long as the process which uses NAPTR RRs specify what an eventual rewrite operate on, that is ok. I think I am clear on what an eventual regexp for rewrite operates on in the paper. If not, let me know. >The second question is regarding the service field "N2R". According to >RFC2168, "N2R" is a service that maps an URN to an instance of resource. >Since an ENUM query returns a set of URLs, will that be "N2L" instead? As far as I think, N2R is the correct thing, but with flag "U" and a URL in the regexp field. Michael? paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Jun 13 11:49:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12435 for ; Tue, 13 Jun 2000 11:49:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26814; Tue, 13 Jun 2000 11:48:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26783 for ; Tue, 13 Jun 2000 11:48:26 -0400 (EDT) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12400 for ; Tue, 13 Jun 2000 11:48:23 -0400 (EDT) Received: from computer.ix.netcom.com ([209.138.4.178]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA28220; Tue, 13 Jun 2000 11:48:22 -0400 (EDT) Message-Id: <4.3.1.2.20000605102851.00cb92c0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 13 Jun 2000 10:49:24 -0500 To: enum@ietf.org From: Richard Shockey Cc: Scott Bradner , mankin@east.isi.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] ENUM Working Group Last Call on draft-enum-e164-dns-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org To all... We've been a little quiet on the list recently. But I believe it is safe to assume that our core protocol document is essentially finished. In that case I want to issue a WG Last call on E.164 number and DNS draft-enum-e164-dns-00.txt. Title : E.164 number and DNS Author(s) : P. Faltstrom Filename : draft-ietf-enum-e164-dns-00.txt Pages : 11 Date : 02-May-00 This document discusses the use of DNS for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. Routing of the actual connection using the service selected using these methods is not discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-00.txt There have been substantial revisions to this document from the beginning but there has been no real change to the essential elements of the protocol. It is now a very "bare bones" document. The only debate has been over some of the examples used in the document which are not essential to the operation of the protocol itself. The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for three weeks from today June 13 to to at least July 4 th though we can modify that if new issues come up. Other work items we will need to discuss in the future are the Goals and Requirements documents ...which I understand is being updated at this time and some decisions will have to be made on delegation issues. Your co-chair, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please Note New Contact Information: Richard Shockey Shockey Consulting LLC 5237 Sutherland St. Louis, MO 63109 Voice 314.503.0640 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Jun 13 12:26:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13744 for ; Tue, 13 Jun 2000 12:26:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27414; Tue, 13 Jun 2000 12:25:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27383 for ; Tue, 13 Jun 2000 12:25:22 -0400 (EDT) Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13733 for ; Tue, 13 Jun 2000 12:25:20 -0400 (EDT) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg15e1.nortelnetworks.com; Tue, 13 Jun 2000 12:24:24 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 12:24:21 -0400 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24018D2732@bcarua63.ca.nortel.com> From: "Anne Brown" To: "'ENUM'" Date: Tue, 13 Jun 2000 12:24:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFD553.D464BF7C" Subject: [Enum] Revised Requirements Draft 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_000_01BFD553.D464BF7C Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD553.D464BF7C" ------_=_NextPart_001_01BFD553.D464BF7C Content-Type: text/plain; charset="iso-8859-1" A revised draft, attached, has been submitted to the IESG. Changes from the previous draft are outlined in section 8 of the revised draft. These changes are the result of WG discussions and input from the SG2 workshop documents nnar-e164-dns-iw-info.txt and nnar-carrier-sel-supp.txt. Please provide comments so that this draft can be further updated in preparation for a WG last call. Regards, Anne Brown Nortel Networks arbrown@nortelnetworks.com +1 613 765 5274 <> ------_=_NextPart_001_01BFD553.D464BF7C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Revised Requirements Draft

A = revised draft, attached, has been submitted to the IESG.  Changes from the = previous draft are outlined in section 8 of the revised draft.  These changes are the result = of WG discussions and input from the SG2 workshop documents = nnar-e164-dns-iw-info.txt and nnar-carrier-sel-supp.txt.

Please = provide comments so that this draft can be further updated in preparation = for a WG = last call.

Regards,

Anne = Brown

Nortel = Networks

arbrown@nortelnetworks.com

+1 613 = 765 5274

= <<draft-enum-rqmts-01.txt>>

------_=_NextPart_001_01BFD553.D464BF7C-- ------_=_NextPart_000_01BFD553.D464BF7C Content-Type: text/plain; name="draft-enum-rqmts-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-enum-rqmts-01.txt" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Telephone Number Mapping A. Brown Internet Draft Nortel Networks Document: June 2000 Category: Informational=20 =20 =20 ENUM Requirements=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026 [1]. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of=20 six months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet- Drafts=20 as reference material or to cite them other than as "work in=20 progress." =20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 1. Abstract=20 =20 This paper defines the requirements for a DNS-based architecture and = protocols for mapping a telephone number to a set of attributes=20 (e.g., URLs) that can be used to contact a resource associated with=20 that number. There are many possible protocols that can be=20 considered for a telephone number mapping service. The purpose of=20 this document is to focus discussion on a DNS-based solution. The=20 intention is to enumerate the expectations of such a solution and to = clarify the scope.=20 =20 2. Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC-2119 [2].=20 =20 3. Requirements=20 =20 3.1 Endpoint Address Lookup=20 =20 The system SHALL provide a service for the retrieval of service=20 specific endpoint addresses (e.g., email address, IP address, SIP=20 address, URL, etc.) or the retrieval of the addresses of servers, if = available, which may contain this endpoint information.=20 =20 =20 =0C ENUM Requirements June = 2000 =0D =20 =20 3.2 Capabilities Retrieval/Negotiation=20 =20 The retrieval or negotiation of capabilities is beyond the scope of=20 the system. =20 =20 3.3 Retrieval of Additional Information and Capabilities=20 =20 The retrieval of additional, application-specific information (e.g., = spoken name for verification purposes) is beyond the scope of the=20 system. The system MUST provide a service for the retrieval of=20 protocol and service information if available.=20 =20 The system SHOULD provide access to capabilities relevant to the=20 telephone number in question. The retrieval or negotiation of=20 capabilities will depend on the outcome of the rescap work or work=20 done in other groups.=20 =20 3.4 Qualification of the Request=20 =20 The system is not required to enable the qualification of a request=20 by a user, for the purposes of filtering for reducing returned=20 information or for traffic reduction. =20 =20 3.5 Provisioning=20 =20 The architecture and protocol MAY support at least the existing=20 administrative model as the current E.164 telephone number=20 delegation system. The protocol SHOULD also provide the ability to=20 support corporate numbering plan or competitive directory service=20 providers under separate root domains. It SHOULD NOT require an=20 additional centralized administrator beyond that required for the=20 existing telephone number system.=20 =20 The distribution of telephone numbers is a national affair by ITU=20 treaty and different telephone number distribution schemes may=20 require different delegation models. How nations choose to=20 administer the ENUM space within their borders is a national issue. = In any case, the subscriber or enterprise is the ultimate authority=20 for service provisioning.=20 =20 Further, it must be possible for the authority to which a telephone=20 number has been delegated to redirect the query to a different=20 entity that provides service-specific information for that number.=20 =20 3.6 Propagation of Changes=20 =20 Propagation of Changes If multiple copies of the data are=20 distributed in different areas, their update should be incorporated=20 almost simultaneously depending on the application of DNS to=20 services.=20 =20 =20 =0C ENUM Requirements June = 2000 =0D =20 =20 When a numbering plan change is made in a country or network, the=20 update of relevant E.164 number data in DNS needs to be coordinated=20 with the change.=20 =20 3.7 Response Timeout=20 =20 The system SHALL have a defined timeout mechanism.=20 =20 3.8 Global Number Portability=20 =20 The system MUST support existing local number portability=20 mechanisms, where applicable. It is RECOMMENDED that the system not = be designed in such as way as to impede future global number=20 portability. =20 =20 3.9 Scalability=20 =20 The system MUST scale to handle quantities of telephone numbers and=20 queries comparable to current and expected future PSTN usage. =20 =20 It must be possible to operate the system based on telephone number=20 blocks defined at the digit boundaries as well as explicit per- number configuration.=20 =20 3.10 Query Performance=20 =20 It SHOULD be possible to administer the ENUM service using the=20 selected protocols and structures such that the current user=20 expectations for latency in telecommunications services can be met. = In particular, it SHOULD be possible to operate the system in such a = manner that an ENUM query for a service-specific record can be=20 satisfied within one second 95% of the time and that within two=20 seconds, the query can be satisfied 99% of the time.=20 =20 3.11 Other PSTN Numbering Services=20 =20 E.164 numbers, short codes, service codes and prefixes are=20 categorized in dialing plans. A prefix is an indicator consisting=20 of one or more digits that allows the selection of different types=20 of number formats, networks and/or services. Prefixes are not part=20 of the number and are part of a dialing plan. The uses and the=20 formats of prefixes are a national matter. Short codes, e.g.=20 emergency, or service codes may be used based on the national=20 numbering plan. Those codes are not universal and typically valid=20 only within a numbering domain identified with the same country code = or country code + network identification code.=20 =20 PSTN type numbering services such as Emergency 911, directory=20 assistance 411, and other carrier codes for services accessible via=20 non-E164 (or subset) telephone number service access codes are=20 outside the scope of ENUM.=20 =20 3.12 Privacy=20 =20 =0C ENUM Requirements June = 2000 =0D =20 =20 =20 The system MUST allow the owner of the telephone number to control=20 the information which prospective callers may receive.=20 =20 3.13 Competition=20 =20 The solution MUST permit competing service providers to offer=20 telecommunications service for a given number. Competing=20 telecommunications services MUST be enabled where the ENUM entry is=20 administered by the single entity to which the number is delegated. = Who that single entity is, is beyond the scope of ENUM.=20 =20 3.14 Authorization of Requests and Responses=20 =20 The system SHALL enable the authorization of requests and responses. = =20 3.15 Privacy and Integrity of Requests and Responses=20 =20 The system SHALL enable the privacy and integrity of requests and=20 responses.=20 =20 3.16 Call Routing=20 =20 The system is not required to provide a service for routing calls or = locating gateways to a specific service.=20 =20 3.17 Service Logic=20 =20 The system is not responsible for employing service logic for the=20 intelligent retrieval of information.=20 =20 3.18 E.164 Numbers=20 =20 The system is not responsible for returning information on private=20 numbering plans and non-E.164 numbers. The system is responsible=20 for returning information on 1-800 and other legitimate E.164=20 numbers. =20 =20 3.19 Application Specific Use of ENUM=20 =20 The ENUM service MUST be application agnostic. It is expected that=20 various other IETF work groups will develop ENUM specific usage=20 profiles for their specific application. ENUM will not mandate the=20 use of any specific DNS Resource Record for any particular=20 application. =20 =20 4. Security Considerations=20 =20 This document specifies several security requirements including=20 privacy of information, and authorization, privacy and integrity or=20 requests and responses. =20 =20 =20 =0C ENUM Requirements June = 2000 =0D =20 =20 The system will be designed to retrieve information required to=20 initiate an Internet telephony session. Each of these session types = will have their own security threats, which should be addressed in=20 the groups responsible for those services.=20 =20 5. References=20 =20 =20 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP=20 9, RFC 2026, October 1996.=20 =20 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement=20 Levels", BCP 14, RFC 2119, March 1997=20 =20 6. Acknowledgements =20 =20 This document is based on discussions from the ENUM working group.=20 =20 7. Author's Addresses=20 =20 Anne Brown=20 Nortel Networks=20 P.O. Box 3511, Station C=20 K1Y 4H7=20 Phone: +1 613 765 5274=20 Email: arbrown@nortelnetworks.com=20 =20 8. Changes From draft-enum-rqmts-00.txt=20 =20 Based on WG discussions and input documents from the SG2 workshop,=20 the following changes have been made since the previous version of=20 this draft:=20 =20 3.1 Endpoint Address Lookup=20 Major - URLs are not the only response=20 3.3 Retrieval of Additional Information and Capabilities=20 Renamed from "Retrieval of Additional Information"=20 Minor - Added paragraph on capabilities=20 3.5 Provisioning=20 Major - New text involving change of ENUM scope=20 3.6 Propagation of Changes=20 New section=20 Major - New section based on nnar-e164-dns-iw-info.txt=20 3.9 Scalability=20 Renumbered from 3.8=20 Major - New paragraph on handling of both blocks and=20 individual telephone numbers.=20 3.10 Query Performance=20 Renumbered from 3.9=20 Major - Upgraded to support PSTN performance =20 expectations=20 3.11 Other PSTN Numbering Services=20 Renumbered from 3.10=20 =20 =0C ENUM Requirements June = 2000 =0D =20 =20 Renamed from "Other PSTN Services"=20 Minor - Changes for clarification based on WG =20 discussions and nnar-e164-dns-iw-info.txt=20 =20 3.13 Competition=20 Renumbered from 3.12=20 Major - Telephone number MUST be able to be =20 administered by a single entity=20 =20 3.19 Application Specific Use of ENUM=20 New Section=20 Major - For clarification =20 =20 Full Copyright Statement=20 =20 "Copyright (C) The Internet Society (date). All Rights Reserved.=20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it = or assist in its implmentation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph=20 are included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into=20 =20 =20 =0C ------_=_NextPart_000_01BFD553.D464BF7C-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Jun 13 12:38:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14246 for ; Tue, 13 Jun 2000 12:38:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27705; Tue, 13 Jun 2000 12:37:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27672 for ; Tue, 13 Jun 2000 12:37:40 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14240 for ; Tue, 13 Jun 2000 12:37:40 -0400 (EDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 13 Jun 2000 09:37:00 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Tue, 13 Jun 2000 09:36:59 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF01FF5702@red-msg-24.redmond.corp.microsoft.com> From: Christian Huitema To: "'Richard Shockey'" , enum@ietf.org Cc: Scott Bradner , mankin@east.isi.edu Subject: RE: [Enum] ENUM Working Group Last Call on draft-enum-e164-dns-00 .txt Date: Tue, 13 Jun 2000 09:36:45 -0700 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 The only problem in this document is the existence and mandate of a fixed root, e164.int, which poses the classic "monopoly" problem. The problem has already been debated at length, but its documentation is worth at least a paragraph in the (missing) IANA considerations section -- or should that be ICANN? _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Jun 13 13:17: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 ESMTP id NAA15640 for ; Tue, 13 Jun 2000 13:17:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28197; Tue, 13 Jun 2000 13:16:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28166 for ; Tue, 13 Jun 2000 13:16:25 -0400 (EDT) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15625 for ; Tue, 13 Jun 2000 13:16:23 -0400 (EDT) Received: from computer.ix.netcom.com ([209.138.153.181]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA23246; Tue, 13 Jun 2000 13:16:14 -0400 (EDT) Message-Id: <4.3.1.2.20000613115930.00c03420@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 13 Jun 2000 12:17:14 -0500 To: Christian Huitema , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] ENUM Working Group Last Call on draft-enum-e164-dns-00 .txt Cc: Scott Bradner , mankin@east.isi.edu In-Reply-To: <2E3FA0558747934A8F753CC533A3F6DF01FF5702@red-msg-24.redmon d.corp.microsoft.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 09:36 AM 6/13/2000 -0700, Christian Huitema wrote: >The only problem in this document is the existence and mandate of a fixed >root, e164.int, which poses the classic "monopoly" problem. The problem has >already been debated at length, but its documentation is worth at least a >paragraph in the (missing) IANA considerations section -- or should that be >ICANN? I agree .. we all know the problem exists. IMHO IANA for now... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please Note New Contact Information: Richard Shockey Shockey Consulting LLC 5237 Sutherland St. Louis, MO 63109 Voice 314.503.0640 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 14 06:59:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15210 for ; Wed, 14 Jun 2000 06:59:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22084; Wed, 14 Jun 2000 06:59:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22053 for ; Wed, 14 Jun 2000 06:59:05 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15185; Wed, 14 Jun 2000 06:59:04 -0400 (EDT) Message-Id: <200006141059.GAA15185@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, 14 Jun 2000 06:59:04 -0400 Subject: [Enum] I-D ACTION:draft-ietf-enum-rqmts-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. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Requirements Author(s) : A. Brown Filename : draft-ietf-enum-rqmts-01.txt Pages : Date : 13-Jun-00 This paper defines the requirements for a DNS-based architecture and protocols for mapping a telephone number to a set of attributes (e.g., URLs) which can be used to contact a resource associated with that number. There are many possible protocols that can be considered for a telephone number mapping service. The purpose of this document is to focus discussion on a DNS-based solution. The intention is to enumerate the expectations of such a solution and to clarify the scope. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-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-ietf-enum-rqmts-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-ietf-enum-rqmts-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: <20000613124450.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-rqmts-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-rqmts-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000613124450.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jun 19 13:14:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16419 for ; Mon, 19 Jun 2000 13:14:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22139; Mon, 19 Jun 2000 13:13:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22108 for ; Mon, 19 Jun 2000 13:13:34 -0400 (EDT) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16333 for ; Mon, 19 Jun 2000 13:13:33 -0400 (EDT) Received: from computer.ix.netcom.com ([209.138.179.32]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA29273 for ; Mon, 19 Jun 2000 13:13:30 -0400 (EDT) Message-Id: <4.3.1.2.20000619121309.00c52dc0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 19 Jun 2000 12:14:16 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: I-D ACTION:draft-folts-ohno-ieps-considerations-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 Though aspects of this ID are out of scope for our charter... its well worth considering. >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-folts-ohno-ieps-considerations-00.txt >Date: Mon, 19 Jun 2000 07:00:08 -0400 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Functional Requirements for Priority Services to > Support Critical Communications > Author(s) : H. Folts, H. Ohno > Filename : draft-folts-ohno-ieps-considerations-00.txt > Pages : 12 > Date : 16-Jun-00 > >This draft requests development of detailed specifications for the >technical and operational requirements for an Internet-based >International Emergency Preparedness Scheme (IEPS) as >defined by ITU-T Recommendation E.106. Public >telecommunications services have long had such a >scheme, to ensure priority handling of telephone >communications, such as during natural disasters. As a >wide range of communication services increasingly rely >upon the family of specifications related to Internet >Protocol (IP), IETF work needs to include consideration >and provision for supporting IEPS. This work needs to >be addressed in two phases concurrently - 1) interface >for transition from today's public switched telephone >network (PSTN) to IP-based network telephony services, >and 2) additional and enhanced capabilities, such as >application-specific IEPS services. An Email list for discussion >and a Web site for background and documents has been established >to assist the work > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-folts-ohno-ieps-considerations-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-folts-ohno-ieps-considerations-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-folts-ohno-ieps-considerations-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20000616143557.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-folts-ohno-ieps-considerations-00.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please Note New Contact Information: Richard Shockey Shockey Consulting LLC 5237 Sutherland St. Louis, MO 63109 Voice 314.503.0640 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sat Jun 24 21:24:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16452 for ; Sat, 24 Jun 2000 21:24:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07650; Sat, 24 Jun 2000 21:23:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07619 for ; Sat, 24 Jun 2000 21:23:05 -0400 (EDT) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16445 for ; Sat, 24 Jun 2000 21:23:05 -0400 (EDT) Received: from computer.ix.netcom.com ([209.138.154.206]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id VAA07224; Sat, 24 Jun 2000 21:23:03 -0400 (EDT) Message-Id: <4.3.1.2.20000624200646.00bf4540@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 24 Jun 2000 20:23:19 -0500 To: enum@ietf.org From: Richard Shockey Cc: Scott Bradner , mankin@east.isi.edu, michaelm@NETSOL.COM In-Reply-To: <4.3.1.2.20000605102851.00cb92c0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] REMINDER : ENUM Working Group Last Call on draft-enum-e164-dns-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I want to remind folks that we are in last call for the following document. The deadline is July 4... US Independence day ..which for many reasons seems appropriate. Its speak now or forever hold your peace. I am just going to add my 2 cents worth here on what should be changed. 1. Remove references to .int . It should be replaced with .foo or .arpa which seems to be the logical place that this administrative function should be placed per IAB agreements etc. 2. A clear statement that ENUM is "application agnostic" and it will be dependent on other Work Groups to actually define how ENUM is used, either for VPIM or SIP or whatever. 3. I do not want to create any dependencies here on moving the document forward. Since we do reference NAPTR examples, we should remind the authors of that draft that we _are_ moving forward and their cooperation would be helpful. In that light we will need to revise our milestones and at this time its clear that .. A. By August we hope to have both our Requirements document and Patrik's draft in the IESG hopper. B. By October we should have discussed the tricky issue of delegation and decided on a course of action. DNAME, CNAME, PTR etc. That IMHO will be a central topic of discussion in Pittsburgh. C. If anyone is interested in presenting any material in Pittsburgh...now it the time to think about what you want to present and request some time for presenting it. I have asked for a 2 1/2 hour slot and I have every reason to believe that we will use all of it. >In that case I want to issue a WG Last call on E.164 number and >DNS draft-enum-e164-dns-00.txt. > > Title : E.164 number and DNS > Author(s) : P. Faltstrom > Filename : draft-ietf-enum-e164-dns-00.txt > Pages : 11 > Date : 02-May-00 > >This document discusses the use of DNS for storage of E.164 numbers. >More specifically, how DNS can be used for identifying available >services connected to one E.164 number. Routing of the actual >connection using the service selected using these methods is not >discussed. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-00.txt Your co chair..... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please Note New Contact Information: Richard Shockey Shockey Consulting LLC 5237 Sutherland St. Louis, MO 63109 Voice 314.503.0640 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jun 26 08:23:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02389 for ; Mon, 26 Jun 2000 08:23:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06203; Mon, 26 Jun 2000 08:22:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06172 for ; Mon, 26 Jun 2000 08:22:05 -0400 (EDT) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02365 for ; Mon, 26 Jun 2000 08:22:05 -0400 (EDT) Received: from mo3980r1.ems.att.com ([135.38.12.14]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id IAA16489; Mon, 26 Jun 2000 08:20:33 -0400 (EDT) Received: from njb140bh1.ems.att.com by mo3980r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id IAA11545; Mon, 26 Jun 2000 08:14:12 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 08:20:33 -0400 Message-ID: <012F722EA7AFD211860B00E0290C6C5B047E2EAA@njc240po04.mt.att.com> From: "Pfautz, Penn L, NNAD" To: enum@ietf.org Cc: Scott Bradner , mankin@east.isi.edu, michaelm@netsol.com Subject: RE: [Enum] REMINDER : ENUM Working Group Last Call on draft-enum- e164-dns-00.txt Date: Mon, 26 Jun 2000 08:20:30 -0400 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 Re the last call on enum-e164-dns-00.txt: I'm concerned that the draft does not address or cite the complications introduced by Number Portability. Below I give an example based on the current situation in the US because it's the one I'm most familiar with but I suspect the issues will have more general relevance. Therefore I hope that others familiar with practices elsewhere will share their perspectives. I don't pretend to have a clean solution to the problems of portability, but I think the draft needs to at least allude to the kinds of problems portability introduces. I'd suggest adding a paragraph to the draft like the following: Number portability complicates the implementation of the ENUM service because in some cases it complicates the hierarchy of numbering space authority. For example, when a subscriber ports their number away from the service provider to which it was originally delegated, the numbering authority may no longer be able to redirect a query to the correct service provider. In that case queries must either be redirected by the original service provider or else the numbering authority or a surrogate must track number assignments at the individual telephone number level. The former approach raises performance, reliability, and authority issues, especially when a single number ports multiple times. The latter approach requires a more burdensome centralized infrastructure. Such issues will be a topic of further work by the WG. USA example number portability issue relative to use of ENUM/DNS In the US Central Office codes (NPA-NXXs) are assigned by the North American Numbering Plan Administrator. Neustar (formerly Lockheed-Martin CIS) provides this function. Thus, following the draft's logic in the example, NANPA/Neustar would be the regulator. (Actually routing information is maintained in the Local Exchange Routing Guide (LERG) which is a Telcordia (formerly Bellcore) product made available for a fee.) Let's assume , however, that for some unspecified financial consideration the NANPA agrees to provide the top-level DNS function for NANP numbers. NANPA could then direct queries to the DNS of the service provider to which the central office code containing the queried number was assigned. But subscribers may port their geographically significant numbers to a service provider other than the one to which the number was originally assigned. The Number Portability Administration Center (NPAC, currently also run by Neustar but in principle independent of NANPA) maintains the industry database-of-record of ported number assignments. These data are NOT public and access must be contracted for by service providers who must agree to some limitations on its use and dissemination. So if a number is ported, a query to the NANPA will not result in redirection the proper service provider's DNS. There are several alternatives, none of them pretty: The ported-from or donor service provider could redirect the query to the new SP. But if the customer ported again would the original SP be obligated to continue to track the number? Or would the donor redirect to the first ported-to SP who would redirect to the second ported-to SP, etc.? The original SP could indicate a need to query a ported number database, perhaps maintained by the NPAC All calls could simply query a master database that included ported numbers. This approach, however, leads away from the distributed database structure that is the basis of DNS To complicate things further, the US Federal Communications Commission (FCC) has ordered a process called number pooling that will have the NANPA assign numbers not in blocks of 10,000 (NPA-NXX) but in blocks of 1000 (NPA-NXX-X). Network routing of blocks assigned to carriers other than that to which the Central Office code is assigned will be handled by treating numbers in pooled blocks as being ported to the assigned carrier. With little pooling yet in place the US already has 8M ported numbers with between 0.5-0.75M being added each month so ported numbers will soon represent a non-negligible fraction of the North American Numbering Plan space. Non-geographic toll-free ("800") numbers are also portable in the US. Data indicating the Responsible Organization (RESPORG) for each number are contained in the 800 SMS which is operated under tariffs of the former Bell Operating companies by yet another contractor and these data too are not in the public domain. Since there is no inherent assignment of toll-free number blocks to service providers, there is no basis for establishing a distributed DNS structure aligned with zones of authority as exists for internet domains. And, in the absence of some authority being set up to provide a master database, there is no place for an individual toll-free number owner to put a DNS record for their number that would be generally reachable. The active North American toll-free number space is on the order of 24M numbers with additional toll-free codes planned. Penn Pfautz AT&T E4-3A01 200 S. Laurel Ave Middletown, NJ 07748 732-420-4962 ppfautz@att.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jun 26 10:42:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07351 for ; Mon, 26 Jun 2000 10:42:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07957; Mon, 26 Jun 2000 10:41:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07926 for ; Mon, 26 Jun 2000 10:41:19 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07299 for ; Mon, 26 Jun 2000 10:41:17 -0400 (EDT) Received: from [192.168.124.95] (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id QAA08458; Mon, 26 Jun 2000 16:40:38 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@nix.swip.net Message-Id: In-Reply-To: <012F722EA7AFD211860B00E0290C6C5B047E2EAA@njc240po04.mt.att.com> References: <012F722EA7AFD211860B00E0290C6C5B047E2EAA@njc240po04.mt.att.com> Date: Mon, 26 Jun 2000 16:33:41 +0200 To: "Pfautz, Penn L, NNAD" , enum@ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] REMINDER : ENUM Working Group Last Call on draft-enum- e164-dns-00.txt Cc: Scott Bradner , mankin@east.isi.edu, michaelm@netsol.com 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.20 -0400 00-06-26, Pfautz, Penn L, NNAD wrote: > I'm concerned that the draft does not address or cite the complications >introduced by Number Portability. Earlier versions did, and the reason for removing it is because the situations in the various countries differ so much that it is impossible to state how DNS is used below each country code. For example, 1.e164.arpa will be delegated to someone. How resource records are used in that domain to suit the numbering allocation scheme in the 1 country code is up to the parties involved in that discussion. One way is to simply have an NS record for the actual number pointing to whatever service provider the end user (holder of the E.164 number) wishes, and do that delegation with NS records from Neustar directly. The telco handling PSTN switching doesn't _have_ to be involved. If one want to do a less drastic approach, other RR types such as CNAME or DNAME can be used for handling eventual redirection in the DNS lookup algorithm. The whole point is that one have to see the DNS delegation tree separate from the one in the PSTN world, and the reason one can is just because one have an abstraction layer in DNS/INternet which doesn't exist in the E.164 world. There, a E.164 number is a E.164 number is a .... So, each country code have to handle the delegation in DNS according to their local rules so it suits their way of handling portability. >Number portability complicates the implementation of the ENUM service >because in some cases it complicates the hierarchy of numbering space >authority. For example, when a subscriber ports their number away from the >service provider to which it was originally delegated, the numbering >authority may no longer be able to redirect a query to the correct service >provider. In that case queries must either be redirected by the original >service provider or else the numbering authority or a surrogate must track >number assignments at the individual telephone number level. The former >approach raises performance, reliability, and authority issues, especially >when a single number ports multiple times. The latter approach requires a >more burdensome centralized infrastructure. Such issues will be a topic of >further work by the WG. This is not correct, as when doing a DNS lookup, the lookup always starts at the top of the tree, i.e. at 1.e164.arpa in the case of country code 1. The pointers you talk about is to go from the top down, not from one administrative body to another one in the same level of the hierarchal tree of administrative bodies being authoritive for E.164 numbers. I.e. in the normal portability discussions, one talk about one authority moving one number to a second one. So, the first have to redirect queries to the second one. That is not how DNS works. The second one tell the parent in the DNS tree that he is not authoritative for information of that domain. Exactly how that process is to work is up to the country code as I said earlier. >USA example number portability issue relative to use of ENUM/DNS > >In the US Central Office codes (NPA-NXXs) are assigned by the North >American Numbering Plan Administrator. Neustar (formerly Lockheed-Martin >CIS) provides this function. Thus, following the draft's logic in the >example, NANPA/Neustar would be the regulator. (Actually routing information >is maintained in the Local Exchange Routing Guide (LERG) which is a >Telcordia (formerly Bellcore) product made available for a fee.) Let's >assume , however, that for some unspecified financial consideration the >NANPA agrees to provide the top-level DNS function for NANP numbers. NANPA >could then direct queries to the DNS of the service provider to which the >central office code containing the queried number was assigned. > >But subscribers may port their geographically significant numbers to a >service provider other than the one to which the number was originally >assigned. The Number Portability Administration Center (NPAC, currently also >run by Neustar but in principle independent of NANPA) maintains the industry >database-of-record of ported number assignments. These data are NOT public >and access must be contracted for by service providers who must agree to >some limitations on its use and dissemination. > >So if a number is ported, a query to the NANPA will not result in >redirection the proper service provider's DNS. According to what I have heard, when you query the Neustar (regulator) for NS records, i.e. follow the chain of delegations, you will in DNS always end up at the correct place. You traverse the tree from top to bottom. When a number is moved in the DNS tree, you don't end up in the old place anymore. >There are several >alternatives, none of them pretty: >The ported-from or donor service provider could redirect the query to the >new SP. This is not DNS. etc etc... >Non-geographic toll-free ("800") numbers are also portable in the US. We only talk about E.164 numbers. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jun 26 11:02:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07835 for ; Mon, 26 Jun 2000 11:02:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08317; Mon, 26 Jun 2000 11:01:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08290 for ; Mon, 26 Jun 2000 11:01:04 -0400 (EDT) Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07758 for ; Mon, 26 Jun 2000 11:01:01 -0400 (EDT) Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA10823 for ; Mon, 26 Jun 2000 11:01:03 -0400 (EDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA10810 for ; Mon, 26 Jun 2000 11:01:03 -0400 (EDT) Received: from buzz.ons.octel.com by ihrh1.emsr.lucent.com (8.8.8+Sun/EMS-1.5 Solaris/emsr) id KAA01960 for ; Mon, 26 Jun 2000 10:01:00 -0500 (CDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id KAA19739 for ; Mon, 26 Jun 2000 10:01:01 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 26 Jun 2000 09:58:18 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F4133703705025@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: enum@ietf.org Date: Mon, 26 Jun 2000 09:58:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Enum] NAPTR is not as an ENUM Requirement 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 Coming out of the Adelaide meetings, I understood we had agreement that NAPTR is good and useful but not a requirement for the deployment of the ENUM service. The particular resource records to be queried are a function of the higher-level service being requested. For example, if one is sending regular SMTP mail using telephone numbers, only an MX record is necessary. No additional NAPTR related processing should be required. This separation of the RR type from the ENUM protocol is not clear and should be. In addition to clarifying the many editorial references suggesting NAPTR record queries are the only ones used of ENUM, I suggest adding an example (maybe using MX) to clarify that NAPTR is not required. The specific references I suggest editing are: 1.1 Introduction Was: Through transformation of E.164 numbers into DNS names and the use of existing DNS services like delegation through NS records, and use of NAPTR[1] records in DNS[4], one can look up what services are Suggested: Through transformation of E.164 numbers into DNS names and the use of existing DNS services like delegation through NS records, and resource records such as NAPTR[1], or MX records in DNS[4], one can look up what services are 3. Indentifying available servers This section is very misleading. This entire section needs to be recast as one of at least two examples. The current section reads as a requirement to support only NAPTR for the ENUM service even though there are no "requirement words" such as MUST and SHOULD. In part this is because this section is longer than the ballance of the document! Greg V. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jun 26 11:12:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08012 for ; Mon, 26 Jun 2000 11:12:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08537; Mon, 26 Jun 2000 11:11:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08506 for ; Mon, 26 Jun 2000 11:11:21 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08001 for ; Mon, 26 Jun 2000 11:11:18 -0400 (EDT) Received: from [192.168.124.95] (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id RAA09393; Mon, 26 Jun 2000 17:10:43 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@nix.swip.net Message-Id: In-Reply-To: <6B57F36F4FF9D111B30A0008C7F4133703705025@exdal1.ons.octel.com> References: <6B57F36F4FF9D111B30A0008C7F4133703705025@exdal1.ons.octel.com> Date: Mon, 26 Jun 2000 17:07:22 +0200 To: "Vaudreuil, Greg M (Greg)" , enum@ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Enum] NAPTR is not as an ENUM Requirement 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.58 -0500 00-06-26, Vaudreuil, Greg M (Greg) wrote: >Coming out of the Adelaide meetings, I understood we had agreement that >NAPTR is good and useful but not a requirement for the deployment of the >ENUM service. The particular resource records to be queried are a function >of the higher-level service being requested. For example, if one is sending >regular SMTP mail using telephone numbers, only an MX record is necessary. >No additional NAPTR related processing should be required. That is correct, if you know that the recipient can handle email. Also, an MX doesn't give you the local part to use. Because of this, I have tried to solve the problem with going from an E.164 number to a URI, which can be a mailto URI which is what one should use. But, I understand what you are talking about. >This separation of the RR type from the ENUM protocol is not clear and >should be. In addition to clarifying the many editorial references >suggesting NAPTR record queries are the only ones used of ENUM, I suggest >adding an example (maybe using MX) to clarify that NAPTR is not required. > >The specific references I suggest editing are: > >1.1 Introduction > >Was: > Through transformation of E.164 numbers into DNS names and the use > of existing DNS services like delegation through NS records, and use > of NAPTR[1] records in DNS[4], one can look up what services are > >Suggested: > Through transformation of E.164 numbers into DNS names and the use > of existing DNS services like delegation through NS records, and >resource > records such as NAPTR[1], or MX records in DNS[4], one can look up what > services are You can not look up what service to use using MX records. That can only be done via NAPTR records. But, I will try to change the text so this is more clear. Personally, I don't think MX is possible to use as you (as I said above) doesn't know the local part of the mail address to use. If you use the E.164 number as a replacement for the domain part, and know by out of band communication (for example) what the local part is, _then_ MX can be used. >3. Indentifying available servers > >This section is very misleading. This entire section needs to be recast as >one of at least two examples. The current section reads as a requirement to >support only NAPTR for the ENUM service even though there are no >"requirement words" such as MUST and SHOULD. In part this is because this >section is longer than the ballance of the document! Ok. Will be changed (the example is wrong anyway...). paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jun 26 11:44:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08911 for ; Mon, 26 Jun 2000 11:44:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09176; Mon, 26 Jun 2000 11:43:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09145 for ; Mon, 26 Jun 2000 11:43:13 -0400 (EDT) Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08860 for ; Mon, 26 Jun 2000 11:43:10 -0400 (EDT) Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA25929 for ; Mon, 26 Jun 2000 11:43:11 -0400 (EDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA25908; Mon, 26 Jun 2000 11:43:11 -0400 (EDT) Received: from buzz.ons.octel.com by ihrh1.emsr.lucent.com (8.8.8+Sun/EMS-1.5 Solaris/emsr) id KAA16385 for ; Mon, 26 Jun 2000 10:43:09 -0500 (CDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id KAA21362; Mon, 26 Jun 2000 10:42:34 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 26 Jun 2000 10:39:52 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F413370370502D@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , enum@ietf.org Subject: RE: [Enum] NAPTR is not as an ENUM Requirement Date: Mon, 26 Jun 2000 10:39:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA09146 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Thanks for the reply. I expect that use of MX records directly would require a separate mail-service specific specification of how to build the domain portion. One leading contender for general email is to use the ENUM domain as follows: 19727332722@2.2.7.2.3.3.7.2.7.9.1.e164.arpa If the local mail gateway will accept telephone number local-part, it can also be provisioned to accept mail addressed to e164.arpa. At that point the local part is examined to determine who it goes to internally. (using laser?) Just a suggestion for an example. Another would be to show the use of SRV records to connect to a named LDAP service. (see draft-vaudreuil-enum-e164dir-00.txt. Greg V. -----Original Message----- From: Patrik Fältström [mailto:paf@swip.net] Sent: Monday, June 26, 2000 10:07 AM To: Vaudreuil, Greg M (Greg); enum@ietf.org Subject: Re: [Enum] NAPTR is not as an ENUM Requirement At 09.58 -0500 00-06-26, Vaudreuil, Greg M (Greg) wrote: >Coming out of the Adelaide meetings, I understood we had agreement that >NAPTR is good and useful but not a requirement for the deployment of the >ENUM service. The particular resource records to be queried are a function >of the higher-level service being requested. For example, if one is sending >regular SMTP mail using telephone numbers, only an MX record is necessary. >No additional NAPTR related processing should be required. That is correct, if you know that the recipient can handle email. Also, an MX doesn't give you the local part to use. Because of this, I have tried to solve the problem with going from an E.164 number to a URI, which can be a mailto URI which is what one should use. But, I understand what you are talking about. >This separation of the RR type from the ENUM protocol is not clear and >should be. In addition to clarifying the many editorial references >suggesting NAPTR record queries are the only ones used of ENUM, I suggest >adding an example (maybe using MX) to clarify that NAPTR is not required. > >The specific references I suggest editing are: > >1.1 Introduction > >Was: > Through transformation of E.164 numbers into DNS names and the use > of existing DNS services like delegation through NS records, and use > of NAPTR[1] records in DNS[4], one can look up what services are > >Suggested: > Through transformation of E.164 numbers into DNS names and the use > of existing DNS services like delegation through NS records, and >resource > records such as NAPTR[1], or MX records in DNS[4], one can look up what > services are You can not look up what service to use using MX records. That can only be done via NAPTR records. But, I will try to change the text so this is more clear. Personally, I don't think MX is possible to use as you (as I said above) doesn't know the local part of the mail address to use. If you use the E.164 number as a replacement for the domain part, and know by out of band communication (for example) what the local part is, _then_ MX can be used. >3. Indentifying available servers > >This section is very misleading. This entire section needs to be recast as >one of at least two examples. The current section reads as a requirement to >support only NAPTR for the ENUM service even though there are no >"requirement words" such as MUST and SHOULD. In part this is because this >section is longer than the ballance of the document! Ok. Will be changed (the example is wrong anyway...). paf _______________________________________________ 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 Jun 26 11:52:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09050 for ; Mon, 26 Jun 2000 11:52:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09353; Mon, 26 Jun 2000 11:51:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09279 for ; Mon, 26 Jun 2000 11:51:15 -0400 (EDT) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09027 for ; Mon, 26 Jun 2000 11:51:12 -0400 (EDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Mon, 26 Jun 2000 10:42:08 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 10:45:18 -0500 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24018D2756@bcarua63.ca.nortel.com> From: "Anne Brown" To: "'ENUM'" Subject: FW: [Enum] NAPTR is not as an ENUM Requirement Date: Mon, 26 Jun 2000 10:45:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDF85.85FB506C" X-Orig: Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDF85.85FB506C Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable As stated in the requirements draft, the ENUM system provides a service = for the retrieval of service-specific endpoint addresses OR the retrieval = of the addresses of servers, if available, which may contain this endpoint information. The RR is not required to provide resource-based and service-specific information as this type of information will be very difficult to maintain at a global level. This will be especially true = for enterprise-based information. Though I don't have any proposed text or examples to contribute, I = would like to see text in the abstract and introduction, stating that there = are other alternative uses of the ENUM service than retrieval of service-specific information. =20 Regards, Anne Brown Nortel Networks arbrown@nortelnetworks.com +1 613 765 5274 -----Original Message----- From: Patrik F=E4ltstr=F6m [mailto:paf@swip.net]=20 Sent: June 26, 2000 11:07 AM To: Vaudreuil, Greg M (Greg); enum@ietf.org Subject: Re: [Enum] NAPTR is not as an ENUM Requirement At 09.58 -0500 00-06-26, Vaudreuil, Greg M (Greg) wrote: >Coming out of the Adelaide meetings, I understood we had agreement = that >NAPTR is good and useful but not a requirement for the deployment of = the >ENUM service. The particular resource records to be queried are a = function >of the higher-level service being requested. For example, if one is sending >regular SMTP mail using telephone numbers, only an MX record is = necessary. >No additional NAPTR related processing should be required. That is correct, if you know that the recipient can handle email.=20 Also, an MX doesn't give you the local part to use. Because of this, I have tried to solve the problem with going from an = E.164 number to a URI, which can be a mailto URI which is what one should = use. But, I understand what you are talking about. >This separation of the RR type from the ENUM protocol is not clear and >should be. In addition to clarifying the many editorial references >suggesting NAPTR record queries are the only ones used of ENUM, I = suggest >adding an example (maybe using MX) to clarify that NAPTR is not = required. > >The specific references I suggest editing are: > >1.1 Introduction > >Was: > Through transformation of E.164 numbers into DNS names and the = use > of existing DNS services like delegation through NS records, and = use > of NAPTR[1] records in DNS[4], one can look up what services are > >Suggested: > Through transformation of E.164 numbers into DNS names and the = use > of existing DNS services like delegation through NS records, and >resource > records such as NAPTR[1], or MX records in DNS[4], one can look = up what > services are You can not look up what service to use using MX records. That can only = be done via NAPTR records. But, I will try to change the text so this is more clear. Personally, I don't think MX is possible to use as you (as I said = above) doesn't know the local part of the mail address to use. If you use the = E.164 number as a replacement for the domain part, and know by out of band communication (for example) what the local part is, _then_ MX can be = used. >3. Indentifying available servers > >This section is very misleading. This entire section needs to be = recast as >one of at least two examples. The current section reads as a = requirement to >support only NAPTR for the ENUM service even though there are no >"requirement words" such as MUST and SHOULD. In part this is because = this >section is longer than the ballance of the document! Ok. Will be changed (the example is wrong anyway...). paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01BFDF85.85FB506C Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable FW: [Enum] NAPTR is not as an ENUM Requirement

As stated in the requirements draft, the ENUM system = provides a service for the retrieval of service-specific endpoint = addresses OR the retrieval of the addresses of servers, if  = available, which may contain this endpoint information.  The RR is = not required to provide resource-based and service-specific information = as this type of information will be very difficult to maintain at a = global level.  This will be especially true for enterprise-based = information.

Though I don't have any proposed text or examples to = contribute, I would like to see text in the abstract and introduction, = stating that there are other alternative uses of the ENUM service than = retrieval of service-specific information. 

Regards,

Anne Brown
Nortel Networks
arbrown@nortelnetworks.com
+1 613 765 5274

-----Original Message-----
From:   Patrik F=E4ltstr=F6m [mailto:paf@swip.net]
Sent:   June 26, 2000 11:07 AM
To:     Vaudreuil, Greg M = (Greg); enum@ietf.org
Subject:        = Re: [Enum] NAPTR is not as an ENUM Requirement

At 09.58 -0500 00-06-26, Vaudreuil, Greg M (Greg) = wrote:
>Coming out of the Adelaide meetings, I = understood we had agreement that
>NAPTR is good and useful but not a requirement = for the deployment of the
>ENUM service.  The particular resource = records to be queried are a function
>of the higher-level service being = requested.  For example, if one is sending
>regular SMTP mail using telephone numbers, only = an MX record is necessary.
>No additional NAPTR related processing should be = required.

That is correct, if you know that the recipient can = handle email.
Also, an MX doesn't give you the local part to = use.
Because of this, I have tried to solve the problem = with going from an E.164 number to a URI, which can be a mailto URI = which is what one should use.

But, I understand what you are talking about.
>This separation of the RR type from the ENUM = protocol is not clear and
>should be.  In addition to clarifying the = many editorial references
>suggesting NAPTR record queries are the only = ones used of ENUM, I suggest
>adding an example (maybe using MX) to clarify = that NAPTR is not required.
>
>The specific references I suggest editing = are:
>
>1.1 Introduction
>
>Was:
>     Through transformation = of E.164 numbers into DNS names and the use
>     of existing DNS = services like delegation through NS records, and use
>     of NAPTR[1] records in = DNS[4], one can look up what services are
>
>Suggested:
>     Through transformation = of E.164 numbers into DNS names and the use
>     of existing DNS = services like delegation through NS records, and
>resource
>     records such as = NAPTR[1], or MX records in DNS[4], one can look up what
>     services are

You can not look up what service to use using MX = records. That can only be done via NAPTR records.
But, I will try to change the text so this is more = clear.
Personally, I don't think MX is possible to use as = you (as I said above) doesn't know the local part of the mail address = to use. If you use the E.164 number as a replacement for the domain = part, and know by out of band communication (for example) what the = local part is, _then_ MX can be used.

>3. Indentifying available servers
>
>This section is very misleading.  This = entire section needs to be recast as
>one of at least two examples.  The current = section reads as a requirement to
>support only NAPTR for the ENUM service even = though there are no
>"requirement words" such as MUST and = SHOULD.  In part this is because this
>section is longer than the ballance of the = document!

Ok.
Will be changed (the example is wrong = anyway...).
paf

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

------_=_NextPart_001_01BFDF85.85FB506C-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jun 26 11:55:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09112 for ; Mon, 26 Jun 2000 11:55:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09425; Mon, 26 Jun 2000 11:54:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09394 for ; Mon, 26 Jun 2000 11:54:36 -0400 (EDT) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09081 for ; Mon, 26 Jun 2000 11:54:33 -0400 (EDT) Received: from computer.ix.netcom.com (pool-209-138-11-4.ipls.grid.net [209.138.11.4]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA24774; Mon, 26 Jun 2000 11:54:10 -0400 (EDT) Message-Id: <4.3.1.2.20000626103704.00d30960@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 26 Jun 2000 10:55:04 -0500 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Pfautz, Penn L, NNAD" , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] REMINDER : ENUM Working Group Last Call on draft-enum- e164-dns-00.txt Cc: Scott Bradner , mankin@east.isi.edu, michaelm@netsol.com In-Reply-To: References: < <012F722EA7AFD211860B00E0290C6C5B047E2EAA@njc240po04.mt.att.com> <012F722EA7AFD211860B00E0290C6C5B047E2EAA@njc240po04.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 > >etc etc... > >>Non-geographic toll-free ("800") numbers are also portable in the US. > >We only talk about E.164 numbers. Freephone numbers (800,888) _are_ e164 numbers in the ITU definition, however all of your other points are essentially correct. The problem is that the administration of numbers in a PSTN world is different from a DNS world since, in DNS, e164 numbers numbers have no meaning at all. They are names. There is only one type of delegation in ENUM. The subscriber or their authorized representative provisions the appropriate NS. But because of portability ENUM lookup is always to the last digit, except in those very rare occurrences where a NXX block or NXX-X block has been given to a enterprise or a corporation. Plus given the extreme desire of the regulators to avoid a total NANP renumbering, that practice may no longer be permitted and even enterprises will be forced to enter the pooling system. The key is the application environment. A "800" number can be ported from service provider to service provider in the PSTN world but that would not necessarily require a change in its DNS RR since, the SIP service provider for that number may be entirely different carrier...indeed there may be multiple SIP carriers listed for a particular number ( for fallback and redundancy ) and a H.323 carrier as well. Changing the service provider for circuit switched calls would not effect the IP service providers. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please Note New Contact Information: Richard Shockey Shockey Consulting LLC 5237 Sutherland St. Louis, MO 63109 Voice 314.503.0640 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jun 26 12:27:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10085 for ; Mon, 26 Jun 2000 12:27:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09981; Mon, 26 Jun 2000 12:25:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09952 for ; Mon, 26 Jun 2000 12:25:06 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10026 for ; Mon, 26 Jun 2000 12:25:05 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA28641 for ; Mon, 26 Jun 2000 09:25:05 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id JAA23437 for ; Mon, 26 Jun 2000 09:25:04 -0700 (PDT) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Mon, 26 Jun 2000 07:04:26 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 10:04:25 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBCA1@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Pfautz, Penn L, NNAD'" , enum@ietf.org Subject: RE: [Enum] REMINDER : ENUM Working Group Last Call on draft-enum-e164-dns-00.txt Date: Mon, 26 Jun 2000 10:04:15 -0400 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 Unless I'm not understanding the problem at all, it seems to me that the concern you raise is caused by the fact that "portable numbers" in the US still are geographically significant, E.164 numbers, which are assigned to service providers. But this is not the case in Europe, where their structure is flat? I'm not sure how portable numbers can continue to be defined and assigned in the US as they are now. What are the long-term plans for this? Anyone know? Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] > Re the last call on enum-e164-dns-00.txt: > > > I'm concerned that the draft does not address or cite the > complications > introduced by Number Portability. Below I give an example > based on the > current situation in the US because it's the one I'm most > familiar with but > I suspect the issues will have more general relevance. > Therefore I hope > that others familiar with practices elsewhere will share their > perspectives. > I don't pretend to have a clean solution to the problems of > portability, but > I think the draft needs to at least allude to the kinds of problems > portability introduces. > > I'd suggest adding a paragraph to the draft like the following: > > Number portability complicates the implementation of the ENUM service > because in some cases it complicates the hierarchy of numbering space > authority. For example, when a subscriber ports their number > away from the > service provider to which it was originally delegated, the numbering > authority may no longer be able to redirect a query to the > correct service > provider. In that case queries must either be redirected by > the original > service provider or else the numbering authority or a > surrogate must track > number assignments at the individual telephone number level. > The former > approach raises performance, reliability, and authority > issues, especially > when a single number ports multiple times. The latter > approach requires a > more burdensome centralized infrastructure. Such issues will > be a topic of > further work by the WG. > > USA example number portability issue relative to use of ENUM/DNS > > In the US Central Office codes (NPA-NXXs) are assigned by the North > American Numbering Plan Administrator. Neustar (formerly > Lockheed-Martin > CIS) provides this function. Thus, following the draft's logic in the > example, NANPA/Neustar would be the regulator. (Actually > routing information > is maintained in the Local Exchange Routing Guide (LERG) which is a > Telcordia (formerly Bellcore) product made available for a fee.) Let's > assume , however, that for some unspecified financial > consideration the > NANPA agrees to provide the top-level DNS function for NANP > numbers. NANPA > could then direct queries to the DNS of the service provider > to which the > central office code containing the queried number was assigned. > > But subscribers may port their geographically significant numbers to a > service provider other than the one to which the number was originally > assigned. The Number Portability Administration Center (NPAC, > currently also > run by Neustar but in principle independent of NANPA) > maintains the industry > database-of-record of ported number assignments. These data > are NOT public > and access must be contracted for by service providers who > must agree to > some limitations on its use and dissemination. > > So if a number is ported, a query to the NANPA will not result in > redirection the proper service provider's DNS. There are several > alternatives, none of them pretty: > The ported-from or donor service provider could redirect the > query to the > new SP. But if the customer ported again would the original > SP be obligated > to continue to track the number? Or would the donor redirect > to the first > ported-to SP who would redirect to the second ported-to SP, etc.? > The original SP could indicate a need to query a ported > number database, > perhaps maintained by the NPAC > All calls could simply query a master database that included ported > numbers. This approach, however, leads away from the > distributed database > structure that is the basis of DNS > > To complicate things further, the US Federal Communications > Commission (FCC) > has ordered a process called number pooling that will have > the NANPA assign > numbers not in blocks of 10,000 (NPA-NXX) but in blocks of > 1000 (NPA-NXX-X). > Network routing of blocks assigned to carriers other than > that to which the > Central Office code is assigned will be handled by treating numbers in > pooled blocks as being ported to the assigned carrier. With > little pooling > yet in place the US already has 8M ported numbers with > between 0.5-0.75M > being added each month so ported numbers will soon represent a > non-negligible fraction of the North American Numbering Plan space. > > Non-geographic toll-free ("800") numbers are also portable in > the US. Data > indicating the Responsible Organization (RESPORG) for each number are > contained in the 800 SMS which is operated under tariffs of > the former Bell > Operating companies by yet another contractor and these data > too are not in > the public domain. Since there is no inherent assignment of > toll-free number > blocks to service providers, there is no basis for establishing a > distributed DNS structure aligned with zones of authority as > exists for > internet domains. And, in the absence of some authority being > set up to > provide a master database, there is no place for an > individual toll-free > number owner to put a DNS record for their number that would > be generally > reachable. The active North American toll-free number space > is on the order > of 24M numbers with additional toll-free codes planned. > > Penn Pfautz > AT&T E4-3A01 > 200 S. Laurel Ave > Middletown, NJ 07748 > 732-420-4962 > ppfautz@att.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 Jun 26 12:27:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10096 for ; Mon, 26 Jun 2000 12:27:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09941; Mon, 26 Jun 2000 12:25:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09913 for ; Mon, 26 Jun 2000 12:25:01 -0400 (EDT) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10023 for ; Mon, 26 Jun 2000 12:25:00 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id MAA03318; Mon, 26 Jun 2000 12:23:06 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id MAA00471; Mon, 26 Jun 2000 12:21:56 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 12:23:03 -0400 Message-ID: From: "Lind, Steven D" To: "'Richard Shockey'" , =?iso-8859-1?Q?Patrik_F?= =?iso-8859-1?Q?=E4ltstr=F6m?= , "Pfautz, Penn L, NNAD" , enum@ietf.org Cc: Scott Bradner , mankin@east.isi.edu, michaelm@netsol.com Subject: RE: [Enum] REMINDER : ENUM Working Group Last Call on draft-enum- e164-dns-00.txt Date: Mon, 26 Jun 2000 12:23:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > Changing the service provider for circuit switched calls would not effect > the IP service providers. > [Lind, Steven, ALINT] I respectfully disagree. From a service perspective, 800 (or international freephone) subcribers (i.e., those that receive calls dialed to an 800 or freephone number) are going to want a consistent customer experience no matter where the call originates (e.g., pstn or ip-based). Having different service providers supplying the 800 service is not going to provide that experience . In most cases, the DNS is probably going to be asked to route the call to the correct service provider and that service provider will then terminate the call, providing the desired customer call handling. Changing the service provider will cause a change in the DNS record to point to the new service provider. Steve Lind AT&T > _______________________________________________ > 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 Jun 26 12:47:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10507 for ; Mon, 26 Jun 2000 12:47:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10343; Mon, 26 Jun 2000 12:46:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10312 for ; Mon, 26 Jun 2000 12:46:06 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10482 for ; Mon, 26 Jun 2000 12:46:03 -0400 (EDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Jun 2000 09:44:27 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Mon, 26 Jun 2000 09:40:57 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF01FF579C@red-msg-24.redmond.corp.microsoft.com> From: Christian Huitema To: "'Manfredi, Albert E'" , "'Pfautz, Penn L, NNAD'" , enum@ietf.org Subject: RE: [Enum] REMINDER : ENUM Working Group Last Call on draft-enum- e164-dns-00.txt Date: Mon, 26 Jun 2000 09:40:53 -0700 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 > Unless I'm not understanding the problem at all, it seems to > me that the > concern you raise is caused by the fact that "portable > numbers" in the US > still are geographically significant, E.164 numbers, which > are assigned to > service providers. But this is not the case in Europe, where > their structure > is flat? This is kind of a red herring. Portable numbers, be they 800 or local numbers, are resolved through a two-tier database. First, a generic database provides the name of the "provider of record" for the 800 number, or to the "selected local provider" for the portable local number. Second, a database within that provider of record provides the mapping to a phone number or a call center (800), or to a physical line (LNP). This structure can be mapped trivially in the DNS: the first mapping is really a name server delegation (NS record pointing to the server of the provider of record) while the second is provided by linking DNS resolution within that provider to the database that provides the 800 mapping or phone number routing. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jun 26 13:17:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11250 for ; Mon, 26 Jun 2000 13:17:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10735; Mon, 26 Jun 2000 13:17:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10704 for ; Mon, 26 Jun 2000 13:17:09 -0400 (EDT) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11246 for ; Mon, 26 Jun 2000 13:17:07 -0400 (EDT) Received: from computer.ix.netcom.com ([209.138.11.4]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA10200; Mon, 26 Jun 2000 13:16:25 -0400 (EDT) Message-Id: <4.3.1.2.20000626114915.00c61850@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 26 Jun 2000 12:17:14 -0500 To: "Lind, Steven D" , Patrik F =?iso-8859-1?Q?=E4ltstr=F6m?= , "Pfautz, Penn L, NNAD" , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] REMINDER : ENUM Working Group Last Call on draft-enum- e164-dns-00.txt Cc: Scott Bradner , mankin@east.isi.edu, michaelm@netsol.com 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:23 PM 6/26/2000 -0400, Lind, Steven D wrote: > > Changing the service provider for circuit switched calls would not effect > > the IP service providers. > > > [Lind, Steven, ALINT] I respectfully disagree. From a service >perspective, 800 (or international freephone) subcribers (i.e., those that >receive calls dialed to an 800 or freephone number) are going to want a >consistent customer experience no matter where the call originates (e.g., >pstn or ip-based). Of course.... this is understood ..this is the whole point of ENUM. However you must understand that ENUM is essentially subscriber driven. If a subscriber _chooses_ not to list his TN as IP reachable that is their prerogative. Administrative issues are out of scope for this WG but it should be clear that most of think this is a _opt in_ system not _opt out_. >Having different service providers supplying the 800 >service is not going to provide that experience . In most cases, the DNS is >probably going to be asked to route the call to the correct service provider >and that service provider will then terminate the call, providing the >desired customer call handling. Changing the service provider will cause a >change in the DNS record to point to the new service provider. This is the point that seems to hang everyone up...ENUM does _not_ route calls. It only provides a RR response to a query, such as a SRV or NAPTR record. It is the Internet Telephony application that actually processes the call and routes in the appropriate manner. Lets take the example of "MyCompany". It has contracted with both WorldCom and ATT to terminate its SIP routed 800 calls. Upon resolution of a 800 e164 number the following data is revealed. > ;; ord pr fl service re replacement > IN NAPTR 100 10 "u" "sip+N2R" "" "sip:800mycompany@wcom.com" > IN NAPTR 80 10 "u" "sip+N2R" "" "sip:800mycompany@att800net.com" > IN NAPTR 102 10 "u" "smtp+N2R" "" "mailto:information@mycompany.com" In the above scenerio MyCompany is permitting both carriers to terminate their SIP 800 calls with preference given to WorldCom. The caller's SIP application or gateway makes the determination on which service to use and if Wcom is unavailable then ATT can take over the call. Now how WCom or ATT actually routes the call into the call center is not revealed here..only that service is available from 2 carriers. The caller has no idea ( or desire ) on how the call is processed. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please Note New Contact Information: Richard Shockey Shockey Consulting LLC 5237 Sutherland St. Louis, MO 63109 Voice 314.503.0640 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jun 26 17:04:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15846 for ; Mon, 26 Jun 2000 17:04:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13172; Mon, 26 Jun 2000 17:04:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13104 for ; Mon, 26 Jun 2000 17:04:11 -0400 (EDT) Received: from cqmx.corp.comsat.com (cqmx.corp.comsat.com [134.133.184.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15837; Mon, 26 Jun 2000 17:04:08 -0400 (EDT) From: Andrew.Gallant@comsat.com Received: from cqgate5.cmc.comsat.com ([134.133.162.20]) by cqmx.corp.comsat.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Mon, 26 Jun 2000 17:03:14 -0400 Received: from ccMail by cqgate5.cmc.comsat.com (IMA Internet Exchange 3.13) id 00079989; Mon, 26 Jun 2000 17:06:19 -0400 Mime-Version: 1.0 Date: Mon, 26 Jun 2000 17:00:36 -0400 Message-ID: <00079989.C22277@comsat.com> To: enum@ietf.org Cc: Richard Shockey , itu+ietf@ietf.org Subject: Re: [Enum] Re: 48th IETF: ENUM ... Scheduling Content-Type: multipart/mixed; boundary="IMA.Boundary.9753502690" 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 Mime message, which your current mail reader may not understand. Parts of the message will appear as text. To process the remainder, you will need to use a Mime compatible mail reader. Contact your vendor for details. --IMA.Boundary.9753502690 Content-Type: text/plain; charset="US-ASCII" Content-Description: cc:Mail note part Content-Transfer-Encoding: 7bit Subject: Request for some time on the ENUM agenda in Pittsburgh After some discussions with Richard Shockey and others, I would like to request 20 minutes (total) on the ENUM agenda in Pittsburgh for two presentations: 1. Overview of the Number Portability Supplement to ITU-T E.164 I plan to give an overview as requested, along with submitting an Internet Draft containing the text version. That text version may be found at: http://www.itu.int/ITU-T/ip-telecoms/nnar/nnar-number-port-supp.txt 2. A Participant's POV of Some Work in the ITU-T's Numbering Question As an individual(!), I will present some information about some recent results, future work, and upcoming meetings. If I can, I'll prepare an I-D of the material. Note: Only information from ITU-T reports and outputs will be used, and (disclaimer alert!) I will be speaking for myself and not on behalf of any particular organization, corporation, or Administration. Finally, if I finish some research related to NNAR Issue 6 (E.164, URL's and "Telephony" - see Attachment 1 of www.itu.int/ITU-T/ip-telecoms/ip-telecoms.htm) in time, I'll submit an I-D. It's not directly ENUM-related, so I'm not asking for any ENUM time in Pittsburgh. However, whenever I get it done, I'll ask for comments. -Andy Gallant Andrew Gallant Comsat Corporation T: +1-301-214-3264 F: +1-301-214-7226 E: andrew.gallant@comsat.com ______________________________ Reply Separator _________________________________ Subject: [Enum] Re: 48th IETF: ENUM Working Group/BOF Scheduling Author: Richard Shockey at INTERNET-IMA Date: 6/2/00 11:28 AM At 01:32 PM 5/24/2000 -0400, you wrote: >Meeting Dates: July 30 - August 4, 2000 > >We will be taking scheduling requests for ALL Working Groups and >BOFs starting today. The cut-off for requesting a slot is Friday, >July 7 at 5:00 PM ET. The agenda for the working group is due by >Monday, July 24 at 5:00 PM ET, please submit the agenda to: > agenda@ietf.org The ENUM WG in the Transport area requests one single 2 1/2 hour session similar to the session scheduled in Australia. We would anticipate a similar audience for the group [150+] Conflicts to avoid would be: VPIM, DNSEXT, DNSOPS, SIP ( if possible), IPTEL. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please Note New Contact Information: Richard Shockey Shockey Consulting LLC 5237 Sutherland St. Louis, MO 63109 Voice 314.503.0640 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum --IMA.Boundary.9753502690 Content-Type: text/plain; charset="US-ASCII"; name="RFC822 message headers" Content-Description: cc:Mail note part Content-Disposition: inline; filename="RFC822 message headers" Content-Transfer-Encoding: 7bit Received: from ro.ctd.comsat.com ([134.133.40.45]) by cqgate6.cmc.comsat.com with SMTP (IMA Internet Exchange 3.13) id 0004851C; Fri, 2 Jun 2000 12:34:55 -0400 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ro.ctd.comsat.com with esmtp (Exim 2.12 #8) id 12xuGQ-0001ti-00 for andrew.gallant@comsat.com; Fri, 2 Jun 2000 12:25:38 -0400 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17315; Fri, 2 Jun 2000 12:27:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17292 for ; Fri, 2 Jun 2000 12:27:55 -0400 (EDT) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06617; Fri, 2 Jun 2000 12:27:51 -0400 (EDT) Received: from computer.ix.netcom.com ([209.138.179.44]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA19364; Fri, 2 Jun 2000 12:27:52 -0400 (EDT) Message-Id: <4.3.1.2.20000602112141.00dff7a0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 02 Jun 2000 11:28:49 -0500 To: agenda@ietf.org From: Richard Shockey Cc: enum@ietf.org, Scott Bradner , mankin@east.isi.edu, Scott Petrack In-Reply-To: <200005241732.NAA09724@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Re: 48th IETF: ENUM Working Group/BOF Scheduling 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 --IMA.Boundary.9753502690-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jun 26 17:38:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16235 for ; Mon, 26 Jun 2000 17:38:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13557; Mon, 26 Jun 2000 17:38:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13526 for ; Mon, 26 Jun 2000 17:38:08 -0400 (EDT) Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16218 for ; Mon, 26 Jun 2000 17:38:06 -0400 (EDT) Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA25877 for ; Mon, 26 Jun 2000 11:25:34 -0400 (EDT) Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA25849; Mon, 26 Jun 2000 11:25:32 -0400 (EDT) Received: from buzz.ons.octel.com by horh1.emsr.lucent.com (8.9.3+Sun/EMS-1.5 Solaris/emsr) id LAA05639 for ; Mon, 26 Jun 2000 11:25:31 -0400 (EDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id KAA20668; Mon, 26 Jun 2000 10:25:30 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 26 Jun 2000 10:22:47 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F413370370502A@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Pfautz, Penn L, NNAD" , enum@ietf.org Cc: Scott Bradner , mankin@east.isi.edu, michaelm@netsol.com Subject: RE: [Enum] REMINDER : ENUM Working Group Last Call on draft-enum- e164-dns-00.txt Date: Mon, 26 Jun 2000 10:22:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >I.e. in the normal portability discussions, one talk about one >authority moving one number to a second one. So, the first have to >redirect queries to the second one. That is not how DNS works. The >second one tell the parent in the DNS tree that he is not >authoritative for information of that domain. >Exactly how that process is to work is up to the country code as I >said earlier. There is enough comonality here that we must discuss the protocol mechanics. It is clear that NS delegation in the face of number portability will not scale. As you note, when you port a number, the parent in the DNS tree must be notified and must create a separate zone for that number. Because you cannot yank out a single entry in a child's zone file and assign it to another zone, you need to split the child's zone into multiple zones. As I noted in my earlier message, quickly you get to needing tens of millions of zones. We must address this issue if the service is to scale in an interoperable manner! Greg V. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jun 26 18:00:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16417 for ; Mon, 26 Jun 2000 18:00:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13822; Mon, 26 Jun 2000 18:00:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13791 for ; Mon, 26 Jun 2000 18:00:14 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16410 for ; Mon, 26 Jun 2000 18:00:11 -0400 (EDT) Received: from [192.168.110.7] (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id XAA18601; Mon, 26 Jun 2000 23:59:30 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@nix.swip.net Message-Id: In-Reply-To: <6B57F36F4FF9D111B30A0008C7F413370370502D@exdal1.ons.octel.com> References: <6B57F36F4FF9D111B30A0008C7F413370370502D@exdal1.ons.octel.com> Date: Mon, 26 Jun 2000 23:29:31 +0200 To: "Vaudreuil, Greg M (Greg)" , enum@ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] NAPTR is not as an ENUM Requirement 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.39 -0500 00-06-26, Vaudreuil, Greg M (Greg) wrote: >I expect that use of MX records directly would require a separate >mail-service specific specification of how to build the domain portion. The same thing is true for LDAP. I myself thought from the beginning that SRV RR was enough, but it is not. You need in many protocols like SIP, SMTP and LDAP some local metainformation when connecting to the service which you have just found. The reasons for having NAPTR still in the dratf is because: - The idea with ENUM was to go from E.164 to URI, because then you will get both local part and domain and whatever else is needed in that (random) URI scheme - I wanted _one_ way of handling extra protocol specific information, and the world seem to agree on using URIs. This even though, as you point out, the most important part of the draft is to tell how to map a E.164 into a domainname -- which then can be used in whatever way one wants. >One >leading contender for general email is to use the ENUM domain as follows: > > 19727332722@2.2.7.2.3.3.7.2.7.9.1.e164.arpa > >If the local mail gateway will accept telephone number local-part, it can >also be provisioned to accept mail addressed to e164.arpa. At that point >the local part is examined to determine who it goes to internally. (using >laser?) :-) The only downside with this is that the "holder" of the E.164 number also have to have one mail domain for the domain in question, and also one local part. The chance is that the user already have one email address at some random ISP, for example "john.smith@hotmail.com" and it might be problematic for joe to set up another domainname. Hotmail doesn't help him. The ability to have "mailto:john.smith@hotmail.com" in a NAPTR which have as a name the E.164 number is what I think "a good thing". But, I am definitely not opposing your ideas. I am just explaining why I think it is important to have NAPTR still in the draft. >Just a suggestion for an example. Another would be to show the use of SRV >records to connect to a named LDAP service. (see >draft-vaudreuil-enum-e164dir-00.txt. I understand the logic (I think), but I have problems with the examples. For example "5.1 Example: Hypothetical Reachme Service" which shows how to find a specific LDAP server. It doesn't talk about what query to issue at that LDAP service. You talk about " >The client can then use LDAP with the reachme schema to determine >the set of communications technologies available for +1 613 555 >1212. Does that specify exactly what query to issue? In that case, where? In the case of LDAP (and also SIP) I of course (as you understand) rather see the URI be in an NAPTR record instead of using out of band information. Patrik _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jun 26 18:00:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16428 for ; Mon, 26 Jun 2000 18:00:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13869; Mon, 26 Jun 2000 18:00:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13833 for ; Mon, 26 Jun 2000 18:00:31 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16414 for ; Mon, 26 Jun 2000 18:00:28 -0400 (EDT) Received: from [192.168.110.7] (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id XAA18612; Mon, 26 Jun 2000 23:59:46 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@nix.swip.net Message-Id: In-Reply-To: <31AF4D00A662D211B6D10000F8BCBC24018D2756@bcarua63.ca.nortel.com> References: <31AF4D00A662D211B6D10000F8BCBC24018D2756@bcarua63.ca.nortel.com> Date: Mon, 26 Jun 2000 23:56:04 +0200 To: "Anne Brown" , "'ENUM'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: FW: [Enum] NAPTR is not as an ENUM Requirement Cc: Scott Bradner 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.45 -0500 00-06-26, Anne Brown wrote: >As stated in the requirements draft, the ENUM system provides a >service for the retrieval of service-specific endpoint addresses OR >the retrieval of the addresses of servers, if available, which may >contain this endpoint information. I quote the charter of this Working Group: >This working group will define a DNS-based architecture and >protocols for mapping a telephone number to a set of attributes >(e.g. URLs) which can be used to contact a resource associated with >that number. This is what this working group is working with. That said, the mapping from a E.164 number to a domainname can be (re)used for other things, but that is up to other working groups to talk about. Patrik _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jun 26 18:15:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16597 for ; Mon, 26 Jun 2000 18:15:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14028; Mon, 26 Jun 2000 18:13:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13997 for ; Mon, 26 Jun 2000 18:13:01 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16583 for ; Mon, 26 Jun 2000 18:12:58 -0400 (EDT) Received: from [192.168.110.7] (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id AAA19196; Tue, 27 Jun 2000 00:12:09 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@nix.swip.net Message-Id: In-Reply-To: <6B57F36F4FF9D111B30A0008C7F413370370502A@exdal1.ons.octel.com> References: <6B57F36F4FF9D111B30A0008C7F413370370502A@exdal1.ons.octel.com> Date: Tue, 27 Jun 2000 00:01:57 +0200 To: "Vaudreuil, Greg M (Greg)" , "Pfautz, Penn L, NNAD" , enum@ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] REMINDER : ENUM Working Group Last Call on draft-enum- e164-dns-00.txt Cc: Scott Bradner , mankin@east.isi.edu, michaelm@netsol.com 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.22 -0500 00-06-26, Vaudreuil, Greg M (Greg) wrote: >It is clear that NS delegation in the face of number portability will not >scale. What is your basis for this conclusion? I don't agree with you. >As you note, when you port a number, the parent in the DNS tree must >be notified and must create a separate zone for that number. Yes. >Because you >cannot yank out a single entry in a child's zone file and assign it to >another zone, you need to split the child's zone into multiple zones. Yes. >As I >noted in my earlier message, quickly you get to needing tens of millions of >zones. And? DNS is designed to handle tens of millions of zones, but not tens of millions of names in the same zone (as in .com as of today). >We must address this issue if the service is to scale in an interoperable >manner! Why? paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jun 26 18:51:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16796 for ; Mon, 26 Jun 2000 18:51:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14428; Mon, 26 Jun 2000 18:50:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14402 for ; Mon, 26 Jun 2000 18:50:46 -0400 (EDT) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16781 for ; Mon, 26 Jun 2000 18:50:44 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id SAA03180; Mon, 26 Jun 2000 18:38:28 -0400 (EDT) Date: Mon, 26 Jun 2000 18:38:28 -0400 From: Michael Mealling To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: "Vaudreuil, Greg M (Greg)" , "Pfautz, Penn L, NNAD" , enum@ietf.org, Scott Bradner , mankin@east.isi.edu, michaelm@netsol.com Subject: Re: [Enum] REMINDER : ENUM Working Group Last Call on draft-enum- e164-dns-00.txt Message-ID: <20000626183828.A3164@bailey.dscga.com> Reply-To: michaelm@netsol.com References: <6B57F36F4FF9D111B30A0008C7F413370370502A@exdal1.ons.octel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.2i In-Reply-To: ; from paf@swip.net on Tue, Jun 27, 2000 at 12:01:57AM +0200 Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit On Tue, Jun 27, 2000 at 12:01:57AM +0200, Patrik Fältström wrote: > At 10.22 -0500 00-06-26, Vaudreuil, Greg M (Greg) wrote: > >As I > >noted in my earlier message, quickly you get to needing tens of millions of > >zones. > > And? DNS is designed to handle tens of millions of zones, but not > tens of millions of names in the same zone (as in .com as of today). And based on existing operational experience, a mostly stock DNS server can handle both cases on some fairly modest, off the shelf hardware. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jun 26 23:58:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21351 for ; Mon, 26 Jun 2000 23:58:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA17186; Mon, 26 Jun 2000 23:57:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA17121 for ; Mon, 26 Jun 2000 23:57:33 -0400 (EDT) Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21347 for ; Mon, 26 Jun 2000 23:57:31 -0400 (EDT) Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA25856 for ; Mon, 26 Jun 2000 11:25:33 -0400 (EDT) Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA25848; Mon, 26 Jun 2000 11:25:32 -0400 (EDT) Received: from buzz.ons.octel.com by horh1.emsr.lucent.com (8.9.3+Sun/EMS-1.5 Solaris/emsr) id LAA05638 for ; Mon, 26 Jun 2000 11:25:31 -0400 (EDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id KAA20665; Mon, 26 Jun 2000 10:25:29 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 26 Jun 2000 10:22:47 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F4133703705029@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: "Pfautz, Penn L, NNAD" , enum@ietf.org Cc: Scott Bradner , mankin@east.isi.edu, michaelm@netsol.com Subject: RE: [Enum] REMINDER : ENUM Working Group Last Call on draft-enum- e164-dns-00.txt Date: Mon, 26 Jun 2000 10:22:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I would like to further suggest changes to the ENUM protocol to support the it's use in the real-world. Beyond the ability to form an appropriate query domain name the ENUM draft is silent about client requirements to support the ENUM service. The only discussion of client requirements is part of the NAPTR discussions. There are additional requirements on the clients to ensure an interoperable service. In particular, I believe we need to explicitly require client support of the Cname and/or require support of Dname for the ENUM facilities of DNS. If as suggested by the current ENUM draft, only NS records are used to delegate numbers, there will be a huge proliferation of micro-zones, that is, zones of a single telephone number. Within a small corporation with say, twenty numbers, this will require a DNS set-up with twenty zone-files. In larger corporations like Lucent that receive 100-number blocks of numbers as well as thousands of individual delegations, this will require THOUSANDS of separate zone-files. Within a public telephony service provider suffering number portability, there will be tens to hundreds of millions of separate zones. Each has it's own SOA records. Each file of course needs to be hosted by a secondary making an inordinate number of separate zone-transfers necessary. I don't think this is possible within BIND. While one could use a database other than BIND, administrating and operating this service would face huge deployment obsticals. The only mechanism being considered at this time to make this workable is the Cname and Dname records. In this manner, the delegations to unit of one can be remapped to a single zone hosted by a corporation or service provider. Now Lucent could host a single zone with thousands of entries (trivial). However, this can only be achieved if the entities which delegate the numbers use Cname (for singletons) or Dname (for number blocks). Given that Cname and Dname resolution is not automatically performed by most resolvers, clients MUST be able to deal with both Cnames and Dnames or they will not work for large parts of the number space. These issues are discussed at length in draft-vaudreuil-enum-e164dir-00.txt. However, to make an interoperable protocol, implementation requirements for client and servers must be in the ENUM "protocol" document itself. Greg V. -----Original Message----- From: Pfautz, Penn L, NNAD [mailto:ppfautz@att.com] Sent: Monday, June 26, 2000 7:21 AM To: enum@ietf.org Cc: Scott Bradner; mankin@east.isi.edu; michaelm@netsol.com Subject: RE: [Enum] REMINDER : ENUM Working Group Last Call on draft-enum- e164-dns-00.txt Re the last call on enum-e164-dns-00.txt: I'm concerned that the draft does not address or cite the complications introduced by Number Portability. Below I give an example based on the current situation in the US because it's the one I'm most familiar with but I suspect the issues will have more general relevance. Therefore I hope that others familiar with practices elsewhere will share their perspectives. I don't pretend to have a clean solution to the problems of portability, but I think the draft needs to at least allude to the kinds of problems portability introduces. I'd suggest adding a paragraph to the draft like the following: Number portability complicates the implementation of the ENUM service because in some cases it complicates the hierarchy of numbering space authority. For example, when a subscriber ports their number away from the service provider to which it was originally delegated, the numbering authority may no longer be able to redirect a query to the correct service provider. In that case queries must either be redirected by the original service provider or else the numbering authority or a surrogate must track number assignments at the individual telephone number level. The former approach raises performance, reliability, and authority issues, especially when a single number ports multiple times. The latter approach requires a more burdensome centralized infrastructure. Such issues will be a topic of further work by the WG. USA example number portability issue relative to use of ENUM/DNS In the US Central Office codes (NPA-NXXs) are assigned by the North American Numbering Plan Administrator. Neustar (formerly Lockheed-Martin CIS) provides this function. Thus, following the draft's logic in the example, NANPA/Neustar would be the regulator. (Actually routing information is maintained in the Local Exchange Routing Guide (LERG) which is a Telcordia (formerly Bellcore) product made available for a fee.) Let's assume , however, that for some unspecified financial consideration the NANPA agrees to provide the top-level DNS function for NANP numbers. NANPA could then direct queries to the DNS of the service provider to which the central office code containing the queried number was assigned. But subscribers may port their geographically significant numbers to a service provider other than the one to which the number was originally assigned. The Number Portability Administration Center (NPAC, currently also run by Neustar but in principle independent of NANPA) maintains the industry database-of-record of ported number assignments. These data are NOT public and access must be contracted for by service providers who must agree to some limitations on its use and dissemination. So if a number is ported, a query to the NANPA will not result in redirection the proper service provider's DNS. There are several alternatives, none of them pretty: The ported-from or donor service provider could redirect the query to the new SP. But if the customer ported again would the original SP be obligated to continue to track the number? Or would the donor redirect to the first ported-to SP who would redirect to the second ported-to SP, etc.? The original SP could indicate a need to query a ported number database, perhaps maintained by the NPAC All calls could simply query a master database that included ported numbers. This approach, however, leads away from the distributed database structure that is the basis of DNS To complicate things further, the US Federal Communications Commission (FCC) has ordered a process called number pooling that will have the NANPA assign numbers not in blocks of 10,000 (NPA-NXX) but in blocks of 1000 (NPA-NXX-X). Network routing of blocks assigned to carriers other than that to which the Central Office code is assigned will be handled by treating numbers in pooled blocks as being ported to the assigned carrier. With little pooling yet in place the US already has 8M ported numbers with between 0.5-0.75M being added each month so ported numbers will soon represent a non-negligible fraction of the North American Numbering Plan space. Non-geographic toll-free ("800") numbers are also portable in the US. Data indicating the Responsible Organization (RESPORG) for each number are contained in the 800 SMS which is operated under tariffs of the former Bell Operating companies by yet another contractor and these data too are not in the public domain. Since there is no inherent assignment of toll-free number blocks to service providers, there is no basis for establishing a distributed DNS structure aligned with zones of authority as exists for internet domains. And, in the absence of some authority being set up to provide a master database, there is no place for an individual toll-free number owner to put a DNS record for their number that would be generally reachable. The active North American toll-free number space is on the order of 24M numbers with additional toll-free codes planned. Penn Pfautz AT&T E4-3A01 200 S. Laurel Ave Middletown, NJ 07748 732-420-4962 ppfautz@att.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 Jun 27 02:00:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28224 for ; Tue, 27 Jun 2000 02:00:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23677; Tue, 27 Jun 2000 02:00:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23631 for ; Tue, 27 Jun 2000 02:00:05 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27656 for ; Tue, 27 Jun 2000 02:00:04 -0400 (EDT) Received: from [192.168.110.7] (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id HAA25820; Tue, 27 Jun 2000 07:59:18 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@nix.swip.net Message-Id: In-Reply-To: <6B57F36F4FF9D111B30A0008C7F4133703705029@exdal1.ons.octel.com> References: <6B57F36F4FF9D111B30A0008C7F4133703705029@exdal1.ons.octel.com> Date: Tue, 27 Jun 2000 07:56:13 +0200 To: "Vaudreuil, Greg M (Greg)" , "Pfautz, Penn L, NNAD" , enum@ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] REMINDER : ENUM Working Group Last Call on draft-enum- e164-dns-00.txt Cc: Scott Bradner , mankin@east.isi.edu, michaelm@netsol.com 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.22 -0500 00-06-26, Vaudreuil, Greg M (Greg) wrote: >In particular, I believe we need to explicitly require client >support of the Cname and/or require support of Dname for the ENUM facilities >of DNS. I will check what is required by a DNS client, and how to point out that every RR which is "required" (like CNAME) must be handled correctly. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Jun 27 09:14:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11235 for ; Tue, 27 Jun 2000 09:14:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27950; Tue, 27 Jun 2000 09:12:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27921 for ; Tue, 27 Jun 2000 09:12:14 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11118 for ; Tue, 27 Jun 2000 09:12:14 -0400 (EDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Tue, 27 Jun 2000 08:09:50 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Jun 2000 08:11:20 -0500 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24018D275A@bcarua63.ca.nortel.com> From: "Anne Brown" To: =?ISO-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , "'ENUM'" Cc: Scott Bradner Subject: RE: FW: [Enum] NAPTR is not as an ENUM Requirement Date: Tue, 27 Jun 2000 08:11:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE039.2EE666F4" 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_01BFE039.2EE666F4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable My comments in text below. Anne Brown Nortel Networks arbrown@nortelnetworks.com +1 613 765 5274 -----Original Message----- From: Patrik F=E4ltstr=F6m [mailto:paf@swip.net]=20 Sent: June 26, 2000 5:56 PM To: Brown, Anne [CAR:5N00:EXCH]; 'ENUM' Cc: Scott Bradner Subject: Re: FW: [Enum] NAPTR is not as an ENUM Requirement At 10.45 -0500 00-06-26, Anne Brown wrote: >As stated in the requirements draft, the ENUM system provides a=20 >service for the retrieval of service-specific endpoint addresses OR=20 >the retrieval of the addresses of servers, if available, which may=20 >contain this endpoint information. I quote the charter of this Working Group: >This working group will define a DNS-based architecture and=20 >protocols for mapping a telephone number to a set of attributes=20 >(e.g. URLs) which can be used to contact a resource associated with=20 >that number. This doesn't contradict with my request. The resource associated with = a number could be a directory server. The top level RR pointing to the directory server need not have service-specific information associated = with it. I would still like to see text in the abstract and introduction, stating that there are alternative uses of the ENUM service than = retrieval of service-specific information. That is, there are alternatives to = the NAPTR RR in the ENUM service. This is what this working group is working with. That said, the mapping from a E.164 number to a domainname can be=20 (re)used for other things, but that is up to other working groups to=20 talk about. I don't know what other groups you are talking about. We need the = ability in ENUM to locate either end-point address information, or the location = of a repository that contains that information. Quoting Greg in an earlier message in which you agreed: >Coming out of the Adelaide meetings, I understood we had agreement = that >NAPTR is good and useful but not a requirement for the deployment of = the >ENUM service. =20 Let's state that, please. Regards, Anne ------_=_NextPart_001_01BFE039.2EE666F4 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: [Enum] NAPTR is not as an ENUM Requirement

My comments in text below.

Anne Brown
Nortel Networks
arbrown@nortelnetworks.com
+1 613 765 5274

 -----Original Message-----
From:   Patrik F=E4ltstr=F6m [mailto:paf@swip.net]
Sent:   June 26, 2000 5:56 PM
To:     Brown, Anne = [CAR:5N00:EXCH]; 'ENUM'
Cc:     Scott Bradner
Subject:        = Re: FW: [Enum] NAPTR is not as an ENUM Requirement

At 10.45 -0500 00-06-26, Anne Brown wrote:
>As stated in the requirements draft, the ENUM = system provides a
>service for the retrieval of service-specific = endpoint addresses OR
>the retrieval of the addresses of servers, = if  available, which may
>contain this endpoint information.

I quote the charter of this Working Group:

>This working group will define a DNS-based = architecture and
>protocols for mapping a telephone number to a = set of attributes
>(e.g. URLs) which can be used to contact a = resource associated with
>that number.

This doesn't contradict with my request.  The = resource associated with a number could be a directory server.  = The top level RR pointing to the directory server need not have = service-specific information associated with it.  I would still = like to see text in the abstract and introduction, stating that there = are alternative uses of the ENUM service than retrieval of = service-specific information.  That is, there are alternatives to = the NAPTR RR in the ENUM service.

This is what this working group is working = with.

That said, the mapping from a E.164 number to a = domainname can be
(re)used for other things, but that is up to other = working groups to
talk about.

I don't know what other groups you are talking = about.  We need the ability in ENUM to locate either end-point = address information, or the location of a repository that contains that = information.

Quoting Greg in an earlier message in which you = agreed:
>Coming out of the Adelaide meetings, I = understood we had agreement that
>NAPTR is good and useful but not a requirement = for the deployment of the
>ENUM service. 

Let's state that, please.

Regards,
Anne

------_=_NextPart_001_01BFE039.2EE666F4-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Jun 27 09:52:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12664 for ; Tue, 27 Jun 2000 09:52:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28380; Tue, 27 Jun 2000 09:50:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28346 for ; Tue, 27 Jun 2000 09:50:24 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12468 for ; Tue, 27 Jun 2000 09:50:23 -0400 (EDT) Received: from [192.168.110.10] (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id PAA10302; Tue, 27 Jun 2000 15:49:38 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@nix.swip.net Message-Id: In-Reply-To: <31AF4D00A662D211B6D10000F8BCBC24018D275A@bcarua63.ca.nortel.com> References: <31AF4D00A662D211B6D10000F8BCBC24018D275A@bcarua63.ca.nortel.com> Date: Tue, 27 Jun 2000 15:44:47 +0200 To: "Anne Brown" , "'ENUM'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: FW: [Enum] NAPTR is not as an ENUM Requirement Cc: Scott Bradner 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.11 -0500 00-06-27, Anne Brown wrote: > >This working group will define a DNS-based architecture and >>protocols for mapping a telephone number to a set of attributes >>(e.g. URLs) which can be used to contact a resource associated with >>that number. > >This doesn't contradict with my request. The resource associated >with a number could be a directory server. The top level RR >pointing to the directory server need not have service-specific >information associated with it. I would still like to see text in >the abstract and introduction, stating that there are alternative >uses of the ENUM service than retrieval of service-specific >information. That is, there are alternatives to the NAPTR RR in the >ENUM service. Can you describe one? Note that the algorithm should be DNS based, the input is a E.164 and the output URL(s). >That said, the mapping from a E.164 number to a domainname can be >(re)used for other things, but that is up to other working groups to >talk about. > >I don't know what other groups you are talking about. We need the >ability in ENUM to locate either end-point address information, or >the location of a repository that contains that information. Other wg's can be created when there is interest and firm statement on what they are supposed to deliver. Note that in the world, the client which only have one E.164 number is to know what to do with that number and get more information. Having an _or_ in the algorithm is normally "a good thing" because that means that the client have to do two things, out of which one will fail (if two choices exist). My take is that I have not seen any other proposal on how to take an E.164 number and get URL(s) back than using DNS and NAPTR RRs. Note that _additional_ information can be found by using LDAP URIs or SIP URIs or whatever after the first DNS resolution. So I am not saying that the NAPTRs are enough for building services, only that having alternative ways of fetching the (initial) URLs will create interoperability problems. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Jun 27 10:22:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13400 for ; Tue, 27 Jun 2000 10:22:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28763; Tue, 27 Jun 2000 10:20:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28736 for ; Tue, 27 Jun 2000 10:20:38 -0400 (EDT) Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13353 for ; Tue, 27 Jun 2000 10:20:37 -0400 (EDT) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg15e1.nortelnetworks.com; Tue, 27 Jun 2000 09:56:58 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Jun 2000 09:56:58 -0400 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24018D275C@bcarua63.ca.nortel.com> From: "Anne Brown" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , "'ENUM'" Cc: Scott Bradner Subject: RE: FW: [Enum] NAPTR is not as an ENUM Requirement Date: Tue, 27 Jun 2000 09:56:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE03F.8EBCDB2A" 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_01BFE03F.8EBCDB2A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Quoting Greg, again, in an earlier message in which you agreed:=20 >Coming out of the Adelaide meetings, I understood we had agreement = that=20 >NAPTR is good and useful but not a requirement for the deployment of = the=20 >ENUM service. =20 Again, let's state that, please. Anne Brown Nortel Networks arbrown@nortelnetworks.com +1 613 765 5274 -----Original Message----- From: Patrik F=E4ltstr=F6m [mailto:paf@swip.net]=20 Sent: June 27, 2000 9:45 AM To: Brown, Anne [CAR:5N00:EXCH]; 'ENUM' Cc: Scott Bradner Subject: RE: FW: [Enum] NAPTR is not as an ENUM Requirement At 08.11 -0500 00-06-27, Anne Brown wrote: > >This working group will define a DNS-based architecture and >>protocols for mapping a telephone number to a set of attributes >>(e.g. URLs) which can be used to contact a resource associated with >>that number. > >This doesn't contradict with my request. The resource associated=20 >with a number could be a directory server. The top level RR=20 >pointing to the directory server need not have service-specific=20 >information associated with it. I would still like to see text in=20 >the abstract and introduction, stating that there are alternative=20 >uses of the ENUM service than retrieval of service-specific=20 >information. That is, there are alternatives to the NAPTR RR in the=20 >ENUM service. Can you describe one? Note that the algorithm should be DNS based, the input is a E.164 and=20 the output URL(s). >That said, the mapping from a E.164 number to a domainname can be >(re)used for other things, but that is up to other working groups to >talk about. > >I don't know what other groups you are talking about. We need the=20 >ability in ENUM to locate either end-point address information, or=20 >the location of a repository that contains that information. Other wg's can be created when there is interest and firm statement=20 on what they are supposed to deliver. Note that in the world, the client which only have one E.164 number=20 is to know what to do with that number and get more information.=20 Having an _or_ in the algorithm is normally "a good thing" because=20 that means that the client have to do two things, out of which one=20 will fail (if two choices exist). My take is that I have not seen any other proposal on how to take an=20 E.164 number and get URL(s) back than using DNS and NAPTR RRs. Note that _additional_ information can be found by using LDAP URIs or=20 SIP URIs or whatever after the first DNS resolution. So I am not=20 saying that the NAPTRs are enough for building services, only that=20 having alternative ways of fetching the (initial) URLs will create=20 interoperability problems. paf ------_=_NextPart_001_01BFE03F.8EBCDB2A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: [Enum] NAPTR is not as an ENUM Requirement

Quoting Greg, again, in an earlier message in which = you agreed:
>Coming out of the Adelaide meetings, I = understood we had agreement that
>NAPTR is good and useful but not a requirement = for the deployment of the
>ENUM service. 

Again, let's state that, please.

Anne Brown
Nortel Networks
arbrown@nortelnetworks.com
+1 613 765 5274

 -----Original Message-----
From:   Patrik F=E4ltstr=F6m [mailto:paf@swip.net]
Sent:   June 27, 2000 9:45 AM
To:     Brown, Anne = [CAR:5N00:EXCH]; 'ENUM'
Cc:     Scott Bradner
Subject:        = RE: FW: [Enum] NAPTR is not as an ENUM Requirement

At 08.11 -0500 00-06-27, Anne Brown wrote:
>  >This working group will define a = DNS-based architecture and
>>protocols for mapping a telephone number to = a set of attributes
>>(e.g. URLs) which can be used to contact a = resource associated with
>>that number.
>
>This doesn't contradict with my request.  = The resource associated
>with a number could be a directory server.  = The top level RR
>pointing to the directory server need not have = service-specific
>information associated with it.  I would = still like to see text in
>the abstract and introduction, stating that = there are alternative
>uses of the ENUM service than retrieval of = service-specific
>information.  That is, there are = alternatives to the NAPTR RR in the
>ENUM service.

Can you describe one?

Note that the algorithm should be DNS based, the = input is a E.164 and
the output URL(s).

>That said, the mapping from a E.164 number to a = domainname can be
>(re)used for other things, but that is up to = other working groups to
>talk about.
>
>I don't know what other groups you are talking = about.  We need the
>ability in ENUM to locate either end-point = address information, or
>the location of a repository that contains that = information.

Other wg's can be created when there is interest and = firm statement
on what they are supposed to deliver.

Note that in the world, the client which only have = one E.164 number
is to know what to do with that number and get more = information.
Having an _or_ in the algorithm is normally "a = good thing" because
that means that the client have to do two things, = out of which one
will fail (if two choices exist).

My take is that I have not seen any other proposal on = how to take an
E.164 number and get URL(s) back than using DNS and = NAPTR RRs.

Note that _additional_ information can be found by = using LDAP URIs or
SIP URIs or whatever after the first DNS resolution. = So I am not
saying that the NAPTRs are enough for building = services, only that
having alternative ways of fetching the (initial) = URLs will create
interoperability problems.

    paf

------_=_NextPart_001_01BFE03F.8EBCDB2A-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Jun 27 10:28:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13630 for ; Tue, 27 Jun 2000 10:28:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28862; Tue, 27 Jun 2000 10:27:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28831 for ; Tue, 27 Jun 2000 10:27:09 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13577 for ; Tue, 27 Jun 2000 10:27:08 -0400 (EDT) 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 KAA12544 for ; Tue, 27 Jun 2000 10:27:09 -0400 (EDT) Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA12520; Tue, 27 Jun 2000 10:27:08 -0400 (EDT) Received: from buzz.ons.octel.com by horh1.emsr.lucent.com (8.9.3+Sun/EMS-1.5 Solaris/emsr) id KAA18282 for ; Tue, 27 Jun 2000 10:27:06 -0400 (EDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id JAA07569; Tue, 27 Jun 2000 09:27:05 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 27 Jun 2000 09:24:23 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F4133703705057@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Anne Brown , "'ENUM'" Cc: Scott Bradner Subject: RE: FW: [Enum] NAPTR is not as an ENUM Requirement Date: Tue, 27 Jun 2000 09:24:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA28832 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit I believe a set of SRV DNS RRs or MX RRs qualifies as a "set of attribute which can be used to contact a resource associated with that number." I read the "(e.g. URLs)" as a parenthetical example, not a restriction on the types of resources that may be supported by the resulting protocol. Greg V. -----Original Message----- From: Patrik Fältström [mailto:paf@swip.net] Sent: Tuesday, June 27, 2000 8:45 AM To: Anne Brown; 'ENUM' Cc: Scott Bradner Subject: RE: FW: [Enum] NAPTR is not as an ENUM Requirement At 08.11 -0500 00-06-27, Anne Brown wrote: > >This working group will define a DNS-based architecture and >>protocols for mapping a telephone number to a set of attributes >>(e.g. URLs) which can be used to contact a resource associated with >>that number. > >This doesn't contradict with my request. The resource associated >with a number could be a directory server. The top level RR >pointing to the directory server need not have service-specific >information associated with it. I would still like to see text in >the abstract and introduction, stating that there are alternative >uses of the ENUM service than retrieval of service-specific >information. That is, there are alternatives to the NAPTR RR in the >ENUM service. Can you describe one? Note that the algorithm should be DNS based, the input is a E.164 and the output URL(s). >That said, the mapping from a E.164 number to a domainname can be >(re)used for other things, but that is up to other working groups to >talk about. > >I don't know what other groups you are talking about. We need the >ability in ENUM to locate either end-point address information, or >the location of a repository that contains that information. Other wg's can be created when there is interest and firm statement on what they are supposed to deliver. Note that in the world, the client which only have one E.164 number is to know what to do with that number and get more information. Having an _or_ in the algorithm is normally "a good thing" because that means that the client have to do two things, out of which one will fail (if two choices exist). My take is that I have not seen any other proposal on how to take an E.164 number and get URL(s) back than using DNS and NAPTR RRs. Note that _additional_ information can be found by using LDAP URIs or SIP URIs or whatever after the first DNS resolution. So I am not saying that the NAPTRs are enough for building services, only that having alternative ways of fetching the (initial) URLs will create interoperability problems. paf _______________________________________________ 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 Jun 27 12:31:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17736 for ; Tue, 27 Jun 2000 12:31:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00965; Tue, 27 Jun 2000 12:29:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00935 for ; Tue, 27 Jun 2000 12:29:39 -0400 (EDT) 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 ESMTP id MAA17580 for ; Tue, 27 Jun 2000 12:29:38 -0400 (EDT) Received: from rwalter ([38.136.73.76]) by hvmta02-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20000627162908.OWAL26052.hvmta02-stg@rwalter> for ; Tue, 27 Jun 2000 12:29:08 -0400 Reply-To: From: "Robert H. Walter" To: Subject: RE: [Enum] NAPTR is not as an ENUM Requirement Date: Tue, 27 Jun 2000 12:30:08 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0023_01BFE033.6E072860" 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 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_0023_01BFE033.6E072860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Patrik Faltstrom wrote: > My take is that I have not seen any other proposal on how to take an > E.164 number and get URL(s) back than using DNS and NAPTR RRs. Patrik please see "Internet-Telephony Directory for Mapping E.164 to Internet Addresses" http://www.ietf.org/internet-drafts/draft-peek-enum-itd-00.txt. The draft describes an approach that takes an E.164 number and service protocol (e.g. SIP, VPIM, etc.) and returns a URI using TXT RRs. Note delegation of the E.164 name space is described using conventional NS and A RRs which eliminates the use of CNAME, DNAME RR's. Bob Walter, CTO NetNumber (www.netnumber.com) ====================================================================== Robert H. Walter Voice: 978.454.4210 x24 NetNumber.com, Inc. Mobile: 617.828.6443 650 Suffolk Street Fax: 978.454.5044 Lowell, MA 01854 Email: rwalter@netnumber.com ------=_NextPart_000_0023_01BFE033.6E072860 Content-Type: text/x-vcard; name="Robert H. Walter.vcf" Content-Disposition: attachment; filename="Robert H. Walter.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Walter;Robert;H. FN:Robert H. Walter NICKNAME:Bob ORG:NetNumber.com, Inc.;Engineering TITLE:CTO, VP Development TEL;WORK;VOICE:(978) 454-4210 x24 TEL;HOME;VOICE:(978) 392-0059 TEL;CELL;VOICE:(617) 828-6443 TEL;WORK;FAX:(978) 454-5044 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;650 Suffolk Street=3D0D=3D0ASuite = 307;Lowell;MA;01854;United States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:650 Suffolk Street=3D0D=3D0ASuite = 307=3D0D=3D0ALowell, MA 01854=3D0D=3D0AUnited States o=3D f America X-WAB-GENDER:2 URL: URL:http://www.netnumber.com BDAY:20000307 EMAIL;PREF;INTERNET:rwalter@netnumber.com REV:20000605T154031Z END:VCARD ------=_NextPart_000_0023_01BFE033.6E072860-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 01:52:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09107 for ; Wed, 28 Jun 2000 01:52:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15039; Wed, 28 Jun 2000 01:51:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15008 for ; Wed, 28 Jun 2000 01:51:53 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09104 for ; Wed, 28 Jun 2000 01:51:53 -0400 (EDT) Received: from [192.168.110.10] (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id HAA00642; Wed, 28 Jun 2000 07:51:04 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: In-Reply-To: <31AF4D00A662D211B6D10000F8BCBC24018D275C@bcarua63.ca.nortel.com> References: <31AF4D00A662D211B6D10000F8BCBC24018D275C@bcarua63.ca.nortel.com> Date: Wed, 28 Jun 2000 07:17:41 +0200 To: "Anne Brown" , "'ENUM'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: FW: [Enum] NAPTR is not as an ENUM Requirement Cc: Scott Bradner 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.56 -0400 00-06-27, Anne Brown wrote: >Quoting Greg, again, in an earlier message in which you agreed: > >Coming out of the Adelaide meetings, I understood we had agreement that > >NAPTR is good and useful but not a requirement for the deployment of the > >ENUM service. > >Again, let's state that, please. I asked you, and have not got a response: - Give me text which describes one algorithm which can be used to go from an E.164 number to a URL What I agreed to is that the domain name itself which is outcome of the pure mapping from E.164 to a domain name can be used for other things, but that is NOT part of the charter of this wg. This wg is to find URLs given a E.164 number. Other wg's can work with other things. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 01:52:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09123 for ; Wed, 28 Jun 2000 01:52:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15090; Wed, 28 Jun 2000 01:52:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15059 for ; Wed, 28 Jun 2000 01:52:28 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09119 for ; Wed, 28 Jun 2000 01:52:27 -0400 (EDT) Received: from [192.168.110.10] (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id HAA00651; Wed, 28 Jun 2000 07:51:21 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: In-Reply-To: <6B57F36F4FF9D111B30A0008C7F4133703705057@exdal1.ons.octel.com> References: <6B57F36F4FF9D111B30A0008C7F4133703705057@exdal1.ons.octel.com> Date: Wed, 28 Jun 2000 07:19:14 +0200 To: "Vaudreuil, Greg M (Greg)" , Anne Brown , "'ENUM'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: FW: [Enum] NAPTR is not as an ENUM Requirement Cc: Scott Bradner 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.24 -0500 00-06-27, Vaudreuil, Greg M (Greg) wrote: >I believe a set of SRV DNS RRs or MX RRs qualifies as a "set of attribute >which can be used to contact a resource associated with that number." I >read the "(e.g. URLs)" as a parenthetical example, not a restriction on the >types of resources that may be supported by the resulting protocol. I do not agree. You need more information than what is stored in an MX or SRV, for both SMTP and LDAP and other protocols I know of. Why do you oppose a URI as the outcome? What can you not express as a URI? paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 01:53:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09144 for ; Wed, 28 Jun 2000 01:53:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15181; Wed, 28 Jun 2000 01:53:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15143 for ; Wed, 28 Jun 2000 01:53:09 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09140 for ; Wed, 28 Jun 2000 01:53:09 -0400 (EDT) Received: from [192.168.110.10] (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id HAA00726; Wed, 28 Jun 2000 07:52:18 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 28 Jun 2000 07:21:12 +0200 To: "Robert H. Walter" , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] NAPTR is not as an ENUM Requirement 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.30 -0400 00-06-27, Robert H. Walter wrote: >The draft describes an approach that takes an E.164 number and >service protocol (e.g. SIP, VPIM, etc.) and returns a URI using >TXT RRs. You can not use TXT RR for that. The DNS wg's in the IETF opposes use of TXT RRs for similar purposes, so this is a showstopper. When storing URI's in the DNS, NAPTRs are used. Full stop. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 02:15:00 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16074 for ; Wed, 28 Jun 2000 02:15:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15473; Wed, 28 Jun 2000 02:13:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15442 for ; Wed, 28 Jun 2000 02:13:38 -0400 (EDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16047 for ; Wed, 28 Jun 2000 02:13:38 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 137B6E-0000Ti-00; Tue, 27 Jun 2000 23:13:26 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: "Robert H. Walter" , Subject: RE: [Enum] NAPTR is not as an ENUM Requirement References: Message-Id: Date: Tue, 27 Jun 2000 23:13:26 -0700 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 draft describes an approach that takes an E.164 number and service >> protocol (e.g. SIP, VPIM, etc.) and returns a URI using TXT RRs. > You can not use TXT RR for that. > The DNS wg's in the IETF opposes use of TXT RRs for similar purposes, > so this is a showstopper. to stick my dnsext co-chair nose in and explain. using TXT RRs to substitute for what would normally be a 'proper' RR is seen as an end-run around the review and registration process. randy _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 09:48:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23048 for ; Wed, 28 Jun 2000 09:48:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20030; Wed, 28 Jun 2000 09:45:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20001 for ; Wed, 28 Jun 2000 09:45:53 -0400 (EDT) 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 ESMTP id JAA23016 for ; Wed, 28 Jun 2000 09:45:53 -0400 (EDT) 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 <20000628134524.WSDQ24415.hvmta03-stg@rwalter>; Wed, 28 Jun 2000 09:45:24 -0400 Reply-To: From: "Robert H. Walter" To: "Randy Bush" , =?us-ascii?B?UGF0cmlrIEZhbHRzdHJvbQ==?= Cc: Subject: RE: [Enum] NAPTR is not as an ENUM Requirement Date: Wed, 28 Jun 2000 09:46:11 -0400 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: 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 Randy, Patrik, Thank you for your comments. I'm in complete agreement. Section 4.2.1 of http://www.ietf.org/internet-drafts/draft-peek-enum-itd-00.txt states that use of either TXT and NAPTR are effectively end-run around's of the review and registration process. TXT RRs are simple, meet the requirement of mapping domain names to URI's, however, they are semantically weak and must derive their context from the zone they reside in. NAPTR RRs are complex in comparison, can map domain names to URI information when formulated as a regex, but are not well suited for this purpose. The following is quoted from the abstract of RFC2168 - Resolution of Uniform Resource Identifiers using the Domain Name System This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. The NAPTR RR is specifically designed to map parts of URI's to domain names, not map domain names into URI's. If you accept that both TXT and NAPTR RR's are both end-run arounds then one must either choose or wait for the creation of a new RR that is specifically designed for mapping domain names to URI's. I would welcome the opportunity to work with the IETF to define this new RR. Bob -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Wednesday, June 28, 2000 2:13 AM To: Patrik Faltstrom Cc: Robert H. Walter; enum@ietf.org Subject: RE: [Enum] NAPTR is not as an ENUM Requirement >> The draft describes an approach that takes an E.164 number and service >> protocol (e.g. SIP, VPIM, etc.) and returns a URI using TXT RRs. > You can not use TXT RR for that. > The DNS wg's in the IETF opposes use of TXT RRs for similar purposes, > so this is a showstopper. to stick my dnsext co-chair nose in and explain. using TXT RRs to substitute for what would normally be a 'proper' RR is seen as an end-run around the review and registration process. randy _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 09:50:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23129 for ; Wed, 28 Jun 2000 09:50:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20131; Wed, 28 Jun 2000 09:49:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20098 for ; Wed, 28 Jun 2000 09:49:13 -0400 (EDT) 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 ESMTP id JAA23068 for ; Wed, 28 Jun 2000 09:49:13 -0400 (EDT) Received: from seagal ([208.146.135.202]) by hvmta02-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20000628134844.XALN26052.hvmta02-stg@seagal> for ; Wed, 28 Jun 2000 09:48:44 -0400 From: "David P. Peek" To: "ENUM List Group" Date: Wed, 28 Jun 2000 09:44:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Enum] Declaring an "Implementation" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit I have two comments concerning the "last call" on the Falstrom draft. 1. I agree with the comments suggesting the removal of defining a specific implementation using the NAPTR RR. Other examples exist in the draft that show the use of another RR (TXT) that could be shown in addition to examples defined by the Greg Vaudreuil/Anne Brown draft. 2. I request that the NAPTR examples be revised so they conform with RFC 2168 and the updated Internet Draft . The replacment field strings used in the examples currently do not conform to the requirements of retrieving a URI using the NAPTR. -dp ------------------------------------- David P. Peek Director, Technology Strategy NetNumber +1-603-362-4315 dpeek@netnumber.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 10:08:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23605 for ; Wed, 28 Jun 2000 10:08:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20480; Wed, 28 Jun 2000 10:07:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20449 for ; Wed, 28 Jun 2000 10:07:39 -0400 (EDT) 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 ESMTP id KAA23587 for ; Wed, 28 Jun 2000 10:07:40 -0400 (EDT) Received: from seagal ([208.146.135.202]) by hvmta02-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20000628140711.XESM26052.hvmta02-stg@seagal> for ; Wed, 28 Jun 2000 10:07:11 -0400 From: "David P. Peek" To: "ENUM List Group" Date: Wed, 28 Jun 2000 10:02:45 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Transfer-Encoding: 8bit Subject: [Enum] FW: Last Call or New Draft? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Question for our chair: In reference to these comments made on the list: -------- At 10.22 -0500 00-06-26, Vaudreuil, Greg M (Greg) wrote: >In particular, I believe we need to explicitly require client >support of the Cname and/or require support of Dname for the ENUM facilities >of DNS. I will check what is required by a DNS client, and how to point out that every RR which is "required" (like CNAME) must be handled correctly. paf --------- CNAME and DNAME are not referenced in the Falstrom draft that is being declared as “last call”. Clearly there are many issues with the use of CNAME and DNAME that have not been discussed within this list group that I’m sure many of us would like to comment on before a "last call". Is there going to be a new draft published thereby removing “last call” on the current draft? If a new version includes the use of CNAME and DNAME there will need to be adequate time for comments to be made prior to making a "last call". -dp ------------------------------------- David P. Peek Director, Technology Strategy NetNumber +1-603-362-4315 dpeek@netnumber.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 10:12:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23698 for ; Wed, 28 Jun 2000 10:12:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20584; Wed, 28 Jun 2000 10:11:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20554 for ; Wed, 28 Jun 2000 10:11:32 -0400 (EDT) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23671 for ; Wed, 28 Jun 2000 10:11:31 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id KAA01274; Wed, 28 Jun 2000 10:01:09 -0400 (EDT) Date: Wed, 28 Jun 2000 10:01:09 -0400 From: Michael Mealling To: "Robert H. Walter" Cc: Randy Bush , Patrik Faltstrom , enum@ietf.org Subject: Re: [Enum] NAPTR is not as an ENUM Requirement Message-ID: <20000628100109.B1236@bailey.dscga.com> Reply-To: michaelm@netsol.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: ; from rwalter@netnumber.com on Wed, Jun 28, 2000 at 09:46:11AM -0400 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 On Wed, Jun 28, 2000 at 09:46:11AM -0400, Robert H. Walter wrote: > Thank you for your comments. I'm in complete agreement. Section 4.2.1 > of http://www.ietf.org/internet-drafts/draft-peek-enum-itd-00.txt states > that use of either TXT and NAPTR are effectively end-run around's of the > review and registration process. TXT RRs are simple, meet the requirement > of mapping domain names to URI's, however, they are semantically weak and > must derive their context from the zone they reside in. NAPTR RRs are > complex in comparison, can map domain names to URI information when > formulated as a regex, but are not well suited for this purpose. The > following is quoted from the abstract of RFC2168 - Resolution of Uniform > Resource Identifiers using the Domain Name System > > This document describes the first, experimental, RDS. It is > implemented by a new DNS Resource Record, NAPTR (Naming Authority > PoinTeR), that provides rules for mapping parts of URIs to > domain names. > > The NAPTR RR is specifically designed to map parts of URI's to domain > names, not map domain names into URI's. If you accept that both TXT > and NAPTR RR's are both end-run arounds then one must either choose or > wait for the creation of a new RR that is specifically designed for > mapping domain names to URI's. I would welcome the opportunity to > work with the IETF to define this new RR. Actually you are incorrect. Those are older documents that have been and are in the process of being updated due to input from the working group. NAPTR is not meant to only map URIs to domain-names. That is simply one 'application' (to use the language from the documents I'm updating). Here's the rough outline (no technical changes, just clarifications about what areas you can use NAPTR for): There is this thing called a Dynamic Delegation Discovery System. It is what we used to call the RDS but RDS was specific to URIs. A DDDS is nothing more than the iterative rewrite algorithm. In order to use it you have to specify an Application and at least one Database. The Application gets to define the Appliction Unique String which is the thing the algoirthm works on to find out specific syntactic rules for delegation. In the case of URI resolution, any URI is the Application Unique String and the inttended output is a server that can authoritatively tell you things about it. In the case of an ENUM application the Unique String would be the e.164 phone number and the output would be URIs that identify services. You can use any Database with the Application. The NAPTR record is how records are encoded in the DNS DDDS Database. Domain-names are that database's keys. Justic Couch defined a database using a flat text file for use with the URI Application. He needed it for URNs in VRML apps where the resolution information was mostly known a head of time. I hope to have new versions of these documents explaining all of this come the first of next week. The important thing to note is that they do not change any technical aspect of how NAPTR works. Specifically, the ENUM drafts will not have any technical aspects of NAPTR changed out from underneath them. They just clarify that you can do it and how you say what it is you are doing... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 10:24:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24005 for ; Wed, 28 Jun 2000 10:24:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20760; Wed, 28 Jun 2000 10:22:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20725 for ; Wed, 28 Jun 2000 10:22:44 -0400 (EDT) Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23965 for ; Wed, 28 Jun 2000 10:22:44 -0400 (EDT) Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA09775 for ; Wed, 28 Jun 2000 10:22:45 -0400 (EDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA09746; Wed, 28 Jun 2000 10:22:44 -0400 (EDT) Received: from buzz.ons.octel.com by ihrh1.emsr.lucent.com (8.8.8+Sun/EMS-1.5 Solaris/emsr) id JAA19077 for ; Wed, 28 Jun 2000 09:22:41 -0500 (CDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id JAA15376; Wed, 28 Jun 2000 09:22:42 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 28 Jun 2000 09:19:59 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F413370370508B@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Anne Brown , "'ENUM'" Cc: Scott Bradner Subject: RE: FW: [Enum] NAPTR is not as an ENUM Requirement Date: Wed, 28 Jun 2000 09:19:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Patrick, >I do not agree. You need more information than what is stored in an >MX or SRV, for both SMTP and LDAP and other protocols I know of. You also need more information that what is stored to use the URL returned from a NAPTR! For the sames reasons an SRV _ldap_tcp or MX record does not provide sufficient information to a client to utilize a service, neither does a LDAP: or Mailto: URL. Except at the most primative level, the URL does not define the interesting stuff, the "schema" of a given service. It still requires out-of-band information, which at a minimum is provided in the URL registration document, but more typically would be in a more comprehensive service-specific document. The SRV is exactly equivalent: if you register a service, you provide the same level of out-of-band information necessary to utilize the identified resource. For example, say I want to accept SMS pages, Store-and-Forward FAX, and Voice messages, each addressed to my one telephone number, but terminating on different devices. (one goes to my mobile phone via an SMS gateway, one to my office Ifax printer, and the third to my legacy voice mail machine). NAPTR provides no additional means of distinguishing to the client which record to use. 2.8.0.4.6.2.6.5.8.6.4.e164.int. IN NAPTR 102 10 "a" "smtp+N2R" "" "mailto:+46856264082@fax.swip.net". IN NAPTR 102 10 "a" "smtp+N2R" "" "mailto:+46856264082@SMS.swip.net". IN NAPTR 102 10 "a" "smtp+N2R" "" "mailto:+46856264082@VPIM.swip.net". If we need to register a new service type for each messaging service, then we have not gained much by the use of NAPTR over a similar record MX record with a service-specific domain-name construction rule. Except more records, more protocol, and a need to upgrade my operating system. >Why do you oppose a URI as the outcome? NAPTR and URL's are overkill for many of the services I envision using the ENUM service. (store-and-forward fax for example) There are deployment obsticals to the use of NAPTRs that do not exist for some of the simpler record types. Some services just do not need information beyond a simple MX record and a service- specific, pre-defined domain-name construction rule. There is a smallish limit to the number of NAPTRs that can be stored for a given telephone number, limited by the size of the DNS packet. There is no way to scope the requests to a subset of NAPTRs relevant to the service requested except to rebuild the mechanism currently defined for the SRV lookup. Artificial interdependency of protocols creates a standardization tangle. I see no reason to the advancement of the ENUM protocol dependent upon the adoption and deployment of NAPTR, a substantially more complicated protocol than ENUM itself. >What can you not express as a URI? What can't you kill with a bazooka? NAPTR and URI is simply not necessary for many important services! DNS resource records are a perfectly adequate way to identify a resource! Greg V. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 10:41:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24471 for ; Wed, 28 Jun 2000 10:41:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21077; Wed, 28 Jun 2000 10:40:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21046 for ; Wed, 28 Jun 2000 10:40:42 -0400 (EDT) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24460 for ; Wed, 28 Jun 2000 10:40:42 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id KAA01338; Wed, 28 Jun 2000 10:30:21 -0400 (EDT) Date: Wed, 28 Jun 2000 10:30:21 -0400 From: Michael Mealling To: "Vaudreuil, Greg M (Greg)" Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Anne Brown , "'ENUM'" , Scott Bradner Subject: Re: FW: [Enum] NAPTR is not as an ENUM Requirement Message-ID: <20000628103021.E1236@bailey.dscga.com> Reply-To: michaelm@netsol.com References: <6B57F36F4FF9D111B30A0008C7F413370370508B@exdal1.ons.octel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <6B57F36F4FF9D111B30A0008C7F413370370508B@exdal1.ons.octel.com>; from gregv@lucent.com on Wed, Jun 28, 2000 at 09:19:57AM -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Wed, Jun 28, 2000 at 09:19:57AM -0500, Vaudreuil, Greg M (Greg) wrote: > >What can you not express as a URI? > > What can't you kill with a bazooka? NAPTR and URI is simply not necessary > for many important services! DNS resource records are a perfectly adequate > way to identify a resource! True. But if I can only carry one weapon, I'd rather it be a bazooka since I know it handles nearly every situation I'll encounter. I.e. DNS records may be adequate for your very limited applications but are you willing to handicap everyeone elses possibly slightly more ambitious applications simply because yours don't need a particular feature? -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 11:18:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25234 for ; Wed, 28 Jun 2000 11:18:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21518; Wed, 28 Jun 2000 11:16:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21490 for ; Wed, 28 Jun 2000 11:16:16 -0400 (EDT) Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25188 for ; Wed, 28 Jun 2000 11:16:16 -0400 (EDT) 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 LAA04897 for ; Wed, 28 Jun 2000 11:16:18 -0400 (EDT) Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA04855; Wed, 28 Jun 2000 11:16:17 -0400 (EDT) Received: from buzz.ons.octel.com by horh1.emsr.lucent.com (8.9.3+Sun/EMS-1.5 Solaris/emsr) id LAA15882 for ; Wed, 28 Jun 2000 11:16:15 -0400 (EDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id KAA19126; Wed, 28 Jun 2000 10:16:14 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 28 Jun 2000 10:13:30 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F413370370508F@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: michaelm@netsol.com Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Anne Brown , "'ENUM'" , Scott Bradner Subject: RE: FW: [Enum] NAPTR is not as an ENUM Requirement Date: Wed, 28 Jun 2000 10:13:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA21491 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit I am sorry to continue such a militaristic theme, but once started... I already carry a knife, a handgun, and a can of pepper spray. I am simply saying that for my personal self-defense, I have what I need. Carrying a bazooka is too much trouble for my needs. It is heavy, unweildy, and hard to check as luggage. However, if you have an challenging assignment, by all means carry one. I am not arguing that NAPTRs are not useful, nor that they are unnecessary for certian applications. I just don't buy the argument that we need a "biggest-size fits all" solution.... especially when I have a several solutions that may do just fine. The latest posted version NAPTR is defined in 26 dense pages of specification not including referenced specifications. The rule-sets require additional configuration files and substantial processing logic on the resolver or client. The client must deal with a wide-variety of responses from an arbitary server including indefinite levels of recursion. Given that NAPTR logic is not supported in any deployed resolvers, that means any application developed for the next few years should implement this logic. However, NAPTR is very expensive overkill for many (most) initial applications. My experience with other standards suggest that most application developers will take short-cuts when they work and do not initially hinder the product. Few initial applications need the power or flexibility of NAPTR. The DNS client is not the core-value of most telephone-number based applications. If required to use NAPTR, most developers will take short-cuts that may have the effect of blocking general use of the best parts of NAPTR. This is likely because servers will have to be conservatively configured to not break the installed base of popular clients implemented with the obvious short-cuts.) Just a few more thoughts.. Greg V. -----Original Message----- From: Michael Mealling [mailto:michael@bailey.dscga.com] Sent: Wednesday, June 28, 2000 9:30 AM To: Vaudreuil, Greg M (Greg) Cc: Patrik Fältström; Anne Brown; 'ENUM'; Scott Bradner Subject: Re: FW: [Enum] NAPTR is not as an ENUM Requirement On Wed, Jun 28, 2000 at 09:19:57AM -0500, Vaudreuil, Greg M (Greg) wrote: > >What can you not express as a URI? > > What can't you kill with a bazooka? NAPTR and URI is simply not necessary > for many important services! DNS resource records are a perfectly adequate > way to identify a resource! True. But if I can only carry one weapon, I'd rather it be a bazooka since I know it handles nearly every situation I'll encounter. I.e. DNS records may be adequate for your very limited applications but are you willing to handicap everyeone elses possibly slightly more ambitious applications simply because yours don't need a particular feature? -MM -- ---------------------------------------------------------------------------- ---- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 11:22:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25344 for ; Wed, 28 Jun 2000 11:22:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21681; Wed, 28 Jun 2000 11:22:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21615 for ; Wed, 28 Jun 2000 11:22:07 -0400 (EDT) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25336; Wed, 28 Jun 2000 11:22:07 -0400 (EDT) Received: from computer.ix.netcom.com ([209.138.176.187]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA15372; Wed, 28 Jun 2000 11:22:00 -0400 (EDT) Message-Id: <4.3.1.2.20000626202535.00bc59d0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 28 Jun 2000 10:22:38 -0500 To: Andrew.Gallant@comsat.com, Randy Bush From: Richard Shockey Subject: Re[4]: [ITU+IETF] Re: [Enum] Re: 48th IETF: ENUM ... Sch Cc: , enum@ietf.org, itu+ietf@ietf.org In-Reply-To: <00079E99.C22277@comsat.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 08:23 PM 6/26/2000 -0400, Andrew.Gallant@comsat.com wrote: > No problem. I agree with you in theory and a great deal in practice. > > OTOH, re NP I was asked, and re ITU (I'm an individual!) for this info > (e.g., status of certain E.164 codes, next meetings, ...) I think face > time is important. Andy.. I'm sympathetic to Randy's concerns..to a point. There are differences in process that have to be understood...and it is the differences in process that often cause the most difficulty between IETF and ITU. In the IETF the work _should_ be done on the list since that is what they are there for. IETF meetings are crammed with lots of issues that need to be resolved in a short period of time. Meetings of WG's at IETF sessions by definition have to be very "structured" in the sense that there is no time for formal "presentations" of protocols or information. The assumption is that there has been work posted to the list and that during the meeting there is a fast recap of the salient issues and then open discussion of the issues involved in the hope that "rough consensus" can be reached, or a path to solution defined. > > It's a shared and interactive medium -- and I certainly will be brief > (if I do in fact present). The few minutes shared as proposed would > be useful and applicable to a larger audience than ENUM, but (again > IMO) not worth repeating nor worth doing in any other/larger group. > To me the tradeoff is worth it on these MORE GENERAL areas. > > I want the day to come when your position comes to apply here. One > trap related to numbering is that it's the tip of many icebergs. When > a group can actually work on requirements and protocols, I'm on your > side. Sorry for the rambling ... > > Let's see what else comes back from the list. I posted my original request in the spirit that folks who wanted to present material at Pittsburgh get their material together NOW, much as you have started to do. Format ID's or, as you have done, create pointers to the relevant documents. I believe that your documents and your presence in Pittsburgh is very valuable. There is a amazing lack of understanding of what Number Portability is within the IETF and how it might relate to ENUM in general. I have also asked James Yu and Mark Foster of NeuStar to consider updating their previous ID on the subject as well. The work of SG2/Q1 in many ways directly impacts our work so it is vitally important that people understand what is happening in the ITU and what the future work plans are. I also firmly believe in the ongoing cooperation between the ITU and the IETF.. and I will bend over backwards, if necessary, to accommodate the wishes of the many distinguished participants in ITU work, such as yourself, who are opening channels of communication between our organizations. So. What I want is for you to submit whatever you want as ID'd by the July 15 deadline. I think we'd all prefer IETF ID's, vs ITU URL's, so the documents can be exposed to a larger audience. I'll hold a spot for you at the ENUM meeting! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please Note New Contact Information: Richard Shockey Shockey Consulting LLC 5237 Sutherland St. Louis, MO 63109 Voice 314.503.0640 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 11:24:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25391 for ; Wed, 28 Jun 2000 11:24:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21769; Wed, 28 Jun 2000 11:22:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21696 for ; Wed, 28 Jun 2000 11:22:16 -0400 (EDT) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25340 for ; Wed, 28 Jun 2000 11:22:16 -0400 (EDT) Received: from computer.ix.netcom.com ([209.138.176.187]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA15716; Wed, 28 Jun 2000 11:22:06 -0400 (EDT) Message-Id: <4.3.1.2.20000628093412.00be0470@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 28 Jun 2000 09:57:18 -0500 To: Randy Bush , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Richard Shockey Subject: RE: [Enum] NAPTR is not as an ENUM Requirement Cc: "Robert H. Walter" , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11:13 PM 6/27/2000 -0700, Randy Bush wrote: > >> The draft describes an approach that takes an E.164 number and service > >> protocol (e.g. SIP, VPIM, etc.) and returns a URI using TXT RRs. > > You can not use TXT RR for that. > > The DNS wg's in the IETF opposes use of TXT RRs for similar purposes, > > so this is a showstopper. > >to stick my dnsext co-chair nose in and explain. using TXT RRs to >substitute for what would normally be a 'proper' RR is seen as an >end-run around the review and registration process. Thanks Randy... I need clarification on one issue... As I understand it ..and I could be wrong here, a request for NAPTR records will return ALL records associated with a particular number. If there are _lots_ of services associated with a phone number it is conceivable that one could reach the 256 byte limit on UDP transmission and the NS would then signal the resolver to open up a TCP connection for the retrieval of the records. However if SRV records are used ...the resolver can request _only_ those records associated with a service, correct? I'm not arguing for or against the use of NAPTR vs SRV. I restate my belief that these definitions and any appropriate IANA registration must come from the appropriate application WG. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please Note New Contact Information: Richard Shockey Shockey Consulting LLC 5237 Sutherland St. Louis, MO 63109 Voice 314.503.0640 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 11:29:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25581 for ; Wed, 28 Jun 2000 11:29:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21903; Wed, 28 Jun 2000 11:28:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21872 for ; Wed, 28 Jun 2000 11:28:14 -0400 (EDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25528 for ; Wed, 28 Jun 2000 11:28:13 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 137Jl4-0005lo-00; Wed, 28 Jun 2000 08:28:10 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Richard Shockey Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Robert H. Walter" , Subject: RE: [Enum] NAPTR is not as an ENUM Requirement References: <4.3.1.2.20000628093412.00be0470@127.0.0.1> Message-Id: Date: Wed, 28 Jun 2000 08:28:10 -0700 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 > Thanks Randy... I need clarification on one issue... As I understand it > ..and I could be wrong here, a request for NAPTR records will return ALL > records associated with a particular number. > > If there are _lots_ of services associated with a phone number it is > conceivable that one could reach the 256 byte limit on UDP transmission and > the NS would then signal the resolver to open up a TCP connection for the > retrieval of the records. > > However if SRV records are used ...the resolver can request _only_ those > records associated with a service, correct? no time to look at docs to be sure my foot is in my mouth. but the essential concept is that of rrs of the same label-class-type will be returned as a set. srvs have different names for different services. naptrs do not necessarily. you could get a partial with trunc set. but, if you really expect a glopload, look at requesting with edns0 set and that should make you happier. randy, way out on a limb _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 11:41:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25910 for ; Wed, 28 Jun 2000 11:41:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22238; Wed, 28 Jun 2000 11:40:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22164 for ; Wed, 28 Jun 2000 11:40:43 -0400 (EDT) Received: from cqmx.corp.comsat.com (cqmx.corp.comsat.com [134.133.184.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25876; Wed, 28 Jun 2000 11:40:43 -0400 (EDT) From: Andrew.Gallant@comsat.com Received: from cqgate6.cmc.comsat.com ([134.133.162.21]) by cqmx.corp.comsat.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Wed, 28 Jun 2000 11:39:44 -0400 Received: from ccMail by cqgate6.cmc.comsat.com (IMA Internet Exchange 3.13) id 00059FA5; Wed, 28 Jun 2000 11:46:05 -0400 Mime-Version: 1.0 Date: Wed, 28 Jun 2000 11:37:21 -0400 Message-ID: <00059FA5.C22219@comsat.com> To: Randy Bush , Richard Shockey Cc: paf@swip.net, enum@ietf.org, itu+ietf@ietf.org Subject: Re[5]: [ITU+IETF] Re: [Enum] Re: 48th IETF: ENUM ... Sch Content-Type: multipart/mixed; boundary="IMA.Boundary.5617022690" 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 --IMA.Boundary.5617022690 Content-Type: text/plain; charset="US-ASCII" Content-Description: cc:Mail note part Content-Transfer-Encoding: 7bit Thanks for this. I'll submit what I can as soon as I can. Wish me luck! ______________________________ Reply Separator _________________________________ Subject: Re[4]: [ITU+IETF] Re: [Enum] Re: 48th IETF: ENUM ... Sch Author: Richard Shockey at INTERNET-IMA Date: 6/28/00 10:22 AM At 08:23 PM 6/26/2000 -0400, Andrew.Gallant@comsat.com wrote: > No problem. I agree with you in theory and a great deal in practice. > > OTOH, re NP I was asked, and re ITU (I'm an individual!) for this info > (e.g., status of certain E.164 codes, next meetings, ...) I think face > time is important. Andy.. I'm sympathetic to Randy's concerns..to a point. There are differences in process that have to be understood...and it is the differences in process that often cause the most difficulty between IETF and ITU. In the IETF the work _should_ be done on the list since that is what they are there for. IETF meetings are crammed with lots of issues that need to be resolved in a short period of time. Meetings of WG's at IETF sessions by definition have to be very "structured" in the sense that there is no time for formal "presentations" of protocols or information. The assumption is that there has been work posted to the list and that during the meeting there is a fast recap of the salient issues and then open discussion of the issues involved in the hope that "rough consensus" can be reached, or a path to solution defined. > > It's a shared and interactive medium -- and I certainly will be brief > (if I do in fact present). The few minutes shared as proposed would > be useful and applicable to a larger audience than ENUM, but (again > IMO) not worth repeating nor worth doing in any other/larger group. > To me the tradeoff is worth it on these MORE GENERAL areas. > > I want the day to come when your position comes to apply here. One > trap related to numbering is that it's the tip of many icebergs. When > a group can actually work on requirements and protocols, I'm on your > side. Sorry for the rambling ... > > Let's see what else comes back from the list. I posted my original request in the spirit that folks who wanted to present material at Pittsburgh get their material together NOW, much as you have started to do. Format ID's or, as you have done, create pointers to the relevant documents. I believe that your documents and your presence in Pittsburgh is very valuable. There is a amazing lack of understanding of what Number Portability is within the IETF and how it might relate to ENUM in general. I have also asked James Yu and Mark Foster of NeuStar to consider updating their previous ID on the subject as well. The work of SG2/Q1 in many ways directly impacts our work so it is vitally important that people understand what is happening in the ITU and what the future work plans are. I also firmly believe in the ongoing cooperation between the ITU and the IETF.. and I will bend over backwards, if necessary, to accommodate the wishes of the many distinguished participants in ITU work, such as yourself, who are opening channels of communication between our organizations. So. What I want is for you to submit whatever you want as ID'd by the July 15 deadline. I think we'd all prefer IETF ID's, vs ITU URL's, so the documents can be exposed to a larger audience. I'll hold a spot for you at the ENUM meeting! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please Note New Contact Information: Richard Shockey Shockey Consulting LLC 5237 Sutherland St. Louis, MO 63109 Voice 314.503.0640 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum --IMA.Boundary.5617022690 Content-Type: text/plain; charset="US-ASCII"; name="RFC822 message headers" Content-Description: cc:Mail note part Content-Disposition: inline; filename="RFC822 message headers" Content-Transfer-Encoding: 7bit Received: from ro.ctd.comsat.com ([134.133.40.45]) by cqgate5.cmc.comsat.com with SMTP (IMA Internet Exchange 3.13) id 0007BCFD; Wed, 28 Jun 2000 11:25:27 -0400 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ro.ctd.comsat.com with smtp (Exim 2.12 #8) id 137JfT-000609-00 for andrew.gallant@comsat.com; Wed, 28 Jun 2000 11:22:23 -0400 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21678; Wed, 28 Jun 2000 11:22:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21615 for ; Wed, 28 Jun 2000 11:22:07 -0400 (EDT) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25336; Wed, 28 Jun 2000 11:22:07 -0400 (EDT) Received: from computer.ix.netcom.com ([209.138.176.187]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA15372; Wed, 28 Jun 2000 11:22:00 -0400 (EDT) Message-Id: <4.3.1.2.20000626202535.00bc59d0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 28 Jun 2000 10:22:38 -0500 To: Andrew.Gallant@comsat.com, Randy Bush From: Richard Shockey Subject: Re[4]: [ITU+IETF] Re: [Enum] Re: 48th IETF: ENUM ... Sch Cc: , enum@ietf.org, itu+ietf@ietf.org In-Reply-To: <00079E99.C22277@comsat.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 --IMA.Boundary.5617022690-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 11:42:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25945 for ; Wed, 28 Jun 2000 11:42:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22301; Wed, 28 Jun 2000 11:41:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22266 for ; Wed, 28 Jun 2000 11:41:50 -0400 (EDT) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25929 for ; Wed, 28 Jun 2000 11:41:50 -0400 (EDT) Received: from computer.ix.netcom.com ([209.138.176.187]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA26098; Wed, 28 Jun 2000 11:41:45 -0400 (EDT) Message-Id: <4.3.1.2.20000628103029.00e2e8a0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 28 Jun 2000 10:42:39 -0500 To: "David P. Peek" , "ENUM List Group" From: Richard Shockey Subject: Re: [Enum] FW: Last Call or New Draft? 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 10.22 -0500 00-06-26, Vaudreuil, Greg M (Greg) wrote: > >In particular, I believe we need to explicitly require client > >support of the Cname and/or require support of Dname for the ENUM >facilities > >of DNS. > > >CNAME and DNAME are not referenced in the Falstrom draft that is being >declared as "last call". Clearly there are many issues with the use of >CNAME and DNAME that have not been discussed within this list group that I'm >sure many of us would like to comment on before a "last call". CNAME and DNAME are issues surrounding delegation to NS that are not part of Patrik's draft and it is not necessary to include them. >Is there going to be a new draft published thereby removing "last call" on >the current draft? Well the co-chairs have considerable discretion in these matters. Patrik will have to produce a updated version of his draft. If it is our determination that the edits he has made to his document are essentially editorial and do not affect the protocol. Then I can declare that the last call is finished and move the document forward to the IESG for approval. > If a new version includes the use of CNAME and DNAME >there will need to be adequate time for comments to be made prior to making >a "last call". >-dp The CNAME, DNAME, PTR issues will have to be debated separately or as part of one of Greg's earlier ID. However new submissions on this matter are always welcome! ############ Title : ENUM Service Specific Provisioning: Principles of Operation Author(s) : A. Brown, G. Vaudreuil Filename : draft-vaudreuil-enum-e164dir-01.txt Pages : 9 Date : 27-Apr-00 This document outlines the principles for the operation of a telephone number directory service. This service provides for the resolution of telephone numbers into Internet domain name addresses and service specific directory discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vaudreuil-enum-e164dir-01.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please Note New Contact Information: Richard Shockey Shockey Consulting LLC 5237 Sutherland St. Louis, MO 63109 Voice 314.503.0640 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 12:13:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26908 for ; Wed, 28 Jun 2000 12:13:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23009; Wed, 28 Jun 2000 12:13:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22978 for ; Wed, 28 Jun 2000 12:12:58 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26891 for ; Wed, 28 Jun 2000 12:12:56 -0400 (EDT) Received: from [10.0.1.3] (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id SAA18285; Wed, 28 Jun 2000 18:12:08 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 28 Jun 2000 17:51:24 +0200 To: "David P. Peek" , "ENUM List Group" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Enum] Declaring an "Implementation" 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.44 -0400 00-06-28, David P. Peek wrote: >2. I request that the NAPTR examples be revised so they conform with RFC >2168 and the updated Internet Draft . The >replacment field strings used in the examples currently do not conform to >the requirements of retrieving a URI using the NAPTR. The examples will be updated. I am waiting at the moment for Michael Mealling to correct any mistakes I have in the (not yet published) new version of the draft. I.e. I don't want to have any typos in this (hopfully) last version. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 12:14:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26944 for ; Wed, 28 Jun 2000 12:14:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23095; Wed, 28 Jun 2000 12:13:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23064 for ; Wed, 28 Jun 2000 12:13:22 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26900 for ; Wed, 28 Jun 2000 12:13:20 -0400 (EDT) Received: from [10.0.1.3] (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id SAA18310; Wed, 28 Jun 2000 18:12:36 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 28 Jun 2000 17:56:21 +0200 To: "David P. Peek" , "ENUM List Group" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Enum] FW: Last Call or New Draft? Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit At 10.02 -0400 00-06-28, David P. Peek wrote: >CNAME and DNAME are not referenced in the Falstrom draft that is being >declared as “last call”. Clearly there are many issues with the use of >CNAME and DNAME that have not been discussed within this list group that I’m >sure many of us would like to comment on before a "last call". No, that will not be added explicitely. "DNS services" or some wording like that might be added. We are _not_ going to define how to do resolution in DNS for specific RRs, like NAPTRs. That process and algorithm is defined in other working groups. Writing about the use of CNAME and DNAME in this wg is not an option. >Is there going to be a new draft published thereby removing “last call” on >the current draft? If a new version includes the use of CNAME and DNAME >there will need to be adequate time for comments to be made prior to making >a "last call". There will be a new version. wg last call is never removed. The wg chair is making the decision on what to do next, if a new wg last call is needed or if we can go for an IETF wide last call. Patrik _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 12:14:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26967 for ; Wed, 28 Jun 2000 12:14:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22967; Wed, 28 Jun 2000 12:12:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22937 for ; Wed, 28 Jun 2000 12:12:36 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26874 for ; Wed, 28 Jun 2000 12:12:34 -0400 (EDT) Received: from [10.0.1.3] (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id SAA18270; Wed, 28 Jun 2000 18:11:42 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 28 Jun 2000 17:50:17 +0200 To: "Robert H. Walter" , "Randy Bush" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] NAPTR is not as an ENUM Requirement Cc: 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.46 -0400 00-06-28, Robert H. Walter wrote: >NAPTR RRs are >complex in comparison, can map domain names to URI information when >formulated as a regex, but are not well suited for this purpose. Why are they not well suited? Have you read draft-ietf-urn-naptr-rr-03.txt? >The NAPTR RR is specifically designed to map parts of URI's to domain >names, not map domain names into URI's. Nope, it is designed to map arbitrary text into some other text using regular expressions. That is why the text about non terminals in the enum draft is written as it is. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 12: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 ESMTP id MAA26990 for ; Wed, 28 Jun 2000 12:14:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23146; Wed, 28 Jun 2000 12:13:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23116 for ; Wed, 28 Jun 2000 12:13:45 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26924 for ; Wed, 28 Jun 2000 12:13:43 -0400 (EDT) Received: from [10.0.1.3] (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id SAA18319; Wed, 28 Jun 2000 18:12:45 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: In-Reply-To: <6B57F36F4FF9D111B30A0008C7F413370370508B@exdal1.ons.octel.com> References: <6B57F36F4FF9D111B30A0008C7F413370370508B@exdal1.ons.octel.com> Date: Wed, 28 Jun 2000 18:03:39 +0200 To: "Vaudreuil, Greg M (Greg)" , Anne Brown , "'ENUM'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: FW: [Enum] NAPTR is not as an ENUM Requirement Cc: Scott Bradner 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.19 -0500 00-06-28, Vaudreuil, Greg M (Greg) wrote: >You also need more information that what is stored to use the URL returned >from a NAPTR! Nope. I claim you don't have to. >Except at the most primative level, the URL >does not define the interesting stuff, the "schema" of a given service. In the case of LDAP, the schema discovery service is defined in the LDAPEXt working group. In some other cases, people have to define new URI schemes, or redefine the ones they use. As I said before, this wg is according to the charter working with the problem of resolving a E.164 number to a set of URIs. >For example, say I want to accept SMS pages, Store-and-Forward FAX, and >Voice messages, each addressed to my one telephone number, but terminating >on different devices. (one goes to my mobile phone via an SMS gateway, one >to my office Ifax printer, and the third to my legacy voice mail machine). >NAPTR provides no additional means of distinguishing to the client which >record to use. > > 2.8.0.4.6.2.6.5.8.6.4.e164.int. > IN NAPTR 102 10 "a" "smtp+N2R" "" >"mailto:+46856264082@fax.swip.net". > IN NAPTR 102 10 "a" "smtp+N2R" "" >"mailto:+46856264082@SMS.swip.net". > IN NAPTR 102 10 "a" "smtp+N2R" "" >"mailto:+46856264082@VPIM.swip.net". These are all SMTP services. Not different -- from an internet perspective. > There is a smallish limit to the number of NAPTRs that can be stored > for a given telephone number, limited by the size of the DNS > > packet. Wrong. DNS uses TCP as fallback if the packet is truncated. > I see no reason to the advancement of the ENUM protocol >dependent > upon the adoption and deployment of NAPTR, a substantially >more > complicated protocol than ENUM itself. NAPTR is already supported since a while back in Bind. I don't know what version was the first one supporting it. > >What can you not express as a URI? > >What can't you kill with a bazooka? NAPTR and URI is simply not necessary >for many important services! DNS resource records are a perfectly adequate >way to identify a resource! I have still not seen any examples, more than "store and forward fax services", which is not description of a service from my perspective. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 12:14:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27007 for ; Wed, 28 Jun 2000 12:14:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23185; Wed, 28 Jun 2000 12:13:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23158 for ; Wed, 28 Jun 2000 12:13:55 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26929 for ; Wed, 28 Jun 2000 12:13:52 -0400 (EDT) Received: from [10.0.1.3] (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id SAA18328; Wed, 28 Jun 2000 18:13:01 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: In-Reply-To: <4.3.1.2.20000628093412.00be0470@127.0.0.1> References: <4.3.1.2.20000628093412.00be0470@127.0.0.1> Date: Wed, 28 Jun 2000 18:07:49 +0200 To: Richard Shockey , Randy Bush From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] NAPTR is not as an ENUM Requirement Cc: "Robert H. Walter" , 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.57 -0500 00-06-28, Richard Shockey wrote: >Thanks Randy... I need clarification on one issue... As I understand >it ..and I could be wrong here, a request for NAPTR records will >return ALL records associated with a particular number. If you query for a domainname and a specific RR and class, you get back all records matching that request. >If there are _lots_ of services associated with a phone number it is >conceivable that one could reach the 256 byte limit on UDP >transmission and the NS would then signal the resolver to open up a >TCP connection for the retrieval of the records. The limit is not 256 bytes, but you are in principle correct. >However if SRV records are used ...the resolver can request _only_ >those records associated with a service, correct? See above. On the other hand, you don't know beforehand what services to ask for when you only have the E.164, so you might have to query for a number of SRVs. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 12:14:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27018 for ; Wed, 28 Jun 2000 12:14:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23055; Wed, 28 Jun 2000 12:13:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23022 for ; Wed, 28 Jun 2000 12:13:12 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26896 for ; Wed, 28 Jun 2000 12:13:09 -0400 (EDT) Received: from [10.0.1.3] (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id SAA18295; Wed, 28 Jun 2000 18:12:26 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 28 Jun 2000 17:53:09 +0200 To: "David P. Peek" , "ENUM List Group" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Enum] Declaring an "Implementation" 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.44 -0400 00-06-28, David P. Peek wrote: >1. I agree with the comments suggesting the removal of defining a specific >implementation using the NAPTR RR. Other examples exist in the draft > that show the use of another RR (TXT) that >could be shown in addition to examples defined by the Greg Vaudreuil/Anne >Brown draft. With the word standard in the IETF we mean _one_ agreed way of solving a specific problem. Not alternative ways. If you have more than one alternative, then you don't have interperability. This WG is to solve the problem to, given a E.164 number, get a set of URIs using a DNS-based system. We can not have alternatives for that piece of the puzzle. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 14:09:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29641 for ; Wed, 28 Jun 2000 14:09:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24683; Wed, 28 Jun 2000 14:07:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24652 for ; Wed, 28 Jun 2000 14:07:52 -0400 (EDT) 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 ESMTP id OAA29587 for ; Wed, 28 Jun 2000 14:07:52 -0400 (EDT) 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 <20000628180723.YWMJ24415.hvmta03-stg@rwalter>; Wed, 28 Jun 2000 14:07:23 -0400 Reply-To: From: "Robert H. Walter" To: =?us-ascii?B?UGF0cmlrIEZhbHRzdHJvbQ==?= Cc: Subject: RE: [Enum] NAPTR is not as an ENUM Requirement Date: Wed, 28 Jun 2000 14:08:10 -0400 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: 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 Patrik Faltstrom wrote: >>NAPTR RRs are >>complex in comparison, can map domain names to URI information when >>formulated as a regex, but are not well suited for this purpose. > >Why are they not well suited? NAPTR is not well suited to map domain names to URI's because it envolves non-trivial regular expression processing by the client application and/or resolver. If the Basic NAPTR Algorithm is followed, the regex field must be matched and processed to obtain the resulting URI. The replacement field can not be used because it MUST be a domain name. Don't misunderstand me, all of this can be can be implemented... IMHO it's simply over-kill and not well suited to the objective of SIMPLY mapping a domain name to a URI. Bob _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 14:43:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01385 for ; Wed, 28 Jun 2000 14:43:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25235; Wed, 28 Jun 2000 14:43:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25207 for ; Wed, 28 Jun 2000 14:43:13 -0400 (EDT) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01305 for ; Wed, 28 Jun 2000 14:43:12 -0400 (EDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Wed, 28 Jun 2000 13:35:05 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Jun 2000 13:38:10 -0500 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24018D2760@bcarua63.ca.nortel.com> From: "Anne Brown" To: ENUM List Group Subject: RE: [Enum] Declaring an "Implementation" Date: Wed, 28 Jun 2000 13:38:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE130.01242DB2" X-Orig: Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFE130.01242DB2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Patrik, You stated: " With the word standard in the IETF we mean _one_ agreed way of=20 solving a specific problem. Not alternative ways. If you have more=20 than one alternative, then you don't have interperability." I would be careful with your use of "IETF" definitions. At the onset = of the WG there were several people who wanted a standard protocol for the = ENUM service after investigating the alternatives. And yet the IETF/IESG = saw fit to mandate a DNS-only solution, stating that other WGs could be formed = to work on other solutions to the same problem. This was done even before = the requirements document was started. One of the biggest problems with = this is interoperability, in the event that another WG develops another = solution. =20 You also stated: "We can not have alternatives for that piece of the puzzle." =20 But you have not disagreed with the statement that NAPTR RRs are not a requirement for the deployment of the ENUM service. Yet if you define = NAPTR RRS for use with ENUM and then turn around and state that we must have = only one according to the "IETF", then you are in contradiction.=20 I have asked you to put a statement into your draft indicating that = NAPTR RRs are not a requirement and that there may be others. However you = will not agree to do that unless I give you " text which describes one = algorithm which can be used to go from an E.164 number to a URL", which I told = you beforehand I did not have. =20 Of course you also know from discussions on the listserv that there is = not a consensus on NAPTR as the RR of choice. My particular objection to use = of NAPTR is its requirement to specify service-specifics (e.g., services available and email addresses, etc.) at such a high level, when it understood that DNS is often not appropriate for maintaining = information on a per resource basis (see draft-ietf-urn-dns-rds-01) and such = information is not scaleable and manageable on a global or even a national level. Is it your intention to mandate NAPTR as "the" ENUM RR to be used, and = not allow others? I hope and suspect not and would therefore like to see = text in your draft stating that there are other possible RRs that can be = used. This request does not require for those examples to be stated.=20 Anne Brown Nortel Networks arbrown@nortelnetworks.com +1 613 765 5274 -----Original Message----- From: Patrik F=E4ltstr=F6m [mailto:paf@swip.net]=20 Sent: June 28, 2000 11:53 AM To: David P. Peek; ENUM List Group Subject: Re: [Enum] Declaring an "Implementation" At 09.44 -0400 00-06-28, David P. Peek wrote: >1. I agree with the comments suggesting the removal of defining a = specific >implementation using the NAPTR RR. Other examples exist in the draft > that show the use of another RR (TXT) = that >could be shown in addition to examples defined by the Greg = Vaudreuil/Anne >Brown draft. With the word standard in the IETF we mean _one_ agreed way of=20 solving a specific problem. Not alternative ways. If you have more=20 than one alternative, then you don't have interperability. This WG is to solve the problem to, given a E.164 number, get a set=20 of URIs using a DNS-based system. We can not have alternatives for that piece of the puzzle. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01BFE130.01242DB2 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Enum] Declaring an "Implementation"

Patrik,

You stated:
" With the word standard in the IETF we mean = _one_ agreed way of
solving a specific problem. Not alternative ways. If = you have more
than one alternative, then you don't have = interperability."

I would be careful with your use of "IETF" = definitions.  At the onset of the WG there were several people who = wanted a standard protocol for the ENUM service after investigating the = alternatives.  And yet the IETF/IESG saw fit to mandate a DNS-only = solution, stating that other WGs could be formed to work on other = solutions to the same problem.  This was done even before the = requirements document was started. One of the biggest problems with = this is interoperability, in the event that another WG develops another = solution. 

You also stated:
"We can not have alternatives for that piece of = the puzzle." 

But you have not disagreed with the statement that = NAPTR RRs are not a requirement for the deployment of the ENUM = service.  Yet if you define NAPTR RRS for use with ENUM and then = turn around and state that we must have only one according to the = "IETF", then you are in contradiction.

I have asked you to put a statement into your draft = indicating that NAPTR RRs are not a requirement and that there may be = others.  However you will not agree to do that unless I give you = " text which describes one algorithm which can be used to go from = an E.164 number to a URL", which I told you beforehand I did not = have. 

Of course you also know from discussions on the = listserv that there is not a consensus on NAPTR as the RR of = choice.  My particular objection to use of NAPTR is its = requirement to specify service-specifics (e.g., services available and = email addresses, etc.) at such a high level, when it understood that = DNS is often not appropriate for maintaining information on a per = resource basis (see draft-ietf-urn-dns-rds-01) and such information is = not scaleable and manageable on a global or even a national = level.

Is it your intention to mandate NAPTR as = "the" ENUM RR to be used, and not allow others?  I hope = and suspect not and would therefore like to see text in your draft = stating that there are other possible RRs that can be used.  This = request does not require for those examples to be stated.

Anne Brown
Nortel Networks
arbrown@nortelnetworks.com
+1 613 765 5274

 -----Original Message-----
From:   Patrik F=E4ltstr=F6m [mailto:paf@swip.net]
Sent:   June 28, 2000 11:53 AM
To:     David P. Peek; ENUM List = Group
Subject:        = Re: [Enum] Declaring an "Implementation"

At 09.44 -0400 00-06-28, David P. Peek wrote:
>1. I agree with the comments suggesting the = removal of defining a specific
>implementation using the NAPTR RR.  Other = examples exist in the draft
><draft-peek-enum-itd-00.txt> that show the = use of another RR (TXT) that
>could be shown in addition to examples defined = by the Greg Vaudreuil/Anne
>Brown draft.

With the word standard in the IETF we mean _one_ = agreed way of
solving a specific problem. Not alternative ways. If = you have more
than one alternative, then you don't have = interperability.

This WG is to solve the problem to, given a E.164 = number, get a set
of URIs using a DNS-based system.

We can not have alternatives for that piece of the = puzzle.

   paf

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

------_=_NextPart_001_01BFE130.01242DB2-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 15:07:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02089 for ; Wed, 28 Jun 2000 15:07:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25705; Wed, 28 Jun 2000 15:06:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25678 for ; Wed, 28 Jun 2000 15:06:26 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02082 for ; Wed, 28 Jun 2000 15:06:27 -0400 (EDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 28 Jun 2000 12:05:36 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Wed, 28 Jun 2000 12:03:34 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF01FF57C1@red-msg-24.redmond.corp.microsoft.com> From: Christian Huitema To: Patrik Faltstrom Cc: enum@ietf.org Subject: RE: [Enum] NAPTR is not as an ENUM Requirement Date: Wed, 28 Jun 2000 12:03:30 -0700 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 Reality check here. Enum is defining a way to build DNS names out of E164 numbers. We can use any standard DNS tool to delegate management of a subtree (NS, SOA), to map some of the number space to a subtree managed in another SOA (DNAME), or to map a terminal name to another terminal name (CNAME). Given the operational constraints, CNAME or DNAME look like the solution of choice for terminals; in fact, DNAME are preferable, since we will most probably want at some point to use SRV records, and for that we will need to build a subtree under the number-derived name. We can make the point that this is obvious, since there is just no way this WG could prevent the use of zone delegation or DNAME aliasing in the number derived tree. At mist, this belongs to the operation guidleines, or to the IANA consideration section. Once we have a DNS name, we ought to be able to stick in it pretty much every type of record we want, e.g. MX records to define how to send mail, SRV records for arbitrary applications, etc. NAPTR are useful for some specific applications; when these applications are enabled, the records should be present, and that is pretty much the end of it. So, what are we exactly bickering for? _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 15:59:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02962 for ; Wed, 28 Jun 2000 15:59:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26435; Wed, 28 Jun 2000 15:58:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26408 for ; Wed, 28 Jun 2000 15:58:28 -0400 (EDT) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02928 for ; Wed, 28 Jun 2000 15:58:29 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id PAA23442; Wed, 28 Jun 2000 15:58:00 -0400 (EDT) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id PAA24158; Wed, 28 Jun 2000 15:59:35 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Jun 2000 15:58:00 -0400 Message-ID: <012F722EA7AFD211860B00E0290C6C5B0484C803@njc240po04.mt.att.com> From: "Pfautz, Penn L, NNAD" To: Richard Shockey , ENUM List Group Subject: RE: [Enum] FW: Last Call or New Draft? - Portability Date: Wed, 28 Jun 2000 14:29:01 -0400 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 Richard: Although it sounds like there will be an attempt at some resolution of the issues raised with respect to record type, I'm not sure what's happening re number portability impacts. Some of Patrik's discussion has helped me better understand the issues but also convinced me that, at least in the NANP area, there will need to be a very large database at the 1.e164.int level that provides pointers to the DNS service of the end user's choice for each individual number (or number block for corporate ownership). I've done a crude cut and paste on the example in Patrik's Appendix to illustrate how this might be expected to work. Appendix A. Example 2 The ITU has delegated the country code 1, and the zone 1.e164.int to the North American Numbering Plan. The regulators of the NANP countries have delegated the responsibility for this zone to the contracted NANP Administrator. NANPA Because of that, the content of the e164.int zone is: $ORIGIN e164.int. 1 IN NS nanpa-e164.com Although the NANPA assigns blocks of 10,000 or 1,000 numbers to various Service providers for assignment to end users, numbers are portable so the NANPA DNS provides a zone for each telephone number or block of numbers assigned A single user. Thus the NANPA DNS has a record directing queries for a specific number to the DNS of the current service provider. The user can then either have that provider be the source of authoritative information or request the telephony provider's DNS refer to that of some other DNS service provider. A user named Jenny Jones has from Telco A got the phone number +1 792-867-5309. The user gets the service of running DNS from the company Redirection Service. Jenny Jones has asked Telco A to point out Redirection Service as the authoritative source for information about the number +1 792-867-5309. Telco A because of this puts in its DNS the following. $ORIGIN 1.e164.int. 9.0.3.5.7.6.8.2.9.7 IN NS ns.redirection-service.com Jenny already has plain telephony from Telco A, but also a SIP service from the company Sip Service which provides Jenny with the SIP URI "sip:jenny@sipservice.com.". The ISP with the name ISP A runs email and webpages for Jenny, under the emailaddress jenny@ispa.net, and URL http://jenny.ispa.net The DNS for the redirection service because of this contains the following. $ORIGIN 9.0.3.5.7.6.8.2.9.7.1.e164.int. IN NAPTR 10 10 "a" "sip+N2R" "" "sip:jenny@sipservice.com" IN NAPTR 10 10 "a" "smtp+N2R" "" "mailto:jenny@ispa.net" IN NAPTR 10 10 "a" "http+N2R" "" "http://jenny.ispa.net" IN NAPTR 10 10 "a" "tel+N2R" "" "tel:+1-792-867-5309" A user, John Smith, wants to contact Jenny Jones, and has to start with only the E.164 number of Jenny, i.e. +:+1-792-867-5309. He takes the number, and enters the number in his communication client, which happen to know how to handle the SIP protocol. The client removes the dashes, and ends up with the E.164 number +17928675309. That is what is used in the algorithm for NAPTR records, which is as follows. The client converts the E.164 number into the domainname 9.0.3.5.7.6.8.2.9.7.1.e164.int., and queries for NAPTR records for this domainname. Using DNS mechanisms which includes following the NS record referals, the following records are returned: $ORIGIN 9.0.3.5.7.6.8.2.9.7.1.e164.int. IN NAPTR 10 10 "a" "sip+N2R" "" "sip:jenny@sipservice.com" IN NAPTR 10 10 "a" "smtp+N2R" "" "mailto:jenny@ispa.net" IN NAPTR 10 10 "a" "http+N2R" "" "http://jenny.ispa.net" IN NAPTR 10 10 "a" "tel+N2R" "" "tel:+1-792-867-5309" Because this client knows sip, the first record above is selected, and the SIP URI is extracted, and used according to SIP specifications. Penn Pfautz AT&T E4-3A01 200 S. Laurel Ave Middletown, NJ 07748 732-420-4962 ppfautz@att.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 16:00:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02989 for ; Wed, 28 Jun 2000 16:00:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26516; Wed, 28 Jun 2000 16:00:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26473 for ; Wed, 28 Jun 2000 15:59:59 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02974 for ; Wed, 28 Jun 2000 15:59:59 -0400 (EDT) Received: from [10.0.1.3] (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id VAA23256; Wed, 28 Jun 2000 21:59:15 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 28 Jun 2000 21:44:43 +0200 To: "Robert H. Walter" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] NAPTR is not as an ENUM Requirement Cc: 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 14.08 -0400 00-06-28, Robert H. Walter wrote: > >Why are they not well suited? > >NAPTR is not well suited to map domain names to URI's because >it envolves non-trivial regular expression processing by the >client application and/or resolver. Ok, then we have different opinion whether regular expressions are ok or not. I felt that (a) In any application which reads any other RR from DNS than type A have to do quite some stuff to get the data anyway (b) In any application which tries to deal with abstraction of services will be complicated anyway, so a regexp implementation will be a tiny fraction of the code you need (c) Libraries exists on the net which implements regular expressions >If the Basic NAPTR Algorithm >is followed, the regex field must be matched and processed to >obtain the resulting URI. The replacement field can not be used >because it MUST be a domain name. I know, this is one bug in the draft. >Don't misunderstand me, all of >this can be can be implemented... IMHO it's simply over-kill and >not well suited to the objective of SIMPLY mapping a domain name >to a URI. Ok. I don't think the whole algorithm will be simple, but now I understand where we don't agree. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 16:00:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03017 for ; Wed, 28 Jun 2000 16:00:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26675; Wed, 28 Jun 2000 16:00:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26644 for ; Wed, 28 Jun 2000 16:00:19 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02990 for ; Wed, 28 Jun 2000 16:00:19 -0400 (EDT) Received: from [10.0.1.3] (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id VAA23263; Wed, 28 Jun 2000 21:59:28 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: In-Reply-To: <2E3FA0558747934A8F753CC533A3F6DF01FF57C1@red-msg-24.redmond.corp.microsof t.com> References: <2E3FA0558747934A8F753CC533A3F6DF01FF57C1@red-msg-24.redmond.corp.microsof t.com> Date: Wed, 28 Jun 2000 21:48:33 +0200 To: Christian Huitema From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] NAPTR is not as an ENUM Requirement Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 12.03 -0700 00-06-28, Christian Huitema wrote: >CNAME or DNAME look like the >solution of choice for terminals; Neither of these are terminals, or do I misunderstand the use of the term? > in fact, DNAME are preferable, since we >will most probably want at some point to use SRV records I thought what was needed was: (1) Output be a URI (2) The ability to do redirections and rewrites, like in $ORIGIN 6.4.se. * IN NAPTR 100 10 "u" "sip+N2R" "!^+46(.*)$!ldap://ldap.pts.se/cn=$1,c=SE!" . ...or something like that... How are you going to use the SRV? paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 16:14:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03402 for ; Wed, 28 Jun 2000 16:14:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26953; Wed, 28 Jun 2000 16:14:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26922 for ; Wed, 28 Jun 2000 16:14:05 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03390 for ; Wed, 28 Jun 2000 16:14:05 -0400 (EDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 28 Jun 2000 13:13:24 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Wed, 28 Jun 2000 13:13:13 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF01FF57C4@red-msg-24.redmond.corp.microsoft.com> From: Christian Huitema To: "'Patrik Fältström'" Cc: enum@ietf.org Subject: RE: [Enum] NAPTR is not as an ENUM Requirement Date: Wed, 28 Jun 2000 13:13:12 -0700 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 > How are you going to use the SRV? Classic VOIP example. I want to contact +1 234 567 8901. I will look for the corresponding SIP/SRV record under _sip.udp.1.0.9.8.7.6.5.4.3.2.1.ipv6.int _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 16:17:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03480 for ; Wed, 28 Jun 2000 16:17:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27076; Wed, 28 Jun 2000 16:16:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27010 for ; Wed, 28 Jun 2000 16:16:52 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03477 for ; Wed, 28 Jun 2000 16:16:52 -0400 (EDT) Received: from [10.0.1.3] (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id WAA23651; Wed, 28 Jun 2000 22:16:04 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: In-Reply-To: <31AF4D00A662D211B6D10000F8BCBC24018D2760@bcarua63.ca.nortel.com> References: <31AF4D00A662D211B6D10000F8BCBC24018D2760@bcarua63.ca.nortel.com> Date: Wed, 28 Jun 2000 22:13:21 +0200 To: "Anne Brown" , ENUM List Group From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] Declaring an "Implementation" 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 13.38 -0500 00-06-28, Anne Brown wrote: >You stated: >" With the word standard in the IETF we mean _one_ agreed way of >solving a specific problem. Not alternative ways. If you have more >than one alternative, then you don't have interperability." > >I would be careful with your use of "IETF" definitions. At the >onset of the WG there were several people who wanted a standard >protocol for the ENUM service after investigating the alternatives. >And yet the IETF/IESG saw fit to mandate a DNS-only solution, >stating that other WGs could be formed to work on other solutions to >the same problem. This was done even before the requirements >document was started. One of the biggest problems with this is >interoperability, in the event that another WG develops another >solution. Ok. Understood. >You also stated: >"We can not have alternatives for that piece of the puzzle." > >But you have not disagreed with the statement that NAPTR RRs are not >a requirement for the deployment of the ENUM service. It depends on what you mean by ENUM service. _I_ define ENUM service to take one E.164 and get a set of URIs, and I think that should be done by NAPTR RRs, and nothing else. One of these URIs can be an LDAP URI, which in turn can give back (through use of LDAP) other URIs which can be selected based on the data in the LDAP database. >Yet if you define NAPTR RRS for use with ENUM and then turn around >and state that we must have only one according to the "IETF", then >you are in contradiction. What I am trying to say is that the domainname that you get by mapping the E.164 according to what is in the paper that I drafted can be used for other purposes, like all domainnames. >I have asked you to put a statement into your draft indicating that >NAPTR RRs are not a requirement and that there may be others. Requirement for what? That is what I don't understand. I might be tired, slow, or whatever... >However you will not agree to do that unless I give you " text which >describes one algorithm which can be used to go from an E.164 number >to a URL", which I told you beforehand I did not have. I see three things here: (1) Mapping from E.164 into a domainname (2) Using domainname given in (1) and get back URI(s) (3) Do other things than asking for URI(s) with domainnames defined by (1) I try to follow the charter of the wg to do (1) and (2). I claim that other people can do (3) if they want, but if one want a set of URI(s) given a E.164, NAPTR RRs are what they should use. >Of course you also know from discussions on the listserv that there >is not a consensus on NAPTR as the RR of choice. The only alternatives I have seen include: (1) TXT RRs -- immediately turned down by the DNS wg co-chair (2) Defining a new RR -- which will take years to deploy 1 is just out, and 2 is out as a conclusion because we do have NAPTR support in for example bind, but not the new RR type -- AND (as I explain in a different email) I don't agree that regexp handling is hard, compared with for example the code you have to write to talk with the resolver to get back a TXT RR or something new. Getting back responses from SRV is harder than getting back the regexp from a NAPTR because of the compression used in the SRV for example. > My particular objection to use of NAPTR is its requirement to >specify service-specifics (e.g., services available and email >addresses, etc.) at such a high level, when it understood that DNS >is often not appropriate for maintaining information on a per >resource basis (see draft-ietf-urn-dns-rds-01) and such information >is not scaleable and manageable on a global or even a national level. The draft you point at talks about the URN resolution process which is a very specific one, and I don't want to go into extrapolating that discussion into what we deal with here. And, as one of the people which came up with the current design of URNs, it is NOT because I am trying to run away. >Is it your intention to mandate NAPTR as "the" ENUM RR to be used, >and not allow others? My personal, yes, when I define the algorithm we talk about in the ENUM group is to get back URI(s). I hear that you want to do other things than get URI(s) back, and that is for me not an ENUM thing. >I hope and suspect not and would therefore like to see text in your >draft stating that there are other possible RRs that can be used. >This request does not require for those examples to be stated. IF one can use more than one type of RR to get back URI(s) given a E.164, how should the one querying DNS know what RR to query for? I claim that we need one and only one algorithm to use to find URI(s) when having a E.164, but IF we want to get back other things than URI(s) then we can reuse the domainname definition part of the draft and do whatever someone come up with. And, I still don't, as a sidenote, understand what you can NOT do with a URI which is easier to do with an SRV? But, as that is (from my point of view) not part of ENUM, I really don't care. People should be able to come up with whatever they want. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 16:41:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03936 for ; Wed, 28 Jun 2000 16:41:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27500; Wed, 28 Jun 2000 16:40:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27468 for ; Wed, 28 Jun 2000 16:40:04 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03916 for ; Wed, 28 Jun 2000 16:40:04 -0400 (EDT) Received: from [10.0.1.3] (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id WAA24180; Wed, 28 Jun 2000 22:39:21 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: In-Reply-To: <012F722EA7AFD211860B00E0290C6C5B0484C803@njc240po04.mt.att.com> References: <012F722EA7AFD211860B00E0290C6C5B0484C803@njc240po04.mt.att.com> Date: Wed, 28 Jun 2000 22:28:55 +0200 To: "Pfautz, Penn L, NNAD" , Richard Shockey , ENUM List Group From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] FW: Last Call or New Draft? - Portability 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 14.29 -0400 00-06-28, Pfautz, Penn L, NNAD wrote: >Some of Patrik's discussion has helped me better understand the issues but >also convinced me that, at least in the NANP area, there will need to be a >very large database at the 1.e164.int level that provides pointers to the >DNS service of the end user's choice for each individual number (or number >block for corporate ownership). That is correct. Or rather, the total number of records in the central cluster of mappings under 1.e164.arpa in the same administrative domain (not the same as the same DNS domain) will be large. It can though due to the way DNS works be split into a large number of physical databases. So, I don't see this as any showstopper, because the mapping have to be somewhere...and the amount of data will not decrease whether we have it in one administrative domain or many. It is rather the case that when talking about number portability, you have a classic problem of handling a distributed database where the administration can not be delegated (without quite complicated redirections to "parent" nodes in the tree, to enter a different administrative domain). paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 16:41:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03951 for ; Wed, 28 Jun 2000 16:41:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27546; Wed, 28 Jun 2000 16:40:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27515 for ; Wed, 28 Jun 2000 16:40:39 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03921 for ; Wed, 28 Jun 2000 16:40:39 -0400 (EDT) Received: from [10.0.1.3] (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id WAA24197; Wed, 28 Jun 2000 22:39:50 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: In-Reply-To: <2E3FA0558747934A8F753CC533A3F6DF01FF57C4@red-msg-24.redmond.corp.microsof t.com> References: <2E3FA0558747934A8F753CC533A3F6DF01FF57C4@red-msg-24.redmond.corp.microsof t.com> Date: Wed, 28 Jun 2000 22:37:19 +0200 To: Christian Huitema From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] NAPTR is not as an ENUM Requirement Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 13.13 -0700 00-06-28, Christian Huitema wrote: > > How are you going to use the SRV? > >Classic VOIP example. I want to contact +1 234 567 8901. I will look for the >corresponding SIP/SRV record under _sip.udp.1.0.9.8.7.6.5.4.3.2.1.ipv6.int But, the SRV for sip is to be looked up for the domain part of the sip URI, i.e. you seem to use 1.0.9.8.7.6.5.4.3.2.1.ipv6.int as if it was the domain part of the URI, to find the SIP server which handles that number. What is the local part? Or have I misunderstood something with SIP completely? From RFC 2543: > For example, consider a client that wishes to send a SIP request. The > Request-URI for the destination is sip:user@company.com. The client > only supports UDP. It would follow these steps: > > 1. The host portion is not an IP address, so the client goes > to step 2 above. > > 2. The client does a DNS query of QNAME="sip.udp.company.com", > QCLASS=IN, QTYPE=SRV. Since it doesn't support TCP, it > omits the TCP query. There were no addresses in the DNS > response, so the client goes to the next step. > > 3. The client does a DNS query for A records for > "company.com". An address is found, so that client attempts > to contact a server at that address at port 5060. What I thought what one should do is: (a) Take the E.164, and turn that into a domain name (b) Look up the NAPTR for the domain name (following CNAME, DNAME, NAPTR non-terminals etc etc) (c) Take the SIP URI from the according NAPTR (d) Use the algorithm above to fetch the SRV for the SIP URI Or: (a) Take the E.164, and turn that into a domain name (b) Look up the NAPTR for the domain name (following CNAME, DNAME, NAPTR non-terminals etc etc) (c) Take the LDAP URI from the according NAPTR (d) Lookup in LDAP what SIP URI to use at this very moment (according to some other future specification) (e) Take the SIP URI from the according NAPTR (f) Use the algorithm above to fetch the SRV for the SIP URI I.e. steps (a) and (b) are very generic and can/should be done all the time. I claim that -- as you understand... paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 16:47:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04001 for ; Wed, 28 Jun 2000 16:47:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27713; Wed, 28 Jun 2000 16:46:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27682 for ; Wed, 28 Jun 2000 16:46:56 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03997 for ; Wed, 28 Jun 2000 16:46:56 -0400 (EDT) Received: from [10.0.1.3] (nix.swip.net [192.71.220.2]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id WAA24323; Wed, 28 Jun 2000 22:46:08 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: In-Reply-To: <6B57F36F4FF9D111B30A0008C7F413370370508B@exdal1.ons.octel.com> References: <6B57F36F4FF9D111B30A0008C7F413370370508B@exdal1.ons.octel.com> Date: Wed, 28 Jun 2000 22:44:33 +0200 To: "Vaudreuil, Greg M (Greg)" , Anne Brown , "'ENUM'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: FW: [Enum] NAPTR is not as an ENUM Requirement Cc: Scott Bradner 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.19 -0500 00-06-28, Vaudreuil, Greg M (Greg) wrote: > 2.8.0.4.6.2.6.5.8.6.4.e164.int. > IN NAPTR 102 10 "a" "smtp+N2R" "" >"mailto:+46856264082@fax.swip.net". > IN NAPTR 102 10 "a" "smtp+N2R" "" >"mailto:+46856264082@SMS.swip.net". > IN NAPTR 102 10 "a" "smtp+N2R" "" >"mailto:+46856264082@VPIM.swip.net". > >If we need to register a new service type for each messaging service, then >we have not gained much by the use of NAPTR over a similar record MX record >with a service-specific domain-name construction rule. Except more records, >more protocol, and a need to upgrade my operating system. Actually, when thinking about it, IF you want to do that, I belive you can define new flags instead of "SMTP+N2R", i.e. a new string instead of "SMTP", but the best must be to define a new URI scheme, like IPP has done for printing. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jun 28 17:48:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05032 for ; Wed, 28 Jun 2000 17:48:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28911; Wed, 28 Jun 2000 17:48:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28880 for ; Wed, 28 Jun 2000 17:48:08 -0400 (EDT) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05028 for ; Wed, 28 Jun 2000 17:47:45 -0400 (EDT) Received: from computer.ix.netcom.com ([209.138.176.187]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA12363; Wed, 28 Jun 2000 17:47:25 -0400 (EDT) Message-Id: <4.3.1.2.20000628161121.00de42d0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 28 Jun 2000 16:48:23 -0500 To: "Pfautz, Penn L, NNAD" , ENUM List Group From: Richard Shockey Subject: RE: [Enum] FW: Last Call or New Draft? - Portability In-Reply-To: <012F722EA7AFD211860B00E0290C6C5B0484C803@njc240po04.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 02:29 PM 6/28/2000 -0400, Pfautz, Penn L, NNAD wrote: >Richard: >Although it sounds like there will be an attempt at some resolution of the >issues raised with respect to record type, I'm not sure what's happening re >number portability impacts. >Some of Patrik's discussion has helped me better understand the issues but >also convinced me that, at least in the NANP area, there will need to be a >very large database at the 1.e164.int level that provides pointers to the >DNS service of the end user's choice for each individual number (or number >block for corporate ownership). Right the subscribers choice ..the ultimate rule in ENUM administration ..if and when that is discussed somewhere....but please not on this list. >I've done a crude cut and paste on the >example in Patrik's Appendix to illustrate how this might be expected to >work. Think 1.e164.arpa. >Appendix A. Example 2 > The ITU has delegated the country code 1, and the zone 1.e164.arpa to > the North American Numbering Plan. The regulators of the NANP countries > have delegated the responsibility for this zone to the contracted > NANP Administrator. NANPA Because of that, the content > of the e164.int zone is: > > $ORIGIN e164.arpa. > 1 IN NS nanpa-e164.com Yep. > > Although the NANPA assigns blocks of 10,000 or 1,000 numbers to various > Service providers for assignment to end users, numbers are portable so >the NANPA > DNS provides a zone for each telephone number or block of numbers >assigned > A single user. Well there is some thinking in these circles that in general the resolution at the first level delegation goes all the way to the last digit and only those numbers that are assigned to enterprises can be properly delegated at a NXX level. The current regulatory assignment environment is at the 1000 block level but with pooling and the anticipation of much more aggressive number conservation even this is only a temporary solution. You can anticipate the FCC and the CRTC will do nearly anything to avoid NANP exhaustion. This 1st level delegation can be broken up into numerous servers to load balance etc. And with NP the way it currently works, all digit look up is what is happening today in the IN >Thus the NANPA DNS has a record directing queries for a >specific > number to the DNS of the current service provider. The user can then >either have that > provider be the source of authoritative information or request the >telephony provider's > DNS refer to that of some other DNS service provider. Well yes you are just about on the mark ..but you should remember the essential principal of number portability administration which is "non reliance on donor networks". There is a very legitimate worry by some service providers on having to rely on incumbent "carriers of record" to provision ENUM RR's. To put it bluntly ...why should Bell South assist provisioning SIP services from ATT, if Bell South is offering those services themselves. [ This assumes 271 permission is eventually granted Bell South ]. The last thing we need as system that invites Internet Telephony slamming. See below. > A user named Jenny Jones has from Telco A got the phone number > +1 792-867-5309. The user gets the service of running DNS from the > company Redirection Service. Jenny Jones has asked Telco A to > point out Redirection Service as the authoritative source for > information about the number +1 792-867-5309. Telco A because of >this > puts in its DNS the following. Well not exactly ..... Jenny Jones might tell Teleco A to point to "Redirection Service" as the NS for this number and this could be redirected directly from NANPA to "Redirection Service", or their friendly neighborhood global SIP service provider ( read ATT could do this for them ) their is no need for Telco A to maintain any RR except for those customers that have specifically asked for them to do so. Of course ..we are now getting into the real NO NO of discussing ENUM administration and policy issues on this list and as co-chair I'd like to chastise myself for going this far. > > $ORIGIN 1.e164.int. > 9.0.3.5.7.6.8.2.9.7 IN NS ns.redirection-service.com > > Jenny already has plain telephony from Telco A, but also a > SIP service from the company Sip Service which provides Jenny with > the SIP URI "sip:jenny@sipservice.com.". The ISP with the name > ISP A runs email and webpages for Jenny, under the emailaddress > jenny@ispa.net, and URL http://jenny.ispa.net > The DNS for the redirection service because of this contains the > following. > $ORIGIN 9.0.3.5.7.6.8.2.9.7.1.e164.arpa. > IN NAPTR 10 10 "a" "sip+N2R" "" "sip:jenny@sipservice.com" > IN NAPTR 10 10 "a" "smtp+N2R" "" "mailto:jenny@ispa.net" > IN NAPTR 10 10 "a" "http+N2R" "" "http://jenny.ispa.net" > IN NAPTR 10 10 "a" "tel+N2R" "" "tel:+1-792-867-5309" > A user, John Smith, wants to contact Jenny Jones, and has to start with > only the E.164 number of Jenny, i.e. +:+1-792-867-5309. He takes the > number, and enters the number in his communication client, which > happen to know how to handle the SIP protocol. The client removes > the dashes, and ends up with the E.164 number +17928675309. That is > what is used in the algorithm for NAPTR records, which is as follows. > The client converts the E.164 number into the domainname > 9.0.3.5.7.6.8.2.9.7.1.e164.arpa., and queries for NAPTR records for > this domainname. Using DNS mechanisms which includes following the > NS record referals, the following records are returned: Looking good .... I've changed .int to .arpa > $ORIGIN 9.0.3.5.7.6.8.2.9.7.1.e164.arpa. > IN NAPTR 10 10 "a" "sip+N2R" "" "sip:jenny@sipservice.com" > IN NAPTR 10 10 "a" "smtp+N2R" "" "mailto:jenny@ispa.net" > IN NAPTR 10 10 "a" "http+N2R" "" "http://jenny.ispa.net" > IN NAPTR 10 10 "a" "tel+N2R" "" "tel:+1-792-867-5309" > > Because this client knows sip, the first record above is selected, > and the SIP URI is extracted, and used according to SIP specifications. Ta Da!.. ...if you use NAPTR records. Now we should see how our SIP colleagues think about this scenerio. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please Note New Contact Information: Richard Shockey Shockey Consulting LLC 5237 Sutherland St. Louis, MO 63109 Voice 314.503.0640 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Jun 29 02:15:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23112 for ; Thu, 29 Jun 2000 02:15:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08666; Thu, 29 Jun 2000 02:14:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08635 for ; Thu, 29 Jun 2000 02:14:46 -0400 (EDT) Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23109 for ; Thu, 29 Jun 2000 02:14:47 -0400 (EDT) Received: from dynamicsoft.com (1Cust141.tnt1.freehold.nj.da.uu.net [63.17.113.141]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA21633; Thu, 29 Jun 2000 02:16:04 -0400 (EDT) Message-ID: <395ABA5E.4B4050F7@dynamicsoft.com> Date: Wed, 28 Jun 2000 22:54:22 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Richard Shockey CC: "Pfautz, Penn L, NNAD" , ENUM List Group Subject: Re: [Enum] FW: Last Call or New Draft? - Portability References: <4.3.1.2.20000628161121.00de42d0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Richard Shockey wrote: > > Looking good .... I've changed .int to .arpa > > > $ORIGIN 9.0.3.5.7.6.8.2.9.7.1.e164.arpa. > > IN NAPTR 10 10 "a" "sip+N2R" "" "sip:jenny@sipservice.com" > > IN NAPTR 10 10 "a" "smtp+N2R" "" "mailto:jenny@ispa.net" > > IN NAPTR 10 10 "a" "http+N2R" "" "http://jenny.ispa.net" > > IN NAPTR 10 10 "a" "tel+N2R" "" "tel:+1-792-867-5309" > > > > Because this client knows sip, the first record above is selected, > > and the SIP URI is extracted, and used according to SIP specifications. > > Ta Da!.. ...if you use NAPTR records. Now we should see how our SIP > colleagues think about this scenerio. Seems fine to me... the next step would be an SRV lookup of _sip._udp.sipservice.com and _sip._tcp.sipservice.com to locate the server for this domain. -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: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Jun 29 02:17:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23139 for ; Thu, 29 Jun 2000 02:17:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08739; Thu, 29 Jun 2000 02:17:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08710 for ; Thu, 29 Jun 2000 02:17:00 -0400 (EDT) Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23134 for ; Thu, 29 Jun 2000 02:17:01 -0400 (EDT) Received: from dynamicsoft.com (1Cust141.tnt1.freehold.nj.da.uu.net [63.17.113.141]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA21641; Thu, 29 Jun 2000 02:16:17 -0400 (EDT) Message-ID: <395ABCBA.EA4E2F96@dynamicsoft.com> Date: Wed, 28 Jun 2000 23:04:26 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: Christian Huitema , enum@ietf.org Subject: Re: [Enum] NAPTR is not as an ENUM Requirement References: <2E3FA0558747934A8F753CC533A3F6DF01FF57C4@red-msg-24.redmond.corp.microsof t.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Patrik Fältström wrote: > > At 13.13 -0700 00-06-28, Christian Huitema wrote: > > > How are you going to use the SRV? > > > >Classic VOIP example. I want to contact +1 234 567 8901. I will look for the > >corresponding SIP/SRV record under _sip.udp.1.0.9.8.7.6.5.4.3.2.1.ipv6.int > > But, the SRV for sip is to be looked up for the domain part of the > sip URI, i.e. you seem to use 1.0.9.8.7.6.5.4.3.2.1.ipv6.int as if it > was the domain part of the URI, to find the SIP server which handles > that number. > > What is the local part? > > Or have I misunderstood something with SIP completely? No, you are correct; I would expect a two stage process whereby the telephone number is first resolved to a SIP URL, and then the domain part of the SIP URL is looked up to find the SRV record for that domain. -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: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Jun 29 03:42:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24026 for ; Thu, 29 Jun 2000 03:42:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10059; Thu, 29 Jun 2000 03:41:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10028 for ; Thu, 29 Jun 2000 03:41:43 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24019 for ; Thu, 29 Jun 2000 03:41:42 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nok.ntc.nokia.com [131.228.10.151]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id KAA10939 for ; Thu, 29 Jun 2000 10:41:42 +0300 (EETDST) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 29 Jun 2000 10:41:38 +0300 Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id ; Thu, 29 Jun 2000 10:41:38 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DEC48@eseis04nok> To: paf@swip.net, rshockey@ix.netcom.com, randy@psg.com Cc: rwalter@netnumber.com, enum@ietf.org Date: Thu, 29 Jun 2000 10:31:09 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] Using NAPTR vs. SRV 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, > >However if SRV records are used ...the resolver can request _only_ > >those records associated with a service, correct? > > See above. > > On the other hand, you don't know beforehand what services to ask for > when you only have the E.164, so you might have to query for a number > of SRVs. I'm currently writing a draft that will support cellular roaming. What I want to do is basically query an e.164 number and a service (let's call it ROAM) and return a URI for the location of the entity that is providing some sort of authentication for that user. The authentication agent might be an IP HLR, IP VLR, or AAA server. The protocols used will probably be SIGTRAN/SCTP or DIAMETER/SCTP (though there are other possibilities). My first assumption is to use SRV RRs for this - but I'm not at all an expert in DNS, so any advice would be appreciated. best regards, John _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Jun 29 03:58:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24105 for ; Thu, 29 Jun 2000 03:58:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10281; Thu, 29 Jun 2000 03:58:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10250 for ; Thu, 29 Jun 2000 03:58:39 -0400 (EDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24102 for ; Thu, 29 Jun 2000 03:58:38 -0400 (EDT) Received: from [10.0.1.3] (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id JAA05402; Thu, 29 Jun 2000 09:57:55 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@nix.swip.net Message-Id: In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE1031DEC48@eseis04nok> References: <01D91AFB08B6D211BFD00008C7EABAE1031DEC48@eseis04nok> Date: Thu, 29 Jun 2000 09:56:13 +0200 To: john.loughney@nokia.com, rshockey@ix.netcom.com, randy@psg.com From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: rwalter@netnumber.com, enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: Using NAPTR vs. SRV 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.31 +0300 00-06-29, john.loughney@nokia.com wrote: >I'm currently writing a draft that will support cellular roaming. >What I want to do is basically query an e.164 number and a service >(let's call it ROAM) and return a URI for the location of the >entity that is providing some sort of authentication for that >user. As you might have seen in the discussions, you can not get back anything else than a domainname with an SRV. You need other mechanisms for that, and I have proposed using NAPTR RRs for fetching URIs. Other methods can be using LDAP, given that you can go from E.164 to an LDAP query, and I propose that is done (aswell) using NAPTR RRs but then using an LDAP URI instead of what you get back in the previous example. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Jun 29 10:49:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09525 for ; Thu, 29 Jun 2000 10:49:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14325; Thu, 29 Jun 2000 10:46:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14292 for ; Thu, 29 Jun 2000 10:46:21 -0400 (EDT) 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 ESMTP id KAA09461 for ; Thu, 29 Jun 2000 10:46:21 -0400 (EDT) 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 <20000629144551.GJCI24415.hvmta03-stg@rwalter>; Thu, 29 Jun 2000 10:45:51 -0400 Reply-To: From: "Robert H. Walter" To: "Pfautz, Penn L, NNAD" , "Richard Shockey" , Cc: "ENUM List Group" Subject: RE: [Enum] FW: Last Call or New Draft? - Portability Date: Thu, 29 Jun 2000 10:46:40 -0400 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <395ABA5E.4B4050F7@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Richard Shockey wrote: > > Looking good .... I've changed .int to .arpa > > > $ORIGIN 9.0.3.5.7.6.8.2.9.7.1.e164.arpa. > > IN NAPTR 10 10 "a" "sip+N2R" "" "sip:jenny@sipservice.com" > > IN NAPTR 10 10 "a" "smtp+N2R" "" "mailto:jenny@ispa.net" > > IN NAPTR 10 10 "a" "http+N2R" "" "http://jenny.ispa.net" > > IN NAPTR 10 10 "a" "tel+N2R" "" "tel:+1-792-867-5309" > > > > Because this client knows sip, the first record above is selected, > > and the SIP URI is extracted, and used according to SIP specifications. > > Ta Da!.. ...if you use NAPTR records. Now we should see how our SIP > colleagues think about this scenerio. Conceptually the works!, however the example NAPTR RRs are not accurately defined. The replacement field MUST be a domain name and the above examples use URI's. Mike Mealling wrote in a prevous post on Wed 6/28/00 10:01 AM: > The Application gets to define the Appliction Unique String > which is the thing the algoirthm works on to find out specific > syntactic rules for delegation. > ... > In the case of an ENUM application the Unique String would be > the e.164 phone number and the output would be URIs that > identify services. Mike would you mind shedding light on what the NAPTR RR's would look like given the unique string of 17928675309? Your assistance is greatly appreciated. Bob _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Jun 29 11:22:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10524 for ; Thu, 29 Jun 2000 11:22:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14825; Thu, 29 Jun 2000 11:21:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14794 for ; Thu, 29 Jun 2000 11:21:24 -0400 (EDT) Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10502 for ; Thu, 29 Jun 2000 11:21:22 -0400 (EDT) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg15e1.nortelnetworks.com; Thu, 29 Jun 2000 11:15:05 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Jun 2000 11:15:04 -0400 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24018D2763@bcarua63.ca.nortel.com> From: "Anne Brown" To: "'ENUM'" Subject: RE: [Enum] Declaring an "Implementation" Date: Thu, 29 Jun 2000 11:14:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE1DC.CCEF816A" 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_01BFE1DC.CCEF816A Content-Type: text/plain; charset="iso-8859-1" >> My particular objection to use of NAPTR is its requirement to >>specify service-specifics (e.g., services available and email >>addresses, etc.) at such a high level, when it understood that DNS >>is often not appropriate for maintaining information on a per >>resource basis (see draft-ietf-urn-dns-rds-01) and such information >>is not scaleable and manageable on a global or even a national level. >The draft you point at talks about the URN resolution process which >is a very specific one, and I don't want to go into extrapolating >that discussion into what we deal with here. And, as one of the >people which came up with the current design of URNs, it is NOT >because I am trying to run away. Do you think that storing service-specific and resource-based information (e.g., service-specific addresses for each individual telephone number) at a global or national level will be scalable and manageable? >>Is it your intention to mandate NAPTR as "the" ENUM RR to be used, >>and not allow others? >My personal, yes, when I define the algorithm we talk about in the >ENUM group is to get back URI(s). OK, I agree with this. However, as noted above I have reservations about how it should be used. Anne Brown Nortel Networks arbrown@nortelnetworks.com +1 613 765 5274 ------_=_NextPart_001_01BFE1DC.CCEF816A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Enum] Declaring an "Implementation"

>>   My particular objection to use = of NAPTR is its requirement to
>>specify service-specifics (e.g., services = available and email
>>addresses, etc.) at such a high level, when = it understood that DNS
>>is often not appropriate for maintaining = information on a per
>>resource basis (see = draft-ietf-urn-dns-rds-01) and such information
>>is not scaleable and manageable on a global = or even a national level.

>The draft you point at talks about the URN = resolution process which
>is a very specific one, and I don't want to go = into extrapolating
>that discussion into what we deal with here. = And, as one of the
>people which came up with the current design of = URNs, it is NOT
>because I am trying to run away.

Do you think that storing service-specific and = resource-based information (e.g., service-specific addresses for each = individual telephone number) at a global or national level will be = scalable and manageable?

>>Is it your intention to mandate NAPTR as = "the" ENUM RR to be used,
>>and not allow others?

>My personal, yes, when I define the algorithm we = talk about in the
>ENUM group is to get back URI(s).

OK, I agree with this.  However, as noted above = I have reservations about how it should be used.

Anne Brown
Nortel Networks
arbrown@nortelnetworks.com
+1 613 765 5274

------_=_NextPart_001_01BFE1DC.CCEF816A-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum