From enum-bounces@ietf.org Thu Feb 01 11:34:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCesU-0000wD-Ou; Thu, 01 Feb 2007 11:33:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCesT-0000vz-VY for enum@ietf.org; Thu, 01 Feb 2007 11:33:37 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCesP-0004cr-22 for enum@ietf.org; Thu, 01 Feb 2007 11:33:34 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id l11GXMHZ019652 for ; Thu, 1 Feb 2007 08:33:23 -0800 Received: from OVE1WNEXCB02.vcorp.ad.vrsn.com ([10.60.13.34]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 08:33:23 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 1 Feb 2007 10:33:22 -0600 Message-ID: <122A5731B827474C99ED552C6BFE23ED488013@OVE1WNEXCB02.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ENUM applications Thread-Index: AcdGHrAgzi0O8ODzTaODJH/xFmklsA== From: "McCandless, Kevin" To: X-OriginalArrivalTime: 01 Feb 2007 16:33:23.0668 (UTC) FILETIME=[B10C3940:01C7461E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [Enum] ENUM applications 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="===============0617792835==" Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============0617792835== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7461E.B06112FE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7461E.B06112FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We are participating in the US ENUM trial and are starting on working on phase three requirements that includes testing ENUM enabled applications. If you are aware of any ENUM applications that are available for use in our trial would you please email me directly. =20 Thank you, =20 Kevin=20 =20 ------_=_NextPart_001_01C7461E.B06112FE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We are participating in the US ENUM trial and are = starting on working on phase three requirements that includes testing ENUM = enabled applications. If you are aware of any ENUM applications that are = available for use in our trial would you please email me = directly.

Thank you,

Kevin =

------_=_NextPart_001_01C7461E.B06112FE-- --===============0617792835== 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 --===============0617792835==-- From enum-bounces@ietf.org Thu Feb 01 11:52:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCf9w-0002W6-2Y; Thu, 01 Feb 2007 11:51:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCf9t-0002Vx-PW for enum@ietf.org; Thu, 01 Feb 2007 11:51:38 -0500 Received: from imo-m23.mx.aol.com ([64.12.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCf9p-0000Vm-Cp for enum@ietf.org; Thu, 01 Feb 2007 11:51:37 -0500 Received: from ABGallant@aol.com by imo-m23.mx.aol.com (mail_out_v38_r7.6.) id l.c17.1061027c (52342); Thu, 1 Feb 2007 11:51:23 -0500 (EST) Received: from TOSHIBAR15 (c-68-33-203-171.hsd1.md.comcast.net [68.33.203.171]) by ciaaol-d07.mail.aol.com (v114_r2.4) with ESMTP id MAILCIAAOLD078-cc7645c21a8a2f4; Thu, 01 Feb 2007 11:51:22 -0500 From: "Andrew Gallant" To: "'McCandless, Kevin'" , Subject: RE: [Enum] ENUM applications Date: Thu, 1 Feb 2007 11:51:24 -0500 Message-ID: <001c01c74621$35728070$0500a8c0@TOSHIBAR15> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdGHrAgzi0O8ODzTaODJH/xFmklsAAAVTtg In-Reply-To: <122A5731B827474C99ED552C6BFE23ED488013@OVE1WNEXCB02.vcorp.ad.vrsn.com> X-AOL-IP: 68.33.203.171 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: robert.schafer@core.verizon.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: , Content-Type: multipart/mixed; boundary="===============1471836495==" Errors-To: enum-bounces@ietf.org --===============1471836495== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C745F7.4C9C7870" ------=_NextPart_000_001D_01C745F7.4C9C7870 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Kevin. In theory, the snom and 3cx softphones do enum lookups as MS windows-based applications. Enum.at also has an ENUM softphone. 1. http://www.snom.com/snom360softphone.html This does have some configuration options for ENUM, but so far I haven't been able to make the basic phone work. 2. http://www.3cx.com/VOIP/sip-phone.html I have installed but not tested this yet. The web page says it does ENUM but I haven't found any way to do it yet. 3. http://www.enum.at/index.php?id=softphone &L=9 I haven't tried this. This page is the English version of the one Robert provided. Thanks. -Andy | Andrew Gallant | AG Design, LLC | 664 Azalea Drive | Rockville, MD 20850 USA | Tel: +1 301 762 4024 | Fax: +1 301 762 5801 | Cell: +1 301 785 1442 | Email: abgallant@aol.com _____ From: McCandless, Kevin [mailto:KMcCandless@verisign.com] Sent: Thursday, February 01, 2007 11:33 AM To: enum@ietf.org Subject: [Enum] ENUM applications We are participating in the US ENUM trial and are starting on working on phase three requirements that includes testing ENUM enabled applications. If you are aware of any ENUM applications that are available for use in our trial would you please email me directly. Thank you, Kevin ------=_NextPart_000_001D_01C745F7.4C9C7870 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Kevin.

In theory, the snom and=20= 3cx softphones do enum lookups as MS windows-based applications. Enum.at also has an ENU= M softphone.

1. http://www.snom.com/snom360softphone.= html This does have some configuration options for ENUM, but so far I haven't bee= n able to make the basic phone work.

2. http://www.3cx.com/VOIP/sip-phone.html I have installed but not tested this yet. The web page says it does EN= UM but I haven't found any way to do it yet.

3. http://www.enum.at/index.= php?id=3Dsoftphone&L=3D9 I haven't tried this. This page is the English version of the one Robe= rt provided.

Thanks.

-Andy<= /font>

From:=20= McCandless, Kevin [mailto:KMcCandless@verisign.com]
Sent: Thursday, February 01,=20= 2007 11:33 AM
To: enum@ietf.org
Subject: [Enum] ENUM applicat= ions

We are participating in the US ENUM trial and are s= tarting on working on phase three requirements that includes testing ENUM enabled applications. If you are aware of any ENUM applications that are available for use in our trial would you please email me directly.

Thank you,

Kevin

------=_NextPart_000_001D_01C745F7.4C9C7870-- --===============1471836495== 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 --===============1471836495==-- From enum-bounces@ietf.org Thu Feb 01 13:17:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCgUc-0006p7-87; Thu, 01 Feb 2007 13:17:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCgUb-0006p1-26 for enum@ietf.org; Thu, 01 Feb 2007 13:17:05 -0500 Received: from borg.c-l-i.net ([192.16.192.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCgUV-0005Si-P2 for enum@ietf.org; Thu, 01 Feb 2007 13:17:05 -0500 Received: from [127.0.0.1] (borg.c-l-i.net [127.0.0.1]) by borg.c-l-i.net (Postfix) with ESMTP id 1B7431EAB36 for ; Thu, 1 Feb 2007 19:16:41 +0100 (CET) Message-ID: <45C22E8C.2030702@schiefner.de> Date: Thu, 01 Feb 2007 19:16:44 +0100 From: Carsten Schiefner User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: enum@ietf.org Subject: Re: [Enum] ENUM applications References: <122A5731B827474C99ED552C6BFE23ED488013@OVE1WNEXCB02.vcorp.ad.vrsn.com> In-Reply-To: <122A5731B827474C99ED552C6BFE23ED488013@OVE1WNEXCB02.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: enum-bounces@ietf.org Kevin, all - McCandless, Kevin wrote: > We are participating in the US ENUM trial and are starting on working on > phase three requirements that includes testing ENUM enabled > applications. If you are aware of any ENUM applications that are > available for use in our trial would you please email me directly. Juergen Falb [http://www.falb.at/] has a Firefox plug-in on his site. Unfortunately it works with FF 1.0.x so far only. Best, Carsten _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 01 13:36:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCgmM-0006WE-Hu; Thu, 01 Feb 2007 13:35:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCgmL-0006W8-77 for enum@ietf.org; Thu, 01 Feb 2007 13:35:25 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCgmB-00006L-Pi for enum@ietf.org; Thu, 01 Feb 2007 13:35:25 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l11ITQ1O020767; Thu, 1 Feb 2007 10:29:33 -0800 From: "Richard Shockey" To: "'Andrew Gallant'" , "'McCandless, Kevin'" , References: <122A5731B827474C99ED552C6BFE23ED488013@OVE1WNEXCB02.vcorp.ad.vrsn.com> <001c01c74621$35728070$0500a8c0@TOSHIBAR15> Subject: RE: [Enum] ENUM applications Date: Thu, 1 Feb 2007 13:29:20 -0500 Message-ID: <051b01c7462e$e4f2dd30$67201f0a@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdGHrAgzi0O8ODzTaODJH/xFmklsAAAVTtgAANmakA= In-Reply-To: <001c01c74621$35728070$0500a8c0@TOSHIBAR15> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.2 (/) X-Scan-Signature: 089da5e32269fece1072c9ff54523f20 Cc: robert.schafer@core.verizon.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1331091529==" Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1331091529== Content-Type: multipart/alternative; boundary="----=_NextPart_000_051C_01C74604.FC1CD530" This is a multi-part message in MIME format. ------=_NextPart_000_051C_01C74604.FC1CD530 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The SNOM 300 320 and 360 hard phones definitely have built in ENUM support, its triggered via the use of a dial prefix like 011 that is configured via its HTTP interface. The apex is also configurable. In addition the Asterisk server has long had ENUM support and I'm aware that the Pingtel platform will have ENUM support built in shortly. I not sure about reSIPprocate or SER. In addition you will find that all the major SBC's have ENUM support ..Nextone and Acme Packet, for carrier applications where the SBC queries via DNS and translates the response to SIP Redirect for the Soft Switches that currently cannot support 3761. _____ From: Andrew Gallant [mailto:abgallant@aol.com] Sent: Thursday, February 01, 2007 11:51 AM To: 'McCandless, Kevin'; enum@ietf.org Cc: robert.schafer@core.verizon.com Subject: RE: [Enum] ENUM applications Hi Kevin. In theory, the snom and 3cx softphones do enum lookups as MS windows-based applications. Enum.at also has an ENUM softphone. 1. http://www.snom.com/snom360softphone.html This does have some configuration options for ENUM, but so far I haven't been able to make the basic phone work. 2. http://www.3cx.com/VOIP/sip-phone.html I have installed but not tested this yet. The web page says it does ENUM but I haven't found any way to do it yet. 3. http://www.enum.at/index.php?id=softphone &L=9 I haven't tried this. This page is the English version of the one Robert provided. Thanks. -Andy | Andrew Gallant | AG Design, LLC | 664 Azalea Drive | Rockville, MD 20850 USA | Tel: +1 301 762 4024 | Fax: +1 301 762 5801 | Cell: +1 301 785 1442 | Email: abgallant@aol.com _____ From: McCandless, Kevin [mailto:KMcCandless@verisign.com] Sent: Thursday, February 01, 2007 11:33 AM To: enum@ietf.org Subject: [Enum] ENUM applications We are participating in the US ENUM trial and are starting on working on phase three requirements that includes testing ENUM enabled applications. If you are aware of any ENUM applications that are available for use in our trial would you please email me directly. Thank you, Kevin ------=_NextPart_000_051C_01C74604.FC1CD530 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The SNOM 300 320 and 360 hard = phones definitely have built in ENUM support, its triggered via the use of a dial prefix = like 011 that is configured via its HTTP interface. The apex is also = configurable.

In addition the Asterisk server has = long had ENUM support and I’m aware that the Pingtel platform will have = ENUM support built in shortly. I not sure about reSIPprocate or SER. =

In addition you will find that all = the major SBC’s have ENUM support ..Nextone and Acme Packet, for carrier applications where the SBC queries via DNS and translates the response = to SIP Redirect for the Soft Switches that currently cannot support = 3761.

From: = Andrew Gallant [mailto:abgallant@aol.com]
Sent: Thursday, February = 01, 2007 11:51 AM
To: 'McCandless, Kevin'; enum@ietf.org
Cc: robert.schafer@core.verizon.com
Subject: RE: [Enum] ENUM applications

Hi = Kevin.

In theory, the snom and 3cx = softphones do enum lookups as MS windows-based applications. Enum.at also has an = ENUM softphone.

1. http://www.snom.com/sn= om360softphone.html This does have some configuration options for ENUM, but so far I haven't = been able to make the basic phone work.

2. http://www.3cx.com/VOIP/s= ip-phone.html I have installed but not tested this yet. The web page says it = does ENUM but I haven't found any way to do it yet.

3. http://www= .enum.at/index.php?id=3Dsoftphone&L=3D9 I haven't tried this. This page is the English version of the one = Robert provided.

Thanks.

-Andy

From: = McCandless, Kevin [mailto:KMcCandless@verisign.com]
Sent: Thursday, February = 01, 2007 11:33 AM
To: enum@ietf.org
Subject: [Enum] ENUM = applications

We are participating in the US ENUM trial and are = starting on working on phase three requirements that includes testing ENUM = enabled applications. If you are aware of any ENUM applications that are available for use in our trial would you please email me = directly.

Thank you,

Kevin =

------=_NextPart_000_051C_01C74604.FC1CD530-- --===============1331091529== 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 --===============1331091529==-- From enum-bounces@ietf.org Thu Feb 01 17:03:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCk0C-0007OU-OX; Thu, 01 Feb 2007 17:01:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCk0C-0007OJ-1Q for enum@ietf.org; Thu, 01 Feb 2007 17:01:56 -0500 Received: from alnrmhc16.comcast.net ([206.18.177.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCk07-0000mA-Lx for enum@ietf.org; Thu, 01 Feb 2007 17:01:55 -0500 Received: from dragon.ariadne.com (failure[24.34.79.42]) by comcast.net (alnrmhc16) with ESMTP id <20070201220128b16004ee2de>; Thu, 1 Feb 2007 22:01:36 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l11M0S98025665 for ; Thu, 1 Feb 2007 17:00:28 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l11M04lu025634; Thu, 1 Feb 2007 17:00:04 -0500 Date: Thu, 1 Feb 2007 17:00:04 -0500 Message-Id: <200702012200.l11M04lu025634@dragon.ariadne.com> To: KMcCandless@verisign.com, enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: <051b01c7462e$e4f2dd30$67201f0a@cis.neustar.com> (richard@shockey.us) Subject: Re: [Enum] ENUM applications References: <122A5731B827474C99ED552C6BFE23ED488013@OVE1WNEXCB02.vcorp.ad.vrsn.com> <001c01c74621$35728070$0500a8c0@TOSHIBAR15> <051b01c7462e$e4f2dd30$67201f0a@cis.neustar.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: , Errors-To: enum-bounces@ietf.org From: "Richard Shockey" I'm aware that the Pingtel platform will have ENUM support built in shortly. ENUM support is scheduled for the 3.8 version of SIPxchange, Pingtel's commercial product, but the open-source sipX version has native ENUM support now (http://www.sipfoundry.org). (You can try it out by registering a phone to Pingtel's interoperability server -- see http://interop.pingtel.com.) Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 01 17:15:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCkCS-000330-5F; Thu, 01 Feb 2007 17:14:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCkCQ-00032n-25 for enum@ietf.org; Thu, 01 Feb 2007 17:14:34 -0500 Received: from wodka.aus-biz.com ([65.23.153.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCkCL-000394-PI for enum@ietf.org; Thu, 01 Feb 2007 17:14:34 -0500 Received: from [192.168.1.103] (cpe-65-24-79-168.columbus.res.rr.com [65.24.79.168]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by wodka.aus-biz.com (Postfix) with ESMTP id AE59F11A5A3; Thu, 1 Feb 2007 17:14:24 -0500 (EST) Message-ID: <45C26649.7070502@e164.org> Date: Thu, 01 Feb 2007 17:14:33 -0500 From: Duane User-Agent: Thunderbird 1.5.0.9 (X11/20070131) MIME-Version: 1.0 To: "McCandless, Kevin" Subject: Re: [Enum] ENUM applications References: <122A5731B827474C99ED552C6BFE23ED488013@OVE1WNEXCB02.vcorp.ad.vrsn.com> In-Reply-To: <122A5731B827474C99ED552C6BFE23ED488013@OVE1WNEXCB02.vcorp.ad.vrsn.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: , Errors-To: enum-bounces@ietf.org McCandless, Kevin wrote: > We are participating in the US ENUM trial and are starting on working on > phase three requirements that includes testing ENUM enabled > applications. If you are aware of any ENUM applications that are > available for use in our trial would you please email me directly. http://www.e164.org/wiki/StuffThatSupportsENUM -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 05 05:14:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE0pX-0002nq-Nr; Mon, 05 Feb 2007 05:12:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE0pW-0002nC-Pn for enum@ietf.org; Mon, 05 Feb 2007 05:12:10 -0500 Received: from zinal.switch.ch ([2001:620:0:14:203:baff:fe37:d128]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE0pR-0007Li-Fl for enum@ietf.org; Mon, 05 Feb 2007 05:12:10 -0500 Received: from [130.59.6.129] (helo=machb.switch.ch) by zinal.switch.ch with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54) id 1HE0p2-0006BP-4v; Mon, 05 Feb 2007 11:11:40 +0100 Date: Mon, 5 Feb 2007 11:11:35 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: Richard Shockey Subject: RE: [Enum] ENUM applications In-Reply-To: <051b01c7462e$e4f2dd30$67201f0a@cis.neustar.com> Message-ID: References: <122A5731B827474C99ED552C6BFE23ED488013@OVE1WNEXCB02.vcorp.ad.vrsn.com> <001c01c74621$35728070$0500a8c0@TOSHIBAR15> <051b01c7462e$e4f2dd30$67201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SWITCH-SCANNER: bypassed X-Spam-Score: -2.8 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 'Andrew Gallant' , enum@ietf.org, robert.schafer@core.verizon.com, "'McCandless, Kevin'" 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: , Errors-To: enum-bounces@ietf.org On Thu, 1 Feb 2007, Richard Shockey wrote: > In addition the Asterisk server has long had ENUM support and I'm aware that > the Pingtel platform will have ENUM support built in shortly. I not sure > about reSIPprocate or SER. SER has had ENUM support for a long time already. Also the SER fork OpenSER supports ENUM. (We are using it in our system.) In the H.323 world I am aware of GnuGK, that supports ENUM. cheers, Bernie _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 05 06:14:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE1ne-0001Ut-LI; Mon, 05 Feb 2007 06:14:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE1nd-0001Td-Eg for enum@ietf.org; Mon, 05 Feb 2007 06:14:17 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE1nc-0004rn-2B for enum@ietf.org; Mon, 05 Feb 2007 06:14:17 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 0332398FDC; Mon, 5 Feb 2007 11:14:01 +0000 (GMT) In-Reply-To: References: <122A5731B827474C99ED552C6BFE23ED488013@OVE1WNEXCB02.vcorp.ad.vrsn.com> <001c01c74621$35728070$0500a8c0@TOSHIBAR15> <051b01c7462e$e4f2dd30$67201f0a@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <913C6F5D-1FD0-4727-BBA8-77A5AAC617C8@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] ENUM applications Date: Mon, 5 Feb 2007 11:13:59 +0000 To: Bernie Hoeneisen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 'Andrew Gallant' , enum@ietf.org, "'McCandless, Kevin'" , robert.schafer@core.verizon.com, 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: , Errors-To: enum-bounces@ietf.org Hi folks, -- This is a general comment - it is not specific to SER (or *, or Intertex, or IOS...) -- Please be aware that the ENUM support in the products listed so far is generally "as good as you need". To get an ENUM client working and delivering calls is not at all hard, and as mentioned there are many products that do this. However... Support for ENUM is not always complete, and the different implementations do not always handle the potential buffer overflow attack well. From the ENUM Plugtest ETSI ran last year (and in testing other implementations as part of that work), we found that some of the implementations do not support "non-trivial" Regexps well or at all. They often ignore non-terminal NAPTRs, and NAPTRs where there is more than one enumservice. At the time some didn't handle sorting multiple NAPTRs properly or even notice that there could be more than one NAPTR in a response. I trust these have been fixed since then. YMMV: this was the state of the art last year. For basic ENUM mediated calling there are a wide range of options, but... Don't assume that all ENUM implementations are as thorough as one another. They may be good enough for your purposes, but that doesn't mean that they will all behave the same way when looking up different ENUM zones. In short, "Be careful out there" all the best, Lawrence On 5 Feb 2007, at 10:11, Bernie Hoeneisen wrote: > On Thu, 1 Feb 2007, Richard Shockey wrote: >> In addition the Asterisk server has long had ENUM support and I'm >> aware that >> the Pingtel platform will have ENUM support built in shortly. I >> not sure >> about reSIPprocate or SER. > > SER has had ENUM support for a long time already. Also the SER fork > OpenSER supports ENUM. (We are using it in our system.) > > In the H.323 world I am aware of GnuGK, that supports ENUM. > > cheers, > Bernie _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 05 08:46:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE49t-00019R-Lp; Mon, 05 Feb 2007 08:45:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE49p-00010R-K2 for enum@ietf.org; Mon, 05 Feb 2007 08:45:21 -0500 Received: from wodka.aus-biz.com ([65.23.153.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE49n-000728-BC for enum@ietf.org; Mon, 05 Feb 2007 08:45:21 -0500 Received: from [192.168.1.103] (cpe-65-24-79-168.columbus.res.rr.com [65.24.79.168]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by wodka.aus-biz.com (Postfix) with ESMTP id 7BFB811A5A2; Mon, 5 Feb 2007 08:45:07 -0500 (EST) Message-ID: <45C734EA.8020302@e164.org> Date: Mon, 05 Feb 2007 08:45:14 -0500 From: Duane User-Agent: Thunderbird 1.5.0.9 (X11/20070131) MIME-Version: 1.0 To: lconroy Subject: Re: [Enum] ENUM applications References: <122A5731B827474C99ED552C6BFE23ED488013@OVE1WNEXCB02.vcorp.ad.vrsn.com> <001c01c74621$35728070$0500a8c0@TOSHIBAR15> <051b01c7462e$e4f2dd30$67201f0a@cis.neustar.com> <913C6F5D-1FD0-4727-BBA8-77A5AAC617C8@insensate.co.uk> In-Reply-To: <913C6F5D-1FD0-4727-BBA8-77A5AAC617C8@insensate.co.uk> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: enum@ietf.org, Bernie Hoeneisen , "'McCandless, Kevin'" , Richard Shockey , 'Andrew Gallant' , robert.schafer@core.verizon.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: , Errors-To: enum-bounces@ietf.org lconroy wrote: > However... > Support for ENUM is not always complete, and the different > implementations do > not always handle the potential buffer overflow attack well. Asterisk is/was notorious for this, we added a record type and this broke asterisk in 2 ways, they weren't checking for long ENUM types, or long enum records, both caused asterisk to crash as they had a fixed buffer and didn't bother to check the string length, or limit the length going into the buffer. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 05 17:24:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HECFN-0007d5-G6; Mon, 05 Feb 2007 17:23:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HECFM-0007SL-1h; Mon, 05 Feb 2007 17:23:36 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HECFK-0000fK-Ko; Mon, 05 Feb 2007 17:23:36 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l15MNP3K015732; Mon, 5 Feb 2007 14:23:31 -0800 From: "Richard Shockey" To: , Date: Mon, 5 Feb 2007 17:23:08 -0500 Message-ID: <02c201c74974$381b3690$78201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aca702mENXL9DZxEQ/2M5JBgNzpfYg== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= , 'Jon Peterson' Subject: [Enum] Request for Publication - draft-ietf-enum-xmpp-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Title : IANA Registration for Enumservice 'XMPP' Author(s) : A. Mayrhofer Filename : draft-ietf-enum-xmpp-01.txt Pages : 8 Date : 2007-1-3 This document requests IANA registration of an Enumservice for XMPP, the Extensible Messaging and Presence Protocol. This Enumservice specifically allows the use of 'xmpp' Uniform Resource Identifiers (URIs) in the context of E.164 Number Mapping (ENUM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-xmpp-01.txt This document has been extensively discussed in the WG in 2005 and 2006. This is a request for publication for one IETF ENUM WG working group document. A two week WG last call on this document concluded on February 5. There were no additional comments from the last call. The document listed above is intended to Informational. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 05 20:48:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEFQa-0004A1-60; Mon, 05 Feb 2007 20:47:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEFQY-00048z-Dv; Mon, 05 Feb 2007 20:47:22 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEFQX-00059T-1B; Mon, 05 Feb 2007 20:47:22 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l161l7Y6017139; Mon, 5 Feb 2007 17:47:13 -0800 From: "Richard Shockey" To: , , References: <02c201c74974$381b3690$78201f0a@cis.neustar.com> Subject: RE: [Enum] Request for Publication - draft-ietf-enum-xmpp-01.txt Date: Mon, 5 Feb 2007 20:46:59 -0500 Message-ID: <005501c74990$b1ee9630$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aca702mENXL9DZxEQ/2M5JBgNzpfYiNvS3Dg In-Reply-To: <02c201c74974$381b3690$78201f0a@cis.neustar.com> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= , 'Jon Peterson' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org OOPS ... I meant this document to be standards track .. apologies to all concerned. > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Monday, February 05, 2007 5:23 PM > To: iesg-secretary@ietf.org; enum@ietf.org > Cc: 'Cullen Jennings'; 'Patrik F=E4ltstr=F6m'; 'Jon Peterson' > Subject: [Enum] Request for Publication - draft-ietf-enum-xmpp-01.txt >=20 >=20 >=20 >=20 > Title : IANA Registration for Enumservice 'XMPP' > Author(s) : A. Mayrhofer > Filename : draft-ietf-enum-xmpp-01.txt > Pages : 8 > Date : 2007-1-3 >=20 > This document requests IANA registration of an Enumservice for XMPP, = the > Extensible Messaging and Presence Protocol. This Enumservice = specifically > allows the use of 'xmpp' Uniform Resource Identifiers (URIs) in the > context > of E.164 Number Mapping (ENUM). >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-xmpp-01.txt >=20 > This document has been extensively discussed in the WG in 2005 and = 2006. >=20 > This is a request for publication for one IETF ENUM WG working group > document. >=20 > A two week WG last call on this document concluded on February 5. >=20 > There were no additional comments from the last call. >=20 > The document listed above is intended to Informational. >=20 >=20 >=20 > Richard Shockey > Director, Member of the Technical Staff > NeuStar > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org > sip:57141@fwd.pulver.com > PSTN Office +1 571.434.5651 > PSTN Mobile: +1 703.593.2683 > > >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Feb 07 07:23:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HElnc-0002lh-JU; Wed, 07 Feb 2007 07:21:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HElnb-0002la-7p for enum@ietf.org; Wed, 07 Feb 2007 07:21:19 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HElnY-0003ZW-VD for enum@ietf.org; Wed, 07 Feb 2007 07:21:19 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 2553A4C6EB; Wed, 7 Feb 2007 13:21:16 +0100 (CET) Date: Wed, 7 Feb 2007 13:21:16 +0100 From: Otmar Lendl To: Jim Reid Subject: Re: [Enum] RE: The larger issue here. Message-ID: <20070207122115.GA31624@nic.at> Mail-Followup-To: Otmar Lendl , Jim Reid , richard@shockey.us, enum@ietf.org, 'Stastny Richard' References: <011001c744e6$a7f4e5c0$22f0a544@cis.neustar.com> <32755D354E6B65498C3BD9FD496C7D46646AD9@oefeg-s04.oefeg.loc> <001701c74550$0b9df530$22f0a544@cis.neustar.com> <12A510FD-6309-4F2B-96D4-AA64C75450B3@rfc1035.com> <00c101c74573$48582400$67201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: enum@ietf.org, 'Stastny Richard' , richard@shockey.us 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: , Errors-To: enum-bounces@ietf.org On 2007/01/31 21:01, Jim Reid wrote: > On Jan 31, 2007, at 20:06, Richard Shockey wrote: > > >>>I suspect it will be like many of the routine IANA procedures with > >>>a expert committee appointed > >> > >>FWIW, this mirrors a similar concern in the dnsop WG. There the issue > >>is getting a lightweight procedure for issuing codes for new resource > >>record types. The WG is debugging a process that involves an expert > >>(singular) making a determination. I think this model may well be a > >>good idea for this WG too. > > > >Hummm interesting. What does the text look like for the procedure? > > See RFC2929bis. The DNSEXT co-chairs appointed one of your > colleagues, Ed Lewis, to be the expert reviewer. We're test-driving that process with the EBL draft. Ed has found some issues with the guidelines in the 2929bis draft (see http://ops.ietf.org/lists/namedroppers/namedroppers.2007/msg00078.html) and he has been equally critical regarding the EBL / I-ENUM specs. There are still kinks to work out in that process (e.g. is the expert supposed just to weed out obvious non-sense and formally incorrect proposals, or is he supposed to only let through top-notch proposals?), so the jury is still out on how that setup works in the real world. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Feb 08 08:27:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF9IG-0005Q1-QI; Thu, 08 Feb 2007 08:26:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF9IF-0005Pu-0b for enum@ietf.org; Thu, 08 Feb 2007 08:26:31 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF9I9-0007mV-5o for enum@ietf.org; Thu, 08 Feb 2007 08:26:30 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l18DQ7Pt017145 for ; Thu, 8 Feb 2007 05:26:22 -0800 From: "Richard Shockey" To: Date: Thu, 8 Feb 2007 08:25:59 -0500 Message-ID: <01d001c74b84$b253ef80$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdLajApmdcs3T2FSMKawESSZ34PwAAGkugg X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Subject: [Enum] FW: Important: Remember to use latest boilerplate in drafts X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: IETF Chair [mailto:chair@ietf.org] > Sent: Thursday, February 08, 2007 5:15 AM > To: IETF Announcement list > Subject: Important: Remember to use latest boilerplate in drafts > > Hi, > > With the submission deadlines before the Prague meeting coming up, > please remember that all drafts need to use the latest boilerplate > text (see below for details). > > February 26, Monday - Internet Draft Cut-off for initial document (-00) > submission by 09:00 ET (14:00 UTC/GMT) > > March 5, Monday - Internet Draft final submission cut-off by 09:00 ET > (14:00 UTC/GMT) > > Thanks > > Brian Carpenter > > -------- Original Message -------- > Subject: Internet-Draft Boilerplate Reminder > Date: Mon, 15 Jan 2007 11:51:16 -0500 > From: IETF Secretariat > To: IETF Announcement list > CC: iesg@ietf.org > > This message is to remind you that as of February 1, 2007 the IETF > Secretariat will no longer accept Internet-Drafts with the old > (i.e. pre RFC 4748) boilerplate. For your convenience, below is > the text of the message that was sent to the IETF Announcement > List by the IETF Chair on October 26, 2006 with Subject: Update to > Internet Draft and RFC Boilerplate. > > The IETF Secretariat. > -------------------------------------------------------------- > A small update to BCP 78 was recently approved by the IESG as RFC 4748, > to update the boilerplate (i.e., standard legal text) in RFCs and > Internet-Drafts to recognize the IETF Trust as a rights holder, > instead of ISOC. > > The actual boilerplate changes are given below this message. > > Starting as soon as reasonably possible, all authors of Internet-Drafts > are requested to use the new boilerplate. The RFC Editor will in any > case be inserting it in all RFCs issued from 2006-11-01. (The rights > held by ISOC in older RFCs will be administratively transferred to > the IETF Trust.) > > The public ID Nits checker already accepts I-Ds with old or new > boilerplate. The Secretariat has started accepting I-Ds with old or > new boilerplate. > > XML2RFC version 1.32 will generate the new boilerplate. > Users of I-D templates are requested to update them appropriately. > > http://www.ietf.org/ID-Checklist.html and > http://www.ietf.org/ietf/1id-guidelines.html are being updated. > > Starting December, the public ID Nits checker will issue warnings for old > boilerplate. > > Starting February 2007, the Secretariat will refuse the old boilerplate > in Internet-Drafts. > > We are sorry for the inconvenience, but this change cannot be avoided. > > IETF Chair > IETF Secretariat > TOOLS Team > > -------- > > Copyright Notice (required for all IETF Documents) > > (Normally placed at the end of the IETF Document.) > > NOTE: by convention, the first line of the copyright statement is usually > placed near the beginning of each document. This must also be updated. > > OLD > "Copyright (C) The Internet Society (year). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > NEW > "Copyright (C) The IETF Trust (year). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > > Disclaimer (required in all IETF Documents) > > (Normally placed at the end of the IETF Document after the copyright > notice.) > > > OLD > "This document and the information contained herein are provided > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, > EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT > THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR > ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A > PARTICULAR PURPOSE." > > > NEW > "This document and the information contained herein are provided > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE > IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY > WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE > ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS > FOR A PARTICULAR PURPOSE." > > Exceptions > > In MIB modules, PIB modules and similar material commonly > extracted from IETF Documents, except for material that is being > placed under IANA maintenance, the following abbreviated notice > shall be included in the body of the material that will be > extracted in lieu of the notices otherwise required by Section 5: > > OLD > "Copyright (C) The Internet Society . This version of > this MIB module is part of RFC XXXX; see the RFC itself for > full legal notices." > > NEW > "Copyright (C) The IETF Trust . This version of > this MIB module is part of RFC XXXX; see the RFC itself for > full legal notices." > > When the MIB or PIB module is the initial version of a module that > is to be maintained by the IANA, the following abbreviated notice > shall be included: > > OLD > "Copyright (C) The Internet Society . The initial > version of this MIB module was published in RFC XXXX; for full > legal notices see the RFC itself. Supplementary information > may be available at: > http://www.ietf.org/copyrights/ianamib.html." > > NEW > "Copyright (C) The IETF Trust . The initial > version of this MIB module was published in RFC XXXX; for full > legal notices see the RFC itself. Supplementary information > may be available at: > http://www.ietf.org/copyrights/ianamib.html." > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 09 20:28:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFh1z-0006ox-Eu; Fri, 09 Feb 2007 20:27:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFh1x-0006or-M3 for enum@ietf.org; Fri, 09 Feb 2007 20:27:57 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFh1w-0001xB-AQ for enum@ietf.org; Fri, 09 Feb 2007 20:27:57 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l1A1RgoL029734; Fri, 9 Feb 2007 17:27:48 -0800 From: "Richard Shockey" To: Date: Fri, 9 Feb 2007 20:27:36 -0500 Message-ID: <020901c74cb2$a649e9e0$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdMsqTtj1wN0t4MS96KiWUM4eCF+w== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= Subject: [Enum] Time slot... X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org If we have a light agenda do we really need 2 hours? Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org Skype:"rshockey101" PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 09 20:28:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFgzd-0005Kh-4p; Fri, 09 Feb 2007 20:25:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFgzb-0005Kc-R6 for enum@ietf.org; Fri, 09 Feb 2007 20:25:31 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFgza-0001e7-Dw for enum@ietf.org; Fri, 09 Feb 2007 20:25:31 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l1A1PD4J029398 for ; Fri, 9 Feb 2007 17:25:18 -0800 From: "Richard Shockey" To: Date: Fri, 9 Feb 2007 20:25:06 -0500 Message-ID: <020801c74cb2$4d307720$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdMni5g4X6mmyhCTBKzDuyAh+kFawAE8liQ X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Enum] FW: 68th IETF - DRAFT Meeting Agenda X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: To: Date: Fri, 9 Feb 2007 20:27:36 -0500 Message-ID: <020901c74cb2$a649e9e0$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdMsqTtj1wN0t4MS96KiWUM4eCF+w== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= Subject: [Enum] Time slot... X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org If we have a light agenda do we really need 2 hours? Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org Skype:"rshockey101" PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 09 20:28:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFgzd-0005Kh-4p; Fri, 09 Feb 2007 20:25:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFgzb-0005Kc-R6 for enum@ietf.org; Fri, 09 Feb 2007 20:25:31 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFgza-0001e7-Dw for enum@ietf.org; Fri, 09 Feb 2007 20:25:31 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l1A1PD4J029398 for ; Fri, 9 Feb 2007 17:25:18 -0800 From: "Richard Shockey" To: Date: Fri, 9 Feb 2007 20:25:06 -0500 Message-ID: <020801c74cb2$4d307720$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdMni5g4X6mmyhCTBKzDuyAh+kFawAE8liQ X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Enum] FW: 68th IETF - DRAFT Meeting Agenda X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org It looks like Monday afternoon but this is definitely subject to change. I have three items on the agenda so far so I'd like to hear what else is potentially out there. A. 3761 revision B. ENUMservice template and procedures. C. WG next steps and wind down time tables. > -----Original Message----- > From: IETF Agenda [mailto:agenda@ietf.org] > Sent: Friday, February 09, 2007 6:00 PM > To: ietf-announce@ietf.org > Subject: 68th IETF - DRAFT Meeting Agenda > > The DRAFT agenda for the 68th IETF Meeting can be found at: > http://www.ietf.org/meetings/68-IETF.html > > Please note that the agenda is in draft form and is subject to change > substantially before the final agenda is published on Monday, February > 26th. > > IETF Secretariat > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum f.org> List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org It looks like Monday afternoon but this is definitely subject to change. I have three items on the agenda so far so I'd like to hear what else is potentially out there. A. 3761 revision B. ENUMservice template and procedures. C. WG next steps and wind down time tables. > -----Original Message----- > From: IETF Agenda [mailto:agenda@ietf.org] > Sent: Friday, February 09, 2007 6:00 PM > To: ietf-announce@ietf.org > Subject: 68th IETF - DRAFT Meeting Agenda > > The DRAFT agenda for the 68th IETF Meeting can be found at: > http://www.ietf.org/meetings/68-IETF.html > > Please note that the agenda is in draft form and is subject to change > substantially before the final agenda is published on Monday, February > 26th. > > IETF Secretariat > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Feb 10 12:11:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFvjl-0001Vp-ME; Sat, 10 Feb 2007 12:10:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFvjj-0001VE-5i for enum@ietf.org; Sat, 10 Feb 2007 12:10:07 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HFvjh-0001DZ-KY for enum@ietf.org; Sat, 10 Feb 2007 12:10:07 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [Enum] FW: 68th IETF - DRAFT Meeting Agenda Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sat, 10 Feb 2007 18:09:31 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C74@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] FW: 68th IETF - DRAFT Meeting Agenda Thread-Index: AcdMni5g4X6mmyhCTBKzDuyAh+kFawAE8liQACCJZiQ= References: <020801c74cb2$4d307720$22f0a544@cis.neustar.com> From: "Stastny Richard" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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: , Errors-To: enum-bounces@ietf.org I partizipated at the ITI-T SG2 plenary last week =20 Triggered by a contribution from Penn Pfautz and another from Alain Doisenau (France) SG2 Q,1 started to work on Infrastructure ENUM. There where two ad-hoc meetings and also a=20 Correspondance Group led by Karen Mulberry was established =20 What was missing was a liaison from IESG =20 What I request is an entry in the agenda giving a status report from IESG on the current activities regarding Infrastructure ENUM in general and especially towards ITU-T SG2 =20 Richard =20 Here is an excerpt from the Q.1 Progress report: see the last sentence -------- C34 (AT&T) provided informational introduction to = Infrastructure/Carrier/Provider ENUM. This contribution provide = additional work that is being studied within the IETF, the interim = mechanisms for constructing a global infrastructure ENUM resources that = are being discussed, and the challenges associated with End-User ENUM = would also exist for infrastructure ENUM. =20 C29 (France) provided requirements for a global infrastructure ENUM = provision and the role of the ITU-T. The contribution recommended that = the ITU-T begin a study on the high-level I-ENUM structure, the Tier 0 = administrative contact, and the Tier 0 - Tier 1 relationship and that = SG2 define the conditions for CC delegations in a similar way they are = operated for user ENUM. =20 It was pointed out that the Interim Procedures for ENUM delegations = needed to be approved on an annual basis and it was decided that since = no contributions were received addressing any issues with the procedures = and since Q1/2 has another meeting planned in the October/November = timeframe in 2007, the Interim Procedures will be reviewed and approved = at that meeting. During the discussion on the issues and the actions required of Q1/2, it = was agreed to create an ad-hoc to develop a document regarding routing = resolution functions. The ad-hoc should consider as input C34 and C39 = as well as takes into account the current landscape; existing documents = on Public ENUM, Infrastructure ENUM, ETSI, SG13, draft IETF RFCs that = are available.. The ad-hoc proposed and the Q1 participants agreed to = establish a correspondence group to progress this work as well as to be = able to initiate any work in the event of incoming liaisons that are = received between SG2 meetings=20 ----- ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Sa 10.02.2007 02:25 An: enum@ietf.org Betreff: [Enum] FW: 68th IETF - DRAFT Meeting Agenda It looks like Monday afternoon but this is definitely subject to change. I have three items on the agenda so far so I'd like to hear what else is potentially out there. A. 3761 revision B. ENUMservice template and procedures. C. WG next steps and wind down time tables. > -----Original Message----- > From: IETF Agenda [mailto:agenda@ietf.org] > Sent: Friday, February 09, 2007 6:00 PM > To: ietf-announce@ietf.org > Subject: 68th IETF - DRAFT Meeting Agenda > > The DRAFT agenda for the 68th IETF Meeting can be found at: > http://www.ietf.org/meetings/68-IETF.html > > Please note that the agenda is in draft form and is subject to change > substantially before the final agenda is published on Monday, February > 26th. > > IETF Secretariat > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ 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 Feb 12 12:47:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGfFB-00077d-5x; Mon, 12 Feb 2007 12:45:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGfFA-000779-7k; Mon, 12 Feb 2007 12:45:36 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGfF8-0002D1-Ru; Mon, 12 Feb 2007 12:45:36 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l1CHjK1a023539; Mon, 12 Feb 2007 09:45:26 -0800 From: "Richard Shockey" To: Date: Mon, 12 Feb 2007 12:45:16 -0500 Message-ID: <010401c74ecd$8f7dd880$95201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdOzY3BxSi5k/k4QYeSlie9Y3uAOQ== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: enum@ietf.org, speermint@ietf.org Subject: [Enum] There will not be a Official BOF on PEPPERMINT at IETF Prague X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org The IESG has decided not to hold a BOF on PEPPERMINT "at this time". There are many reasons for this, principally scheduling, which is rather complex this cycle. This action does not imply that our problem statement is bad or that there is not a clear indication that there are folks who want to move forward on the work. We all know this work is important and needs to get done. This list will remain open. What I'm going to try and do is see if I can get a room in Prague for an unofficial BOF so we can collectively discuss what the next steps are before Chicago and we resubmit a BOF plan and agenda. Certainly one of the things we should do before Chicago is refine the current Requirements proposals into something more well defined and coherent. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org Skype:"rshockey101" PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 16 16:14:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAOl-0006SX-Bs; Fri, 16 Feb 2007 16:13:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAOk-0006Rq-12 for enum@ietf.org; Fri, 16 Feb 2007 16:13:42 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIAOg-0006SQ-Vt for enum@ietf.org; Fri, 16 Feb 2007 16:13:42 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l1GLDLXW014141 for ; Fri, 16 Feb 2007 13:13:33 -0800 From: "Richard Shockey" To: Date: Fri, 16 Feb 2007 16:13:15 -0500 Message-ID: <022701c7520f$46e8d6c0$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdSBYtx8RFIfinqSQe2qYCz4B8DzQ== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.4 (+) X-Scan-Signature: 441f623df000f14368137198649cb083 Subject: [Enum] MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTURE ENUM IN THE ENUM WORKING GROUP X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org FYI this was just sent to the IAB/IESG. MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTURE ENUM IN THE ENUM WORKING GROUP Dear Colleagues, We, the ENUM Working Group chairs want to alert the IESG as well as the IAB to some unusual and significant considerations involving several documents the ENUM WG has recently approved and submitted to the IESG for approval as Informational or Proposed Standards. The documents listed below [Appendix A] deal with issues involving what has been referred to as Infrastructure ENUM. We believe it is necessary to alert the larger IETF Management community to their significance before IESG action is taken on them and we believe the documents also point to actions that should be taken by the IAB as well. This memorandum outlines the issues involved with these documents, a general back ground of their historical context and some specific recommendations that the IESG/IAB should undertake in its relationship with ITU-T and ITU Study Group 2. To understand why these documents are particularly significant, it is worth pointing out a little history about the development and deployment of RFC 2916 and its successor RFC 3761. When RFC 2916/3761 was approved there was a highly significant IANA instruction included in the RFC. {Quote from RFC 3761} "4. IANA Considerations This memo requests that the IANA delegate the E164.ARPA domain following instructions to be provided by the IAB. Names within this zone are to be delegated to parties according to the ITU recommendation E.164. The names allocated should be hierarchic in accordance with ITU Recommendation E.164, and the codes should assigned in accordance with that Recommendation. Delegations in the zone e164.arpa (not delegations in delegated domains of e164.arpa) should be done after Expert Review, and the IESG will appoint a designated expert." This clause triggered a long and complicated process of negotiations with the ITU-T Study Group 2 that resulted in a series of agreements between the IETF and the ITU regarding how delegations within e164.arpa were to be accomplished. These negotiations were documented in the following: The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2) ftp://ftp.rfc-editor.org/in-notes/rfc3245.txt Liaison to IETF/ISOC on ENUM ftp://ftp.rfc-editor.org/in-notes/rfc3026.txt The negotiation process was extremely difficult and resulted is several compromises that continue to complicate the global deployment of RFC 3761, such as the processes by which zone administrators are selected. The ITU has never fully reconciled itself with the e164.arpa zone administration system though, in practice, there have been few disputes. Of particular concern is that the IAB/ITU agreements on the administration of e164.arpa are still considered "Interim Procedures" and consequently subject to cancellation at any time. This, in our opinion, continues to have a negative effect on ENUM global deployments and zone delegations. [ITU ENUM procedures] http://www.itu.int/ITU-T/inr/enum/procedures.html ENUM was envisioned as a global public service where the customer or the telephone number holder would have to "opt-in" before their information would be listed within the public DNS zone that other users would access. This mode of operation was supported by many government regulators as a natural extension of policy on Number Portability. The deployment of RFC 3761 under these principals is generally referred to as "Public ENUM". [Historical over view of Number Portability] Number Portability in the Global Switched Telephone Network (GSTN): An Overview http://www.ietf.org/rfc/rfc3482.txt In the intervening years since RFC 3761 was approved in 2004 there has been a considerable shift in the development and deployment of SIP based VoIP in general and the emerging concept of Next Generation Networks [NGN]. Many national communications carriers and new incumbent carriers are redesigning their voice networks to use TCP/IP and SIP. Some global carriers have announced plans to "shut off" the PSTN completely. This has created a new set of requirements for number translation resolution and signaling in emerging NGN networks to support "All Call Query" on call or session origination. This created the requirements for what is commonly referred to as "Infrastructure ENUM". The central premise behind Infrastructure ENUM is that it is the carrier of record that issues the phone number vs the consumer or number holder that would be authoritative for writing the zone files with NAPTR records that designate "points of network interconnection" between real time communications service providers. Many global carriers have come to look on the technology of RFC 3761 as central to internally resolving phone numbers to URI's in order to facilitate internal network routing between network soft switches as well as facilitate network to network service interconnection. An added benefit has been to replace protocol functions now exclusively associated with SS7/C7 signaling. ENUM related work is currently under active discussion in such fora as 3GPP, CableLabs, ETSI, ITU and ATIS. The IETF ENUM WG continues to make significant contributions to that effort. ENUM related issues have also spawned the SPEERMINT WG in the IETF RAI Area. SPEERMINT is specifically chartered to assist in developing tools and best current practices to assist in carrier to carrier peering and interconnection when ENUM is used to resolve the telephone number to a URI. Global service providers looked at the administrative procedures surrounding the various zones of e164.arpa and correctly concluded that RFC 3761 could not be relied upon to provide a truly authoritative database of E.164 named end points since the data relied upon the explicit "opt-in" by the user as opposed to the carrier of record for a particular telephone number. Should significant numbers of consumers "opt-out" of a Public ENUM system, it would be impossible for service providers to route sessions in an accurate manner and would therefore require the use of SS7/C7 signaling mechanisms indefinitely. The ENUM Working group has been discussing for several years now what is necessary to actually implement an Infrastructure ENUM system. The logical place to start was to adapt the e164.arpa domain for that purpose but for countless technical reasons that has proved to be a challenge. There is consensus within the ENUM community and ENUM WG that the requirements for User and Infrastructure ENUM are orthogonal to each other and the one approach would be to designate an entirely separate domain [ie164.arpa] for Infrastructure ENUM purposes only. This approach is outlined in: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-04.txt. This approach represented a WG consensus after the ENUM WG meeting at IETF 65 in Dallas in early 2006 as outlined in the following ENUM message. http://www1.ietf.org/mail-archive/web/enum/current/msg04848.html Another school of thought believes that the use of the global DNS for discovery of carrier to carrier points of interconnection is a misuse of the DNS and that various "Private ENUM" approaches are the ultimate solution. Many carriers are deeply concerned that exposure of points of interconnection in the global DNS could expose their networks to various forms of attacks that would compromise the quality and reliability of real time voice communications. Private ENUM is generally regarded as one or more technologies that permit service providers to exchange phone number to URI data to find points of interconnection in private secure manner. Any mutually agreed to domain could be used and access control to the data would be strictly enforced. Private ENUM could take several forms including maintaining a full and complete cache of an authoritative telephone number database within the service providers network boundaries or permitting queries via SIP Redirect or RFC 3761 to a centralized registry or database so long at the data was not visible or accessible by the general public. All of the various approaches however stress that there is a strict division between the concept of a "Public ENUM" where the end user is in control of the zone files and Infrastructure ENUM or Private ENUM, where the service provider of record is in control. There is also near universal agreement that both concepts need to exist in parallel with each other. The larger issue these documents [Appendix A] raise is what is the appropriate role the IETF can and should play in defining relationships between real time application service providers? The IESG and IAB should be aware that by approving the documents listed below may mean that the IETF is endorsing the idea that a new domain or sub domain under .arpa will be required for Infrastructure ENUM. This domain would be under the control of carriers only and the zone delegations would likely be handled in a similar manner to that of e164.arpa. There is some question about the viability of Infrastructure ENUM concept in general, not only for security reasons previously stated, but in light of many Private ENUM initiatives sponsored by 3GPP, CableLabs and commercial firms. We do not advocate any particular approach for service providers to take Infrastructure or Private. Ultimately that is not the concern of the IETF. Such issues will be properly resolved in the market place. The issues IAB and IESG should consider as to what are the appropriate roles of the IETF and the ITU in developing standards appropriate to governing relationships between service providers. IETF can and must define protocols that a carrier can use to create real time communication and facilitate interconnection over IP networks but it does not seem appropriate for the IETF to define a specific Carrier Infrastructure ENUM domain, carrier business rules or carrier to carrier business structures. We believe this crosses the boundary of what is and is not appropriate work for the IETF to undertake. This seems a perfectly reasonable conclusion in light of the IETF recognizing the role that ICANN plays in defining the business rules the domain name business while the IETF defines the actual DNS protocols and DNS provisioning tools. We, the ENUM WG chairs believe we have preformed our task in managing the documents listed below to WG consensus, though we both believe there are significant architectural issues with the combined use of e164.arpa for both User and Infrastructure purposes and in particular the use of the so called Branch Location Record within e164.arpa. [http://www.ietf.org/internet-drafts/draft-ietf-enum-branch-location-record- 02.txt ] We strongly recommend expert DNS review of this document and the associated draft-ietf-enum-combined-03.txt. The chairs do not recommend either of these documents should Standards Track RFC's but adopted as Experimental only. Over the years the ENUM WG has looked at several other technical solutions that were ultimately rejected, such as a branch "below" the full E.164 number in the DNS tree using either non-terminal NAPTR Resource Records or new suggested resource record types, such as the one discussed in draft-ietf-enum-uri-00.txt. These mechanisms were rejected due to the requirement that a carrier of record would have to rely on DNS hosting by some external party for any intermediary zone between the Country Code zone [cc.e164.arpa] and the location of the NAPTR record that referred to the service they run. At IETF 67 in San Diego, the ENUM WG chairs held discussions with Lesile Daigle, Olaf Kolkman, John Klensin, and Scott Bradner (in his capacity as IETF - ITU liaison) and many others voicing our concerns about these documents. We also kept our RAI Area Directors Jon Peterson and Cullen Jennings appraised of these discussions. In these discussions, a general set of ideas emerged which we, the ENUM WG chairs completely support. The consensus is that the IETF should not attempt to define a specific domain for Infrastructure ENUM purposes. If such a domain should be defined at all it should be a result of discussions by ITU Study Group 2 which is authoritative for the E.164 plan. In addition there was a consensus that a mutual understanding of what are the appropriate roles and responsibilities between IETF and ITU-T needs to be developed as it may relate to these emerging carrier to carrier business models. A potential set of guidelines might include: 1. The IETF continue to be responsible for the DNS, including definition of Resource Records, and the base ENUM specification as defined for "Public ENUM" (or just "ENUM") in RFC 3761 and its successors where the E.164 number holder is in control over the information in global DNS, and that information is made available through the DNS, to anyone on the Internet. 2. The IAB continues to be responsible to decisions related to the namespace in the DNS according to the existing exchange of letters between IAB, ITU-T, ITU-T TSB and the registry for ENUM (as appointed by the IAB, currently RIPE NCC). 3. The IETF will continue to develop standards and profiles that facilitate the exchange of real time SIP sessions including applications that assist in the provisioning of telephone number to URI data to various network elements. 4. The ITU-T should take responsibility for "Infrastructure ENUM" where goals are resolve the issues described in draft-ietf-enum-infrastructure-04.txt. ITU-T should be responsible for business relationships that involve bi-lateral or multilateral agreements between service providers. 5. The IAB should strongly suggest that the ITU-T SG2 Interim Agreements on the delegation of the zones for e164.apra be made permanent. In conclusion, should the management of the IETF decide that this consensus is appropriate then we recommend an appropriate Liaison Letter should be sent to ITU SG2 outlining these views as soon as practically possible. Though these documents raise some unique issues for our community, the working group chairs are immensely proud of the overall accomplishments of the ENUM WG in general. We both have confidence that the RFC's currently delivered by the ENUM WG now and in the future will be deployed by service provider networks world wide. Sincerely, Richard Shockey Patrik Faltstrom Appendix A: INFRASTRUCTURE ENUM DOCUMENTS UNDER DISCUSSION Title : Infrastructure ENUM Requirements Author(s) : S. Lind, P. Pfautz Filename : draft-ietf-enum-infrastructure-enum-reqs-03.txt Pages : 7 Date : 2006-8-8 This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum-reqs -03.txt Title : The ENUM Branch Location Record Author(s) : O. Lendl Filename : draft-ietf-enum-branch-location-record-02.txt Pages : 9 Date : 2006-12-12 This documents defines the ENUM Branch Location record (EBL) which is used to indicate where the ENUM tree for special ENUM application is located. The primary application for the EBL record is to provide a temporary solution for the Infrastructure ENUM tree location. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-branch-location-record-0 2.txt Title : Combined User and Infrastructure ENUM in the e164.arpa tree Author(s) : M. Haberler, R. Stastny Filename : draft-ietf-enum-combined-04.txt Pages : 12 Date : 2007-1-24 This memo defines an interim solution for Infrastructure ENUM to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice until the long-term solution is approved. This interim solution will be deprecated after approval of the long-term solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-combined-04.txt Title : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM Author(s) : J. Livingood, et al. Filename : draft-ietf-enum-infrastructure-05.txt Pages : 6 Date : 2007-1-24 This document defines a use case as well as a proposal for a parallel namespace to "e164.arpa" as defined in RFC3761, to be used for Infrastructure ENUM purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-05.txt Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org Skype:"rshockey101" PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Feb 16 16:33:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAh7-0003lO-7e; Fri, 16 Feb 2007 16:32:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAh6-0003k4-Cu for enum@ietf.org; Fri, 16 Feb 2007 16:32:40 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIAh5-0003Lq-Ri for enum@ietf.org; Fri, 16 Feb 2007 16:32:40 -0500 Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.30317700; Fri, 16 Feb 2007 16:32:16 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:32:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] The larger issue here. Date: Fri, 16 Feb 2007 16:32:15 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602B3BED5@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] The larger issue here. Thread-Index: AcdEpcz4Ug50d5rKRVGQxZ6C/ipwvQADEAx1AAzmV4AAAUYS0AAZU/sgAACS/gADL5P78A== References: <45BDFC1A.6080108@cisco.com> <0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com><45BF5AC6.7020803@cisco.com><45BF6AB1.1000802@e164.org><0CED449E95A92A42991EB71B778C17BF047BC532@TSMAIL2.ad.tri.sbc.com><45BF9D90.3050008@cisco.com><32755D354E6B65498C3BD9FD496C7D462C4C6C@oefeg-s04.oefeg.loc><011001c744e6$a7f4e5c0$22f0a544@cis.neustar.com><0CED449E95A92A42991EB71B778C17BF047BCC95@TSMAIL2.ad.tri.sbc.com><001b01c74550$bb6f6b10$22f0a544@cis.neustar.com> <0CED449E95A92A42991EB71B778C17BF047FAE62@TSMAIL2.ad.tri.sbc.com> From: "Livingood, Jason" To: "Jackson, James" , , "Stastny Richard" , "Paul Kyzivat" X-OriginalArrivalTime: 16 Feb 2007 21:32:16.0443 (UTC) FILETIME=[EE02C8B0:01C75211] X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 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: , Errors-To: enum-bounces@ietf.org First off, do not interpret my comments as saying your I-D may not move forward. There are all sorts of enumservices and not everyone needs to agree with each one. If you have a valid app, put in an I-D so the community can really comment and add to your idea. =20 My comments simply come from the perspective of an implementer. I operate a SIP-based IP voicemail system in my group with a very large number of mailboxes and was just considering this question of exchanging voicemail between service providers. =20 You are correct in pointing out that many voicemail providers do not support VPIM. When I personally looked at how to connect non-VPIM-compliant systems it seemed a bit of a pain compared to ones that were VPIM-compliant. But I will tell you that I don't know of any big implementations out there using VPIM at scale (if anyone does - please chime in). It seems to be one of those things some software companies decided to support but no one is making much use of now. Whenever I have seen that, even these early s/w implementations may not work right in version 1. I think that will change in the next few years as providers peer real-time traffic. It may even be that non-real-time traffic like voicemail is a way to dip the toe into the water, so to speak. =20 A non-VPIM draft could certainly have value to some folks and who knows, may even win out in the marketplace of implementers in the end. I would actually ENCOURAGE you to submit a draft. Getting a lot of feedback is actually GOOD. You should be more worried when you hear silence. ;-) I am happy to help review the doc before or after submission and add some use cases or other content or whatever to it if you like. Jason Livingood > -----Original Message----- > From: Jackson, James [mailto:james_jackson@labs.att.com]=20 > Sent: Wednesday, January 31, 2007 11:56 AM > To: richard@shockey.us; Stastny Richard; Paul Kyzivat > Cc: enum@ietf.org > Subject: RE: [Enum] The larger issue here. >=20 >=20 > It's fair for the IETF to assume that Unified Messaging=20 > platforms supporting voicemail/fax/e-mail should all do VPIM.=20 > However, I wouldn't say it's correct to assume that all=20 > voicemail systems will be Unified Messaging platforms, or for=20 > that matter that voicemail and e-mail would even necessarily=20 > be provided by the same entity. >=20 > Would the enumservices fax (for PSTN) and voice (for PSTN) be=20 > considered standards ? I suppose we could call T.30 the=20 > standard for fax. So then this looks more like the voice=20 > service but for non-interactive sessions. > Perhaps an alpha-pager using the TAP protocol would be fine=20 > since there is a more defined application-level standard ? >=20 > Based on the feedback, I don't think I'll be submitting a=20 > draft :) I just want to understand the logic for why a=20 > particular contribution would or would not be useful. I=20 > apologize if this discussion is viewed as disruptive to the=20 > group. Anyone can certainly respond to me off-line if they like. >=20 > James >=20 > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Wednesday, January 31, 2007 9:59 AM > To: Jackson, James; 'Stastny Richard'; 'Paul Kyzivat' > Cc: enum@ietf.org > Subject: RE: [Enum] The larger issue here. >=20 >=20 > Because the IETF defines the voice mail service for the PSTN=20 > as the VPIM > standard. We generally don't go around creating enum services=20 > for things > that are not defined as a standard. >=20 > Frankly, from the comments you are seeing I would not be=20 > optimistic on > the > chances a draft along the lines you propose would make it through the > WG. >=20 > > -----Original Message----- > > From: Jackson, James [mailto:james_jackson@labs.att.com] > > Sent: Tuesday, January 30, 2007 10:58 PM > > To: richard@shockey.us; Stastny Richard; Paul Kyzivat > > Cc: enum@ietf.org > > Subject: RE: [Enum] The larger issue here. > >=20 > >=20 > > That's fine. RFC4238 works great if the voicemail system implements > VPIM > > - most do not. The VPIM service defines e-mail access to voicemail > much > > like the ifax service defines e-mail access to fax.=20 > However, there is > > also a fax service for PSTN. If someone could shed some=20 > light on why a > > voicemail service for PSTN is unreasonable that would be=20 > appreciated. > >=20 > > Thanks, > > James > >=20 > > -----Original Message----- > > From: Richard Shockey [mailto:richard@shockey.us] > > Sent: Tuesday, January 30, 2007 9:20 PM > > To: 'Stastny Richard'; 'Paul Kyzivat' > > Cc: enum@ietf.org > > Subject: [Enum] The larger issue here. > >=20 > >=20 > > Chair hat off .. I agree with Mr. Stastny and Mr. Kyzivat=20 > as well. And > > with > > the argument that Jason Livingood makes that this is really=20 > covered By > > RFC > > 4238. > >=20 > > Chair hat on... > >=20 > > The larger issue is one we will need to deal with in Prague is that > this > > work group is winding down. With the Infrastructure ENUM=20 > issues now in > > the > > hands of "higher authority" we have only one real task which is the > > advancement of RFC 3761 to Draft. > >=20 > > We do need to declare victory here and start to close up shop unless > > there > > is compelling technical reasons not to do so and frankly I have not > seen > > one > > recently. > >=20 > >=20 > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Tuesday, January 30, 2007 4:03 PM > > > To: Paul Kyzivat > > > Cc: enum@ietf.org > > > Subject: Re: [Enum] Proposal for new enumservice=20 > "voicemail", using > > SIP > > > URI > > > > > > I fully support this argument > > > Richard > > > > > > ________________________________ > > > > > > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Gesendet: Di 30.01.2007 20:33 > > > An: Jackson, James > > > Cc: enum@ietf.org; Shawn Pouliotte; Duane > > > Betreff: Re: [Enum] Proposal for new enumservice=20 > "voicemail", using > > SIP > > > URI > > > > > > > > > > > > A fundamental problem I have with using ENUM is that it is > > fundamentally > > > tied to cases where the address of the callee is an E.164 number. > That > > > is fine in cases where the problem is intrinsically tied=20 > to the use > of > > a > > > phone number. But it is an unappealing solution to any=20 > problem that > > also > > > applies when the callee is identified by a SIP URI. I=20 > certainly see > > that > > > to be the case here. I just as well may want to get to the VM for > > > sip:alice@atlanta.com as for tel:+12125551234. > > > > > > BTW, that also means that indicating you want VM by prefixing the > > > address with *99 isn't an ideal interface. I guess it is *an* > > interface, > > > that might be suitable for UAs that can only deal with=20 > numbers. But > > > another interface will be needed for alphanumeric calling. I don't > > think > > > the concept of adding to the callee's URI is appropriate in this > case. > > > Whatever technique does work for alphanumeric URIs would hopefully > > work > > > for phone numbers as well. In general a sip UA supports a=20 > telephone > > > dialing interface already needs to recognize and locally process > some > > > star codes, so it ought to be able to do so for this one too. > > > > > > Paul > > > > > > Jackson, James wrote: > > > > I have been thinking about the PSTN service in another context, > but > > > > perhaps it is more generally applicable here. Specifically, > consider > > the > > > > case where the called number is purely PSTN and you=20 > want to reach > > their > > > > voicemail. In theory an ENUM query could return the Call > Forwarding > > > > Number and the call could be forwarded out a Media Gateway. The > > mailbox > > > > would be indicated by the Redirecting Number. > > > > > > > > James > > > > > > > > -----Original Message----- > > > > From: Duane [mailto:duane@e164.org] > > > > Sent: Tuesday, January 30, 2007 9:57 AM > > > > To: Paul Kyzivat > > > > Cc: Jackson, James; enum@ietf.org; Shawn Pouliotte > > > > Subject: Re: [Enum] Proposal for new enumservice "voicemail", > using > > SIP > > > > URI > > > > > > > > Paul Kyzivat wrote: > > > > > > > >> The above assumes that the VM system is arranged in a suitable > way. > > > >> Notably that it has a unique and globally routable URI=20 > of its own > > for > > > >> each mailbox (possibly by a common URI plus a parameter > identifying > > > > the > > > >> mailbox). Or at least that there is a single globally routable > URI > > for > > > > > > > >> the VM server and that the caller will be satisfied with having > to > > > > enter > > > >> the target phone number a second time. > > > > > > > > While I won't go into the merits of having such an enum service, > > > > (although couldn't it just be a sub-type of pstn?) it=20 > seems pretty > > > > trivial to me to be just another SIP URI that could easily be > setup, > > > > both in DNS and in most/all software driven PBXs. > > > > > > > > eg > > > > > > > > sip:123456@example.com > > > > voicemail:vm-123456@example.com > > > > > > > > On the PBX you simply look for vm- strip it and send=20 > the call into > > the > > > > voicemail system. > > > > > > > > eg > > > > > > > > 100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\1@example.com!" . > > > > 100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\1@example.com!" . > > > > > > > > > > _______________________________________________ > > > 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 > >=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 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Feb 17 09:44:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIQm0-0002w1-G4; Sat, 17 Feb 2007 09:42:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIQly-0002uE-UK for enum@ietf.org; Sat, 17 Feb 2007 09:42:46 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HIQlu-0001vG-El for enum@ietf.org; Sat, 17 Feb 2007 09:42:46 -0500 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] MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTUREENUM IN THE ENUM WORKING GROUP Date: Sat, 17 Feb 2007 15:37:19 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C7C@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTUREENUM IN THE ENUM WORKING GROUP Thread-Index: AcdSBYtx8RFIfinqSQe2qYCz4B8DzQAm5Vp2 References: <022701c7520f$46e8d6c0$22f0a544@cis.neustar.com> From: "Stastny Richard" To: , X-Spam-Score: 1.0 (+) X-Scan-Signature: ceb20e3ccfd90d068e2ad6c8a4781b53 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: , Errors-To: enum-bounces@ietf.org I have some concerns with this memorandum, which needs to be discussed in Prague The first one: =20 >3. The IETF will continue to develop standards and profiles that = facilitate >the exchange of real time SIP sessions including applications that = assist in >the provisioning of telephone number to URI data to various network >elements. So IETF is dealing in future with SIP only ? =20 Richard=20 =20 ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Fr 16.02.2007 22:13 An: enum@ietf.org Betreff: [Enum] MEMORANDUM RELATING TO ISSUES SURROUNDING = INFRASTRUCTUREENUM IN THE ENUM WORKING GROUP FYI this was just sent to the IAB/IESG. MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTURE ENUM IN THE = ENUM WORKING GROUP Dear Colleagues,=20 We, the ENUM Working Group chairs want to alert the IESG as well as the = IAB to some unusual and significant considerations involving several = documents the ENUM WG has recently approved and submitted to the IESG for approval = as Informational or Proposed Standards. The documents listed below [Appendix A] deal with issues involving what = has been referred to as Infrastructure ENUM. We believe it is necessary to alert the larger IETF Management community to their significance before = IESG action is taken on them and we believe the documents also point to = actions that should be taken by the IAB as well. This memorandum outlines the issues involved with these documents, a = general back ground of their historical context and some specific = recommendations that the IESG/IAB should undertake in its relationship with ITU-T and = ITU Study Group 2.=20 To understand why these documents are particularly significant, it is = worth pointing out a little history about the development and deployment of = RFC 2916 and its successor RFC 3761. When RFC 2916/3761 was approved there was a highly significant IANA instruction included in the RFC. {Quote from RFC 3761} "4. IANA Considerations This memo requests that the IANA delegate the E164.ARPA domain = following instructions to be provided by the IAB. Names within this zone are to = be delegated to parties according to the ITU recommendation E.164. The = names allocated should be hierarchic in accordance with ITU Recommendation = E.164, and the codes should assigned in accordance with that Recommendation. Delegations in the zone e164.arpa (not delegations in delegated = domains of e164.arpa) should be done after Expert Review, and the IESG will = appoint a designated expert." This clause triggered a long and complicated process of negotiations = with the ITU-T Study Group 2 that resulted in a series of agreements between = the IETF and the ITU regarding how delegations within e164.arpa were to be accomplished. These negotiations were documented in the following: The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 = (SG2) ftp://ftp.rfc-editor.org/in-notes/rfc3245.txt Liaison to IETF/ISOC on ENUM ftp://ftp.rfc-editor.org/in-notes/rfc3026.txt The negotiation process was extremely difficult and resulted is several compromises that continue to complicate the global deployment of RFC = 3761, such as the processes by which zone administrators are selected. The ITU has never fully reconciled itself with the e164.arpa zone administration system though, in practice, there have been few disputes. Of particular concern is that the IAB/ITU agreements on the = administration of e164.arpa are still considered "Interim Procedures" and consequently subject to cancellation at any time. This, in our opinion, continues to = have a negative effect on ENUM global deployments and zone delegations. [ITU ENUM procedures] http://www.itu.int/ITU-T/inr/enum/procedures.html ENUM was envisioned as a global public service where the customer or the telephone number holder would have to "opt-in" before their information would be listed within the public DNS zone that other users would = access. This mode of operation was supported by many government regulators as a natural extension of policy on Number Portability. The deployment of RFC 3761 under these principals is generally referred to as "Public ENUM". [Historical over view of Number Portability] Number Portability in the Global Switched Telephone Network (GSTN): An Overview http://www.ietf.org/rfc/rfc3482.txt In the intervening years since RFC 3761 was approved in 2004 there has = been a considerable shift in the development and deployment of SIP based VoIP = in general and the emerging concept of Next Generation Networks [NGN]. = Many national communications carriers and new incumbent carriers are = redesigning their voice networks to use TCP/IP and SIP. Some global carriers have announced plans to "shut off" the PSTN completely. This has created a = new set of requirements for number translation resolution and signaling in emerging NGN networks to support "All Call Query" on call or session origination. This created the requirements for what is commonly referred to as "Infrastructure ENUM". The central premise behind Infrastructure ENUM is that it is the carrier of record that issues the phone number vs the consumer or number holder that would be authoritative for writing the = zone files with NAPTR records that designate "points of network = interconnection" between real time communications service providers. Many global carriers have come to look on the technology of RFC 3761 as central to internally resolving phone numbers to URI's in order to facilitate internal network routing between network soft switches as = well as facilitate network to network service interconnection. An added benefit = has been to replace protocol functions now exclusively associated with = SS7/C7 signaling. ENUM related work is currently under active discussion in = such fora as 3GPP, CableLabs, ETSI, ITU and ATIS. The IETF ENUM WG continues = to make significant contributions to that effort. ENUM related issues have also spawned the SPEERMINT WG in the IETF RAI = Area. SPEERMINT is specifically chartered to assist in developing tools and = best current practices to assist in carrier to carrier peering and interconnection when ENUM is used to resolve the telephone number to a = URI. Global service providers looked at the administrative procedures = surrounding the various zones of e164.arpa and correctly concluded that RFC 3761 = could not be relied upon to provide a truly authoritative database of E.164 = named end points since the data relied upon the explicit "opt-in" by the user = as opposed to the carrier of record for a particular telephone number. Should significant numbers of consumers "opt-out" of a Public ENUM = system, it would be impossible for service providers to route sessions in an accurate manner and would therefore require the use of SS7/C7 signaling mechanisms indefinitely. The ENUM Working group has been discussing for several years now what is necessary to actually implement an Infrastructure ENUM system. The = logical place to start was to adapt the e164.arpa domain for that purpose but = for countless technical reasons that has proved to be a challenge. There is consensus within the ENUM community and ENUM WG that the requirements for User and Infrastructure ENUM are orthogonal to each = other and the one approach would be to designate an entirely separate domain [ie164.arpa] for Infrastructure ENUM purposes only. This approach is outlined in: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-04.txt= . This approach represented a WG consensus after the ENUM WG meeting at = IETF 65 in Dallas in early 2006 as outlined in the following ENUM message. http://www1.ietf.org/mail-archive/web/enum/current/msg04848.html Another school of thought believes that the use of the global DNS for discovery of carrier to carrier points of interconnection is a misuse of = the DNS and that various "Private ENUM" approaches are the ultimate = solution. Many carriers are deeply concerned that exposure of points of interconnection in the global DNS could expose their networks to various forms of attacks that would compromise the quality and reliability of = real time voice communications. Private ENUM is generally regarded as one or more technologies that = permit service providers to exchange phone number to URI data to find points of interconnection in private secure manner. Any mutually agreed to domain could be used and access control to the data would be strictly enforced. Private ENUM could take several forms including maintaining a full and complete cache of an authoritative telephone number database within the service providers network boundaries or permitting queries via SIP = Redirect or RFC 3761 to a centralized registry or database so long at the data = was not visible or accessible by the general public. All of the various approaches however stress that there is a strict = division between the concept of a "Public ENUM" where the end user is in control = of the zone files and Infrastructure ENUM or Private ENUM, where the = service provider of record is in control. There is also near universal agreement that both concepts need to exist in parallel with each other. The larger issue these documents [Appendix A] raise is what is the appropriate role the IETF can and should play in defining relationships between real time application service providers? The IESG and IAB should be aware that by approving the documents listed below may mean that the IETF is endorsing the idea that a new domain or = sub domain under .arpa will be required for Infrastructure ENUM. This domain would be under the control of carriers only and the zone delegations = would likely be handled in a similar manner to that of e164.arpa. There is some question about the viability of Infrastructure ENUM = concept in general, not only for security reasons previously stated, but in light = of many Private ENUM initiatives sponsored by 3GPP, CableLabs and = commercial firms.=20 We do not advocate any particular approach for service providers to take Infrastructure or Private. Ultimately that is not the concern of the = IETF. Such issues will be properly resolved in the market place. The issues IAB and IESG should consider as to what are the appropriate = roles of the IETF and the ITU in developing standards appropriate to governing relationships between service providers. IETF can and must define protocols that a carrier can use to create real time communication and facilitate interconnection over IP networks but = it does not seem appropriate for the IETF to define a specific Carrier Infrastructure ENUM domain, carrier business rules or carrier to carrier business structures. We believe this crosses the boundary of what is and is not appropriate = work for the IETF to undertake. This seems a perfectly reasonable conclusion = in light of the IETF recognizing the role that ICANN plays in defining the business rules the domain name business while the IETF defines the = actual DNS protocols and DNS provisioning tools. We, the ENUM WG chairs believe we have preformed our task in managing = the documents listed below to WG consensus, though we both believe there are significant architectural issues with the combined use of e164.arpa for = both User and Infrastructure purposes and in particular the use of the so = called Branch Location Record within e164.arpa. [http://www.ietf.org/internet-drafts/draft-ietf-enum-branch-location-reco= rd- 02.txt ]=20 We strongly recommend expert DNS review of this document and the = associated draft-ietf-enum-combined-03.txt. The chairs do not recommend either of these documents should Standards Track RFC's but adopted as Experimental only. Over the years the ENUM WG has looked at several other technical = solutions that were ultimately rejected, such as a branch "below" the full E.164 number in the DNS tree using either non-terminal NAPTR Resource Records = or new suggested resource record types, such as the one discussed in draft-ietf-enum-uri-00.txt. These mechanisms were rejected due to the requirement that a carrier of record would have to rely on DNS hosting by some external party for any intermediary zone between the Country Code zone [cc.e164.arpa] and the location of the NAPTR record that referred to the service they run. At IETF 67 in San Diego, the ENUM WG chairs held discussions with Lesile Daigle, Olaf Kolkman, John Klensin, and Scott Bradner (in his capacity = as IETF - ITU liaison) and many others voicing our concerns about these documents. We also kept our RAI Area Directors Jon Peterson and Cullen Jennings appraised of these discussions. In these discussions, a general set of ideas emerged which we, the ENUM = WG chairs completely support. The consensus is that the IETF should not attempt to define a specific domain for Infrastructure ENUM purposes. If such a domain should be = defined at all it should be a result of discussions by ITU Study Group 2 which = is authoritative for the E.164 plan. In addition there was a consensus that a mutual understanding of what = are the appropriate roles and responsibilities between IETF and ITU-T needs = to be developed as it may relate to these emerging carrier to carrier = business models. A potential set of guidelines might include: 1. The IETF continue to be responsible for the DNS, including definition = of Resource Records, and the base ENUM specification as defined for "Public ENUM" (or just "ENUM") in RFC 3761 and its successors where the E.164 = number holder is in control over the information in global DNS, and that information is made available through the DNS, to anyone on the = Internet. 2. The IAB continues to be responsible to decisions related to the = namespace in the DNS according to the existing exchange of letters between IAB, = ITU-T, ITU-T TSB and the registry for ENUM (as appointed by the IAB, currently = RIPE NCC). 3. The IETF will continue to develop standards and profiles that = facilitate the exchange of real time SIP sessions including applications that = assist in the provisioning of telephone number to URI data to various network elements. 4. The ITU-T should take responsibility for "Infrastructure ENUM" where goals are resolve the issues described in draft-ietf-enum-infrastructure-04.txt. ITU-T should be responsible for business relationships that involve bi-lateral or multilateral = agreements between service providers. 5. The IAB should strongly suggest that the ITU-T SG2 Interim Agreements = on the delegation of the zones for e164.apra be made permanent. In conclusion, should the management of the IETF decide that this = consensus is appropriate then we recommend an appropriate Liaison Letter should be sent to ITU SG2 outlining these views as soon as practically possible. Though these documents raise some unique issues for our community, the working group chairs are immensely proud of the overall accomplishments = of the ENUM WG in general. We both have confidence that the RFC's currently delivered by the ENUM WG now and in the future will be deployed by = service provider networks world wide. Sincerely, Richard Shockey Patrik Faltstrom Appendix A: INFRASTRUCTURE ENUM DOCUMENTS UNDER DISCUSSION Title : Infrastructure ENUM Requirements Author(s) : S. Lind, P. Pfautz Filename : = draft-ietf-enum-infrastructure-enum-reqs-03.txt Pages : 7 Date : 2006-8-8 =20 This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology = to facilitate interconnection of networks for E.164 number addressed = services, in particular but not restricted to VoIP (Voice over IP.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum-r= eqs -03.txt Title : The ENUM Branch Location Record Author(s) : O. Lendl Filename : draft-ietf-enum-branch-location-record-02.txt Pages : 9 Date : 2006-12-12 =20 This documents defines the ENUM Branch Location record (EBL) which is used to indicate where the ENUM tree for special ENUM application is located. The primary application for the EBL record is to provide a temporary solution for the Infrastructure ENUM tree location. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-branch-location-recor= d-0 2.txt Title : Combined User and Infrastructure ENUM in the e164.arpa tree Author(s) : M. Haberler, R. Stastny Filename : draft-ietf-enum-combined-04.txt Pages : 12 Date : 2007-1-24 =20 This memo defines an interim solution for Infrastructure ENUM to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice until the long-term solution is approved. This interim solution will be deprecated after approval of the long-term solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-combined-04.txt Title : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM Author(s) : J. Livingood, et al. Filename : draft-ietf-enum-infrastructure-05.txt Pages : 6 Date : 2007-1-24 =20 This document defines a use case as well as a proposal for a parallel namespace to "e164.arpa" as defined in RFC3761, to be used for Infrastructure ENUM purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-05.txt= Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org Skype:"rshockey101" PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ 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 Feb 17 10:23:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIROS-00071q-6D; Sat, 17 Feb 2007 10:22:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIRMp-00069U-Cl for enum@ietf.org; Sat, 17 Feb 2007 10:20:51 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIRJg-0008Q4-Mk for enum@ietf.org; Sat, 17 Feb 2007 10:17:38 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 073369B248; Sat, 17 Feb 2007 15:17:36 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Date: Sat, 17 Feb 2007 15:17:35 +0000 To: IETF ENUM WG , Richard Shockey , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Richard Stastny Subject: [Enum] MEMORANDUM 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: , Errors-To: enum-bounces@ietf.org Hi esteemed co-chairs, Richard, The status of the MEMORANDUM included in message: : is unstated, and there are open questions for clarification prior to any substantive comments. Q: Are the subscribers to this ENUM ML to assume that comments sent to this list will be considered by the recipients of the MEMORANDUM, or that comments should be copied to the IETF-gen ML, or that comments should be copied to the iesg@ietf.org and/or iab@ietf.org exploders? Richard mentioned (in an earlier post to this list) that ITU-T SG2 has an ad-hoc correspondence group awaiting incoming Liaison statements. See . Q: Is this MEMORANDUM to be used as the basis for any Liaison from IAB/IESG to the ITU-T SG2 ad-hoc correspondence group? There are many separate statements in the MEMORANDUM, and at least a summary presentation on what the situation is (and why all of it's statements are needed when considering Infrastructure ENUM) would be useful BEFORE any Liaison is issued. This is not clear at present (at least to me). Q: Is there an intention for a Liaison to be sent to the ITU-T SG2 on this topic before the Prague meeting? all the best, Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Feb 17 12:01:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HISv5-0006r4-Rt; Sat, 17 Feb 2007 12:00:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HISv5-0006qz-1M for enum@ietf.org; Sat, 17 Feb 2007 12:00:19 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HISv3-0007tW-Jy for enum@ietf.org; Sat, 17 Feb 2007 12:00:19 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l1HGxmxp005694; Sat, 17 Feb 2007 08:59:54 -0800 From: "Richard Shockey" To: "'lconroy'" , "'IETF ENUM WG'" , "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" References: Subject: RE: [Enum] MEMORANDUM Date: Sat, 17 Feb 2007 11:59:43 -0500 Message-ID: <011a01c752b5$06336c20$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdSp3UKyoc0E9wEQMCJMWGzDaxKOQACRRwg In-Reply-To: X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: 'Richard Stastny' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: lconroy [mailto:lconroy@insensate.co.uk] > Sent: Saturday, February 17, 2007 10:18 AM > To: IETF ENUM WG; Richard Shockey; Patrik F=E4ltstr=F6m > Cc: Richard Stastny > Subject: [Enum] MEMORANDUM >=20 > Hi esteemed co-chairs, Richard, > The status of the MEMORANDUM included in message: > : > is unstated, and there are open questions for clarification prior > to any substantive comments. This is a personal memorandum by Patrick and myself in our capacity as = ENUM WG chairs to IETF management. As such it has no official status. It is = not, you will note, an ID.=20 The Memorandum was posted to the list as a courtesy. You will notice I = said FYI.=20 > Q: Are the subscribers to this ENUM ML to assume that comments sent = to > this list will be considered by the recipients of the MEMORANDUM, or > that comments should be copied to the IETF-gen ML, or that comments > should be copied to the iesg@ietf.org and/or iab@ietf.org exploders? You can send any comments you want to whomever you want to.=20 However if you or any member of this list wants to comment on the = Memorandum on this list you are certainly free to do. Patrik and I can advise the IAB/IESG that an ongoing discussion of issues raised by this document is occurring on this list and any member of the IAB/IESG that wants to = monitor the discussion can do so. > Richard mentioned (in an earlier post to this list) that ITU-T SG2 > has an ad-hoc correspondence group awaiting incoming Liaison = statements. > See = . >=20 > Q: Is this MEMORANDUM to be used as the basis for any Liaison from > IAB/IESG to the ITU-T SG2 ad-hoc correspondence group? That is entirely up to IAB/IESG.=20 > There are many separate statements in the MEMORANDUM, and at least a > summary presentation on what the situation is (and why all of it's statements are needed when considering Infrastructure ENUM) would be = useful BEFORE any Liaison is issued. This is not clear at present (at least to = me). These are personal observations by myself and Patrik. Many members of = the IAB/IESG are not familiar with the context in which the Infrastructure = ENUM documents were written. We have provided them with our personal views of = the current situation with our personal recommendations.=20 > Q: Is there an intention for a Liaison to be sent to the ITU-T SG2 > on this topic before the Prague meeting? That is entirely up to the IAB/IESG but given the timing of issues and management turnover given this NOMCOM cycle I would doubt it. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Feb 17 12:28:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HITLF-0004QH-7C; Sat, 17 Feb 2007 12:27:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HITLE-0004QC-6o for enum@ietf.org; Sat, 17 Feb 2007 12:27:20 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HITLC-00042i-R6 for enum@ietf.org; Sat, 17 Feb 2007 12:27:20 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l1HHRAwi010697; Sat, 17 Feb 2007 09:27:16 -0800 From: "Richard Shockey" To: "'Stastny Richard'" , "'IETF ENUM WG'" References: <022701c7520f$46e8d6c0$22f0a544@cis.neustar.com> <32755D354E6B65498C3BD9FD496C7D462C4C7C@oefeg-s04.oefeg.loc> Subject: RE: [Enum] MEMORANDUM RELATING TO ISSUES SURROUNDINGINFRASTRUCTUREENUM IN THE ENUM WORKING GROUP Date: Sat, 17 Feb 2007 12:27:08 -0500 Message-ID: <011e01c752b8$dac3beb0$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdSBYtx8RFIfinqSQe2qYCz4B8DzQAm5Vp2AAO+SyA= In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4C7C@oefeg-s04.oefeg.loc> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Saturday, February 17, 2007 9:37 AM > To: richard@shockey.us; enum@ietf.org > Subject: Re: [Enum] MEMORANDUM RELATING TO ISSUES > SURROUNDINGINFRASTRUCTUREENUM IN THE ENUM WORKING GROUP > > I have some concerns with this memorandum, which needs > to be discussed in Prague > > The first one: > > >3. The IETF will continue to develop standards and profiles that > facilitate the exchange of real time SIP sessions including applications that assist in the provisioning of telephone number to URI data to various network elements. > > So IETF is dealing in future with SIP only? Well the only realtime session protocol the IETF is generally working on is SIP but I think I understand your point. Obviously protocol support for provisioning TN to URI mappings for non-SIP protocols like H.323 would certainly be in order. I think that is your concern here correct? > > Richard > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Feb 18 10:07:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HInam-0002SW-Mf; Sun, 18 Feb 2007 10:04:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HInak-0002SG-Ha for enum@ietf.org; Sun, 18 Feb 2007 10:04:42 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HInaj-0003ku-0o for enum@ietf.org; Sun, 18 Feb 2007 10:04:42 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l1IF4H95015504 for ; Sun, 18 Feb 2007 07:04:23 -0800 From: "Richard Shockey" To: "'IETF ENUM WG'" Date: Sun, 18 Feb 2007 10:04:09 -0500 Message-ID: <00dc01c7536e$0c67ddb0$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdTLXJSPQ1GWBRiQ8eUt7ZOxMoc8gAQICYg X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Subject: [Enum] FW: draft-enum-teluri-e212-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org FYI this should be on the ID list early next week. > > INTERNET-DRAFT Edward Lewis > February 18, 2007 NeuStar, Inc. > > E.212 Parameters for the "tel" URI > draft-enum-teluri-e212-00.txt > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware have > been or will be disclosed, and any of which he or she becomes aware will > be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering Task > Force (IETF), its areas, and its working groups. Note that other groups > may also distribute working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months and > may be updated, replaced, or obsoleted by other documents at any time. It > is inappropriate to use Internet-Drafts as reference material or to cite > them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/1id-abstracts.html > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html > > Discussion of this document should include the following list address: > Provisioning Extensions in Peering Registries for Multimedia > INTerconnection > > Abstract > > Parameters are defined in the "tel" Uniform Resource Identifier (URI) > to carry ITU E.212-related information. > > 1 Introduction > > Three parameters are defined for the tel URI [RFC3966] to permit > storage of E.212 [ITUE212] data. E.212 data has three components, > the Mobile Country Code (MCC), the Mobile Network Code (MNC), and the > Mobile Subscriber Identification Number (MSIN). Collectively, these > form the Internation Mobile Subscriber Identity. > > To store an IMSI, and therefore all three components, just one > parameter would be needed if not for concern over exposing the MSIN > in a public database like DNS. There is a need to publically view the > MCC and MNC numbers though, so individual parameters are defined for > those values. > > The parameter for the entire IMSI will be "imsi", the parameter for > the MCC will be "mcc" and the parameter for the MNC will be "mnc." > In the parlance of RFC 4694 [RFC4694], these parameters are suitable > for placement in static content. > > 2 Terminology > > The key words "MUST," "SHOULD," and "MAY" in this document are to be > interpreted as described in RFC 2119 [RFC2119]. > > 3 Formal Syntax > > The following syntax specification uses the Augmented Backus-Naur > Form (ABNF) as described in RFC 4234 [RFC4234] and defines the three > parameters, imsi, mcc, and mnc by extending the "parameter" production > rule of the "tel" URI defined in [RFC3966]. > > parameter = / imsi / mcc / mnc > imsi = ";imsi=" imsi-digits > mcc = ";mcc=" 3(DIGIT) > mnc = ";mnc=" (2(DIGIT) / 3(DIGIT)) > imsi-digits = (upto) 15(DIGIT) ; ed.note, fix this > > 4 Normative Rules > > If the imsi parameter is in use, all three values are expected to be > present. Rules for the use of the parameter's value are contained > in the ITU document defining the IMSI. > > The other two parameters, mcc and mnc are used in tandem to identify > the network serving the telephone number. > > 5 Examples > > For a telephone number +1-571-555-1000, served on a network whose MCC > is 330, MNC is 110 and MSIN is 123456789, the two "tel" URI's that > might appear with these parameters are: > > tel:+15715551000;imsi=330110123456789 > tel:+15715551000;mcc=330;mnc=110 > > 6 Security Considerations > > The one concern raised in this document is the potential concern over > the provacy required for the MSIN that appears in the IMSI. If the > IMSC parameter is used, the operator must understand the exposure that > may be had by the data. The full IMSI ought to be restricted to > situations in which the exposure of the MSIN is acceptable. > > To alleviate this concern, the MCC and MNC parameters are defined, these > are expected to be what appears in a pubic or otherwise widely (or > externally) distributed environment. > > 7 IANA Considerations > > This document requires no IANA actions. > > 8 Internationalization Considerations > > There are no internationalization considerations in these parameters. > All data are numeric. > > 9 References > > 9.1 Normative > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC > 3966, December 2004. > > [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax > Specifications: ABNF", RFC 4234, October 2005. > > [ITUE212] ITU-T Recommendation E.212, "The International > Identification Plan for Mobile Terminals and Mobile > Users, " May 2004. > > 9.2 Informative > > (ed.note - do I need this, i.e., should it be mentioned in IANA consid.?) > [TELREG] Jennings, C. and V. Gurbani, "The Internet Assigned Numbers > Authority (IANA) tel Uniform Resource Identifier (URI) > Parameter Registry", Work in Progress, May 2006. > > 10 Author's Address > Edward Lewis > NeuStar > 46000 Center Oak Plaza > Sterling, VA > 20166, US > > Phone: +1-571-434-5468 > EMail: ed.lewis@neustar.biz > > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > Copyright (C) The IETF Trust (2007). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors retain > all their rights. > > This document and the information contained herein are provided > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE > IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY > WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE > ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS > FOR A PARTICULAR PURPOSE. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 19 03:10:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ3a2-0006Bt-9E; Mon, 19 Feb 2007 03:09:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ3a0-0005xR-FO for enum@ietf.org; Mon, 19 Feb 2007 03:09:00 -0500 Received: from cellgate.btcellnet.net ([158.230.100.102] helo=uksthmsw001.uk.pri.o2.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJ3Zz-0005nM-3c for enum@ietf.org; Mon, 19 Feb 2007 03:09:00 -0500 Received: from uksthims001.uk.pri.o2.com (uksthims001.uk.pri.o2.com) by uksthmsw001.uk.pri.o2.com (Clearswift SMTPRS 5.1.7) with ESMTP id for ; Mon, 19 Feb 2007 08:08:52 +0000 Received: from UKSTHMSX007.uk.pri.o2.com ([172.17.62.169]) by uksthims001.uk.pri.o2.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 08:08:51 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTUREENUM IN THE ENUM WORKING GROUP Date: Mon, 19 Feb 2007 08:08:51 -0000 Message-ID: <42986C4138E81A4494E4BDEA0978CB5501C215CE@UKSTHMSX007.uk.pri.o2.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTUREENUM IN THE ENUM WORKING GROUP Thread-Index: AcdSBYtx8RFIfinqSQe2qYCz4B8DzQB9fEvQ From: "Fullbrook Kim $UK$" To: X-OriginalArrivalTime: 19 Feb 2007 08:08:51.0737 (UTC) FILETIME=[3101A090:01C753FD] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: , Errors-To: enum-bounces@ietf.org I'm not aware of any Private ENUM initiatives taking place in 3GPP. Can someone send me a relevant web link ? Kim Fullbrook O2 UK Chair, GSMA ENUM Group -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: 16 February 2007 21:13 To: enum@ietf.org Subject: [Enum] MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTUREENUM IN THE ENUM WORKING GROUP There is some question about the viability of Infrastructure ENUM concept in general, not only for security reasons previously stated, but in light of many Private ENUM initiatives sponsored by 3GPP, CableLabs and commercial firms. =20 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 below) immediately. O2 (UK) Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in Engl= and and Wales: 1743099. VAT number: GB 778 6037 85 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Feb 19 11:48:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJBfs-0002qG-3B; Mon, 19 Feb 2007 11:47:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJBfq-0002pu-C0; Mon, 19 Feb 2007 11:47:34 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJBfo-0003fU-N8; Mon, 19 Feb 2007 11:47:34 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l1JGlFDh009542; Mon, 19 Feb 2007 08:47:27 -0800 From: "Richard Shockey" To: "'IETF ENUM WG'" , "'Edward Lewis'" References: <00dc01c7536e$0c67ddb0$22f0a544@cis.neustar.com> Subject: RE: [Enum] FW: draft-enum-teluri-e212-00.txt Date: Mon, 19 Feb 2007 11:47:03 -0500 Message-ID: <005b01c75445$99b26370$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <00dc01c7536e$0c67ddb0$22f0a544@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdTLXJSPQ1GWBRiQ8eUt7ZOxMoc8gAQICYgADXJVSA= X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: iptel@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Ed the answer to your question in this draft is. A., Yes these parameters need to be registered according to the new TEL parameter registry. B. Do you intend to create a specific ENUM service associated with just these paramaters. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry Author(s) : C. Jennings, V. Gurbani Filename : draft-ietf-iptel-tel-reg-04.txt Pages : 8 Date : 2006-12-8 This document creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values. It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-04.txt > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Sunday, February 18, 2007 10:04 AM > To: 'IETF ENUM WG' > Subject: [Enum] FW: draft-enum-teluri-e212-00.txt > > > FYI this should be on the ID list early next week. > > > > > INTERNET-DRAFT Edward Lewis > > February 18, 2007 NeuStar, Inc. > > > > E.212 Parameters for the "tel" URI > > draft-enum-teluri-e212-00.txt > > > > By submitting this Internet-Draft, each author represents that any > > applicable patent or other IPR claims of which he or she is aware have > > been or will be disclosed, and any of which he or she becomes aware will > > be disclosed, in accordance with Section 6 of BCP 79. > > > > Internet-Drafts are working documents of the Internet Engineering Task > > Force (IETF), its areas, and its working groups. Note that other groups > > may also distribute working documents as Internet-Drafts. > > > > Internet-Drafts are draft documents valid for a maximum of six months > and > > may be updated, replaced, or obsoleted by other documents at any time. > It > > is inappropriate to use Internet-Drafts as reference material or to cite > > them other than as "work in progress." > > > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/1id-abstracts.html > > > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html > > > > Discussion of this document should include the following list address: > > Provisioning Extensions in Peering Registries for Multimedia > > INTerconnection > > > > Abstract > > > > Parameters are defined in the "tel" Uniform Resource Identifier (URI) > > to carry ITU E.212-related information. > > > > 1 Introduction > > > > Three parameters are defined for the tel URI [RFC3966] to permit > > storage of E.212 [ITUE212] data. E.212 data has three components, > > the Mobile Country Code (MCC), the Mobile Network Code (MNC), and the > > Mobile Subscriber Identification Number (MSIN). Collectively, these > > form the Internation Mobile Subscriber Identity. > > > > To store an IMSI, and therefore all three components, just one > > parameter would be needed if not for concern over exposing the MSIN > > in a public database like DNS. There is a need to publically view the > > MCC and MNC numbers though, so individual parameters are defined for > > those values. > > > > The parameter for the entire IMSI will be "imsi", the parameter for > > the MCC will be "mcc" and the parameter for the MNC will be "mnc." > > In the parlance of RFC 4694 [RFC4694], these parameters are suitable > > for placement in static content. > > > > 2 Terminology > > > > The key words "MUST," "SHOULD," and "MAY" in this document are to be > > interpreted as described in RFC 2119 [RFC2119]. > > > > 3 Formal Syntax > > > > The following syntax specification uses the Augmented Backus-Naur > > Form (ABNF) as described in RFC 4234 [RFC4234] and defines the three > > parameters, imsi, mcc, and mnc by extending the "parameter" production > > rule of the "tel" URI defined in [RFC3966]. > > > > parameter = / imsi / mcc / mnc > > imsi = ";imsi=" imsi-digits > > mcc = ";mcc=" 3(DIGIT) > > mnc = ";mnc=" (2(DIGIT) / 3(DIGIT)) > > imsi-digits = (upto) 15(DIGIT) ; ed.note, fix this > > > > 4 Normative Rules > > > > If the imsi parameter is in use, all three values are expected to be > > present. Rules for the use of the parameter's value are contained > > in the ITU document defining the IMSI. > > > > The other two parameters, mcc and mnc are used in tandem to identify > > the network serving the telephone number. > > > > 5 Examples > > > > For a telephone number +1-571-555-1000, served on a network whose MCC > > is 330, MNC is 110 and MSIN is 123456789, the two "tel" URI's that > > might appear with these parameters are: > > > > tel:+15715551000;imsi=330110123456789 > > tel:+15715551000;mcc=330;mnc=110 > > > > 6 Security Considerations > > > > The one concern raised in this document is the potential concern over > > the provacy required for the MSIN that appears in the IMSI. If the > > IMSC parameter is used, the operator must understand the exposure that > > may be had by the data. The full IMSI ought to be restricted to > > situations in which the exposure of the MSIN is acceptable. > > > > To alleviate this concern, the MCC and MNC parameters are defined, these > > are expected to be what appears in a pubic or otherwise widely (or > > externally) distributed environment. > > > > 7 IANA Considerations > > > > This document requires no IANA actions. > > > > 8 Internationalization Considerations > > > > There are no internationalization considerations in these parameters. > > All data are numeric. > > > > 9 References > > > > 9.1 Normative > > > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > > Requirement Levels", BCP 14, RFC 2119, March 1997. > > > > [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC > > 3966, December 2004. > > > > [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax > > Specifications: ABNF", RFC 4234, October 2005. > > > > [ITUE212] ITU-T Recommendation E.212, "The International > > Identification Plan for Mobile Terminals and Mobile > > Users, " May 2004. > > > > 9.2 Informative > > > > (ed.note - do I need this, i.e., should it be mentioned in IANA > consid.?) > > [TELREG] Jennings, C. and V. Gurbani, "The Internet Assigned > Numbers > > Authority (IANA) tel Uniform Resource Identifier (URI) > > Parameter Registry", Work in Progress, May 2006. > > > > 10 Author's Address > > Edward Lewis > > NeuStar > > 46000 Center Oak Plaza > > Sterling, VA > > 20166, US > > > > Phone: +1-571-434-5468 > > EMail: ed.lewis@neustar.biz > > > > > > Copies of IPR disclosures made to the IETF Secretariat and any > > assurances of licenses to be made available, or the result of an > > attempt made to obtain a general license or permission for the use of > > such proprietary rights by implementers or users of this > > specification can be obtained from the IETF on-line IPR repository at > > http://www.ietf.org/ipr. > > > > Copyright (C) The IETF Trust (2007). > > > > This document is subject to the rights, licenses and restrictions > > contained in BCP 78, and except as set forth therein, the authors retain > > all their rights. > > > > This document and the information contained herein are provided > > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE > > IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY > > WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE > > ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS > > FOR A PARTICULAR PURPOSE. > > > _______________________________________________ > 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 Feb 19 11:55:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJBml-0005zr-6d; Mon, 19 Feb 2007 11:54:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJBmk-0005yi-LS for enum@ietf.org; Mon, 19 Feb 2007 11:54:42 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJBmj-0005dA-8H for enum@ietf.org; Mon, 19 Feb 2007 11:54:42 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l1JGsSmH011175; Mon, 19 Feb 2007 08:54:38 -0800 From: "Richard Shockey" To: "'Fullbrook Kim $UK$'" , References: <42986C4138E81A4494E4BDEA0978CB5501C215CE@UKSTHMSX007.uk.pri.o2.com> Subject: RE: [Enum] MEMORANDUM RELATING TO ISSUES SURROUNDINGINFRASTRUCTUREENUM IN THE ENUM WORKING GROUP Date: Mon, 19 Feb 2007 11:54:19 -0500 Message-ID: <021101c75446$9bec7f80$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <42986C4138E81A4494E4BDEA0978CB5501C215CE@UKSTHMSX007.uk.pri.o2.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdSBYtx8RFIfinqSQe2qYCz4B8DzQB9fEvQABKob0A= X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Kim I'm sorry ... you are right this was my editorial mistake. Though 3GPP has several documents in the IMS architecture that reference RFC 3761 they are not sponsoring a private ENUM initiative. I meant the private ENUM architecture discussions going on in the GSM-A. Thanks for pointing this out. > -----Original Message----- > From: Fullbrook Kim (UK) [mailto:Kim.Fullbrook@O2.COM] > Sent: Monday, February 19, 2007 3:09 AM > To: enum@ietf.org > Subject: RE: [Enum] MEMORANDUM RELATING TO ISSUES > SURROUNDINGINFRASTRUCTUREENUM IN THE ENUM WORKING GROUP > > I'm not aware of any Private ENUM initiatives taking place in 3GPP. Can > someone send me a relevant web link ? > > Kim Fullbrook > O2 UK > Chair, GSMA ENUM Group > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: 16 February 2007 21:13 > To: enum@ietf.org > Subject: [Enum] MEMORANDUM RELATING TO ISSUES SURROUNDING > INFRASTRUCTUREENUM IN THE ENUM WORKING GROUP > > > > There is some question about the viability of Infrastructure ENUM > concept in > general, not only for security reasons previously stated, but in light > of > many Private ENUM initiatives sponsored by 3GPP, CableLabs and > commercial > firms. > > > > > > 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 below) immediately. > O2 (UK) Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in > England and Wales: 1743099. VAT number: GB 778 6037 85 > > > > > _______________________________________________ > 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 Feb 20 14:22:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJaXE-0001E0-KT; Tue, 20 Feb 2007 14:20:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJaXD-0001DA-Np for enum@ietf.org; Tue, 20 Feb 2007 14:20:19 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJaXC-0008NM-Bp for enum@ietf.org; Tue, 20 Feb 2007 14:20:19 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l1KJK98w011671 for ; Tue, 20 Feb 2007 11:20:15 -0800 From: "Richard Shockey" To: "'IETF ENUM WG'" Date: Tue, 20 Feb 2007 14:19:51 -0500 Message-ID: <01b801c75524$18f7b8e0$8d201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdU0SdxLv1DWC59Q3aF5vK/xCvymwAUt2GQ X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Enum] FW: [enum-wg] Thesis on Infrastructure ENUM options for the Netherlands X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org FYI this is a very interesting and well written document. > -----Original Message----- > From: enum-wg-admin@ripe.net [mailto:enum-wg-admin@ripe.net] On Behalf Of > Carsten Schiefner > Sent: Tuesday, February 20, 2007 4:25 AM > To: enum-wg@ripe.net > Subject: [enum-wg] Thesis on Infrastructure ENUM options for the > Netherlands > > Dear ENUM colleagues, > > yesterday an announcement was posted on the Dutch SIP & ENUM list > about Lennart Maris' thesis "Infrastructure > ENUM - implementation options for the Netherlands" that can be found at: > > http://isoc.nl/files/ScriptieLennartMaris.pdf > > I have had no opportunity so far to already digest it but nonetheless > wanted to share that piece of information with you. > > Best regards, > > Carsten Schiefner _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Feb 20 16:22:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJcQZ-0000Gq-C6; Tue, 20 Feb 2007 16:21:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJcQX-0000GQ-G3 for enum@ietf.org; Tue, 20 Feb 2007 16:21:33 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJcQV-0007ya-5q for enum@ietf.org; Tue, 20 Feb 2007 16:21:33 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l1KL8gdn000696 for ; Tue, 20 Feb 2007 13:08:49 -0800 From: "Richard Shockey" To: "'IETF ENUM WG'" Date: Tue, 20 Feb 2007 16:08:37 -0500 Message-ID: <012601c75533$4aa26c00$8d201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0127_01C75509.61CC6400" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AcdVMNCbec+ZVODbS9COOeX+Q54U0AAAnNog X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [Enum] FW: I-D ACTION:draft-lewis-enum-teluri-e212-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0127_01C75509.61CC6400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, February 20, 2007 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-lewis-enum-teluri-e212-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : E.212 Parameters for the "tel" URI > Author(s) : E. Lewis > Filename : draft-lewis-enum-teluri-e212-00.txt > Pages : > Date : 2007-2-20 > > Parameters are defined in the "tel" Uniform Resource Identifier (URI) > to carry ITU E.212-related information. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lewis-enum-teluri-e212-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-lewis-enum-teluri-e212-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-lewis-enum-teluri-e212-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_000_0127_01C75509.61CC6400 Content-Type: Message/External-body; name="ATT00032.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00032.dat" Content-Type: text/plain Content-ID: <2007-2-20120329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lewis-enum-teluri-e212-00.txt ------=_NextPart_000_0127_01C75509.61CC6400 Content-Type: Message/External-body; name="draft-lewis-enum-teluri-e212-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-lewis-enum-teluri-e212-00.txt" Content-Type: text/plain Content-ID: <2007-2-20120329.I-D@ietf.org> ------=_NextPart_000_0127_01C75509.61CC6400 Content-Type: text/plain; name="ATT00035.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00035.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_0127_01C75509.61CC6400 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_000_0127_01C75509.61CC6400-- From enum-bounces@ietf.org Tue Feb 20 16:22:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJcQZ-0000H0-Lv; Tue, 20 Feb 2007 16:21:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJcQZ-0000Gk-4f for enum@ietf.org; Tue, 20 Feb 2007 16:21:35 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJcQX-0007ya-Mn for enum@ietf.org; Tue, 20 Feb 2007 16:21:35 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l1KL8LXx000504 for ; Tue, 20 Feb 2007 13:08:27 -0800 From: "Richard Shockey" To: "'IETF ENUM WG'" Date: Tue, 20 Feb 2007 16:08:13 -0500 Message-ID: <012201c75533$3e04bf20$8d201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0123_01C75509.5531C460" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AcdVMNE0dZEqqWZtRAiTbCalpw4IowAAmHUg X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [Enum] FW: I-D ACTION:draft-lewis-enum-enumservice-e212-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0123_01C75509.5531C460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, February 20, 2007 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-lewis-enum-enumservice-e212-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : E.212 ENUMService Type Definition > Author(s) : E. Lewis > Filename : draft-lewis-enum-enumservice-e212-00.txt > Pages : > Date : 2007-2-20 > > This document registers the Enumservice "e212" using the URI scheme > "tel:" as per the IANA registration process defined in the ENUM > specification, RFC 3761. This Enumservice may be used to > indicate International Mobile Subscriber Information with a telephone > number. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lewis-enum-enumservice-e212- > 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-lewis-enum-enumservice-e212-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-lewis-enum-enumservice-e212-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_000_0123_01C75509.5531C460 Content-Type: Message/External-body; name="ATT00059.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00059.dat" Content-Type: text/plain Content-ID: <2007-2-20120147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lewis-enum-enumservice-e212-00.txt ------=_NextPart_000_0123_01C75509.5531C460 Content-Type: Message/External-body; name="draft-lewis-enum-enumservice-e212-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-lewis-enum-enumservice-e212-00.txt" Content-Type: text/plain Content-ID: <2007-2-20120147.I-D@ietf.org> ------=_NextPart_000_0123_01C75509.5531C460 Content-Type: text/plain; name="ATT00062.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00062.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_0123_01C75509.5531C460 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_000_0123_01C75509.5531C460-- From enum-bounces@ietf.org Tue Feb 20 16:44:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJcmL-000871-Df; Tue, 20 Feb 2007 16:44:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJcmJ-00086d-9Q for enum@ietf.org; Tue, 20 Feb 2007 16:44:03 -0500 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJcmF-0006pT-UV for enum@ietf.org; Tue, 20 Feb 2007 16:44:03 -0500 X-VirusChecked: Checked X-Env-Sender: sdlind@att.com X-Msg-Ref: server-5.tower-146.messagelabs.com!1172007838!11430439!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 23622 invoked from network); 20 Feb 2007 21:43:59 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-5.tower-146.messagelabs.com with SMTP; 20 Feb 2007 21:43:59 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l1KLhsWF018483; Tue, 20 Feb 2007 16:43:55 -0500 (EST) Received: from KCCLUST05EVS1.ugd.att.com ([135.38.164.86]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l1KLhgCu018363; Tue, 20 Feb 2007 16:43:48 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 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] FW: I-D ACTION:draft-lewis-enum-teluri-e212-00.txt Date: Tue, 20 Feb 2007 15:43:46 -0600 Message-ID: In-Reply-To: <012601c75533$4aa26c00$8d201f0a@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] FW: I-D ACTION:draft-lewis-enum-teluri-e212-00.txt Thread-Index: AcdVMNCbec+ZVODbS9COOeX+Q54U0AAAnNogAAEb2EA= References: <012601c75533$4aa26c00$8d201f0a@cis.neustar.com> From: "LIND, STEVEN D, ATTLABS" To: , "IETF ENUM WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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: