From enum-bounces@ietf.org Fri Sep 02 15:14:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBGzb-0001we-Ao; Fri, 02 Sep 2005 15:14:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBGzY-0001uw-CL for enum@megatron.ietf.org; Fri, 02 Sep 2005 15:14:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24863 for ; Fri, 2 Sep 2005 15:14:22 -0400 (EDT) Received: from bay103-dav14.bay103.hotmail.com ([65.54.174.86] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBH1k-0006gt-At for enum@ietf.org; Fri, 02 Sep 2005 15:16:41 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 2 Sep 2005 12:14:11 -0700 Message-ID: Received: from 65.54.174.200 by BAY103-DAV14.phx.gbl with DAV; Fri, 02 Sep 2005 19:14:10 +0000 X-Originating-IP: [65.54.174.200] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: "Peter Williams" To: Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] telURIsincommonpolicy Date: Fri, 2 Sep 2005 12:14:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWj5/5Zpv/HNaIoSDqCa9nRBojT9AChqcbQAC1AAKAAAJYzoAAAp1NwAAAynkAAAOiKsAAAwOSQAANx4EAAHMCwAAIQNmhA In-Reply-To: X-OriginalArrivalTime: 02 Sep 2005 19:14:11.0260 (UTC) FILETIME=[7FE52FC0:01C5AFF2] X-Spam-Score: 0.8 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The week-long enum silence is deafening. Is it holiday time in France, again? So all design work stops? Or has the manufacturing world essentially stopped - given its national holiday week, in China? Peter. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 02 20:54:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBMJ0-00007E-7W; Fri, 02 Sep 2005 20:54:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBMIy-000079-A8 for enum@megatron.ietf.org; Fri, 02 Sep 2005 20:54:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21921 for ; Fri, 2 Sep 2005 20:54:46 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EBML8-00042a-W7 for enum@ietf.org; Fri, 02 Sep 2005 20:57:08 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-10.tower-121.messagelabs.com!1125708831!5111230!6 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 30324 invoked from network); 3 Sep 2005 00:54:32 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-10.tower-121.messagelabs.com with SMTP; 3 Sep 2005 00:54:32 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 431511900020E793; Fri, 2 Sep 2005 20:54:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Sep 2005 20:54:30 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0B044284@ACCLUST02EVS1.ugd.att.com> Thread-Topic: ENUM silence - how's the re-charter coming? Thread-Index: AcWj5/5Zpv/HNaIoSDqCa9nRBojT9AChqcbQAC1AAKAAAJYzoAAAp1NwAAAynkAAAOiKsAAAwOSQAANx4EAAHMCwAAIQNmhAAAvlGVA= From: "Pfautz, Penn L, NEO" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: "Peterson, Jon" , Allison Mankin Subject: [Enum] ENUM silence - how's the re-charter coming? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Peter: You remind me of an essential point: WHERE ARE WE ON THE RE-CHARTER of the ENUM WG to INCLUDE CARRIER ENUM!? This really needs be happening now. Penn Pfautz=20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Peter Williams Sent: Friday, September 02, 2005 3:14 PM To: enum@ietf.org Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple]telURIsincommonpolicy The week-long enum silence is deafening.=20 Is it holiday time in France, again? So all design work stops? Or has the manufacturing world essentially stopped - given its national holiday week, in China? Peter. _______________________________________________ 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 enum-bounces@ietf.org Sat Sep 03 01:38:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBQjV-0005J2-7s; Sat, 03 Sep 2005 01:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBQjQ-0005Dz-QJ for enum@megatron.ietf.org; Sat, 03 Sep 2005 01:38:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01915 for ; Sat, 3 Sep 2005 01:38:23 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EBQle-0003Tw-KG for enum@ietf.org; Sat, 03 Sep 2005 01:40:46 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] ENUM silence - how's the re-charter coming? X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sat, 3 Sep 2005 07:38:15 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C44C4@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] ENUM silence - how's the re-charter coming? Thread-Index: AcWj5/5Zpv/HNaIoSDqCa9nRBojT9AChqcbQAC1AAKAAAJYzoAAAp1NwAAAynkAAAOiKsAAAwOSQAANx4EAAHMCwAAIQNmhAAAvlGVAAChqJyQ== From: "Stastny Richard" To: "Pfautz, Penn L, NEO" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: "Peterson, Jon" , Allison Mankin X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I am also waiting on the proposal for re-chartering ENUM WG to be = distributed =20 BTW: Did anybody already tell Allison what happened in Paris in the ENUM = WG? Because Allison did not attend the meeting on Friday. =20 -richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Pfautz, Penn L, NEO Gesendet: Sa 03.09.2005 02:54 An: enum@ietf.org Cc: Peterson, Jon; Allison Mankin Betreff: [Enum] ENUM silence - how's the re-charter coming? Peter: You remind me of an essential point: WHERE ARE WE ON THE RE-CHARTER of the ENUM WG to INCLUDE CARRIER ENUM!? This really needs be happening now. Penn Pfautz -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Peter Williams Sent: Friday, September 02, 2005 3:14 PM To: enum@ietf.org Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple]telURIsincommonpolicy The week-long enum silence is deafening. Is it holiday time in France, again? So all design work stops? Or has the manufacturing world essentially stopped - given its national holiday week, in China? Peter. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Sep 04 06:04:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBrMT-00083H-0n; Sun, 04 Sep 2005 06:04:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBrMQ-000839-GH for enum@megatron.ietf.org; Sun, 04 Sep 2005 06:04:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00645 for ; Sun, 4 Sep 2005 06:04:24 -0400 (EDT) Received: from sip.mah.priv.at ([81.223.16.194] helo=www.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBrOx-00029L-66 for enum@ietf.org; Sun, 04 Sep 2005 06:07:04 -0400 Received: from localhost ([127.0.0.1] helo=mah9.inode.at) by www.mah.priv.at with esmtp (Exim 3.36 #1 (Debian)) id 1EBrM1-0004KW-00; Sun, 04 Sep 2005 12:04:01 +0200 Message-Id: <6.2.3.4.2.20050904115431.03558770@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 04 Sep 2005 12:04:00 +0200 To: "Pfautz, Penn L, NEO" , From: Michael Haberler Subject: Re: [Enum] ENUM silence - how's the re-charter coming? In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0B044284@ACCLUST02EVS1.ugd .att.com> References: <34DA635B184A644DA4588E260EC0A25A0B044284@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-59A22814 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Peterson, Jon" , Allison Mankin X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I would love to see progress on this front, too market demand is in place, politics is in place, service could be in place - our bottleneck is currently the IETF process *please* pick up the loose ends thanks -Michael At 02:54 03.09.2005, Pfautz, Penn L, NEO wrote: >Peter: >You remind me of an essential point: >WHERE ARE WE ON THE RE-CHARTER of the ENUM WG to INCLUDE CARRIER ENUM!? > >This really needs be happening now. > > >Penn Pfautz > >-----Original Message----- >From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of >Peter Williams >Sent: Friday, September 02, 2005 3:14 PM >To: enum@ietf.org >Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: >[Simple]telURIsincommonpolicy > >The week-long enum silence is deafening. > >Is it holiday time in France, again? So all design work stops? > >Or has the manufacturing world essentially stopped - given its national >holiday week, in China? > >Peter. > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 05 06:39:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECEOF-00076Y-In; Mon, 05 Sep 2005 06:39:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECEOE-00076D-3M for enum@megatron.ietf.org; Mon, 05 Sep 2005 06:39:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09032 for ; Mon, 5 Sep 2005 06:39:47 -0400 (EDT) Received: from central.switch.ch ([130.59.11.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECEQx-0002V0-H7 for enum@ietf.org; Mon, 05 Sep 2005 06:42:40 -0400 Received: from machb.switch.ch ([130.59.6.129]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1ECENk-0004Jn-00; Mon, 05 Sep 2005 12:39:20 +0200 Date: Mon, 5 Sep 2005 12:38:27 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: "Pfautz, Penn L, NEO" Subject: Re: [Enum] ENUM silence - how's the re-charter coming? In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0B044284@ACCLUST02EVS1.ugd.att.com> Message-ID: References: <34DA635B184A644DA4588E260EC0A25A0B044284@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: enum@ietf.org, "Peterson, Jon" , Allison Mankin X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Penn, On Fri, 2 Sep 2005, Pfautz, Penn L, NEO wrote: > You remind me of an essential point: WHERE ARE WE ON THE > RE-CHARTER of the ENUM WG to INCLUDE CARRIER ENUM!? > > This really needs be happening now. Hey man! Take it easy...! ;-) It is kind of an unwritten law that ENUM WG processes, which involve acions by the ENUM WG chairs, tend to take more time than elsewhere. To give you a rough idea on how much time this could be: For a simple ENUM WG chair approval of a new WG document, I have been waiting already for more than two months (and I am still waiting)... So, now you can start extrapolating...;-) Have fun and good luck! cheers, Bernie _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 05 07:05:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECEnO-00028R-98; Mon, 05 Sep 2005 07:05:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECEnN-00028C-1K for enum@megatron.ietf.org; Mon, 05 Sep 2005 07:05:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10285 for ; Mon, 5 Sep 2005 07:05:45 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ECEq6-0003Cd-LZ for enum@ietf.org; Mon, 05 Sep 2005 07:08:40 -0400 Subject: AW: [Enum] ENUM silence - how's the re-charter coming? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Sep 2005 13:06:22 +0200 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C44CB@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] ENUM silence - how's the re-charter coming? thread-index: AcWyBuFv3NzpoSMLRHKCADtSgOTDyQAAvhRt From: "Stastny Richard" To: "Bernie Hoeneisen" , "Pfautz, Penn L, NEO" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, "Peterson, Jon" , Allison Mankin X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Bernie, =20 minor correction: =20 acions by the ENUM WG chairs, tend to take more time than elsewhere. ^^^^^^ c/WG chairs/AD/ =20 -richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Bernie Hoeneisen Gesendet: Mo 05.09.2005 12:38 An: Pfautz, Penn L, NEO Cc: enum@ietf.org; Peterson, Jon; Allison Mankin Betreff: Re: [Enum] ENUM silence - how's the re-charter coming? Penn, On Fri, 2 Sep 2005, Pfautz, Penn L, NEO wrote: > You remind me of an essential point: WHERE ARE WE ON THE > RE-CHARTER of the ENUM WG to INCLUDE CARRIER ENUM!? > > This really needs be happening now. Hey man! Take it easy...! ;-) It is kind of an unwritten law that ENUM WG processes, which involve acions by the ENUM WG chairs, tend to take more time than elsewhere. To give you a rough idea on how much time this could be: For a simple ENUM WG chair approval of a new WG document, I have been waiting already for more than two months (and I am still waiting)... So, now you can start extrapolating...;-) Have fun and good luck! cheers, Bernie _______________________________________________ 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 enum-bounces@ietf.org Tue Sep 06 12:07:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECfyq-0000HL-Au; Tue, 06 Sep 2005 12:07:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECfyo-0000H2-Q9 for enum@megatron.ietf.org; Tue, 06 Sep 2005 12:07:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05411 for ; Tue, 6 Sep 2005 12:07:24 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECg1n-0000xC-Qz for enum@ietf.org; Tue, 06 Sep 2005 12:10:33 -0400 Received: from [10.31.32.109] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j86G7is1019596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2005 09:07:46 -0700 Message-ID: <431DBEA0.4090509@shockey.us> Date: Tue, 06 Sep 2005 12:06:56 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: AW: [Enum] ENUM silence - how's the re-charter coming? References: <32755D354E6B65498C3BD9FD496C7D462C44CB@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C44CB@oefeg-s04.oefeg.loc> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.4 (+) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: enum@ietf.org, Bernie Hoeneisen , "Pfautz, Penn L, NEO" , "Peterson, Jon" , Allison Mankin X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1743922385==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1743922385== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Stastny Richard wrote: 
Bernie,
 
minor correction:
 
acions by the ENUM WG chairs, tend to take more time than elsewhere.
                             ^^^^^^
c/WG chairs/AD/
The WG chairs have submitted a recharter proposal to the AD's several weeks ago ..we are waiting for a response.
 

  
You remind me of an essential point: WHERE ARE WE ON THE
RE-CHARTER of the ENUM WG to INCLUDE CARRIER ENUM!?

This really needs be happening now.
    

Hey man! Take it easy...! ;-)

It is kind of an unwritten law that ENUM WG processes, which involve
acions by the ENUM WG chairs, tend to take more time than elsewhere.
To give you a rough idea on how much time this could be: For a simple
ENUM WG chair approval of a new WG document, I have been waiting already
for more than two months (and I am still waiting)...
So, now you can start extrapolating...;-)
You know Bernie .. I told you what was going on ... I've informed the ID editors of the status of your document.

I dont control the ID editors

I suggested you go ahead and resubmit the document..( which you did not do) and you still are whining.

I'm getting a little ticked off.
Have fun and good luck!

cheers,
  Bernie


_______________________________________________
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

  


-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--===============1743922385== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1743922385==-- From enum-bounces@ietf.org Tue Sep 06 15:11:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECiqX-0008Oo-4L; Tue, 06 Sep 2005 15:11:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECiqU-0008Mv-UV for enum@megatron.ietf.org; Tue, 06 Sep 2005 15:11:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14674 for ; Tue, 6 Sep 2005 15:10:59 -0400 (EDT) Received: from omzesmtp02.mci.com ([199.249.17.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECitP-0005xB-IZ for enum@ietf.org; Tue, 06 Sep 2005 15:14:08 -0400 Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0IME0033UT9W88@firewall.mci.com> for enum@ietf.org; Tue, 06 Sep 2005 19:10:44 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0IME00C01T9KT5@pmismtp05.mcilink.com>; Tue, 06 Sep 2005 19:10:44 +0000 (GMT) Received: from [166.50.70.118] by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0IME00CB5T9THT@pmismtp05.mcilink.com>; Tue, 06 Sep 2005 19:10:41 +0000 (GMT) Date: Tue, 06 Sep 2005 14:10:41 -0500 From: Robert Schafer Subject: Re: AW: [Enum] ENUM silence - how's the re-charter coming? In-reply-to: <431DBEA0.4090509@shockey.us> To: enum@ietf.org Message-id: <431DE9B1.3050804@mci.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) References: <32755D354E6B65498C3BD9FD496C7D462C44CB@oefeg-s04.oefeg.loc> <431DBEA0.4090509@shockey.us> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: mankin@psg.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: robert.schafer@mci.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org We support IETF moving forward in a timely fashion with the ENUM WG's re-charter efforts related to Carrier ENUM (i.e., supporting WG activities at IETF #64). Thank you, Robert W Schafer, MCI Network Architecture & Standards 2400 N Glenville Dr,Richardson,TX 75082/Ofc +1972 7296125 This message is privileged, confidential and not for public use. If received in error, please delete it. _ _ _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 06 15:41:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECjKK-00060x-Qo; Tue, 06 Sep 2005 15:41:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECjKJ-00060m-60 for enum@megatron.ietf.org; Tue, 06 Sep 2005 15:41:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17350 for ; Tue, 6 Sep 2005 15:41:49 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECjNK-0006x8-47 for enum@ietf.org; Tue, 06 Sep 2005 15:44:59 -0400 Received: from [10.31.13.115] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j86JgGop006534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2005 12:42:17 -0700 Message-ID: <431DF0E7.2090409@shockey.us> Date: Tue, 06 Sep 2005 15:41:27 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: robert.schafer@mci.com Subject: Re: AW: [Enum] ENUM silence - how's the re-charter coming? References: <32755D354E6B65498C3BD9FD496C7D462C44CB@oefeg-s04.oefeg.loc> <431DBEA0.4090509@shockey.us> <431DE9B1.3050804@mci.com> In-Reply-To: <431DE9B1.3050804@mci.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "Peterson, Jon" , mankin@psg.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Robert Schafer wrote: > We support IETF moving forward in a timely fashion with the ENUM WG's > re-charter efforts related to Carrier ENUM (i.e., supporting WG > activities at IETF #64). > > Thank you, No thank you all. Expressions of support for a rechartering effort such as this are important .. it is August so our AD's may be still be relaxing on some remote beach. The chairs will continue to press the issue. Just a reminder to the list of the importance here. To repeat what I posted to the list on Aug 19. " The Chairs want to make it explicitly clear that ultimate acceptance of Carrier / Private ENUM related drafts are fundamentally Dependant upon WG recharter. This task has been long over due. The Chairs are now actively engaged in the task of drafting language to the AD's/ IESG incorporating the wishes of the WG to move forward on these issues including specific Goals and Milestones. In addition there is a clear relationship of our efforts to the emerging discussions coming out of the voipeer BOF that must be taken into consideration. That said the spirited discussion within the ENUM WG to date and in tandem with the voipeer community should indicate the general consensus on where a recharter should be focused on. " > Robert W Schafer, MCI Network Architecture & Standards > 2400 N Glenville Dr,Richardson,TX 75082/Ofc +1972 7296125 > This message is privileged, confidential and not for > public use. If received in error, please delete it. > _ _ > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)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 enum-bounces@ietf.org Wed Sep 07 09:01:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECzYr-0002bn-Uy; Wed, 07 Sep 2005 09:01:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECkf2-000491-Ip for enum@megatron.ietf.org; Tue, 06 Sep 2005 17:07:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29160 for ; Tue, 6 Sep 2005 17:07:18 -0400 (EDT) Received: from argv.paf.se ([195.66.31.72] helo=paf.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECki3-0002w9-Un for enum@ietf.org; Tue, 06 Sep 2005 17:10:29 -0400 Received: from [195.66.31.71] (account paf HELO [195.66.31.71]) by paf.se (CommuniGate Pro SMTP 4.3.6) with ESMTPA id 2656906; Tue, 06 Sep 2005 23:06:53 +0200 In-Reply-To: References: <34DA635B184A644DA4588E260EC0A25A0B044284@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47861366-AA27-4B0B-A58A-E758B0A0107C@paf.se> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] ENUM silence - how's the re-charter coming? Date: Tue, 6 Sep 2005 23:06:49 +0200 To: Bernie Hoeneisen X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 07 Sep 2005 09:01:53 -0400 Cc: "'enum@ietf.org' ENUM" , David Meyer , "Pfautz, Penn L, NEO" , Jon Peterson , Allison Mankin X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org We (ENUM chairs) are syncing with voipeer bof chairs, and we (with help from the AD's of course) will make sure the two groups don't stomp on each others toes. We have practical problems at the moment, to find a time when we all can have a teleconf together. We are working on it. That said, I see good discussions the last week(s). Don't stop thinking just because of our administrative / practical problems. paf On Sep 5, 2005, at 12:38, Bernie Hoeneisen wrote: > Penn, > > On Fri, 2 Sep 2005, Pfautz, Penn L, NEO wrote: > > > >> You remind me of an essential point: WHERE ARE WE ON THE RE- >> CHARTER of the ENUM WG to INCLUDE CARRIER ENUM!? >> >> This really needs be happening now. >> >> > > Hey man! Take it easy...! ;-) > > It is kind of an unwritten law that ENUM WG processes, which > involve acions by the ENUM WG chairs, tend to take more time than > elsewhere. > To give you a rough idea on how much time this could be: For a > simple ENUM WG chair approval of a new WG document, I have been > waiting already for more than two months (and I am still waiting)... > So, now you can start extrapolating...;-) > > Have fun and good luck! > > cheers, > Bernie > > > _______________________________________________ > 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 enum-bounces@ietf.org Wed Sep 07 09:59:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0S5-00076N-0E; Wed, 07 Sep 2005 09:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED0S3-00076I-BZ for enum@megatron.ietf.org; Wed, 07 Sep 2005 09:58:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20560 for ; Wed, 7 Sep 2005 09:58:57 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ED0VF-0006Pd-1N for enum@ietf.org; Wed, 07 Sep 2005 10:02:17 -0400 Content-class: urn:content-classes:message Subject: RE: [Enum] ENUM silence - how's the re-charter coming? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Sep 2005 16:02:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B211E@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] ENUM silence - how's the re-charter coming? Thread-Index: AcWzrOXKwKNKytDYTmWWp4DfXTv8oQAB4KLw From: "Stastny Richard" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Bernie Hoeneisen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, David Meyer , "Pfautz, Penn L, NEO" , Jon Peterson , Allison Mankin X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > Don't stop > thinking just because of our administrative / practical problems. Thanks for the wake-up call. I was in sleep-mode now since Paris ;-) Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 07 15:50:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED5w6-0003Hw-6T; Wed, 07 Sep 2005 15:50:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED5vo-0003CH-38; Wed, 07 Sep 2005 15:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12576; Wed, 7 Sep 2005 15:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED5z1-0008Vj-EA; Wed, 07 Sep 2005 15:53:24 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ED5vl-0005IC-V8; Wed, 07 Sep 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Sep 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-epp-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Validation Information Mapping for the Extensible Provisioning Protocol Author(s) : B. Hoeneisen Filename : draft-ietf-enum-validation-epp-00.txt Pages : 25 Date : 2005-9-7 This document describes an EPP extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range), which the ENUM domain name is based on. Specified in XML, this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM domain names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-epp-00.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-validation-epp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-validation-epp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-7153221.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-validation-epp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-validation-epp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-7153221.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Thu Sep 08 10:14:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDNAC-00055l-AM; Thu, 08 Sep 2005 10:14:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDEhg-0001Ck-QF for enum@megatron.ietf.org; Thu, 08 Sep 2005 01:12:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15517 for ; Thu, 8 Sep 2005 01:12:03 -0400 (EDT) Received: from its-mu-mail1.its.rmit.edu.au ([131.170.1.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDEkn-0007zV-QB for enum@ietf.org; Thu, 08 Sep 2005 01:15:30 -0400 Received: from student.rmit.edu.au (its-nm-smtp57.its.rmit.edu.au [131.170.11.130]) by its-mu-mail1.its.rmit.edu.au (8.13.1/8.13.1/mail1) with ESMTP id j885Bfl1008925 for ; Thu, 8 Sep 2005 15:11:42 +1000 (EST) Received: from S8902866 [138.217.120.236] by student.rmit.edu.au with NetMail ModWeb Module; Thu, 08 Sep 2005 15:11:41 +1000 From: "Graham Leslie Galea" To: enum@ietf.org Date: Thu, 08 Sep 2005 15:11:41 +1000 X-Mailer: NetMail ModWeb Module X-Sender: S8902866 MIME-Version: 1.0 Message-ID: <1126156301.53fbbbdcS8902866@student.rmit.edu.au> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 1.0 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 08 Sep 2005 10:14:01 -0400 Subject: [Enum] VoIP Identification and location, minor thesis X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hello IETF, My name is Graham Galea and I am a Masters of Telecommunications Engineerin= g Student at RMIT working on a minor thesis researching how VoIP phones c= an be identified and located by parties such as Emergency Services, and i= s thus very interested in ENUM. I also happen to work for the Victorian State Emergency Service as a Commun= ications Projects Engineer, and have recently helped design and implement= the routing table for the Victorian backbone of the 132xxx National Stat= e Emergency Number, hence my interest in VoIP is more than just academic.= =20 The 3 main issues that I am researching are: 1. How to route a call to the nearest Emeregncy Service Provider. 2. Call Identification for Callback 3. Physical location of the caller for an immediate response. I'd like to enter into discussion with IETF the 3 above mentioned issues, e= specially on whether ENUM will play a key role in the call Identification= for Callback, and how this is intended to work. In the mean time, if anyone can direct me to a good source of research mate= rial. This will be most appreciated. I can be contact on my mobile any time 0439318822 or by this email address. Kind Regards Graham Galea. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 08 10:21:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDNH0-0007c3-Ug; Thu, 08 Sep 2005 10:21:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDNGy-0007bv-Ot for enum@megatron.ietf.org; Thu, 08 Sep 2005 10:21:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22521 for ; Thu, 8 Sep 2005 10:21:02 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDNKK-0005CF-W3 for enum@ietf.org; Thu, 08 Sep 2005 10:24:35 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 08 Sep 2005 07:20:51 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j88EKNKO028001; Thu, 8 Sep 2005 07:20:43 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 10:18:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] VoIP Identification and location, minor thesis Date: Thu, 8 Sep 2005 10:18:32 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E38A3B58@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] VoIP Identification and location, minor thesis Thread-Index: AcW0f9eF1WiJIujkRKOCaFbDiChKowAAEbag From: "Michael Hammer \(mhammer\)" To: "Graham Leslie Galea" , X-OriginalArrivalTime: 08 Sep 2005 14:18:32.0987 (UTC) FILETIME=[318A06B0:01C5B480] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Have you checked into the ECRIT WG yet? Mike =20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Graham Leslie Galea > Sent: Thursday, September 08, 2005 1:12 AM > To: enum@ietf.org > Subject: [Enum] VoIP Identification and location, minor thesis >=20 > Hello IETF, >=20 > My name is Graham Galea and I am a Masters of=20 > Telecommunications Engineering Student at RMIT working on a=20 > minor thesis researching how VoIP phones can be identified=20 > and located by parties such as Emergency Services, and is=20 > thus very interested in ENUM. >=20 > I also happen to work for the Victorian State Emergency=20 > Service as a Communications Projects Engineer, and have=20 > recently helped design and implement the routing table for=20 > the Victorian backbone of the 132xxx National State Emergency=20 > Number, hence my interest in VoIP is more than just academic.=20 >=20 > The 3 main issues that I am researching are: >=20 > 1. How to route a call to the nearest Emeregncy Service Provider. >=20 > 2. Call Identification for Callback >=20 > 3. Physical location of the caller for an immediate response. >=20 > I'd like to enter into discussion with IETF the 3 above=20 > mentioned issues, especially on whether ENUM will play a key=20 > role in the call Identification for Callback, and how this is=20 > intended to work. >=20 > In the mean time, if anyone can direct me to a good source of=20 > research material. This will be most appreciated. >=20 > I can be contact on my mobile any time 0439318822 or by this=20 > email address. >=20 > Kind Regards >=20 > Graham Galea. >=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 08 10:26:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDNLq-0000B3-3v; Thu, 08 Sep 2005 10:26:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDNLn-0000AK-52 for enum@megatron.ietf.org; Thu, 08 Sep 2005 10:26:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22809 for ; Thu, 8 Sep 2005 10:26:00 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EDNPA-0005Jk-KB for enum@ietf.org; Thu, 08 Sep 2005 10:29:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: Re: [Enum] VoIP Identification and location, minor thesis MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Sep 2005 16:28:09 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C44DB@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] VoIP Identification and location, minor thesis Thread-Index: AcW0gDIpK4MPjAThRvarQewxe2UGzAAAVcnR From: "Stastny Richard" To: "Graham Leslie Galea" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org http://www.ietf.org/html.charters/ecrit-charter.html =20 -richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Graham Leslie Galea Gesendet: Do 08.09.2005 07:11 An: enum@ietf.org Betreff: [Enum] VoIP Identification and location, minor thesis Hello IETF, My name is Graham Galea and I am a Masters of Telecommunications = Engineering Student at RMIT working on a minor thesis researching how = VoIP phones can be identified and located by parties such as Emergency = Services, and is thus very interested in ENUM. I also happen to work for the Victorian State Emergency Service as a = Communications Projects Engineer, and have recently helped design and = implement the routing table for the Victorian backbone of the 132xxx = National State Emergency Number, hence my interest in VoIP is more than = just academic. The 3 main issues that I am researching are: 1. How to route a call to the nearest Emeregncy Service Provider. 2. Call Identification for Callback 3. Physical location of the caller for an immediate response. I'd like to enter into discussion with IETF the 3 above mentioned = issues, especially on whether ENUM will play a key role in the call = Identification for Callback, and how this is intended to work. In the mean time, if anyone can direct me to a good source of research = material. This will be most appreciated. I can be contact on my mobile any time 0439318822 or by this email = address. Kind Regards Graham Galea. _______________________________________________ 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 enum-bounces@ietf.org Thu Sep 08 13:17:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDQ1f-0005rj-1J; Thu, 08 Sep 2005 13:17:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDQ1d-0005pW-EJ for enum@megatron.ietf.org; Thu, 08 Sep 2005 13:17:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03981 for ; Thu, 8 Sep 2005 13:17:22 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDQ53-0001tl-CR for enum@ietf.org; Thu, 08 Sep 2005 13:20:57 -0400 Received: from [10.31.13.113] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j88HHuJf019595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2005 10:17:58 -0700 Message-ID: <4320721A.9080001@shockey.us> Date: Thu, 08 Sep 2005 13:17:14 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.6 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Subject: [Enum] WG action items... X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1101400358==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1101400358== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Now that the August holidays are over and in order to eliminate the mad rush to November I want to see if we can start to move forward on some of our documents to WGLC especially those we made decisions on in Paris

First I think VOID is ready now for WGLC ... right?

http://www.ietf.org/internet-drafts/draft-ietf-enum-void-01.txt

Larry are you planing on one more iteration of this shortly so it can move forward?
http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-02.txt  

Andy I believe you were going to spin this one more time ... and  resubmit in WG format for WGLC. As we discussed in Paris   we have a requirement for this in the US ENUM LLC.
http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-00.txt

This was pretty straight forward so if it can be resubmited as WG document and go to WGLC ASAP. OK
http://www.ietf.org/internet-drafts/draft-brandner-enum-voice-00.txt

-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

--===============1101400358== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1101400358==-- From enum-bounces@ietf.org Fri Sep 09 09:01:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDiVS-0007Mo-97; Fri, 09 Sep 2005 09:01:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDiVM-0007LT-4X for enum@megatron.ietf.org; Fri, 09 Sep 2005 09:01:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00174 for ; Fri, 9 Sep 2005 09:01:18 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EDiYw-00013g-Hl for enum@ietf.org; Fri, 09 Sep 2005 09:05:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [Enum] WG action items... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Sep 2005 15:03:26 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2129@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] WG action items... Thread-Index: AcW0mcQFRR33Gq1RQ3ig7fwBO55NzwApFCSg From: "Stastny Richard" To: "Richard Shockey" , , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Rich, >First I think VOID is ready now for WGLC ... right? > http://www.ietf.org/internet-drafts/draft-ietf-enum-void-01.txt No need to do this, It was done already, Void is already in IESG Evaluation. We need to provide a new draft. This was pretty straight forward so if it can be resubmited as WG = document and go to WGLC ASAP. OK=20 http://www.ietf.org/internet-drafts/draft-brandner-enum-voice-00.txt We will resubmit this asap as WG document Richard ________________________________________ From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = Richard Shockey Sent: Thursday, September 08, 2005 7:17 PM To: enum@ietf.org; Patrik F=E4ltstr=F6m Subject: [Enum] WG action items... Now that the August holidays are over and in order to eliminate the mad = rush to November I want to see if we can start to move forward on some = of our documents to WGLC especially those we made decisions on in Paris First I think VOID is ready now for WGLC ... right? http://www.ietf.org/internet-drafts/draft-ietf-enum-void-01.txt Larry are you planing on one more iteration of this shortly so it can = move forward? http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-02.txt _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 09 11:26:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDkm9-0005Ee-QX; Fri, 09 Sep 2005 11:26:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDkm8-0005Ck-GK for enum@megatron.ietf.org; Fri, 09 Sep 2005 11:26:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09925 for ; Fri, 9 Sep 2005 11:26:46 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDkpj-00059y-70 for enum@ietf.org; Fri, 09 Sep 2005 11:30:32 -0400 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 09 Sep 2005 11:26:42 -0400 id 000C7C27.4321A9B2.0000658C In-Reply-To: <4320721A.9080001@shockey.us> References: <4320721A.9080001@shockey.us> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7BADB03E-53F1-485B-81D3-34D911B28FAD@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Enum] WG action items... Date: Fri, 9 Sep 2005 11:26:42 -0400 To: Richard Shockey X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "=?ISO-8859-1?Q?\"Patrik_F=E4ltstr=F6m\"?=" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Sep 8, 2005, at 1:17 PM, Richard Shockey wrote: > Andy I believe you were going to spin this one more time ... and > resubmit in WG format for WGLC. As we discussed in Paris we have > a requirement for this in the US ENUM LLC. > http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-00.txt Yup. In fact, I'm submitting it today. -andy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Sep 11 08:36:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EER4d-0005Kp-Vw; Sun, 11 Sep 2005 08:36:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDnE2-0000BN-TA for enum@megatron.ietf.org; Fri, 09 Sep 2005 14:03:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19317 for ; Fri, 9 Sep 2005 14:03:45 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDnHd-0001QD-SF for enum@ietf.org; Fri, 09 Sep 2005 14:07:32 -0400 Received: from admb.isi.edu (admb.isi.edu [128.9.160.248]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id j89I1hk20488; Fri, 9 Sep 2005 11:01:43 -0700 (PDT) Message-Id: <200509091801.j89I1hk20488@boreas.isi.edu> Date: Fri, 9 Sep 2005 11:01:43 -0700 (PDT) From: Alice Hagens To: bhoeneis@switch.ch MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: tKki/Jb4FCFd7nnHYNkiKA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hagens@boreas.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-Mailman-Approved-At: Sun, 11 Sep 2005 08:36:42 -0400 Cc: enum@ietf.org, "Hollenbeck, Scott" , rfc-editor@rfc-editor.org Subject: [Enum] Re: Erratum in RFC 4114 (fwd) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alice Hagens List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Greetings, Thank you for bringing this error to our attention. Please confirm that it is posted accurately on http://www.rfc-editor.org/errata.html. Thank you. RFC Editor/ah >Date: Tue, 21 Jun 2005 12:48:30 +0200 (CEST) >From: Bernie Hoeneisen >X-X-Sender: bhoeneis@machb >To: rfc-editor@rfc-editor.org >Subject: Erratum in RFC 4114 (fwd) >MIME-Version: 1.0 >X-ISI-4-39-6-MailScanner: Found to be clean, Found to be clean >X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 > >Dear RFC Editor > >Just a reminder: > >2 weeks ago I have reported an Erratum in RFC 4114 (see below), but it has >not appeared in the RFC Errata pages yet: > http://www.rfc-editor.org/errata.html > >cheers, > Bernie > >---------- Forwarded message ---------- >Date: Tue, 7 Jun 2005 11:37:57 +0200 (CEST) >From: Bernie Hoeneisen >To: rfc-editor@rfc-editor.org >Cc: enum@ietf.org, "Hollenbeck, Scott" >Subject: Erratum in RFC 4114 > >FYI and the RFC errata Database: > >As reported months ago (before publication as RFC) directly to the author, >there is an erratum in RFC 4114 in section 3.1.2. EPP Command: > > > Example response: > > [...] > S: 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa > [...] > S: ns1.example.com > S: ns2.example.com > S: > --> S: ns1.example.com > --> S: ns2.example.com > [...] > >There is the that should list the "fully qualified names of >the subordinate host objects that exist under this superordinate domain >object." > >As the is not "example.com:, those elements should >be removed in this case. > >cheers, > Bernie > > >On Mon, 6 Jun 2005 rfc-editor@rfc-editor.org wrote: > >> A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 4114 >> >> Title: E.164 Number Mapping for the Extensible >> Provisioning Protocol (EPP) >> Author(s): S. Hollenbeck >> Status: Standards Track >> Date: June 2005 >> Mailbox: shollenbeck@verisign.com >> Pages: 17 >> Characters: 31490 >> Updates/Obsoletes/SeeAlso: None >> >> I-D Tag: draft-ietf-enum-epp-e164-08.txt >> >> URL: ftp://ftp.rfc-editor.org/in-notes/rfc4114.txt _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 12 15:50:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEuKK-0004gs-5Z; Mon, 12 Sep 2005 15:50:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEuJa-0004RO-8q; Mon, 12 Sep 2005 15:50:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11834; Mon, 12 Sep 2005 15:50:03 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEuNm-00077S-Vt; Mon, 12 Sep 2005 15:54:28 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EEuJW-0004CV-A8; Mon, 12 Sep 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 12 Sep 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-iris-ereg-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : An ENUM Registry Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-ietf-enum-iris-ereg-02.txt Pages : 57 Date : 2005-9-12 This document describes an IRIS registry schema for registered ENUM information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-iris-ereg-02.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-iris-ereg-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-iris-ereg-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-12110550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-iris-ereg-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-iris-ereg-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-12110550.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Mon Sep 12 15:50:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEuKM-0004iB-Vi; Mon, 12 Sep 2005 15:50:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEuJb-0004SJ-Vr; Mon, 12 Sep 2005 15:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11868; Mon, 12 Sep 2005 15:50:06 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEuNn-00077s-MZ; Mon, 12 Sep 2005 15:54:29 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EEuJW-0004EM-V4; Mon, 12 Sep 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 12 Sep 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-voice-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for Enumservice Voice Author(s) : R. Brandner Filename : draft-ietf-enum-voice-00.txt Pages : 13 Date : 2005-9-12 This document registers the ENUMservice ^voice^ (which has a defined sub-type ^tel^), as per the IANA registration process defined in the ENUM specification RFC3761. This service indicates that the contact held in the generated URI can be used to initiate an interactive voice (audio) call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-voice-00.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-voice-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-voice-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-12130007.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-voice-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-voice-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-12130007.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Tue Sep 13 15:32:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGW2-0004Pc-2L; Tue, 13 Sep 2005 15:32:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFACp-0007Hf-7o for enum@megatron.ietf.org; Tue, 13 Sep 2005 08:48:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19891 for ; Tue, 13 Sep 2005 08:48:06 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFAHB-0001eM-6P for enum@ietf.org; Tue, 13 Sep 2005 08:52:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Sep 2005 14:51:33 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C44F9@oefeg-s04.oefeg.loc> Thread-Topic: Carrier ENUM an applet of Voipeer (IP Interconnect) Thread-Index: AcW4Yd5D5nswHAzRScyy47D67Zmb4w== From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Subject: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi all, =20 since we still do not have a new ENUM charter and time is running out, (ADs missing in non-action) I want to throw in some stones in the pond to stir up the Carrier ENUM requirements discussion: =20 ENUM (Carrier and User ENUM) is an applet to IP -Interconnect. To be = able to use an applet you need to be able to use the applications the = applet is running on. You cannot use e.g. an applet integrating your Skype buddies in MS = Outlook without having Skype and MS Outlook installed and running on = your laptop. Same with ENUM: ENUM is useless without the possibility to enter an E.164 number in DNS = and the capability to use the resulting URI, e.g. in case of real-time = communications a SIP URI.=20 =20 For further background and rationale see: http://voipandenum.blogspot.com/2005/09/carrier-enum-is-applet-of-ip.html= =20 Executive summary: =20 The basic requirement for Carrier ENUM to work is a global IP = Interconnect (VoIP peering) solution for "Carriers". To summarize: 1. The minimum requirements and rules for IP Interconnect based on = routing via SIP URIs have to be established globally. Note: if the = minimum requirements are fullfilled (e.g. TLS), the calling server must = be able to resolve the SIP AoR to the IP-address of the called server = and also to be able to contact the called server. The called user MAY = have additional agreements in his profile, e.g. to reject all anonymous = calls. 2. Only if this is in place, Carrier ENUM makes sense on a global scale. = This does not imply that Carrier ENUM may not be trialed and used = commercially earlier, but only in a limited way. 3. Carrier ENUM must be available on a global scale. This implies that = Carrier MUST be available for any carrier who wants to use it. This = implies that although it is a national matter how to implement Carrier = ENUM in detail and to define e.g. the entity operating the Tier 1, there = should be no opt-out possible (this is IMHO the most problematic point). 4. It is a national matter to define who is entitled to enter which = numbers and the corresponding NAPTRs in "Carrier" ENUM, e.g. an entity is only allowed to enter numbers in Carrier ENUM if it is = hosting the final destination of the E.164 number on behalf of the = end-user (that means no signalling transit is allowed) or if it is providing a direct gateway/SBC to the own destination = network hosting the E.164 number on a private IP-based network (NGN) or = on the PSTN. National number portability issues have also be taken into = account here. If an entity is assigned an E.164 number directly (e.g. an 800 number or = a corporate number), and if the entity is running the SIP server on its = own, it may also be allowed to enter this number and the NAPTRs in = Carrier ENUM. 4. There is no user opt-in or opt-out possible in Carrier ENUM. The = entities allowed to enter NAPTRs in Carrier ENUM MUST be aware that the = data in Carrier ENUM is public, therefor end-user privacy MUST be = assured. This implies that either the E.164 number or a random number = (userid) is used in the user-part of the SIP URI. The mapping from this = number to the end-user identity used further (even if it is a public = identity) MUST be done within the end-systems. 5. All SIP URIs entered in Carrier ENUM must be reachable via the = minimum requirements of IP Interconnect as defined in 1.=20 =20 Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 13 15:32:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGWG-0004cC-Jy; Tue, 13 Sep 2005 15:32:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFBLb-00029B-3m for enum@megatron.ietf.org; Tue, 13 Sep 2005 10:01:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22291 for ; Tue, 13 Sep 2005 10:00:54 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFBPc-00039f-3D for enum@ietf.org; Tue, 13 Sep 2005 10:05:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Sep 2005 16:01:27 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C44FC@oefeg-s04.oefeg.loc> Thread-Topic: Carrier ENUM an applet of Voipeer (IP Interconnect) Thread-Index: AcW1U6CnJhXCyiJuTgWuwKa6EgyHTwDGAHGz From: "Stastny Richard" To: "Richard Shockey" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, =?iso-8859-1?Q?=22Patrik_F=E4ltstr=F6m=22?= Subject: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi all, =20 since we still do not have a new ENUM charter and time is running out, (ADs missing in non-action) I want to throw in some stones in the pond to stir up the Carrier ENUM requirements discussion: =20 =20 ENUM (Carrier and User ENUM) is an applet to IP -Interconnect. To be = able to use an applet you need to be able to use the applications the = applet is running on. You cannot use e.g. an applet integrating your Skype buddies in MS = Outlook without having Skype and MS Outlook installed and running on = your laptop. Same with ENUM: ENUM is useless without the possibility to enter an E.164 number in DNS = and the capability to use the resulting URI, e.g. in case of real-time = communications a SIP URI.=20 =20 For further background and rationale see: http://voipandenum.blogspot.com/2005/09/carrier-enum-is-applet-of-ip.html= =20 Executive summary: =20 The basic requirement for Carrier ENUM to work is a global IP = Interconnect (VoIP peering) solution for "Carriers". To summarize: 1. The minimum requirements and rules for IP Interconnect based on = routing via SIP URIs have to be established globally. Note: if the = minimum requirements are fullfilled (e.g. TLS), the calling server must = be able to resolve the SIP AoR to the IP-address of the called server = and also to be able to contact the called server. The called user MAY = have additional agreements in his profile, e.g. to reject all anonymous = calls. 2. Only if this is in place, Carrier ENUM makes sense on a global scale. = This does not imply that Carrier ENUM may not be trialed and used = commercially earlier, but only in a limited way. 3. Carrier ENUM must be available on a global scale. This implies that = Carrier MUST be available for any carrier who wants to use it. This = implies that although it is a national matter how to implement Carrier = ENUM in detail and to define e.g. the entity operating the Tier 1, there = should be no opt-out possible (this is IMHO the most problematic point). 4. It is a national matter to define who is entitled to enter which = numbers and the corresponding NAPTRs in "Carrier" ENUM, e.g. an entity is only allowed to enter numbers in Carrier ENUM if it is = hosting the final destination of the E.164 number on behalf of the = end-user (that means no signalling transit is allowed) or if it is providing a direct gateway/SBC to the own destination = network hosting the E.164 number on a private IP-based network (NGN) or = on the PSTN. National number portability issues have also be taken into = account here. If an entity is assigned an E.164 number directly (e.g. an 800 number or = a corporate number), and if the entity is running the SIP server on its = own, it may also be allowed to enter this number and the NAPTRs in = Carrier ENUM. 4. There is no user opt-in or opt-out possible in Carrier ENUM. The = entities allowed to enter NAPTRs in Carrier ENUM MUST be aware that the = data in Carrier ENUM is public, therefor end-user privacy MUST be = assured. This implies that either the E.164 number or a random number = (userid) is used in the user-part of the SIP URI. The mapping from this = number to the end-user identity used further (even if it is a public = identity) MUST be done within the end-systems. 5. All SIP URIs entered in Carrier ENUM must be reachable via the = minimum requirements of IP Interconnect as defined in 1.=20 =20 Richard =20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 13 15:32:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGWZ-0004oR-FC; Tue, 13 Sep 2005 15:32:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFCJP-0003Xn-T0 for enum@megatron.ietf.org; Tue, 13 Sep 2005 11:03:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26164 for ; Tue, 13 Sep 2005 11:02:57 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFCNg-0004X4-SA for enum@ietf.org; Tue, 13 Sep 2005 11:07:34 -0400 Received: from [10.31.13.117] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8DF3L9s021224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Sep 2005 08:03:22 -0700 Message-ID: <4326EA0A.9040208@shockey.us> Date: Tue, 13 Sep 2005 11:02:34 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Enum] IRIS ereg and voice 00 documents X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org We have the new versions of IRIS ereg and voice 00 now ready. Please take some time ASAP to review the documents as the chairs wish to issue WGLC quickly. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)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 enum-bounces@ietf.org Wed Sep 14 04:44:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFSsv-0007LG-TI; Wed, 14 Sep 2005 04:44:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFSsu-0007LA-46 for enum@megatron.ietf.org; Wed, 14 Sep 2005 04:44:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28692 for ; Wed, 14 Sep 2005 04:44:50 -0400 (EDT) Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFSxQ-0003LS-Cw for enum@ietf.org; Wed, 14 Sep 2005 04:49:35 -0400 Received: from g8ibr.kiel01.telekom.de by tcmail31.dmz.telekom.de with ESMTP for enum@ietf.org; Wed, 14 Sep 2005 10:44:31 +0200 Received: by G8IBR.kiel01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Sep 2005 10:44:31 +0200 Message-Id: From: "Schiefner, Carsten" To: enum@ietf.org Subject: RE: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Date: Wed, 14 Sep 2005 10:43:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Richard, > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf = Of > Stastny Richard > Sent: Tuesday, September 13, 2005 2:52 PM > To: enum@ietf.org > Subject: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) >=20 > [...] > =20 > ENUM (Carrier and User ENUM) is an applet to IP=20 > -Interconnect. [...] as this was raised during the VOIPEER BOF in Paris already: we should = come up with another term to replace "Interconnect[ion]" - this one = could easily trigger (too much) interest from the regulatory front. I = personally don't like "VoIP Peering" too much either because it is = partly misleading and confusing with IP Peering, but for the time being = it seems to me to be the better pick. Best, Carsten --=20 Carsten Schiefner | p: +49 441 = 234-4571 Deutsche Telekom | f: +49 431 = 7163-3972 T-Com Zentrale TK44 | m: +49 151 = 14525458 Ammerl=E4nder Heerstr. 138 | = mailto:Carsten.Schiefner@t-com.net D-26129 Oldenburg | = http://www.t-com.de/kundendienst _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 14 04:56:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFT3t-000159-16; Wed, 14 Sep 2005 04:56:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFT3r-000154-Al for enum@megatron.ietf.org; Wed, 14 Sep 2005 04:56:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29037 for ; Wed, 14 Sep 2005 04:56:08 -0400 (EDT) Received: from clix.aarnet.edu.au ([192.94.63.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFT8P-0003dS-4M for enum@ietf.org; Wed, 14 Sep 2005 05:00:54 -0400 Received: from [127.0.0.1] (dhcp080.yarralumla.aarnet.edu.au [192.94.63.80]) (authenticated bits=0) by clix.aarnet.edu.au (8.12.8/8.12.8) with ESMTP id j8E8u1X2011156; Wed, 14 Sep 2005 18:56:03 +1000 Message-ID: <4327E597.2020201@aarnet.edu.au> Date: Wed, 14 Sep 2005 18:55:51 +1000 From: Kewin Stoeckigt Organization: AARNet User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) References: <32755D354E6B65498C3BD9FD496C7D462C44F9@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C44F9@oefeg-s04.oefeg.loc> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MDSA: Yes X-Spam-Score: -99.982 OPT_IN,USER_IN_WHITELIST X-Spam-Status: No X-Scanned-By: MIMEDefang 2.39 X-Spam-Score: 2.4 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Richard, ... > 4. There is no user opt-in or opt-out possible in Carrier ENUM. The entities allowed to enter NAPTRs in Carrier ENUM MUST be aware that the data in Carrier ENUM is public, therefor end-user privacy MUST be assured. This implies that either the E.164 number or a random number (userid) is used in the user-part of the SIP URI. The mapping from this number to the end-user identity used further (even if it is a public identity) MUST be done within the end-systems. Confess...you were reading on the Terena TF-VVC list (http://www.terena.nl/mail-archives/tf-vvc/). We were discussing such an option - using the informational RFC3944 for the 'backend'. We should formalize the thoughts thou... Kewin > > 5. All SIP URIs entered in Carrier ENUM must be reachable via the minimum requirements of IP Interconnect as defined in 1. > > Richard > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > - -- - ---------------------------------------------- Australian Academic and Research Network (AARNet) Kewin Stoeckigt Building 9, Banks Street Canberra ACT 2600 Australia Phone: +61 2 6222 3546 Fax: +61 2 6222 3535 Mobile:+61 4 2158 2563 Email: kewin.stoeckigt@aarnet.edu.au SIP: kewin.stoeckigt@aarnet.edu.au WWW: http://www.aarnet.edu.au/~kos/ - ----------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFDJ+WXbhxXquPpou8RAs+ZAJ90iWWHrEaGbc1lprLqyRtNI/TvZQCcDCZa 4wAgX9PB396Kaz7918MSQAs= =QPjx -----END PGP SIGNATURE----- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 14 05:08:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFTFW-0003iD-Oc; Wed, 14 Sep 2005 05:08:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFTFT-0003gy-E9 for enum@megatron.ietf.org; Wed, 14 Sep 2005 05:08:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29611 for ; Wed, 14 Sep 2005 05:08:09 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFTK2-0003y1-UO for enum@ietf.org; Wed, 14 Sep 2005 05:12:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Date: Wed, 14 Sep 2005 11:07:48 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4509@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Thread-Index: AcW5CUiZCFinxK1uTU2E2/78YqlFiwAAn4kZ From: "Stastny Richard" To: "Schiefner, Carsten" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I basically agree with you that both terms are inappropriate, but I have no better idea either. =20 IP Interconnect is very misleading, because it includes also L3.=20 What we are talking here is application (signalling) level interconnect (and not peering) =20 Any better ideas out there? =20 Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Schiefner, Carsten Gesendet: Mi 14.09.2005 10:43 An: enum@ietf.org Betreff: RE: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Hi Richard, > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of > Stastny Richard > Sent: Tuesday, September 13, 2005 2:52 PM > To: enum@ietf.org > Subject: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) > > [...] >=20 > ENUM (Carrier and User ENUM) is an applet to IP > -Interconnect. [...] as this was raised during the VOIPEER BOF in Paris already: we should = come up with another term to replace "Interconnect[ion]" - this one = could easily trigger (too much) interest from the regulatory front. I = personally don't like "VoIP Peering" too much either because it is = partly misleading and confusing with IP Peering, but for the time being = it seems to me to be the better pick. Best, Carsten -- Carsten Schiefner | p: +49 441 234-4571 Deutsche Telekom | f: +49 431 7163-3972 T-Com Zentrale TK44 | m: +49 151 14525458 Ammerl=E4nder Heerstr. 138 | = mailto:Carsten.Schiefner@t-com.net D-26129 Oldenburg | http://www.t-com.de/kundendienst _______________________________________________ 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 enum-bounces@ietf.org Wed Sep 14 05:50:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFTuT-0004Nm-FB; Wed, 14 Sep 2005 05:50:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFTuR-0004Ng-2u for enum@megatron.ietf.org; Wed, 14 Sep 2005 05:50:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01562 for ; Wed, 14 Sep 2005 05:50:28 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFTyz-00056x-Kr for enum@ietf.org; Wed, 14 Sep 2005 05:55:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Date: Wed, 14 Sep 2005 11:51:08 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C450B@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Thread-Index: AcW5EYeHLWto3SdERQ6LEr+hOnbEpAAAE0UF From: "Stastny Richard" To: "Alexander Mayrhofer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >IP endpoint discovery =20 Nice try, but this would be moe a replacement for Carrier ENUM ;-) =20 IP (Realtime Communications) Interconnect goes beyond this it also includes (IMHO) the minimum requirements for right of access of the IP endpoint. =20 Richard =20 ________________________________ Von: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] Gesendet: Mi 14.09.2005 11:44 An: Stastny Richard Cc: Schiefner, Carsten; enum@ietf.org Betreff: Re: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Stastny Richard wrote: > I basically agree with you that both terms are inappropriate, > but I have no better idea either. >=20 > IP Interconnect is very misleading, because it includes > also L3. > What we are talking here is application (signalling) > level interconnect (and not peering) >=20 > Any better ideas out there? What about "IP endpoint discovery"? axelm _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 14 06:32:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFUYl-0005J0-5a; Wed, 14 Sep 2005 06:32:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFUYi-0005Is-ST for enum@megatron.ietf.org; Wed, 14 Sep 2005 06:32:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02894 for ; Wed, 14 Sep 2005 06:32:05 -0400 (EDT) Received: from central.switch.ch ([130.59.11.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFUdH-00066j-SZ for enum@ietf.org; Wed, 14 Sep 2005 06:36:53 -0400 Received: from machb.switch.ch ([130.59.6.129]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1EFUYG-0006VD-00 for enum@ietf.org; Wed, 14 Sep 2005 12:31:40 +0200 Date: Wed, 14 Sep 2005 12:31:03 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: enum@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Enum] GnuGK works with ENUM and H.323-URLs X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Dear ENUMers! For those, who are interested in ENUM and (H.323) Videoconferencing: We can just confirm that the latest GnuGK [1] can deal with ENUM NAPTR records containing a H.323 URL [2], and routes the sessions to the correct destination. For this purpose we have set up a test environment for our Videoconferencing Infrastructure [3] (Videoconferencing implementations are still mostly based on H.323) and looked into different scenarios. We hope that the commercial vendors of videoconferencing devices soon follow the approach of the Open Source community and build in ENUM support into their products. Furthermore we are still looking for an ENUM enabled gateway, which handles the interconnection between SIP and H.323 videoconferencing correctly. There are many products, that can handle this correctly for voice only sessions (e.g. Asterisk [4]), but as soon as video comes into the game, it gets tricky.... Best regards, B. Hoeneisen, Switch, Project Manager ENUM References: [1] http://www.gnugk.org/ [2] http://www.ietf.org/rfc/rfc3762.txt [3] http://www.switch.ch/econf/html/vconf_main.html [4] http://www.asterisk.org/ _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 14 10:42:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFYSZ-0002p6-V0; Wed, 14 Sep 2005 10:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFYSX-0002oq-Tm for enum@megatron.ietf.org; Wed, 14 Sep 2005 10:42:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14747 for ; Wed, 14 Sep 2005 10:41:59 -0400 (EDT) Received: from philipp.labs.nic.at ([83.136.32.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFYX0-0003f8-Mf for enum@ietf.org; Wed, 14 Sep 2005 10:46:48 -0400 Received: from nat.labs.nic.at ([83.136.33.3] helo=[10.10.0.50]) by philipp.labs.nic.at with esmtp (Exim 3.36 #1 (Debian)) id 1EFYRq-0007om-00; Wed, 14 Sep 2005 16:41:18 +0200 Message-ID: <4328368E.5010404@pernau.at> Date: Wed, 14 Sep 2005 16:41:18 +0200 From: Klaus Darilion User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) References: <32755D354E6B65498C3BD9FD496C7D462C4509@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4509@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA14747 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Stastny Richard wrote: > I basically agree with you that both terms are inappropriate, > but I have no better idea either. > =20 > IP Interconnect is very misleading, because it includes > also L3.=20 > What we are talking here is application (signalling) > level interconnect (and not peering) > =20 > Any better ideas out there? IMO carrier ENUM does not define any kind of interconnect. It is a=20 routing information on L7. klaus > =20 > Richard >=20 > ________________________________ >=20 > Von: enum-bounces@ietf.org im Auftrag von Schiefner, Carsten > Gesendet: Mi 14.09.2005 10:43 > An: enum@ietf.org > Betreff: RE: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) >=20 >=20 >=20 > Hi Richard, >=20 >=20 >>-----Original Message----- >>From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of >>Stastny Richard >>Sent: Tuesday, September 13, 2005 2:52 PM >>To: enum@ietf.org >>Subject: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) >> >>[...] >> >>ENUM (Carrier and User ENUM) is an applet to IP >>-Interconnect. [...] >=20 >=20 > as this was raised during the VOIPEER BOF in Paris already: we should c= ome up with another term to replace "Interconnect[ion]" - this one could = easily trigger (too much) interest from the regulatory front. I personall= y don't like "VoIP Peering" too much either because it is partly misleadi= ng and confusing with IP Peering, but for the time being it seems to me t= o be the better pick. >=20 > Best, >=20 > Carsten > -- >=20 > Carsten Schiefner | p: +49 441 234-457= 1 > Deutsche Telekom | f: +49 431 7163-397= 2 > T-Com Zentrale TK44 | m: +49 151 1452545= 8 > Ammerl=E4nder Heerstr. 138 | mailto:Carsten.Schiefner@t-com.= net > D-26129 Oldenburg | http://www.t-com.de/kundendiens= t >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 14 11:04:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFYo9-0007tm-O9; Wed, 14 Sep 2005 11:04:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFYo8-0007tQ-Sf for enum@megatron.ietf.org; Wed, 14 Sep 2005 11:04:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15832 for ; Wed, 14 Sep 2005 11:04:18 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFYsi-0004F2-6f for enum@ietf.org; Wed, 14 Sep 2005 11:09:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Date: Wed, 14 Sep 2005 17:05:30 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4510@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Thread-Index: AcW5OuQM1yx1XQf6TQWXM4nCvCH18gAAttOa From: "Stastny Richard" To: "Klaus Darilion" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >IMO carrier ENUM does not define any kind of interconnect. It is a >routing information on L7. Correct It does not define it, but it needs some kind of interconnect defined, because otherwise it does not work As I said, an applet needs an application to run on Richard ________________________________ Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Gesendet: Mi 14.09.2005 16:41 An: Stastny Richard Cc: Schiefner, Carsten; enum@ietf.org Betreff: Re: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Stastny Richard wrote: > I basically agree with you that both terms are inappropriate, > but I have no better idea either. >=20 > IP Interconnect is very misleading, because it includes > also L3. > What we are talking here is application (signalling) > level interconnect (and not peering) >=20 > Any better ideas out there? IMO carrier ENUM does not define any kind of interconnect. It is a routing information on L7. klaus >=20 > Richard > > ________________________________ > > Von: enum-bounces@ietf.org im Auftrag von Schiefner, Carsten > Gesendet: Mi 14.09.2005 10:43 > An: enum@ietf.org > Betreff: RE: [Enum] Carrier ENUM an applet of Voipeer (IP = Interconnect) > > > > Hi Richard, > > >>-----Original Message----- >>From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of >>Stastny Richard >>Sent: Tuesday, September 13, 2005 2:52 PM >>To: enum@ietf.org >>Subject: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) >> >>[...] >> >>ENUM (Carrier and User ENUM) is an applet to IP >>-Interconnect. [...] > > > as this was raised during the VOIPEER BOF in Paris already: we should = come up with another term to replace "Interconnect[ion]" - this one = could easily trigger (too much) interest from the regulatory front. I = personally don't like "VoIP Peering" too much either because it is = partly misleading and confusing with IP Peering, but for the time being = it seems to me to be the better pick. > > Best, > > Carsten > -- > > Carsten Schiefner | p: +49 441 = 234-4571 > Deutsche Telekom | f: +49 431 = 7163-3972 > T-Com Zentrale TK44 | m: +49 151 = 14525458 > Ammerl=E4nder Heerstr. 138 | = mailto:Carsten.Schiefner@t-com.net > D-26129 Oldenburg | = http://www.t-com.de/kundendienst > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 14 12:10:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZqc-000132-Qt; Wed, 14 Sep 2005 12:10:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZqZ-00010o-Au for enum@megatron.ietf.org; Wed, 14 Sep 2005 12:10:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19311 for ; Wed, 14 Sep 2005 12:10:52 -0400 (EDT) Received: from cellgate.btcellnet.net ([158.230.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFZvB-000699-6S for enum@ietf.org; Wed, 14 Sep 2005 12:15:42 -0400 Received: from ukbrwmsw05.uk.pri.o2.com by cellgate.btcellnet.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 14 Sep 2005 16:59:32 +0100 Received: from uksthims002.uk.pri.o2.com (uksthims002.uk.pri.o2.com) by uksthmsw005.uk.pri.o2.com (Clearswift SMTPRS 5.0.9) with ESMTP id for ; Wed, 14 Sep 2005 17:10:41 +0100 Received: from UKSTHMSX012.uk.pri.o2.com ([172.17.61.187]) by uksthims002.uk.pri.o2.com with Microsoft SMTPSVC (6.0.3790.1830); Wed, 14 Sep 2005 17:10:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Date: Wed, 14 Sep 2005 17:10:38 +0100 Message-ID: <0CD3FFEAEC982F489F872AB8DA32D62401F7385B@Uksthmsx012.uk.pri.o2.com> Thread-Topic: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Thread-Index: AcW1U6CnJhXCyiJuTgWuwKa6EgyHTwDGAHGzADZTs3A= From: "Fullbrook Kim \(UK\)" To: X-OriginalArrivalTime: 14 Sep 2005 16:10:38.0424 (UTC) FILETIME=[D8B0C580:01C5B946] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard Stastny wrote: >> 1. The minimum requirements and rules for IP Interconnect=20 >> based on routing via SIP URIs have to be established globally.=20 >> Note: if the minimum requirements are fullfilled (e.g. TLS),=20 >> the calling server must be able to resolve the SIP AoR to the=20 >> IP-address of the called server and also to be able to contact=20 >> the called server. The called user MAY have additional=20 >> agreements in his profile, e.g. to reject all anonymous calls. This is not an appropriate reflection of the minimum requirements. The stat= ement above assumes every SIP caller will make a direct connection to the d= estination network which is a false assumption. It's not realistic to expec= t every SIP network in the world to interconnect directly with every other. If a customer of Network A calls a customer of Network B, it might well be = the case that there is no direct Interconnection agreement between A and B,= but both A and B have interworking agreements with Carrier K. So in this e= xample the call is routed from A to K to B. ENUM as described in RFC 3761 for SIP calls does NOT describe routing. It p= rovides the URI for the Destination.=20 The gap is that we need a way of specifying call routing in "Carrier DNS". = Being careful about terminology this is not something that ENUM would do. Regards, Kim Fullbrook O2 UK -----Original Message----- =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 This electronic message contains information from O2 which may be privilege= d or confidential. The information is intended to be for the use of the ind= ividual(s) or entity named above. If you are not the intended recipient be = aware that any disclosure, copying distribution or use of the contents of t= his information is prohibited. If you have received this electronic message= in error, please notify us by telephone or email (to the numbers or addres= s above) immediately. =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 From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Sta= stny Richard Sent: 13 September 2005 15:01 To: Richard Shockey; tispan_wg4@list.etsi.org Cc: enum@ietf.org; "Patrik F=E4ltstr=F6m" Subject: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Hi all, =20 since we still do not have a new ENUM charter and time is running out, (ADs missing in non-action) I want to throw in some stones in the pond to stir up the Carrier ENUM requirements discussion: =20 =20 ENUM (Carrier and User ENUM) is an applet to IP -Interconnect. To be able t= o use an applet you need to be able to use the applications the applet is r= unning on. You cannot use e.g. an applet integrating your Skype buddies in MS Outlook = without having Skype and MS Outlook installed and running on your laptop. Same with ENUM: ENUM is useless without the possibility to enter an E.164 number in DNS and= the capability to use the resulting URI, e.g. in case of real-time communi= cations a SIP URI.=20 =20 For further background and rationale see: http://voipandenum.blogspot.com/2005/09/carrier-enum-is-applet-of-ip.html =20 Executive summary: =20 The basic requirement for Carrier ENUM to work is a global IP Interconnect = (VoIP peering) solution for "Carriers". To summarize: 1. The minimum requirements and rules for IP Interconnect based on routing = via SIP URIs have to be established globally. Note: if the minimum requirem= ents are fullfilled (e.g. TLS), the calling server must be able to resolve = the SIP AoR to the IP-address of the called server and also to be able to c= ontact the called server. The called user MAY have additional agreements in= his profile, e.g. to reject all anonymous calls. 2. Only if this is in place, Carrier ENUM makes sense on a global scale. Th= is does not imply that Carrier ENUM may not be trialed and used commerciall= y earlier, but only in a limited way. 3. Carrier ENUM must be available on a global scale. This implies that Carr= ier MUST be available for any carrier who wants to use it. This implies tha= t although it is a national matter how to implement Carrier ENUM in detail = and to define e.g. the entity operating the Tier 1, there should be no opt-= out possible (this is IMHO the most problematic point). 4. It is a national matter to define who is entitled to enter which numbers= and the corresponding NAPTRs in "Carrier" ENUM, e.g. an entity is only allowed to enter numbers in Carrier ENUM if it is ho= sting the final destination of the E.164 number on behalf of the end-user (= that means no signalling transit is allowed) or if it is providing a direct gateway/SBC to the own destination network h= osting the E.164 number on a private IP-based network (NGN) or on the PSTN.= National number portability issues have also be taken into account here. If an entity is assigned an E.164 number directly (e.g. an 800 number or a = corporate number), and if the entity is running the SIP server on its own, = it may also be allowed to enter this number and the NAPTRs in Carrier ENUM. 4. There is no user opt-in or opt-out possible in Carrier ENUM. The entitie= s allowed to enter NAPTRs in Carrier ENUM MUST be aware that the data in Ca= rrier ENUM is public, therefor end-user privacy MUST be assured. This impli= es that either the E.164 number or a random number (userid) is used in the = user-part of the SIP URI. The mapping from this number to the end-user iden= tity used further (even if it is a public identity) MUST be done within the= end-systems. 5. All SIP URIs entered in Carrier ENUM must be reachable via the minimum r= equirements of IP Interconnect as defined in 1.=20 =20 Richard =20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 14 12:37:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFaG3-00088m-IE; Wed, 14 Sep 2005 12:37:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFaG1-00088h-2D for enum@megatron.ietf.org; Wed, 14 Sep 2005 12:37:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20318 for ; Wed, 14 Sep 2005 12:37:10 -0400 (EDT) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFaKc-0006oK-Qf for enum@ietf.org; Wed, 14 Sep 2005 12:42:00 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 38A926EDB1; Wed, 14 Sep 2005 17:38:16 +0100 (BST) In-Reply-To: <0CD3FFEAEC982F489F872AB8DA32D62401F7385B@Uksthmsx012.uk.pri.o2.com> References: <0CD3FFEAEC982F489F872AB8DA32D62401F7385B@Uksthmsx012.uk.pri.o2.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <9742EA48-5C4E-4566-8EE9-62294AC39D0C@insensate.co.uk> Content-Transfer-Encoding: quoted-printable From: lconroy Subject: Re: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Date: Wed, 14 Sep 2005 17:36:30 +0100 To: "Fullbrook Kim (UK)" , Stastny Richard X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: quoted-printable Cc: "'enum@ietf.org' ENUM" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Richard, Kim, folks, I understood Richard's R4 to suggest that who gets to populate a =20 number is a national matter, and that, FOR EXAMPLE, this policy might =20= be to permit only the entity hosting the final destination number to =20 populate the equivalent ENUM zone. Your Mileage May Vary. Re. R1 - IIUC, at the VoIPPEER and ENUM meetings in Gay Paree,there =20 was a general agreement that Carrier ENUM meant, in the IETF context, =20= that the entries in such a system were URIs that were able to be =20 queried and any resulting URI could be resolved via the Internet. =20 Whether or not the SBC/SIP Proxy responsible for the domainpart in a =20 SIP URI actually responded to an incoming request was another matter. I took this to mean that an Carrier ENUM-aware calling UAS should be =20 able to resolve the destination SIP proxy's IP address. Whether or =20 not that destination SIP proxy responded is another matter. If a Carrier chooses to use some private DNS system to map from a =20 destination domainpart to a different intermediate system (using, for =20= example, private SRV records or other schemes) is it's own business - =20= this has nothing to do with the globally accessible Carrier ENUM as =20 envisaged in the IETF. I must be missing something, so clarification required, please. all the best, Lawrence On 14 Sep 2005, at 17:10, Fullbrook Kim (UK) wrote: > Richard Stastny wrote: > > >>> 1. The minimum requirements and rules for IP Interconnect >>> based on routing via SIP URIs have to be established globally. >>> Note: if the minimum requirements are fullfilled (e.g. TLS), >>> the calling server must be able to resolve the SIP AoR to the >>> IP-address of the called server and also to be able to contact >>> the called server. The called user MAY have additional >>> agreements in his profile, e.g. to reject all anonymous calls. >>> > > This is not an appropriate reflection of the minimum requirements. =20 > The statement above assumes every SIP caller will make a direct =20 > connection to the destination network which is a false assumption. =20 > It's not realistic to expect every SIP network in the world to =20 > interconnect directly with every other. > > If a customer of Network A calls a customer of Network B, it might =20 > well be the case that there is no direct Interconnection agreement =20 > between A and B, but both A and B have interworking agreements with =20= > Carrier K. So in this example the call is routed from A to K to B. > > ENUM as described in RFC 3761 for SIP calls does NOT describe =20 > routing. It provides the URI for the Destination. > > The gap is that we need a way of specifying call routing in =20 > "Carrier DNS". Being careful about terminology this is not =20 > something that ENUM would do. > > Regards, > Kim Fullbrook > O2 UK > > -----Original Message----- > > =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 > This electronic message contains information from O2 which may be =20 > privileged or confidential. The information is intended to be for =20 > the use of the individual(s) or entity named above. If you are not =20 > the intended recipient be aware that any disclosure, copying =20 > distribution or use of the contents of this information is =20 > prohibited. If you have received this electronic message in error, =20 > please notify us by telephone or email (to the numbers or address =20 > above) immediately. > =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 > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On =20 > Behalf Of Stastny Richard > Sent: 13 September 2005 15:01 > To: Richard Shockey; tispan_wg4@list.etsi.org > Cc: enum@ietf.org; "Patrik F=E4ltstr=F6m" > Subject: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) > > > Hi all, > > since we still do not have a new ENUM charter and time is running out, > (ADs missing in non-action) > I want to throw in some stones in the pond to stir up the > Carrier ENUM requirements discussion: > > > ENUM (Carrier and User ENUM) is an applet to IP -Interconnect. To =20 > be able to use an applet you need to be able to use the =20 > applications the applet is running on. > > You cannot use e.g. an applet integrating your Skype buddies in MS =20 > Outlook without having Skype and MS Outlook installed and running =20 > on your laptop. > > Same with ENUM: > > ENUM is useless without the possibility to enter an E.164 number in =20= > DNS and the capability to use the resulting URI, e.g. in case of =20 > real-time communications a SIP URI. > > For further background and rationale see: > http://voipandenum.blogspot.com/2005/09/carrier-enum-is-applet-of-=20 > ip.html > > Executive summary: > > The basic requirement for Carrier ENUM to work is a global IP =20 > Interconnect (VoIP peering) solution for "Carriers". > > To summarize: > > 1. The minimum requirements and rules for IP Interconnect based on =20 > routing via SIP URIs have to be established globally. Note: if the =20 > minimum requirements are fullfilled (e.g. TLS), the calling server =20 > must be able to resolve the SIP AoR to the IP-address of the called =20= > server and also to be able to contact the called server. The called =20= > user MAY have additional agreements in his profile, e.g. to reject =20 > all anonymous calls. > > 2. Only if this is in place, Carrier ENUM makes sense on a global =20 > scale. This does not imply that Carrier ENUM may not be trialed and =20= > used commercially earlier, but only in a limited way. > > 3. Carrier ENUM must be available on a global scale. This implies =20 > that Carrier MUST be available for any carrier who wants to use it. =20= > This implies that although it is a national matter how to implement =20= > Carrier ENUM in detail and to define e.g. the entity operating the =20 > Tier 1, there should be no opt-out possible (this is IMHO the most =20 > problematic point). > > 4. It is a national matter to define who is entitled to enter which =20= > numbers and the corresponding NAPTRs in "Carrier" ENUM, > > e.g. an entity is only allowed to enter numbers in Carrier ENUM if =20 > it is hosting the final destination of the E.164 number on behalf =20 > of the end-user (that means no signalling transit is allowed) > > or if it is providing a direct gateway/SBC to the own destination =20 > network hosting the E.164 number on a private IP-based network =20 > (NGN) or on the PSTN. National number portability issues have also =20 > be taken into account here. > > If an entity is assigned an E.164 number directly (e.g. an 800 =20 > number or a corporate number), and if the entity is running the SIP =20= > server on its own, it may also be allowed to enter this number and =20 > the NAPTRs in Carrier ENUM. > > 4. There is no user opt-in or opt-out possible in Carrier ENUM. The =20= > entities allowed to enter NAPTRs in Carrier ENUM MUST be aware that =20= > the data in Carrier ENUM is public, therefor end-user privacy MUST =20 > be assured. This implies that either the E.164 number or a random =20 > number (userid) is used in the user-part of the SIP URI. The =20 > mapping from this number to the end-user identity used further =20 > (even if it is a public identity) MUST be done within the end-systems. > > 5. All SIP URIs entered in Carrier ENUM must be reachable via the =20 > minimum requirements of IP Interconnect as defined in 1. > > Richard > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 14 13:55:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFbTO-0001xD-Bk; Wed, 14 Sep 2005 13:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFbTM-0001vE-3U for enum@megatron.ietf.org; Wed, 14 Sep 2005 13:55:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23702 for ; Wed, 14 Sep 2005 13:55:02 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFbXx-0000JX-R9 for enum@ietf.org; Wed, 14 Sep 2005 13:59:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Date: Wed, 14 Sep 2005 19:58:31 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4511@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Thread-Index: AcW1U6CnJhXCyiJuTgWuwKa6EgyHTwDGAHGzADZTs3AAAqER5Q== From: "Stastny Richard" To: "Fullbrook Kim \(UK\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Kim wrote: >> 1. The minimum requirements and rules for IP Interconnect >> based on routing via SIP URIs have to be established globally. >> Note: if the minimum requirements are fullfilled (e.g. TLS), >> the calling server must be able to resolve the SIP AoR to the >> IP-address of the called server and also to be able to contact >> the called server. The called user MAY have additional >> agreements in his profile, e.g. to reject all anonymous calls. >This is not an appropriate reflection of the minimum requirements. The = statement above assumes every SIP caller will make a >direct connection = to the destination network which is a false assumption. It's not = realistic to expect every SIP network in the >world to interconnect = directly with every other. Note: this requirement has nothing to do with ENUM. A originating user = is submitting a public user identity and this public user identity need = to be resolved. The basic problem in your reply is that you talk about a SIP "network". = I am talking here only about signalling (L5).=20 A public user identity is an AoR (SIP URI) and must resolve into an IP = address. If a user wnats to contact sip:kim@o2.net, o2.net is looked up and should bring you back some SRV records. If this = srv records are pointing to gw17.grx.net and there is a SBC accepting the call and delivering via some internal magic = finally to O2, fine. But you cannot provide a customer with a PUBLIC user identity like = sip:kim@o2.net;context=3D3GPPnetworksonly >If a customer of Network A calls a customer of Network B, it might well = be the case that there is no direct Interconnection >agreement between A = and B, but both A and B have interworking agreements with Carrier K. So = in this example the call is >routed from A to K to B. Again, what is a Network with big N on the Internet? As you say, it is = not possible to have "Interconnect" (peering?)=20 agreements between all Carriers. So you assume that there will be = signalling transit providers as proposed in UK ;-) e.g. of course C&W and BT. And then you also may have Forward = Routing for ported numbers. The PSTN operators (including the mobile operators) simply want to build = their stovepipe architecture on top of the=20 the Internet. This does not prevent the real traffic on L3 to be = transited via K. >ENUM as described in RFC 3761 for SIP calls does NOT describe routing. = It provides the URI for the Destination. Yes: so will Carrier ENUM >The gap is that we need a way of specifying call routing in "Carrier = DNS". Being careful about terminology this is not >something that ENUM = would do. No, you missed IETF Paris, but you should at least read the minutes. = Call routing is done via SIP URIs and this problem will be (hopefully) handled by voipeer, not in ENUM WG If this is not provided, Carrier ENUM does not work. That why I did this = post and said Carreir ENUM is an applet to the underlying peering. Richard Regards, Kim Fullbrook O2 UK -----Original Message----- =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 This electronic message contains information from O2 which may be = privileged or confidential. The information is intended to be for the = use of the individual(s) or entity named above. If you are not the = intended recipient be aware that any disclosure, copying distribution or = use of the contents of this information is prohibited. If you have = received this electronic message in error, please notify us by telephone = or email (to the numbers or address above) immediately. =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 From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = Stastny Richard Sent: 13 September 2005 15:01 To: Richard Shockey; tispan_wg4@list.etsi.org Cc: enum@ietf.org; "Patrik F=E4ltstr=F6m" Subject: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Hi all, since we still do not have a new ENUM charter and time is running out, (ADs missing in non-action) I want to throw in some stones in the pond to stir up the Carrier ENUM requirements discussion: ENUM (Carrier and User ENUM) is an applet to IP -Interconnect. To be = able to use an applet you need to be able to use the applications the = applet is running on. You cannot use e.g. an applet integrating your Skype buddies in MS = Outlook without having Skype and MS Outlook installed and running on = your laptop. Same with ENUM: ENUM is useless without the possibility to enter an E.164 number in DNS = and the capability to use the resulting URI, e.g. in case of real-time = communications a SIP URI. For further background and rationale see: http://voipandenum.blogspot.com/2005/09/carrier-enum-is-applet-of-ip.html= Executive summary: The basic requirement for Carrier ENUM to work is a global IP = Interconnect (VoIP peering) solution for "Carriers". To summarize: 1. The minimum requirements and rules for IP Interconnect based on = routing via SIP URIs have to be established globally. Note: if the = minimum requirements are fullfilled (e.g. TLS), the calling server must = be able to resolve the SIP AoR to the IP-address of the called server = and also to be able to contact the called server. The called user MAY = have additional agreements in his profile, e.g. to reject all anonymous = calls. 2. Only if this is in place, Carrier ENUM makes sense on a global scale. = This does not imply that Carrier ENUM may not be trialed and used = commercially earlier, but only in a limited way. 3. Carrier ENUM must be available on a global scale. This implies that = Carrier MUST be available for any carrier who wants to use it. This = implies that although it is a national matter how to implement Carrier = ENUM in detail and to define e.g. the entity operating the Tier 1, there = should be no opt-out possible (this is IMHO the most problematic point). 4. It is a national matter to define who is entitled to enter which = numbers and the corresponding NAPTRs in "Carrier" ENUM, e.g. an entity is only allowed to enter numbers in Carrier ENUM if it is = hosting the final destination of the E.164 number on behalf of the = end-user (that means no signalling transit is allowed) or if it is providing a direct gateway/SBC to the own destination = network hosting the E.164 number on a private IP-based network (NGN) or = on the PSTN. National number portability issues have also be taken into = account here. If an entity is assigned an E.164 number directly (e.g. an 800 number or = a corporate number), and if the entity is running the SIP server on its = own, it may also be allowed to enter this number and the NAPTRs in = Carrier ENUM. 4. There is no user opt-in or opt-out possible in Carrier ENUM. The = entities allowed to enter NAPTRs in Carrier ENUM MUST be aware that the = data in Carrier ENUM is public, therefor end-user privacy MUST be = assured. This implies that either the E.164 number or a random number = (userid) is used in the user-part of the SIP URI. The mapping from this = number to the end-user identity used further (even if it is a public = identity) MUST be done within the end-systems. 5. All SIP URIs entered in Carrier ENUM must be reachable via the = minimum requirements of IP Interconnect as defined in 1. Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 14 14:06:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFbdx-0003xX-3P; Wed, 14 Sep 2005 14:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFbdv-0003xS-OV for enum@megatron.ietf.org; Wed, 14 Sep 2005 14:05:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23987 for ; Wed, 14 Sep 2005 14:05:58 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFbiZ-0000We-GN for enum@ietf.org; Wed, 14 Sep 2005 14:10:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Date: Wed, 14 Sep 2005 20:09:34 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4512@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Thread-Index: AcW5SwF8kdDub3FSQ9SyvPTau4cIswACxOyg From: "Stastny Richard" To: "lconroy" , "Fullbrook Kim \(UK\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Lawrence, =20 in principle yes, a minor point: =20 >I took this to mean that an Carrier ENUM-aware calling UAS should be=20 >able to resolve the destination SIP proxy's IP address. Whether or=20 >not that destination SIP proxy responded is another matter. This is correct what was said in Paris. I am only the opinion that this could be the case eventually in User ENUM (and laos here it is not a=20 good idea) but is would defineitely not work very well in Carrier ENUM, because then this would be more like a lottery. If a carreir is queriying ENUM he would expect that normally the call is at least accepted by the server. If you are a carrier and get in 50% a rejection,=20 such as "I do not like you at all. 1. what are you doing instead 2. why should you ask in the first place such a bad system This does of course not imply that the call may not be rejected because eg the user has set up a profile lto autoreject calls e.g. from insensate.co.uk ;-) So I proposed that the requiremnets I-D of voipeer (not enum) should state what the minimum requirements are to be accepted without a L7 peering agreement (e.g. a domain certificate, or = whatever.) -richard ________________________________ Von: lconroy [mailto:lconroy@insensate.co.uk] Gesendet: Mi 14.09.2005 18:36 An: Fullbrook Kim (UK); Stastny Richard Cc: 'enum@ietf.org' ENUM Betreff: Re: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) Hi Richard, Kim, folks, I understood Richard's R4 to suggest that who gets to populate a=20 number is a national matter, and that, FOR EXAMPLE, this policy might=20 be to permit only the entity hosting the final destination number to=20 populate the equivalent ENUM zone. Your Mileage May Vary. Re. R1 - IIUC, at the VoIPPEER and ENUM meetings in Gay Paree,there=20 was a general agreement that Carrier ENUM meant, in the IETF context,=20 that the entries in such a system were URIs that were able to be=20 queried and any resulting URI could be resolved via the Internet.=20 Whether or not the SBC/SIP Proxy responsible for the domainpart in a=20 SIP URI actually responded to an incoming request was another matter. I took this to mean that an Carrier ENUM-aware calling UAS should be=20 able to resolve the destination SIP proxy's IP address. Whether or=20 not that destination SIP proxy responded is another matter. If a Carrier chooses to use some private DNS system to map from a=20 destination domainpart to a different intermediate system (using, for=20 example, private SRV records or other schemes) is it's own business -=20 this has nothing to do with the globally accessible Carrier ENUM as=20 envisaged in the IETF. I must be missing something, so clarification required, please. all the best, Lawrence On 14 Sep 2005, at 17:10, Fullbrook Kim (UK) wrote: > Richard Stastny wrote: > > >>> 1. The minimum requirements and rules for IP Interconnect >>> based on routing via SIP URIs have to be established globally. >>> Note: if the minimum requirements are fullfilled (e.g. TLS), >>> the calling server must be able to resolve the SIP AoR to the >>> IP-address of the called server and also to be able to contact >>> the called server. The called user MAY have additional >>> agreements in his profile, e.g. to reject all anonymous calls. >>> > > This is not an appropriate reflection of the minimum requirements.=20 > The statement above assumes every SIP caller will make a direct=20 > connection to the destination network which is a false assumption.=20 > It's not realistic to expect every SIP network in the world to=20 > interconnect directly with every other. > > If a customer of Network A calls a customer of Network B, it might=20 > well be the case that there is no direct Interconnection agreement=20 > between A and B, but both A and B have interworking agreements with=20 > Carrier K. So in this example the call is routed from A to K to B. > > ENUM as described in RFC 3761 for SIP calls does NOT describe=20 > routing. It provides the URI for the Destination. > > The gap is that we need a way of specifying call routing in=20 > "Carrier DNS". Being careful about terminology this is not=20 > something that ENUM would do. > > Regards, > Kim Fullbrook > O2 UK > > -----Original Message----- > > = =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 > This electronic message contains information from O2 which may be=20 > privileged or confidential. The information is intended to be for=20 > the use of the individual(s) or entity named above. If you are not=20 > the intended recipient be aware that any disclosure, copying=20 > distribution or use of the contents of this information is=20 > prohibited. If you have received this electronic message in error,=20 > please notify us by telephone or email (to the numbers or address=20 > above) immediately. > = =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 > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Stastny Richard > Sent: 13 September 2005 15:01 > To: Richard Shockey; tispan_wg4@list.etsi.org > Cc: enum@ietf.org; "Patrik F=E4ltstr=F6m" > Subject: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect) > > > Hi all, > > since we still do not have a new ENUM charter and time is running out, > (ADs missing in non-action) > I want to throw in some stones in the pond to stir up the > Carrier ENUM requirements discussion: > > > ENUM (Carrier and User ENUM) is an applet to IP -Interconnect. To=20 > be able to use an applet you need to be able to use the=20 > applications the applet is running on. > > You cannot use e.g. an applet integrating your Skype buddies in MS=20 > Outlook without having Skype and MS Outlook installed and running=20 > on your laptop. > > Same with ENUM: > > ENUM is useless without the possibility to enter an E.164 number in=20 > DNS and the capability to use the resulting URI, e.g. in case of=20 > real-time communications a SIP URI. > > For further background and rationale see: > http://voipandenum.blogspot.com/2005/09/carrier-enum-is-applet-of- > ip.html > > Executive summary: > > The basic requirement for Carrier ENUM to work is a global IP=20 > Interconnect (VoIP peering) solution for "Carriers". > > To summarize: > > 1. The minimum requirements and rules for IP Interconnect based on=20 > routing via SIP URIs have to be established globally. Note: if the=20 > minimum requirements are fullfilled (e.g. TLS), the calling server=20 > must be able to resolve the SIP AoR to the IP-address of the called=20 > server and also to be able to contact the called server. The called=20 > user MAY have additional agreements in his profile, e.g. to reject=20 > all anonymous calls. > > 2. Only if this is in place, Carrier ENUM makes sense on a global=20 > scale. This does not imply that Carrier ENUM may not be trialed and=20 > used commercially earlier, but only in a limited way. > > 3. Carrier ENUM must be available on a global scale. This implies=20 > that Carrier MUST be available for any carrier who wants to use it.=20 > This implies that although it is a national matter how to implement=20 > Carrier ENUM in detail and to define e.g. the entity operating the=20 > Tier 1, there should be no opt-out possible (this is IMHO the most=20 > problematic point). > > 4. It is a national matter to define who is entitled to enter which=20 > numbers and the corresponding NAPTRs in "Carrier" ENUM, > > e.g. an entity is only allowed to enter numbers in Carrier ENUM if=20 > it is hosting the final destination of the E.164 number on behalf=20 > of the end-user (that means no signalling transit is allowed) > > or if it is providing a direct gateway/SBC to the own destination=20 > network hosting the E.164 number on a private IP-based network=20 > (NGN) or on the PSTN. National number portability issues have also=20 > be taken into account here. > > If an entity is assigned an E.164 number directly (e.g. an 800=20 > number or a corporate number), and if the entity is running the SIP=20 > server on its own, it may also be allowed to enter this number and=20 > the NAPTRs in Carrier ENUM. > > 4. There is no user opt-in or opt-out possible in Carrier ENUM. The=20 > entities allowed to enter NAPTRs in Carrier ENUM MUST be aware that=20 > the data in Carrier ENUM is public, therefor end-user privacy MUST=20 > be assured. This implies that either the E.164 number or a random=20 > number (userid) is used in the user-part of the SIP URI. The=20 > mapping from this number to the end-user identity used further=20 > (even if it is a public identity) MUST be done within the end-systems. > > 5. All SIP URIs entered in Carrier ENUM must be reachable via the=20 > minimum requirements of IP Interconnect as defined in 1. > > Richard > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 15 12:39:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFwm9-0001lq-6L; Thu, 15 Sep 2005 12:39:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFwm7-0001li-8k for enum@megatron.ietf.org; Thu, 15 Sep 2005 12:39:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20857 for ; Thu, 15 Sep 2005 12:39:48 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFwqu-0005xk-CK for enum@ietf.org; Thu, 15 Sep 2005 12:44:51 -0400 Received: from [10.31.13.196] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8FGdXNG009543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2005 09:39:35 -0700 Message-ID: <4329A396.2070905@shockey.us> Date: Thu, 15 Sep 2005 12:38:46 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Peterson, Jon" , Allison Mankin Subject: [Enum] ENUM Working Group Last call on IANA Registration for Enumservice Voice X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This draft is sufficiently easy to understand that this can proceed immediately to last call as we discussed in Paris. I've noted no substantive issues with it. Title : IANA Registration for Enumservice Voice Author(s) : R. Brandner Filename : draft-ietf-enum-voice-00.txt Pages : 13 Date : 2005-9-12 This document registers the ENUMservice ^voice^ (which has a defined sub-type ^tel^), as per the IANA registration process defined in the ENUM specification RFC3761. This service indicates that the contact held in the generated URI can be used to initiate an interactive voice (audio) call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-voice-00.txt The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for 2 weeks or so from today Sept 15 until at least Oct 3 though we can modify that if new issues come up. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)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 enum-bounces@ietf.org Thu Sep 15 12:42:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFwoT-00028J-Ck; Thu, 15 Sep 2005 12:42:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFwoR-00027H-Dm for enum@megatron.ietf.org; Thu, 15 Sep 2005 12:42:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20959 for ; Thu, 15 Sep 2005 12:42:12 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFwtF-00062J-Hd for enum@ietf.org; Thu, 15 Sep 2005 12:47:15 -0400 Received: from [10.31.13.196] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8FGgBsA009761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2005 09:42:12 -0700 Message-ID: <4329A433.2060103@shockey.us> Date: Thu, 15 Sep 2005 12:41:23 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Peterson, Jon" , Allison Mankin Subject: [Enum] ENUM Working Group Last call on IRIS EREG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org We discussed the need to move this document forward in Paris. Though some have noted they would like enhancements to the protocol there has been consensus that this version is sufficiently mature to bring forward and there will almost certainly be enhanced versions in the future. Title: An ENUM Registry Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-ietf-enum-iris-ereg-02.txt Pages : 57 Date : 2005-9-12 This document describes an IRIS registry schema for registered ENUM information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-iris-ereg-02.txt The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for 2 weeks or so from today Sept 15 until at least Oct 3 though we can modify that if new issues come up. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)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 enum-bounces@ietf.org Thu Sep 15 13:45:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxnx-0001e6-Km; Thu, 15 Sep 2005 13:45:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxnv-0001dX-Rx for enum@megatron.ietf.org; Thu, 15 Sep 2005 13:45:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23425 for ; Thu, 15 Sep 2005 13:45:43 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFxsi-0007Zx-HJ for enum@ietf.org; Thu, 15 Sep 2005 13:50:45 -0400 Received: from [10.31.13.196] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8FHk9Tr016305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2005 10:46:10 -0700 Message-ID: <4329B332.3080600@shockey.us> Date: Thu, 15 Sep 2005 13:45:22 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org, "Lawrence Conroy (Lawrence Conroy)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] A note for the Implementers Draft X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Larry did you make any note of the use of RFC 2671 to permit the use in DNS of larger than 512 Octets in the UDP response. I was not aware of this ..we have always speculated that some NAPTR responses might exceed 512 and throw the transaction into TCP. Is this something that all ENUM requestors and responders MUST be able to support? -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)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 enum-bounces@ietf.org Fri Sep 16 06:15:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGDFL-0007Me-Ph; Fri, 16 Sep 2005 06:15:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGDFI-0007Ls-Vs for enum@megatron.ietf.org; Fri, 16 Sep 2005 06:15:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06788 for ; Fri, 16 Sep 2005 06:15:01 -0400 (EDT) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGDKH-00013B-7V for enum@ietf.org; Fri, 16 Sep 2005 06:20:14 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 71A006EEFD; Fri, 16 Sep 2005 11:16:05 +0100 (BST) In-Reply-To: <4329B332.3080600@shockey.us> References: <4329B332.3080600@shockey.us> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <95A15E8A-6644-4D5C-B2C8-6D7FEF8A8BC3@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] A note for the Implementers Draft Date: Fri, 16 Sep 2005 11:14:25 +0100 To: Richard Shockey X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "Lawrence Conroy \(Lawrence Conroy\)" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Richard, folks, Lawrence here. Experiences has had a description of the size issue, and several recommendations on support for TCP and EDNS0. It's still there, as section 6. NOTE WELL: The conclusions in the existing section 6 are that ENUM-involve clients and servers, plus recursive resolvers AND middle boxes, SHOULD support TCP transport for requests/responses and UDP requests/ responses with EDNS0 set. Personally, I would be happy to make this a MUST (at least for EDNS0) for all DNS entities that are used for ENUM queries. IMHO, everyone will need EDNS0 if/when we ever get DNSSEC deployed. Do any of the group have comments on this? all the best, Lawrence On 15 Sep 2005, at 18:45, Richard Shockey wrote: > Larry did you make any note of the use of RFC 2671 to permit the > use in DNS of larger than 512 Octets in the UDP response. > > I was not aware of this ..we have always speculated that some NAPTR > responses might exceed 512 and throw the transaction into TCP. > > Is this something that all ENUM requestors and responders MUST be > able to support? > > -- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 16 11:16:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHxI-0000KC-00; Fri, 16 Sep 2005 11:16:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHwx-0000GZ-P7 for enum@megatron.ietf.org; Fri, 16 Sep 2005 11:16:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22771 for ; Fri, 16 Sep 2005 11:16:25 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGI1x-0000Ur-Lu for enum@ietf.org; Fri, 16 Sep 2005 11:21:40 -0400 Received: from [10.31.32.93] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8GFGvUW018001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 Sep 2005 08:16:58 -0700 Message-ID: <432AE1BA.4050608@shockey.us> Date: Fri, 16 Sep 2005 11:16:10 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.9 (+) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: [Enum] [Fwd: Possible new Real-Time Applications and Infrastucture (RAI) Area] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0361292571==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0361292571== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
FYI ... for those of you who do not get the Announce List

-------- Original Message --------
Subject: Possible new Real-Time Applications and Infrastucture (RAI) Area
Date: Fri, 16 Sep 2005 09:14:15 -0400
From: IETF Chair <chair@ietf.org>
To: IETF Announcement list <ietf-announce@ietf.org> 


As mentioned in the recent call for NomCom volunteers, the IESG
is considering the creation of a new area, as set out below.  We 
solicit feedback from the community on the scope of this potential 
new area as well as the impact on the IETF's infrastructure and 
efficiency of setting up this new area. We need to decide quite
quickly, to fit the NomCom schedule.

Please write to iesg@ietf.org, or to ietf@ietf.org if you want
community discussion of your comment. (There's no need
to write to both!)

   Brian Carpenter

-----------------

Real-Time Applications and Infrastucture (RAI) Area Description

The Real-Time Applications and Infrastructure Area develops protocols
and architectures for delay-sensitive interpersonal communications. Work
in this area serves an emerging industry whose applications and services
include voice and video over IP, instant messaging and presence. These
applications and services are "real-time" in the sense that delay
impedes human participation in the associated systems.

The RAI Area is seeded with existing working groups from the Transport
and Applications Area: SIP, SIPPING, XCON, SIMPLE, GEOPRIV, ECRIT, ENUM,
IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, and SIGTRAN.  A good rule of
thumb for the incorporation of new work into RAI, as opposed to
Transport or Applications, is that the work in question has major goals
supporting instant interpersonal communication or its infrastructure.
For example, they can range from applications to help users make
decisions about how best to communicate using presence services, to
session signaling protocols and emergency call routing solutions, to
work on the "layer five" issues for Internet telephony.

Like all areas of the IETF, the RAI Area draws on the work of numerous
other areas, and as such there can be no neat mathematical boundaries
delineating RAI's work from the rest of the IETF. The new area will
allow an existing community within the IETF to solidify its vision and
to benefit from increased institutional support.

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce



-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--===============0361292571== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0361292571==-- From enum-bounces@ietf.org Sat Sep 17 17:52:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGkbw-0003Gn-IV; Sat, 17 Sep 2005 17:52:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGkbu-0003Gf-Fg for enum@megatron.ietf.org; Sat, 17 Sep 2005 17:52:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05171 for ; Sat, 17 Sep 2005 17:52:35 -0400 (EDT) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGkhB-0001Bw-5w for enum@ietf.org; Sat, 17 Sep 2005 17:58:06 -0400 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j8HLqEMN002475; Sat, 17 Sep 2005 22:52:16 +0100 (BST) In-Reply-To: <95A15E8A-6644-4D5C-B2C8-6D7FEF8A8BC3@insensate.co.uk> References: <4329B332.3080600@shockey.us> <95A15E8A-6644-4D5C-B2C8-6D7FEF8A8BC3@insensate.co.uk> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] A note for the Implementers Draft Date: Sat, 17 Sep 2005 22:52:07 +0100 To: lconroy X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "Lawrence Conroy \(Lawrence Conroy\)" , Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Sep 16, 2005, at 11:14, lconroy wrote: > Personally, I would be happy to make this a MUST (at least for > EDNS0) for all DNS entities that are used for ENUM queries. I agree. The draft should recommend that clients use EDNS0 whenever possible. This is a far better option than having truncated 512-byte UDP responses followed by TCP retries. Any name server that gets lots of queries -- hundreds per second or more -- would not be happy to keep a TCP protocol control block for each of these "transactions" if they went over TCP. > IMHO, everyone will need EDNS0 if/when we ever get DNSSEC deployed. This isn't a matter of opinion Lawrence. It's a matter of fact. Apart from explicitly querying for DNSSEC-related RRtypes, DNS clients -- resolving name servers or stub resolvers -- will only get those RRtypes if they indicate that they are DNSSEC-aware. This is done by setting the DO bit in the EDNS0 header: see RFC3225. So a client will not get signed responses without EDNS0. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Sep 17 20:48:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGnLj-0007Ij-Mc; Sat, 17 Sep 2005 20:48:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGnLh-0007IY-Ce for enum@megatron.ietf.org; Sat, 17 Sep 2005 20:48:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12239 for ; Sat, 17 Sep 2005 20:48:03 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGnR0-0004KP-3S for enum@ietf.org; Sat, 17 Sep 2005 20:53:35 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8I0m6BE029211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Sep 2005 17:48:09 -0700 Message-ID: <432CB918.6050304@shockey.us> Date: Sat, 17 Sep 2005 20:47:20 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Reid Subject: Re: [Enum] A note for the Implementers Draft References: <4329B332.3080600@shockey.us> <95A15E8A-6644-4D5C-B2C8-6D7FEF8A8BC3@insensate.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, lconroy , "Lawrence Conroy \(Lawrence Conroy\)" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jim Reid wrote: > On Sep 16, 2005, at 11:14, lconroy wrote: > >> Personally, I would be happy to make this a MUST (at least for >> EDNS0) for all DNS entities that are used for ENUM queries. > > > I agree. The draft should recommend that clients use EDNS0 whenever > possible. This is a far better option than having truncated 512-byte > UDP responses followed by TCP retries. Any name server that gets lots > of queries -- hundreds per second or more -- would not be happy to > keep a TCP protocol control block for each of these "transactions" > if they went over TCP. > >> IMHO, everyone will need EDNS0 if/when we ever get DNSSEC deployed. > > > This isn't a matter of opinion Lawrence. It's a matter of fact. Apart > from explicitly querying for DNSSEC-related RRtypes, DNS clients -- > resolving name servers or stub resolvers -- will only get those > RRtypes if they indicate that they are DNSSEC-aware. This is done by > setting the DO bit in the EDNS0 header: see RFC3225. So a client will > not get signed responses without EDNS0. IMHO this is very very very important... I'd like to get a consensus from the list on this ... this could be a critical element of the Implementers draft .. should support for EDNSO be mandatory? -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)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 enum-bounces@ietf.org Sat Sep 17 21:47:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGoHS-0008Qq-87; Sat, 17 Sep 2005 21:47:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGoHP-0008PX-19 for enum@megatron.ietf.org; Sat, 17 Sep 2005 21:47:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14766 for ; Sat, 17 Sep 2005 21:47:40 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EGoMh-0005Pf-US for enum@ietf.org; Sat, 17 Sep 2005 21:53:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] A note for the Implementers Draft Date: Sun, 18 Sep 2005 03:49:38 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4528@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] A note for the Implementers Draft Thread-Index: AcW761g/D1HUPxIeTx+8q3w5Gcz/pAAB+Kh8 From: "Stastny Richard" To: "Richard Shockey" , "Jim Reid" X-Spam-Score: 0.8 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, lconroy , "Lawrence Conroy \(Lawrence Conroy\)" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >IMHO this is very very very important...=20 agree =20 >I'd like to get a consensus >from the list on this ... this could be a critical element of the >Implementers draft .. should support for EDNSO be mandatory? As Jim pointed out - yes Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Richard Shockey Gesendet: So 18.09.2005 02:47 An: Jim Reid Cc: enum@ietf.org; lconroy; Lawrence Conroy (Lawrence Conroy) Betreff: Re: [Enum] A note for the Implementers Draft Jim Reid wrote: > On Sep 16, 2005, at 11:14, lconroy wrote: > >> Personally, I would be happy to make this a MUST (at least for=20 >> EDNS0) for all DNS entities that are used for ENUM queries. > > > I agree. The draft should recommend that clients use EDNS0 whenever=20 > possible. This is a far better option than having truncated 512-byte=20 > UDP responses followed by TCP retries. Any name server that gets lots=20 > of queries -- hundreds per second or more -- would not be happy to=20 > keep a TCP protocol control block for each of these "transactions"=20 > if they went over TCP. > >> IMHO, everyone will need EDNS0 if/when we ever get DNSSEC deployed. > > > This isn't a matter of opinion Lawrence. It's a matter of fact. Apart=20 > from explicitly querying for DNSSEC-related RRtypes, DNS clients --=20 > resolving name servers or stub resolvers -- will only get those=20 > RRtypes if they indicate that they are DNSSEC-aware. This is done by=20 > setting the DO bit in the EDNS0 header: see RFC3225. So a client will=20 > not get signed responses without EDNS0. IMHO this is very very very important... I'd like to get a consensus from the list on this ... this could be a critical element of the Implementers draft .. should support for EDNSO be mandatory? -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Sep 18 05:09:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGvBI-0006hB-2t; Sun, 18 Sep 2005 05:09:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGvBG-0006h6-Pe for enum@megatron.ietf.org; Sun, 18 Sep 2005 05:09:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13109 for ; Sun, 18 Sep 2005 05:09:46 -0400 (EDT) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGvGb-0001Tl-1X for enum@ietf.org; Sun, 18 Sep 2005 05:15:22 -0400 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j8I99iMN003409; Sun, 18 Sep 2005 10:09:44 +0100 (BST) In-Reply-To: <432CB918.6050304@shockey.us> References: <4329B332.3080600@shockey.us> <95A15E8A-6644-4D5C-B2C8-6D7FEF8A8BC3@insensate.co.uk> <432CB918.6050304@shockey.us> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9F65A0ED-0274-4AF3-95AB-896E4EF2201E@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] A note for the Implementers Draft Date: Sun, 18 Sep 2005 10:09:38 +0100 To: Richard Shockey X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, lconroy , "Lawrence Conroy \(Lawrence Conroy\)" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Sep 18, 2005, at 01:47, Richard Shockey wrote: >> This isn't a matter of opinion Lawrence. It's a matter of fact. >> Apart from explicitly querying for DNSSEC-related RRtypes, DNS >> clients -- resolving name servers or stub resolvers -- will only >> get those RRtypes if they indicate that they are DNSSEC-aware. >> This is done by setting the DO bit in the EDNS0 header: see >> RFC3225. So a client will not get signed responses without EDNS0. > > IMHO this is very very very important... I'd like to get a > consensus from the list on this ... this could be a critical > element of the Implementers draft .. should support for EDNSO be > mandatory? YES! Even without DNSSEC, ENUM clients need EDNS0. There are two reasons: [1] It's likely some ENUM entries will have large NAPTR RRsets which would exceed the 512 byte limit. EDNS0 allows for a bigger UDP payload which should eliminate truncated responses and TCP retries. This is a VERY Good Thing: less latency for the client and less load on the name servers. [2] EDNS0 provides more flexibility for future expansion. There are extra header bits available. There might be a need to use them later on. Or ENUM might want to rely on some still-to-be-invented DNS feature which uses them. I'd be happy to contribute a paragraph to the draft explaining why EDNS0 support is mandatory. IMO the draft is fatally flawed if EDNS0 support is not made mandatory. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Sep 18 19:24:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EH8W9-0002Tv-GT; Sun, 18 Sep 2005 19:24:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EH8W8-0002Tn-F8 for enum@megatron.ietf.org; Sun, 18 Sep 2005 19:24:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02070 for ; Sun, 18 Sep 2005 19:24:13 -0400 (EDT) Received: from bay103-f26.bay103.hotmail.com ([65.54.174.36] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EH8bd-00055V-LY for enum@ietf.org; Sun, 18 Sep 2005 19:29:58 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 18 Sep 2005 16:24:06 -0700 Message-ID: Received: from 65.54.174.203 by by103fd.bay103.hotmail.msn.com with HTTP; Sun, 18 Sep 2005 23:24:05 GMT X-Originating-IP: [65.54.174.203] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <9F65A0ED-0274-4AF3-95AB-896E4EF2201E@rfc1035.com> From: "Peter Williams" Cc: enum@ietf.org Subject: Re: [Enum] A note for the Implementers Draft Date: Sun, 18 Sep 2005 16:24:05 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 18 Sep 2005 23:24:06.0241 (UTC) FILETIME=[1035B510:01C5BCA8] X-Spam-Score: 0.8 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org RFC 2671 "5 - Transport Considerations 5.1. The presence of an OPT pseudo-RR in a request should be taken as an indication that the requestor fully implements the given version of EDNS, and can correctly understand any response that conforms to that feature's specification. 5.2. Lack of use of these features in a request must be taken as an indication that the requestor does not implement any part of this specification and that the responder may make no use of any protocol extension described here in its response." We can (and MUST) assert the negative as a standard track requirement: if a responder receives a ENUM request without an OPT pseudo-RR, it must not process the ENUM query. Quite what it should do might now be specified. This is not a guide issue: this issue is normative, and must be part of the standards track. >From: Jim Reid >To: Richard Shockey >CC: enum@ietf.org, lconroy ,"Lawrence Conroy >(Lawrence Conroy)" >Subject: Re: [Enum] A note for the Implementers Draft >Date: Sun, 18 Sep 2005 10:09:38 +0100 > >On Sep 18, 2005, at 01:47, Richard Shockey wrote: > >>>This isn't a matter of opinion Lawrence. It's a matter of fact. Apart >>>from explicitly querying for DNSSEC-related RRtypes, DNS clients -- >>>resolving name servers or stub resolvers -- will only get those RRtypes >>>if they indicate that they are DNSSEC-aware. This is done by setting >>>the DO bit in the EDNS0 header: see RFC3225. So a client will not get >>>signed responses without EDNS0. >> >>IMHO this is very very very important... I'd like to get a consensus from >>the list on this ... this could be a critical element of the Implementers >>draft .. should support for EDNSO be mandatory? > >YES! Even without DNSSEC, ENUM clients need EDNS0. There are two reasons: > >[1] It's likely some ENUM entries will have large NAPTR RRsets which would >exceed the 512 byte limit. EDNS0 allows for a bigger UDP payload which >should eliminate truncated responses and TCP retries. This is a VERY Good >Thing: less latency for the client and less load on the name servers. > >[2] EDNS0 provides more flexibility for future expansion. There are extra >header bits available. There might be a need to use them later on. Or ENUM >might want to rely on some still-to-be-invented DNS feature which uses >them. > > >I'd be happy to contribute a paragraph to the draft explaining why EDNS0 >support is mandatory. > >IMO the draft is fatally flawed if EDNS0 support is not made mandatory. > >_______________________________________________ >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 enum-bounces@ietf.org Mon Sep 19 08:43:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHKzd-0008Dn-QY; Mon, 19 Sep 2005 08:43:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHKzb-0008De-J8 for enum@megatron.ietf.org; Mon, 19 Sep 2005 08:43:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17985 for ; Mon, 19 Sep 2005 08:43:29 -0400 (EDT) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHL5D-0005qc-O5 for enum@ietf.org; Mon, 19 Sep 2005 08:49:20 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id A77B16F10B; Mon, 19 Sep 2005 13:44:33 +0100 (BST) In-Reply-To: <9F65A0ED-0274-4AF3-95AB-896E4EF2201E@rfc1035.com> References: <4329B332.3080600@shockey.us> <95A15E8A-6644-4D5C-B2C8-6D7FEF8A8BC3@insensate.co.uk> <432CB918.6050304@shockey.us> <9F65A0ED-0274-4AF3-95AB-896E4EF2201E@rfc1035.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] A note for the Implementers Draft Date: Mon, 19 Sep 2005 13:43:01 +0100 To: Jim Reid X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Cc: "'enum@ietf.org' ENUM" , Stastny Richard , Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Jim, Richards, folks, OK - "fatally flawed if EDNS0 support is not made mandatory" is perhaps not the most tactful comment, given the effort that has been put into the document so far. However... First - note that EDNS0 and TCP support has already been covered in the existing Experiences draft - please read section 6. I have tightened it up somewhat in the new version, but this is not a NEW issue. Second - thanks for the offer, Jim, but this has to be woven into what's already there, so it would be better if I stitched it together. Third - the current (and updated) text strongly recommends TCP and EDNS0 support, and explains that if the entities involved don't do this, then it isn't going to work well if at all. What we're talking about here is recommending that Clients MUST support EDNS0, not that they SHOULD. Personally, given that EDNS0 support for larger packets consists of tacking a *fixed* 11 byte chunk onto the end of a packet and bumping the N_additional count to 1 (for any chosen reported supported datagram size), I do not believe that EDNS0 support in "home rolled" customer ENUM/DNS clients is hard. IIUC, the chunk to report 1280 byte packets is '00 0029 0500 00000000 0000' - gee whiz. We'll worry about queries with "DNSSEC items requested" later. But ... let's get real here. This is non-trivial, and please will folks think about things before just saying yes. It is not just "hand rolled" ENUM/DNS clients - the Recursive Resolvers need to support EDNS0, the Authoritative Servers need to support EDNS0 (and any middle box needs not do dump DNS messages larger than 512 bytes ;). There is also the issue of Network Access Providers who support small MTUs. If one uses EDNS0 and one's provider supports an MTU of 576 bytes, then reporting that MTU as the supported datagram size is not going to help. Of course, one can report a larger size, but this means that datagram fragmentation is going to occur, or if one is really unlucky the Authoritative Server will have set the DF bit in its response and the packet will be dumped on the way back. Also, if it uses a standard DNS stack, then the ENUM client needs some way to indicate that it wants this query to indicate EDNS0 support. That means that the stack needs a usable API. Typically, this means that the DNS stack sends EDNS0 with *every* DNS query (not just ones looking for NAPTRs in an ENUM zone), but YMMV with different stacks and APIs. As we cobbled together a hand-rolled stack for our mobile phone client, I don't worry about interfacing with the underlying DNS stack (just as well, as the APIs provided by DNS stacks on mobile phones typically "are less than ideal" - gethostbyname and that's about it for most of them). ---- I do worry that this mandate means that *every* involved component, including your ISP's (or MoFoCo's) Recursive Resolver is required to provide this support, and Network Access and MTU may add some interesting issues to the mix. Short of "sustained physical pressure", I don't know how one can force them to do this. If the WG wants to go for a MUST (and the IETF/IESG agrees) then at least we should include a description of what happens when everything is not playing ball, and what the fallback process should be for a client. If we put in an unalloyed MUST, then some developers WILL assume that the send an EDNS0 query and they're done. If it doesn't work, then DNS is broken and they abort the process. all the best, Lawrence On 18 Sep 2005, at 10:09, Jim Reid wrote: > On Sep 18, 2005, at 01:47, Richard Shockey wrote: >>> This isn't a matter of opinion Lawrence. It's a matter of fact. >>> Apart from explicitly querying for DNSSEC-related RRtypes, DNS >>> clients -- resolving name servers or stub resolvers -- will only >>> get those RRtypes if they indicate that they are DNSSEC-aware. >>> This is done by setting the DO bit in the EDNS0 header: see >>> RFC3225. So a client will not get signed responses without EDNS0. >>> >> >> IMHO this is very very very important... I'd like to get a >> consensus from the list on this ... this could be a critical >> element of the Implementers draft .. should support for EDNSO be >> mandatory? >> > > YES! Even without DNSSEC, ENUM clients need EDNS0. There are two > reasons: > > [1] It's likely some ENUM entries will have large NAPTR RRsets > which would exceed the 512 byte limit. EDNS0 allows for a bigger > UDP payload which should eliminate truncated responses and TCP > retries. This is a VERY Good Thing: less latency for the client and > less load on the name servers. > > [2] EDNS0 provides more flexibility for future expansion. There are > extra header bits available. There might be a need to use them > later on. Or ENUM might want to rely on some still-to-be-invented > DNS feature which uses them. > > > I'd be happy to contribute a paragraph to the draft explaining why > EDNS0 support is mandatory. > > IMO the draft is fatally flawed if EDNS0 support is not made > mandatory. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 20 05:20:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHeIK-0005yl-UB; Tue, 20 Sep 2005 05:20:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHeII-0005ya-Af for enum@megatron.ietf.org; Tue, 20 Sep 2005 05:20:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17938 for ; Tue, 20 Sep 2005 05:20:03 -0400 (EDT) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHeO4-0006nl-Ip for enum@ietf.org; Tue, 20 Sep 2005 05:26:06 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 0A59E6F192; Tue, 20 Sep 2005 10:21:24 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <115AD536-978F-4640-B3EF-4E4B12665DC7@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] A note for the Implementers Draft Date: Tue, 20 Sep 2005 10:19:54 +0100 To: Peter Williams X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi there, I beg to differ slightly with the statement that this is not a guide issue. IIUC, what folk aim to say is that EDNS0 ->support<- is mandatory, NOT that an ENUM/DNS Client MUST only send EDNS0 queries. Of course, we ADVISE that these queries should go out with EDNS0 (which is why it's in the guide - it's advisory). However, nowhere in RFC2671 does is state that support for EDNS0 means that "standard" queries according to RFC1035 MUST NOT be answered. That would certainly be a standards track issue, and would IMHO be both bad and wrong. all the best, Lawrence On 19 Sep 2005, at 00:24, Peter Williams wrote: > RFC 2671 > > "5 - Transport Considerations > > 5.1. The presence of an OPT pseudo-RR in a request should be taken > as an > indication that the requestor fully implements the given version of > EDNS, and can correctly understand any response that conforms to > that feature's specification. > > 5.2. Lack of use of these features in a request must be taken as an > indication that the requestor does not implement any part of this > specification and that the responder may make no use of any > protocol extension described here in its response." > > > We can (and MUST) assert the negative as a standard track > requirement: if a responder receives a ENUM request without an OPT > pseudo-RR, it must not process the ENUM query. Quite what it should > do might now be specified. > > This is not a guide issue: this issue is normative, and must be > part of the standards track. > > > >> From: Jim Reid >> To: Richard Shockey >> CC: enum@ietf.org, lconroy ,"Lawrence >> Conroy (Lawrence Conroy)" >> Subject: Re: [Enum] A note for the Implementers Draft >> Date: Sun, 18 Sep 2005 10:09:38 +0100 >> >> On Sep 18, 2005, at 01:47, Richard Shockey wrote: >> >> >>>> This isn't a matter of opinion Lawrence. It's a matter of fact. >>>> Apart from explicitly querying for DNSSEC-related RRtypes, DNS >>>> clients -- resolving name servers or stub resolvers -- will >>>> only get those RRtypes if they indicate that they are DNSSEC- >>>> aware. This is done by setting the DO bit in the EDNS0 header: >>>> see RFC3225. So a client will not get signed responses without >>>> EDNS0. >>>> >>> >>> IMHO this is very very very important... I'd like to get a >>> consensus from the list on this ... this could be a critical >>> element of the Implementers draft .. should support for EDNSO be >>> mandatory? >>> >> >> YES! Even without DNSSEC, ENUM clients need EDNS0. There are two >> reasons: >> >> [1] It's likely some ENUM entries will have large NAPTR RRsets >> which would exceed the 512 byte limit. EDNS0 allows for a bigger >> UDP payload which should eliminate truncated responses and TCP >> retries. This is a VERY Good Thing: less latency for the client >> and less load on the name servers. >> >> [2] EDNS0 provides more flexibility for future expansion. There >> are extra header bits available. There might be a need to use >> them later on. Or ENUM might want to rely on some still-to-be- >> invented DNS feature which uses them. >> >> >> I'd be happy to contribute a paragraph to the draft explaining >> why EDNS0 support is mandatory. >> >> IMO the draft is fatally flawed if EDNS0 support is not made >> mandatory. >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum >> > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 20 06:11:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHf5f-0002f7-UH; Tue, 20 Sep 2005 06:11:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHf5d-0002ek-Ts for enum@megatron.ietf.org; Tue, 20 Sep 2005 06:11:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20315 for ; Tue, 20 Sep 2005 06:11:03 -0400 (EDT) Received: from bay103-f20.bay103.hotmail.com ([65.54.174.30] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHfBR-00082w-KV for enum@ietf.org; Tue, 20 Sep 2005 06:17:06 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Sep 2005 03:10:55 -0700 Message-ID: Received: from 65.54.174.207 by by103fd.bay103.hotmail.msn.com with HTTP; Tue, 20 Sep 2005 10:10:54 GMT X-Originating-IP: [65.54.174.207] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <115AD536-978F-4640-B3EF-4E4B12665DC7@insensate.co.uk> From: "Peter Williams" To: lconroy@insensate.co.uk Subject: Re: [Enum] A note for the Implementers Draft Date: Tue, 20 Sep 2005 03:10:54 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 20 Sep 2005 10:10:55.0505 (UTC) FILETIME=[96BF3010:01C5BDCB] X-Spam-Score: 0.8 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I think I understand the intent of the language in reflecting the group's state of mind, but Im attempting to read the material as would a new (intelligent) reader, one without the benefit of WG experience. After 10+ years of IETF experience, Ive really no idea what "mandatory _support_" means. Im either conforming with MUST, SHOULD or MAY in my implementation or i'm not. On this issue, there seems no reason not to expect the definition of conformance to be pretty clear. (ok. the political layer in IETF means that implementor guides add the unauthorized "ADVISE" to the conformance option set, but, lets not go there.) Let me be priggish, for the sake of clarity, expecting the answer to the following to be "NO": does "mandatory feature support" equate to initiators "SHOULD" send the EDNSO-format queries? The rationale for SHOULD might be that (a) ENUM wont work half the time if non-EDNSO queries are sent (b) sending EDNSO queries with the magic const bytes at least addresses the transport issue without obliging the client to have the capability to process any EDNSO protocol elements (c) responders recognizing that the UDP limit has been reached on a non EDNSO query response might reasonably abandon the operation, in a manner conforming with the incoming transport (e.g. UDP tunneled over an IPSEC/IKEv2 TCP-based SA) Now to the impudent, priggish part: why not have SHOULD in the stds language, and why punt to the implementors guide? My red flag went up, especially as the introduction to the issue was founded in ..... DNS SEC issue area. lets mark the language used: "feature support" mandatory, DNSSEC, signed responses, implied client support for processing DNS signed responses....ENUM WG has punted DNSSEC till "later"... Im worried we are just mandating DNSSEC "feature support" by the back door, becuase its politically too hot to do in the stds track. But using guides for this purpose this is like the "just under the legal definition of torture" culture: it has bad sideeffects on the stds process, once we start down this track. Its politically expedient and perhaps even necessary in todays ENUM-based VOIP to start signing the E.164 entries in the Carrier ENUM domain adminsitration model; but do we really want to mandate that in a backdoor manner? What started out as "solve the practical UDP problem using accepted migration strategies" quickly started being about DNSSEC, and thats whats worried me. >From: lconroy >To: Peter Williams >CC: enum@ietf.org >Subject: Re: [Enum] A note for the Implementers Draft >Date: Tue, 20 Sep 2005 10:19:54 +0100 > >Hi there, > I beg to differ slightly with the statement that this is not a guide >issue. >IIUC, what folk aim to say is that EDNS0 ->support<- is mandatory, NOT >that >an ENUM/DNS Client MUST only send EDNS0 queries. > >Of course, we ADVISE that these queries should go out with EDNS0 (which is >why it's in the guide - it's advisory). > >However, nowhere in RFC2671 does is state that support for EDNS0 means >that >"standard" queries according to RFC1035 MUST NOT be answered. >That would certainly be a standards track issue, and would IMHO be both >bad >and wrong. > >all the best, > Lawrence > >On 19 Sep 2005, at 00:24, Peter Williams wrote: >>RFC 2671 >> >>"5 - Transport Considerations >> >>5.1. The presence of an OPT pseudo-RR in a request should be taken as an >>indication that the requestor fully implements the given version of >>EDNS, and can correctly understand any response that conforms to >>that feature's specification. >> >>5.2. Lack of use of these features in a request must be taken as an >>indication that the requestor does not implement any part of this >>specification and that the responder may make no use of any >>protocol extension described here in its response." >> >> >>We can (and MUST) assert the negative as a standard track requirement: if >>a responder receives a ENUM request without an OPT pseudo-RR, it must not >>process the ENUM query. Quite what it should do might now be specified. >> >>This is not a guide issue: this issue is normative, and must be part of >>the standards track. >> >> >> >>>From: Jim Reid >>>To: Richard Shockey >>>CC: enum@ietf.org, lconroy ,"Lawrence Conroy >>>(Lawrence Conroy)" >>>Subject: Re: [Enum] A note for the Implementers Draft >>>Date: Sun, 18 Sep 2005 10:09:38 +0100 >>> >>>On Sep 18, 2005, at 01:47, Richard Shockey wrote: >>> >>> >>>>>This isn't a matter of opinion Lawrence. It's a matter of fact. Apart >>>>> from explicitly querying for DNSSEC-related RRtypes, DNS clients -- >>>>> resolving name servers or stub resolvers -- will only get those >>>>>RRtypes if they indicate that they are DNSSEC- aware. This is done by >>>>>setting the DO bit in the EDNS0 header: see RFC3225. So a client will >>>>> not get signed responses without EDNS0. >>>>> >>>> >>>>IMHO this is very very very important... I'd like to get a consensus >>>>from the list on this ... this could be a critical element of the >>>>Implementers draft .. should support for EDNSO be mandatory? >>>> >>> >>>YES! Even without DNSSEC, ENUM clients need EDNS0. There are two >>>reasons: >>> >>>[1] It's likely some ENUM entries will have large NAPTR RRsets which >>>would exceed the 512 byte limit. EDNS0 allows for a bigger UDP payload >>>which should eliminate truncated responses and TCP retries. This is a >>>VERY Good Thing: less latency for the client and less load on the name >>>servers. >>> >>>[2] EDNS0 provides more flexibility for future expansion. There are >>>extra header bits available. There might be a need to use them later >>>on. Or ENUM might want to rely on some still-to-be- invented DNS feature >>>which uses them. >>> >>> >>>I'd be happy to contribute a paragraph to the draft explaining why >>>EDNS0 support is mandatory. >>> >>>IMO the draft is fatally flawed if EDNS0 support is not made mandatory. >>> >>>_______________________________________________ >>>enum mailing list >>>enum@ietf.org >>>https://www1.ietf.org/mailman/listinfo/enum >>> >> >> >> >>_______________________________________________ >>enum mailing list >>enum@ietf.org >>https://www1.ietf.org/mailman/listinfo/enum >> > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 20 07:05:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHfwa-00074O-Bi; Tue, 20 Sep 2005 07:05:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHfwY-00074A-Lc for enum@megatron.ietf.org; Tue, 20 Sep 2005 07:05:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22544 for ; Tue, 20 Sep 2005 07:05:43 -0400 (EDT) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHg2J-0000m8-NJ for enum@ietf.org; Tue, 20 Sep 2005 07:11:47 -0400 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j8KB5UMN006753 for ; Tue, 20 Sep 2005 12:05:31 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] A note for the Implementers Draft Date: Tue, 20 Sep 2005 12:05:24 +0100 To: enum@ietf.org X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Sep 20, 2005, at 11:10, Peter Williams wrote: > The rationale for SHOULD might be that (a) ENUM wont work half the > time if non-EDNSO queries are sent Nope! Most of the world's name servers support EDNS0 today. The few that don't -- BIND4, djbdns -- are supposed to return a FORMERR, SERVFAIL or NOTIMPL response if they get an ENDS0 query. The client then repeats the query in RFC1035-format. Which could of course lead to a truncated response => TCP retry. ENUM will work just fine without EDNS0. However it won't work well. And without EDNS0, the load on ENUM name servers could be very, very nasty. Few operating systems have TCP/IP stacks that can cope with thousands (or many hundreds) of TCP connections per second: the typical query rate for a busy name server. I think Section 6 of the draft is too vague. IMO the language & recommendations need to be tightened up to say: [1] All name servers involved in ENUM -- authoritative and recursive resolvers -- MUST support EDNS0 and TCP queries. This is a no-brainer as 90%+ of the world's name servers already do this. By making this requirement mandatory, it should hopefully stop the clueless from using broken or ancient DNS software for ENUM. That software probably wouldn't understand NAPTR records anyway. At the very least, a strong, clear recommendation here gives engineers something to point at when their management decides BIND4 would be a good platform for ENUM. [2] ENUM clients -- name servers and stub resolvers -- MUST support EDNS0. EDNS0 queries SHOULD be the default for lookups unless the client knows for sure it's talking to a name server that violates [1] by not supporting EDNS0. [3] ENUM clients SHOULD support TCP queries. Dropping TCP support would be inadvisable. But it might be OK in controlled environments: say handsets that can't accommodate TCP(?) but always use EDNS0 to talk to name servers that always support EDNS0. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 20 07:36:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHgQG-0005uj-3Q; Tue, 20 Sep 2005 07:36:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHgQE-0005ub-LH for enum@megatron.ietf.org; Tue, 20 Sep 2005 07:36:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23476 for ; Tue, 20 Sep 2005 07:36:25 -0400 (EDT) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHgW2-0001Nz-41 for enum@ietf.org; Tue, 20 Sep 2005 07:42:27 -0400 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j8KBaMMN006863 for ; Tue, 20 Sep 2005 12:36:23 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <115AD536-978F-4640-B3EF-4E4B12665DC7@insensate.co.uk> References: <115AD536-978F-4640-B3EF-4E4B12665DC7@insensate.co.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1D67A879-3633-490B-AF5B-8537F7079A29@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] A note for the Implementers Draft Date: Tue, 20 Sep 2005 12:36:16 +0100 To: enum@ietf.org X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Sep 20, 2005, at 10:19, lconroy wrote: > I beg to differ slightly with the statement that this is not a > guide issue. > IIUC, what folk aim to say is that EDNS0 ->support<- is mandatory, > NOT that > an ENUM/DNS Client MUST only send EDNS0 queries. > > Of course, we ADVISE that these queries should go out with EDNS0 > (which is > why it's in the guide - it's advisory). > My interpretation of what you're saying Lawrence is that EDNS0 support is mandatory and that lookups SHOULD be done by EDNS0 unless the query is going to a server that doesn't speak EDNS0. Right? > However, nowhere in RFC2671 does is state that support for EDNS0 > means that > "standard" queries according to RFC1035 MUST NOT be answered. > That would certainly be a standards track issue, and would IMHO be > both bad > and wrong. > Indeed. EDNS0 was designed to be backwards compatible with the installed base. [In 1999, few name servers supported EDNS0. It's a very different story today.] If an EDNS0 query went to a server that didn't support EDNS0, it would return a "I don't understand this" response. The client would then repeat the query using RFC1035 semantics and all would be well. Apart obviously from the latency of an extra query/response RTT. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 20 07:59:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHgmB-0003If-Kp; Tue, 20 Sep 2005 07:59:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHgmA-0003IX-Hm for enum@megatron.ietf.org; Tue, 20 Sep 2005 07:59:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24474 for ; Tue, 20 Sep 2005 07:59:05 -0400 (EDT) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHgry-00023Q-6C for enum@ietf.org; Tue, 20 Sep 2005 08:05:07 -0400 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j8KBx0MN006884; Tue, 20 Sep 2005 12:59:02 +0100 (BST) In-Reply-To: References: <4329B332.3080600@shockey.us> <95A15E8A-6644-4D5C-B2C8-6D7FEF8A8BC3@insensate.co.uk> <432CB918.6050304@shockey.us> <9F65A0ED-0274-4AF3-95AB-896E4EF2201E@rfc1035.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6979AAD8-FA00-47F0-B534-5A46FBCBCBF0@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] A note for the Implementers Draft Date: Tue, 20 Sep 2005 12:58:54 +0100 To: lconroy X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: "'enum@ietf.org' ENUM" , Stastny Richard , Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Sep 19, 2005, at 13:43, lconroy wrote: > Also, if it uses a standard DNS stack, then the ENUM client needs > some way to indicate that it wants this query to indicate EDNS0 > support. That means that the stack needs a usable API. > Typically, this means that the DNS stack sends EDNS0 with *every* > DNS query (not just ones looking for NAPTRs in an ENUM zone), but > YMMV with different stacks and APIs. > As we cobbled together a hand-rolled stack for our mobile phone > client, I don't worry about interfacing with the underlying DNS > stack (just as well, as the APIs provided by DNS stacks on mobile > phones typically "are less than ideal" - gethostbyname and that's > about it for most of them). Sigh. Yes, the DNS has lacked a decent API ever since it was invented. [The de facto API -- nearest thing to a standard -- is the set of 20 year-old res_mkquery() BSD library calls that usually lurk underneath the gethostby{name,addr}() interface.] New DNS stuff like Dynamic Update, EDNS0, TSIG, SIG(0), DNSSEC and NAPTR record processing make this problem even more acute. No wonder there's so much perl shimware to support these features. There is a general recognition that there's a need for a comprehensive and up to date DNS API. Sadly nobody seems willing to pay for one to be developed. Or share the cost with like-minded companies. If you know of anyone who'd be willing to fund this work, I know of a neutral, non-profit organisation that would be delighted to produce that API and get it through X/Open and/or the ANSI C people. :-) _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 20 08:09:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHgwF-0006Hz-JA; Tue, 20 Sep 2005 08:09:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHgwD-0006Hu-SL for enum@megatron.ietf.org; Tue, 20 Sep 2005 08:09:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25404 for ; Tue, 20 Sep 2005 08:09:28 -0400 (EDT) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHh21-0002Qm-P0 for enum@ietf.org; Tue, 20 Sep 2005 08:15:31 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 61A296F1BC; Tue, 20 Sep 2005 13:10:44 +0100 (BST) In-Reply-To: <1D67A879-3633-490B-AF5B-8537F7079A29@rfc1035.com> References: <115AD536-978F-4640-B3EF-4E4B12665DC7@insensate.co.uk> <1D67A879-3633-490B-AF5B-8537F7079A29@rfc1035.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <395B31F8-CFF4-4736-A24D-0898DB97022E@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] A note for the Implementers Draft Date: Tue, 20 Sep 2005 13:09:13 +0100 To: Jim Reid X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Jim, folks, On 20 Sep 2005, at 12:36, Jim Reid wrote: > On Sep 20, 2005, at 10:19, lconroy wrote: >> I beg to differ slightly with the statement that this is not a >> guide issue. >> IIUC, what folk aim to say is that EDNS0 ->support<- is mandatory, >> NOT that >> an ENUM/DNS Client MUST only send EDNS0 queries. >> >> Of course, we ADVISE that these queries should go out with EDNS0 >> (which is >> why it's in the guide - it's advisory). > > My interpretation of what you're saying Lawrence is that EDNS0 > support is mandatory and that lookups SHOULD be done by EDNS0 > unless the query is going to a server that doesn't speak EDNS0. Right? We ADVISE that queries MUST use EDNS0 for good performance reasons (and/or sanity). Will the protocol work if EDNS0 is NOT used? Generally, yes. That means that, from a Standards Track *protocol* perspective, there is no need for a MUST (but there is a "gotcha" if the infrastructure supports neither EDNS0 nor TCP and large RRSets are "published"). => It is not a standards track mandate for the underlying DNS protocol and its implementations. If the result of a probe is not implemented/serv fail/..., then the fallback procedure will work - it's just painful. The implication is that, for performance reasons, we advise that Servers and Middleboxes MUST support EDNS0. Again, the protocol still works if they don't, but they sure will p**s people off. They did me until I junked the box. I also take this to mean that the *advice* is that one MUST try EDNS0 first. Anything else is going to be painfully slow. Is this acceptable? >> However, nowhere in RFC2671 does is state that support for EDNS0 >> means that >> "standard" queries according to RFC1035 MUST NOT be answered. >> That would certainly be a standards track issue, and would IMHO be >> both bad >> and wrong. > Indeed. EDNS0 was designed to be backwards compatible with the > installed base. [In 1999, few name servers supported EDNS0. It's a > very different story today.] If an EDNS0 query went to a server > that didn't support EDNS0, it would return a "I don't understand > this" response. The client would then repeat the query using > RFC1035 semantics and all would be well. Apart obviously from the > latency of an extra query/response RTT. Absolutely agree - section 5.3 in rfc2671 spells out that one falls- back if the response indicates lack of support. I assume that this would mean one then tries UDP, and if/when THAT comes back with TC=1, one finally tries TCP. In the situation where a server doesn't support EDNS0, then one is in for a long delay. If the server/middlebox also doesn't support TCP, then one is in a heap of pain with large RRSets, but from the text of 1035 and 1123, I take that to mean that the configuration of the server/middlebox is broken. all the best, Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 20 08:18:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHh4q-00008a-42; Tue, 20 Sep 2005 08:18:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHh4n-00005w-53 for enum@megatron.ietf.org; Tue, 20 Sep 2005 08:18:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25750 for ; Tue, 20 Sep 2005 08:18:19 -0400 (EDT) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHhAc-0002ei-7T for enum@ietf.org; Tue, 20 Sep 2005 08:24:22 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 681EA6F1C1; Tue, 20 Sep 2005 13:19:40 +0100 (BST) In-Reply-To: <6979AAD8-FA00-47F0-B534-5A46FBCBCBF0@rfc1035.com> References: <4329B332.3080600@shockey.us> <95A15E8A-6644-4D5C-B2C8-6D7FEF8A8BC3@insensate.co.uk> <432CB918.6050304@shockey.us> <9F65A0ED-0274-4AF3-95AB-896E4EF2201E@rfc1035.com> <6979AAD8-FA00-47F0-B534-5A46FBCBCBF0@rfc1035.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80121EDF-731F-461A-A1C1-8A4D24B0FBEE@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] A note for the Implementers Draft Date: Tue, 20 Sep 2005 13:18:10 +0100 To: Jim Reid X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: "'enum@ietf.org' ENUM" , Stastny Richard , Jim Reid , Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Jim, folks, atEnd: On 20 Sep 2005, at 12:58, Jim Reid wrote: > On Sep 19, 2005, at 13:43, lconroy wrote: >> Also, if it uses a standard DNS stack, then the ENUM client needs >> some way to indicate that it wants this query to indicate EDNS0 >> support. That means that the stack needs a usable API. >> Typically, this means that the DNS stack sends EDNS0 with *every* >> DNS query (not just ones looking for NAPTRs in an ENUM zone), but >> YMMV with different stacks and APIs. >> As we cobbled together a hand-rolled stack for our mobile phone >> client, I don't worry about interfacing with the underlying DNS >> stack (just as well, as the APIs provided by DNS stacks on mobile >> phones typically "are less than ideal" - gethostbyname and that's >> about it for most of them). >> > > Sigh. Yes, the DNS has lacked a decent API ever since it was > invented. [The de facto API -- nearest thing to a standard -- is > the set of 20 year-old res_mkquery() BSD library calls that usually > lurk underneath the gethostby{name,addr}() interface.] New DNS > stuff like Dynamic Update, EDNS0, TSIG, SIG(0), DNSSEC and NAPTR > record processing make this problem even more acute. No wonder > there's so much perl shimware to support these features. > > There is a general recognition that there's a need for a > comprehensive and up to date DNS API. Sadly nobody seems willing to > pay for one to be developed. Or share the cost with like-minded > companies. If you know of anyone who'd be willing to fund this > work, I know of a neutral, non-profit organisation that would be > delighted to produce that API and get it through X/Open and/or the > ANSI C people. :-) res_mkquery? - you were lucky. Don't forget Java and the J2ME standardisation process. It's no good if the devices out there don't have it, and from my experience, this means every mobile phone. I would dearly love to be convinced otherwise, but... all the best, Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 20 08:49:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHhZO-0007iC-7A; Tue, 20 Sep 2005 08:49:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHhZI-0007hR-Vx for enum@megatron.ietf.org; Tue, 20 Sep 2005 08:49:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27329 for ; Tue, 20 Sep 2005 08:49:51 -0400 (EDT) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHhf7-0003Qz-1m for enum@ietf.org; Tue, 20 Sep 2005 08:55:54 -0400 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j8KCnkMN006955; Tue, 20 Sep 2005 13:49:48 +0100 (BST) In-Reply-To: <395B31F8-CFF4-4736-A24D-0898DB97022E@insensate.co.uk> References: <115AD536-978F-4640-B3EF-4E4B12665DC7@insensate.co.uk> <1D67A879-3633-490B-AF5B-8537F7079A29@rfc1035.com> <395B31F8-CFF4-4736-A24D-0898DB97022E@insensate.co.uk> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] A note for the Implementers Draft Date: Tue, 20 Sep 2005 13:49:40 +0100 To: lconroy X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Sep 20, 2005, at 13:09, lconroy wrote: > We ADVISE that queries MUST use EDNS0 for good performance reasons > (and/or sanity). > > Will the protocol work if EDNS0 is NOT used? Generally, yes. That > means that, from a Standards Track *protocol* perspective, there is > no need for a MUST (but there is a "gotcha" if the infrastructure > supports neither EDNS0 nor TCP and large RRSets are "published"). > => It is not a standards track mandate for the underlying DNS > protocol and its implementations. I disagree. The draft should mandate support for queries using EDNS0 and TCP. And explain why. If it leaves enough wiggle room for people to deploy stuff that doesn't support these things, some will take the easy/lazy way out and deploy stuff that won't support them. This would be bad for everyone. We have a fair idea today that ENUM lookups are likely to generate jumbogram responses -- big NAPTR RRsets, DNSSEC, etc. So the WG should produce (mandatory) recommendations that will avoid the operational problems caused by too many truncated responses and TCP retries. It's better to get this nailed before there's substantial deployment because fixing it later is never going to succeed, especially for hand-held devices. In this context. MUSTs are preferable to SHOULDs. > The implication is that, for performance reasons, we advise that > Servers and Middleboxes MUST support EDNS0. > Again, the protocol still works if they don't, but they sure will > p**s people off. They did me until I junked the box. > > I also take this to mean that the *advice* is that one MUST try > EDNS0 first. > Anything else is going to be painfully slow. > > Is this acceptable? Yes. But IMO the draft doesn't state this clearly enough. I believe we're in violent agreement Lawrence. We seem to disagree on how to say that. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Sep 25 15:33:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJcFl-0001wd-W0; Sun, 25 Sep 2005 15:33:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJcFk-0001vH-Hz for enum@megatron.ietf.org; Sun, 25 Sep 2005 15:33:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28896 for ; Sun, 25 Sep 2005 15:33:06 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJcMA-00066F-F3 for enum@ietf.org; Sun, 25 Sep 2005 15:40:16 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j8PJXXSI030293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 25 Sep 2005 12:33:35 -0700 Message-ID: <4336FB60.4030103@shockey.us> Date: Sun, 25 Sep 2005 15:32:48 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Subject: [Enum] Nominations for ENUM WG Secretary X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org As part of the over all process of making WG operations more efficient it has been proposed that WG Chairs have the option of appointing a WG Secretary to assist the Chairs in various functions of WG management. Functions would including reviewing ID for nits, helping manage the document sheparding process, permanent WG scribe and other functions the WG chairs may determine from time to time. The WG Secretary is reckgonized on the WG home page but does not get a dot. Many of the SIP working groups are using this function to advantage, though our work load is not high Patrik and I feel its a useful thing to do. Therefore ENUM WG members interested in the position or wishing to nominate some one should privately contact the Chairs. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)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 enum-bounces@ietf.org Thu Sep 29 22:38:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELAnB-0000hW-JZ; Thu, 29 Sep 2005 22:38:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELAn9-0000h0-Gt for enum@megatron.ietf.org; Thu, 29 Sep 2005 22:38:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00259 for ; Thu, 29 Sep 2005 22:38:28 -0400 (EDT) Received: from mta2.srv.hcvlny.cv.net ([167.206.4.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELAuv-0007ci-W1 for enum@ietf.org; Thu, 29 Sep 2005 22:46:34 -0400 Received: from oemcomputer (ool-182ff143.dyn.optonline.net [24.47.241.67]) by mta2.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-2.06 (built May 11 2005)) with ESMTP id <0INL006F9ZBGM900@mta2.srv.hcvlny.cv.net> for enum@ietf.org; Thu, 29 Sep 2005 22:38:05 -0400 (EDT) Date: Thu, 29 Sep 2005 22:36:55 -0400 From: Jeff Heath To: enum@ietf.org Message-id: <0INL006FDZBHM900@mta2.srv.hcvlny.cv.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-index: AcXFZ7ssd4jDxgNWSTaWHwFsB1YEIQ== X-Spam-Score: 1.3 (+) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [Enum] unsubscribe X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1571654037==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1571654037== Content-type: multipart/alternative; boundary="Boundary_(ID_UCmNYqsUvBF5Wtv8IN6fGw)" This is a multi-part message in MIME format. --Boundary_(ID_UCmNYqsUvBF5Wtv8IN6fGw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT unsubscribe --Boundary_(ID_UCmNYqsUvBF5Wtv8IN6fGw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

unsubscribe

--Boundary_(ID_UCmNYqsUvBF5Wtv8IN6fGw)-- --===============1571654037== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1571654037==-- From enum-bounces@ietf.org Fri Sep 30 15:20:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQQK-0005YA-1o; Fri, 30 Sep 2005 15:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQQJ-0005Y5-Bb for enum@megatron.ietf.org; Fri, 30 Sep 2005 15:19:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01267 for ; Fri, 30 Sep 2005 15:19:57 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ELQYD-00073N-1s for enum@ietf.org; Fri, 30 Sep 2005 15:28:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Sep 2005 21:23:19 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C458F@oefeg-s04.oefeg.loc> Thread-Topic: Neustar and GSM create alternate ROOT Thread-Index: AcXF9GpVsXpT4AIFRp+qrgQ7u4tGfA== From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Subject: [Enum] Neustar and GSM create alternate ROOT X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Dear co-chairs, especially Patrik, =20 what is your opiniion on this press release? =20 http://www.neustar.com/pressroom/files/announcements/ns_pr_09282005.pdf =20 GSM Association and NeuStar Sign Agreement to Offer Root DNS Services to = More than 680 Global GSM Mobile Operators providing .grps and 3gppnetwork.org as TLD in the GRX network using = public IP addresses. =20 I thought the IAB recommended to 3GPP NOT to do this because of leakage =20 Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 30 15:38:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQhz-0002Ma-9b; Fri, 30 Sep 2005 15:38:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQhx-0002MV-Fl for enum@megatron.ietf.org; Fri, 30 Sep 2005 15:38:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03037 for ; Fri, 30 Sep 2005 15:38:11 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELQpq-0007su-Gt for enum@ietf.org; Fri, 30 Sep 2005 15:46:24 -0400 Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8UJblI19483; Fri, 30 Sep 2005 21:37:47 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zharhxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Sep 2005 20:37:47 +0100 Received: from [127.0.0.1] ([47.130.17.215] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Sep 2005 15:37:45 -0400 Message-ID: <433D9404.60900@nortel.com> Date: Fri, 30 Sep 2005 15:37:40 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] Neustar and GSM create alternate ROOT References: <32755D354E6B65498C3BD9FD496C7D462C458F@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C458F@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Sep 2005 19:37:45.0514 (UTC) FILETIME=[6E6C38A0:01C5C5F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Do I understand correctly that this is a form of carrier ENUM? Stastny Richard wrote: > Dear co-chairs, especially Patrik, > > what is your opiniion on this press release? > > http://www.neustar.com/pressroom/files/announcements/ns_pr_09282005.pdf > > GSM Association and NeuStar Sign Agreement to Offer Root DNS Services to More than 680 Global GSM Mobile Operators > > providing .grps and 3gppnetwork.org as TLD in the GRX network using public IP addresses. > > I thought the IAB recommended to 3GPP NOT to do this because of leakage > > Richard > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 30 15:42:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQlo-0003Js-8B; Fri, 30 Sep 2005 15:42:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQll-0003Jn-QT for enum@megatron.ietf.org; Fri, 30 Sep 2005 15:42:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03242 for ; Fri, 30 Sep 2005 15:42:08 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ELQtg-00080R-50 for enum@ietf.org; Fri, 30 Sep 2005 15:50:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Neustar and GSM create alternate ROOT Date: Fri, 30 Sep 2005 21:42:17 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4595@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Neustar and GSM create alternate ROOT Thread-Index: AcXF9vkOZDVCxMziQ1ylgsoavDQtUAAABeyv From: "Stastny Richard" To: "Tom-PT Taylor" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Yes and no, =20 Routing in IMS is done via SIP URIs (see ETSI TS 123.228) It is a complete new root also for SIP routing of "public" User = Identities (finding the other servers) =20 Of course it will also contain a ENUM tree for mapping E.164 to these = SIP URIs, which will then also resolved within this alternate root=20 =20 Richard ________________________________ Von: Tom-PT Taylor [mailto:taylor@nortel.com] Gesendet: Fr 30.09.2005 21:37 An: Stastny Richard Cc: enum@ietf.org Betreff: Re: [Enum] Neustar and GSM create alternate ROOT Do I understand correctly that this is a form of carrier ENUM? Stastny Richard wrote: > Dear co-chairs, especially Patrik, >=20 > what is your opiniion on this press release? >=20 > = http://www.neustar.com/pressroom/files/announcements/ns_pr_09282005.pdf >=20 > GSM Association and NeuStar Sign Agreement to Offer Root DNS Services = to More than 680 Global GSM Mobile Operators > > providing .grps and 3gppnetwork.org as TLD in the GRX network using = public IP addresses. >=20 > I thought the IAB recommended to 3GPP NOT to do this because of = leakage >=20 > Richard > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum