From exim@www1.ietf.org Tue Mar 2 00:57:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04403 for ; Tue, 2 Mar 2004 00:57:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2uG-0002j9-EH for enum-archive@odin.ietf.org; Tue, 02 Mar 2004 00:57:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i225vRvm010425 for enum-archive@odin.ietf.org; Tue, 2 Mar 2004 00:57:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2u0-0002fS-Ku; Tue, 02 Mar 2004 00:57:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2t5-0002cT-Gb for enum@optimus.ietf.org; Tue, 02 Mar 2004 00:56:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04294 for ; Tue, 2 Mar 2004 00:56:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2t2-0001Vf-00 for enum@ietf.org; Tue, 02 Mar 2004 00:56:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2s8-0001QJ-00 for enum@ietf.org; Tue, 02 Mar 2004 00:55:16 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2rc-0001JG-00 for enum@ietf.org; Tue, 02 Mar 2004 00:54:45 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (ibm-eyjgx9r6nqt.cis.neustar.com [218.37.213.62] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i22634d18988 for ; Mon, 1 Mar 2004 22:03:04 -0800 Message-Id: <6.0.3.0.2.20040302005036.0436eb10@popd.ix.netcom.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 02 Mar 2004 00:53:55 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=BIZ_TLD autolearn=no version=2.60 Subject: [Enum] Additional Agenda item for Tomorrow.. Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , There has been some discussion among the AD's and the WG chairs of the FAX WG and Patrick myself whether there has been sufficient cross review of the attached document. I have privately informed the AD" that this document was well known to the ENUM WG and that we certainly approved of its advancement. If there is a problem ..speak now or tomorrow at 9 AM. ######### IFAX service of ENUM Status: Proposed Standard Summary: This document describes the functional specification and the definition of the ENUM NAPTR record, for IFax service. IFax is "Facsimile using Internet Mail". For this use, the DNS returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers, rather than requiring that the sender already know the recipient email address. Working Group Last Call Result: At San Francisco's meeting our WG agreed to the content. The I-D was submitted for IETF-FAX WG Last Call on April 11. During WG LC period, there were no comments. It sucessfully finished on April 30. ............... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 2 11:41:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18492 for ; Tue, 2 Mar 2004 11:41:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCxC-0004wx-Mv for enum-archive@odin.ietf.org; Tue, 02 Mar 2004 11:41:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22GfA1l018976 for enum-archive@odin.ietf.org; Tue, 2 Mar 2004 11:41:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCx4-0004vc-3k; Tue, 02 Mar 2004 11:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCwf-0004uD-GX for enum@optimus.ietf.org; Tue, 02 Mar 2004 11:40:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18444 for ; Tue, 2 Mar 2004 11:40:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyCwe-0000Zz-00 for enum@ietf.org; Tue, 02 Mar 2004 11:40:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyCvk-0000SL-00 for enum@ietf.org; Tue, 02 Mar 2004 11:39:40 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AyCuv-0000DW-00 for enum@ietf.org; Tue, 02 Mar 2004 11:38:49 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGML0TG>; Tue, 2 Mar 2004 16:38:09 -0000 Received: from [127.0.0.1] (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1ZGN1VPS; Tue, 2 Mar 2004 16:38:07 -0000 From: "Conroy, Lawrence (SMTP)" To: Richard Shockey Cc: enum@ietf.org In-Reply-To: <6.0.3.0.2.20040302005036.0436eb10@popd.ix.netcom.com> References: <6.0.3.0.2.20040302005036.0436eb10@popd.ix.netcom.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Enum] Additional Agenda item for Tomorrow Date: Tue, 2 Mar 2004 16:38:05 +0000 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,BIZ_TLD autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Folks, this looks fine to me - as it did when I first looked at it. I note in passing how long this has been hanging around dependent on the perpetually draft 2916bis (It refers to rfc2916bis-04, so we can guess :). One slight point for the Author's 48 - In the references section is mention of the "Full-mode Fax Profile for Internet Mail" draft which was probably current when this ifax enumservice draft was issued. Has this been updated/made into an RFC in the interim? It's a minor point, as there is no actual reference in the body text to this. Whilst we're on nits, the [KEYWORDS] reference isn't spelt out. atb, Lawrence On 2 Mar 2004, at 5:53 am, Richard Shockey wrote: > > There has been some discussion among the AD's and the WG chairs of the > FAX WG and Patrick myself whether there has been sufficient cross > review of the attached document. > > I have privately informed the AD" that this document was well known to > the ENUM WG and that we certainly approved of its advancement. > > If there is a problem ..speak now or tomorrow at 9 AM. > > ######### > > IFAX service of ENUM > > > Status: Proposed Standard > > Summary: > This document describes the functional specification > and the definition of the ENUM NAPTR record, for IFax > service. IFax is "Facsimile using Internet Mail". For > this use, the DNS returns the email address of the > referenced IFax system. This mechanism allows email-based > fax communication to use telephone numbers, rather than > requiring that the sender already know the recipient > email address. > > Working Group Last Call Result: > At San Francisco's meeting our WG agreed to the content. > The I-D was submitted for IETF-FAX WG Last Call on April 11. > During WG LC period, there were no comments. > It sucessfully finished on April 30. > > ............... > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 > 815.333.1237 > or > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 3 02:04:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12728 for ; Wed, 3 Mar 2004 02:04:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQQR-0007S7-Sq for enum-archive@odin.ietf.org; Wed, 03 Mar 2004 02:04:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2374FDK028576 for enum-archive@odin.ietf.org; Wed, 3 Mar 2004 02:04:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQQG-0007Nn-9q; Wed, 03 Mar 2004 02:04:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQPU-0006v8-EJ for enum@optimus.ietf.org; Wed, 03 Mar 2004 02:03:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10978 for ; Wed, 3 Mar 2004 02:03:14 -0500 (EST) From: fujiwara@jprs.co.jp Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQPQ-0004ZP-00 for enum@ietf.org; Wed, 03 Mar 2004 02:03:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQOY-0004Pu-00 for enum@ietf.org; Wed, 03 Mar 2004 02:02:18 -0500 Received: from sender2.nic.ad.jp ([61.120.151.69] helo=sender2.jprs.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1AyQNl-00047q-00 for enum@ietf.org; Wed, 03 Mar 2004 02:01:29 -0500 Received: from alias.jprs.co.jp (alias.jprs.co.jp [192.168.102.41]) by sender2.jprs.co.jp (8.11.6/8.11.6) with ESMTP id i236eNL04138 for ; Wed, 3 Mar 2004 15:40:23 +0900 Received: from unix01.jprs.co.jp (unix01.jprs.co.jp [192.168.118.11]) by alias.jprs.co.jp (8.11.7p1+Sun/8.11.7) with ESMTP id i236xx319334 for ; Wed, 3 Mar 2004 15:59:59 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by unix01.jprs.co.jp (8.11.6/8.11.6) with ESMTP id i236xx501760 for ; Wed, 3 Mar 2004 15:59:59 +0900 Date: Wed, 03 Mar 2004 15:59:59 +0900 (JST) Message-Id: <20040303.155959.54196172.fujiwara@jprs.co.jp> To: enum@ietf.org X-Mailer: Mew version 4.0.64 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Enum] ietf59 slides: ETJP and exeriences Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi folks, I'm Kazunori Fujiwara from JPRS. Today's my slides are on my web page: http://member.wide.ad.jp/~fujiwara/enum/ There are also my ENUM library ENUM.pm. (this code is under constuction) -- Fujiwara, Kazunori JPRS _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 3 02:33:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06804 for ; Wed, 3 Mar 2004 02:33:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQsT-0000Nu-2N for enum-archive@odin.ietf.org; Wed, 03 Mar 2004 02:33:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i237XD7g001418 for enum-archive@odin.ietf.org; Wed, 3 Mar 2004 02:33:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQsH-0000I7-GV; Wed, 03 Mar 2004 02:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQrv-0000CT-GG for enum@optimus.ietf.org; Wed, 03 Mar 2004 02:32:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06573 for ; Wed, 3 Mar 2004 02:32:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQrX-00026q-00 for enum@ietf.org; Wed, 03 Mar 2004 02:32:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQqh-0001vf-00 for enum@ietf.org; Wed, 03 Mar 2004 02:31:23 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AyQps-0001PS-00 for enum@ietf.org; Wed, 03 Mar 2004 02:30:32 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (ibm-eyjgx9r6nqt.cis.neustar.com [218.37.228.204] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i237cqd16676 for ; Tue, 2 Mar 2004 23:38:52 -0800 Message-Id: <6.0.3.0.2.20040303022718.03c99ec0@popd.ix.netcom.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 03 Mar 2004 02:29:47 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=BIZ_TLD autolearn=no version=2.60 Subject: [Enum] Since many of you asked about my screen saver... Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , its a commercial product available from http://www.despair.com >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 3 02:47:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07729 for ; Wed, 3 Mar 2004 02:47:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyR5x-0006m7-5Y for enum-archive@odin.ietf.org; Wed, 03 Mar 2004 02:47:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i237l85k025936 for enum-archive@odin.ietf.org; Wed, 3 Mar 2004 02:47:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyR5p-0006it-Jo; Wed, 03 Mar 2004 02:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyR5T-0006gP-LT for enum@optimus.ietf.org; Wed, 03 Mar 2004 02:46:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07676 for ; Wed, 3 Mar 2004 02:46:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyR55-00049o-00 for enum@ietf.org; Wed, 03 Mar 2004 02:46:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyR45-00042W-00 for enum@ietf.org; Wed, 03 Mar 2004 02:45:13 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AyR3Z-0003tw-00 for enum@ietf.org; Wed, 03 Mar 2004 02:44:42 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (ibm-eyjgx9r6nqt.cis.neustar.com [218.37.228.204] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i237r2d17401 for ; Tue, 2 Mar 2004 23:53:02 -0800 Message-Id: <6.0.3.0.2.20040303015454.03c99ec0@popd.ix.netcom.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 03 Mar 2004 02:27:16 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,BIZ_TLD autolearn=no version=2.60 Subject: [Enum] Presentations from IETF59 ENUM WG Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Given the strong interest in the presentations given today, I've taken the liberty of ZIPing them up making them available early to those of you who are interested. http://www.shockey.us/enum/IETF59_ENUMWG_presentations.zip >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 3 02:47:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07730 for ; Wed, 3 Mar 2004 02:47:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyR5x-0006m6-4i for enum-archive@odin.ietf.org; Wed, 03 Mar 2004 02:47:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i237l8iD025940 for enum-archive@odin.ietf.org; Wed, 3 Mar 2004 02:47:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyR5r-0006j4-5o; Wed, 03 Mar 2004 02:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyR5R-0006gN-4E for enum@optimus.ietf.org; Wed, 03 Mar 2004 02:46:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07670 for ; Wed, 3 Mar 2004 02:46:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyR53-00049W-00 for enum@ietf.org; Wed, 03 Mar 2004 02:46:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyR3z-00041o-00 for enum@ietf.org; Wed, 03 Mar 2004 02:45:08 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AyR3B-0003nB-00 for enum@ietf.org; Wed, 03 Mar 2004 02:44:17 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (ibm-eyjgx9r6nqt.cis.neustar.com [218.37.228.204] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i237qAd17327; Tue, 2 Mar 2004 23:52:10 -0800 Message-Id: <6.0.3.0.2.20040303023303.03f785c8@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 03 Mar 2004 02:43:07 -0500 To: fujiwara@jprs.co.jp, enum@ietf.org From: Richard Shockey Subject: Oh Larry - [Enum] ietf59 slides: ETJP and exeriences Cc: lwc@roke.co.uk In-Reply-To: <20040303.155959.54196172.fujiwara@jprs.co.jp> References: <20040303.155959.54196172.fujiwara@jprs.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=BIZ_TLD autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 01:59 AM 3/3/2004, you wrote: Larry .. it is the will and order :-) of the WG that you and Fujiwara-san collaborate on further iterations of the Implementations issues draft. It is now a official WG document and in the future should be submitted as such.. JPRS discovered several other problems that need to be addressed ... in the next rev what I would suggest is that you detail each problem and then discuss action items for authors, workarounds or proposed solutions to each problem identified and we can then discuss them on the list. For instance on the issue of ORDER vs PRECEDENCE ..state clearly that it is RECOMMEDED implementors should fix ORDER of all ENUM service fields to 100 and sort on precedence etc. repeat the format on the the issue of case insensitivity etc .. >Hi folks, > >I'm Kazunori Fujiwara from JPRS. > >Today's my slides are on my web page: > http://member.wide.ad.jp/~fujiwara/enum/ > >There are also my ENUM library ENUM.pm. >(this code is under constuction) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 3 02:59:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08464 for ; Wed, 3 Mar 2004 02:59:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRHW-0008T0-Op for enum-archive@odin.ietf.org; Wed, 03 Mar 2004 02:59:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i237x6Xb032518 for enum-archive@odin.ietf.org; Wed, 3 Mar 2004 02:59:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRHR-0008Ry-F8; Wed, 03 Mar 2004 02:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRGy-0008QP-ST for enum@optimus.ietf.org; Wed, 03 Mar 2004 02:58:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08408 for ; Wed, 3 Mar 2004 02:58:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRGa-00077J-00 for enum@ietf.org; Wed, 03 Mar 2004 02:58:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRFe-0006xy-00 for enum@ietf.org; Wed, 03 Mar 2004 02:57:11 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1AyREy-0005ps-00 for enum@ietf.org; Wed, 03 Mar 2004 02:56:28 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Mar 2004 00:02:40 +0000 Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i237tT1v006218; Wed, 3 Mar 2004 08:55:29 +0100 (MET) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 3 Mar 2004 08:54:50 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 3 Mar 2004 08:55:55 +0100 In-Reply-To: <6.0.3.0.2.20040303023303.03f785c8@joy.songbird.com> References: <20040303.155959.54196172.fujiwara@jprs.co.jp> <6.0.3.0.2.20040303023303.03f785c8@joy.songbird.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3130E39E-6CE8-11D8-A5F4-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit Cc: fujiwara@jprs.co.jp, lwc@roke.co.uk, enum@ietf.org From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Oh Larry - [Enum] ietf59 slides: ETJP and exeriences Date: Wed, 3 Mar 2004 16:55:52 +0900 To: Richard Shockey X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 03 Mar 2004 07:55:55.0988 (UTC) FILETIME=[F5407940:01C400F4] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,BIZ_TLD autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Michael and I have already sync:ed to start allocating time working on this document (and update/clarifications). We would like you to merge your document with the Japanese ENUM findings first though. Let us know when we can take over the "pen". paf On 2004-03-03, at 16.43, Richard Shockey wrote: > At 01:59 AM 3/3/2004, you wrote: > > Larry .. it is the will and order :-) of the WG that you and > Fujiwara-san collaborate on further iterations of the Implementations > issues draft. > > It is now a official WG document and in the future should be submitted > as such.. > > JPRS discovered several other problems that need to be addressed ... > in the next rev what I would suggest is that you detail each problem > and then discuss action items for authors, workarounds or proposed > solutions to each problem identified and we can then discuss them on > the list. > > For instance on the issue of ORDER vs PRECEDENCE ..state clearly that > it is RECOMMEDED implementors should fix ORDER of all ENUM service > fields to 100 and sort on precedence etc. > > repeat the format on the the issue of case insensitivity etc .. > > >> Hi folks, >> >> I'm Kazunori Fujiwara from JPRS. >> >> Today's my slides are on my web page: >> http://member.wide.ad.jp/~fujiwara/enum/ >> >> There are also my ENUM library ENUM.pm. >> (this code is under constuction) > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 > 815.333.1237 > or > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Mar 8 10:30:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07428 for ; Mon, 8 Mar 2004 10:30:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0MhC-00070a-AR for enum-archive@odin.ietf.org; Mon, 08 Mar 2004 10:29:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28FTYC7026891 for enum-archive@odin.ietf.org; Mon, 8 Mar 2004 10:29:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Mgf-0006xB-0K; Mon, 08 Mar 2004 10:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0MgI-0006vB-U9 for enum@optimus.ietf.org; Mon, 08 Mar 2004 10:28:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07346 for ; Mon, 8 Mar 2004 10:28:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0MgG-0004eE-00 for enum@ietf.org; Mon, 08 Mar 2004 10:28:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0MfI-0004SC-00 for enum@ietf.org; Mon, 08 Mar 2004 10:27:36 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1B0MeJ-0004B4-00 for enum@ietf.org; Mon, 08 Mar 2004 10:26:35 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (neustargw.va.neustar.com [209.173.53.233]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i28FZ2d05592; Mon, 8 Mar 2004 07:35:02 -0800 Message-Id: <6.0.3.0.2.20040304215737.0469e0e0@popd.ix.netcom.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 08 Mar 2004 10:20:50 -0500 To: enum@ietf.org From: Richard Shockey Cc: jon.peterson@neustar.biz, mankin@psg.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=BIZ_TLD autolearn=no version=2.60 Subject: [Enum] Last Call on Presence enumservice field Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , It was the consensus of the WG in Seoul that we proceed to last call with this document. 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 2 weeks from today March 8 to at least March 22 though we can modify that if new issues come up. Title : Enumservice Registration for Presence Services Author(s) : J. Peterson Filename : draft-ietf-enum-pres-00.txt Pages : 8 Date : 2003-12-18 This document registers an ENUM service for presence services (as described in RFC2778 [2]) pursuant to the guidelines in RFC2916bis [1]. Specifically, this document focuses on provisioning pres URIs in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-pres-00.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 10 06:50:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04366 for ; Wed, 10 Mar 2004 06:50:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12E5-0001tJ-Qc for enum-archive@odin.ietf.org; Wed, 10 Mar 2004 06:50:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ABoHBC007218 for enum-archive@odin.ietf.org; Wed, 10 Mar 2004 06:50:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12Dq-0001rm-3C; Wed, 10 Mar 2004 06:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12DJ-0001or-3g for enum@optimus.ietf.org; Wed, 10 Mar 2004 06:49:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04263 for ; Wed, 10 Mar 2004 06:49:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B12DF-0004Vr-00 for enum@ietf.org; Wed, 10 Mar 2004 06:49:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B12CE-0004C8-00 for enum@ietf.org; Wed, 10 Mar 2004 06:48:23 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1B12Av-0003ob-00 for enum@ietf.org; Wed, 10 Mar 2004 06:47:01 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (h-68-165-240-38.MCLNVA23.covad.net [68.165.240.38]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2ABtXd18462 for ; Wed, 10 Mar 2004 03:55:33 -0800 Message-Id: <6.0.3.0.2.20040310064603.04217530@popd.ix.netcom.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 10 Mar 2004 06:46:12 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=BIZ_TLD autolearn=no version=2.60 Subject: [Enum] Fwd: I-D ACTION:draft-ietf-fax-faxservice-enum-02.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >X-Authentication-Warning: above.proper.com: majordom set sender to >owner-ietf-fax@mail.imc.org using -f >To: IETF-Announce: ; >Cc: ietf-fax@imc.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-fax-faxservice-enum-02.txt >Date: Tue, 09 Mar 2004 15:56:51 -0500 >Sender: owner-ietf-fax@mail.imc.org >List-Archive: >List-ID: >List-Unsubscribe: > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Internet Fax Working Group of the IETF. > > Title : IFAX service of ENUM > Author(s) : K. Toyoda, D. Crocker > Filename : draft-ietf-fax-faxservice-enum-02.txt > Pages : 0 > Date : 2004-3-9 > >This document describes the functional specification >and the definition of the ENUM NAPTR record, for IFax >service. IFax is 'Facsimile using Internet Mail'. For >this use, the DNS returns the email address of the >referenced IFax system. This mechanism allows email-based >fax communication to use telephone numbers, rather than >requiring that the sender already know the recipient >email address. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-fax-faxservice-enum-02.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-fax-faxservice-enum-02.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-fax-faxservice-enum-02.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-3-9161715.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-fax-faxservice-enum-02.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 11 01:24:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00928 for ; Thu, 11 Mar 2004 01:24:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1JcC-0000HZ-H1 for enum-archive@odin.ietf.org; Thu, 11 Mar 2004 01:24:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B6OKfs001081 for enum-archive@odin.ietf.org; Thu, 11 Mar 2004 01:24:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Jbu-0000H0-G3; Thu, 11 Mar 2004 01:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1JbG-0000Er-FC for enum@optimus.ietf.org; Thu, 11 Mar 2004 01:23:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00879 for ; Thu, 11 Mar 2004 01:23:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1JbD-00030q-00 for enum@ietf.org; Thu, 11 Mar 2004 01:23:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1JaM-0002s5-00 for enum@ietf.org; Thu, 11 Mar 2004 01:22:27 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B1JZU-0002aS-00 for enum@ietf.org; Thu, 11 Mar 2004 01:21:32 -0500 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i2B6LCNr016546; Thu, 11 Mar 2004 01:21:13 -0500 (EST) Message-ID: <4050054D.9080906@dynamicsoft.com> Date: Thu, 11 Mar 2004 01:21:01 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Shockey CC: enum@ietf.org, jon.peterson@neustar.biz, mankin@psg.com Subject: Re: [Enum] Last Call on Presence enumservice field References: <6.0.3.0.2.20040304215737.0469e0e0@popd.ix.netcom.com> In-Reply-To: <6.0.3.0.2.20040304215737.0469e0e0@popd.ix.netcom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,BIZ_TLD autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Some comments on the draft: 1. The abstract includes references to rfc2778 and rfc2916bis. I believe that you are not allowed to have references in an abstract, since the abstract frequently appears in isolation, without the rest of the document (see http://www.ietf.org/ID-nits.html). > ENUM exists primarily to facilitate > the interconnection of systems that rely on telephone numbers with > those that use URIs to route transactions. Nit: URIs don't do routing. They're names. Suggest: ".. that use URIs to identify resources." > The IMPP WG of the IETF has a defined a generic URI used to identify > a presence service for a particular resource: the 'pres' URI scheme > (defined in CPP [4]). This document describes an enumservice for > advertising presence information associated with an E.164 number. Nit: I'm not a fan of naming working groups in standards document, since standards frequently persist beyond the group itself. I would suggest: "The Common Profile for Presence (CPP) [4] defines the 'pres' URI scheme for identifying a presence resource". > The presence information that is shared varies by communications > service. The IETF IMPP WG has defined a Presence Information Data > Format (or PIDF [6]) for describing the presence data associated with > a presentity. same comment as above. > The scheme of the URI that will appear in the regexp field of a NAPTR > record using the 'E2U+pres' enumservice will be the 'pres' URI > scheme. There are, however, other URI schemes that can be used to > identify presence services. Its unclear from this text whether the URI MUST be a pres URI, or just SHOULD be a pres URI, and therefore a SIP URI, for example, would be OK. > However, revealing a pres URI in and of itself is unlikely to > introduce many privacy concerns (although depending on the structure > of the URI, it might reveal the full name or employer of the target). I think its worth saying that, in cases where this bit is a security concern (revealing the full name or employer of the target), anonymized URIs can be used to avoid such disclosure. > References This section is not split into normative and informative. I'm assuming that this specification is targeted for PS and not informational, right? Thanks, Jonathan R. Richard Shockey wrote: > > It was the consensus of the WG in Seoul that we proceed to last call > with this document. > > 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 2 weeks from today March 8 to at > least March 22 though we can modify that if new issues come up. > > Title : Enumservice Registration for Presence > Services > Author(s) : J. Peterson > Filename : draft-ietf-enum-pres-00.txt > Pages : 8 > Date : 2003-12-18 > > This document registers an ENUM service for presence services (as > described in RFC2778 [2]) pursuant to the guidelines in RFC2916bis > [1]. Specifically, this document focuses on provisioning pres URIs > in ENUM. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-pres-00.txt > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 > 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 11 11:46:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10591 for ; Thu, 11 Mar 2004 11:46:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1TJV-0001Ne-9U for enum-archive@odin.ietf.org; Thu, 11 Mar 2004 11:45:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BGjffB005252 for enum-archive@odin.ietf.org; Thu, 11 Mar 2004 11:45:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1TIr-0001CC-Q0; Thu, 11 Mar 2004 11:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1TIW-0001AQ-0p for enum@optimus.ietf.org; Thu, 11 Mar 2004 11:44:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10488 for ; Thu, 11 Mar 2004 11:44:37 -0500 (EST) From: rwalter@netnumber.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1TIU-0004Fp-00 for enum@ietf.org; Thu, 11 Mar 2004 11:44:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1THV-00046F-00 for enum@ietf.org; Thu, 11 Mar 2004 11:43:37 -0500 Received: from ma-duxbury1c-a-31.albyny.adelphia.net ([24.48.200.31] helo=BRIGAR-CSOBAKKF) by ietf-mx with smtp (Exim 4.12) id 1B1TGW-0003q7-00 for enum@ietf.org; Thu, 11 Mar 2004 11:42:36 -0500 Date: Thu, 11 Mar 2004 11:42:24 -0500 To: enum@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jgyskpddhvpijapedmny" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [Enum] Hi! Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , ----------jgyskpddhvpijapedmny Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_BAGLE.E in file qctcvdmy.exe (in dcadcaaab.zip) The file is deleted. --------------------------------------------------------- ----------jgyskpddhvpijapedmny Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Look it through ----------jgyskpddhvpijapedmny Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) dcadcaaab.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------jgyskpddhvpijapedmny-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Mar 15 11:28:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08279 for ; Mon, 15 Mar 2004 11:28:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2uww-0002KJ-DX for enum-archive@odin.ietf.org; Mon, 15 Mar 2004 11:28:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FGSMt1008939 for enum-archive@odin.ietf.org; Mon, 15 Mar 2004 11:28:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2uwd-0002Fz-Lv; Mon, 15 Mar 2004 11:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2uwG-0002EK-Kb for enum@optimus.ietf.org; Mon, 15 Mar 2004 11:27:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08127 for ; Mon, 15 Mar 2004 11:27:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2uwF-0000dS-00 for enum@ietf.org; Mon, 15 Mar 2004 11:27:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2uuu-0000KB-00 for enum@ietf.org; Mon, 15 Mar 2004 11:26:18 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1B2ut4-0007Ty-00 for enum@ietf.org; Mon, 15 Mar 2004 11:24:22 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (neustargw.va.neustar.com [209.173.53.233]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2FGWwd16203 for ; Mon, 15 Mar 2004 08:32:59 -0800 Message-Id: <6.0.3.0.2.20040303024610.03d3dec0@popd.ix.netcom.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 15 Mar 2004 11:23:42 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,BIZ_TLD,LINES_OF_YELLING autolearn=no version=2.60 Subject: [Enum] Preliminary Minutes of ENUM WG IETF 59 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , If there are any additions or corrections let me know... Telephone Number Mapping WG (enum) Wednesday, March 3 at 0900-1130 =============================== CHAIRS: Patrik Faltstrom Richard Shockey SCRIBE: Spencer Dawkins AGENDA: AGENDA BASHING (5 min) ( appointment of scribe etc) Status of 2916bis ... Allison Mankin Transport AD - problem with IANA - and our relationship is not formal, no contract with us, just handshake agreements - they have a very significant staffing problem with a huge backlog. - IESG made a list - high delay, extremely high backlog, high priority was so backlogged that they had a hard time prioritizing - 2916bis is part of the backlog - no tracker in place today (as we have with I-D trackers) - we started this action before the document was approved, but had no way to know there was a problem - if registries are being blocked, please let us know so we can prioritize - all the registration documents are blocked - iFax, VPIM, at least six documents - today's presentations are about services that are rolling out now - what else do we need to say? - registries acting in faith that I-Ds will not change before RFC publication - ACTION ITEM_ - chairs to send a formal letter to IESG - please provide inputs to this letter - revs of other services - get them in sooner, rather than later, OK? IFAX Registration - Richard Shockey- Claudio Allocchio Fax WG co-chair - this document also in the IANA queue - any difficulties with this document? - Claudio - security and privacy sections very skinny - should we expand this stuff or leave it and point elsewhere? - web and FT documents contained all considerations - IFAX should match these documents - is this a simple revision, or harder? CONSENSUS any objections to this document? none in the room - chair preference is to add this text and send it to the IESG - editors say no problem adding this text - no last call required - Allison - document user interested in fax, not other services, not going to look at an H.323 document for these sections - bits are free A. Discussion of Jon Peterson's presence document ... (10 m) http://www.ietf.org/internet-drafts/draft-ietf-enum-pres-00.txt - not a lot of feedback received so far - want more - adds a pres: URI scheme, resolves to XMPP, SIMPLE, etc. - presence protocol-independent - PSTN telephones still need work (states, location attributions) - especially for wireless - not a lot of changes since initial draft (name change plus references update - James - what is XMPP status now? RFC? still an I-D, but have been approved by IESG - what about press: schema? Also passed IESG, some time back - move forward to WGLC? any objection? Is this urgently needed? it is implemented, will move forward. CONSENSUS - GO TO LAST CALL B. A report on the results of the ETSI ENUM Plugtest Workshop (R. Stastny 15 M) - last week, hosted by ETSI, 55 attendees (lower because of 3GPP conflicts, etc.) - presentations available at ETSI website - spent time on both user ENUM and carrier ENUM - 14 presentations on user ENUM - privacy and data security viewed as more critical than regulatory issues for ENUM rollout - no "killer application", but strong focus for VoIP - 4 presentations on carrier ENUM - huge number of possible implementations, including MMSC, SMSC, SMPP gateway, MSSP, HLR/HSS, ...) - Verisign presentation focused on registries and registry interworking. - applications/implementations vary more widely than user ENUM - two Plugfests upcoming, in October and late November/early December - Plugfests and related workshops are open to anyone, not just ETSI members - www.etsi.org/plugtests for details C. A report on APRICOT ENUM BoF (J Seng 10M) - ENUM/SIP BoF last week - James focused on TWNIC trials (other participants presenting separately) - regulators have allocated 0944 for trials, but production SIP/ENUM using unofficial block(?) of 070 - 802.11b SIP phones for 50 dollars, also being distributed with two-year contract commitments to carriers - 64111 allocated (10,000 numbers), with no telco involvement - all countries eager to do trials, but ENUMs mean different things to different people - have issues getting e164-arpa to work under delegation - operating under ccTLD for now - forming Asia Pacific ENUM Technical Forum, details by July timeframe - what are regulator difficulties? vary by country. Helps if you work in the same building as regulators. Ongoing discussions with regulators in China and Japan. - Taiwan is a special case (86 not in ITU tables at all) D. CN-NIC focussing their ENUM trials in China (15M Sheldon Lee) - 80M Internet users in China, 260M mobile phones, 255M fixed phones at yearend 2003 - trials started in July 2001, 6.8.e164.arpa delegation in September 2002, opened for public testing in December 2003, performance testing in September 2003 - 3-tier ENUM resolution in China, registration plan studied but not completed - 7741 queries in February 2004 (after spring festival in January) - 260 users and 520 ENUMs registrations - ENUM trial platform includes SIP UAs, IP/GSTN gateway, ENUM-enabled SIP proxy, only ENUM users can register SIP account - ENUM server pressure is how to support large number of queries with dynamic update - 94% query responses with 2-second latency when not using caching - participating in both ITU-T and IETF ENUM, and in several workshops - promotion of ENUM/SIP in China is big challenge - no Internet phone license issued for end users in China - what service is most beneficial in China? SIP registration, exchange ENUM in browser address bar - finished with SIP call to person in the second row of audience, and to China ("hello to IETF") E. JP-NIC discussing ENUM in Japan ETJP(Enum Trial Japan) web page is http://etjp.jp/english/ (15M Kazunori Fujiwara) - 1-year trial activity, started in September 2003 - verify communication and applications technologies, and clarify relevant issues - working groups - Privacy and Security, and DNS - using +81 numbers - includes SIP server, SOHO router, DNS, applications Implementation Experience R. Stastny for Larry Conroy - 2916bis and DDDS ambiguous - example from NAPTR RR regulart expression interpretation, and room was not sure what right answer was - multiple field delimiter characters are proving troublesome - limit to one character? - Patrik - we have inherited regular expression, and we can't fix it ourselves - must fix NAPTR itself - Patrik has action to close this loop - processing order - SERVICE before ORDER? RFC 3405 seems contradictory - answer, process SERVICE before ORDER? but this answer is too easy, if we need to choose between services based on preferences - but this seems to require FQDN? but that's what we have in ENUM anyway - what about privacy aspects of including this stuff in DNS instead of SIP? may have overriding preferences - put that in DNS - maybe we shouldn't touch the ORDER field - but this is a negotiation between the endpoints and shouldn't be prescribed - does ENUM always return a single rule? multiple contact points, which may not all be SIP contact points? e-mail, etc. - MUST process non-terminal NAPTR? we don't - is summary 2916bis-compliant? - Richard - suggests that people who have implementation issues collaborate with Larry Conroy on his draft - we have issues with these RFCs, and fixing them will take time. How to move forward? "BCP" for an I-D? - Patrik would also like to maintain the Conroy draft as experience grows - need to document workarounds - this should become a BCP document CONSENSUS Combine JPRS work with existing implementation document make this draft a working group document F. Our Korean Hosts KR-NIC will update us on their ENUM trial status... - launched public trial October 2003-January 2004, national workshop last December, national standards requivalent to RFCs and New Standard Development - see lots of possibilities in Asia-Pacific region (not just Korea) - ENUM APIs, telephony, DNS, registration - 60-percent of telephone numbers are mobile - don't distinguish between PSTN and mobile numbers - still developing APIs - ENUM FAX, ENUM H.323, telephony on a website - service council moving to profit model setup, commercial services - Korea still waiting for country to sign with ITU - registry problem - have been negotiating with goverment for two years - Tier 1 registry selection is quite important - not sure why other countries are working on ENUM? effect of ENUM on Telecommunication Policy? charm of ENUM, compared to domain names? - mobile environment important to ENUM deployment - expect regulations, AAA, business model in 2004, commercial service in 2005 - Japan shipping H.323 now, with numbering plan assigned to commercial service - Japan using special numbers for VoIP calls, and Korea expects to do the same thing - is priority in your service the number to connect? - want to keep up with ENUM in real world. Telcos think people would prefer mobile device numbers to other device numbers - all this is a hard decision for us - does Korean government assign special numbers? yes - what is official VoIP protocol? H.323, but SIP is good... G. Plans to close the trial and go commercial in Austria with ENUM and the ENUM-only number range (+43780) (R. Stastny 10-15) - Austria has proved concept with ENUM trial - ENUM ready for deployment, so trial is ending - need legal framework, need official platform (AK-TK) - ENUM will be a working group within AK-TK regulatory body - basic issues are solved, but opt-in for residential numbers has problems - see Metcalf's law - how do we get users into ENUM? - ENUM for IP-PBX with direct dial-in - ENUM-only ranges for IP Communications - mobile numbers validated via SIM card - IP communication bigger than VoIP, and other services growing in importance. - no definition of how routing will be done - punt PSTN-only numbers to PSTN gateways - pre-paid cards add validation/identification considerations - adding mms:mailto and mms:sip - one company in Gernany giving out ENUM numbers commercially now - interesting "primary goals" slide... H. ENUM Implementation Redux - Willheim Wimmhitter http://www.ietf.org/internet-drafts/draft-conroy-enum-experiences-01.txt - case sensitivity (we only use numbers in ENUM, but we still manage to break some clients that assume last character is a regexp delimiter) - don't use this flag if you can avoid it - order traversal (as previously described) I. ENUM WG issues - could we hibernate? still some implementation experience to capture - can we get a link to these presentations? Richard will provide this - no discussion of provisioning issues - OK for trials, but probably not for commercial offerings 1. Status of Privacy-Security and other drafts still in the pipeline >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Mar 15 17:26:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02539 for ; Mon, 15 Mar 2004 17:26:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30XR-0001gc-Iz for enum-archive@odin.ietf.org; Mon, 15 Mar 2004 17:26:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FMQPl5006481 for enum-archive@odin.ietf.org; Mon, 15 Mar 2004 17:26:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30X5-0001c2-KB; Mon, 15 Mar 2004 17:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30WT-0001Y6-W2 for enum@optimus.ietf.org; Mon, 15 Mar 2004 17:25:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02421 for ; Mon, 15 Mar 2004 17:25:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B30WR-0005Z7-00 for enum@ietf.org; Mon, 15 Mar 2004 17:25:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B30Vt-0005UN-00 for enum@ietf.org; Mon, 15 Mar 2004 17:24:49 -0500 Received: from cypress.neustar.com ([209.173.57.84]) by ietf-mx with esmtp (Exim 4.12) id 1B30V1-0005Iw-00 for enum@ietf.org; Mon, 15 Mar 2004 17:23:55 -0500 Received: from chiimc01.cis.neustar.com (chiimc01.neustar.com [10.32.90.4]) by cypress.neustar.com (8.12.8/8.11.6) with ESMTP id i2FMNG4P027556; Mon, 15 Mar 2004 22:23:16 GMT Received: by chiimc01.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 15 Mar 2004 16:23:38 -0600 Message-ID: From: "Peterson, Jon" To: "'Jonathan Rosenberg'" , Richard Shockey Cc: enum@ietf.org, mankin@psg.com Subject: RE: [Enum] Last Call on Presence enumservice field Date: Mon, 15 Mar 2004 16:23:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,BIZ_TLD autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Thanks for these nits and other comments. At the conclusion of WGLC, I'll issue a revision that incorporates the proposed changes below. I think the only issue that requires substantial consideration below is the question of what type of URI needs to appear in a resource record identified by the "E2U+pres" service field. I agree that the current text here is weak. What I had in mind was something like "SHOULD be pres URI, MAY be other URI identifying a presence service, as appropriate, but understand that pres URI is most compatible". Does that work for you? Jon Peterson NeuStar, Inc. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, March 10, 2004 10:21 PM To: Richard Shockey Cc: enum@ietf.org; jon.peterson@neustar.biz; mankin@psg.com Subject: Re: [Enum] Last Call on Presence enumservice field Some comments on the draft: 1. The abstract includes references to rfc2778 and rfc2916bis. I believe that you are not allowed to have references in an abstract, since the abstract frequently appears in isolation, without the rest of the document (see http://www.ietf.org/ID-nits.html). > ENUM exists primarily to facilitate > the interconnection of systems that rely on telephone numbers with > those that use URIs to route transactions. Nit: URIs don't do routing. They're names. Suggest: ".. that use URIs to identify resources." > The IMPP WG of the IETF has a defined a generic URI used to identify > a presence service for a particular resource: the 'pres' URI scheme > (defined in CPP [4]). This document describes an enumservice for > advertising presence information associated with an E.164 number. Nit: I'm not a fan of naming working groups in standards document, since standards frequently persist beyond the group itself. I would suggest: "The Common Profile for Presence (CPP) [4] defines the 'pres' URI scheme for identifying a presence resource". > The presence information that is shared varies by communications > service. The IETF IMPP WG has defined a Presence Information Data > Format (or PIDF [6]) for describing the presence data associated with > a presentity. same comment as above. > The scheme of the URI that will appear in the regexp field of a NAPTR > record using the 'E2U+pres' enumservice will be the 'pres' URI > scheme. There are, however, other URI schemes that can be used to > identify presence services. Its unclear from this text whether the URI MUST be a pres URI, or just SHOULD be a pres URI, and therefore a SIP URI, for example, would be OK. > However, revealing a pres URI in and of itself is unlikely to > introduce many privacy concerns (although depending on the structure > of the URI, it might reveal the full name or employer of the target). I think its worth saying that, in cases where this bit is a security concern (revealing the full name or employer of the target), anonymized URIs can be used to avoid such disclosure. > References This section is not split into normative and informative. I'm assuming that this specification is targeted for PS and not informational, right? Thanks, Jonathan R. Richard Shockey wrote: > > It was the consensus of the WG in Seoul that we proceed to last call > with this document. > > 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 2 weeks from today March 8 to at > least March 22 though we can modify that if new issues come up. > > Title : Enumservice Registration for Presence > Services > Author(s) : J. Peterson > Filename : draft-ietf-enum-pres-00.txt > Pages : 8 > Date : 2003-12-18 > > This document registers an ENUM service for presence services (as > described in RFC2778 [2]) pursuant to the guidelines in RFC2916bis > [1]. Specifically, this document focuses on provisioning pres URIs > in ENUM. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-pres-00.txt > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 > 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 16 10:28:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06398 for ; Tue, 16 Mar 2004 10:28:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3GUV-0007xm-D6 for enum-archive@odin.ietf.org; Tue, 16 Mar 2004 10:28:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GFSRon030556 for enum-archive@odin.ietf.org; Tue, 16 Mar 2004 10:28:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3GU5-0007w0-Ul; Tue, 16 Mar 2004 10:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3GTx-0007vY-FJ for enum@optimus.ietf.org; Tue, 16 Mar 2004 10:27:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06340 for ; Tue, 16 Mar 2004 10:27:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3GTv-0005Cs-00 for enum@ietf.org; Tue, 16 Mar 2004 10:27:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3GT5-00058C-00 for enum@ietf.org; Tue, 16 Mar 2004 10:27:00 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B3GSV-000502-00 for enum@ietf.org; Tue, 16 Mar 2004 10:26:24 -0500 Received: from dynamicsoft.com ([63.113.46.98]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i2GFPxNr019315; Tue, 16 Mar 2004 10:26:01 -0500 (EST) Message-ID: <40571C75.4010209@dynamicsoft.com> Date: Tue, 16 Mar 2004 10:25:41 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: Richard Shockey , enum@ietf.org, mankin@psg.com Subject: Re: [Enum] Last Call on Presence enumservice field References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Peterson, Jon wrote: > Thanks for these nits and other comments. At the conclusion of WGLC, I'll > issue a revision that incorporates the proposed changes below. Thanks. > > I think the only issue that requires substantial consideration below is the > question of what type of URI needs to appear in a resource record identified > by the "E2U+pres" service field. I agree that the current text here is weak. > What I had in mind was something like "SHOULD be pres URI, MAY be other URI > identifying a presence service, as appropriate, but understand that pres URI > is most compatible". Does that work for you? Sounds fine. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 17 11:50:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20148 for ; Wed, 17 Mar 2004 11:50:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3eEw-0005Mm-S3 for enum-archive@odin.ietf.org; Wed, 17 Mar 2004 11:49:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HGnwBs020628 for enum-archive@odin.ietf.org; Wed, 17 Mar 2004 11:49:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3eE2-0005D1-6C; Wed, 17 Mar 2004 11:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3eDi-0005B7-7e for enum@optimus.ietf.org; Wed, 17 Mar 2004 11:48:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20033 for ; Wed, 17 Mar 2004 11:48:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3eDc-00028k-00 for enum@ietf.org; Wed, 17 Mar 2004 11:48:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3eCo-00022C-00 for enum@ietf.org; Wed, 17 Mar 2004 11:47:47 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1B3eCA-0001s5-00 for enum@ietf.org; Wed, 17 Mar 2004 11:47:06 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (neustargw.va.neustar.com [209.173.53.233]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2HGtkd05757 for ; Wed, 17 Mar 2004 08:55:46 -0800 Message-Id: <6.0.3.0.2.20040317114300.03d21ec0@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 17 Mar 2004 11:43:05 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,BIZ_TLD autolearn=no version=2.60 Subject: [Enum] Fwd: I-D ACTION:draft-bartosiewicz-enterprise-enum-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-bartosiewicz-enterprise-enum-00.txt >Date: Wed, 17 Mar 2004 11:08:09 -0500 >Sender: owner-ietf-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Cost optimization based on Enterprise-ENUM > Author(s) : A. Bartosiewicz > Filename : draft-bartosiewicz-enterprise-enum-00.txt > Pages : 0 > Date : 2004-3-12 > >This paper presents an extension of NAPTR Resource Records and an > application of the local DNS (called in further part of this > document 'Enterprise -ENUM') in order to keep information required > for costs optimization of telecommunication connections. > The optimization should cover the cost reduction through the > selection of cheapest form of telecommunication connections for > the calling party (a person initializing a telecommunication > connection). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-bartosiewicz-enterprise-enum-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-bartosiewicz-enterprise-enum-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-bartosiewicz-enterprise-enum-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: <2004-3-17113102.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-bartosiewicz-enterprise-enum-00.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 18 12:50:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26939 for ; Thu, 18 Mar 2004 12:50:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41ev-0001dM-9B for enum-archive@odin.ietf.org; Thu, 18 Mar 2004 12:50:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IHoLkq006226 for enum-archive@odin.ietf.org; Thu, 18 Mar 2004 12:50:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41eb-0001bH-GE; Thu, 18 Mar 2004 12:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41eF-0001Yi-IM for enum@optimus.ietf.org; Thu, 18 Mar 2004 12:49:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26834 for ; Thu, 18 Mar 2004 12:49:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B41eD-0006iU-00 for enum@ietf.org; Thu, 18 Mar 2004 12:49:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B41dO-0006eG-00 for enum@ietf.org; Thu, 18 Mar 2004 12:48:47 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1B41cR-0006WF-00 for enum@ietf.org; Thu, 18 Mar 2004 12:47:48 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (neustargw.va.neustar.com [209.173.53.233]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2IHuNd01296; Thu, 18 Mar 2004 09:56:23 -0800 Message-Id: <6.0.3.0.2.20040308102100.03b934a8@popd.ix.netcom.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 18 Mar 2004 12:32:38 -0500 To: enum@ietf.org From: Richard Shockey Cc: paf@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,BIZ_TLD autolearn=no version=2.60 Subject: [Enum] Action Item from the WG meeting on the IANA process issues in 2916bis Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , As was discussed in Seoul the Chairs have taken as an action to compose a memo to the IESG on the difficulties with ENUM implementations and deployments due to inactions by the IANA on processing our drafts. We believe there is some progress here but additional pressure may be needed Patrik and I are, therefore, soliciting comments from the list to properly document these difficulties so that ICANN ,as the contractor for the IANA function, can be properly briefed. Please send comments to this list and we, as the chairs, will compile the comments and forward as required. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Mar 19 09:21:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04506 for ; Fri, 19 Mar 2004 09:21:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Ks2-0003wp-Fd for enum-archive@odin.ietf.org; Fri, 19 Mar 2004 09:21:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JELANn015121 for enum-archive@odin.ietf.org; Fri, 19 Mar 2004 09:21:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Kru-0003vU-8B; Fri, 19 Mar 2004 09:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4KrX-0003ue-HV for enum@optimus.ietf.org; Fri, 19 Mar 2004 09:20:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04462 for ; Fri, 19 Mar 2004 09:20:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4KrV-0004Eb-00 for enum@ietf.org; Fri, 19 Mar 2004 09:20:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Kqf-00049I-00 for enum@ietf.org; Fri, 19 Mar 2004 09:19:48 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B4Kpc-00040a-00 for enum@ietf.org; Fri, 19 Mar 2004 09:18:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Action Item from the WG meeting on the IANA process issues in 2916bis Date: Fri, 19 Mar 2004 15:24:10 +0100 Message-ID: <06CF906FE3998C4E944213062009F162233C08@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Action Item from the WG meeting on the IANA process issues in 2916bis Thread-Index: AcQNEme3RWoIfXBETwKi5slmR0VF0AAqdXBw From: "Stastny Richard" To: "Richard Shockey" , Cc: Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Before I send in a comment on the difficulties with commercial ENUM Applications based on non-existing standards, I would like the Chairs to = ask IANA what the problems are they have in processing the drafts. Maybe we could provide some help or input. As I understand it, tha task of IANA is to set up a webpage on the IANA = site which points to a file containing the registered enumservices with the = the relevant RFC listed or am I missing something? Is there something missing or incorrect in the templates of rfc2916bis? Is there something missing or incorrect in the already existing = enumservice drafts? Are there any other problems? Regards Richard > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Thursday, March 18, 2004 6:33 PM > To: enum@ietf.org > Cc: paf@cisco.com > Subject: [Enum] Action Item from the WG meeting on the IANA process = issues > in 2916bis >=20 >=20 > As was discussed in Seoul the Chairs have taken as an action to = compose a > memo to the IESG on the difficulties with ENUM implementations and > deployments due to inactions by the IANA on processing our drafts. >=20 > We believe there is some progress here but additional pressure may be > needed >=20 > Patrik and I are, therefore, soliciting comments from the list to = properly > document these difficulties so that ICANN ,as the contractor for the = IANA > function, can be properly briefed. >=20 > Please send comments to this list and we, as the chairs, will compile = the > comments and forward as required. >=20 >=20 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 > 815.333.1237 > or = > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Mar 19 10:18:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07782 for ; Fri, 19 Mar 2004 10:18:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Ll9-0005TR-Pn for enum-archive@odin.ietf.org; Fri, 19 Mar 2004 10:18:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JFI7PE021016 for enum-archive@odin.ietf.org; Fri, 19 Mar 2004 10:18:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Ll3-0005S3-FC; Fri, 19 Mar 2004 10:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Lk4-0005Bn-Pp for enum@optimus.ietf.org; Fri, 19 Mar 2004 10:17:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07606 for ; Fri, 19 Mar 2004 10:16:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Lk2-0000tR-00 for enum@ietf.org; Fri, 19 Mar 2004 10:16:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Lif-0000le-00 for enum@ietf.org; Fri, 19 Mar 2004 10:15:36 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1B4LhN-0000bJ-00 for enum@ietf.org; Fri, 19 Mar 2004 10:14:13 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMRGXN>; Fri, 19 Mar 2004 15:13:35 -0000 Received: from [127.0.0.1] (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1ZGNFGDF; Fri, 19 Mar 2004 15:13:27 -0000 From: "Conroy, Lawrence (SMTP)" To: Stastny Richard Cc: Richard Shockey , paf@cisco.com, enum@ietf.org In-Reply-To: <06CF906FE3998C4E944213062009F162233C08@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F162233C08@oefeg-s02.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Enum] Action Item from the WG meeting on the IANA process issues in 2916bis Date: Fri, 19 Mar 2004 15:13:25 +0000 X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Folks, ... and whilst we're on this topic... Why do we need to wait until the IANA have set up their web page before allocating a number for the RFC (and publishing it)? AFAIK, releasing and publishing an RFC has nothing to do with the IANA contractor. The problems I've found have been from implementation folk in a (non-Siemens) German company telling me that they MUST implement RFC2916 as they follow IETF recommendations not to implement from Internet-Drafts. Thus when I suggested that they implement RFC2916bis, they said that this was wrong. I refuse to embarrass the source of this statement by identifying them. They are, in some ways, correct; basically, this mess is our fault. all the best, Lawrence On 19 Mar 2004, at 2:24 pm, Stastny Richard wrote: > Before I send in a comment on the difficulties with commercial ENUM > Applications based on non-existing standards, I would like the Chairs > to ask > IANA what the problems are they have in processing the drafts. Maybe we > could provide some help or input. > > As I understand it, tha task of IANA is to set up a webpage on the > IANA site > which points to a file containing the registered enumservices with the > the > relevant RFC listed or am I missing something? > > Is there something missing or incorrect in the templates of rfc2916bis? > Is there something missing or incorrect in the already existing > enumservice drafts? > Are there any other problems? > > Regards > Richard > > >> -----Original Message----- >> From: Richard Shockey [mailto:richard@shockey.us] >> >> Patrik and I are, therefore, soliciting comments from the list to >> properly >> document these difficulties so that ICANN ,as the contractor for the >> IANA >> function, can be properly briefed. >> >> Please send comments to this list and we, as the chairs, will compile >> the >> comments and forward as required. >> _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Mar 19 16:23:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23833 for ; Fri, 19 Mar 2004 16:23:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RSR-0000e1-U6 for enum-archive@odin.ietf.org; Fri, 19 Mar 2004 16:23:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JLNBft002473 for enum-archive@odin.ietf.org; Fri, 19 Mar 2004 16:23:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RRJ-0000Ti-Td; Fri, 19 Mar 2004 16:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4QeN-0005Pv-3c for enum@optimus.ietf.org; Fri, 19 Mar 2004 15:31:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21227 for ; Fri, 19 Mar 2004 15:31:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4QeL-0006Dk-00 for enum@ietf.org; Fri, 19 Mar 2004 15:31:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4QdU-00067h-00 for enum@ietf.org; Fri, 19 Mar 2004 15:30:33 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1B4QcX-0005wI-00; Fri, 19 Mar 2004 15:29:33 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (neustargw.va.neustar.com [209.173.53.233]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2JKcFd25616; Fri, 19 Mar 2004 12:38:15 -0800 Message-Id: <6.0.3.0.2.20040318115616.03bdd978@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Fri, 19 Mar 2004 15:28:25 -0500 To: proceedings@ietf.org From: Richard Shockey Cc: enum@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=BIZ_TLD,LINES_OF_YELLING autolearn=no version=2.60 Subject: [Enum] FINAL- Minutes of ENUM WG IETF 59 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Telephone Number Mapping WG (enum) IETF 59 Soeul, Korea Wednesday, March 3, 2004 0900-1130 AM =============================== CHAIRS: Patrik Faltstrom Richard Shockey SCRIBE: Spencer Dawkins AGENDA: AGENDA BASHING (5 min) ( appointment of scribe etc) Status of 2916bis ... Allison Mankin Transport AD - problem with IANA - and our relationship is not formal, no contract with us, just handshake agreements - they have a very significant staffing problem with a huge backlog. - IESG made a list - high delay, extremely high backlog, high priority was so backlogged that they had a hard time prioritizing - 2916bis is part of the backlog - no tracker in place today (as we have with I-D trackers) - we started this action before the document was approved, but had no way to know there was a problem - if registries are being blocked, please let us know so we can prioritize - all the registration documents are blocked - iFax, VPIM, at least six documents - today's presentations are about services that are rolling out now - what else do we need to say? - registries acting in faith that I-Ds will not change before RFC publication - ACTION ITEM_ - chairs to send a formal letter to IESG - please provide inputs to this letter - revs of other services - get them in sooner, rather than later, OK? IFAX Registration - Richard Shockey- Claudio Allocchio Fax WG co-chair - this document also in the IANA queue - any difficulties with this document? - Claudio - security and privacy sections very skinny - should we expand this stuff or leave it and point elsewhere? - web and FT documents contained all considerations - IFAX should match these documents - is this a simple revision, or harder? CONSENSUS any objections to this document? none in the room - chair preference is to add this text and send it to the IESG - editors say no problem adding this text - no last call required - Allison - document user interested in fax, not other services, not going to look at an H.323 document for these sections - bits are free A. Discussion of Jon Peterson's presence document ... (10 m) http://www.ietf.org/internet-drafts/draft-ietf-enum-pres-00.txt - not a lot of feedback received so far - want more - adds a pres: URI scheme, resolves to XMPP, SIMPLE, etc. - presence protocol-independent - PSTN telephones still need work (states, location attributions) - especially for wireless - not a lot of changes since initial draft (name change plus references update - James - what is XMPP status now? RFC? still an I-D, but have been approved by IESG - what about press: schema? Also passed IESG, some time back - move forward to WGLC? any objection? Is this urgently needed? it is implemented, will move forward. CONSENSUS - GO TO LAST CALL B. A report on the results of the ETSI ENUM Plugtest Workshop (R. Stastny 15 M) - last week, hosted by ETSI, 55 attendees (lower because of 3GPP conflicts, etc.) - presentations available at ETSI website - spent time on both user ENUM and carrier ENUM - 14 presentations on user ENUM - privacy and data security viewed as more critical than regulatory issues for ENUM rollout - no "killer application", but strong focus for VoIP - 4 presentations on carrier ENUM - huge number of possible implementations, including MMSC, SMSC, SMPP gateway, MSSP, HLR/HSS, ...) - Verisign presentation focused on registries and registry interworking. - applications/implementations vary more widely than user ENUM - two Plugfests upcoming, in October and late November/early December - Plugfests and related workshops are open to anyone, not just ETSI members - www.etsi.org/plugtests for details C. A report on APRICOT ENUM BoF (J Seng 10M) - ENUM/SIP BoF last week - James focused on TWNIC trials (other participants presenting separately) - regulators have allocated 0944 for trials, but production SIP/ENUM using unofficial block(?) of 070 - 802.11b SIP phones for 50 dollars, also being distributed with two-year contract commitments to carriers - 64111 allocated (10,000 numbers), with no telco involvement - all countries eager to do trials, but ENUMs mean different things to different people - have issues getting e164-arpa to work under delegation - operating under ccTLD for now - forming Asia Pacific ENUM Technical Forum, details by July timeframe - what are regulator difficulties? vary by country. Helps if you work in the same building as regulators. Ongoing discussions with regulators in China and Japan. - Taiwan is a special case (86 not in ITU tables at all) D. CN-NIC focussing their ENUM trials in China (15M Sheldon Lee) - 80M Internet users in China, 260M mobile phones, 255M fixed phones at yearend 2003 - trials started in July 2001, 6.8.e164.arpa delegation in September 2002, opened for public testing in December 2003, performance testing in September 2003 - 3-tier ENUM resolution in China, registration plan studied but not completed - 7741 queries in February 2004 (after spring festival in January) - 260 users and 520 ENUMs registrations - ENUM trial platform includes SIP UAs, IP/GSTN gateway, ENUM-enabled SIP proxy, only ENUM users can register SIP account - ENUM server pressure is how to support large number of queries with dynamic update - 94% query responses with 2-second latency when not using caching - participating in both ITU-T and IETF ENUM, and in several workshops - promotion of ENUM/SIP in China is big challenge - no Internet phone license issued for end users in China - what service is most beneficial in China? SIP registration, exchange ENUM in browser address bar - finished with SIP call to person in the second row of audience, and to China ("hello to IETF") E. JP-NIC discussing ENUM in Japan ETJP(Enum Trial Japan) web page is http://etjp.jp/english/ (15M Kazunori Fujiwara) - 1-year trial activity, started in September 2003 - verify communication and applications technologies, and clarify relevant issues - working groups - Privacy and Security, and DNS - using +81 numbers - includes SIP server, SOHO router, DNS, applications Implementation Experience R. Stastny for Larry Conroy - 2916bis and DDDS ambiguous - example from NAPTR RR regulart expression interpretation, and room was not sure what right answer was - multiple field delimiter characters are proving troublesome - limit to one character? - Patrik - we have inherited regular expression, and we can't fix it ourselves - must fix NAPTR itself - Patrik has action to close this loop - processing order - SERVICE before ORDER? RFC 3405 seems contradictory - answer, process SERVICE before ORDER? but this answer is too easy, if we need to choose between services based on preferences - but this seems to require FQDN? but that's what we have in ENUM anyway - what about privacy aspects of including this stuff in DNS instead of SIP? may have overriding preferences - put that in DNS - maybe we shouldn't touch the ORDER field - but this is a negotiation between the endpoints and shouldn't be prescribed - does ENUM always return a single rule? multiple contact points, which may not all be SIP contact points? e-mail, etc. - MUST process non-terminal NAPTR? we don't - is summary 2916bis-compliant? - Richard - suggests that people who have implementation issues collaborate with Larry Conroy on his draft - we have issues with these RFCs, and fixing them will take time. How to move forward? "BCP" for an I-D? - Patrik would also like to maintain the Conroy draft as experience grows - need to document workarounds - this should become a BCP document CONSENSUS Combine JPRS work with existing implementation document make this draft a working group document F. Our Korean Hosts KR-NIC will update us on their ENUM trial status... - launched public trial October 2003-January 2004, national workshop last December, national standards requivalent to RFCs and New Standard Development - see lots of possibilities in Asia-Pacific region (not just Korea) - ENUM APIs, telephony, DNS, registration - 60-percent of telephone numbers are mobile - don't distinguish between PSTN and mobile numbers - still developing APIs - ENUM FAX, ENUM H.323, telephony on a website - service council moving to profit model setup, commercial services - Korea still waiting for country to sign with ITU - registry problem - have been negotiating with goverment for two years - Tier 1 registry selection is quite important - not sure why other countries are working on ENUM? effect of ENUM on Telecommunication Policy? charm of ENUM, compared to domain names? - mobile environment important to ENUM deployment - expect regulations, AAA, business model in 2004, commercial service in 2005 - Japan shipping H.323 now, with numbering plan assigned to commercial service - Japan using special numbers for VoIP calls, and Korea expects to do the same thing - is priority in your service the number to connect? - want to keep up with ENUM in real world. Telcos think people would prefer mobile device numbers to other device numbers - all this is a hard decision for us - does Korean government assign special numbers? yes - what is official VoIP protocol? H.323, but SIP is good... G. Plans to close the trial and go commercial in Austria with ENUM and the ENUM-only number range (+43780) (R. Stastny 10-15) - Austria has proved concept with ENUM trial - ENUM ready for deployment, so trial is ending - need legal framework, need official platform (AK-TK) - ENUM will be a working group within AK-TK regulatory body - basic issues are solved, but opt-in for residential numbers has problems - see Metcalf's law - how do we get users into ENUM? - ENUM for IP-PBX with direct dial-in - ENUM-only ranges for IP Communications - mobile numbers validated via SIM card - IP communication bigger than VoIP, and other services growing in importance. - no definition of how routing will be done - punt PSTN-only numbers to PSTN gateways - pre-paid cards add validation/identification considerations - adding mms:mailto and mms:sip - one company in Gernany giving out ENUM numbers commercially now - interesting "primary goals" slide... H. ENUM Implementation Redux - Willheim Wimmhitter http://www.ietf.org/internet-drafts/draft-conroy-enum-experiences-01.txt - case sensitivity (we only use numbers in ENUM, but we still manage to break some clients that assume last character is a regexp delimiter) - don't use this flag if you can avoid it - order traversal (as previously described) I. ENUM WG issues - could we hibernate? still some implementation experience to capture - can we get a link to these presentations? Richard will provide this - no discussion of provisioning issues - OK for trials, but probably not for commercial offerings 1. Status of Privacy-Security and other drafts still in the pipeline >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Mar 22 06:16:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16535 for ; Mon, 22 Mar 2004 06:16:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5NPx-0008Jj-0R for enum-archive@odin.ietf.org; Mon, 22 Mar 2004 06:16:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MBGSJK031960 for enum-archive@odin.ietf.org; Mon, 22 Mar 2004 06:16:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5NPk-00080V-NR; Mon, 22 Mar 2004 06:16:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5NPO-0007xb-Gd for enum@optimus.ietf.org; Mon, 22 Mar 2004 06:15:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16487 for ; Mon, 22 Mar 2004 06:15:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5NPK-0000lX-00 for enum@ietf.org; Mon, 22 Mar 2004 06:15:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5NNv-0000cj-00 for enum@ietf.org; Mon, 22 Mar 2004 06:14:24 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B5NN2-0000OU-00 for enum@ietf.org; Mon, 22 Mar 2004 06:13:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Mar 2004 12:18:57 +0100 Message-ID: <06CF906FE3998C4E944213062009F162233C17@oefeg-s02.oefeg.loc> Thread-Topic: New Enumservice NoPSTN? Thread-Index: AcQP/3eys1jgN/8OTae3jUdOsYYxYg== From: "Stastny Richard" To: Cc: "Richard Shockey" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Enum] New Enumservice NoPSTN? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Working currently on the draft for the enum-dip-indicator for the tel: URI, as discussed on the IPTEL-list, and also thinking about the pstn-indicator, as discussed recently on the SIPPING-list, I encoutered the following minor problem. An ENUM client (e.g. in a SIP server) currently works in the following way: If it gets an E.164 number in, it is querying the domain e164.arpa related to this number in the DNS for NAPTR, and if he get a result back (one or more NAPTRs), fine.=20 If there is no domain related to this number in the DNS, there is currently the intrinsic assumption, that the number may exist on the PSTN or at least the PSTN finally knows that the number does not exist. So the call may be routed to the PSTN if the SIP-server is able to do so. For ENUM-only number ranges we have a problem here. ENUM-only number ranges exist only in the DNS. The PSTN is recognizing the number range as ENUM-only, so any call originating on the PSTN is routed to a gateway capable of doing an ENUM query. If such a gateway is not finding an entry for the specific number, he should have a logic built in not to route the call back to the PSTN, but to signal this fact back to the user (e.g. SIT).=20 If the above mentioned SIP-server is querying an ENUM-only number range, finding no entry, routing the call to the PSTN, the call is finally routed to an ENUM-enable gateway by the PSTN and properly treated. So this is a minor problem, but it is not nice to bother the PSTN or even to need it to properly treat a call originating on the Internet. There are two solutions coming to my mind: A. Populate the DNS for this number range with all numbers possible, and enter a proper default NAPTR B: use a wildcard for the whole number range But both solutions raise the question how the NAPTR record finally should look like. One solution could be to use the ENUMservice "ann" (as defined in ETSI TS 102 072), but this service is more intented for end-user information and may be also in addition to other enumservices. Furthermore this enumservice has until know not even been discussed at IETF. Another solution could be to define an enumservice "nopstn", "noentry" or "void". The question here is which URI should be used to keep the syntax? One way could be to use http://.....html and point to a web-page, where the entity responsible for the number range places some text. On the other hand, SIP-servers or any other application querying ENUM could immediately recognize that there is no such number. What is the opinion of the group and are there any additional proposals? Is this the group where this should be discussed and/or in IPTEL or SIPPING? regards Richard Stastny OeFEG +43 664 420 4100 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Mar 22 16:02:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21147 for ; Mon, 22 Mar 2004 16:02:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WYp-0000GA-49 for enum-archive@odin.ietf.org; Mon, 22 Mar 2004 16:02:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ML2EVu000934 for enum-archive@odin.ietf.org; Mon, 22 Mar 2004 16:02:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WYb-0000EV-KY; Mon, 22 Mar 2004 16:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WXf-00008I-TJ for enum@optimus.ietf.org; Mon, 22 Mar 2004 16:01:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20908 for ; Mon, 22 Mar 2004 16:00:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5WXS-0002iw-00 for enum@ietf.org; Mon, 22 Mar 2004 16:00:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5WVF-0002Bs-00 for enum@ietf.org; Mon, 22 Mar 2004 15:58:34 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1B5WTy-0001qB-00 for enum@ietf.org; Mon, 22 Mar 2004 15:57:14 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (neustargw.va.neustar.com [209.173.53.233]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2MKucd25220; Mon, 22 Mar 2004 12:56:39 -0800 Message-Id: <6.0.3.0.2.20040322153019.03abd528@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 22 Mar 2004 15:56:37 -0500 To: "Stastny Richard" , From: Richard Shockey Cc: In-Reply-To: <06CF906FE3998C4E944213062009F162233C17@oefeg-s02.oefeg.loc > References: <06CF906FE3998C4E944213062009F162233C17@oefeg-s02.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,BIZ_TLD autolearn=no version=2.60 Subject: [Enum] Re: New Enumservice NoPSTN? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , A >If it gets an E.164 number in, it is querying the domain e164.arpa >related to this number in the DNS for NAPTR, and if he get a result back >(one or more NAPTRs), fine. its done ... it substitutes the SIP URI in the To: field and proceeds to create a session >If there is no domain related to this number in the DNS, there is >currently the intrinsic assumption, that the number may exist on the >PSTN or at least the PSTN finally knows that the number does not exist. >So the call may be routed to the PSTN if the SIP-server is able to do >so. Well it depends on network topology ..if the 1 hop edge SIP proxy executes a query and gets a 404 that would indicate a default condition of PSTN routing and IMHO the TEL URI needs to be modified to indicate that a ENUM query has been made. >For ENUM-only number ranges we have a problem here. ENUM-only number >ranges exist only in the DNS. You mean E.164 numbers that cannot be routed on the PSTN >The PSTN is recognizing the number range >as ENUM-only, so any call originating on the PSTN is routed to a gateway >capable of doing an ENUM query. If such a gateway is not finding an >entry for the specific number, he should have a logic built in not to >route the call back to the PSTN, but to signal this fact back to the >user (e.g. SIT). OK ..no problem Spell this out not everyone knows what SIT tones means though I have put them on my answering machine to stop predictive dialers... ( the tone generated by the switch when the number is unreachable . usually used in number disconnect situations.) >If the above mentioned SIP-server is querying an ENUM-only number range, >finding no entry, routing the call to the PSTN, the call is finally >routed to an ENUM-enable gateway by the PSTN and properly treated. Well here is where you seem to be losing me . if it is a ENUM only range and the 1st hop proxy gets a 404 .. it insert the dip indicator...then pass to the PSTN.. Unless the 1st hop proxy has knowledge of ENUM number ranges locally and can interpret a 404 as call failure and not attempt to pass the call across. >So this is a minor problem, but it is not nice to bother the PSTN or >even to need it to properly treat a call originating on the Internet. OK I get it .. the PSTN carriers do not want to be bothered by trying to route calls from IP only number ranges ..both situations would create failure ( SIT) but the latter is unecessary. >There are two solutions coming to my mind: > >A. Populate the DNS for this number range with all numbers possible, and >enter a proper default NAPTR Never going to happen ... >B: use a wildcard for the whole number range not going to happen either... >But both solutions raise the question how the NAPTR record finally >should look like. Well >One solution could be to use the ENUMservice "ann" (as defined in ETSI >TS 102 072), but this service is more intented for end-user information >and may be also in addition to other enumservices. Furthermore this >enumservice has until know not even been discussed at IETF. > >Another solution could be to define an enumservice "nopstn", "noentry" >or "void". The question here is which URI should be used to keep the >syntax? I'm still not clear why these error conditions in SIP cannot be dealt with with extensions to the tel URL or why local edge proxy's cannot be made aware of ENUM number ranges in order to prevent necessary PSTN call routing. This is a interesting case in ENUM bahaivor that should be documented ..but I'd rather see decision trees like this one dealt with at the edge and not higher up the network. >One way could be to use http://.....html and point to a web-page, where >the entity responsible for the number range places some text. huh? >On the other hand, SIP-servers or any other application querying ENUM >could immediately recognize that there is no such number. > >What is the opinion of the group and are there any additional proposals? > >Is this the group where this should be discussed and/or in IPTEL or >SIPPING? Well IMHO probably IPTEL but it has relevance here... >regards > >Richard Stastny >OeFEG >+43 664 420 4100 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Mar 22 17:34:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29656 for ; Mon, 22 Mar 2004 17:34:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Xzo-0000DO-PL for enum-archive@odin.ietf.org; Mon, 22 Mar 2004 17:34:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MMYCvF000776 for enum-archive@odin.ietf.org; Mon, 22 Mar 2004 17:34:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Xzc-0000C8-V4; Mon, 22 Mar 2004 17:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5XzL-00007Z-AT for enum@optimus.ietf.org; Mon, 22 Mar 2004 17:33:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29618 for ; Mon, 22 Mar 2004 17:33:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5XzI-0001Je-00 for enum@ietf.org; Mon, 22 Mar 2004 17:33:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5XyL-0001DI-00 for enum@ietf.org; Mon, 22 Mar 2004 17:32:42 -0500 Received: from smtpout-1-1c.secureserver.net ([64.202.165.65]) by ietf-mx with smtp (Exim 4.12) id 1B5XxP-00012g-00 for enum@ietf.org; Mon, 22 Mar 2004 17:31:43 -0500 Received: (qmail 17355 invoked from network); 22 Mar 2004 22:31:24 -0000 Received: from unknown (HELO TIMRUIZ) (192.168.5.250) by smtpout-1-1c.secureserver.net with SMTP; 22 Mar 2004 22:31:24 -0000 From: "Tim Ruiz" To: "'Richard Shockey'" , Date: Mon, 22 Mar 2004 16:31:12 -0600 Message-ID: <04e701c4105d$6202a540$fa05a8c0@TIMRUIZ> 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, Build 10.0.4510 In-Reply-To: <6.0.3.0.2.20040322153019.03abd528@joy.songbird.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Enum] .TEL and ENUM? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Richard, I follow this list with interest. I feel less than qualified to participate much but I've been learning a lot. Recently a set of new sTLD applications were posted publicly by ICANN at: http://www.icann.org/announcements/announcement-19mar04.htm I found the .MOBI and .TEL applications of particular interest, especially the .TEL application from pulver.com: http://www.icann.org/tlds/stld-apps-19mar04/tel-pulver.htm I was wondering if you have had a chance to look at that. It appears to my less qualified eye that it would conflict with ENUM. Where you aware of it? Is my reading of it correct? Tim Ruiz Go Daddy Software, Inc. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 03:03:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10331 for ; Tue, 23 Mar 2004 03:03:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5gsU-0000g8-Rt for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 03:03:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2N83ED9002605 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 03:03:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5gsH-0000fQ-9m; Tue, 23 Mar 2004 03:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5grK-0000de-Mg for enum@optimus.ietf.org; Tue, 23 Mar 2004 03:02:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10293 for ; Tue, 23 Mar 2004 03:01:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5grG-0007Q7-00 for enum@ietf.org; Tue, 23 Mar 2004 03:01:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5gqJ-0007KD-00 for enum@ietf.org; Tue, 23 Mar 2004 03:01:00 -0500 Received: from us.svf.stuba.sk ([147.175.16.9]) by ietf-mx with esmtp (Exim 4.12) id 1B5gpP-00079t-00 for enum@ietf.org; Tue, 23 Mar 2004 03:00:03 -0500 Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.11/8.12.11) with ESMTP id i2N7x7O4061098; Tue, 23 Mar 2004 08:59:08 +0100 (CET) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.11/8.12.11/Submit) id i2N7wq9U061083; Tue, 23 Mar 2004 08:58:52 +0100 (CET) (envelope-from md) Date: Tue, 23 Mar 2004 08:58:52 +0100 From: Marian Durkovic To: Richard Shockey Cc: Stastny Richard , enum@ietf.org, paf@cisco.com Subject: Re: [Enum] Re: New Enumservice NoPSTN? Message-ID: <20040323075852.GA57922@us.svf.stuba.sk> References: <06CF906FE3998C4E944213062009F162233C17@oefeg-s02.oefeg.loc> <6.0.3.0.2.20040322153019.03abd528@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.3.0.2.20040322153019.03abd528@joy.songbird.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > >One solution could be to use the ENUMservice "ann" (as defined in ETSI > >TS 102 072), but this service is more intented for end-user information > >and may be also in addition to other enumservices. Furthermore this > >enumservice has until know not even been discussed at IETF. > > > >Another solution could be to define an enumservice "nopstn", "noentry" > >or "void". The question here is which URI should be used to keep the > >syntax? > > I'm still not clear why these error conditions in SIP cannot be dealt with > with extensions to the tel URL or why local edge proxy's cannot be made > aware of ENUM number ranges in order to prevent necessary PSTN call routing. Well, since ENUM-only ranges are to be expected under several country codes and also globally (like +87810) it's not feasible to put all those ranges statically into _every_ SIP proxy around the globe. Anyway, this problem again rises the question about "smart" wildcards in ENUM. I think it's not possible to populate every unused number under ENUM-only range with some record, since we'll end up with billions of records, and we still don't catch every possible misdialing - users can dial anything (incomplete number, wrong number, too long number etc.): +87810 12 +87810 1115553 or even +87810 1235671253652635172536153267156215367215312527651352167 Instead, we need to look for a solution, which allows the "default route" in ENUM, i.e. how to route all numbers under some prefix not having explicit NAPTR record to this "default" route. In other words, we need "smart" wildcard - i.e. the wildcard which will _not_ depend on presence/absence of other records. This will also be of high benefit for DDI ranges and all the like. With kind regards, M. -------------------------------------------------------------------------- ---- ---- ---- Marian Durkovic network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 524 51 301 ---- ---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail/sip: md@bts.sk ---- ---- ---- -------------------------------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 05:31:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16291 for ; Tue, 23 Mar 2004 05:31:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5jBs-0003il-Cb for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 05:31:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NAVO8E014298 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 05:31:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5jBX-0003h6-Ib; Tue, 23 Mar 2004 05:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5jAd-0003c9-V6 for enum@optimus.ietf.org; Tue, 23 Mar 2004 05:30:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16259 for ; Tue, 23 Mar 2004 05:30:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5jAa-0001Cx-00 for enum@ietf.org; Tue, 23 Mar 2004 05:30:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5j9c-00016m-00 for enum@ietf.org; Tue, 23 Mar 2004 05:29:05 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1B5j8f-0000ts-00 for enum@ietf.org; Tue, 23 Mar 2004 05:28:05 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMSKBQ>; Tue, 23 Mar 2004 10:27:30 -0000 Received: from [127.0.0.1] (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1ZGNFJDF; Tue, 23 Mar 2004 10:27:15 -0000 From: "Conroy, Lawrence (SMTP)" To: Marian Durkovic Cc: Stastny Richard , enum@ietf.org In-Reply-To: <20040323075852.GA57922@us.svf.stuba.sk> References: <06CF906FE3998C4E944213062009F162233C17@oefeg-s02.oefeg.loc> <6.0.3.0.2.20040322153019.03abd528@joy.songbird.com> <20040323075852.GA57922@us.svf.stuba.sk> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Enum] Re: New Enumservice NoPSTN? Date: Tue, 23 Mar 2004 10:27:14 +0000 X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Folks, at the risk of going way off-topic for ENUM (I haven't seen all of the messages quoted ?): Note: before anyone jumps in to complain that wildcards are ALWAYS a bad idea, please spell out for idiots such as myself why it won't work in this situation. (i.e. not that it is difficult or acts in an unexpected way, but exactly what it does that is not what's required here). (i) This comes about due to some implicit assumptions that are outside the protocol. - Specifically, what to do if there is no ENUM domain for a given E.164 number. Most of the time, dumping to the PSTN works, but this *is* an ASSUMPTION and is broken in some cases. The protocol is fine, the assumption may not be. (ii) I don't understand what's so smart about the proposed wildcard at the apex of an "ENUM-only" number range (i.e. in a Tier 1 server). It comes up again and again, but I *had* thought that with a standard wildcard, if there's a delegation for a queried leaf sub-domain (i.e. there *is* an ENUM-only number) then that will get returned, else the wildcard will be returned. The only time that you'll have a problem is if there is ANY intermediary RR under the wildcard (so delegating for a subsidiary block is out, or at least there must be another wildcard "under" that block). So... what's smart about this wildcard? all the best, Lawrence On 23 Mar 2004, at 7:58 am, Marian Durkovic wrote: > Anyway, this problem again rises the question about "smart" wildcards > in > ENUM. I think it's not possible to populate every unused number under > ENUM-only range with some record, since we'll end up with billions of > records, and we still don't catch every possible misdialing - users > can dial anything (incomplete number, wrong number, too long number > etc.): > > +87810 12 > +87810 1115553 or even > +87810 1235671253652635172536153267156215367215312527651352167 > > Instead, we need to look for a solution, which allows the "default > route" > in ENUM, i.e. how to route all numbers under some prefix not having > explicit > NAPTR record to this "default" route. In other words, we need "smart" > wildcard - i.e. the wildcard which will _not_ depend on > presence/absence of > other records. This will also be of high benefit for DDI ranges and all > the like. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 08:08:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24260 for ; Tue, 23 Mar 2004 08:08:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ldZ-0002Kx-Ix for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 08:08:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ND89Tv008982 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 08:08:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ldR-0002Ia-VJ; Tue, 23 Mar 2004 08:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5lcm-00026d-MO for enum@optimus.ietf.org; Tue, 23 Mar 2004 08:07:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24155 for ; Tue, 23 Mar 2004 08:07:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5lcl-0005eu-00 for enum@ietf.org; Tue, 23 Mar 2004 08:07:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5lbw-0005XP-00 for enum@ietf.org; Tue, 23 Mar 2004 08:06:29 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B5lb3-0005JL-00 for enum@ietf.org; Tue, 23 Mar 2004 08:05:33 -0500 Date: Tue, 23 Mar 2004 14:11:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <06CF906FE3998C4E944213062009F162233C21@oefeg-s02.oefeg.loc> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: New Enumservice NoPSTN? Thread-Index: AcQQUQnmfBu73+5KTgGvDIQel9a/AQAg7aNg From: "Stastny Richard" To: "Richard Shockey" , Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Enum] RE: New Enumservice NoPSTN? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Richard Shockey wrote: > >If there is no domain related to this number in the DNS, there is > >currently the intrinsic assumption, that the number may exist on the > >PSTN or at least the PSTN finally knows that the number does not = exist. > >So the call may be routed to the PSTN if the SIP-server is able to do > >so. >=20 > Well it depends on network topology ..if the 1 hop edge SIP proxy = executes > a query and gets a 404 that would indicate a default condition of PSTN > routing and IMHO the TEL URI needs to be modified to indicate that a = ENUM > query has been made. [Richard>] you mean the ;enum-dip-indicator, the SIP proxy could also add the ;pstn indicator. =20 >=20 > >For ENUM-only number ranges we have a problem here. ENUM-only number > >ranges exist only in the DNS. >=20 > You mean E.164 numbers that cannot be routed on the PSTN [Richard>] To be correct, the number can be routed on the PSTN, but it will be routed again to a IP-gateway (the so-called generic gateway) see below, so the correct terminology is:=20 I mean E.164 numbers that cannot be TERMINATED on the PSTN. >=20 > >The PSTN is recognizing the number range > >as ENUM-only, so any call originating on the PSTN is routed to a = gateway > >capable of doing an ENUM query. If such a gateway is not finding an > >entry for the specific number, he should have a logic built in not to > >route the call back to the PSTN, but to signal this fact back to the > >user (e.g. SIT). >=20 > OK ..no problem >=20 > Spell this out not everyone knows what SIT tones means though I have = put > them on my answering machine to stop predictive dialers... ( the tone > generated by the switch when the number is unreachable . usually used = in > number disconnect situations. [Richard>] SIT (Special Information Tone) is generated if a number does = not exist. If the number exists, but is (currently) not available,=20 Trunk Busy is generated. =20 >=20 > >If the above mentioned SIP-server is querying an ENUM-only number = range, > >finding no entry, routing the call to the PSTN, the call is finally > >routed to an ENUM-enable gateway by the PSTN and properly treated. >=20 > Well here is where you seem to be losing me . if it is a ENUM only = range > and the 1st hop proxy gets a 404 .. it insert the dip indicator...then > pass > to the PSTN.. > Unless the 1st hop proxy has knowledge of ENUM number ranges locally = and > can interpret a 404 as call failure and not attempt to pass the call > across. [Richard>] The problem is that there is no local number ranges on the = Internet (see also below) >=20 >=20 > >So this is a minor problem, but it is not nice to bother the PSTN or > >even to need it to properly treat a call originating on the Internet. >=20 > OK I get it .. the PSTN carriers do not want to be bothered by trying = to > route calls from IP only number ranges ..both situations would create > failure ( SIT) but the latter is unecessary. [Richard>] It is even worse: the generic gateway from the PSTN to IP, = where the call is finally routed to needs to know ALL ENUM-only number = ranges worldwide. Because if not, it may drop the call again to the = PSTN, especially if you consider that the gateway is also receiving call calls forced to the gateway, eg with an access code. This is not impossible, = but not elegant and not fool proof, so a more elegant solution is required. >=20 >=20 > >There are two solutions coming to my mind: > > > >A. Populate the DNS for this number range with all numbers possible, = and > >enter a proper default NAPTR >=20 > Never going to happen ... >=20 > >B: use a wildcard for the whole number range >=20 > not going to happen either... [Richard>] Why not? >=20 >=20 > >But both solutions raise the question how the NAPTR record finally > >should look like. >=20 > Well >=20 >=20 > >One solution could be to use the ENUMservice "ann" (as defined in = ETSI > >TS 102 072), but this service is more intented for end-user = information > >and may be also in addition to other enumservices. Furthermore this > >enumservice has until know not even been discussed at IETF. > > > >Another solution could be to define an enumservice "nopstn", = "noentry" > >or "void". The question here is which URI should be used to keep the > >syntax? >=20 > I'm still not clear why these error conditions in SIP cannot be dealt = with > with extensions to the tel URL or why local edge proxy's cannot be = made > aware of ENUM number ranges in order to prevent necessary PSTN call > routing. >=20 > This is a interesting case in ENUM bahaivor that should be documented > ..but > I'd rather see decision trees like this one dealt with at the edge and = not > higher up the network. >=20 >=20 > >One way could be to use http://.....html and point to a web-page, = where > >the entity responsible for the number range places some text. >=20 > huh? [Richard>] You need at least some URI >=20 > >On the other hand, SIP-servers or any other application querying ENUM > >could immediately recognize that there is no such number. > > > >What is the opinion of the group and are there any additional = proposals? > > > >Is this the group where this should be discussed and/or in IPTEL or > >SIPPING? >=20 > Well IMHO probably IPTEL but it has relevance here... >=20 >=20 [Richard>] I also think it should be dicussed here Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 13:33:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16889 for ; Tue, 23 Mar 2004 13:33:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5qiI-0003dM-EX for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 13:33:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NIXMHc013907 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 13:33:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5qhx-0003aG-SY; Tue, 23 Mar 2004 13:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5qhb-0003XH-Kl for enum@optimus.ietf.org; Tue, 23 Mar 2004 13:32:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16746 for ; Tue, 23 Mar 2004 13:32:37 -0500 (EST) From: rich.shockey@neustar.biz Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5qhZ-00007Y-00 for enum@ietf.org; Tue, 23 Mar 2004 13:32:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5qgd-00001K-00 for enum@ietf.org; Tue, 23 Mar 2004 13:31:40 -0500 Received: from adsl-63-207-15-68.dsl.snfc21.pacbell.net ([63.207.15.68] helo=shade) by ietf-mx with smtp (Exim 4.12) id 1B5qet-0007jN-00 for enum@ietf.org; Tue, 23 Mar 2004 13:29:51 -0500 Date: Tue, 23 Mar 2004 10:30:28 -0800 To: enum@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rpxrcccqinfdfhfunhtx" Subject: [Enum] Hey, dude, it's me ^_^ :P Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , ----------rpxrcccqinfdfhfunhtx Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_FUNBAG.GEN in file Info.zip The uncleanable file is deleted. --------------------------------------------------------- ----------rpxrcccqinfdfhfunhtx Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't bite, weah! pass: 27332 ----------rpxrcccqinfdfhfunhtx Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Info.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------rpxrcccqinfdfhfunhtx-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 13:59:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18024 for ; Tue, 23 Mar 2004 13:59:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5r7O-0006A9-BA for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 13:59:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NIxIUM023620 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 13:59:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5r77-00067Z-H4; Tue, 23 Mar 2004 13:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5r6Y-00063B-EF for enum@optimus.ietf.org; Tue, 23 Mar 2004 13:58:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17978 for ; Tue, 23 Mar 2004 13:58:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5r6W-0001sv-00 for enum@ietf.org; Tue, 23 Mar 2004 13:58:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5r5W-0001ng-00 for enum@ietf.org; Tue, 23 Mar 2004 13:57:22 -0500 Received: from gromit.rfc1035.com ([195.54.233.67]) by ietf-mx with esmtp (Exim 4.12) id 1B5r4b-0001hW-00 for enum@ietf.org; Tue, 23 Mar 2004 13:56:25 -0500 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i2NIuFRv010118; Tue, 23 Mar 2004 18:56:16 GMT To: Tim Ruiz cc: Richard Shockey , enum@ietf.org Subject: Re: [Enum] .TEL and ENUM? In-Reply-To: Message from "Tim Ruiz" of "Mon, 22 Mar 2004 16:31:12 CST." <04e701c4105d$6202a540$fa05a8c0@TIMRUIZ> Date: Tue, 23 Mar 2004 18:56:15 +0000 Message-ID: <10117.1080068175@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Tim" == Tim Ruiz writes: Tim> http://www.icann.org/announcements/announcement-19mar04.htm Tim> I found the .MOBI and .TEL applications of particular Tim> interest, especially the .TEL application from pulver.com: Tim> http://www.icann.org/tlds/stld-apps-19mar04/tel-pulver.htm Tim> I was wondering if you have had a chance to look at that. It Tim> appears to my less qualified eye that it would conflict with Tim> ENUM. Is my reading of it correct? Yes. It doesn't conflict with ENUM: the proposal merely copies the ENUM name space under .tel instead of 164.arpa. Therefore it doesn't offer anything new. And IMO, for that reason alone ICANN should reject this application out of hand. If anything, the proposal is worse than e164.arpa because there appear to be none of the necessary safeguards that already apply to the e164.arpa tree. If this TLD was created, then there would be all sorts of conflicts such as confusion with the ENUM tree. [Where is your phone number registered, .tel or .e164.arpa? And if it's both, which one is right?] This is just a re-run of the "golden tree" rationale which has been understood and generally accepted. Other nasties that lurk in this proposed .tel concern national sovereignty. It's up to a government, not Pulver, what gets done to its E.164 resources. Governments and regulators are also likely to be concerned about things like consumer protection, data privacy, slamming, hijacking, competition policy, transparency, etc, etc. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 15:03:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22797 for ; Tue, 23 Mar 2004 15:03:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5s7L-0000TV-HY for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 15:03:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NK3J54001822 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 15:03:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5s74-0000Aa-Q3; Tue, 23 Mar 2004 15:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5s6w-0008TQ-7l for enum@optimus.ietf.org; Tue, 23 Mar 2004 15:02:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22669 for ; Tue, 23 Mar 2004 15:02:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5s6s-0000b4-00 for enum@ietf.org; Tue, 23 Mar 2004 15:02:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5s5b-0000P0-00 for enum@ietf.org; Tue, 23 Mar 2004 15:01:31 -0500 Received: from gromit.rfc1035.com ([195.54.233.67]) by ietf-mx with esmtp (Exim 4.12) id 1B5s4Y-0000Cp-00 for enum@ietf.org; Tue, 23 Mar 2004 15:00:26 -0500 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i2NK0ERv010222; Tue, 23 Mar 2004 20:00:14 GMT To: Marian Durkovic cc: Richard Shockey , Stastny Richard , enum@ietf.org, paf@cisco.com Subject: Re: [Enum] Re: New Enumservice NoPSTN? In-Reply-To: Message from Marian Durkovic of "Tue, 23 Mar 2004 08:58:52 +0100." <20040323075852.GA57922@us.svf.stuba.sk> Date: Tue, 23 Mar 2004 20:00:14 +0000 Message-ID: <10221.1080072014@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Marian" == Marian Durkovic writes: Marian> Anyway, this problem again rises the question about Marian> "smart" wildcards in ENUM. I think it's not possible to Marian> populate every unused number under ENUM-only range with Marian> some record, since we'll end up with billions of records, Marian> and we still don't catch every possible misdialing - users Marian> can dial anything (incomplete number, wrong number, too Marian> long number etc.): Oh please, not yet another salespitch for wildcard RRs! :-( There's absolutely no need to add resource records for non-existent domain names (numbers). [Which is an impossibility in the DNS, but put that to one side.] This is how the DNS works today. And it works just fine. An application is free to lookup whatever.it.likes.e164.arpa. If this name exists, the application presumably gets back some valid NAPTR records and all is good. If the name doesn't exist, the DNS returns an NXDOMAIN. The application can then decide for itself what it should do next. It could apply a default rule such as "route a call for this number to SIP gateway foo" or report an error like "ENUM doesn't recognise this number". ie the rule is in the application where it belongs, not the DNS. As for misdialling, so what? Why should an ENUM lookup for a broken number be expected to work? [For some definition of "work".] Surely, these should fail in essentially the same way as a misdialled or invalid number on the PSTN? Marian> Instead, we need to look for a solution, which allows the Marian> "default route" in ENUM, i.e. how to route all numbers Marian> under some prefix not having explicit NAPTR record to this Marian> "default" route. In other words, we need "smart" wildcard The juxtaposition of "smart" and "wildcard" in the context of DNS is an oxymoron. :-) Have you forgotten the furore when Verisign put a wildcard A record in .com which pointed at their sitefinder website? This broke huge chunks of the internet. Wildcard RRs in e164.arpa are likely to have comparable unpleasant consequences once ENUM systems are widely deployed. Marian> - i.e. the wildcard which will _not_ depend on Marian> presence/absence of other records. This will also be of Marian> high benefit for DDI ranges and all the like. Such a wildcard, if it could be created, would contradict the way the world's name servers and the DNS protocol works today. A wildcard in the DNS is only matched if the name being looked up does not exist as *any* record type. In other words, it depends on the presence or absence of other resource records. That won't change without a rewrite of RFC103[45] and a very long period of migration. Good luck getting that through IETF! BTW, the excellent IAB statement on DNS wildcard RRs should be mandatory reading for anyone thinking about deploying them. It's at: http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 15:29:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25124 for ; Tue, 23 Mar 2004 15:29:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sVl-0000s2-44 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 15:28:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NKSXEE003293 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 15:28:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sVF-0000qD-Do; Tue, 23 Mar 2004 15:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sV0-0000pn-6R for enum@optimus.ietf.org; Tue, 23 Mar 2004 15:27:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25070 for ; Tue, 23 Mar 2004 15:27:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sUy-0002UO-00 for enum@ietf.org; Tue, 23 Mar 2004 15:27:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5sTs-0002RV-00 for enum@ietf.org; Tue, 23 Mar 2004 15:26:37 -0500 Received: from pacdcoavas05.cable.comcast.com ([208.17.33.54]) by ietf-mx with esmtp (Exim 4.12) id 1B5sTN-0002OP-00 for enum@ietf.org; Tue, 23 Mar 2004 15:26:05 -0500 Message-ID: From: "Livingood, Jason" To: "'Jim Reid'" , Tim Ruiz Cc: Richard Shockey , enum@ietf.org Subject: RE: [Enum] .TEL and ENUM? Date: Tue, 23 Mar 2004 15:19:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=NORMAL_HTTP_TO_IP autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , You should check out Jeff Pulver's personal blog on this item today: http://192.246.69.231/jeff/personal/archives/000654.html Jason > >>>>> "Tim" == Tim Ruiz writes: > > Tim> http://www.icann.org/announcements/announcement-19mar04.htm > > Tim> I found the .MOBI and .TEL applications of particular > Tim> interest, especially the .TEL application from pulver.com: > > Tim> http://www.icann.org/tlds/stld-apps-19mar04/tel-pulver.htm > > Tim> I was wondering if you have had a chance to look at that. It > Tim> appears to my less qualified eye that it would conflict with > Tim> ENUM. Is my reading of it correct? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 15:47:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27488 for ; Tue, 23 Mar 2004 15:47:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5smr-0002xw-07 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 15:46:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NKkCBi011393 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 15:46:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5smn-0002x4-LL; Tue, 23 Mar 2004 15:46:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5smY-0002qc-S1 for enum@optimus.ietf.org; Tue, 23 Mar 2004 15:45:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27217 for ; Tue, 23 Mar 2004 15:45:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5smX-0005Cn-00 for enum@ietf.org; Tue, 23 Mar 2004 15:45:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5slG-0004uv-00 for enum@ietf.org; Tue, 23 Mar 2004 15:44:36 -0500 Received: from 66-193-54-209.gen.twtelecom.net ([66.193.54.209] helo=voxeo.com) by ietf-mx with esmtp (Exim 4.12) id 1B5sip-0004RS-00 for enum@ietf.org; Tue, 23 Mar 2004 15:42:03 -0500 Received: from [66.127.83.188] (account rj HELO [192.168.102.10]) by voxeo.com (CommuniGate Pro SMTP 4.1.5) with ESMTP-TLS id 1243703; Tue, 23 Mar 2004 15:36:32 -0500 In-Reply-To: References: <06CF906FE3998C4E944213062009F162233C17@oefeg-s02.oefeg.loc> <6.0.3.0.2.20040322153019.03abd528@joy.songbird.com> <20040323075852.GA57922@us.svf.stuba.sk> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <70AFD349-7D0A-11D8-8CD3-0003938E6664@voxeo.com> Content-Transfer-Encoding: 7bit Cc: Stastny Richard , Marian Durkovic , enum@ietf.org From: RJ Auburn Subject: Re: [Enum] Re: New Enumservice NoPSTN? Date: Tue, 23 Mar 2004 12:41:20 -0800 To: "Conroy, Lawrence (SMTP)" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I would also like to understand a bit more about some of the concerns of using wild card records in enum tree's. Lets use the example where I own a complete range of numbers (lets use +1-555-666-1xxx as an example) and I want everything to end up on my sip server located at sip.voxeo.net. With wild cards this is very easy to do with the following record: 1.6.6.6.5.5.5.1.e164.arpa. NAPTR 0 0 "u" "E2U+sip" "!^(.*)$!sip:\1@sip.voxeo.net!" . Without wild card records I would end up having to have 1000 records and they must each be a maintained and updated individually. For large companies that may want all their calls routed to a single proxy server I can see this being a major pain to keep updated. What do folks think of this? As a service provider that manages ten's of thousands of phone numbers I really would like to have something that does not require me to maintain that many records. Is there another way to do this that works better? If so I would love to hear about it. RJ --- RJ Auburn CTO, Voxeo Corporation tel:+1-407-418-1800 On Mar 23, 2004, at 02:27, Conroy, Lawrence (SMTP) wrote: > Hi Folks, > at the risk of going way off-topic for ENUM (I haven't seen all of > the messages quoted ?): > > Note: before anyone jumps in to complain that wildcards are ALWAYS a > bad idea, > please spell out for idiots such as myself why it won't work in > this situation. > (i.e. not that it is difficult or acts in an unexpected way, but > exactly what > it does that is not what's required here). > > (i) This comes about due to some implicit assumptions that are > outside the protocol. > - Specifically, what to do if there is no ENUM domain for a given > E.164 number. > Most of the time, dumping to the PSTN works, but this *is* an > ASSUMPTION and > is broken in some cases. The protocol is fine, the assumption may > not be. > (ii) I don't understand what's so smart about the proposed wildcard at > the apex of > an "ENUM-only" number range (i.e. in a Tier 1 server). > It comes up again and again, but I *had* thought that with a > standard wildcard, > if there's a delegation for a queried leaf sub-domain (i.e. there > *is* an ENUM-only > number) then that will get returned, else the wildcard will be > returned. > The only time that you'll have a problem is if there is ANY > intermediary RR under > the wildcard (so delegating for a subsidiary block is out, or at > least there must > be another wildcard "under" that block). So... what's smart about > this wildcard? > > all the best, > Lawrence > > On 23 Mar 2004, at 7:58 am, Marian Durkovic wrote: > >> Anyway, this problem again rises the question about "smart" wildcards >> in >> ENUM. I think it's not possible to populate every unused number under >> ENUM-only range with some record, since we'll end up with billions of >> records, and we still don't catch every possible misdialing - users >> can dial anything (incomplete number, wrong number, too long number >> etc.): >> >> +87810 12 >> +87810 1115553 or even >> +87810 1235671253652635172536153267156215367215312527651352167 >> >> Instead, we need to look for a solution, which allows the "default >> route" >> in ENUM, i.e. how to route all numbers under some prefix not having >> explicit >> NAPTR record to this "default" route. In other words, we need "smart" >> wildcard - i.e. the wildcard which will _not_ depend on >> presence/absence of >> other records. This will also be of high benefit for DDI ranges and >> all >> the like. > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 15:56:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28456 for ; Tue, 23 Mar 2004 15:56:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5swR-0004uj-Jn for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 15:56:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NKu7Mn018835 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 15:56:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5swP-0004tM-GC; Tue, 23 Mar 2004 15:56:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5st5-0004Lu-KU for enum@optimus.ietf.org; Tue, 23 Mar 2004 15:52:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28312 for ; Tue, 23 Mar 2004 15:52:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5st4-0006Lj-00 for enum@ietf.org; Tue, 23 Mar 2004 15:52:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ssR-0006Ht-00 for enum@ietf.org; Tue, 23 Mar 2004 15:51:59 -0500 Received: from gromit.rfc1035.com ([195.54.233.67]) by ietf-mx with esmtp (Exim 4.12) id 1B5sri-0006BO-00 for enum@ietf.org; Tue, 23 Mar 2004 15:51:14 -0500 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i2NKpBRv010338; Tue, 23 Mar 2004 20:51:11 GMT To: "Livingood, Jason" cc: Tim Ruiz , Richard Shockey , enum@ietf.org Subject: Re: [Enum] .TEL and ENUM? In-Reply-To: Message from "Livingood, Jason" of "Tue, 23 Mar 2004 15:19:37 EST." Date: Tue, 23 Mar 2004 20:51:11 +0000 Message-ID: <10337.1080075071@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,NORMAL_HTTP_TO_IP autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Jason" == Livingood, Jason writes: Jason> You should check out Jeff Pulver's personal blog on this Jason> item today: Jason> http://192.246.69.231/jeff/personal/archives/000654.html Thanks for the URL. However this says nothing new. It confirms he either doesn't know or care about the many difficult issues of sovereignty and national interests that apply to the use of E.164 numbers. I don't know whether this makes him a madman or a genius. :-) BTW his reference to "multiple implementations of ENUM" is a nonsense. When E.164 numbers are mapped into domain names, this can only be called ENUM if the protocol that's used complies with RFC2916(bis). So if the mapping is done under e164.arpa, it's ENUM. If it's somewhere else, it can't be ENUM. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 16:32:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02869 for ; Tue, 23 Mar 2004 16:32:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tVN-0000Jj-JL for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 16:32:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NLWDE5001218 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 16:32:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tVB-0000Iw-4A; Tue, 23 Mar 2004 16:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tUP-0000Fv-Jv for enum@optimus.ietf.org; Tue, 23 Mar 2004 16:31:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02631 for ; Tue, 23 Mar 2004 16:31:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5tUN-0004kp-00 for enum@ietf.org; Tue, 23 Mar 2004 16:31:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5tSw-0004UQ-00 for enum@ietf.org; Tue, 23 Mar 2004 16:29:43 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1B5tRR-000451-00 for enum@ietf.org; Tue, 23 Mar 2004 16:28:09 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (neustargw.va.neustar.com [209.173.53.233]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2NLRNd18909; Tue, 23 Mar 2004 13:27:24 -0800 Message-Id: <6.0.3.0.2.20040323160639.03d1dec0@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 23 Mar 2004 16:26:56 -0500 To: Jim Reid , "Livingood, Jason" From: Richard Shockey Subject: Re: [Enum] .TEL and ENUM? Cc: Tim Ruiz , enum@ietf.org In-Reply-To: <10337.1080075071@gromit.rfc1035.com> References: <10337.1080075071@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,BIZ_TLD,NORMAL_HTTP_TO_IP autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 03:51 PM 3/23/2004, Jim Reid wrote: > >>>>> "Jason" == Livingood, Jason writes: > > Jason> You should check out Jeff Pulver's personal blog on this > Jason> item today: > Jason> http://192.246.69.231/jeff/personal/archives/000654.html > >Thanks for the URL. However this says nothing new. It confirms he >either doesn't know or care about the many difficult issues of >sovereignty and national interests that apply to the use of E.164 >numbers. I don't know whether this makes him a madman or a genius. :-) > >BTW his reference to "multiple implementations of ENUM" is a nonsense. >When E.164 numbers are mapped into domain names, this can only be >called ENUM if the protocol that's used complies with RFC2916(bis). So >if the mapping is done under e164.arpa, it's ENUM. If it's somewhere >else, it can't be ENUM. Well that maybe stretching the semantics a bit .. there are folks that want to use the technology of ENUM for all sorts of private telephony signalling purposes and many of them are operators and the tree of resolution is not and will not be in e164.arpa. The discussions over Operator ENUM have been going on for years NetNumber et al have had services available and that's just great. Its just I don't think a private product offering needs an endorsement by ICANN. 2916bis is fundamentally about trust and preserving the integrity of the ITU E.164 numbering plan and the administrative rights and privileges accorded nation states under that plan. It might be worth noting that the E.164 plan helped make the global PSTN possible. Trust in both the E.164 plan and the admistrative procedures surrounding the implementation of RFC 2916bis is essential if we want to roll out global VoIP and other services. Trust in a global system that all service providers, world wide, can rely upon. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 18:05:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09419 for ; Tue, 23 Mar 2004 18:05:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uxN-00040r-KC for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 18:05:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NN5DKE015399 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 18:05:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uxB-0003wl-CW; Tue, 23 Mar 2004 18:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uwk-0003pL-Hy for enum@optimus.ietf.org; Tue, 23 Mar 2004 18:04:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09248 for ; Tue, 23 Mar 2004 18:04:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uwh-0006ih-00 for enum@ietf.org; Tue, 23 Mar 2004 18:04:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uvn-0006ep-00 for enum@ietf.org; Tue, 23 Mar 2004 18:03:35 -0500 Received: from smtp.nildram.co.uk ([195.112.4.54]) by ietf-mx with esmtp (Exim 4.12) id 1B5uuq-0006al-00 for enum@ietf.org; Tue, 23 Mar 2004 18:02:36 -0500 Received: from hourglass (unknown [81.6.214.202]) by smtp.nildram.co.uk (Postfix) with SMTP id A5ABF29F799; Tue, 23 Mar 2004 23:00:30 +0000 (GMT) From: "Christian de Larrinaga" To: "Jim Reid" , "Livingood, Jason" Cc: "Tim Ruiz" , "Richard Shockey" , Subject: RE: [Enum] .TEL and ENUM? Date: Tue, 23 Mar 2004 22:59:31 -0000 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <10337.1080075071@gromit.rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=NORMAL_HTTP_TO_IP autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit well surely e164 numbers is just one numbering plan implementable using ENUM rather than the only one? Christian > >>>>> "Jason" == Livingood, Jason > writes: > > Jason> You should check out Jeff Pulver's personal blog on this > Jason> item today: > Jason> http://192.246.69.231/jeff/personal/archives/000654.html > > Thanks for the URL. However this says nothing new. It confirms he > either doesn't know or care about the many difficult issues of > sovereignty and national interests that apply to the use of E.164 > numbers. I don't know whether this makes him a madman or a genius. :-) > > BTW his reference to "multiple implementations of ENUM" is a nonsense. > When E.164 numbers are mapped into domain names, this can only be > called ENUM if the protocol that's used complies with RFC2916(bis). So > if the mapping is done under e164.arpa, it's ENUM. If it's somewhere > else, it can't be ENUM. > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 18:34:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12021 for ; Tue, 23 Mar 2004 18:34:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vPH-00037e-AI for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 18:34:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NNY3f4011960 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 18:34:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vPF-00036V-T0; Tue, 23 Mar 2004 18:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vOs-00035B-Q9 for enum@optimus.ietf.org; Tue, 23 Mar 2004 18:33:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12001 for ; Tue, 23 Mar 2004 18:33:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5vOp-0001F4-00 for enum@ietf.org; Tue, 23 Mar 2004 18:33:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5vNu-0001BQ-00 for enum@ietf.org; Tue, 23 Mar 2004 18:32:39 -0500 Received: from mit.xs4all.nl ([213.84.95.205] helo=raid.dns-hosting.info) by ietf-mx with esmtp (Exim 4.12) id 1B5vNg-000188-00 for enum@ietf.org; Tue, 23 Mar 2004 18:32:25 -0500 Received: from [192.168.0.4] ([192.168.0.4]) by raid.dns-hosting.info (8.12.9/8.12.9/Debian-3) with ESMTP id i2NNWA2o021518; Wed, 24 Mar 2004 00:32:10 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4D3A781F-7D22-11D8-9463-000393A1C8BA@ag-projects.com> Content-Transfer-Encoding: 7bit Cc: "Jim Reid" , "Livingood, Jason" , "Tim Ruiz" , "Richard Shockey" , From: Adrian Georgescu Subject: Re: [Enum] .TEL and ENUM? Date: Wed, 24 Mar 2004 00:32:08 +0100 To: "Christian de Larrinaga" X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,NORMAL_HTTP_TO_IP autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Indeed, ENUM may work under any TLD. But creating a paralel root to e164.arpa. is not the answer for the current issues we have with it. Adrian On Mar 23, 2004, at 11:59 PM, Christian de Larrinaga wrote: > well surely e164 numbers is just one numbering plan implementable > using ENUM > rather than the only one? > > Christian > >>>>>>> "Jason" == Livingood, Jason >> writes: >> >> Jason> You should check out Jeff Pulver's personal blog on this >> Jason> item today: >> Jason> http://192.246.69.231/jeff/personal/archives/000654.html >> >> Thanks for the URL. However this says nothing new. It confirms he >> either doesn't know or care about the many difficult issues of >> sovereignty and national interests that apply to the use of E.164 >> numbers. I don't know whether this makes him a madman or a genius. :-) >> >> BTW his reference to "multiple implementations of ENUM" is a nonsense. >> When E.164 numbers are mapped into domain names, this can only be >> called ENUM if the protocol that's used complies with RFC2916(bis). So >> if the mapping is done under e164.arpa, it's ENUM. If it's somewhere >> else, it can't be ENUM. >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum >> > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 18:34:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12048 for ; Tue, 23 Mar 2004 18:34:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vPH-000382-BN for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 18:34:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NNY3Zk011961 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 18:34:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vPF-000369-Cu; Tue, 23 Mar 2004 18:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vOo-000354-Bk for enum@optimus.ietf.org; Tue, 23 Mar 2004 18:33:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11948 for ; Tue, 23 Mar 2004 18:33:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5vOl-0001ET-00 for enum@ietf.org; Tue, 23 Mar 2004 18:33:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5vNm-0001A9-00 for enum@ietf.org; Tue, 23 Mar 2004 18:32:31 -0500 Received: from [62.254.208.140] (helo=hedwig.Westbrooke.bango.net) by ietf-mx with esmtp (Exim 4.12) id 1B5vMn-000146-00 for enum@ietf.org; Tue, 23 Mar 2004 18:31:30 -0500 Received: from RAYANDERSON.westbrooke (host213-120-116-62.in-addr.btopenworld.com [213.120.116.62]) by hedwig.Westbrooke.bango.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HD88Z1MG; Tue, 23 Mar 2004 23:30:58 -0000 Message-Id: <6.0.1.1.2.20040323232635.01e84da8@smtp.bango.net> X-Sender: ray@smtp.bango.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 23 Mar 2004 23:30:55 +0000 To: Richard Shockey , Jim Reid , "Livingood, Jason" From: Ray Anderson Subject: Re: [Enum] .TEL and ENUM? Cc: Tim Ruiz , enum@ietf.org In-Reply-To: <6.0.3.0.2.20040323160639.03d1dec0@joy.songbird.com> References: <10337.1080075071@gromit.rfc1035.com> <6.0.3.0.2.20040323160639.03d1dec0@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Its the "difficult stuff" around the technology that takes the time and requires the massive investment. Thats why the "official" tree is the one that will get support and which will have great value. I'm sure there will be some oddball private namespaces like .tel might be able to become, but in the scheme of things they will be niche and not worth much attention. UMTS 's big value is in the "U" - not in the protocols or spectrum. Thats what made it hard, and makes it last for tens of years. Just as the "M" in GSM made it the place to be. For what its worth, Bango is totally committed to using ENUM to determine the real "home/owner" for phone numbers because its the best chance we have. At 21:26 23/03/2004, Richard Shockey wrote: It might be worth noting that the E.164 plan helped make the global PSTN possible. Trust in both the E.164 plan and the admistrative procedures surrounding the implementation of RFC 2916bis is essential if we want to roll out global VoIP and other services. Trust in a global system that all service providers, world wide, can rely upon. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 19:22:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14068 for ; Tue, 23 Mar 2004 19:22:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5w9q-0007Zb-Ab for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 19:22:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O0MAXm029082 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 19:22:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5w9h-0007Wf-Fm; Tue, 23 Mar 2004 19:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5w9Y-0007Vq-2A for enum@optimus.ietf.org; Tue, 23 Mar 2004 19:21:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14020 for ; Tue, 23 Mar 2004 19:21:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5w9W-0005bE-00 for enum@ietf.org; Tue, 23 Mar 2004 19:21:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5w8m-0005WB-00 for enum@ietf.org; Tue, 23 Mar 2004 19:21:04 -0500 Received: from gromit.rfc1035.com ([195.54.233.67]) by ietf-mx with esmtp (Exim 4.12) id 1B5w7r-0005Oy-00 for enum@ietf.org; Tue, 23 Mar 2004 19:20:07 -0500 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i2O0JuRv011185; Wed, 24 Mar 2004 00:19:56 GMT To: Christian de Larrinaga cc: Tim Ruiz , Richard Shockey , enum@ietf.org Subject: Re: [Enum] .TEL and ENUM? In-Reply-To: Message from "Christian de Larrinaga" of "Tue, 23 Mar 2004 22:59:31 GMT." Date: Wed, 24 Mar 2004 00:19:56 +0000 Message-ID: <11184.1080087596@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Christian" == Christian de Larrinaga writes: Christian> well surely e164 numbers is just one numbering plan Christian> implementable using ENUM rather than the only one? ENUM is defined in RFC2916(bis). This maps E.164 numbers into domain names under e164.arpa. E.164 numbers could be, and indeed are, mapped into domain names anywhere in the DNS. And, in principle, any numbering scheme could be mapped into domain names under e164.arpa. But neither of these should be called ENUM. They might be ENUM-like, but they're not ENUM as it's understood by RFC2916(bis). What's also in this RFC is a role for ITU in the delegation process for country codes. This implicitly safeguards national interests and the sovereignty issues surrounding national resources: a country's E.164 numbers. AFAIK no other "ENUM-like" mapping scheme for E.164 numbers provides those essential safeguards. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 19:35:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14575 for ; Tue, 23 Mar 2004 19:35:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wMJ-00006a-A0 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 19:35:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O0Z3Ho000392 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 19:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wMG-00004u-1i; Tue, 23 Mar 2004 19:35:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wH8-00088O-S5 for enum@optimus.ietf.org; Tue, 23 Mar 2004 19:29:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14397 for ; Tue, 23 Mar 2004 19:29:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wH7-0006J6-00 for enum@ietf.org; Tue, 23 Mar 2004 19:29:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wGI-0006Cc-00 for enum@ietf.org; Tue, 23 Mar 2004 19:28:51 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1B5wF8-000634-00 for enum@ietf.org; Tue, 23 Mar 2004 19:27:39 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (h-68-165-240-38.mclnva23.covad.net [68.165.240.38]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2O0Pwd01356; Tue, 23 Mar 2004 16:25:58 -0800 Message-Id: <6.0.3.0.2.20040323191158.038ee790@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 23 Mar 2004 19:14:09 -0500 To: "Christian de Larrinaga" , "Jim Reid" , "Livingood, Jason" From: Richard Shockey Subject: RE: [Enum] .TEL and ENUM? Cc: "Tim Ruiz" , In-Reply-To: References: <10337.1080075071@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,BIZ_TLD,NORMAL_HTTP_TO_IP autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 05:59 PM 3/23/2004, Christian de Larrinaga wrote: >well surely e164 numbers is just one numbering plan implementable using ENUM >rather than the only one? Well funny you mention other numbering plans .. if you look a the global plan for the next generation barcode technology.. aka EPCglobal using RFID the methodology for resolving the EPC code into the Object Name Service looks a lot like ENUM ( for some odd reason :-)) but again in a different domain. http://www.epcglobalinc.org/standards_technology/Secure/v1.0/WD-ons-1.0-20030930.pdf I'd go so far to say that enterprise private dialing plans can be easily implemented within their own domains using the DNS and the technology outlined in 2916 and for any number of reasons makes a great deal of sense. Great way to force interoperability among diverse SIP based IP PBX's. >Christian > > > >>>>> "Jason" == Livingood, Jason > > writes: > > > > Jason> You should check out Jeff Pulver's personal blog on this > > Jason> item today: > > Jason> http://192.246.69.231/jeff/personal/archives/000654.html > > > > Thanks for the URL. However this says nothing new. It confirms he > > either doesn't know or care about the many difficult issues of > > sovereignty and national interests that apply to the use of E.164 > > numbers. I don't know whether this makes him a madman or a genius. :-) > > > > BTW his reference to "multiple implementations of ENUM" is a nonsense. > > When E.164 numbers are mapped into domain names, this can only be > > called ENUM if the protocol that's used complies with RFC2916(bis). So > > if the mapping is done under e164.arpa, it's ENUM. If it's somewhere > > else, it can't be ENUM. > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 20:23:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14576 for ; Tue, 23 Mar 2004 19:35:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wMJ-00006X-9o for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 19:35:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O0Z3ls000391 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 19:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wME-0008W8-Q1; Tue, 23 Mar 2004 19:34:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wGU-00083b-35 for enum@optimus.ietf.org; Tue, 23 Mar 2004 19:29:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14375 for ; Tue, 23 Mar 2004 19:29:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wGS-0006E7-00 for enum@ietf.org; Tue, 23 Mar 2004 19:29:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wFM-000691-00 for enum@ietf.org; Tue, 23 Mar 2004 19:27:53 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1B5wEW-0005yO-00 for enum@ietf.org; Tue, 23 Mar 2004 19:27:01 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (h-68-165-240-38.mclnva23.covad.net [68.165.240.38]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2O0Q0d01361; Tue, 23 Mar 2004 16:26:00 -0800 Message-Id: <6.0.3.0.2.20040323191440.03e72ec0@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 23 Mar 2004 19:17:09 -0500 To: Ray Anderson , Jim Reid , "Livingood, Jason" From: Richard Shockey Subject: Re: [Enum] .TEL and ENUM? Cc: Tim Ruiz , enum@ietf.org In-Reply-To: <6.0.1.1.2.20040323232635.01e84da8@smtp.bango.net> References: <10337.1080075071@gromit.rfc1035.com> <6.0.3.0.2.20040323160639.03d1dec0@joy.songbird.com> <6.0.1.1.2.20040323232635.01e84da8@smtp.bango.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,BIZ_TLD autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 06:30 PM 3/23/2004, Ray Anderson wrote: >Its the "difficult stuff" around the technology that takes the time and >requires the massive investment. > >Thats why the "official" tree is the one that will get support and which >will have great value. I'm sure there will be some oddball private >namespaces like .tel might be able to become, but in the scheme of things >they will be niche and not worth much attention. We've noticed alternative roots havent gone very far either ..including that New.NET thing or whatever it was called. >UMTS 's big value is in the "U" - not in the protocols or spectrum. Thats >what made it hard, and >makes it last for tens of years. Just as the "M" in GSM made it the >place to be. > >For what its worth, Bango is totally committed to using ENUM to determine >the real "home/owner" for phone numbers because its the best chance we have. well said and thanks for the support some of us are working on 1. as fast as we can.. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 23:29:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24395 for ; Tue, 23 Mar 2004 23:29:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B600x-0003Np-9K for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 23:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O4TFMf012987 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 23:29:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B600j-0003Mv-DV; Tue, 23 Mar 2004 23:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B600c-0003Mk-JL for enum@optimus.ietf.org; Tue, 23 Mar 2004 23:28:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24368 for ; Tue, 23 Mar 2004 23:28:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B600Z-0005L6-00 for enum@ietf.org; Tue, 23 Mar 2004 23:28:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5zzT-0005FE-00 for enum@ietf.org; Tue, 23 Mar 2004 23:27:43 -0500 Received: from granger.mail.mindspring.net ([207.69.200.148]) by ietf-mx with esmtp (Exim 4.12) id 1B5zyY-0005A9-00 for enum@ietf.org; Tue, 23 Mar 2004 23:26:46 -0500 Received: from 1cust31.tnt36.dfw9.da.uu.net ([67.234.81.31] helo=ix.netcom.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1B5zyI-0005nG-00; Tue, 23 Mar 2004 23:26:30 -0500 Message-ID: <4061284E.BE24A349@ix.netcom.com> Date: Tue, 23 Mar 2004 22:18:55 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Jim Reid CC: Marian Durkovic , Richard Shockey , Stastny Richard , enum@ietf.org, paf@cisco.com Subject: Re: [Enum] Re: New Enumservice NoPSTN? References: <10221.1080072014@gromit.rfc1035.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jim and all, Sitefinder didn't break anything. Wildcard entries for DNS are widely desired and utilized. Haralds take is not broadly shared despite the IAB's endorsement. The Wildcard argument raged several times before on other forum's fora. The gospel according to Harald/IAB is only one book in the ongoing development of the DNS Bible... Jim Reid wrote: > >>>>> "Marian" == Marian Durkovic writes: > > Marian> Anyway, this problem again rises the question about > Marian> "smart" wildcards in ENUM. I think it's not possible to > Marian> populate every unused number under ENUM-only range with > Marian> some record, since we'll end up with billions of records, > Marian> and we still don't catch every possible misdialing - users > Marian> can dial anything (incomplete number, wrong number, too > Marian> long number etc.): > > Oh please, not yet another salespitch for wildcard RRs! :-( > > There's absolutely no need to add resource records for non-existent > domain names (numbers). [Which is an impossibility in the DNS, but put > that to one side.] This is how the DNS works today. And it works just > fine. > > An application is free to lookup whatever.it.likes.e164.arpa. If this > name exists, the application presumably gets back some valid NAPTR > records and all is good. If the name doesn't exist, the DNS returns an > NXDOMAIN. The application can then decide for itself what it should do > next. It could apply a default rule such as "route a call for this > number to SIP gateway foo" or report an error like "ENUM doesn't > recognise this number". ie the rule is in the application where it > belongs, not the DNS. > > As for misdialling, so what? Why should an ENUM lookup for a broken > number be expected to work? [For some definition of "work".] Surely, > these should fail in essentially the same way as a misdialled or > invalid number on the PSTN? > > Marian> Instead, we need to look for a solution, which allows the > Marian> "default route" in ENUM, i.e. how to route all numbers > Marian> under some prefix not having explicit NAPTR record to this > Marian> "default" route. In other words, we need "smart" wildcard > > The juxtaposition of "smart" and "wildcard" in the context of DNS is > an oxymoron. :-) Have you forgotten the furore when Verisign put a > wildcard A record in .com which pointed at their sitefinder website? > This broke huge chunks of the internet. Wildcard RRs in e164.arpa are > likely to have comparable unpleasant consequences once ENUM systems > are widely deployed. > > Marian> - i.e. the wildcard which will _not_ depend on > Marian> presence/absence of other records. This will also be of > Marian> high benefit for DDI ranges and all the like. > > Such a wildcard, if it could be created, would contradict the way the > world's name servers and the DNS protocol works today. A wildcard in > the DNS is only matched if the name being looked up does not exist as > *any* record type. In other words, it depends on the presence or > absence of other resource records. That won't change without a rewrite > of RFC103[45] and a very long period of migration. Good luck getting > that through IETF! > > BTW, the excellent IAB statement on DNS wildcard RRs should be > mandatory reading for anyone thinking about deploying them. It's at: > > http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 23:39:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24789 for ; Tue, 23 Mar 2004 23:39:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B60AS-00046q-GA for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 23:39:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O4d4VW015789 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 23:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B60AQ-00046G-Q3; Tue, 23 Mar 2004 23:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B607V-0003iO-Cj for enum@optimus.ietf.org; Tue, 23 Mar 2004 23:36:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24682 for ; Tue, 23 Mar 2004 23:35:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B607T-0005zC-00 for enum@ietf.org; Tue, 23 Mar 2004 23:35:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B606j-0005tT-00 for enum@ietf.org; Tue, 23 Mar 2004 23:35:16 -0500 Received: from granger.mail.mindspring.net ([207.69.200.148]) by ietf-mx with esmtp (Exim 4.12) id 1B6054-0005j8-00 for enum@ietf.org; Tue, 23 Mar 2004 23:33:30 -0500 Received: from 1cust31.tnt36.dfw9.da.uu.net ([67.234.81.31] helo=ix.netcom.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1B604y-0005Nx-00; Tue, 23 Mar 2004 23:33:25 -0500 Message-ID: <406129EE.BF5BC00B@ix.netcom.com> Date: Tue, 23 Mar 2004 22:25:51 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: RJ Auburn CC: enum@ietf.org, "Harald@alvestrand.no" Subject: Re: [Enum] Re: New Enumservice NoPSTN? References: <06CF906FE3998C4E944213062009F162233C17@oefeg-s02.oefeg.loc> <6.0.3.0.2.20040322153019.03abd528@joy.songbird.com> <20040323075852.GA57922@us.svf.stuba.sk> <70AFD349-7D0A-11D8-8CD3-0003938E6664@voxeo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit RJ and all, RJ Auburn wrote: > I would also like to understand a bit more about some of the concerns > of using wild card records in enum tree's. > > Lets use the example where I own a complete range of numbers (lets use > +1-555-666-1xxx as an example) and I want everything to end up on my > sip server located at sip.voxeo.net. With wild cards this is very easy > to do with the following record: > > 1.6.6.6.5.5.5.1.e164.arpa. NAPTR 0 0 "u" "E2U+sip" > "!^(.*)$!sip:\1@sip.voxeo.net!" . Good approach... > > > Without wild card records I would end up having to have 1000 records > and they must each be a maintained and updated individually. For large > companies that may want all their calls routed to a single proxy server > I can see this being a major pain to keep updated. Not only a pain but also prone to error making or other errors that would likely go unnoticed or denied for some time before corrected.. > > > What do folks think of this? As a service provider that manages ten's > of thousands of phone numbers I really would like to have something > that does not require me to maintain that many records. > > Is there another way to do this that works better? If so I would love > to hear about it. I would also... Ask Harald! >;) And good luck with whatever answer he MAY provide... > > > RJ > > --- > RJ Auburn > CTO, Voxeo Corporation > tel:+1-407-418-1800 > > On Mar 23, 2004, at 02:27, Conroy, Lawrence (SMTP) wrote: > > > Hi Folks, > > at the risk of going way off-topic for ENUM (I haven't seen all of > > the messages quoted ?): > > > > Note: before anyone jumps in to complain that wildcards are ALWAYS a > > bad idea, > > please spell out for idiots such as myself why it won't work in > > this situation. > > (i.e. not that it is difficult or acts in an unexpected way, but > > exactly what > > it does that is not what's required here). > > > > (i) This comes about due to some implicit assumptions that are > > outside the protocol. > > - Specifically, what to do if there is no ENUM domain for a given > > E.164 number. > > Most of the time, dumping to the PSTN works, but this *is* an > > ASSUMPTION and > > is broken in some cases. The protocol is fine, the assumption may > > not be. > > (ii) I don't understand what's so smart about the proposed wildcard at > > the apex of > > an "ENUM-only" number range (i.e. in a Tier 1 server). > > It comes up again and again, but I *had* thought that with a > > standard wildcard, > > if there's a delegation for a queried leaf sub-domain (i.e. there > > *is* an ENUM-only > > number) then that will get returned, else the wildcard will be > > returned. > > The only time that you'll have a problem is if there is ANY > > intermediary RR under > > the wildcard (so delegating for a subsidiary block is out, or at > > least there must > > be another wildcard "under" that block). So... what's smart about > > this wildcard? > > > > all the best, > > Lawrence > > > > On 23 Mar 2004, at 7:58 am, Marian Durkovic wrote: > > > >> Anyway, this problem again rises the question about "smart" wildcards > >> in > >> ENUM. I think it's not possible to populate every unused number under > >> ENUM-only range with some record, since we'll end up with billions of > >> records, and we still don't catch every possible misdialing - users > >> can dial anything (incomplete number, wrong number, too long number > >> etc.): > >> > >> +87810 12 > >> +87810 1115553 or even > >> +87810 1235671253652635172536153267156215367215312527651352167 > >> > >> Instead, we need to look for a solution, which allows the "default > >> route" > >> in ENUM, i.e. how to route all numbers under some prefix not having > >> explicit > >> NAPTR record to this "default" route. In other words, we need "smart" > >> wildcard - i.e. the wildcard which will _not_ depend on > >> presence/absence of > >> other records. This will also be of high benefit for DDI ranges and > >> all > >> the like. > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 23:40:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24833 for ; Tue, 23 Mar 2004 23:40:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B60BN-0004FE-Mr for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 23:40:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O4e1W8016307 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 23:40:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B60BN-0004Ed-CF; Tue, 23 Mar 2004 23:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B60BL-0004Dn-CN for enum@optimus.ietf.org; Tue, 23 Mar 2004 23:39:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24825 for ; Tue, 23 Mar 2004 23:39:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B60BJ-0006Oo-00 for enum@ietf.org; Tue, 23 Mar 2004 23:39:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B60AO-0006Hz-00 for enum@ietf.org; Tue, 23 Mar 2004 23:39:00 -0500 Received: from granger.mail.mindspring.net ([207.69.200.148]) by ietf-mx with esmtp (Exim 4.12) id 1B609f-0006Bj-00 for enum@ietf.org; Tue, 23 Mar 2004 23:38:15 -0500 Received: from 1cust31.tnt36.dfw9.da.uu.net ([67.234.81.31] helo=ix.netcom.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1B609e-0006hM-00; Tue, 23 Mar 2004 23:38:14 -0500 Message-ID: <40612B0E.E040E3D4@ix.netcom.com> Date: Tue, 23 Mar 2004 22:30:39 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Jim Reid CC: "Livingood, Jason" , Tim Ruiz , Richard Shockey , enum@ietf.org Subject: Re: [Enum] .TEL and ENUM? References: <10337.1080075071@gromit.rfc1035.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NORMAL_HTTP_TO_IP autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jim and all, Jim Reid wrote: > >>>>> "Jason" == Livingood, Jason writes: > > Jason> You should check out Jeff Pulver's personal blog on this > Jason> item today: > Jason> http://192.246.69.231/jeff/personal/archives/000654.html > > Thanks for the URL. However this says nothing new. It confirms he > either doesn't know or care about the many difficult issues of > sovereignty and national interests that apply to the use of E.164 > numbers. I don't know whether this makes him a madman or a genius. :-) I would have to agree here... > > > BTW his reference to "multiple implementations of ENUM" is a nonsense. > When E.164 numbers are mapped into domain names, this can only be > called ENUM if the protocol that's used complies with RFC2916(bis). So > if the mapping is done under e164.arpa, it's ENUM. If it's somewhere > else, it can't be ENUM. Of course RFC2916(bis) is flawed as I some time ago pointed out, as it is too restrictive in general.. But I have already gone over all that some time ago. Hence leaving your last statement here invalid.. Therefor many different and "multiple implementations of ENUM" will be done and will have various levels of success or failure... > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 23 23:47:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25136 for ; Tue, 23 Mar 2004 23:47:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B60IB-0004je-Ge for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 23:47:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O4l3ol018196 for enum-archive@odin.ietf.org; Tue, 23 Mar 2004 23:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B60I9-0004j9-Gk; Tue, 23 Mar 2004 23:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B60Hv-0004ip-V3 for enum@optimus.ietf.org; Tue, 23 Mar 2004 23:46:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25124 for ; Tue, 23 Mar 2004 23:46:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B60Ht-00072G-00 for enum@ietf.org; Tue, 23 Mar 2004 23:46:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B60Gz-0006yF-00 for enum@ietf.org; Tue, 23 Mar 2004 23:45:50 -0500 Received: from maynard.mail.mindspring.net ([207.69.200.243]) by ietf-mx with esmtp (Exim 4.12) id 1B60GK-0006u4-00 for enum@ietf.org; Tue, 23 Mar 2004 23:45:08 -0500 Received: from 1cust31.tnt36.dfw9.da.uu.net ([67.234.81.31] helo=ix.netcom.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1B60GC-00012Q-00; Tue, 23 Mar 2004 23:45:01 -0500 Message-ID: <40612CA5.442C4A4C@ix.netcom.com> Date: Tue, 23 Mar 2004 22:37:26 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Richard Shockey CC: Jim Reid , "Livingood, Jason" , Tim Ruiz , enum@ietf.org Subject: Re: [Enum] .TEL and ENUM? References: <10337.1080075071@gromit.rfc1035.com> <6.0.3.0.2.20040323160639.03d1dec0@joy.songbird.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,BIZ_TLD,NORMAL_HTTP_TO_IP autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Richard and all, Richard Shockey wrote: > At 03:51 PM 3/23/2004, Jim Reid wrote: > > > >>>>> "Jason" == Livingood, Jason writes: > > > > Jason> You should check out Jeff Pulver's personal blog on this > > Jason> item today: > > Jason> http://192.246.69.231/jeff/personal/archives/000654.html > > > >Thanks for the URL. However this says nothing new. It confirms he > >either doesn't know or care about the many difficult issues of > >sovereignty and national interests that apply to the use of E.164 > >numbers. I don't know whether this makes him a madman or a genius. :-) > > > >BTW his reference to "multiple implementations of ENUM" is a nonsense. > >When E.164 numbers are mapped into domain names, this can only be > >called ENUM if the protocol that's used complies with RFC2916(bis). So > >if the mapping is done under e164.arpa, it's ENUM. If it's somewhere > >else, it can't be ENUM. > > Well that maybe stretching the semantics a bit .. there are folks that > want to use the technology of ENUM for all sorts of private telephony > signalling purposes and many of them are operators and the tree of > resolution is not and will not be in e164.arpa. The discussions over > Operator ENUM have been going on for years NetNumber et al have had > services available and that's just great. Its just I don't think a private > product offering needs an endorsement by ICANN. Any endorsement from ICANN at this juncture is circumspect at best... > > > 2916bis is fundamentally about trust and preserving the integrity of the > ITU E.164 numbering plan and the administrative rights and privileges > accorded nation states under that plan. I seriously question this as have many of the nation states governments have begun to question it as well... > > > It might be worth noting that the E.164 plan helped make the global PSTN > possible. Yes helped. > Trust in both the E.164 plan and the admistrative procedures > surrounding the implementation of RFC 2916bis is essential if we want to > roll out global VoIP and other services. RFC 2916bis is not essential and in some instances or for some countries not advisable... > Trust in a global system that all > service providers, world wide, can rely upon. Good point if such a system is ever developed... > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 24 01:40:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00941 for ; Wed, 24 Mar 2004 01:40:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B623b-0003Gv-N5 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 01:40:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O6e7lM012568 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 01:40:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B623V-0003GG-Od; Wed, 24 Mar 2004 01:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B622b-0003E8-Gv for enum@optimus.ietf.org; Wed, 24 Mar 2004 01:39:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00891 for ; Wed, 24 Mar 2004 01:39:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B622Y-0001Rj-00 for enum@ietf.org; Wed, 24 Mar 2004 01:39:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B621j-0001Ge-00 for enum@ietf.org; Wed, 24 Mar 2004 01:38:12 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B621E-00012K-00 for enum@ietf.org; Wed, 24 Mar 2004 01:37:40 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 23 Mar 2004 22:44:08 +0000 Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2O6absk029687; Wed, 24 Mar 2004 07:36:37 +0100 (MET) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 24 Mar 2004 07:37:08 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Mar 2004 07:37:08 +0100 In-Reply-To: <10337.1080075071@gromit.rfc1035.com> References: <10337.1080075071@gromit.rfc1035.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Tim Ruiz , "Livingood, Jason" , Richard Shockey , enum@ietf.org From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] .TEL and ENUM? Date: Wed, 24 Mar 2004 07:37:07 +0100 To: Jim Reid X-Mailer: Apple Mail (2.613) X-OriginalArrivalTime: 24 Mar 2004 06:37:08.0175 (UTC) FILETIME=[6DEE35F0:01C4116A] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 23, 2004, at 21:51, Jim Reid wrote: > When E.164 numbers are mapped into domain names, this can only be > called ENUM if the protocol that's used complies with RFC2916(bis). So > if the mapping is done under e164.arpa, it's ENUM. If it's somewhere > else, it can't be ENUM. Yes, but...even if we are not that precise on the use of the word ENUM (I think you are right Jim, but...) we have problems. The issue is that the calling party have to know, given only the E.164 number is known, what domain name to add to the domain part which is created by the numbers. If I happen to have the E.164 for Jeff, how do I know whether I should look up things in tel and not in e164.arpa and vice versa? The whole idea with ENUM builds on the idea that the domain name is one and only one, except in closed areas (like inside an enterprise) where everyone agrees on use of something else. That is though as Jim says not ENUM, but "ENUM-like service" or "service using ENUM technology" or whatever. So, IF tel is created, I only see a "war" in the market where either e164.arpa or tel "wins". There can only be one... And you all know what _I_ want. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 24 04:48:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09743 for ; Wed, 24 Mar 2004 04:48:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64zW-00070w-To for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 04:48:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O9m6mg026959 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 04:48:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64zR-0006zn-BK; Wed, 24 Mar 2004 04:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64yV-0006wc-2O for enum@optimus.ietf.org; Wed, 24 Mar 2004 04:47:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09618 for ; Wed, 24 Mar 2004 04:47:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B64yS-0003vC-00 for enum@ietf.org; Wed, 24 Mar 2004 04:47:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B64xS-0003fp-00 for enum@ietf.org; Wed, 24 Mar 2004 04:45:58 -0500 Received: from us.svf.stuba.sk ([147.175.16.9]) by ietf-mx with esmtp (Exim 4.12) id 1B64wU-0003HC-00 for enum@ietf.org; Wed, 24 Mar 2004 04:44:58 -0500 Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.11/8.12.11) with ESMTP id i2O9iBfx046644 for ; Wed, 24 Mar 2004 10:44:11 +0100 (CET) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.11/8.12.11/Submit) id i2O9i6O6046641 for enum@ietf.org; Wed, 24 Mar 2004 10:44:06 +0100 (CET) (envelope-from md) Date: Wed, 24 Mar 2004 10:44:06 +0100 From: Marian Durkovic To: enum@ietf.org Subject: Re: [Enum] Re: New Enumservice NoPSTN? Message-ID: <20040324094406.GA43709@us.svf.stuba.sk> References: <06CF906FE3998C4E944213062009F162233C17@oefeg-s02.oefeg.loc> <6.0.3.0.2.20040322153019.03abd528@joy.songbird.com> <20040323075852.GA57922@us.svf.stuba.sk> <70AFD349-7D0A-11D8-8CD3-0003938E6664@voxeo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70AFD349-7D0A-11D8-8CD3-0003938E6664@voxeo.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 12:41:20PM -0800, RJ Auburn wrote: > > I would also like to understand a bit more about some of the concerns > of using wild card records in enum tree's. The basic problem is that wildcard records work fine _only_ in case there's no other record present in the zone. You can't do something like this 1.1.1.1 IN NAPTR ...... * IN NAPTR ...... because the 1.1.1.1 record blocks also anything.1.1.1, anything.1.1 and anything.1 The result is, that query for 2.2.2.1 returns NXDOMAIN and not the wildcard as you would perhaps expect. See the section 4.3.3 of RFC1034 for details. The other problem mentioned here was that wildcards match anything, which is not always desired, however this could be easily avoided by using smart regexpr field - for example in our DDI ranges we now use a modified regexpr syntax: $ORIGIN 6.9.2.7.5.2.1.2.4.e164.arpa. * IN NAPTR 100 10 "u" "E2U+sip" "!^\\+421257296(...)$!sip:2\\1@stuba.sk!" . and this regexpr only matches _exactly_ 3 digits of PBX extension - so any misdialed numbers with incorrect legth are disallowed. So - if you want to use wildcards: 1) don't place anything else in the zone 2) formulate the regexpr precisely in order to exactly match your needs. Also note, that the solution for use of wildcards in DNS SEC is not (yet?) known. > What do folks think of this? As a service provider that manages ten's > of thousands of phone numbers I really would like to have something > that does not require me to maintain that many records. I fully share your view and that's why we're using wildcards here. With kind regards, M. -------------------------------------------------------------------------- ---- ---- ---- Marian Durkovic network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 524 51 301 ---- ---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail/sip: md@bts.sk ---- ---- ---- -------------------------------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 24 05:03:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10534 for ; Wed, 24 Mar 2004 05:03:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B65E3-0008KO-3u for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 05:03:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OA37uT031954 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 05:03:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B65Dy-0008Iy-Je; Wed, 24 Mar 2004 05:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B65D6-0008GR-6W for enum@optimus.ietf.org; Wed, 24 Mar 2004 05:02:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10453 for ; Wed, 24 Mar 2004 05:02:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B65D3-0007K1-00 for enum@ietf.org; Wed, 24 Mar 2004 05:02:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B65C8-00077S-00 for enum@ietf.org; Wed, 24 Mar 2004 05:01:08 -0500 Received: from smtp.nildram.co.uk ([195.112.4.54]) by ietf-mx with esmtp (Exim 4.12) id 1B65BO-0006vU-00 for enum@ietf.org; Wed, 24 Mar 2004 05:00:23 -0500 Received: from hourglass (unknown [81.6.214.202]) by smtp.nildram.co.uk (Postfix) with SMTP id 9053725EFB5; Wed, 24 Mar 2004 09:58:59 +0000 (GMT) From: "Christian de Larrinaga" To: =?us-ascii?Q?Patrik_Faltstrom?= , "Jim Reid" Cc: "Tim Ruiz" , "Livingood, Jason" , "Richard Shockey" , Subject: RE: [Enum] .TEL and ENUM? Date: Wed, 24 Mar 2004 09:57:59 -0000 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.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Patrik Faltstrom wrote 24 March 2004 06:37 > The issue is that the calling party have to know, given only the E.164 > number is known, what domain name to add to the domain part which is > created by the numbers. > > If I happen to have the E.164 for Jeff, how do I know whether I should > look up things in tel and not in e164.arpa and vice versa? > If I've read what Jeff proposes right he is suggesting is that .tel will be used only by operators (so users of those operators will just dial or push to talk or whatever) and the .tel service will default to e164.arpa if the record for that number exists in e164.arpa. (I haven't seen a technical appraisal that sets out how they propose to achieve this) Christian _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 24 05:06:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10754 for ; Wed, 24 Mar 2004 05:06:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B65Gv-0000Jq-06 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 05:06:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OA64Cs001178 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 05:06:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B65Gt-0000Hy-9P; Wed, 24 Mar 2004 05:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B65G6-00009x-7P for enum@optimus.ietf.org; Wed, 24 Mar 2004 05:05:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10653 for ; Wed, 24 Mar 2004 05:05:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B65G3-0000FL-00 for enum@ietf.org; Wed, 24 Mar 2004 05:05:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B65F4-0007nh-00 for enum@ietf.org; Wed, 24 Mar 2004 05:04:11 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B65E6-0007Ml-00 for enum@ietf.org; Wed, 24 Mar 2004 05:03:10 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 24 Mar 2004 02:09:42 +0000 Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2OA28sk028045; Wed, 24 Mar 2004 11:02:08 +0100 (MET) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 24 Mar 2004 11:01:00 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Mar 2004 11:02:38 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <610A54A7-7D7A-11D8-9B8B-000A95B2B926@cisco.com> Content-Transfer-Encoding: 7bit Cc: , "Jim Reid" , "Livingood, Jason" , "Tim Ruiz" , "Richard Shockey" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] .TEL and ENUM? Date: Wed, 24 Mar 2004 11:02:37 +0100 To: "Christian de Larrinaga" X-Mailer: Apple Mail (2.613) X-OriginalArrivalTime: 24 Mar 2004 10:02:38.0989 (UTC) FILETIME=[23AB1BD0:01C41187] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 24, 2004, at 10:57, Christian de Larrinaga wrote: >> Patrik Faltstrom wrote 24 March 2004 06:37 > >> The issue is that the calling party have to know, given only the E.164 >> number is known, what domain name to add to the domain part which is >> created by the numbers. >> >> If I happen to have the E.164 for Jeff, how do I know whether I should >> look up things in tel and not in e164.arpa and vice versa? >> > > If I've read what Jeff proposes right he is suggesting is that .tel > will be > used only by operators (so users of those operators will just dial or > push > to talk or whatever) and the .tel service will default to e164.arpa if > the > record for that number exists in e164.arpa. (I haven't seen a technical > appraisal that sets out how they propose to achieve this) They can already to that in tel.pulver.com. A new TLD is not needed. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 24 05:58:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13135 for ; Wed, 24 Mar 2004 05:58:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B665I-0004gH-7q for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 05:58:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OAw8vX017988 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 05:58:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B665B-0004fm-2q; Wed, 24 Mar 2004 05:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B664S-0004fA-S0 for enum@optimus.ietf.org; Wed, 24 Mar 2004 05:57:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13071 for ; Wed, 24 Mar 2004 05:57:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B664P-0003vv-00 for enum@ietf.org; Wed, 24 Mar 2004 05:57:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B663U-0003j6-00 for enum@ietf.org; Wed, 24 Mar 2004 05:56:18 -0500 Received: from us.svf.stuba.sk ([147.175.16.9]) by ietf-mx with esmtp (Exim 4.12) id 1B662x-0003UD-00 for enum@ietf.org; Wed, 24 Mar 2004 05:55:43 -0500 Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.11/8.12.11) with ESMTP id i2OAtBGO053618; Wed, 24 Mar 2004 11:55:12 +0100 (CET) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.11/8.12.11/Submit) id i2OAsutf053585; Wed, 24 Mar 2004 11:54:56 +0100 (CET) (envelope-from md) Date: Wed, 24 Mar 2004 11:54:56 +0100 From: Marian Durkovic To: enum@ietf.org Cc: Richard.Stastny@oefeg.at Subject: Re: [Enum] Re: New Enumservice NoPSTN? Message-ID: <20040324105456.GA46670@us.svf.stuba.sk> References: <20040323075852.GA57922@us.svf.stuba.sk> <10221.1080072014@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10221.1080072014@gromit.rfc1035.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 08:00:14PM +0000, Jim Reid wrote: > >>>>> "Marian" == Marian Durkovic writes: > > Marian> Anyway, this problem again rises the question about > Marian> "smart" wildcards in ENUM. I think it's not possible to > Marian> populate every unused number under ENUM-only range with > Marian> some record, since we'll end up with billions of records, > Marian> and we still don't catch every possible misdialing - users > Marian> can dial anything (incomplete number, wrong number, too > Marian> long number etc.): > > Oh please, not yet another salespitch for wildcard RRs! :-( > > There's absolutely no need to add resource records for non-existent > domain names (numbers). Well, as Richard pointed out, there probably _is_ a need to do that - in case you want to influence the default behaviour encoded in applications. For ENUM-only range, there's no routing information in the PSTN, and the only usable info is in the ENUM tree. If application applies the default behaviour of routing all NXDOMAINs into PSTN, and PSTN is instructed to route ENUM-only ranges back to some IP gateway, you 1) unnecessarily bother PSTN and 2) you might easily create a loop. What Richard is looking for is the method how to tell the aplication "please _never_ use PSTN in case that NAPTR for the exact number does not exist". > Such a wildcard, if it could be created, would contradict the way the > world's name servers and the DNS protocol works today. A wildcard in > the DNS is only matched if the name being looked up does not exist as > *any* record type. In other words, it depends on the presence or > absence of other resource records. That won't change without a rewrite > of RFC103[45] and a very long period of migration. Good luck getting > that through IETF! I don't think there's any need to redefine the RFC103[45]. The "default route" behaviour might probably be also achieved by some other means, like another record in the zone, another flags in NAPTR or another infrastructure ENUM zone. For example, the following approach might work: Fictive ENUM-only zone: +421 700 ... $ORIGIN 0.0.7.1.2.4.e164.arpa. * IN NAPTR 10 10 "d" -> would be the default record for the +421 700 ... IN NAPTR 10 10 "e" -> would be the redirector for exact records pointing to other DNS zone e.g. 700.mydomain.org or perhaps even E.0.0.7.1.2.4.e164.arpa. Then you can disable PSTN fallback or set other options in the default record and proceed with normal ENUM rules in the exact tree. As mentioned before, this will be of high benefit also for DDI ranges, since here you can set the default record to use the VoIP gateway attached to PBX and list only exceptions in the exact tree. With kind regards, M. -------------------------------------------------------------------------- ---- ---- ---- Marian Durkovic network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 524 51 301 ---- ---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail/sip: md@bts.sk ---- ---- ---- -------------------------------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 24 06:10:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13712 for ; Wed, 24 Mar 2004 06:10:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66Gp-0006OK-TE for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 06:10:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OBA35T024545 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 06:10:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66Gn-0006NW-R4; Wed, 24 Mar 2004 06:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66G3-0006Gw-Dg for enum@optimus.ietf.org; Wed, 24 Mar 2004 06:09:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13639 for ; Wed, 24 Mar 2004 06:09:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B66Fz-0006aI-00 for enum@ietf.org; Wed, 24 Mar 2004 06:09:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B66F7-0006OM-00 for enum@ietf.org; Wed, 24 Mar 2004 06:08:18 -0500 Received: from smtp.nildram.co.uk ([195.112.4.54]) by ietf-mx with esmtp (Exim 4.12) id 1B66EY-0006Ax-00 for enum@ietf.org; Wed, 24 Mar 2004 06:07:42 -0500 Received: from hourglass (unknown [81.6.214.202]) by smtp.nildram.co.uk (Postfix) with SMTP id 1A9F92772ED; Wed, 24 Mar 2004 11:07:38 +0000 (GMT) From: "Christian de Larrinaga" To: =?us-ascii?Q?Patrik_Faltstrom?= Cc: , "Jim Reid" , "Livingood, Jason" , "Tim Ruiz" , "Richard Shockey" Subject: RE: [Enum] .TEL and ENUM? Date: Wed, 24 Mar 2004 11:06:37 -0000 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.2911.0) In-Reply-To: <610A54A7-7D7A-11D8-9B8B-000A95B2B926@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > From: Patrik Faltstrom [mailto:paf@cisco.com] > Sent: 24 March 2004 10:03 > > > They can already to that in tel.pulver.com. A new TLD is not needed. > > paf > Yes that is exactly what I suggested to Jeff :-). I am not a part of Jeff's bid and so not an apologist for him but I think there is an interesting inference here that is worth exploring. First a big IF IF Pulver's .tel idea will reliably defer first to the official e164 root (where it exists) AND is private ENUM (or ENUM like!) for operator use only THEN we can ask the question Is it better to have an appraised and openly available service for operators only that is approved and under the authority of ICANN communities than leave the space completely wild to just any.enumlike.com as is the situation today? If so then applying for an SLD begins to look public spirited! As only by applying for an SLD at ICANN can one achieve that level of public oversight over an ENUM (like!) application by operators that defers reliably to the delegated national authorities. Christian _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 24 06:20:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14353 for ; Wed, 24 Mar 2004 06:20:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66QV-0007JJ-Mq for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 06:20:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OBK3ef028047 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 06:20:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66QT-0007Hw-AP; Wed, 24 Mar 2004 06:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66Pe-0007GT-E7 for enum@optimus.ietf.org; Wed, 24 Mar 2004 06:19:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14231 for ; Wed, 24 Mar 2004 06:19:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B66Pa-0000yR-00 for enum@ietf.org; Wed, 24 Mar 2004 06:19:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B66Oi-0000kS-00 for enum@ietf.org; Wed, 24 Mar 2004 06:18:13 -0500 Received: from gromit.rfc1035.com ([195.54.233.67]) by ietf-mx with esmtp (Exim 4.12) id 1B66Np-0000Ua-00 for enum@ietf.org; Wed, 24 Mar 2004 06:17:17 -0500 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i2OBFRRv011906; Wed, 24 Mar 2004 11:15:27 GMT To: Christian de Larrinaga cc: =?us-ascii?Q?Patrik_Faltstrom?= , Tim Ruiz , Richard Shockey , enum@ietf.org Subject: Re: [Enum] .TEL and ENUM? In-Reply-To: Message from "Christian de Larrinaga" of "Wed, 24 Mar 2004 09:57:59 GMT." Date: Wed, 24 Mar 2004 11:15:27 +0000 Message-ID: <11905.1080126927@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Christian" == Christian de Larrinaga writes: Christian> If I've read what Jeff proposes right he is suggesting Christian> is that .tel will be used only by operators (so users Christian> of those operators will just dial or push to talk or Christian> whatever) and the .tel service will default to Christian> e164.arpa if the record for that number exists in Christian> e164.arpa. This may be true, but it's pointless and irrelevant. It's not a justification for a new TLD. If operators want to put phone numbers into some mutually agreed part of the DNS, they can do that already. [Some will have doing this for a while.] All they need to do is agree where the tree goes in the DNS and make sure it's not public. A telco might need to lookup my unlisted number to route calls to me. But that data must not be in the public DNS for obvious reasons. If telcos need to decide on a mutually agreed domain name for this, they can do this through various industry bodies like ETSI or ITU. It doesn't need a new TLD. Or any other domain name for that matter. That's why we have e164.arpa. Oh and if Jeff is saying e164.arpa will be preferred over .tel entries, what's the point of ever populating .tel? This would be as stupid as creating a .kom TLD and then saying this only gets used if the name isn't already in .com. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 24 06:53:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16363 for ; Wed, 24 Mar 2004 06:53:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66wU-0001UA-S4 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 06:53:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OBr6t5005681 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 06:53:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66wP-0001Sx-Cs; Wed, 24 Mar 2004 06:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66vZ-0001S7-7n for enum@optimus.ietf.org; Wed, 24 Mar 2004 06:52:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16264 for ; Wed, 24 Mar 2004 06:52:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B66vV-0000X7-00 for enum@ietf.org; Wed, 24 Mar 2004 06:52:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B66ua-0000KG-00 for enum@ietf.org; Wed, 24 Mar 2004 06:51:08 -0500 Received: from bartok.sidn.nl ([193.176.144.164]) by ietf-mx with esmtp (Exim 4.12) id 1B66tc-0007jH-00 for enum@ietf.org; Wed, 24 Mar 2004 06:50:08 -0500 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.11/8.12.11) with ESMTP id i2OBnbFH032127 for ; Wed, 24 Mar 2004 12:49:38 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200403241149.i2OBnbFH032127@bartok.sidn.nl> To: enum@ietf.org Subject: Re: [Enum] .TEL and ENUM? In-reply-to: Your message of Wed, 24 Mar 2004 11:02:37 +0100. <610A54A7-7D7A-11D8-9B8B-000A95B2B926@cisco.com> Date: Wed, 24 Mar 2004 12:49:37 +0100 From: Jaap Akkerhuis X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , They can already to that in tel.pulver.com. A new TLD is not needed. Apart from that, note that the other .tel bid excludes ENUM-style use. If I recall correctly, with the previous bunch of new TLDs, ICANN decided that if there were multiple bids for the same name, the parties should make a combined bid. They refused to choose. (Or maybe this was just the position of some board members). Something like that might happen again. Note that the comment periode start the 1st of April (no joke). It might be better to comment to ICANN directly then on this list. jaap _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 24 06:56:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16487 for ; Wed, 24 Mar 2004 06:56:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66zL-0001pm-O6 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 06:56:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OBu30U007044 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 06:56:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66zL-0001ox-9l; Wed, 24 Mar 2004 06:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66yf-0001ed-KM for enum@optimus.ietf.org; Wed, 24 Mar 2004 06:55:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16462 for ; Wed, 24 Mar 2004 06:55:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B66yb-0001Do-00 for enum@ietf.org; Wed, 24 Mar 2004 06:55:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B66xp-00011Y-00 for enum@ietf.org; Wed, 24 Mar 2004 06:54:30 -0500 Received: from gromit.rfc1035.com ([195.54.233.67]) by ietf-mx with esmtp (Exim 4.12) id 1B66xD-0000nc-00 for enum@ietf.org; Wed, 24 Mar 2004 06:53:52 -0500 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i2OBriRv011954; Wed, 24 Mar 2004 11:53:44 GMT To: Christian de Larrinaga cc: =?us-ascii?Q?Patrik_Faltstrom?= , enum@ietf.org, Tim Ruiz , Richard Shockey Subject: Re: [Enum] .TEL and ENUM? In-Reply-To: Message from "Christian de Larrinaga" of "Wed, 24 Mar 2004 11:06:37 GMT." Date: Wed, 24 Mar 2004 11:53:44 +0000 Message-ID: <11952.1080129224@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Christian" == Christian de Larrinaga writes: Christian> Is it better to have an appraised and openly available Christian> service for operators only that is approved and under Christian> the authority of ICANN communities than leave the space Christian> completely wild to just any.enumlike.com as is the Christian> situation today? This question doesn't follow from your hypotheticals. There is no role for ICANN in ENUM. End of story. All ICANN have to do is oversee a single consistent name space in the DNS which provides a platform for ENUM and many other things. If telcos want to have a private name space for whatever purpose they like, that is up to them. Many enterprises do this already: internal root servers on the corporate intranet. The telco operators can get together and decide that name space for themselves, just like the 3G/GSM people have done with the bogus .gprs TLD. An ICANN-endorsed TLD isn't needed. The telcos could arrange an industry standard for operator ENUM though something like an ITU recommendation or an ETSI standard. [ETSI is working on such a standard.] No doubt there are other fora where internal telco conventions and standards get agreed. Dragging ICANN into this arena may well turn out to be spectacularly counter-productive. Imagine how say China will react if ICANN approves .tel and Jeff starts entering Chinese E.164 numbers there without the approval of the Chinese authorities. Repeat this for any other country of your choosing. For bonus points, pick a country that's very sensitive about the perception that the internet and ICANN is under the control of the US government. I fail to see how Jeff's .tel differs from any.enumlike.com, even if .tel did exist with ICANN's blessing. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 24 09:05:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22594 for ; Wed, 24 Mar 2004 09:05:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B690K-00060L-DR for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 09:05:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OE5CEl023044 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 09:05:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6909-0005yc-FE; Wed, 24 Mar 2004 09:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B68zN-0005wy-GZ for enum@optimus.ietf.org; Wed, 24 Mar 2004 09:04:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22497 for ; Wed, 24 Mar 2004 09:04:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B68zM-0000hV-00 for enum@ietf.org; Wed, 24 Mar 2004 09:04:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B68yP-0000QW-00 for enum@ietf.org; Wed, 24 Mar 2004 09:03:13 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1B68xM-0007jx-00 for enum@ietf.org; Wed, 24 Mar 2004 09:02:08 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (h-68-165-240-38.mclnva23.covad.net [68.165.240.38]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2OE1Pd27533; Wed, 24 Mar 2004 06:01:25 -0800 Message-Id: <6.0.3.0.2.20040324085946.03a99ec0@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 24 Mar 2004 09:00:27 -0500 To: Jaap Akkerhuis , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] .TEL and ENUM? In-Reply-To: <200403241149.i2OBnbFH032127@bartok.sidn.nl> References: <200403241149.i2OBnbFH032127@bartok.sidn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,BIZ_TLD autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 06:49 AM 3/24/2004, Jaap Akkerhuis wrote: > They can already to that in tel.pulver.com. A new TLD is not > needed. > >Apart from that, note that the other .tel bid excludes ENUM-style >use. > >If I recall correctly, with the previous bunch of new TLDs, ICANN >decided that if there were multiple bids for the same name, the >parties should make a combined bid. They refused to choose. (Or >maybe this was just the position of some board members). Something >like that might happen again. > >Note that the comment periode start the 1st of April (no joke). It >might be better to comment to ICANN directly then on this list. Thank you Japp ... a excellent suggestion to all. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 24 18:35:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29944 for ; Wed, 24 Mar 2004 18:35:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Hu2-0001mp-7W for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 18:35:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ONZIcM006863 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 18:35:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Htl-0001lo-D9; Wed, 24 Mar 2004 18:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Hsx-0001jc-FE for enum@optimus.ietf.org; Wed, 24 Mar 2004 18:34:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29841 for ; Wed, 24 Mar 2004 18:34:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Hsu-0003zj-00 for enum@ietf.org; Wed, 24 Mar 2004 18:34:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Hs5-0003rO-00 for enum@ietf.org; Wed, 24 Mar 2004 18:33:18 -0500 Received: from blount.mail.mindspring.net ([207.69.200.226]) by ietf-mx with esmtp (Exim 4.12) id 1B6Hr0-0003gS-00 for enum@ietf.org; Wed, 24 Mar 2004 18:32:10 -0500 Received: from 1cust137.tnt36.dfw9.da.uu.net ([67.234.81.137] helo=ix.netcom.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1B6Hqp-0000M5-00; Wed, 24 Mar 2004 18:31:59 -0500 Message-ID: <406234C1.51623D52@ix.netcom.com> Date: Wed, 24 Mar 2004 17:24:21 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Jim Reid CC: Christian de Larrinaga , Patrik Faltstrom , Tim Ruiz , Richard Shockey , enum@ietf.org Subject: Re: [Enum] .TEL and ENUM? References: <11905.1080126927@gromit.rfc1035.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jim and all, I agree there is no good reason for .TEL or for that matter a .xxx TLD. However there is perhaps a desire for these TLD's. Given that there such a desire, not allowing for their inclusion/creation based on "Good reason" may not be enough... Jim Reid wrote: > >>>>> "Christian" == Christian de Larrinaga writes: > > Christian> If I've read what Jeff proposes right he is suggesting > Christian> is that .tel will be used only by operators (so users > Christian> of those operators will just dial or push to talk or > Christian> whatever) and the .tel service will default to > Christian> e164.arpa if the record for that number exists in > Christian> e164.arpa. > > This may be true, but it's pointless and irrelevant. It's not a > justification for a new TLD. If operators want to put phone numbers > into some mutually agreed part of the DNS, they can do that > already. [Some will have doing this for a while.] All they need to do > is agree where the tree goes in the DNS and make sure it's not > public. A telco might need to lookup my unlisted number to route calls > to me. But that data must not be in the public DNS for obvious > reasons. > > If telcos need to decide on a mutually agreed domain name for this, > they can do this through various industry bodies like ETSI or ITU. > It doesn't need a new TLD. Or any other domain name for that matter. > That's why we have e164.arpa. > > Oh and if Jeff is saying e164.arpa will be preferred over .tel > entries, what's the point of ever populating .tel? This would be as > stupid as creating a .kom TLD and then saying this only gets used if > the name isn't already in .com. > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 24 18:48:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00782 for ; Wed, 24 Mar 2004 18:48:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6I6Q-00032i-86 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 18:48:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ONm6A2011695 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 18:48:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6I6L-0002xF-Ae; Wed, 24 Mar 2004 18:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6I61-0002w2-8p for enum@optimus.ietf.org; Wed, 24 Mar 2004 18:47:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00663 for ; Wed, 24 Mar 2004 18:47:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6I5y-0004sA-00 for enum@ietf.org; Wed, 24 Mar 2004 18:47:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6I56-0004oJ-00 for enum@ietf.org; Wed, 24 Mar 2004 18:46:44 -0500 Received: from blount.mail.mindspring.net ([207.69.200.226]) by ietf-mx with esmtp (Exim 4.12) id 1B6I4P-0004kJ-00 for enum@ietf.org; Wed, 24 Mar 2004 18:46:01 -0500 Received: from 1cust137.tnt36.dfw9.da.uu.net ([67.234.81.137] helo=ix.netcom.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1B6I4M-0001Ox-00; Wed, 24 Mar 2004 18:45:58 -0500 Message-ID: <4062380D.EB52A464@ix.netcom.com> Date: Wed, 24 Mar 2004 17:38:23 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Jaap Akkerhuis CC: enum@ietf.org, icann board address , baker@icann.org Subject: Re: [Enum] .TEL and ENUM? References: <200403241149.i2OBnbFH032127@bartok.sidn.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jaap and all, Commenting to ICANN directly might help but I doubt it.. The two bids for .TEL are two different views of the confidence in the direction the IETF has taken with ENUM, admitted or not... Jaap Akkerhuis wrote: > They can already to that in tel.pulver.com. A new TLD is not > needed. > > Apart from that, note that the other .tel bid excludes ENUM-style > use. > > If I recall correctly, with the previous bunch of new TLDs, ICANN > decided that if there were multiple bids for the same name, the > parties should make a combined bid. They refused to choose. (Or > maybe this was just the position of some board members). Something > like that might happen again. > > Note that the comment periode start the 1st of April (no joke). It > might be better to comment to ICANN directly then on this list. > > jaap > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 24 22:28:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10382 for ; Wed, 24 Mar 2004 22:28:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6LXU-0007G2-6x for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 22:28:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P3SG2m027883 for enum-archive@odin.ietf.org; Wed, 24 Mar 2004 22:28:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6LXE-0007F9-Me; Wed, 24 Mar 2004 22:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6LWp-0007EM-GT for enum@optimus.ietf.org; Wed, 24 Mar 2004 22:27:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10344 for ; Wed, 24 Mar 2004 22:27:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6LWm-0006Ui-00 for enum@ietf.org; Wed, 24 Mar 2004 22:27:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6LVn-0006RJ-00 for enum@ietf.org; Wed, 24 Mar 2004 22:26:31 -0500 Received: from bgslc11.burtongroup.com ([63.99.125.13]) by ietf-mx with esmtp (Exim 4.12) id 1B6LUw-0006MH-00 for enum@ietf.org; Wed, 24 Mar 2004 22:25:38 -0500 Received: from [10.71.3.136] ([63.99.125.25]) by BGSLC11.burtongroup.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 24 Mar 2004 20:25:04 -0700 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 24 Mar 2004 22:25:02 -0500 Subject: Re: [Enum] .TEL and ENUM? From: Irwin Lazar To: Message-ID: In-Reply-To: <406234C1.51623D52@ix.netcom.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Mar 2004 03:25:04.0151 (UTC) FILETIME=[C37D7270:01C41218] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > From: Jeff Williams > Date: Wed, 24 Mar 2004 17:24:21 -0800 > To: Jim Reid > Cc: Christian de Larrinaga , Patrik Faltstrom > , Tim Ruiz , Richard Shockey > , enum@ietf.org > Subject: Re: [Enum] .TEL and ENUM? > > Jim and all, > > I agree there is no good reason for .TEL or for that matter > a .xxx TLD. However there is perhaps a desire for these > TLD's. Given that there such a desire, not allowing for their > inclusion/creation based on "Good reason" may not be > enough... > What about the idea that I could use "me@carrier.tel" for my phone number? It seems to me that the .tel TLD would be an ideal marker for consumer phone and would easily differentiate to the average person that they were referring to my phone instead of my e-mail account. irwin _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 00:01:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13748 for ; Thu, 25 Mar 2004 00:01:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6MzQ-0005yU-OF for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 00:01:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P51C6v022966 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 00:01:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6MzE-0005xl-03; Thu, 25 Mar 2004 00:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Myu-0005ve-MD for enum@optimus.ietf.org; Thu, 25 Mar 2004 00:00:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13726 for ; Thu, 25 Mar 2004 00:00:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Mys-0005uk-00 for enum@ietf.org; Thu, 25 Mar 2004 00:00:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Mxx-0005q4-00 for enum@ietf.org; Wed, 24 Mar 2004 23:59:41 -0500 Received: from barry.mail.mindspring.net ([207.69.200.25]) by ietf-mx with esmtp (Exim 4.12) id 1B6Mx1-0005lw-00 for enum@ietf.org; Wed, 24 Mar 2004 23:58:43 -0500 Received: from 1cust150.tnt36.dfw9.da.uu.net ([67.234.81.150] helo=ix.netcom.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1B6Mwy-00073F-00; Wed, 24 Mar 2004 23:58:40 -0500 Message-ID: <40628153.9125DBEA@ix.netcom.com> Date: Wed, 24 Mar 2004 22:51:03 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Irwin Lazar CC: enum@ietf.org Subject: Re: [Enum] .TEL and ENUM? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Irwin and all, Irwin Lazar wrote: > > From: Jeff Williams > > Date: Wed, 24 Mar 2004 17:24:21 -0800 > > To: Jim Reid > > Cc: Christian de Larrinaga , Patrik Faltstrom > > , Tim Ruiz , Richard Shockey > > , enum@ietf.org > > Subject: Re: [Enum] .TEL and ENUM? > > > > Jim and all, > > > > I agree there is no good reason for .TEL or for that matter > > a .xxx TLD. However there is perhaps a desire for these > > TLD's. Given that there such a desire, not allowing for their > > inclusion/creation based on "Good reason" may not be > > enough... > > > What about the idea that I could use "me@carrier.tel" for my phone number? > It seems to me that the .tel TLD would be an ideal marker for consumer phone > and would easily differentiate to the average person that they were > referring to my phone instead of my e-mail account. Sorry to burst your bubble here, but the "@" tells me it is an Email address only.. < shrug > Using a TLD or in this instance a "Class of TLD, ergo an sTLD" for a marker can be helpful in some instances for a class of goods or services. But .TEL is a type of communication service, not a class. Hence in many instances domain names in the .TEL name space could be very misleading... Your example is only one such instance... > > > irwin > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 09:30:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24172 for ; Thu, 25 Mar 2004 09:30:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VsB-0004Hv-9l for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 09:30:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEUJ3s016483 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 09:30:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Vs4-0004FT-Ro; Thu, 25 Mar 2004 09:30:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VrW-00041m-DK for enum@optimus.ietf.org; Thu, 25 Mar 2004 09:29:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23940 for ; Thu, 25 Mar 2004 09:29:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VrP-0000mJ-00 for enum@ietf.org; Thu, 25 Mar 2004 09:29:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VpO-0000Qb-00 for enum@ietf.org; Thu, 25 Mar 2004 09:27:27 -0500 Received: from internal.mail.demon.net ([193.195.224.3]) by ietf-mx with esmtp (Exim 4.12) id 1B6VnD-00001d-00 for enum@ietf.org; Thu, 25 Mar 2004 09:25:11 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by internal.mail.demon.net with ESMTP id i2PERHD17595; Thu, 25 Mar 2004 14:27:17 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1B6Vn8-00069a-00; Thu, 25 Mar 2004 14:25:06 +0000 Date: Thu, 25 Mar 2004 14:25:06 +0000 From: "Clive D.W. Feather" To: Stastny Richard Cc: Marian Durkovic , lwc@roke.co.uk, enum@ietf.org Subject: Re: [Enum] Summary on NoPSTN dicussion Message-ID: <20040325142506.GB20735@finch-staff-1.thus.net> References: <06CF906FE3998C4E944213062009F162233C3E@oefeg-s02.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06CF906FE3998C4E944213062009F162233C3E@oefeg-s02.oefeg.loc> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Stastny Richard said: > B. use a (one, common) second common tree (e164shadow.arpa, where you put > in only the wildcards for the number ranges in question. The processing > assumption now should be: [...] > C. Use individual second shadow trees, eg on a national level, eg in > Austria e164shadow.at would be used. The problem here is how one can > find out the domain names of the individual trees. > One solution is to do it with a table in each server (which is not good). > > The other solution is to put pointers in e164.arpa, eg SRV RR or even MX RR. [...] > Since the structure of the delegations in e164.arpa varies (Tier 1 levels), > there is no easy way to find out the level of the pointers, even if they are > only on the Tier 1 layer. If the shadow tree is shadow.e164.arpa, and if the delegation rule is that the national authority getting .e164.arpa is also delegated .shadow.e164.arpa (so the UK Tier 1 operator has both 4.4.e164.arpa and 4.4.shadow.e164.arpa), doesn't that give you both B and C without needing to create another special SLD? Obviously, "shadow" can be replaced by something shorter if felt desirable, such as "w" (for "wildcards"). -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | *** NOTE CHANGE *** Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 Thus plc | | Mobile: +44 7973 377646 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 09:40:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25154 for ; Thu, 25 Mar 2004 09:40:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6W1s-0005ti-HQ for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 09:40:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEeKCS022613 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 09:40:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6W1l-0005qH-I5; Thu, 25 Mar 2004 09:40:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6W0s-0005h8-IO for enum@optimus.ietf.org; Thu, 25 Mar 2004 09:39:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24954 for ; Thu, 25 Mar 2004 09:39:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6W0q-0002Mu-00 for enum@ietf.org; Thu, 25 Mar 2004 09:39:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Vz8-000219-00 for enum@ietf.org; Thu, 25 Mar 2004 09:37:32 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B6Vvt-0001JR-00 for enum@ietf.org; Thu, 25 Mar 2004 09:34:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: AW: [Enum] Summary on NoPSTN dicussion MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 25 Mar 2004 15:33:37 +0100 Message-ID: <06CF906FE3998C4E944213062009F162233C42@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQSdPmILvNaGsDBRgOt6IJBoLYYYwAALZai From: "Stastny Richard" To: "Clive D.W. Feather" Cc: "Marian Durkovic" , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 IA0KDQoJQ2xpdmUgc2FpZDoNCgk+SWYgdGhlIHNoYWRvdyB0cmVlIGlzIHNoYWRvdy5lMTY0LmFy cGEsIGFuZCBpZiB0aGUgZGVsZWdhdGlvbiBydWxlIGlzIHRoYXQNCgk+dGhlIG5hdGlvbmFsIGF1 dGhvcml0eSBnZXR0aW5nIDxOPi5lMTY0LmFycGEgaXMgYWxzbyBkZWxlZ2F0ZWQNCgk+PE4+LnNo YWRvdy5lMTY0LmFycGEgKHNvIHRoZSBVSyBUaWVyIDEgb3BlcmF0b3IgaGFzIGJvdGggNC40LmUx NjQuYXJwYSBhbmQNCgk+NC40LnNoYWRvdy5lMTY0LmFycGEpLCBkb2Vzbid0IHRoYXQgZ2l2ZSB5 b3UgYm90aCBCIGFuZCBDIHdpdGhvdXQgbmVlZGluZw0KCT50byBjcmVhdGUgYW5vdGhlciBzcGVj aWFsIFNMRD8NCgkNCg0KCVllcywgb2YgY291cnNlLCBtYXliZSBJIGRpZCBpdCBub3QgbWFrZSBj b21wbGV0ZWx5IGNsZWFyIHRoYXQgSSB3b3VsZCBwcmVmZXINCg0KCXRoaXMgdmFyaWFudCwgYmVj YXVzZSBpdCBtYWtlcyB0aGUgb3RoZXIgdmFyaWFudHMgdW5uZWNlc3NhcnkuIEkgb25seSBmZWFy DQoNCgl0aGF0IHRoaXMgd2lsbCB0YWtlIHNvbWUgdGltZSwgc28gaW4gdGhlIG1lYW50aW1lIHRo ZSBvdGhlciBTTERTIGNvdWxkIGJlIHVzZWQNCgkNCgk+T2J2aW91c2x5LCAic2hhZG93IiBjYW4g YmUgcmVwbGFjZWQgYnkgc29tZXRoaW5nIHNob3J0ZXIgaWYgZmVsdCBkZXNpcmFibGUsDQoJPnN1 Y2ggYXMgInciIChmb3IgIndpbGRjYXJkcyIpLg0KDQoJT2YgY291cnNlLCBlMTY0dy5hcnBhIHdv dWxkIGJlIHN1ZmZpY2llbnQuDQoNCglSaWNoYXJkDQoJDQoJLS0NCglDbGl2ZSBELlcuIEZlYXRo ZXIgIHwgV29yazogIDxjbGl2ZUBkZW1vbi5uZXQ+ICAgfCBUZWw6ICAgICs0NCAyMCA4NDk1IDYx MzgNCglJbnRlcm5ldCBFeHBlcnQgICAgIHwgSG9tZTogIDxjbGl2ZUBkYXZyb3Mub3JnPiAgfCAq KiogTk9URSBDSEFOR0UgKioqDQoJRGVtb24gSW50ZXJuZXQgICAgICB8IFdXVzogaHR0cDovL3d3 dy5kYXZyb3Mub3JnIHwgRmF4OiAgICArNDQgODcwIDA1MSA5OTM3DQoJVGh1cyBwbGMgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgTW9iaWxlOiArNDQgNzk3MyAzNzc2 NDYNCgkNCg0K _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 10:04:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27249 for ; Thu, 25 Mar 2004 10:04:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WP3-0002Li-KM for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 10:04:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PF4HOS009002 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 10:04:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WOy-0002Jy-IH; Thu, 25 Mar 2004 10:04:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WOk-0002G4-B6 for enum@optimus.ietf.org; Thu, 25 Mar 2004 10:03:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27005 for ; Thu, 25 Mar 2004 10:03:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6WOh-0004nh-00 for enum@ietf.org; Thu, 25 Mar 2004 10:03:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6WNl-0004ir-00 for enum@ietf.org; Thu, 25 Mar 2004 10:02:57 -0500 Received: from internal.mail.demon.net ([193.195.224.3]) by ietf-mx with esmtp (Exim 4.12) id 1B6WMw-0004ff-00 for enum@ietf.org; Thu, 25 Mar 2004 10:02:06 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by internal.mail.demon.net with ESMTP id i2PF44D03113; Thu, 25 Mar 2004 15:04:04 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1B6WMk-00076M-00; Thu, 25 Mar 2004 15:01:54 +0000 Date: Thu, 25 Mar 2004 15:01:54 +0000 From: "Clive D.W. Feather" To: Stastny Richard , #@demon.net Cc: Marian Durkovic , lwc@roke.co.uk, enum@ietf.org Subject: Re: [Enum] Summary on NoPSTN dicussion# Message-ID: <20040325150154.GC20735@finch-staff-1.thus.net> References: <06CF906FE3998C4E944213062009F162233C42@oefeg-s02.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06CF906FE3998C4E944213062009F162233C42@oefeg-s02.oefeg.loc> User-Agent: Mutt/1.5.3i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Stastny Richard said: >>Obviously, "shadow" can be replaced by something shorter if felt desirable, >>such as "w" (for "wildcards"). > >Of course, e164w.arpa would be sufficient. But this requires a second SLD, which *will* lead to arguments. The advantage of w.e164.arpa is that it's more information in the same tree; otherwise people are going to say "why should we expect it to stop at two SLDs?" or even "as well as e164w.arpa, we clearly need e164.com". This is a can of worms we don't need to have opened. Doing it my way also establishes a precedent for other reference information in the tree. For example, tier 1 registries could use registry..e164.arpa (e.g. r.4.4.e164.arpa) for number-independent stuff (in the same way that nic. is used to refer to the current NIC for the country). -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | *** NOTE CHANGE *** Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 Thus plc | | Mobile: +44 7973 377646 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 10:45:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01495 for ; Thu, 25 Mar 2004 10:45:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6X1w-00025K-K6 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 10:44:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PFiSLh007962 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 10:44:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6X1X-0001pa-TO; Thu, 25 Mar 2004 10:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Whv-0008KG-8g for enum@optimus.ietf.org; Thu, 25 Mar 2004 10:23:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29950 for ; Thu, 25 Mar 2004 10:23:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Wht-0007JG-00 for enum@ietf.org; Thu, 25 Mar 2004 10:23:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Wgz-0007A7-00 for enum@ietf.org; Thu, 25 Mar 2004 10:22:49 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B6Wfg-0006r8-00 for enum@ietf.org; Thu, 25 Mar 2004 10:21:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [Enum] Summary on NoPSTN dicussion# MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Mar 2004 16:20:50 +0100 Message-ID: <06CF906FE3998C4E944213062009F162233C43@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Summary on NoPSTN dicussion# Thread-Index: AcQSehzjDdDDfllMRIGfNg4mdXKpVAAARBeQ From: "Stastny Richard" To: "Clive D.W. Feather" , <#@demon.net> Cc: "Marian Durkovic" , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Clive said: > >Of course, e164w.arpa would be sufficient. >=20 > But this requires a second SLD, which *will* lead to arguments. The > advantage of w.e164.arpa is that it's more information in the same = tree; > otherwise people are going to say "why should we expect it to stop at > two SLDs?" or even "as well as e164w.arpa, we clearly need e164.com". = This > is a can of worms we don't need to have opened. [Richard>] I really do not care if it is w.e164.arpa or e164w.arpa, most ENUM clients accept both of it, as long as the rest of the chain is not broken. If you consider it easier to implement w.e164.arpa - = fime. BTW, who do you think will be responsible for making this decision? >=20 > Doing it my way also establishes a precedent for other reference > information in the tree. For example, tier 1 registries could use > registry..e164.arpa (e.g. r.4.4.e164.arpa) for number-independent = stuff > (in the same way that nic. is used to refer to the current NIC = for > the country). [Richard>]=20 With this solution there will be a similar problem with nic., not = all ccTLD are following this convention and that why RIPE proposed to = introduce and SRV record e.g. to point to the WHOIS domain. The problem is similar to the problem where to put the MX record. You = need to know the length of the country code (this is the easy part, you get = it from the ITU-T webpage, but you still need to administer it). In = addition,=20 if a country decides to use different tier 1 or a two layered tier 1, = you=20 will get a problem. This will be especially the case in the NANPA. Regards Richard >=20 > -- > Clive D.W. Feather | Work: | Tel: +44 20 8495 > 6138 > Internet Expert | Home: | *** NOTE CHANGE *** > Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 > 9937 > Thus plc | | Mobile: +44 7973 = 377646 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 10:45:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01519 for ; Thu, 25 Mar 2004 10:45:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6X1w-000250-JP for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 10:44:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PFiSFR007961 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 10:44:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6X1a-0001qs-O1; Thu, 25 Mar 2004 10:44:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Wjy-00006P-CZ for enum@optimus.ietf.org; Thu, 25 Mar 2004 10:25:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00149 for ; Thu, 25 Mar 2004 10:25:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Wjv-0007cG-00 for enum@ietf.org; Thu, 25 Mar 2004 10:25:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Wir-0007ST-00 for enum@ietf.org; Thu, 25 Mar 2004 10:24:46 -0500 Received: from gromit.rfc1035.com ([195.54.233.67]) by ietf-mx with esmtp (Exim 4.12) id 1B6Whm-0007I1-00 for enum@ietf.org; Thu, 25 Mar 2004 10:23:38 -0500 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i2PFNZRv014762; Thu, 25 Mar 2004 15:23:35 GMT To: "Stastny Richard" cc: "Marian Durkovic" , lwc@roke.co.uk, enum@ietf.org Subject: Re: [Enum] Summary on NoPSTN dicussion In-Reply-To: Message from "Stastny Richard" of "Thu, 25 Mar 2004 13:08:20 +0100." <06CF906FE3998C4E944213062009F162233C3E@oefeg-s02.oefeg.loc> Date: Thu, 25 Mar 2004 15:23:35 +0000 Message-ID: <14760.1080228215@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Richard" == Stastny Richard writes: Richard> 4. Now the real problem starts: If the ENUM-query returns Richard> NXDOMAIN, the current assumption of all clients is: the Richard> call is routed to the PSTN if the server is able to do so Richard> (eventually with the ;enumdi set. Richard> The solutions proposed for this sofar are. Richard> A. use tables in each server. Yes, this is unacceptable. Richard> B. use a (one, common) second common tree Richard> C. Use individual second shadow trees B and C are ugly and evil. Alternate trees, however well intentioned, give me the heebie-jeebies. Richard> D. Are there additional possibilities or proposals? Yes. Use the additional information that's in the NXDOMAIN response. This will include the SOA record for the zone enclosing the name that was looked up. The name of that zone could be looked up to get a NAPTR for a default SIP gateway or whatever. An example might clarify this. Consider the non-existent phone number 1234567890. An ENUM lookup of 0.9.8.7.6.5.4.3.2.1.e164.arpa returns NXDOMAIN. The response includes a SOA record for 5.4.3.2.1.e164.arpa -- the enclosing zone for this name. This will be in the Authority Section of the reply. In other words, the name servers for 5.4.3.2.1.e164.arpa are saying 0.9.8.7.6.5.4.3.2.1.e164.arpa doesn't exist. If I then lookup 5.4.3.2.1.e164.arpa, this could have a NAPTR that gives me the name of a SIP gateway that will do the Right Thing for 1234567890. There's no need for wildcards or shadow tree ickiness. And it's nice and clean for things like 800 and 900 numbers or DDI blocks. Calls to these numbers will get shunted to the right "gateway". This does of course make things a little bit trickier for a Tier-1 registry that delegates every individual E.164 number. BTW, what about NODATA responses from the DNS? ie The name exists, but not as the QTYPE (NAPTR?) that was requested.... _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 10:48:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01959 for ; Thu, 25 Mar 2004 10:48:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6X5c-0003DZ-Ph for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 10:48:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PFmGFC012370 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 10:48:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6X5R-0003CQ-Py; Thu, 25 Mar 2004 10:48:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6X4j-00034D-Qy for enum@optimus.ietf.org; Thu, 25 Mar 2004 10:47:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01864 for ; Thu, 25 Mar 2004 10:47:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6X4h-0001dC-00 for enum@ietf.org; Thu, 25 Mar 2004 10:47:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6X3w-0001Y5-00 for enum@ietf.org; Thu, 25 Mar 2004 10:46:32 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B6X39-0001Nf-00 for enum@ietf.org; Thu, 25 Mar 2004 10:45:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [Enum] Summary on NoPSTN dicussion MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Mar 2004 16:45:07 +0100 Message-ID: <06CF906FE3998C4E944213062009F162233C45@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQSfSZ8I2CP4rh1RNOr8Zaw31MVbwAAauIQ From: "Stastny Richard" To: "Jim Reid" Cc: "Marian Durkovic" , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Jim, let me see if I understand you proposal (I am not a DNS expert, sorry), and if it works how it is intended. This may solve some other problems, = too. > Richard> D. Are there additional possibilities or proposals? >=20 > Yes. Use the additional information that's in the NXDOMAIN response. > This will include the SOA record for the zone enclosing the name that > was looked up. The name of that zone could be looked up to get a > NAPTR for a default SIP gateway or whatever. An example might clarify > this. >=20 > Consider the non-existent phone number 1234567890. >=20 > An ENUM lookup of 0.9.8.7.6.5.4.3.2.1.e164.arpa returns NXDOMAIN. The > response includes a SOA record for 5.4.3.2.1.e164.arpa -- the > enclosing zone for this name. This will be in the Authority Section of > the reply. In other words, the name servers for 5.4.3.2.1.e164.arpa > are saying 0.9.8.7.6.5.4.3.2.1.e164.arpa doesn't exist. If I then > lookup 5.4.3.2.1.e164.arpa, this could have a NAPTR that gives me the > name of a SIP gateway that will do the Right Thing for 1234567890. >=20 > There's no need for wildcards or shadow tree ickiness. And it's nice > and clean for things like 800 and 900 numbers or DDI blocks. Calls to > these numbers will get shunted to the right "gateway". This does of > course make things a little bit trickier for a Tier-1 registry that > delegates every individual E.164 number. [Richard>]=20 If I want to have a spezial policy for a number block, I put in a NAPTR In the zone delegating the numbers to the next tier. This could either be a default gateway as requested or a VOID NAPTR (for discussions sake) So if a client gets a NXDOMAIN, he just has to do another lookup to The domain returned in the SOA. If again no NAPTR is returned, another SOA is return from the next higher zone. So he queries here for NAPTR. So this can even be nested from bottom up. This is very nice, because it would also solve the DDI and switchboard problem with PBX. >=20 > BTW, what about NODATA responses from the DNS? ie The name exists, but > not as the QTYPE (NAPTR?) that was requested.... [Richard>]=20 Could you please elaborate, I do not understand this. Regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 10:55:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02605 for ; Thu, 25 Mar 2004 10:55:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XCF-0004dG-Iv for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 10:55:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PFt7ve017753 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 10:55:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XC9-0004bP-7d; Thu, 25 Mar 2004 10:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XBF-0004XX-J7 for enum@optimus.ietf.org; Thu, 25 Mar 2004 10:54:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02542 for ; Thu, 25 Mar 2004 10:54:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6XBD-00028c-00 for enum@ietf.org; Thu, 25 Mar 2004 10:54:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6XAG-00025a-00 for enum@ietf.org; Thu, 25 Mar 2004 10:53:05 -0500 Received: from boromix.nask.net.pl ([195.187.245.33]) by ietf-mx with esmtp (Exim 4.12) id 1B6X9P-00021x-00 for enum@ietf.org; Thu, 25 Mar 2004 10:52:11 -0500 Received: from boromir.nask.waw.pl (boromir [195.187.245.136]) by boromix.nask.net.pl with ESMTP id i2PFq5pt014607 for ; Thu, 25 Mar 2004 16:52:05 +0100 Received: from localhost by boromir.nask.waw.pl with ESMTP id i2PFq3RI022210 for ; Thu, 25 Mar 2004 16:52:03 +0100 (MET) Date: Thu, 25 Mar 2004 16:52:03 +0100 (MET) From: Andrzej Bartosiewicz X-X-Sender: andrzejb@boromir To: IETF ENUM list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII VirusProtection: checked - Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Enum] ENUM "Phone book" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , NASK has developed the "Phone Book" for mobile phones (Personal Java) based on ENUM/DNS. more... http://www.dns.pl/ENUM/enumClient.zip If you are interested, please download. Be aware: it's the "alpha" version. Regards, Andrzej Bartosiewicz. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 12:26:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09181 for ; Thu, 25 Mar 2004 12:26:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Y6q-0002oC-7A for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 11:54:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PGrPhb010635 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 11:53:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Y5J-0002fV-QT; Thu, 25 Mar 2004 11:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Y4g-0002cA-K2 for enum@optimus.ietf.org; Thu, 25 Mar 2004 11:51:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06270 for ; Thu, 25 Mar 2004 11:51:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Y4f-0006Uz-00 for enum@ietf.org; Thu, 25 Mar 2004 11:51:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Y3l-0006R5-00 for enum@ietf.org; Thu, 25 Mar 2004 11:50:25 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B6Y2s-0006MS-00 for enum@ietf.org; Thu, 25 Mar 2004 11:49:31 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Mar 2004 08:56:24 +0000 Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2PGmRsk004095; Thu, 25 Mar 2004 17:48:27 +0100 (MET) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 25 Mar 2004 17:47:17 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Mar 2004 17:48:57 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4EBBB942-7E7C-11D8-A27F-000A95B2B926@cisco.com> Content-Transfer-Encoding: 7bit Cc: IETF ENUM list From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] ENUM "Phone book" Date: Thu, 25 Mar 2004 17:48:56 +0100 To: Andrzej Bartosiewicz X-Mailer: Apple Mail (2.613) X-OriginalArrivalTime: 25 Mar 2004 16:48:57.0931 (UTC) FILETIME=[111031B0:01C41289] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mar 25, 2004, at 16:52, Andrzej Bartosiewicz wrote: > NASK has developed the "Phone Book" for mobile phones (Personal Java) > based on ENUM/DNS. > > more... > http://www.dns.pl/ENUM/enumClient.zip > > If you are interested, please download. Be aware: it's the "alpha" > version. Works like a charm! Excellent! Well done! paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 12:33:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09551 for ; Thu, 25 Mar 2004 12:33:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Yj5-000823-NX for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 12:33:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PHX7gU030847 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 12:33:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Yiz-000811-Rv; Thu, 25 Mar 2004 12:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6YiY-0007km-RA for enum@optimus.ietf.org; Thu, 25 Mar 2004 12:32:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09475 for ; Thu, 25 Mar 2004 12:32:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6YiX-0002Y4-00 for enum@ietf.org; Thu, 25 Mar 2004 12:32:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Yhl-0002UM-00 for enum@ietf.org; Thu, 25 Mar 2004 12:31:45 -0500 Received: from eddie.austria.eu.net ([193.154.142.22]) by ietf-mx with esmtp (Exim 4.12) id 1B6Ygu-0002Ml-00 for enum@ietf.org; Thu, 25 Mar 2004 12:30:52 -0500 Received: from eddie.Austria.EU.net (localhost [127.0.0.1]) by eddie.Austria.EU.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2PHUKkb024252 for ; Thu, 25 Mar 2004 18:30:20 +0100 Received: (from lendl@localhost) by eddie.Austria.EU.net (8.12.3/8.12.3/Debian-6.6) id i2PHUK84024251 for enum@ietf.org; Thu, 25 Mar 2004 18:30:20 +0100 Date: Thu, 25 Mar 2004 18:30:20 +0100 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] Summary on NoPSTN dicussion Message-ID: <20040325183020.A24144@at.tiscali.com> Mail-Followup-To: Otmar Lendl , enum@ietf.org References: <06CF906FE3998C4E944213062009F162233C3E@oefeg-s02.oefeg.loc> <14760.1080228215@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14760.1080228215@gromit.rfc1035.com> User-Agent: Mutt/1.3.23i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On 2004/03/25 16:03, Jim Reid wrote: > > Yes. Use the additional information that's in the NXDOMAIN response. > This will include the SOA record for the zone enclosing the name that > was looked up. The name of that zone could be looked up to get a > NAPTR for a default SIP gateway or whatever. An example might clarify > this. Jim, this is a cute idea, especially for DDI on PBXes. For 800 numbers, this could be a replacement for freenum.org. I see issues (not showstoppers) with it, though: * I'm not sure whether the current resolver libraries are designed to pass additional information returned in an error response back to the calling application. The typical gethostbyname - type functions certainly don't. I haven't seen a standardised API to NAPTR queries yet (all the code I have seen (asterisk, ser) by now does manual response parsing -- yuck.), maybe you're early enough to get this added. * The scheme only works on zone boundaries. If we (as 3.4.e164.arpa Tier1) were to implement this on +43780 (which is under discussion as ENUM-only number range) we would have to delegate 0.8.7.3.4.e164.arpa to ourselves first, and then delegate individual numbers from within that zone. That violates our basic assumption that all delegation from the Tier1 will be within the 3.4.e164.arpa zone. Yes, one can program around that, but it certainly won't make things easier for us. > BTW, what about NODATA responses from the DNS? ie The name exists, but > not as the QTYPE (NAPTR?) that was requested.... ditto with SRVFAIL. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 12:39:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09953 for ; Thu, 25 Mar 2004 12:39:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6YpE-0000c1-8M for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 12:39:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PHdSRu002347 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 12:39:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6YpA-0000b3-Oe; Thu, 25 Mar 2004 12:39:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6YoQ-0000OL-Pz for enum@optimus.ietf.org; Thu, 25 Mar 2004 12:38:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09896 for ; Thu, 25 Mar 2004 12:38:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6YoO-0002wz-00 for enum@ietf.org; Thu, 25 Mar 2004 12:38:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6YnR-0002u4-00 for enum@ietf.org; Thu, 25 Mar 2004 12:37:38 -0500 Received: from gromit.rfc1035.com ([195.54.233.67]) by ietf-mx with esmtp (Exim 4.12) id 1B6Ymw-0002q8-00 for enum@ietf.org; Thu, 25 Mar 2004 12:37:06 -0500 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i2PHavRv015131; Thu, 25 Mar 2004 17:36:58 GMT To: "Stastny Richard" cc: "Marian Durkovic" , lwc@roke.co.uk, enum@ietf.org Subject: Re: [Enum] Summary on NoPSTN dicussion In-Reply-To: Message from "Stastny Richard" of "Thu, 25 Mar 2004 16:45:07 +0100." <06CF906FE3998C4E944213062009F162233C45@oefeg-s02.oefeg.loc> Date: Thu, 25 Mar 2004 17:36:57 +0000 Message-ID: <15130.1080236217@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Richard" == Stastny Richard writes: >> Yes. Use the additional information that's in the NXDOMAIN >> response. This will include the SOA record for the zone >> enclosing the name that was looked up. The name of that zone >> could be looked up to get a NAPTR for a default SIP gateway or >> whatever. An example might clarify this. >> >> Consider the non-existent phone number 1234567890. >> >> An ENUM lookup of 0.9.8.7.6.5.4.3.2.1.e164.arpa returns >> NXDOMAIN. The response includes a SOA record for >> 5.4.3.2.1.e164.arpa -- the enclosing zone for this name. This >> will be in the Authority Section of the reply. In other words, >> the name servers for 5.4.3.2.1.e164.arpa are saying >> 0.9.8.7.6.5.4.3.2.1.e164.arpa doesn't exist. If I then lookup >> 5.4.3.2.1.e164.arpa, this could have a NAPTR that gives me the >> name of a SIP gateway that will do the Right Thing for >> 1234567890. >> >> There's no need for wildcards or shadow tree ickiness. And it's >> nice and clean for things like 800 and 900 numbers or DDI >> blocks. Calls to these numbers will get shunted to the right >> "gateway". This does of course make things a little bit >> trickier for a Tier-1 registry that delegates every individual >> E.164 number. Richard> So if a client gets a NXDOMAIN, he just has to do another Richard> lookup to The domain returned in the SOA. Yes, but he *doesn't* have to do this. He should of course, but... Richard> If again no NAPTR is returned, another SOA is return from Richard> the next higher zone. So he queries here for NAPTR. Nope! The SOA record is returned for the closest enclosing zone: the delegation point. Let's take the example above. I get an NXDOMAIN when looking up 0.9.8.7.6.5.4.3.2.1.e164.arpa. The SOA record for the nearest delegation point, 5.4.3.2.1.e164.arpa, is returned in that response. So I now look for a NAPTR (say) for 5.4.3.2.1.e164.arpa. If this doesn't exist, I get an NXDOMAIN back. This time the *same* SOA record will be returned because the 5.4.3.2.1.e164.arpa zone is the nearest delegation point to 5.4.3.2.1.e164.arpa. Now, I suppose an (idiot) application could walk up the tree, trying 4.3.2.1.e164.arpa, 3.2.1.e164.arpa, etc looking for the next highest delegation point and hypothetical default NAPTR. But this is ugly and should be avoided. Imagine the implications for a 10-12 digit phone number. >> BTW, what about NODATA responses from the DNS? ie The name >> exists, but not as the QTYPE (NAPTR?) that was requested.... Richard> [Richard>] Could you please elaborate, I do not Richard> understand this. Sure. Suppose I ask for NAPTRs for 0.9.8.7.6.5.4.3.2.1.e164.arpa. There aren't any. But the name has a TXT record. Or an MX record. Or... In this case, the server returns a NODATA response. The Answer Section is empty, but the reply's status field is NOERROR, not NXDOMAIN. The name 0.9.8.7.6.5.4.3.2.1.e164.arpa exists, but not as the QTYPE -- NAPTR in this example -- that was looked up. This corner case may need to be covered. There's nothing in RFC2916(bis) that says only NAPTR records can exist as leaf nodes of e164.arpa. Clients must/should be prepared to handle any legal resource records that could get returned. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 12:53:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10878 for ; Thu, 25 Mar 2004 12:53:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Z2T-0001rP-5Z for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 12:53:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PHr9A8007097 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 12:53:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Z25-0001hr-V9; Thu, 25 Mar 2004 12:52:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Yzm-0001Jt-Al for enum@optimus.ietf.org; Thu, 25 Mar 2004 12:50:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10780 for ; Thu, 25 Mar 2004 12:50:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Yzk-0003r5-00 for enum@ietf.org; Thu, 25 Mar 2004 12:50:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Yyo-0003oP-00 for enum@ietf.org; Thu, 25 Mar 2004 12:49:23 -0500 Received: from eddie.austria.eu.net ([193.154.142.22]) by ietf-mx with esmtp (Exim 4.12) id 1B6YyP-0003lY-00 for enum@ietf.org; Thu, 25 Mar 2004 12:48:57 -0500 Received: from eddie.Austria.EU.net (localhost [127.0.0.1]) by eddie.Austria.EU.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2PHmQkb024418 for ; Thu, 25 Mar 2004 18:48:26 +0100 Received: (from lendl@localhost) by eddie.Austria.EU.net (8.12.3/8.12.3/Debian-6.6) id i2PHmQGW024417 for enum@ietf.org; Thu, 25 Mar 2004 18:48:26 +0100 Date: Thu, 25 Mar 2004 18:48:26 +0100 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] Summary on NoPSTN dicussion Message-ID: <20040325184826.A24384@nic.at> Mail-Followup-To: Otmar Lendl , enum@ietf.org References: <06CF906FE3998C4E944213062009F162233C45@oefeg-s02.oefeg.loc> <15130.1080236217@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15130.1080236217@gromit.rfc1035.com> User-Agent: Mutt/1.3.23i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On 2004/03/25 18:03, Jim Reid wrote: > > >> BTW, what about NODATA responses from the DNS? ie The name > >> exists, but not as the QTYPE (NAPTR?) that was requested.... > > Richard> [Richard>] Could you please elaborate, I do not > Richard> understand this. > > Sure. Suppose I ask for NAPTRs for 0.9.8.7.6.5.4.3.2.1.e164.arpa. > There aren't any. But the name has a TXT record. Or an MX record. > Or... In this case, the server returns a NODATA response. The Answer > Section is empty, but the reply's status field is NOERROR, not > NXDOMAIN. The name 0.9.8.7.6.5.4.3.2.1.e164.arpa exists, but not as > the QTYPE -- NAPTR in this example -- that was looked up. This corner > case may need to be covered. There's nothing in RFC2916(bis) that says > only NAPTR records can exist as leaf nodes of e164.arpa. Clients > must/should be prepared to handle any legal resource records that > could get returned. Even if there are NAPTR records, you still might not get a NAPTR with enumservice for voice. My guess is that you should handle both cases in the same way. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 13:13:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12194 for ; Thu, 25 Mar 2004 13:13:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ZLK-0004mo-9V for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 13:12:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PICcUw018398 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 13:12:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ZLE-0004kY-Qv; Thu, 25 Mar 2004 13:12:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ZJR-0004dQ-LI for enum@optimus.ietf.org; Thu, 25 Mar 2004 13:10:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12024 for ; Thu, 25 Mar 2004 13:10:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ZJF-0005ZS-00 for enum@ietf.org; Thu, 25 Mar 2004 13:10:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ZIS-0005WJ-00 for enum@ietf.org; Thu, 25 Mar 2004 13:09:41 -0500 Received: from us.svf.stuba.sk ([147.175.16.9]) by ietf-mx with esmtp (Exim 4.12) id 1B6ZHU-0005Pu-00 for enum@ietf.org; Thu, 25 Mar 2004 13:08:41 -0500 Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.11/8.12.11) with ESMTP id i2PI84aV055665 for ; Thu, 25 Mar 2004 19:08:04 +0100 (CET) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.11/8.12.11/Submit) id i2PI7xPm055664 for enum@ietf.org; Thu, 25 Mar 2004 19:07:59 +0100 (CET) (envelope-from md) Date: Thu, 25 Mar 2004 19:07:59 +0100 From: Marian Durkovic To: enum@ietf.org Subject: Re: [Enum] Summary on NoPSTN dicussion Message-ID: <20040325180759.GA54506@us.svf.stuba.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi all, well, please read at the bottom what I've proposed in July last year... I'd prefer to have a special subdomain in order not to clash with misdialed numbers. Jim> BTW, what about NODATA responses from the DNS? ie The name Jim> exists, but not as the QTYPE (NAPTR?) that was requested.... as for NODATA response - this contains "NOERROR, 0 answers, 1 authority" so it's usable the same way as NXDOMAIN - the authority section contains the name of the authoritative zone. However, other problem exists here - this approach will only work if all info is present in the same zone, which is fine for DDI ranges and 800 numbers but probably not for ENUM-only range, unless you're prepared to store all records for ENUM-only range in the same DNS zone. Once you delegate something, the authoritative zone changes and you have to rely on Tier-x to place the default records in their zones. ----- Forwarded message from Patrik F?ltstr?m ----- From: Patrik F?ltstr?m Date: Thu, 10 Jul 2003 11:26:15 +0200 To: Marian Durkovic Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt X-Mailer: Apple Mail (2.552) On torsdag, jul 10, 2003, at 11:19 Europe/Stockholm, Marian Durkovic wrote: >would you think this might be a solution? > >PBX prefix: +421 5555 xxx > >ENUM client requests 1.1.1.5.5.5.5.1.2.4.e164.arpa. > >gets an answer: NXDOMAIN, authority record: 5.5.5.5.1.2.4.e164.arpa. > >Then the client performs a second query - either directly to > >5.5.5.5.1.2.4.e164.arpa. or some well-known subdomain i.e. > >all.5.5.5.5.1.2.4.e164.arpa. > >and gets a NAPTR record with non-greedy regexpr. The client doesn't send this second query. If it gets a NXDOMAIN that's it. Or, what do I not understand? paf > >This IMHO is _no_ wildcard in DNS, is OK with DNSSEC and is one-to-many >translation. > > What do you think? > > > Thanks, > > M. > > ----- End forwarded message ----- -------------------------------------------------------------------------- ---- ---- ---- Marian Durkovic network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 524 51 301 ---- ---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail/sip: md@bts.sk ---- ---- ---- -------------------------------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 13:20:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12504 for ; Thu, 25 Mar 2004 13:20:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ZSh-0005h4-Ub for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 13:20:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PIKFxQ021833 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 13:20:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ZST-0005cU-G3; Thu, 25 Mar 2004 13:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XZt-00084X-Gd for enum@optimus.ietf.org; Thu, 25 Mar 2004 11:19:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04585 for ; Thu, 25 Mar 2004 11:19:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6XZs-0004Tk-00 for enum@ietf.org; Thu, 25 Mar 2004 11:19:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6XYe-0004P5-00 for enum@ietf.org; Thu, 25 Mar 2004 11:18:16 -0500 Received: from maya20.nic.fr ([192.134.4.152]) by ietf-mx with esmtp (Exim 4.12) id 1B6XXh-0004KM-00 for enum@ietf.org; Thu, 25 Mar 2004 11:17:18 -0500 Received: from bug.nic.fr (bug.nic.fr [192.134.4.100]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id i2PGHHBb1077189; Thu, 25 Mar 2004 17:17:17 +0100 (CET) Received: from nic.fr (unknown [192.134.4.100]) by bug.nic.fr (Postfix) with SMTP id 8EEB818F5F1; Thu, 25 Mar 2004 11:08:58 -0500 (EST) Date: Thu, 25 Mar 2004 17:08:58 +0100 From: "Samia M'timet" To: Jim Reid Cc: Richard.Stastny@oefeg.at, md@bts.sk, lwc@roke.co.uk, enum@ietf.org Subject: Re: [Enum] Summary on NoPSTN dicussion Message-Id: <20040325170858.57bc86db.samia.mtimet@nic.fr> In-Reply-To: <14760.1080228215@gromit.rfc1035.com> References: <06CF906FE3998C4E944213062009F162233C3E@oefeg-s02.oefeg.loc> <14760.1080228215@gromit.rfc1035.com> Organization: AFNIC X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 25 Mar 2004 15:23:35 +0000 Jim Reid wrote: > > There's no need for wildcards or shadow tree ickiness. And it's nice > and clean for things like 800 and 900 numbers or DDI blocks. Calls to > these numbers will get shunted to the right "gateway". This does of > course make things a little bit trickier for a Tier-1 registry that > delegates every individual E.164 number. > ==> This is the option we followed for the User-ENUM french trial : we stuck at the *real* numbering resources allocation. At Tier-1 registry we delegate blocks of E.164 numbers as they are in the real numbering plan. Consequences : - no "validation" problems - no need for a ".tel" alternative root for Infrastructure-ENUM -- Samia M'timet AFNIC _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 16:03:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23211 for ; Thu, 25 Mar 2004 16:03:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6c0L-00081X-PM for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 16:03:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PL3906030797 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 16:03:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6c0D-0007zX-GC; Thu, 25 Mar 2004 16:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6bzJ-0007o0-9I for enum@optimus.ietf.org; Thu, 25 Mar 2004 16:02:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22887 for ; Thu, 25 Mar 2004 16:02:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6bzH-0001Gm-00 for enum@ietf.org; Thu, 25 Mar 2004 16:02:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6by7-00014M-00 for enum@ietf.org; Thu, 25 Mar 2004 16:00:52 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B6bx1-0000nN-00 for enum@ietf.org; Thu, 25 Mar 2004 15:59:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: AW: [Enum] Summary on NoPSTN dicussion MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 25 Mar 2004 21:59:05 +0100 Message-ID: <06CF906FE3998C4E944213062009F162233C4A@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQShKX7EYxahsI7Tz+bxIhrTQPbKwAJwuwh From: "Stastny Richard" To: "Samia M'timet" , "Jim Reid" Cc: , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 U2FtaWEgd3JvdGU6DQo9PT4gVGhpcyBpcyB0aGUgb3B0aW9uIHdlIGZvbGxvd2VkIGZvciB0aGUg VXNlci1FTlVNIGZyZW5jaCB0cmlhbCA6IHdlIHN0dWNrIGF0IHRoZSAqcmVhbCogbnVtYmVyaW5n IHJlc291cmNlcyBhbGxvY2F0aW9uLiBBdCBUaWVyLTEgcmVnaXN0cnkgd2UgZGVsZWdhdGUgYmxv Y2tzIG9mIEUuMTY0IG51bWJlcnMgYXMgdGhleSBhcmUgaW4gdGhlIHJlYWwgbnVtYmVyaW5nIHBs YW4uDQoNCkNvbnNlcXVlbmNlcyA6DQoNCi0gbm8gInZhbGlkYXRpb24iIHByb2JsZW1zDQoNCi0g bm8gbmVlZCBmb3IgYSAiLnRlbCIgYWx0ZXJuYXRpdmUgcm9vdCBmb3IgSW5mcmFzdHJ1Y3R1cmUt RU5VTQ0KDQpBZ3JlZWQsIGJ1dCB0aGUgcmVhc29uIGlzIHRoYXQgdGhlIEZyZW5jaCB0cmlhbCBp cyBJTUhPIG1vcmUgaW5mcnN0cnVjdHVyZSBFTlVNIHRoYW4gVXNlci1FTlVNIDstKQ0KUmljaGFy ZA0KDQoNCg== _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 16:14:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24954 for ; Thu, 25 Mar 2004 16:14:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cAv-0000pc-5w for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 16:14:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PLE58u003184 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 16:14:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cAr-0000oR-EV; Thu, 25 Mar 2004 16:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cAR-0000kK-AG for enum@optimus.ietf.org; Thu, 25 Mar 2004 16:13:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24757 for ; Thu, 25 Mar 2004 16:13:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6cAP-0003Hu-00 for enum@ietf.org; Thu, 25 Mar 2004 16:13:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6c8W-0002yq-00 for enum@ietf.org; Thu, 25 Mar 2004 16:11:38 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B6c66-0002Qq-00 for enum@ietf.org; Thu, 25 Mar 2004 16:09:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: AW: [Enum] Summary on NoPSTN dicussion MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 25 Mar 2004 22:08:34 +0100 Message-ID: <06CF906FE3998C4E944213062009F162233C4C@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQSj0XlYscUPgDoR+iOMwEIYvBVGwAHSNqe From: "Stastny Richard" To: "Otmar Lendl" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 T3RobWFyIHdyb3RlOg0KDQoJDQoNCgk+dGhpcyBpcyBhIGN1dGUgaWRlYSwgZXNwZWNpYWxseSBm b3IgRERJIG9uIFBCWGVzLiBGb3IgODAwIG51bWJlcnMsDQoJPnRoaXMgY291bGQgYmUgYSByZXBs YWNlbWVudCBmb3IgZnJlZW51bS5vcmcuDQoJIA0KCUlNSE8gaWYgaXQgb25seSBzb2x2ZXMgdGhp cyBwcm9ibGVtLCBpdCBpcyB3b3J0aCBwdXJzdWluZyBpdA0KCQ0KCUkgc2VlIGlzc3VlcyAobm90 IHNob3dzdG9wcGVycykgd2l0aCBpdCwgdGhvdWdoOg0KCQ0KCT4qIEknbSBub3Qgc3VyZSB3aGV0 aGVyIHRoZSBjdXJyZW50IHJlc29sdmVyIGxpYnJhcmllcyBhcmUgZGVzaWduZWQNCgk+dG8gcGFz cyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHJldHVybmVkIGluIGFuIGVycm9yIHJlc3BvbnNlIGJh Y2sgdG8NCgk+dGhlIGNhbGxpbmcgYXBwbGljYXRpb24uIFRoZSB0eXBpY2FsIGdldGhvc3RieW5h bWUgLSB0eXBlIGZ1bmN0aW9ucw0KCT5jZXJ0YWlubHkgZG9uJ3QuIEkgaGF2ZW4ndCBzZWVuIGEg c3RhbmRhcmRpc2VkIEFQSSB0byBOQVBUUg0KCT5xdWVyaWVzIHlldCAoYWxsIHRoZSBjb2RlIEkg aGF2ZSBzZWVuIChhc3Rlcmlzaywgc2VyKSBieSBub3cgZG9lcw0KCT5tYW51YWwgcmVzcG9uc2Ug cGFyc2luZyAtLSB5dWNrLiksIG1heWJlIHlvdSdyZSBlYXJseSBlbm91Z2ggdG8NCgk+Z2V0IHRo aXMgYWRkZWQuDQoJIA0KCUFsbCBwcm9wb3NlZCBzb2x1dGlvbiBuZWVkIHNvbWUgY2hhbmdlcywg c28gd2UgY291bGQgY29tZSB0byBhIHJlc3VsdCBzb29uLg0KCQ0KCT4qIFRoZSBzY2hlbWUgb25s eSB3b3JrcyBvbiB6b25lIGJvdW5kYXJpZXMuIElmIHdlIChhcyAzLjQuZTE2NC5hcnBhIFRpZXIx KQ0KCT53ZXJlIHRvIGltcGxlbWVudCB0aGlzIG9uICs0Mzc4MCAod2hpY2ggaXMgdW5kZXIgZGlz Y3Vzc2lvbiBhcyBFTlVNLW9ubHkNCgk+bnVtYmVyIHJhbmdlKSB3ZSB3b3VsZCBoYXZlIHRvIGRl bGVnYXRlIDAuOC43LjMuNC5lMTY0LmFycGEgdG8gb3Vyc2VsdmVzDQoJPmZpcnN0LCBhbmQgdGhl biBkZWxlZ2F0ZSBpbmRpdmlkdWFsIG51bWJlcnMgZnJvbSB3aXRoaW4gdGhhdCB6b25lLg0KCSAN CglZZXMsIEppbSBtZW50aW9uZWQgdGhpcyBhbHJlYWR5LCBidXQgYW55IHNvbHV0aW9uIHB1dGlu ZyBhIHJlY29yZCBpbnRvDQoJdGhlIHRyZWUgaGFzIHRoZSBzYW1lIHByb2JsZW0uIEJ1dCBpdCBj YW4gYmUgZG9uZS4NCglJZiB5b3Ugd2FudCB0byBhdm9pZCB0aGlzLCB5b3UgbmVlZCBhIHNlY29u ZCB0cmVlLg0KCQ0KCT5UaGF0IHZpb2xhdGVzIG91ciBiYXNpYyBhc3N1bXB0aW9uIHRoYXQgYWxs IGRlbGVnYXRpb24gZnJvbSB0aGUgVGllcjENCgk+d2lsbCBiZSB3aXRoaW4gdGhlIDMuNC5lMTY0 LmFycGEgem9uZS4gWWVzLCBvbmUgY2FuIHByb2dyYW0gYXJvdW5kDQoJPnRoYXQsIGJ1dCBpdCBj ZXJ0YWlubHkgd29uJ3QgbWFrZSB0aGluZ3MgZWFzaWVyIGZvciB1cy4NCgkNCglXaG8gc2FpZCBs aXZlIGlzIGVhc3kgOy0pLCBJIGFsd2F5cyB0aG91Z2h0IHlvdSBsaWtlZCBhIGNoYWxsZW5nZQ0K CSANCglSaWNoYXJkDQoJIA0KCSANCg0K _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 16:23:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25407 for ; Thu, 25 Mar 2004 16:23:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cJc-0001qK-Gb for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 16:23:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PLN4KG007078 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 16:23:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cJY-0001pp-S2; Thu, 25 Mar 2004 16:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cJ0-0001pJ-Rz for enum@optimus.ietf.org; Thu, 25 Mar 2004 16:22:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25356 for ; Thu, 25 Mar 2004 16:22:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6cIz-0003tp-00 for enum@ietf.org; Thu, 25 Mar 2004 16:22:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6cI1-0003qy-00 for enum@ietf.org; Thu, 25 Mar 2004 16:21:25 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B6cH4-0003n6-00 for enum@ietf.org; Thu, 25 Mar 2004 16:20:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: AW: [Enum] Summary on NoPSTN dicussion MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 25 Mar 2004 22:19:54 +0100 Message-ID: <06CF906FE3998C4E944213062009F162233C4D@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQSj8vKEcVRgKZQSmiE15Asru43SAAHaCHn From: "Stastny Richard" To: "Jim Reid" Cc: "Marian Durkovic" , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 IA0KDQoJDQoNCgk+ICAgIFJpY2hhcmQ+IFNvIGlmIGEgY2xpZW50IGdldHMgYSBOWERPTUFJTiwg aGUganVzdCBoYXMgdG8gZG8gYW5vdGhlcg0KCT4gICAgUmljaGFyZD4gbG9va3VwIHRvIFRoZSBk b21haW4gcmV0dXJuZWQgaW4gdGhlIFNPQS4NCgkNCgk+IFllcywgYnV0IGhlICpkb2Vzbid0KiBo YXZlIHRvIGRvIHRoaXMuIEhlIHNob3VsZCBvZiBjb3Vyc2UsIGJ1dC4uLg0KCSANCglJIHRoaW5r IHdlIHNob3VsZCBmaW5hbGx5IHdyaXRlIGhpcyB1cCBzb21ld2hlcmUNCgkNCgk+ICAgIFJpY2hh cmQ+IElmIGFnYWluIG5vIE5BUFRSIGlzIHJldHVybmVkLCBhbm90aGVyIFNPQSBpcyByZXR1cm4g ZnJvbQ0KCT4gICAgUmljaGFyZD4gdGhlIG5leHQgaGlnaGVyIHpvbmUuIFNvIGhlIHF1ZXJpZXMg aGVyZSBmb3IgTkFQVFIuDQoJDQoJPk5vcGUhIFRoZSBTT0EgcmVjb3JkIGlzIHJldHVybmVkIGZv ciB0aGUgY2xvc2VzdCBlbmNsb3Npbmcgem9uZTogdGhlDQoJPmRlbGVnYXRpb24gcG9pbnQuIExl dCdzIHRha2UgdGhlIGV4YW1wbGUgYWJvdmUuIEkgZ2V0IGFuIE5YRE9NQUlOIHdoZW4NCgk+bG9v a2luZyB1cCAwLjkuOC43LjYuNS40LjMuMi4xLmUxNjQuYXJwYS4gVGhlIFNPQSByZWNvcmQgZm9y IHRoZQ0KCT5uZWFyZXN0IGRlbGVnYXRpb24gcG9pbnQsIDUuNC4zLjIuMS5lMTY0LmFycGEsIGlz IHJldHVybmVkIGluIHRoYXQNCgk+cmVzcG9uc2UuIFNvIEkgbm93IGxvb2sgZm9yIGEgTkFQVFIg KHNheSkgZm9yIDUuNC4zLjIuMS5lMTY0LmFycGEuIElmDQoJPnRoaXMgZG9lc24ndCBleGlzdCwg SSBnZXQgYW4gTlhET01BSU4gYmFjay4gVGhpcyB0aW1lIHRoZSAqc2FtZSogU09BDQoJPnJlY29y ZCB3aWxsIGJlIHJldHVybmVkIGJlY2F1c2UgdGhlIDUuNC4zLjIuMS5lMTY0LmFycGEgem9uZSBp cyB0aGUNCgk+bmVhcmVzdCBkZWxlZ2F0aW9uIHBvaW50IHRvIDUuNC4zLjIuMS5lMTY0LmFycGEu DQoJDQoJPk5vdywgSSBzdXBwb3NlIGFuIChpZGlvdCkgYXBwbGljYXRpb24gY291bGQgd2FsayB1 cCB0aGUgdHJlZSwgdHJ5aW5nDQoJPjQuMy4yLjEuZTE2NC5hcnBhLCAzLjIuMS5lMTY0LmFycGEs IGV0YyBsb29raW5nIGZvciB0aGUgbmV4dCBoaWdoZXN0DQoJPmRlbGVnYXRpb24gcG9pbnQgYW5k IGh5cG90aGV0aWNhbCBkZWZhdWx0IE5BUFRSLiBCdXQgdGhpcyBpcyB1Z2x5IGFuZA0KCT5zaG91 bGQgYmUgYXZvaWRlZC4gSW1hZ2luZSB0aGUgaW1wbGljYXRpb25zIGZvciBhIDEwLTEyIGRpZ2l0 IHBob25lDQoJPm51bWJlci4NCgkgDQoJSWYgIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHkseW91 IHdvdWxkbnQgaGF2ZSB0byBnbyB1cCBkaWdpdCBwZXIgZGlnaXQuDQoJSWYgeW91IGhhdmUgYSBk ZWxlZ2F0aW9uIHBvaW50IGF0IDIuMS5lMTY0LmFycGEgYW5kDQoJYW5vdGhlciBvbmUgYnkgNS40 LjMuMi4xLmUxNjQuYXJwYSANCgkgDQoJeW91IHF1ZXJ5IGZvciA1LjQuMy4yLjEuZTE2NC5hcnBh IGFuZCBnZXQgYWdhaW4gTlhET01BSU4gd2l0aCBTT0EgNS40LjMuMi4xLmUxNjQuYXJwYQ0KCXNv IHlvdSBxdWVyeSBmb3IgNC4zLjIuMS5lMTY0LmFycGEgYW5kIGdldCBOWERPTUFJTiB3aXRoIFNP QSAyLjEuZTE2NC5hcnBhDQoJc28gSSBxdWVyeSBub3cgZm9yIDIuMS5lMTY0LmFycGENCglvciBk aWQgSSBnZXQgc29tZXRoaW5nIHdyb25nDQoJDQoJICAgID4+ICBCVFcsIHdoYXQgYWJvdXQgTk9E QVRBIHJlc3BvbnNlcyBmcm9tIHRoZSBETlM/IGllIFRoZSBuYW1lDQoJICAgID4+IGV4aXN0cywg YnV0IG5vdCBhcyB0aGUgUVRZUEUgKE5BUFRSPykgdGhhdCB3YXMgcmVxdWVzdGVkLi4uLg0KCQ0K CSAgICBSaWNoYXJkPiBbUmljaGFyZD5dIENvdWxkIHlvdSBwbGVhc2UgZWxhYm9yYXRlLCBJIGRv IG5vdA0KCSAgICBSaWNoYXJkPiB1bmRlcnN0YW5kIHRoaXMuDQoJDQoJPlN1cmUuIFN1cHBvc2Ug SSBhc2sgZm9yIE5BUFRScyBmb3IgMC45LjguNy42LjUuNC4zLjIuMS5lMTY0LmFycGEuDQoJPlRo ZXJlIGFyZW4ndCBhbnkuIEJ1dCB0aGUgbmFtZSBoYXMgYSBUWFQgcmVjb3JkLiBPciBhbiBNWCBy ZWNvcmQuDQoJPk9yLi4uIEluIHRoaXMgY2FzZSwgdGhlIHNlcnZlciByZXR1cm5zIGEgTk9EQVRB IHJlc3BvbnNlLiBUaGUgQW5zd2VyDQoJPlNlY3Rpb24gaXMgZW1wdHksIGJ1dCB0aGUgcmVwbHkn cyBzdGF0dXMgZmllbGQgaXMgTk9FUlJPUiwgbm90DQoJPk5YRE9NQUlOLiBUaGUgbmFtZSAwLjku OC43LjYuNS40LjMuMi4xLmUxNjQuYXJwYSBleGlzdHMsIGJ1dCBub3QgYXMNCgk+dGhlIFFUWVBF IC0tIE5BUFRSIGluIHRoaXMgZXhhbXBsZSAtLSB0aGF0IHdhcyBsb29rZWQgdXAuIFRoaXMgY29y bmVyDQoJPmNhc2UgbWF5IG5lZWQgdG8gYmUgY292ZXJlZC4gVGhlcmUncyBub3RoaW5nIGluIFJG QzI5MTYoYmlzKSB0aGF0IHNheXMNCgk+b25seSBOQVBUUiByZWNvcmRzIGNhbiBleGlzdCBhcyBs ZWFmIG5vZGVzIG9mIGUxNjQuYXJwYS4gQ2xpZW50cw0KCT5tdXN0L3Nob3VsZCBiZSBwcmVwYXJl ZCB0byBoYW5kbGUgYW55IGxlZ2FsIHJlc291cmNlIHJlY29yZHMgdGhhdA0KCT5jb3VsZCBnZXQg cmV0dXJuZWQuDQoJIA0KCW9rLiBCVFcgd2UgaGF2ZSBUWFQgcmVjb3JkcywgYnV0IG5vdCB3aXRo b3V0IE5BUFRScy4NCgkgDQoJUmljaGFyZA0KCQ0KDQo= _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 16:34:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25975 for ; Thu, 25 Mar 2004 16:34:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cUK-0002mk-Kk for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 16:34:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PLY8ZJ010652 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 16:34:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cUE-0002lA-BI; Thu, 25 Mar 2004 16:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cTp-0002fC-11 for enum@optimus.ietf.org; Thu, 25 Mar 2004 16:33:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25883 for ; Thu, 25 Mar 2004 16:33:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6cTn-0004P7-00 for enum@ietf.org; Thu, 25 Mar 2004 16:33:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6cSr-0004Lx-00 for enum@ietf.org; Thu, 25 Mar 2004 16:32:38 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B6cS5-0004Gh-00 for enum@ietf.org; Thu, 25 Mar 2004 16:31:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: AW: [Enum] Summary on NoPSTN dicussion MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 25 Mar 2004 22:31:17 +0100 Message-ID: <06CF906FE3998C4E944213062009F162233C4E@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQSkgbXSvSyJ50pT0G5swxtVPJ64wAHPg9x From: "Stastny Richard" To: "Otmar Lendl" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 T3RobWFyIHdyb3RlOg0KDQo+RXZlbiBpZiB0aGVyZSBhcmUgTkFQVFIgcmVjb3JkcywgeW91IHN0 aWxsIG1pZ2h0IG5vdCBnZXQgYSBOQVBUUiB3aXRoDQo+ZW51bXNlcnZpY2UgZm9yIHZvaWNlLiBN eSBndWVzcyBpcyB0aGF0IHlvdSBzaG91bGQgaGFuZGxlIGJvdGggY2FzZXMNCj5pbiB0aGUgc2Ft ZSB3YXkuDQoNClRoaXMgaXMgYW4gaW1wb3J0YW50IGFyZ3VtZW50LiBDdXJyZW50bHkgdGhlIGNh bGwgaW4gdGhpcyBjYXNlIGlzIGZvcndhcmRlZA0KdG8gdGhlIFBTVE4sIHNvIHdlIHNob3VsZCBl aXRoZXIgZGVjaWRlIG5vdCB0byBkbyB0aGlzIG9yIHdlIG5lZWQgYSBzb2x1dGlvbg0KdG8gZ2V0 IHRoZSBpbmZvcm1hdGlvbiBmcm9tIGRlbGVnYXRpb24gcG9pbnQuIElzIHRoZXJlIGEgd2F5IHRv IGZpbmQgdGhpcyBvdXQ/DQogDQpPZiBjb3Vyc2UsIGlmIHdlIGNob29zZSB2YXJpYW50IEIgKHRo ZSBnbG9iYWwgc2hhZG93IHRyZWUpIHRoZXJlIHdvdWxkIGJlIG5vIHByb2JsZW0uDQogDQpSaWNo YXJkDQo= _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 17:45:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29243 for ; Thu, 25 Mar 2004 17:45:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6db3-0003od-V6 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 17:45:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PMj91u014626 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 17:45:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6dau-0003n3-OW; Thu, 25 Mar 2004 17:45:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6daR-0003mH-Kg for enum@optimus.ietf.org; Thu, 25 Mar 2004 17:44:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29108 for ; Thu, 25 Mar 2004 17:44:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6daP-000187-00 for enum@ietf.org; Thu, 25 Mar 2004 17:44:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6dZW-00012V-00 for enum@ietf.org; Thu, 25 Mar 2004 17:43:35 -0500 Received: from gromit.rfc1035.com ([195.54.233.67]) by ietf-mx with esmtp (Exim 4.12) id 1B6dYZ-0000x0-00 for enum@ietf.org; Thu, 25 Mar 2004 17:42:35 -0500 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i2PMgXRv015520; Thu, 25 Mar 2004 22:42:33 GMT To: "Stastny Richard" cc: "Marian Durkovic" , lwc@roke.co.uk, enum@ietf.org Subject: Re: AW: [Enum] Summary on NoPSTN dicussion In-Reply-To: Message from "Stastny Richard" of "Thu, 25 Mar 2004 22:19:54 +0100." <06CF906FE3998C4E944213062009F162233C4D@oefeg-s02.oefeg.loc> Date: Thu, 25 Mar 2004 22:42:33 +0000 Message-ID: <15519.1080254553@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Richard" == Stastny Richard writes: Richard> I think we should finally write his up somewhere Yes, I agree. A draft on resolver behaviour for ENUM applications is needed. This might lead on to documenting and recommending an API for ENUM-aware applications. Another follow-on could be something about a standard naming convention for the default "whatever" -- SIP gateway, web server, etc -- for some delegation point. This is a bit like the idea the RIPE DNS WG had for locating whois servers with SRV records. >> Now, I suppose an (idiot) application could walk up the tree, >> trying 4.3.2.1.e164.arpa, 3.2.1.e164.arpa, etc looking for the >> next highest delegation point and hypothetical default >> NAPTR. But this is ugly and should be avoided. Imagine the >> implications for a 10-12 digit phone number. Richard> If I understand it correctly,you wouldnt have to go up Richard> digit per digit. If you have a delegation point at Richard> 2.1.e164.arpa and another one by 5.4.3.2.1.e164.arpa Yes. But it would be less offensive to go down the tree and get the actual delegation points than go upwards trying to guess where they are. A downwards traversal of the tree is how DNS works anyway. And name servers will be caching the delegation info as they're resolving queries. So the name servers should already know where delegations occur without having to guess where they might be. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 19:45:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05923 for ; Thu, 25 Mar 2004 19:45:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6fTO-0002jQ-CN for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 19:45:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q0jMKS010486 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 19:45:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6fT3-0002i0-Pe; Thu, 25 Mar 2004 19:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6fSe-0002gK-VF for enum@optimus.ietf.org; Thu, 25 Mar 2004 19:44:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05902 for ; Thu, 25 Mar 2004 19:44:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6fSd-0001Eh-00 for enum@ietf.org; Thu, 25 Mar 2004 19:44:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6fRf-0001BH-00 for enum@ietf.org; Thu, 25 Mar 2004 19:43:36 -0500 Received: from blount.mail.mindspring.net ([207.69.200.226]) by ietf-mx with esmtp (Exim 4.12) id 1B6fQk-000182-00 for enum@ietf.org; Thu, 25 Mar 2004 19:42:38 -0500 Received: from 1cust124.tnt36.dfw9.da.uu.net ([67.234.81.124] helo=ix.netcom.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1B6fQe-00051s-00; Thu, 25 Mar 2004 19:42:32 -0500 Message-ID: <406396C9.49247A60@ix.netcom.com> Date: Thu, 25 Mar 2004 18:34:53 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: "Clive D.W. Feather" CC: enum@ietf.org, "Harald@alvestrand.no" Subject: Re: [Enum] Summary on NoPSTN dicussion References: <06CF906FE3998C4E944213062009F162233C3E@oefeg-s02.oefeg.loc> <20040325142506.GB20735@finch-staff-1.thus.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Clive and all, Clive D.W. Feather wrote: > Stastny Richard said: > > B. use a (one, common) second common tree (e164shadow.arpa, where you put > > in only the wildcards for the number ranges in question. The processing > > assumption now should be: > [...] > > C. Use individual second shadow trees, eg on a national level, eg in > > Austria e164shadow.at would be used. The problem here is how one can > > find out the domain names of the individual trees. > > One solution is to do it with a table in each server (which is not good). > > > > The other solution is to put pointers in e164.arpa, eg SRV RR or even MX RR. > [...] > > Since the structure of the delegations in e164.arpa varies (Tier 1 levels), > > there is no easy way to find out the level of the pointers, even if they are > > only on the Tier 1 layer. > > If the shadow tree is shadow.e164.arpa, and if the delegation rule is that > the national authority getting .e164.arpa is also delegated > .shadow.e164.arpa (so the UK Tier 1 operator has both 4.4.e164.arpa and > 4.4.shadow.e164.arpa), doesn't that give you both B and C without needing > to create another special SLD? I think it does, yes. Nicely illustrated.. > > > Obviously, "shadow" can be replaced by something shorter if felt desirable, > such as "w" (for "wildcards"). Ah yes! Good point here as well... But Harald wont agree or like it anyway... :/ > > > -- > Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 > Internet Expert | Home: | *** NOTE CHANGE *** > Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 > Thus plc | | Mobile: +44 7973 377646 > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Mar 25 21:34:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09967 for ; Thu, 25 Mar 2004 21:34:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6hAh-0001Pi-HB for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 21:34:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q2YB7k005430 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 21:34:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6hAW-0001Nq-Uq; Thu, 25 Mar 2004 21:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6hAG-0001Il-GP for enum@optimus.ietf.org; Thu, 25 Mar 2004 21:33:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09919 for ; Thu, 25 Mar 2004 21:33:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6hAD-0000r0-00 for enum@ietf.org; Thu, 25 Mar 2004 21:33:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6h9H-0000mw-00 for enum@ietf.org; Thu, 25 Mar 2004 21:32:44 -0500 Received: from tisch.mail.mindspring.net ([207.69.200.157]) by ietf-mx with esmtp (Exim 4.12) id 1B6h8X-0000ji-00 for enum@ietf.org; Thu, 25 Mar 2004 21:31:57 -0500 Received: from 1cust84.tnt36.dfw9.da.uu.net ([67.234.81.84] helo=ix.netcom.com) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1B6h8U-0007lo-00; Thu, 25 Mar 2004 21:31:55 -0500 Message-ID: <4063B06F.74F8C76A@ix.netcom.com> Date: Thu, 25 Mar 2004 20:24:16 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Kieran Baker CC: icann board address , enum@ietf.org Subject: Re: [Enum] .TEL and ENUM? References: <200403260143.i2Q1hiq26956@hudson.icann.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kieran, I am reluctant to yet again add to the "Black Holes" non-published prominently ICANN's idea of public comments on anything. Rather a more honest public forum would be more reasonable and available... However, I shall consider your offer, such as it is and pass it along to our members... Oh, and by the way open until April when/what? Kieran Baker wrote: > A public comment period will open in April and I'll be happy add yours, > Kind Regards > > -----Original Message----- > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > Sent: Wednesday, March 24, 2004 5:38 PM > To: Jaap Akkerhuis > Cc: enum@ietf.org; icann board address; baker@icann.org > Subject: Re: [Enum] .TEL and ENUM? > > Jaap and all, > > Commenting to ICANN directly might help but I doubt it.. > The two bids for .TEL are two different views of the confidence > in the direction the IETF has taken with ENUM, admitted or > not... > > Jaap Akkerhuis wrote: > > > They can already to that in tel.pulver.com. A new TLD is not > > needed. > > > > Apart from that, note that the other .tel bid excludes ENUM-style > > use. > > > > If I recall correctly, with the previous bunch of new TLDs, ICANN > > decided that if there were multiple bids for the same name, the > > parties should make a combined bid. They refused to choose. (Or > > maybe this was just the position of some board members). Something > > like that might happen again. > > > > Note that the comment periode start the 1st of April (no joke). It > > might be better to comment to ICANN directly then on this list. > > > > jaap > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > Regards, > > -- > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > "Be precise in the use of words and expect precision from others" - > Pierre Abelard > > "If the probability be called P; the injury, L; and the burden, B; > liability depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security > IDNS. div. of Information Network Eng. INEG. INC. > E-Mail jwkckid1@ix.netcom.com > Registered Email addr with the USPS > Contact Number: 214-244-4827 Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Mar 26 03:41:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07400 for ; Fri, 26 Mar 2004 03:41:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6mtw-000530-R2 for enum-archive@odin.ietf.org; Fri, 26 Mar 2004 03:41:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q8fGk8019397 for enum-archive@odin.ietf.org; Fri, 26 Mar 2004 03:41:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6mth-000521-Qg; Fri, 26 Mar 2004 03:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6mtZ-00051c-4p for enum@optimus.ietf.org; Fri, 26 Mar 2004 03:40:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07384 for ; Fri, 26 Mar 2004 03:40:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6mtW-0005yf-00 for enum@ietf.org; Fri, 26 Mar 2004 03:40:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6msg-0005uz-00 for enum@ietf.org; Fri, 26 Mar 2004 03:39:58 -0500 Received: from us.svf.stuba.sk ([147.175.16.9]) by ietf-mx with esmtp (Exim 4.12) id 1B6msG-0005pR-00 for enum@ietf.org; Fri, 26 Mar 2004 03:39:32 -0500 Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.11/8.12.11) with ESMTP id i2Q8cxuf091369; Fri, 26 Mar 2004 09:38:59 +0100 (CET) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.11/8.12.11/Submit) id i2Q8ch8q091349; Fri, 26 Mar 2004 09:38:43 +0100 (CET) (envelope-from md) Date: Fri, 26 Mar 2004 09:38:43 +0100 From: Marian Durkovic To: Jim Reid Cc: Stastny Richard , lwc@roke.co.uk, enum@ietf.org Subject: Re: AW: [Enum] Summary on NoPSTN dicussion Message-ID: <20040326083843.GA89978@us.svf.stuba.sk> References: <06CF906FE3998C4E944213062009F162233C4D@oefeg-s02.oefeg.loc> <15519.1080254553@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15519.1080254553@gromit.rfc1035.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > Richard> If I understand it correctly,you wouldnt have to go up > Richard> digit per digit. If you have a delegation point at > Richard> 2.1.e164.arpa and another one by 5.4.3.2.1.e164.arpa > > Yes. But it would be less offensive to go down the tree and get the > actual delegation points than go upwards trying to guess where they > are. A downwards traversal of the tree is how DNS works anyway. And > name servers will be caching the delegation info as they're resolving > queries. So the name servers should already know where delegations > occur without having to guess where they might be. Jim, how would you like to do that? Going up the tree is easy - the authority section will give you the information about the current delegation zone, so you only need 1 query per delegation, as Richard pointed out. But there's no query to learn the delegation downwards... With kind regards, -------------------------------------------------------------------------- ---- ---- ---- Marian Durkovic network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 524 51 301 ---- ---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail/sip: md@bts.sk ---- ---- ---- -------------------------------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Mar 26 14:16:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09209 for ; Fri, 26 Mar 2004 14:16:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6woU-0004X3-9N for enum-archive@odin.ietf.org; Fri, 26 Mar 2004 14:16:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QJGI95017383 for enum-archive@odin.ietf.org; Fri, 26 Mar 2004 14:16:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6woN-0004Um-Ix; Fri, 26 Mar 2004 14:16:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6woB-0004PK-7j for enum@optimus.ietf.org; Fri, 26 Mar 2004 14:15:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08984 for ; Fri, 26 Mar 2004 14:15:56 -0500 (EST) From: paf@cisco.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6wo8-0006ol-00 for enum@ietf.org; Fri, 26 Mar 2004 14:15:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6wmh-0006at-00 for enum@ietf.org; Fri, 26 Mar 2004 14:14:28 -0500 Received: from ool-44c3a526.dyn.optonline.net ([68.195.165.38] helo=ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1B6wlL-0006LE-00 for enum@ietf.org; Fri, 26 Mar 2004 14:13:03 -0500 To: enum@ietf.org Date: Fri, 26 Mar 2004 14:13:04 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.8 required=5.0 tests=MICROSOFT_EXECUTABLE, MIME_BOUND_NEXTPART,MISSING_MIMEOLE,MSGID_FROM_MTA_SHORT,NO_REAL_NAME, PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.1 MICROSOFT_EXECUTABLE RAW: Message includes Microsoft executable program * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.2 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Subject: [Enum] Re: Mail Authentification Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Please authenticate the secure message. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: details.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ------=_NextPart_000_0016----=_NextPart_000_0016-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Mar 26 17:11:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20354 for ; Fri, 26 Mar 2004 17:11:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6zXn-0008Ek-Rf for enum-archive@odin.ietf.org; Fri, 26 Mar 2004 17:11:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QMBFN4031659 for enum-archive@odin.ietf.org; Fri, 26 Mar 2004 17:11:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6zXa-0008Dw-FN; Fri, 26 Mar 2004 17:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6zWv-0008DW-Kf for enum@optimus.ietf.org; Fri, 26 Mar 2004 17:10:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20309 for ; Fri, 26 Mar 2004 17:10:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6zWt-0006FF-00 for enum@ietf.org; Fri, 26 Mar 2004 17:10:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6zVx-0006CJ-00 for enum@ietf.org; Fri, 26 Mar 2004 17:09:23 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B6zVg-00069L-00 for enum@ietf.org; Fri, 26 Mar 2004 17:09:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: WG: [Iptel] FW: [Enum] Summary on NoPSTN dicussion MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 26 Mar 2004 23:08:27 +0100 Message-ID: <06CF906FE3998C4E944213062009F162233C5E@oefeg-s02.oefeg.loc> Thread-Topic: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQTUR402UkZTl1DThiuqW1cXdUE1AALaNOu From: "Stastny Richard" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 RnJvbSBpcHRlbCBhbmQgc2lwcGluZyBsaXN0czoNCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFj aHJpY2h0LS0tLS0gDQoJVm9uOiBNaWNoYWVsIEhhbW1lciBbbWFpbHRvOm1oYW1tZXJAY2lzY28u Y29tXSANCglHZXNlbmRldDogRnIgMjYuMDMuMjAwNCAxNzo0MCANCglBbjogU3Rhc3RueSBSaWNo YXJkIA0KCUNjOiBpcHRlbEBpZXRmLm9yZzsgc2lwcGluZ0BpZXRmLm9yZyANCglCZXRyZWZmOiBS ZTogW0lwdGVsXSBGVzogW0VudW1dIFN1bW1hcnkgb24gTm9QU1ROIGRpY3Vzc2lvbg0KCQ0KCQ0K DQoJUmljaGFyZCwNCgkNCglHb2luZyBvdXQgb24gYSBsaW1iIGhlcmUsIHNpbmNlIEkgaGF2ZSBu b3Qgc2VlbiBhbGwgdGhlIHJlZmVyZW5jZWQNCglkaXNjdXNzaW9ucy4gIE15IGZpcnN0IGltcHJl c3Npb24gaXMgdGhhdCB0aGUgZGVzY3JpcHRpb24gYmVsb3cgaXMgb3ZlcmxheQ0KCWNvbXBsZXgu DQoJDQoJSSBoYXZlIGEgY29uY2VybiB0aGF0IHlvdSBhcHBlYXIgdG8gYmUgcHJvcG9zaW5nIHRo YXQgdGhlIEVOVU0gZGlwIHdvdWxkDQoJaGF2ZSBkZWZpbml0aXZlIGFuc3dlcnMgdG86DQoJYSkg d2hldGhlciBhIG51bWJlciBoYXMgYmVlbiBhc3NpZ25lZCBhbmQgdGhlcmVmb3JlIHJvdXQtYWJs ZSwNCgliKSB3aGV0aGVyIGEgbnVtYmVyIHRoYXQgaXMgYXNzaWduZWQgd2FzIGRvbmUsIGFuZCBp ZiBzbyB3aGV0aGVyIHRvIGEgUFNUTg0KCWVuZHBvaW50IG9yIGFuIElQIGVuZHBvaW50Lg0KCQ0K CUFub3RoZXIgY29uY2VybiBpcyB0aGF0LCBpZiB5b3UgZG8gZ2V0IGxvb3BlZCByb3V0aW5nIGJl dHdlZW4gdGhlIElQIGRvbWFpbg0KCWFuZCB0aGUgVERNIGRvbWFpbiwgdGhpcyBpcyBsaWtlbHkg YW4gaW5kaWNhdGlvbiBvZiBhIGxhY2sgb2YNCglzeW5jaHJvbml6YXRpb24gYmV0d2VlbiB0aGUg RU5VTSBkYXRhYmFzZSBhbmQgdGhlIExOUCBkYXRhYmFzZS4gIE9uZSBvciB0aGUNCglvdGhlciBo YXMgaW5jb3JyZWN0IGRhdGEuICBJIHN1c3BlY3QgdGhhdCB0aGVyZSBtYXkgYmUgdGltZSBsYWdz IGZyb20gd2hlbg0KCWFuIFNQIGFzc2lnbnMgYSBudW1iZXIgYW5kIHdoZW4gaXQgZ2V0cyByZWZs ZWN0ZWQgaW4gb25lIG9yIGFub3RoZXINCglkYXRhYmFzZXMuICBJZiB5b3Ugd2FudCB0aGUgRU5V TSBhbmQgTE5QIGRhdGFiYXNlcyB0byBiZSBzb21ld2hhdA0KCWluZGVwZW5kZW50LCB5b3UgbWln aHQgd2FudCBhIGxvb3NlIGNvdXBsaW5nIG9mIHRoZSB1c2Ugb2YgdGhlIHR3byBzeXN0ZW1zOg0K CQ0KCSAgLUlmIGVuZHBvaW50IGlzIFRETSwgdGhlbiB0aGUgRU5VTSBkYXRhYmFzZSBzaG91bGQg cG9pbnQgdG8gdGhlIFBTVE4sDQoJd2l0aCBkZWZhdWx0IGJlaGF2aW9yIGJlaW5nLCBpZiB1bmtu b3duIHRvIEVOVU0sIHNlbmQgdG8gUFNUTiB0bw0KCXJlc29sdmUuICAoTm90ZSB0aGlzIGlzIG9y dGhvZ29uYWwgdG8gRU5VTXMgdXNlIHRvIHNlbGVjdCBhbHRlcm5hdGl2ZQ0KCWVuZHBvaW50cy4p DQoJDQoJICAtIElmIGVuZHBvaW50IGlzIElQLCB0aGVuIHRoZSBMTlAgZGF0YWJhc2VzIHNob3Vs ZCBwb2ludCB0byB0aGUgSVANCglkb21haW4sIHdpdGggZGVmYXVsdCBiZWhhdmlvciBiZWluZywg aWYgdW5rbm93biB0byBMTlAsIHJvdXRlIGluIHRoZSBQU1RODQoJdG8gcmVzb2x2ZS4NCgkNCglU aGUgZGlmZmVyZW5jZSBpcyBpbiB0aGUgaW50ZXJwcmV0YXRpb24gb2YgYSBsYWNrIG9mIGEgcmVj b3JkLiAgSW4gTE5QLCBpdA0KCXdvdWxkIG1lYW4gdGhhdCB0aGUgRS4xNjQgbnVtYmVyIGlzIHN0 aWxsIG93bmVkIGJ5IHRoZSBvcmlnaW5hbCBzd2l0Y2gsDQoJd2hlcmVhcyBpbiBFTlVNIGl0IHdv dWxkIG1lYW4gdGhhdCB0aGUgRS4xNjQgbnVtYmVyIGlzIG5vdCByb3V0ZS1hYmxlIHRvIGFuDQoJ SVAgZW5kcG9pbnQuICBGcm9tIGEgVERNIHBlcnNwZWN0aXZlLCB0aGUgZW50aXJlIElQIGRvbWFp biBjb3VsZCBiZSB2aWV3ZWQNCglhcyBhIHNpbmdsZSBzd2l0Y2ggYW5kIHRoZSBMTlAgcm91dGlu ZyBzY2hlbWUgc2hvdWxkIHdvcmsuICBUaGUgY29udmVyc2UNCgkod2hlbiByZWNvcmRzIGV4aXN0 KSBjb3VsZCBiZSB0cnVlIGZvciBFTlVNLg0KCQ0KCUEgZ2F0ZXdheSBiZXR3ZWVuIElQLWRvbWFp biBhbmQgVERNIGRvbWFpbiwgdXBvbiBzZWVpbmcgdGhhdCBib3RoIGFuIExOUA0KCWFuZCBhbiBF TlVNIGRpcCBoYXZlIG5vdCByZXNvbHZlZCB0aGUgcm91dGUsIGNhbiBzYWZlbHkgY29uY2x1ZGUg dGhhdCB0aGUNCgludW1iZXIgaXMgdW5hc3NpZ25lZCBhbmQgcmVsZWFzZSB0aGUgY2FsbC4NCgkN CglBY3R1YWxseSwgaXQgbWF5IG5vdCBiZSBuZWNlc3NhcnkgdG8gc2VuZCBhIHNldHVwIG1lc3Nh Z2UgdG8gYSBHVywgbm9yIGlzDQoJaXQgbmVjZXNzYXJ5IHRvIGhhdmUgdGhlIEVOVU0gYW5kIExO UCBkYXRhYmFzZXMgZHVwbGljYXRlIGVhY2ggb3RoZXIuICBJdA0KCXNob3VsZCBiZSBzdWZmaWNp ZW50IGZvciBhbiBFTlVNIERCIHRvIHF1ZXJ5IHRoZSBMTlAgREIgYW5kIHJlc3BvbmQgd2l0aCBh bg0KCWFwcHJvcHJpYXRlIGFuc3dlciwgb3IgdGhlIGNvbnZlcnNlLg0KCQ0KCU1pa2UNCgkNCgkN CglBdCAwNDoyMiBQTSAzLzI1LzIwMDQgKzAxMDAsIFN0YXN0bnkgUmljaGFyZCB3cm90ZToNCgk+ Q3Jvc3MgcG9zdGluZyBmcm9tIGVudW1AaWV0Zi5vcmcNCgk+VGhlIGRpc2N1c3Npb24gaXMgZ29p bmcgb24gdGhlIGVudW0tbGlzdA0KCT4NCgk+UmljaGFyZCBTdGFzdG55DQoJPk9lRkVHDQoJPis0 MyA2NjQgNDIwIDQxMDANCgk+DQoJPg0KCT4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCT5G cm9tOiBTdGFzdG55IFJpY2hhcmQNCgk+U2VudDogVGh1cnNkYXksIE1hcmNoIDI1LCAyMDA0IDE6 MDggUE0NCgk+VG86IE1hcmlhbiBEdXJrb3ZpYzsgbHdjQHJva2UuY28udWsNCgk+Q2M6IGVudW1A aWV0Zi5vcmcNCgk+U3ViamVjdDogW0VudW1dIFN1bW1hcnkgb24gTm9QU1ROIGRpY3Vzc2lvbg0K CT4NCgk+RGVhciBjb2xsZWFndWVzLA0KCT4NCgk+VGhlcmUgd2FzIGEgbG90IG9mIGRpc2N1c3Np b25zIG9uLWxpc3QgYW5kIG9mZi1saXN0IG9uIHRoaXMgaXNzdWUsDQoJPnNvIEkgd2lsbCB0cnkg dG8gc3VtbWFyaXplIGF0IGxlYXN0IG15IHZpZXcgb2YgdGhlIHByb2JsZW0uDQoJPkkgd2lsbCBh bHNvIGluY2x1ZGUgbXkgY3VycmVudCB2aWV3IG9uIHRoZSA7ZW51bWRpDQoJPmFuZCB0aGUgO3Bz dG4gaW5kaWNhdG9yIGZvciB0aGUgdGVsOiBVUkkNCgk+DQoJPkVOVU0tZW5hYmxlZCBVQXMgYW5k IFNlcnZlcnMgYXJlIGN1cnJlbnRseSBwcm9jZXNzaW5nDQoJPnJlY2VpdmVkIEUuMTY0IG51bWJl cnMgKGVpdGhlciBpbiBhIHRlbDoreHh4IFVSSSBvciBpbiBhIHNpcDogVVJJDQoJPmluIHRoZSBm b3JtYXQgc2lwOit4eHh4QHByb2MubmV0O3VzZXI9cGhvbmUpIGluIHRoZSBmb2xsb3dpbmcgd2F5 Og0KCT4oZm9yIHNpbXBsaWNpdHkgSSBhbSBvbmx5IGRlYWxpbmcgd2l0aCB2b2ljZSBjYWxscykN Cgk+UGxlYXNlIGhvbGxlciBpZiBJIGdvdCBzb21ldGhpbmcgd3Jvbmcgb3IgeW91IGRpc2FncmVl DQoJPg0KCT4xLiBRdWVyeSBFTlVNIChpbiBlMTY0LmFycGEpDQoJPg0KCT4yLiBpZiBhIE5BUFRS IGlzIGZvdW5kIHdpdGggYW4gImVudW1zZXJ2aWNlIiBzaXAgb3Igdm9pY2U6c2lwLA0KCT5oYW5k bGUgdGhlIGNhbGwgYXMgaWYgeW91IGhhdmUgcmVjZWl2ZWQgYSBzaXA6IFVSSSBpbiB0aGUgZm9y bWF0DQoJPnNpcDp1c2VyQHByb3YubmV0IGluIHRoZSBmaXJzdCBwbGFjZS4NCgk+DQoJPjMuIElm IGEgTkFQVFIgaXMgZm91bmQgd2l0aCBhbiAiZW51bXNlcnZpY2UiIHZvaWNlOnRlbA0KCT4zYS4g YW5kIHRoZSB0ZWw6IFVSSSBpcyBwb2ludGluZyB0byBhIGRpZmZlcmVudCBudW1iZXIsDQoJPnF1 ZXJ5IEVOVU0gYWdhaW4gZm9yIHRoaXMgbnVtYmVyDQoJPjNiLiBpZiB0aGUgdGVsOiBVUkkgaXMg dGhlIHNhbWUgYXMgdGhlIEFVUywgZm9yd2FyZCB0aGUNCgk+Y2FsbCB0byB0aGUgUFNUTiwgaWYg eW91IGFyZSBhYmxlIHRvIGRvIHNvLg0KCT4NCgk+Tm90ZTogaGVyZSB0aGUgcHJvcG9zZWQgO3Bz dG4gaW5kaWNhdG9yIG1heSBjb21lIGluIGhhbmR5Og0KCT5JbiAzYSB5b3UgbWF5IHVzZSBpdCBp biB0aGUgTkFQVFIgdG8gcHJldmVudCBhIHNlY29uZCBFTlVNLXF1ZXJ5DQoJPmFuZCBmb3JjZSB0 aGUgY2FsbCB0byB0aGUgUFNUTi4NCgk+SW4gM2IgdGhlIHNlcnZlciBtYXkgYWRkIDtwc3RuIHRv IGluZm9ybSB0aGUgbmV4dCBwcm94eSBhYm91dA0KCT5UaGUgZGVjaXNpb24gdG8gZm9yY2UgdGhl IGNhbGwgdG8gdGhlIFBTVE4uIE9uIHRoZSBvdGhlciBoYW5kLA0KCT5JbiB0aGlzIGNhc2UgYWxz byB0aGUgO2VudW1kaSBpbmRpY2F0b3IgbWF5IGJlIHVzZWQganVzdCB0byBwcmV2ZW50DQoJPmFu IEVOVU0gcXVlcnkuIFJlc3VsdDogO3BzdG4gaXMgdXNlZCBpbiBFTlVNIC0gO2VudW1kaSBpcyB1 c2VkIGluDQoJPnNpZ25hbGxpbmcuDQoJPg0KCT40LiBOb3cgdGhlIHJlYWwgcHJvYmxlbSBzdGFy dHM6IElmIHRoZSBFTlVNLXF1ZXJ5IHJldHVybnMgTlhET01BSU4sDQoJPnRoZSBjdXJyZW50IGFz c3VtcHRpb24gb2YgYWxsIGNsaWVudHMgaXM6IHRoZSBjYWxsIGlzIHJvdXRlZCB0byB0aGUNCgk+ UFNUTiBpZiB0aGUgc2VydmVyIGlzIGFibGUgdG8gZG8gc28gKGV2ZW50dWFsbHkgd2l0aCB0aGUg O2VudW1kaSBzZXQuDQoJPg0KCT5UaGlzIG1lYW5zLCB3ZSByZWZlciB0aGUgcHJvYmxlbSB0byB0 aGUgUFNUTi4gVGhpcyBpcyBub3QgbmljZSBmb3INCgk+dmFyaW91cyByZWFzb25zOg0KCT4xLiB3 ZSBhcmUgYm90aGVyaW5nIHRoZSBQU1ROIGluIHNvbWUgY2FzZXMgdW5uZWNlc3NhcmlseQ0KCT4y LiB0aGUgUFNUTiBtYXkgbm90IGtub3cgd2hhdCB0byBkbyBlaXRoZXIgYW5kIGJvdW5jZSB0aGUN Cgk+Y2FsbCBiYWNrLCB3aGljaCBpcyBjcmVhdGluZyBsb29wcw0KCT4zLiBhbmQgZmluYWxseTog d2hhdCBhcmUgd2UgZG9pbmcgaWYgdGhlcmUgaXMgbm8gUFNUTiBhbnltb3JlIDstKQ0KCT5Paywg dGhpcyBzZWVtcyBmYXIgcmVhY2hlZCwgYnV0IEludGVybmV0IFRlbGVwaG9ueSBzaG91bGQgYmUg ZmluYWxseQ0KCT5zZWxmLWNvbnRhaW5pbmcuDQoJPg0KCT5TbyB3aGF0IGFyZSB0aGUgYWRkaXRp b25hbCBwb2xpY2llcyB3ZSBtYXkgd2FudCB0byB0ZWxsIGFuIEVOVU0tDQoJPmNsaWVudD8NCgk+ DQoJPjEuIE5vIHN1Y2ggbnVtYmVyICh1bmFzc2lnbmVkIG51bWJlcikNCgk+MWEuIFRoZSB3aG9s ZSBudW1iZXIgcmFuZ2UgKG51bWJlciBibG9jaylpcyB1bmFzc2lnbmVkDQoJPjFiLiBUaGVyZSBh cmUgbnVtYmVycyBhc3NpZ25lZCBpbiB0aGlzIG51bWJlciByYW5nZSwgYnV0IGlmIHlvdQ0KCT5k byBub3QgZmluZCBvbmUgaW4gRU5VTSwgeW91IGFsc28gd2lsbCBub3QgZmluZCBvbmUgb24gdGhl IFBTVE4sIHNvDQoJPml0IG1ha2VzIG5vIHNlbnNlIHRvIHJvdXRlIGl0IHRvIHRoZSBQU1ROIChF TlVNLW9ubHkpDQoJPjIuIERlZmF1bHQgcm91dGluZyBmb3IgdGhlIHdob2xlIG51bWJlciByYW5n ZSAobnVtYmVyIGJsb2NrKSB0byBhIFZvSVANCgk+Z2F0ZXdheS4NCgk+MmEuIFRoZSB3aG9sZSBi bG9jayBpcyByb3V0ZWQsIHRoZXJlIGFyZSBubyBpbmRpdmlkdWFsIGVudHJpZXMgaW4gRU5VTQ0K CT4oZS5nLiAxLTgwMCBudW1iZXJzKQ0KCT4yYi4gVGhlcmUgYXJlIG51bWJlcnMgaW4gRU5VTSwg YnV0IGlmIHlvdSBkbyBub3QgZmluZCBhbiBlbnRyeSwgcm91dGUNCgk+dGhlIGNhbGwgdG8gdGhl IGRlZmF1bHQgZ2F0ZXdheSBnaXZlbi4gT25lIGV4YW1wbGUgZm9yIHRoaXMgY2FzZSBtYXkgYmUN Cgk+YSBWb0lQIHByb3ZpZGVyIG9wZXJhdGluZyBhbiBpc2xhbmQgb25seSBjb25uZWN0ZWQgdG8g dGhlIFBTVE4uIFNvbWUNCgk+b2YgdGhlIHVzZXJzIGFyZSBhbHNvIGluIEVOVU0gKG9wdC1pbiku IElmIGhlIHByb3ZpZGVyIG5vdyBvcGVucyB1cCBhY2Nlc3MNCgk+dG8gdGhlIEludGVybmV0IHZp YSBhIGdhdGV3YXkgKGJvcmRlciBlbGVtZW50LCAuLi4pLCBoZSBtYXkgd2FudCB0byByb3V0ZQ0K CT5hbGwgY2FsbHMgZm9yIGhpcyB1c2VycyBub3QgaW4gRU5VTSB0byB0aGUgZ2F0ZXdheSBwcm92 aWRlZCBieSBkZWZhdWx0DQoJPg0KCT5DYXNlIDFhIGFuZCAyYSBjYW4gYmUgZGVhbHQgd2l0aCBp biBlMTY0LmFycGEgd2l0aCB3aWxkY2FyZHMsIGJlY2F1c2Ugbm8NCgk+QWRkaXRpb25hbCBlbnRy aWVzIGJlbG93IGV4aXN0Lg0KCT5DYXNlIDFiIGFuZCAyYiBjYW5ub3QgYmUgZGVhbHQgd2l0aGlu IGUxNjQuYXJwYSwgYmVjYXVzZSB3aWxkY2FyZHMgZG8NCgk+bm90IHN1cHBvcnQgdGhpcy4NCgk+ DQoJPlRoZSBzb2x1dGlvbnMgcHJvcG9zZWQgZm9yIHRoaXMgc29mYXIgYXJlLg0KCT4NCgk+QS4g dXNlIHRhYmxlcyBpbiBlYWNoIHNlcnZlci4gVGhpcyBpcyBub3QgYSBnb29kIGlkZWEgYW5kIGRv ZXMgbm90IGhlbHANCgk+RU5VTS1lbmFibGUgVUEuIFRoZSBpbmZvcm1hdGlvbiBzaG91bGQgYmUg c3RvcmVkIGluIGEgZ2xvYmFsIGFjY2Vzc2libGUNCgk+YW5kIHB1YmxpYyBkYXRhYmFzZSAoRE5T KS4NCgk+DQoJPkIuIHVzZSBhIChvbmUsIGNvbW1vbikgc2Vjb25kIGNvbW1vbiB0cmVlIChlMTY0 c2hhZG93LmFycGEsIHdoZXJlIHlvdSBwdXQNCgk+aW4gb25seSB0aGUgd2lsZGNhcmRzIGZvciB0 aGUgbnVtYmVyIHJhbmdlcyBpbiBxdWVzdGlvbi4gVGhlIHByb2Nlc3NpbmcNCgk+YXNzdW1wdGlv biBub3cgc2hvdWxkIGJlOg0KCT4NCgk+SWYgdGhlIEVOVU0tcXVlcnkgcmV0dXJucyBOWERPTUFJ TiwgdGhlIGNhbGwgaXMgbm90IHJvdXRlZCB0byB0aGUgUFNUTg0KCT5JbiBhbnkgY2FzZSwgdGhl IHNlcnZlciBxdWVyaWVzIGUxNjRzaGFkb3cuYXJwYSwgYW5kIG9ubHkgaWYgbm8gZW50cnkNCgk+ aXMgZm91bmQgdGhlcmUsIHRoZSBjYWxsIGlzIHJvdXRlZCB0byB0aGUgUFNUTi4gVGhlIG1hbmFn ZW1lbnQgYW5kDQoJPmRlbGVnYXRpb24gcHJvY2VkdXJlcyBvZiB0aGUgdHJlZSBhcmUgdGhlIHNh bWUgYXMgZm9yIGUxNjQuYXJwYS4NCgk+VGhlIHNlY29uZCB0cmVlIHdvdWxkIGNvbnRhaW4gb25s eSB3aWxkY2FyZCBOQVBUUiBSUiBmb3IgbnVtYmVyIHJhbmdlcw0KCT4NCgk+VGhpcyB3b3VsZCBi ZSB0aGUgb3B0aW1hbCBzb2x1dGlvbiBwcm9wb3NlZCBzb2Zhci4gVGhlIHByb2JsZW0gaXMgdGhh dA0KCT5hIGNvbW1vbiBhZ3JlZW1lbnQgYW5kIGEgZGVmaW5pdGlvbiBvbiB0aGUgc2Vjb25kIHRy ZWUgaXMgbmVjZXNzYXJ5Lg0KCT4NCgk+Qy4gVXNlIGluZGl2aWR1YWwgc2Vjb25kIHNoYWRvdyB0 cmVlcywgZWcgb24gYSBuYXRpb25hbCBsZXZlbCwgZWcgaW4NCgk+QXVzdHJpYSBlMTY0c2hhZG93 LmF0IHdvdWxkIGJlIHVzZWQuIFRoZSBwcm9ibGVtIGhlcmUgaXMgaG93IG9uZSBjYW4NCgk+Zmlu ZCBvdXQgdGhlIGRvbWFpbiBuYW1lcyBvZiB0aGUgaW5kaXZpZHVhbCB0cmVlcy4NCgk+T25lIHNv bHV0aW9uIGlzIHRvIGRvIGl0IHdpdGggYSB0YWJsZSBpbiBlYWNoIHNlcnZlciAod2hpY2ggaXMg bm90IGdvb2QpLg0KCT4NCgk+VGhlIG90aGVyIHNvbHV0aW9uIGlzIHRvIHB1dCBwb2ludGVycyBp biBlMTY0LmFycGEsIGVnIFNSViBSUiBvciBldmVuIE1YIFJSLg0KCT5UaGUgTVggcmVjb3JkIHdv dWxkIGdpdmUgZWcgdGhlIHJvb3Qgb2YgdGhlIG90aGVyIHRyZWUsIGFuZCBlYWNoIHRyZWUNCgk+ d291bGQgYmUgc3RydWN0dXJlZCBpbiB0aGUgc2FuZSB3YXkgbGlrZSBlMTY0LmFycGEsIHNvIHRo ZSBzYW1lIGFsZ29yaXRobXMNCgk+Y2FuIGJlIHVzZWQuDQoJPg0KCT5TaW5jZSB0aGUgc3RydWN0 dXJlIG9mIHRoZSBkZWxlZ2F0aW9ucyBpbiBlMTY0LmFycGEgdmFyaWVzIChUaWVyIDEgbGV2ZWxz KSwNCgk+dGhlcmUgaXMgbm8gZWFzeSB3YXkgdG8gZmluZCBvdXQgdGhlIGxldmVsIG9mIHRoZSBw b2ludGVycywgZXZlbiBpZiB0aGV5IGFyZQ0KCT5vbmx5IG9uIHRoZSBUaWVyIDEgbGF5ZXIuDQoJ Pg0KCT5JdCB3YXMgcHJvcG9zZWQgdG8gc2VhcmNoIGVpdGhlciB0b3AgZG93biAoZmFzdGVyKSBv ciBib3R0b20gdXAgKG1vcmUNCgk+ZmxleGlibGUpLCBiZWNhdXNlIHRoaXMgd291bGQgYWxsb3cg c3ViLXBvbGljaWVzIGluIG51bWJlciByYW5nZXMuDQoJPg0KCT5ELiBBcmUgdGhlcmUgYWRkaXRp b25hbCBwb3NzaWJpbGl0aWVzIG9yIHByb3Bvc2Fscz8NCgk+DQoJPkZpbmFsbHkgSSBjb21lIHRv IHRoZSBsYXN0IGlzc3VlOg0KCT4NCgk+Rm9yIGNhc2UgMWEgYW5kIDFiIGFib3ZlIChubyBzdWNo IG51bWJlcikgYW4gImVudW1zZXJ2aWNlIiBpcyBuZWNlc3NhcnkNCgk+dG8gaW5kaWNhdGUgdGhh dCB0aGVyZSBleGlzdHMgbm8gc3VjaCBudW1iZXIsIG5laXRoZXIgaW4gRU5VTSBub3Igb24gdGhl DQoJPlBTVE4uDQoJPg0KCT5Qcm9wb3NhbHMgc29mYXIgYXJlOg0KCT4NCgk+VXNlIGEgc3BlY2lh bCBmbGFnIGUuZy4gIm4iIG9yICJ2Ig0KCT5Vc2UgYSAiZW51bXNlcnZpY2UiIGUuZy4gIkUyVStO T05FIiBvciAiRTJVK1ZPSUQiIG9yIG9ubHkgIlZPSUQiDQoJPg0KCT5BbHNvIGhlcmUgYWRkaXRp b25hbCBwcm9wb3NhbHMgYXJlIGludml0ZWQuDQoJPg0KCT5CZXN0IHJlZ2FyZHMNCgk+DQoJPlJp Y2hhcmQNCgk+DQoJPg0KCT4NCgk+DQoJPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoJPmVudW0gbWFpbGluZyBsaXN0DQoJPmVudW1AaWV0Zi5vcmcNCgk+ aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZW51bQ0KCT4NCgk+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+SXB0ZWwgbWFpbGlu ZyBsaXN0DQoJPklwdGVsQGlldGYub3JnDQoJPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXB0ZWwNCgkNCgkNCg0K _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sun Mar 28 21:35:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19305 for ; Sun, 28 Mar 2004 21:35:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7mcM-0006B1-Ie for enum-archive@odin.ietf.org; Sun, 28 Mar 2004 21:35:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T2ZEPa023707 for enum-archive@odin.ietf.org; Sun, 28 Mar 2004 21:35:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7mc9-00068z-L8; Sun, 28 Mar 2004 21:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7mbP-0005uL-UZ for enum@optimus.ietf.org; Sun, 28 Mar 2004 21:34:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19274 for ; Sun, 28 Mar 2004 21:34:12 -0500 (EST) From: jon.peterson@neustar.biz Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7mbN-0003IC-00 for enum@ietf.org; Sun, 28 Mar 2004 21:34:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7maU-0003AJ-00 for enum@ietf.org; Sun, 28 Mar 2004 21:33:18 -0500 Received: from [202.155.112.88] (helo=webmaster) by ietf-mx with smtp (Exim 4.12) id 1B7mZZ-00031c-00 for enum@ietf.org; Sun, 28 Mar 2004 21:32:21 -0500 Date: Mon, 29 Mar 2004 09:32:10 +0700 To: enum@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jwulgahwcmtfvhflvwbd" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [Enum] ^_^ meay-meay! Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , ----------jwulgahwcmtfvhflvwbd Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_BAGLE.GEN-1 in file MoreInfo.zip The uncleanable file is deleted. --------------------------------------------------------- ----------jwulgahwcmtfvhflvwbd Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Argh, i don't like the plaintext :) archive password: 15225 ----------jwulgahwcmtfvhflvwbd Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) MoreInfo.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------jwulgahwcmtfvhflvwbd-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sun Mar 28 21:37:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19427 for ; Sun, 28 Mar 2004 21:37:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7meB-0006c9-2a for enum-archive@odin.ietf.org; Sun, 28 Mar 2004 21:37:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T2b61G025373 for enum-archive@odin.ietf.org; Sun, 28 Mar 2004 21:37:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7me4-0006Vg-Eg; Sun, 28 Mar 2004 21:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7mdI-0006Nc-Cy for enum@optimus.ietf.org; Sun, 28 Mar 2004 21:36:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19342 for ; Sun, 28 Mar 2004 21:36:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7mdF-0003ZX-00 for enum@ietf.org; Sun, 28 Mar 2004 21:36:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7mcM-0003Rq-00 for enum@ietf.org; Sun, 28 Mar 2004 21:35:15 -0500 Received: from bay16-f40.bay16.hotmail.com ([65.54.186.90] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B7mbj-0003HJ-00 for enum@ietf.org; Sun, 28 Mar 2004 21:34:35 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 28 Mar 2004 18:34:05 -0800 Received: from 193.126.136.215 by by16fd.bay16.hotmail.msn.com with HTTP; Mon, 29 Mar 2004 02:34:05 GMT X-Originating-IP: [193.126.136.215] X-Originating-Email: [lau_m_costa@hotmail.com] X-Sender: lau_m_costa@hotmail.com From: =?iso-8859-1?B?Q2zhdWRpYSBDb3N0YQ==?= To: enum@ietf.org Date: Mon, 29 Mar 2004 02:34:05 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 29 Mar 2004 02:34:05.0723 (UTC) FILETIME=[4E2D5EB0:01C41536] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Enum] FW: Welcome to the "enum" mailing list (Digest mode) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , ; ) _________________________________________________________________ MSN Messenger: converse com os seus amigos online. http://messenger.msn.com.br _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Mar 29 01:00:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27028 for ; Mon, 29 Mar 2004 01:00:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7pop-000577-RJ for enum-archive@odin.ietf.org; Mon, 29 Mar 2004 01:00:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T60JlV019617 for enum-archive@odin.ietf.org; Mon, 29 Mar 2004 01:00:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7poY-000548-22; Mon, 29 Mar 2004 01:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7pnp-0004yy-0v for enum@optimus.ietf.org; Mon, 29 Mar 2004 00:59:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26936 for ; Mon, 29 Mar 2004 00:59:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7pnm-0006V6-00 for enum@ietf.org; Mon, 29 Mar 2004 00:59:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7pmu-0006MG-00 for enum@ietf.org; Mon, 29 Mar 2004 00:58:20 -0500 Received: from sentosa.post1.com ([202.27.17.100]) by ietf-mx with smtp (Exim 4.12) id 1B7pmB-00064Z-00 for enum@ietf.org; Mon, 29 Mar 2004 00:57:35 -0500 Received: (qmail 92997 invoked from network); 29 Mar 2004 06:16:55 -0000 Received: from icsf.ida.gov.sg (HELO pobox.org.sg) (210.24.193.10) by sentosa.post1.com with SMTP; 29 Mar 2004 06:16:55 -0000 Message-ID: <4067BA7D.9050101@pobox.org.sg> Date: Mon, 29 Mar 2004 13:56:13 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: enum@ietf.org CC: enum-trials@ripe.net References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Enum] any enum number to test to call Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit does anyone has any connected enum numbers (e164.arpa) whom we can test calling with? we have the following numbers setup: +65 6411-1000 to +65 6411-1005 -James Seng _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Mar 29 09:56:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05186 for ; Mon, 29 Mar 2004 09:56:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yBW-0006Jm-5R for enum-archive@odin.ietf.org; Mon, 29 Mar 2004 09:56:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TEuIRg024232 for enum-archive@odin.ietf.org; Mon, 29 Mar 2004 09:56:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yBF-0006HP-Pa; Mon, 29 Mar 2004 09:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yAl-0006GX-8z for enum@optimus.ietf.org; Mon, 29 Mar 2004 09:55:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05122 for ; Mon, 29 Mar 2004 09:55:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7yAj-0005x3-00 for enum@ietf.org; Mon, 29 Mar 2004 09:55:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7y9p-0005pt-00 for enum@ietf.org; Mon, 29 Mar 2004 09:54:33 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1B7y98-0005bb-00 for enum@ietf.org; Mon, 29 Mar 2004 09:53:51 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 3412051D9C; Mon, 29 Mar 2004 16:52:08 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id CB19D51D9D; Mon, 29 Mar 2004 16:52:07 +0200 (CEST) Received: from ripe.net (penguin.ripe.net [193.0.1.232]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i2TEq1hu004161; Mon, 29 Mar 2004 16:52:07 +0200 Message-ID: <40683811.7090100@ripe.net> Date: Mon, 29 Mar 2004 16:52:01 +0200 From: Carsten Schiefner Organization: RIPE Network Coordination Centre User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: de-DE,de-AT,de-CH,de,en-US,en-GB,en MIME-Version: 1.0 To: James Seng Cc: enum@ietf.org Subject: Re: [Enum] any enum number to test to call References: <4067BA7D.9050101@pobox.org.sg> In-Reply-To: <4067BA7D.9050101@pobox.org.sg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: b93c3bb409f43c5e1440f53c295a77c3 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, feel free to dial +49308541452 between 18:00 and 23:00 +0200. Regards, -C. James Seng wrote: > does anyone has any connected enum numbers (e164.arpa) whom we can test > calling with? > > we have the following numbers setup: > > +65 6411-1000 to +65 6411-1005 > > -James Seng _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Mar 29 10:33:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08338 for ; Mon, 29 Mar 2004 10:33:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7ylH-0008Jx-6O for enum-archive@odin.ietf.org; Mon, 29 Mar 2004 10:33:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TFXFtD031984 for enum-archive@odin.ietf.org; Mon, 29 Mar 2004 10:33:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yl5-0008II-Q3; Mon, 29 Mar 2004 10:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7ykq-0008GE-EF for enum@optimus.ietf.org; Mon, 29 Mar 2004 10:32:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08226 for ; Mon, 29 Mar 2004 10:32:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7yko-0003ys-00 for enum@ietf.org; Mon, 29 Mar 2004 10:32:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7yjw-0003oB-00 for enum@ietf.org; Mon, 29 Mar 2004 10:31:53 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B7yj6-0003a6-00; Mon, 29 Mar 2004 10:31:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 29 Mar 2004 17:30:23 +0200 Message-ID: <06CF906FE3998C4E944213062009F162233C68@oefeg-s02.oefeg.loc> Thread-Topic: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQTUR402UkZTl1DThiuqW1cXdUE1ACT+yqb From: "Stastny Richard" To: "Michael Hammer" Cc: , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgTWljaGFlbCwNCiANCldlIGFyZSB0cnlpbmcgdG8gZmluZCBhIHNvbHV0aW9uIGZvciB0aGUg Zm9sbG93aW5nIHNjZW5hcmlvczoNCkEuIEFuIEUuMTY0IG51bWJlciByYW5nZSBpcyBvbmx5IGF2 YWlsYWJsZSBhbmQgcm91dGFibGUgaW4gRU5VTQ0KQi4gQW4gRS4xNjQgbnVtYmVyIHJhbmdlIGlz IGF2YWlsYWJsZSB2aWEgUFNUTiBhbmQgdmlhIElQDQpDLiBBbiBFLjE2NCBudW1iZXIgcmFuZ2Ug aXMgbm90IGFzc2lnbmVkIGF0IHRoZSBQU1RODQogDQpJZiBpbiBjYXNlcyBBIGFuZCBCIGFuIGVu dHJ5IGlzIGV4aXN0aW5nIGluIEVOVU0sIG5vIHByb2JsZW0uDQpJZiB0aGUgcXVlcnkgcmV0dXJu cyBOWERPTUFJTiwgdGhlIHByb2JsZW0gYXJpc2VzIGZvciB0aGUgDQpxdWVyeWluZyBzZXJ2ZXIg aG93IHRvIHByb2NlZWQuDQogDQpJbiBjYXNlIEEgdGhlIHNlcnZlciBtdXN0IG5vdCBmb3J3YXJk IHRoZSBjYWxsIHRvIHRoZSBQU1ROLCBiZWNhdXNlDQphIGxvb3AgbWF5IGJlIGNyZWF0ZWQuIElu IGNhc2VzIEIgYW5kIEMgaXQgbWF5IGZvcndhcmQgdGhlIGNhbGwgKG5vIGhhcm0pDQpidXQgaXQg aXMgbm90IG5lY2Vzc2FyeS4gSW4gY2FzZSBCIHRoZSBzZXJ2ZXIgY291bGQgdGVybWluYXRlIHRo ZSBjYWxsIG9uIElQLA0KaW4gY2FzZSBDIHRoZSBzZXJ2ZXIgY291bGQgc2F5IG51bWJlciBub3Qg YXZhaWxhYmxlIGFuZCBub3QgYm90aGVyIHRoZSANClBTVE4gYXQgYWxsLg0KIA0KSWYgd2UgZmlu ZCBhIHNvbHV0aW9uIHRoYXQgY292ZXJzIEEsIEIgYW5kIEMgbWF5IGJlIGNvdmVyZWQgYXMgd2Vs bC4NCiANCkkgYWdyZWUgdGhhdCBpbiBmdXR1cmUgY2FsbCByb3V0aW5nIG1heSBiZSBpbXByb3Zl ZCBmdXJ0aGVyIGluIGFjY2Vzcw0KdG8gTE5QIHNlcnZlcnMgb24gdGhlIFBTVE4gaXMgYXZhaWxh YmxlIGFuZCBhbHNvIGlmIGFjY2VzcyB0byBFTlVNDQppcyBhdmFpbGFibGUgb24gdGhlIFBTVE4g KHNvbWUgY2FycmllcnMgYXJlIGFscmVhZHkgd29ya2luZyBvbiB0aGlzKSwNCmJ1dCB0aGlzIHdp bGwgdGFrZSBzb21lIHRpbWUuDQogDQpXZSBzaG91bGQgYWxzbyBjb21lIHVwIHdpdGggYSBzc2Vs Zi1jb250YWluaW5nIHNvbHV0aW9uIG9uIElQIGFuZA0Kbm90IGFsd2F5cyByZWx5IG9uIHRoZSBQ U1ROLg0KIA0KcmVnYXJkcw0KUmljaGFyZA0KDQoJLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmlj aHQtLS0tLSANCglWb246IE1pY2hhZWwgSGFtbWVyIFttYWlsdG86bWhhbW1lckBjaXNjby5jb21d IA0KCUdlc2VuZGV0OiBGciAyNi4wMy4yMDA0IDE3OjQwIA0KCUFuOiBTdGFzdG55IFJpY2hhcmQg DQoJQ2M6IGlwdGVsQGlldGYub3JnOyBzaXBwaW5nQGlldGYub3JnIA0KCUJldHJlZmY6IFJlOiBb SXB0ZWxdIEZXOiBbRW51bV0gU3VtbWFyeSBvbiBOb1BTVE4gZGljdXNzaW9uDQoJDQoJDQoNCglS aWNoYXJkLA0KCQ0KCUdvaW5nIG91dCBvbiBhIGxpbWIgaGVyZSwgc2luY2UgSSBoYXZlIG5vdCBz ZWVuIGFsbCB0aGUgcmVmZXJlbmNlZA0KCWRpc2N1c3Npb25zLiAgTXkgZmlyc3QgaW1wcmVzc2lv biBpcyB0aGF0IHRoZSBkZXNjcmlwdGlvbiBiZWxvdyBpcyBvdmVybGF5DQoJY29tcGxleC4NCgkN CglJIGhhdmUgYSBjb25jZXJuIHRoYXQgeW91IGFwcGVhciB0byBiZSBwcm9wb3NpbmcgdGhhdCB0 aGUgRU5VTSBkaXAgd291bGQNCgloYXZlIGRlZmluaXRpdmUgYW5zd2VycyB0bzoNCglhKSB3aGV0 aGVyIGEgbnVtYmVyIGhhcyBiZWVuIGFzc2lnbmVkIGFuZCB0aGVyZWZvcmUgcm91dC1hYmxlLA0K CWIpIHdoZXRoZXIgYSBudW1iZXIgdGhhdCBpcyBhc3NpZ25lZCB3YXMgZG9uZSwgYW5kIGlmIHNv IHdoZXRoZXIgdG8gYSBQU1RODQoJZW5kcG9pbnQgb3IgYW4gSVAgZW5kcG9pbnQuDQoJDQoJQW5v dGhlciBjb25jZXJuIGlzIHRoYXQsIGlmIHlvdSBkbyBnZXQgbG9vcGVkIHJvdXRpbmcgYmV0d2Vl biB0aGUgSVAgZG9tYWluDQoJYW5kIHRoZSBURE0gZG9tYWluLCB0aGlzIGlzIGxpa2VseSBhbiBp bmRpY2F0aW9uIG9mIGEgbGFjayBvZg0KCXN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIHRoZSBFTlVN IGRhdGFiYXNlIGFuZCB0aGUgTE5QIGRhdGFiYXNlLiAgT25lIG9yIHRoZQ0KCW90aGVyIGhhcyBp bmNvcnJlY3QgZGF0YS4gIEkgc3VzcGVjdCB0aGF0IHRoZXJlIG1heSBiZSB0aW1lIGxhZ3MgZnJv bSB3aGVuDQoJYW4gU1AgYXNzaWducyBhIG51bWJlciBhbmQgd2hlbiBpdCBnZXRzIHJlZmxlY3Rl ZCBpbiBvbmUgb3IgYW5vdGhlcg0KCWRhdGFiYXNlcy4gIElmIHlvdSB3YW50IHRoZSBFTlVNIGFu ZCBMTlAgZGF0YWJhc2VzIHRvIGJlIHNvbWV3aGF0DQoJaW5kZXBlbmRlbnQsIHlvdSBtaWdodCB3 YW50IGEgbG9vc2UgY291cGxpbmcgb2YgdGhlIHVzZSBvZiB0aGUgdHdvIHN5c3RlbXM6DQoJDQoJ ICAtSWYgZW5kcG9pbnQgaXMgVERNLCB0aGVuIHRoZSBFTlVNIGRhdGFiYXNlIHNob3VsZCBwb2lu dCB0byB0aGUgUFNUTiwNCgl3aXRoIGRlZmF1bHQgYmVoYXZpb3IgYmVpbmcsIGlmIHVua25vd24g dG8gRU5VTSwgc2VuZCB0byBQU1ROIHRvDQoJcmVzb2x2ZS4gIChOb3RlIHRoaXMgaXMgb3J0aG9n b25hbCB0byBFTlVNcyB1c2UgdG8gc2VsZWN0IGFsdGVybmF0aXZlDQoJZW5kcG9pbnRzLikNCgkN CgkgIC0gSWYgZW5kcG9pbnQgaXMgSVAsIHRoZW4gdGhlIExOUCBkYXRhYmFzZXMgc2hvdWxkIHBv aW50IHRvIHRoZSBJUA0KCWRvbWFpbiwgd2l0aCBkZWZhdWx0IGJlaGF2aW9yIGJlaW5nLCBpZiB1 bmtub3duIHRvIExOUCwgcm91dGUgaW4gdGhlIFBTVE4NCgl0byByZXNvbHZlLg0KCQ0KCVRoZSBk aWZmZXJlbmNlIGlzIGluIHRoZSBpbnRlcnByZXRhdGlvbiBvZiBhIGxhY2sgb2YgYSByZWNvcmQu ICBJbiBMTlAsIGl0DQoJd291bGQgbWVhbiB0aGF0IHRoZSBFLjE2NCBudW1iZXIgaXMgc3RpbGwg b3duZWQgYnkgdGhlIG9yaWdpbmFsIHN3aXRjaCwNCgl3aGVyZWFzIGluIEVOVU0gaXQgd291bGQg bWVhbiB0aGF0IHRoZSBFLjE2NCBudW1iZXIgaXMgbm90IHJvdXRlLWFibGUgdG8gYW4NCglJUCBl bmRwb2ludC4gIEZyb20gYSBURE0gcGVyc3BlY3RpdmUsIHRoZSBlbnRpcmUgSVAgZG9tYWluIGNv dWxkIGJlIHZpZXdlZA0KCWFzIGEgc2luZ2xlIHN3aXRjaCBhbmQgdGhlIExOUCByb3V0aW5nIHNj aGVtZSBzaG91bGQgd29yay4gIFRoZSBjb252ZXJzZQ0KCSh3aGVuIHJlY29yZHMgZXhpc3QpIGNv dWxkIGJlIHRydWUgZm9yIEVOVU0uDQoJDQoJQSBnYXRld2F5IGJldHdlZW4gSVAtZG9tYWluIGFu ZCBURE0gZG9tYWluLCB1cG9uIHNlZWluZyB0aGF0IGJvdGggYW4gTE5QDQoJYW5kIGFuIEVOVU0g ZGlwIGhhdmUgbm90IHJlc29sdmVkIHRoZSByb3V0ZSwgY2FuIHNhZmVseSBjb25jbHVkZSB0aGF0 IHRoZQ0KCW51bWJlciBpcyB1bmFzc2lnbmVkIGFuZCByZWxlYXNlIHRoZSBjYWxsLg0KCQ0KCUFj dHVhbGx5LCBpdCBtYXkgbm90IGJlIG5lY2Vzc2FyeSB0byBzZW5kIGEgc2V0dXAgbWVzc2FnZSB0 byBhIEdXLCBub3IgaXMNCglpdCBuZWNlc3NhcnkgdG8gaGF2ZSB0aGUgRU5VTSBhbmQgTE5QIGRh dGFiYXNlcyBkdXBsaWNhdGUgZWFjaCBvdGhlci4gIEl0DQoJc2hvdWxkIGJlIHN1ZmZpY2llbnQg Zm9yIGFuIEVOVU0gREIgdG8gcXVlcnkgdGhlIExOUCBEQiBhbmQgcmVzcG9uZCB3aXRoIGFuDQoJ YXBwcm9wcmlhdGUgYW5zd2VyLCBvciB0aGUgY29udmVyc2UuDQoJDQoJTWlrZQ0KCQ0KCQ0KCUF0 IDA0OjIyIFBNIDMvMjUvMjAwNCArMDEwMCwgU3Rhc3RueSBSaWNoYXJkIHdyb3RlOg0KCT5Dcm9z cyBwb3N0aW5nIGZyb20gZW51bUBpZXRmLm9yZw0KCT5UaGUgZGlzY3Vzc2lvbiBpcyBnb2luZyBv biB0aGUgZW51bS1saXN0DQoJPg0KCT5SaWNoYXJkIFN0YXN0bnkNCgk+T2VGRUcNCgk+KzQzIDY2 NCA0MjAgNDEwMA0KCT4NCgk+DQoJPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPkZyb206 IFN0YXN0bnkgUmljaGFyZA0KCT5TZW50OiBUaHVyc2RheSwgTWFyY2ggMjUsIDIwMDQgMTowOCBQ TQ0KCT5UbzogTWFyaWFuIER1cmtvdmljOyBsd2NAcm9rZS5jby51aw0KCT5DYzogZW51bUBpZXRm Lm9yZw0KCT5TdWJqZWN0OiBbRW51bV0gU3VtbWFyeSBvbiBOb1BTVE4gZGljdXNzaW9uDQoJPg0K CT5EZWFyIGNvbGxlYWd1ZXMsDQoJPg0KCT5UaGVyZSB3YXMgYSBsb3Qgb2YgZGlzY3Vzc2lvbnMg b24tbGlzdCBhbmQgb2ZmLWxpc3Qgb24gdGhpcyBpc3N1ZSwNCgk+c28gSSB3aWxsIHRyeSB0byBz dW1tYXJpemUgYXQgbGVhc3QgbXkgdmlldyBvZiB0aGUgcHJvYmxlbS4NCgk+SSB3aWxsIGFsc28g aW5jbHVkZSBteSBjdXJyZW50IHZpZXcgb24gdGhlIDtlbnVtZGkNCgk+YW5kIHRoZSA7cHN0biBp bmRpY2F0b3IgZm9yIHRoZSB0ZWw6IFVSSQ0KCT4NCgk+RU5VTS1lbmFibGVkIFVBcyBhbmQgU2Vy dmVycyBhcmUgY3VycmVudGx5IHByb2Nlc3NpbmcNCgk+cmVjZWl2ZWQgRS4xNjQgbnVtYmVycyAo ZWl0aGVyIGluIGEgdGVsOit4eHggVVJJIG9yIGluIGEgc2lwOiBVUkkNCgk+aW4gdGhlIGZvcm1h dCBzaXA6K3h4eHhAcHJvYy5uZXQ7dXNlcj1waG9uZSkgaW4gdGhlIGZvbGxvd2luZyB3YXk6DQoJ Pihmb3Igc2ltcGxpY2l0eSBJIGFtIG9ubHkgZGVhbGluZyB3aXRoIHZvaWNlIGNhbGxzKQ0KCT5Q bGVhc2UgaG9sbGVyIGlmIEkgZ290IHNvbWV0aGluZyB3cm9uZyBvciB5b3UgZGlzYWdyZWUNCgk+ DQoJPjEuIFF1ZXJ5IEVOVU0gKGluIGUxNjQuYXJwYSkNCgk+DQoJPjIuIGlmIGEgTkFQVFIgaXMg Zm91bmQgd2l0aCBhbiAiZW51bXNlcnZpY2UiIHNpcCBvciB2b2ljZTpzaXAsDQoJPmhhbmRsZSB0 aGUgY2FsbCBhcyBpZiB5b3UgaGF2ZSByZWNlaXZlZCBhIHNpcDogVVJJIGluIHRoZSBmb3JtYXQN Cgk+c2lwOnVzZXJAcHJvdi5uZXQgaW4gdGhlIGZpcnN0IHBsYWNlLg0KCT4NCgk+My4gSWYgYSBO QVBUUiBpcyBmb3VuZCB3aXRoIGFuICJlbnVtc2VydmljZSIgdm9pY2U6dGVsDQoJPjNhLiBhbmQg dGhlIHRlbDogVVJJIGlzIHBvaW50aW5nIHRvIGEgZGlmZmVyZW50IG51bWJlciwNCgk+cXVlcnkg RU5VTSBhZ2FpbiBmb3IgdGhpcyBudW1iZXINCgk+M2IuIGlmIHRoZSB0ZWw6IFVSSSBpcyB0aGUg c2FtZSBhcyB0aGUgQVVTLCBmb3J3YXJkIHRoZQ0KCT5jYWxsIHRvIHRoZSBQU1ROLCBpZiB5b3Ug YXJlIGFibGUgdG8gZG8gc28uDQoJPg0KCT5Ob3RlOiBoZXJlIHRoZSBwcm9wb3NlZCA7cHN0biBp bmRpY2F0b3IgbWF5IGNvbWUgaW4gaGFuZHk6DQoJPkluIDNhIHlvdSBtYXkgdXNlIGl0IGluIHRo ZSBOQVBUUiB0byBwcmV2ZW50IGEgc2Vjb25kIEVOVU0tcXVlcnkNCgk+YW5kIGZvcmNlIHRoZSBj YWxsIHRvIHRoZSBQU1ROLg0KCT5JbiAzYiB0aGUgc2VydmVyIG1heSBhZGQgO3BzdG4gdG8gaW5m b3JtIHRoZSBuZXh0IHByb3h5IGFib3V0DQoJPlRoZSBkZWNpc2lvbiB0byBmb3JjZSB0aGUgY2Fs bCB0byB0aGUgUFNUTi4gT24gdGhlIG90aGVyIGhhbmQsDQoJPkluIHRoaXMgY2FzZSBhbHNvIHRo ZSA7ZW51bWRpIGluZGljYXRvciBtYXkgYmUgdXNlZCBqdXN0IHRvIHByZXZlbnQNCgk+YW4gRU5V TSBxdWVyeS4gUmVzdWx0OiA7cHN0biBpcyB1c2VkIGluIEVOVU0gLSA7ZW51bWRpIGlzIHVzZWQg aW4NCgk+c2lnbmFsbGluZy4NCgk+DQoJPjQuIE5vdyB0aGUgcmVhbCBwcm9ibGVtIHN0YXJ0czog SWYgdGhlIEVOVU0tcXVlcnkgcmV0dXJucyBOWERPTUFJTiwNCgk+dGhlIGN1cnJlbnQgYXNzdW1w dGlvbiBvZiBhbGwgY2xpZW50cyBpczogdGhlIGNhbGwgaXMgcm91dGVkIHRvIHRoZQ0KCT5QU1RO IGlmIHRoZSBzZXJ2ZXIgaXMgYWJsZSB0byBkbyBzbyAoZXZlbnR1YWxseSB3aXRoIHRoZSA7ZW51 bWRpIHNldC4NCgk+DQoJPlRoaXMgbWVhbnMsIHdlIHJlZmVyIHRoZSBwcm9ibGVtIHRvIHRoZSBQ U1ROLiBUaGlzIGlzIG5vdCBuaWNlIGZvcg0KCT52YXJpb3VzIHJlYXNvbnM6DQoJPjEuIHdlIGFy ZSBib3RoZXJpbmcgdGhlIFBTVE4gaW4gc29tZSBjYXNlcyB1bm5lY2Vzc2FyaWx5DQoJPjIuIHRo ZSBQU1ROIG1heSBub3Qga25vdyB3aGF0IHRvIGRvIGVpdGhlciBhbmQgYm91bmNlIHRoZQ0KCT5j YWxsIGJhY2ssIHdoaWNoIGlzIGNyZWF0aW5nIGxvb3BzDQoJPjMuIGFuZCBmaW5hbGx5OiB3aGF0 IGFyZSB3ZSBkb2luZyBpZiB0aGVyZSBpcyBubyBQU1ROIGFueW1vcmUgOy0pDQoJPk9rLCB0aGlz IHNlZW1zIGZhciByZWFjaGVkLCBidXQgSW50ZXJuZXQgVGVsZXBob255IHNob3VsZCBiZSBmaW5h bGx5DQoJPnNlbGYtY29udGFpbmluZy4NCgk+DQoJPlNvIHdoYXQgYXJlIHRoZSBhZGRpdGlvbmFs IHBvbGljaWVzIHdlIG1heSB3YW50IHRvIHRlbGwgYW4gRU5VTS0NCgk+Y2xpZW50Pw0KCT4NCgk+ MS4gTm8gc3VjaCBudW1iZXIgKHVuYXNzaWduZWQgbnVtYmVyKQ0KCT4xYS4gVGhlIHdob2xlIG51 bWJlciByYW5nZSAobnVtYmVyIGJsb2NrKWlzIHVuYXNzaWduZWQNCgk+MWIuIFRoZXJlIGFyZSBu dW1iZXJzIGFzc2lnbmVkIGluIHRoaXMgbnVtYmVyIHJhbmdlLCBidXQgaWYgeW91DQoJPmRvIG5v dCBmaW5kIG9uZSBpbiBFTlVNLCB5b3UgYWxzbyB3aWxsIG5vdCBmaW5kIG9uZSBvbiB0aGUgUFNU Tiwgc28NCgk+aXQgbWFrZXMgbm8gc2Vuc2UgdG8gcm91dGUgaXQgdG8gdGhlIFBTVE4gKEVOVU0t b25seSkNCgk+Mi4gRGVmYXVsdCByb3V0aW5nIGZvciB0aGUgd2hvbGUgbnVtYmVyIHJhbmdlIChu dW1iZXIgYmxvY2spIHRvIGEgVm9JUA0KCT5nYXRld2F5Lg0KCT4yYS4gVGhlIHdob2xlIGJsb2Nr IGlzIHJvdXRlZCwgdGhlcmUgYXJlIG5vIGluZGl2aWR1YWwgZW50cmllcyBpbiBFTlVNDQoJPihl LmcuIDEtODAwIG51bWJlcnMpDQoJPjJiLiBUaGVyZSBhcmUgbnVtYmVycyBpbiBFTlVNLCBidXQg aWYgeW91IGRvIG5vdCBmaW5kIGFuIGVudHJ5LCByb3V0ZQ0KCT50aGUgY2FsbCB0byB0aGUgZGVm YXVsdCBnYXRld2F5IGdpdmVuLiBPbmUgZXhhbXBsZSBmb3IgdGhpcyBjYXNlIG1heSBiZQ0KCT5h IFZvSVAgcHJvdmlkZXIgb3BlcmF0aW5nIGFuIGlzbGFuZCBvbmx5IGNvbm5lY3RlZCB0byB0aGUg UFNUTi4gU29tZQ0KCT5vZiB0aGUgdXNlcnMgYXJlIGFsc28gaW4gRU5VTSAob3B0LWluKS4gSWYg aGUgcHJvdmlkZXIgbm93IG9wZW5zIHVwIGFjY2Vzcw0KCT50byB0aGUgSW50ZXJuZXQgdmlhIGEg Z2F0ZXdheSAoYm9yZGVyIGVsZW1lbnQsIC4uLiksIGhlIG1heSB3YW50IHRvIHJvdXRlDQoJPmFs bCBjYWxscyBmb3IgaGlzIHVzZXJzIG5vdCBpbiBFTlVNIHRvIHRoZSBnYXRld2F5IHByb3ZpZGVk IGJ5IGRlZmF1bHQNCgk+DQoJPkNhc2UgMWEgYW5kIDJhIGNhbiBiZSBkZWFsdCB3aXRoIGluIGUx NjQuYXJwYSB3aXRoIHdpbGRjYXJkcywgYmVjYXVzZSBubw0KCT5BZGRpdGlvbmFsIGVudHJpZXMg YmVsb3cgZXhpc3QuDQoJPkNhc2UgMWIgYW5kIDJiIGNhbm5vdCBiZSBkZWFsdCB3aXRoaW4gZTE2 NC5hcnBhLCBiZWNhdXNlIHdpbGRjYXJkcyBkbw0KCT5ub3Qgc3VwcG9ydCB0aGlzLg0KCT4NCgk+ VGhlIHNvbHV0aW9ucyBwcm9wb3NlZCBmb3IgdGhpcyBzb2ZhciBhcmUuDQoJPg0KCT5BLiB1c2Ug dGFibGVzIGluIGVhY2ggc2VydmVyLiBUaGlzIGlzIG5vdCBhIGdvb2QgaWRlYSBhbmQgZG9lcyBu b3QgaGVscA0KCT5FTlVNLWVuYWJsZSBVQS4gVGhlIGluZm9ybWF0aW9uIHNob3VsZCBiZSBzdG9y ZWQgaW4gYSBnbG9iYWwgYWNjZXNzaWJsZQ0KCT5hbmQgcHVibGljIGRhdGFiYXNlIChETlMpLg0K CT4NCgk+Qi4gdXNlIGEgKG9uZSwgY29tbW9uKSBzZWNvbmQgY29tbW9uIHRyZWUgKGUxNjRzaGFk b3cuYXJwYSwgd2hlcmUgeW91IHB1dA0KCT5pbiBvbmx5IHRoZSB3aWxkY2FyZHMgZm9yIHRoZSBu dW1iZXIgcmFuZ2VzIGluIHF1ZXN0aW9uLiBUaGUgcHJvY2Vzc2luZw0KCT5hc3N1bXB0aW9uIG5v dyBzaG91bGQgYmU6DQoJPg0KCT5JZiB0aGUgRU5VTS1xdWVyeSByZXR1cm5zIE5YRE9NQUlOLCB0 aGUgY2FsbCBpcyBub3Qgcm91dGVkIHRvIHRoZSBQU1RODQoJPkluIGFueSBjYXNlLCB0aGUgc2Vy dmVyIHF1ZXJpZXMgZTE2NHNoYWRvdy5hcnBhLCBhbmQgb25seSBpZiBubyBlbnRyeQ0KCT5pcyBm b3VuZCB0aGVyZSwgdGhlIGNhbGwgaXMgcm91dGVkIHRvIHRoZSBQU1ROLiBUaGUgbWFuYWdlbWVu dCBhbmQNCgk+ZGVsZWdhdGlvbiBwcm9jZWR1cmVzIG9mIHRoZSB0cmVlIGFyZSB0aGUgc2FtZSBh cyBmb3IgZTE2NC5hcnBhLg0KCT5UaGUgc2Vjb25kIHRyZWUgd291bGQgY29udGFpbiBvbmx5IHdp bGRjYXJkIE5BUFRSIFJSIGZvciBudW1iZXIgcmFuZ2VzDQoJPg0KCT5UaGlzIHdvdWxkIGJlIHRo ZSBvcHRpbWFsIHNvbHV0aW9uIHByb3Bvc2VkIHNvZmFyLiBUaGUgcHJvYmxlbSBpcyB0aGF0DQoJ PmEgY29tbW9uIGFncmVlbWVudCBhbmQgYSBkZWZpbml0aW9uIG9uIHRoZSBzZWNvbmQgdHJlZSBp cyBuZWNlc3NhcnkuDQoJPg0KCT5DLiBVc2UgaW5kaXZpZHVhbCBzZWNvbmQgc2hhZG93IHRyZWVz LCBlZyBvbiBhIG5hdGlvbmFsIGxldmVsLCBlZyBpbg0KCT5BdXN0cmlhIGUxNjRzaGFkb3cuYXQg d291bGQgYmUgdXNlZC4gVGhlIHByb2JsZW0gaGVyZSBpcyBob3cgb25lIGNhbg0KCT5maW5kIG91 dCB0aGUgZG9tYWluIG5hbWVzIG9mIHRoZSBpbmRpdmlkdWFsIHRyZWVzLg0KCT5PbmUgc29sdXRp b24gaXMgdG8gZG8gaXQgd2l0aCBhIHRhYmxlIGluIGVhY2ggc2VydmVyICh3aGljaCBpcyBub3Qg Z29vZCkuDQoJPg0KCT5UaGUgb3RoZXIgc29sdXRpb24gaXMgdG8gcHV0IHBvaW50ZXJzIGluIGUx NjQuYXJwYSwgZWcgU1JWIFJSIG9yIGV2ZW4gTVggUlIuDQoJPlRoZSBNWCByZWNvcmQgd291bGQg Z2l2ZSBlZyB0aGUgcm9vdCBvZiB0aGUgb3RoZXIgdHJlZSwgYW5kIGVhY2ggdHJlZQ0KCT53b3Vs ZCBiZSBzdHJ1Y3R1cmVkIGluIHRoZSBzYW5lIHdheSBsaWtlIGUxNjQuYXJwYSwgc28gdGhlIHNh bWUgYWxnb3JpdGhtcw0KCT5jYW4gYmUgdXNlZC4NCgk+DQoJPlNpbmNlIHRoZSBzdHJ1Y3R1cmUg b2YgdGhlIGRlbGVnYXRpb25zIGluIGUxNjQuYXJwYSB2YXJpZXMgKFRpZXIgMSBsZXZlbHMpLA0K CT50aGVyZSBpcyBubyBlYXN5IHdheSB0byBmaW5kIG91dCB0aGUgbGV2ZWwgb2YgdGhlIHBvaW50 ZXJzLCBldmVuIGlmIHRoZXkgYXJlDQoJPm9ubHkgb24gdGhlIFRpZXIgMSBsYXllci4NCgk+DQoJ Pkl0IHdhcyBwcm9wb3NlZCB0byBzZWFyY2ggZWl0aGVyIHRvcCBkb3duIChmYXN0ZXIpIG9yIGJv dHRvbSB1cCAobW9yZQ0KCT5mbGV4aWJsZSksIGJlY2F1c2UgdGhpcyB3b3VsZCBhbGxvdyBzdWIt cG9saWNpZXMgaW4gbnVtYmVyIHJhbmdlcy4NCgk+DQoJPkQuIEFyZSB0aGVyZSBhZGRpdGlvbmFs IHBvc3NpYmlsaXRpZXMgb3IgcHJvcG9zYWxzPw0KCT4NCgk+RmluYWxseSBJIGNvbWUgdG8gdGhl IGxhc3QgaXNzdWU6DQoJPg0KCT5Gb3IgY2FzZSAxYSBhbmQgMWIgYWJvdmUgKG5vIHN1Y2ggbnVt YmVyKSBhbiAiZW51bXNlcnZpY2UiIGlzIG5lY2Vzc2FyeQ0KCT50byBpbmRpY2F0ZSB0aGF0IHRo ZXJlIGV4aXN0cyBubyBzdWNoIG51bWJlciwgbmVpdGhlciBpbiBFTlVNIG5vciBvbiB0aGUNCgk+ UFNUTi4NCgk+DQoJPlByb3Bvc2FscyBzb2ZhciBhcmU6DQoJPg0KCT5Vc2UgYSBzcGVjaWFsIGZs YWcgZS5nLiAibiIgb3IgInYiDQoJPlVzZSBhICJlbnVtc2VydmljZSIgZS5nLiAiRTJVK05PTkUi IG9yICJFMlUrVk9JRCIgb3Igb25seSAiVk9JRCINCgk+DQoJPkFsc28gaGVyZSBhZGRpdGlvbmFs IHByb3Bvc2FscyBhcmUgaW52aXRlZC4NCgk+DQoJPkJlc3QgcmVnYXJkcw0KCT4NCgk+UmljaGFy ZA0KCT4NCgk+DQoJPg0KCT4NCgk+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCgk+ZW51bSBtYWlsaW5nIGxpc3QNCgk+ZW51bUBpZXRmLm9yZw0KCT5odHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbnVtDQoJPg0KCT5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCT5JcHRlbCBtYWlsaW5nIGxp c3QNCgk+SXB0ZWxAaWV0Zi5vcmcNCgk+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHRlbA0KCQ0KCQ0KDQo= _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 30 16:04:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11738 for ; Tue, 30 Mar 2004 16:04:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8QP8-0008Ss-1m for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 16:04:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UL4EDN032538 for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 16:04:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8QOu-0008Qu-T0; Tue, 30 Mar 2004 16:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8QOT-0008NH-Hq for enum@optimus.ietf.org; Tue, 30 Mar 2004 16:03:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11622 for ; Tue, 30 Mar 2004 16:03:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8QOR-0006Cd-00 for enum@ietf.org; Tue, 30 Mar 2004 16:03:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8QNS-000684-00 for enum@ietf.org; Tue, 30 Mar 2004 16:02:34 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1B8QMc-00063S-00 for enum@ietf.org; Tue, 30 Mar 2004 16:01:38 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2UKxNM16868; Tue, 30 Mar 2004 15:59:23 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Mar 2004 15:59:23 -0500 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6096E3514@zcard0ke.ca.nortel.com> From: "James McEachern" To: "'Stastny Richard'" , Michael Hammer Cc: enum@ietf.org Subject: RE: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Date: Tue, 30 Mar 2004 15:59:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41699.DB36BC02" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C41699.DB36BC02 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mike, In your email you state: ---snip--- The difference is in the interpretation of a lack of a record. In LNP, = it would mean that the E.164 number is still owned by the original switch, whereas in ENUM it would mean that the E.164 number is not route-able = to an IP endpoint. From a TDM perspective, the entire IP domain could be = viewed as a single switch and the LNP routing scheme should work. The = converse (when records exist) could be true for ENUM. =09 A gateway between IP-domain and TDM domain, upon seeing that both an = LNP and an ENUM dip have not resolved the route, can safely conclude that the = number is unassigned and release the call." ---end snip--- This seems to suggest that routing to an IP endpoint would require an = ENUM entry - otherwise the gateway could safely assume the number is = unassigned. Do you really mean this? What would this do to opt-in? Thanks Jim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Monday, March 29, 2004 10:30 AM To: Michael Hammer Cc: iptel@ietf.org; sipping@ietf.org; enum@ietf.org Subject: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Hi Michael, =20 We are trying to find a solution for the following scenarios: A. An E.164 number range is only available and routable in ENUM B. An E.164 number range is available via PSTN and via IP C. An E.164 number range is not assigned at the PSTN =20 If in cases A and B an entry is existing in ENUM, no problem. If the query returns NXDOMAIN, the problem arises for the=20 querying server how to proceed. =20 In case A the server must not forward the call to the PSTN, because a loop may be created. In cases B and C it may forward the call (no = harm) but it is not necessary. In case B the server could terminate the call = on IP, in case C the server could say number not available and not bother the=20 PSTN at all. =20 If we find a solution that covers A, B and C may be covered as well. =20 I agree that in future call routing may be improved further in access to LNP servers on the PSTN is available and also if access to ENUM is available on the PSTN (some carriers are already working on this), but this will take some time. =20 We should also come up with a sself-containing solution on IP and not always rely on the PSTN. =20 regards Richard -----Urspr=C3=BCngliche Nachricht-----=20 Von: Michael Hammer [mailto:mhammer@cisco.com]=20 Gesendet: Fr 26.03.2004 17:40=20 An: Stastny Richard=20 Cc: iptel@ietf.org; sipping@ietf.org=20 Betreff: Re: [Iptel] FW: [Enum] Summary on NoPSTN dicussion =09 =09 Richard, =09 Going out on a limb here, since I have not seen all the referenced discussions. My first impression is that the description below is overlay complex. =09 I have a concern that you appear to be proposing that the ENUM dip would have definitive answers to: a) whether a number has been assigned and therefore rout-able, b) whether a number that is assigned was done, and if so whether to a PSTN endpoint or an IP endpoint. =09 Another concern is that, if you do get looped routing between the IP domain and the TDM domain, this is likely an indication of a lack of synchronization between the ENUM database and the LNP database. One or the other has incorrect data. I suspect that there may be time lags from when an SP assigns a number and when it gets reflected in one or another databases. If you want the ENUM and LNP databases to be somewhat independent, you might want a loose coupling of the use of the two systems: =09 -If endpoint is TDM, then the ENUM database should point to the PSTN, with default behavior being, if unknown to ENUM, send to PSTN to resolve. (Note this is orthogonal to ENUMs use to select alternative endpoints.) =09 - If endpoint is IP, then the LNP databases should point to the IP domain, with default behavior being, if unknown to LNP, route in the PSTN to resolve. =09 The difference is in the interpretation of a lack of a record. In LNP, it would mean that the E.164 number is still owned by the original switch, whereas in ENUM it would mean that the E.164 number is not route-able to an IP endpoint. From a TDM perspective, the entire IP domain could be viewed as a single switch and the LNP routing scheme should work. The converse (when records exist) could be true for ENUM. =09 A gateway between IP-domain and TDM domain, upon seeing that both an LNP and an ENUM dip have not resolved the route, can safely conclude that the number is unassigned and release the call. =09 Actually, it may not be necessary to send a setup message to a GW, nor is it necessary to have the ENUM and LNP databases duplicate each other. It should be sufficient for an ENUM DB to query the LNP DB and respond with an appropriate answer, or the converse. =09 Mike =09 =09 At 04:22 PM 3/25/2004 +0100, Stastny Richard wrote: >Cross posting from enum@ietf.org >The discussion is going on the enum-list > >Richard Stastny >OeFEG >+43 664 420 4100 > > >-----Original Message----- >From: Stastny Richard >Sent: Thursday, March 25, 2004 1:08 PM >To: Marian Durkovic; lwc@roke.co.uk >Cc: enum@ietf.org >Subject: [Enum] Summary on NoPSTN dicussion > >Dear colleagues, > >There was a lot of discussions on-list and off-list on this issue, >so I will try to summarize at least my view of the problem. >I will also include my current view on the ;enumdi >and the ;pstn indicator for the tel: URI > >ENUM-enabled UAs and Servers are currently processing >received E.164 numbers (either in a tel:+xxx URI or in a sip: URI >in the format sip:+xxxx@proc.net;user=3Dphone) in the following way: >(for simplicity I am only dealing with voice calls) >Please holler if I got something wrong or you disagree > >1. Query ENUM (in e164.arpa) > >2. if a NAPTR is found with an "enumservice" sip or voice:sip, >handle the call as if you have received a sip: URI in the format >sip:user@prov.net in the first place. > >3. If a NAPTR is found with an "enumservice" voice:tel >3a. and the tel: URI is pointing to a different number, >query ENUM again for this number >3b. if the tel: URI is the same as the AUS, forward the >call to the PSTN, if you are able to do so. > >Note: here the proposed ;pstn indicator may come in handy: >In 3a you may use it in the NAPTR to prevent a second ENUM-query >and force the call to the PSTN. >In 3b the server may add ;pstn to inform the next proxy about >The decision to force the call to the PSTN. On the other hand, >In this case also the ;enumdi indicator may be used just to prevent >an ENUM query. Result: ;pstn is used in ENUM - ;enumdi is used in >signalling. > >4. Now the real problem starts: If the ENUM-query returns NXDOMAIN, >the current assumption of all clients is: the call is routed to the >PSTN if the server is able to do so (eventually with the ;enumdi set. > >This means, we refer the problem to the PSTN. This is not nice for >various reasons: >1. we are bothering the PSTN in some cases unnecessarily >2. the PSTN may not know what to do either and bounce the >call back, which is creating loops >3. and finally: what are we doing if there is no PSTN anymore ;-) >Ok, this seems far reached, but Internet Telephony should be finally >self-containing. > >So what are the additional policies we may want to tell an ENUM- >client? > >1. No such number (unassigned number) >1a. The whole number range (number block)is unassigned >1b. There are numbers assigned in this number range, but if you >do not find one in ENUM, you also will not find one on the PSTN, so >it makes no sense to route it to the PSTN (ENUM-only) >2. Default routing for the whole number range (number block) to a VoIP >gateway. >2a. The whole block is routed, there are no individual entries in ENUM >(e.g. 1-800 numbers) >2b. There are numbers in ENUM, but if you do not find an entry, route >the call to the default gateway given. One example for this case may be >a VoIP provider operating an island only connected to the PSTN. Some >of the users are also in ENUM (opt-in). If he provider now opens up access >to the Internet via a gateway (border element, ...), he may want to route >all calls for his users not in ENUM to the gateway provided by default > >Case 1a and 2a can be dealt with in e164.arpa with wildcards, because no >Additional entries below exist. >Case 1b and 2b cannot be dealt within e164.arpa, because wildcards do >not support this. > >The solutions proposed for this sofar are. > >A. use tables in each server. This is not a good idea and does not help >ENUM-enable UA. The information should be stored in a global accessible >and public database (DNS). > >B. use a (one, common) second common tree (e164shadow.arpa, where you put >in only the wildcards for the number ranges in question. The processing >assumption now should be: > >If the ENUM-query returns NXDOMAIN, the call is not routed to the PSTN >In any case, the server queries e164shadow.arpa, and only if no entry >is found there, the call is routed to the PSTN. The management and >delegation procedures of the tree are the same as for e164.arpa. >The second tree would contain only wildcard NAPTR RR for number ranges > >This would be the optimal solution proposed sofar. The problem is that >a common agreement and a definition on the second tree is necessary. > >C. Use individual second shadow trees, eg on a national level, eg in >Austria e164shadow.at would be used. The problem here is how one can >find out the domain names of the individual trees. >One solution is to do it with a table in each server (which is not good). > >The other solution is to put pointers in e164.arpa, eg SRV RR or even MX RR. >The MX record would give eg the root of the other tree, and each tree >would be structured in the sane way like e164.arpa, so the same algorithms >can be used. > >Since the structure of the delegations in e164.arpa varies (Tier 1 levels), >there is no easy way to find out the level of the pointers, even if they are >only on the Tier 1 layer. > >It was proposed to search either top down (faster) or bottom up (more >flexible), because this would allow sub-policies in number ranges. > >D. Are there additional possibilities or proposals? > >Finally I come to the last issue: > >For case 1a and 1b above (no such number) an "enumservice" is necessary >to indicate that there exists no such number, neither in ENUM nor on the >PSTN. > >Proposals sofar are: > >Use a special flag e.g. "n" or "v" >Use a "enumservice" e.g. "E2U+NONE" or "E2U+VOID" or only "VOID" > >Also here additional proposals are invited. > >Best regards > >Richard > > > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum > >_______________________________________________ >Iptel mailing list >Iptel@ietf.org >https://www.ietf.org/mailman/listinfo/iptel =09 =09 z{x%^=E1=A6=9Ezr=08m=E1=A8=B6? 0u'~ffX)n ------_=_NextPart_001_01C41699.DB36BC02 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [Iptel] FW: [Enum] Summary on NoPSTN dicussion

Mike,
In your email you state:

---snip---
The difference is in the interpretation of a lack of = a record.  In LNP, it would mean that the E.164 number is still = owned by the original switch, whereas in ENUM it would mean that the = E.164 number is not route-able to an IP endpoint.  From a TDM = perspective, the entire IP domain could be viewed as a single switch = and the LNP routing scheme should work.  The converse (when = records exist) could be true for ENUM.

       =20
A gateway between IP-domain and TDM domain, upon = seeing that both an LNP and an ENUM dip have not resolved the route, = can safely conclude that the number is unassigned and release the = call."

---end snip---

This seems to suggest that routing to an IP endpoint = would require an ENUM entry - otherwise the gateway could safely assume = the number is unassigned. Do you really mean this? What would this do = to opt-in?

Thanks
Jim


-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny@oefeg.at= ]
Sent: Monday, March 29, 2004 10:30 AM
To: Michael Hammer
Cc: iptel@ietf.org; sipping@ietf.org; = enum@ietf.org
Subject: AW: [Iptel] FW: [Enum] Summary on NoPSTN = dicussion

Hi Michael,
 
We are trying to find a solution for the following = scenarios:
A. An E.164 number range is only available and = routable in ENUM
B. An E.164 number range is available via PSTN and = via IP
C. An E.164 number range is not assigned at the = PSTN
 
If in cases A and B an entry is existing in ENUM, no = problem.
If the query returns NXDOMAIN, the problem arises = for the
querying server how to proceed.
 
In case A the server must not forward the call to = the PSTN, because
a loop may be created. In cases B and C it may = forward the call (no harm)
but it is not necessary. In case B the server could = terminate the call on IP,
in case C the server could say number not available = and not bother the
PSTN at all.
 
If we find a solution that covers A, B and C may be = covered as well.
 
I agree that in future call routing may be improved = further in access
to LNP servers on the PSTN is available and also if = access to ENUM
is available on the PSTN (some carriers are already = working on this),
but this will take some time.
 
We should also come up with a sself-containing = solution on IP and
not always rely on the PSTN.
 
regards
Richard

        -----Urspr=C3=BCngliche Nachricht-----
        Von: = Michael Hammer [mailto:mhammer@cisco.com]
        Gesendet: = Fr 26.03.2004 17:40
        An: = Stastny Richard
        Cc: = iptel@ietf.org; sipping@ietf.org
        Betreff: = Re: [Iptel] FW: [Enum] Summary on NoPSTN dicussion
       =20
       =20

        Richard,
       =20
        Going out = on a limb here, since I have not seen all the referenced
        discussions.  My first impression is that the description = below is overlay
        complex.
       =20
        I have a = concern that you appear to be proposing that the ENUM dip would
        have = definitive answers to:
        a) = whether a number has been assigned and therefore rout-able,
        b) = whether a number that is assigned was done, and if so whether to a = PSTN
        endpoint = or an IP endpoint.
       =20
        Another = concern is that, if you do get looped routing between the IP = domain
        and the = TDM domain, this is likely an indication of a lack of
        synchronization between the ENUM database and the LNP = database.  One or the
        other has = incorrect data.  I suspect that there may be time lags from = when
        an SP = assigns a number and when it gets reflected in one or another
        databases.  If you want the ENUM and LNP databases to be = somewhat
        independent, you might want a loose coupling of the use of the = two systems:
       =20
          = -If endpoint is TDM, then the ENUM database should point to the = PSTN,
        with = default behavior being, if unknown to ENUM, send to PSTN to
        resolve.  (Note this is orthogonal to ENUMs use to select = alternative
        endpoints.)
       =20
          - = If endpoint is IP, then the LNP databases should point to the IP
        domain, = with default behavior being, if unknown to LNP, route in the = PSTN
        to = resolve.
       =20
        The = difference is in the interpretation of a lack of a record.  In = LNP, it
        would = mean that the E.164 number is still owned by the original = switch,
        whereas = in ENUM it would mean that the E.164 number is not route-able to = an
        IP = endpoint.  From a TDM perspective, the entire IP domain could be = viewed
        as a = single switch and the LNP routing scheme should work.  The = converse
        (when = records exist) could be true for ENUM.
       =20
        A gateway = between IP-domain and TDM domain, upon seeing that both an LNP
        and an = ENUM dip have not resolved the route, can safely conclude that = the
        number is = unassigned and release the call.
       =20
        Actually, = it may not be necessary to send a setup message to a GW, nor is
        it = necessary to have the ENUM and LNP databases duplicate each = other.  It
        should be = sufficient for an ENUM DB to query the LNP DB and respond with = an
        appropriate answer, or the converse.
       =20
        Mike
       =20
       =20
        At 04:22 = PM 3/25/2004 +0100, Stastny Richard wrote:
        >Cross = posting from enum@ietf.org
        >The = discussion is going on the enum-list
        >
        >Richard Stastny
        >OeFEG
        >+43 = 664 420 4100
        >
        >
        >-----Original Message-----
        >From: = Stastny Richard
        >Sent: = Thursday, March 25, 2004 1:08 PM
        >To: = Marian Durkovic; lwc@roke.co.uk
        >Cc: = enum@ietf.org
        >Subject: [Enum] Summary on NoPSTN dicussion
        >
        >Dear = colleagues,
        >
        >There = was a lot of discussions on-list and off-list on this issue,
        >so I = will try to summarize at least my view of the problem.
        >I = will also include my current view on the ;enumdi
        >and = the ;pstn indicator for the tel: URI
        >
        >ENUM-enabled UAs and Servers are currently = processing
        >received E.164 numbers (either in a tel:+xxx URI or in a = sip: URI
        >in = the format sip:+xxxx@proc.net;user=3Dphone) in the following = way:
        >(for = simplicity I am only dealing with voice calls)
        >Please holler if I got something wrong or you = disagree
        >
        >1. = Query ENUM (in e164.arpa)
        >
        >2. if = a NAPTR is found with an "enumservice" sip or = voice:sip,
        >handle the call as if you have received a sip: URI in the = format
        >sip:user@prov.net in the first place.
        >
        >3. If = a NAPTR is found with an "enumservice" voice:tel
        >3a. = and the tel: URI is pointing to a different number,
        >query = ENUM again for this number
        >3b. = if the tel: URI is the same as the AUS, forward the
        >call = to the PSTN, if you are able to do so.
        >
        >Note: = here the proposed ;pstn indicator may come in handy:
        >In 3a = you may use it in the NAPTR to prevent a second ENUM-query
        >and = force the call to the PSTN.
        >In 3b = the server may add ;pstn to inform the next proxy about
        >The = decision to force the call to the PSTN. On the other hand,
        >In = this case also the ;enumdi indicator may be used just to prevent
        >an = ENUM query. Result: ;pstn is used in ENUM - ;enumdi is used in
        >signalling.
        >
        >4. = Now the real problem starts: If the ENUM-query returns NXDOMAIN,
        >the = current assumption of all clients is: the call is routed to the
        >PSTN = if the server is able to do so (eventually with the ;enumdi set.
        >
        >This = means, we refer the problem to the PSTN. This is not nice for
        >variou= s reasons:
        >1. we = are bothering the PSTN in some cases unnecessarily
        >2. = the PSTN may not know what to do either and bounce the
        >call = back, which is creating loops
        >3. = and finally: what are we doing if there is no PSTN anymore ;-)
        >Ok, = this seems far reached, but Internet Telephony should be finally
        >self-containing.
        >
        >So = what are the additional policies we may want to tell an ENUM-
        >client?
        >
        >1. No = such number (unassigned number)
        >1a. = The whole number range (number block)is unassigned
        >1b. = There are numbers assigned in this number range, but if you
        >do = not find one in ENUM, you also will not find one on the PSTN, so
        >it = makes no sense to route it to the PSTN (ENUM-only)
        >2. = Default routing for the whole number range (number block) to a = VoIP
        >gateway.
        >2a. = The whole block is routed, there are no individual entries in = ENUM
        >(e.g. = 1-800 numbers)
        >2b. = There are numbers in ENUM, but if you do not find an entry, = route
        >the = call to the default gateway given. One example for this case may = be
        >a = VoIP provider operating an island only connected to the PSTN. = Some
        >of = the users are also in ENUM (opt-in). If he provider now opens up = access
        >to = the Internet via a gateway (border element, ...), he may want to = route
        >all = calls for his users not in ENUM to the gateway provided by = default
        >
        >Case = 1a and 2a can be dealt with in e164.arpa with wildcards, because = no
        >Additional entries below exist.
        >Case = 1b and 2b cannot be dealt within e164.arpa, because wildcards do
        >not = support this.
        >
        >The = solutions proposed for this sofar are.
        >
        >A. = use tables in each server. This is not a good idea and does not = help
        >ENUM-enable UA. The information should be stored in a = global accessible
        >and = public database (DNS).
        >
        >B. = use a (one, common) second common tree (e164shadow.arpa, where you = put
        >in = only the wildcards for the number ranges in question. The = processing
        >assumption now should be:
        >
        >If = the ENUM-query returns NXDOMAIN, the call is not routed to the = PSTN
        >In = any case, the server queries e164shadow.arpa, and only if no = entry
        >is = found there, the call is routed to the PSTN. The management and
        >delegation procedures of the tree are the same as for = e164.arpa.
        >The = second tree would contain only wildcard NAPTR RR for number = ranges
        >
        >This = would be the optimal solution proposed sofar. The problem is = that
        >a = common agreement and a definition on the second tree is = necessary.
        >
        >C. = Use individual second shadow trees, eg on a national level, eg = in
        >Austria e164shadow.at would be used. The problem here is = how one can
        >find = out the domain names of the individual trees.
        >One = solution is to do it with a table in each server (which is not = good).
        >
        >The = other solution is to put pointers in e164.arpa, eg SRV RR or even MX = RR.
        >The = MX record would give eg the root of the other tree, and each = tree
        >would = be structured in the sane way like e164.arpa, so the same = algorithms
        >can = be used.
        >
        >Since = the structure of the delegations in e164.arpa varies (Tier 1 = levels),
        >there = is no easy way to find out the level of the pointers, even if they = are
        >only = on the Tier 1 layer.
        >
        >It = was proposed to search either top down (faster) or bottom up = (more
        >flexible), because this would allow sub-policies in number = ranges.
        >
        >D. = Are there additional possibilities or proposals?
        >
        >Finally I come to the last issue:
        >
        >For = case 1a and 1b above (no such number) an "enumservice" is = necessary
        >to = indicate that there exists no such number, neither in ENUM nor on = the
        >PSTN.
        >
        >Proposals sofar are:
        >
        >Use a = special flag e.g. "n" or "v"
        >Use a = "enumservice" e.g. "E2U+NONE" or = "E2U+VOID" or only "VOID"
        >
        >Also = here additional proposals are invited.
        >
        >Best = regards
        >
        >Richard
        >
        >
        >
        >
        >_______________________________________________
        >enum = mailing list
        >enum@ietf.org
        >https://www1.ietf.org/mailman/listinfo/enum=
        >
        >_______________________________________________
        >Iptel = mailing list
        >Iptel@ietf.org
        >https://www.ietf.org/mailman/listinfo/iptel=
       =20
       =20

z{x%^=E1=A6=9Ezr=08m=E1=A8=B6?
0u'~ffX)n

------_=_NextPart_001_01C41699.DB36BC02-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 30 16:37:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13885 for ; Tue, 30 Mar 2004 16:37:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Qux-000680-Bn for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 16:37:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ULb74b023531 for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 16:37:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Qur-000659-AU; Tue, 30 Mar 2004 16:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8QuN-00063J-J5 for enum@optimus.ietf.org; Tue, 30 Mar 2004 16:36:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13832 for ; Tue, 30 Mar 2004 16:36:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8QuL-0001BN-00 for enum@ietf.org; Tue, 30 Mar 2004 16:36:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8QtP-00016m-00 for enum@ietf.org; Tue, 30 Mar 2004 16:35:32 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B8QsU-00012W-00 for enum@ietf.org; Tue, 30 Mar 2004 16:34:35 -0500 Content-Class: urn:content-classes:message Subject: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Date: Tue, 30 Mar 2004 23:34:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-ID: <06CF906FE3998C4E944213062009F162233C79@oefeg-s02.oefeg.loc> x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQWmeVJedDyTQO7TTSOY+34TBV+cwABDFE4 From: "Stastny Richard" To: "James McEachern" , "Michael Hammer" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SmltIHdyb3RlOg0KPlRoaXMgc2VlbXMgdG8gc3VnZ2VzdCB0aGF0IHJvdXRpbmcgdG8gYW4gSVAg ZW5kcG9pbnQgd291bGQgcmVxdWlyZSBhbiBFTlVNIGVudHJ5IC0gb3RoZXJ3aXNlIHRoZSBnYXRl d2F5IGNvdWxkIHNhZmVseSA+YXNzdW1lIHRoZSBudW1iZXIgaXMgdW5hc3NpZ25lZC4gRG8geW91 IHJlYWxseSBtZWFuIHRoaXM/IFdoYXQgd291bGQgdGhpcyBkbyB0byBvcHQtaW4/DQogDQpGb3Ig RU5VTS1vbmx5IG51bWJlcnMgeWVzLCBmb3Igb3B0LWluIG51bWJlcnMgbm90Lg0KIA0KU29tZSBu dW1iZXIgcmFuZ2VzIGFyZSBvcHQtaW4gKHRoYXQgbWVhbnMgdGhleSBhbHNvIGV4aXN0IG9uIHRo ZSBQU1ROKSwgc29tZSBudW1iZXIgcmFuZ2VzIGFyZSANCkVOVU0tb25seSAodGhhdCBtZWFucyB0 aGV5IGRvIG5vdCBleGlzdCBvbiB0aGUgUFNUTikuDQogDQpXaGF0IEkgYW0gc2F5aW5nIGlzIHRo YXQgdGhlcmUgbmVlZCB0byBleGlzdCBzb21lIG1lYW5zIG9uIElQIHRvIGRpc3Rpbmd1aXNoIGJl dHdlZW4gdGhlIHR3bw0Kb3B0aW9ucy4NCiANCnJlZ2FyZHMNClJpY2hhcmQNCg0KCSAgICAgIA0K DQo= _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 30 18:47:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05612 for ; Tue, 30 Mar 2004 18:47:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj1-0006ZK-GI for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q799BG013950 for enum-archive@odin.ietf.org; Thu, 26 Feb 2004 02:09:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFcx-0003Bk-6C; Thu, 26 Feb 2004 02:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFcF-0002jm-Vb for enum@optimus.ietf.org; Thu, 26 Feb 2004 02:07:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18450 for ; Thu, 26 Feb 2004 02:07:25 -0500 (EST) From: fujiwara@jprs.co.jp Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwFcC-000079-00 for enum@ietf.org; Thu, 26 Feb 2004 02:07:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwFbI-000026-00 for enum@ietf.org; Thu, 26 Feb 2004 02:06:29 -0500 Received: from sender2.nic.ad.jp ([61.120.151.69] helo=sender2.jprs.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1AwFat-0007jd-00 for enum@ietf.org; Thu, 26 Feb 2004 02:06:03 -0500 Received: from alias.jprs.co.jp (alias.jprs.co.jp [192.168.102.41]) by sender2.jprs.co.jp (8.11.6/8.11.6) with ESMTP id i1Q6ktL15361; Thu, 26 Feb 2004 15:46:56 +0900 Received: from unix01.jprs.co.jp (unix01.jprs.co.jp [192.168.118.11]) by alias.jprs.co.jp (8.11.7p1+Sun/8.11.7) with ESMTP id i1Q751326175; Thu, 26 Feb 2004 16:05:01 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by unix01.jprs.co.jp (8.11.6/8.11.6) with ESMTP id i1Q74w509181; Thu, 26 Feb 2004 16:05:01 +0900 Date: Thu, 26 Feb 2004 16:04:57 +0900 (JST) Message-Id: <20040226.160457.102567026.fujiwara@jprs.co.jp> To: lwc@roke.co.uk Cc: enum@ietf.org Subject: Re: [Enum] One more quality "experience" In-Reply-To: References: X-Mailer: Mew version 4.0.64 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear, Mr. Conroy and enum list members, I'm Kazunori Fujiwara, and I'm developing ENUM client and registry. I agree with you. I read rfc2916bis and DDDS RFC. In RFC3403 page 9, there is a E164 Example. $ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@foo.se!i" . IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i" . If we MUST process in ORDER-field order without checking SERVICE-field, we MUST choose order=100 entry only. # RFC3404 Appendix A. Pseudo Code seems to be such code. But in RFC3403 page 9 E164 Example, "These state that the available protocols used to access that telephone's service are either the Session Initiation Protocol or SMTP mail." So, I assume ENUM client can check SERVICE-field(enumservice match) before ORDER-field sorting. Is it correct? Regards, -- Fujiwara, Kazunori JPRS > From: "Conroy, Lawrence (SMTP)" > Subject: [Enum] One more quality "experience" > Date: Wed, 25 Feb 2004 12:05:28 +0000 > Hi Folks, > I did say that the experiences draft was a living document, didn't I? > > If an ENUM client can't handle//support//understand fields (or the > result) of a NAPTR, > then it can discard it and carry on with processing of any remaining > NAPTRs. This seems > reasonable to me (see 2.9 of the "experiences" draft). > > RFC2916bis (section 1.3) requires a client to process NAPTRs sorted on > the ORDER field, > and to always deal with NAPTRs with a "winning" ORDER value first. They > can take the > PREFERENCE field "under advisement", but they MUST consider the ORDER > field value. > > However, if a client can't handle any of the NAPTRs with this winning > ORDER value, what > do they do - give up or carry on? > At least some clients appear to be sorting all of the NAPTRs in a > domain first on ORDER > and then on PREFERENCE, and processing entries from this sorted list > one by one. If they > can't handle the "current" NAPTR, then they go on to the next. > > This does have a (fairly subtle) implication for Registrants; if you > just want to "disable" > a NAPTR, you shouldn't just change the ORDER value (to, say, 250) but > leave it in the zone. > At least some clients will (eventually) get around to processing it if > they can't handle > any of the other ones. > > Thus, please don't put in a test NAPTR with an ORDER field value of 250 > knowing that it > won't get processed (and you won't get called at 3 in the morning). If > (for example) the > other "winning" NAPTRs all have a syntax error, it may, and you will :| > > On the grounds that this is very close to the logic of section 2.9 of > the "experiences" > draft, I don't think it needs its own section, but I await any > comments. Failing that, > I'll re-jig 2.9 to spell this out once we come out of shadow. > > all the best, > Lawrence > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 30 18:50:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06539 for ; Tue, 30 Mar 2004 18:50:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riz-0006ZK-Dq for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DM1S6N001976 for enum-archive@odin.ietf.org; Fri, 13 Feb 2004 17:01:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlMw-0000Ip-VW; Fri, 13 Feb 2004 17:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlMA-0008VX-Uc for enum@optimus.ietf.org; Fri, 13 Feb 2004 17:00:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09476 for ; Fri, 13 Feb 2004 17:00:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlM8-0001cc-00 for enum@ietf.org; Fri, 13 Feb 2004 17:00:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArlLF-0001XS-00 for enum@ietf.org; Fri, 13 Feb 2004 16:59:22 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1ArlKR-0001NV-00 for enum@ietf.org; Fri, 13 Feb 2004 16:58:31 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMG0X7>; Fri, 13 Feb 2004 21:58:00 -0000 Received: from [127.0.0.1] (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1ZGN1CWY; Fri, 13 Feb 2004 21:57:47 -0000 From: "Conroy, Lawrence (SMTP)" To: Richard Shockey Cc: enum@ietf.org In-Reply-To: <6.0.1.1.2.20040211121837.0445e520@joy.songbird.com> References: <6.0.1.1.2.20040211121837.0445e520@joy.songbird.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Enum] Fwd: I-D ACTION:draft-conroy-enum-experiences-00.txt Date: Fri, 13 Feb 2004 21:57:45 +0000 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,BIZ_TLD autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi folks, in case anyone was wondering what an -01 was doing on the IETF site - it's my fault. I hit the send button to Internet-drafts twice. The secretariat was kind enough to publish the second one as well as the first. They should be identical (apart from the "-01" in the text :), so there's no need to download (or read) this "new" one as well. Mea culpa. all the best, Lawrence On 11 Feb 2004, at 5:18 pm, Richard Shockey wrote: > >> To: IETF-Announce: ; >> From: Internet-Drafts@ietf.org >> Reply-to: Internet-Drafts@ietf.org >> Subject: I-D ACTION:draft-conroy-enum-experiences-00.txt >> Date: Tue, 10 Feb 2004 15:56:29 -0500 >> Sender: owner-ietf-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : ENUM Implementation Issues and Experiences >> Author(s) : L. Conroy >> Filename : draft-conroy-enum-experiences-00.txt >> Pages : 0 >> Date : 2004-2-10 >> >> This document captures experience in implementing systems based on the >> ENUM protocol, and experience of ENUM data that have been created >> by >> others. As such, it is informational only, and produced as a help >> to >> others in reporting what is 'out there' and the potential pitfalls >> in >> interpreting the set of documents that specify the protocol. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-conroy-enum-experiences >> -00.txt >> >> To remove yourself from the IETF Announcement list, send a message to >> ietf-announce-request with the word unsubscribe in the body of the >> message. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-conroy-enum-experiences-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-conroy-enum-experiences-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: <2004-2-10153811.I-D@ietf.org> >> >> ENCODING mime >> FILE /internet-drafts/draft-conroy-enum-experiences-00.txt >> >> > -00.txt> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 > 815.333.1237 > or > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 30 18:58:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08421 for ; Tue, 30 Mar 2004 18:58:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riu-0006ZK-Lg for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEElNs001068 for enum-archive@odin.ietf.org; Thu, 25 Mar 2004 09:14:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZ3-0007QS-AC; Thu, 25 Mar 2004 09:10:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ThK-00074O-5D for enum@optimus.ietf.org; Thu, 25 Mar 2004 07:10:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16669 for ; Thu, 25 Mar 2004 07:10:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ThF-0001dM-00 for enum@ietf.org; Thu, 25 Mar 2004 07:10:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6TgI-0001XX-00 for enum@ietf.org; Thu, 25 Mar 2004 07:09:55 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B6TfN-0001NV-00 for enum@ietf.org; Thu, 25 Mar 2004 07:08:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Mar 2004 13:08:20 +0100 Message-ID: <06CF906FE3998C4E944213062009F162233C3E@oefeg-s02.oefeg.loc> Thread-Topic: Summary on NoPSTN dicussion Thread-Index: AcQRt9bcSuB7Oo7AS0Gc2AYgmYqO+gAlPKGQ From: "Stastny Richard" To: "Marian Durkovic" , Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Enum] Summary on NoPSTN dicussion Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear colleagues, There was a lot of discussions on-list and off-list on this issue, so I will try to summarize at least my view of the problem. I will also include my current view on the ;enumdi and the ;pstn indicator for the tel: URI ENUM-enabled UAs and Servers are currently processing=20 received E.164 numbers (either in a tel:+xxx URI or in a sip: URI in the format sip:+xxxx@proc.net;user=3Dphone) in the following way: (for simplicity I am only dealing with voice calls) Please holler if I got something wrong or you disagree 1. Query ENUM (in e164.arpa) 2. if a NAPTR is found with an "enumservice" sip or voice:sip, handle the call as if you have received a sip: URI in the format sip:user@prov.net in the first place. 3. If a NAPTR is found with an "enumservice" voice:tel 3a. and the tel: URI is pointing to a different number, query ENUM again for this number 3b. if the tel: URI is the same as the AUS, forward the call to the PSTN, if you are able to do so. Note: here the proposed ;pstn indicator may come in handy: In 3a you may use it in the NAPTR to prevent a second ENUM-query and force the call to the PSTN. In 3b the server may add ;pstn to inform the next proxy about The decision to force the call to the PSTN. On the other hand, In this case also the ;enumdi indicator may be used just to prevent an ENUM query. Result: ;pstn is used in ENUM - ;enumdi is used in=20 signalling. 4. Now the real problem starts: If the ENUM-query returns NXDOMAIN, the current assumption of all clients is: the call is routed to the PSTN if the server is able to do so (eventually with the ;enumdi set. This means, we refer the problem to the PSTN. This is not nice for various reasons: 1. we are bothering the PSTN in some cases unnecessarily=20 2. the PSTN may not know what to do either and bounce the call back, which is creating loops 3. and finally: what are we doing if there is no PSTN anymore ;-) Ok, this seems far reached, but Internet Telephony should be finally=20 self-containing. So what are the additional policies we may want to tell an ENUM- client? 1. No such number (unassigned number) 1a. The whole number range (number block)is unassigned 1b. There are numbers assigned in this number range, but if you do not find one in ENUM, you also will not find one on the PSTN, so it makes no sense to route it to the PSTN (ENUM-only) 2. Default routing for the whole number range (number block) to a VoIP gateway. 2a. The whole block is routed, there are no individual entries in ENUM (e.g. 1-800 numbers) 2b. There are numbers in ENUM, but if you do not find an entry, route the call to the default gateway given. One example for this case may be a VoIP provider operating an island only connected to the PSTN. Some of the users are also in ENUM (opt-in). If he provider now opens up = access to the Internet via a gateway (border element, ...), he may want to = route all calls for his users not in ENUM to the gateway provided by default Case 1a and 2a can be dealt with in e164.arpa with wildcards, because no Additional entries below exist. Case 1b and 2b cannot be dealt within e164.arpa, because wildcards do not support this. The solutions proposed for this sofar are. A. use tables in each server. This is not a good idea and does not help ENUM-enable UA. The information should be stored in a global accessible = and public database (DNS). B. use a (one, common) second common tree (e164shadow.arpa, where you = put=20 in only the wildcards for the number ranges in question. The processing assumption now should be:=20 If the ENUM-query returns NXDOMAIN, the call is not routed to the PSTN In any case, the server queries e164shadow.arpa, and only if no entry is found there, the call is routed to the PSTN. The management and delegation procedures of the tree are the same as for e164.arpa. The second tree would contain only wildcard NAPTR RR for number ranges This would be the optimal solution proposed sofar. The problem is that a common agreement and a definition on the second tree is necessary. C. Use individual second shadow trees, eg on a national level, eg in Austria e164shadow.at would be used. The problem here is how one can=20 find out the domain names of the individual trees.=20 One solution is to do it with a table in each server (which is not = good). =20 The other solution is to put pointers in e164.arpa, eg SRV RR or even MX = RR.=20 The MX record would give eg the root of the other tree, and each tree would be structured in the sane way like e164.arpa, so the same = algorithms can be used. Since the structure of the delegations in e164.arpa varies (Tier 1 = levels), there is no easy way to find out the level of the pointers, even if they = are only on the Tier 1 layer. It was proposed to search either top down (faster) or bottom up (more=20 flexible), because this would allow sub-policies in number ranges. D. Are there additional possibilities or proposals? Finally I come to the last issue: For case 1a and 1b above (no such number) an "enumservice" is necessary to indicate that there exists no such number, neither in ENUM nor on the PSTN. Proposals sofar are: Use a special flag e.g. "n" or "v" Use a "enumservice" e.g. "E2U+NONE" or "E2U+VOID" or only "VOID" Also here additional proposals are invited. Best regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 30 18:58:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08459 for ; Tue, 30 Mar 2004 18:58:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riu-0006ZK-Jl for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GL19Ca021246 for enum-archive@odin.ietf.org; Mon, 16 Feb 2004 16:01:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsprU-0005Vj-KR; Mon, 16 Feb 2004 16:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aspr6-0005Pu-6A for enum@optimus.ietf.org; Mon, 16 Feb 2004 16:00:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23556 for ; Mon, 16 Feb 2004 16:00:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aspr4-0005w4-00 for enum@ietf.org; Mon, 16 Feb 2004 16:00:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asppp-0005gk-00 for enum@ietf.org; Mon, 16 Feb 2004 15:59:22 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1Aspoq-0005Q0-00 for enum@ietf.org; Mon, 16 Feb 2004 15:58:20 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (h-68-165-240-38.MCLNVA23.covad.net [68.165.240.38]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1GL6Hd10965 for ; Mon, 16 Feb 2004 13:06:17 -0800 Message-Id: <6.0.1.1.2.20040216154518.03b5f640@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 16 Feb 2004 15:45:23 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=BIZ_TLD autolearn=no version=2.60 Subject: [Enum] Fwd: I-D ACTION:draft-conroy-enum-experiences-01.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-conroy-enum-experiences-01.txt >Date: Fri, 13 Feb 2004 16:09:55 -0500 >Sender: owner-ietf-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : ENUM Implementation Issues and Experiences > Author(s) : L. Conroy > Filename : draft-conroy-enum-experiences-01.txt > Pages : 9 > Date : 2004-2-12 > >This document captures experience in implementing systems based on the > ENUM protocol, and experience of ENUM data that have been created by > others. As such, it is informational only, and produced as a help to > others in reporting what is 'out there' and the potential pitfalls in > interpreting the set of documents that specify the protocol. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-conroy-enum-experiences-01.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-conroy-enum-experiences-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-conroy-enum-experiences-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. >Content-Type: text/plain >Content-ID: <2004-2-13163058.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-conroy-enum-experiences-01.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 30 18:58:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08477 for ; Tue, 30 Mar 2004 18:58:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rit-0006ZK-QF for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKFcLI4009129 for enum-archive@odin.ietf.org; Thu, 20 Nov 2003 10:38:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqsc-0002HU-6a; Thu, 20 Nov 2003 10:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqsD-00026B-8R for enum@optimus.ietf.org; Thu, 20 Nov 2003 10:37:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09687 for ; Thu, 20 Nov 2003 10:37:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqsA-0004l8-00 for enum@ietf.org; Thu, 20 Nov 2003 10:37:34 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AMqsA-0004kT-00 for enum@ietf.org; Thu, 20 Nov 2003 10:37:34 -0500 Received: from ibm-eyjgx9r6nqt.shockey.us (neustargw.va.neustar.com [209.173.53.233]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hAKFhQf14087; Thu, 20 Nov 2003 07:43:26 -0800 Message-Id: <6.0.1.1.2.20031120103555.036dbec0@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 20 Nov 2003 10:36:39 -0500 To: "'James Seng'" From: Richard Shockey Subject: RE: [Enum] IETF58 ENUM WG slides for enum-voip-numbering Cc: "'enum@ietf.org'" In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF01E81046@vsvapostal8.vasrv .verisign.com> References: <5BEA6CDB196A4241B8BE129D309AA4AF01E81046@vsvapostal8.vasrv.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 07:30 AM 11/20/2003, Hollenbeck, Scott wrote: >I took the minutes and sent them to both Rich and Patrik after the meeting >concluded. I'll have the draft notes up either today or tommrrow at the latest >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 30 18:58:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08589 for ; Tue, 30 Mar 2004 18:58:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Ris-0006ZK-BQ for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA69pTEw012338 for enum-archive@odin.ietf.org; Thu, 6 Nov 2003 04:51:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgmd-00038u-HP; Thu, 06 Nov 2003 04:50:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgjj-0002d6-HN for enum@optimus.ietf.org; Thu, 06 Nov 2003 04:47:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01781 for ; Thu, 6 Nov 2003 04:47:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHgjW-00062Q-00 for enum@ietf.org; Thu, 06 Nov 2003 04:47:18 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1AHgjV-00061Q-00 for enum@ietf.org; Thu, 06 Nov 2003 04:47:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message Subject: RE: RE : [Enum] Prototype of ENUM validation system online MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Nov 2003 10:51:58 +0100 Message-ID: <06CF906FE3998C4E944213062009F16223396E@oefeg-s02.oefeg.loc> Thread-Topic: RE : [Enum] Prototype of ENUM validation system online Thread-Index: AcOkSJc/bc2hxU74SFatF7qMLtlHCQAAG7RQ From: "Stastny Richard" To: "Clive D.W. Feather" , Cc: , , Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable See inline: > -----Original Message----- > From: Clive D.W. Feather [mailto:clive@demon.net]=20 > Sent: Thursday, November 06, 2003 9:28 AM > To: Olivier.Girard@bakom.admin.ch > Cc: ppfautz@att.com; mah@eunet.at; enum@ietf.org > Subject: Re: RE : [Enum] Prototype of ENUM validation system online >=20 >=20 > Olivier.Girard@bakom.admin.ch said: > > The best thing would be to have a validation process totally=20 > > independent from the TSP... This is not possible as long as the TSP=20 > > will be responsible for the allocation of individual E.164=20 > numbers to=20 > > customers. > >=20 > > What about a direct allocation of E.164 numbers to the=20 > customers based=20 > > on the model used for Internet domain names ? > >=20 > > This could be done directly by the Authority managing the E.164=20 > > ressources in a country... >=20 > Can you say "political minefield"? >=20 > I don't have time to write a full explanation of the history=20 > and issues, but a proposal like that would simply result in=20 > Enum being seen, by UK telcos, as "a stupid idea from a bunch=20 > of complete idiots". Hold on, currently service numbers are already given to the end-users directly. What is proposed here by Oliver is to do the same for portable geo and mobile numbers also. This has nothing to do with ENUM. He then proposes to use the MODEL (and the Registry technology) used for domain names. Still nothing to do with ENUM. You may then use the Registry database to either populate ENUM DNS and/or IN-databases. Then ENUM may or may not be involved So what is the problem in UK? Richard >=20 > --=20 > Clive D.W. Feather | Work: | Tel: =20 > +44 20 8495 6138 > Internet Expert | Home: | *** NOTE CHANGE *** > Demon Internet | WWW: http://www.davros.org | Fax: =20 > +44 870 051 9937 > Thus plc | | Mobile:=20 > +44 7973 377646 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 30 19:00:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08910 for ; Tue, 30 Mar 2004 19:00:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006Yx-Vd for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2386JJ7005579 for enum-archive@odin.ietf.org; Wed, 3 Mar 2004 03:06:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyROL-0001Ne-06; Wed, 03 Mar 2004 03:06:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRNo-0001LC-Hy for enum@optimus.ietf.org; Wed, 03 Mar 2004 03:05:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09273 for ; Wed, 3 Mar 2004 03:05:13 -0500 (EST) From: jon.peterson@neustar.biz Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRNQ-0000xm-00 for enum@ietf.org; Wed, 03 Mar 2004 03:05:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRMQ-0000kb-00 for enum@ietf.org; Wed, 03 Mar 2004 03:04:10 -0500 Received: from ip010.skynet.lt ([212.122.69.10] helo=aruniaus-pc ident=M-0-163) by ietf-mx with smtp (Exim 4.12) id 1AyRLY-0000YN-00 for enum@ietf.org; Wed, 03 Mar 2004 03:03:16 -0500 Date: Wed, 03 Mar 2004 10:03:17 +0200 To: enum@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jebehjuosaftnenuwnuc" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [Enum] Weah, hello! :-) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , ----------jebehjuosaftnenuwnuc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Looking forward for a response :P pass: 33571 ----------jebehjuosaftnenuwnuc Content-Type: application/octet-stream; name="Msg.zip" Content-Disposition: attachment; filename="Msg.zip" Content-Transfer-Encoding: base64 UEsDBAoAAQAAACBQYzBllHZKXlUAAFJVAAANAAAAa2x2Z25pbmZhLmV4ZfImhYXqdJtAWCJh DrTxh3JRrUsDAltU96lXI5KMBCuTg2Gyi/6d7EYtSMJ3uxIGEVJyTAk6dsu2VU22N/F+55b7 5DeaFiYBK6VM9GzNHSKR5rGgnR1ReisiSD/xMrzJytLZFxhnhVdJZ6UMsNLO7/XLZSYWh2Aa upxuS55TwWQLb3iTaw+a37I3yXHEpGXoePS3MGMfMBFDoIZrWmcTkeQgxjvtTBGm+Q+m5meM 9RP8r7Ps6qBL0zhkvF3aAH9iT5S7bxuoaTredYDwFPuiCKR2UMLyTeLDCiU7ya2+CL1FW82i ZNRGPJ6GOKNTkTAdS2OEClzIHP2h4BFTdbBBcfdYKCWj2awDQr26h00wytdgNdwnIWG5aDjm VWwKejQcS8RisQ+JYBclxoGKufACy/NxcvMI45wmYWzHi2wA78+P08ZOGWqdZvl3kJaNKdLh iPMlFOYxh1QwQ7eQ6Y6+hFUqTG2mTyA4+lPGC+XL+CmuUn5o7xi2fXHdKaM4mg+4FPJYyMJy ABwhPlvebSwjRPYxj+SF/LZfXDni/ko0eANiuy3pdbsInoh9U5ol7hHBEmPNA21Zc53f695D +x9yDDcOHyE3LMtDAdR1CfIJ8tDvJWuReW+HJqEYq+g5dtbUsO8I9S2W20J4uq/ouADQBPI8 ODztT+AdZR0Xhc1gmQSbXxCuqLeAUTCfmZNuZM1bG2zrx9pnZRUVyNB+hJyEitJbL1t2M9CA RsEGJA2hjtl5sJJm9KtmNDcYjqjSMTGAFxVRFckSiJvqjoTofnVPvBFaI6pya7cJYHY4YjF5 sp/PupJtZ0OV+Imbx96bU7fYJC+gg7kHrxrd+wEORDyKQobtK4km2vqiUfjs/tHsVORQcL1b P9an5KUgnyxLPk3QivsxkH2Tk9LHjNRMoeW39LldFZsIO1c55GSeQ8HjOKRfMHXE5el6YaMp 5lWpEMpjwuQ4xYkGR0G6INXLPDeY+VuLzbtKrkKtMBrLl+NBES17O/bosgaP7rvh1yLxwqx3 ky78Z7vbpiz0NXgmzIjMothe32W/Ak3YW6hj9aiK7OgynfQxFEKPsF84sSOWf+SZhnaA44Ha DBePU4Agd75n4d0r53q6YybW1R/D0v4zZFUNIrIFligFHnez+MYefdXoodghbDQuRH3Bl1L/ 37Dtm43J/s1C2lHRBT2to4EAAfSOjVaP6pkoJR6juJ+vD1L82utNaBX9OKg2IA8U6hJC6FCY vQqVH5JrMAVHNKxQ1jSBOvs40A33+y4oBwgLS0b+Asmi0G2OIiuip42H7A7p2DuTB45YqvzB 9jD/9SmcTw3x9J51w+fOBMKii1tqatS3rXzG1eOr170kdaJWtn6ggzaL6R8O2xEDJpIUn3ca PHn50NobjJvD9hedBaGfHeQQ/LY4PT90bS+h8HXqE4XqJEi8MExbV85EhWV9Kf6E+ugCZREU ZGH/QE/T/19GUoBp7A8H5nDBRwff0uX4yS7EXNp93jjcOTyotLrF7QcqLyVLduUf0IrRIrD4 xSiVOtnG2SPe2PyvpRpUoAH/71HHSSLZi3If06lgJI/g4gCzU9aj4nM+9MYSAWbRqM3xopgk FX5xpX9T4gWf7laJCKHAPV4mXjOthoaK6ETTYT+y54jyUAcwff2q1agmgn+p9Yj7qEEMES+r Tel9sH28lBLfd7F21Pcrvl8ycSUGAefZSgKGHvmOYrlqWJ8ETSSzvpYMUYnjJ8LJc3+IXhmz ocJZ4DLRMtjNdwgTMFyEkZBhRBYVdaPIQlnnVq+JyImFhYqu8W4oceL4EJuPZAVK8pEchQRq zFVKBPWegMRHHFQjrf2MvNlkNvKDzTtXpnDiBgzk+lmiDIYaVIhoQCWfzcNB8u0LXgOR8aqa JHb1CB9wdXPLWK35YDUbQtCdXSRHh7CwCVIsw0sk5cTfV476YGXgPMb27U4oSD2unvGr+gPt 2WxoMZqYNveYO5MtIBGE4lzPl8L8lZ7X+2CJ1m4mzOdTxHktHLXviFFT8HmfY8xbAGh5Oylz XlbONZLvGrIifi2fyh4Aa3mMM8mREli5nJIHKrLS5VYjp5nzQSTO1/UN8d5AAjb9TbbFv3qY pfq29iJoNE74+nnzESwwz4fpDB7VZjyGKUa6bbD9tvqZFZWIIfz9HSR+RnycWgPxfOCjC0Ky i4KngY5Pq5TmF/vb1ErE6ht3lMzjl2HiIfkR9jDujhJJteB/pvzIUegFBEB6ViUD17mvm9sU NYeIsgU6DU9lEZIE6zncHSsfW8H4Xkyk/O+6yY3rticS5X8kL0zLaENYag4XFNzazLCPgpsB PgnKkwrJeW6Q/Lrq6zK640ujNrZxdsQkA5qvYaTff+ErMgAi8HCMwvDXvsODsUdJGGRFWe8u lWaQtVMxR/xawJmMdAZAxxw8l9Hzdma5noQP8Rw62tiInhE1P1zWjay6Srv+QCWfZWroKbZd kmHD2E+hlySlVAheuL8yP8NdbTorHqrgVC6XDjhAEOJgV+s02YsPxkWs+n96RXKIHjmOwp7t S2Dr3vYdw0hPsYstDOAXGr1fkUlS3JX/Cj/YwCjAVVxUEW9mdNGRY41h6FvGVhH4BqVRoJVi G6m08pQDOSOkGQ8T66jiv0uPZbgJBbS6cdgpunlwxS8cpA279NSyJHARZ++lR7MOYmts5PTt /DK3Xk3iIvgQFYBzj2nJVVBJ4LtLjBW8a8GODvQNX5VkOGLyuZncG0E3+n+e8YZF8MTfeH64 xWuraxPxS0wFZhzMfr8DRZGaao9wt2iz3TT0FWVKRF6IgKx9OMROsRHRPIZpQnFC6jiLkiDh h2LrS6PdG6aLSeHxm37oom6DvWA+VIVf+N9h7G0cLOCum58dDYi8P95/J1EWszCS5mme6PBO pxPU8H8VdzBrlO5Me2FhHzNM/TMlMt5/4OA1Bp47u3oo5U3XQUmH7MCYdEwo8j7cECz1JgSW 54oPnUrJ18QNJF0u4PSHAQOxOxjkkk651csWSm1MKG5JIpN7/osqfNA/u//UrvTSLh0oJiYx /AU0/V9yr4lgRspTLRjElBkeqFKduInWAOITwjd6vya/RFyPthbXovTwQwztOJIqrNTNreeZ x4C+NK/NXUrwSVUj54ZbrWQ1jUCtWr9/1QdhGzksdu3nFBTR3bUbJ6OXHUXz9aQcLl4t4Qne w4BO0qSrwuQ8kZVrwuwTZn5TpqK9cyzTh9XgMguKoCtxMMXQL7KlESf8lGJPCF51BzAy4ma+ d3MwixbjPGSAqnEzXaqMWZFTb2Yam6X+W/DwhmdfKRc1v3aCVfKDOwUe0kGT9cuH2/104lmn EwarZCjYt6MjcZsnUvJ0pa9FY7e4MBn1lvKwv0F7aH2vfokVF5G72FXp053zxXdtnQvixC3q q3cEq5VVFiCICUnPWWsZpXvZ9iIqrUXfBpY8qLDQGQDAI0gk2rBUioridNVxeDmK2qRr3tJD 4qxgK1QqxQpJp2mF7vDFgrbVu0VbYI2HuUekjelygwDKhRxPLd9qtCmFmHhuSi17h2K2V7qe byTFPd29yrv7raiitrwVhhMeZaw6+w27iN3K/P513uwsrXHbD8e/UnrScdPa8C36AwsEW9f1 DilWltKOs10C9puGJKaBm5ibVD5Beo9EfM9WukCo715ZQjR+lzkMpXGvW1evgsj1r0BootOr 3xaxNu78OmbRSSLlpLM6y+3WaT9Q/+IodC1W+l8nMZgisq5P6Pli5wblkjDwJ2Sos+CBqEY5 AyfKqHEoUnrQO5mMVnfBQ8Tmw9HEZDygBc+cLbnKvDCFlOg2S+YPI/eM5VYyKc7e67piBkD3 LpyQ7Gj8MYTdynP/D0MeZnZAsifV21wYbs1Iw/GD2yx4W7pjwOrNRiVbqrib2sER5152oCV7 QrwyXaA+9k6hsyc960KKibOyCKhnelBFTDmu5AZpXYu5yCEc+kfI/z2/WpptT3ytD23iIbsm iX4Vc1iQ138sMyu0WuUVo+Ik2/6ygkVg2kL12ungUOkAYuJdXQnnfIesLIbB1NJPLbA0H3DU EPUzV0NXovSk15QCO4iyFJRVfhilFNYvCJry70JVK7aM/2H4JAfWXTRlzlWdEdzDRONDyspq GF0UL/+YWwytBGyWupgpQi1nKtbLT0+dl0nkunOub3Y0eid8VDkSA9lRRsy4PihlGlXvgb4w HcQbua+O3mNXfEH3esfADbKvdXcNBor8mVt4TuvEeTn+tXKwZGAWEE894PX8CozY8o+S3JrH JKcnbp0gNNVElmJCg5XalDmX6YZ2E+9nNsP1r2TDepONYAHWGr6IvlJ1YNPBWev5qtVNLLux J8aWs+YOylqzSzEjkxdbE2dqmmzegbpprrQdIcMcDs27TMX4BmiBBtelA5jVM9u4a8Uuv72V ZbBdlPS65cpmbmijPrtYJUk0QguooabdWabiymhX5NJaGqbLns+tvGbDpgXalmk5pEXDfVIr 38TgrI+serIHmcBV8B8eL10TOogSVNBc+UVfgCUjgEFQ86yps4P6e42/o7UTqqu9lnZ1fQJJ 8+214EUykL28ho50P4r3LVTU0HuMJyH6fOW4thA91qk+lrunf7WMwa03kWDOtzkszP7X/csr W4ko0eDMGk6oiqwHyohcbr9fSubq2TJFYGksoNZkwBiooHW21yaGbU1pofIdvFMAMGoPt8NU 3UK/q8OmhpGvZIdaVUMyqrF0PO6Qi9CsxOCnyNgCXwsnHxa7zw8hClG7oFKt/uaPL9KFDSG5 hofdQUcLoXBnD9Y7tMcoEIQhQ5Wj1dkXS47VFxWkjMnDyyHyR/o8tqhrt9KGayqcrjSqb5eA TWxy89TI689nb8fn1VbLWWZW7xo7b/9/MZEsqT1nonsDwT9zXXG31EKNoKpEOS50DVUHIZqn /Xqg4+EYv8d0PeBmgS5idEMFfOyhvbvS+cgBpNXtC+Ph615wi5PLGqrmhEMC7Vqx5VThN7je VZZFOe4V2eZ3lcqyOMtKgNbyPWq8AB/SD1uoNLV1RrbKgNIs2aiEsV48eKYleqcyF1IuOVhN Vu+FFkVOSOPclgW2ksTgU2kr3h+W+xkrzLthZJnDdrM4uEMW/5+SipcJeNOoDHsGwkGZxcqD RQP1DkqZDwbCc1edFGZeuFPjbi3GXHZTpG5P56tZKQc5e1CiOQheEw/czXg41OPGOSH5yEv2 4mkuP/zLM5SJ1V3qe9/i0s45bbxKnwlnshg3Gt1/mjeDENAudm/mKz4muszYYQI8nm1Ldq51 hFc2qWMMu88SDqJwzqcAqa1TUMk2OgcQkooIdOgyYhTzfu6IfvC2/c4BaFk662DGUfV8fiyr izNO88MV016GVg/IAyxlE7HgmwwfuOqnVjVwjXQ+Rt5YRRMrAmPaBjbcK5N8J2z/wgUkV0nl rLGQTLXUQZKcTRhe2SWc3iqjArPp8UYGE+Dvjyqsii8wcPBCxRpXjHcqAizdm+5xEu6kP1G3 5Ir6ewZQW05gThXg/hnYTem5HCqvYu0ZF2IQQqjtzUFYdaok5kSK2e8JbvHei+xXc1XmR8+5 vq1lVd5OljunesjoAyyRkmDKodlwRSEo7t9t5L5WHHIhwfumtZ6puqrygSNJ/dT7uXYLGBTU itSr87Q25fT/emgZ23xfPAOscjLS6dnVgNRTE47kdK4qnQHhhc8ndICfKhuzEkZuc9gYmzUb 6i231Dkr31BP/793xXI1fbqF6+QZdOEZcinTx+WbY3mHlbLYRakkh/9crIzSLqV9vasRbhXb wDc7tMULqY2x0r2XA/4z7ZRmC4g26f7ssBsk679Th65zbGHcDL/gMgwiNJdYRyf4Ud87N7e+ UBOCpkG1e2QG9zRsUfpmF/o4r/WKnM9lcfyNfpYrgvR5DPZ7ubVZ+Ba/S8K/41rt878DG3dd bJNdVsyc6yuFxJoSCfchVHM3kNNqW8JmIDt4B9MqnVLEUH+fRxgQ5VGCygCps+AsUgdRaUSm S8RHetvHHyZ9Xc1ZWSBk1panArCp8OhVbseWyr9TNpNHFytj6QrM5C31utAHvMIgTAt2lO0q Ug/G1R7q+doDz/WJQSK782ZAqO9q8GNslsn8rNwO3fGt4C32AYhzs9iOyhEyX5JJE4TSbssj 5k6j5LLUqQhPTJPmd+InvXaxfkrQLu/z85B0ERixc76/nZwLD4G0LO5eP1ZDlF1AfbgrNQdA 00F0cfh01+UGSgpao4UwvlyWVaLnt/nS42UXS6qpuTBf8FRk5uxDdwP41cNhfT/tj/C0qcO1 atayajKpCB4n0spIIpQJxJEUgfwztEe+hc9a6fpAGT+ttxpH0hW4V2cvUm3AFMeZxS2GzTTj IJReDcdZtAVWxqcyP1wkthMDjCY9s9c5DD7JiTALlBJMxWnAOYkT/5kP5i7W3NKHGvXD1Mhr Dru5co5sPZElFKj8D+Hfo8ZcHMyzp47FwAfpj6ZIQB+wjXzUKK0j3K5sBKXLv/25RTWvvjo8 YCRiKz3Rr93jRrFLevfJX0UX1eee8YtbhjMiJM3x8jCv7eLDnRSZCbhyqMFaK/lkGG6vGR/X U39mAb1Q4mwxb7p2iGTviqrmCXOliFf0dTFc/b28T1QQSOlkthiyQn7BM9wCVAmCoBPo8noi dZo48vWACFdSSi919nw0IkYFzd5qf6XZTuznuzzSajhNz7P11SorCJKkmE6wROnUDkx0dMrI 5m9Rrudy6D2NG/XdN/P8bDPE/9gDjj4QvUznj/fXbtixSfHuDpPIh1yMLsTMnBCNIQX894lB Mqurhdcm1n3HUOzriSpkbuc8zh5Ctn5Ndpqjq2oUcD3nwV38Iv1onD5Qv624ux010Mxk6xiz bTe50x6z0M4T2oP17LG3gD+i/6yGN2uZsmcAE0TQ1EBP1XmngP4vUgxaQdD+hxQsMxTxtZ+2 Y9kALHRvITQrK1/hRaf0ZgDhKb2uHYNvSdxQo8duOagYR/royvTamVFmtAjeE6Vm5saMrad8 4SiIWBVJkjJUwYivWPuF80af5LLWWnPPscSrON/KEk3NNESH89VmYHdT57zXuUocUGWorRz2 xwHAoDLDYvBAaYvXWybQxEO5JzSx7hYsMsX/yqwHCBzm2r33QNgWy3Wxh/44RAAn6UaUxt3R +TSLEgSwco9dy6hbdbWF0LQSR5qVSpqsIOzaXWaCAsuk+2VyQJKVFELLl/vhmMFN6ggicN+2 wnVJqBZzyyyKKPxZM8ClWf59J3AvMf1hh/60O6PzLYwem4D17bOoCVRmCoJ0mJBPnyT/Prp2 VnGjo6rigZfzhbgINZef3OLbHWOd6ARO1hVEPdOpDJeywG20KmAfiEbZQVIwmDw7andMsXGD 84ACjkp0myBg/bFxyHOiP9/A8h1YGaVbYWBV8/GnjqPgBQ3Rs9DHkzc4JBVi77IfGaoEpDb/ YStIj/gFeMl1cstV7JITDUGqBMz5VJccCyvt709X8p3UMcmVU0bH6HokdujNYdxvlbRXo03g TPlsdavJgFiNffLYDsUzaY2ZyHopVDqh1xXKpqoRe/NNki0PVOGAUcxWzkfw5soLzrfIfOAZ 5mPZ+5VaFxgaeVUPJFlgkbZDmzFlDGED4i3Lceq6Za/x/W3F0NHSsO1ILyl1eNGWIqxLN8Lw Ph/uW1UOa87b9F6ONjAKhmNYujgnixYgPduoLZf8fimR0yCnWwxnxfRagS89razoda5c+ZY0 L0thQDYYS6Mbqj3UjyB3K24SeeTKHrSJ3gVsy2P85zjRJoC/EKmw6t7pKv7UPptrM19UKNIt 8Q9kGaBYqEOwsiQXZ2jlO+kIAO3myJi3SLwwqGEyUFKgYCYZ9DbgJBckpJyGUynv4NBPjVA0 RBphv3lFowmz7jnK8bw4dNTNqNo6+TKkR7B8pITPlhLkVkm4nlxCg9B/bUVflpKJjeFYgjIW pGBHaUV2GS4utNb6cAN9TT4Se5UPzRjlPGFxmAz0v6pCP/6JZBuztIisGqYmGuwVQsK3Tecq ZLtq2Bg2X+1MZI40o816x5K8rsUUaXJGKk/g2v2AMNCKZSaEprxgDGsa60w+/+SHKYov1osw EsPysiefnHxf0z3p9KKAPywmE7TSwYdv5eIp1xfjAy3sArdNkwovGk7UGSZ2JxIgMOpgPAWI HqffwbghCLxkA9tTrmEdxkKOUUCpnNsnHzPvRiynAqXJxw5+4oQzkeXaC6c2wtNkPLrF1NG0 RzMKZVntCpuK0KqEiBIP/k3Pya/4j2fUY8RVc4SzjKsusbBP5235UGin0OfLbnN59IwqOf4Y NSTjp3KgEl3zuUKHU+sy3Z80JfiTuIAQOG0AF25XNm5Gzcd0fneNwYL+Q1PYFgZ2+GpXaV46 +HyGmX7/xG5wf1rbxNJq0ITyk/fuL0Uac/CLd43XYQPI7RaX8k7TTWXinPTAMmmRJyPFtSjj o8ctoxYmka5CXmt7beThS4wYFQXH8tCAn9hPzPNv8W6K6WoI00eUy9VragYivCZVL5LO2Zlo uAcIsoiOhxWP+d9gk+Wm9HPRc60fuuVcUeccZIxbrm8uuJr+jTOqaOSMZOODmERP8fvXx2Go kizYKvDdjN/9Xrjzxk8QG7bZ7UvSnqz2bE9VZk0xxMy19f14Fb+t3yF7iKsLbn/pYa3d4mY/ leoC43bs/JPmDfSxn3Y50O3SYMslVFeX6wsN/1avTFHXXFyKdhYsaQXSUMbfJyFMSFEnpuJO 3NjkA9WkNWiDqjbpEO3E8tKh6zE+cM9p4tooNJb3Evg+VR78uAdIBTgnSLrH+3m3fXSV4lnm cCsn+TNm3zt+YMgmIlP4aezCtH0RbJwScUgNrBw02/GyURBVXVwTj3gi5e/xIZlEc1x2CUYp yaGxM2qv1JwDiLd6oM6yULPnEGIVoPL1yesBoWvHwKkVkO3cozrUiIoX42f+Wt2lLyrJCiEh Q8YID6Yd1+HtBQPJF8G1oIInUA3sTjBjvfk01rPiNQMNd+a6eH4nhbmNwH7jgfePmYbL6C/1 hPT1WP+6xgvH+aPGFNPxZb5pEobrJ8vYgsDG5r0b1r15y33U/Nn8M3ICvHvg4Upym7G+a6gN GxesKJoK/WwXurCbKCXek2YyE9IH21Y0qJeVc7liSKd70TY5MP1KS3XDOnsS2faHfOyEa5+k GHWliXrwnCzt8TcHpTehYEGEmp1HWY4if0WfcwT1toIGcT4bxepeDRuDnAe0Oy2IdKEfUBkE ph9IxbEX1U96WIuJm1aeaXSE0GPqL80m6WVIS7a3grr/icm29r0H0lCdF6Q1i+Zu43BfSD2D JWb8PhwUF2DyHtt2OjMt/60Qqt1b6LXptIbX5t61HAwjywFqMhjuNwdkEEajioPH0fUQo8Ny EnzLw24oN7Lyoqngo2N5JRSV3dJHki1uyruqdc69SwOXbN4wgWEpzeLIISGAWVxAsVyKXEen BhhkooQ2WnwCN1WPneEUnJNRq8pFyZHi+CpfUjbMz0l89MaXZVsL7vGTh+cvusckpN7zW0Pw 8EjvEODD9ViJpERVxKpTR3GqmbIZG1uX1wfsQRK38o/hE0wKx1kQ+uCQJoibU6RvNMjo1XWG Illw5Bm4/sRVNQe32dZHa2nB1OdcswCPqN8StEH21ZUo8AvZbE78IMc76asbNLDoPYyQcAqa xME/qFplmXRZR9gHa7BOQ4O+dc8LoAgkIZbdiRq+ACpruv7/w15hcspyw6Tl9b+9ZnH0SvPG Ez7oPWxbgfy9g/ryjvV+37J3AlWAhRp71hW4e864GfECdWhwABM1MfXky0BVbZm9SVSR+V6l Msx9ovXCZMC5Bbsg4s6bvXARoW9SxMB7hxvohW2NN7hEXNt+RMU8xy+gTdmXOBuQZ3Mf8mG4 Eu27txhazAN+vFR2VznBVNZrPYvsvqPnArpy5ZijcfwxsuSVMVbcBVlBhL5XWaacrkzGm8uF dokpVEubQ2UfGbA76roiL1A/+T6yqZyCu3o+UqTFVKqZsEqZOm2OAWIgrcXDTJCw7H4kIFxJ QkW161eBOBsaaqF+1HOdEhwlQd8yh3XOPlMfyy+UQosXGwjbt4EnF3xmyjU8BI8YOiIzScnm qj8qbuEXRPXAsjPUv8iY6aUHhGrcjD94E5/5FV82qhwgcvnsfNy3lioqcuDAORHzSplK6J4f Xto7pha5gbiQIu6474J3Z5hJE2JtPZEgLsjL/tM8cngPOsZrgjm1x8MzACSolSmyNAe4ljEc JuQPk+rdDOf4NXl2gu+F1Sv4edce5WCa0YERb7Y3spD+x4k5dIKnuhlyy49VV3d/3nAmrmKz d6i1c3jyBfIgSYwUufRzlZ1VtXe5xxS86C4sd+00VWGFi4+KQoZVKaqWQKZkk/4Lpytyiq02 xkvGitYo1TTAqQmJ6dtJ4SfGxlITkluUC+3lDFI9zhETjZhwdQKhK9nSNZ/qi4SoapYwXYQ0 tztyiywmstvg92MCW+/QfsOftoudN9aymxr+e28FsZkSsNlMeSeXj6RNDFZMSDYe+GTxa+5C 0JcEHnVRKeuIfbwdywcKYEJwAKqMgk1RGfEAxCE24JnUMuHYKbBeHRO4JGplt3J97YyoZSjE 5/3uIrMpo4gMYNE21AWA1aj/DV1XUy0VajDCZMsLa60kG35dQPvkSISxW4pVpA47m17Fj53M PY+/hyvzICnOKHnypb5BF3bCtb0mKhhd3x8rQTpchz2P/jlUd/ugp7DGJ0GPKzo7/QMJZXLu oc3RtCco856SRxrbNm255b7XK9lM/bxqRIk5WANiXTZp6kp2gZdLvGZqI1tzzBvZrvzJFN2y bXKINZWuoYQWEK+2J5SX5TiVdHbbiLX0UvpuZvmgyOp1QF7RQJnLUCRMy3f10b4yyTzAkrKV d3EN68W4loITsUknqQV8o6sNj7CRIGqS/VQ6mJgBHj1iQKIq4fExnstTp/3ygjY3nqEBBLEI GjlVPjQ2F5fooaEJyGW/QfvhGCw9c867mPL6bL8mlIFwiqHHE/aL9XWkzsaVviFlRIasS9Yd g71rK7DBxF28h0wH1t2IPGl3+bsN2oAkr5bZiPSb1El98/V0B3iBcdocL3iDpm6yIksXRUT1 WNxi5mVTSxvwyAvDjuu43vd7SOUFNd3rTXCcwdOtr2esO9dc59ksZEQRtXLu8kJhAHXuS9N3 CI2U9q3q6u1f04n/yTU4oS4VEHzoUXkVR2+P6YmLzHTSMq4CT0oMqEt6Kw+08uGtPy+SA5du bm8mEGfLYwDq8E0Qqru1jpDBRshqmUPpeAQ7wtb+9nTOMo+VRuah1AJhHSfeFmuIcQwNGlSy uwpI0yptlvCBNzaZLMvgkuh7CnPa0FAiQ8Y87ObBUcf103ykvJgvpDA36WyUIygtd37Kl2af gALoXOBXB1BnquuXxeeL4i4iJqVKm9DIMhrFybH/euR+ANkpb9MW5Q02yTlIjQ9PIdqQb4AL 6FTvnHKVbZvKcNWMPRQzSMCKxKfIRG3sdTN49nhF1tGOpyO4OvIyiKIJxWA1tj64D1kKk3ym iB0nf23kSqsIMKpNLlrJ1nhfcawb9WxR5Vfqu5/MWaAM5cIF03NGkypskhzrmgm052IwOayz 7ZXPUPcB1i7ZZPS5aPSC8JrGGFTj29GrxRpInBvMmHbTRcj4EVoesFTWFrcn1+c33kbcOAxi /2ITXblqS/3d3USSkJpzyeUZgzHwev4NyxDhz/ye3nJxyxfNxJDCiG01RFvGXMNj02JyxPtl NTD6nwDmSxo8Se9sRMfIzm8x5ODotyMg+7S5oEOG+o20acpBBi4YiMwQp52cc2yxRO+VWoKq 2NPQsqWKVz2Mu+DtyAnNeUhxujQ5d2JAMXEFagk7tpIZE5/S0N7pfajNFruG6QfExWGvMRa2 BefGXtcAlN2cIHITjki3y+sKHPPhF3Al+YlE9d7QnQW/ACpdklaR7xnXZmRY3pe2OBSJjspL FHX519qBnASnsWxSdG3h9HVzSv3Xoke8XdyiX9eGGgWamso/Np/8bUvDRN/VpIbfejnFkWbg oAHCyPKjY/u0mJYDIVvDSdirPJzlWSQMaIY2DGWFRHTKO8wa1yKUp0PvTrQadm9QNhNwVPoY T76F1q0ZbZm/8upJnxVWnaPnPcfV7WrQ5Hp6wrrLGS6KDf2gP6/yKu62RroEo4VF7dqhZqme KrvZT8mjwjJIzNXELvMnxCIi1/JaaCmIalPbF1v9qR9KMvctoEYciVumhPCZ5RCnjF4BP1T0 aucdd+K8nDRgtXEkE1sFKonyhvnh82YPZ920YE1LP3FIEwH9cSAeQKgI8LUIP5uMzwkaA8Hz RtSYs5JNb6L6LHI4FcWrQ+iGStB9xlyR58RyO5zModiA2r0ChD1B8Ast+XrGXb6RN8eCVvSr Rf3xoObllG5ecIrG9ec8EUpVVasaK3TMxNl5nPz3zFntAMejWIrxyi/7vEipV1IW5qX8dxl/ FayjecdQNoKYZ9sxBexG7IcFD5vjmveeT4ZlfNxYdSQrvThmn72TXHAbz2lKzcHnZXDWwuE8 D3AIW9sc9aWh3XcPiNimyFvGKwutweVoxU7B7cu87cnhNe59f5RYOv2bO1BBqXWJiqu29WvQ on3ZIb4Yng49qD986L2xK7fgNQ9d4ts1/nFp3Y7oRjHatDU2GA7+EzWdI4cLBGEieBiTGnsf LaUM/hePNVj+VSeYjs/3bOTV5fLYPYJuV3LlCw7piB4xJFeEWwRigLQ7Ag2oO8xNYkqEg+cS crq/FTVsPJ5By7sFqAi0RaiZ78302grP8ABD1F5Iou6zBKY5GULqqrk4AFgTFlesOT3oIFo/ MjangKhHKYd1gQvmm1K5w/hOfYTaK28lFztqKFxFag1pc0EREp21kHZTsRg1vqbRgV+SOeL3 GPbWbS/AqtRFi2UasGu16+plykALhtXO0KOmMu6bdoK5uQNV/+I6STKW3XFIyPieqLeUX88Z 3qY6nwTICwlgTf+vCvgJZnmxj5zYfxbzivzAHQluIhNSwImuqUiwAwxxA+W1ksqJ4mvVYhDA 7JIe5amnFDtYtT9+fBYLQ2NQ5/GvaOslP8Lk72tu2FTFHJbA4Cn7kzcNTTI+mjdpRD9u9c9I +hGmnFMXu8SFQwrNIsxK5RnfWN8RQR08GzFWc2NRBjQ7hvO24CGATQn7Ac0rS+QxntBbr1Hu uzH/EsjFJROvsjJoMzo48dR/NyPTNL6acsTZVHAP/tDOcXxVOJk4XzBlla4F7Ea1Sbgv1WW0 Ejmhh2gMUMJjrG9aa7rXUEW11r8W97h+TXpl2BfcPwz8WJrksU/hRGjQBnFuBWihAgfWoNPG BJu81HaECqVHx/aSFf13E+qK8yMSxjTw1O9MZ1gmiMuTci4NcRMzZ5pIssYxFVtKe0lQWeRW LoYzzs96iA8uvUE8//CN7q+MTCtkWjp4iuMSVTt0qQyHNSCbIFl09NVmoy/NVbBqJGG2rpbf Vn0SmzgC7kEVTxG9P1xWnyN/TLTzVzCv9Ts0nghhHLD/dKCr0R2XoX2NggbVyt5p5CK8/pYM KH/YjABpxxyOBfAhTsRxFW3c/WF8rZSJV5JBdBqSdMI2Y8v/+V6uN/lIWM2jKH0USlJv6WwG 2tQXtl8DiP2ZnWhPbuQuu/tgTnKHsE0R1akXDTZgZgoNX8zq2Sv8VTBZxVmUpd1lCv9ozGlN t5z5430DBAKZ/fYvv/0jHGH8lNWIbF7qvdR/fM0OY29JhLih1Cl1FqPxYldu+gqjoG5gDe9t z6d36xf0Okn67RhdaSsMEnbmr3xU5Tu7nYfXMlSCYxv9wmM4WGb2CzewykvX0DP73RvbQJpF 3mfquGE/W74NGR0B9fHkFY1Dx2rSjoZQmf1pE+hi2tup7z0HxxkrCQ7viuAHbIeGzfZIlrI+ is80ImhzkmDCz0ZiWLe57bsRqBNEtC4o1NKxfomKDTYi4TH99R0b0XWPBvIhiGRYM6C5GiZ2 YcgkYM/ajS6NqJsh+XKZn1lM/Ht2NarjI8+ykCOot+GuPr9rCUKrQAnCMppa4b2sLLpMGWz3 AwUNXt0ASuAplUEI9IOzrVWtngWKJgpF8jrjJa9K2z8ZO7Bx43GPNfmo8sbX0wfp7xfhJZ1B Ve31KIFSKOpLXc7vHiDHuGcpx/OajvkE9a3MPUhiL2ok18QTWGcJ0iZZWwAqS4FocFYNzTZG vPY/maUy/khAW8c+jj0sAAD/lBLv7DERiNkiVbKREIXsM+qz5JCY4wf1KGzFGDXOwJSipYpn m2ivZJr85bqAGldQAa59bZBrqbvdqoseM9RzLIlFJCVVTmG7qeWwp2If/XOwyuYd8v+Ufb// 1Gg7O2xcnhuJSzH4lJXpkdANsbKFQwCd3+dRIb72Ny2qPnutTzXgwpoVvRUF7QAeiS+wSyLM 2c0cyTA4y8TwDjsxU6wI5JnVUvKH+M+ejBiT5N0tzE5BVq8RK0mf9hg+gWUGNiYoo0dnZoRq QG/+otV7KqPUK2fCk0wZGUztWQGzyFvLb6r3pCVHpgyHbSCUGnZjHOYtK/j1z5Ug3kw3Wh32 0absh2MMNG9OxZRLBfObpNv3MrCqxzKHJFHbKL6XYzPuctJN3AoAtuxv7kvOcyT9E157ROXZ hKKeA8CbBsBR4EkF/4vpE5t15HZpCWuMKTalbegpOzn/OXvdALl1Zu3gvCX/91y5+2ktWnwL ZT76vnGIMut9JKDj8aVSQ/CCwdBhoo5hmgY0+RHtnz1Ksv63MVIVE1Qn6Ch6aEFcKni7/v3H aNc7RheJubmih2/RP0dot8uPlBnhK5z6kYykWLrZJdKAjRMmUyy2ZiZCEXeTgQs/tQ3gnWX8 x/2kbAn2ecQjfIutZbZlt98lagKn5Ew+Wl7IPLDLn9IgUlbhVaYEwMSH5SaC6rB0i/MoZENt JQ1QMHmzoTy9Tpc2LUoeuSkvmd929ML4mhCDpCED6vj+OdH84C0n11OVnhRryY3IAxK9AqEf ApGgfKbQTeYZQX8KJSOiCnn+vI3yytTnFk/HXQ+WTDyxOLfEOiuzSfHKYdDGNhfLA0/IpzmM u6k0LFBSkEvIIsmV5r0dmA+eW9qUbSNazSlD7kTI9RQloU/oQ6oBRDsmLF13JB0IO6hz+ydD Y+WwFO+3ElosqDUsVWIvk5Ofpj71fGK6BnWbOO/HbOI3+Fdu/JF8JCsYFpqoxqg7F7Uw59FG C64VWyMjZYLE2pf8zLSY3hY/LGR6fIsocWIH34iJ1waWioFOXAk1QwIHYkudAjpMERqin+RG Q2cC6KqgXJYWzH8RFzreEDqwKLf5PZ9gyc1sppZpKyYjUdRj+wGMTJ9nxWafJBodOJJ0U+Oj yCVdAxGeAZv0DzQAzWblQ0q56mpDMq9lhHFyrFbuZqR7g93oRPMUO1SGSXQnemAxvfYZ4j29 6XlDZbvNwYpkNoTQ4pO04kdiQPdg7EJy9bQ2AVoqkDCkVk4rr4sbkLC+AOxiBB9EUxxSYtXE I6XGkf96JhkH7rfzTmGin3C73QvLvQztvszX5FwR528Zd+IfzcVkSQ5Is052jgAzUklPCwjp wLSxLgb79JhyrgMUwT1jGNdnjmnYoC125wXlNnMb/dbkskk4VDhuuwC9efbe01NiUR7u6MMW FudzXdQNTqzOstWiAPNcbK73RGWNA7WwA38EENgT0bzsnXkUWnHpSUS2zPWuEsSbTMhcZ/C9 3GirbeOQFqONIJxdQhYZ1lRQAaeVM39EC7yEgQav/P8iuhDpNoAsqMCsm5zTtTHzL6I9Ofx3 oKxy5nTsX1DmKGmA+9hAsj45wAxxPIXYFOwP1fIzenVR2nIZvXHY4U9Rh3BmYQcPUM0OmBF6 zoaVSMZZN3CrkU9W5eB1fZZyUzfniGpAMz/8EU68gVetpL1To8EUA3jQ0yBw72yKvckM8evj ryA/GGkpzZ0+xQ2zfxe2DSuPMLqGRYTpnZiqRBO0AiBuB+plsKpzwCwYya5b7wEjqBZNHpE0 JXU7EupLsPj3oiUdH8F55x+hjpkIYtjKThRQ2QMj4vcL9W6bXcYgYk/CokH+wNs8Twf2221D pjmOq8VM5oSp5Jy1LAR/ve6Y5OCYYOcCsl38MFPd4pJELIdyHarTPdBM9F5k5Wm5qVKVJLGn 74rrneeRPg0tS5lKtuohvHzb4xIYZJQAjbFyqyp+oCasb9Iofqf1PhuwXA+ZFc6BgE+JbEuU u409CzXr4x8mo9nBYjRKLrEDODANquuALZvvrj57U+q77o/ILyymTR9Jz79UnmR6KsqJLaMA 3jILF+aAjCG1wgkHgEJJ4VQr1V0t59qzwivq1vMMOKVMfZmpOCWYLGH5RiglcV9F8eUGjXor opCfBhkoqNuXYtwCyCr7jDebILJHtIUV5VRSgSBBs4uvWooc3J6SLmeFhcRalkmv8cj7tUKA uOkMd8YpmrhGM2l7t4HwX/mViSWDqK/mtNC31zGvzSO/5isYQb2oVIBG/8Gzd9RUd7RU2Zxz HAjnd6ukcdMCOaOmukQR7XTCm0Sy5nGlWGOVGOOpV1Ox3nRA8KlQ0oN+9bpc2ZaFX8gbyRCe wkmNH7gC8ueKWF0QJAaziExQBKJgk60+XrClmUildNtvQWuTqxgdMNm1c7P33LXJIzM7PSUz 1zbelUiVYZxR/H47Q7DKVNRb4PW9yHwMUY1/xJH5TgSJ+FpfwDdcaOWU7EjOBJl6m1LONSt3 +Hclnm+m840hHAJEKFQ/DJzTJcKWQN9LQA56/EQg0sI54FV9TZegxz6dy+IBhYPb7gAaTP/6 Tg+cHM3WLknpy873+26b6mnWtZv1hoCFhCQzqQS69KAXVj8Qoy5HXOKlflqsnHU5ouWer/Fp quuzumrx9NFG8RFIDXfqkDI8ZqlWk12xljOagcHufx58u+P/sYDGBw38FOC2jo/G/VpXAnwR /9dFd4nCJqnRNMiLixtCnTvqykv4xa6FJkxo6jKOA4NAge9mBT/aixepeGNCcnGpcD5FEE98 x3SA2VyoGSyWM0RKFIwOtWn6hhW9SPQUXhvxMVdbf85r0V4uXsQvFIIRTd0FZ09XN3ij9nuI zE0ZwYJpNXWltm+4F4MUjg1mmSlYDsk3e9HZEB5KGFVU6Y9S8m785Rpdc+KLdp4MnUhzCJWc ++ef8Aj5mk0g4gOSo+M0HQMv52wUucAsQBFU0ZUFOeqxMXDgdGnZJuy/+gRcBwVr2HnPAHtV JXF3bu0mBYcvMbdVQqaNjbH7tHgwUujuhzYkqo5VxLDo93YIBy4cHbb41XOfrTSxoCIrsIBI E0VxhxCD2X1FMe93zp8lF4LMv89/uSqcvwqTZ3pfq4aF79YMw20HJNcDsjvWYWyEF5qxPWbz FL2aPsJ7QsL9RwzHCDX00ikhvc2gGQ7LxD19Bb9MBW0YhHM9JSvAsqkjqkYp9SaCiX9fXtBC TcLNbNssr3oHgFCW0dA3stkK0zO0MCdzGnFks5Xkw4ezWc9xoKatxF1kefsnfxCehO+u7ioP YpqAl2dFhTHT6dVx1O3btxDOIW8Q4aEJjmAB7Ko5BfYlDHceLPxv80+tUft/9V5+wozYpTvb Qfbt4amzUTzVaTKELIjkRyYLWXrMal9rjFiAX36mPGrbAS7p1r+Fsjnv7zwvOknMxY3UUE/W XY9UJv1Q5xRGU9DRBrK6cZMMhaq+y9JhflQJbWlcY871FLGhOMMCux1sBrXf7Kqby6sQtSrc kMbf295dK+W+9SKJeEj+LyYbYetn0eKAqtSe/KCdJc7VtufKhWrQicUGMdZKMp3iqPHmt+N1 kOu9E115m5c9fcnJsC2KYNzxV+VqhGmaM0nzLy9fOWbP8vd3kL1t1h4cMLXwCmdhIiMghMI7 ek/LLlI0B62JST7IwMHi9U9K487lPEDbBpcdzSM/IwSOacNYE7+AWhX6OYJuobxScqdlugRA SVROheJ+f0QZtB7dYv64BFby17reIwZWFDjvVZJ96iyIwmdJw3XLZrmFt4cW2JQZYMdQkHNr G9aMtodvm0l/HnQ+8+I4a29CCusnQ18BrK7ZEqGvsvetPV0MAIdoW4F7xB61zav+OQEXPQXT xtMwhP25rW+L4IRjYfWIBhIBNOp1GEAq63svAUa8xq9CyjSn1Fx9fZNmZBuIAlbfWF8Ct2ry 4/x3z2TEoSEEdcgLw4mbYzaq+/Iebr9/ZHkUgzYwTgmkLJ49W36iNVdkQTnRCTnf+ZRewDaE Yyapp4191JDbocDZckRPBs4KcZiFgj4QHbtObjuJSYyX9TM1zALjbKz3MYs5GFBHmtkgiZx7 S8FmK3iZOLMZZ91jHrwOGKL22Yu7uYWUuuYTkTEIVTWq+asmDAdy99dDxiutxvsoVT/wqc7Q dfE3/qPVMDjurAARTYPAsbw+sr6cnDXF7ao6BSwHrHt2RalmXTXyYCRClRMAkNcq47PbLH+d afcbrhu5lAK7AWnkT35enbusg3HgKTS8LeKEG08g33xK3wgY8pEc1b8KRFjnET6vjeTn9KtO /uVqcB+QvdkVG2S2+ZEIUBHJ9DzJtvgspwE0jZrv2XMDE0CdW7N31J/BQmAA3V2UuBahXYEE Z+QbSAuUo0rJk0Bl78+Sk4WX2jB47inu4EVB0LNwlge327t4yWyf6BS4Y5NT4FotZ7c5rtq4 Q6g2OWYLJklGYunWd7g0HAxCLUNGja51VyAKChyPyeZYiniNXFkvXrymY+QepEwiD4VArfM3 YUQomJNBtMJeflumgVcjEz7ermUsk4JeDrrfafkyOnaEaQopR7HFAgMaJLeDsj7uu8sUAv/i WZ6Po7PTYilbSF92uuPyZUoK3YQe/easLCXZXETl+t+VNzWXCntBctfFoZPI4ZxRCQVRLtlS BJbqCFBSKBQOjaqhA8y5bUDUwCDTbUBWOPHV2lyK9OG4TBJEDfsNGzA+CuFuiAodeqc9zxD5 k3TVe7lfhm3OzWTdJZoTlDe/QK7CqSgF+f6Xj4YUgOeBXQQzJjdEZBsoPnZ2RprMMHMfGO+k 4ry6cl9i8ZGdH15c0D1tPj95FKewdeoJgVkz+0hUei9yrCURsPlDTZ0Js/rhZLBD+lVJOVLg lX1DHrRG5+pyXpon2LfvGwYIU0bWwktn2LJrmwyxWlPW6cEh5sr/a2G4RB3X0A36QXAs+390 UieCt7dgx33a8K4DjSU/zH6jRpct4/Ia4IJT+wopZqNydvStRBgLWe2IRFUzWSOg89/sAImy Rq8ZeYD0mLtrnclFcITt04He8FNX77mEVydDT1+w5HZrz9SKL7xuyhfxPPQGhMFyT4KRpKv6 wKp4FICT5lt5wULz2F6pi/M7IkN1iv4X3Tz0S2/WcdcMqoRpSE//Iw3XAPMe+rVjS7lT1Pdt e8jLcG7mgmHQQDgUKjlzBh1Mk5scmN6NNkKK0fasWqJCQF8taY53ZAyWpWxZW4v/60EEPUuN 2bSg9+TKTD8ii0yXHzu4TQfYP/LHhiwk4b44DM7TAmNs7LLeB4u5OzrXE/Y+Th86gDTp2UJN buS3Ce8xdKVP8eRvyNZQkUxMHoL4g++XHW5hRS/G6MheF1tdtqsGpyLbSd2LEHNJahUSCVqY KIqJy/f+6knVBNsCKnEpt1Jsl12VjrVAnLqG5uDj6ArpXxvDk+/VViXuNVhzZ8PMGRq8JWI8 FOzpslFIuabUqvG7F6vTV8MBcmg/Zkcb6KFyURrR0O5Kq8pBWmGa9BM96tbc/SBj/pIrj7KZ u5nWG4RBPaYE7jPcEaT4+d4BcXVuAxMYW1gFk8amLgnXAzrT7fRboH4DqSFFZ5scG1Pxe1tw ZNUxZvunArm8IsOZdYD4h8qPVABNNiOPi+vOPKG4LmYXCbZDmMQu3L/NW1Rtyng9cEKurT9p Ux17fMcrK7o5t7WepUpw0Vwb/3WIoHebxBo1rRUF4wbM3bPi/O/1JgbwYmMxGu/sx2Y7hz3y bbUfJoqAHafeQuQIS2u/wTsSMDPbv7ItmyhxHqp+e2DgAH84Nyj1BKQg0xUXRvJfkLUyi5Qc RjRwgBVvzcbabwyqUZR77jPFC2SOudwEhIeLLbzNdpqPz7hn4YrKJ4qBY805ES+M+m9yJwIX arUNsdC8J5RKmeOP+GLtxNdzQMed8ETBg+wCtb0KDOuwD2j1WzsCurrPrfWPcXmTohxyceAL dmebCtxJO2OV17ekBu4fxktzYWxKM+xV4Vd0CmNhxxUfh87UC3cY32zIaYoSTUB9EYouzhce N2q0svNfPhyzkQBjBW9DdEcdRVaBH+vUXS690kzmLJREzVnaepUunAd7apVlGVbYOlCU7v7v xc3AmmPi+vl6SjbeWp/0xLxSW1h/wjs6bSQEInmFN2uKbi4kmol5nz6KVPyZAQUBl6WSGen8 RhJMgrld6Q8HOy7wpAh8jOfrwIVmMI8f1n7RA3IAGBAlvub96E8Ltet5vao3h4tLwbG8QIGi /XgDogFv7BGzgvNMaAx1k0v3DyycZ86MmsnpDV1znM7Kg3+cqp3go406YAQvkymPN4u2ziw2 mkAlH+AjTetli+T2deoVHIX25/lyBsJyc26SyAHu3OG0LBG+sTiwOM+QVQJkAWX6M3rZXsRP vOD5RX8oZoy98FULV9Xk4Cjs3dTrURvzFo6334y2tfP7Agu3Nr2+xMKXqhmg9C9Ce4JaxQOR Ccdyu3IR/b4movjISV53rnS9YTS8UAT1k15eyCseGFC6Nm74SGZmOiSAbAE0Pm6YCIEv5rQz KvtXz/Oifwx7zsC08Gzw9kSEF8AnCHL/8O6KPijoB5Ns7WtYjSSfRNCTA2O/Xjt4PdGvIWSJ go6dXv94yACT9VNpHhAdbmBnxv9fdVKyOpgnRE8N1Nmi1Dye2mkxrBdSbYqzL6LOu46k9ATp DPGOw77Onno9azATLKgHTTpmx2HuM062atzWSB3wsEyexOQTgGry5hRj/TYrolDyBLeq/oKe X/lCJfKMyms88KbEkMKJfV+RJ/J+6STm9Y6wU8CFe+CTiZ3lA0Og5tbVG2yZh1V51AE4jX/R vEhhJpWFoQ0+ybOjNGkTgIe0vvL6zMm2UdnBCtUyW2axLbOHTcIYBaGcJ7flDiTtoTF2mkIV RFy6pNGidrxvnJn3iHqov4nA4chtpnThfVuhwfjbhtTP33LU5hONCgejLHRbGkk7UtB+oKmd GNijmknn+FHO3KbLlT2XaCduhCuhoEpaJwY/KhNTUeIyxk+RC3VnPT8eNkCCzqC+V+mTd3Vp pNwg1bH0jXYYdrMWkFKLAItf63LNY0KtNrJUNssO13b4exkrp/SDplJBZbNyo5wqRUbKr+jV C3GiYXptImmuS56pU2VBR71ZhfBKzYeKcKEMya/X07pHf2yI5KWwHXay8/E4FqiRSIjsFFgc OQGtG/C8j7vsRG/zN1gkpq+dyq+O7T4H9/mmNV8IU+VE5mOHT/bpXh3bigPUXByeUH3B7kXX slEPMXINVkl5UQvg9faQgOTM4K3b0YD0krkQYWYFOz/plhN2jgxONgUIRFLuVV9KzEEN3rgF PZqvknbLTp4cOL3EAXZe7Vwp7/elgS8bFFo97OCVEDOSZ9jYcHX3/kvTfmErPLX2gH9u/jBD Ug5zSeB+afvQ0ogiqVihBb6hFIM8ZBIj/dPhkSsVN99DAL5rUjkXYzzT++qr4ELQBGVSknpg NjzfqIR2jJSEDetNHZSkPkWSi9OK/8ras8EMmhNy8XoXNInHIg7piX+yYf8PMqzMXYExZQvs HZfagaTrXKywkooISlEhIANhp100Uxap0nZ6scbEAwyLvbgpZy3Oz5YxYqHdw4CqtNaq2aJr GyVEFpZEwTf/z9YsfdBncXoQTZrjP44iIr8ExGRIHWt3avDpJg6f6Uk7kYUMSgSMOL2DsxpU cFs3K1nsSZUipsphOZ1nDRRHZia6nHLCLSF1xz92fClKlTC4j0VsJqaZ2r3iMmBxQaTOYZp/ r07gzgygSosaG+BI8lZSiSwvpLk041X1x42rSVcgawR2zl+rKv7EyecFEVwUqX0ohdS9EYPE +rN4vDo2/vXBFKxtuRnfg88Iw0OagcATi4LE6tJ27d4Jposkm0iiNs0r5hWegyf56tlgcLey PpRwDn4CyLzZVVp9EsRs16poLOgApcub095rjJ5rTixeere67DWVYFT+xqoDzhLU54kavQTC DCJBfg69ERqk7yK+lVhGEMlBxsKHGfTRnOs/nn5Y3L6sJtdIgseeQCd1cBdS+eycrWiKBHDM ptSncyzil6xI5TqaugU2bbhw2vb1261M4MSpeiQja6ZjK4oyqMOXJYONM4yHakrll1UiRGD7 20USmRvSn7ntZB8nm3W0nmcwGaoY4vkhq0sKQpFHOkiMg5AOjb7hjIxf8v05+5G2Hh3lV84V 82HuN7n1fwpewz4fuzszKBjpoO3UI7Zh0fLklygeID462+QcP7034aEVce+/niqOGku4m6fd tpD56u66YoGEweHEQSpwWUkINZc6mGn0KwKE6GNTyHeHes+j1HfqdBkXTmR0jT2P+hdnZUzh zeJMZbVykHcxNudw6y4waBP4UVrA0XBLHYRZB0mfqnLust83WzFc324kWGFklgfesrtNcXTG dhDKUkf7LD1iikW4zbDghmpNMT51VyEUBNTLJ8VTryDeDNLiFjNamQYHlqq3X+ayuECNjdgD 1OlHW3EEA7feH1DwvsKVY4+JPjZgzHu2g2X0vnTtDk3XxQMWBrEUlkXIvgm0UMB7Q/CNSbP9 HC4P39hHEQY83PGAva8STSY4oUu2mZ2jQL2zM3Rme3VQi233EsvqTF9ODOYlt5En6XTIubF8 hmu0bhdAsYSHUQUtll5BmQXB8fJbiU5dyIiahtpmRlfNTP2dSndnpJCvgY7TPzxRH9640/Gk L2Xm3Z1KnoyAfo+feaP8lteAYUj5slTKTE7U6gIVFtK2LqfF8OFY7NtUhpRkgqn6sBl7Zuqm BYfO7U29/TryXuTdVH1rV8MLiIOJCNhmVOBit2oEt5SKbQsCvZ6wnPLWi8lVlqBqTdBxq6fl Ee/VGopgPLgPXpEZDwYmsfG/OFrk1Zz7UMW3VLu6cjThhuf/Gdbq0EFdOjEz1E3OprzEGsGO DwCVhMn+iShzUvbRaVH4x6ARX66+6FOlqZsQeQf3+1fk9DVwBoXL2bGRAUUGFMBRT/ZMxajF EIozBI+fWeyO+1GV6gU2YWVV9aW3GPLr27ta1fIGCcAlV34UMuj7TSQArHptR52/tHJoc8no vbQ0fjVxpSW+1y6dxtFrck7ncWVxe2rScO7llcNz7Mzmq5EVz2QFUGMWFfiU64qBm6tCWBai DEgDW0X3WvhRDs6XD0ANqTCqa5uPJkcvejtmJ5ZCCr3VPdZovhnrdBCDuliiwIgoFHHgyBsH xEr0zBj2gAVFdovbnGUiZTAOM54bxPUgNxWO2rFAuVv0Pc8GYiQwk/yXaw+FHRhzU9eDzeRB ZJy5PDWGlzTVpqE2OaQayVB9YtG418rbeA9WUtLoRTGVm9QPNvGTVnLpvX6sQvNDWcJg3N6k CAQvHmO4tKjdly/koY8rOdnPR05vov/6oh8tldoalLpBOt8xM6LlvBm0ZqWC6He5PbX2F++F 935BBh0JTgcZLj5xYC/BloxHaFnu9iSTpcWoUbbVt9lcBeRAQ6dV/zzKtrZG3KSwvwQzDPbU BYpWCvOJNOWEe/nengqWV1bP2nf0yfW/CLEXEIzyj++piJI82heIplOsHJ6SJEoZ1m1AuzyO GTfV21Km0GS0pqWyf8TEZtJ//EEcCi3J0Abhst5ro/9gBV6FTZrkfIFIJA9nEsYuFTW53Blb RRGth/hFBLtRkfPMxQGwzO+rzWZ5RCPef2PYz6A300CukLenc6NFxAQGsfs74E1ryxN6FR3s cjBwnuIdcRZkKQjYh+WXJPEMP/jsVqSauHbLYxTOlXWwEO5yaVnd6oFzaV02S39ln92sJzw6 9847dgAml5y1K5I13qGzDR3VkF7syPN8HUoBw8yV9cvT3c0eGgR5jZ5hK78Qun9kHIA7lV3A TNi4lSb8nkqibUhY6OFAty5z/aXUWxZzSxz44B9mfLU+EwzgjjmsnpcsbBFLLiiuTOcf7Lue XQrr6pfeLXMYNJ4lJqw3FUydBXcXA3AnnG6m0mHPZR0nhl3EX3HgoKy7Slh2k5t0d1G3rSC+ LWUM32smlyuM923Gq8PvmPUCqs+CWjVUvVN9Ag0a3B8r8koZORAr9L6GF9gruZd1iIMUSIWG t4Jd4h+mF7gss5GvW+u06QCT1aCtGy4H8O1hgZBNliCjFeNXjXcfI4jhtVI9tg6bbouGX5RM TAlseeY91Lwvt2qp7m5ZjPqgi06GfpknpsHG36T1uMEHPnQF8sUhJ9BBe0ev5er0S91MSACw Q9wKnnnGTBSaUnoqFusVhIuvn8Lqrpzp1NwqV6k3OXk1ljO7nSalGCLFknCIaeCZaUhmgtTn /N+KoNqAA9E+4GI9geZAUJizZEIzUsEGM8ZVJMLFqxQ6Cq/kG6ZUB39643zrDDct8RiV/Lfr PagQMUza1GGauhInHmtQxCz8v+/nr1w/n40FIlB/lL77myy3dyn6WDHW6xZJXkoesuxc0g9W MggK10pZ47VGmavZw1iuQ7TUO3/kN5H7CaVmkRRlvdNkgTyP6ksWfERNxi3NL6XjJfB62Ugy OBwADNEgJcz8+L8CUljfzL4lm9PyOsPGNFFz2xDSgiL65W7uP6HrHx0u6JsZtXEO5NO7k/SH /gUHdCoMvRMGJ2Wyf8cGneTNpfzpMJTju5kc9aDNQyRzAl7xZSarkvYsHSbroSrVSytD40Tz JRIIt3JOPTS9i3S8+mltmWI1WgQrunvL3Q4o+RIc53wx+xK2ZJBeRmHHcP1FRGTNMPWMxcb+ PJbiLBnfhkSZNDhvbmSg5YXWqmDNpuJ1/DTWEksfoq/jfC4D4dp/gDDRo/mqw57qXZcHeYmb +0SVC0XBG2KOzdVKNOwmydVTqsEskNPVEquFSZ10lsU+cVTg6TYk/vnFTCfuq9tXxuONgymm ThONyXsUeEW2Nt8sfl/YAz+/CsplbFtQ+oomZHHenSrY6U5DohDbhsVCMswv/KP2isFcjEyX A4OdTAG6n8BJoM7lXxnAuErE+Q5MOQCclZF8jNV8KAx/snSuLv2TaR2DXl+mWla+0nLU5qeF 1J0C5mbSbXKIm+psKJPuK3ydAzOcSU7qmWH56RJkKnw/k7INibeWidvzGwZ9TgvKb0p+RCTX XQtfbIm9EiEfVbuG8XoJWk1nkSr20mnOomjdiJWzgIci6uDNuzdX69dMjhJbnGK6gWqGabUF vr4VhuSU76YiQoYW+5/HNjBz5c2OwBrkOOw1WC3kav/zaRQd5kymFiy0El+k2VSVq7fWQ8R3 eFqGumzMe/QoECRy9rCw6gRbhdZ1fXA6cypsn6m4GOnKzqNTqS3gw8oOQm5ZYkUU4r8qri0N lWszwWO1iY1Fj3rf4kvgQ/sMH86zeOKhPf1xSvTpZ5dIh4+Be1cpNOoGs1mnapE7AmwZ6ftq B8OEB04jPvYiztzGQxa72NaeotGFJ4GFaDNi+V46pE+IOVtfSIpyIUlMsHaV1Jv/PnTBkcd2 mA2o+LYUve9qdUiLWYOB6prPdi2+/a2+iWVMIqiU7H320JyPI3RMPezgUX2WYB5C38fBjW/4 FA1XU3oyNOb86pQoUhaa8Bchm9o6+ix2C2YDm6twz/5tcFRdQr7DHmyBRrX+BngrlIWqwReP 2ivmBZqUWcbjRc3iU2TZjRpMlM0bSkz7tYQcRXE3e2emiRbgm7xIb/AGOT20/Sx0vh8BhlID CuVGaoD9iBWkXC6SC/VOk5Gd4xRh6/itLLiDNH+YmJr/k3H9l5vC2S2PoTHm/MFsLFF3N+Y4 cTcjnEvEtwejj1FvZKCd372AEEL82BwRqyNKW6Jlw7Lm2MnlFpzWwz4DIqpMNW/q51WIs0QP Z1JQvTHu6ZrS8N2qTOVfJDou1sHsatnpgQl1nHvgmeMo6Trd79+OziP7y0NInGWhq9SHidxF nuo5CSvnVPK7tf4n/wXUBAy0r9/+ZCNmwHwIBh4JNgqb88UT/En16M3YdJo3Qol87edxXVw2 Oc3RRdoOM/CXTlD47lz8DyrEuNDSl0Pb2TyA4/lW+AVbhfFWpuFxyh/20ZqgwfUKkyWuFfKj tvAWvZOT4jq2P+W++xFYLYO3OHpseIqsomzS/9dqB349eVt1fWFl3+XADc6jAbvxRVtOQ+SJ nyF2AWFMRg6STHLsW1ogAISYamqgRKlbBeN572Rc4l1QamGjD38VxliK3MwNpSYFdci4n6OT J8gXC8y7FSLrXdpES5sBtn86Zlsg2Zlo8m0Dao6tz71M38ZzIhjzGgOd1oN7t8IeCTil7BRT K8CmOh3+lOkSBTQtz+vu8pR1Re8rdt4t/BOGG42CYdNnk1uRozcvv0slm1C2Iyeh2TMuWU4J t3e0ErVJSPe5d12HbCZ/nVlGlc4QBckSJYAC6ol9INOYatqfNBJlh29D07kSFk2Kh0EeIFX+ Rv4oD0xUnBFUQe83J1V9Zjtc5FFIm0mnfY+P6rj4zZsHrjMOPsSiMpn3QuVD3dZA6SzcyekU KcEvIORL7TaKPFrc8GNYD8+fsOWKbAMD/dJWsKa9JpL29j98kLcvwAwrU3zaxZ593f4rpJdO YrUaTrga5IhaUhj8JH6FuXHr5ljRBo4KMBMvPtyu6CciHrehtFhxdyzIDi7z9H0Hd7ciaBY/ o2SkLPytMvD6FEJAmC1DPWyRbV89aYv/6xltdx+31qFvNAiOJG/pKvFLxxJSN3Aj+1CZqX52 uPxvrLYkA0Ppdzyn/X7sNFjXt39f/haAYiyaznnGZ480X9/02HDPO45r8lgLQQ/K6NChh+zJ ADc13vY4kHjk+b2tTH66i7L/k2AJsxQ/+t9B1FNjqCfjAK9i7OhCUjL2hwdTXMJDztBhUxWG jAxOn0WJ5ZL3PfjuyVIi2U1nHk486Ai0QgoqZviMqfwHAJOhg25dscTy/2dqDwwb0J/lm/2S +Mu3x3ZDySdhq7qFpv+LtL39W+zc6TsP03ibzvsEvq8y+WoPAQbeaZ/BOqsBUG7FQYWf8blS R3nQeRifx9BF7FO3idyqnxDMk8CQcHtj1zUSB+gYYsMUFluX8WlkgLGTQgjgYMRBprPdnnOn +Qo3oBsE4YJdaq5AcnUxOvwO9utOwVHu1xaDOgx5vx0VEOk1dHh9YVd7BYsLpL+fp+VrXdhH YuH+XGDP4QtbcTCiGyNykHd83U1IZe2SprwvrpWj5UM4bzU0Z0oO3LnXYwqRYgf2Ka4ceVF8 Gzuj6QKF90tHwCBvtoYYUMF06KAel10Rw88ZbA8ZMfUvC3ujimmZb/S5YgrwQaqDISF4CGwr 7YqFKnqD0uKtowhpHCkz70HmKKkXsRTgmTIsNxraFP8INMCtRkb4q7kUJOU83XdvDH2WFYtB l4P028hBaPS6alhKYZ8CWDHDwyhaEd+Y4uzQfOB/tW58lvoEjg6w2FPcYuPREzv25b+ivYhV G3lInP0PuhXl3kzNIO4e74D8LheSpp4tT+VlB79kjUeP77HUqMvpUQ5JZqihqDscgwfsFBYX UR9FCeM4AgQfo355QMZqvMNWAIVEGptFurQwBAqnZ+vuZ2obBcSLQ7YN0Ns9vAC+rPAWenQA /gVxJgdbYeOM/M54CPt+i1/c+iCQsxlW0JkQSzGhAdJmIzkuy1AYXZoK/Opg8GnwPmp/FOfJ uiU0ihdo31zFK/tpPmI0Hzstc0UyPyEVFoXUYEqPjEiFESz2HGxih8uVlRg22hE/TpmTdT8F EX+5sUNdBlvR1Saq3tEC002qh2CQ6bf+pWdkAsEM3GAtJgbtwWyd1TgdrCmnYmm2q70RXMtC knj+lesj5tpJjrL8hAtkdOYqSZU3sqV7I3y5vEeC3dmsqrTigSGpoSnezW+c08uc1T2MuCPu m+7SHISjw9THyUqGH7mwV6d4l1zGZxJaxpJx3NeR8nIPHJxTDGwEjwuk+biaEKQhJ99mWBMP FFZsh7OGcaWjKsv6WTSwcGun6CpWido7Q779UjC06SOug4qSjQaOvDY378fNHdb0qjiNPEZh fzNy9B3nVyKj6Z6lXou2kpqxEcCcsZli4vcSa2dI2/8BiBT5BlY79Cl/7ExjowPiCHA9V0Pt nBTVIb4buQl865H+XYpK6bFImoEjAceyschhu6bnUvPQlml/y1XBLSxuoALHyok5ZxHPuXCX hAQ2Uq1/SIn5QdFRtbe2pZ/h/KHA8zEZiJUM61FdCqa+82JkIaGWr6cV+tL8Ir0YcM9J0iBR X73Vohot/0gWEEuhsKD+WcqH1YwrlW5rJRTVE5LjczvMbxXmEQw/XzH4zkdfMitDs5H1jU8t 0FBXqtcz1xTt6mzz/aJ1Va2Fc0qrVyAImrbw59+8WittuqZTEW5CDhUT34/YV6QbAbhN5EQM 64fRxkSGSQlLLQkqBeDOwiLbpzNFjCXvq8+hBA4YwO47+o+V7HRvB/xV/p/KYyw6Qhh+qnwO fYsuknkC+Jli5qj4FZx5W5C8jhSX5GOljZeh3e914b8I0BJgzpnyTXyR2Hm3iuusm/wR7d4n 9cVebzBclE2fj9moxNUBIa70R6giGYYn724b4wHIc+WuXnAj4kjpjaDRus+Ntd8+bkYC6oAo FUE6HLRf3OjbFYCcYQnamuHUyUAAFPMaD6IdnTyu1YhWttpkryI/IwGMk1YgrlcgJ8S0ZWey WgTOxQesZRjI22x/qbcf/3HS7wXk2nN+wV9dBofE67qSwycGfjDJgQRULLvFBrtHLWTg5YX7 QTC7ilW/UbZkNNNHsfB5pGLWHk13o4a9mHgEvme7osJyNfSPT+F2ek/FUsxdVnnYAq6h0MVS aRhors7cul/a6inkDJjuKDVKEfcTBrzp9af/XcFAgz9AJQwFqt0Sx7Jf7j9wws0zKE7Lbrag vUltd3YVepKuvpZk+eKS9KZr9p18AogzRPnMYVkidMBaoQhBjzYkmH90b04e03z91HshCMXa 3wZVeDvFD651lmi01KaTeH1sKyb7bq9AfsQxUEsBAhQACgABAAAAIFBjMGWUdkpeVQAAUlUA AA0AAAAAAAAAAQAgAAAAAAAAAGtsdmduaW5mYS5leGVQSwUGAAAAAAEAAQA7AAAAiVUAAAAA ----------jebehjuosaftnenuwnuc-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 30 19:03:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09622 for ; Tue, 30 Mar 2004 19:03:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006ZK-9F for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALL6Fh9015113 for enum-archive@odin.ietf.org; Fri, 21 Nov 2003 16:06:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANITb-0003na-3K; Fri, 21 Nov 2003 16:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANISn-0003QY-5L for enum@optimus.ietf.org; Fri, 21 Nov 2003 16:05:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02608; Fri, 21 Nov 2003 16:04:59 -0500 (EST) Message-Id: <200311212104.QAA02608@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 21 Nov 2003 16:04:59 -0500 Subject: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-07.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : The E.164 to URI DDDS Application (ENUM) Author(s) : P. Faltstrom, M. Mealling Filename : draft-ietf-enum-rfc2916bis-07.txt Pages : 22 Date : 2003-11-21 This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-rfc2916bis-07.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-rfc2916bis-07.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: <2003-11-21162342.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-rfc2916bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-rfc2916bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-21162342.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 30 19:04:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09809 for ; Tue, 30 Mar 2004 19:04:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rir-0006Yx-5J for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1KWank029377 for enum-archive@odin.ietf.org; Mon, 1 Dec 2003 15:32:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuiA-0007SD-HZ; Mon, 01 Dec 2003 15:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuhG-00073N-2q for enum@optimus.ietf.org; Mon, 01 Dec 2003 15:31:06 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27466; Mon, 1 Dec 2003 15:30:51 -0500 (EST) Message-Id: <200312012030.PAA27466@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 01 Dec 2003 15:30:51 -0500 Subject: [Enum] I-D ACTION:draft-ietf-enum-sip-01.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : enumservice registration for SIP Addresses-of-Record Author(s) : J. Peterson Filename : draft-ietf-enum-sip-01.txt Pages : 9 Date : 2003-12-1 This document registers an ENUM service for SIP (the Session Initiation Protocol), pursuant to the guidelines in RFC2916bis. Specifically, this document focuses on provisioning SIP addresses-of- record in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-sip-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-sip-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-sip-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: <2003-12-1152456.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-sip-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-sip-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-1152456.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 30 21:27:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18451 for ; Tue, 30 Mar 2004 21:27:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8VRk-0005ej-4v for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 21:27:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V2RGkA021741 for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 21:27:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8VRV-0005ct-Rs; Tue, 30 Mar 2004 21:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8S3C-0008DO-Ux for enum@optimus.ietf.org; Tue, 30 Mar 2004 17:49:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20418 for ; Tue, 30 Mar 2004 17:49:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8S3A-0007gX-00 for enum@ietf.org; Tue, 30 Mar 2004 17:49:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8S2I-0007br-00 for enum@ietf.org; Tue, 30 Mar 2004 17:48:48 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B8S1X-0007Uc-00 for enum@ietf.org; Tue, 30 Mar 2004 17:47:59 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 30 Mar 2004 14:56:15 -0800 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2UMlQA6003787; Tue, 30 Mar 2004 17:47:27 -0500 (EST) Received: from mhammer-w2k03.cisco.com ([64.100.229.254]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AYC37497; Tue, 30 Mar 2004 14:47:22 -0800 (PST) Message-Id: <4.3.2.7.2.20040330170616.00b56660@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Mar 2004 17:47:21 -0500 To: "James McEachern" From: Michael Hammer Subject: RE: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Cc: "'Stastny Richard'" , enum@ietf.org In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E6096E3514@zcard0ke.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable James, I guess I have to curb my desire to get the call onto the IP network as=20 soon as possible rather than as late as possible. In today's environment, I think we have pockets of IP networks=20 interconnected by the global PSTN. One of the characteristics of the PSTN= =20 is that I can dial a number from anywhere in the world and it will get=20 routed to the destination where that number resides. When going from PSTN= =20 to IP, it might be expected that the PSTN-IP GW has all the telephone=20 number to SIP/IP address mappings associated with that IP pocket=20 provisioned into it. Now reverse the situation. We have pockets of TDM interconnected to the=20 "Network". A user in that TDM pocket dials a number it goes to a nearby=20 gateway and then routed to anywhere in the Network. I don't expect that=20 gateway to have a mapping from all of the telephone numbers in the world to= =20 a SIP or IP address in the IP domain. So, given only a telephone number,=20 how do I get routing information for the IP domain? I assumed the ENUM=20 database would get them started on doing that translation, or at least=20 going in the right direction. I don't see that this changes opt-in. What it probably does mean is that,= =20 lacking any ENUM entry, the call must be routed mostly through the PSTN to= =20 the (one?) GW that has a mapping to the called party in the last IP=20 domain. That is likely to delay crossing into the IP domain, be a more=20 expensive call, and one which perpetuates the TDM backbone. I was also conjecturing what it means to "own" a telephone number. In the= =20 PSTN, the number is owned by the SP and assigned to an end-user. The LNP=20 rulings stretch that a bit by allowing a number to be carried to another=20 SP, but technically it is still owned by the original carrier. If it is=20 ever given up, it reverts back to that carrier. How is this going to work= =20 in IP? Are E.164 number blocks going to be assigned to an ITSP? Does a=20 TDM carrier that becomes an ITSP get to move them over without=20 restriction? Could an ITSP own a block of numbers, yet have no GW to the=20 PSTN? Are there going to be restrictions on how the network evolves? I would hope that even if an individual number was unlisted, if a block of= =20 numbers belonged to an ITSP, there would be a higher-level node entry in=20 the ENUM tree, and the call could be routed to an IP-GW, which might have=20 additional information to route the call, or at least determine that the=20 number is unassigned. I confess I have not been watching the ENUM list, but perhaps should=20 join. My apologies if this has all been figured out. Mike At 03:59 PM 3/30/2004 -0500, James McEachern wrote: >Mike, >In your email you state: > >---snip--- >The difference is in the interpretation of a lack of a record. In LNP, it= =20 >would mean that the E.164 number is still owned by the original switch,=20 >whereas in ENUM it would mean that the E.164 number is not route-able to=20 >an IP endpoint. From a TDM perspective, the entire IP domain could be=20 >viewed as a single switch and the LNP routing scheme should work. The=20 >converse (when records exist) could be true for ENUM. > > >A gateway between IP-domain and TDM domain, upon seeing that both an LNP=20 >and an ENUM dip have not resolved the route, can safely conclude that the= =20 >number is unassigned and release the call." > >---end snip--- > >This seems to suggest that routing to an IP endpoint would require an ENUM= =20 >entry - otherwise the gateway could safely assume the number is=20 >unassigned. Do you really mean this? What would this do to opt-in? > >Thanks >Jim > >-----Original Message----- >From: Stastny Richard=20 >[mailto:Richard.Stastny@oefeg.at] >Sent: Monday, March 29, 2004 10:30 AM >To: Michael Hammer >Cc: iptel@ietf.org; sipping@ietf.org; enum@ietf.org >Subject: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion > >Hi Michael, > >We are trying to find a solution for the following scenarios: >A. An E.164 number range is only available and routable in ENUM >B. An E.164 number range is available via PSTN and via IP >C. An E.164 number range is not assigned at the PSTN > >If in cases A and B an entry is existing in ENUM, no problem. >If the query returns NXDOMAIN, the problem arises for the >querying server how to proceed. > >In case A the server must not forward the call to the PSTN, because >a loop may be created. In cases B and C it may forward the call (no harm) >but it is not necessary. In case B the server could terminate the call on= IP, >in case C the server could say number not available and not bother the >PSTN at all. > >If we find a solution that covers A, B and C may be covered as well. > >I agree that in future call routing may be improved further in access >to LNP servers on the PSTN is available and also if access to ENUM >is available on the PSTN (some carriers are already working on this), >but this will take some time. > >We should also come up with a sself-containing solution on IP and >not always rely on the PSTN. > >regards >Richard > > -----Urspr=C3=BCngliche Nachricht----- > Von: Michael Hammer=20 > [mailto:mhammer@cisco.com] > Gesendet: Fr 26.03.2004 17:40 > An: Stastny Richard > Cc: iptel@ietf.org; sipping@ietf.org > Betreff: Re: [Iptel] FW: [Enum] Summary on NoPSTN dicussion > > > > Richard, > > Going out on a limb here, since I have not seen all the referenced > discussions. My first impression is that the description below=20 > is overlay > complex. > > I have a concern that you appear to be proposing that the ENUM=20 > dip would > have definitive answers to: > a) whether a number has been assigned and therefore rout-able, > b) whether a number that is assigned was done, and if so whether= =20 > to a PSTN > endpoint or an IP endpoint. > > Another concern is that, if you do get looped routing between the= =20 > IP domain > and the TDM domain, this is likely an indication of a lack of > synchronization between the ENUM database and the LNP=20 > database. One or the > other has incorrect data. I suspect that there may be time lags= =20 > from when > an SP assigns a number and when it gets reflected in one or= another > databases. If you want the ENUM and LNP databases to be somewhat > independent, you might want a loose coupling of the use of the=20 > two systems: > > -If endpoint is TDM, then the ENUM database should point to the= =20 > PSTN, > with default behavior being, if unknown to ENUM, send to PSTN to > resolve. (Note this is orthogonal to ENUMs use to select=20 > alternative > endpoints.) > > - If endpoint is IP, then the LNP databases should point to the= IP > domain, with default behavior being, if unknown to LNP, route in= =20 > the PSTN > to resolve. > > The difference is in the interpretation of a lack of a=20 > record. In LNP, it > would mean that the E.164 number is still owned by the original=20 > switch, > whereas in ENUM it would mean that the E.164 number is not=20 > route-able to an > IP endpoint. From a TDM perspective, the entire IP domain could= =20 > be viewed > as a single switch and the LNP routing scheme should work. The=20 > converse > (when records exist) could be true for ENUM. > > A gateway between IP-domain and TDM domain, upon seeing that both= =20 > an LNP > and an ENUM dip have not resolved the route, can safely conclude= =20 > that the > number is unassigned and release the call. > > Actually, it may not be necessary to send a setup message to a=20 > GW, nor is > it necessary to have the ENUM and LNP databases duplicate each=20 > other. It > should be sufficient for an ENUM DB to query the LNP DB and=20 > respond with an > appropriate answer, or the converse. > > Mike > > > At 04:22 PM 3/25/2004 +0100, Stastny Richard wrote: > >Cross posting from enum@ietf.org > >The discussion is going on the enum-list > > > >Richard Stastny > >OeFEG > >+43 664 420 4100 > > > > > >-----Original Message----- > >From: Stastny Richard > >Sent: Thursday, March 25, 2004 1:08 PM > >To: Marian Durkovic; lwc@roke.co.uk > >Cc: enum@ietf.org > >Subject: [Enum] Summary on NoPSTN dicussion > > > >Dear colleagues, > > > >There was a lot of discussions on-list and off-list on this= issue, > >so I will try to summarize at least my view of the problem. > >I will also include my current view on the ;enumdi > >and the ;pstn indicator for the tel: URI > > > >ENUM-enabled UAs and Servers are currently processing > >received E.164 numbers (either in a tel:+xxx URI or in a sip: URI > >in the format sip:+xxxx@proc.net;user=3Dphone) in the following= way: > >(for simplicity I am only dealing with voice calls) > >Please holler if I got something wrong or you disagree > > > >1. Query ENUM (in e164.arpa) > > > >2. if a NAPTR is found with an "enumservice" sip or voice:sip, > >handle the call as if you have received a sip: URI in the format > >sip:user@prov.net in the first place. > > > >3. If a NAPTR is found with an "enumservice" voice:tel > >3a. and the tel: URI is pointing to a different number, > >query ENUM again for this number > >3b. if the tel: URI is the same as the AUS, forward the > >call to the PSTN, if you are able to do so. > > > >Note: here the proposed ;pstn indicator may come in handy: > >In 3a you may use it in the NAPTR to prevent a second ENUM-query > >and force the call to the PSTN. > >In 3b the server may add ;pstn to inform the next proxy about > >The decision to force the call to the PSTN. On the other hand, > >In this case also the ;enumdi indicator may be used just to= prevent > >an ENUM query. Result: ;pstn is used in ENUM - ;enumdi is used in > >signalling. > > > >4. Now the real problem starts: If the ENUM-query returns= NXDOMAIN, > >the current assumption of all clients is: the call is routed to= the > >PSTN if the server is able to do so (eventually with the ;enumdi= =20 > set. > > > >This means, we refer the problem to the PSTN. This is not nice= for > >various reasons: > >1. we are bothering the PSTN in some cases unnecessarily > >2. the PSTN may not know what to do either and bounce the > >call back, which is creating loops > >3. and finally: what are we doing if there is no PSTN anymore ;-) > >Ok, this seems far reached, but Internet Telephony should be=20 > finally > >self-containing. > > > >So what are the additional policies we may want to tell an ENUM- > >client? > > > >1. No such number (unassigned number) > >1a. The whole number range (number block)is unassigned > >1b. There are numbers assigned in this number range, but if you > >do not find one in ENUM, you also will not find one on the PSTN,= so > >it makes no sense to route it to the PSTN (ENUM-only) > >2. Default routing for the whole number range (number block) to= =20 > a VoIP > >gateway. > >2a. The whole block is routed, there are no individual entries=20 > in ENUM > >(e.g. 1-800 numbers) > >2b. There are numbers in ENUM, but if you do not find an entry,= =20 > route > >the call to the default gateway given. One example for this case= =20 > may be > >a VoIP provider operating an island only connected to the PSTN.= =20 > Some > >of the users are also in ENUM (opt-in). If he provider now opens= =20 > up access > >to the Internet via a gateway (border element, ...), he may want= =20 > to route > >all calls for his users not in ENUM to the gateway provided by=20 > default > > > >Case 1a and 2a can be dealt with in e164.arpa with wildcards,=20 > because no > >Additional entries below exist. > >Case 1b and 2b cannot be dealt within e164.arpa, because=20 > wildcards do > >not support this. > > > >The solutions proposed for this sofar are. > > > >A. use tables in each server. This is not a good idea and does=20 > not help > >ENUM-enable UA. The information should be stored in a global=20 > accessible > >and public database (DNS). > > > >B. use a (one, common) second common tree (e164shadow.arpa,=20 > where you put > >in only the wildcards for the number ranges in question. The=20 > processing > >assumption now should be: > > > >If the ENUM-query returns NXDOMAIN, the call is not routed to=20 > the PSTN > >In any case, the server queries e164shadow.arpa, and only if no= =20 > entry > >is found there, the call is routed to the PSTN. The management= and > >delegation procedures of the tree are the same as for e164.arpa. > >The second tree would contain only wildcard NAPTR RR for number= =20 > ranges > > > >This would be the optimal solution proposed sofar. The problem=20 > is that > >a common agreement and a definition on the second tree is=20 > necessary. > > > >C. Use individual second shadow trees, eg on a national level,=20 > eg in > >Austria e164shadow.at would be used. The problem here is how one= =20 > can > >find out the domain names of the individual trees. > >One solution is to do it with a table in each server (which is=20 > not good). > > > >The other solution is to put pointers in e164.arpa, eg SRV RR or= =20 > even MX RR. > >The MX record would give eg the root of the other tree, and each= =20 > tree > >would be structured in the sane way like e164.arpa, so the same= =20 > algorithms > >can be used. > > > >Since the structure of the delegations in e164.arpa varies (Tier= =20 > 1 levels), > >there is no easy way to find out the level of the pointers, even= =20 > if they are > >only on the Tier 1 layer. > > > >It was proposed to search either top down (faster) or bottom up= =20 > (more > >flexible), because this would allow sub-policies in number= ranges. > > > >D. Are there additional possibilities or proposals? > > > >Finally I come to the last issue: > > > >For case 1a and 1b above (no such number) an "enumservice" is=20 > necessary > >to indicate that there exists no such number, neither in ENUM=20 > nor on the > >PSTN. > > > >Proposals sofar are: > > > >Use a special flag e.g. "n" or "v" > >Use a "enumservice" e.g. "E2U+NONE" or "E2U+VOID" or only "VOID" > > > >Also here additional proposals are invited. > > > >Best regards > > > >Richard > > > > > > > > > >_______________________________________________ > >enum mailing list > >enum@ietf.org >=20 >= >https://www1.ietf.org/mailman= /listinfo/enum=20 > > > > >_______________________________________________ > >Iptel mailing list > >Iptel@ietf.org >=20 >= >https://www.ietf.org/mailman/= listinfo/iptel=20 > > > > >z{x%^=E1=A6=9Ezrm=E1=A8=B6? >0u'~ffX)n _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Mar 30 22:20:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21329 for ; Tue, 30 Mar 2004 22:20:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8WGs-0001MU-TO for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 22:20:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V3K6Xa005235 for enum-archive@odin.ietf.org; Tue, 30 Mar 2004 22:20:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8WGn-0001LZ-Ip; Tue, 30 Mar 2004 22:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8WGX-0001JT-4A for enum@optimus.ietf.org; Tue, 30 Mar 2004 22:19:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21317 for ; Tue, 30 Mar 2004 22:19:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8WGT-0007HZ-00 for enum@ietf.org; Tue, 30 Mar 2004 22:19:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8WFa-0007Es-00 for enum@ietf.org; Tue, 30 Mar 2004 22:18:48 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B8WEp-00079d-00 for enum@ietf.org; Tue, 30 Mar 2004 22:17:59 -0500 Content-Class: urn:content-classes:message Subject: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Date: Wed, 31 Mar 2004 05:17:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-ID: <06CF906FE3998C4E944213062009F162233C7C@oefeg-s02.oefeg.loc> x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQWx8tYy/g0NBk1TNSt0WqCIeZWWgABLNKW From: "Stastny Richard" To: "Michael Hammer" , "James McEachern" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgTWlrZSwNCg0KPkluIHRvZGF5J3MgZW52aXJvbm1lbnQsIEkgdGhpbmsgd2UgaGF2ZSBwb2Nr ZXRzIG9mIElQIG5ldHdvcmtzDQo+aW50ZXJjb25uZWN0ZWQgYnkgdGhlIGdsb2JhbCBQU1ROLiAg T25lIG9mIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIFBTVE4NCj5pcyB0aGF0IEkgY2FuIGRp YWwgYSBudW1iZXIgZnJvbSBhbnl3aGVyZSBpbiB0aGUgd29ybGQgYW5kIGl0IHdpbGwgZ2V0DQo+ cm91dGVkIHRvIHRoZSBkZXN0aW5hdGlvbiB3aGVyZSB0aGF0IG51bWJlciByZXNpZGVzLiAgV2hl biBnb2luZyBmcm9tIFBTVE4NCj50byBJUCwgaXQgbWlnaHQgYmUgZXhwZWN0ZWQgdGhhdCB0aGUg UFNUTi1JUCBHVyBoYXMgYWxsIHRoZSB0ZWxlcGhvbmUNCj5udW1iZXIgdG8gU0lQL0lQIGFkZHJl c3MgbWFwcGluZ3MgYXNzb2NpYXRlZCB3aXRoIHRoYXQgSVAgcG9ja2V0DQo+cHJvdmlzaW9uZWQg aW50byBpdC4NCiANCk5vdCB3aXRoIGEgZ2VuZXJpYyBnYXRld2F5IHVzaW5nIEVOVU06IGFueSBn YXRld2F5IG1heSByb3V0ZSBhbnkgY2FsbA0KdG8gYW55IG51bWJlciBpbiBFTlVNLiBUaGlzIGlz IGJ5IGRlZmluaXRpb24gYWxsIG51bWJlcnMgbGl2aW5nIGluIEVOVU0tb25seS4NCg0KPk5vdyBy ZXZlcnNlIHRoZSBzaXR1YXRpb24uICBXZSBoYXZlIHBvY2tldHMgb2YgVERNIGludGVyY29ubmVj dGVkIHRvIHRoZQ0KPiJOZXR3b3JrIi4gIEEgdXNlciBpbiB0aGF0IFRETSBwb2NrZXQgZGlhbHMg YSBudW1iZXIgaXQgZ29lcyB0byBhIG5lYXJieQ0KPmdhdGV3YXkgYW5kIHRoZW4gcm91dGVkIHRv IGFueXdoZXJlIGluIHRoZSBOZXR3b3JrLiAgSSBkb24ndCBleHBlY3QgdGhhdA0KPmdhdGV3YXkg dG8gaGF2ZSBhIG1hcHBpbmcgZnJvbSBhbGwgb2YgdGhlIHRlbGVwaG9uZSBudW1iZXJzIGluIHRo ZSB3b3JsZCB0bw0KPmEgU0lQIG9yIElQIGFkZHJlc3MgaW4gdGhlIElQIGRvbWFpbi4gIFNvLCBn aXZlbiBvbmx5IGEgdGVsZXBob25lIG51bWJlciwNCj5ob3cgZG8gSSBnZXQgcm91dGluZyBpbmZv cm1hdGlvbiBmb3IgdGhlIElQIGRvbWFpbj8gIEkgYXNzdW1lZCB0aGUgRU5VTQ0KPmRhdGFiYXNl IHdvdWxkIGdldCB0aGVtIHN0YXJ0ZWQgb24gZG9pbmcgdGhhdCB0cmFuc2xhdGlvbiwgb3IgYXQg bGVhc3QNCj5nb2luZyBpbiB0aGUgcmlnaHQgZGlyZWN0aW9uLg0KIA0KQ29ycmVjdA0KDQo+SSBk b24ndCBzZWUgdGhhdCB0aGlzIGNoYW5nZXMgb3B0LWluLiAgV2hhdCBpdCBwcm9iYWJseSBkb2Vz IG1lYW4gaXMgdGhhdCwNCj5sYWNraW5nIGFueSBFTlVNIGVudHJ5LCB0aGUgY2FsbCBtdXN0IGJl IHJvdXRlZCBtb3N0bHkgdGhyb3VnaCB0aGUgUFNUTiB0bw0KPnRoZSAob25lPykgR1cgdGhhdCBo YXMgYSBtYXBwaW5nIHRvIHRoZSBjYWxsZWQgcGFydHkgaW4gdGhlIGxhc3QgSVANCj5kb21haW4u ICBUaGF0IGlzIGxpa2VseSB0byBkZWxheSBjcm9zc2luZyBpbnRvIHRoZSBJUCBkb21haW4sIGJl IGEgbW9yZQ0KPmV4cGVuc2l2ZSBjYWxsLCBhbmQgb25lIHdoaWNoIHBlcnBldHVhdGVzIHRoZSBU RE0gYmFja2JvbmUuDQogDQpBZ2FpbjogRm9yIG9wdC1pbiBFTlVNIGVudHJpZXMgeWVzLCBmb3Ig RU5VTS1vbmx5IGVudHJpZXMgbm8sIGJlY2F1c2UNCml0IGRvZXMgbm90IG1ha2Ugc2Vuc2UgdG8g cm91dGUgdGhlbSB0byB0aGUgUFNUTiwgYmVjYXN1ZSB0aGVyZSBpcyBubw0Kb25lIHNwZWNpZmlj IGdhdGV3YXkgaGF2aW5nIHRoZSBtYXBwaW5nLCBhbGwgR1dzIGFyZSBlcXVhbCwgc28gdGhlIGNh bGwNCmNhbiBiZSByb3V0ZWQgb24gdGhlIFBTVE4gb25seSBhZ2FpbiB0byBhIGdlbmVyaWMgZ2F0 ZXdheSwgYW5kIHRoaXMgR1cNCndpbGwgZmluZCBvdXQgYWdhaW4gdGhhdCB0aGVyZSBpcyBubyBl bnRyeSBpbiBFTlVNLg0KDQo+SSB3YXMgYWxzbyBjb25qZWN0dXJpbmcgd2hhdCBpdCBtZWFucyB0 byAib3duIiBhIHRlbGVwaG9uZSBudW1iZXIuICBJbiB0aGUNCj5QU1ROLCB0aGUgbnVtYmVyIGlz IG93bmVkIGJ5IHRoZSBTUCBhbmQgYXNzaWduZWQgdG8gYW4gZW5kLXVzZXIuICBUaGUgTE5QDQo+ cnVsaW5ncyBzdHJldGNoIHRoYXQgYSBiaXQgYnkgYWxsb3dpbmcgYSBudW1iZXIgdG8gYmUgY2Fy cmllZCB0byBhbm90aGVyDQo+U1AsIGJ1dCB0ZWNobmljYWxseSBpdCBpcyBzdGlsbCBvd25lZCBi eSB0aGUgb3JpZ2luYWwgY2Fycmllci4gIElmIGl0IGlzDQo+ZXZlciBnaXZlbiB1cCwgaXQgcmV2 ZXJ0cyBiYWNrIHRvIHRoYXQgY2Fycmllci4gDQogDQpPbmx5IGZvciBnZW9ncmFwaGljIG51bWJl cnMsIGFuZCB0aGF0IGhhcyBtb3N0bHkgdGVjaG5pY2FsIHJlYXNvbnMNCihvbndhcmQgcm91dGlu ZykNCiANCkZpcnN0LCBubyBudW1iZXIgaXMgb3duZXIgYnkgYW55Ym9keSwgaXQgaXMgYXNzaWdu ZWQgYnkgSVRVLVQgdG8gdGhlIE5SQSwNCmFuZCBhc3NpZ25lZCBpbiB0dXJuIHRvIHRoZSBTUCwg YW5kIHRoZSBTUCBhc3NpZ25lcyBpdCB0byB0aGUgZW5kLXVzZXIgKGZvcg0KZ2VvZ3JhcGhpYyBu dW1iZXJzLiBTZXJ2aWNlIG51bWJlcnMgYXJlIGFscmVhZHkgYXNzaWduZWQgb25lLWJ5LW9uZQ0K dG8gdGhlIGVuZC11c2VyIGJ5IHRoZSBOUkEsIG5vIGJsb2Nrcywgbm8gYW5jaG9yIFNQLiANCiAN Cj5Ib3cgaXMgdGhpcyBnb2luZyB0byB3b3JrDQo+aW4gSVA/ICBBcmUgRS4xNjQgbnVtYmVyIGJs b2NrcyBnb2luZyB0byBiZSBhc3NpZ25lZCB0byBhbiBJVFNQPyAgRG9lcyBhDQo+VERNIGNhcnJp ZXIgdGhhdCBiZWNvbWVzIGFuIElUU1AgZ2V0IHRvIG1vdmUgdGhlbSBvdmVyIHdpdGhvdXQNCj5y ZXN0cmljdGlvbj8gIENvdWxkIGFuIElUU1Agb3duIGEgYmxvY2sgb2YgbnVtYmVycywgeWV0IGhh dmUgbm8gR1cgdG8gdGhlDQo+UFNUTj8gIEFyZSB0aGVyZSBnb2luZyB0byBiZSByZXN0cmljdGlv bnMgb24gaG93IHRoZSBuZXR3b3JrIGV2b2x2ZXM/DQogDQpXaXRoIEVOVU0tb25seSBudW1iZXJz IHRoZXJlIGlzIG5vIG5lZWQgdG8gYXNzaWduIGJsb2NrcyBvZiBudW1iZXJzLg0KQW4gRU5VTS1v bmx5IG51bWJlciBpcyB0aGUgZXF1aXZhbGVudCBvZiBhIGRvbWFpbiBuYW1lLiBJdCBpcyBhc3Np Z25lZA0KdG8gdGhlIGVuZC11c2VyIGRpcmVjdGx5LCB3aG8gY2hvb3NlcyB0aGUgU1AsIGxpa2Ug d2l0aCBhIHNlcnZpY2UgbnVtYmVyLg0KWW91IGFsc28gZG8gbm90IGFzc2lnbiBkb21haW4gbmFt ZXMgaW4gYmxvY2tzLg0KDQpJIHdvdWxkIGhvcGUgdGhhdCBldmVuIGlmIGFuIGluZGl2aWR1YWwg bnVtYmVyIHdhcyB1bmxpc3RlZCwgaWYgYSBibG9jayBvZg0KbnVtYmVycyBiZWxvbmdlZCB0byBh biBJVFNQLCB0aGVyZSB3b3VsZCBiZSBhIGhpZ2hlci1sZXZlbCBub2RlIGVudHJ5IGluDQp0aGUg RU5VTSB0cmVlLCBhbmQgdGhlIGNhbGwgY291bGQgYmUgcm91dGVkIHRvIGFuIElQLUdXLCB3aGlj aCBtaWdodCBoYXZlDQphZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRvIHJvdXRlIHRoZSBjYWxsLCBv ciBhdCBsZWFzdCBkZXRlcm1pbmUgdGhhdCB0aGUNCm51bWJlciBpcyB1bmFzc2lnbmVkLg0KIA0K SWYgeW91IGxvb2sgYXQgdGhlIG1vc3RseSB1c2VkIEVOVU0gc3RydWN0dXJlLCB0aGVyZSBpcyBv bmx5IGEgVGllciAwIChkZWxlZ2F0aW9ucw0Kb2YgQ0MsIHRoZW4gdGhlcmUgaXMgYSB0aWVyIDEg KGRlbGVnYXRpb24gb2Ygc2luZ2xlIG51bWJlcnMgdG8gZW5kIHVzZXJzKSBhbmQNCmEgdGllciAy LCBob2xkaW5nIHRoZSBkYXRhIChOQVBUUikuIE5vIG5lZWQgZm9yIGFuIGFkZGl0aW9uYWwgYmxv Y2sgc3RydWN0dXJlDQooZXhjZXB0IGluIEZyYW5jZSwgYnV0IHRoZXkgYXJlIGRpZmZlcmVudCBh bnl3YXkpDQoNCj5JIGNvbmZlc3MgSSBoYXZlIG5vdCBiZWVuIHdhdGNoaW5nIHRoZSBFTlVNIGxp c3QsIGJ1dCBwZXJoYXBzIHNob3VsZA0KPmpvaW4uICBNeSBhcG9sb2dpZXMgaWYgdGhpcyBoYXMg YWxsIGJlZW4gZmlndXJlZCBvdXQuDQogDQpnb29kIGlkZWENCiANClJpY2hhcmQNCg0KTWlrZQ0K DQoNCkF0IDAzOjU5IFBNIDMvMzAvMjAwNCAtMDUwMCwgSmFtZXMgTWNFYWNoZXJuIHdyb3RlOg0K DQo+TWlrZSwNCj5JbiB5b3VyIGVtYWlsIHlvdSBzdGF0ZToNCj4NCj4tLS1zbmlwLS0tDQo+VGhl IGRpZmZlcmVuY2UgaXMgaW4gdGhlIGludGVycHJldGF0aW9uIG9mIGEgbGFjayBvZiBhIHJlY29y ZC4gIEluIExOUCwgaXQNCj53b3VsZCBtZWFuIHRoYXQgdGhlIEUuMTY0IG51bWJlciBpcyBzdGls bCBvd25lZCBieSB0aGUgb3JpZ2luYWwgc3dpdGNoLA0KPndoZXJlYXMgaW4gRU5VTSBpdCB3b3Vs ZCBtZWFuIHRoYXQgdGhlIEUuMTY0IG51bWJlciBpcyBub3Qgcm91dGUtYWJsZSB0bw0KPmFuIElQ IGVuZHBvaW50LiAgRnJvbSBhIFRETSBwZXJzcGVjdGl2ZSwgdGhlIGVudGlyZSBJUCBkb21haW4g Y291bGQgYmUNCj52aWV3ZWQgYXMgYSBzaW5nbGUgc3dpdGNoIGFuZCB0aGUgTE5QIHJvdXRpbmcg c2NoZW1lIHNob3VsZCB3b3JrLiAgVGhlDQo+Y29udmVyc2UgKHdoZW4gcmVjb3JkcyBleGlzdCkg Y291bGQgYmUgdHJ1ZSBmb3IgRU5VTS4NCj4NCj4NCj5BIGdhdGV3YXkgYmV0d2VlbiBJUC1kb21h aW4gYW5kIFRETSBkb21haW4sIHVwb24gc2VlaW5nIHRoYXQgYm90aCBhbiBMTlANCj5hbmQgYW4g RU5VTSBkaXAgaGF2ZSBub3QgcmVzb2x2ZWQgdGhlIHJvdXRlLCBjYW4gc2FmZWx5IGNvbmNsdWRl IHRoYXQgdGhlDQo+bnVtYmVyIGlzIHVuYXNzaWduZWQgYW5kIHJlbGVhc2UgdGhlIGNhbGwuIg0K Pg0KPi0tLWVuZCBzbmlwLS0tDQo+DQo+VGhpcyBzZWVtcyB0byBzdWdnZXN0IHRoYXQgcm91dGlu ZyB0byBhbiBJUCBlbmRwb2ludCB3b3VsZCByZXF1aXJlIGFuIEVOVU0NCj5lbnRyeSAtIG90aGVy d2lzZSB0aGUgZ2F0ZXdheSBjb3VsZCBzYWZlbHkgYXNzdW1lIHRoZSBudW1iZXIgaXMNCj51bmFz c2lnbmVkLiBEbyB5b3UgcmVhbGx5IG1lYW4gdGhpcz8gV2hhdCB3b3VsZCB0aGlzIGRvIHRvIG9w dC1pbj8NCj4NCj5UaGFua3MNCj5KaW0NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PkZyb206IFN0YXN0bnkgUmljaGFyZA0KPls8bWFpbHRvOlJpY2hhcmQuU3Rhc3RueUBvZWZlZy5h dD5tYWlsdG86UmljaGFyZC5TdGFzdG55QG9lZmVnLmF0XQ0KPlNlbnQ6IE1vbmRheSwgTWFyY2gg MjksIDIwMDQgMTA6MzAgQU0NCj5UbzogTWljaGFlbCBIYW1tZXINCj5DYzogaXB0ZWxAaWV0Zi5v cmc7IHNpcHBpbmdAaWV0Zi5vcmc7IGVudW1AaWV0Zi5vcmcNCj5TdWJqZWN0OiBBVzogW0lwdGVs XSBGVzogW0VudW1dIFN1bW1hcnkgb24gTm9QU1ROIGRpY3Vzc2lvbg0KPg0KPkhpIE1pY2hhZWws DQo+DQo+V2UgYXJlIHRyeWluZyB0byBmaW5kIGEgc29sdXRpb24gZm9yIHRoZSBmb2xsb3dpbmcg c2NlbmFyaW9zOg0KPkEuIEFuIEUuMTY0IG51bWJlciByYW5nZSBpcyBvbmx5IGF2YWlsYWJsZSBh bmQgcm91dGFibGUgaW4gRU5VTQ0KPkIuIEFuIEUuMTY0IG51bWJlciByYW5nZSBpcyBhdmFpbGFi bGUgdmlhIFBTVE4gYW5kIHZpYSBJUA0KPkMuIEFuIEUuMTY0IG51bWJlciByYW5nZSBpcyBub3Qg YXNzaWduZWQgYXQgdGhlIFBTVE4NCj4NCj5JZiBpbiBjYXNlcyBBIGFuZCBCIGFuIGVudHJ5IGlz IGV4aXN0aW5nIGluIEVOVU0sIG5vIHByb2JsZW0uDQo+SWYgdGhlIHF1ZXJ5IHJldHVybnMgTlhE T01BSU4sIHRoZSBwcm9ibGVtIGFyaXNlcyBmb3IgdGhlDQo+cXVlcnlpbmcgc2VydmVyIGhvdyB0 byBwcm9jZWVkLg0KPg0KPkluIGNhc2UgQSB0aGUgc2VydmVyIG11c3Qgbm90IGZvcndhcmQgdGhl IGNhbGwgdG8gdGhlIFBTVE4sIGJlY2F1c2UNCj5hIGxvb3AgbWF5IGJlIGNyZWF0ZWQuIEluIGNh c2VzIEIgYW5kIEMgaXQgbWF5IGZvcndhcmQgdGhlIGNhbGwgKG5vIGhhcm0pDQo+YnV0IGl0IGlz IG5vdCBuZWNlc3NhcnkuIEluIGNhc2UgQiB0aGUgc2VydmVyIGNvdWxkIHRlcm1pbmF0ZSB0aGUg Y2FsbCBvbiBJUCwNCj5pbiBjYXNlIEMgdGhlIHNlcnZlciBjb3VsZCBzYXkgbnVtYmVyIG5vdCBh dmFpbGFibGUgYW5kIG5vdCBib3RoZXIgdGhlDQo+UFNUTiBhdCBhbGwuDQo+DQo+SWYgd2UgZmlu ZCBhIHNvbHV0aW9uIHRoYXQgY292ZXJzIEEsIEIgYW5kIEMgbWF5IGJlIGNvdmVyZWQgYXMgd2Vs bC4NCj4NCj5JIGFncmVlIHRoYXQgaW4gZnV0dXJlIGNhbGwgcm91dGluZyBtYXkgYmUgaW1wcm92 ZWQgZnVydGhlciBpbiBhY2Nlc3MNCj50byBMTlAgc2VydmVycyBvbiB0aGUgUFNUTiBpcyBhdmFp bGFibGUgYW5kIGFsc28gaWYgYWNjZXNzIHRvIEVOVU0NCj5pcyBhdmFpbGFibGUgb24gdGhlIFBT VE4gKHNvbWUgY2FycmllcnMgYXJlIGFscmVhZHkgd29ya2luZyBvbiB0aGlzKSwNCj5idXQgdGhp cyB3aWxsIHRha2Ugc29tZSB0aW1lLg0KPg0KPldlIHNob3VsZCBhbHNvIGNvbWUgdXAgd2l0aCBh IHNzZWxmLWNvbnRhaW5pbmcgc29sdXRpb24gb24gSVAgYW5kDQo+bm90IGFsd2F5cyByZWx5IG9u IHRoZSBQU1ROLg0KPg0KPnJlZ2FyZHMNCj5SaWNoYXJkDQo+DQo+ICAgICAgICAgLS0tLS1VcnNw csODwrxuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+ICAgICAgICAgVm9uOiBNaWNoYWVsIEhhbW1l cg0KPiBbPG1haWx0bzptaGFtbWVyQGNpc2NvLmNvbT5tYWlsdG86bWhhbW1lckBjaXNjby5jb21d DQo+ICAgICAgICAgR2VzZW5kZXQ6IEZyIDI2LjAzLjIwMDQgMTc6NDANCj4gICAgICAgICBBbjog U3Rhc3RueSBSaWNoYXJkDQo+ICAgICAgICAgQ2M6IGlwdGVsQGlldGYub3JnOyBzaXBwaW5nQGll dGYub3JnDQo+ICAgICAgICAgQmV0cmVmZjogUmU6IFtJcHRlbF0gRlc6IFtFbnVtXSBTdW1tYXJ5 IG9uIE5vUFNUTiBkaWN1c3Npb24NCj4NCj4NCj4NCj4gICAgICAgICBSaWNoYXJkLA0KPg0KPiAg ICAgICAgIEdvaW5nIG91dCBvbiBhIGxpbWIgaGVyZSwgc2luY2UgSSBoYXZlIG5vdCBzZWVuIGFs bCB0aGUgcmVmZXJlbmNlZA0KPiAgICAgICAgIGRpc2N1c3Npb25zLiAgTXkgZmlyc3QgaW1wcmVz c2lvbiBpcyB0aGF0IHRoZSBkZXNjcmlwdGlvbiBiZWxvdw0KPiBpcyBvdmVybGF5DQo+ICAgICAg ICAgY29tcGxleC4NCj4NCj4gICAgICAgICBJIGhhdmUgYSBjb25jZXJuIHRoYXQgeW91IGFwcGVh ciB0byBiZSBwcm9wb3NpbmcgdGhhdCB0aGUgRU5VTQ0KPiBkaXAgd291bGQNCj4gICAgICAgICBo YXZlIGRlZmluaXRpdmUgYW5zd2VycyB0bzoNCj4gICAgICAgICBhKSB3aGV0aGVyIGEgbnVtYmVy IGhhcyBiZWVuIGFzc2lnbmVkIGFuZCB0aGVyZWZvcmUgcm91dC1hYmxlLA0KPiAgICAgICAgIGIp IHdoZXRoZXIgYSBudW1iZXIgdGhhdCBpcyBhc3NpZ25lZCB3YXMgZG9uZSwgYW5kIGlmIHNvIHdo ZXRoZXINCj4gdG8gYSBQU1RODQo+ICAgICAgICAgZW5kcG9pbnQgb3IgYW4gSVAgZW5kcG9pbnQu DQo+DQo+ICAgICAgICAgQW5vdGhlciBjb25jZXJuIGlzIHRoYXQsIGlmIHlvdSBkbyBnZXQgbG9v cGVkIHJvdXRpbmcgYmV0d2VlbiB0aGUNCj4gSVAgZG9tYWluDQo+ICAgICAgICAgYW5kIHRoZSBU RE0gZG9tYWluLCB0aGlzIGlzIGxpa2VseSBhbiBpbmRpY2F0aW9uIG9mIGEgbGFjayBvZg0KPiAg ICAgICAgIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIHRoZSBFTlVNIGRhdGFiYXNlIGFuZCB0aGUg TE5QDQo+IGRhdGFiYXNlLiAgT25lIG9yIHRoZQ0KPiAgICAgICAgIG90aGVyIGhhcyBpbmNvcnJl Y3QgZGF0YS4gIEkgc3VzcGVjdCB0aGF0IHRoZXJlIG1heSBiZSB0aW1lIGxhZ3MNCj4gZnJvbSB3 aGVuDQo+ICAgICAgICAgYW4gU1AgYXNzaWducyBhIG51bWJlciBhbmQgd2hlbiBpdCBnZXRzIHJl ZmxlY3RlZCBpbiBvbmUgb3IgYW5vdGhlcg0KPiAgICAgICAgIGRhdGFiYXNlcy4gIElmIHlvdSB3 YW50IHRoZSBFTlVNIGFuZCBMTlAgZGF0YWJhc2VzIHRvIGJlIHNvbWV3aGF0DQo+ICAgICAgICAg aW5kZXBlbmRlbnQsIHlvdSBtaWdodCB3YW50IGEgbG9vc2UgY291cGxpbmcgb2YgdGhlIHVzZSBv ZiB0aGUNCj4gdHdvIHN5c3RlbXM6DQo+DQo+ICAgICAgICAgICAtSWYgZW5kcG9pbnQgaXMgVERN LCB0aGVuIHRoZSBFTlVNIGRhdGFiYXNlIHNob3VsZCBwb2ludCB0byB0aGUNCj4gUFNUTiwNCj4g ICAgICAgICB3aXRoIGRlZmF1bHQgYmVoYXZpb3IgYmVpbmcsIGlmIHVua25vd24gdG8gRU5VTSwg c2VuZCB0byBQU1ROIHRvDQo+ICAgICAgICAgcmVzb2x2ZS4gIChOb3RlIHRoaXMgaXMgb3J0aG9n b25hbCB0byBFTlVNcyB1c2UgdG8gc2VsZWN0DQo+IGFsdGVybmF0aXZlDQo+ICAgICAgICAgZW5k cG9pbnRzLikNCj4NCj4gICAgICAgICAgIC0gSWYgZW5kcG9pbnQgaXMgSVAsIHRoZW4gdGhlIExO UCBkYXRhYmFzZXMgc2hvdWxkIHBvaW50IHRvIHRoZSBJUA0KPiAgICAgICAgIGRvbWFpbiwgd2l0 aCBkZWZhdWx0IGJlaGF2aW9yIGJlaW5nLCBpZiB1bmtub3duIHRvIExOUCwgcm91dGUgaW4NCj4g dGhlIFBTVE4NCj4gICAgICAgICB0byByZXNvbHZlLg0KPg0KPiAgICAgICAgIFRoZSBkaWZmZXJl bmNlIGlzIGluIHRoZSBpbnRlcnByZXRhdGlvbiBvZiBhIGxhY2sgb2YgYQ0KPiByZWNvcmQuICBJ biBMTlAsIGl0DQo+ICAgICAgICAgd291bGQgbWVhbiB0aGF0IHRoZSBFLjE2NCBudW1iZXIgaXMg c3RpbGwgb3duZWQgYnkgdGhlIG9yaWdpbmFsDQo+IHN3aXRjaCwNCj4gICAgICAgICB3aGVyZWFz IGluIEVOVU0gaXQgd291bGQgbWVhbiB0aGF0IHRoZSBFLjE2NCBudW1iZXIgaXMgbm90DQo+IHJv dXRlLWFibGUgdG8gYW4NCj4gICAgICAgICBJUCBlbmRwb2ludC4gIEZyb20gYSBURE0gcGVyc3Bl Y3RpdmUsIHRoZSBlbnRpcmUgSVAgZG9tYWluIGNvdWxkDQo+IGJlIHZpZXdlZA0KPiAgICAgICAg IGFzIGEgc2luZ2xlIHN3aXRjaCBhbmQgdGhlIExOUCByb3V0aW5nIHNjaGVtZSBzaG91bGQgd29y ay4gIFRoZQ0KPiBjb252ZXJzZQ0KPiAgICAgICAgICh3aGVuIHJlY29yZHMgZXhpc3QpIGNvdWxk IGJlIHRydWUgZm9yIEVOVU0uDQo+DQo+ICAgICAgICAgQSBnYXRld2F5IGJldHdlZW4gSVAtZG9t YWluIGFuZCBURE0gZG9tYWluLCB1cG9uIHNlZWluZyB0aGF0IGJvdGgNCj4gYW4gTE5QDQo+ICAg ICAgICAgYW5kIGFuIEVOVU0gZGlwIGhhdmUgbm90IHJlc29sdmVkIHRoZSByb3V0ZSwgY2FuIHNh ZmVseSBjb25jbHVkZQ0KPiB0aGF0IHRoZQ0KPiAgICAgICAgIG51bWJlciBpcyB1bmFzc2lnbmVk IGFuZCByZWxlYXNlIHRoZSBjYWxsLg0KPg0KPiAgICAgICAgIEFjdHVhbGx5LCBpdCBtYXkgbm90 IGJlIG5lY2Vzc2FyeSB0byBzZW5kIGEgc2V0dXAgbWVzc2FnZSB0byBhDQo+IEdXLCBub3IgaXMN Cj4gICAgICAgICBpdCBuZWNlc3NhcnkgdG8gaGF2ZSB0aGUgRU5VTSBhbmQgTE5QIGRhdGFiYXNl cyBkdXBsaWNhdGUgZWFjaA0KPiBvdGhlci4gIEl0DQo+ICAgICAgICAgc2hvdWxkIGJlIHN1ZmZp Y2llbnQgZm9yIGFuIEVOVU0gREIgdG8gcXVlcnkgdGhlIExOUCBEQiBhbmQNCj4gcmVzcG9uZCB3 aXRoIGFuDQo+ICAgICAgICAgYXBwcm9wcmlhdGUgYW5zd2VyLCBvciB0aGUgY29udmVyc2UuDQo+ DQo+ICAgICAgICAgTWlrZQ0KPg0KPg0KPiAgICAgICAgIEF0IDA0OjIyIFBNIDMvMjUvMjAwNCAr MDEwMCwgU3Rhc3RueSBSaWNoYXJkIHdyb3RlOg0KPiAgICAgICAgID5Dcm9zcyBwb3N0aW5nIGZy b20gZW51bUBpZXRmLm9yZw0KPiAgICAgICAgID5UaGUgZGlzY3Vzc2lvbiBpcyBnb2luZyBvbiB0 aGUgZW51bS1saXN0DQo+ICAgICAgICAgPg0KPiAgICAgICAgID5SaWNoYXJkIFN0YXN0bnkNCj4g ICAgICAgICA+T2VGRUcNCj4gICAgICAgICA+KzQzIDY2NCA0MjAgNDEwMA0KPiAgICAgICAgID4N Cj4gICAgICAgICA+DQo+ICAgICAgICAgPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICAg ICAgICAgPkZyb206IFN0YXN0bnkgUmljaGFyZA0KPiAgICAgICAgID5TZW50OiBUaHVyc2RheSwg TWFyY2ggMjUsIDIwMDQgMTowOCBQTQ0KPiAgICAgICAgID5UbzogTWFyaWFuIER1cmtvdmljOyBs d2NAcm9rZS5jby51aw0KPiAgICAgICAgID5DYzogZW51bUBpZXRmLm9yZw0KPiAgICAgICAgID5T dWJqZWN0OiBbRW51bV0gU3VtbWFyeSBvbiBOb1BTVE4gZGljdXNzaW9uDQo+ICAgICAgICAgPg0K PiAgICAgICAgID5EZWFyIGNvbGxlYWd1ZXMsDQo+ICAgICAgICAgPg0KPiAgICAgICAgID5UaGVy ZSB3YXMgYSBsb3Qgb2YgZGlzY3Vzc2lvbnMgb24tbGlzdCBhbmQgb2ZmLWxpc3Qgb24gdGhpcyBp c3N1ZSwNCj4gICAgICAgICA+c28gSSB3aWxsIHRyeSB0byBzdW1tYXJpemUgYXQgbGVhc3QgbXkg dmlldyBvZiB0aGUgcHJvYmxlbS4NCj4gICAgICAgICA+SSB3aWxsIGFsc28gaW5jbHVkZSBteSBj dXJyZW50IHZpZXcgb24gdGhlIDtlbnVtZGkNCj4gICAgICAgICA+YW5kIHRoZSA7cHN0biBpbmRp Y2F0b3IgZm9yIHRoZSB0ZWw6IFVSSQ0KPiAgICAgICAgID4NCj4gICAgICAgICA+RU5VTS1lbmFi bGVkIFVBcyBhbmQgU2VydmVycyBhcmUgY3VycmVudGx5IHByb2Nlc3NpbmcNCj4gICAgICAgICA+ cmVjZWl2ZWQgRS4xNjQgbnVtYmVycyAoZWl0aGVyIGluIGEgdGVsOit4eHggVVJJIG9yIGluIGEg c2lwOiBVUkkNCj4gICAgICAgICA+aW4gdGhlIGZvcm1hdCBzaXA6K3h4eHhAcHJvYy5uZXQ7dXNl cj1waG9uZSkgaW4gdGhlIGZvbGxvd2luZyB3YXk6DQo+ICAgICAgICAgPihmb3Igc2ltcGxpY2l0 eSBJIGFtIG9ubHkgZGVhbGluZyB3aXRoIHZvaWNlIGNhbGxzKQ0KPiAgICAgICAgID5QbGVhc2Ug aG9sbGVyIGlmIEkgZ290IHNvbWV0aGluZyB3cm9uZyBvciB5b3UgZGlzYWdyZWUNCj4gICAgICAg ICA+DQo+ICAgICAgICAgPjEuIFF1ZXJ5IEVOVU0gKGluIGUxNjQuYXJwYSkNCj4gICAgICAgICA+ DQo+ICAgICAgICAgPjIuIGlmIGEgTkFQVFIgaXMgZm91bmQgd2l0aCBhbiAiZW51bXNlcnZpY2Ui IHNpcCBvciB2b2ljZTpzaXAsDQo+ICAgICAgICAgPmhhbmRsZSB0aGUgY2FsbCBhcyBpZiB5b3Ug aGF2ZSByZWNlaXZlZCBhIHNpcDogVVJJIGluIHRoZSBmb3JtYXQNCj4gICAgICAgICA+c2lwOnVz ZXJAcHJvdi5uZXQgaW4gdGhlIGZpcnN0IHBsYWNlLg0KPiAgICAgICAgID4NCj4gICAgICAgICA+ My4gSWYgYSBOQVBUUiBpcyBmb3VuZCB3aXRoIGFuICJlbnVtc2VydmljZSIgdm9pY2U6dGVsDQo+ ICAgICAgICAgPjNhLiBhbmQgdGhlIHRlbDogVVJJIGlzIHBvaW50aW5nIHRvIGEgZGlmZmVyZW50 IG51bWJlciwNCj4gICAgICAgICA+cXVlcnkgRU5VTSBhZ2FpbiBmb3IgdGhpcyBudW1iZXINCj4g ICAgICAgICA+M2IuIGlmIHRoZSB0ZWw6IFVSSSBpcyB0aGUgc2FtZSBhcyB0aGUgQVVTLCBmb3J3 YXJkIHRoZQ0KPiAgICAgICAgID5jYWxsIHRvIHRoZSBQU1ROLCBpZiB5b3UgYXJlIGFibGUgdG8g ZG8gc28uDQo+ICAgICAgICAgPg0KPiAgICAgICAgID5Ob3RlOiBoZXJlIHRoZSBwcm9wb3NlZCA7 cHN0biBpbmRpY2F0b3IgbWF5IGNvbWUgaW4gaGFuZHk6DQo+ICAgICAgICAgPkluIDNhIHlvdSBt YXkgdXNlIGl0IGluIHRoZSBOQVBUUiB0byBwcmV2ZW50IGEgc2Vjb25kIEVOVU0tcXVlcnkNCj4g ICAgICAgICA+YW5kIGZvcmNlIHRoZSBjYWxsIHRvIHRoZSBQU1ROLg0KPiAgICAgICAgID5JbiAz YiB0aGUgc2VydmVyIG1heSBhZGQgO3BzdG4gdG8gaW5mb3JtIHRoZSBuZXh0IHByb3h5IGFib3V0 DQo+ICAgICAgICAgPlRoZSBkZWNpc2lvbiB0byBmb3JjZSB0aGUgY2FsbCB0byB0aGUgUFNUTi4g T24gdGhlIG90aGVyIGhhbmQsDQo+ICAgICAgICAgPkluIHRoaXMgY2FzZSBhbHNvIHRoZSA7ZW51 bWRpIGluZGljYXRvciBtYXkgYmUgdXNlZCBqdXN0IHRvIHByZXZlbnQNCj4gICAgICAgICA+YW4g RU5VTSBxdWVyeS4gUmVzdWx0OiA7cHN0biBpcyB1c2VkIGluIEVOVU0gLSA7ZW51bWRpIGlzIHVz ZWQgaW4NCj4gICAgICAgICA+c2lnbmFsbGluZy4NCj4gICAgICAgICA+DQo+ICAgICAgICAgPjQu IE5vdyB0aGUgcmVhbCBwcm9ibGVtIHN0YXJ0czogSWYgdGhlIEVOVU0tcXVlcnkgcmV0dXJucyBO WERPTUFJTiwNCj4gICAgICAgICA+dGhlIGN1cnJlbnQgYXNzdW1wdGlvbiBvZiBhbGwgY2xpZW50 cyBpczogdGhlIGNhbGwgaXMgcm91dGVkIHRvIHRoZQ0KPiAgICAgICAgID5QU1ROIGlmIHRoZSBz ZXJ2ZXIgaXMgYWJsZSB0byBkbyBzbyAoZXZlbnR1YWxseSB3aXRoIHRoZSA7ZW51bWRpDQo+IHNl dC4NCj4gICAgICAgICA+DQo+ICAgICAgICAgPlRoaXMgbWVhbnMsIHdlIHJlZmVyIHRoZSBwcm9i bGVtIHRvIHRoZSBQU1ROLiBUaGlzIGlzIG5vdCBuaWNlIGZvcg0KPiAgICAgICAgID52YXJpb3Vz IHJlYXNvbnM6DQo+ICAgICAgICAgPjEuIHdlIGFyZSBib3RoZXJpbmcgdGhlIFBTVE4gaW4gc29t ZSBjYXNlcyB1bm5lY2Vzc2FyaWx5DQo+ICAgICAgICAgPjIuIHRoZSBQU1ROIG1heSBub3Qga25v dyB3aGF0IHRvIGRvIGVpdGhlciBhbmQgYm91bmNlIHRoZQ0KPiAgICAgICAgID5jYWxsIGJhY2ss IHdoaWNoIGlzIGNyZWF0aW5nIGxvb3BzDQo+ICAgICAgICAgPjMuIGFuZCBmaW5hbGx5OiB3aGF0 IGFyZSB3ZSBkb2luZyBpZiB0aGVyZSBpcyBubyBQU1ROIGFueW1vcmUgOy0pDQo+ICAgICAgICAg Pk9rLCB0aGlzIHNlZW1zIGZhciByZWFjaGVkLCBidXQgSW50ZXJuZXQgVGVsZXBob255IHNob3Vs ZCBiZQ0KPiBmaW5hbGx5DQo+ICAgICAgICAgPnNlbGYtY29udGFpbmluZy4NCj4gICAgICAgICA+ DQo+ICAgICAgICAgPlNvIHdoYXQgYXJlIHRoZSBhZGRpdGlvbmFsIHBvbGljaWVzIHdlIG1heSB3 YW50IHRvIHRlbGwgYW4gRU5VTS0NCj4gICAgICAgICA+Y2xpZW50Pw0KPiAgICAgICAgID4NCj4g ICAgICAgICA+MS4gTm8gc3VjaCBudW1iZXIgKHVuYXNzaWduZWQgbnVtYmVyKQ0KPiAgICAgICAg ID4xYS4gVGhlIHdob2xlIG51bWJlciByYW5nZSAobnVtYmVyIGJsb2NrKWlzIHVuYXNzaWduZWQN Cj4gICAgICAgICA+MWIuIFRoZXJlIGFyZSBudW1iZXJzIGFzc2lnbmVkIGluIHRoaXMgbnVtYmVy IHJhbmdlLCBidXQgaWYgeW91DQo+ICAgICAgICAgPmRvIG5vdCBmaW5kIG9uZSBpbiBFTlVNLCB5 b3UgYWxzbyB3aWxsIG5vdCBmaW5kIG9uZSBvbiB0aGUgUFNUTiwgc28NCj4gICAgICAgICA+aXQg bWFrZXMgbm8gc2Vuc2UgdG8gcm91dGUgaXQgdG8gdGhlIFBTVE4gKEVOVU0tb25seSkNCj4gICAg ICAgICA+Mi4gRGVmYXVsdCByb3V0aW5nIGZvciB0aGUgd2hvbGUgbnVtYmVyIHJhbmdlIChudW1i ZXIgYmxvY2spIHRvDQo+IGEgVm9JUA0KPiAgICAgICAgID5nYXRld2F5Lg0KPiAgICAgICAgID4y YS4gVGhlIHdob2xlIGJsb2NrIGlzIHJvdXRlZCwgdGhlcmUgYXJlIG5vIGluZGl2aWR1YWwgZW50 cmllcw0KPiBpbiBFTlVNDQo+ICAgICAgICAgPihlLmcuIDEtODAwIG51bWJlcnMpDQo+ICAgICAg ICAgPjJiLiBUaGVyZSBhcmUgbnVtYmVycyBpbiBFTlVNLCBidXQgaWYgeW91IGRvIG5vdCBmaW5k IGFuIGVudHJ5LA0KPiByb3V0ZQ0KPiAgICAgICAgID50aGUgY2FsbCB0byB0aGUgZGVmYXVsdCBn YXRld2F5IGdpdmVuLiBPbmUgZXhhbXBsZSBmb3IgdGhpcyBjYXNlDQo+IG1heSBiZQ0KPiAgICAg ICAgID5hIFZvSVAgcHJvdmlkZXIgb3BlcmF0aW5nIGFuIGlzbGFuZCBvbmx5IGNvbm5lY3RlZCB0 byB0aGUgUFNUTi4NCj4gU29tZQ0KPiAgICAgICAgID5vZiB0aGUgdXNlcnMgYXJlIGFsc28gaW4g RU5VTSAob3B0LWluKS4gSWYgaGUgcHJvdmlkZXIgbm93IG9wZW5zDQo+IHVwIGFjY2Vzcw0KPiAg ICAgICAgID50byB0aGUgSW50ZXJuZXQgdmlhIGEgZ2F0ZXdheSAoYm9yZGVyIGVsZW1lbnQsIC4u LiksIGhlIG1heSB3YW50DQo+IHRvIHJvdXRlDQo+ICAgICAgICAgPmFsbCBjYWxscyBmb3IgaGlz IHVzZXJzIG5vdCBpbiBFTlVNIHRvIHRoZSBnYXRld2F5IHByb3ZpZGVkIGJ5DQo+IGRlZmF1bHQN Cj4gICAgICAgICA+DQo+ICAgICAgICAgPkNhc2UgMWEgYW5kIDJhIGNhbiBiZSBkZWFsdCB3aXRo IGluIGUxNjQuYXJwYSB3aXRoIHdpbGRjYXJkcywNCj4gYmVjYXVzZSBubw0KPiAgICAgICAgID5B ZGRpdGlvbmFsIGVudHJpZXMgYmVsb3cgZXhpc3QuDQo+ICAgICAgICAgPkNhc2UgMWIgYW5kIDJi IGNhbm5vdCBiZSBkZWFsdCB3aXRoaW4gZTE2NC5hcnBhLCBiZWNhdXNlDQo+IHdpbGRjYXJkcyBk bw0KPiAgICAgICAgID5ub3Qgc3VwcG9ydCB0aGlzLg0KPiAgICAgICAgID4NCj4gICAgICAgICA+ VGhlIHNvbHV0aW9ucyBwcm9wb3NlZCBmb3IgdGhpcyBzb2ZhciBhcmUuDQo+ICAgICAgICAgPg0K PiAgICAgICAgID5BLiB1c2UgdGFibGVzIGluIGVhY2ggc2VydmVyLiBUaGlzIGlzIG5vdCBhIGdv b2QgaWRlYSBhbmQgZG9lcw0KPiBub3QgaGVscA0KPiAgICAgICAgID5FTlVNLWVuYWJsZSBVQS4g VGhlIGluZm9ybWF0aW9uIHNob3VsZCBiZSBzdG9yZWQgaW4gYSBnbG9iYWwNCj4gYWNjZXNzaWJs ZQ0KPiAgICAgICAgID5hbmQgcHVibGljIGRhdGFiYXNlIChETlMpLg0KPiAgICAgICAgID4NCj4g ICAgICAgICA+Qi4gdXNlIGEgKG9uZSwgY29tbW9uKSBzZWNvbmQgY29tbW9uIHRyZWUgKGUxNjRz aGFkb3cuYXJwYSwNCj4gd2hlcmUgeW91IHB1dA0KPiAgICAgICAgID5pbiBvbmx5IHRoZSB3aWxk Y2FyZHMgZm9yIHRoZSBudW1iZXIgcmFuZ2VzIGluIHF1ZXN0aW9uLiBUaGUNCj4gcHJvY2Vzc2lu Zw0KPiAgICAgICAgID5hc3N1bXB0aW9uIG5vdyBzaG91bGQgYmU6DQo+ICAgICAgICAgPg0KPiAg ICAgICAgID5JZiB0aGUgRU5VTS1xdWVyeSByZXR1cm5zIE5YRE9NQUlOLCB0aGUgY2FsbCBpcyBu b3Qgcm91dGVkIHRvDQo+IHRoZSBQU1RODQo+ICAgICAgICAgPkluIGFueSBjYXNlLCB0aGUgc2Vy dmVyIHF1ZXJpZXMgZTE2NHNoYWRvdy5hcnBhLCBhbmQgb25seSBpZiBubw0KPiBlbnRyeQ0KPiAg ICAgICAgID5pcyBmb3VuZCB0aGVyZSwgdGhlIGNhbGwgaXMgcm91dGVkIHRvIHRoZSBQU1ROLiBU aGUgbWFuYWdlbWVudCBhbmQNCj4gICAgICAgICA+ZGVsZWdhdGlvbiBwcm9jZWR1cmVzIG9mIHRo ZSB0cmVlIGFyZSB0aGUgc2FtZSBhcyBmb3IgZTE2NC5hcnBhLg0KPiAgICAgICAgID5UaGUgc2Vj b25kIHRyZWUgd291bGQgY29udGFpbiBvbmx5IHdpbGRjYXJkIE5BUFRSIFJSIGZvciBudW1iZXIN Cj4gcmFuZ2VzDQo+ICAgICAgICAgPg0KPiAgICAgICAgID5UaGlzIHdvdWxkIGJlIHRoZSBvcHRp bWFsIHNvbHV0aW9uIHByb3Bvc2VkIHNvZmFyLiBUaGUgcHJvYmxlbQ0KPiBpcyB0aGF0DQo+ICAg ICAgICAgPmEgY29tbW9uIGFncmVlbWVudCBhbmQgYSBkZWZpbml0aW9uIG9uIHRoZSBzZWNvbmQg dHJlZSBpcw0KPiBuZWNlc3NhcnkuDQo+ICAgICAgICAgPg0KPiAgICAgICAgID5DLiBVc2UgaW5k aXZpZHVhbCBzZWNvbmQgc2hhZG93IHRyZWVzLCBlZyBvbiBhIG5hdGlvbmFsIGxldmVsLA0KPiBl ZyBpbg0KPiAgICAgICAgID5BdXN0cmlhIGUxNjRzaGFkb3cuYXQgd291bGQgYmUgdXNlZC4gVGhl IHByb2JsZW0gaGVyZSBpcyBob3cgb25lDQo+IGNhbg0KPiAgICAgICAgID5maW5kIG91dCB0aGUg ZG9tYWluIG5hbWVzIG9mIHRoZSBpbmRpdmlkdWFsIHRyZWVzLg0KPiAgICAgICAgID5PbmUgc29s dXRpb24gaXMgdG8gZG8gaXQgd2l0aCBhIHRhYmxlIGluIGVhY2ggc2VydmVyICh3aGljaCBpcw0K PiBub3QgZ29vZCkuDQo+ICAgICAgICAgPg0KPiAgICAgICAgID5UaGUgb3RoZXIgc29sdXRpb24g aXMgdG8gcHV0IHBvaW50ZXJzIGluIGUxNjQuYXJwYSwgZWcgU1JWIFJSIG9yDQo+IGV2ZW4gTVgg UlIuDQo+ICAgICAgICAgPlRoZSBNWCByZWNvcmQgd291bGQgZ2l2ZSBlZyB0aGUgcm9vdCBvZiB0 aGUgb3RoZXIgdHJlZSwgYW5kIGVhY2gNCj4gdHJlZQ0KPiAgICAgICAgID53b3VsZCBiZSBzdHJ1 Y3R1cmVkIGluIHRoZSBzYW5lIHdheSBsaWtlIGUxNjQuYXJwYSwgc28gdGhlIHNhbWUNCj4gYWxn b3JpdGhtcw0KPiAgICAgICAgID5jYW4gYmUgdXNlZC4NCj4gICAgICAgICA+DQo+ICAgICAgICAg PlNpbmNlIHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIGRlbGVnYXRpb25zIGluIGUxNjQuYXJwYSB2YXJp ZXMgKFRpZXINCj4gMSBsZXZlbHMpLA0KPiAgICAgICAgID50aGVyZSBpcyBubyBlYXN5IHdheSB0 byBmaW5kIG91dCB0aGUgbGV2ZWwgb2YgdGhlIHBvaW50ZXJzLCBldmVuDQo+IGlmIHRoZXkgYXJl DQo+ICAgICAgICAgPm9ubHkgb24gdGhlIFRpZXIgMSBsYXllci4NCj4gICAgICAgICA+DQo+ICAg ICAgICAgPkl0IHdhcyBwcm9wb3NlZCB0byBzZWFyY2ggZWl0aGVyIHRvcCBkb3duIChmYXN0ZXIp IG9yIGJvdHRvbSB1cA0KPiAobW9yZQ0KPiAgICAgICAgID5mbGV4aWJsZSksIGJlY2F1c2UgdGhp cyB3b3VsZCBhbGxvdyBzdWItcG9saWNpZXMgaW4gbnVtYmVyIHJhbmdlcy4NCj4gICAgICAgICA+ DQo+ICAgICAgICAgPkQuIEFyZSB0aGVyZSBhZGRpdGlvbmFsIHBvc3NpYmlsaXRpZXMgb3IgcHJv cG9zYWxzPw0KPiAgICAgICAgID4NCj4gICAgICAgICA+RmluYWxseSBJIGNvbWUgdG8gdGhlIGxh c3QgaXNzdWU6DQo+ICAgICAgICAgPg0KPiAgICAgICAgID5Gb3IgY2FzZSAxYSBhbmQgMWIgYWJv dmUgKG5vIHN1Y2ggbnVtYmVyKSBhbiAiZW51bXNlcnZpY2UiIGlzDQo+IG5lY2Vzc2FyeQ0KPiAg ICAgICAgID50byBpbmRpY2F0ZSB0aGF0IHRoZXJlIGV4aXN0cyBubyBzdWNoIG51bWJlciwgbmVp dGhlciBpbiBFTlVNDQo+IG5vciBvbiB0aGUNCj4gICAgICAgICA+UFNUTi4NCj4gICAgICAgICA+ DQo+ICAgICAgICAgPlByb3Bvc2FscyBzb2ZhciBhcmU6DQo+ICAgICAgICAgPg0KPiAgICAgICAg ID5Vc2UgYSBzcGVjaWFsIGZsYWcgZS5nLiAibiIgb3IgInYiDQo+ICAgICAgICAgPlVzZSBhICJl bnVtc2VydmljZSIgZS5nLiAiRTJVK05PTkUiIG9yICJFMlUrVk9JRCIgb3Igb25seSAiVk9JRCIN Cj4gICAgICAgICA+DQo+ICAgICAgICAgPkFsc28gaGVyZSBhZGRpdGlvbmFsIHByb3Bvc2FscyBh cmUgaW52aXRlZC4NCj4gICAgICAgICA+DQo+ICAgICAgICAgPkJlc3QgcmVnYXJkcw0KPiAgICAg ICAgID4NCj4gICAgICAgICA+UmljaGFyZA0KPiAgICAgICAgID4NCj4gICAgICAgICA+DQo+ICAg ICAgICAgPg0KPiAgICAgICAgID4NCj4gICAgICAgICA+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgICAgICA+ZW51bSBtYWlsaW5nIGxpc3QNCj4g ICAgICAgICA+ZW51bUBpZXRmLm9yZw0KPg0KID4gPjxodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9lbnVtPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2VudW0NCj4NCj4gICAgICAgICA+DQo+ICAgICAgICAgPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAgICAgPklwdGVsIG1haWxpbmcgbGlzdA0K PiAgICAgICAgID5JcHRlbEBpZXRmLm9yZw0KPg0KID4gPjxodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lwdGVsPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXB0ZWwNCj4NCj4NCj4NCj4NCj56e3glXsOhwqbFvnpybcOhwqjCtj8NCj4wdSd+ZmZYKW4N Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZW51 bSBtYWlsaW5nIGxpc3QNCmVudW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2VudW0NCg0K _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Mar 31 15:19:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10953 for ; Wed, 31 Mar 2004 15:19:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8mAo-0000km-F2 for enum-archive@odin.ietf.org; Wed, 31 Mar 2004 15:18:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VKIsRZ002896 for enum-archive@odin.ietf.org; Wed, 31 Mar 2004 15:18:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8m9w-0000W3-VA; Wed, 31 Mar 2004 15:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8l0Y-0003OX-Hy for enum@optimus.ietf.org; Wed, 31 Mar 2004 14:04:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07604 for ; Wed, 31 Mar 2004 14:04:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8l0U-00044x-00 for enum@ietf.org; Wed, 31 Mar 2004 14:04:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8kzV-00042k-00 for enum@ietf.org; Wed, 31 Mar 2004 14:03:11 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B8kya-00040A-00 for enum@ietf.org; Wed, 31 Mar 2004 14:02:12 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 31 Mar 2004 11:10:36 -0800 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2VJ1ccp026827; Wed, 31 Mar 2004 14:01:38 -0500 (EST) Received: from mhammer-w2k03.cisco.com ([64.100.229.254]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AYC94907; Wed, 31 Mar 2004 11:01:35 -0800 (PST) Message-Id: <4.3.2.7.2.20040331134339.03843e90@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Mar 2004 14:01:35 -0500 To: "Stastny Richard" From: Michael Hammer Subject: Re: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Cc: "James McEachern" , In-Reply-To: <06CF906FE3998C4E944213062009F162233C7C@oefeg-s02.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable At 05:17 AM 3/31/2004 +0200, Stastny Richard wrote: >Hi Mike, > > >In today's environment, I think we have pockets of IP networks > >interconnected by the global PSTN. One of the characteristics of the= PSTN > >is that I can dial a number from anywhere in the world and it will get > >routed to the destination where that number resides. When going from= PSTN > >to IP, it might be expected that the PSTN-IP GW has all the telephone > >number to SIP/IP address mappings associated with that IP pocket > >provisioned into it. > >Not with a generic gateway using ENUM: any gateway may route any call >to any number in ENUM. This is by definition all numbers living in= ENUM-only. This was my pre-ENUM view, probably now dated. > >Now reverse the situation. We have pockets of TDM interconnected to the > >"Network". A user in that TDM pocket dials a number it goes to a nearby > >gateway and then routed to anywhere in the Network. I don't expect that > >gateway to have a mapping from all of the telephone numbers in the world= to > >a SIP or IP address in the IP domain. So, given only a telephone number, > >how do I get routing information for the IP domain? I assumed the ENUM > >database would get them started on doing that translation, or at least > >going in the right direction. > >Correct > > >I don't see that this changes opt-in. What it probably does mean is= that, > >lacking any ENUM entry, the call must be routed mostly through the PSTN= to > >the (one?) GW that has a mapping to the called party in the last IP > >domain. That is likely to delay crossing into the IP domain, be a more > >expensive call, and one which perpetuates the TDM backbone. > >Again: For opt-in ENUM entries yes, for ENUM-only entries no, because >it does not make sense to route them to the PSTN, becasue there is no >one specific gateway having the mapping, all GWs are equal, so the call >can be routed on the PSTN only again to a generic gateway, and this GW >will find out again that there is no entry in ENUM. Understood. If it ENUM-only, then it should never go to a GW. > >I was also conjecturing what it means to "own" a telephone number. In= the > >PSTN, the number is owned by the SP and assigned to an end-user. The LNP > >rulings stretch that a bit by allowing a number to be carried to another > >SP, but technically it is still owned by the original carrier. If it is > >ever given up, it reverts back to that carrier. > >Only for geographic numbers, and that has mostly technical reasons >(onward routing) > >First, no number is owner by anybody, it is assigned by ITU-T to the NRA, >and assigned in turn to the SP, and the SP assignes it to the end-user (for >geographic numbers. Service numbers are already assigned one-by-one >to the end-user by the NRA, no blocks, no anchor SP. How does this work for numbers that were assigned to an SP, that used to be= =20 TDM-only, but then (over time) converts to an IP-only network? The SPs are= =20 very guarded about the E.164 numbers assigned to them. That is what I=20 meant by "owned." You are suggesting that when a person with a phone=20 number assigned by an SP moves to an IP-based "phone" that the SP will=20 relinquish that phone number back to the NRA? Or are you saying that=20 number portability doesn't work between TDM and IP worlds? > >How is this going to work > >in IP? Are E.164 number blocks going to be assigned to an ITSP? Does a > >TDM carrier that becomes an ITSP get to move them over without > >restriction? Could an ITSP own a block of numbers, yet have no GW to the > >PSTN? Are there going to be restrictions on how the network evolves? > >With ENUM-only numbers there is no need to assign blocks of numbers. >An ENUM-only number is the equivalent of a domain name. It is assigned >to the end-user directly, who chooses the SP, like with a service number. >You also do not assign domain names in blocks. I think there is an issue here. If the SPs hold most of the current NPA=20 blocks, and there is a migration of many users from TDM to IP, then do you= =20 lengthen the number to 11 digits to get more, or do the SPs have to=20 relinquish numbers? >I would hope that even if an individual number was unlisted, if a block of >numbers belonged to an ITSP, there would be a higher-level node entry in >the ENUM tree, and the call could be routed to an IP-GW, which might have >additional information to route the call, or at least determine that the >number is unassigned. > >If you look at the mostly used ENUM structure, there is only a Tier 0=20 >(delegations >of CC, then there is a tier 1 (delegation of single numbers to end users)= and >a tier 2, holding the data (NAPTR). No need for an additional block= structure >(except in France, but they are different anyway) I now understand the plan for ENUM, just need to understand how currently=20 assigned E.164 numbers move from current SPs to ENUM users. Mike > >I confess I have not been watching the ENUM list, but perhaps should > >join. My apologies if this has all been figured out. > >good idea > >Richard > >Mike > > >At 03:59 PM 3/30/2004 -0500, James McEachern wrote: > > >Mike, > >In your email you state: > > > >---snip--- > >The difference is in the interpretation of a lack of a record. In LNP,= it > >would mean that the E.164 number is still owned by the original switch, > >whereas in ENUM it would mean that the E.164 number is not route-able to > >an IP endpoint. From a TDM perspective, the entire IP domain could be > >viewed as a single switch and the LNP routing scheme should work. The > >converse (when records exist) could be true for ENUM. > > > > > >A gateway between IP-domain and TDM domain, upon seeing that both an LNP > >and an ENUM dip have not resolved the route, can safely conclude that the > >number is unassigned and release the call." > > > >---end snip--- > > > >This seems to suggest that routing to an IP endpoint would require an= ENUM > >entry - otherwise the gateway could safely assume the number is > >unassigned. Do you really mean this? What would this do to opt-in? > > > >Thanks > >Jim > > > >-----Original Message----- > >From: Stastny Richard > >[mailto:Richard.Stastny@oefeg.at] > >Sent: Monday, March 29, 2004 10:30 AM > >To: Michael Hammer > >Cc: iptel@ietf.org; sipping@ietf.org; enum@ietf.org > >Subject: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion > > > >Hi Michael, > > > >We are trying to find a solution for the following scenarios: > >A. An E.164 number range is only available and routable in ENUM > >B. An E.164 number range is available via PSTN and via IP > >C. An E.164 number range is not assigned at the PSTN > > > >If in cases A and B an entry is existing in ENUM, no problem. > >If the query returns NXDOMAIN, the problem arises for the > >querying server how to proceed. > > > >In case A the server must not forward the call to the PSTN, because > >a loop may be created. In cases B and C it may forward the call (no harm) > >but it is not necessary. In case B the server could terminate the call=20 > on IP, > >in case C the server could say number not available and not bother the > >PSTN at all. > > > >If we find a solution that covers A, B and C may be covered as well. > > > >I agree that in future call routing may be improved further in access > >to LNP servers on the PSTN is available and also if access to ENUM > >is available on the PSTN (some carriers are already working on this), > >but this will take some time. > > > >We should also come up with a sself-containing solution on IP and > >not always rely on the PSTN. > > > >regards > >Richard > > > > -----Urspr=C3=83=C2=BCngliche Nachricht----- > > Von: Michael Hammer > > [mailto:mhammer@cisco.com] > > Gesendet: Fr 26.03.2004 17:40 > > An: Stastny Richard > > Cc: iptel@ietf.org; sipping@ietf.org > > Betreff: Re: [Iptel] FW: [Enum] Summary on NoPSTN dicussion > > > > > > > > Richard, > > > > Going out on a limb here, since I have not seen all the= referenced > > discussions. My first impression is that the description below > > is overlay > > complex. > > > > I have a concern that you appear to be proposing that the ENUM > > dip would > > have definitive answers to: > > a) whether a number has been assigned and therefore rout-able, > > b) whether a number that is assigned was done, and if so whether > > to a PSTN > > endpoint or an IP endpoint. > > > > Another concern is that, if you do get looped routing between= the > > IP domain > > and the TDM domain, this is likely an indication of a lack of > > synchronization between the ENUM database and the LNP > > database. One or the > > other has incorrect data. I suspect that there may be time lags > > from when > > an SP assigns a number and when it gets reflected in one or= another > > databases. If you want the ENUM and LNP databases to be= somewhat > > independent, you might want a loose coupling of the use of the > > two systems: > > > > -If endpoint is TDM, then the ENUM database should point to= the > > PSTN, > > with default behavior being, if unknown to ENUM, send to PSTN to > > resolve. (Note this is orthogonal to ENUMs use to select > > alternative > > endpoints.) > > > > - If endpoint is IP, then the LNP databases should point to=20 > the IP > > domain, with default behavior being, if unknown to LNP, route in > > the PSTN > > to resolve. > > > > The difference is in the interpretation of a lack of a > > record. In LNP, it > > would mean that the E.164 number is still owned by the original > > switch, > > whereas in ENUM it would mean that the E.164 number is not > > route-able to an > > IP endpoint. From a TDM perspective, the entire IP domain could > > be viewed > > as a single switch and the LNP routing scheme should work. The > > converse > > (when records exist) could be true for ENUM. > > > > A gateway between IP-domain and TDM domain, upon seeing that= both > > an LNP > > and an ENUM dip have not resolved the route, can safely conclude > > that the > > number is unassigned and release the call. > > > > Actually, it may not be necessary to send a setup message to a > > GW, nor is > > it necessary to have the ENUM and LNP databases duplicate each > > other. It > > should be sufficient for an ENUM DB to query the LNP DB and > > respond with an > > appropriate answer, or the converse. > > > > Mike > > > > > > At 04:22 PM 3/25/2004 +0100, Stastny Richard wrote: > > >Cross posting from enum@ietf.org > > >The discussion is going on the enum-list > > > > > >Richard Stastny > > >OeFEG > > >+43 664 420 4100 > > > > > > > > >-----Original Message----- > > >From: Stastny Richard > > >Sent: Thursday, March 25, 2004 1:08 PM > > >To: Marian Durkovic; lwc@roke.co.uk > > >Cc: enum@ietf.org > > >Subject: [Enum] Summary on NoPSTN dicussion > > > > > >Dear colleagues, > > > > > >There was a lot of discussions on-list and off-list on this= issue, > > >so I will try to summarize at least my view of the problem. > > >I will also include my current view on the ;enumdi > > >and the ;pstn indicator for the tel: URI > > > > > >ENUM-enabled UAs and Servers are currently processing > > >received E.164 numbers (either in a tel:+xxx URI or in a sip:= URI > > >in the format sip:+xxxx@proc.net;user=3Dphone) in the following= way: > > >(for simplicity I am only dealing with voice calls) > > >Please holler if I got something wrong or you disagree > > > > > >1. Query ENUM (in e164.arpa) > > > > > >2. if a NAPTR is found with an "enumservice" sip or voice:sip, > > >handle the call as if you have received a sip: URI in the= format > > >sip:user@prov.net in the first place. > > > > > >3. If a NAPTR is found with an "enumservice" voice:tel > > >3a. and the tel: URI is pointing to a different number, > > >query ENUM again for this number > > >3b. if the tel: URI is the same as the AUS, forward the > > >call to the PSTN, if you are able to do so. > > > > > >Note: here the proposed ;pstn indicator may come in handy: > > >In 3a you may use it in the NAPTR to prevent a second= ENUM-query > > >and force the call to the PSTN. > > >In 3b the server may add ;pstn to inform the next proxy about > > >The decision to force the call to the PSTN. On the other hand, > > >In this case also the ;enumdi indicator may be used just to=20 > prevent > > >an ENUM query. Result: ;pstn is used in ENUM - ;enumdi is used= in > > >signalling. > > > > > >4. Now the real problem starts: If the ENUM-query returns=20 > NXDOMAIN, > > >the current assumption of all clients is: the call is routed=20 > to the > > >PSTN if the server is able to do so (eventually with the= ;enumdi > > set. > > > > > >This means, we refer the problem to the PSTN. This is not nice= for > > >various reasons: > > >1. we are bothering the PSTN in some cases unnecessarily > > >2. the PSTN may not know what to do either and bounce the > > >call back, which is creating loops > > >3. and finally: what are we doing if there is no PSTN anymore= ;-) > > >Ok, this seems far reached, but Internet Telephony should be > > finally > > >self-containing. > > > > > >So what are the additional policies we may want to tell an= ENUM- > > >client? > > > > > >1. No such number (unassigned number) > > >1a. The whole number range (number block)is unassigned > > >1b. There are numbers assigned in this number range, but if you > > >do not find one in ENUM, you also will not find one on the=20 > PSTN, so > > >it makes no sense to route it to the PSTN (ENUM-only) > > >2. Default routing for the whole number range (number block) to > > a VoIP > > >gateway. > > >2a. The whole block is routed, there are no individual entries > > in ENUM > > >(e.g. 1-800 numbers) > > >2b. There are numbers in ENUM, but if you do not find an entry, > > route > > >the call to the default gateway given. One example for this= case > > may be > > >a VoIP provider operating an island only connected to the PSTN. > > Some > > >of the users are also in ENUM (opt-in). If he provider now= opens > > up access > > >to the Internet via a gateway (border element, ...), he may= want > > to route > > >all calls for his users not in ENUM to the gateway provided by > > default > > > > > >Case 1a and 2a can be dealt with in e164.arpa with wildcards, > > because no > > >Additional entries below exist. > > >Case 1b and 2b cannot be dealt within e164.arpa, because > > wildcards do > > >not support this. > > > > > >The solutions proposed for this sofar are. > > > > > >A. use tables in each server. This is not a good idea and does > > not help > > >ENUM-enable UA. The information should be stored in a global > > accessible > > >and public database (DNS). > > > > > >B. use a (one, common) second common tree (e164shadow.arpa, > > where you put > > >in only the wildcards for the number ranges in question. The > > processing > > >assumption now should be: > > > > > >If the ENUM-query returns NXDOMAIN, the call is not routed to > > the PSTN > > >In any case, the server queries e164shadow.arpa, and only if no > > entry > > >is found there, the call is routed to the PSTN. The management= and > > >delegation procedures of the tree are the same as for= e164.arpa. > > >The second tree would contain only wildcard NAPTR RR for number > > ranges > > > > > >This would be the optimal solution proposed sofar. The problem > > is that > > >a common agreement and a definition on the second tree is > > necessary. > > > > > >C. Use individual second shadow trees, eg on a national level, > > eg in > > >Austria e164shadow.at would be used. The problem here is how= one > > can > > >find out the domain names of the individual trees. > > >One solution is to do it with a table in each server (which is > > not good). > > > > > >The other solution is to put pointers in e164.arpa, eg SRV RR= or > > even MX RR. > > >The MX record would give eg the root of the other tree, and= each > > tree > > >would be structured in the sane way like e164.arpa, so the same > > algorithms > > >can be used. > > > > > >Since the structure of the delegations in e164.arpa varies= (Tier > > 1 levels), > > >there is no easy way to find out the level of the pointers,= even > > if they are > > >only on the Tier 1 layer. > > > > > >It was proposed to search either top down (faster) or bottom up > > (more > > >flexible), because this would allow sub-policies in number= ranges. > > > > > >D. Are there additional possibilities or proposals? > > > > > >Finally I come to the last issue: > > > > > >For case 1a and 1b above (no such number) an "enumservice" is > > necessary > > >to indicate that there exists no such number, neither in ENUM > > nor on the > > >PSTN. > > > > > >Proposals sofar are: > > > > > >Use a special flag e.g. "n" or "v" > > >Use a "enumservice" e.g. "E2U+NONE" or "E2U+VOID" or only= "VOID" > > > > > >Also here additional proposals are invited. > > > > > >Best regards > > > > > >Richard > > > > > > > > > > > > > > >_______________________________________________ > > >enum mailing list > > >enum@ietf.org > > >=20 > > >https://www1.ietf.org/mai= =20 >lman/listinfo/enum > > > > > > > >_______________________________________________ > > >Iptel mailing list > > >Iptel@ietf.org > > >=20 > > >https://www.ietf.org/mail= =20 >man/listinfo/iptel > > > > > > > > > >z{x%^=C3=A1=C2=A6=C5=BEzrm=C3=A1=C2=A8=C2=B6? > >0u'~ffX)n > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum