From exim@www1.ietf.org Thu Apr 1 00:24:56 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 AAA05054 for ; Thu, 1 Apr 2004 00:24:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ugo-0006XF-80 for enum-archive@odin.ietf.org; Thu, 01 Apr 2004 00:24:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i315OUkX025055 for enum-archive@odin.ietf.org; Thu, 1 Apr 2004 00:24:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ugV-0006En-Ra; Thu, 01 Apr 2004 00:24:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8uKr-0004rb-MS for enum@optimus.ietf.org; Thu, 01 Apr 2004 00:01:49 -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 AAA03917 for ; Thu, 1 Apr 2004 00:01:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8uKp-0007Wj-00 for enum@ietf.org; Thu, 01 Apr 2004 00:01:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8uJq-0007US-00 for enum@ietf.org; Thu, 01 Apr 2004 00:00:47 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B8uJA-0007OW-00 for enum@ietf.org; Thu, 01 Apr 2004 00:00:04 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 31 Mar 2004 21:08:59 +0000 X-BrightmailFiltered: true 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 i314wxsk002460 for ; Thu, 1 Apr 2004 06:58:59 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 1 Apr 2004 06:57:39 +0200 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 07:00:44 +0200 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <6.0.3.0.2.20040318115616.03bdd978@joy.songbird.com> References: <6.0.3.0.2.20040318115616.03bdd978@joy.songbird.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5B8E4702-8399-11D8-B323-000A95B2B926@cisco.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 1 Apr 2004 06:59:29 +0200 To: IETF ENUM list X-Mailer: Apple Mail (2.613) X-OriginalArrivalTime: 01 Apr 2004 05:00:44.0607 (UTC) FILETIME=[49F5C4F0:01C417A6] 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 Subject: [Enum] Action items from -- 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: , Content-Transfer-Encoding: 7bit On Mar 19, 2004, at 21:28, Richard Shockey wrote: > - 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 Do we have any status on the updated "Conroy Draft"? paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Apr 1 00:37: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 AAA05521 for ; Thu, 1 Apr 2004 00:37: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 1B8usx-0007Qy-7h for enum-archive@odin.ietf.org; Thu, 01 Apr 2004 00:37:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i315b3qh028550 for enum-archive@odin.ietf.org; Thu, 1 Apr 2004 00:37:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8usu-0007PU-TX; Thu, 01 Apr 2004 00: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 1B8uso-0007Oi-Gw for enum@optimus.ietf.org; Thu, 01 Apr 2004 00:36: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 AAA05518 for ; Thu, 1 Apr 2004 00:36:50 -0500 (EST) From: fujiwara@jprs.co.jp Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8usl-0001oU-00 for enum@ietf.org; Thu, 01 Apr 2004 00:36:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8urq-0001lw-00 for enum@ietf.org; Thu, 01 Apr 2004 00:35:55 -0500 Received: from sender2.jprs.co.jp ([61.120.151.69]) by ietf-mx with esmtp (Exim 4.12) id 1B8urd-0001gz-00 for enum@ietf.org; Thu, 01 Apr 2004 00:35:41 -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 i31576L31308; Thu, 1 Apr 2004 14:07:07 +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 i315Y2323711; Thu, 1 Apr 2004 14:34:02 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by unix01.jprs.co.jp (8.11.6/8.11.6) with ESMTP id i315Y1s28421; Thu, 1 Apr 2004 14:34:01 +0900 Date: Thu, 01 Apr 2004 14:34:01 +0900 (JST) Message-Id: <20040401.143401.74728159.fujiwara@jprs.co.jp> To: paf@cisco.com Cc: enum@ietf.org Subject: Re: [Enum] Action items from -- Minutes of ENUM WG IETF 59 In-Reply-To: <5B8E4702-8399-11D8-B323-000A95B2B926@cisco.com> References: <6.0.3.0.2.20040318115616.03bdd978@joy.songbird.com> <5B8E4702-8399-11D8-B323-000A95B2B926@cisco.com> X-Mailer: Mew version 4.0.64 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 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.3 required=5.0 tests=NO_REAL_NAME 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 > From: Patrik F=E4ltstr=F6m > > - 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. H= ow = > > 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 > = > Do we have any status on the updated "Conroy Draft"? Sorry, I didn't work it. I will rewrite my issues as a part of "Conroy Draft" next week. -- Fujiwara, Kazunori JPRS _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Apr 1 02:38: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 CAA23315 for ; Thu, 1 Apr 2004 02:38: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 1B8wm9-0000ol-Jh for enum-archive@odin.ietf.org; Thu, 01 Apr 2004 02:38:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i317c95l003141 for enum-archive@odin.ietf.org; Thu, 1 Apr 2004 02:38:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8wm2-0000mV-0l; Thu, 01 Apr 2004 02: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 1B8wlx-0000lG-IF for enum@optimus.ietf.org; Thu, 01 Apr 2004 02:37: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 CAA23253 for ; Thu, 1 Apr 2004 02:37:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8wlt-0003ie-00 for enum@ietf.org; Thu, 01 Apr 2004 02:37:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8wkx-0003eF-00 for enum@ietf.org; Thu, 01 Apr 2004 02:36:56 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B8wkM-0003Wr-00 for enum@ietf.org; Thu, 01 Apr 2004 02:36:18 -0500 Content-Class: urn:content-classes:message Subject: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 1 Apr 2004 09:35:44 +0200 Message-ID: <06CF906FE3998C4E944213062009F162233C92@oefeg-s02.oefeg.loc> x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQXXXtu22xhWhiAQ1OVZFYOT0PcHwAWLJbw From: "Stastny Richard" To: "Michael Hammer" Cc: "James McEachern" , 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 TWlrZSB3cm90ZToNCg0KCT4+Rmlyc3QsIG5vIG51bWJlciBpcyBvd25lciBieSBhbnlib2R5LCBp dCBpcyBhc3NpZ25lZCBieSBJVFUtVCB0byB0aGUgTlJBLA0KCT4+YW5kIGFzc2lnbmVkIGluIHR1 cm4gdG8gdGhlIFNQLCBhbmQgdGhlIFNQIGFzc2lnbmVzIGl0IHRvIHRoZSBlbmQtdXNlciAoZm9y DQoJPj5nZW9ncmFwaGljIG51bWJlcnMuIFNlcnZpY2UgbnVtYmVycyBhcmUgYWxyZWFkeSBhc3Np Z25lZCBvbmUtYnktb25lDQoJPj50byB0aGUgZW5kLXVzZXIgYnkgdGhlIE5SQSwgbm8gYmxvY2tz LCBubyBhbmNob3IgU1AuDQoJDQoJPkhvdyBkb2VzIHRoaXMgd29yayBmb3IgbnVtYmVycyB0aGF0 IHdlcmUgYXNzaWduZWQgdG8gYW4gU1AsIHRoYXQgdXNlZCB0byBiZQ0KCT5URE0tb25seSwgYnV0 IHRoZW4gKG92ZXIgdGltZSkgY29udmVydHMgdG8gYW4gSVAtb25seSBuZXR3b3JrPyAgVGhlIFNQ cyBhcmUNCgk+dmVyeSBndWFyZGVkIGFib3V0IHRoZSBFLjE2NCBudW1iZXJzIGFzc2lnbmVkIHRv IHRoZW0uICBUaGF0IGlzIHdoYXQgSQ0KCT5tZWFudCBieSAib3duZWQuIiAgWW91IGFyZSBzdWdn ZXN0aW5nIHRoYXQgd2hlbiBhIHBlcnNvbiB3aXRoIGEgcGhvbmUNCgk+bnVtYmVyIGFzc2lnbmVk IGJ5IGFuIFNQIG1vdmVzIHRvIGFuIElQLWJhc2VkICJwaG9uZSIgdGhhdCB0aGUgU1Agd2lsbA0K CT5yZWxpbnF1aXNoIHRoYXQgcGhvbmUgbnVtYmVyIGJhY2sgdG8gdGhlIE5SQT8gIE9yIGFyZSB5 b3Ugc2F5aW5nIHRoYXQNCgk+bnVtYmVyIHBvcnRhYmlsaXR5IGRvZXNuJ3Qgd29yayBiZXR3ZWVu IFRETSBhbmQgSVAgd29ybGRzPw0KCSANCglXZSBhcmUgdGFsa2luZyBoZXJlIGFib3V0IGZvdXIg ZGlmZmVyZW50IHRoaW5ncyBoZXJlOg0KCUNhc2UgMTogIGEgVm9JUCBwcm92aWRlciBpcyBhbHNv IGFuIElMRUMgKGVnIGEgY2FibGUgb3BlcmF0b3IpIGFuZCBnZXRzIGEgDQoJbnVtYmVyIChnZW9n cmFwaGljKSByYW5nZSAoYmxvY2spIGFzc2lnbmVkIGFuZCBhc3NpZ25lcyB0aGVtIHRvIGhpcyB1 c2Vycy4NCglTaW5jZSBudW1iZXIgYXNzaWduZW1lbnQgaXMgdGVjaG5vbG9neSBpbmRlcGVuZGVu dCwgdGhlcmUgaXMgbm8gcHJvYmxlbSBoZXJlLA0KCWFzIGxvbmcgYXMgdGhlIFNQIGlzIHByb3Zp ZGluZyBhIHRlbGVwaG9ueSBzZXJ2aWNlIGFzIHVzdWFsICh3ZSBjYWxsIHRoaXMgUEFUUyAtDQoJ UHVibGljbHkgQXZhaWxhYmxlIFRlbGVwaG9ueSBTZXJ2aWNlIGluIEV1cm9wZSkuDQoJTm90ZTog c29tZSBWb0lQIFNQIGhpZGUgYmV0d2VlbiBzbWFsbCBJTEVDcyBhbmQgZ2V0IHN1Y2ggbnVtYmVy IHJhbmdlcw0KCXZpYSB0aGVtIChlLmcgVm9uYWdlLCBzaXBnYXRlLmRlLCAuLi4pDQoJIA0KCUNh c2UgMjogU2luY2UgYWxsIG5vcm1hbCBydWxlcyBhcHBseSwgYWxzbyBMTlAgYXBwbGllcywgc28g dXNlcnMgbWF5IHBvcnQNCgl0aGVpciBudW1iZXJzIGJhY2sgYW5kIGZvcnRoIGJldHdlZW4gUFNU TiBhbmQgVm9JUCBTUA0KCSANCglDYXNlIDM6IFRoZSByZWd1bGF0b3IgcmVzZXJ2ZXMgYSBzcGVj aWFsIG51bWJlciByYW5nZSBmb3IgVm9JUCAoMDUwIGluDQoJSmFwYW4sIDA1eCBpbiBVSywgMDMy IGluIEdlcm1hbnkpLiBJZiB0aGVzZSBzZXJ2aWNlcyBhcmUgZGVjbGFyZWQgbm9uLVBBVFMNCglO UCBkb2VzIG5vdCBhcHBseSAodGhpcyBpcyB1bmRlciBkaXNjdXNzaW9uKS4gSW4gSmFwYW4gdGhl cmUgaXMgYWxzbyBhIGxpZ2h0ZXIgDQoJcmVnaW1lIHJlZ2FyZGluZyBRb1MuIFJlZ3VsYXRpb25z IGRpZmZlciBoZXJlIGluIGFsbCBjb3VudHJpZXMuIA0KCUluIHRoaXMgY2FzZSB0aGUgVm9JUCBT UCBhbHNvIGdldCBibG9ja3Mgb2YgbnVtYmVycyBhbmQgcm91dGUgdGhlbSB0byB0aGVpciBHVy4g DQoJSSBrbm93LCBpbiB0aGUgVVMgdGhlcmUgaXMgbm8gc3VjaCBudW1iZXIgcmFuZ2UuIFRoZSBw cm9ibGVtIEkgaGF2ZSB3aXRoDQoJc3VjaCBhbiBhcHByb2FjaCBpcyB0aGF0IHRoZXJlIGFyZSBk aWZmZXJudCBydWxlcyBpbiBldmVyeSBjb3VudHJ5IGFuZCBlbmQtdXNlcnMNCglnZXQgcmVzdHJp Y3RlZCBzZXJ2aWNlcy4gKGUuZyBubyBOUCwgbm8gYWNjZXNzIHRvIGVtZXJnZW5jZSBzZXJ2aWNl cywgZXRjLg0KCUlNSE8gdGhpcyB3aWxsIGNhdXNlIHByb2JsZW1zIGluIHRoZSBmdXR1cmUNCgkg DQoJQ2FzZSA0LiB0aGUgcmVndWxhdG9yIHJlc2VydmVzIGEgc3BlY2lhbCBudW1iZXIgcmFuZ2Ug Zm9yIEVOVU0tb25seSByb3V0ZWQgDQoJbnVtYmVycy4gVGhpcyBzaG91bGQgYmUgZG9uZSBkaXJl Y3RseSB0byB0aGUgZW5kLXVzZXIuIFRoZSBhZHZhbnRhZ2UgaXMNCgl0aGF0IHlvdSBoYXZlIE5Q IGJ1aWx0LWluLCB3aXRob3V0IGhhdmluZyB0byBkZWFsIHdpdGggbm9ybWFsIExOUCBpc3N1ZXMg YW5kDQoJdGVjaG5vbG9neSwgc2F2aW5nIHRoZSBTUCBtdWNoIGVmZm9ydC4NCgkgDQoJVGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiBjYXNlIDMgYW5kIDQgaXMgdGhhdCBpbiBjYXNlIDMgbm8gcnVsZXMg ZXhpc3QgZm9yIE5QIGFuZA0KCWludGVyY29ubmVjdCBvbiBJUCwgc28geW91IGNyZWF0ZSBWb0lQ IElzbGFuZCB0aGF0IGFyZSBpbnRlcmNvbm5lY3RlZCBvbmx5IHZpYQ0KCXRoZSBQU1ROIHBlciBk ZWZhdWx0LiBJZiB5b3UgaW50ZXJjb25uZWN0IG9uIElQLCB5b3UgY2FuIGRvIHRoaXMgb25seSBj dXJyZW50bHkNCgl3aXRoIGJpbGF0ZXJhbCBhZ3JlZW1lbnRzLiBJbiBjYXNlIDQgeW91IGhhdmUg YXV0b21hdGljYWxseSBOUCBhbmQgYWxzbyBpbnRlcmNvbm5lY3QNCgliZWNhdXNlIHlvdSBjYW4g dXNlIEVOVU0gYWxzbyBvbiBJUCB0byBpbnRlcmNvbm5lY3QuIFRoaXMgaXMgQlRXIGFsc28gZHJh ZnRlZA0KCWluIHRoZSBTSVAgRm9ydW0gU2VydmljZSBQcm92aWRlciBXRyBJbnRlcmNvbm5lY3Qg Q29uc2Vuc3VzLg0KDQoJPj5XaXRoIEVOVU0tb25seSBudW1iZXJzIHRoZXJlIGlzIG5vIG5lZWQg dG8gYXNzaWduIGJsb2NrcyBvZiBudW1iZXJzLg0KCT4+QW4gRU5VTS1vbmx5IG51bWJlciBpcyB0 aGUgZXF1aXZhbGVudCBvZiBhIGRvbWFpbiBuYW1lLiBJdCBpcyBhc3NpZ25lZA0KCT4+dG8gdGhl IGVuZC11c2VyIGRpcmVjdGx5LCB3aG8gY2hvb3NlcyB0aGUgU1AsIGxpa2Ugd2l0aCBhIHNlcnZp Y2UgbnVtYmVyLg0KCT4+WW91IGFsc28gZG8gbm90IGFzc2lnbiBkb21haW4gbmFtZXMgaW4gYmxv Y2tzLg0KCQ0KCT5JIHRoaW5rIHRoZXJlIGlzIGFuIGlzc3VlIGhlcmUuICBJZiB0aGUgU1BzIGhv bGQgbW9zdCBvZiB0aGUgY3VycmVudCBOUEENCgk+YmxvY2tzLCBhbmQgdGhlcmUgaXMgYSBtaWdy YXRpb24gb2YgbWFueSB1c2VycyBmcm9tIFRETSB0byBJUCwgdGhlbiBkbyB5b3UNCgk+bGVuZ3Ro ZW4gdGhlIG51bWJlciB0byAxMSBkaWdpdHMgdG8gZ2V0IG1vcmUsIG9yIGRvIHRoZSBTUHMgaGF2 ZSB0bw0KCT5yZWxpbnF1aXNoIG51bWJlcnM/DQoNCglUaGlzIGEgdHlwaWNhbCBOQU5QIHByb2Js ZW0uIEluIHRoZSBOQU5QIHRoZXJlIGlzIG9ubHkgZ2VvZ3JhcGhpYyBhcmVhDQoJY29kZXMgKHdp dGggdGhlIGV4Y2VwdGlvbiBvZiA4MDAgbnVtYmVycykuIEluIG1vc3Qgb3RoZXIgY291bnRyeSB0 aGVyZSBhcmUNCgltb3JlIG51bWJlciB0eXBlczogeW91IGhhdmUgZ2VvZ3JhcGhpYyBhbmQgbm9u LWdlb2dyYXBoaWMgbnVtYmVycy4NCg0KCU5vbi1nZW8gbnVtYmVycyBhcmUgZWcgbW9iaWxlIG51 bWJlcnMsIHBlcnNvbmFsIG51bWJlcnMsIGV0Yy4gVGhlIGFkdmFudGFnZQ0KCWhlcmUgaXMgdGhh dCB5b3UgcmVsaWV2ZSB0aGUgcHJlc3N1cmUgb24gdGhlIG51bWJlciBleGhhdXN0IGhlcmUuIFNp bmNlIGdlbw0KCW51bWJlcnMgYXJlIGdpdmVuIGF3YXkgaW4gYmxvY2tzLCB5b3UgaGF2ZSBhIGxv dCBvZiB1bnVzZWQgbnVtYmVycy4NCglFZyBpbiBBdXN0cmlhIHRoZSBnZW8gbnVtYmVycyBhcmUg dXNpbmcgdXAgYSBncmVhdCBjaHVuayBvZiB0aGUgbnVtYmVyczoNCgl3ZSBoYXZlIDExMDAgNC1k aWdpdCBhcmVhIGNvZGVzIHVzZWQgYmUgYXBwb3ggNCBNaW8gc3Vic2NyaWJlcnMsDQoJb24gdGhl IG90aGVyIGhhbmQsIHdlIGhhdmUgNSAoZml2ZSkgMy1kaWdpdCBtb2JpbGUgbnVtYmVyIHJhbmdl cw0KCXVzZWQgYnkgNCw1IE1pbyBzdWJzY3JpYmVycyAoODAlIG9mIHRoZW0gYXJlIGJlaGluZCAy IG1vYmlsZSAiYXJlYSIgY29kZXMpLg0KDQoJVGhlIHJlYXNvbiBpcyBzaW1wbGU6IHRoZSBtb2Jp bGUgbnVtYmVyIHJhbmdlcyBhcmUgZmxhdC4gU28gaWYgd2UgZ2l2ZSBlZw0KCW9uZSAzLWRpZ2l0 IG51bWJlciByYW5nZSB0byBFTlVNLCB3ZSBjYW4gaW5zdGFudGx5IHVzZSB0aGVtIHdpdGgNCglh ZGRpdGlvbmFsIDctZGlnaXRzIGZvciA5Ljk5OS45OTkgc3Vic2NyaWJlcnMuIA0KCQ0KCXJlZ2Fy ZHMNCg0KCVJpY2hhcmQNCg0K _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Apr 1 06:06:37 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 GAA06130 for ; Thu, 1 Apr 2004 06:06: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 1B901S-0007fs-Vm for enum-archive@odin.ietf.org; Thu, 01 Apr 2004 06:06:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31B6ATK029500 for enum-archive@odin.ietf.org; Thu, 1 Apr 2004 06:06:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B901I-0007f3-Vq; Thu, 01 Apr 2004 06:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B900R-0007e7-Us for enum@optimus.ietf.org; Thu, 01 Apr 2004 06:05:07 -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 GAA06098 for ; Thu, 1 Apr 2004 06:05:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B900O-0004O8-00 for enum@ietf.org; Thu, 01 Apr 2004 06:05:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8zzW-0004K4-00 for enum@ietf.org; Thu, 01 Apr 2004 06:04:11 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1B8zyr-0004DJ-00 for enum@ietf.org; Thu, 01 Apr 2004 06:03:29 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMV3GM>; Thu, 1 Apr 2004 12:02:58 +0100 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 H5DV85R4; Thu, 1 Apr 2004 12:02:53 +0100 From: "Conroy, Lawrence (SMTP)" To: fujiwara@jprs.co.jp Cc: paf@cisco.com, enum@ietf.org In-Reply-To: <20040401.143401.74728159.fujiwara@jprs.co.jp> References: <6.0.3.0.2.20040318115616.03bdd978@joy.songbird.com> <5B8E4702-8399-11D8-B323-000A95B2B926@cisco.com> <20040401.143401.74728159.fujiwara@jprs.co.jp> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <1E1A45FB-83CC-11D8-9AE5-00039355516C@roke.co.uk> Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Action items from -- Minutes of ENUM WG IETF 59 Date: Thu, 1 Apr 2004 12:02:50 +0100 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: 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 Patrik, Fujiwara-san, folks, Mea Culpa. I also haven't had a chance to look at this document - = day=20 job kept me busy. If Fujiwara-san could send me his text then I will work on a combined=20 version over Easter and bounce it back to check I haven't broken it. Note that there is some discussion on the RIPE trials list that may add = an item to the draft; if no one else does beforehand, I'll summarise the issue for=20 this list over the weekend. Thus the plan is to get something for the WG in the next couple of=20 weeks. Is this OK? all the best, Lawrence On 1 Apr 2004, at 6:34 am, fujiwara@jprs.co.jp wrote: >> From: Patrik F=E4ltstr=F6m >>> - 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 >> >> Do we have any status on the updated "Conroy Draft"? > > Sorry, I didn't work it. > I will rewrite my issues as a part of "Conroy Draft" next week. > > -- > Fujiwara, Kazunori JPRS > > _______________________________________________ > 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 Thu Apr 1 06:25: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 GAA06617 for ; Thu, 1 Apr 2004 06:25: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 1B90Jj-0000qp-AO for enum-archive@odin.ietf.org; Thu, 01 Apr 2004 06:25:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31BP3IO003266 for enum-archive@odin.ietf.org; Thu, 1 Apr 2004 06:25:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90Jh-0000pz-8r; Thu, 01 Apr 2004 06:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90Ip-0000eV-AT for enum@optimus.ietf.org; Thu, 01 Apr 2004 06:24:07 -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 GAA06571 for ; Thu, 1 Apr 2004 06:24:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B90Il-0005wg-00 for enum@ietf.org; Thu, 01 Apr 2004 06:24:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B90Hp-0005sy-00 for enum@ietf.org; Thu, 01 Apr 2004 06:23:06 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1B90HV-0005oq-00 for enum@ietf.org; Thu, 01 Apr 2004 06:22:45 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <1ZGMV3N1>; Thu, 1 Apr 2004 12:22:08 +0100 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 H5DV8560; Thu, 1 Apr 2004 12:21:54 +0100 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed Date: Thu, 1 Apr 2004 12:21:53 +0100 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 Subject: [Enum] Is it just me? - Fwd: Returned mail: User unknown 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, Is it just me, or does everyone posting to the ENUM list get this message from AOL? Could the listmaster check the subscribed member addresses for bounces, please? all the best, Lawrence Begin forwarded message: > From: Mail Delivery Subsystem > Date: 1 April 2004 12:12:08 pm BST > To: "Conroy, Lawrence (SMTP)" > Subject: Returned mail: User unknown > > The original message was received at Thu, 1 Apr 2004 06:11:55 -0500 > (EST) > from siaab2ab.compuserve.com [149.174.40.130] > > > *** ATTENTION *** > > Your e-mail is being returned to you because there was a problem with > its > delivery. The address which was undeliverable is listed in the section > labeled: "----- The following addresses had permanent fatal errors > -----". > > The reason your mail is being returned to you is listed in the section > labeled: "----- Transcript of Session Follows -----". > > The line beginning with "<<<" describes the specific reason your > e-mail could > not be delivered. The next line contains a second error message which > is a > general translation for other e-mail servers. > > Please direct further questions regarding this message to your e-mail > administrator. > > --AOL Postmaster > > > > ----- The following addresses had permanent fatal errors ----- > > > ----- Transcript of session follows ----- > ... while talking to air-xg01.mail.aol.com.: >>>> RCPT To: > <<< 550 MAILBOX NOT FOUND > 550 ... User unknown > > Reporting-MTA: dns; rly-xg04.mx.aol.com > Arrival-Date: Thu, 1 Apr 2004 06:11:55 -0500 (EST) > > Final-Recipient: RFC822; rjhorrocks@cs.com > Action: failed > Status: 5.1.1 > Remote-MTA: DNS; air-xg01.mail.aol.com > Diagnostic-Code: SMTP; 550 MAILBOX NOT FOUND > Last-Attempt-Date: Thu, 1 Apr 2004 06:12:08 -0500 (EST) > Received: from siaab2ab.compuserve.com (siaab2ab.compuserve.com > [149.174.40.130]) by rly-xg04.mx.aol.com (v98.5) with ESMTP id > MAILRELAYINXG41-461406bf8fa83; Thu, 01 Apr 2004 06:11:54 -0500 > Received: (from mailgate@localhost) > by siaab2ab.compuserve.com (8.12.9/8.12.7/SUN-2.12) id i31BBr6g000891 > for rjhorrocks@cs.com; Thu, 1 Apr 2004 06:11:53 -0500 (EST) > Date: Thu, 1 Apr 2004 06:08:13 -0500 > From: "Conroy, Lawrence (SMTP)" > Subject: Re: [Enum] Action items from -- Minutes of ENUM WG IETF 59 > Sender: enum-admin@ietf.org > To: fujiwara@jprs.co.jp > Cc: enum@ietf.org, paf@cisco.com > Reply-To: "Conroy, Lawrence (SMTP)" > Message-ID: <200404010608_MC3-1-7ADC-723C@compuserve.com> > MIME-Version: 1.0 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=ISO-8859-1 > Content-Disposition: inline > X-AOL-IP: 149.174.40.130 > X-AOL-SCOLL-SCORE: 0:XXX:XX > X-AOL-SCOLL-URL_COUNT: 0 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Apr 1 06:26:28 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 GAA06661 for ; Thu, 1 Apr 2004 06:26:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90Kg-00012t-8Z for enum-archive@odin.ietf.org; Thu, 01 Apr 2004 06:26:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31BQ2ID003981 for enum-archive@odin.ietf.org; Thu, 1 Apr 2004 06:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90Kf-00011q-W0; Thu, 01 Apr 2004 06:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90Jn-0000rp-7g for enum@optimus.ietf.org; Thu, 01 Apr 2004 06:25:07 -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 GAA06611 for ; Thu, 1 Apr 2004 06:25:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B90Jj-000616-00 for enum@ietf.org; Thu, 01 Apr 2004 06:25:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B90Io-0005xC-00 for enum@ietf.org; Thu, 01 Apr 2004 06:24:06 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B90IS-0005t7-00 for enum@ietf.org; Thu, 01 Apr 2004 06:23:44 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2004 03:32:46 +0000 X-BrightmailFiltered: true 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 i31BKZsu025600; Thu, 1 Apr 2004 13:22:14 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 1 Apr 2004 13:17:15 +0200 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 13:17:24 +0200 In-Reply-To: <1E1A45FB-83CC-11D8-9AE5-00039355516C@roke.co.uk> References: <6.0.3.0.2.20040318115616.03bdd978@joy.songbird.com> <5B8E4702-8399-11D8-B323-000A95B2B926@cisco.com> <20040401.143401.74728159.fujiwara@jprs.co.jp> <1E1A45FB-83CC-11D8-9AE5-00039355516C@roke.co.uk> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1F9D036D-83CE-11D8-B323-000A95B2B926@cisco.com> Content-Transfer-Encoding: 7bit Cc: fujiwara@jprs.co.jp, enum@ietf.org From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] Action items from -- Minutes of ENUM WG IETF 59 Date: Thu, 1 Apr 2004 13:17:12 +0200 To: "Conroy, Lawrence (SMTP)" X-Mailer: Apple Mail (2.613) X-OriginalArrivalTime: 01 Apr 2004 11:17:24.0435 (UTC) FILETIME=[E881DA30:01C417DA] 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 Apr 1, 2004, at 13:02, Conroy, Lawrence (SMTP) wrote: > Thus the plan is to get something for the WG in the next couple of > weeks. Is this OK? Absolutely! I have myself vacation for at least one week starting upcoming Saturday, so I will not have time doing anything for two weeks anyway. But, I felt (before I go on vacation) I should ping you folks. This so we will be at least faster than RFC-Editor+IANA.... paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Apr 1 06:31:28 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 GAA06840 for ; Thu, 1 Apr 2004 06:31:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90PW-0001Qo-7m for enum-archive@odin.ietf.org; Thu, 01 Apr 2004 06:31:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31BV2PH005472 for enum-archive@odin.ietf.org; Thu, 1 Apr 2004 06:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90PU-0001Pa-Fs; Thu, 01 Apr 2004 06:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90Ob-0001IC-Qz for enum@optimus.ietf.org; Thu, 01 Apr 2004 06:30: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 GAA06801 for ; Thu, 1 Apr 2004 06:30:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B90OX-0006UT-00 for enum@ietf.org; Thu, 01 Apr 2004 06:30:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B90Nf-0006Qm-00 for enum@ietf.org; Thu, 01 Apr 2004 06:29:08 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1B90N1-0006IJ-00 for enum@ietf.org; Thu, 01 Apr 2004 06:28:27 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 304404EFAE; Thu, 1 Apr 2004 13:27:58 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id C1F4B4E639; Thu, 1 Apr 2004 13:27:57 +0200 (CEST) Received: (from carsten@localhost) by birch.ripe.net (8.12.10/8.11.6) id i31BRt64008375; Thu, 1 Apr 2004 13:27:55 +0200 From: Carsten Schiefner Message-Id: <200404011127.i31BRt64008375@birch.ripe.net> Subject: Re: [Enum] Is it just me? - Fwd: Returned mail: User unknown To: lwc@roke.co.uk ("Conroy, Lawrence (SMTP)") Date: Thu, 1 Apr 2004 13:27:55 +0200 (CEST) Cc: enum@ietf.org In-Reply-To: from "Conroy, Lawrence (SMTP)" at Apr 01, 2004 12:21:53 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000146 / 0.0 / 0.0 / disabled X-RIPE-Signature: 063807c36764eb6b8635780ee0c272f7 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 Same here. Cheers, -C. "Conroy, Lawrence (SMTP)" wrote: > Hi Folks, > Is it just me, or does everyone posting to the ENUM list get this > message from AOL? > Could the listmaster check the subscribed member addresses for bounces, > please? > > all the best, > Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Apr 1 21:14:18 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 VAA23599 for ; Thu, 1 Apr 2004 21:14:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9CoL-0004Tr-LJ for enum-archive@odin.ietf.org; Thu, 01 Apr 2004 19:45:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i320jTZ3017173 for enum-archive@odin.ietf.org; Thu, 1 Apr 2004 19:45:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9AAd-0007XL-67; Thu, 01 Apr 2004 16:56:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B96qk-0002Jc-5F for enum@optimus.ietf.org; Thu, 01 Apr 2004 13:23: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 NAA24790 for ; Thu, 1 Apr 2004 13:23:19 -0500 (EST) From: jon.peterson@neustar.biz Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B96qY-0001xc-00 for enum@ietf.org; Thu, 01 Apr 2004 13:23:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B96pg-0001qV-00 for enum@ietf.org; Thu, 01 Apr 2004 13:22:29 -0500 Received: from nat-b.acn.pl ([212.76.39.249] helo=komputer.com) by ietf-mx with smtp (Exim 4.12) id 1B96oh-0001jR-00 for enum@ietf.org; Thu, 01 Apr 2004 13:21:28 -0500 Date: Thu, 01 Apr 2004 20:21:18 +0100 To: enum@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------kqgoyevanjoclyxnegrs" 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=HTML_20_30,HTML_MESSAGE, MIME_HTML_ONLY,NO_REAL_NAME autolearn=no version=2.60 Subject: [Enum] Encrypted document 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: , ----------kqgoyevanjoclyxnegrs Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit More info in attach


----------kqgoyevanjoclyxnegrs Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: Attach.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ----------kqgoyevanjoclyxnegrs-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Apr 1 23:22: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 XAA01474 for ; Thu, 1 Apr 2004 23:22: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 1B9DD0-0006AL-Pr for enum-archive@odin.ietf.org; Thu, 01 Apr 2004 20:10:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i321AwTm023698 for enum-archive@odin.ietf.org; Thu, 1 Apr 2004 20:10:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ABM-0007a0-MR; Thu, 01 Apr 2004 16:57:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95kr-0001cg-7o for enum@optimus.ietf.org; Thu, 01 Apr 2004 12:13:25 -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 MAA22374 for ; Thu, 1 Apr 2004 12:13:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B95kf-0002Kk-00 for enum@ietf.org; Thu, 01 Apr 2004 12:13:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B95jp-0002Fx-00 for enum@ietf.org; Thu, 01 Apr 2004 12:12:22 -0500 Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1B95jA-00027y-00 for enum@ietf.org; Thu, 01 Apr 2004 12:11:41 -0500 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i31H8po5008227 for ; Thu, 1 Apr 2004 12:11:10 -0500 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.032) id 404B562A0068DA4D; Thu, 1 Apr 2004 12:07:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6489.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Date: Thu, 1 Apr 2004 12:11:10 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A06AA2ED5@ACCLUST02EVS1.ugd.att.com> Thread-Topic: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQXXXtu22xhWhiAQ1OVZFYOT0PcHwAWLJbwABT5Y/A= From: "Pfautz, Penn L, ALABS" To: "Stastny Richard" , "Michael Hammer" Cc: "James McEachern" , 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: 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 SWYgSSB1bmRlcnN0YW5kIGl0IHRoZSByb290IGlzc3VlIGlzIHRoaXM6DQpBbGwgRS4xNjQgbnVt YmVycyB3aWxsIGhhdmUgYSBQU1ROIHBvaW50LW9mLWludGVyZmFjZSwgYnV0IGZvciBzb21lIG51 bWJlcnMgdGhhdCBQT0kgaXMgYSBnYXRld2F5IHRvIElQLiBGdXJ0aGVyIHNvbWUgc3Vic2V0IG9m IHRoZXNlIG51bWJlcnMgYXJlIG9uZXMgdGhhdCB3b24ndCBiZSBhc3NpZ25lZCBpZiB0aGV5J3Jl IG5vdCByZWFjaGFibGUgdGhyb3VnaCBJUC4gU28sIGluIG9yZGVyIHRvIGF2b2lkIHJvdXRpbmcg dG8gdGhlIGRlZmF1bHQgZ2F0ZXdheSBhZnRlciBhbiBFTlVNIHF1ZXJ5IHRoYXQgcmV0dXJucyBu byByZXN1bHQgYmVjYXVzZSB0aGUgbnVtYmVyIGlzIHVuYXNzaWduZWQsIHBlb3BsZSBhcmUgc2Vl a2luZyBzb21lIG1lY2hhbmlzbSB0byBwcm92aWRlIGEgcmVzcG9uc2UgdG8gdGhlIGluaXRpYWwg RU5VTSBxdWVyeSB0byBpbmRpY2F0ZSB0aGF0IGF0dGVtcHRzIHRvIHJvdXRlIHRocm91Z2ggdGhl IFBTVE4gd2lsbCBiZSBmdWl0bGVzcy4gQW5kIHRoZSBuZWVkIGlzIHRvIGRvIHRoaXMgd2l0aG91 dCB0cmVhZGluZyBvbiB0aGUgb3B0LWluIHByaW5jaXBsZS4NCg0KSGVyZSdzIGEgdGhvdWdodCB3 aGljaCB0aGUgbW9yZSBETlMvREREUyBsaXRlcmF0ZSBtYXkgYmUgYWJsZSB0byBjb25maXJtIG9y IHNob290IGRvd246DQpBdCBUaWVyIDEsIGluc3RlYWQgb2YgcG9wdWxhdGluZyBhbiBOUyByZWNv cmQgd2l0aCB0aGUgdGllciAyIGRlbGVnYXRpb24gZm9yIGVhY2ggbnVtYmVyIGluc3RlYWQgcG9w dWxhdGUgYSBwYWlyIG9mIG5vbi10ZXJtaW5hbCBOQVBUUiByZWNvcmRzIHdpdGggZGlmZmVyZW50 IHNlcnZpY2UgZmllbGRzIChlLmcuLCAgRTJVICBhbmQgRTJDKSB3aGljaCB3b3VsZCBwb2ludCB0 byB0aGUgZG9tYWlucyBmb3IgdGhlIGVuZCB1c2VyIFRpZXIgMiBhbmQgY2FycmllciBUaWVyIDIg cmVzcGVjdGl2ZWx5LiBJbiB0aGlzIHdheSwgYSBzaW5nbGUgcXVlcnkgd291bGQgcHJvdmlkZSBw b2ludGVycyBpbnRvIGJvdGggdHJlZXMgYW5kIGEgY2xpZW50IGNvdWxkIGRlY2lkZSB3aGV0aGVy IHRvIHB1cnN1ZSBvbmUgb3IgdGhlIG90aGVyLCBvciBwb3RlbnRpYWxseSBib3RoLiBGb3Igbm9u LWFzc2lnbmVkICJFTlVNLW9ubHkiIG51bWJlcnMsIHRoZSBjYXJyaWVyIGNvdWxkIHBvcHVsYXRl IHRoZSBFMkMgcmVjb3JkIG9ubHkgd2l0aG91dCB0cmVhZGluZyBvbiB0aGUgcGVyb2dhdGl2ZXMg b2YgdGhlIGVuZCB1c2VyIG9yIGhhdmluZyB0byBpbnN0YW50aWF0ZSBhIHNlcGFyYXRlIFRpZXIg MS4NClN1Y2ggRTJDIHJlY29yZHMgY291bGQgbm90IG9ubHkgYWRkcmVzcyB0aGUgTm9QU1ROIGlz c3VlIGJ1dCBhbHNvIGJlIHRoZSBiYXNpcyBmb3IgYSBjYXJyaWVyIG9yIGluZnJhc3RydWN0dXJl IEVOVU0gY2FwYWJpbGl0eSB0aGF0IG1heSBiZWNvbWUgbW9yZSBpbXBvcnRhbnQgYXMgVm9JUCBt b3ZlcyBiZXlvbmQgYXJiaXRyYWdlIHRvIHdoZXJlIElQIGludGVyY29ubmVjdGlvbiBiZWNvbWVz IG5vcm0uDQoNClBlbm4gUGZhdXR6DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGVudW0tYWRtaW5AaWV0Zi5vcmcgW21haWx0bzplbnVtLWFkbWluQGlldGYub3JnXU9uIEJl aGFsZiBPZg0KU3Rhc3RueSBSaWNoYXJkDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDEsIDIwMDQg MjozNiBBTQ0KVG86IE1pY2hhZWwgSGFtbWVyDQpDYzogSmFtZXMgTWNFYWNoZXJuOyBlbnVtQGll dGYub3JnDQpTdWJqZWN0OiBBVzogQVc6IFtJcHRlbF0gRlc6IFtFbnVtXSBTdW1tYXJ5IG9uIE5v UFNUTiBkaWN1c3Npb24NCg0KDQpNaWtlIHdyb3RlOg0KDQoJPj5GaXJzdCwgbm8gbnVtYmVyIGlz IG93bmVyIGJ5IGFueWJvZHksIGl0IGlzIGFzc2lnbmVkIGJ5IElUVS1UIHRvIHRoZSBOUkEsDQoJ Pj5hbmQgYXNzaWduZWQgaW4gdHVybiB0byB0aGUgU1AsIGFuZCB0aGUgU1AgYXNzaWduZXMgaXQg dG8gdGhlIGVuZC11c2VyIChmb3INCgk+Pmdlb2dyYXBoaWMgbnVtYmVycy4gU2VydmljZSBudW1i ZXJzIGFyZSBhbHJlYWR5IGFzc2lnbmVkIG9uZS1ieS1vbmUNCgk+PnRvIHRoZSBlbmQtdXNlciBi eSB0aGUgTlJBLCBubyBibG9ja3MsIG5vIGFuY2hvciBTUC4NCgkNCgk+SG93IGRvZXMgdGhpcyB3 b3JrIGZvciBudW1iZXJzIHRoYXQgd2VyZSBhc3NpZ25lZCB0byBhbiBTUCwgdGhhdCB1c2VkIHRv IGJlDQoJPlRETS1vbmx5LCBidXQgdGhlbiAob3ZlciB0aW1lKSBjb252ZXJ0cyB0byBhbiBJUC1v bmx5IG5ldHdvcms/ICBUaGUgU1BzIGFyZQ0KCT52ZXJ5IGd1YXJkZWQgYWJvdXQgdGhlIEUuMTY0 IG51bWJlcnMgYXNzaWduZWQgdG8gdGhlbS4gIFRoYXQgaXMgd2hhdCBJDQoJPm1lYW50IGJ5ICJv d25lZC4iICBZb3UgYXJlIHN1Z2dlc3RpbmcgdGhhdCB3aGVuIGEgcGVyc29uIHdpdGggYSBwaG9u ZQ0KCT5udW1iZXIgYXNzaWduZWQgYnkgYW4gU1AgbW92ZXMgdG8gYW4gSVAtYmFzZWQgInBob25l IiB0aGF0IHRoZSBTUCB3aWxsDQoJPnJlbGlucXVpc2ggdGhhdCBwaG9uZSBudW1iZXIgYmFjayB0 byB0aGUgTlJBPyAgT3IgYXJlIHlvdSBzYXlpbmcgdGhhdA0KCT5udW1iZXIgcG9ydGFiaWxpdHkg ZG9lc24ndCB3b3JrIGJldHdlZW4gVERNIGFuZCBJUCB3b3JsZHM/DQoJIA0KCVdlIGFyZSB0YWxr aW5nIGhlcmUgYWJvdXQgZm91ciBkaWZmZXJlbnQgdGhpbmdzIGhlcmU6DQoJQ2FzZSAxOiAgYSBW b0lQIHByb3ZpZGVyIGlzIGFsc28gYW4gSUxFQyAoZWcgYSBjYWJsZSBvcGVyYXRvcikgYW5kIGdl dHMgYSANCgludW1iZXIgKGdlb2dyYXBoaWMpIHJhbmdlIChibG9jaykgYXNzaWduZWQgYW5kIGFz c2lnbmVzIHRoZW0gdG8gaGlzIHVzZXJzLg0KCVNpbmNlIG51bWJlciBhc3NpZ25lbWVudCBpcyB0 ZWNobm9sb2d5IGluZGVwZW5kZW50LCB0aGVyZSBpcyBubyBwcm9ibGVtIGhlcmUsDQoJYXMgbG9u ZyBhcyB0aGUgU1AgaXMgcHJvdmlkaW5nIGEgdGVsZXBob255IHNlcnZpY2UgYXMgdXN1YWwgKHdl IGNhbGwgdGhpcyBQQVRTIC0NCglQdWJsaWNseSBBdmFpbGFibGUgVGVsZXBob255IFNlcnZpY2Ug aW4gRXVyb3BlKS4NCglOb3RlOiBzb21lIFZvSVAgU1AgaGlkZSBiZXR3ZWVuIHNtYWxsIElMRUNz IGFuZCBnZXQgc3VjaCBudW1iZXIgcmFuZ2VzDQoJdmlhIHRoZW0gKGUuZyBWb25hZ2UsIHNpcGdh dGUuZGUsIC4uLikNCgkgDQoJQ2FzZSAyOiBTaW5jZSBhbGwgbm9ybWFsIHJ1bGVzIGFwcGx5LCBh bHNvIExOUCBhcHBsaWVzLCBzbyB1c2VycyBtYXkgcG9ydA0KCXRoZWlyIG51bWJlcnMgYmFjayBh bmQgZm9ydGggYmV0d2VlbiBQU1ROIGFuZCBWb0lQIFNQDQoJIA0KCUNhc2UgMzogVGhlIHJlZ3Vs YXRvciByZXNlcnZlcyBhIHNwZWNpYWwgbnVtYmVyIHJhbmdlIGZvciBWb0lQICgwNTAgaW4NCglK YXBhbiwgMDV4IGluIFVLLCAwMzIgaW4gR2VybWFueSkuIElmIHRoZXNlIHNlcnZpY2VzIGFyZSBk ZWNsYXJlZCBub24tUEFUUw0KCU5QIGRvZXMgbm90IGFwcGx5ICh0aGlzIGlzIHVuZGVyIGRpc2N1 c3Npb24pLiBJbiBKYXBhbiB0aGVyZSBpcyBhbHNvIGEgbGlnaHRlciANCglyZWdpbWUgcmVnYXJk aW5nIFFvUy4gUmVndWxhdGlvbnMgZGlmZmVyIGhlcmUgaW4gYWxsIGNvdW50cmllcy4gDQoJSW4g dGhpcyBjYXNlIHRoZSBWb0lQIFNQIGFsc28gZ2V0IGJsb2NrcyBvZiBudW1iZXJzIGFuZCByb3V0 ZSB0aGVtIHRvIHRoZWlyIEdXLiANCglJIGtub3csIGluIHRoZSBVUyB0aGVyZSBpcyBubyBzdWNo IG51bWJlciByYW5nZS4gVGhlIHByb2JsZW0gSSBoYXZlIHdpdGgNCglzdWNoIGFuIGFwcHJvYWNo IGlzIHRoYXQgdGhlcmUgYXJlIGRpZmZlcm50IHJ1bGVzIGluIGV2ZXJ5IGNvdW50cnkgYW5kIGVu ZC11c2Vycw0KCWdldCByZXN0cmljdGVkIHNlcnZpY2VzLiAoZS5nIG5vIE5QLCBubyBhY2Nlc3Mg dG8gZW1lcmdlbmNlIHNlcnZpY2VzLCBldGMuDQoJSU1ITyB0aGlzIHdpbGwgY2F1c2UgcHJvYmxl bXMgaW4gdGhlIGZ1dHVyZQ0KCSANCglDYXNlIDQuIHRoZSByZWd1bGF0b3IgcmVzZXJ2ZXMgYSBz cGVjaWFsIG51bWJlciByYW5nZSBmb3IgRU5VTS1vbmx5IHJvdXRlZCANCgludW1iZXJzLiBUaGlz IHNob3VsZCBiZSBkb25lIGRpcmVjdGx5IHRvIHRoZSBlbmQtdXNlci4gVGhlIGFkdmFudGFnZSBp cw0KCXRoYXQgeW91IGhhdmUgTlAgYnVpbHQtaW4sIHdpdGhvdXQgaGF2aW5nIHRvIGRlYWwgd2l0 aCBub3JtYWwgTE5QIGlzc3VlcyBhbmQNCgl0ZWNobm9sb2d5LCBzYXZpbmcgdGhlIFNQIG11Y2gg ZWZmb3J0Lg0KCSANCglUaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGNhc2UgMyBhbmQgNCBpcyB0aGF0 IGluIGNhc2UgMyBubyBydWxlcyBleGlzdCBmb3IgTlAgYW5kDQoJaW50ZXJjb25uZWN0IG9uIElQ LCBzbyB5b3UgY3JlYXRlIFZvSVAgSXNsYW5kIHRoYXQgYXJlIGludGVyY29ubmVjdGVkIG9ubHkg dmlhDQoJdGhlIFBTVE4gcGVyIGRlZmF1bHQuIElmIHlvdSBpbnRlcmNvbm5lY3Qgb24gSVAsIHlv dSBjYW4gZG8gdGhpcyBvbmx5IGN1cnJlbnRseQ0KCXdpdGggYmlsYXRlcmFsIGFncmVlbWVudHMu IEluIGNhc2UgNCB5b3UgaGF2ZSBhdXRvbWF0aWNhbGx5IE5QIGFuZCBhbHNvIGludGVyY29ubmVj dA0KCWJlY2F1c2UgeW91IGNhbiB1c2UgRU5VTSBhbHNvIG9uIElQIHRvIGludGVyY29ubmVjdC4g VGhpcyBpcyBCVFcgYWxzbyBkcmFmdGVkDQoJaW4gdGhlIFNJUCBGb3J1bSBTZXJ2aWNlIFByb3Zp ZGVyIFdHIEludGVyY29ubmVjdCBDb25zZW5zdXMuDQoNCgk+PldpdGggRU5VTS1vbmx5IG51bWJl cnMgdGhlcmUgaXMgbm8gbmVlZCB0byBhc3NpZ24gYmxvY2tzIG9mIG51bWJlcnMuDQoJPj5BbiBF TlVNLW9ubHkgbnVtYmVyIGlzIHRoZSBlcXVpdmFsZW50IG9mIGEgZG9tYWluIG5hbWUuIEl0IGlz IGFzc2lnbmVkDQoJPj50byB0aGUgZW5kLXVzZXIgZGlyZWN0bHksIHdobyBjaG9vc2VzIHRoZSBT UCwgbGlrZSB3aXRoIGEgc2VydmljZSBudW1iZXIuDQoJPj5Zb3UgYWxzbyBkbyBub3QgYXNzaWdu IGRvbWFpbiBuYW1lcyBpbiBibG9ja3MuDQoJDQoJPkkgdGhpbmsgdGhlcmUgaXMgYW4gaXNzdWUg aGVyZS4gIElmIHRoZSBTUHMgaG9sZCBtb3N0IG9mIHRoZSBjdXJyZW50IE5QQQ0KCT5ibG9ja3Ms IGFuZCB0aGVyZSBpcyBhIG1pZ3JhdGlvbiBvZiBtYW55IHVzZXJzIGZyb20gVERNIHRvIElQLCB0 aGVuIGRvIHlvdQ0KCT5sZW5ndGhlbiB0aGUgbnVtYmVyIHRvIDExIGRpZ2l0cyB0byBnZXQgbW9y ZSwgb3IgZG8gdGhlIFNQcyBoYXZlIHRvDQoJPnJlbGlucXVpc2ggbnVtYmVycz8NCg0KCVRoaXMg YSB0eXBpY2FsIE5BTlAgcHJvYmxlbS4gSW4gdGhlIE5BTlAgdGhlcmUgaXMgb25seSBnZW9ncmFw aGljIGFyZWENCgljb2RlcyAod2l0aCB0aGUgZXhjZXB0aW9uIG9mIDgwMCBudW1iZXJzKS4gSW4g bW9zdCBvdGhlciBjb3VudHJ5IHRoZXJlIGFyZQ0KCW1vcmUgbnVtYmVyIHR5cGVzOiB5b3UgaGF2 ZSBnZW9ncmFwaGljIGFuZCBub24tZ2VvZ3JhcGhpYyBudW1iZXJzLg0KDQoJTm9uLWdlbyBudW1i ZXJzIGFyZSBlZyBtb2JpbGUgbnVtYmVycywgcGVyc29uYWwgbnVtYmVycywgZXRjLiBUaGUgYWR2 YW50YWdlDQoJaGVyZSBpcyB0aGF0IHlvdSByZWxpZXZlIHRoZSBwcmVzc3VyZSBvbiB0aGUgbnVt YmVyIGV4aGF1c3QgaGVyZS4gU2luY2UgZ2VvDQoJbnVtYmVycyBhcmUgZ2l2ZW4gYXdheSBpbiBi bG9ja3MsIHlvdSBoYXZlIGEgbG90IG9mIHVudXNlZCBudW1iZXJzLg0KCUVnIGluIEF1c3RyaWEg dGhlIGdlbyBudW1iZXJzIGFyZSB1c2luZyB1cCBhIGdyZWF0IGNodW5rIG9mIHRoZSBudW1iZXJz Og0KCXdlIGhhdmUgMTEwMCA0LWRpZ2l0IGFyZWEgY29kZXMgdXNlZCBiZSBhcHBveCA0IE1pbyBz dWJzY3JpYmVycywNCglvbiB0aGUgb3RoZXIgaGFuZCwgd2UgaGF2ZSA1IChmaXZlKSAzLWRpZ2l0 IG1vYmlsZSBudW1iZXIgcmFuZ2VzDQoJdXNlZCBieSA0LDUgTWlvIHN1YnNjcmliZXJzICg4MCUg b2YgdGhlbSBhcmUgYmVoaW5kIDIgbW9iaWxlICJhcmVhIiBjb2RlcykuDQoNCglUaGUgcmVhc29u IGlzIHNpbXBsZTogdGhlIG1vYmlsZSBudW1iZXIgcmFuZ2VzIGFyZSBmbGF0LiBTbyBpZiB3ZSBn aXZlIGVnDQoJb25lIDMtZGlnaXQgbnVtYmVyIHJhbmdlIHRvIEVOVU0sIHdlIGNhbiBpbnN0YW50 bHkgdXNlIHRoZW0gd2l0aA0KCWFkZGl0aW9uYWwgNy1kaWdpdHMgZm9yIDkuOTk5Ljk5OSBzdWJz Y3JpYmVycy4gDQoJDQoJcmVnYXJkcw0KDQoJUmljaGFyZA0KDQp6e3glXnoIbT8MMCd+ZmZYKd+j DQo= _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 2 04:17: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 EAA00426 for ; Fri, 2 Apr 2004 04:17: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 1B9GUn-0002Eu-4K for enum-archive@odin.ietf.org; Thu, 01 Apr 2004 23:41:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i324fXcf008596 for enum-archive@odin.ietf.org; Thu, 1 Apr 2004 23:41:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Dqi-0001nR-SV; Thu, 01 Apr 2004 20:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99uI-0004z6-ID for enum@optimus.ietf.org; Thu, 01 Apr 2004 16:39: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 QAA03429 for ; Thu, 1 Apr 2004 16:39:20 -0500 (EST) From: Robert.Shaw@itu.int Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B99uE-0006Wm-00 for enum@ietf.org; Thu, 01 Apr 2004 16:39:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B99tI-0006RA-00 for enum@ietf.org; Thu, 01 Apr 2004 16:38:25 -0500 Received: from protext02.itu.ch ([156.106.192.19] helo=protext02.exadir.itu.ch) by ietf-mx with esmtp (Exim 4.12) id 1B99sk-0006L6-00 for enum@ietf.org; Thu, 01 Apr 2004 16:37:50 -0500 Received: from protext02.exadir.itu.ch ([156.106.192.19]) by protext02.exadir.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Apr 2004 23:37:20 +0200 Received: From mailcon1.ITU.CH ([156.106.128.45]) by protext02.exadir.itu.ch (WebShield SMTP v4.5 MR1a); id 1080855439706; Thu, 1 Apr 2004 23:37:19 +0200 Received: by MAILCON1.itu.ch with Internet Mail Service (5.5.2657.72) id <2CLJMKM3>; Thu, 1 Apr 2004 23:37:19 +0200 Message-ID: <055DA814F0A9C643A0594D50C23D6C7B028750F4@mailsrv7.itu.ch> To: enum@ietf.org Date: Thu, 1 Apr 2004 23:37:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Apr 2004 21:37:20.0019 (UTC) FILETIME=[82CD8E30:01C41831] 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] Interest in participating in APT-ITU Workshop on 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: , Hello, The Asia-Pacific Telecommunity (APT) is organizing the Asia Pacific Forum on Telecommunication Policy and Regulation from May 17 to 20, 2004 in Bandar Seri Begawan, Brunei Darussalam. This Forum will be followed by a Joint APT/ITU Workshop on ENUM & IDN from 21 to 22 May 2004 at the same venue. There may be subscribers to this list who may be interested in contributing to the ENUM part of the workshop on 22 May 2004 in Brunei Darussalam (for example, to share individual country Asia-Pac experiences in implementing ENUM). If so, you are invited to contact me privately off this list to discuss potential participation in the workshop. Thanks, Robert -- Robert Shaw ITU Internet Strategy and Policy Advisor Strategy and Policy Unit _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 2 04:36: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 EAA01091 for ; Fri, 2 Apr 2004 04:36: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 1B9Gyi-0003qE-8i for enum-archive@odin.ietf.org; Fri, 02 Apr 2004 00:12:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i325CSrD014766 for enum-archive@odin.ietf.org; Fri, 2 Apr 2004 00:12:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E5N-0004Uy-5F; Thu, 01 Apr 2004 21:07:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Age-0002BC-OX for enum@optimus.ietf.org; Thu, 01 Apr 2004 17:29: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 RAA04846 for ; Thu, 1 Apr 2004 17:29:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Agc-0003Yk-00 for enum@ietf.org; Thu, 01 Apr 2004 17:29:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Afd-0003TC-00 for enum@ietf.org; Thu, 01 Apr 2004 17:28:24 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1B9Aee-0003JB-00 for enum@ietf.org; Thu, 01 Apr 2004 17:27:20 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i31MQW911234; Thu, 1 Apr 2004 17:26:32 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Apr 2004 17:26:33 -0500 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6096E352B@zcard0ke.ca.nortel.com> From: "James McEachern" To: "'Michael Hammer'" , "Pfautz, Penn L, ALABS" Cc: Stastny Richard , enum@ietf.org Subject: RE: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Date: Thu, 1 Apr 2004 17:26:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41838.620CF7CE" 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,HTML_20_30,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_01C41838.620CF7CE Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04f.nortelnetworks.com id i31MQW911234 Content-Transfer-Encoding: quoted-printable If the E.164 number has been assigned to a SP providing a PATS, then the PSTN will (must - because of opt-in) always know how to route to the appropriate SP, and the SP in turn knows how to route to the device. If t= he number is an ENUM only number, then the PSTN will need to know this (both the fact that it is a valid number so it does not reject it, and the fact that it is an ENUM-only number so that it can route it to an ENUM enabled GW). The PSTN will be able to determine this using existing routing & translation techniques - nothing more is required. So the entire problem comes down to how the VoIP network can recognize th= at a number is an "ENUM-only" number, and not route this to the PSTN if ther= e is no ENUM entry. For all other cases routing to the PSTN works fine. Thi= s means that whatever solution we come up with, it is only necessary to app= ly it to ENUM-only numbers. (We *may* decide it is valuable to also apply it= to other numbers, but if it complicates things this is not necessary.) Am I missing something? Jim -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com]=20 Sent: Thursday, April 01, 2004 3:58 PM To: Pfautz, Penn L, ALABS Cc: Stastny Richard; McEachern, James [CAR:5N00:EXCH]; enum@ietf.org Subject: RE: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion This sounds reasonable to me, but I would rather hear from the DNS expert= s. My assumption, as you note below, was that if the number was not in ENUM,= =20 then the only element that knows whether the number is assigned and=20 reachable is the operator PSTN-IP GW that has a configured translation or= =20 knows that the number is unassigned. Mike At 12:11 PM 4/1/2004 -0500, Pfautz, Penn L, ALABS wrote: >If I understand it the root issue is this: >All E.164 numbers will have a PSTN point-of-interface, but for some=20 >numbers that POI is a gateway to IP. Further some subset of these number= s=20 >are ones that won't be assigned if they're not reachable through IP. So,= =20 >in order to avoid routing to the default gateway after an ENUM query tha= t=20 >returns no result because the number is unassigned, people are seeking=20 >some mechanism to provide a response to the initial ENUM query to indica= te=20 >that attempts to route through the PSTN will be fuitless. And the need i= s=20 >to do this without treading on the opt-in principle. > >Here's a thought which the more DNS/DDDS literate may be able to confirm= =20 >or shoot down: >At Tier 1, instead of populating an NS record with the tier 2 delegation= =20 >for each number instead populate a pair of non-terminal NAPTR records wi= th=20 >different service fields (e.g., E2U and E2C) which would point to the=20 >domains for the end user Tier 2 and carrier Tier 2 respectively. In this= =20 >way, a single query would provide pointers into both trees and a client=20 >could decide whether to pursue one or the other, or potentially both. Fo= r=20 >non-assigned "ENUM-only" numbers, the carrier could populate the E2C=20 >record only without treading on the perogatives of the end user or havin= g=20 >to instantiate a separate Tier 1. >Such E2C records could not only address the NoPSTN issue but also be the= =20 >basis for a carrier or infrastructure ENUM capability that may become mo= re=20 >important as VoIP moves beyond arbitrage to where IP interconnection=20 >becomes norm. > >Penn Pfautz > > >-----Original Message----- >From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of >Stastny Richard >Sent: Thursday, April 01, 2004 2:36 AM >To: Michael Hammer >Cc: James McEachern; enum@ietf.org >Subject: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion > > >Mike wrote: > > >>First, no number is owner by anybody, it is assigned by ITU-T= =20 > to the NRA, > >>and assigned in turn to the SP, and the SP assignes it to the= =20 > 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, th= at=20 > used to be > >TDM-only, but then (over time) converts to an IP-only=20 > network? The SPs are > >very guarded about the E.164 numbers assigned to them. That i= s=20 > what I > >meant by "owned." You are suggesting that when a person with = a=20 > phone > >number assigned by an SP moves to an IP-based "phone" that the= =20 > SP will > >relinquish that phone number back to the NRA? Or are you sayi= ng=20 > that > >number portability doesn't work between TDM and IP worlds? > > We are talking here about four different things here: > Case 1: a VoIP provider is also an ILEC (eg a cable operator)=20 > and gets a > number (geographic) range (block) assigned and assignes them to= =20 > his users. > Since number assignement is technology independent, there is no= =20 > problem here, > as long as the SP is providing a telephony service as usual (we= =20 > call this PATS - > Publicly Available Telephony Service in Europe). > Note: some VoIP SP hide between small ILECs and get such number= =20 > ranges > via them (e.g Vonage, sipgate.de, ...) > > Case 2: Since all normal rules apply, also LNP applies, so user= s=20 > may port > their numbers back and forth between PSTN and VoIP SP > > Case 3: The regulator reserves a special number range for VoIP=20 > (050 in > Japan, 05x in UK, 032 in Germany). If these services are declar= ed=20 > non-PATS > NP does not apply (this is under discussion). In Japan there is= =20 > also a lighter > regime regarding QoS. Regulations differ here in all countries. > In this case the VoIP SP also get blocks of numbers and route=20 > them to their GW. > I know, in the US there is no such number range. The problem I=20 > have with > such an approach is that there are differnt rules in every=20 > country and end-users > get restricted services. (e.g no NP, no access to emergence=20 > services, etc. > IMHO this will cause problems in the future > > Case 4. the regulator reserves a special number range for=20 > ENUM-only routed > numbers. This should be done directly to the end-user. The=20 > advantage is > that you have NP built-in, without having to deal with normal L= NP=20 > issues and > technology, saving the SP much effort. > > The difference between case 3 and 4 is that in case 3 no rules=20 > exist for NP and > interconnect on IP, so you create VoIP Island that are=20 > interconnected only via > the PSTN per default. If you interconnect on IP, you can do thi= s=20 > only currently > with bilateral agreements. In case 4 you have automatically NP=20 > and also interconnect > because you can use ENUM also on IP to interconnect. This is BT= W=20 > also drafted > in the SIP Forum Service Provider WG Interconnect Consensus. > > >>With ENUM-only numbers there is no need to assign blocks of=20 > numbers. > >>An ENUM-only number is the equivalent of a domain name. It is= =20 > assigned > >>to the end-user directly, who chooses the SP, like with a=20 > 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=20 > current NPA > >blocks, and there is a migration of many users from TDM to IP,= =20 > then do you > >lengthen the number to 11 digits to get more, or do the SPs ha= ve to > >relinquish numbers? > > This a typical NANP problem. In the NANP there is only geograph= ic=20 > area > codes (with the exception of 800 numbers). In most other countr= y=20 > there are > more number types: you have geographic and non-geographic numbe= rs. > > Non-geo numbers are eg mobile numbers, personal numbers, etc. T= he=20 > advantage > here is that you relieve the pressure on the number exhaust her= e.=20 > Since geo > numbers are given away in blocks, you have a lot of unused numbers. > Eg in Austria the geo numbers are using up a great chunk of the= =20 > numbers: > we have 1100 4-digit area codes used be appox 4 Mio subscribers= , > on the other hand, we have 5 (five) 3-digit mobile number range= s > used by 4,5 Mio subscribers (80% of them are behind 2 mobile=20 > "area" codes). > > The reason is simple: the mobile number ranges are flat. So if = we=20 > give eg > one 3-digit number range to ENUM, we can instantly use them wit= h > additional 7-digits for 9.999.999 subscribers. > > regards > > Richard > >z{x%^zm?0'~ffX)=DF=A3 ------_=_NextPart_001_01C41838.620CF7CE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion

If the E.164 number has been assigned to a SP = providing a PATS, then the PSTN will (must - because of opt-in) always = know how to route to the appropriate SP, and the SP in turn knows how = to route to the device. If the number is an ENUM only number, then the = PSTN will need to know this (both the fact that it is a valid number so = it does not reject it, and the fact that it is an ENUM-only number so = that it can route it to an ENUM enabled GW). The PSTN will be able to = determine this using existing routing & translation techniques - = nothing more is required.

So the entire problem comes down to how the VoIP = network can recognize that a number is an "ENUM-only" number, = and not route this to the PSTN if there is no ENUM entry. For all other = cases routing to the PSTN works fine. This means that whatever solution = we come up with, it is only necessary to apply it to ENUM-only numbers. = (We *may* decide it is valuable to also apply it to other numbers, but = if it complicates things this is not necessary.)

Am I missing something?

Jim

-----Original Message-----
From: Michael Hammer [mailto:mhammer@cisco.com]
Sent: Thursday, April 01, 2004 3:58 PM
To: Pfautz, Penn L, ALABS
Cc: Stastny Richard; McEachern, James = [CAR:5N00:EXCH]; enum@ietf.org
Subject: RE: AW: [Iptel] FW: [Enum] Summary on = NoPSTN dicussion

This sounds reasonable to me, but I would rather hear = from the DNS experts.

My assumption, as you note below, was that if the = number was not in ENUM,
then the only element that knows whether the number = is assigned and
reachable is the operator PSTN-IP GW that has a = configured translation or
knows that the number is unassigned.

Mike


At 12:11 PM 4/1/2004 -0500, Pfautz, Penn L, ALABS = wrote:
>If I understand it the root issue is = this:
>All E.164 numbers will have a PSTN = point-of-interface, but for some
>numbers that POI is a gateway to IP. Further = some subset of these numbers
>are ones that won't be assigned if they're not = reachable through IP. So,
>in order to avoid routing to the default gateway = after an ENUM query that
>returns no result because the number is = unassigned, people are seeking
>some mechanism to provide a response to the = initial ENUM query to indicate
>that attempts to route through the PSTN will be = fuitless. And the need is
>to do this without treading on the opt-in = principle.
>
>Here's a thought which the more DNS/DDDS = literate may be able to confirm
>or shoot down:
>At Tier 1, instead of populating an NS record = with the tier 2 delegation
>for each number instead populate a pair of = non-terminal NAPTR records with
>different service fields (e.g.,  E2U  = and E2C) which would point to the
>domains for the end user Tier 2 and carrier Tier = 2 respectively. In this
>way, a single query would provide pointers into = both trees and a client
>could decide whether to pursue one or the other, = or potentially both. For
>non-assigned "ENUM-only" numbers, the = carrier could populate the E2C
>record only without treading on the perogatives = of the end user or having
>to instantiate a separate Tier 1.
>Such E2C records could not only address the = NoPSTN issue but also be the
>basis for a carrier or infrastructure ENUM = capability that may become more
>important as VoIP moves beyond arbitrage to = where IP interconnection
>becomes norm.
>
>Penn Pfautz
>
>
>-----Original Message-----
>From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On = Behalf Of
>Stastny Richard
>Sent: Thursday, April 01, 2004 2:36 AM
>To: Michael Hammer
>Cc: James McEachern; enum@ietf.org
>Subject: AW: AW: [Iptel] FW: [Enum] Summary on = NoPSTN dicussion
>
>
>Mike wrote:
>
>         = >>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
>         = >TDM-only, but then (over time) converts to an IP-only
> network?  The SPs are
>         = >very guarded about the E.164 numbers assigned to them.  That = is
> what I
>         = >meant by "owned."  You are suggesting that when a = person with a
> phone
>         = >number assigned by an SP moves to an IP-based "phone" = that the
> SP will
>         = >relinquish that phone number back to the NRA?  Or are you = saying
> that
>         = >number portability doesn't work between TDM and IP worlds?
>
>         = We are talking here about four different things here:
>         = Case 1:  a VoIP provider is also an ILEC (eg a cable operator) =
> and gets a
>         = number (geographic) range (block) assigned and assignes them to
> his users.
>         = Since number assignement is technology independent, there is no
> problem here,
>         = as long as the SP is providing a telephony service as usual (we
> call this PATS -
>         = Publicly Available Telephony Service in Europe).
>         = Note: some VoIP SP hide between small ILECs and get such number
> ranges
>         = via them (e.g Vonage, sipgate.de, ...)
>
>         = Case 2: Since all normal rules apply, also LNP applies, so users =
> may port
>         = their numbers back and forth between PSTN and VoIP SP
>
>         = Case 3: The regulator reserves a special number range for VoIP
> (050 in
>         = Japan, 05x in UK, 032 in Germany). If these services are declared =
> non-PATS
>         = NP does not apply (this is under discussion). In Japan there is
> also a lighter
>         = regime regarding QoS. Regulations differ here in all countries.
>         = In this case the VoIP SP also get blocks of numbers and route
> them to their GW.
>         = I know, in the US there is no such number range. The problem I
> have with
>         = such an approach is that there are differnt rules in every
> country and end-users
>         = get restricted services. (e.g no NP, no access to emergence
> services, etc.
>         = IMHO this will cause problems in the future
>
>         = Case 4. the regulator reserves a special number range for
> ENUM-only routed
>         = numbers. This should be done directly to the end-user. The
> advantage is
>         = that you have NP built-in, without having to deal with normal LNP =
> issues and
>         = technology, saving the SP much effort.
>
>         = The difference between case 3 and 4 is that in case 3 no rules
> exist for NP and
>         = interconnect on IP, so you create VoIP Island that are
> interconnected only via
>         = the PSTN per default. If you interconnect on IP, you can do this =
> only currently
>         = with bilateral agreements. In case 4 you have automatically NP
> and also interconnect
>         = because you can use ENUM also on IP to interconnect. This is BTW =
> also drafted
>         = in the SIP Forum Service Provider WG Interconnect Consensus.
>
>         = >>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
>         = >blocks, and there is a migration of many users from TDM to IP, =
> then do you
>         = >lengthen the number to 11 digits to get more, or do the SPs have = to
>         = >relinquish numbers?
>
>         = This a typical NANP problem. In the NANP there is only geographic =
> area
>         = codes (with the exception of 800 numbers). In most other country =
> there are
>         = more number types: you have geographic and non-geographic = numbers.
>
>         = Non-geo numbers are eg mobile numbers, personal numbers, etc. The =
> advantage
>         = here is that you relieve the pressure on the number exhaust here. =
> Since geo
>         = numbers are given away in blocks, you have a lot of unused = numbers.
>         = Eg in Austria the geo numbers are using up a great chunk of the
> numbers:
>         = we have 1100 4-digit area codes used be appox 4 Mio subscribers,
>         = on the other hand, we have 5 (five) 3-digit mobile number ranges
>         = used by 4,5 Mio subscribers (80% of them are behind 2 mobile
> "area" codes).
>
>         = The reason is simple: the mobile number ranges are flat. So if we =
> give eg
>         = one 3-digit number range to ENUM, we can instantly use them with
>         = additional 7-digits for 9.999.999 subscribers.
>
>         = regards
>
>         = Richard
>
>z{x%^zm?0'~ffX)=DF=A3

------_=_NextPart_001_01C41838.620CF7CE-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 2 04:37: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 EAA01129 for ; Fri, 2 Apr 2004 04:37: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 1B9H8n-00049o-5k for enum-archive@odin.ietf.org; Fri, 02 Apr 2004 00:23:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i325Mrnc015976 for enum-archive@odin.ietf.org; Fri, 2 Apr 2004 00:22:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E6H-0004uD-Cb; Thu, 01 Apr 2004 21:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Ax7-00033y-40 for enum@optimus.ietf.org; Thu, 01 Apr 2004 17:46:25 -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 RAA05479 for ; Thu, 1 Apr 2004 17:46:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Ax4-0005Hx-00 for enum@ietf.org; Thu, 01 Apr 2004 17:46:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Aw7-0005BM-00 for enum@ietf.org; Thu, 01 Apr 2004 17:45:28 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1B9AvH-00051p-00 for enum@ietf.org; Thu, 01 Apr 2004 17:44:31 -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 i31Mhm726610; Thu, 1 Apr 2004 17:43:48 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Apr 2004 17:43:49 -0500 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6096E352C@zcard0ke.ca.nortel.com> From: "James McEachern" To: "'Michael Hammer'" Cc: "'Stastny Richard'" , enum@ietf.org Subject: RE: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Date: Thu, 1 Apr 2004 17:43:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4183A.CBC4DBE4" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 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_01C4183A.CBC4DBE4 Content-Type: text/plain; charset="utf-8" X-MIME-Autoconverted: from 8bit to quoted-printable by zcars0m9.nortelnetworks.com id i31Mhm726610 Content-Transfer-Encoding: quoted-printable Mike, I certainly don't want to curb your desire to get calls onto the IP netwo= rk as soon as possible... I don't think the PSTN-to-IP GW needs to know the mapping to every teleph= one number in the world to route it using IP. If the number is assigned to a Service Provider using techniques like those used today, then the GW shou= ld be able to know which SP the number maps to - and route on that basis. Th= is could be done with Carrier ENUM, or with traditional routing and translations - either one could work. There is no reason whatsoever why "PSTN routing" cannot select IP "trunks" to another VoIP network. (Of cou= rse this would not be true for ENUM-only numbers.) Public ENUM (in those cases where the subscriber has opted-in) can accelerate and refine this, but there is no reason to wait for it to get started moving to end-to-end IP. Jim -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com]=20 Sent: Tuesday, March 30, 2004 5:47 PM To: McEachern, James [CAR:5N00:EXCH] Cc: 'Stastny Richard'; enum@ietf.org Subject: RE: [Iptel] FW: [Enum] Summary on NoPSTN dicussion 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 PST= N=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 PST= N=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 t= o=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 th= e=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 wor= k=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 o= f=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 th= e=20 >number is unassigned and release the call." > >---end snip--- > >This seems to suggest that routing to an IP endpoint would require an EN= UM=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 o= n 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=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 referen= ced > 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 whethe= r=20 > to a PSTN > endpoint or an IP endpoint. > > Another concern is that, if you do get looped routing between t= he=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 lag= s=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 somewh= at > 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 t= he=20 > PSTN, > with default behavior being, if unknown to ENUM, send to PSTN t= o > resolve. (Note this is orthogonal to ENUMs use to select=20 > alternative > endpoints.) > > - If endpoint is IP, then the LNP databases should point to t= he IP > domain, with default behavior being, if unknown to LNP, route i= n=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 coul= d=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 bo= th=20 > an LNP > and an ENUM dip have not resolved the route, can safely conclud= e=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 followin= g 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 form= at > >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-que= ry > >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 t= o the > >PSTN if the server is able to do so (eventually with the ;enum= di=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 ENU= M- > >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 yo= u > >do not find one in ENUM, you also will not find one on the PST= N, so > >it makes no sense to route it to the PSTN (ENUM-only) > >2. Default routing for the whole number range (number block) t= o=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 ca= se=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 ope= ns=20 > up access > >to the Internet via a gateway (border element, ...), he may wa= nt=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 n= o=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.arp= a. > >The second tree would contain only wildcard NAPTR RR for numbe= r=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 o= ne=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 ea= ch=20 > tree > >would be structured in the sane way like e164.arpa, so the sam= e=20 > algorithms > >can be used. > > > >Since the structure of the delegations in e164.arpa varies (Ti= er=20 > 1 levels), > >there is no easy way to find out the level of the pointers, ev= en=20 > if they are > >only on the Tier 1 layer. > > > >It was proposed to search either top down (faster) or bottom u= p=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 "VOI= D" > > > >Also here additional proposals are invited. > > > >Best regards > > > >Richard > > > > > > > > > >_______________________________________________ > >enum mailing list > >enum@ietf.org >=20 > >https://www1.ietf.org/mailm= an/ listinfo/enum=20 > > > > >_______________________________________________ > >Iptel mailing list > >Iptel@ietf.org >=20 > >https://www.ietf.org/mailma= n/l istinfo/iptel=20 > > > > >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 ------_=_NextPart_001_01C4183A.CBC4DBE4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [Iptel] FW: [Enum] Summary on NoPSTN dicussion

Mike,
I certainly don't want to curb your desire to get = calls onto the IP network as soon as possible...

I don't think the PSTN-to-IP GW needs to know the = mapping to every telephone number in the world to route it using IP. If = the number is assigned to a Service Provider using techniques like = those used today, then the GW should be able to know which SP the = number maps to - and route on that basis. This could be done with = Carrier ENUM, or with traditional routing and translations - either one = could work. There is no reason whatsoever why "PSTN routing" = cannot select IP "trunks" to another VoIP network. (Of course = this would not be true for ENUM-only numbers.)

Public ENUM (in those cases where the subscriber has = opted-in) can accelerate and refine this, but there is no reason to = wait for it to get started moving to end-to-end IP.

Jim

-----Original Message-----
From: Michael Hammer [mailto:mhammer@cisco.com]
Sent: Tuesday, March 30, 2004 5:47 PM
To: McEachern, James [CAR:5N00:EXCH]
Cc: 'Stastny Richard'; enum@ietf.org
Subject: RE: [Iptel] FW: [Enum] Summary on NoPSTN = dicussion

James,

I guess I have to curb my desire to get the call onto = the IP network as
soon as possible rather than as late as = possible.

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.

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.

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.

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.  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?

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.

I confess I have not been watching the ENUM list, but = perhaps should
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
>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= >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=83=C2=BCngliche Nachricht-----
>         = Von: Michael Hammer
> [<mailto:mhammer@cisco.com>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 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 = 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>https://www1.ietf.org/mailman/listinfo/enum =
>
>         = >
>         = >_______________________________________________
>         = >Iptel mailing list
>         = >Iptel@ietf.org
>
 > ><https://www.ietf.org/mailman/listinfo/iptel>https://www.ietf.org/mailman/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=

------_=_NextPart_001_01C4183A.CBC4DBE4-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 2 07:41:03 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 HAA06927 for ; Fri, 2 Apr 2004 07:41:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9L0p-0005vm-0o for enum-archive@odin.ietf.org; Fri, 02 Apr 2004 04:30:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i329Usqm022798 for enum-archive@odin.ietf.org; Fri, 2 Apr 2004 04:30:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9GqY-0003M0-Ty; Fri, 02 Apr 2004 00:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E2A-0002qf-FH for enum@optimus.ietf.org; Thu, 01 Apr 2004 21:03:50 -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 VAA22440 for ; Thu, 1 Apr 2004 21:03:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9E27-0000l8-00 for enum@ietf.org; Thu, 01 Apr 2004 21:03:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9E1B-0000Wp-00 for enum@ietf.org; Thu, 01 Apr 2004 21:02:50 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B9E0H-0000ER-00 for enum@ietf.org; Thu, 01 Apr 2004 21:01:53 -0500 Content-Class: urn:content-classes:message Subject: Re: [Iptel] FW: [Enum] Summary on NoPSTN dicussion MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 2 Apr 2004 04:01:19 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F162233C98@oefeg-s02.oefeg.loc> Thread-Topic: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQYAj7nZ8HYcB0MS9qDGuLyDZEN4AAUBiEx From: "Stastny Richard" To: "Michael Hammer" Cc: "James McEachern" , 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 SSB0cmllZCB0byB3b3JrIG9uIHlvdSBtYXRyaXg6DQpHZW86ICAgICAgICAgIFkgICAgICAgIE4v QSAgICAgTi9BDQpQU1ROOiAgICAgICBZICAgICAgICBOL0EgICAgIE4vQQ0KVm9JUDogICAgICAg ICBZICAgICAgICAgWSAgICAgICAgIFkNCkVOVU06ICAgICBvcHQtaW4gIG9wdC1pbiAgICBvbmx5 DQogQ2FzZSAgICAgICAxLTIgICAgICAgIDMgICAgICAgICAgNA0KIA0KYnV0IGl0IGRvZXMgbm90 IGhlbHAgdmVyeSBtdWNoLg0KV2UgYXJlIHRhbGtpbmcgYWJvdXQgcmVxdWlyZW1lbnRzIGluIFB1 YmxpYyBVc2VyIEVOVU06DQpNdXN0OiBpZiBhIG51bWJlciBpcyBpbiBFTlVNIG9ubHksIHRoZSBj bGllbnQgbmVlZHMgdG8ga25vdyB0aGF0IGlzIA0KZG9lcyBub3QgbWFrZSBzZW5zZSB0byBmb3J3 YXJkIHRoZSBjYWxsIHRvIHRoZSBQU1RODQogDQpXZSBuZWVkIHRvIGZpbmQgYSBzb2x1dGlvbiBm b3IgdGhpcy4gSUYgdGhpcyBzb2x1dGlvbnMgYWxsb3dzIGFsc28NCnRvIGRvIGFkZGl0aW9uYWwg dGhpbmdzIChkZXBlbmRpbmcgb24gdGhlIHNvbHV0aW9uIGZvdW5kKSwNCml0IHdvdWxkIGJlIG5p Y2UgdG8gaGF2ZToNCi1JbmRpY2F0aW9uIHRoYXQgdGhlIG51bWJlciBpcyBub3QgZXhpc3Rpbmcg YW4gdGhlIFBTVE4gZWl0aGVyIChlLmcgdW51c2VkIG51bWJlciBibG9jaykNCi1JZiB0aGUgbnVt YmVyIGlzIG9uIFZvSVAgKG9yIFBTVE4pLCBidXQgbm90IGluIEVOVU0sIGJ1dCBjYW4gYmUgcmVh Y2hlZCB2aWEgYSAiR1ciIG9uIElQLA0KdGhlIGRvbWFpbiBuYW1lIG9mIHRoZSBnYXRld2F5IHdo ZXJlIHRoZSBudW1iZXIgY2FuIGJlIGRlbGl2ZXJlZCB2aWEgc2lwOit4eHhAZ3cucHJvdi5mb28N Ci1JZiB0aGUgbnVtYmVyIGlzIG9uIHRoZSBQU1ROLCBidXQgcG9ydGVkLCBhbmQgdGhlIExOUCBp cyBhbHNvIGFjY2Vzc2libGUgdmlhIElQIChjYXJyaWVyIA0KRU5VTSkgd2hhdCBpcyB0aGUgcm9v dCBvZiB0aGUgY2FycmllciBFTlVNIChpZiBwdWJsaWNseSBhdmFpbGFibGUpLiBUaGlzIG1heSBi ZSB0cmlja3ksIGlmIG5vdC4NCiANCkJ1dCByZW1lbWJlciwgdGhlc2UgYXJlIG5pY2UgdG8gaGF2 ZXMgYW5kIG5lZWQgbm90IHRvIGJlIHNvbHZlZCwgYXMgbG9uZyBhcyB0aGUgUFNUTiBpcyB0aGVy ZS4NCk9uIHRoZSBvdGhlciBoYW5kLCBpZiB3ZSBmaW5hbGx5IHdhbnQgVm9JUCB0byBiZSBzZWxm Y29udGFpbmluZyBhbmQgbm90IHJlbHkgb24gdGhlIFBTVE4sIHdlIGhhdmUgDQp0byBmaW5kIHNv bHV0aW9ucyBmb3IgdGhpcyANCiANClJpY2hhcmQNCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFj aHJpY2h0LS0tLS0gDQoJVm9uOiBNaWNoYWVsIEhhbW1lciBbbWFpbHRvOm1oYW1tZXJAY2lzY28u Y29tXSANCglHZXNlbmRldDogRG8gMDEuMDQuMjAwNCAxNzo1OCANCglBbjogU3Rhc3RueSBSaWNo YXJkIA0KCUNjOiBKYW1lcyBNY0VhY2hlcm47IGVudW1AaWV0Zi5vcmcgDQoJQmV0cmVmZjogUmU6 IEFXOiBBVzogW0lwdGVsXSBGVzogW0VudW1dIFN1bW1hcnkgb24gTm9QU1ROIGRpY3Vzc2lvbg0K CQ0KCQ0KDQoJUmljaGFyZCwNCgkNCglTbywgaWYgSSBtaWdodCBzdW1tYXJpemUgd2hhdCB5b3Ug aGF2ZSBzYWlkLCB0aGVyZSBhcmUgZm91ciBhdHRyaWJ1dGVzIHRoYXQNCglyZXN1bHQgaW4gZGlm ZmVyZW50IGNvbWJpbmF0aW9uczoNCgkNCglHZW9ncmFwaGljIG9yIG5vdD8gICAgWSAgICAgICAg IE4gICAgICAgTg0KCVB1YmxpYyAoTlApIG9yIG5vdD8gICBZICAgICAgICBZL04gICAgICA/ICAo cm93OiBOUC9yZWd1bGF0b3J5IHJlcXVpcmVtZW50cykNCglWb0lQIG9yIG5vdD8gICAgICAgICBZ L04gICAgICAgIFkgICAgICAgWQ0KCUVOVU0gb3Igbm90PyAgICAgICBvcHQtaW4/ICAgb3B0LWlu PyAgICBZDQoJICAgICAgICAgICAgICAgICAgICBDYXNlIDEtMiAgQ2FzZSAzICAgQ2FzZSA0DQoJ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKE5QIGluaGVyZW50KQ0KCQ0K CVRoZXJlIGFyZSBwcm9iYWJseSAxNiBjb21iaW5hdGlvbnMsIG9mIHdoaWNoIG1hbnkgZG9uJ3Qg bWFrZSBzZW5zZSBvcg0KCWFyZW4ndCB1c2VkLiAgSSB3YXMgdW5jbGVhciBhYm91dCB3aGV0aGVy IGJlaW5nIGFuIEVOVU0gbnVtYmVyIGFsbG93ZWQgeW91DQoJdG8gb3B0IGluIG9yIG91dCwgaS5l LiB3aGF0IGRvZXMgYW4gdW5saXN0ZWQgRU5VTSBudW1iZXIgbWVhbi4gIEl0IHdvdWxkDQoJZ3Jl YXRseSBzaW1wbGlmeSB0aGluZ3MsIGlmIHRoZXJlIHdlcmUgZmV3IGNvbWJpbmF0aW9ucy4NCgkN CglCdXQsIHRoaXMgYWxsIGNvbWVzIGRvd24gdG8gcm91dGluZyBiYXNlZCBvbiBjb25maWd1cmF0 aW9uLCBkYXRhYmFzZSwgb3INCglib3RoLiAgQW5kIGZvciBjYWxscyB0byByZWFjaCBzb21lb25l LCBvbmUgb3IgdGhlIG90aGVyIG11c3QgZXhpc3QsIGV2ZW4gaWYNCglvbmx5IG9uIHRoZSBjYWxs aW5nIHBhcnR5J3MgIHRlcm1pbmFsLg0KCQ0KCU1pa2UNCgkNCglBdCAwOTozNSBBTSA0LzEvMjAw NCArMDIwMCwgU3Rhc3RueSBSaWNoYXJkIHdyb3RlOg0KCT5NaWtlIHdyb3RlOg0KCT4NCgk+ICAg ICAgICAgPj5GaXJzdCwgbm8gbnVtYmVyIGlzIG93bmVyIGJ5IGFueWJvZHksIGl0IGlzIGFzc2ln bmVkIGJ5IElUVS1UDQoJPiB0byB0aGUgTlJBLA0KCT4gICAgICAgICA+PmFuZCBhc3NpZ25lZCBp biB0dXJuIHRvIHRoZSBTUCwgYW5kIHRoZSBTUCBhc3NpZ25lcyBpdCB0byB0aGUNCgk+IGVuZC11 c2VyIChmb3INCgk+ICAgICAgICAgPj5nZW9ncmFwaGljIG51bWJlcnMuIFNlcnZpY2UgbnVtYmVy cyBhcmUgYWxyZWFkeSBhc3NpZ25lZCBvbmUtYnktb25lDQoJPiAgICAgICAgID4+dG8gdGhlIGVu ZC11c2VyIGJ5IHRoZSBOUkEsIG5vIGJsb2Nrcywgbm8gYW5jaG9yIFNQLg0KCT4NCgk+ICAgICAg ICAgPkhvdyBkb2VzIHRoaXMgd29yayBmb3IgbnVtYmVycyB0aGF0IHdlcmUgYXNzaWduZWQgdG8g YW4gU1AsIHRoYXQNCgk+IHVzZWQgdG8gYmUNCgk+ICAgICAgICAgPlRETS1vbmx5LCBidXQgdGhl biAob3ZlciB0aW1lKSBjb252ZXJ0cyB0byBhbiBJUC1vbmx5DQoJPiBuZXR3b3JrPyAgVGhlIFNQ cyBhcmUNCgk+ICAgICAgICAgPnZlcnkgZ3VhcmRlZCBhYm91dCB0aGUgRS4xNjQgbnVtYmVycyBh c3NpZ25lZCB0byB0aGVtLiAgVGhhdCBpcw0KCT4gd2hhdCBJDQoJPiAgICAgICAgID5tZWFudCBi eSAib3duZWQuIiAgWW91IGFyZSBzdWdnZXN0aW5nIHRoYXQgd2hlbiBhIHBlcnNvbiB3aXRoIGEN Cgk+IHBob25lDQoJPiAgICAgICAgID5udW1iZXIgYXNzaWduZWQgYnkgYW4gU1AgbW92ZXMgdG8g YW4gSVAtYmFzZWQgInBob25lIiB0aGF0IHRoZQ0KCT4gU1Agd2lsbA0KCT4gICAgICAgICA+cmVs aW5xdWlzaCB0aGF0IHBob25lIG51bWJlciBiYWNrIHRvIHRoZSBOUkE/ICBPciBhcmUgeW91IHNh eWluZw0KCT4gdGhhdA0KCT4gICAgICAgICA+bnVtYmVyIHBvcnRhYmlsaXR5IGRvZXNuJ3Qgd29y ayBiZXR3ZWVuIFRETSBhbmQgSVAgd29ybGRzPw0KCT4NCgk+ICAgICAgICAgV2UgYXJlIHRhbGtp bmcgaGVyZSBhYm91dCBmb3VyIGRpZmZlcmVudCB0aGluZ3MgaGVyZToNCgk+ICAgICAgICAgQ2Fz ZSAxOiAgYSBWb0lQIHByb3ZpZGVyIGlzIGFsc28gYW4gSUxFQyAoZWcgYSBjYWJsZSBvcGVyYXRv cikNCgk+IGFuZCBnZXRzIGENCgk+ICAgICAgICAgbnVtYmVyIChnZW9ncmFwaGljKSByYW5nZSAo YmxvY2spIGFzc2lnbmVkIGFuZCBhc3NpZ25lcyB0aGVtIHRvDQoJPiBoaXMgdXNlcnMuDQoJPiAg ICAgICAgIFNpbmNlIG51bWJlciBhc3NpZ25lbWVudCBpcyB0ZWNobm9sb2d5IGluZGVwZW5kZW50 LCB0aGVyZSBpcyBubw0KCT4gcHJvYmxlbSBoZXJlLA0KCT4gICAgICAgICBhcyBsb25nIGFzIHRo ZSBTUCBpcyBwcm92aWRpbmcgYSB0ZWxlcGhvbnkgc2VydmljZSBhcyB1c3VhbCAod2UNCgk+IGNh bGwgdGhpcyBQQVRTIC0NCgk+ICAgICAgICAgUHVibGljbHkgQXZhaWxhYmxlIFRlbGVwaG9ueSBT ZXJ2aWNlIGluIEV1cm9wZSkuDQoJPiAgICAgICAgIE5vdGU6IHNvbWUgVm9JUCBTUCBoaWRlIGJl dHdlZW4gc21hbGwgSUxFQ3MgYW5kIGdldCBzdWNoIG51bWJlcg0KCT4gcmFuZ2VzDQoJPiAgICAg ICAgIHZpYSB0aGVtIChlLmcgVm9uYWdlLCBzaXBnYXRlLmRlLCAuLi4pDQoJPg0KCT4gICAgICAg ICBDYXNlIDI6IFNpbmNlIGFsbCBub3JtYWwgcnVsZXMgYXBwbHksIGFsc28gTE5QIGFwcGxpZXMs IHNvIHVzZXJzDQoJPiBtYXkgcG9ydA0KCT4gICAgICAgICB0aGVpciBudW1iZXJzIGJhY2sgYW5k IGZvcnRoIGJldHdlZW4gUFNUTiBhbmQgVm9JUCBTUA0KCT4NCgk+ICAgICAgICAgQ2FzZSAzOiBU aGUgcmVndWxhdG9yIHJlc2VydmVzIGEgc3BlY2lhbCBudW1iZXIgcmFuZ2UgZm9yIFZvSVANCgk+ ICgwNTAgaW4NCgk+ICAgICAgICAgSmFwYW4sIDA1eCBpbiBVSywgMDMyIGluIEdlcm1hbnkpLiBJ ZiB0aGVzZSBzZXJ2aWNlcyBhcmUgZGVjbGFyZWQNCgk+IG5vbi1QQVRTDQoJPiAgICAgICAgIE5Q IGRvZXMgbm90IGFwcGx5ICh0aGlzIGlzIHVuZGVyIGRpc2N1c3Npb24pLiBJbiBKYXBhbiB0aGVy ZSBpcw0KCT4gYWxzbyBhIGxpZ2h0ZXINCgk+ICAgICAgICAgcmVnaW1lIHJlZ2FyZGluZyBRb1Mu IFJlZ3VsYXRpb25zIGRpZmZlciBoZXJlIGluIGFsbCBjb3VudHJpZXMuDQoJPiAgICAgICAgIElu IHRoaXMgY2FzZSB0aGUgVm9JUCBTUCBhbHNvIGdldCBibG9ja3Mgb2YgbnVtYmVycyBhbmQgcm91 dGUNCgk+IHRoZW0gdG8gdGhlaXIgR1cuDQoJPiAgICAgICAgIEkga25vdywgaW4gdGhlIFVTIHRo ZXJlIGlzIG5vIHN1Y2ggbnVtYmVyIHJhbmdlLiBUaGUgcHJvYmxlbSBJDQoJPiBoYXZlIHdpdGgN Cgk+ICAgICAgICAgc3VjaCBhbiBhcHByb2FjaCBpcyB0aGF0IHRoZXJlIGFyZSBkaWZmZXJudCBy dWxlcyBpbiBldmVyeQ0KCT4gY291bnRyeSBhbmQgZW5kLXVzZXJzDQoJPiAgICAgICAgIGdldCBy ZXN0cmljdGVkIHNlcnZpY2VzLiAoZS5nIG5vIE5QLCBubyBhY2Nlc3MgdG8gZW1lcmdlbmNlDQoJ PiBzZXJ2aWNlcywgZXRjLg0KCT4gICAgICAgICBJTUhPIHRoaXMgd2lsbCBjYXVzZSBwcm9ibGVt cyBpbiB0aGUgZnV0dXJlDQoJPg0KCT4gICAgICAgICBDYXNlIDQuIHRoZSByZWd1bGF0b3IgcmVz ZXJ2ZXMgYSBzcGVjaWFsIG51bWJlciByYW5nZSBmb3INCgk+IEVOVU0tb25seSByb3V0ZWQNCgk+ ICAgICAgICAgbnVtYmVycy4gVGhpcyBzaG91bGQgYmUgZG9uZSBkaXJlY3RseSB0byB0aGUgZW5k LXVzZXIuIFRoZQ0KCT4gYWR2YW50YWdlIGlzDQoJPiAgICAgICAgIHRoYXQgeW91IGhhdmUgTlAg YnVpbHQtaW4sIHdpdGhvdXQgaGF2aW5nIHRvIGRlYWwgd2l0aCBub3JtYWwgTE5QDQoJPiBpc3N1 ZXMgYW5kDQoJPiAgICAgICAgIHRlY2hub2xvZ3ksIHNhdmluZyB0aGUgU1AgbXVjaCBlZmZvcnQu DQoJPg0KCT4gICAgICAgICBUaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGNhc2UgMyBhbmQgNCBpcyB0 aGF0IGluIGNhc2UgMyBubyBydWxlcw0KCT4gZXhpc3QgZm9yIE5QIGFuZA0KCT4gICAgICAgICBp bnRlcmNvbm5lY3Qgb24gSVAsIHNvIHlvdSBjcmVhdGUgVm9JUCBJc2xhbmQgdGhhdCBhcmUNCgk+ IGludGVyY29ubmVjdGVkIG9ubHkgdmlhDQoJPiAgICAgICAgIHRoZSBQU1ROIHBlciBkZWZhdWx0 LiBJZiB5b3UgaW50ZXJjb25uZWN0IG9uIElQLCB5b3UgY2FuIGRvIHRoaXMNCgk+IG9ubHkgY3Vy cmVudGx5DQoJPiAgICAgICAgIHdpdGggYmlsYXRlcmFsIGFncmVlbWVudHMuIEluIGNhc2UgNCB5 b3UgaGF2ZSBhdXRvbWF0aWNhbGx5IE5QDQoJPiBhbmQgYWxzbyBpbnRlcmNvbm5lY3QNCgk+ICAg ICAgICAgYmVjYXVzZSB5b3UgY2FuIHVzZSBFTlVNIGFsc28gb24gSVAgdG8gaW50ZXJjb25uZWN0 LiBUaGlzIGlzIEJUVw0KCT4gYWxzbyBkcmFmdGVkDQoJPiAgICAgICAgIGluIHRoZSBTSVAgRm9y dW0gU2VydmljZSBQcm92aWRlciBXRyBJbnRlcmNvbm5lY3QgQ29uc2Vuc3VzLg0KCT4NCgk+ICAg ICAgICAgPj5XaXRoIEVOVU0tb25seSBudW1iZXJzIHRoZXJlIGlzIG5vIG5lZWQgdG8gYXNzaWdu IGJsb2NrcyBvZg0KCT4gbnVtYmVycy4NCgk+ICAgICAgICAgPj5BbiBFTlVNLW9ubHkgbnVtYmVy IGlzIHRoZSBlcXVpdmFsZW50IG9mIGEgZG9tYWluIG5hbWUuIEl0IGlzDQoJPiBhc3NpZ25lZA0K CT4gICAgICAgICA+PnRvIHRoZSBlbmQtdXNlciBkaXJlY3RseSwgd2hvIGNob29zZXMgdGhlIFNQ LCBsaWtlIHdpdGggYQ0KCT4gc2VydmljZSBudW1iZXIuDQoJPiAgICAgICAgID4+WW91IGFsc28g ZG8gbm90IGFzc2lnbiBkb21haW4gbmFtZXMgaW4gYmxvY2tzLg0KCT4NCgk+ICAgICAgICAgPkkg dGhpbmsgdGhlcmUgaXMgYW4gaXNzdWUgaGVyZS4gIElmIHRoZSBTUHMgaG9sZCBtb3N0IG9mIHRo ZQ0KCT4gY3VycmVudCBOUEENCgk+ICAgICAgICAgPmJsb2NrcywgYW5kIHRoZXJlIGlzIGEgbWln cmF0aW9uIG9mIG1hbnkgdXNlcnMgZnJvbSBURE0gdG8gSVAsDQoJPiB0aGVuIGRvIHlvdQ0KCT4g ICAgICAgICA+bGVuZ3RoZW4gdGhlIG51bWJlciB0byAxMSBkaWdpdHMgdG8gZ2V0IG1vcmUsIG9y IGRvIHRoZSBTUHMgaGF2ZSB0bw0KCT4gICAgICAgICA+cmVsaW5xdWlzaCBudW1iZXJzPw0KCT4N Cgk+ICAgICAgICAgVGhpcyBhIHR5cGljYWwgTkFOUCBwcm9ibGVtLiBJbiB0aGUgTkFOUCB0aGVy ZSBpcyBvbmx5IGdlb2dyYXBoaWMNCgk+IGFyZWENCgk+ICAgICAgICAgY29kZXMgKHdpdGggdGhl IGV4Y2VwdGlvbiBvZiA4MDAgbnVtYmVycykuIEluIG1vc3Qgb3RoZXIgY291bnRyeQ0KCT4gdGhl cmUgYXJlDQoJPiAgICAgICAgIG1vcmUgbnVtYmVyIHR5cGVzOiB5b3UgaGF2ZSBnZW9ncmFwaGlj IGFuZCBub24tZ2VvZ3JhcGhpYyBudW1iZXJzLg0KCT4NCgk+ICAgICAgICAgTm9uLWdlbyBudW1i ZXJzIGFyZSBlZyBtb2JpbGUgbnVtYmVycywgcGVyc29uYWwgbnVtYmVycywgZXRjLiBUaGUNCgk+ IGFkdmFudGFnZQ0KCT4gICAgICAgICBoZXJlIGlzIHRoYXQgeW91IHJlbGlldmUgdGhlIHByZXNz dXJlIG9uIHRoZSBudW1iZXIgZXhoYXVzdCBoZXJlLg0KCT4gU2luY2UgZ2VvDQoJPiAgICAgICAg IG51bWJlcnMgYXJlIGdpdmVuIGF3YXkgaW4gYmxvY2tzLCB5b3UgaGF2ZSBhIGxvdCBvZiB1bnVz ZWQgbnVtYmVycy4NCgk+ICAgICAgICAgRWcgaW4gQXVzdHJpYSB0aGUgZ2VvIG51bWJlcnMgYXJl IHVzaW5nIHVwIGEgZ3JlYXQgY2h1bmsgb2YgdGhlDQoJPiBudW1iZXJzOg0KCT4gICAgICAgICB3 ZSBoYXZlIDExMDAgNC1kaWdpdCBhcmVhIGNvZGVzIHVzZWQgYmUgYXBwb3ggNCBNaW8gc3Vic2Ny aWJlcnMsDQoJPiAgICAgICAgIG9uIHRoZSBvdGhlciBoYW5kLCB3ZSBoYXZlIDUgKGZpdmUpIDMt ZGlnaXQgbW9iaWxlIG51bWJlciByYW5nZXMNCgk+ICAgICAgICAgdXNlZCBieSA0LDUgTWlvIHN1 YnNjcmliZXJzICg4MCUgb2YgdGhlbSBhcmUgYmVoaW5kIDIgbW9iaWxlDQoJPiAiYXJlYSIgY29k ZXMpLg0KCT4NCgk+ICAgICAgICAgVGhlIHJlYXNvbiBpcyBzaW1wbGU6IHRoZSBtb2JpbGUgbnVt YmVyIHJhbmdlcyBhcmUgZmxhdC4gU28gaWYgd2UNCgk+IGdpdmUgZWcNCgk+ICAgICAgICAgb25l IDMtZGlnaXQgbnVtYmVyIHJhbmdlIHRvIEVOVU0sIHdlIGNhbiBpbnN0YW50bHkgdXNlIHRoZW0g d2l0aA0KCT4gICAgICAgICBhZGRpdGlvbmFsIDctZGlnaXRzIGZvciA5Ljk5OS45OTkgc3Vic2Ny aWJlcnMuDQoJPg0KCT4gICAgICAgICByZWdhcmRzDQoJPg0KCT4gICAgICAgICBSaWNoYXJkDQoJ DQoJDQoNCg== _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 2 10:28:15 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 KAA13830 for ; Fri, 2 Apr 2004 10:28:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ND8-00036a-OS for enum-archive@odin.ietf.org; Fri, 02 Apr 2004 06:51:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32BpkOc011864 for enum-archive@odin.ietf.org; Fri, 2 Apr 2004 06:51:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9KBq-0003G7-Et; Fri, 02 Apr 2004 03:38:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Egv-0002rK-G7 for enum@optimus.ietf.org; Thu, 01 Apr 2004 21:45: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 VAA28444 for ; Thu, 1 Apr 2004 21:45:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Egs-0007ew-00 for enum@ietf.org; Thu, 01 Apr 2004 21:45:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9EZE-0005zg-00 for enum@ietf.org; Thu, 01 Apr 2004 21:38:03 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B9EMq-0003YF-00 for enum@ietf.org; Thu, 01 Apr 2004 21:25:12 -0500 Content-Class: urn:content-classes:message Subject: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 2 Apr 2004 04:24:45 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F162233C99@oefeg-s02.oefeg.loc> Thread-Topic: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQXXXtu22xhWhiAQ1OVZFYOT0PcHwAWLJbwABT5Y/AAExv7EQ== From: "Stastny Richard" To: "Pfautz, Penn L, ALABS" , "Michael Hammer" Cc: "James McEachern" , 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 UGVubiB3cm90ZToNCiANCj5JZiBJIHVuZGVyc3RhbmQgaXQgdGhlIHJvb3QgaXNzdWUgaXMgdGhp czoNCj5BbGwgRS4xNjQgbnVtYmVycyB3aWxsIGhhdmUgYSBQU1ROIHBvaW50LW9mLWludGVyZmFj ZSwgYnV0IGZvciBzb21lIG51bWJlcnMgdGhhdCBQT0kgaXMgYSBnYXRld2F5IHRvIElQLiBGdXJ0 aGVyIHNvbWUgPnN1YnNldCBvZiB0aGVzZSBudW1iZXJzIGFyZSBvbmVzIHRoYXQgd29uJ3QgYmUg YXNzaWduZWQgaWYgdGhleSdyZSBub3QgcmVhY2hhYmxlIHRocm91Z2ggSVAuIFNvLCBpbiBvcmRl ciB0byBhdm9pZCByb3V0aW5nID50byB0aGUgZGVmYXVsdCBnYXRld2F5IGFmdGVyIGFuIEVOVU0g cXVlcnkgdGhhdCByZXR1cm5zIG5vIHJlc3VsdCBiZWNhdXNlIHRoZSBudW1iZXIgaXMgdW5hc3Np Z25lZCwgcGVvcGxlIGFyZSA+c2Vla2luZyBzb21lIG1lY2hhbmlzbSB0byBwcm92aWRlIGEgcmVz cG9uc2UgdG8gdGhlIGluaXRpYWwgRU5VTSBxdWVyeSB0byBpbmRpY2F0ZSB0aGF0IGF0dGVtcHRz IHRvIHJvdXRlIHRocm91Z2ggdGhlID5QU1ROIHdpbGwgYmUgZnVpdGxlc3MuIEFuZCB0aGUgbmVl ZCBpcyB0byBkbyB0aGlzIHdpdGhvdXQgdHJlYWRpbmcgb24gdGhlIG9wdC1pbiBwcmluY2lwbGUu DQoNClBlcmZlY3RseSBjb3JyZWN0Lg0KDQo+SGVyZSdzIGEgdGhvdWdodCB3aGljaCB0aGUgbW9y ZSBETlMvREREUyBsaXRlcmF0ZSBtYXkgYmUgYWJsZSB0byBjb25maXJtIG9yIHNob290IGRvd246 DQo+QXQgVGllciAxLCBpbnN0ZWFkIG9mIHBvcHVsYXRpbmcgYW4gTlMgcmVjb3JkIHdpdGggdGhl IHRpZXIgMiBkZWxlZ2F0aW9uIGZvciBlYWNoIG51bWJlciBpbnN0ZWFkIHBvcHVsYXRlIGEgcGFp ciBvZiBub24tPnRlcm1pbmFsIE5BUFRSIHJlY29yZHMgd2l0aCBkaWZmZXJlbnQgc2VydmljZSBm aWVsZHMgKGUuZy4sICBFMlUgIGFuZCBFMkMpIHdoaWNoIHdvdWxkIHBvaW50IHRvIHRoZSBkb21h aW5zIGZvciB0aGUgZW5kID51c2VyIFRpZXIgMiBhbmQgY2FycmllciBUaWVyIDIgcmVzcGVjdGl2 ZWx5LiBJbiB0aGlzIHdheSwgYSBzaW5nbGUgcXVlcnkgd291bGQgcHJvdmlkZSBwb2ludGVycyBp bnRvIGJvdGggdHJlZXMgYW5kIGEgY2xpZW50ID5jb3VsZCBkZWNpZGUgd2hldGhlciB0byBwdXJz dWUgb25lIG9yIHRoZSBvdGhlciwgb3IgcG90ZW50aWFsbHkgYm90aC4gRm9yIG5vbi1hc3NpZ25l ZCAiRU5VTS1vbmx5IiBudW1iZXJzLCB0aGUgPmNhcnJpZXIgY291bGQgcG9wdWxhdGUgdGhlIEUy QyByZWNvcmQgb25seSB3aXRob3V0IHRyZWFkaW5nIG9uIHRoZSBwZXJvZ2F0aXZlcyBvZiB0aGUg ZW5kIHVzZXIgb3IgaGF2aW5nIHRvIGluc3RhbnRpYXRlIGEgPnNlcGFyYXRlIFRpZXIgMS4NCg0K VGhpcyBwcm9wb3NhbCBpcyBJTUhPIHZlcnkgc2ltaWxhciB0byB0aGUgcHJvcG9zYWwgb2YgdGhl IHNoYWRvdyB0cmVlLCBiZWNhdXNlIHlvdSB3b3VsZCBuZWVkIHNlcGFyYXRlDQp0cmVlcyBmb3Ig dXNlciBFTlVNIHRvbyAoeW91IGNhbm5vdCBwb2ludCB3aXRoIHRoZSBFMlUgbm9uLXRlcm1pbmFs cyBOQVBUUnMgaW4gZTE2NCAuYXJwYSwgYXQgbGVhc3QNCm5vdCB3aXRoIHRoZSBzYW1lIG51bWJl cikuIElmIHlvdSBsZWF2ZSBlMTY0LmFycGEgYXMgaXMgKGFuZCB3ZSBzaG91bGQgZG8gdGhpcyBm b3IgaGVhdmVucyBzYWtlIDstKSwNCml0IGNvdWxkIGJlIGltcGxlbWVudGVkIGluIHRoZSBmb2xs b3dpbmcgd2F5LiBZb3UgZmlyc3QgcXVlcnkgZTE2NC5hcnBhIGFzIHVzdWFsLCBvbmx5IGlmIHlv dSBkbyBub3QgZmluZA0KYW4gZW50cnkgdGhlcmUsIHlvdSBnbyB0byB0aGUgb3RoZXIgdHJlZS4g VGhpcyB0cmVlIGlzIGFkbWluc3RyYXRlIGJ5IHRoZSBzYW1lIHJ1bGVzIHRoYW4gZTE2NC5hcnBh Lg0KWW91IGVpdGhlciBmaW5kIGEgbm9ybWFsIE5BUFRSIChlLmcgZm9yIHVuYXNzaWduZWQgYmxv Y2tzIG9yIEVOVU0tb25seSBibG9ja3MpICwgb3IgYSBub24tdGVybWluYWwgTkFQVFIgDQpwb2lu dGluZyB0byBhIHNlcGFyYXRlIHRyZWUuIA0KVGhlc2UgdHJlZXMgY291bGQgZWl0aGVyIGJlIHNl dCB1cCBieSBjb3VudGllcyBhcyBhIHdob2xlIG9yIGJ5IGNhcnJpZXJzLCB0aGlzIGlzIGEgbmF0 aW9uYWwgbWF0dGVyLg0KDQo+U3VjaCBFMkMgcmVjb3JkcyBjb3VsZCBub3Qgb25seSBhZGRyZXNz IHRoZSBOb1BTVE4gaXNzdWUgYnV0IGFsc28gYmUgdGhlIGJhc2lzIGZvciBhIGNhcnJpZXIgb3Ig aW5mcmFzdHJ1Y3R1cmUgRU5VTSA+Y2FwYWJpbGl0eSB0aGF0IG1heSBiZWNvbWUgbW9yZSBpbXBv cnRhbnQgYXMgVm9JUCBtb3ZlcyBiZXlvbmQgYXJiaXRyYWdlIHRvIHdoZXJlIElQIGludGVyY29u bmVjdGlvbiBiZWNvbWVzIG5vcm0uDQoNCkluIHRoZSBmb3JtIGFib3ZlLCB5ZXMuDQoNClJpY2hh cmQNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZW51bS1hZG1pbkBpZXRm Lm9yZyBbbWFpbHRvOmVudW0tYWRtaW5AaWV0Zi5vcmddT24gQmVoYWxmIE9mDQpTdGFzdG55IFJp Y2hhcmQNClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwMSwgMjAwNCAyOjM2IEFNDQpUbzogTWljaGFl bCBIYW1tZXINCkNjOiBKYW1lcyBNY0VhY2hlcm47IGVudW1AaWV0Zi5vcmcNClN1YmplY3Q6IEFX OiBBVzogW0lwdGVsXSBGVzogW0VudW1dIFN1bW1hcnkgb24gTm9QU1ROIGRpY3Vzc2lvbg0KDQoN Ck1pa2Ugd3JvdGU6DQoNCiAgICAgICAgPj5GaXJzdCwgbm8gbnVtYmVyIGlzIG93bmVyIGJ5IGFu eWJvZHksIGl0IGlzIGFzc2lnbmVkIGJ5IElUVS1UIHRvIHRoZSBOUkEsDQogICAgICAgID4+YW5k IGFzc2lnbmVkIGluIHR1cm4gdG8gdGhlIFNQLCBhbmQgdGhlIFNQIGFzc2lnbmVzIGl0IHRvIHRo ZSBlbmQtdXNlciAoZm9yDQogICAgICAgID4+Z2VvZ3JhcGhpYyBudW1iZXJzLiBTZXJ2aWNlIG51 bWJlcnMgYXJlIGFscmVhZHkgYXNzaWduZWQgb25lLWJ5LW9uZQ0KICAgICAgICA+PnRvIHRoZSBl bmQtdXNlciBieSB0aGUgTlJBLCBubyBibG9ja3MsIG5vIGFuY2hvciBTUC4NCiAgICAgICANCiAg ICAgICAgPkhvdyBkb2VzIHRoaXMgd29yayBmb3IgbnVtYmVycyB0aGF0IHdlcmUgYXNzaWduZWQg dG8gYW4gU1AsIHRoYXQgdXNlZCB0byBiZQ0KICAgICAgICA+VERNLW9ubHksIGJ1dCB0aGVuIChv dmVyIHRpbWUpIGNvbnZlcnRzIHRvIGFuIElQLW9ubHkgbmV0d29yaz8gIFRoZSBTUHMgYXJlDQog ICAgICAgID52ZXJ5IGd1YXJkZWQgYWJvdXQgdGhlIEUuMTY0IG51bWJlcnMgYXNzaWduZWQgdG8g dGhlbS4gIFRoYXQgaXMgd2hhdCBJDQogICAgICAgID5tZWFudCBieSAib3duZWQuIiAgWW91IGFy ZSBzdWdnZXN0aW5nIHRoYXQgd2hlbiBhIHBlcnNvbiB3aXRoIGEgcGhvbmUNCiAgICAgICAgPm51 bWJlciBhc3NpZ25lZCBieSBhbiBTUCBtb3ZlcyB0byBhbiBJUC1iYXNlZCAicGhvbmUiIHRoYXQg dGhlIFNQIHdpbGwNCiAgICAgICAgPnJlbGlucXVpc2ggdGhhdCBwaG9uZSBudW1iZXIgYmFjayB0 byB0aGUgTlJBPyAgT3IgYXJlIHlvdSBzYXlpbmcgdGhhdA0KICAgICAgICA+bnVtYmVyIHBvcnRh YmlsaXR5IGRvZXNuJ3Qgd29yayBiZXR3ZWVuIFRETSBhbmQgSVAgd29ybGRzPw0KICAgICAgICAN CiAgICAgICAgV2UgYXJlIHRhbGtpbmcgaGVyZSBhYm91dCBmb3VyIGRpZmZlcmVudCB0aGluZ3Mg aGVyZToNCiAgICAgICAgQ2FzZSAxOiAgYSBWb0lQIHByb3ZpZGVyIGlzIGFsc28gYW4gSUxFQyAo ZWcgYSBjYWJsZSBvcGVyYXRvcikgYW5kIGdldHMgYQ0KICAgICAgICBudW1iZXIgKGdlb2dyYXBo aWMpIHJhbmdlIChibG9jaykgYXNzaWduZWQgYW5kIGFzc2lnbmVzIHRoZW0gdG8gaGlzIHVzZXJz Lg0KICAgICAgICBTaW5jZSBudW1iZXIgYXNzaWduZW1lbnQgaXMgdGVjaG5vbG9neSBpbmRlcGVu ZGVudCwgdGhlcmUgaXMgbm8gcHJvYmxlbSBoZXJlLA0KICAgICAgICBhcyBsb25nIGFzIHRoZSBT UCBpcyBwcm92aWRpbmcgYSB0ZWxlcGhvbnkgc2VydmljZSBhcyB1c3VhbCAod2UgY2FsbCB0aGlz IFBBVFMgLQ0KICAgICAgICBQdWJsaWNseSBBdmFpbGFibGUgVGVsZXBob255IFNlcnZpY2UgaW4g RXVyb3BlKS4NCiAgICAgICAgTm90ZTogc29tZSBWb0lQIFNQIGhpZGUgYmV0d2VlbiBzbWFsbCBJ TEVDcyBhbmQgZ2V0IHN1Y2ggbnVtYmVyIHJhbmdlcw0KICAgICAgICB2aWEgdGhlbSAoZS5nIFZv bmFnZSwgc2lwZ2F0ZS5kZSwgLi4uKQ0KICAgICAgICANCiAgICAgICAgQ2FzZSAyOiBTaW5jZSBh bGwgbm9ybWFsIHJ1bGVzIGFwcGx5LCBhbHNvIExOUCBhcHBsaWVzLCBzbyB1c2VycyBtYXkgcG9y dA0KICAgICAgICB0aGVpciBudW1iZXJzIGJhY2sgYW5kIGZvcnRoIGJldHdlZW4gUFNUTiBhbmQg Vm9JUCBTUA0KICAgICAgICANCiAgICAgICAgQ2FzZSAzOiBUaGUgcmVndWxhdG9yIHJlc2VydmVz IGEgc3BlY2lhbCBudW1iZXIgcmFuZ2UgZm9yIFZvSVAgKDA1MCBpbg0KICAgICAgICBKYXBhbiwg MDV4IGluIFVLLCAwMzIgaW4gR2VybWFueSkuIElmIHRoZXNlIHNlcnZpY2VzIGFyZSBkZWNsYXJl ZCBub24tUEFUUw0KICAgICAgICBOUCBkb2VzIG5vdCBhcHBseSAodGhpcyBpcyB1bmRlciBkaXNj dXNzaW9uKS4gSW4gSmFwYW4gdGhlcmUgaXMgYWxzbyBhIGxpZ2h0ZXINCiAgICAgICAgcmVnaW1l IHJlZ2FyZGluZyBRb1MuIFJlZ3VsYXRpb25zIGRpZmZlciBoZXJlIGluIGFsbCBjb3VudHJpZXMu DQogICAgICAgIEluIHRoaXMgY2FzZSB0aGUgVm9JUCBTUCBhbHNvIGdldCBibG9ja3Mgb2YgbnVt YmVycyBhbmQgcm91dGUgdGhlbSB0byB0aGVpciBHVy4NCiAgICAgICAgSSBrbm93LCBpbiB0aGUg VVMgdGhlcmUgaXMgbm8gc3VjaCBudW1iZXIgcmFuZ2UuIFRoZSBwcm9ibGVtIEkgaGF2ZSB3aXRo DQogICAgICAgIHN1Y2ggYW4gYXBwcm9hY2ggaXMgdGhhdCB0aGVyZSBhcmUgZGlmZmVybnQgcnVs ZXMgaW4gZXZlcnkgY291bnRyeSBhbmQgZW5kLXVzZXJzDQogICAgICAgIGdldCByZXN0cmljdGVk IHNlcnZpY2VzLiAoZS5nIG5vIE5QLCBubyBhY2Nlc3MgdG8gZW1lcmdlbmNlIHNlcnZpY2VzLCBl dGMuDQogICAgICAgIElNSE8gdGhpcyB3aWxsIGNhdXNlIHByb2JsZW1zIGluIHRoZSBmdXR1cmUN CiAgICAgICAgDQogICAgICAgIENhc2UgNC4gdGhlIHJlZ3VsYXRvciByZXNlcnZlcyBhIHNwZWNp YWwgbnVtYmVyIHJhbmdlIGZvciBFTlVNLW9ubHkgcm91dGVkDQogICAgICAgIG51bWJlcnMuIFRo aXMgc2hvdWxkIGJlIGRvbmUgZGlyZWN0bHkgdG8gdGhlIGVuZC11c2VyLiBUaGUgYWR2YW50YWdl IGlzDQogICAgICAgIHRoYXQgeW91IGhhdmUgTlAgYnVpbHQtaW4sIHdpdGhvdXQgaGF2aW5nIHRv IGRlYWwgd2l0aCBub3JtYWwgTE5QIGlzc3VlcyBhbmQNCiAgICAgICAgdGVjaG5vbG9neSwgc2F2 aW5nIHRoZSBTUCBtdWNoIGVmZm9ydC4NCiAgICAgICAgDQogICAgICAgIFRoZSBkaWZmZXJlbmNl IGJldHdlZW4gY2FzZSAzIGFuZCA0IGlzIHRoYXQgaW4gY2FzZSAzIG5vIHJ1bGVzIGV4aXN0IGZv ciBOUCBhbmQNCiAgICAgICAgaW50ZXJjb25uZWN0IG9uIElQLCBzbyB5b3UgY3JlYXRlIFZvSVAg SXNsYW5kIHRoYXQgYXJlIGludGVyY29ubmVjdGVkIG9ubHkgdmlhDQogICAgICAgIHRoZSBQU1RO IHBlciBkZWZhdWx0LiBJZiB5b3UgaW50ZXJjb25uZWN0IG9uIElQLCB5b3UgY2FuIGRvIHRoaXMg b25seSBjdXJyZW50bHkNCiAgICAgICAgd2l0aCBiaWxhdGVyYWwgYWdyZWVtZW50cy4gSW4gY2Fz ZSA0IHlvdSBoYXZlIGF1dG9tYXRpY2FsbHkgTlAgYW5kIGFsc28gaW50ZXJjb25uZWN0DQogICAg ICAgIGJlY2F1c2UgeW91IGNhbiB1c2UgRU5VTSBhbHNvIG9uIElQIHRvIGludGVyY29ubmVjdC4g VGhpcyBpcyBCVFcgYWxzbyBkcmFmdGVkDQogICAgICAgIGluIHRoZSBTSVAgRm9ydW0gU2Vydmlj ZSBQcm92aWRlciBXRyBJbnRlcmNvbm5lY3QgQ29uc2Vuc3VzLg0KDQogICAgICAgID4+V2l0aCBF TlVNLW9ubHkgbnVtYmVycyB0aGVyZSBpcyBubyBuZWVkIHRvIGFzc2lnbiBibG9ja3Mgb2YgbnVt YmVycy4NCiAgICAgICAgPj5BbiBFTlVNLW9ubHkgbnVtYmVyIGlzIHRoZSBlcXVpdmFsZW50IG9m IGEgZG9tYWluIG5hbWUuIEl0IGlzIGFzc2lnbmVkDQogICAgICAgID4+dG8gdGhlIGVuZC11c2Vy IGRpcmVjdGx5LCB3aG8gY2hvb3NlcyB0aGUgU1AsIGxpa2Ugd2l0aCBhIHNlcnZpY2UgbnVtYmVy Lg0KICAgICAgICA+PllvdSBhbHNvIGRvIG5vdCBhc3NpZ24gZG9tYWluIG5hbWVzIGluIGJsb2Nr cy4NCiAgICAgICANCiAgICAgICAgPkkgdGhpbmsgdGhlcmUgaXMgYW4gaXNzdWUgaGVyZS4gIElm IHRoZSBTUHMgaG9sZCBtb3N0IG9mIHRoZSBjdXJyZW50IE5QQQ0KICAgICAgICA+YmxvY2tzLCBh bmQgdGhlcmUgaXMgYSBtaWdyYXRpb24gb2YgbWFueSB1c2VycyBmcm9tIFRETSB0byBJUCwgdGhl biBkbyB5b3UNCiAgICAgICAgPmxlbmd0aGVuIHRoZSBudW1iZXIgdG8gMTEgZGlnaXRzIHRvIGdl dCBtb3JlLCBvciBkbyB0aGUgU1BzIGhhdmUgdG8NCiAgICAgICAgPnJlbGlucXVpc2ggbnVtYmVy cz8NCg0KICAgICAgICBUaGlzIGEgdHlwaWNhbCBOQU5QIHByb2JsZW0uIEluIHRoZSBOQU5QIHRo ZXJlIGlzIG9ubHkgZ2VvZ3JhcGhpYyBhcmVhDQogICAgICAgIGNvZGVzICh3aXRoIHRoZSBleGNl cHRpb24gb2YgODAwIG51bWJlcnMpLiBJbiBtb3N0IG90aGVyIGNvdW50cnkgdGhlcmUgYXJlDQog ICAgICAgIG1vcmUgbnVtYmVyIHR5cGVzOiB5b3UgaGF2ZSBnZW9ncmFwaGljIGFuZCBub24tZ2Vv Z3JhcGhpYyBudW1iZXJzLg0KDQogICAgICAgIE5vbi1nZW8gbnVtYmVycyBhcmUgZWcgbW9iaWxl IG51bWJlcnMsIHBlcnNvbmFsIG51bWJlcnMsIGV0Yy4gVGhlIGFkdmFudGFnZQ0KICAgICAgICBo ZXJlIGlzIHRoYXQgeW91IHJlbGlldmUgdGhlIHByZXNzdXJlIG9uIHRoZSBudW1iZXIgZXhoYXVz dCBoZXJlLiBTaW5jZSBnZW8NCiAgICAgICAgbnVtYmVycyBhcmUgZ2l2ZW4gYXdheSBpbiBibG9j a3MsIHlvdSBoYXZlIGEgbG90IG9mIHVudXNlZCBudW1iZXJzLg0KICAgICAgICBFZyBpbiBBdXN0 cmlhIHRoZSBnZW8gbnVtYmVycyBhcmUgdXNpbmcgdXAgYSBncmVhdCBjaHVuayBvZiB0aGUgbnVt YmVyczoNCiAgICAgICAgd2UgaGF2ZSAxMTAwIDQtZGlnaXQgYXJlYSBjb2RlcyB1c2VkIGJlIGFw cG94IDQgTWlvIHN1YnNjcmliZXJzLA0KICAgICAgICBvbiB0aGUgb3RoZXIgaGFuZCwgd2UgaGF2 ZSA1IChmaXZlKSAzLWRpZ2l0IG1vYmlsZSBudW1iZXIgcmFuZ2VzDQogICAgICAgIHVzZWQgYnkg NCw1IE1pbyBzdWJzY3JpYmVycyAoODAlIG9mIHRoZW0gYXJlIGJlaGluZCAyIG1vYmlsZSAiYXJl YSIgY29kZXMpLg0KDQogICAgICAgIFRoZSByZWFzb24gaXMgc2ltcGxlOiB0aGUgbW9iaWxlIG51 bWJlciByYW5nZXMgYXJlIGZsYXQuIFNvIGlmIHdlIGdpdmUgZWcNCiAgICAgICAgb25lIDMtZGln aXQgbnVtYmVyIHJhbmdlIHRvIEVOVU0sIHdlIGNhbiBpbnN0YW50bHkgdXNlIHRoZW0gd2l0aA0K ICAgICAgICBhZGRpdGlvbmFsIDctZGlnaXRzIGZvciA5Ljk5OS45OTkgc3Vic2NyaWJlcnMuDQog ICAgICAgDQogICAgICAgIHJlZ2FyZHMNCg0KICAgICAgICBSaWNoYXJkDQoNCnp7eCVeeghtPyAw J35mZlgp36MNCg0KDQo= _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 2 10:28: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 KAA13848 for ; Fri, 2 Apr 2004 10:28: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 1B9NI5-0003IV-P2 for enum-archive@odin.ietf.org; Fri, 02 Apr 2004 06:56:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32BurL1012667 for enum-archive@odin.ietf.org; Fri, 2 Apr 2004 06:56:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9KBv-0003ID-UL; Fri, 02 Apr 2004 03:38:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Ehm-0002zf-Sj for enum@optimus.ietf.org; Thu, 01 Apr 2004 21:46:50 -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 VAA28596 for ; Thu, 1 Apr 2004 21:46:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Ehj-00003V-00 for enum@ietf.org; Thu, 01 Apr 2004 21:46:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Edu-00070I-00 for enum@ietf.org; Thu, 01 Apr 2004 21:42:52 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B9EUI-0004y8-00 for enum@ietf.org; Thu, 01 Apr 2004 21:32:54 -0500 Content-Class: urn:content-classes:message Subject: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 2 Apr 2004 04:32:27 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F162233C9A@oefeg-s02.oefeg.loc> Thread-Topic: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQYOGv8tWiee/jwTCe5OC1awoJUkQAIXlSm From: "Stastny Richard" To: "James McEachern" , "Michael Hammer" , "Pfautz, Penn L, ALABS" 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 SmltIHdyb3RlOg0KDQoJSWYgdGhlIEUuMTY0IG51bWJlciBoYXMgYmVlbiBhc3NpZ25lZCB0byBh IFNQIHByb3ZpZGluZyBhIFBBVFMsIHRoZW4gdGhlIFBTVE4gd2lsbCAobXVzdCAtIGJlY2F1c2Ug b2Ygb3B0LWluKSBhbHdheXMga25vdyBob3cgdG8gcm91dGUgdG8gdGhlIGFwcHJvcHJpYXRlIFNQ LCBhbmQgdGhlIFNQIGluIHR1cm4ga25vd3MgaG93IHRvIHJvdXRlIHRvIHRoZSBkZXZpY2UuIElm IHRoZSBudW1iZXIgaXMgYW4gRU5VTSBvbmx5IG51bWJlciwgdGhlbiB0aGUgUFNUTiB3aWxsIG5l ZWQgdG8ga25vdyB0aGlzIChib3RoIHRoZSBmYWN0IHRoYXQgaXQgaXMgYSB2YWxpZCBudW1iZXIg c28gaXQgZG9lcyBub3QgcmVqZWN0IGl0LCBhbmQgdGhlIGZhY3QgdGhhdCBpdCBpcyBhbiBFTlVN LW9ubHkgbnVtYmVyIHNvIHRoYXQgaXQgY2FuIHJvdXRlIGl0IHRvIGFuIEVOVU0gZW5hYmxlZCBH VykuIFRoZSBQU1ROIHdpbGwgYmUgYWJsZSB0byBkZXRlcm1pbmUgdGhpcyB1c2luZyBleGlzdGlu ZyByb3V0aW5nICYgdHJhbnNsYXRpb24gdGVjaG5pcXVlcyAtIG5vdGhpbmcgbW9yZSBpcyByZXF1 aXJlZC4NCg0KCVNvIHRoZSBlbnRpcmUgcHJvYmxlbSBjb21lcyBkb3duIHRvIGhvdyB0aGUgVm9J UCBuZXR3b3JrIGNhbiByZWNvZ25pemUgdGhhdCBhIG51bWJlciBpcyBhbiAiRU5VTS1vbmx5IiBu dW1iZXIsIGFuZCBub3Qgcm91dGUgdGhpcyB0byB0aGUgUFNUTiBpZiB0aGVyZSBpcyBubyBFTlVN IGVudHJ5LiBGb3IgYWxsIG90aGVyIGNhc2VzIHJvdXRpbmcgdG8gdGhlIFBTVE4gd29ya3MgZmlu ZS4gVGhpcyBtZWFucyB0aGF0IHdoYXRldmVyIHNvbHV0aW9uIHdlIGNvbWUgdXAgd2l0aCwgaXQg aXMgb25seSBuZWNlc3NhcnkgdG8gYXBwbHkgaXQgdG8gRU5VTS1vbmx5IG51bWJlcnMuIChXZSAq bWF5KiBkZWNpZGUgaXQgaXMgdmFsdWFibGUgdG8gYWxzbyBhcHBseSBpdCB0byBvdGhlciBudW1i ZXJzLCBidXQgaWYgaXQgY29tcGxpY2F0ZXMgdGhpbmdzIHRoaXMgaXMgbm90IG5lY2Vzc2FyeS4p DQoNCglBbSBJIG1pc3Npbmcgc29tZXRoaW5nPyANCg0KCT5SaWNoYXJkOg0KCU5vLCB0aGlzIGlz IHRoZSBwcmltZSByZXF1aXJlbWVudCwgYWxsIG90aGVyIHRoaW5ncyBhcmUgbmljZSB0byBoYXZl LiBPbiB0aGUNCglvdGhlciBoYW5kLCBpZiB3ZSBmaW5kIGEgc29sdXRpb24gd2hpY2ggaXMgYWxz byBhdXRvbWF0aWNhbGx5IHNvbHZpbmcgdGhlDQoJb3RoZXIgbmljZXRpZXMsIHdlIGNhb3VsZCB1 c2UgaXQgZm9yIHRoaXMgYWxzby4gSSB3aWxsIHRyeSB0byBzdW0gdXAgdGhlIHByb3Bvc2VkDQoJ c29sdXRpb25zIG5leHQgd2Vlaywgc28gd2UgY2FuIGRlY2lkZSBvbiB0aGUgYmVzdCB3YXkgZm9y d2FyZC4NCgkNCglJIHRhbGtlZCB0byBSaWNoIFNob2NrZXkgdG9kYXkgYW5kIHRoZSBwbGFuIGlz IHRvIGhhdmUgYSBwcmluY2lwYWwgaWRlYQ0KCXdpdGhpbiB0aGUgbmV4dCB3ZWVrcyB0byBoYXZl IHRoaXMgd3JpdHRlbiBkb3duIGZvciBTYW4gRGllZ28gaW4gdGltZS4NCg0KCVJpY2hhcmQNCg0K CSANCg0KCUppbSANCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IE1pY2hh ZWwgSGFtbWVyIFttYWlsdG86bWhhbW1lckBjaXNjby5jb21dIA0KCVNlbnQ6IFRodXJzZGF5LCBB cHJpbCAwMSwgMjAwNCAzOjU4IFBNIA0KCVRvOiBQZmF1dHosIFBlbm4gTCwgQUxBQlMgDQoJQ2M6 IFN0YXN0bnkgUmljaGFyZDsgTWNFYWNoZXJuLCBKYW1lcyBbQ0FSOjVOMDA6RVhDSF07IGVudW1A aWV0Zi5vcmcgDQoJU3ViamVjdDogUkU6IEFXOiBbSXB0ZWxdIEZXOiBbRW51bV0gU3VtbWFyeSBv biBOb1BTVE4gZGljdXNzaW9uIA0KDQoJVGhpcyBzb3VuZHMgcmVhc29uYWJsZSB0byBtZSwgYnV0 IEkgd291bGQgcmF0aGVyIGhlYXIgZnJvbSB0aGUgRE5TIGV4cGVydHMuIA0KDQoJTXkgYXNzdW1w dGlvbiwgYXMgeW91IG5vdGUgYmVsb3csIHdhcyB0aGF0IGlmIHRoZSBudW1iZXIgd2FzIG5vdCBp biBFTlVNLCANCgl0aGVuIHRoZSBvbmx5IGVsZW1lbnQgdGhhdCBrbm93cyB3aGV0aGVyIHRoZSBu dW1iZXIgaXMgYXNzaWduZWQgYW5kIA0KCXJlYWNoYWJsZSBpcyB0aGUgb3BlcmF0b3IgUFNUTi1J UCBHVyB0aGF0IGhhcyBhIGNvbmZpZ3VyZWQgdHJhbnNsYXRpb24gb3IgDQoJa25vd3MgdGhhdCB0 aGUgbnVtYmVyIGlzIHVuYXNzaWduZWQuIA0KDQoJTWlrZSANCg0KDQoJQXQgMTI6MTEgUE0gNC8x LzIwMDQgLTA1MDAsIFBmYXV0eiwgUGVubiBMLCBBTEFCUyB3cm90ZTogDQoJPklmIEkgdW5kZXJz dGFuZCBpdCB0aGUgcm9vdCBpc3N1ZSBpcyB0aGlzOiANCgk+QWxsIEUuMTY0IG51bWJlcnMgd2ls bCBoYXZlIGEgUFNUTiBwb2ludC1vZi1pbnRlcmZhY2UsIGJ1dCBmb3Igc29tZSANCgk+bnVtYmVy cyB0aGF0IFBPSSBpcyBhIGdhdGV3YXkgdG8gSVAuIEZ1cnRoZXIgc29tZSBzdWJzZXQgb2YgdGhl c2UgbnVtYmVycyANCgk+YXJlIG9uZXMgdGhhdCB3b24ndCBiZSBhc3NpZ25lZCBpZiB0aGV5J3Jl IG5vdCByZWFjaGFibGUgdGhyb3VnaCBJUC4gU28sIA0KCT5pbiBvcmRlciB0byBhdm9pZCByb3V0 aW5nIHRvIHRoZSBkZWZhdWx0IGdhdGV3YXkgYWZ0ZXIgYW4gRU5VTSBxdWVyeSB0aGF0IA0KCT5y ZXR1cm5zIG5vIHJlc3VsdCBiZWNhdXNlIHRoZSBudW1iZXIgaXMgdW5hc3NpZ25lZCwgcGVvcGxl IGFyZSBzZWVraW5nIA0KCT5zb21lIG1lY2hhbmlzbSB0byBwcm92aWRlIGEgcmVzcG9uc2UgdG8g dGhlIGluaXRpYWwgRU5VTSBxdWVyeSB0byBpbmRpY2F0ZSANCgk+dGhhdCBhdHRlbXB0cyB0byBy b3V0ZSB0aHJvdWdoIHRoZSBQU1ROIHdpbGwgYmUgZnVpdGxlc3MuIEFuZCB0aGUgbmVlZCBpcyAN Cgk+dG8gZG8gdGhpcyB3aXRob3V0IHRyZWFkaW5nIG9uIHRoZSBvcHQtaW4gcHJpbmNpcGxlLiAN Cgk+IA0KCT5IZXJlJ3MgYSB0aG91Z2h0IHdoaWNoIHRoZSBtb3JlIEROUy9ERERTIGxpdGVyYXRl IG1heSBiZSBhYmxlIHRvIGNvbmZpcm0gDQoJPm9yIHNob290IGRvd246IA0KCT5BdCBUaWVyIDEs IGluc3RlYWQgb2YgcG9wdWxhdGluZyBhbiBOUyByZWNvcmQgd2l0aCB0aGUgdGllciAyIGRlbGVn YXRpb24gDQoJPmZvciBlYWNoIG51bWJlciBpbnN0ZWFkIHBvcHVsYXRlIGEgcGFpciBvZiBub24t dGVybWluYWwgTkFQVFIgcmVjb3JkcyB3aXRoIA0KCT5kaWZmZXJlbnQgc2VydmljZSBmaWVsZHMg KGUuZy4sICBFMlUgIGFuZCBFMkMpIHdoaWNoIHdvdWxkIHBvaW50IHRvIHRoZSANCgk+ZG9tYWlu cyBmb3IgdGhlIGVuZCB1c2VyIFRpZXIgMiBhbmQgY2FycmllciBUaWVyIDIgcmVzcGVjdGl2ZWx5 LiBJbiB0aGlzIA0KCT53YXksIGEgc2luZ2xlIHF1ZXJ5IHdvdWxkIHByb3ZpZGUgcG9pbnRlcnMg aW50byBib3RoIHRyZWVzIGFuZCBhIGNsaWVudCANCgk+Y291bGQgZGVjaWRlIHdoZXRoZXIgdG8g cHVyc3VlIG9uZSBvciB0aGUgb3RoZXIsIG9yIHBvdGVudGlhbGx5IGJvdGguIEZvciANCgk+bm9u LWFzc2lnbmVkICJFTlVNLW9ubHkiIG51bWJlcnMsIHRoZSBjYXJyaWVyIGNvdWxkIHBvcHVsYXRl IHRoZSBFMkMgDQoJPnJlY29yZCBvbmx5IHdpdGhvdXQgdHJlYWRpbmcgb24gdGhlIHBlcm9nYXRp dmVzIG9mIHRoZSBlbmQgdXNlciBvciBoYXZpbmcgDQoJPnRvIGluc3RhbnRpYXRlIGEgc2VwYXJh dGUgVGllciAxLiANCgk+U3VjaCBFMkMgcmVjb3JkcyBjb3VsZCBub3Qgb25seSBhZGRyZXNzIHRo ZSBOb1BTVE4gaXNzdWUgYnV0IGFsc28gYmUgdGhlIA0KCT5iYXNpcyBmb3IgYSBjYXJyaWVyIG9y IGluZnJhc3RydWN0dXJlIEVOVU0gY2FwYWJpbGl0eSB0aGF0IG1heSBiZWNvbWUgbW9yZSANCgk+ aW1wb3J0YW50IGFzIFZvSVAgbW92ZXMgYmV5b25kIGFyYml0cmFnZSB0byB3aGVyZSBJUCBpbnRl cmNvbm5lY3Rpb24gDQoJPmJlY29tZXMgbm9ybS4gDQoJPiANCgk+UGVubiBQZmF1dHogDQoJPiAN Cgk+IA0KCT4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCgk+RnJvbTogZW51bS1hZG1pbkBp ZXRmLm9yZyBbbWFpbHRvOmVudW0tYWRtaW5AaWV0Zi5vcmddT24gQmVoYWxmIE9mIA0KCT5TdGFz dG55IFJpY2hhcmQgDQoJPlNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwMSwgMjAwNCAyOjM2IEFNIA0K CT5UbzogTWljaGFlbCBIYW1tZXIgDQoJPkNjOiBKYW1lcyBNY0VhY2hlcm47IGVudW1AaWV0Zi5v cmcgDQoJPlN1YmplY3Q6IEFXOiBBVzogW0lwdGVsXSBGVzogW0VudW1dIFN1bW1hcnkgb24gTm9Q U1ROIGRpY3Vzc2lvbiANCgk+IA0KCT4gDQoJPk1pa2Ugd3JvdGU6IA0KCT4gDQoJPiAgICAgICAg ID4+Rmlyc3QsIG5vIG51bWJlciBpcyBvd25lciBieSBhbnlib2R5LCBpdCBpcyBhc3NpZ25lZCBi eSBJVFUtVCANCgk+IHRvIHRoZSBOUkEsIA0KCT4gICAgICAgICA+PmFuZCBhc3NpZ25lZCBpbiB0 dXJuIHRvIHRoZSBTUCwgYW5kIHRoZSBTUCBhc3NpZ25lcyBpdCB0byB0aGUgDQoJPiBlbmQtdXNl ciAoZm9yIA0KCT4gICAgICAgICA+Pmdlb2dyYXBoaWMgbnVtYmVycy4gU2VydmljZSBudW1iZXJz IGFyZSBhbHJlYWR5IGFzc2lnbmVkIG9uZS1ieS1vbmUgDQoJPiAgICAgICAgID4+dG8gdGhlIGVu ZC11c2VyIGJ5IHRoZSBOUkEsIG5vIGJsb2Nrcywgbm8gYW5jaG9yIFNQLiANCgk+IA0KCT4gICAg ICAgICA+SG93IGRvZXMgdGhpcyB3b3JrIGZvciBudW1iZXJzIHRoYXQgd2VyZSBhc3NpZ25lZCB0 byBhbiBTUCwgdGhhdCANCgk+IHVzZWQgdG8gYmUgDQoJPiAgICAgICAgID5URE0tb25seSwgYnV0 IHRoZW4gKG92ZXIgdGltZSkgY29udmVydHMgdG8gYW4gSVAtb25seSANCgk+IG5ldHdvcms/ICBU aGUgU1BzIGFyZSANCgk+ICAgICAgICAgPnZlcnkgZ3VhcmRlZCBhYm91dCB0aGUgRS4xNjQgbnVt YmVycyBhc3NpZ25lZCB0byB0aGVtLiAgVGhhdCBpcyANCgk+IHdoYXQgSSANCgk+ICAgICAgICAg Pm1lYW50IGJ5ICJvd25lZC4iICBZb3UgYXJlIHN1Z2dlc3RpbmcgdGhhdCB3aGVuIGEgcGVyc29u IHdpdGggYSANCgk+IHBob25lIA0KCT4gICAgICAgICA+bnVtYmVyIGFzc2lnbmVkIGJ5IGFuIFNQ IG1vdmVzIHRvIGFuIElQLWJhc2VkICJwaG9uZSIgdGhhdCB0aGUgDQoJPiBTUCB3aWxsIA0KCT4g ICAgICAgICA+cmVsaW5xdWlzaCB0aGF0IHBob25lIG51bWJlciBiYWNrIHRvIHRoZSBOUkE/ICBP ciBhcmUgeW91IHNheWluZyANCgk+IHRoYXQgDQoJPiAgICAgICAgID5udW1iZXIgcG9ydGFiaWxp dHkgZG9lc24ndCB3b3JrIGJldHdlZW4gVERNIGFuZCBJUCB3b3JsZHM/IA0KCT4gDQoJPiAgICAg ICAgIFdlIGFyZSB0YWxraW5nIGhlcmUgYWJvdXQgZm91ciBkaWZmZXJlbnQgdGhpbmdzIGhlcmU6 IA0KCT4gICAgICAgICBDYXNlIDE6ICBhIFZvSVAgcHJvdmlkZXIgaXMgYWxzbyBhbiBJTEVDIChl ZyBhIGNhYmxlIG9wZXJhdG9yKSANCgk+IGFuZCBnZXRzIGEgDQoJPiAgICAgICAgIG51bWJlciAo Z2VvZ3JhcGhpYykgcmFuZ2UgKGJsb2NrKSBhc3NpZ25lZCBhbmQgYXNzaWduZXMgdGhlbSB0byAN Cgk+IGhpcyB1c2Vycy4gDQoJPiAgICAgICAgIFNpbmNlIG51bWJlciBhc3NpZ25lbWVudCBpcyB0 ZWNobm9sb2d5IGluZGVwZW5kZW50LCB0aGVyZSBpcyBubyANCgk+IHByb2JsZW0gaGVyZSwgDQoJ PiAgICAgICAgIGFzIGxvbmcgYXMgdGhlIFNQIGlzIHByb3ZpZGluZyBhIHRlbGVwaG9ueSBzZXJ2 aWNlIGFzIHVzdWFsICh3ZSANCgk+IGNhbGwgdGhpcyBQQVRTIC0gDQoJPiAgICAgICAgIFB1Ymxp Y2x5IEF2YWlsYWJsZSBUZWxlcGhvbnkgU2VydmljZSBpbiBFdXJvcGUpLiANCgk+ICAgICAgICAg Tm90ZTogc29tZSBWb0lQIFNQIGhpZGUgYmV0d2VlbiBzbWFsbCBJTEVDcyBhbmQgZ2V0IHN1Y2gg bnVtYmVyIA0KCT4gcmFuZ2VzIA0KCT4gICAgICAgICB2aWEgdGhlbSAoZS5nIFZvbmFnZSwgc2lw Z2F0ZS5kZSwgLi4uKSANCgk+IA0KCT4gICAgICAgICBDYXNlIDI6IFNpbmNlIGFsbCBub3JtYWwg cnVsZXMgYXBwbHksIGFsc28gTE5QIGFwcGxpZXMsIHNvIHVzZXJzIA0KCT4gbWF5IHBvcnQgDQoJ PiAgICAgICAgIHRoZWlyIG51bWJlcnMgYmFjayBhbmQgZm9ydGggYmV0d2VlbiBQU1ROIGFuZCBW b0lQIFNQIA0KCT4gDQoJPiAgICAgICAgIENhc2UgMzogVGhlIHJlZ3VsYXRvciByZXNlcnZlcyBh IHNwZWNpYWwgbnVtYmVyIHJhbmdlIGZvciBWb0lQIA0KCT4gKDA1MCBpbiANCgk+ICAgICAgICAg SmFwYW4sIDA1eCBpbiBVSywgMDMyIGluIEdlcm1hbnkpLiBJZiB0aGVzZSBzZXJ2aWNlcyBhcmUg ZGVjbGFyZWQgDQoJPiBub24tUEFUUyANCgk+ICAgICAgICAgTlAgZG9lcyBub3QgYXBwbHkgKHRo aXMgaXMgdW5kZXIgZGlzY3Vzc2lvbikuIEluIEphcGFuIHRoZXJlIGlzIA0KCT4gYWxzbyBhIGxp Z2h0ZXIgDQoJPiAgICAgICAgIHJlZ2ltZSByZWdhcmRpbmcgUW9TLiBSZWd1bGF0aW9ucyBkaWZm ZXIgaGVyZSBpbiBhbGwgY291bnRyaWVzLiANCgk+ICAgICAgICAgSW4gdGhpcyBjYXNlIHRoZSBW b0lQIFNQIGFsc28gZ2V0IGJsb2NrcyBvZiBudW1iZXJzIGFuZCByb3V0ZSANCgk+IHRoZW0gdG8g dGhlaXIgR1cuIA0KCT4gICAgICAgICBJIGtub3csIGluIHRoZSBVUyB0aGVyZSBpcyBubyBzdWNo IG51bWJlciByYW5nZS4gVGhlIHByb2JsZW0gSSANCgk+IGhhdmUgd2l0aCANCgk+ICAgICAgICAg c3VjaCBhbiBhcHByb2FjaCBpcyB0aGF0IHRoZXJlIGFyZSBkaWZmZXJudCBydWxlcyBpbiBldmVy eSANCgk+IGNvdW50cnkgYW5kIGVuZC11c2VycyANCgk+ICAgICAgICAgZ2V0IHJlc3RyaWN0ZWQg c2VydmljZXMuIChlLmcgbm8gTlAsIG5vIGFjY2VzcyB0byBlbWVyZ2VuY2UgDQoJPiBzZXJ2aWNl cywgZXRjLiANCgk+ICAgICAgICAgSU1ITyB0aGlzIHdpbGwgY2F1c2UgcHJvYmxlbXMgaW4gdGhl IGZ1dHVyZSANCgk+IA0KCT4gICAgICAgICBDYXNlIDQuIHRoZSByZWd1bGF0b3IgcmVzZXJ2ZXMg YSBzcGVjaWFsIG51bWJlciByYW5nZSBmb3IgDQoJPiBFTlVNLW9ubHkgcm91dGVkIA0KCT4gICAg ICAgICBudW1iZXJzLiBUaGlzIHNob3VsZCBiZSBkb25lIGRpcmVjdGx5IHRvIHRoZSBlbmQtdXNl ci4gVGhlIA0KCT4gYWR2YW50YWdlIGlzIA0KCT4gICAgICAgICB0aGF0IHlvdSBoYXZlIE5QIGJ1 aWx0LWluLCB3aXRob3V0IGhhdmluZyB0byBkZWFsIHdpdGggbm9ybWFsIExOUCANCgk+IGlzc3Vl cyBhbmQgDQoJPiAgICAgICAgIHRlY2hub2xvZ3ksIHNhdmluZyB0aGUgU1AgbXVjaCBlZmZvcnQu IA0KCT4gDQoJPiAgICAgICAgIFRoZSBkaWZmZXJlbmNlIGJldHdlZW4gY2FzZSAzIGFuZCA0IGlz IHRoYXQgaW4gY2FzZSAzIG5vIHJ1bGVzIA0KCT4gZXhpc3QgZm9yIE5QIGFuZCANCgk+ICAgICAg ICAgaW50ZXJjb25uZWN0IG9uIElQLCBzbyB5b3UgY3JlYXRlIFZvSVAgSXNsYW5kIHRoYXQgYXJl IA0KCT4gaW50ZXJjb25uZWN0ZWQgb25seSB2aWEgDQoJPiAgICAgICAgIHRoZSBQU1ROIHBlciBk ZWZhdWx0LiBJZiB5b3UgaW50ZXJjb25uZWN0IG9uIElQLCB5b3UgY2FuIGRvIHRoaXMgDQoJPiBv bmx5IGN1cnJlbnRseSANCgk+ICAgICAgICAgd2l0aCBiaWxhdGVyYWwgYWdyZWVtZW50cy4gSW4g Y2FzZSA0IHlvdSBoYXZlIGF1dG9tYXRpY2FsbHkgTlAgDQoJPiBhbmQgYWxzbyBpbnRlcmNvbm5l Y3QgDQoJPiAgICAgICAgIGJlY2F1c2UgeW91IGNhbiB1c2UgRU5VTSBhbHNvIG9uIElQIHRvIGlu dGVyY29ubmVjdC4gVGhpcyBpcyBCVFcgDQoJPiBhbHNvIGRyYWZ0ZWQgDQoJPiAgICAgICAgIGlu IHRoZSBTSVAgRm9ydW0gU2VydmljZSBQcm92aWRlciBXRyBJbnRlcmNvbm5lY3QgQ29uc2Vuc3Vz LiANCgk+IA0KCT4gICAgICAgICA+PldpdGggRU5VTS1vbmx5IG51bWJlcnMgdGhlcmUgaXMgbm8g bmVlZCB0byBhc3NpZ24gYmxvY2tzIG9mIA0KCT4gbnVtYmVycy4gDQoJPiAgICAgICAgID4+QW4g RU5VTS1vbmx5IG51bWJlciBpcyB0aGUgZXF1aXZhbGVudCBvZiBhIGRvbWFpbiBuYW1lLiBJdCBp cyANCgk+IGFzc2lnbmVkIA0KCT4gICAgICAgICA+PnRvIHRoZSBlbmQtdXNlciBkaXJlY3RseSwg d2hvIGNob29zZXMgdGhlIFNQLCBsaWtlIHdpdGggYSANCgk+IHNlcnZpY2UgbnVtYmVyLiANCgk+ ICAgICAgICAgPj5Zb3UgYWxzbyBkbyBub3QgYXNzaWduIGRvbWFpbiBuYW1lcyBpbiBibG9ja3Mu IA0KCT4gDQoJPiAgICAgICAgID5JIHRoaW5rIHRoZXJlIGlzIGFuIGlzc3VlIGhlcmUuICBJZiB0 aGUgU1BzIGhvbGQgbW9zdCBvZiB0aGUgDQoJPiBjdXJyZW50IE5QQSANCgk+ICAgICAgICAgPmJs b2NrcywgYW5kIHRoZXJlIGlzIGEgbWlncmF0aW9uIG9mIG1hbnkgdXNlcnMgZnJvbSBURE0gdG8g SVAsIA0KCT4gdGhlbiBkbyB5b3UgDQoJPiAgICAgICAgID5sZW5ndGhlbiB0aGUgbnVtYmVyIHRv IDExIGRpZ2l0cyB0byBnZXQgbW9yZSwgb3IgZG8gdGhlIFNQcyBoYXZlIHRvIA0KCT4gICAgICAg ICA+cmVsaW5xdWlzaCBudW1iZXJzPyANCgk+IA0KCT4gICAgICAgICBUaGlzIGEgdHlwaWNhbCBO QU5QIHByb2JsZW0uIEluIHRoZSBOQU5QIHRoZXJlIGlzIG9ubHkgZ2VvZ3JhcGhpYyANCgk+IGFy ZWEgDQoJPiAgICAgICAgIGNvZGVzICh3aXRoIHRoZSBleGNlcHRpb24gb2YgODAwIG51bWJlcnMp LiBJbiBtb3N0IG90aGVyIGNvdW50cnkgDQoJPiB0aGVyZSBhcmUgDQoJPiAgICAgICAgIG1vcmUg bnVtYmVyIHR5cGVzOiB5b3UgaGF2ZSBnZW9ncmFwaGljIGFuZCBub24tZ2VvZ3JhcGhpYyBudW1i ZXJzLiANCgk+IA0KCT4gICAgICAgICBOb24tZ2VvIG51bWJlcnMgYXJlIGVnIG1vYmlsZSBudW1i ZXJzLCBwZXJzb25hbCBudW1iZXJzLCBldGMuIFRoZSANCgk+IGFkdmFudGFnZSANCgk+ICAgICAg ICAgaGVyZSBpcyB0aGF0IHlvdSByZWxpZXZlIHRoZSBwcmVzc3VyZSBvbiB0aGUgbnVtYmVyIGV4 aGF1c3QgaGVyZS4gDQoJPiBTaW5jZSBnZW8gDQoJPiAgICAgICAgIG51bWJlcnMgYXJlIGdpdmVu IGF3YXkgaW4gYmxvY2tzLCB5b3UgaGF2ZSBhIGxvdCBvZiB1bnVzZWQgbnVtYmVycy4gDQoJPiAg ICAgICAgIEVnIGluIEF1c3RyaWEgdGhlIGdlbyBudW1iZXJzIGFyZSB1c2luZyB1cCBhIGdyZWF0 IGNodW5rIG9mIHRoZSANCgk+IG51bWJlcnM6IA0KCT4gICAgICAgICB3ZSBoYXZlIDExMDAgNC1k aWdpdCBhcmVhIGNvZGVzIHVzZWQgYmUgYXBwb3ggNCBNaW8gc3Vic2NyaWJlcnMsIA0KCT4gICAg ICAgICBvbiB0aGUgb3RoZXIgaGFuZCwgd2UgaGF2ZSA1IChmaXZlKSAzLWRpZ2l0IG1vYmlsZSBu dW1iZXIgcmFuZ2VzIA0KCT4gICAgICAgICB1c2VkIGJ5IDQsNSBNaW8gc3Vic2NyaWJlcnMgKDgw JSBvZiB0aGVtIGFyZSBiZWhpbmQgMiBtb2JpbGUgDQoJPiAiYXJlYSIgY29kZXMpLiANCgk+IA0K CT4gICAgICAgICBUaGUgcmVhc29uIGlzIHNpbXBsZTogdGhlIG1vYmlsZSBudW1iZXIgcmFuZ2Vz IGFyZSBmbGF0LiBTbyBpZiB3ZSANCgk+IGdpdmUgZWcgDQoJPiAgICAgICAgIG9uZSAzLWRpZ2l0 IG51bWJlciByYW5nZSB0byBFTlVNLCB3ZSBjYW4gaW5zdGFudGx5IHVzZSB0aGVtIHdpdGggDQoJ PiAgICAgICAgIGFkZGl0aW9uYWwgNy1kaWdpdHMgZm9yIDkuOTk5Ljk5OSBzdWJzY3JpYmVycy4g DQoJPiANCgk+ICAgICAgICAgcmVnYXJkcyANCgk+IA0KCT4gICAgICAgICBSaWNoYXJkIA0KCT4g DQoJPnp7eCVeem0/MCd+ZmZYKcOfwqMgDQoNCg== _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 2 10: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 KAA13866 for ; Fri, 2 Apr 2004 10:28: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 1B9NL9-0003RU-U8 for enum-archive@odin.ietf.org; Fri, 02 Apr 2004 07:00:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32C03AP013233 for enum-archive@odin.ietf.org; Fri, 2 Apr 2004 07:00:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9KBx-0003Io-SC; Fri, 02 Apr 2004 03:38:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Ei8-00030z-R3 for enum@optimus.ietf.org; Thu, 01 Apr 2004 21:47: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 VAA28627 for ; Thu, 1 Apr 2004 21:47:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Ei5-00006n-00 for enum@ietf.org; Thu, 01 Apr 2004 21:47:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Egl-0007cm-00 for enum@ietf.org; Thu, 01 Apr 2004 21:45:51 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B9EZ5-0005sn-00 for enum@ietf.org; Thu, 01 Apr 2004 21:37:51 -0500 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: Fri, 2 Apr 2004 04:37:23 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F162233C9B@oefeg-s02.oefeg.loc> Thread-Topic: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQYOtZTN6Rqrs0nRz+XFWOmI34lGAAIBt5K 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 SmltLA0KUHVibGljIEVOVU0gaXMgY3VycmVudGx5IGJlaW5nIGRlcGxveWVkIGFuZCBwcm9ncmVz c2luZyBuaWNlbHkuIENhcnJpZXIgRU5VTQ0KaXMgc3RpbGwgaW4gYSBuYXNjZW50IHN0YXRlIGFu ZCBvbmx5IHdpdGhpbiBpc2xhbmRzLiBJIGRvIG5vdCBzZWUgYW55IHByb2dyZXNzIHRvIG1ha2UN CklQLUlQIGNhbGxzIHJvdXRhYmxlIG9uIGEgZ2xvYmFsIHNjYWxlIHdpdGggY2FycmllciBFTlVN LiBJZiB3ZSBmaW5kIGEgd29ya2FibGUNCnNvbHV0aW9uIGhlcmUsIHB1YmxpYyBFTlVNIGNvdWxk IHNlcnZlIGFzIGEgbWVhbnMgdG8gZ2x1ZSB0aGUgY2FycmVpciBFTlVNIHRvZ2V0aGVyLg0KIA0K UmljaGFyZA0KDQoJLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IEph bWVzIE1jRWFjaGVybiBbbWFpbHRvOmptY2VAbm9ydGVsbmV0d29ya3MuY29tXSANCglHZXNlbmRl dDogRnIgMDIuMDQuMjAwNCAwMDo0MyANCglBbjogJ01pY2hhZWwgSGFtbWVyJyANCglDYzogU3Rh c3RueSBSaWNoYXJkOyBlbnVtQGlldGYub3JnIA0KCUJldHJlZmY6IFJFOiBbSXB0ZWxdIEZXOiBb RW51bV0gU3VtbWFyeSBvbiBOb1BTVE4gZGljdXNzaW9uDQoJDQoJDQoNCglNaWtlLCANCglJIGNl cnRhaW5seSBkb24ndCB3YW50IHRvIGN1cmIgeW91ciBkZXNpcmUgdG8gZ2V0IGNhbGxzIG9udG8g dGhlIElQIG5ldHdvcmsgYXMgc29vbiBhcyBwb3NzaWJsZS4uLiANCg0KCUkgZG9uJ3QgdGhpbmsg dGhlIFBTVE4tdG8tSVAgR1cgbmVlZHMgdG8ga25vdyB0aGUgbWFwcGluZyB0byBldmVyeSB0ZWxl cGhvbmUgbnVtYmVyIGluIHRoZSB3b3JsZCB0byByb3V0ZSBpdCB1c2luZyBJUC4gSWYgdGhlIG51 bWJlciBpcyBhc3NpZ25lZCB0byBhIFNlcnZpY2UgUHJvdmlkZXIgdXNpbmcgdGVjaG5pcXVlcyBs aWtlIHRob3NlIHVzZWQgdG9kYXksIHRoZW4gdGhlIEdXIHNob3VsZCBiZSBhYmxlIHRvIGtub3cg d2hpY2ggU1AgdGhlIG51bWJlciBtYXBzIHRvIC0gYW5kIHJvdXRlIG9uIHRoYXQgYmFzaXMuIFRo aXMgY291bGQgYmUgZG9uZSB3aXRoIENhcnJpZXIgRU5VTSwgb3Igd2l0aCB0cmFkaXRpb25hbCBy b3V0aW5nIGFuZCB0cmFuc2xhdGlvbnMgLSBlaXRoZXIgb25lIGNvdWxkIHdvcmsuIFRoZXJlIGlz IG5vIHJlYXNvbiB3aGF0c29ldmVyIHdoeSAiUFNUTiByb3V0aW5nIiBjYW5ub3Qgc2VsZWN0IElQ ICJ0cnVua3MiIHRvIGFub3RoZXIgVm9JUCBuZXR3b3JrLiAoT2YgY291cnNlIHRoaXMgd291bGQg bm90IGJlIHRydWUgZm9yIEVOVU0tb25seSBudW1iZXJzLikNCg0KCVB1YmxpYyBFTlVNIChpbiB0 aG9zZSBjYXNlcyB3aGVyZSB0aGUgc3Vic2NyaWJlciBoYXMgb3B0ZWQtaW4pIGNhbiBhY2NlbGVy YXRlIGFuZCByZWZpbmUgdGhpcywgYnV0IHRoZXJlIGlzIG5vIHJlYXNvbiB0byB3YWl0IGZvciBp dCB0byBnZXQgc3RhcnRlZCBtb3ZpbmcgdG8gZW5kLXRvLWVuZCBJUC4NCg0KCUppbSANCg0KCS0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IE1pY2hhZWwgSGFtbWVyIFttYWlsdG86 bWhhbW1lckBjaXNjby5jb21dIA0KCVNlbnQ6IFR1ZXNkYXksIE1hcmNoIDMwLCAyMDA0IDU6NDcg UE0gDQoJVG86IE1jRWFjaGVybiwgSmFtZXMgW0NBUjo1TjAwOkVYQ0hdIA0KCUNjOiAnU3Rhc3Ru eSBSaWNoYXJkJzsgZW51bUBpZXRmLm9yZyANCglTdWJqZWN0OiBSRTogW0lwdGVsXSBGVzogW0Vu dW1dIFN1bW1hcnkgb24gTm9QU1ROIGRpY3Vzc2lvbiANCg0KCUphbWVzLCANCg0KCUkgZ3Vlc3Mg SSBoYXZlIHRvIGN1cmIgbXkgZGVzaXJlIHRvIGdldCB0aGUgY2FsbCBvbnRvIHRoZSBJUCBuZXR3 b3JrIGFzIA0KCXNvb24gYXMgcG9zc2libGUgcmF0aGVyIHRoYW4gYXMgbGF0ZSBhcyBwb3NzaWJs ZS4gDQoNCglJbiB0b2RheSdzIGVudmlyb25tZW50LCBJIHRoaW5rIHdlIGhhdmUgcG9ja2V0cyBv ZiBJUCBuZXR3b3JrcyANCglpbnRlcmNvbm5lY3RlZCBieSB0aGUgZ2xvYmFsIFBTVE4uICBPbmUg b2YgdGhlIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgUFNUTiANCglpcyB0aGF0IEkgY2FuIGRpYWwg YSBudW1iZXIgZnJvbSBhbnl3aGVyZSBpbiB0aGUgd29ybGQgYW5kIGl0IHdpbGwgZ2V0IA0KCXJv dXRlZCB0byB0aGUgZGVzdGluYXRpb24gd2hlcmUgdGhhdCBudW1iZXIgcmVzaWRlcy4gIFdoZW4g Z29pbmcgZnJvbSBQU1ROIA0KCXRvIElQLCBpdCBtaWdodCBiZSBleHBlY3RlZCB0aGF0IHRoZSBQ U1ROLUlQIEdXIGhhcyBhbGwgdGhlIHRlbGVwaG9uZSANCgludW1iZXIgdG8gU0lQL0lQIGFkZHJl c3MgbWFwcGluZ3MgYXNzb2NpYXRlZCB3aXRoIHRoYXQgSVAgcG9ja2V0IA0KCXByb3Zpc2lvbmVk IGludG8gaXQuIA0KDQoJTm93IHJldmVyc2UgdGhlIHNpdHVhdGlvbi4gIFdlIGhhdmUgcG9ja2V0 cyBvZiBURE0gaW50ZXJjb25uZWN0ZWQgdG8gdGhlIA0KCSJOZXR3b3JrIi4gIEEgdXNlciBpbiB0 aGF0IFRETSBwb2NrZXQgZGlhbHMgYSBudW1iZXIgaXQgZ29lcyB0byBhIG5lYXJieSANCglnYXRl d2F5IGFuZCB0aGVuIHJvdXRlZCB0byBhbnl3aGVyZSBpbiB0aGUgTmV0d29yay4gIEkgZG9uJ3Qg ZXhwZWN0IHRoYXQgDQoJZ2F0ZXdheSB0byBoYXZlIGEgbWFwcGluZyBmcm9tIGFsbCBvZiB0aGUg dGVsZXBob25lIG51bWJlcnMgaW4gdGhlIHdvcmxkIHRvIA0KCWEgU0lQIG9yIElQIGFkZHJlc3Mg aW4gdGhlIElQIGRvbWFpbi4gIFNvLCBnaXZlbiBvbmx5IGEgdGVsZXBob25lIG51bWJlciwgDQoJ aG93IGRvIEkgZ2V0IHJvdXRpbmcgaW5mb3JtYXRpb24gZm9yIHRoZSBJUCBkb21haW4/ICBJIGFz c3VtZWQgdGhlIEVOVU0gDQoJZGF0YWJhc2Ugd291bGQgZ2V0IHRoZW0gc3RhcnRlZCBvbiBkb2lu ZyB0aGF0IHRyYW5zbGF0aW9uLCBvciBhdCBsZWFzdCANCglnb2luZyBpbiB0aGUgcmlnaHQgZGly ZWN0aW9uLiANCg0KCUkgZG9uJ3Qgc2VlIHRoYXQgdGhpcyBjaGFuZ2VzIG9wdC1pbi4gIFdoYXQg aXQgcHJvYmFibHkgZG9lcyBtZWFuIGlzIHRoYXQsIA0KCWxhY2tpbmcgYW55IEVOVU0gZW50cnks IHRoZSBjYWxsIG11c3QgYmUgcm91dGVkIG1vc3RseSB0aHJvdWdoIHRoZSBQU1ROIHRvIA0KCXRo ZSAob25lPykgR1cgdGhhdCBoYXMgYSBtYXBwaW5nIHRvIHRoZSBjYWxsZWQgcGFydHkgaW4gdGhl IGxhc3QgSVAgDQoJZG9tYWluLiAgVGhhdCBpcyBsaWtlbHkgdG8gZGVsYXkgY3Jvc3NpbmcgaW50 byB0aGUgSVAgZG9tYWluLCBiZSBhIG1vcmUgDQoJZXhwZW5zaXZlIGNhbGwsIGFuZCBvbmUgd2hp Y2ggcGVycGV0dWF0ZXMgdGhlIFRETSBiYWNrYm9uZS4gDQoNCglJIHdhcyBhbHNvIGNvbmplY3R1 cmluZyB3aGF0IGl0IG1lYW5zIHRvICJvd24iIGEgdGVsZXBob25lIG51bWJlci4gIEluIHRoZSAN CglQU1ROLCB0aGUgbnVtYmVyIGlzIG93bmVkIGJ5IHRoZSBTUCBhbmQgYXNzaWduZWQgdG8gYW4g ZW5kLXVzZXIuICBUaGUgTE5QIA0KCXJ1bGluZ3Mgc3RyZXRjaCB0aGF0IGEgYml0IGJ5IGFsbG93 aW5nIGEgbnVtYmVyIHRvIGJlIGNhcnJpZWQgdG8gYW5vdGhlciANCglTUCwgYnV0IHRlY2huaWNh bGx5IGl0IGlzIHN0aWxsIG93bmVkIGJ5IHRoZSBvcmlnaW5hbCBjYXJyaWVyLiAgSWYgaXQgaXMg DQoJZXZlciBnaXZlbiB1cCwgaXQgcmV2ZXJ0cyBiYWNrIHRvIHRoYXQgY2Fycmllci4gIEhvdyBp cyB0aGlzIGdvaW5nIHRvIHdvcmsgDQoJaW4gSVA/ICBBcmUgRS4xNjQgbnVtYmVyIGJsb2NrcyBn b2luZyB0byBiZSBhc3NpZ25lZCB0byBhbiBJVFNQPyAgRG9lcyBhIA0KCVRETSBjYXJyaWVyIHRo YXQgYmVjb21lcyBhbiBJVFNQIGdldCB0byBtb3ZlIHRoZW0gb3ZlciB3aXRob3V0IA0KCXJlc3Ry aWN0aW9uPyAgQ291bGQgYW4gSVRTUCBvd24gYSBibG9jayBvZiBudW1iZXJzLCB5ZXQgaGF2ZSBu byBHVyB0byB0aGUgDQoJUFNUTj8gIEFyZSB0aGVyZSBnb2luZyB0byBiZSByZXN0cmljdGlvbnMg b24gaG93IHRoZSBuZXR3b3JrIGV2b2x2ZXM/IA0KDQoJSSB3b3VsZCBob3BlIHRoYXQgZXZlbiBp ZiBhbiBpbmRpdmlkdWFsIG51bWJlciB3YXMgdW5saXN0ZWQsIGlmIGEgYmxvY2sgb2YgDQoJbnVt YmVycyBiZWxvbmdlZCB0byBhbiBJVFNQLCB0aGVyZSB3b3VsZCBiZSBhIGhpZ2hlci1sZXZlbCBu b2RlIGVudHJ5IGluIA0KCXRoZSBFTlVNIHRyZWUsIGFuZCB0aGUgY2FsbCBjb3VsZCBiZSByb3V0 ZWQgdG8gYW4gSVAtR1csIHdoaWNoIG1pZ2h0IGhhdmUgDQoJYWRkaXRpb25hbCBpbmZvcm1hdGlv biB0byByb3V0ZSB0aGUgY2FsbCwgb3IgYXQgbGVhc3QgZGV0ZXJtaW5lIHRoYXQgdGhlIA0KCW51 bWJlciBpcyB1bmFzc2lnbmVkLiANCg0KCUkgY29uZmVzcyBJIGhhdmUgbm90IGJlZW4gd2F0Y2hp bmcgdGhlIEVOVU0gbGlzdCwgYnV0IHBlcmhhcHMgc2hvdWxkIA0KCWpvaW4uICBNeSBhcG9sb2dp ZXMgaWYgdGhpcyBoYXMgYWxsIGJlZW4gZmlndXJlZCBvdXQuIA0KDQoJTWlrZSANCg0KDQoJQXQg MDM6NTkgUE0gMy8zMC8yMDA0IC0wNTAwLCBKYW1lcyBNY0VhY2hlcm4gd3JvdGU6IA0KDQoJPk1p a2UsIA0KCT5JbiB5b3VyIGVtYWlsIHlvdSBzdGF0ZTogDQoJPiANCgk+LS0tc25pcC0tLSANCgk+ VGhlIGRpZmZlcmVuY2UgaXMgaW4gdGhlIGludGVycHJldGF0aW9uIG9mIGEgbGFjayBvZiBhIHJl Y29yZC4gIEluIExOUCwgaXQgDQoJPndvdWxkIG1lYW4gdGhhdCB0aGUgRS4xNjQgbnVtYmVyIGlz IHN0aWxsIG93bmVkIGJ5IHRoZSBvcmlnaW5hbCBzd2l0Y2gsIA0KCT53aGVyZWFzIGluIEVOVU0g aXQgd291bGQgbWVhbiB0aGF0IHRoZSBFLjE2NCBudW1iZXIgaXMgbm90IHJvdXRlLWFibGUgdG8g DQoJPmFuIElQIGVuZHBvaW50LiAgRnJvbSBhIFRETSBwZXJzcGVjdGl2ZSwgdGhlIGVudGlyZSBJ UCBkb21haW4gY291bGQgYmUgDQoJPnZpZXdlZCBhcyBhIHNpbmdsZSBzd2l0Y2ggYW5kIHRoZSBM TlAgcm91dGluZyBzY2hlbWUgc2hvdWxkIHdvcmsuICBUaGUgDQoJPmNvbnZlcnNlICh3aGVuIHJl Y29yZHMgZXhpc3QpIGNvdWxkIGJlIHRydWUgZm9yIEVOVU0uIA0KCT4gDQoJPiANCgk+QSBnYXRl d2F5IGJldHdlZW4gSVAtZG9tYWluIGFuZCBURE0gZG9tYWluLCB1cG9uIHNlZWluZyB0aGF0IGJv dGggYW4gTE5QIA0KCT5hbmQgYW4gRU5VTSBkaXAgaGF2ZSBub3QgcmVzb2x2ZWQgdGhlIHJvdXRl LCBjYW4gc2FmZWx5IGNvbmNsdWRlIHRoYXQgdGhlIA0KCT5udW1iZXIgaXMgdW5hc3NpZ25lZCBh bmQgcmVsZWFzZSB0aGUgY2FsbC4iIA0KCT4gDQoJPi0tLWVuZCBzbmlwLS0tIA0KCT4gDQoJPlRo aXMgc2VlbXMgdG8gc3VnZ2VzdCB0aGF0IHJvdXRpbmcgdG8gYW4gSVAgZW5kcG9pbnQgd291bGQg cmVxdWlyZSBhbiBFTlVNIA0KCT5lbnRyeSAtIG90aGVyd2lzZSB0aGUgZ2F0ZXdheSBjb3VsZCBz YWZlbHkgYXNzdW1lIHRoZSBudW1iZXIgaXMgDQoJPnVuYXNzaWduZWQuIERvIHlvdSByZWFsbHkg bWVhbiB0aGlzPyBXaGF0IHdvdWxkIHRoaXMgZG8gdG8gb3B0LWluPyANCgk+IA0KCT5UaGFua3Mg DQoJPkppbSANCgk+IA0KCT4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCgk+RnJvbTogU3Rh c3RueSBSaWNoYXJkIA0KCT5bPG1haWx0bzpSaWNoYXJkLlN0YXN0bnlAb2VmZWcuYXQ+bWFpbHRv OlJpY2hhcmQuU3Rhc3RueUBvZWZlZy5hdF0gDQoJPlNlbnQ6IE1vbmRheSwgTWFyY2ggMjksIDIw MDQgMTA6MzAgQU0gDQoJPlRvOiBNaWNoYWVsIEhhbW1lciANCgk+Q2M6IGlwdGVsQGlldGYub3Jn OyBzaXBwaW5nQGlldGYub3JnOyBlbnVtQGlldGYub3JnIA0KCT5TdWJqZWN0OiBBVzogW0lwdGVs XSBGVzogW0VudW1dIFN1bW1hcnkgb24gTm9QU1ROIGRpY3Vzc2lvbiANCgk+IA0KCT5IaSBNaWNo YWVsLCANCgk+IA0KCT5XZSBhcmUgdHJ5aW5nIHRvIGZpbmQgYSBzb2x1dGlvbiBmb3IgdGhlIGZv bGxvd2luZyBzY2VuYXJpb3M6IA0KCT5BLiBBbiBFLjE2NCBudW1iZXIgcmFuZ2UgaXMgb25seSBh dmFpbGFibGUgYW5kIHJvdXRhYmxlIGluIEVOVU0gDQoJPkIuIEFuIEUuMTY0IG51bWJlciByYW5n ZSBpcyBhdmFpbGFibGUgdmlhIFBTVE4gYW5kIHZpYSBJUCANCgk+Qy4gQW4gRS4xNjQgbnVtYmVy IHJhbmdlIGlzIG5vdCBhc3NpZ25lZCBhdCB0aGUgUFNUTiANCgk+IA0KCT5JZiBpbiBjYXNlcyBB IGFuZCBCIGFuIGVudHJ5IGlzIGV4aXN0aW5nIGluIEVOVU0sIG5vIHByb2JsZW0uIA0KCT5JZiB0 aGUgcXVlcnkgcmV0dXJucyBOWERPTUFJTiwgdGhlIHByb2JsZW0gYXJpc2VzIGZvciB0aGUgDQoJ PnF1ZXJ5aW5nIHNlcnZlciBob3cgdG8gcHJvY2VlZC4gDQoJPiANCgk+SW4gY2FzZSBBIHRoZSBz ZXJ2ZXIgbXVzdCBub3QgZm9yd2FyZCB0aGUgY2FsbCB0byB0aGUgUFNUTiwgYmVjYXVzZSANCgk+ YSBsb29wIG1heSBiZSBjcmVhdGVkLiBJbiBjYXNlcyBCIGFuZCBDIGl0IG1heSBmb3J3YXJkIHRo ZSBjYWxsIChubyBoYXJtKSANCgk+YnV0IGl0IGlzIG5vdCBuZWNlc3NhcnkuIEluIGNhc2UgQiB0 aGUgc2VydmVyIGNvdWxkIHRlcm1pbmF0ZSB0aGUgY2FsbCBvbiBJUCwgDQoJPmluIGNhc2UgQyB0 aGUgc2VydmVyIGNvdWxkIHNheSBudW1iZXIgbm90IGF2YWlsYWJsZSBhbmQgbm90IGJvdGhlciB0 aGUgDQoJPlBTVE4gYXQgYWxsLiANCgk+IA0KCT5JZiB3ZSBmaW5kIGEgc29sdXRpb24gdGhhdCBj b3ZlcnMgQSwgQiBhbmQgQyBtYXkgYmUgY292ZXJlZCBhcyB3ZWxsLiANCgk+IA0KCT5JIGFncmVl IHRoYXQgaW4gZnV0dXJlIGNhbGwgcm91dGluZyBtYXkgYmUgaW1wcm92ZWQgZnVydGhlciBpbiBh Y2Nlc3MgDQoJPnRvIExOUCBzZXJ2ZXJzIG9uIHRoZSBQU1ROIGlzIGF2YWlsYWJsZSBhbmQgYWxz byBpZiBhY2Nlc3MgdG8gRU5VTSANCgk+aXMgYXZhaWxhYmxlIG9uIHRoZSBQU1ROIChzb21lIGNh cnJpZXJzIGFyZSBhbHJlYWR5IHdvcmtpbmcgb24gdGhpcyksIA0KCT5idXQgdGhpcyB3aWxsIHRh a2Ugc29tZSB0aW1lLiANCgk+IA0KCT5XZSBzaG91bGQgYWxzbyBjb21lIHVwIHdpdGggYSBzc2Vs Zi1jb250YWluaW5nIHNvbHV0aW9uIG9uIElQIGFuZCANCgk+bm90IGFsd2F5cyByZWx5IG9uIHRo ZSBQU1ROLiANCgk+IA0KCT5yZWdhcmRzIA0KCT5SaWNoYXJkIA0KCT4gDQoJPiAgICAgICAgIC0t LS0tVXJzcHLDg8K8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCgk+ICAgICAgICAgVm9uOiBNaWNo YWVsIEhhbW1lciANCgk+IFs8bWFpbHRvOm1oYW1tZXJAY2lzY28uY29tPm1haWx0bzptaGFtbWVy QGNpc2NvLmNvbV0gDQoJPiAgICAgICAgIEdlc2VuZGV0OiBGciAyNi4wMy4yMDA0IDE3OjQwIA0K CT4gICAgICAgICBBbjogU3Rhc3RueSBSaWNoYXJkIA0KCT4gICAgICAgICBDYzogaXB0ZWxAaWV0 Zi5vcmc7IHNpcHBpbmdAaWV0Zi5vcmcgDQoJPiAgICAgICAgIEJldHJlZmY6IFJlOiBbSXB0ZWxd IEZXOiBbRW51bV0gU3VtbWFyeSBvbiBOb1BTVE4gZGljdXNzaW9uIA0KCT4gDQoJPiANCgk+IA0K CT4gICAgICAgICBSaWNoYXJkLCANCgk+IA0KCT4gICAgICAgICBHb2luZyBvdXQgb24gYSBsaW1i IGhlcmUsIHNpbmNlIEkgaGF2ZSBub3Qgc2VlbiBhbGwgdGhlIHJlZmVyZW5jZWQgDQoJPiAgICAg ICAgIGRpc2N1c3Npb25zLiAgTXkgZmlyc3QgaW1wcmVzc2lvbiBpcyB0aGF0IHRoZSBkZXNjcmlw dGlvbiBiZWxvdyANCgk+IGlzIG92ZXJsYXkgDQoJPiAgICAgICAgIGNvbXBsZXguIA0KCT4gDQoJ PiAgICAgICAgIEkgaGF2ZSBhIGNvbmNlcm4gdGhhdCB5b3UgYXBwZWFyIHRvIGJlIHByb3Bvc2lu ZyB0aGF0IHRoZSBFTlVNIA0KCT4gZGlwIHdvdWxkIA0KCT4gICAgICAgICBoYXZlIGRlZmluaXRp dmUgYW5zd2VycyB0bzogDQoJPiAgICAgICAgIGEpIHdoZXRoZXIgYSBudW1iZXIgaGFzIGJlZW4g YXNzaWduZWQgYW5kIHRoZXJlZm9yZSByb3V0LWFibGUsIA0KCT4gICAgICAgICBiKSB3aGV0aGVy IGEgbnVtYmVyIHRoYXQgaXMgYXNzaWduZWQgd2FzIGRvbmUsIGFuZCBpZiBzbyB3aGV0aGVyIA0K CT4gdG8gYSBQU1ROIA0KCT4gICAgICAgICBlbmRwb2ludCBvciBhbiBJUCBlbmRwb2ludC4gDQoJ PiANCgk+ICAgICAgICAgQW5vdGhlciBjb25jZXJuIGlzIHRoYXQsIGlmIHlvdSBkbyBnZXQgbG9v cGVkIHJvdXRpbmcgYmV0d2VlbiB0aGUgDQoJPiBJUCBkb21haW4gDQoJPiAgICAgICAgIGFuZCB0 aGUgVERNIGRvbWFpbiwgdGhpcyBpcyBsaWtlbHkgYW4gaW5kaWNhdGlvbiBvZiBhIGxhY2sgb2Yg DQoJPiAgICAgICAgIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIHRoZSBFTlVNIGRhdGFiYXNlIGFu ZCB0aGUgTE5QIA0KCT4gZGF0YWJhc2UuICBPbmUgb3IgdGhlIA0KCT4gICAgICAgICBvdGhlciBo YXMgaW5jb3JyZWN0IGRhdGEuICBJIHN1c3BlY3QgdGhhdCB0aGVyZSBtYXkgYmUgdGltZSBsYWdz IA0KCT4gZnJvbSB3aGVuIA0KCT4gICAgICAgICBhbiBTUCBhc3NpZ25zIGEgbnVtYmVyIGFuZCB3 aGVuIGl0IGdldHMgcmVmbGVjdGVkIGluIG9uZSBvciBhbm90aGVyIA0KCT4gICAgICAgICBkYXRh YmFzZXMuICBJZiB5b3Ugd2FudCB0aGUgRU5VTSBhbmQgTE5QIGRhdGFiYXNlcyB0byBiZSBzb21l d2hhdCANCgk+ICAgICAgICAgaW5kZXBlbmRlbnQsIHlvdSBtaWdodCB3YW50IGEgbG9vc2UgY291 cGxpbmcgb2YgdGhlIHVzZSBvZiB0aGUgDQoJPiB0d28gc3lzdGVtczogDQoJPiANCgk+ICAgICAg ICAgICAtSWYgZW5kcG9pbnQgaXMgVERNLCB0aGVuIHRoZSBFTlVNIGRhdGFiYXNlIHNob3VsZCBw b2ludCB0byB0aGUgDQoJPiBQU1ROLCANCgk+ICAgICAgICAgd2l0aCBkZWZhdWx0IGJlaGF2aW9y IGJlaW5nLCBpZiB1bmtub3duIHRvIEVOVU0sIHNlbmQgdG8gUFNUTiB0byANCgk+ICAgICAgICAg cmVzb2x2ZS4gIChOb3RlIHRoaXMgaXMgb3J0aG9nb25hbCB0byBFTlVNcyB1c2UgdG8gc2VsZWN0 IA0KCT4gYWx0ZXJuYXRpdmUgDQoJPiAgICAgICAgIGVuZHBvaW50cy4pIA0KCT4gDQoJPiAgICAg ICAgICAgLSBJZiBlbmRwb2ludCBpcyBJUCwgdGhlbiB0aGUgTE5QIGRhdGFiYXNlcyBzaG91bGQg cG9pbnQgdG8gdGhlIElQIA0KCT4gICAgICAgICBkb21haW4sIHdpdGggZGVmYXVsdCBiZWhhdmlv ciBiZWluZywgaWYgdW5rbm93biB0byBMTlAsIHJvdXRlIGluIA0KCT4gdGhlIFBTVE4gDQoJPiAg ICAgICAgIHRvIHJlc29sdmUuIA0KCT4gDQoJPiAgICAgICAgIFRoZSBkaWZmZXJlbmNlIGlzIGlu IHRoZSBpbnRlcnByZXRhdGlvbiBvZiBhIGxhY2sgb2YgYSANCgk+IHJlY29yZC4gIEluIExOUCwg aXQgDQoJPiAgICAgICAgIHdvdWxkIG1lYW4gdGhhdCB0aGUgRS4xNjQgbnVtYmVyIGlzIHN0aWxs IG93bmVkIGJ5IHRoZSBvcmlnaW5hbCANCgk+IHN3aXRjaCwgDQoJPiAgICAgICAgIHdoZXJlYXMg aW4gRU5VTSBpdCB3b3VsZCBtZWFuIHRoYXQgdGhlIEUuMTY0IG51bWJlciBpcyBub3QgDQoJPiBy b3V0ZS1hYmxlIHRvIGFuIA0KCT4gICAgICAgICBJUCBlbmRwb2ludC4gIEZyb20gYSBURE0gcGVy c3BlY3RpdmUsIHRoZSBlbnRpcmUgSVAgZG9tYWluIGNvdWxkIA0KCT4gYmUgdmlld2VkIA0KCT4g ICAgICAgICBhcyBhIHNpbmdsZSBzd2l0Y2ggYW5kIHRoZSBMTlAgcm91dGluZyBzY2hlbWUgc2hv dWxkIHdvcmsuICBUaGUgDQoJPiBjb252ZXJzZSANCgk+ICAgICAgICAgKHdoZW4gcmVjb3JkcyBl eGlzdCkgY291bGQgYmUgdHJ1ZSBmb3IgRU5VTS4gDQoJPiANCgk+ICAgICAgICAgQSBnYXRld2F5 IGJldHdlZW4gSVAtZG9tYWluIGFuZCBURE0gZG9tYWluLCB1cG9uIHNlZWluZyB0aGF0IGJvdGgg DQoJPiBhbiBMTlAgDQoJPiAgICAgICAgIGFuZCBhbiBFTlVNIGRpcCBoYXZlIG5vdCByZXNvbHZl ZCB0aGUgcm91dGUsIGNhbiBzYWZlbHkgY29uY2x1ZGUgDQoJPiB0aGF0IHRoZSANCgk+ICAgICAg ICAgbnVtYmVyIGlzIHVuYXNzaWduZWQgYW5kIHJlbGVhc2UgdGhlIGNhbGwuIA0KCT4gDQoJPiAg ICAgICAgIEFjdHVhbGx5LCBpdCBtYXkgbm90IGJlIG5lY2Vzc2FyeSB0byBzZW5kIGEgc2V0dXAg bWVzc2FnZSB0byBhIA0KCT4gR1csIG5vciBpcyANCgk+ICAgICAgICAgaXQgbmVjZXNzYXJ5IHRv IGhhdmUgdGhlIEVOVU0gYW5kIExOUCBkYXRhYmFzZXMgZHVwbGljYXRlIGVhY2ggDQoJPiBvdGhl ci4gIEl0IA0KCT4gICAgICAgICBzaG91bGQgYmUgc3VmZmljaWVudCBmb3IgYW4gRU5VTSBEQiB0 byBxdWVyeSB0aGUgTE5QIERCIGFuZCANCgk+IHJlc3BvbmQgd2l0aCBhbiANCgk+ICAgICAgICAg YXBwcm9wcmlhdGUgYW5zd2VyLCBvciB0aGUgY29udmVyc2UuIA0KCT4gDQoJPiAgICAgICAgIE1p a2UgDQoJPiANCgk+IA0KCT4gICAgICAgICBBdCAwNDoyMiBQTSAzLzI1LzIwMDQgKzAxMDAsIFN0 YXN0bnkgUmljaGFyZCB3cm90ZTogDQoJPiAgICAgICAgID5Dcm9zcyBwb3N0aW5nIGZyb20gZW51 bUBpZXRmLm9yZyANCgk+ICAgICAgICAgPlRoZSBkaXNjdXNzaW9uIGlzIGdvaW5nIG9uIHRoZSBl bnVtLWxpc3QgDQoJPiAgICAgICAgID4gDQoJPiAgICAgICAgID5SaWNoYXJkIFN0YXN0bnkgDQoJ PiAgICAgICAgID5PZUZFRyANCgk+ICAgICAgICAgPis0MyA2NjQgNDIwIDQxMDAgDQoJPiAgICAg ICAgID4gDQoJPiAgICAgICAgID4gDQoJPiAgICAgICAgID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLSANCgk+ICAgICAgICAgPkZyb206IFN0YXN0bnkgUmljaGFyZCANCgk+ICAgICAgICAgPlNl bnQ6IFRodXJzZGF5LCBNYXJjaCAyNSwgMjAwNCAxOjA4IFBNIA0KCT4gICAgICAgICA+VG86IE1h cmlhbiBEdXJrb3ZpYzsgbHdjQHJva2UuY28udWsgDQoJPiAgICAgICAgID5DYzogZW51bUBpZXRm Lm9yZyANCgk+ICAgICAgICAgPlN1YmplY3Q6IFtFbnVtXSBTdW1tYXJ5IG9uIE5vUFNUTiBkaWN1 c3Npb24gDQoJPiAgICAgICAgID4gDQoJPiAgICAgICAgID5EZWFyIGNvbGxlYWd1ZXMsIA0KCT4g ICAgICAgICA+IA0KCT4gICAgICAgICA+VGhlcmUgd2FzIGEgbG90IG9mIGRpc2N1c3Npb25zIG9u LWxpc3QgYW5kIG9mZi1saXN0IG9uIHRoaXMgaXNzdWUsIA0KCT4gICAgICAgICA+c28gSSB3aWxs IHRyeSB0byBzdW1tYXJpemUgYXQgbGVhc3QgbXkgdmlldyBvZiB0aGUgcHJvYmxlbS4gDQoJPiAg ICAgICAgID5JIHdpbGwgYWxzbyBpbmNsdWRlIG15IGN1cnJlbnQgdmlldyBvbiB0aGUgO2VudW1k aSANCgk+ICAgICAgICAgPmFuZCB0aGUgO3BzdG4gaW5kaWNhdG9yIGZvciB0aGUgdGVsOiBVUkkg DQoJPiAgICAgICAgID4gDQoJPiAgICAgICAgID5FTlVNLWVuYWJsZWQgVUFzIGFuZCBTZXJ2ZXJz IGFyZSBjdXJyZW50bHkgcHJvY2Vzc2luZyANCgk+ICAgICAgICAgPnJlY2VpdmVkIEUuMTY0IG51 bWJlcnMgKGVpdGhlciBpbiBhIHRlbDoreHh4IFVSSSBvciBpbiBhIHNpcDogVVJJIA0KCT4gICAg ICAgICA+aW4gdGhlIGZvcm1hdCBzaXA6K3h4eHhAcHJvYy5uZXQ7dXNlcj1waG9uZSkgaW4gdGhl IGZvbGxvd2luZyB3YXk6IA0KCT4gICAgICAgICA+KGZvciBzaW1wbGljaXR5IEkgYW0gb25seSBk ZWFsaW5nIHdpdGggdm9pY2UgY2FsbHMpIA0KCT4gICAgICAgICA+UGxlYXNlIGhvbGxlciBpZiBJ IGdvdCBzb21ldGhpbmcgd3Jvbmcgb3IgeW91IGRpc2FncmVlIA0KCT4gICAgICAgICA+IA0KCT4g ICAgICAgICA+MS4gUXVlcnkgRU5VTSAoaW4gZTE2NC5hcnBhKSANCgk+ICAgICAgICAgPiANCgk+ ICAgICAgICAgPjIuIGlmIGEgTkFQVFIgaXMgZm91bmQgd2l0aCBhbiAiZW51bXNlcnZpY2UiIHNp cCBvciB2b2ljZTpzaXAsIA0KCT4gICAgICAgICA+aGFuZGxlIHRoZSBjYWxsIGFzIGlmIHlvdSBo YXZlIHJlY2VpdmVkIGEgc2lwOiBVUkkgaW4gdGhlIGZvcm1hdCANCgk+ICAgICAgICAgPnNpcDp1 c2VyQHByb3YubmV0IGluIHRoZSBmaXJzdCBwbGFjZS4gDQoJPiAgICAgICAgID4gDQoJPiAgICAg ICAgID4zLiBJZiBhIE5BUFRSIGlzIGZvdW5kIHdpdGggYW4gImVudW1zZXJ2aWNlIiB2b2ljZTp0 ZWwgDQoJPiAgICAgICAgID4zYS4gYW5kIHRoZSB0ZWw6IFVSSSBpcyBwb2ludGluZyB0byBhIGRp ZmZlcmVudCBudW1iZXIsIA0KCT4gICAgICAgICA+cXVlcnkgRU5VTSBhZ2FpbiBmb3IgdGhpcyBu dW1iZXIgDQoJPiAgICAgICAgID4zYi4gaWYgdGhlIHRlbDogVVJJIGlzIHRoZSBzYW1lIGFzIHRo ZSBBVVMsIGZvcndhcmQgdGhlIA0KCT4gICAgICAgICA+Y2FsbCB0byB0aGUgUFNUTiwgaWYgeW91 IGFyZSBhYmxlIHRvIGRvIHNvLiANCgk+ICAgICAgICAgPiANCgk+ICAgICAgICAgPk5vdGU6IGhl cmUgdGhlIHByb3Bvc2VkIDtwc3RuIGluZGljYXRvciBtYXkgY29tZSBpbiBoYW5keTogDQoJPiAg ICAgICAgID5JbiAzYSB5b3UgbWF5IHVzZSBpdCBpbiB0aGUgTkFQVFIgdG8gcHJldmVudCBhIHNl Y29uZCBFTlVNLXF1ZXJ5IA0KCT4gICAgICAgICA+YW5kIGZvcmNlIHRoZSBjYWxsIHRvIHRoZSBQ U1ROLiANCgk+ICAgICAgICAgPkluIDNiIHRoZSBzZXJ2ZXIgbWF5IGFkZCA7cHN0biB0byBpbmZv cm0gdGhlIG5leHQgcHJveHkgYWJvdXQgDQoJPiAgICAgICAgID5UaGUgZGVjaXNpb24gdG8gZm9y Y2UgdGhlIGNhbGwgdG8gdGhlIFBTVE4uIE9uIHRoZSBvdGhlciBoYW5kLCANCgk+ICAgICAgICAg PkluIHRoaXMgY2FzZSBhbHNvIHRoZSA7ZW51bWRpIGluZGljYXRvciBtYXkgYmUgdXNlZCBqdXN0 IHRvIHByZXZlbnQgDQoJPiAgICAgICAgID5hbiBFTlVNIHF1ZXJ5LiBSZXN1bHQ6IDtwc3RuIGlz IHVzZWQgaW4gRU5VTSAtIDtlbnVtZGkgaXMgdXNlZCBpbiANCgk+ICAgICAgICAgPnNpZ25hbGxp bmcuIA0KCT4gICAgICAgICA+IA0KCT4gICAgICAgICA+NC4gTm93IHRoZSByZWFsIHByb2JsZW0g c3RhcnRzOiBJZiB0aGUgRU5VTS1xdWVyeSByZXR1cm5zIE5YRE9NQUlOLCANCgk+ICAgICAgICAg PnRoZSBjdXJyZW50IGFzc3VtcHRpb24gb2YgYWxsIGNsaWVudHMgaXM6IHRoZSBjYWxsIGlzIHJv dXRlZCB0byB0aGUgDQoJPiAgICAgICAgID5QU1ROIGlmIHRoZSBzZXJ2ZXIgaXMgYWJsZSB0byBk byBzbyAoZXZlbnR1YWxseSB3aXRoIHRoZSA7ZW51bWRpIA0KCT4gc2V0LiANCgk+ICAgICAgICAg PiANCgk+ICAgICAgICAgPlRoaXMgbWVhbnMsIHdlIHJlZmVyIHRoZSBwcm9ibGVtIHRvIHRoZSBQ U1ROLiBUaGlzIGlzIG5vdCBuaWNlIGZvciANCgk+ICAgICAgICAgPnZhcmlvdXMgcmVhc29uczog DQoJPiAgICAgICAgID4xLiB3ZSBhcmUgYm90aGVyaW5nIHRoZSBQU1ROIGluIHNvbWUgY2FzZXMg dW5uZWNlc3NhcmlseSANCgk+ICAgICAgICAgPjIuIHRoZSBQU1ROIG1heSBub3Qga25vdyB3aGF0 IHRvIGRvIGVpdGhlciBhbmQgYm91bmNlIHRoZSANCgk+ICAgICAgICAgPmNhbGwgYmFjaywgd2hp Y2ggaXMgY3JlYXRpbmcgbG9vcHMgDQoJPiAgICAgICAgID4zLiBhbmQgZmluYWxseTogd2hhdCBh cmUgd2UgZG9pbmcgaWYgdGhlcmUgaXMgbm8gUFNUTiBhbnltb3JlIDstKSANCgk+ICAgICAgICAg Pk9rLCB0aGlzIHNlZW1zIGZhciByZWFjaGVkLCBidXQgSW50ZXJuZXQgVGVsZXBob255IHNob3Vs ZCBiZSANCgk+IGZpbmFsbHkgDQoJPiAgICAgICAgID5zZWxmLWNvbnRhaW5pbmcuIA0KCT4gICAg ICAgICA+IA0KCT4gICAgICAgICA+U28gd2hhdCBhcmUgdGhlIGFkZGl0aW9uYWwgcG9saWNpZXMg d2UgbWF5IHdhbnQgdG8gdGVsbCBhbiBFTlVNLSANCgk+ICAgICAgICAgPmNsaWVudD8gDQoJPiAg ICAgICAgID4gDQoJPiAgICAgICAgID4xLiBObyBzdWNoIG51bWJlciAodW5hc3NpZ25lZCBudW1i ZXIpIA0KCT4gICAgICAgICA+MWEuIFRoZSB3aG9sZSBudW1iZXIgcmFuZ2UgKG51bWJlciBibG9j aylpcyB1bmFzc2lnbmVkIA0KCT4gICAgICAgICA+MWIuIFRoZXJlIGFyZSBudW1iZXJzIGFzc2ln bmVkIGluIHRoaXMgbnVtYmVyIHJhbmdlLCBidXQgaWYgeW91IA0KCT4gICAgICAgICA+ZG8gbm90 IGZpbmQgb25lIGluIEVOVU0sIHlvdSBhbHNvIHdpbGwgbm90IGZpbmQgb25lIG9uIHRoZSBQU1RO LCBzbyANCgk+ICAgICAgICAgPml0IG1ha2VzIG5vIHNlbnNlIHRvIHJvdXRlIGl0IHRvIHRoZSBQ U1ROIChFTlVNLW9ubHkpIA0KCT4gICAgICAgICA+Mi4gRGVmYXVsdCByb3V0aW5nIGZvciB0aGUg d2hvbGUgbnVtYmVyIHJhbmdlIChudW1iZXIgYmxvY2spIHRvIA0KCT4gYSBWb0lQIA0KCT4gICAg ICAgICA+Z2F0ZXdheS4gDQoJPiAgICAgICAgID4yYS4gVGhlIHdob2xlIGJsb2NrIGlzIHJvdXRl ZCwgdGhlcmUgYXJlIG5vIGluZGl2aWR1YWwgZW50cmllcyANCgk+IGluIEVOVU0gDQoJPiAgICAg ICAgID4oZS5nLiAxLTgwMCBudW1iZXJzKSANCgk+ICAgICAgICAgPjJiLiBUaGVyZSBhcmUgbnVt YmVycyBpbiBFTlVNLCBidXQgaWYgeW91IGRvIG5vdCBmaW5kIGFuIGVudHJ5LCANCgk+IHJvdXRl IA0KCT4gICAgICAgICA+dGhlIGNhbGwgdG8gdGhlIGRlZmF1bHQgZ2F0ZXdheSBnaXZlbi4gT25l IGV4YW1wbGUgZm9yIHRoaXMgY2FzZSANCgk+IG1heSBiZSANCgk+ICAgICAgICAgPmEgVm9JUCBw cm92aWRlciBvcGVyYXRpbmcgYW4gaXNsYW5kIG9ubHkgY29ubmVjdGVkIHRvIHRoZSBQU1ROLiAN Cgk+IFNvbWUgDQoJPiAgICAgICAgID5vZiB0aGUgdXNlcnMgYXJlIGFsc28gaW4gRU5VTSAob3B0 LWluKS4gSWYgaGUgcHJvdmlkZXIgbm93IG9wZW5zIA0KCT4gdXAgYWNjZXNzIA0KCT4gICAgICAg ICA+dG8gdGhlIEludGVybmV0IHZpYSBhIGdhdGV3YXkgKGJvcmRlciBlbGVtZW50LCAuLi4pLCBo ZSBtYXkgd2FudCANCgk+IHRvIHJvdXRlIA0KCT4gICAgICAgICA+YWxsIGNhbGxzIGZvciBoaXMg dXNlcnMgbm90IGluIEVOVU0gdG8gdGhlIGdhdGV3YXkgcHJvdmlkZWQgYnkgDQoJPiBkZWZhdWx0 IA0KCT4gICAgICAgICA+IA0KCT4gICAgICAgICA+Q2FzZSAxYSBhbmQgMmEgY2FuIGJlIGRlYWx0 IHdpdGggaW4gZTE2NC5hcnBhIHdpdGggd2lsZGNhcmRzLCANCgk+IGJlY2F1c2Ugbm8gDQoJPiAg ICAgICAgID5BZGRpdGlvbmFsIGVudHJpZXMgYmVsb3cgZXhpc3QuIA0KCT4gICAgICAgICA+Q2Fz ZSAxYiBhbmQgMmIgY2Fubm90IGJlIGRlYWx0IHdpdGhpbiBlMTY0LmFycGEsIGJlY2F1c2UgDQoJ PiB3aWxkY2FyZHMgZG8gDQoJPiAgICAgICAgID5ub3Qgc3VwcG9ydCB0aGlzLiANCgk+ICAgICAg ICAgPiANCgk+ICAgICAgICAgPlRoZSBzb2x1dGlvbnMgcHJvcG9zZWQgZm9yIHRoaXMgc29mYXIg YXJlLiANCgk+ICAgICAgICAgPiANCgk+ICAgICAgICAgPkEuIHVzZSB0YWJsZXMgaW4gZWFjaCBz ZXJ2ZXIuIFRoaXMgaXMgbm90IGEgZ29vZCBpZGVhIGFuZCBkb2VzIA0KCT4gbm90IGhlbHAgDQoJ PiAgICAgICAgID5FTlVNLWVuYWJsZSBVQS4gVGhlIGluZm9ybWF0aW9uIHNob3VsZCBiZSBzdG9y ZWQgaW4gYSBnbG9iYWwgDQoJPiBhY2Nlc3NpYmxlIA0KCT4gICAgICAgICA+YW5kIHB1YmxpYyBk YXRhYmFzZSAoRE5TKS4gDQoJPiAgICAgICAgID4gDQoJPiAgICAgICAgID5CLiB1c2UgYSAob25l LCBjb21tb24pIHNlY29uZCBjb21tb24gdHJlZSAoZTE2NHNoYWRvdy5hcnBhLCANCgk+IHdoZXJl IHlvdSBwdXQgDQoJPiAgICAgICAgID5pbiBvbmx5IHRoZSB3aWxkY2FyZHMgZm9yIHRoZSBudW1i ZXIgcmFuZ2VzIGluIHF1ZXN0aW9uLiBUaGUgDQoJPiBwcm9jZXNzaW5nIA0KCT4gICAgICAgICA+ YXNzdW1wdGlvbiBub3cgc2hvdWxkIGJlOiANCgk+ICAgICAgICAgPiANCgk+ICAgICAgICAgPklm IHRoZSBFTlVNLXF1ZXJ5IHJldHVybnMgTlhET01BSU4sIHRoZSBjYWxsIGlzIG5vdCByb3V0ZWQg dG8gDQoJPiB0aGUgUFNUTiANCgk+ICAgICAgICAgPkluIGFueSBjYXNlLCB0aGUgc2VydmVyIHF1 ZXJpZXMgZTE2NHNoYWRvdy5hcnBhLCBhbmQgb25seSBpZiBubyANCgk+IGVudHJ5IA0KCT4gICAg ICAgICA+aXMgZm91bmQgdGhlcmUsIHRoZSBjYWxsIGlzIHJvdXRlZCB0byB0aGUgUFNUTi4gVGhl IG1hbmFnZW1lbnQgYW5kIA0KCT4gICAgICAgICA+ZGVsZWdhdGlvbiBwcm9jZWR1cmVzIG9mIHRo ZSB0cmVlIGFyZSB0aGUgc2FtZSBhcyBmb3IgZTE2NC5hcnBhLiANCgk+ICAgICAgICAgPlRoZSBz ZWNvbmQgdHJlZSB3b3VsZCBjb250YWluIG9ubHkgd2lsZGNhcmQgTkFQVFIgUlIgZm9yIG51bWJl ciANCgk+IHJhbmdlcyANCgk+ICAgICAgICAgPiANCgk+ICAgICAgICAgPlRoaXMgd291bGQgYmUg dGhlIG9wdGltYWwgc29sdXRpb24gcHJvcG9zZWQgc29mYXIuIFRoZSBwcm9ibGVtIA0KCT4gaXMg dGhhdCANCgk+ICAgICAgICAgPmEgY29tbW9uIGFncmVlbWVudCBhbmQgYSBkZWZpbml0aW9uIG9u IHRoZSBzZWNvbmQgdHJlZSBpcyANCgk+IG5lY2Vzc2FyeS4gDQoJPiAgICAgICAgID4gDQoJPiAg ICAgICAgID5DLiBVc2UgaW5kaXZpZHVhbCBzZWNvbmQgc2hhZG93IHRyZWVzLCBlZyBvbiBhIG5h dGlvbmFsIGxldmVsLCANCgk+IGVnIGluIA0KCT4gICAgICAgICA+QXVzdHJpYSBlMTY0c2hhZG93 LmF0IHdvdWxkIGJlIHVzZWQuIFRoZSBwcm9ibGVtIGhlcmUgaXMgaG93IG9uZSANCgk+IGNhbiAN Cgk+ICAgICAgICAgPmZpbmQgb3V0IHRoZSBkb21haW4gbmFtZXMgb2YgdGhlIGluZGl2aWR1YWwg dHJlZXMuIA0KCT4gICAgICAgICA+T25lIHNvbHV0aW9uIGlzIHRvIGRvIGl0IHdpdGggYSB0YWJs ZSBpbiBlYWNoIHNlcnZlciAod2hpY2ggaXMgDQoJPiBub3QgZ29vZCkuIA0KCT4gICAgICAgICA+ IA0KCT4gICAgICAgICA+VGhlIG90aGVyIHNvbHV0aW9uIGlzIHRvIHB1dCBwb2ludGVycyBpbiBl MTY0LmFycGEsIGVnIFNSViBSUiBvciANCgk+IGV2ZW4gTVggUlIuIA0KCT4gICAgICAgICA+VGhl IE1YIHJlY29yZCB3b3VsZCBnaXZlIGVnIHRoZSByb290IG9mIHRoZSBvdGhlciB0cmVlLCBhbmQg ZWFjaCANCgk+IHRyZWUgDQoJPiAgICAgICAgID53b3VsZCBiZSBzdHJ1Y3R1cmVkIGluIHRoZSBz YW5lIHdheSBsaWtlIGUxNjQuYXJwYSwgc28gdGhlIHNhbWUgDQoJPiBhbGdvcml0aG1zIA0KCT4g ICAgICAgICA+Y2FuIGJlIHVzZWQuIA0KCT4gICAgICAgICA+IA0KCT4gICAgICAgICA+U2luY2Ug dGhlIHN0cnVjdHVyZSBvZiB0aGUgZGVsZWdhdGlvbnMgaW4gZTE2NC5hcnBhIHZhcmllcyAoVGll ciANCgk+IDEgbGV2ZWxzKSwgDQoJPiAgICAgICAgID50aGVyZSBpcyBubyBlYXN5IHdheSB0byBm aW5kIG91dCB0aGUgbGV2ZWwgb2YgdGhlIHBvaW50ZXJzLCBldmVuIA0KCT4gaWYgdGhleSBhcmUg DQoJPiAgICAgICAgID5vbmx5IG9uIHRoZSBUaWVyIDEgbGF5ZXIuIA0KCT4gICAgICAgICA+IA0K CT4gICAgICAgICA+SXQgd2FzIHByb3Bvc2VkIHRvIHNlYXJjaCBlaXRoZXIgdG9wIGRvd24gKGZh c3Rlcikgb3IgYm90dG9tIHVwIA0KCT4gKG1vcmUgDQoJPiAgICAgICAgID5mbGV4aWJsZSksIGJl Y2F1c2UgdGhpcyB3b3VsZCBhbGxvdyBzdWItcG9saWNpZXMgaW4gbnVtYmVyIHJhbmdlcy4gDQoJ PiAgICAgICAgID4gDQoJPiAgICAgICAgID5ELiBBcmUgdGhlcmUgYWRkaXRpb25hbCBwb3NzaWJp bGl0aWVzIG9yIHByb3Bvc2Fscz8gDQoJPiAgICAgICAgID4gDQoJPiAgICAgICAgID5GaW5hbGx5 IEkgY29tZSB0byB0aGUgbGFzdCBpc3N1ZTogDQoJPiAgICAgICAgID4gDQoJPiAgICAgICAgID5G b3IgY2FzZSAxYSBhbmQgMWIgYWJvdmUgKG5vIHN1Y2ggbnVtYmVyKSBhbiAiZW51bXNlcnZpY2Ui IGlzIA0KCT4gbmVjZXNzYXJ5IA0KCT4gICAgICAgICA+dG8gaW5kaWNhdGUgdGhhdCB0aGVyZSBl eGlzdHMgbm8gc3VjaCBudW1iZXIsIG5laXRoZXIgaW4gRU5VTSANCgk+IG5vciBvbiB0aGUgDQoJ PiAgICAgICAgID5QU1ROLiANCgk+ICAgICAgICAgPiANCgk+ICAgICAgICAgPlByb3Bvc2FscyBz b2ZhciBhcmU6IA0KCT4gICAgICAgICA+IA0KCT4gICAgICAgICA+VXNlIGEgc3BlY2lhbCBmbGFn IGUuZy4gIm4iIG9yICJ2IiANCgk+ICAgICAgICAgPlVzZSBhICJlbnVtc2VydmljZSIgZS5nLiAi RTJVK05PTkUiIG9yICJFMlUrVk9JRCIgb3Igb25seSAiVk9JRCIgDQoJPiAgICAgICAgID4gDQoJ PiAgICAgICAgID5BbHNvIGhlcmUgYWRkaXRpb25hbCBwcm9wb3NhbHMgYXJlIGludml0ZWQuIA0K CT4gICAgICAgICA+IA0KCT4gICAgICAgICA+QmVzdCByZWdhcmRzIA0KCT4gICAgICAgICA+IA0K CT4gICAgICAgICA+UmljaGFyZCANCgk+ICAgICAgICAgPiANCgk+ICAgICAgICAgPiANCgk+ICAg ICAgICAgPiANCgk+ICAgICAgICAgPiANCgk+ICAgICAgICAgPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fIA0KCT4gICAgICAgICA+ZW51bSBtYWlsaW5nIGxp c3QgDQoJPiAgICAgICAgID5lbnVtQGlldGYub3JnIA0KCT4gDQoJID4gPjxodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbnVtPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2VudW0gDQoJPiANCgk+ICAgICAgICAgPiANCgk+ICAgICAgICAgPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIA0KCT4gICAgICAgICA+ SXB0ZWwgbWFpbGluZyBsaXN0IA0KCT4gICAgICAgICA+SXB0ZWxAaWV0Zi5vcmcgDQoJPiANCgkg PiA+PGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB0ZWw+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHRlbCANCgk+IA0KCT4gDQoJPiANCgk+IA0K CT56e3glXsOhwqbFvnpybcOhwqjCtj8gDQoJPjB1J35mZlgpbiANCg0KDQoJX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQoJZW51bSBtYWlsaW5nIGxpc3Qg DQoJZW51bUBpZXRmLm9yZyANCglodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9lbnVtIA0KDQo= _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 2 11:00:53 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 LAA15621 for ; Fri, 2 Apr 2004 11:00:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9OM2-0007Ae-UR for enum-archive@odin.ietf.org; Fri, 02 Apr 2004 08:05:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32D524x027564 for enum-archive@odin.ietf.org; Fri, 2 Apr 2004 08:05:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9LAe-00070e-SA; Fri, 02 Apr 2004 04:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9HiO-0005AW-UK for enum@optimus.ietf.org; Fri, 02 Apr 2004 00:59: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 AAA11366 for ; Fri, 2 Apr 2004 00:59:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9HiM-0001Jj-00 for enum@ietf.org; Fri, 02 Apr 2004 00:59:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9HhR-0001E5-00 for enum@ietf.org; Fri, 02 Apr 2004 00:58:41 -0500 Received: from mclean.mail.mindspring.net ([207.69.200.57]) by ietf-mx with esmtp (Exim 4.12) id 1B9Hgy-00018S-00 for enum@ietf.org; Fri, 02 Apr 2004 00:58:12 -0500 Received: from 1cust202.tnt36.dfw9.da.uu.net ([67.234.81.202] helo=ix.netcom.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1B9Hgq-0008UL-00; Fri, 02 Apr 2004 00:58:04 -0500 Message-ID: <406D1B2A.10EA1A12@ix.netcom.com> Date: Thu, 01 Apr 2004 23:50:06 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Robert.Shaw@itu.int CC: enum@ietf.org Subject: Re: [Enum] Interest in participating in APT-ITU Workshop on ENUM? References: <055DA814F0A9C643A0594D50C23D6C7B028750F4@mailsrv7.itu.ch> 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 Robert and all, Thanks for the info Bob. BTW what I would like to know is will you be bringing your own smokes this time?? >;) Robert.Shaw@itu.int wrote: > Hello, > > The Asia-Pacific Telecommunity (APT) is organizing the Asia Pacific Forum > on Telecommunication Policy and Regulation from May 17 to 20, 2004 in > Bandar Seri Begawan, Brunei Darussalam. This Forum will be followed by a > Joint APT/ITU Workshop on ENUM & IDN from 21 to 22 May 2004 at the same > venue. > > There may be subscribers to this list who may be interested in contributing > to the > ENUM part of the workshop on 22 May 2004 in Brunei Darussalam (for example, > to share individual country Asia-Pac experiences in implementing ENUM). If > so, > you are invited to contact me privately off this list to discuss potential > participation in the > workshop. > > Thanks, > > Robert > -- > Robert Shaw > ITU Internet Strategy and Policy Advisor > Strategy and Policy Unit > > _______________________________________________ > 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 Fri Apr 2 16:18: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 QAA00630 for ; Fri, 2 Apr 2004 16:18: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 1B9Shy-0001pp-Gw for enum-archive@odin.ietf.org; Fri, 02 Apr 2004 12:44:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32HhwgB007054 for enum-archive@odin.ietf.org; Fri, 2 Apr 2004 12:43:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9R4O-00087p-R0; Fri, 02 Apr 2004 10:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Nzm-0006Rl-3o for enum@optimus.ietf.org; Fri, 02 Apr 2004 07:42: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 HAA06995 for ; Fri, 2 Apr 2004 07:42:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Nzl-00017L-00 for enum@ietf.org; Fri, 02 Apr 2004 07:42:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Nyl-0000wc-00 for enum@ietf.org; Fri, 02 Apr 2004 07:41:01 -0500 Received: from sentosa.post1.com ([202.27.17.100]) by ietf-mx with smtp (Exim 4.12) id 1B9Ny2-0000hL-00 for enum@ietf.org; Fri, 02 Apr 2004 07:40:14 -0500 Received: (qmail 79817 invoked from network); 2 Apr 2004 12:59:09 -0000 Received: from bb220-255-104-113.singnet.com.sg (HELO JAMESTOSHIBA) (220.255.104.113) by sentosa.post1.com with SMTP; 2 Apr 2004 12:59:09 -0000 Message-ID: <001001c418af$8dc248c0$2d00a8c0@JAMESTOSHIBA> From: "James Seng" To: "James McEachern" , "'Michael Hammer'" Cc: "'Stastny Richard'" , References: <0D7FC1D8D861D511AEA70002A52CE5E6096E352C@zcard0ke.ca.nortel.com> Subject: Re: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Date: Fri, 2 Apr 2004 20:39:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA06996 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 RE: [Iptel] FW: [Enum] Summary on NoPSTN dicussionIn our IP Telephony/ENU= M proof-of-concept, one of the things we demostrate is the ability to make = a IP->PSTN call in US and JP but only incuring only US-PSTN or JP-PSTN char= ges. We did this by having a PSTN GW in US and also in JP. However, we do need= to do prior configuration on the dialing plan so that the SIP servers knows = how to route the call to US PSTGN-GW or JP PSTN-GW. Obviously, it is kind of silly...because we arent really using ENUM stric= tly speaking. And of cos, the "prior configuration" is not a scalable solutio= n in the long run. I envision it is possible to have multiple services providers in various countries who can route the call to PSTN, but there must be a more scalab= le, seamless voice routing system, ie. I pick up a phone (IP or normal PSTN),= dial a number, and it just ring the other party. In other words, I agree with Richard here. How do this in a scalable, standard mechanism is going to be challenge... But having said this, I am not sure enum@ietf.org is the appropriate foru= m to discuss this. -James Seng ----- Original Message -----=20 From: James McEachern To: 'Michael Hammer' Cc: 'Stastny Richard' ; enum@ietf.org Sent: Friday, April 02, 2004 6:43 AM Subject: RE: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Mike, I certainly don't want to curb your desire to get calls onto the IP netwo= rk as soon as possible... I don't think the PSTN-to-IP GW needs to know the mapping to every teleph= one number in the world to route it using IP. If the number is assigned to a Service Provider using techniques like those used today, then the GW shou= ld be able to know which SP the number maps to - and route on that basis. This = could be done with Carrier ENUM, or with traditional routing and translations - either one could work. There is no reason whatsoever why "PSTN routing" c= annot select IP "trunks" to another VoIP network. (Of course this would not be = true for ENUM-only numbers.) Public ENUM (in those cases where the subscriber has opted-in) can accele= rate and refine this, but there is no reason to wait for it to get started mov= ing to end-to-end IP. Jim -----Original Message-----=20 From: Michael Hammer [mailto:mhammer@cisco.com] Sent: Tuesday, March 30, 2004 5:47 PM To: McEachern, James [CAR:5N00:EXCH] Cc: 'Stastny Richard'; enum@ietf.org Subject: RE: [Iptel] FW: [Enum] Summary on NoPSTN dicussion James, I guess I have to curb my desire to get the call onto the IP network as soon as possible rather than as late as possible. In today's environment, I think we have pockets of IP networks interconnected by the global PSTN. One of the characteristics of the PST= N 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 PST= N 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. 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. 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 t= o 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. I was also conjecturing what it means to "own" a telephone number. In th= e 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. How is this going to wor= k 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? I would hope that even if an individual number was unlisted, if a block o= f 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. I confess I have not been watching the ENUM list, but perhaps should 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---=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. > > >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 th= e >number is unassigned and release the call." > >---end snip---=20 > >This seems to suggest that routing to an IP endpoint would require an EN= UM >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-----=20 >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 o= n 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-----=20 > 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 referen= ced > 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 whethe= r > to a PSTN > endpoint or an IP endpoint. > > Another concern is that, if you do get looped routing between t= he > 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 lag= s > from when > an SP assigns a number and when it gets reflected in one or ano= ther > databases. If you want the ENUM and LNP databases to be somewh= at > 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 t= he > PSTN, > with default behavior being, if unknown to ENUM, send to PSTN t= o > resolve. (Note this is orthogonal to ENUMs use to select > alternative > endpoints.) > > - If endpoint is IP, then the LNP databases should point to t= he IP > domain, with default behavior being, if unknown to LNP, route i= n > 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 coul= d > 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 bo= th > an LNP > and an ENUM dip have not resolved the route, can safely conclud= e > 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-----=20 > >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 is= sue, > >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 followin= g 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 form= at > >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-que= ry > >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 pr= event > >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 NXDO= MAIN, > >the current assumption of all clients is: the call is routed t= o the > >PSTN if the server is able to do so (eventually with the ;enum= di > 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 ENU= M- > >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 yo= u > >do not find one in ENUM, you also will not find one on the PST= N, so > >it makes no sense to route it to the PSTN (ENUM-only) > >2. Default routing for the whole number range (number block) t= o > 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 ca= se > 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 ope= ns > up access > >to the Internet via a gateway (border element, ...), he may wa= nt > 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 n= o > 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.arp= a. > >The second tree would contain only wildcard NAPTR RR for numbe= r > 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 o= ne > 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 ea= ch > tree > >would be structured in the sane way like e164.arpa, so the sam= e > algorithms > >can be used. > > > >Since the structure of the delegations in e164.arpa varies (Ti= er > 1 levels), > >there is no easy way to find out the level of the pointers, ev= en > if they are > >only on the Tier 1 layer. > > > >It was proposed to search either top down (faster) or bottom u= p > (more > >flexible), because this would allow sub-policies in number ran= ges. > > > >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 "VOI= D" > > > >Also here additional proposals are invited. > > > >Best regards > > > >Richard > > > > > > > > > >_______________________________________________ > >enum mailing list > >enum@ietf.org > > >https://www1.ietf.org/mailm= an/li stinfo/enum > > > > >_______________________________________________ > >Iptel mailing list > >Iptel@ietf.org > > >https://www.ietf.org/mailma= n/lis tinfo/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 From exim@www1.ietf.org Fri Apr 2 16:37:56 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 QAA02302 for ; Fri, 2 Apr 2004 16:37:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WLw-00068Y-6q for enum-archive@odin.ietf.org; Fri, 02 Apr 2004 16:37:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LbSiI023543 for enum-archive@odin.ietf.org; Fri, 2 Apr 2004 16:37:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WLj-0005x3-0l; Fri, 02 Apr 2004 16:37:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9U98-0006n8-83 for enum@optimus.ietf.org; Fri, 02 Apr 2004 14:16:06 -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 OAA23180 for ; Fri, 2 Apr 2004 14:16:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9U95-00000B-00 for enum@ietf.org; Fri, 02 Apr 2004 14:16:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9U89-0007hZ-00 for enum@ietf.org; Fri, 02 Apr 2004 14:15:05 -0500 Received: from falcon.verisign.com ([216.168.239.71]) by ietf-mx with esmtp (Exim 4.12) id 1B9U7H-0007Ut-00 for enum@ietf.org; Fri, 02 Apr 2004 14:14:11 -0500 Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id i32JEPop002540 for ; Fri, 2 Apr 2004 14:14:25 -0500 (EST) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 2 Apr 2004 14:13:41 -0500 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF030DF9BF@vsvapostal8.vcorp.ad.vrsn.com> From: "Hollenbeck, Scott" To: "'enum@ietf.org'" Date: Fri, 2 Apr 2004 14:14:22 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Enum] EPP-ENUM Draft Updated 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: , With the EPP RFCs having been published last week, I have updated my expired I-D describing an ENUM extension for EPP. It should be announced and available shortly. -Scott- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 2 16:37: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 QAA02309 for ; Fri, 2 Apr 2004 16:37: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 1B9WLw-00068d-7C for enum-archive@odin.ietf.org; Fri, 02 Apr 2004 16:37:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LbSle023544 for enum-archive@odin.ietf.org; Fri, 2 Apr 2004 16:37:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WLj-0005xg-Qe; Fri, 02 Apr 2004 16:37:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9UA8-0006pB-7i for enum@optimus.ietf.org; Fri, 02 Apr 2004 14:17:11 -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 OAA23192 for ; Fri, 2 Apr 2004 14:17:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9UA5-00007R-00 for enum@ietf.org; Fri, 02 Apr 2004 14:17:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9U98-00000b-00 for enum@ietf.org; Fri, 02 Apr 2004 14:16:07 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B9U8e-0007hm-00 for enum@ietf.org; Fri, 02 Apr 2004 14:15:36 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 02 Apr 2004 11:24:21 -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 i32JF4cp022871; Fri, 2 Apr 2004 14:15:04 -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 AYE51440; Fri, 2 Apr 2004 11:15:02 -0800 (PST) Message-Id: <4.3.2.7.2.20040402140710.00b44d20@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Apr 2004 14:15:02 -0500 To: "James McEachern" From: Michael Hammer Subject: RE: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Cc: Stastny Richard , "Pfautz, Penn L, ALABS" , enum@ietf.org In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E6096E3532@zcard0ke.ca.norte l.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=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: , I think we are aligned, except for the bit about how a TDM switch "knows" that a number presented to it is ENUM-only. Is this a special country or area/city code? If so, then yes the call could be routed to the ENUM-enabled GW, which then could presumable fetch the user ENUM or carrier ENUM record, and route accordingly. Then, I guess the only question is how every ENUM-only telephone number can match some ENUM record. For that, I am not sure why two trees versus one is better or worse to traverse to find that record. Perhaps the ENUM veterans could explain that. Mike At 01:55 PM 4/2/2004 -0500, James McEachern wrote: >Comments inline > >-----Original Message----- >From: Michael Hammer [mailto:mhammer@cisco.com] >Sent: Friday, April 02, 2004 10:15 AM > >Don't expect the PSTN to be reprogrammed to know it is an ENUM only >number. The switches will simply be configured to route to a particular GW >because that is the "home switch" for that number. >[Jim McE] This was essentially what I meant when I said the PSTN would >need to know it was an ENUM-only number. > >If a number originally >belonged to a TDM switch and gets ported to the GW, then the NP database >will indicate that. Beyond that don't expect much. >[Jim McE] Agreed - but unless I'm missing something, this would not apply >to ENUM-only numbers, as an ENUM-only number would never have originally >belonged to a TDM switch. > >Once the call is directed to that GW, it has two possibilities: >1) it has configured information about that number, >2) it can do an ENUM look up. >Lacking both, that call gets released. > >If you have an ENUM-only number, then the GW needs to know which GW that >number is homed to, and preferably route within the IP domain to that >GW. >[Jim McE] If you have an ENUM-only number, wouldn't the PSTN just route to >the nearest ENUM enabled GW where an ENUM dip would be done so the call >could be routed to the end device in the IP domain? > >This is where the carrier ENUM entry would help. > >If this ENUM-only belongs to a user (and not associated with a carrier?), I >hope they have an entry in ENUM. What does it mean to have an ENUM-only >number and to not opt-in? >[Jim McE] I've wondered about this one myself. Is it a valid scenario? >Should we worry about it? > >Either there is a GW with configuration >information to do the further routing, or the call dies, i.e., is >unreachable except for folks that know your IP address. But then why have >a E.164 number at all? So, if you have an E.164 number assigned, you must >have an ENUM entry, either pointing directly to your IP addresses, or to a >carrier GW that can act on your behalf. > >Mike _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 2 16:37:58 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 QAA02308 for ; Fri, 2 Apr 2004 16:37: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 1B9WLw-00068l-81 for enum-archive@odin.ietf.org; Fri, 02 Apr 2004 16:37:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LbSpg023542 for enum-archive@odin.ietf.org; Fri, 2 Apr 2004 16:37:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WLe-0005rc-UL; Fri, 02 Apr 2004 16:37:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Trl-00067X-4K for enum@optimus.ietf.org; Fri, 02 Apr 2004 13:58: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 NAA22873 for ; Fri, 2 Apr 2004 13:58:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Tri-0005jy-00 for enum@ietf.org; Fri, 02 Apr 2004 13:58:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Tqm-0005dJ-00 for enum@ietf.org; Fri, 02 Apr 2004 13:57:09 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1B9TqG-0005Vp-00 for enum@ietf.org; Fri, 02 Apr 2004 13:56:36 -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 i32ItrZ01763; Fri, 2 Apr 2004 13:55:53 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Apr 2004 13:55:53 -0500 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6096E3532@zcard0ke.ca.nortel.com> From: "James McEachern" To: "'Michael Hammer'" , Stastny Richard Cc: "Pfautz, Penn L, ALABS" , enum@ietf.org Subject: RE: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Date: Fri, 2 Apr 2004 13:55:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C418E4.1F7AF15C" 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_20_30,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_01C418E4.1F7AF15C Content-Type: text/plain Comments inline -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com] Sent: Friday, April 02, 2004 10:15 AM Don't expect the PSTN to be reprogrammed to know it is an ENUM only number. The switches will simply be configured to route to a particular GW because that is the "home switch" for that number. [Jim McE] This was essentially what I meant when I said the PSTN would need to know it was an ENUM-only number. If a number originally belonged to a TDM switch and gets ported to the GW, then the NP database will indicate that. Beyond that don't expect much. [Jim McE] Agreed - but unless I'm missing something, this would not apply to ENUM-only numbers, as an ENUM-only number would never have originally belonged to a TDM switch. Once the call is directed to that GW, it has two possibilities: 1) it has configured information about that number, 2) it can do an ENUM look up. Lacking both, that call gets released. If you have an ENUM-only number, then the GW needs to know which GW that number is homed to, and preferably route within the IP domain to that GW. [Jim McE] If you have an ENUM-only number, wouldn't the PSTN just route to the nearest ENUM enabled GW where an ENUM dip would be done so the call could be routed to the end device in the IP domain? This is where the carrier ENUM entry would help. If this ENUM-only belongs to a user (and not associated with a carrier?), I hope they have an entry in ENUM. What does it mean to have an ENUM-only number and to not opt-in? [Jim McE] I've wondered about this one myself. Is it a valid scenario? Should we worry about it? Either there is a GW with configuration information to do the further routing, or the call dies, i.e., is unreachable except for folks that know your IP address. But then why have a E.164 number at all? So, if you have an E.164 number assigned, you must have an ENUM entry, either pointing directly to your IP addresses, or to a carrier GW that can act on your behalf. Mike ------_=_NextPart_001_01C418E4.1F7AF15C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN = dicussion

Comments inline

-----Original Message-----
From: Michael Hammer [mailto:mhammer@cisco.com]
Sent: Friday, April 02, 2004 10:15 AM

Don't expect the PSTN to be reprogrammed to know it = is an ENUM only
number.  The switches will simply be configured = to route to a particular GW
because that is the "home switch" for that = number. 
[Jim McE] This was essentially what I meant when I = said the PSTN would need to know it was an ENUM-only number.

If a number originally
belonged to a TDM switch and gets ported to the GW, = then the NP database
will indicate that.  Beyond that don't expect = much.
[Jim McE] Agreed - but unless I'm missing something, = this would not apply to ENUM-only numbers, as an ENUM-only number would = never have originally belonged to a TDM switch.

Once the call is directed to that GW, it has two = possibilities:
1) it has configured information about that = number,
2) it can do an ENUM look up.
Lacking both, that call gets released.

If you have an ENUM-only number, then the GW needs to = know which GW that
number is homed to, and preferably route within the = IP domain to that
GW. 
[Jim McE] If you have an ENUM-only number, wouldn't = the PSTN just route to the nearest ENUM enabled GW where an ENUM dip = would be done so the call could be routed to the end device in the IP = domain?

This is where the carrier ENUM entry would = help.

If this ENUM-only belongs to a user (and not = associated with a carrier?), I
hope they have an entry in ENUM.  What does it = mean to have an ENUM-only
number and to not opt-in? 
[Jim McE] I've wondered about this one myself. Is it = a valid scenario? Should we worry about it?

Either there is a GW with configuration
information to do the further routing, or the call = dies, i.e., is
unreachable except for folks that know your IP = address.  But then why have
a E.164 number at all?  So, if you have an = E.164 number assigned, you must
have an ENUM entry, either pointing directly to your = IP addresses, or to a
carrier GW that can act on your behalf.

Mike


------_=_NextPart_001_01C418E4.1F7AF15C-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 2 16:49: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 QAA03999 for ; Fri, 2 Apr 2004 16:49: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 1B9VXC-0006vK-HO for enum-archive@odin.ietf.org; Fri, 02 Apr 2004 15:45:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32Kj2qn026614 for enum-archive@odin.ietf.org; Fri, 2 Apr 2004 15:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SJo-0007fY-W2; Fri, 02 Apr 2004 12:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95LL-00011G-26 for enum@optimus.ietf.org; Thu, 01 Apr 2004 11: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 LAA17589 for ; Thu, 1 Apr 2004 11:01:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94dA-0001NY-00 for enum@ietf.org; Thu, 01 Apr 2004 11:01:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94c8-0001BE-00 for enum@ietf.org; Thu, 01 Apr 2004 11:00:21 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1B94bG-0000wr-00 for enum@ietf.org; Thu, 01 Apr 2004 10:59:26 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 01 Apr 2004 07:58:33 -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 i31Fwrcp029451; Thu, 1 Apr 2004 10:58:53 -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 AYD57303; Thu, 1 Apr 2004 07:58:47 -0800 (PST) Message-Id: <4.3.2.7.2.20040401103346.00b4e5d0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Apr 2004 10:58:47 -0500 To: "Stastny Richard" From: Michael Hammer Subject: Re: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Cc: "James McEachern" , In-Reply-To: <06CF906FE3998C4E944213062009F162233C92@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.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, So, if I might summarize what you have said, there are four attributes that result in different combinations: Geographic or not? Y N N Public (NP) or not? Y Y/N ? (row: NP/regulatory requirements) VoIP or not? Y/N Y Y ENUM or not? opt-in? opt-in? Y Case 1-2 Case 3 Case 4 (NP inherent) There are probably 16 combinations, of which many don't make sense or aren't used. I was unclear about whether being an ENUM number allowed you to opt in or out, i.e. what does an unlisted ENUM number mean. It would greatly simplify things, if there were few combinations. But, this all comes down to routing based on configuration, database, or both. And for calls to reach someone, one or the other must exist, even if only on the calling party's terminal. Mike At 09:35 AM 4/1/2004 +0200, Stastny Richard wrote: >Mike wrote: > > >>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 > >TDM-only, but then (over time) converts to an IP-only > network? The SPs are > >very guarded about the E.164 numbers assigned to them. That is > what I > >meant by "owned." You are suggesting that when a person with a > phone > >number assigned by an SP moves to an IP-based "phone" that the > SP will > >relinquish that phone number back to the NRA? Or are you saying > that > >number portability doesn't work between TDM and IP worlds? > > We are talking here about four different things here: > Case 1: a VoIP provider is also an ILEC (eg a cable operator) > and gets a > number (geographic) range (block) assigned and assignes them to > his users. > Since number assignement is technology independent, there is no > problem here, > as long as the SP is providing a telephony service as usual (we > call this PATS - > Publicly Available Telephony Service in Europe). > Note: some VoIP SP hide between small ILECs and get such number > ranges > via them (e.g Vonage, sipgate.de, ...) > > Case 2: Since all normal rules apply, also LNP applies, so users > may port > their numbers back and forth between PSTN and VoIP SP > > Case 3: The regulator reserves a special number range for VoIP > (050 in > Japan, 05x in UK, 032 in Germany). If these services are declared > non-PATS > NP does not apply (this is under discussion). In Japan there is > also a lighter > regime regarding QoS. Regulations differ here in all countries. > In this case the VoIP SP also get blocks of numbers and route > them to their GW. > I know, in the US there is no such number range. The problem I > have with > such an approach is that there are differnt rules in every > country and end-users > get restricted services. (e.g no NP, no access to emergence > services, etc. > IMHO this will cause problems in the future > > Case 4. the regulator reserves a special number range for > ENUM-only routed > numbers. This should be done directly to the end-user. The > advantage is > that you have NP built-in, without having to deal with normal LNP > issues and > technology, saving the SP much effort. > > The difference between case 3 and 4 is that in case 3 no rules > exist for NP and > interconnect on IP, so you create VoIP Island that are > interconnected only via > the PSTN per default. If you interconnect on IP, you can do this > only currently > with bilateral agreements. In case 4 you have automatically NP > and also interconnect > because you can use ENUM also on IP to interconnect. This is BTW > also drafted > in the SIP Forum Service Provider WG Interconnect Consensus. > > >>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 > >blocks, and there is a migration of many users from TDM to IP, > then do you > >lengthen the number to 11 digits to get more, or do the SPs have to > >relinquish numbers? > > This a typical NANP problem. In the NANP there is only geographic > area > codes (with the exception of 800 numbers). In most other country > there are > more number types: you have geographic and non-geographic numbers. > > Non-geo numbers are eg mobile numbers, personal numbers, etc. The > advantage > here is that you relieve the pressure on the number exhaust here. > Since geo > numbers are given away in blocks, you have a lot of unused numbers. > Eg in Austria the geo numbers are using up a great chunk of the > numbers: > we have 1100 4-digit area codes used be appox 4 Mio subscribers, > on the other hand, we have 5 (five) 3-digit mobile number ranges > used by 4,5 Mio subscribers (80% of them are behind 2 mobile > "area" codes). > > The reason is simple: the mobile number ranges are flat. So if we > give eg > one 3-digit number range to ENUM, we can instantly use them with > additional 7-digits for 9.999.999 subscribers. > > regards > > Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 2 16:50:13 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 QAA04042 for ; Fri, 2 Apr 2004 16:50:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9VaH-00079U-0l for enum-archive@odin.ietf.org; Fri, 02 Apr 2004 15:48:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32KmDVa027490 for enum-archive@odin.ietf.org; Fri, 2 Apr 2004 15:48:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SJp-0007fh-F3; Fri, 02 Apr 2004 12:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99IU-0002OP-9c for enum@optimus.ietf.org; Thu, 01 Apr 2004 16:00:25 -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 QAA02404 for ; Thu, 1 Apr 2004 16:00:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B99IS-00035F-00 for enum@ietf.org; Thu, 01 Apr 2004 16:00:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B99HZ-00030S-00 for enum@ietf.org; Thu, 01 Apr 2004 15:59:26 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B99Gg-0002q9-00 for enum@ietf.org; Thu, 01 Apr 2004 15:58:30 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 01 Apr 2004 13:07:05 -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 i31KvvA6015413; Thu, 1 Apr 2004 15:57:57 -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 AYD85346; Thu, 1 Apr 2004 12:57:53 -0800 (PST) Message-Id: <4.3.2.7.2.20040401154637.00b5ba38@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Apr 2004 15:57:53 -0500 To: "Pfautz, Penn L, ALABS" From: Michael Hammer Subject: RE: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Cc: "Stastny Richard" , "James McEachern" , In-Reply-To: <34DA635B184A644DA4588E260EC0A25A06AA2ED5@ACCLUST02EVS1.ugd .att.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 This sounds reasonable to me, but I would rather hear from the DNS experts. My assumption, as you note below, was that if the number was not in ENUM,=20 then the only element that knows whether the number is assigned and=20 reachable is the operator PSTN-IP GW that has a configured translation or=20 knows that the number is unassigned. Mike At 12:11 PM 4/1/2004 -0500, Pfautz, Penn L, ALABS wrote: >If I understand it the root issue is this: >All E.164 numbers will have a PSTN point-of-interface, but for some=20 >numbers that POI is a gateway to IP. Further some subset of these numbers= =20 >are ones that won't be assigned if they're not reachable through IP. So,=20 >in order to avoid routing to the default gateway after an ENUM query that= =20 >returns no result because the number is unassigned, people are seeking=20 >some mechanism to provide a response to the initial ENUM query to indicate= =20 >that attempts to route through the PSTN will be fuitless. And the need is= =20 >to do this without treading on the opt-in principle. > >Here's a thought which the more DNS/DDDS literate may be able to confirm=20 >or shoot down: >At Tier 1, instead of populating an NS record with the tier 2 delegation=20 >for each number instead populate a pair of non-terminal NAPTR records with= =20 >different service fields (e.g., E2U and E2C) which would point to the=20 >domains for the end user Tier 2 and carrier Tier 2 respectively. In this=20 >way, a single query would provide pointers into both trees and a client=20 >could decide whether to pursue one or the other, or potentially both. For= =20 >non-assigned "ENUM-only" numbers, the carrier could populate the E2C=20 >record only without treading on the perogatives of the end user or having= =20 >to instantiate a separate Tier 1. >Such E2C records could not only address the NoPSTN issue but also be the=20 >basis for a carrier or infrastructure ENUM capability that may become more= =20 >important as VoIP moves beyond arbitrage to where IP interconnection=20 >becomes norm. > >Penn Pfautz > > >-----Original Message----- >From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of >Stastny Richard >Sent: Thursday, April 01, 2004 2:36 AM >To: Michael Hammer >Cc: James McEachern; enum@ietf.org >Subject: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion > > >Mike wrote: > > >>First, no number is owner by anybody, it is assigned by ITU-T=20 > to the NRA, > >>and assigned in turn to the SP, and the SP assignes it to the=20 > 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= =20 > used to be > >TDM-only, but then (over time) converts to an IP-only=20 > network? The SPs are > >very guarded about the E.164 numbers assigned to them. That is= =20 > what I > >meant by "owned." You are suggesting that when a person with a= =20 > phone > >number assigned by an SP moves to an IP-based "phone" that the=20 > SP will > >relinquish that phone number back to the NRA? Or are you saying= =20 > that > >number portability doesn't work between TDM and IP worlds? > > We are talking here about four different things here: > Case 1: a VoIP provider is also an ILEC (eg a cable operator)=20 > and gets a > number (geographic) range (block) assigned and assignes them to=20 > his users. > Since number assignement is technology independent, there is no=20 > problem here, > as long as the SP is providing a telephony service as usual (we=20 > call this PATS - > Publicly Available Telephony Service in Europe). > Note: some VoIP SP hide between small ILECs and get such number=20 > ranges > via them (e.g Vonage, sipgate.de, ...) > > Case 2: Since all normal rules apply, also LNP applies, so users= =20 > may port > their numbers back and forth between PSTN and VoIP SP > > Case 3: The regulator reserves a special number range for VoIP=20 > (050 in > Japan, 05x in UK, 032 in Germany). If these services are declared= =20 > non-PATS > NP does not apply (this is under discussion). In Japan there is=20 > also a lighter > regime regarding QoS. Regulations differ here in all countries. > In this case the VoIP SP also get blocks of numbers and route=20 > them to their GW. > I know, in the US there is no such number range. The problem I=20 > have with > such an approach is that there are differnt rules in every=20 > country and end-users > get restricted services. (e.g no NP, no access to emergence=20 > services, etc. > IMHO this will cause problems in the future > > Case 4. the regulator reserves a special number range for=20 > ENUM-only routed > numbers. This should be done directly to the end-user. The=20 > advantage is > that you have NP built-in, without having to deal with normal LNP= =20 > issues and > technology, saving the SP much effort. > > The difference between case 3 and 4 is that in case 3 no rules=20 > exist for NP and > interconnect on IP, so you create VoIP Island that are=20 > interconnected only via > the PSTN per default. If you interconnect on IP, you can do this= =20 > only currently > with bilateral agreements. In case 4 you have automatically NP=20 > and also interconnect > because you can use ENUM also on IP to interconnect. This is BTW= =20 > also drafted > in the SIP Forum Service Provider WG Interconnect Consensus. > > >>With ENUM-only numbers there is no need to assign blocks of=20 > numbers. > >>An ENUM-only number is the equivalent of a domain name. It is=20 > assigned > >>to the end-user directly, who chooses the SP, like with a=20 > 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=20 > current NPA > >blocks, and there is a migration of many users from TDM to IP,=20 > then do you > >lengthen the number to 11 digits to get more, or do the SPs have= to > >relinquish numbers? > > This a typical NANP problem. In the NANP there is only geographic= =20 > area > codes (with the exception of 800 numbers). In most other country= =20 > there are > more number types: you have geographic and non-geographic numbers. > > Non-geo numbers are eg mobile numbers, personal numbers, etc. The= =20 > advantage > here is that you relieve the pressure on the number exhaust here.= =20 > Since geo > numbers are given away in blocks, you have a lot of unused= numbers. > Eg in Austria the geo numbers are using up a great chunk of the=20 > numbers: > we have 1100 4-digit area codes used be appox 4 Mio subscribers, > on the other hand, we have 5 (five) 3-digit mobile number ranges > used by 4,5 Mio subscribers (80% of them are behind 2 mobile=20 > "area" codes). > > The reason is simple: the mobile number ranges are flat. So if we= =20 > give eg > one 3-digit number range to ENUM, we can instantly use them with > additional 7-digits for 9.999.999 subscribers. > > regards > > Richard > >z{x%^zm?0'~ffX)=DF=A3 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 2 16:50: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 QAA04111 for ; Fri, 2 Apr 2004 16:50: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 1B9Vcl-0007cv-Js for enum-archive@odin.ietf.org; Fri, 02 Apr 2004 15:50:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32KolhT029311 for enum-archive@odin.ietf.org; Fri, 2 Apr 2004 15:50:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SJp-0007gN-Un; Fri, 02 Apr 2004 12:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9QPi-0002kU-V2 for enum@optimus.ietf.org; Fri, 02 Apr 2004 10:17:04 -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 KAA12980 for ; Fri, 2 Apr 2004 10:16:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9QPg-0005QV-00 for enum@ietf.org; Fri, 02 Apr 2004 10:16:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9QOk-0005Ik-00 for enum@ietf.org; Fri, 02 Apr 2004 10:16:00 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1B9QNw-00053k-00 for enum@ietf.org; Fri, 02 Apr 2004 10:15:08 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 02 Apr 2004 07:14:37 -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 i32FEacp003473; Fri, 2 Apr 2004 10:14:36 -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 AYE30852; Fri, 2 Apr 2004 07:14:31 -0800 (PST) Message-Id: <4.3.2.7.2.20040402100218.00b4a580@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Apr 2004 10:14:31 -0500 To: "Stastny Richard" From: Michael Hammer Subject: Re: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Cc: "James McEachern" , "Pfautz, Penn L, ALABS" , In-Reply-To: <06CF906FE3998C4E944213062009F162233C9A@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 Don't expect the PSTN to be reprogrammed to know it is an ENUM only=20 number. The switches will simply be configured to route to a particular GW= =20 because that is the "home switch" for that number. If a number originally= =20 belonged to a TDM switch and gets ported to the GW, then the NP database=20 will indicate that. Beyond that don't expect much. Once the call is directed to that GW, it has two possibilities: 1) it has configured information about that number, 2) it can do an ENUM look up. Lacking both, that call gets released. If you have an ENUM-only number, then the GW needs to know which GW that=20 number is homed to, and preferably route within the IP domain to that=20 GW. This is where the carrier ENUM entry would help. If this ENUM-only belongs to a user (and not associated with a carrier?), I= =20 hope they have an entry in ENUM. What does it mean to have an ENUM-only=20 number and to not opt-in? Either there is a GW with configuration=20 information to do the further routing, or the call dies, i.e., is=20 unreachable except for folks that know your IP address. But then why have= =20 a E.164 number at all? So, if you have an E.164 number assigned, you must= =20 have an ENUM entry, either pointing directly to your IP addresses, or to a= =20 carrier GW that can act on your behalf. Mike At 04:32 AM 4/2/2004 +0200, Stastny Richard wrote: >Jim wrote: > > If the E.164 number has been assigned to a SP providing a PATS,=20 > then the PSTN will (must - because of opt-in) always know how to route to= =20 > the appropriate SP, and the SP in turn knows how to route to the device.= =20 > If the number is an ENUM only number, then the PSTN will need to know=20 > this (both the fact that it is a valid number so it does not reject it,=20 > and the fact that it is an ENUM-only number so that it can route it to an= =20 > ENUM enabled GW). The PSTN will be able to determine this using existing= =20 > routing & translation techniques - nothing more is required. > > So the entire problem comes down to how the VoIP network can=20 > recognize that a number is an "ENUM-only" number, and not route this to=20 > the PSTN if there is no ENUM entry. For all other cases routing to the=20 > PSTN works fine. This means that whatever solution we come up with, it is= =20 > only necessary to apply it to ENUM-only numbers. (We *may* decide it is=20 > valuable to also apply it to other numbers, but if it complicates things= =20 > this is not necessary.) > > Am I missing something? > > >Richard: > No, this is the prime requirement, all other things are nice to=20 > have. On the > other hand, if we find a solution which is also automatically=20 > solving the > other niceties, we caould use it for this also. I will try to sum= =20 > up the proposed > solutions next week, so we can decide on the best way forward. > > I talked to Rich Shockey today and the plan is to have a=20 > principal idea > within the next weeks to have this written down for San Diego in= =20 > time. > > Richard > > > > Jim > > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Thursday, April 01, 2004 3:58 PM > To: Pfautz, Penn L, ALABS > Cc: Stastny Richard; McEachern, James [CAR:5N00:EXCH];= enum@ietf.org > Subject: RE: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion > > This sounds reasonable to me, but I would rather hear from the=20 > DNS experts. > > My assumption, as you note below, was that if the number was not= =20 > in ENUM, > then the only element that knows whether the number is assigned= and > reachable is the operator PSTN-IP GW that has a configured=20 > translation or > knows that the number is unassigned. > > Mike > > > At 12:11 PM 4/1/2004 -0500, Pfautz, Penn L, ALABS wrote: > >If I understand it the root issue is this: > >All E.164 numbers will have a PSTN point-of-interface, but for= some > >numbers that POI is a gateway to IP. Further some subset of=20 > these numbers > >are ones that won't be assigned if they're not reachable through= =20 > IP. So, > >in order to avoid routing to the default gateway after an ENUM=20 > query that > >returns no result because the number is unassigned, people are=20 > seeking > >some mechanism to provide a response to the initial ENUM query=20 > to indicate > >that attempts to route through the PSTN will be fuitless. And=20 > the need is > >to do this without treading on the opt-in principle. > > > >Here's a thought which the more DNS/DDDS literate may be able to= =20 > confirm > >or shoot down: > >At Tier 1, instead of populating an NS record with the tier 2=20 > delegation > >for each number instead populate a pair of non-terminal NAPTR=20 > records with > >different service fields (e.g., E2U and E2C) which would point= =20 > to the > >domains for the end user Tier 2 and carrier Tier 2 respectively.= =20 > In this > >way, a single query would provide pointers into both trees and a= =20 > client > >could decide whether to pursue one or the other, or potentially= =20 > both. For > >non-assigned "ENUM-only" numbers, the carrier could populate the= =20 > E2C > >record only without treading on the perogatives of the end user= =20 > or having > >to instantiate a separate Tier 1. > >Such E2C records could not only address the NoPSTN issue but=20 > also be the > >basis for a carrier or infrastructure ENUM capability that may=20 > become more > >important as VoIP moves beyond arbitrage to where IP=20 > interconnection > >becomes norm. > > > >Penn Pfautz > > > > > >-----Original Message----- > >From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf= Of > >Stastny Richard > >Sent: Thursday, April 01, 2004 2:36 AM > >To: Michael Hammer > >Cc: James McEachern; enum@ietf.org > >Subject: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion > > > > > >Mike wrote: > > > > >>First, no number is owner by anybody, it is assigned= =20 > by ITU-T > > to the NRA, > > >>and assigned in turn to the SP, and the SP assignes=20 > it to the > > end-user (for > > >>geographic numbers. Service numbers are already=20 > 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=20 > an SP, that > > used to be > > >TDM-only, but then (over time) converts to an IP-only > > network? The SPs are > > >very guarded about the E.164 numbers assigned to=20 > them. That is > > what I > > >meant by "owned." You are suggesting that when a=20 > person with a > > phone > > >number assigned by an SP moves to an IP-based "phone"= =20 > that the > > SP will > > >relinquish that phone number back to the NRA? Or are= =20 > you saying > > that > > >number portability doesn't work between TDM and IP=20 > worlds? > > > > We are talking here about four different things here: > > Case 1: a VoIP provider is also an ILEC (eg a cable=20 > operator) > > and gets a > > number (geographic) range (block) assigned and assignes= =20 > them to > > his users. > > Since number assignement is technology independent,=20 > there is no > > problem here, > > as long as the SP is providing a telephony service as=20 > usual (we > > call this PATS - > > Publicly Available Telephony Service in Europe). > > Note: some VoIP SP hide between small ILECs and get=20 > such number > > ranges > > via them (e.g Vonage, sipgate.de, ...) > > > > Case 2: Since all normal rules apply, also LNP applies,= =20 > so users > > may port > > their numbers back and forth between PSTN and VoIP SP > > > > Case 3: The regulator reserves a special number range=20 > for VoIP > > (050 in > > Japan, 05x in UK, 032 in Germany). If these services=20 > are declared > > non-PATS > > NP does not apply (this is under discussion). In Japan= =20 > there is > > also a lighter > > regime regarding QoS. Regulations differ here in all=20 > countries. > > In this case the VoIP SP also get blocks of numbers and= =20 > route > > them to their GW. > > I know, in the US there is no such number range. The=20 > problem I > > have with > > such an approach is that there are differnt rules in= every > > country and end-users > > get restricted services. (e.g no NP, no access to=20 > emergence > > services, etc. > > IMHO this will cause problems in the future > > > > Case 4. the regulator reserves a special number range= for > > ENUM-only routed > > numbers. This should be done directly to the end-user.= The > > advantage is > > that you have NP built-in, without having to deal with= =20 > normal LNP > > issues and > > technology, saving the SP much effort. > > > > The difference between case 3 and 4 is that in case 3=20 > no rules > > exist for NP and > > interconnect on IP, so you create VoIP Island that are > > interconnected only via > > the PSTN per default. If you interconnect on IP, you=20 > can do this > > only currently > > with bilateral agreements. In case 4 you have=20 > automatically NP > > and also interconnect > > because you can use ENUM also on IP to interconnect.=20 > This is BTW > > also drafted > > in the SIP Forum Service Provider WG Interconnect=20 > Consensus. > > > > >>With ENUM-only numbers there is no need to assign=20 > blocks of > > numbers. > > >>An ENUM-only number is the equivalent of a domain=20 > name. It is > > assigned > > >>to the end-user directly, who chooses the SP, like=20 > 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= =20 > of the > > current NPA > > >blocks, and there is a migration of many users from=20 > TDM to IP, > > then do you > > >lengthen the number to 11 digits to get more, or do=20 > the SPs have to > > >relinquish numbers? > > > > This a typical NANP problem. In the NANP there is only= =20 > geographic > > area > > codes (with the exception of 800 numbers). In most=20 > other country > > there are > > more number types: you have geographic and=20 > non-geographic numbers. > > > > Non-geo numbers are eg mobile numbers, personal=20 > numbers, etc. The > > advantage > > here is that you relieve the pressure on the number=20 > exhaust here. > > Since geo > > numbers are given away in blocks, you have a lot of=20 > unused numbers. > > Eg in Austria the geo numbers are using up a great=20 > chunk of the > > numbers: > > we have 1100 4-digit area codes used be appox 4 Mio=20 > subscribers, > > on the other hand, we have 5 (five) 3-digit mobile=20 > number ranges > > used by 4,5 Mio subscribers (80% of them are behind 2=20 > mobile > > "area" codes). > > > > The reason is simple: the mobile number ranges are=20 > flat. So if we > > give eg > > one 3-digit number range to ENUM, we can instantly use= =20 > them with > > additional 7-digits for 9.999.999 subscribers. > > > > regards > > > > Richard > > > >z{x%^zm?0'~ffX)=C3=9F=C2=A3 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sat Apr 3 05:05: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 FAA14587 for ; Sat, 3 Apr 2004 05:05: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 1B9i1W-0000fh-VH for enum-archive@odin.ietf.org; Sat, 03 Apr 2004 05:05:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i33A5A41002531 for enum-archive@odin.ietf.org; Sat, 3 Apr 2004 05:05:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9i1O-0000eP-23; Sat, 03 Apr 2004 05:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9i12-0000Oq-MC for enum@optimus.ietf.org; Sat, 03 Apr 2004 05:04: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 FAA14570 for ; Sat, 3 Apr 2004 05:04:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9i0z-0003tn-00 for enum@ietf.org; Sat, 03 Apr 2004 05:04:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9i04-0003nV-00 for enum@ietf.org; Sat, 03 Apr 2004 05:03:40 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1B9hzi-0003gf-00 for enum@ietf.org; Sat, 03 Apr 2004 05:03:18 -0500 Content-Class: urn:content-classes:message Subject: AW: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sat, 3 Apr 2004 12:02:45 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F162233CA3@oefeg-s02.oefeg.loc> Thread-Topic: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQY5Chibds0P4ttS8uxeMJ53fGqmQAfiBVu From: "Stastny Richard" To: "James McEachern" , "Michael Hammer" Cc: "Pfautz, Penn L, ALABS" , 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 IA0KDQoJSWYgeW91IGhhdmUgYW4gRU5VTS1vbmx5IG51bWJlciwgdGhlbiB0aGUgR1cgbmVlZHMg dG8ga25vdyB3aGljaCBHVyB0aGF0IA0KCW51bWJlciBpcyBob21lZCB0bywgYW5kIHByZWZlcmFi bHkgcm91dGUgd2l0aGluIHRoZSBJUCBkb21haW4gdG8gdGhhdCANCglHVy4gIA0KCVtKaW0gTWNF XSBJZiB5b3UgaGF2ZSBhbiBFTlVNLW9ubHkgbnVtYmVyLCB3b3VsZG4ndCB0aGUgUFNUTiBqdXN0 IHJvdXRlIHRvIHRoZSBuZWFyZXN0IEVOVU0gZW5hYmxlZCBHVyB3aGVyZSBhbiBFTlVNIGRpcCB3 b3VsZCBiZSBkb25lIHNvIHRoZSBjYWxsIGNvdWxkIGJlIHJvdXRlZCB0byB0aGUgZW5kIGRldmlj ZSBpbiB0aGUgSVAgZG9tYWluPyANCg0KCVtSaWNoYXJkXSBZZXMsIHRoZXJlIGlzIG5vIHN1Y2gg dGhpbmcgYXMgYSBob25lIEdXLg0KDQoJVGhpcyBpcyB3aGVyZSB0aGUgY2FycmllciBFTlVNIGVu dHJ5IHdvdWxkIGhlbHAuIA0KDQoJSWYgdGhpcyBFTlVNLW9ubHkgYmVsb25ncyB0byBhIHVzZXIg KGFuZCBub3QgYXNzb2NpYXRlZCB3aXRoIGEgY2Fycmllcj8pLCBJIA0KCWhvcGUgdGhleSBoYXZl IGFuIGVudHJ5IGluIEVOVU0uICBXaGF0IGRvZXMgaXQgbWVhbiB0byBoYXZlIGFuIEVOVU0tb25s eSANCgludW1iZXIgYW5kIHRvIG5vdCBvcHQtaW4/ICANCglbSmltIE1jRV0gSSd2ZSB3b25kZXJl ZCBhYm91dCB0aGlzIG9uZSBteXNlbGYuIElzIGl0IGEgdmFsaWQgc2NlbmFyaW8/IFNob3VsZCB3 ZSB3b3JyeSBhYm91dCBpdD8gDQoNCglbUmljaGFyZF0gVGhzaSBpcyBkZXBlbmRpbmcgb24gbmF0 aW9uYWwgcmVndWxhdGlvbnMuIEkgcHJpbmNpcGxlIHlvdSBkbyBub3QgbmVlZCBhDQoJQ2Fycmll ciwganVzdCBhIFRpZXIgMiBuYW1lcyBzZXJ2ZXIgYW5kIGEgcmVnaXN0cmFyLg0KDQoJUmljaGFy ZA0KCQ0KDQo= _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sun Apr 4 06:20:20 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 GAA24588 for ; Sun, 4 Apr 2004 06:20:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA4ip-0001zH-9W for enum-archive@odin.ietf.org; Sun, 04 Apr 2004 06:19:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i34AJDM7007504 for enum-archive@odin.ietf.org; Sun, 4 Apr 2004 06:19:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA4b3-0000mh-U6; Sun, 04 Apr 2004 06:11:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA4aU-0000gL-MX for enum@optimus.ietf.org; Sun, 04 Apr 2004 06:10:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24346 for ; Sun, 4 Apr 2004 06:10:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BA4aH-00032X-00 for enum@ietf.org; Sun, 04 Apr 2004 06:10:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BA4ZF-0002vv-00 for enum@ietf.org; Sun, 04 Apr 2004 06:09:29 -0400 Received: from web60607.mail.yahoo.com ([216.109.118.245]) by ietf-mx with smtp (Exim 4.12) id 1BA4YI-0002ku-00 for enum@ietf.org; Sun, 04 Apr 2004 06:08:30 -0400 Message-ID: <20040404100801.11568.qmail@web60607.mail.yahoo.com> Received: from [212.152.27.248] by web60607.mail.yahoo.com via HTTP; Sun, 04 Apr 2004 03:08:01 PDT Date: Sun, 4 Apr 2004 03:08:01 -0700 (PDT) From: Mike Smith To: enum@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1342376846-1081073281=:9805" 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,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [Enum] Public Comments for Proposed Sponsored Top-Level Domains @ ICANN's web site 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: , --0-1342376846-1081073281=:9805 Content-Type: text/plain; charset=us-ascii Behind the link below you will find the public comment forum for the various sTLD applications including the one from Jeff Pulver / NetNumber: http://www.icann.org/tlds/stld-apps-19mar04/stld-public-comments.htm Mike --------------------------------- Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today --0-1342376846-1081073281=:9805 Content-Type: text/html; charset=us-ascii
Behind the link below you will find the public comment forum for the various sTLD applications including the one from Jeff Pulver / NetNumber:
 
 
Mike

Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today --0-1342376846-1081073281=:9805-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Apr 5 12:36: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 MAA13876 for ; Mon, 5 Apr 2004 12:36:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAX3j-00072N-9C for enum-archive@odin.ietf.org; Mon, 05 Apr 2004 12:35:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35GYdDP026949 for enum-archive@odin.ietf.org; Mon, 5 Apr 2004 12:34:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWxD-0006Di-Cy; Mon, 05 Apr 2004 12:28:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWow-0004tA-MB for enum@optimus.ietf.org; Mon, 05 Apr 2004 12:19:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11904 for ; Mon, 5 Apr 2004 12:19:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWou-0006G7-00 for enum@ietf.org; Mon, 05 Apr 2004 12:19:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAWgw-00059p-00 for enum@ietf.org; Mon, 05 Apr 2004 12:11:19 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1BAWba-0003wr-00 for enum@ietf.org; Mon, 05 Apr 2004 12:05:46 -0400 Content-Class: urn:content-classes:message Subject: Re: [Iptel] FW: [Enum] Summary on NoPSTN dicussion MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 5 Apr 2004 18:05:00 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F162233CA5@oefeg-s02.oefeg.loc> Thread-Topic: AW: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQbJWC8u6BmJTNKR+mOGcH1GVEQ+gAAagzM From: "Stastny Richard" To: "Michael Hammer" Cc: "James McEachern" , "Pfautz, Penn L, ALABS" , 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 TWlrZSB3cm90ZQ0KDQo+VGhlIGVmZmVjdCBvZiB5b3VyIHN0YXRlbWVudCBiZWxvdyAobm8gaG9t ZSBHVykgaXMgdGhhdCBhbiBFTlVNLW9ubHkgbnVtYmVyDQo+TVVTVCBiZSByZWdpc3RlcmVkLiAg VGhlcmUgaXMgbm8gb3B0LWluLg0KDQpbUmljaGFyZF0gQ29ycmVjdCwgaWYgdGhlIG51bWJlciBp cyBub3QgcmVnaXN0ZXJlZCBpbiBFTlVNLCBpdCBpcyBub3QgYXNzaWdlbmQuIA0KT3IgdG8gc2F5 IGl0IGluIGFub3RoZXIgd2F5OiB0aGUgcmVnaXN0cmF0aW9uIGluIEVOVU0gSVMgdGhlIGFzc2ln bmVtZW50LA0KKHdoaWNoIG1ha2VzIHZhbGlkYXRpb24gTi9BIDstKQ0KDQpSaWNoYXJkDQoNCg0K DQpBdCAxMjowMiBQTSA0LzMvMjAwNCArMDIwMCwgU3Rhc3RueSBSaWNoYXJkIHdyb3RlOg0KPg0K Pg0KPiAgICAgICAgIElmIHlvdSBoYXZlIGFuIEVOVU0tb25seSBudW1iZXIsIHRoZW4gdGhlIEdX IG5lZWRzIHRvIGtub3cgd2hpY2gNCj4gR1cgdGhhdA0KPiAgICAgICAgIG51bWJlciBpcyBob21l ZCB0bywgYW5kIHByZWZlcmFibHkgcm91dGUgd2l0aGluIHRoZSBJUCBkb21haW4gdG8NCj4gdGhh dA0KPiAgICAgICAgIEdXLg0KPiAgICAgICAgIFtKaW0gTWNFXSBJZiB5b3UgaGF2ZSBhbiBFTlVN LW9ubHkgbnVtYmVyLCB3b3VsZG4ndCB0aGUgUFNUTiBqdXN0DQo+IHJvdXRlIHRvIHRoZSBuZWFy ZXN0IEVOVU0gZW5hYmxlZCBHVyB3aGVyZSBhbiBFTlVNIGRpcCB3b3VsZCBiZSBkb25lIHNvDQo+ IHRoZSBjYWxsIGNvdWxkIGJlIHJvdXRlZCB0byB0aGUgZW5kIGRldmljZSBpbiB0aGUgSVAgZG9t YWluPw0KPg0KPiAgICAgICAgIFtSaWNoYXJkXSBZZXMsIHRoZXJlIGlzIG5vIHN1Y2ggdGhpbmcg YXMgYSBob25lIEdXLg0KPg0KPiAgICAgICAgIFRoaXMgaXMgd2hlcmUgdGhlIGNhcnJpZXIgRU5V TSBlbnRyeSB3b3VsZCBoZWxwLg0KPg0KPiAgICAgICAgIElmIHRoaXMgRU5VTS1vbmx5IGJlbG9u Z3MgdG8gYSB1c2VyIChhbmQgbm90IGFzc29jaWF0ZWQgd2l0aCBhDQo+IGNhcnJpZXI/KSwgSQ0K PiAgICAgICAgIGhvcGUgdGhleSBoYXZlIGFuIGVudHJ5IGluIEVOVU0uICBXaGF0IGRvZXMgaXQg bWVhbiB0byBoYXZlIGFuDQo+IEVOVU0tb25seQ0KPiAgICAgICAgIG51bWJlciBhbmQgdG8gbm90 IG9wdC1pbj8NCj4gICAgICAgICBbSmltIE1jRV0gSSd2ZSB3b25kZXJlZCBhYm91dCB0aGlzIG9u ZSBteXNlbGYuIElzIGl0IGEgdmFsaWQNCj4gc2NlbmFyaW8/IFNob3VsZCB3ZSB3b3JyeSBhYm91 dCBpdD8NCj4NCj4gICAgICAgICBbUmljaGFyZF0gVGhzaSBpcyBkZXBlbmRpbmcgb24gbmF0aW9u YWwgcmVndWxhdGlvbnMuIEkgcHJpbmNpcGxlDQo+IHlvdSBkbyBub3QgbmVlZCBhDQo+ICAgICAg ICAgQ2FycmllciwganVzdCBhIFRpZXIgMiBuYW1lcyBzZXJ2ZXIgYW5kIGEgcmVnaXN0cmFyLg0K Pg0KPiAgICAgICAgIFJpY2hhcmQNCj4NCg0KDQo= _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Apr 5 12:46:24 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 MAA14420 for ; Mon, 5 Apr 2004 12:46:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAXEO-0003XQ-79 for enum-archive@odin.ietf.org; Mon, 05 Apr 2004 12:45:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35Gjqbp013597 for enum-archive@odin.ietf.org; Mon, 5 Apr 2004 12:45:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAXE5-00038r-ER; Mon, 05 Apr 2004 12:45:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWek-0003du-KT for enum@optimus.ietf.org; Mon, 05 Apr 2004 12:09:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10993 for ; Mon, 5 Apr 2004 12:08:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWej-0004iz-00 for enum@ietf.org; Mon, 05 Apr 2004 12:09:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAWVv-0003IA-00 for enum@ietf.org; Mon, 05 Apr 2004 11:59:55 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BAWKo-0001FD-00 for enum@ietf.org; Mon, 05 Apr 2004 11:48:26 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2004 08:57:41 -0700 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 i35Flscp019864; Mon, 5 Apr 2004 11:47:54 -0400 (EDT) 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 AYF39493; Mon, 5 Apr 2004 08:47:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20040405114609.00b3e8e0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Apr 2004 11:47:49 -0400 To: "Stastny Richard" From: Michael Hammer Subject: Re: AW: AW: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Cc: "James McEachern" , "Pfautz, Penn L, ALABS" , In-Reply-To: <06CF906FE3998C4E944213062009F162233CA3@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.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, The effect of your statement below (no home GW) is that an ENUM-only number MUST be registered. There is no opt-in. Mike At 12:02 PM 4/3/2004 +0200, Stastny Richard wrote: > > > If you have an ENUM-only number, then the GW needs to know which > GW that > number is homed to, and preferably route within the IP domain to > that > GW. > [Jim McE] If you have an ENUM-only number, wouldn't the PSTN just > route to the nearest ENUM enabled GW where an ENUM dip would be done so > the call could be routed to the end device in the IP domain? > > [Richard] Yes, there is no such thing as a hone GW. > > This is where the carrier ENUM entry would help. > > If this ENUM-only belongs to a user (and not associated with a > carrier?), I > hope they have an entry in ENUM. What does it mean to have an > ENUM-only > number and to not opt-in? > [Jim McE] I've wondered about this one myself. Is it a valid > scenario? Should we worry about it? > > [Richard] Thsi is depending on national regulations. I principle > you do not need a > Carrier, just a Tier 2 names server and a registrar. > > Richard > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Apr 5 14:47: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 OAA23589 for ; Mon, 5 Apr 2004 14:47:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAZ7o-00024R-SV for enum-archive@odin.ietf.org; Mon, 05 Apr 2004 14:47:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35IlCRa007960 for enum-archive@odin.ietf.org; Mon, 5 Apr 2004 14:47:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAZ7d-00023y-CK; Mon, 05 Apr 2004 14:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAZ6e-0001ud-2Y for enum@optimus.ietf.org; Mon, 05 Apr 2004 14:46:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23574 for ; Mon, 5 Apr 2004 14:45:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAZ6b-0002Mv-00 for enum@ietf.org; Mon, 05 Apr 2004 14:45:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAYjU-0007kB-00 for enum@ietf.org; Mon, 05 Apr 2004 14:22:05 -0400 Received: from barry.mail.mindspring.net ([207.69.200.25]) by ietf-mx with esmtp (Exim 4.12) id 1BAYV7-0005HO-00 for enum@ietf.org; Mon, 05 Apr 2004 14:07:13 -0400 Received: from 1cust67.tnt36.dfw9.da.uu.net ([67.234.81.67] helo=ix.netcom.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BAYUr-0001Fs-00; Mon, 05 Apr 2004 14:06:58 -0400 Message-ID: <4071BA7A.C6F80CF3@ix.netcom.com> Date: Mon, 05 Apr 2004 12:58:51 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Stastny Richard CC: Michael Hammer , James McEachern , "Pfautz, Penn L, ALABS" , enum@ietf.org Subject: Re: [Iptel] FW: [Enum] Summary on NoPSTN dicussion References: <06CF906FE3998C4E944213062009F162233CA5@oefeg-s02.oefeg.loc> 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.7 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA23575 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 Stastny and all Stastny Richard wrote: > Mike wrote > > >The effect of your statement below (no home GW) is that an ENUM-only n= umber > >MUST be registered. There is no opt-in. > > [Richard] Correct, if the number is not registered in ENUM, it is not a= ssigend. > Or to say it in another way: the registration in ENUM IS the assignemen= t, > (which makes validation N/A ;-) This is not a good thing. It is not because the security and privacy issues with "Registered Only" ENUM numbers is significant. > > > Richard > > At 12:02 PM 4/3/2004 +0200, Stastny Richard wrote: > > > > > > If you have an ENUM-only number, then the GW needs to know wh= ich > > GW that > > number is homed to, and preferably route within the IP domain= to > > that > > GW. > > [Jim McE] If you have an ENUM-only number, wouldn't the PSTN = just > > route to the nearest ENUM enabled GW where an ENUM dip would be done = so > > the call could be routed to the end device in the IP domain? > > > > [Richard] Yes, there is no such thing as a hone GW. > > > > This is where the carrier ENUM entry would help. > > > > If this ENUM-only belongs to a user (and not associated with = a > > carrier?), I > > hope they have an entry in ENUM. What does it mean to have a= n > > ENUM-only > > number and to not opt-in? > > [Jim McE] I've wondered about this one myself. Is it a valid > > scenario? Should we worry about it? > > > > [Richard] Thsi is depending on national regulations. I princi= ple > > you do not need a > > Carrier, just a Tier 2 names server and a registrar. > > > > Richard > > > > z{=A6=99=A8=A5=8Ax%=8A=CB^=9E=E9=A2z=D7=E8=AE=08m=B6=9B?=FF0=D6'=AD~=8A= =E0=FEf=A2=96f=A7=FEX=AC=B6)=DF=A3=F7=A7um=3D=3D 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] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 Apr 6 13:39: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 NAA09942 for ; Tue, 6 Apr 2004 13:39:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuXG-0003JC-C2 for enum-archive@odin.ietf.org; Tue, 06 Apr 2004 13:39:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36HciNR012372 for enum-archive@odin.ietf.org; Tue, 6 Apr 2004 13:38:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuRL-0001Gn-PM; Tue, 06 Apr 2004 13:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuB3-0006DD-Ky for enum@optimus.ietf.org; Tue, 06 Apr 2004 13:15:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07758; Tue, 6 Apr 2004 13:15:54 -0400 (EDT) Message-Id: <200404061715.NAA07758@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: enum@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 06 Apr 2004 13:15:54 -0400 Subject: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.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 : E.164 Number Mapping for the Extensible Provisioning Protocol Author(s) : S. Hollenbeck Filename : draft-ietf-enum-epp-e164-03.txt Pages : 17 Date : 2004-4-5 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-epp-e164-03.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-epp-e164-03.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: <2004-4-6105448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-epp-e164-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-epp-e164-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-6105448.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Apr 7 05:14:37 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 FAA00459 for ; Wed, 7 Apr 2004 05:14:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB98L-0000GJ-Ta for enum-archive@odin.ietf.org; Wed, 07 Apr 2004 05:14:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i379E9uS000936 for enum-archive@odin.ietf.org; Wed, 7 Apr 2004 05:14:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB98C-0008Vl-4O; Wed, 07 Apr 2004 05:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB97F-0008Gt-9t for enum@optimus.ietf.org; Wed, 07 Apr 2004 05:13:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00291 for ; Wed, 7 Apr 2004 05:12:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB97C-0007W1-00 for enum@ietf.org; Wed, 07 Apr 2004 05:12:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAueK-00074j-00 for enum@ietf.org; Tue, 06 Apr 2004 13:46:13 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1BAuW3-0005mW-00 for enum@ietf.org; Tue, 06 Apr 2004 13:37:39 -0400 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 i36Hb8d00868 for ; Tue, 6 Apr 2004 10:37:08 -0700 Message-Id: <6.0.3.0.2.20040406133607.03b3aec0@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 06 Apr 2004 13:36:59 -0400 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: Request for Publication - draft-ietf-enum-pres-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: , Apologies this should have gone to the list as well. >Date: Tue, 06 Apr 2004 10:33:40 -0400 >To: iesg-secretary@ietf.org >From: Richard Shockey >Subject: Request for Publication - draft-ietf-enum-pres-00.txt >Cc: jon.peterson@neustar.biz, mankin@psg.com,paf@cisco.com > > > > >This is a request for publication for one IETF ENUM WG working group document. > >WG last call on this document concluded on March 22 ,2004. > >The document listed below is being proposed for Standards Track RFC. > >Status- Proposed Standard > >This document is a ENUM Working Group product, which has been extensively >discussed during 2003 and 2004. Discussions on the list indicated minor >editorial changes which the author has agreed to make. > > > >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 Apr 7 05:14: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 FAA00477 for ; Wed, 7 Apr 2004 05:14:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB98L-0000GH-Te for enum-archive@odin.ietf.org; Wed, 07 Apr 2004 05:14:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i379E97I000937 for enum-archive@odin.ietf.org; Wed, 7 Apr 2004 05:14:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB98C-0008Vt-Gp; Wed, 07 Apr 2004 05:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB97W-0008Ux-TW for enum@optimus.ietf.org; Wed, 07 Apr 2004 05:13:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00297 for ; Wed, 7 Apr 2004 05:13:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB97T-0007Z6-00 for enum@ietf.org; Wed, 07 Apr 2004 05:13:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAwuQ-0003YX-00 for enum@ietf.org; Tue, 06 Apr 2004 16:10:58 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1BAwJ5-00054M-00 for enum@ietf.org; Tue, 06 Apr 2004 15:32:23 -0400 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: Tue, 6 Apr 2004 21:31:51 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F162233CA6@oefeg-s02.oefeg.loc> Thread-Topic: [Iptel] FW: [Enum] Summary on NoPSTN dicussion Thread-Index: AcQbOM/DPI7rHzC+R4O18SevnLcOngA1Fj0V From: "Stastny Richard" To: "Jeff Williams" Cc: "Michael Hammer" , "James McEachern" , "Pfautz, Penn L, ALABS" , 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 SmVmZiB3cm90ZQ0KPlRoaXMgaXMgbm90IGEgZ29vZCB0aGluZy4gIEl0IGlzIG5vdCBiZWNhdXNl IHRoZSBzZWN1cml0eSBhbmQgcHJpdmFjeQ0KPmlzc3VlcyB3aXRoICJSZWdpc3RlcmVkIE9ubHki IEVOVU0gbnVtYmVycyBpcyBzaWduaWZpY2FudC4NCg0KUGxlYXNlIGRvIG5vdCBtYWtlIHN1Y2gg Y3J5cHRpYyBzdGF0ZW1lbnRzLg0KQ291bGQgeW91IHBsZWFzZSBlbGFib3JhdGUgbW9yZSBpbiBk ZXRhaWwgd2hhdCB0aGUgc2lnbmlmaWNhbnQgc2VjdXJpdHkvcHJpdmFjeQ0KaXNzdWUocykgaXMg L2FyZSB3aXRoIEVOVU0tb25seSBudW1iZXJzIGluIHlvdXIgb3Bpbmlvbj8NCg0KUmljaGFyZA0K DQoNCg== _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 9 10:45: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 KAA01158 for ; Fri, 9 Apr 2004 10:45:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxFv-0000Wq-Fw for enum-archive@odin.ietf.org; Fri, 09 Apr 2004 10:45:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39EjJDo002032 for enum-archive@odin.ietf.org; Fri, 9 Apr 2004 10:45:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxFd-0000RF-Jl; Fri, 09 Apr 2004 10:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxEc-0000Pz-CD for enum@optimus.ietf.org; Fri, 09 Apr 2004 10:44:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01102 for ; Fri, 9 Apr 2004 10:43:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBxEY-0003pv-00 for enum@ietf.org; Fri, 09 Apr 2004 10:43:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBxDB-0003kv-00 for enum@ietf.org; Fri, 09 Apr 2004 10:42:30 -0400 Received: from [81.223.16.194] (helo=www.mah.priv.at) by ietf-mx with esmtp (Exim 4.12) id 1BBxCl-0003eb-00 for enum@ietf.org; Fri, 09 Apr 2004 10:42:03 -0400 Received: from localhost ([127.0.0.1] helo=mah9.eunet.at) by www.mah.priv.at with esmtp (Exim 3.36 #1 (Debian)) id 1BBxC1-0002oS-00; Fri, 09 Apr 2004 16:41:17 +0200 Message-Id: <6.0.1.1.0.20040409163423.05dc31d0@localhost> X-Sender: mah#inode.at@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Apr 2004 16:41:15 +0200 To: "Hollenbeck, Scott" From: Michael Haberler Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt Cc: enum@ietf.org, axelm@nic.at, lendl@nic.at, schisch@nic.at In-Reply-To: <200404061715.NAA07758@ietf.org> References: <200404061715.NAA07758@ietf.org> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-778F55C0; boundary="=======204E7E72=======" 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: , --=======204E7E72======= Content-Type: text/plain; x-avg-checked=avg-ok-778F55C0; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit Hi Scott, thanks for tackling the ENUM provisioning problem. A question on your updated draft: in 3.2.1 on the command, you're saying that besides the Tier1 delegation stuff in (nameservers etc) the mandatory block MUST contain the NAPTR records for that domain, which is a Tier2 business. Do I understand this correctly that you assume a combined tier1/tier2 operation including both delegation and NAPTR hosting in this draft? I doubt wether you can assume both operations will go through the same registry? So far I've been assuming this will be split in most jurisdictions, which would limit applicability of your draft. -Michael At 19:15 06.04.2004, Internet-Drafts@ietf.org wrote: >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 : E.164 Number Mapping for the Extensible > Provisioning Protocol > Author(s) : S. Hollenbeck > Filename : draft-ietf-enum-epp-e164-03.txt > Pages : 17 > Date : 2004-4-5 > >This document describes an Extensible Provisioning Protocol (EPP) > extension mapping for the provisioning and management of E.164 > numbers representing domain names stored in a shared central > repository. Specified in XML, this mapping extends the EPP domain > name mapping to provide additional features required for the > provisioning of E.164 numbers. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-03.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the >message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >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-epp-e164-03.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-epp-e164-03.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-4-6105448.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-enum-epp-e164-03.txt > > > --=======204E7E72=======-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 9 10:53: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 KAA01465 for ; Fri, 9 Apr 2004 10:53:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxNO-00012g-Nv for enum-archive@odin.ietf.org; Fri, 09 Apr 2004 10:53:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39Er2Y8004001 for enum-archive@odin.ietf.org; Fri, 9 Apr 2004 10:53:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxNN-00012C-Ij; Fri, 09 Apr 2004 10:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBxMv-0000zG-LB for enum@optimus.ietf.org; Fri, 09 Apr 2004 10:52:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01457 for ; Fri, 9 Apr 2004 10:52:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBxMs-0004bk-00 for enum@ietf.org; Fri, 09 Apr 2004 10:52:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBxMH-0004XL-00 for enum@ietf.org; Fri, 09 Apr 2004 10:51:53 -0400 Received: from falcon.verisign.com ([216.168.239.71]) by ietf-mx with esmtp (Exim 4.12) id 1BBxLG-0004OI-00 for enum@ietf.org; Fri, 09 Apr 2004 10:50:50 -0400 Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id i39EoWop021993; Fri, 9 Apr 2004 10:50:33 -0400 (EDT) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <2LM2GDX5>; Fri, 9 Apr 2004 10:49:55 -0400 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF030DFC84@vsvapostal8.vcorp.ad.vrsn.com> From: "Hollenbeck, Scott" To: "'Michael Haberler'" Cc: "'enum@ietf.org'" , "'axelm@nic.at'" , "'lendl@nic.at'" , "'schisch@nic.at'" Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt Date: Fri, 9 Apr 2004 10:50:48 -0400 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.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: , Michael, Note that there is no mention of tiers in my document. Back when I first wrote the document the tiered functional/business model didn't really exist, so I made a conscious decision to not make any assumptions about which role a registry was fulfilling. Now, though, if you're saying that the situation has evolved in such a way that some registries will be receiving and publishing different bits of the data needed to make enum work, thanks -- that's good info. I can deal with that by making the data blocks distinct, referencing the other if needed. So what should go where, and how do the two tie together? -Scott- > -----Original Message----- > From: Michael Haberler [mailto:mah@eunet.at] > Sent: Friday, April 09, 2004 10:41 AM > To: Hollenbeck, Scott > Cc: enum@ietf.org; axelm@nic.at; lendl@nic.at; schisch@nic.at > Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt > > > Hi Scott, > thanks for tackling the ENUM provisioning problem. > A question on your updated draft: > in 3.2.1 on the command, you're saying that besides > the Tier1 > delegation stuff in (nameservers etc) the mandatory > > block MUST contain the NAPTR records for that domain, which > is a Tier2 > business. > Do I understand this correctly that you assume a combined tier1/tier2 > operation including both delegation and NAPTR hosting in this draft? > I doubt wether you can assume both operations will go through > the same > registry? So far I've been assuming this will be split in most > jurisdictions, which would limit applicability of your draft. > -Michael > At 19:15 06.04.2004, Internet-Drafts@ietf.org wrote: > >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 : E.164 Number Mapping for the Extensible > > Provisioning Protocol > > Author(s) : S. Hollenbeck > > Filename : draft-ietf-enum-epp-e164-03.txt > > Pages : 17 > > Date : 2004-4-5 > > > >This document describes an Extensible Provisioning Protocol (EPP) > > extension mapping for the provisioning and management of E.164 > > numbers representing domain names stored in a shared central > > repository. Specified in XML, this mapping extends the EPP domain > > name mapping to provide additional features required for the > > provisioning of E.164 numbers. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-03.txt > > > >To remove yourself from the I-D Announcement list, send a message to > >i-d-announce-request@ietf.org with the word unsubscribe in > the body of the > >message. > >You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > >to change your subscription settings. > > > > > >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-epp-e164-03.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-epp-e164-03.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-4-6105448.I-D@ietf.org> > > > >ENCODING mime > >FILE /internet-drafts/draft-ietf-enum-epp-e164-03.txt > > > > > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 9 12:04: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 MAA04119 for ; Fri, 9 Apr 2004 12:04:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByUI-0000yt-CL for enum-archive@odin.ietf.org; Fri, 09 Apr 2004 12:04:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39G4EUC003727 for enum-archive@odin.ietf.org; Fri, 9 Apr 2004 12:04:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByU5-0000hT-LT; Fri, 09 Apr 2004 12:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByTf-0000ZU-PM for enum@optimus.ietf.org; Fri, 09 Apr 2004 12:03:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04019 for ; Fri, 9 Apr 2004 12:03:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BByTd-0002wX-00 for enum@ietf.org; Fri, 09 Apr 2004 12:03:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BByRF-0002jC-00 for enum@ietf.org; Fri, 09 Apr 2004 12:01:06 -0400 Received: from [81.223.16.194] (helo=www.mah.priv.at) by ietf-mx with esmtp (Exim 4.12) id 1BByPw-0002Vl-00 for enum@ietf.org; Fri, 09 Apr 2004 11:59:44 -0400 Received: from localhost ([127.0.0.1] helo=mah9.eunet.at) by www.mah.priv.at with esmtp (Exim 3.36 #1 (Debian)) id 1BByPI-0004Hk-00; Fri, 09 Apr 2004 17:59:04 +0200 Message-Id: <6.0.1.1.0.20040409171950.05de9690@localhost> X-Sender: mah#inode.at@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Apr 2004 17:59:02 +0200 To: "Hollenbeck, Scott" From: Michael Haberler Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt Cc: "'enum@ietf.org'" , "'axelm@nic.at'" , "'lendl@nic.at'" , "'schisch@nic.at'" In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF030DFC84@vsvapostal8.vcorp .ad.vrsn.com> References: <5BEA6CDB196A4241B8BE129D309AA4AF030DFC84@vsvapostal8.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-778F55C0; boundary="=======13187FAA=======" 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: , --=======13187FAA======= Content-Type: text/plain; x-avg-checked=avg-ok-778F55C0; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Scott, my conjecture how the industry will evolve: - Tier1 registries will just do delegations. - Tier2 registries (competitive service providers) will host the zone for a= =20 customer's number and provide secondary NS. - Tier2 will either 1. populate the NAPTR records for their customers automatically according=20 to some service bundle (and a contract where the user 'opted in' to ENUM) -= =20 for users who dont care what ENUM =EDs about but like the effect 2. or they will give the user a, say, web portal, where they can manage=20 their own NAPTR records - for those PhD's inclined to do so 3. or the tier2 will redelegate to a customer tier3 name server (if DNAME=20 works, or directly request tier1 delegation to a tier3 name server) 4. or they will give the enduser a protocol interface to manage their NAPTR= =20 records which are hosted at Tier2 1) that's what we're doing with www.at43.at service; the users dont even=20 get a chance to break their naptr records 2) many ENUM trials have done that, and some tier2 SP's might go that route 3) that would be typically the case for a large corporate customer with=20 clue, or an IP PBX which includes a Tier3 server. 4) I could imagine this could evolve as well, for many customers its less=20 painful to use a hosted service which could be driven by an automatic=20 protocol - from a sip server, or an IP PBX for instance. (btw there is a converged IP PBX out which has a Tier3 name server -=20 www.innovaphone.de - you configure an extension on the PBX, and the naptr=20 gets automatically added to the zone - all one needs to do is point Tier1=20 delegation at this NS). I'm unsure wether we'll actually see combined tier1/tier2 service at all. So this points to actually two protocols, first the tier1 delegation used=20 by the tier2 service provider, and potentially a second one where *the=20 customer* or his management system accesses hosted records in standardized= way. Now the first one could be achieved by pretty much using standard "domain"= =20 EPP. On the second protocol, modifying hosted napt'rs, that would be a=20 different entity, with authentication at the domain level, but likely no=20 contact handles as we use them in TLD land - it's not a delegation, it's=20 remote data management. There is an experimental first cut of such a remote naptr management=20 protocol, done by T-Systems in Germany. It currently only supports only a=20 single tier2 operation ("setEntries"), and that is: set the list of NAPTR=20 records according to a parameter array for a single Domain. It is SOAP over TLS, userid/password authentication to access a given=20 domain, pus a client transaction reference field (see=20 http://www.enum-trial.de/docs/ENUM-Trial_Projekt-SOAP_ENUM-SSt_v1_0.pdf;=20 unfortunately teutsch only). My suggestion would be to take the tier1/tier2 combined operation=20 assumption out of the protocol, and make the naptr-relevant data elements=20 optional. On the second protocol, I'm unsure wether EPP is a potentially=20 popular choice of protocol - many IP PBX's, SIP servers etc have stack=20 support for Web services, but implanting EPP might be a lot of effort for a= =20 non-delegation problem to solve. How do other folks see this evolve? -Michael >Michael, > >Note that there is no mention of tiers in my document. Back when I first >wrote the document the tiered functional/business model didn't really= exist, >so I made a conscious decision to not make any assumptions about which role >a registry was fulfilling. > >Now, though, if you're saying that the situation has evolved in such a way >that some registries will be receiving and publishing different bits of the >data needed to make enum work, thanks -- that's good info. I can deal with >that by making the data blocks distinct, referencing the other if needed. >So what should go where, and how do the two tie together? > >-Scott- > > > -----Original Message----- > > From: Michael Haberler [mailto:mah@eunet.at] > > Sent: Friday, April 09, 2004 10:41 AM > > To: Hollenbeck, Scott > > Cc: enum@ietf.org; axelm@nic.at; lendl@nic.at; schisch@nic.at > > Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt > > > > > > Hi Scott, > > thanks for tackling the ENUM provisioning problem. > > A question on your updated draft: > > in 3.2.1 on the command, you're saying that besides > > the Tier1 > > delegation stuff in (nameservers etc) the mandatory > > > > block MUST contain the NAPTR records for that domain, which > > is a Tier2 > > business. > > Do I understand this correctly that you assume a combined tier1/tier2 > > operation including both delegation and NAPTR hosting in this draft? > > I doubt wether you can assume both operations will go through > > the same > > registry? So far I've been assuming this will be split in most > > jurisdictions, which would limit applicability of your draft. > > -Michael --=======13187FAA=======-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 9 13:09: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 NAA08652 for ; Fri, 9 Apr 2004 13:09:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBzV8-0002kE-Hq for enum-archive@odin.ietf.org; Fri, 09 Apr 2004 13:09:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39H9AZp010546 for enum-archive@odin.ietf.org; Fri, 9 Apr 2004 13:09:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBzUz-0002ii-4M; Fri, 09 Apr 2004 13:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBzTy-0002Uv-W4 for enum@optimus.ietf.org; Fri, 09 Apr 2004 13:08:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08477 for ; Fri, 9 Apr 2004 13:07:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBzTw-0002TT-00 for enum@ietf.org; Fri, 09 Apr 2004 13:07:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBzSE-0002GD-00 for enum@ietf.org; Fri, 09 Apr 2004 13:06:12 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1BBzR8-00025H-00 for enum@ietf.org; Fri, 09 Apr 2004 13:05:02 -0400 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 i39H3dd27026; Fri, 9 Apr 2004 10:03:39 -0700 Message-Id: <6.0.3.0.2.20040409121015.03839828@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Fri, 09 Apr 2004 13:03:28 -0400 To: Michael Haberler , "Hollenbeck, Scott" From: Richard Shockey Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt Cc: "'enum@ietf.org'" , "'axelm@nic.at'" , "'lendl@nic.at'" , "'schisch@nic.at'" In-Reply-To: <6.0.1.1.0.20040409171950.05de9690@localhost> References: <5BEA6CDB196A4241B8BE129D309AA4AF030DFC84@vsvapostal8.vcorp.ad.vrsn.com> <6.0.1.1.0.20040409171950.05de9690@localhost> 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.8 required=5.0 tests=AWL,BIZ_TLD 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 11:59 AM 4/9/2004, Michael Haberler wrote: >Scott, Well Michael this is exactly the kind of discussion I was hoping to see=20 evolve here. >my conjecture how the industry will evolve: > >- Tier1 registries will just do delegations. Which means the registration object for the Tier 1 needs the social and=20 technical contact data ( name address etc) as well as the NS data for the=20 delegation. Whether or not the T1 actually uses this data in a thick registry model or= =20 recompiles it into some form of WHOIS or preferably IRIS infrastructure is= =20 a national specific issue as we all know. As a reminder the US ENUM forum produced a document generally outlining the= =20 Implementation issues and the proposed structure of the tiers. http://www.enum-forum.org If folks have other documents from national forums that might impact=20 requirements here ..please post them. many of the national trials have similar documents outling the proposed=20 structure. >- Tier2 registries (competitive service providers) will host the zone for= =20 >a customer's number and provide secondary NS. >- Tier2 will either >1. populate the NAPTR records for their customers automatically according= =20 >to some service bundle (and a contract where the user 'opted in' to ENUM)= =20 >- for users who dont care what ENUM =EDs about but like the effect >2. or they will give the user a, say, web portal, where they can manage=20 >their own NAPTR records - for those PhD's inclined to do so >3. or the tier2 will redelegate to a customer tier3 name server (if DNAME= =20 >works, or directly request tier1 delegation to a tier3 name server) do we have to bring up the DNAME issue again :-) >4. or they will give the enduser a protocol interface to manage their=20 >NAPTR records which are hosted at Tier2 > >1) that's what we're doing with www.at43.at service; the users dont even=20 >get a chance to break their naptr records >2) many ENUM trials have done that, and some tier2 SP's might go that route >3) that would be typically the case for a large corporate customer with=20 >clue, or an IP PBX which includes a Tier3 server. exactly .. >4) I could imagine this could evolve as well, for many customers its less= =20 >painful to use a hosted service which could be driven by an automatic=20 >protocol - from a sip server, or an IP PBX for instance. > >(btw there is a converged IP PBX out which has a Tier3 name server -=20 >www.innovaphone.de - you configure an extension on the PBX, and the naptr= =20 >gets automatically added to the zone - all one needs to do is point Tier1= =20 >delegation at this NS). > >I'm unsure wether we'll actually see combined tier1/tier2 service at all. Well maybe in Liechtenstein. >So this points to actually two protocols, first the tier1 delegation used= =20 >by the tier2 service provider, and potentially a second one where *the=20 >customer* or his management system accesses hosted records in standardized= way. > >Now the first one could be achieved by pretty much using standard "domain"= =20 >EPP. On the second protocol, modifying hosted napt'rs, that would be a=20 >different entity, with authentication at the domain level, but likely no=20 >contact handles as we use them in TLD land - it's not a delegation, it's=20 >remote data management. Not unlike the domain name industry itself where most of the core=20 principals here were developed. For the benefit of the list BTW these are= =20 the PROVREG Extensiable Provisioning Protocol documents and Scott is the=20 principal author of that suite. The PROVREG WG BTW is now concluded. >There is an experimental first cut of such a remote naptr management=20 >protocol, done by T-Systems in Germany. It currently only supports only a= =20 >single tier2 operation ("setEntries"), and that is: set the list of NAPTR= =20 >records according to a parameter array for a single Domain. >It is SOAP over TLS, userid/password authentication to access a given=20 >domain, pus a client transaction reference field (see=20 >http://www.enum-trial.de/docs/ENUM-Trial_Projekt-SOAP_ENUM-SSt_v1_0.pdf;=20 >unfortunately teutsch only). Whatever protocol element we develop here will need to support multiple=20 transport layers and clearly SOAP strikes me as an eventual necessity. The= =20 reason I say this is that the requirements of the domain name industry=20 (.COM, .US , .AT ) are not necessarily the same as what some of us see as=20 the requirements for the ENUM registration industry. In the first case the number of potential players Registries - Registrars=20 not to mention Registrants are exponential orders of magnitude greater we=20 should not expect that the tools appropriate for one industry are=20 appropriate for another. >My suggestion would be to take the tier1/tier2 combined operation=20 >assumption out of the protocol, and make the naptr-relevant data elements= =20 >optional. On the second protocol, I'm unsure wether EPP is a potentially=20 >popular choice of protocol - many IP PBX's, SIP servers etc have stack=20 >support for Web services, but implanting EPP might be a lot of effort for= =20 >a non-delegation problem to solve. again lets not get bogged down in potential transport issues. Michael I=20 totally agree with you that some of the EPP defined transports will be=20 completely inappropriate for many of the possible transaction scenarios=20 that will surely evolve here. I know I'm committing IETF heresy here but we cannot exclude SOAP based=20 transport for the simple reason it is a well defined corporate standard for= =20 query response and data transfer applications. >How do other folks see this evolve? This is certainly the right track .. Well one other way to look at it is to evolve some potential use cases=20 which might be helpful in defining what the protocol data elements need to= do. For instance. A. I call up a ITSP and want to buy a SIP based VoIP service. The service= =20 provider in this case fulfills the function of registrar who then provides= =20 the T1 registry with the social- technical contact data and appropriate NS= =20 record for the ENUM FQDN. The ITSP then maintains the T2 on behalf of the=20 customer or the customer may contract with an independent hosted DNS=20 provider for T2 management. The ITSP acting as registrar would then pass on= =20 the T2 data to what ever entity the consumer required. B. Company A may wish to peer its dial plan with Business Partner B it is=20 not interested in public enum at all. It needs to exchange only the TN and= =20 T2 records to be mapped into internal tables. C. For competitive reasons Company A sells a service to the consumer but=20 needs to populate the Tier 2 held by another company or entity. D. Company A's PBX adds modifies or deletes a user. The PBX directly sends= =20 the new T1 T2 data to the registrar for provisioning. We're skipping a lot of authentication issues here but I think you=20 understand the direction I'm thinking. >-Michael > > >>Michael, >> >>Note that there is no mention of tiers in my document. Back when I first >>wrote the document the tiered functional/business model didn't really= exist, >>so I made a conscious decision to not make any assumptions about which= role >>a registry was fulfilling. >> >>Now, though, if you're saying that the situation has evolved in such a way >>that some registries will be receiving and publishing different bits of= the >>data needed to make enum work, thanks -- that's good info. I can deal= with >>that by making the data blocks distinct, referencing the other if needed. >>So what should go where, and how do the two tie together? >> >>-Scott- >> >> > -----Original Message----- >> > From: Michael Haberler [mailto:mah@eunet.at] >> > Sent: Friday, April 09, 2004 10:41 AM >> > To: Hollenbeck, Scott >> > Cc: enum@ietf.org; axelm@nic.at; lendl@nic.at; schisch@nic.at >> > Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt >> > >> > >> > Hi Scott, >> > thanks for tackling the ENUM provisioning problem. >> > A question on your updated draft: >> > in 3.2.1 on the command, you're saying that besides >> > the Tier1 >> > delegation stuff in (nameservers etc) the mandatory >> > >> > block MUST contain the NAPTR records for that domain, which >> > is a Tier2 >> > business. >> > Do I understand this correctly that you assume a combined tier1/tier2 >> > operation including both delegation and NAPTR hosting in this draft? >> > I doubt wether you can assume both operations will go through >> > the same >> > registry? So far I've been assuming this will be split in most >> > jurisdictions, which would limit applicability of your draft. >> > -Michael >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Apr 9 13:49: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 NAA09664 for ; Fri, 9 Apr 2004 13:49:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC07k-0007mR-G6 for enum-archive@odin.ietf.org; Fri, 09 Apr 2004 13:49:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39Hn4SI029879 for enum-archive@odin.ietf.org; Fri, 9 Apr 2004 13:49:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC07h-0007l2-2V; Fri, 09 Apr 2004 13:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC06c-0007jH-Ie for enum@optimus.ietf.org; Fri, 09 Apr 2004 13:48:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09601 for ; Fri, 9 Apr 2004 13:47:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC06Y-0006JA-00 for enum@ietf.org; Fri, 09 Apr 2004 13:47:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC04t-000671-00 for enum@ietf.org; Fri, 09 Apr 2004 13:46:08 -0400 Received: from gromit.rfc1035.com ([195.54.233.67]) by ietf-mx with esmtp (Exim 4.12) id 1BC034-0005tr-00 for enum@ietf.org; Fri, 09 Apr 2004 13:44:15 -0400 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 i39Hh5rd029001; Fri, 9 Apr 2004 18:43:05 +0100 (BST) To: Richard Shockey cc: Michael Haberler , Scott Hollenbeck , enum@ietf.org, axelm@nic.at, lendl@nic.at, schisch@nic.at Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt In-Reply-To: Message from Richard Shockey of "Fri, 09 Apr 2004 13:03:28 EDT." <6.0.3.0.2.20040409121015.03839828@joy.songbird.com> Date: Fri, 09 Apr 2004 18:43:05 +0100 Message-ID: <29000.1081532585@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" == Richard Shockey writes: >> - Tier1 registries will just do delegations. Richard> Which means the registration object for the Tier 1 needs Richard> the social and technical contact data ( name address etc) Richard> as well as the NS data for the delegation. Not necessarily. They could have a tag for the contact data: for instance an authentication token validating that the number "belongs" to the entity that registered it. The actual contact data could stay with the registrar/ASP. Richard> Whether or not the T1 actually uses this data in a thick Richard> registry model or recompiles it into some form of WHOIS Richard> or preferably IRIS infrastructure is a national specific Richard> issue as we all know. Yup. In the UK we've not bothered with whois in our trial and see no reason to introduce a whois-like service in a commercial phase. After all, the name that's being registered already contains contact data: the registrant's phone number! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 9 13:57: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 NAA09957 for ; Fri, 9 Apr 2004 13:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0FU-00006M-PR for enum-archive@odin.ietf.org; Fri, 09 Apr 2004 13:57:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39Hv4UY000386 for enum-archive@odin.ietf.org; Fri, 9 Apr 2004 13:57:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0FR-0008VA-Ve; Fri, 09 Apr 2004 13:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0F4-0008Se-Uv for enum@optimus.ietf.org; Fri, 09 Apr 2004 13:56:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09925 for ; Fri, 9 Apr 2004 13:56:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC0F2-0007EU-00 for enum@ietf.org; Fri, 09 Apr 2004 13:56:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC0Dw-00078O-00 for enum@ietf.org; Fri, 09 Apr 2004 13:55:28 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1BC0Ch-0006x4-00 for enum@ietf.org; Fri, 09 Apr 2004 13:54:11 -0400 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 i39HrOd31052; Fri, 9 Apr 2004 10:53:24 -0700 Message-Id: <6.0.3.0.2.20040409134758.039d9eb0@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Fri, 09 Apr 2004 13:53:20 -0400 To: Jim Reid From: Richard Shockey Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt Cc: Michael Haberler , Scott Hollenbeck , enum@ietf.org, axelm@nic.at, lendl@nic.at, schisch@nic.at In-Reply-To: <29000.1081532585@gromit.rfc1035.com> References: <29000.1081532585@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.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 01:43 PM 4/9/2004, Jim Reid wrote: > >>>>> "Richard" == Richard Shockey writes: > > >> - Tier1 registries will just do delegations. > > Richard> Which means the registration object for the Tier 1 needs > Richard> the social and technical contact data ( name address etc) > Richard> as well as the NS data for the delegation. > >Not necessarily. They could have a tag for the contact data: for >instance an authentication token validating that the number "belongs" >to the entity that registered it. The actual contact data could stay >with the registrar/ASP. OK the thin registry model the one that everyone has been trying to move away from. .. as I said before this is a national specific issue but the data object MUST be able to carry social data if necessary. > Richard> Whether or not the T1 actually uses this data in a thick > Richard> registry model or recompiles it into some form of WHOIS > Richard> or preferably IRIS infrastructure is a national specific > Richard> issue as we all know. > >Yup. In the UK we've not bothered with whois in our trial and see no >reason to introduce a whois-like service in a commercial phase. After >all, the name that's being registered already contains contact data: >the registrant's phone number! But what about the technical contact data. Who is the DNS manager for the T2 records? I cant believe the UK is not considering a registry centric repository for technical contact data..this goes to issues of security and stability of DNS. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Apr 9 14:08: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 OAA10553 for ; Fri, 9 Apr 2004 14:08:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0Q8-0001Hq-UY for enum-archive@odin.ietf.org; Fri, 09 Apr 2004 14:08:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39I84UX004941 for enum-archive@odin.ietf.org; Fri, 9 Apr 2004 14:08:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0Q6-0001HA-1Q; Fri, 09 Apr 2004 14:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0Pl-00018S-R5 for enum@optimus.ietf.org; Fri, 09 Apr 2004 14:07:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10531 for ; Fri, 9 Apr 2004 14:07:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC0Pi-0000a1-00 for enum@ietf.org; Fri, 09 Apr 2004 14:07:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC0Oe-0000Te-00 for enum@ietf.org; Fri, 09 Apr 2004 14:06:32 -0400 Received: from [81.223.16.194] (helo=www.mah.priv.at) by ietf-mx with esmtp (Exim 4.12) id 1BC0NK-0000Gv-00 for enum@ietf.org; Fri, 09 Apr 2004 14:05:10 -0400 Received: from localhost ([127.0.0.1] helo=mah9.eunet.at) by www.mah.priv.at with esmtp (Exim 3.36 #1 (Debian)) id 1BC0MP-0007Zi-00; Fri, 09 Apr 2004 20:04:13 +0200 Message-Id: <6.0.1.1.0.20040409195352.02bc4068@localhost> X-Sender: mah#inode.at@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Apr 2004 20:03:55 +0200 To: Jim Reid , Richard Shockey From: Michael Haberler Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt Cc: Scott Hollenbeck , enum@ietf.org, axelm@nic.at, lendl@nic.at, schisch@nic.at In-Reply-To: <29000.1081532585@gromit.rfc1035.com> References: <29000.1081532585@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-778F55C0; boundary="=======388F50DB=======" 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: , --=======388F50DB======= Content-Type: text/plain; x-avg-checked=avg-ok-778F55C0; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit That brings us to another interesting issue: the public phone directory and its relation to 'ENUM whois'. is there any? if there's directory information and ENUM whois, what gives? re: tag - I thought the consensus is on a thick registry (not Nominet-style?) as ENUM-driven number ranges become more prevalent, the location of the authoritative social data might move to the ENUM registry. In fact we're looking into supplying directory records to the local directory publisher. A thin registry will make it hard to do that. -Michael ps: I disagree on the search strategy - directory lookup by phone number aint it; lookup by 'whois in ENUM' is valuable At 19:43 09.04.2004, Jim Reid wrote: > >>>>> "Richard" == Richard Shockey writes: > > >> - Tier1 registries will just do delegations. > > Richard> Which means the registration object for the Tier 1 needs > Richard> the social and technical contact data ( name address etc) > Richard> as well as the NS data for the delegation. > >Not necessarily. They could have a tag for the contact data: for >instance an authentication token validating that the number "belongs" >to the entity that registered it. The actual contact data could stay >with the registrar/ASP. > > Richard> Whether or not the T1 actually uses this data in a thick > Richard> registry model or recompiles it into some form of WHOIS > Richard> or preferably IRIS infrastructure is a national specific > Richard> issue as we all know. > >Yup. In the UK we've not bothered with whois in our trial and see no >reason to introduce a whois-like service in a commercial phase. After >all, the name that's being registered already contains contact data: >the registrant's phone number! --=======388F50DB=======-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 9 14:33: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 OAA11365 for ; Fri, 9 Apr 2004 14:33:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0oL-0003Db-2U for enum-archive@odin.ietf.org; Fri, 09 Apr 2004 14:33:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39IX5mR012366 for enum-archive@odin.ietf.org; Fri, 9 Apr 2004 14:33:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0oH-0003D3-2m; Fri, 09 Apr 2004 14:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0nr-0003CI-5n for enum@optimus.ietf.org; Fri, 09 Apr 2004 14:32:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11301 for ; Fri, 9 Apr 2004 14:32:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC0no-000341-00 for enum@ietf.org; Fri, 09 Apr 2004 14:32:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC0mq-0002wd-00 for enum@ietf.org; Fri, 09 Apr 2004 14:31:33 -0400 Received: from [81.223.16.194] (helo=www.mah.priv.at) by ietf-mx with esmtp (Exim 4.12) id 1BC0kz-0002cf-00 for enum@ietf.org; Fri, 09 Apr 2004 14:29:37 -0400 Received: from localhost ([127.0.0.1] helo=mah9.eunet.at) by www.mah.priv.at with esmtp (Exim 3.36 #1 (Debian)) id 1BC0k6-0004Q6-00; Fri, 09 Apr 2004 20:28:42 +0200 Message-Id: <6.0.1.1.0.20040409200714.02bc8240@localhost> X-Sender: mah#inode.at@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 09 Apr 2004 20:28:40 +0200 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Michael Haberler Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt Cc: "'enum@ietf.org'" , "'schisch@nic.at'" , "Hollenbeck, Scott" , "'axelm@nic.at'" , "'lendl@nic.at'" In-Reply-To: <4B110E3C-8A47-11D8-9286-000A95B2B926@cisco.com> References: <5BEA6CDB196A4241B8BE129D309AA4AF030DFC84@vsvapostal8.vcorp.ad.vrsn.com> <6.0.1.1.0.20040409171950.05de9690@localhost> <4B110E3C-8A47-11D8-9286-000A95B2B926@cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-778F55C0; boundary="=======D677A06=======" 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: , --=======D677A06======= Content-Type: text/plain; x-avg-checked=avg-ok-778F55C0; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable At 18:59 09.04.2004, Patrik F=E4ltstr=F6m wrote: >On Apr 9, 2004, at 17:59, Michael Haberler wrote: > >>my conjecture how the industry will evolve: > >Personally, I have never understood (=3D=3D seen a good definition) of the= =20 >various tiers, and what for example "Tier 1" should do and not. The word=20 >"tier" to me means a relationship between parties more than what they do. Tier1 is a natural monopoly. Tier2 isnt. That's why I assume there will be= =20 competitive interest to keep Tier1 as slim as possible. I mean I could live= =20 with a fat Tier1... but others might not. The separation is done for the=20 same reason like we did in TLD land - scaling and competition at the=20 service level (this separation might include naptr management and name=20 service). >>- Tier1 registries will just do delegations. > >Ok. > >>- Tier2 registries (competitive service providers) will host the zone for= =20 >>a customer's number and provide secondary NS. > >Why should the Tier2 provider provider secondary NS? If they host the=20 >zone, they are the ones running the primary NS which holds the SOA for the= =20 >zone where NAPTR for the E.164 is stored. I don't see why they should also= =20 >run secondary NS. Some other organisation might do that. I agree with your diagram of relations and it maps closely to the model=20 used by our regulator; I left out the NS provider as from the interface=20 perspective regarding Scott's proposal I didnt deem it essential. Also,=20 it's more of a business decision as to whom to contract what, being it user= =20 or Tier2. In the Austrian trial the separate NS provider sort of dropped from the=20 scene; I guess nobody considered starting a service just for that. >>- Tier2 will either >>1. populate the NAPTR records for their customers automatically according= =20 >>to some service bundle (and a contract where the user 'opted in' to ENUM)= =20 >>- for users who dont care what ENUM =EDs about but like the effect > >Ok. > >>2. or they will give the user a, say, web portal, where they can manage=20 >>their own NAPTR records - for those PhD's inclined to do so > >Ok > >>3. or the tier2 will redelegate to a customer tier3 name server (if DNAME= =20 >>works, or directly request tier1 delegation to a tier3 name server) > >But, above you said Tier 2 should be the one which run the DNS for the=20 >NAPTR. Here it seems the Tier2 is the one approving the delegation and the= =20 >"registrar" which can request the delegation at the Tier1. > >You can not have both. Only one definition of the tiers. "redelegate" clearly was the wrong term.. Tier2 might be hosting DNS, it=20 might also just effect the delegation for the user directly. my understanding is a Tier2 SP provides a service to the end user, and to=20 do so signs a contract with the Tier1. That includes interaction with Tier1= =20 (like registrars do for TLD's); it might in many cases involve NAPTR=20 hosting, which implies some nameservice - with our without secondary; it=20 might also mean just 'passing through' the delegation without actually=20 being in the DNS resolution chain. In the Austrian Trial we explicitely permitted direct delegations to a=20 Tier3 (customer) nameserver from Tier1 by means of a Tier2-handled=20 registration (for PBXes; not for service provider number blocks). -Michael >>4. or they will give the enduser a protocol interface to manage their=20 >>NAPTR records which are hosted at Tier2 >> >>1) that's what we're doing with www.at43.at service; the users dont even= =20 >>get a chance to break their naptr records >>2) many ENUM trials have done that, and some tier2 SP's might go that= route > >See attached picture. This is what I have seen at trials I have followed.= =20 >In some cases the different roles are run by the same organisation, and in= =20 >some (other) cases one have more than one DNS operator between the two you= =20 >see on the picture. In any case, people mean different >things when they use the "Tier" terminology, so I would recommend either=20 >defining it in _great_ detail, or try to not use it. > >BTW, if you have comments on the picture, please let me know. > > paf > > > > > --=======D677A06=======-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 9 15:10: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 PAA13465 for ; Fri, 9 Apr 2004 15:10:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1OA-0007Sh-EG for enum-archive@odin.ietf.org; Fri, 09 Apr 2004 15:10:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39JA6V8028680 for enum-archive@odin.ietf.org; Fri, 9 Apr 2004 15:10:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1O6-0007Q2-OR; Fri, 09 Apr 2004 15:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1NZ-00073F-Ra for enum@optimus.ietf.org; Fri, 09 Apr 2004 15:09:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13314 for ; Fri, 9 Apr 2004 15:09:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC1NW-0006gp-00 for enum@ietf.org; Fri, 09 Apr 2004 15:09:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC1JE-0006JX-00 for enum@ietf.org; Fri, 09 Apr 2004 15:05:01 -0400 Received: from gromit.rfc1035.com ([195.54.233.67]) by ietf-mx with esmtp (Exim 4.12) id 1BC1FQ-0005rS-00 for enum@ietf.org; Fri, 09 Apr 2004 15:01:05 -0400 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 i39J0Krd029174; Fri, 9 Apr 2004 20:00:21 +0100 (BST) To: Richard Shockey cc: Michael Haberler , Scott Hollenbeck , enum@ietf.org, axelm@nic.at, lendl@nic.at, schisch@nic.at Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt In-Reply-To: Message from Richard Shockey of "Fri, 09 Apr 2004 13:53:20 EDT." <6.0.3.0.2.20040409134758.039d9eb0@joy.songbird.com> Date: Fri, 09 Apr 2004 20:00:20 +0100 Message-ID: <29173.1081537220@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" == Richard Shockey writes: Richard> Which means the registration object for the Tier 1 needs Richard> the social and technical contact data ( name address etc) Richard> as well as the NS data for the delegation. >> Not necessarily. They could have a tag for the contact data: >> for instance an authentication token validating that the number >> "belongs" to the entity that registered it. The actual contact >> data could stay with the registrar/ASP. Richard> OK the thin registry model the one that everyone has been Richard> trying to move away from. .. as I said before this is a Richard> national specific issue but the data object MUST be able Richard> to carry social data if necessary. We are in violent agreement here. All I was saying was that the registry isn't necessarily bound by legal or purely technical constraints into holding that data. The Tier-1 doesn't *have* to hold that data, though it probably should. It doesn't need that data to maintain or provide DNS service for the Tier-1 zone. >> Yup. In the UK we've not bothered with whois in our trial and >> see no reason to introduce a whois-like service in a commercial >> phase. After all, the name that's being registered already >> contains contact data: the registrant's phone number! Richard> But what about the technical contact data. Who is the DNS Richard> manager for the T2 records? I cant believe the UK is not Richard> considering a registry centric repository for technical Richard> contact data..this goes to issues of security and Richard> stability of DNS. I'm not sure that it does. Although registries maintain this contact data, its value in stabilising the DNS is debatable. Firstly, the contact data is often out of date or inaccurate, as a quick peek at some random whois server will show. Even if it's correct, how often is it actually used (and acted on) when somebody's servers go lame? Sure, people can and do use it for that purpose, myself included. But I'm not convinced the benefits outweigh the costs. As for the UK Tier-1, the registry may or may not hold this data. It depends on the registration. We have logically separated the role of DNS provider from the T2 registrar, though in practice these may well be combined. So if some other DNS provider is used, the registry might only be able to give a referral to the registrar who can provide the contact info for the DNS provider. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 9 15:16: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 PAA14109 for ; Fri, 9 Apr 2004 15:16:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1Tv-0001T6-OS for enum-archive@odin.ietf.org; Fri, 09 Apr 2004 15:16:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39JG3Ux005624 for enum-archive@odin.ietf.org; Fri, 9 Apr 2004 15:16:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1Tu-0001SM-Ov; Fri, 09 Apr 2004 15:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1Tn-0001Pw-TH for enum@optimus.ietf.org; Fri, 09 Apr 2004 15:15:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14027 for ; Fri, 9 Apr 2004 15:15:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC1Tm-0007L9-00 for enum@ietf.org; Fri, 09 Apr 2004 15:15:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC1Pu-000705-00 for enum@ietf.org; Fri, 09 Apr 2004 15:11:55 -0400 Received: from gromit.rfc1035.com ([195.54.233.67]) by ietf-mx with esmtp (Exim 4.12) id 1BC1NR-0006g2-00 for enum@ietf.org; Fri, 09 Apr 2004 15:09:21 -0400 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 i39J93rd029186; Fri, 9 Apr 2004 20:09:03 +0100 (BST) To: Michael Haberler cc: Richard Shockey , Scott Hollenbeck , enum@ietf.org, axelm@nic.at, lendl@nic.at, schisch@nic.at Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt In-Reply-To: Message from Michael Haberler of "Fri, 09 Apr 2004 20:03:55 +0200." <6.0.1.1.0.20040409195352.02bc4068@localhost> Date: Fri, 09 Apr 2004 20:09:03 +0100 Message-ID: <29185.1081537743@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: , >>>>> "Michael" == Michael Haberler writes: Michael> re: tag - I thought the consensus is on a thick registry Michael> (not Nominet-style?) Yes. All I was saying was this isn't necessarily the only game in town. Michael> ps: I disagree on the search strategy - directory lookup Michael> by phone number aint it; lookup by 'whois in ENUM' is Michael> valuable We can agree to differ on this Michael. We should be used to that by now. :-) _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 9 16:50:00 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 QAA20592 for ; Fri, 9 Apr 2004 16:49:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC2wL-0000D6-Cw for enum-archive@odin.ietf.org; Fri, 09 Apr 2004 16:49:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39KnTYa000776 for enum-archive@odin.ietf.org; Fri, 9 Apr 2004 16:49:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC2vx-00009s-R0; Fri, 09 Apr 2004 16:49:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC2vi-00007e-EX for enum@optimus.ietf.org; Fri, 09 Apr 2004 16:48:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20448 for ; Fri, 9 Apr 2004 16:48:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC2vd-0001T7-00 for enum@ietf.org; Fri, 09 Apr 2004 16:48:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC2j6-0007b9-00 for enum@ietf.org; Fri, 09 Apr 2004 16:35:49 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1BC2L4-0005jE-00 for enum@ietf.org; Fri, 09 Apr 2004 16:10:58 -0400 Content-Class: urn:content-classes:message Subject: AW: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 9 Apr 2004 22:10:19 +0200 Message-ID: <06CF906FE3998C4E944213062009F162233CAE@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt Thread-Index: AcQebDf1YOJMfJAPQqGPUU9z5qmqrAAAaEQs From: "Stastny Richard" To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , "Michael Haberler" Cc: , , "Hollenbeck, Scott" , , 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 UGF0cmlrIHdyb3RlOg0KIA0KPlNvLCBUaWVyLTIgaXMgZnJvbSB5b3VyIHBvaW50IG9mIHZpZXcg dGhlIG9yZ2FuaXNhdGlvbiB3aGljaCBjYW4gYXNrDQo+dGhlIHRpZXIgMSBmb3IgdGhlIGRlbGVn YXRpb24sIHJlZ2FyZGxlc3Mgb2YgZnJvbSB3aGVyZSBhbmQgdG8gd2hlcmUNCj50aGUgRE5TIGlz IGRlbGVnYXRlZD8NCg0KPlRoYXQgbWFrZXMgc2Vuc2UgdG8gbWUuDQoNClNvcnJ5IHRvIGludGVy cnVwdDogbm90IGV4YWN0bHkNCg0KaW4gdGhlIFRpZXIgZGVmaW5pdGlvbiBvZiBFVFNJIHRoZSBU aWVycw0KYmVsb25nIG1haW5seSB0byB0aGUgbmFtZXNlcnZlci4gUmVxdWVzdGluZyBkZWxlZ2F0 aW9ucyBhcmUgdGhlDQpSZWdpc3RyYXJzIGFuZCB0aGV5IGFyZSBvdXRzaWRlIG9mIHRoZSBUaWVy IGRlZmluaXRpb24sIGJ1dA0KYmVjYXVzZSBpbiBkcmF3aW5ncyB0aGV5IGFyZSBhbHdheXMgb24g dGhlIFRpZXIgMiBsYXllciwNCmV2ZXJib2R5IGFzc3VtZXMgKGFuZCByaGlzIGlzIG5vdCBmYXIg b2ZmIGFueXdheSkgdGhhdA0KdGhlIHJlZ2lzdHJhcnMgYXJlIG9uIHRpZXIgMi4gTWF5YmUgeW91 IGFzayBKb2FraW0sIGhlDQppcyBleHBlcnQgaW4gZXBsYWluaW5nIHN1Y2ggdGhpbmdzIDstKQ0K DQpSaWNoYXJkDQoNCg0KDQo= _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 9 17:45: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 RAA24819 for ; Fri, 9 Apr 2004 17:45:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC3oE-0008V5-9x for enum-archive@odin.ietf.org; Fri, 09 Apr 2004 17:45:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39LjAKL032639 for enum-archive@odin.ietf.org; Fri, 9 Apr 2004 17:45:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC3o5-0008TJ-5q; Fri, 09 Apr 2004 17:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC3nH-0008RA-Lw for enum@optimus.ietf.org; Fri, 09 Apr 2004 17:44:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24690 for ; Fri, 9 Apr 2004 17:44:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC3nD-0006Ap-00 for enum@ietf.org; Fri, 09 Apr 2004 17:44:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC3Xd-0004po-00 for enum@ietf.org; Fri, 09 Apr 2004 17:28:02 -0400 Received: from bartok.sidn.nl ([193.176.144.164]) by ietf-mx with esmtp (Exim 4.12) id 1BC3GE-0003ON-00 for enum@ietf.org; Fri, 09 Apr 2004 17:10:02 -0400 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 i39L9Kcc003267 for ; Fri, 9 Apr 2004 23:09:20 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200404092109.i39L9Kcc003267@bartok.sidn.nl> To: enum@ietf.org Subject: Re: AW: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt In-reply-to: Your message of Fri, 09 Apr 2004 22:10:19 +0200. <06CF906FE3998C4E944213062009F162233CAE@oefeg-s02.oefeg.loc> Date: Fri, 09 Apr 2004 23:09:20 +0200 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: , Sorry to interrupt: not exactly Sorry to interrupt as well but ... in the Tier definition of ETSI the Tiers belong mainly to the nameserver. Requesting delegations are the Registrars and they are outside of the Tier definition, but because in drawings they are always on the Tier 2 layer, everbody assumes (and rhis is not far off anyway) that the registrars are on tier 2. Maybe you ask Joakim, he is expert in eplaining such things ;-) ... maybe it is time to have a formal definition of the Tier # terminology. I have the faint feeling that there are quite different views on what is actually meant with the term. jaap _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 9 18:02: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 SAA25822 for ; Fri, 9 Apr 2004 18:02:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC44k-00032r-DT for enum-archive@odin.ietf.org; Fri, 09 Apr 2004 18:02:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39M2EDH011691 for enum-archive@odin.ietf.org; Fri, 9 Apr 2004 18:02:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC44W-0002n4-AX; Fri, 09 Apr 2004 18:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC43b-00024O-Ex for enum@optimus.ietf.org; Fri, 09 Apr 2004 18:01:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25726 for ; Fri, 9 Apr 2004 18:00:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC43V-0007GK-00 for enum@ietf.org; Fri, 09 Apr 2004 18:00:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC3n6-0006A0-00 for enum@ietf.org; Fri, 09 Apr 2004 17:44:02 -0400 Received: from mail.dns-hosting.info ([81.23.228.129] helo=mail1.dns-hosting.info) by ietf-mx with esmtp (Exim 4.12) id 1BC3Wi-0004mu-00 for enum@ietf.org; Fri, 09 Apr 2004 17:27:05 -0400 Received: from [193.230.215.25] (Async5-33k-25.tomrad.ro [193.230.215.25]) (authenticated bits=0) by mail1.dns-hosting.info (8.12.3/8.12.3/Debian-6.6) with ESMTP id i39LQVta031017; Fri, 9 Apr 2004 23:26:33 +0200 In-Reply-To: <29173.1081537220@gromit.rfc1035.com> References: <29173.1081537220@gromit.rfc1035.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6A1A9CB4-8A6C-11D8-8F94-000393C94104@ag-projects.com> Content-Transfer-Encoding: 7bit Cc: Richard Shockey , Michael Haberler , Scott Hollenbeck , enum@ietf.org, Alexander Mayrhofer , lendl@nic.at, Robert Schischka From: Adrian Georgescu Subject: Re: [Enum] social facet Date: Sat, 10 Apr 2004 00:25:24 +0300 To: Jim Reid 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=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 This a view from the field. Whois is useful to store information about zone delegation. Whois is not suitable to store information at subscriber level. If ENUM means power to the masses including self control over NAPTR records the same should apply for the "to be" ENUM phonebook. As mentioned, this social facet will shift radically with the evolution of ENUM so more control about address book has to move into the hands of the NAPTR owners. Whois allows no control from the end-user so one option could be to replace it with a cleverer system. On 9 Apr 2004, at 22:00, Jim Reid wrote: >>>>>> "Richard" == Richard Shockey writes: > > Richard> Which means the registration object for the Tier 1 needs > Richard> the social and technical contact data ( name address etc) > Richard> as well as the NS data for the delegation. >>> Not necessarily. They could have a tag for the contact data: >>> for instance an authentication token validating that the number >>> "belongs" to the entity that registered it. The actual contact >>> data could stay with the registrar/ASP. > > Richard> OK the thin registry model the one that everyone has been > Richard> trying to move away from. .. as I said before this is a > Richard> national specific issue but the data object MUST be able > Richard> to carry social data if necessary. > > We are in violent agreement here. All I was saying was that the > registry isn't necessarily bound by legal or purely technical > constraints into holding that data. The Tier-1 doesn't *have* to hold > that data, though it probably should. It doesn't need that data to > maintain or provide DNS service for the Tier-1 zone. > >>> Yup. In the UK we've not bothered with whois in our trial and >>> see no reason to introduce a whois-like service in a commercial >>> phase. After all, the name that's being registered already >>> contains contact data: the registrant's phone number! > > Richard> But what about the technical contact data. Who is the DNS > Richard> manager for the T2 records? I cant believe the UK is not > Richard> considering a registry centric repository for technical > Richard> contact data..this goes to issues of security and > Richard> stability of DNS. > > I'm not sure that it does. Although registries maintain this contact > data, its value in stabilising the DNS is debatable. Firstly, the > contact data is often out of date or inaccurate, as a quick peek at > some random whois server will show. Even if it's correct, how often is > it actually used (and acted on) when somebody's servers go lame? Sure, > people can and do use it for that purpose, myself included. But I'm not > convinced the benefits outweigh the costs. > > As for the UK Tier-1, the registry may or may not hold this data. It > depends on the registration. We have logically separated the role of > DNS provider from the T2 registrar, though in practice these may well > be combined. So if some other DNS provider is used, the registry might > only be able to give a referral to the registrar who can provide the > contact info for the DNS provider. > > _______________________________________________ > 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 Apr 9 21:24: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 VAA04132 for ; Fri, 9 Apr 2004 21:24:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC7E4-0001NB-6P for enum-archive@odin.ietf.org; Fri, 09 Apr 2004 21:24:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3A1O4eP005277 for enum-archive@odin.ietf.org; Fri, 9 Apr 2004 21:24:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC7E1-0001Mm-KI; Fri, 09 Apr 2004 21:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC7Dn-0001MB-NU for enum@optimus.ietf.org; Fri, 09 Apr 2004 21:23:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04115 for ; Fri, 9 Apr 2004 21:23:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC7Dj-0007Ec-00 for enum@ietf.org; Fri, 09 Apr 2004 21:23:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC7Cj-00077T-00 for enum@ietf.org; Fri, 09 Apr 2004 21:22:42 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1BC7C1-0006uH-00 for enum@ietf.org; Fri, 09 Apr 2004 21:21:57 -0400 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 i3A1Kud02855; Fri, 9 Apr 2004 18:20:56 -0700 Message-Id: <6.0.3.0.2.20040409205756.03e10ec0@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Fri, 09 Apr 2004 21:19:57 -0400 To: Adrian Georgescu , Jim Reid From: Richard Shockey Subject: Re: [Enum] social facet Cc: Michael Haberler , Scott Hollenbeck , enum@ietf.org, Alexander Mayrhofer , lendl@nic.at, Robert Schischka In-Reply-To: <6A1A9CB4-8A6C-11D8-8F94-000393C94104@ag-projects.com> References: <29173.1081537220@gromit.rfc1035.com> <6A1A9CB4-8A6C-11D8-8F94-000393C94104@ag-projects.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 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:25 PM 4/9/2004, Adrian Georgescu wrote: >This a view from the field. > >Whois is useful to store information about zone delegation. Whois is not >suitable to store information at subscriber level. If ENUM means power to >the masses including self control over NAPTR records the same should apply >for the "to be" ENUM phonebook. As mentioned, this social facet will shift >radically with the evolution of ENUM so more control about address book >has to move into the hands of the NAPTR owners. Whois allows no control >from the end-user so one option could be to replace it with a cleverer system. Thank you .. zone delegation issues are IMHO central to over all security and stability issues in the DNS. Social or subscriber issues are properly defined by each nation state implementation. I agree that ENUM is not the "phone book" or "white pages" to be mined by well known spam scum etc. Though Jim Reid does have a point on the value of such technical data being up to data I do suggest that if voice services are folded into the general class of IP applications the need to discover such data may increase. I would note that the IRIS work in the IETF looks at a more AA rich WHOIS structure that may be useful as commercial ENUM deployments as are about to occur in Austria. We have had several presentation on IRIS ( aka not classic whois) at various IETF meetings but I would suggest that WG members take a renewed look at that work as it might relate to national deployments. That said .. I hope the WG will start to focus some attention on these important issues since as commercial deployments are on the horizon ( GO AUSTRIA !!!) and we have unique opportunity to provide direction to implementors here. Our charter gives us wide latitude to take on these tasks and Scott's draft was already a WG item. Now that PROVREG is concluded and even though Scott has new constraints as APPS AD I think we give his work the proper attention it deserves. >On 9 Apr 2004, at 22:00, Jim Reid wrote: > >>>>>>>"Richard" == Richard Shockey writes: >> >> Richard> Which means the registration object for the Tier 1 needs >> Richard> the social and technical contact data ( name address etc) >> Richard> as well as the NS data for the delegation. >>>> Not necessarily. They could have a tag for the contact data: >>>>for instance an authentication token validating that the number >>>>"belongs" to the entity that registered it. The actual contact >>>>data could stay with the registrar/ASP. >> >> Richard> OK the thin registry model the one that everyone has been >> Richard> trying to move away from. .. as I said before this is a >> Richard> national specific issue but the data object MUST be able >> Richard> to carry social data if necessary. >> >>We are in violent agreement here. All I was saying was that the >>registry isn't necessarily bound by legal or purely technical >>constraints into holding that data. The Tier-1 doesn't *have* to hold >>that data, though it probably should. It doesn't need that data to >>maintain or provide DNS service for the Tier-1 zone. >> >>>> Yup. In the UK we've not bothered with whois in our trial and >>>>see no reason to introduce a whois-like service in a commercial >>>>phase. After all, the name that's being registered already >>>>contains contact data: the registrant's phone number! >> >> Richard> But what about the technical contact data. Who is the DNS >> Richard> manager for the T2 records? I cant believe the UK is not >> Richard> considering a registry centric repository for technical >> Richard> contact data..this goes to issues of security and >> Richard> stability of DNS. >> >>I'm not sure that it does. Although registries maintain this contact >>data, its value in stabilising the DNS is debatable. Firstly, the >>contact data is often out of date or inaccurate, as a quick peek at >>some random whois server will show. Even if it's correct, how often is >>it actually used (and acted on) when somebody's servers go lame? Sure, >>people can and do use it for that purpose, myself included. But I'm not >>convinced the benefits outweigh the costs. >> >>As for the UK Tier-1, the registry may or may not hold this data. It >>depends on the registration. We have logically separated the role of >>DNS provider from the T2 registrar, though in practice these may well >>be combined. So if some other DNS provider is used, the registry might >>only be able to give a referral to the registrar who can provide the >>contact info for the DNS provider. >> >>_______________________________________ > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >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 Sat Apr 10 01:48: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 BAA10522 for ; Sat, 10 Apr 2004 01:48:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBLa-0005u9-EY for enum-archive@odin.ietf.org; Sat, 10 Apr 2004 01:48:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3A5m65v022692 for enum-archive@odin.ietf.org; Sat, 10 Apr 2004 01:48:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBLU-0005te-Ro; Sat, 10 Apr 2004 01:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBKm-0005tP-V9 for enum@optimus.ietf.org; Sat, 10 Apr 2004 01:47:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10505 for ; Sat, 10 Apr 2004 01:47:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCBKj-0003Rc-00 for enum@ietf.org; Sat, 10 Apr 2004 01:47:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCBJZ-0003J6-00 for enum@ietf.org; Sat, 10 Apr 2004 01:46:02 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BCBIm-0002vS-00 for enum@ietf.org; Sat, 10 Apr 2004 01:45:12 -0400 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 10 Apr 2004 07:45:32 +0200 X-BrightmailFiltered: true 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 i3A5hv24001013; Sat, 10 Apr 2004 07:43:58 +0200 (MET DST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 10 Apr 2004 07:42:25 +0200 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 10 Apr 2004 07:44:32 +0200 In-Reply-To: <06CF906FE3998C4E944213062009F162233CAE@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F162233CAE@oefeg-s02.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <22DB850B-8AB2-11D8-9286-000A95B2B926@cisco.com> Content-Transfer-Encoding: 7bit Cc: , , "Hollenbeck, Scott" , , "Michael Haberler" , From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: AW: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt Date: Sat, 10 Apr 2004 07:44:30 +0200 To: "Stastny Richard" X-Mailer: Apple Mail (2.613) X-OriginalArrivalTime: 10 Apr 2004 05:44:32.0122 (UTC) FILETIME=[E5CC7DA0:01C41EBE] 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 Apr 9, 2004, at 22:10, Stastny Richard wrote: >> So, Tier-2 is from your point of view the organisation which can ask >> the tier 1 for the delegation, regardless of from where and to where >> the DNS is delegated? > >> That makes sense to me. > > Sorry to interrupt: not exactly > > in the Tier definition of ETSI the Tiers > belong mainly to the nameserver. Requesting delegations are the > Registrars and they are outside of the Tier definition, but > because in drawings they are always on the Tier 2 layer, > everbody assumes (and rhis is not far off anyway) that > the registrars are on tier 2. Maybe you ask Joakim, he > is expert in eplaining such things ;-) :-) I have talked with him (and many others) about this Tier thing, which I *never* have understood. :-) It seems to be it is unclear for more people than me... I.e. it is impossible to talk about organisations at layers if you don't have strict relationships between them, so it is possible to talk about the layers themselves. Take the situation where we have a registry/registrar model for the DNS management, a separate ENUM approval process, a registrant which want his E.164 number published... In Sweden and this model, you would have (1) the organisation running the DNS server(s) for the 6.4.e164.arpa. With this, I mean the DNS servers the queries go to. (2) the organisation creating the zone for 6.4.e164.arpa and making it available for the ones running the DNS servers. The zone in Sweden only include NS records for full E.164 numbers EXCEPT in the relatively rare cases enterprises have blocks of numbers and request a delegation for the whole block. (3) the organisations which approve the deleation in 6.4.e164.arpa. (4) the organisation/registrar which the end user go to when he want his number delegated. (5) the organisation the DNS is delegated to from DNS servers run by (1) (6) the organisation running the mail service one of the NAPTR point at (7) the organisation running the SIP service one of the NAPTR point at (8) the organisation running the gateway between PSTN and SIP which might be used by the end user etc etc People use the term "tier 2 provider" as if it is one of the above, and I have never understood what. Is what you are saying that some of the above is "on tier 1" and some other "on tier 2"? That "Tier 1" is an adjective? In that case, I can suggest 1-2 be tier 1, and 5-8 be tier 2. But, what about 3-4? My conclusion the last 3 years or so when talking with Joakim et.al. is that I don't see any need for Tier definitions as one have to define the explicit organisations (like above) anyway to get a working system. Using the term "Tier-1 provider" which I have heard many times seems to make take for granted for example 1 and 2 above is run by the same organisation. Same for 3 and 4 etc. That is a limiting factor in some cases. Question: Do we in the IETF need a definition of these terms as people use them all the time, or should we just ignore it and continue to have people like me which are confused? I propose the latter. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sat Apr 10 02:00: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 CAA11362 for ; Sat, 10 Apr 2004 02:00:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBX9-0007HT-Nh for enum-archive@odin.ietf.org; Sat, 10 Apr 2004 02:00:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3A603o2027960 for enum-archive@odin.ietf.org; Sat, 10 Apr 2004 02:00:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBX7-0007E1-SP; Sat, 10 Apr 2004 02:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBX4-0007D1-50 for enum@optimus.ietf.org; Sat, 10 Apr 2004 01:59:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10891 for ; Sat, 10 Apr 2004 01:59:55 -0400 (EDT) From: jon.peterson@neustar.biz Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCBWz-0005JZ-00 for enum@ietf.org; Sat, 10 Apr 2004 01:59:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCBVx-0005Am-00 for enum@ietf.org; Sat, 10 Apr 2004 01:58:49 -0400 Received: from dhcp-192-203-56.in2cable.com ([203.192.203.56] helo=pc2) by ietf-mx with smtp (Exim 4.12) id 1BCBUE-0004tF-00 for enum@ietf.org; Sat, 10 Apr 2004 01:57:04 -0400 Date: Fri, 09 Apr 2004 22:58:16 -0800 To: enum@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------mdgedpxufxploumvttyg" 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] :) 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: , ----------mdgedpxufxploumvttyg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_FUNBAG.GEN in file AttachedDocument.zip The file AttachedDocument.zip is moved to /etc/iscan/virus/virSSCuabqqW. --------------------------------------------------------- ----------mdgedpxufxploumvttyg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Argh, i don't like the plaintext :) 25183 -- archive password ----------mdgedpxufxploumvttyg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) AttachedDocument.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------mdgedpxufxploumvttyg-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sat Apr 10 02:11: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 CAA22545 for ; Sat, 10 Apr 2004 02:11:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBho-0004GY-Hd for enum-archive@odin.ietf.org; Sat, 10 Apr 2004 02:11:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3A6B4JQ016386 for enum-archive@odin.ietf.org; Sat, 10 Apr 2004 02:11:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBhm-0004Ew-9x; Sat, 10 Apr 2004 02:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCBhE-00041j-9Y for enum@optimus.ietf.org; Sat, 10 Apr 2004 02:10:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21412 for ; Sat, 10 Apr 2004 02:10:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCBh7-0006kb-00 for enum@ietf.org; Sat, 10 Apr 2004 02:10:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCBfu-0006cC-00 for enum@ietf.org; Sat, 10 Apr 2004 02:09:07 -0400 Received: from blount.mail.mindspring.net ([207.69.200.226]) by ietf-mx with esmtp (Exim 4.12) id 1BCBet-0006Lv-00 for enum@ietf.org; Sat, 10 Apr 2004 02:08:03 -0400 Received: from 1cust100.tnt36.dfw9.da.uu.net ([67.234.81.100] helo=ix.netcom.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BCBeO-0001F4-00; Sat, 10 Apr 2004 02:07:32 -0400 Message-ID: <4077A94E.63660F47@ix.netcom.com> Date: Sat, 10 Apr 2004 00:59:15 -0700 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 , Michael Haberler , Scott Hollenbeck , enum@ietf.org, axelm@nic.at, lendl@nic.at, schisch@nic.at Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt References: <29000.1081532585@gromit.rfc1035.com> <6.0.3.0.2.20040409134758.039d9eb0@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.1 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 Richard and all, Richard Shockey wrote: > At 01:43 PM 4/9/2004, Jim Reid wrote: > > > >>>>> "Richard" == Richard Shockey writes: > > > > >> - Tier1 registries will just do delegations. > > > > Richard> Which means the registration object for the Tier 1 needs > > Richard> the social and technical contact data ( name address etc) > > Richard> as well as the NS data for the delegation. > > > >Not necessarily. They could have a tag for the contact data: for > >instance an authentication token validating that the number "belongs" > >to the entity that registered it. The actual contact data could stay > >with the registrar/ASP. > > OK the thin registry model the one that everyone has been trying to move > away from. .. as I said before this is a national specific issue but the > data object MUST be able to carry social data if necessary. Why? > > > > Richard> Whether or not the T1 actually uses this data in a thick > > Richard> registry model or recompiles it into some form of WHOIS > > Richard> or preferably IRIS infrastructure is a national specific > > Richard> issue as we all know. > > > >Yup. In the UK we've not bothered with whois in our trial and see no > >reason to introduce a whois-like service in a commercial phase. After > >all, the name that's being registered already contains contact data: > >the registrant's phone number! > > But what about the technical contact data. Who is the DNS manager for the > T2 records? I cant believe the UK is not considering a registry centric > repository for technical contact data..this goes to issues of security and > stability of DNS. This is a politically motivated issue. ICANN has effectively "hossed-up" Whois data requirements and many countries in the EU are not going along for very good security AND privacy reasons. No ENUM user should be forced/required to expose themselves to have their ENUM number/name listed, just as most americans have the option of having their phone number as a unlisted number... Social engineering in software development of any kind is a very slippery slope... > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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 Sat Apr 10 06:43: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 GAA01375 for ; Sat, 10 Apr 2004 06:43:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCFx4-0005xa-QX for enum-archive@odin.ietf.org; Sat, 10 Apr 2004 06:43:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3AAh6QB022910 for enum-archive@odin.ietf.org; Sat, 10 Apr 2004 06:43:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCFwz-0005xB-MU; Sat, 10 Apr 2004 06:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCFwQ-0005wi-LD for enum@optimus.ietf.org; Sat, 10 Apr 2004 06:42:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01353 for ; Sat, 10 Apr 2004 06:42:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCFwM-0007F7-00 for enum@ietf.org; Sat, 10 Apr 2004 06:42:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCFvK-000762-00 for enum@ietf.org; Sat, 10 Apr 2004 06:41:19 -0400 Received: from [81.223.16.194] (helo=www.mah.priv.at) by ietf-mx with esmtp (Exim 4.12) id 1BCFuh-0006ve-00 for enum@ietf.org; Sat, 10 Apr 2004 06:40:39 -0400 Received: from localhost ([127.0.0.1] helo=mah9.eunet.at) by www.mah.priv.at with esmtp (Exim 3.36 #1 (Debian)) id 1BCFtx-0007pd-00; Sat, 10 Apr 2004 12:39:53 +0200 Message-Id: <6.0.1.1.0.20040410115118.060162d8@localhost> X-Sender: mah#inode.at@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 10 Apr 2004 12:39:50 +0200 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Stastny Richard" From: Michael Haberler Subject: Re: AW: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt Cc: , , "Hollenbeck, Scott" , , In-Reply-To: <22DB850B-8AB2-11D8-9286-000A95B2B926@cisco.com> References: <06CF906FE3998C4E944213062009F162233CAE@oefeg-s02.oefeg.loc> <22DB850B-8AB2-11D8-9286-000A95B2B926@cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-778F55C0; boundary="=======672444ED=======" 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: , --=======672444ED======= Content-Type: text/plain; x-avg-checked=avg-ok-778F55C0; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable At 07:44 10.04.2004, Patrik F=E4ltstr=F6m wrote: The discussion originated in protocol support for ENUM operations and=20 drifted into a discussion of layers or organisations involved. However, we= =20 can discuss things also in terms of your list of organisations (which I=20 would relabel as roles for generality, because roles might need to map to=20 organisations as needed; see an example below for (3), the "validation=20 agency"). >Take the situation where we have a registry/registrar model for the DNS=20 >management, a separate ENUM approval process, a registrant which want his= =20 >E.164 number published... > >In Sweden and this model, you would have > >(1) the organisation running the DNS server(s) for the 6.4.e164.arpa. With= =20 >this, I mean the DNS servers the queries go to. > >(2) the organisation creating the zone for 6.4.e164.arpa and making it=20 >available for the ones running the DNS servers. The zone in Sweden only=20 >include NS records for full E.164 numbers EXCEPT in the relatively rare=20 >cases enterprises have blocks of numbers and request a delegation for the= =20 >whole block. This function needs a protocol to interact with (4), and "domain" EPP=20 covers it mostly. It needs to furnish the zone to (1) - that's standard procedure. >(3) the organisations which approve the deleation in 6.4.e164.arpa. We found out that this role is needed, but it should be a competitive=20 function, not a single organisation, fulfilled by SP's as they see fit=20 within a framework of validation requirements. It can be different even on= =20 a number range basis. For instance we agreed in Austria that an SMS from a= =20 handset is good enough to validate number ownership. So in that case that=20 role can be subsumed by (4). In the case of ENUM-driven number ranges,=20 there is no tracking of ENUM domain to number ownership, so the validation= =20 is simple - (4) needs to collect social data, allocate the number and=20 assert that the data is valid. For existing fixed network numbers a more=20 cumbersome external validation might be required (e.g. prove by faxing a=20 phone bill); or in the case of an enlightened telco which is the number=20 range holder and provides ENUM role (4) functions they can validate by=20 looking at their existing subscriber data. Whatever the method, the fact of validation will be carried by a signed=20 token which is passed through the (4)/(2) interface along with the=20 delegation request, and stored in the database of (2). We might need to=20 extend (4)/(2) EPP to carry such tokens. Our model is that (4) "pushes" the= =20 validity assertion to (2) along with the delegation request, and might need= =20 to update it periodically before expiry. That introduces an additional function of (2), which is the validation of=20 tokens by cryptographic means. Only delegations with valid tokens will=20 cause a zone entry in *.e164.arpa. The authenticity of a validation entity= =20 is established by it subscribing to the validation framework principles=20 and assigning it a key to generate valid tokens. In terms of protocol support, fetching a validation token could be either a= =20 function internal to (4) or it might require an interaction between (3) and= =20 (4). We havent set a protocol for that yet but SOAP might suffice. Splitting up that organisation into roles of different players does not=20 exclude the single validation entity approach in some national=20 implementation - it's just a special case. >(4) the organisation/registrar which the end user go to when he want his=20 >number delegated. > >(5) the organisation the DNS is delegated to from DNS servers run by (1) that's where the "remote NAPTR management" protocol between user and (5)=20 comes in, along the lines of the T-Systems work. In Scott's proposal this=20 function is folded into the (4)/(2) interface which I think is the wrong=20 place except if (5) equals (2). It is completely unrelated to delegation=20 and validity issues. >(6) the organisation running the mail service one of the NAPTR point at > >(7) the organisation running the SIP service one of the NAPTR point at > >(8) the organisation running the gateway between PSTN and SIP which might= =20 >be used by the end user 6..7 are anonymous DNS users. For 6..8 I dont see the necessity for=20 protocol support between roles beyond DNS lookup. look, Paf - no tiers ;) -Michael --=======672444ED=======-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sat Apr 10 13:39: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 NAA12669 for ; Sat, 10 Apr 2004 13:39:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCMRi-0003i1-4a for enum-archive@odin.ietf.org; Sat, 10 Apr 2004 13:39:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3AHdAOY014231 for enum-archive@odin.ietf.org; Sat, 10 Apr 2004 13:39:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCMRZ-0003h8-3O; Sat, 10 Apr 2004 13:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCMQZ-0003gW-Sa for enum@optimus.ietf.org; Sat, 10 Apr 2004 13:38:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12637 for ; Sat, 10 Apr 2004 13:37:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCMQW-00032m-00 for enum@ietf.org; Sat, 10 Apr 2004 13:37:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCMPV-0002t5-00 for enum@ietf.org; Sat, 10 Apr 2004 13:36:53 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1BCMOE-0002Z0-00 for enum@ietf.org; Sat, 10 Apr 2004 13:35:34 -0400 Content-Class: urn:content-classes:message Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Sat, 10 Apr 2004 19:34:55 +0200 Message-ID: <06CF906FE3998C4E944213062009F162233CB2@oefeg-s02.oefeg.loc> Thread-Topic: AW: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt Thread-Index: AcQe6DIPHu3d5NByRcKQabJr1trMKAAN/EJs From: "Stastny Richard" To: "Michael Haberler" , =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Cc: , , "Hollenbeck, Scott" , , 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 Pmxvb2ssIFBhZiAtIG5vIHRpZXJzIDspDQogDQpBbmQgd2Ugc2hvdWxkIGxlYXZlIGl0IHdpdGgg dGhpcw0KDQpUaGUgdGllciBjb25jZXB0IHdhcyBpbnZlbnRlZCAyIHllYXJzIGFnbyB0byBleHBs YWluIEVOVU0gdG8gcGVvcGxlDQpoYXZpbmcgbm8gaWRlYSBhYm91dCBETlMgZXRjLiAoZS5nIElU VS1ULCByZWd1bGF0b3JzOyBiZWxsaGVhZHMsIC4uLikNCm9uIG9uZSBzbGlkZToNClRpZXIgMCAt PiBJQUIvSVRVLVQvUklQRQ0KVGllciAxIC0+IG5hdGlvbmFsIG1hdHRlcg0KVGllciAyIC0+IGVu ZC11c2VyLWxldmVsDQoNClRoZSBkZXN0aW5jdGlvbiBpbiBUaWVyIDAgYW5kIFRpZXIgMSB3YXMg ZW5vdWdoIGZvciBJVFUtVC8NCklBQi9SSVBFIHRvIGNyZWF0ZSB0aGUgaW50ZXJpbSBwcm9jZWR1 cmVzIGFuZCBldmVyeWJvZHkgd2FzIA0KYW5kIHN0aWxsIGlzIGhhcHB5LiBUaGUgb25seSBpc3N1 ZSBub3Qgc28gY2xlYXIgd2hhdCBpcyBpbiBiZXR3ZWVuDQpUaWVyIDAgYW5kIDEgaW4gY2FzZSBv ZiB0aGUgTkFOUCAtIHNlZSA7LSkNCg0KSW4gYWRkaXRpb24sIGF0IHRoaXMgdGltZSBub2JvZHkg aGFkIGFueSBpZGVhIGhvdw0KdGhlIGFkbWluaXN0cmF0aW9uIGJldHdlZW4gVGllciAxIGFuZCAy IHdpbGwgd29yayBvdXQgYW5kIGl0IHRvb2sNCnR3byB5ZWFycyB0byBzb3J0IHRoaXMgb3V0IGFu ZCB3ZSBzdGlsbCBhcmUgc3RpbGwgd29ya2luZw0KDQpTbyBJTUhPIG9waW5pb24gd2Ugc2hvdWxk IG5vdCB0cnkgdG8gZGVmaW5lIHRoZSB0aWVycw0Kbm93ICh3aGljaCB3YXMgYSBjb2Fyc2UgbW9k ZWwgYW55d2F5KSwgYnV0IGNvbnRpbnVlDQp0byB3b3JrIG9uIHRoZSAqcm9sZSogbW9kZWwgUGF0 cmlrIGFuZCBNaWNoYWVsIHdoZXJlDQpkaXNjdXNzaW5nLg0KDQpSaWNoYXJkDQoNCiANCg0KDQoN Cg0K _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sun Apr 11 07:22: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 HAA20764 for ; Sun, 11 Apr 2004 07:22:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCd2R-0002MZ-Of for enum-archive@odin.ietf.org; Sun, 11 Apr 2004 07:22:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3BBMBC5009040 for enum-archive@odin.ietf.org; Sun, 11 Apr 2004 07:22:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCd2G-0002LO-I3; Sun, 11 Apr 2004 07:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCd1X-0002Eu-SL for enum@optimus.ietf.org; Sun, 11 Apr 2004 07:21:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20759 for ; Sun, 11 Apr 2004 07:21:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCd1W-0000jw-00 for enum@ietf.org; Sun, 11 Apr 2004 07:21:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCd0p-0000dO-00 for enum@ietf.org; Sun, 11 Apr 2004 07:20:31 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BCczv-0000Om-00 for enum@ietf.org; Sun, 11 Apr 2004 07:19:35 -0400 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 11 Apr 2004 13:20:19 +0200 X-BrightmailFiltered: true 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 i3BBHe24003749; Sun, 11 Apr 2004 13:18:09 +0200 (MET DST) Received: from xfe-ams-331.cisco.com ([144.254.231.72]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 11 Apr 2004 13:16:07 +0200 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 11 Apr 2004 13:18:04 +0200 In-Reply-To: <06CF906FE3998C4E944213062009F162233CB2@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F162233CB2@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 Cc: , , "Hollenbeck, Scott" , , "Michael Haberler" , From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt Date: Sun, 11 Apr 2004 13:18:02 +0200 To: "Stastny Richard" X-Mailer: Apple Mail (2.613) X-OriginalArrivalTime: 11 Apr 2004 11:18:04.0629 (UTC) FILETIME=[A8987850:01C41FB6] 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 Apr 10, 2004, at 19:34, Stastny Richard wrote: > So IMHO opinion we should not try to define the tiers > now (which was a coarse model anyway), but continue > to work on the *role* model Patrik and Michael where > discussing. Sounds like a plan! But, I also like your definitions: > Tier 0 -> IAB/ITU-T/RIPE > Tier 1 -> national matter > Tier 2 -> end-user-level ...which I really think one can have somewhere where the roles are discussed. This to show one can not clearly have a 1:1 mapping between "Tier 1 provider" and a specific organisation somewhere. The mapping is more floating and fuzzy than that. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Apr 14 11:10: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 LAA00172 for ; Wed, 14 Apr 2004 11:10:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlqg-0005q7-FC for enum-archive@odin.ietf.org; Wed, 14 Apr 2004 10:58:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EEwk1G022447 for enum-archive@odin.ietf.org; Wed, 14 Apr 2004 10:58:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDll8-0004nW-20; Wed, 14 Apr 2004 10:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlf5-0003nK-En for enum@optimus.ietf.org; Wed, 14 Apr 2004 10:46:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28721 for ; Wed, 14 Apr 2004 10:46:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlf2-00075G-00 for enum@ietf.org; Wed, 14 Apr 2004 10:46:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDleC-0006xW-00 for enum@ietf.org; Wed, 14 Apr 2004 10:45:53 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1BDldf-0006o9-00; Wed, 14 Apr 2004 10:45:19 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 14 Apr 2004 16:44:49 +0200 Message-ID: <06CF906FE3998C4E944213062009F162233CC5@oefeg-s02.oefeg.loc> Thread-Topic: Additional Information in ENUM and the tel: PSTN-Indicator Thread-Index: AcQiLvm75iM9YeSrSH6zMpncqxkKbA== 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: quoted-printable Subject: [Enum] Additional Information in ENUM and the tel: PSTN-Indicator 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, I apologize in advance for posting this to both lists, but I think both ENUM and IPTEL are involved. I would suggest posting any replies only on the ENUM list. Abstract: This e-mail describes a solution to issues discussed on this list regarding putting additional information in ENUM (e164.arpa). The solution is required for ENUM-driven numbers, but may also be used for additional purposes. The solution may also be used in other ENUM-like applications. The solution may either be submitted as a separate ID or may be included in the currently work-in-progress BCP on ENUM. This proposal will also be submitted to ETSI to be included in V2 of TS 102 172. The solution contains also a proposed change to the NAPTR syntax (the "v" or *void* flag) and an additional parameter for the=20 tel: URI (;pstn) Problem statement: In RFC2916bis, RFC3403 and ETSI TS 102 172 it is well defined how an ENUM client should react if an E.164 number is queried in ENUM DNS (e164.arpa) for NAPTR and how this NAPTR should be processed.=20 On the other hand, it is currently not clearly defined what should happen if the result of the query is NXDOMAIN. The current assumption is that if the UAC wants to establish a=20 voice call, the call is routed by default to the PSTN, if the UAC or server is capable of doing so.=20 The underlying assumption here is the following: since ENUM is opt-in, the number dialed may either exist on the PSTN or the PSTN will know that the number does not exist. This may not be very efficient in all cases, but it works. This is no longer true with *ENUM-driven* E.164 numbers. =20 ENUM-driven E.164 numbers are defined in number ranges=20 existing only in ENUM. Numbers within of these number-ranges are not terminated on the PSTN, but routed forward to an ENUM-enabled=20 gateway. The ENUM-enabled gateways are querying ENUM to route the call further to its termination on the Internet. Within these number-ranges numbers may not be assigned (yet), but the gateway has in this case not the option to route the call further (back) to the PSTN.=20 It is therefore required in this case to provide the ENUM clients (at least the ENUM-clients in the gateways) with an additional information, to prevent them from routing these calls to the PSTN. Note: Since ENUM-enabled clients may route the call immediately to the PSTN (e.g. via an FXO-port), the solution must be simple, related or near to ENUM (e164.arpa) and using=20 similar algorithms (e.g. using NAPTR records). In addition, it would be nice to be able to signal=20 the found-out facts to other servers during the signalling path,=20 to prevent them from making unnecessary queries to ENUM. It would also be nice to be able to re-use possible=20 solutions for other purposes. So what are the requirements? The basic requirement is the following: If an ENUM client queries ENUM for a given fully qualified E.164 number and this number is not contained within e164.arpa, the DNS query returns NXDOMAIN. For ENUM-driven number ranges it SHALL be possible to provide the ENUM client with an additional information how to handle the call (that is: the number is not assigned) For ENUM opt-in number ranges it would be nice in some cases to be able provide additional information. These cases could be (not taxative): - the number is a DDI number out of a number range assigned to a PBX (the additional information may point to the switchboard). - the number range is also not existing on the PSTN=20 (number not assigned). - the number range is operated by telephony service provider providing a gateway (border element) to the public Internet. (the additional information may point to this gateway) - the number range is operated via a LNP or 800 database (ffs). Note: It was also proposed to use these solutions to point to carrier or infrastructure ENUM trees. IMHO this should not be done, considering that we are talking only about User ENUM. User clients will not be able to access carrier ENUM. In addition, it is not clear yet if and how carrier ENUM will be implemented. This issue it therefore=20 currently out-of-scope or ffs. The following questions need to be answered: 1.How and where to place the information in ENUM? 2.In which format the information is placed in ENUM? 3.How the signal this information to other servers? Possible solutions: 1. How and where to place the information in ENUM? During the discussion on the list several proposals have been brought forward: - use wild cards - populate the ENUM database with all possible numbers - create one or more additional trees (shadow tree) - use the SOA response given back with NXDOAMIN I do not want to repeat the full discussion here, but the essence of the discussion was: -wildcards do not work as intended and necessary -populating ENUM with all possible numbers is not a good idea=20 and also would not work in cases with variable number length. -creating more then one shadow tree and placing pointers to these trees in e164.arpa would also not solve the primary problem: where to put these pointers and how to find them. -creating one second shadow tree is a valid option, allowing to wildcard NAPTRs in the second tree for a given number range, but it would not allow to nest this information. In addition, a second tree was considered *nasty* by some participants and it would also require a global agreement, stirring up all bodies again concerned with e164.arpa. -this leaves the usage of the SOA response in NXDOMAIN.=20 This solution also would require only minor changes in ENUM administration and also in the clients. Where and how is the additional information derived from ENUM? This proposal (from Jim Reed) uses the additional information that's in=20 the NXDOMAIN response. This response will include the SOA record=20 for the zone enclosing the name that was looked up. The name=20 of that zone can be looked up to get a NAPTR for a default SIP gateway or whatever.=20 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.=20 The response includes a SOA record for 5.4.3.2.1.e164.arpa -- the=20 enclosing zone for this name. This will be in the Authority Section=20 of the reply. In other words, the name servers for 5.4.3.2.1.e164.arpa=20 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. It can also be used for number-ranges like 800 and 900 numbers or DDI blocks.=20 Calls to these numbers will get shunted to the right "gateway".=20 This does of course make things a little bit trickier for a Tier-1 registry that delegates every individual E.164 number. Below is a complete example how such a query may be=20 implemented in an ENUM client. 2. In which format the information is placed in ENUM? Basic requirement: all information shall use NAPTR records What kind of information could be provided: A. This E.164 number does not exist. Proposal: use the "v" flag (for void) Example: IN NAPTR 10 10 "v" "E2U" In this case the call is not routed further and "No-such number" is returned by the client B. Use a normal NAPTR pointing to a sip: or h323: URI This could be used either to point to the switchboard of a PBX or to a gateway provided for a numbering block by an service provider. Note: if e.g. only a NAPTR is provided for h323 and the=20 client is only capable of doing SIP, the call may also be forwarded to the "PSTN". 3. How does the UAC or server signal this information to other servers? Discussion: If a client or server has queried ENUM for an E.164 number,=20 the following outcomes are possible: a.the client has found a sip: or h323: URI, so the next proxy sees an address-of-record anyway. b.the query has returned a tel: URI and the client has done a second ENUM query for this E.164 number, also retrieving an address-of-Record (or has got an indication in the tel: URI to route the call to the "PSTN", see below). c. the client has queried ENUM, found no result and has DECIDED to route the call to the PSTN. d. the client has NOT done an ENUM query, because the end-user has explicitly prohibited this, e.g. by entering a special service (access) code. So the client (or server) is sending either a=20 sip: or h323: URI to the next proxy or an E.164 number only with the intention to forward it to the PSTN. Only if the client is not capable of doing an ENUM query, it may send an E.164 number otherwise. So sending an enum-dip-indicator seems not very useful. What is required instead is sending a "force-to-pstn" indicator. It is therefore proposed to add a ;pstn indicator to the tel: URI.=20 The ;pstn indicator is attached to a tel: URI (or an equivalent sip: URI in the following cases: 1.The user has explicitly entered an agreed upon access code to force the call to the PSTN 2. The ENUM query has retrieved a tel: URI with a ;pstn indicator 3. The ENUM query has retrieved no result (NXDOMAIN) in all above cases. A server receiving such a tel: URI MUST forward the call to a server capable of PSTN routing or MUST be able to=20 to PSTN routing by itself (either via carrier ENUM or by routing the call to the PSTN via a gateway). If the server or the UA is not capable of doing so, it must return *no such service* So what is finally the new procedure for an ENUM client? Complete walkthrough: =20 For sake of simplicity, let's assume a pure voice call, e.g. from a phone on a terminal adapter: =20 Assumptions: the system (server or TA) is able to: A. set up a voice call B. respond with "no such service" (e.g trunk busy) C: respond with "no such number" (e.g. SIT) =20 Start: The user is dialing a number, the UAC is normalizing this number into an E.164 number and the ENUM client is querying the=20 E.164 number in e164.arpa: 1. It gets back one or more NAPTRs, one of them is usable to set up a voice call -> done. =20 2. It gets back some NAPTRs, none of the is usable to set up a voice call -> response: "no such service" =20 3. It gets back NODATA -> response: "no such service" Note1: 2. and 3. is currently handled in a different way: the system tries to set up a call to the PSTN! (I myself used this to force a call to my mobile phone) Note2: The only way in future to force a call to the PSTN in this case would be to explicitly provide a NAPTR with voice:tel and a tel: URI pointing to the same (or a different number), preferable with tel:+xxx;pstn, (which makes sense anyway) =20 4. It gets back NXDOMAIN 4a. It now queries the domain given back in the SOA response for NAPTR. 4b. It does not get the enclosing domain back in the SOA response because of a broken or out-date DNS implementation -> the call is routed to the PSTN. =20 5. It gets back a NAPTR: 5a. the flag field is "v" -> response: "no such number" Note3: this implies that ENUM-driven number ranges SHALL contain always a NAPTR with flag "v" on top!! 5b. the NAPTR is not usable for voice calls -> response: "no such service"? 5c: the NAPTR is usable for voice and is a simple URI=20 (no regexp) -> set up call, done 5d. the NAPTR is usable for voice and contains a regexp (no comes the tricky part) the regexp has to be evaluated with the original AUS from the first query! -> set up call, done =20 6. It gets back NODATA -> set up call with tel:+xxx;pstn, where xxx is the AUS from the original ENUM query Note4: this would be equivalent if a NAPTR containg enumservice E2U+voice:tel and tel:/1;pstn was retrieved. =20 7. It gets back NXDOMAIN -> something is=20 seriously wrong ;-) Final remark: There is a minor problem with this approach indofar, that some (very out-dated) DNS applications still do not support this feature. Quote from Jim Reed: [Any sane DNS implementation will return a SOA record in the Authority Section of an NXDOMAIN reply. This is required by RFC2308. > > 3 - Negative Answers from Authoritative Servers > > Name servers authoritative for a zone MUST include the SOA record of > the zone in the authority section of the response when reporting an > NXDOMAIN or indicating that no data of the requested type exists. > A DNS implementation that doesn't implement RFC2308 is broken and/or very, very old. These should not be found or deployed in the ENUM system. - end quote] =20 On the other hand the procedure is designed in such a way that as a default (if the enclosing domain is not returned) the call is forwarded to the PSTN. =20 This does not really hurt in the most cases, only in case of=20 ENUM-driven number ranges. In this case the mandatory requirement would be that at least the generic gateways must live in a DNS-foodchain capable of returning the enclosing domain, which should be doable. Summary: What needs to be done: Include the above procedure in a BCP Define the *void* flag in an RFC Define the ;pstn indicator for tel: in an RFC Best regards Richard > Richard Stastny OFEG Osterreichische Fernmeldetechnische Entwicklungs- und Forderungsgesellschaft mbH Buroadresse: Arsenal Objekt 24, 7. Stock, Bauteil Ost, A-1030 Wien Postadresse: Postfach 147, A-1103 Wien Telefon: +43 664 420 4100 Telefax: +43 1 79780 13 E-Mail: =20 Web: Die in dieser Mitteilung und Anhangen enthaltenen Informationen sind ausschlie?lich fur den Adressaten bestimmt und konnen geheime, vertrauliche oder vor Weitergabe geschutzte Informationen enthalten. Falls es sich beim Leser dieses Absatzes nicht um den beabsichtigten Empfanger oder dessen Vertretung handelt, wird er hiermit in Kenntnis gesetzt, dass jegliche Weitergabe, Verteilung oder Vervielfaltigung dieser Mitteilung verboten ist. Sollte dieses Schreiben irrtumlich zugestellt worden sein, wird gebeten, den Absender zu benachrichtigen und die Mitteilung zu loschen, ohne Kopien einzubehalten. Danke. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Apr 14 13:17:11 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 NAA07543 for ; Wed, 14 Apr 2004 13:17:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnd6-0003tq-3x for enum-archive@odin.ietf.org; Wed, 14 Apr 2004 12:52:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EGqq4h014976 for enum-archive@odin.ietf.org; Wed, 14 Apr 2004 12:52:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnCM-0005On-OH; Wed, 14 Apr 2004 12:25:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmwg-0002RH-4h for enum@optimus.ietf.org; Wed, 14 Apr 2004 12:09:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03464 for ; Wed, 14 Apr 2004 12:08:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmwe-0003pI-00 for enum@ietf.org; Wed, 14 Apr 2004 12:09:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmvq-0003nt-00 for enum@ietf.org; Wed, 14 Apr 2004 12:08:11 -0400 Received: from eddie.austria.eu.net ([193.154.142.22]) by ietf-mx with esmtp (Exim 4.12) id 1BDmvO-0003k4-00 for enum@ietf.org; Wed, 14 Apr 2004 12:07:42 -0400 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 i3EG7ABH014431 for ; Wed, 14 Apr 2004 18:07:10 +0200 Received: (from lendl@localhost) by eddie.Austria.EU.net (8.12.3/8.12.3/Debian-6.6) id i3EG7AaN014430 for enum@ietf.org; Wed, 14 Apr 2004 18:07:10 +0200 Date: Wed, 14 Apr 2004 18:07:10 +0200 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-03.txt Message-ID: <20040414180710.A14349@nic.at> Mail-Followup-To: Otmar Lendl , enum@ietf.org References: <29000.1081532585@gromit.rfc1035.com> <6.0.3.0.2.20040409134758.039d9eb0@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.20040409134758.039d9eb0@joy.songbird.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/04/09 19:04, Richard Shockey wrote: > At 01:43 PM 4/9/2004, Jim Reid wrote: > > >>>>>> "Richard" == Richard Shockey writes: > > > > >> - Tier1 registries will just do delegations. > > > > Richard> Which means the registration object for the Tier 1 needs > > Richard> the social and technical contact data ( name address etc) > > Richard> as well as the NS data for the delegation. > > > >Not necessarily. They could have a tag for the contact data: for > >instance an authentication token validating that the number "belongs" > >to the entity that registered it. The actual contact data could stay > >with the registrar/ASP. > > OK the thin registry model the one that everyone has been trying to move > away from. .. as I said before this is a national specific issue but the > data object MUST be able to carry social data if necessary. > >From my point of view, the main issue with thin registries is that you don't have a central DB which contains the authorative data on who owns what domain. Thus whenever there is a dispute about ownership, things get complicated. In the ENUM space, the ownership of the ENUM domain is derived from the ownership of the right-to-use of the corresponding number. The registry data (or registrar data in case of thin registries) does not define ownership any more. In case of disputes you just fall back to your validation procedures and ignore the Tier1 and the registrar DBs. Things might be different for ENUM-only number-ranges where there is no PSTN-side ownership tracking. Of course, even though the data might not be authoritative, it might still be useful to have contact and ownership data in the Tier1. It's just not that important as in the GTLD/ccTLD space. /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 Fri Apr 23 17:34: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 RAA14484 for ; Fri, 23 Apr 2004 17:34:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7zA-0003uk-Sn for enum-archive@odin.ietf.org; Fri, 23 Apr 2004 17:13:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NLDOJv015046 for enum-archive@odin.ietf.org; Fri, 23 Apr 2004 17:13:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7r4-000705-7v; Fri, 23 Apr 2004 17:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7IZ-0001Au-A9 for enum@optimus.ietf.org; Fri, 23 Apr 2004 16:29:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08672 for ; Fri, 23 Apr 2004 16:29:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7IX-0005xU-ER for enum@ietf.org; Fri, 23 Apr 2004 16:29:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7HU-0005bH-00 for enum@ietf.org; Fri, 23 Apr 2004 16:28:17 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1BH7GQ-0004vo-00 for enum@ietf.org; Fri, 23 Apr 2004 16:27:10 -0400 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 i3NKQTd31296 for ; Fri, 23 Apr 2004 13:26:29 -0700 Message-Id: <6.1.0.6.2.20040423162603.039088c8@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Fri, 23 Apr 2004 16:26:11 -0400 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: Last Call: 'Enumservice Registration for Presence Services' to Proposed Standard 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-test-idtracker: no >To: IETF-Announce :; >From: The IESG >Subject: Last Call: 'Enumservice Registration for Presence Services' to > Proposed Standard >Reply-to: iesg@ietf.org >Date: Fri, 23 Apr 2004 12:33:23 -0400 >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,TO_HAS_SPACES autolearn=no > version=2.60 >Sender: ietf-announce-admin@ietf.org >X-BeenThere: ietf-announce@ietf.org >X-Mailman-Version: 2.0.12 >List-Unsubscribe: , > >List-Id: >List-Post: >List-Help: >List-Subscribe: , > > > >The IESG has received a request from the Telephone Number Mapping WG >(ENUM) to consider the following document: > >- 'Enumservice Registration for Presence Services ' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2004-05-07. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-enum-pres-00.txt > > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Sat Apr 24 18: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 SAA09318 for ; Sat, 24 Apr 2004 18:04:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHVEE-0003KT-Pk for enum-archive@odin.ietf.org; Sat, 24 Apr 2004 18:02:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3OM2UUN012762 for enum-archive@odin.ietf.org; Sat, 24 Apr 2004 18:02:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHVAr-0000NH-49; Sat, 24 Apr 2004 17:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3wN-0001uQ-8V for enum@optimus.ietf.org; Fri, 23 Apr 2004 12:54:15 -0400 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19348 for ; Fri, 23 Apr 2004 12:54:11 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BH3cB-0003en-4c; Fri, 23 Apr 2004 12:33:23 -0400 X-test-idtracker: no To: IETF-Announce :; From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Fri, 23 Apr 2004 12:33:23 -0400 Subject: [Enum] Last Call: 'Enumservice Registration for Presence Services' to Proposed Standard 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: , The IESG has received a request from the Telephone Number Mapping WG (ENUM) to consider the following document: - 'Enumservice Registration for Presence Services ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-05-07. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-pres-00.txt _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 30 20:18:07 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 UAA14884 for ; Fri, 30 Apr 2004 20:18:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJi5r-00061x-4W for enum-archive@odin.ietf.org; Fri, 30 Apr 2004 20:10:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i410Axx3023181 for enum-archive@odin.ietf.org; Fri, 30 Apr 2004 20:10:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJi13-0004wC-Pe; Fri, 30 Apr 2004 20:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJhwb-00049Z-EB for enum@optimus.ietf.org; Fri, 30 Apr 2004 20:01:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14199 for ; Fri, 30 Apr 2004 20:01:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJhwZ-00047s-G8 for enum@ietf.org; Fri, 30 Apr 2004 20:01:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJhva-000414-00 for enum@ietf.org; Fri, 30 Apr 2004 20:00:23 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BJhv7-0003vm-00; Fri, 30 Apr 2004 19:59:53 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3UNx5U08151; Fri, 30 Apr 2004 16:59:05 -0700 (PDT) Message-Id: <200404302359.i3UNx5U08151@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, enum@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 30 Apr 2004 16:59:05 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-9.0 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.60 Subject: [Enum] RFC 3761 on The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (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: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3761 Title: The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) Author(s): P. Faltstrom, M. Mealling Status: Standards Track Date: April 2004 Mailbox: paf@cisco.com, michael@verisignlabs.com Pages: 18 Characters: 41559 Obsoletes: 2916 I-D Tag: draft-ietf-enum-rfc2916bis-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3761.txt 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. This document is a product of the Telephone Number Mapping Working Group of the IETF. This is now a Proposed Standard Working Group. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040430165731.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3761 --OtherAccess Content-Type: Message/External-body; name="rfc3761.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040430165731.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 30 20:19:05 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 UAA14956 for ; Fri, 30 Apr 2004 20:19:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJi9N-0006Zs-IV for enum-archive@odin.ietf.org; Fri, 30 Apr 2004 20:14:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i410EbbE025266 for enum-archive@odin.ietf.org; Fri, 30 Apr 2004 20:14:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJi2z-0005M5-C5; Fri, 30 Apr 2004 20:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJhyY-0004TC-WF for enum@optimus.ietf.org; Fri, 30 Apr 2004 20:03:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14368 for ; Fri, 30 Apr 2004 20:03:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJhyX-0004Oc-1P for enum@ietf.org; Fri, 30 Apr 2004 20:03:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJhxr-0004Jc-00 for enum@ietf.org; Fri, 30 Apr 2004 20:02:44 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BJhx8-00048U-00; Fri, 30 Apr 2004 20:01:58 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4100fU08465; Fri, 30 Apr 2004 17:00:41 -0700 (PDT) Message-Id: <200405010000.i4100fU08465@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, enum@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 30 Apr 2004 17:00:41 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-9.0 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.60 Subject: [Enum] RFC 3762 on Telephone Number Mapping (ENUM) Service Registration for H.323 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 Request for Comments is now available in online RFC libraries. RFC 3762 Title: Telephone Number Mapping (ENUM) Service Registration for H.323 Author(s): O. Levin Status: Standards Track Date: April 2004 Mailbox: oritl@microsoft.com Pages: 5 Characters: 8450 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-h323-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3762.txt The H.323 specification defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers a Telephone Number Mapping (ENUM) service for H.323 according to specifications and guidelines in RFC 3761. This document is a product of the Telephone Number Mapping Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040430165924.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3762 --OtherAccess Content-Type: Message/External-body; name="rfc3762.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040430165924.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Apr 30 20: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 UAA15229 for ; Fri, 30 Apr 2004 20:23:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJiEC-0007av-M2 for enum-archive@odin.ietf.org; Fri, 30 Apr 2004 20:19:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i410Jajg029184 for enum-archive@odin.ietf.org; Fri, 30 Apr 2004 20:19:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJi9l-0006kd-NG; Fri, 30 Apr 2004 20:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJi3L-0005Ql-MT for enum@optimus.ietf.org; Fri, 30 Apr 2004 20:08:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14554 for ; Fri, 30 Apr 2004 20:08:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJi3J-0004tZ-Md for enum@ietf.org; Fri, 30 Apr 2004 20:08:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJi2Q-0004nq-00 for enum@ietf.org; Fri, 30 Apr 2004 20:07:26 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BJi1a-0004d5-00; Fri, 30 Apr 2004 20:06:34 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4104KU09576; Fri, 30 Apr 2004 17:04:20 -0700 (PDT) Message-Id: <200405010004.i4104KU09576@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, enum@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 30 Apr 2004 17:04:19 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-8.7 required=5.0 tests=AWL,BIZ_TLD, MIME_BOUND_NEXTPART,NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.60 Subject: [Enum] RFC 3764 on enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record 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 Request for Comments is now available in online RFC libraries. RFC 3764 Title: enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record Author(s): J. Peterson Status: Standards Track Date: April 2004 Mailbox: jon.peterson@neustar.biz Pages: 8 Characters: 17604 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-sip-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3764.txt This document registers an Electronic Number (ENUM) service for the Session Initiation Protocol (SIP), pursuant to the guidelines in RFC 3761. Specifically, this document focuses on provisioning SIP addresses-of-record in ENUM. This document is a product of the Telephone Number Mapping Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040430170301.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3764 --OtherAccess Content-Type: Message/External-body; name="rfc3764.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040430170301.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum