From enum-admin@ietf.org Mon Jan 8 11:16:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09144 for ; Mon, 8 Jan 2001 11:16:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29678; Mon, 8 Jan 2001 11:14:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29647 for ; Mon, 8 Jan 2001 11:14:28 -0500 (EST) Received: from rainier.illuminet.com (root@rainier.illuminet.com [192.246.48.20] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09101 for ; Mon, 8 Jan 2001 11:14:26 -0500 (EST) Received: from cirrus.illuminet.com (cirrus.illuminet.com [198.202.215.22]) by rainier.illuminet.com (8.8.8/8.8.8) with SMTP id IAA00783 for ; Mon, 8 Jan 2001 08:14:21 -0800 (PST) Received: from Olympia-Message_Server by cirrus.illuminet.com with Novell_GroupWise; Mon, 08 Jan 2001 08:14:18 -0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 08 Jan 2001 08:13:53 -0800 From: "Kevin McCandless" To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_A6FDC84A.32532685" Subject: [Enum] Status Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --=_A6FDC84A.32532685 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello: Would someone please provide me with the status of the ENUM Working Group, = such as: Are there any open issues and will a bakeoff be conducted? Also, have any thoughts to how Tier I and II databases will be handled. = On the Tier II database, could this be the current DNS registry database = with a few field modifications? Will the Tier I database only handle = country code routing? Will there be a Tier III and what would be the = function of that tier? Your input and thoughts will be greatly appreciated. Sincerely, Kevin --=_A6FDC84A.32532685 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello:
 
Would someone please provide me with the status of the ENUM Working = Group,=20 such as:  Are there any open issues and will a bakeoff be conducted?
 
Also, have any thoughts to how Tier I and II databases will be=20 handled.  On the Tier II database, could this be the current DNS = registry=20 database with a few field modifications?  Will the Tier I database = only=20 handle country code routing?  Will there be a Tier III and what would = be=20 the function of that tier?
 
Your input and thoughts will be greatly appreciated.
 
Sincerely,
 
Kevin
--=_A6FDC84A.32532685-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 8 12:41:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11863 for ; Mon, 8 Jan 2001 12:41:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01815; Mon, 8 Jan 2001 12:41:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01786 for ; Mon, 8 Jan 2001 12:41:00 -0500 (EST) Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11854 for ; Mon, 8 Jan 2001 12:40:59 -0500 (EST) Received: from dranalli ([38.136.73.86]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20010108174029.OMFA20644.hvmta01-stg@dranalli>; Mon, 8 Jan 2001 12:40:29 -0500 Message-ID: <00b601c07999$3d4ae6d0$56498826@netnumber.com> Reply-To: "Douglas Ranalli" From: "Douglas Ranalli" To: "Kevin McCandless" Cc: References: Subject: Re: [Enum] Status Date: Mon, 8 Jan 2001 12:34:22 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B3_01C0796F.542D0060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_00B3_01C0796F.542D0060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Kevin, Here's my understanding of the status of ENUM. I'm sure Richard Shockey = (Chair) will be able to clarify if I've missed anything: Status of working group: At the last IETF meeting, the ENUM WG was = declared a "success" thanks to the acceptance of RFC 2916 as a core ENUM = standard. Given this foundation, two options were considered for the = future of the ENUM working group. Option #1 was to put the WG into a = "dormant" status and wait to see if any future need might arise that = would justify reactivating the group. Option #2 was to close down the = ENUM WG. Scott Bradner (Area Director) clarified that the IETF Area = Directors would consider the issue in early 2001 and then make a = statement regarding the status of the WG. Regardless of the outcome, = the active phase of standards definition work within the ENUM WG is = concluded. Tier 1 Implementations: The ITU is holding a meeting at the end of = January in Geneva during which discussions will continue regarding the = proposal for establishing a public administration model for ENUM = services under the "e164.arpa" infrastructure domain. In addition to = work within the IETF, various countries (IETF member states) are = beginning to look at ENUM on a local level. Discussions are expected to = begin in the US in February under a newly formed ENUM Ad Hoc group = organized under the Department of State's ITAC function. In addition to = the public "e164.arpa" discussions, there are various companies = advancing trials of private ENUM implementations under different domains = as a mechanism for gaining experience with ENUM services. NetNumber has = deployed a global private ENUM system under "e164.com". Verisign and = Telcordia have deployed a 6-month ENUM trial under "enumworld.com". = NeuStar has indicated that they will deploy a trial system. Tier-2 Implementations: Multiple vendors are currently experimenting = with ENUM implementations in their products. NetNumber is actively = engaged in working with a large number of vendors on implementing ENUM = "update and resolution" capabilities into their applications. As I = understand the situation, Verisign and Telcordia are using the ENUM = World trial as a mechanism for gaining experience with Tier-2 services. = =20 Tier-3 Services: If I understand your question, you're asking "what = happens after I use Tier-1 and Tier-2 ENUM to discover an Internet = service for an end-user?" For example, once you use ENUM to discover a = SIP address for an end-user there is additional information that will be = exchanged between two communications applications to establish a SIP = call. Any data requirements at the application level (Tier-3 level) are = considered "out of scope" for ENUM. =20 I hope this helps. =20 Doug=20 Douglas Ranalli Founder & Chief Strategy Officer NetNumber.com dranalli@netnumber.com ----- Original Message -----=20 From: Kevin McCandless=20 To: enum@ietf.org=20 Sent: Monday, January 08, 2001 11:13 AM Subject: [Enum] Status Hello: Would someone please provide me with the status of the ENUM Working = Group, such as: Are there any open issues and will a bakeoff be = conducted? Also, have any thoughts to how Tier I and II databases will be = handled. On the Tier II database, could this be the current DNS = registry database with a few field modifications? Will the Tier I = database only handle country code routing? Will there be a Tier III and = what would be the function of that tier? Your input and thoughts will be greatly appreciated. Sincerely, Kevin ------=_NextPart_000_00B3_01C0796F.542D0060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Kevin,
 
Here's my understanding of the status = of=20 ENUM.  I'm sure Richard Shockey (Chair) will be able to clarify if = I've=20 missed anything:
 
Status of working group:  At the = last IETF=20 meeting, the ENUM WG was declared a "success" thanks to the acceptance = of RFC=20 2916 as a core ENUM standard.  Given this foundation, two options = were=20 considered for the future of the ENUM working group.  Option #1 was = to put=20 the WG into a "dormant" status and wait to see if any future need = might=20 arise that would justify reactivating the group.  Option = #2 was=20 to close down the ENUM WG.  Scott Bradner (Area Director) clarified = that=20 the IETF Area Directors would consider the issue in early 2001 and then = make a=20 statement regarding the status of the WG.  Regardless of the = outcome, the=20 active phase of standards definition work within the ENUM WG is=20 concluded.
 
Tier 1 Implementations:  The ITU = is holding a=20 meeting at the end of January in Geneva during which discussions will = continue=20 regarding the proposal for establishing a public administration model = for ENUM=20 services under the "e164.arpa" infrastructure domain.  In = addition to=20 work within the IETF, various countries (IETF member states) are = beginning to=20 look at ENUM on a local level.  Discussions are expected to begin = in the US=20 in February under a newly formed ENUM Ad Hoc group organized under the=20 Department of State's ITAC function.  In addition to the public = "e164.arpa"=20 discussions, there are various companies advancing trials of private = ENUM=20 implementations under different domains as a mechanism for gaining = experience=20 with ENUM services.  NetNumber has deployed a global private ENUM = system=20 under "e164.com".  Verisign and Telcordia have deployed a 6-month = ENUM=20 trial under "enumworld.com".  NeuStar has indicated that they = will=20 deploy a trial system.
 
Tier-2 = Implementations:  Multiple vendors=20 are currently experimenting with ENUM implementations in their = products. =20 NetNumber is actively engaged in working with a large number of = vendors=20 on implementing ENUM "update and resolution" capabilities into = their=20 applications.  As I understand the situation, Verisign = and=20 Telcordia are using the ENUM World trial as a mechanism for gaining = experience with Tier-2 services.   
 
Tier-3 Services:  If I understand = your=20 question, you're asking "what happens after I use Tier-1 and Tier-2 ENUM = to=20 discover an Internet service for an end-user?"  For example, once = you use=20 ENUM to discover a SIP address for an end-user there is additional = information=20 that will be exchanged between two communications applications to = establish a=20 SIP call.  Any data requirements at the application level = (Tier-3=20 level) are considered "out of scope" for ENUM. 
 
I hope this helps. 
 
Doug 
 
Douglas Ranalli
Founder & Chief Strategy = Officer
NetNumber.com
dranalli@netnumber.com<= /DIV>
 
 
 
 
----- Original Message -----
From:=20 Kevin McCandless
Sent: Monday, January 08, 2001 = 11:13=20 AM
Subject: [Enum] Status

Hello:
 
Would someone please provide me with the status of the ENUM = Working=20 Group, such as:  Are there any open issues and will a bakeoff be=20 conducted?
 
Also, have any thoughts to how Tier I and II databases will be=20 handled.  On the Tier II database, could this be the current DNS = registry=20 database with a few field modifications?  Will the Tier I = database only=20 handle country code routing?  Will there be a Tier III and what = would be=20 the function of that tier?
 
Your input and thoughts will be greatly appreciated.
 
Sincerely,
 
Kevin
------=_NextPart_000_00B3_01C0796F.542D0060-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 8 13:10:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12634 for ; Mon, 8 Jan 2001 13:10:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02177; Mon, 8 Jan 2001 13:10:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02147 for ; Mon, 8 Jan 2001 13:10:13 -0500 (EST) Received: from exchange.chaos.com ([206.5.17.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12627 for ; Mon, 8 Jan 2001 13:10:11 -0500 (EST) Received: from [216.168.250.52] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id beyjaaaa for enum@ietf.org; Mon, 8 Jan 2001 13:10:07 -0500 Message-Id: <5.0.2.1.2.20010108130231.0278bab0@mail.netmagic.com> X-Sender: amr@mail.netmagic.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 08 Jan 2001 13:10:05 -0500 To: "Douglas Ranalli" , "Kevin McCandless" From: "A.M. Rutkowski" Subject: Re: [Enum] Status Cc: In-Reply-To: <00b601c07999$3d4ae6d0$56498826@netnumber.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_8876874==_.ALT" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --=====================_8876874==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:34 PM 1/8/2001, Douglas Ranalli wrote: >Tier 1 Implementations: The ITU is holding a meeting at the end of >January in Geneva during which discussions will continue regarding the >proposal for establishing a public administration model for ENUM services >under the "e164.arpa" infrastructure domain. In addition to work within >the IETF, various countries (IETF member states) are beginning to look at >ENUM on a local level. Discussions are expected to begin in the US Hi Doug, Good summary. It was the understanding, however, following the Dept of State's industry advisory group meeting last week related to this subject, that the ITU organizers of the 17 Jan ENUM workshop would be asked to open up the 17 Jan meeting to more flexible, market-driven approaches such as you have been advocating, including presentation of your ID...as opposed to only the government regulated "public administration" models currently on the agenda. best, tony --=====================_8876874==_.ALT Content-Type: text/html; charset="us-ascii" At 12:34 PM 1/8/2001, Douglas Ranalli wrote:
Tier 1 Implementations:  The ITU is holding a meeting at the end of January in Geneva during which discussions will continue regarding the proposal for establishing a public administration model for ENUM services under the "e164.arpa" infrastructure domain.  In addition to work within the IETF, various countries (IETF member states) are beginning to look at ENUM on a local level.  Discussions are expected to begin in the US

Hi Doug,

Good summary.

It was the understanding, however, following the Dept of State's
industry advisory group meeting last week related to this subject,
that the ITU organizers of the 17 Jan ENUM workshop would be asked
to open up the 17 Jan meeting to more flexible, market-driven
approaches such as you have been advocating, including presentation
of your ID...as opposed to only the government regulated "public
administration" models currently on the agenda.

best,
tony

--=====================_8876874==_.ALT-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 8 13:24:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12998 for ; Mon, 8 Jan 2001 13:24:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02308; Mon, 8 Jan 2001 13:23:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02276 for ; Mon, 8 Jan 2001 13:23:12 -0500 (EST) Received: from heron.verisign.com ([216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12987 for ; Mon, 8 Jan 2001 13:23:11 -0500 (EST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA07778; Mon, 8 Jan 2001 13:12:02 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Mon, 8 Jan 2001 13:17:47 -0500 Message-ID: From: "Conley, Pat" To: "'Douglas Ranalli'" , Kevin McCandless Cc: enum@ietf.org Subject: RE: [Enum] Status Date: Mon, 8 Jan 2001 13:17:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0799F.4D61F440" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0799F.4D61F440 Content-Type: text/plain; charset="iso-8859-1" Doug, One of the clear activities that was discussed at the last IETF meeting in San Diego was the consolidation of several IDs into one that would bring together terminology and various contributors ideas on possible structures that the industry might take. Has any work started on that process? If so, I would like to participate as we have some serious concerns about the existing drafts and want to contribute to a "best thinking" version. Pat Patrick J. Conley VeriSign Global Registry Services pconley@verisign.com ------_=_NextPart_001_01C0799F.4D61F440 Content-Type: text/html; charset="iso-8859-1"
Doug,
 
One of the clear activities that was discussed at the last IETF meeting in
San Diego was the consolidation of several IDs into one that would bring
together terminology and various contributors ideas on possible structures
that the industry might take.
 
Has any work started on that process?  If so, I would like to participate as
we have some serious concerns about the existing drafts and want to
contribute to a "best thinking" version.
 
Pat
 

Patrick J. Conley
VeriSign Global Registry Services
pconley@verisign.com

------_=_NextPart_001_01C0799F.4D61F440-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 8 17:33:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17869 for ; Mon, 8 Jan 2001 17:33:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06313; Mon, 8 Jan 2001 17:33:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06284 for ; Mon, 8 Jan 2001 17:32:59 -0500 (EST) Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17847 for ; Mon, 8 Jan 2001 17:32:56 -0500 (EST) Received: from dranalli ([38.136.73.86]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20010108223228.RJSA20644.hvmta01-stg@dranalli>; Mon, 8 Jan 2001 17:32:28 -0500 Message-ID: <007701c079c2$075f0d20$56498826@netnumber.com> Reply-To: "Douglas Ranalli" From: "Douglas Ranalli" To: "Conley, Pat" Cc: References: Subject: Re: [Enum] Status Date: Mon, 8 Jan 2001 17:26:20 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0074_01C07998.1D9926E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0074_01C07998.1D9926E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pat, Thank you for prompting me regarding the follow-up from the IETF ENUM = meeting. I will contact Penn Pfaltz at AT&T and James Yu and NeuStar to = begin coordinating on a consolidated ID. I'll make sure to include you = in all correspondence on this effort so that we can get your input into = the combined effort. Doug ----- Original Message -----=20 From: Conley, Pat=20 To: 'Douglas Ranalli' ; Kevin McCandless=20 Cc: enum@ietf.org=20 Sent: Monday, January 08, 2001 1:17 PM Subject: RE: [Enum] Status Doug,=20 =20 One of the clear activities that was discussed at the last IETF = meeting in San Diego was the consolidation of several IDs into one that would = bring together terminology and various contributors ideas on possible = structures that the industry might take. =20 Has any work started on that process? If so, I would like to = participate as we have some serious concerns about the existing drafts and want to=20 contribute to a "best thinking" version. =20 Pat =20 Patrick J. Conley=20 VeriSign Global Registry Services=20 pconley@verisign.com=20 ------=_NextPart_000_0074_01C07998.1D9926E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Pat,
 
Thank you for prompting me regarding = the follow-up=20 from the IETF ENUM meeting.  I will contact Penn Pfaltz at AT&T = and=20 James Yu and NeuStar to begin coordinating on a consolidated ID.  = I'll make=20 sure to include you in all correspondence on this effort so that we can = get your=20 input into the combined effort.
 
Doug
----- Original Message -----
From:=20 Conley,=20 Pat
To: 'Douglas=20 Ranalli' ; Kevin McCandless
Sent: Monday, January 08, 2001 = 1:17=20 PM
Subject: RE: [Enum] = Status

Doug, =
 
One of the clear = activities=20 that was discussed at the last IETF meeting in
San Diego was the = consolidation of several IDs into one that would = bring
together = terminology and=20 various contributors ideas on possible structures
that the industry = might=20 take.
 
Has any work = started on that=20 process?  If so, I would like to participate = as
we have some = serious concerns=20 about the existing drafts and want to
contribute to a = "best=20 thinking" version.
 
Pat
 

Patrick J. Conley
VeriSign Global Registry Services
pconley@verisign.com=20

------=_NextPart_000_0074_01C07998.1D9926E0-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jan 10 16:57:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28424 for ; Wed, 10 Jan 2001 16:57:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25022; Wed, 10 Jan 2001 16:55:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24943 for ; Wed, 10 Jan 2001 16:55:09 -0500 (EST) Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28088 for ; Wed, 10 Jan 2001 16:55:06 -0500 (EST) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id QAA14831 for ; Wed, 10 Jan 2001 16:51:52 -0500 (EST) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852569D0.0078168B ; Wed, 10 Jan 2001 16:51:40 -0500 X-Lotus-FromDomain: TELCORDIA From: "Gary W. Richenaker" To: enum@ietf.org Message-ID: <852569D0.00781524.00@notes949.cc.telcordia.com> Date: Wed, 10 Jan 2001 16:51:11 -0500 Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=nLbRG4WGGmVr1wtjDDD82408LWPEpE2BhtvJkkkRxdTIicWOYp2euspW" Content-Disposition: inline Subject: [Enum] SGA Ad-Hoc on ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --0__=nLbRG4WGGmVr1wtjDDD82408LWPEpE2BhtvJkkkRxdTIicWOYp2euspW Content-type: text/plain; charset=us-ascii Content-Disposition: inline Attached is the meeting notice and registration information regarding the February SGA Ad-Hoc meeting on ENUM. If you have any questions, please feel free to contact me. Gary Richenaker (See attached file: ENUM Meeting Notice.doc) --0__=nLbRG4WGGmVr1wtjDDD82408LWPEpE2BhtvJkkkRxdTIicWOYp2euspW Content-type: application/msword; name="ENUM Meeting Notice.doc" Content-Disposition: attachment; filename="ENUM Meeting Notice.doc" Content-Description: Mac Word 3.0 Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAALwAAAAAAAAAA EAAAMQAAAAEAAAD+////AAAAAC4AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEANyAJBAAA+BK/AAAAAAAAEAAAAAAABAAAUw0AAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAA AAAJBBYAHhgAADd8AAA3fAAAUwkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAEYBAAAAAAAARgEAAEYB AAAAAAAARgEAAAAAAABGAQAAAAAAAEYBAAAAAAAARgEAABQAAAAAAAAAAAAAAFoBAAAAAAAA5AQA AAAAAADkBAAAAAAAAOQEAAAAAAAA5AQAAAwAAADwBAAAFAAAAFoBAAAAAAAAGA4AADIBAAAQBQAA TAAAAFwFAAAAAAAAXAUAAAAAAABcBQAAAAAAAFwFAAAAAAAAXAUAACIAAAB+BQAADAAAAIoFAAAI AAAAlw0AAAIAAACZDQAAAAAAAJkNAAAAAAAAmQ0AAAAAAACZDQAAAAAAAJkNAAAAAAAAmQ0AACQA AABKDwAAIAIAAGoRAAB6AAAAvQ0AABUAAAAAAAAAAAAAAAAAAAAAAAAARgEAAAAAAACSBQAAAAAA AAAAAAAAAAAAAAAAAAAAAABcBQAAAAAAAFwFAAAAAAAAkgUAAAAAAACSBQAAAAAAAL0NAAAAAAAA dgYAAAAAAABGAQAAAAAAAEYBAAAAAAAAXAUAAAAAAAAAAAAAAAAAAFwFAAAAAAAA0g0AABYAAAB2 BgAAAAAAAHYGAAAAAAAAdgYAAAAAAACSBQAAOgAAAEYBAAAAAAAAXAUAAAAAAABGAQAAAAAAAFwF AAAAAAAAlw0AAAAAAAAAAAAAAAAAAHYGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAkgUAAAAAAACXDQAAAAAAAHYGAABsBAAAdgYAAAAAAADiCgAA HgAAAGMNAAAYAAAARgEAAAAAAABGAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiw0AAAAAAABcBQAAAAAAAAQFAAAMAAAA4ApS/Ex7 wAFaAQAAigMAAOQEAAAAAAAAzAUAABYAAAB7DQAACAAAAAAAAAAAAAAAiw0AAAwAAADoDQAAMAAA ABgOAAAAAAAAgw0AAAgAAADkEQAAAAAAAOIFAACUAAAA5BEAAAAAAACLDQAAAAAAAHYGAAAAAAAA WgEAAAAAAABaAQAAAAAAAEYBAAAAAAAARgEAAAAAAABGAQAAAAAAAEYBAAAAAAAAAgDZAAAADVNH QSBBZC1Ib2MNVVMgQWRtaW5pc3RyYXRpdmUgRU5VTSBpc3N1ZXMNTWVldGluZyBOb3RpY2UNDQ1B dCB0aGUgSmFudWFyeSBtZWV0aW5nIG9mIHRoZSBVbml0ZWQgU3RhdGVzIFN0dWR5IEdyb3VwIEEg bWVldGluZywgaXQgd2FzIGFncmVlZCB0byBlc3RhYmxpc2ggYSBuZXcgQWQtSG9jIHRoYXQgd291 bGQgZGV2ZWxvcCBpbmR1c3RyeSBpbnB1dCB0byBpZGVudGlmeSBhZG1pbmlzdHJhdGl2ZSBVUyBF TlVNLUROUyBpc3N1ZXMgYW5kIHJlY29tbWVuZCByZXNvbHV0aW9uIHRvIHRoZSBpc3N1ZXMgaW4g YSBSZXBvcnQgdG8gU3R1ZHkgR3JvdXAgQS4NDVRoZSBpbml0aWFsIG1lZXRpbmcgb2YgdGhpcyBu ZXcgQWQtSG9jIHdpbGwgYmUgb3JnYW5pemF0aW9uYWwgaW4gbmF0dXJlIHdpdGggZnV0dXJlIG1l ZXRpbmdzIHJlcXVpcmluZyBjb250cmlidXRpb25zIHJlbGF0aW5nIHRvIHRoZSBpc3N1ZXMgaWRl bnRpZmllZCBkdXJpbmcgdGhpcyBtZWV0aW5nLg0NRGF0ZTogCUZlYiAxMi0xMywgMjAwMS4gIFRo ZSBtZWV0aW5nIGlzIHNjaGVkdWxlZCB0byBzdGFydCBhdCA4OjMwIG9uIE1vbmRheSBGZWJydWFy eSAxMiBhbmQgZW5kIGJlZm9yZSAxUE0gb24gRmViIDEzLg0NTG9jYXRpb246IAlNaXRyZXRlayBT eXN0ZW1zDQkJNzUyNSBDb2xzaGlyZSBEcg0JCU1jTGVhbiwgVkEgMjIxMDINDVRlbnRhdGl2ZSBB Z2VuZGE6DQlUdXRvcmlhbHMNRU5VTSBPdmVydmlldw1ETlMgT3ZlcnZpZXcNQWRtaW5pc3RyYXRp dmUgSXNzdWVzIGZyb20gSVRVIEVOVU0gV29ya3Nob3AgKDEvMTcvMDEpDUlkZW50aWZ5IFVTIEFk bWluaXN0cmF0aXZlIElzc3VlcyANVGltZSB3aWxsIGJlIGFsbG9jYXRlZCB0byBhbGxvdyBmb3Ig dGhlIHByZXNlbnRhdGlvbiBvZiBhbHRlcm5hdGl2ZSBtb2RlbHMgdGhhdCBpZGVudGlmeSBhZG1p bmlzdHJhdGl2ZSBpc3N1ZXMNSXNzdWVzIHRoYXQgYXJlIGlkZW50aWZpZWQgd2lsbCBiZSB0aGUg YmFzaXMgZm9yIGNvbnRyaWJ1dGlvbnMgYXQgZnV0dXJlIG1lZXRpbmdzDURldmVsb3AgV29yayBQ bGFuDURldGVybWluZSBPdXRwdXQNRnV0dXJlIE1lZXRpbmcgU2NoZWR1bGUNDUxvZ2lzdGljczoN DURpcmVjdGlvbnMgYXJlIGF2YWlsYWJsZSBhdCB0aGUgTWl0cmV0ZWsgd2Vic2l0ZTogaHR0cDov L3d3dy5taXRyZXRlay5vcmcvY29tcGFueS9tYXAuaHRtbC4gIE1pdHJldGVrIGlzIGxvY2F0ZWQg anVzdCBvZmYgdGhlIERDIEJlbHR3YXkgYW5kIFJ0LiAxMjMgaW4gdGhlIFR5c29ucyBDb3JuZXIs IFZBIGFyZWEuICBBbGwgVHlzb24ncyBDb3JuZXIgYXJlYSBob3RlbHMgYXJlIGNvbnZlbmllbnQu ICANDVJlZ2lzdHJhdGlvbjoNDUluIG9yZGVyIHRvIGFudGljaXBhdGUgYW5kIHBsYW4gZm9yIHRo ZSBtZWV0aW5nLCBwcmUtcmVnaXN0cmF0aW9uIGlzIHJlcXVlc3RlZC4gIFBsZWFzZSBzdXBwbHkg dGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiB0byBEZW5pc2UgTXVycGh5IGF0IBMgSFlQRVJMSU5L ICJtYWlsdG86c2RtdXJwaHlAbWl0cmV0ZWsub3JnIiABFHNkbXVycGh5QG1pdHJldGVrLm9yZxUs IG9yIDcwMy42MTAuMjkwMiAoZW1haWwgcHJlZmVycmVkKTsgTmFtZSwgQ29tcGFueSwgZW1haWws IGFkZHJlc3MsIHBob25lLCBTUyMsIGFuZCBmYXguIEZvciBzZWN1cml0eSBwdXJwb3NlcywgcGxl YXNlIGJyaW5nIGEgcGljdHVyZSBJRC4NDVByZXNlbnRhdGlvbnMNDUlmIHlvdSBvciB5b3VyIGNv bXBhbnkgd291bGQgbGlrZSB0byBoYXZlIHRpbWUgdG8gcHJlc2VudCBhbiBpbXBsZW1lbnRhdGlv biBtb2RlbCB3aXRoIHRoZSBhc3NvY2lhdGVkIGFkbWluaXN0cmF0aXZlIGlzc3VlcyBwbGVhc2Ug Y29udGFjdCBHYXJ5IFJpY2hlbmFrZXIgYXQgEyBIWVBFUkxJTksgIm1haWx0bzpncmljaGVuYUB0 ZWxjb3JkaWEuY29tIiABFGdyaWNoZW5hQHRlbGNvcmRpYS5jb20VIC0oOTczKSA4MjkgNDMwNSBv ciBTdGV2ZSBMaW5kIGF0IBMgSFlQRVJMSU5LICJtYWlsdG86c2RsaW5kQGF0dC5jb20iIAEUc2Rs aW5kQGF0dC5jb20VIC0gKDk3MykgMjM2LTY3ODcNDU5vdGU6IEEgY29weSBvZiB0aGlzIG1lZXRp bmcgbm90aWNlIHdpbGwgYmUgc2VudCB0byB0aGUgcGFydGljaXBhbnRzIGF0IHRoZSBEZWMgMTgg RG9DIG1lZXRpbmcsIBMgSFlQRVJMSU5LICJtYWlsdG86ZW51bUBpZXRmLm9yZyIgARRlbnVtQGll dGYub3JnFSwgYW5kIHRoZSBJVEFDLVQgbWFpbGluZyBsaXN0LiAgVGhpcyBtZWV0aW5nIG5vdGlj ZSBpcyBpbnRlbmRlZCB0byBpbmNsdWRlIGFsbCBpbnRlcmVzdGVkIGluZHVzdHJ5IHBhcnRpY2lw YW50cywgdGhlcmVmb3JlLCBwbGVhc2UgZmVlbCBmcmVlIHRvIGZvcndhcmQgdGhpcyBtZWV0aW5n IG5vdGljZSB0byBpbmRpdmlkdWFscyBvciBvdGhlciBtYWlsaW5nIGxpc3RzLg0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAEEAAA5 BAAAOwQAAOkFAADuBQAAYQYAAGoGAACkBgAAtgYAADUHAAA2BwAAMwgAAD4IAAAmCQAANAkAAMIJ AADDCQAA7QkAAO4JAADvCQAABAoAAAUKAACRCgAAnwoAAD4LAAA/CwAAagsAAGsLAABsCwAAggsA AIMLAAClCwAApgsAAMkLAADKCwAAywsAANkLAADaCwAATQwAAE4MAABwDAAAcQwAAHIMAAB/DAAA gAwAAFMNAAAA+wD4+/j7+Pv48fj7+Pv46vjg6tvq+AD46vjR6tvq+Or4x+r46vjq+L3q2+r4AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEwIIgQNqeQIAAAYIAUNKFgBVCAETAgiBA2q6AQAA BggBQ0oWAFUIARMCCIEDatsAAAAGCAFDShYAVQgBCDBKDwBDShYAABMCCIEDagAAAAAGCAFDShYA VQgBDQNqAAAAAENKFgBVCAENQioNQ0oWAHBogAAAAARDShYAAAc1CIFDShYAAC4ABAAAAQQAAAwE AAAqBAAAOQQAADoEAAA7BAAAOwUAADwFAADoBQAA6QUAAGAGAABhBgAAfQYAAJAGAACjBgAApAYA ALYGAADBBgAAzwYAANwGAAATBwAANgcAAKUHAAD3BwAACQgAABoIAAAyCAAA/QAAAAAAAAAAAAAA APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8wAAAAAA AAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAA AADzAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABQAAD4TQAl6E0AIFAAAKJgALRgEAAAQAAAMkAWEkAQABAAAAGwAEAABTDQAA/gAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAQEBMggAADMIAAA+CAAA PwgAACUJAAAmCQAANAkAADUJAACQCgAAkQoAAJ8KAACgCgAA7AsAAO0LAABTDQAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAQAAAQAAAA4cAB+w0C8gsOA9IbAI ByKwCAcjkKAFJJCgBSWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANsAAABEAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ 6nn5us4RjIIAqgBLqQsCAAAAFwAAABYAAABzAGQAbQB1AHIAcABoAHkAQABtAGkAdAByAGUAdABl AGsALgBvAHIAZwAAAODJ6nn5us4RjIIAqgBLqQs6AAAAbQBhAGkAbAB0AG8AOgBzAGQAbQB1AHIA cABoAHkAQABtAGkAdAByAGUAdABlAGsALgBvAHIAZwAAAN8AAABEAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIA qgBLqQsCAAAAFwAAABcAAABnAHIAaQBjAGgAZQBuAGEAQAB0AGUAbABjAG8AcgBkAGkAYQAuAGMA bwBtAAAA4Mnqefm6zhGMggCqAEupCzwAAABtAGEAaQBsAHQAbwA6AGcAcgBpAGMAaABlAG4AYQBA AHQAZQBsAGMAbwByAGQAaQBhAC4AYwBvAG0AAAC/AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kL AgAAABcAAAAPAAAAcwBkAGwAaQBuAGQAQABhAHQAdAAuAGMAbwBtAAAA4Mnqefm6zhGMggCqAEup CywAAABtAGEAaQBsAHQAbwA6AHMAZABsAGkAbgBkAEAAYQB0AHQALgBjAG8AbQAAALsAAABEAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAAA4AAABlAG4AdQBtAEAAaQBlAHQAZgAuAG8AcgBn AAAA4Mnqefm6zhGMggCqAEupCyoAAABtAGEAaQBsAHQAbwA6AGUAbgB1AG0AQABpAGUAdABmAC4A bwByAGcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUABEACgABAGkADwADAAAAAAAAAAAA MAAAQPH/AgAwAAwABgBOAG8AcgBtAGEAbAAAAAIAAAAQAF9IAQRtSAkEc0gJBHRICQQ2AAFAAQAC ADYADAAJAEgAZQBhAGQAaQBuAGcAIAAxAAAACAABAAYkAUAmAAoANQiBQ0oWAFwIgQAAAAAAAAAA AAAAAAAAAAA8AEFA8v+hADwADAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAg AEYAbwBuAHQAAAAAAAAAAAAAAAAALgBVQKIA8QAuAAwACQBIAHkAcABlAHIAbABpAG4AawAAAAwA PioBQioCcGgAAP8APgBWQKIAAQE+AAwAEQBGAG8AbABsAG8AdwBlAGQASAB5AHAAZQByAGwAaQBu AGsAAAAMAD4qAUIqDHBogACAAAAAAABTCQAABAAAGAAAAAD/////AAAAAAEAAAAMAAAAKgAAADkA AAA6AAAAOwAAADsBAAA8AQAA6AEAAOkBAABgAgAAYQIAAH0CAACQAgAAowIAAKQCAAC2AgAAwQIA AM8CAADcAgAAEwMAADYDAAClAwAA9wMAAAkEAAAaBAAAMgQAADMEAAA+BAAAPwQAACUFAAAmBQAA NAUAADUFAACQBgAAkQYAAJ8GAACgBgAA7AcAAO0HAABVCQAAmAAAAAAwAAAAAAAAAIAAAACAmAAA AAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA AAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAA AIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAA AACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACA mAAAAAAwAAAAAAAAAIAAAACAmAABIAAwAAAAAAAAAIAAAACAmAABIAAwAAAAAAAAAIAAAACAmAAB IAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAABIAAwAAAAAAAAAIAAAACAmAABIAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA AAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAA AIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAA AACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACA CAAAAAEwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAA AAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAAAQAAFMNAAAIAAAAAAQAADIIAABTDQAA CQAAAAsAAAAABAAAUw0AAAoAAADCBQAA7gUAAAQGAAA+BwAAawcAAIIHAAClBwAAygcAANkHAABN CAAAcQgAAH8IAABTCQAAE1gU/xWAE1gU/xWAE1gU/xWEE1gU/xWA//8BAAAADQBfAEgAbAB0ADUA MAAzADYAMAA1ADgANwAyAAMGAABVCQAAAAAAQAQGAABVCQAAAAAAAIQCAACMAgAA2wQAAOEEAACL CAAAkAgAAC8JAAA6CQAAVQkAAAcAHAAHABwABwAEAAcABAAHAAAAAADtBwAAoAgAAFUJAAAHAAQA BwAAAAAAhwIAAIcCAADHBAAA0wQAAOgEAADpBAAABgUAAAcFAAAFBgAAKAYAAFAGAABVBgAAXQYA AI8GAADaBwAA2gcAAIsIAACQCAAAzwgAANoIAAAvCQAALwkAAFIJAABVCQAAAwAEAAMABAADAAQA AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAcA//8UAAAADgBTAHQAZQB2AGUAbgAg AEQALgAgAEwAaQBuAGQAJQBDADoAXAB3AGkAbgBkAG8AdwBzAFwARABlAHMAawB0AG8AcABcAE0A ZQBlAHQAaQBuAGcAIABOAG8AdABpAGMAZQAuAGQAbwBjAA8AZwBhAHIAeQAgAHIAaQBjAGgAZQBu AGEAawBlAHIAJgBOADoAXABXAE8AUgBEAFwARQBOAFUATQAtAEEAZAAtAEgAbwBjAFwATQBlAGUA dABpAG4AZwAgAE4AbwB0AGkAYwBlAC4AZABvAGMADwBnAGEAcgB5ACAAcgBpAGMAaABlAG4AYQBr AGUAcgAmAE4AOgBcAFcATwBSAEQAXABFAE4AVQBNAC0AQQBkAC0ASABvAGMAXABNAGUAZQB0AGkA bgBnACAATgBvAHQAaQBjAGUALgBkAG8AYwAPAGcAYQByAHkAIAByAGkAYwBoAGUAbgBhAGsAZQBy ACYATgA6AFwAVwBPAFIARABcAEUATgBVAE0ALQBBAGQALQBIAG8AYwBcAE0AZQBlAHQAaQBuAGcA IABOAG8AdABpAGMAZQAuAGQAbwBjAA8AZwBhAHIAeQAgAHIAaQBjAGgAZQBuAGEAawBlAHIAJgBO ADoAXABXAE8AUgBEAFwARQBOAFUATQAtAEEAZAAtAEgAbwBjAFwATQBlAGUAdABpAG4AZwAgAE4A bwB0AGkAYwBlAC4AZABvAGMACABtAGkAdAByAGUAdABlAGsAJwBDADoAXABNAHkAIABEAG8AYwB1 AG0AZQBuAHQAcwBcAEUATgBVAE0AIABNAGUAZQB0AGkAbgBnACAATgBvAHQAaQBjAGUALgBkAG8A YwAPAGcAYQByAHkAIAByAGkAYwBoAGUAbgBhAGsAZQByACsATgA6AFwAVwBPAFIARABcAEUATgBV AE0ALQBBAGQALQBIAG8AYwBcAEUATgBVAE0AIABNAGUAZQB0AGkAbgBnACAATgBvAHQAaQBjAGUA LgBkAG8AYwAPAGcAYQByAHkAIAByAGkAYwBoAGUAbgBhAGsAZQByACsATgA6AFwAVwBPAFIARABc AEUATgBVAE0ALQBBAGQALQBIAG8AYwBcAEUATgBVAE0AIABNAGUAZQB0AGkAbgBnACAATgBvAHQA aQBjAGUALgBkAG8AYwAPAGcAYQByAHkAIAByAGkAYwBoAGUAbgBhAGsAZQByACsATgA6AFwAVwBP AFIARABcAEUATgBVAE0ALQBBAGQALQBIAG8AYwBcAEUATgBVAE0AIABNAGUAZQB0AGkAbgBnACAA TgBvAHQAaQBjAGUALgBkAG8AYwAQAEQAZQBzAGsAdABvAHAAIABTAGUAcgB2AGkAYwBlAHMAKwBO ADoAXABXAE8AUgBEAFwARQBOAFUATQAtAEEAZAAtAEgAbwBjAFwARQBOAFUATQAgAE0AZQBlAHQA aQBuAGcAIABOAG8AdABpAGMAZQAuAGQAbwBjAAEAx04+ZVD9Fir/D/8P/w//D/8P/w//D/8P/w8Q AGUdAAAXAAAAAAAAAAAAAAAAAAAAAAAAABMYAAAPhDgEEYSY/hXGBQABOAQGXoQ4BGCEmP5PSgAA UEoAAFFKAABeSgAAbygAAQAtAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhAgHEYSY/hXG BQABCAcGXoQIB2CEmP5PSgMAUUoDAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAA D4TYCRGEmP4VxgUAAdgJBl6E2AlghJj+T0oEAFFKBABvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAA AAAAAAAACxgAAA+EqAwRhJj+FcYFAAGoDAZehKgMYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAA AAAAAAAAAAAAAAAAAAAAAAsYAAAPhHgPEYSY/hXGBQABeA8GXoR4D2CEmP5PSgMAUUoDAG8oAAEA bwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RIEhGEmP4VxgUAAUgSBl6ESBJghJj+T0oE AFFKBABvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EGBURhJj+FcYFAAEYFQZe hBgVYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhOgXEYSY /hXGBQAB6BcGXoToF2CEmP5PSgMAUUoDAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAL GAAAD4S4GhGEmP4VxgUAAbgaBl6EuBpghJj+T0oEAFFKBABvKAABAKfwAQAAAMdOPmUAAAAAAAAA AAAAAAD///////8BAAAAAAD//wEAAAAAAAAAAABVCQAAAQAAAP9AAYABAJAIAACQCAAAyAs4AwEA AQCQCAAAAAAAAIAIAAAAAAAAAhAAAAAAAAAAUwkAAEAAAAgAQAAA//8BAAAABwBVAG4AawBuAG8A dwBuAP//AQAIAAAAAAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAUAAABH FpABAAACAgYDBQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcA IABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5 AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkA YQBsAAAAPzWQAQAAAgcDCQICBQIEBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBl AHIAIABOAGUAdwAAADsGkAECAAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkA bgBnAGQAaQBuAGcAcwAAACIABAAxCIgYAPDQAuQEaAEAAAAAGkRRJiFUUWYAAAAACAANAAAAWQEA ALAHAAABAAMAAAAEAAMQEAAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAAAkAwDwEAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAEjAAABAAGQBkAAAAGQAAAHAJAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAA AAAAAAAAAAAygxEA8BAA3wMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAA CgBTAEcAQQAgAEEAZAAtAEgAbwBjAAAAAAAAAA8AZwBhAHIAeQAgAHIAaQBjAGgAZQBuAGEAawBl AHIADwBnAGEAcgB5ACAAcgBpAGMAaABlAG4AYQBrAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf 8vlPaBCrkQgAKyez2TAAAACAAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAArAAAAAQAAAC4AAAA BQAAANAAAAAGAAAA3AAAAAcAAADoAAAACAAAAPwAAAAJAAAAFAEAABIAAAAgAQAACgAAADwBAAAM AAAASAEAAA0AAABUAQAADgAAAGABAAAPAAAAaAEAABAAAABwAQAAEwAAAHgBAAACAAAA5AQAAB4A AAALAAAAU0dBIEFkLUhvYwAAHgAAAAEAAAAAR0EgHgAAABAAAABnYXJ5IHJpY2hlbmFrZXIAHgAA AAEAAAAAYXJ5HgAAAAEAAAAAYXJ5HgAAAAsAAABOb3JtYWwuZG90AGEeAAAAEAAAAGdhcnkgcmlj aGVuYWtlcgAeAAAAAgAAADgAcnkeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDkuMAAAQAAAAACO6tAB AAAAQAAAAACkc5i5ecABQAAAAAAOnudMe8ABAwAAAAEAAAADAAAAWQEAAAMAAACwBwAAAwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cI ACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rkwBAAAIAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAA kAAAAAYAAACYAAAAEQAAAKAAAAAXAAAAqAAAAAsAAACwAAAAEAAAALgAAAATAAAAwAAAABYAAADI AAAADQAAANAAAAAMAAAA5wAAAAIAAADkBAAAHgAAABcAAABUZWxjb3JkaWEgVGVjaG5vbG9naWVz AAADAAAAEAAAAAMAAAADAAAAAwAAAHAJAAADAAAAoAoJAAsAAAAAAAAACwAAAAAAAAALAAAAAAAA AAsAAAAAAAAAHhAAAAEAAAALAAAAU0dBIEFkLUhvYwAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAA AAEAAAAAAADsAQAAAwAAAAAAAAAgAAAAAQAAADgAAAACAAAAQAAAAAEAAAACAAAADAAAAF9QSURf SExJTktTAAIAAADkBAAAQQAAAKQBAAAYAAAAAwAAAAgAOQADAAAACQAAAAMAAAAAAAAAAwAAAAUA AAAfAAAAFQAAAG0AYQBpAGwAdABvADoAZQBuAHUAbQBAAGkAZQB0AGYALgBvAHIAZwAAAAAAHwAA AAEAAAAAAAAAAwAAAFUAZgADAAAABgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAFgAAAG0AYQBpAGwA dABvADoAcwBkAGwAaQBuAGQAQABhAHQAdAAuAGMAbwBtAAAAHwAAAAEAAAAAAAAAAwAAAE4AdgAD AAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAHgAAAG0AYQBpAGwAdABvADoAZwByAGkAYwBoAGUA bgBhAEAAdABlAGwAYwBvAHIAZABpAGEALgBjAG8AbQAAAB8AAAABAAAAAAAAAAMAAAAXACoAAwAA AAAAAAADAAAAAAAAAAMAAAAFAAAAHwAAAB0AAABtAGEAaQBsAHQAbwA6AHMAZABtAHUAcgBwAGgA eQBAAG0AaQB0AHIAZQB0AGUAawAuAG8AcgBnAAAAAAAfAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAA AP7///8OAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAA/v///xYAAAAXAAAAGAAAABkAAAAaAAAA GwAAABwAAAAdAAAA/v///x8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAD+////JwAAACgAAAAp AAAAKgAAACsAAAAsAAAALQAAAP7////9////MAAAAP7////+/////v////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAA AAAAQP6P/Ex7wAEyAAAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAAAEAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIAAQAAAP////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFQAAAOQRAAAAAAAAVwBvAHIA ZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABoAAgEGAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA HhgAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAB4AAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBu AGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJgAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgECAAAABwAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAABPAGIAagBl AGMAdABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA FgABAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAQP6P/Ex7wAFA/o/8THvAAQAAAAAA AAAAAAAAAAEAAAD+//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABNaWNyb3NvZnQgV29yZCBEb2N1 bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA= --0__=nLbRG4WGGmVr1wtjDDD82408LWPEpE2BhtvJkkkRxdTIicWOYp2euspW-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Jan 11 10:30:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03858 for ; Thu, 11 Jan 2001 10:30:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12310; Thu, 11 Jan 2001 10:30:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12279 for ; Thu, 11 Jan 2001 10:30:23 -0500 (EST) Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03843 for ; Thu, 11 Jan 2001 10:30:21 -0500 (EST) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id KAA05802 for ; Thu, 11 Jan 2001 10:21:47 -0500 (EST) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852569D1.00545F56 ; Thu, 11 Jan 2001 10:21:34 -0500 X-Lotus-FromDomain: TELCORDIA From: "Jay R. Hilton" To: enum@ietf.org Message-ID: <852569D1.00545EBF.00@notes949.cc.telcordia.com> Date: Thu, 11 Jan 2001 10:20:53 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Enum] Notes from Dec. 14, 2000 ENUM Mtg Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Enclosed are the notes from the December meeting of ENUM. PLease review and provide any comments / corrections to me at jhilton@telcordia.com. Regards, Jay Hilton Telephone Number Mapping WG (enum) Meeting Notes THURSDAY, December 14 at 1300-1500 ================================== CHAIR: Richard Shockey AGENDA: 1. Agenda Bashing (5 min) Introductions, blue sheets, etc. RS - The agenda was approved as proposed. 2. Thanks to our former co-chair Scott Petrak - The meeting expressed thanks to Scott Petrak for getting ENUM started and moving on this important activity. 3. ENUM Administration in the United States - Penn Pfautz - James Yu (20 min) draft-pfautz-yu-enum-adm-00.txt - Discusses both domain registration and Telephone number Administration. - Major issues identified included: - Authentication of rights to the telephone number. - Disconnect notification. - Telephony service specific records. - The Enum Hierarchy proposed in the document is: e164.arpa (RIPE), Tier 1 (defined by the ITU Member State), Tier 2 - Service Registrar (NAPTR Records), Tier 3 Service Registrar. - Regarding the discussion on Authorization Rights: - Rights to ENUM domain is tied to number assignments in the PSTN. - Generally, the telephone service provider (TSP) is only party that knows if party is authorized. - This is a design issue for the industry. - Regarding the discussion on Disconnect Notify: - Rights to number in ENUM are lost when service on the telephone number is disconnected. - Again, only the TSP knows if party is authorized. - Regarding the discussion on "Telephony Service Specific Records" - Are there services for which the TSP should have the right to put records in ENUM? - How can TSP control records in Tier 2 of end user choice? - How might these records be distinguished? - Alternative is to treat the TSP like any other applications service provide. - Ability of the TSP to populate ENUM four the customer will facilitate penetration. - Comment that the document is generic enough that it will apply outside of the USA as well. For example, in countries where they have NP, etc. - Comment that the document needs to be renamed to a Generic Document. Put North AM specific information in an appendix. REFERENCE MODEL for the ENUM Admin Process: (James Yu) - ENUM DNS Hierarchy in the U.S. - Showed e164.arpa and tier 1, 2, and 3 positions in the hierarchy. - Ref Model I (General) model shows interface points A-H. - James stepped through examples showing how architecture would work. - Ref Model II has simplified model. - Next Steps: - Enhance the model to include. - # Portability administrator. - Etc. - Generalize the names in the ref model to represent their roles in the ENUM admin process. Should this document be generalized and then forwarded for WG approval as Informational RFCs? Question from the floor, suggested that we should look at the next admin model before we make this decision. Also a note that this is one model and is not a definitive statement from that the IETF supports this model. An Info RFC means that this is for info and does not indicate the WG says that this how it should work. Comment from the floor: This WG should state how DNS should be used to support ENUM, and may develop a Best Current Practices (BCP) for use of DNS for ENUM. This document will be either merged with the document that follows regarding Admin processes for ENUM, or if this is not possible, then it may be published as a separate Informational RFC. 4. ENUM - Tier 1 Roles-00.txt - Doug Ranalli (10-15 Min), http://www.ietf.org/internet-drafts/draft-ranalli-peek- walter-enum-t1roles-00.txt Defines a set of "actors". It further defines the roles and responsibilities for "actors". Logical 1st Tier of ENUM System; assumes e.164 # has been assigned to subscriber. Registration and translation of e/164 name into IP-Address of authoritative Tier-2 name server. Physical Tiers: Multiple physical tiers in the proposed IETF-ITU ENUM System. Background: derived from experience in operating ENUM and related services. WG Feedback was requested in 3 areas: - # Provider terminology? - Who has valid registration rights? - Role of # Portability in Tier-1? Proposes a separation of the entity that assigns E.164 # from telephone service provider Tel Number Provider (TNP). 800# example in the US. 2 entities w/registration rights subscriber. Sub Agent (Svc Provider). Tel number Provider has disconnect rights TNP revokes Sub assignment. Dialing plan change. Role of Number Portability in Tier 1 ENUM (NP doesn't apply) Subscriber doesn't change. TNP change only important when exercising exclusive disconnect rights. Confirm role in Tier-1 NEXT Steps - Next version after this meeting - Looking for continuing input from the WG There was discussion that WG may want these two documents to be merged? Ranalli wants to advance this work and perhaps put it in a standards track. S. Bradner indicated that he did not think that we should pursue a standards track or BCP. This would be outside of scope of this WG. Suggestion that an Info RFC is still the best way to go. There was then general agreement that an Info RFC is the way to go. Therefore, it was agreed that both documents will either be merged into a single document or if not possible, both published as individual Info RFCs. 5. ENUM Call Flows - Steve Lind (15 Min), http://www.ietf.org/internet-drafts/draft-lind-enum-callflows-01.txt This document described basic calls using interworking, PSTN-IP and IP-PSTN. It further discussed global services such as - Universal International freephone, International premium rate, shared cost, etc. Steve pointed out that the ITU-T Document COM2-R80 contains the number portability work in SG2. It was proposed that the group develop options for PSTN->IP Gateway identification. This would include. if no DNS records, preference to try to complete the call to number dialed by the end user. It was proposed that the Freephone section should address all global svc (UIFS, IPRS, ISCS). It was also proposed that UIFS calls should route to a central proxy server where, based on point-of-origin or other customer-provided info, proxy can redirect to forward call to the proper destination. NEXT STEPS< resolve outstanding issues A revision of this work will be seen at the January 2001 SG2 meeting. It was proposed that this draft could be a WG Draft for an Informational RFC. Given that is the way to go forward then the WG can expect the document to be ready for WG last call in Sept 2001. An Info RFC may be available shortly after the SG2 meeting in Jan 2001. A comment was made that the mailing list will still go on even if the WG stops and we can approve Last Calls on the mail list. 6. ENUM Operations - Greg Vardureuil (20 min + ) http://www.ietf.org/internet-drafts/draft-ietf-enum-operation-01.txt It was agreed that the title no longer reflects the true focus of the document. Propose to rename to "An ENUM Service Reference Model", because the document is not focused on Admin models, it is not a DNS BCP. However, it does define common terms and topologies and provides context for client implementers. Intention is NOT to define a service. Looking for suggestion for a new name for the document . The Document does propose definitions for Tiers. Tier 1 - 4: regulator to TNP, TNP to svc registrar, svc registrar to NAPTRs, URL to service-specific info respectively. There was discussion to keep the proposal to 4 levels. - Discussion: In this document the Tiers are a proposed transition from one tier to another. Need further definition of Tiers, need to come to consensus. Maybe we need to use another word besides Tier in this document. R. Shockey suggested to collapse tier 1 and 2 in this document. Perhaps this should be a separate model form the previous two documents. After continuing discussion, it was agreed to take the discussion off line to harmonize this these terms. There was some potential Dname-Cname /NAPTR Interactions. May have unintentional interactions where 2 telephone numbers initial strings resolve to the same leaf mode. Proposed resolutions: - Profile NAPTR substitution for ENUM to limit the potential for unintended results - Profile / discourage DNAME/CNAME out of DNS for ENUM use. It was agreed to wait to resolve this interaction until experience with ENUM implementations is gained. Lots of discussion regarding the use of cname and dname. Suggestion that these names are not appropriate for these discussions. Take cname and dname out of this draft Randy: Why do we need this? Greg V.: Telephone renumbering is the issue. Would like to use pointers rather than duplicate database. Randy: Discussion has not supported this. Greg stated that there is expected to be a lot of renumbering. WG Agreement: All references to CNAME and DNAME should be expunged (removed) from this document. This document also discussed Performance Issues: It is unclear whether proposed ENUM hierarchy will perform as required over the open Internet. Discussion followed: UDP packet loss rates and client retry-intervals appear to take too long. This is a packet loss over the Internet question. Some people have stated that as high as 10-40% packet loss could occur. Some specifics statistics were quoted to the meeting. A request was made that this kind of data would be helpful in our discussions. Several comments from people that are putting up ENUM trials suggest that people could run test on these trials to gather data. The WG Agreement was again to wait until experience is available on this issue and then revise the document if necessary. Greg still needs additional text that was promised, but did not arrive, after the last meeting. Additional general editorial clean up. What is this document, Standard, Info RFC or BCP?? A proposal to publish this document as an Informational RFC, once harmonization has occurred, and additional edits completed was agreed. 7. Further Updates on IETF-ITU discussions coming out of ITU Study Group 2 meetings in Berlin. (Chair - Others) - (10 min +) ISCO(IAB/IETF)-ITU Agreements/or understandings (these agreements were actually with the WP1/2 of ITU-T SG2).: Domain zone administration was agreed to be outside the scope of this meeting and WP1/2. ITU will see to it that each Member State has authority for the inclusion of their country code info for input to the DNS. (ENUM is not approved for use in any national state, etc.) The national zone, for geographic resources, is a national matter and is, therefore administered by the ITU Member States to which the country code is assigned. all admin entities, including DNS admins, will adhere to all the applicable tenets of all pertinent ITU Recs, with regard to the inclusion of the E.164 resource information in the DNS. The ITU, IETF and IAB will jointly cooperate fully to ensure that the agreements and procedures to accommodate the above understandings, and any other mutually agreed appropriate future understandings, will be implemented and adhered to on an ongoing basis. The ITU may request the consultation of the WP1/2 experts as necessary and as prescribed in Resolution 20. There was some discussion to clarify who the agreements / understandings were with. S. Bradner clarified that this was an agreement with the ITU regarding the info they had regarding who had number databases. Further Clarification: This agreement only covers e164.arpa, no other domain names are affected. See the liaison statement from WP1/2. ITU has a list of who is the authority that can speak on numbers for the countries. The ITU is not assuming jurisdiction over DNS. Preview upcoming SG2 work. http://www.ietf.org/internet-drafts/draft-itu-sg2-liason-enum-01.txt There was not time to review this document. Attendees are encouraged to review the document to see the plan of upcoming SG2 work. 8. WG next steps - ENUM MIB? (10 min +) Does ENUM protocol need a MIB? No, WG agreed this is not needed! Chair will delete ENUM MIB from WG charter. The question of what the ENUM WG should do now that it has developed the ENUM protocol. Suggestions were: - Go Dormant - Recharter - Conclude Proposal: ENUM has done its job and developed the core protocol for ENUM. NO OBJECTIONS, by the WG. Options now for the ENUM WG A: Go to sleep, take on no new work B: Close the WG After asking the question on each item, there was no clear majority for either course of action. S. Bradner then stated that the ADs will take this under consideration and decide. 9. Open Discussion Additional Reference Documents: These have been submitted but will not be presented at the meeting. Number Portability in the GSTN http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-gstn-np-00.txt Number Portability in the United States http://www.ietf.org/internet-drafts/draft-foster-e164-gstn-npusa-00.txt End of meeting. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Jan 12 09:34:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09673 for ; Fri, 12 Jan 2001 09:34:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02486; Fri, 12 Jan 2001 09:33:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02461 for ; Fri, 12 Jan 2001 09:32:57 -0500 (EST) Received: from rainier.illuminet.com (root@rainier.illuminet.com [192.246.48.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09628 for ; Fri, 12 Jan 2001 09:32:53 -0500 (EST) Received: from cirrus.illuminet.com (cirrus.illuminet.com [198.202.215.22]) by rainier.illuminet.com (8.8.8/8.8.8) with SMTP id GAA28271 for ; Fri, 12 Jan 2001 06:32:53 -0800 (PST) Received: from Olympia-Message_Server by cirrus.illuminet.com with Novell_GroupWise; Fri, 12 Jan 2001 06:32:51 -0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 12 Jan 2001 06:32:39 -0800 From: "Kevin McCandless" To: , Subject: Re: [Enum] SGA Ad-Hoc on ENUM Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_9BC0F383.D5B4C2A6" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --=_9BC0F383.D5B4C2A6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello: After reading the Meeting Notice for the SGA Ad-Hoc and learning about the = ITAB group being developed, by NetNumber, could some one please tell me = what the purpose of these two groups are and why there are two groups when = ENUM working Group was only one? Who will be particiapting in these = meetings? I want to participate in the meetings in the correct meetings = so to speak. Kevin >>> "Gary W. Richenaker" 01/10/01 03:51PM >>> Attached is the meeting notice and registration information regarding the February SGA Ad-Hoc meeting on ENUM. If you have any questions, please feel free to contact me. Gary Richenaker (See attached file: ENUM Meeting Notice.doc) --=_9BC0F383.D5B4C2A6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello:
 
After reading the Meeting Notice for the SGA Ad-Hoc and learning = about the=20 ITAB group being developed, by NetNumber, could some one please tell me = what the=20 purpose of these two groups are and why there are two groups when ENUM = working=20 Group was only one?  Who will be particiapting in these meetings? = ; I=20 want to participate in the meetings in the correct meetings so to = speak.
 
Kevin

>>> "Gary W. Richenaker"=20 <grichena@telcordia.com> 01/10/01 03:51PM >>>


Att= ached=20 is the meeting notice and registration information regarding the
Februar= y SGA=20 Ad-Hoc meeting on ENUM.

If you have any questions, please feel free = to=20 contact me.

Gary Richenaker

(See attached file: ENUM = Meeting=20 Notice.doc)
--=_9BC0F383.D5B4C2A6-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Jan 12 09:39:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09750 for ; Fri, 12 Jan 2001 09:39:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02553; Fri, 12 Jan 2001 09:39:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02524 for ; Fri, 12 Jan 2001 09:39:02 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09724 for ; Fri, 12 Jan 2001 09:39:01 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14H5Lz-0008u2-00; Fri, 12 Jan 2001 06:38:55 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kevin McCandless" Cc: , Subject: Re: [Enum] SGA Ad-Hoc on ENUM References: Message-Id: Date: Fri, 12 Jan 2001 06:38:55 -0800 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > After reading the Meeting Notice for the SGA Ad-Hoc and learning about the > ITAB group being developed, by NetNumber, could some one please tell me > what the purpose of these two groups are and why there are two groups when > ENUM working Group was only one? people smell either money, power, or both. randy _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Jan 12 10:10:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10240 for ; Fri, 12 Jan 2001 10:10:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02917; Fri, 12 Jan 2001 10:09:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02888 for ; Fri, 12 Jan 2001 10:09:56 -0500 (EST) Received: from exchange.chaos.com (exchange.chaos.com [206.5.17.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10226 for ; Fri, 12 Jan 2001 10:09:54 -0500 (EST) Received: from [216.168.250.24] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id otakaaaa for enum@ietf.org; Fri, 12 Jan 2001 10:09:54 -0500 Message-Id: <5.0.2.1.2.20010112100159.00a74a70@mail.netmagic.com> X-Sender: amr@mail.netmagic.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 12 Jan 2001 10:09:53 -0500 To: "Kevin McCandless" , , From: "A.M.Rutkowski" Subject: Re: [Enum] SGA Ad-Hoc on ENUM In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Kevin, >After reading the Meeting Notice for the SGA Ad-Hoc and learning about the >ITAB group being developed, by NetNumber, could some one please tell me >what the purpose of these two groups are and why there are two groups when >ENUM working Group was only one? Who will be particiapting in these >meetings? I want to participate in the meetings in the correct meetings >so to speak. The SG-A Ad-Hoc is a creature of a long standing USGOV public advisory committee that deals with ITU related matters. Perhaps most importantly, it provides antitrust protection for discussions concerning ENUM administrative policy, a fully open process, and a measure of USGOV approval to the extent the participating agencies buy into the resulting policies. In some instances, further additional formal agency policy making is required to meet the APA. ITAB is a potentially viable purely industry forum that could serve as a long term means of coordinating administrative and operations matters among ENUM services and product providers. --tony _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Jan 12 10:11:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10266 for ; Fri, 12 Jan 2001 10:11:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02964; Fri, 12 Jan 2001 10:10:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02937 for ; Fri, 12 Jan 2001 10:10:27 -0500 (EST) Received: from heron.verisign.com ([216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10236 for ; Fri, 12 Jan 2001 10:10:26 -0500 (EST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA17898; Fri, 12 Jan 2001 09:58:58 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 10:04:34 -0500 Message-ID: From: "Conley, Pat" To: "'Randy Bush'" , Kevin McCandless Cc: enum@ietf.org, grichena@telcordia.com Subject: RE: [Enum] SGA Ad-Hoc on ENUM Date: Fri, 12 Jan 2001 10:04:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org The ITAB group was (and perhaps is) a suggestion by NetNumber to set up a board to oversee the deployment of .tel. This was part of their application to ICANN for the .tel top level domain. They have to speak on any ongoing plans for that body... but it was (as I understand it) never a "working group" of any kind. On the other hand, the SGA WG has been set up to work through policy and regulatory issues that are specific to the U.S. deployment and are clearly out of scope for the IETF WG, but most likely of interest to members of thie mail list. pat -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Friday, January 12, 2001 9:39 AM To: Kevin McCandless Cc: enum@ietf.org; grichena@telcordia.com Subject: Re: [Enum] SGA Ad-Hoc on ENUM > After reading the Meeting Notice for the SGA Ad-Hoc and learning about the > ITAB group being developed, by NetNumber, could some one please tell me > what the purpose of these two groups are and why there are two groups when > ENUM working Group was only one? people smell either money, power, or both. randy _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Jan 12 11:29:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11770 for ; Fri, 12 Jan 2001 11:28:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03737; Fri, 12 Jan 2001 11:25:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03708 for ; Fri, 12 Jan 2001 11:25:06 -0500 (EST) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11684 for ; Fri, 12 Jan 2001 11:25:03 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 17:23:06 +0100 Message-ID: <98388C05D464D111B61800805F1504160233A1C0@p-ibis.issy.cnet.fr> From: BARNOLE Valerie FTRD/DAC/ISS To: "'A.M.Rutkowski'" , Kevin McCandless Cc: enum@ietf.org, grichena@telcordia.com Subject: RE: [Enum] SGA Ad-Hoc on ENUM Date: Fri, 12 Jan 2001 17:23:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA03709 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id LAA03737 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA11770 Like Kevin, I have some questions about these meetings. Are these meeting supposed to deal only with US policy or implementation regarding ENUM ? I could believe it when I look at the title "US administrative ENUM issues". But I am not so sure... Are attendants only US ? Do they intend to produce contributions to IETF or ITU ? As a european and an ENUM concerned party, I feel a little umconfortable not being able to set the landscape for this ad hoc group. Valerie. end of message _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Valérie Barnole FTR&D/DAC/ACE tel. : + 33 1 45 29 58 39 fax : + 33 1 46 29 31 42 mail to : valerie.barnole@francetelecom.fr -----Message d'origine----- De : A.M.Rutkowski [mailto:amr@netmagic.com] Envoyé : vendredi 12 janvier 2001 16:10 À : Kevin McCandless; enum@ietf.org; grichena@telcordia.com Objet : Re: [Enum] SGA Ad-Hoc on ENUM Hi Kevin, >After reading the Meeting Notice for the SGA Ad-Hoc and learning about the >ITAB group being developed, by NetNumber, could some one please tell me >what the purpose of these two groups are and why there are two groups when >ENUM working Group was only one? Who will be particiapting in these >meetings? I want to participate in the meetings in the correct meetings >so to speak. The SG-A Ad-Hoc is a creature of a long standing USGOV public advisory committee that deals with ITU related matters. Perhaps most importantly, it provides antitrust protection for discussions concerning ENUM administrative policy, a fully open process, and a measure of USGOV approval to the extent the participating agencies buy into the resulting policies. In some instances, further additional formal agency policy making is required to meet the APA. ITAB is a potentially viable purely industry forum that could serve as a long term means of coordinating administrative and operations matters among ENUM services and product providers. --tony _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Jan 12 11:33:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11821 for ; Fri, 12 Jan 2001 11:33:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03985; Fri, 12 Jan 2001 11:33:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03956 for ; Fri, 12 Jan 2001 11:33:34 -0500 (EST) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11817 for ; Fri, 12 Jan 2001 11:33:32 -0500 (EST) Received: by dnspri.npac.com; id KAA04215; Fri, 12 Jan 2001 10:33:32 -0600 (CST) Received: from unknown(192.168.20.111) by dnspri.npac.com via smap (V5.0) id xma003543; Fri, 12 Jan 01 10:33:12 -0600 Message-Id: <5.0.2.1.2.20010112105821.031d3060@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 12 Jan 2001 11:03:26 -0500 To: "A.M.Rutkowski" , "Kevin McCandless" , , From: Richard Shockey Subject: Re: [Enum] SGA Ad-Hoc on ENUM In-Reply-To: <5.0.2.1.2.20010112100159.00a74a70@mail.netmagic.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > >ITAB is a potentially viable purely industry >forum that could serve as a long term means of >coordinating administrative and operations >matters among ENUM services and product providers. ITAB was formed to promote the interest of the .TEL proposal which was not approved by ICANN and the ITU raised serious objections to. If there is to be a "industry" forum for this it would clearly have to be neutral and represent all of the various constituencies involved in this process. Carriers, equipment suppliers, etc we should not forget that several telecom industry groups are already looking at ENUM seriously etc. >--tony > > >_______________________________________________ >enum mailing list >enum@ietf.org >http://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005 Voice: 202.533.2811, Cell : 314.503.0640, Fax: 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Jan 12 11:38:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11898 for ; Fri, 12 Jan 2001 11:38:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04055; Fri, 12 Jan 2001 11:37:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04027 for ; Fri, 12 Jan 2001 11:37:03 -0500 (EST) Received: from exchange.chaos.com (exchange.chaos.com [206.5.17.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11884 for ; Fri, 12 Jan 2001 11:37:01 -0500 (EST) Received: from [216.168.250.24] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id oxakaaaa for enum@ietf.org; Fri, 12 Jan 2001 11:37:03 -0500 Message-Id: <5.0.2.1.2.20010112112819.00b03118@mail.netmagic.com> X-Sender: amr@mail.netmagic.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 12 Jan 2001 11:37:01 -0500 To: BARNOLE Valerie FTRD/DAC/ISS , Kevin McCandless From: "A.M.Rutkowski" Subject: RE: [Enum] SGA Ad-Hoc on ENUM Cc: enum@ietf.org, grichena@telcordia.com In-Reply-To: <98388C05D464D111B61800805F1504160233A1C0@p-ibis.issy.cnet. fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Valerie, >Are these meeting supposed to deal only with US policy or implementation >regarding ENUM ? I could believe it when I look at the title "US >administrative ENUM issues". But I am not so sure... >Are attendants only US ? Do they intend to produce contributions to IETF or >ITU ? >As a european and an ENUM concerned party, I feel a little umconfortable not >being able to set the landscape for this ad hoc group. ITAC - of which this group is a part - is a policy making mechanism of the US Government that is constituted by members from U.S. industry and the public. You can find a useful explanation at: http://www.state.gov/www/issues/economic/cip/itac.html Many other nations and regional organizations have similar bodies. --tony _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Jan 12 11:44:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12013 for ; Fri, 12 Jan 2001 11:44:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04175; Fri, 12 Jan 2001 11:43:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04144 for ; Fri, 12 Jan 2001 11:43:37 -0500 (EST) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12006 for ; Fri, 12 Jan 2001 11:43:34 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 17:41:20 +0100 Message-ID: <98388C05D464D111B61800805F1504160233A1C1@p-ibis.issy.cnet.fr> From: BARNOLE Valerie FTRD/DAC/ISS To: "'A.M.Rutkowski'" Cc: enum@ietf.org, grichena@telcordia.com, Kevin McCandless Subject: RE: [Enum] SGA Ad-Hoc on ENUM Date: Fri, 12 Jan 2001 17:41:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA04145 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id LAA04175 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA12013 Thanks Tony, I get it better. end of message _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Valérie Barnole FTR&D/DAC/ACE tel. : + 33 1 45 29 58 39 fax : + 33 1 46 29 31 42 mail to : valerie.barnole@francetelecom.fr -----Message d'origine----- De : A.M.Rutkowski [mailto:amr@netmagic.com] Envoyé : vendredi 12 janvier 2001 17:37 À : BARNOLE Valerie FTRD/DAC/ISS; Kevin McCandless Cc : enum@ietf.org; grichena@telcordia.com Objet : RE: [Enum] SGA Ad-Hoc on ENUM Hi Valerie, >Are these meeting supposed to deal only with US policy or implementation >regarding ENUM ? I could believe it when I look at the title "US >administrative ENUM issues". But I am not so sure... >Are attendants only US ? Do they intend to produce contributions to IETF or >ITU ? >As a european and an ENUM concerned party, I feel a little umconfortable not >being able to set the landscape for this ad hoc group. ITAC - of which this group is a part - is a policy making mechanism of the US Government that is constituted by members from U.S. industry and the public. You can find a useful explanation at: http://www.state.gov/www/issues/economic/cip/itac.html Many other nations and regional organizations have similar bodies. --tony _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Jan 12 11:44:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12024 for ; Fri, 12 Jan 2001 11:44:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04225; Fri, 12 Jan 2001 11:43:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04190 for ; Fri, 12 Jan 2001 11:43:53 -0500 (EST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12010 for ; Fri, 12 Jan 2001 11:43:51 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14H7HV-000Cnp-00; Fri, 12 Jan 2001 08:42:25 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Richard Shockey Cc: "A.M.Rutkowski" , "Kevin McCandless" , , Subject: Re: [Enum] SGA Ad-Hoc on ENUM References: <5.0.2.1.2.20010112105821.031d3060@127.0.0.1> Message-Id: Date: Fri, 12 Jan 2001 08:42:25 -0800 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit >> ITAB is a potentially viable purely industry forum that could serve as a >> long term means of coordinating administrative and operations matters >> among ENUM services and product providers. > ITAB was formed to promote the interest of the .TEL proposal which was > not approved by ICANN and the ITU raised serious objections to. the smell of dripping greed randy _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Jan 12 14:08:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15211 for ; Fri, 12 Jan 2001 14:08:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06060; Fri, 12 Jan 2001 14:08:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06035 for ; Fri, 12 Jan 2001 14:08:14 -0500 (EST) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15201 for ; Fri, 12 Jan 2001 14:08:12 -0500 (EST) Received: by dnspri.npac.com; id NAA00231; Fri, 12 Jan 2001 13:08:13 -0600 (CST) Received: from unknown(192.168.20.111) by dnspri.npac.com via smap (V5.0) id xmaa00190; Fri, 12 Jan 01 13:07:53 -0600 Message-Id: <5.0.2.1.2.20010112131221.02d728c0@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 12 Jan 2001 14:09:48 -0500 To: "A.M.Rutkowski" , Richard Shockey , ENUM@ALMSNTSA.LMLIST.STATE.GOV From: Richard Shockey Subject: Re: [ENUM] French contribution Cc: enum@ietf.org In-Reply-To: <5.0.2.1.2.20010112124334.00a75090@mail.netmagic.com> References: <5.0.2.1.2.20010112121117.03289e50@127.0.0.1> <3309B573228FD411AF4500D0B784A148AE39E2@netsol-nic-ex01.pro d.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 12:46 PM 1/12/2001 -0500, A.M.Rutkowski wrote: >>>In case you didn't notice, there is a fairly extreme >>>French government delayed contribution on ENUM that >>>has just been submitted. See >>>http://www.itu.int/itudoc/itu-t/com2/dcontr/01-04/dc-jan01/15.html >> >>Tony ..you have to have a TIES account to access this. > >Hi Richard, > >You can see it at http://www.ngi.org/enum/pub/15_ww9.htm Actually this is not as bad as I might have suspected. It has many positive points. The French accept the value of RFC2916 as a "good thing" and that the use of E.164 naming is, and I quote ,"has the advantages of being stable world-wide used and well digested by end users". ( I always enjoy references to food in technical documents) and "could facilitate the penetration of new applications into the mass market" .. a sentiment I totally agree with. The contribution clearly understands the need for consistency between e164.arpa and E.164 and that there is a technical mandate for a single unique DNS tree. DNS Client resolvers cannot sort through multiple TLD to find a authoritive NS. Where there seems to be some trouble is understanding the nature of e164.arpa. I thought we made this clear. RFC2916 states that e164.arpa follows E.164 and E.164 is a product of the ITU, ... but this has been troublesome to many for quite a while. I think some of us need to work a bit harder work harder to connect the dots here. Among other things: The contribution does not address ITU E.164 Network or Test codes etc. I certainly agree that each Member-State is responsible for "appointing the body in charge of the management of the ENUM sub-domain". This document _could_ be useful. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005 Voice: 202.533.2811, Cell : 314.503.0640, Fax: 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sun Jan 14 18:17:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11055 for ; Sun, 14 Jan 2001 18:17:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13125; Sun, 14 Jan 2001 18:16:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13098 for ; Sun, 14 Jan 2001 18:16:18 -0500 (EST) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11045 for ; Sun, 14 Jan 2001 18:16:18 -0500 (EST) Received: from computer.ix.netcom.com (user-2ivemk5.dialup.mindspring.com [165.247.90.133]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id SAA05461; Sun, 14 Jan 2001 18:16:13 -0500 (EST) Message-Id: <5.0.2.1.2.20010114171941.026f21f0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 14 Jan 2001 17:23:22 -0500 To: enum@ietf.org From: Richard Shockey Cc: Anne Brown , "Vaudreuil, Greg M (Greg)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] I'm taking it that silence is consent and the Minutes of the meeting are ok? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Beyond that I'd like authors to begin to consider their re submission for potential last call. This would be the Requirement, Operations as well as the LNP Informational documents... I think there are no outstanding issues on those beyond what were discussed at the meeting. Other work is under ongoing revision... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005 Voice: 202.533.2811, Cell : 314.503.0640, Fax: 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jan 17 03:32:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14626 for ; Wed, 17 Jan 2001 03:32:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11732; Wed, 17 Jan 2001 03:31:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11702 for ; Wed, 17 Jan 2001 03:31:46 -0500 (EST) Received: from mail.nic.or.kr (mail.nic.or.kr [202.30.50.115]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14621 for ; Wed, 17 Jan 2001 03:31:44 -0500 (EST) Received: from ssw ([203.255.208.201]) by mail.nic.or.kr (8.11.0/8.11.0) with SMTP id f0H8TEE02486 for ; Wed, 17 Jan 2001 17:29:14 +0900 (KST) Message-ID: <003a01c0805f$e0e92c80$c9d0ffcb@nic.or.kr> From: =?ks_c_5601-1987?B?vcW8ur/s?= To: Date: Wed, 17 Jan 2001 17:31:24 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C080AB.50B86A80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [Enum] ssw@nic.or.kr Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C080AB.50B86A80 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 c3N3QG5pYy5vci5rcg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KU3VuZy1Xb28gU0hJTiwgQXNzaXN0YW50IE1hbmFnZXINClBvbGljeSBEZXZlbG9w bWVudCBhbmQgUmVzZWFyY2ggRGl2aXNpb24NCktvcmVhIE5ldHdvcmsgSW5mb3JtYXRpb24gQ2Vu dGVyDQpUZWwgOiArIDgyIDIgMjE4NiA0NTQ2DQpGYXggOiArIDgyIDIgMjE4NiA0NDk2DQpzc3dA bmljLm9yLmtyDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNCg0K ------=_NextPart_000_0037_01C080AB.50B86A80 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+c3N3QG5pYy5vci5rcjwvRElWPg0K PERJVj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJS PlN1bmctV29vIFNISU4sIA0KQXNzaXN0YW50IE1hbmFnZXI8QlI+UG9saWN5IERldmVsb3BtZW50 IGFuZCBSZXNlYXJjaCBEaXZpc2lvbjxCUj5Lb3JlYSBOZXR3b3JrIA0KSW5mb3JtYXRpb24gQ2Vu dGVyPEJSPlRlbCA6ICsgODIgMiAyMTg2IDQ1NDY8QlI+RmF4IDogKyA4MiAyIDIxODYgNDQ5NjxC Uj48QSANCmhyZWY9Im1haWx0bzpzc3dAbmljLm9yLmtyIj5zc3dAbmljLm9yLmtyPC9BPjxCUj4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0037_01C080AB.50B86A80-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sat Jan 20 14:56:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28990 for ; Sat, 20 Jan 2001 14:56:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25012; Sat, 20 Jan 2001 14:54:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24983 for ; Sat, 20 Jan 2001 14:54:57 -0500 (EST) Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28984 for ; Sat, 20 Jan 2001 14:54:56 -0500 (EST) Received: from computer.ix.netcom.com (user-2ivek8d.dialup.mindspring.com [165.247.81.13]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id OAA31582; Sat, 20 Jan 2001 14:54:51 -0500 (EST) Message-Id: <5.0.2.1.2.20010120144613.03308ec0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 20 Jan 2001 14:47:28 -0500 To: enum@ietf.org From: Richard Shockey Cc: ENUM@ALMSNTSA.LMLIST.STATE.GOV Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: RFC 3026 on Liaison to IETF/ISOC on ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >To: IETF-Announce: ; >Subject: RFC 3026 on Liaison to IETF/ISOC on ENUM >Cc: rfc-ed@ISI.EDU >Date: Fri, 19 Jan 2001 10:23:20 -0800 >From: RFC Editor > > >A new Request for Comments is now available in online RFC libraries. > > > RFC 3026 > > Title: Liaison to IETF/ISOC on ENUM > Author(s): R. Blane > Status: Informational > Date: January 2001 > Mailbox: Roy_Blane@inmarsat.com > Pages: 6 > Characters: 11460 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-itu-sg2-liason-enum-01.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3026.txt > > >Working Party 1/2, of the International Telecommunication Union >Telecommunication Standardization Sector (ITU-T) held a meeting of >its collaborators in Berlin Germany 19-26 October 2000. The agenda >of the meeting contained several contributions regarding RFC 2916: >"E.164 Number and DNS" from the Internet Engineering Task Force's >(IETF) ENUM Working Group - more specifically, the method for >administering and maintaining the E.164-based resources in the >Domain Name System (DNS) as related to the ENUM protocol. >Consequently, in addition to the WP1/2 collaborators, there were >several members of the IETF present to assist with the discussion of >issues contained in the aforementioned contributions. > >This liaison from WP1/2 to the IETF/ISOC conveys the understandings >of the WP1/2 collaborators resulting from the discussions. > >This memo provides information for the Internet community. It does >not specify an Internet standard of any kind. Distribution of this >memo is unlimited. > >This announcement is sent to the IETF list and the RFC-DIST list. >Requests to be added to or deleted from the IETF distribution list >should be sent to IETF-REQUEST@IETF.ORG. Requests to be >added to or deleted from the RFC-DIST distribution list should >be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > >Details on obtaining RFCs via FTP or EMAIL may be obtained by sending >an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body >help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution.echo >Submissions for Requests for Comments should be sent to >RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC >Authors, for further information. > > >Joyce K. Reynolds and Sandy Ginoza >USC/Information Sciences Institute > >... > >Below is the data which will enable a MIME compliant Mail Reader >implementation to automatically retrieve the ASCII version >of the RFCs. >Content-Type: text/plain >Content-ID: <010119101914.RFC@RFC-EDITOR.ORG> > >RETRIEVE: rfc >DOC-ID: rfc3026 > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005 Voice: 202.533.2811, Cell : 314.503.0640, Fax: 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 08:52:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04253 for ; Mon, 22 Jan 2001 08:52:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28202; Mon, 22 Jan 2001 08:51:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28173 for ; Mon, 22 Jan 2001 08:51:01 -0500 (EST) Received: from rainier.illuminet.com ([63.116.20.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04188 for ; Mon, 22 Jan 2001 08:50:58 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com ([172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id FAA29136 for ; Mon, 22 Jan 2001 05:50:28 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jan 2001 05:50:27 -0800 Message-ID: <1C1EEC765F843E44996971A80682118B2523DB@OPWINEXCL01> From: Kevin McCandless To: enum@ietf.org Subject: RE: [Enum] Fwd: RFC 3026 on Liaison to IETF/ISOC on ENUM Date: Mon, 22 Jan 2001 05:50:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Thank you for the information. Have a question on the ITU meeting that took place last week, January 18. Any notes or comments that can be shared from last weeks meeting? Sincerely, Kevin -----Original Message----- From: Richard Shockey [mailto:rshockey@ix.netcom.com] Sent: Saturday, January 20, 2001 1:47 PM To: enum@ietf.org Cc: ENUM@ALMSNTSA.LMLIST.STATE.GOV Subject: [Enum] Fwd: RFC 3026 on Liaison to IETF/ISOC on ENUM >To: IETF-Announce: ; >Subject: RFC 3026 on Liaison to IETF/ISOC on ENUM >Cc: rfc-ed@ISI.EDU >Date: Fri, 19 Jan 2001 10:23:20 -0800 >From: RFC Editor > > >A new Request for Comments is now available in online RFC libraries. > > > RFC 3026 > > Title: Liaison to IETF/ISOC on ENUM > Author(s): R. Blane > Status: Informational > Date: January 2001 > Mailbox: Roy_Blane@inmarsat.com > Pages: 6 > Characters: 11460 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-itu-sg2-liason-enum-01.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3026.txt > > >Working Party 1/2, of the International Telecommunication Union >Telecommunication Standardization Sector (ITU-T) held a meeting of >its collaborators in Berlin Germany 19-26 October 2000. The agenda >of the meeting contained several contributions regarding RFC 2916: >"E.164 Number and DNS" from the Internet Engineering Task Force's >(IETF) ENUM Working Group - more specifically, the method for >administering and maintaining the E.164-based resources in the >Domain Name System (DNS) as related to the ENUM protocol. >Consequently, in addition to the WP1/2 collaborators, there were >several members of the IETF present to assist with the discussion of >issues contained in the aforementioned contributions. > >This liaison from WP1/2 to the IETF/ISOC conveys the understandings >of the WP1/2 collaborators resulting from the discussions. > >This memo provides information for the Internet community. It does >not specify an Internet standard of any kind. Distribution of this >memo is unlimited. > >This announcement is sent to the IETF list and the RFC-DIST list. >Requests to be added to or deleted from the IETF distribution list >should be sent to IETF-REQUEST@IETF.ORG. Requests to be >added to or deleted from the RFC-DIST distribution list should >be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > >Details on obtaining RFCs via FTP or EMAIL may be obtained by sending >an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body >help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution.echo >Submissions for Requests for Comments should be sent to >RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC >Authors, for further information. > > >Joyce K. Reynolds and Sandy Ginoza >USC/Information Sciences Institute > >... > >Below is the data which will enable a MIME compliant Mail Reader >implementation to automatically retrieve the ASCII version >of the RFCs. >Content-Type: text/plain >Content-ID: <010119101914.RFC@RFC-EDITOR.ORG> > >RETRIEVE: rfc >DOC-ID: rfc3026 > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005 Voice: 202.533.2811, Cell : 314.503.0640, Fax: 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 10:07:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06013 for ; Mon, 22 Jan 2001 10:07:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29309; Mon, 22 Jan 2001 10:01:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29282 for ; Mon, 22 Jan 2001 10:01:21 -0500 (EST) Received: from rainier.illuminet.com ([63.116.20.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05945 for ; Mon, 22 Jan 2001 10:01:19 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com ([172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id HAA00197 for ; Mon, 22 Jan 2001 07:00:50 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jan 2001 07:00:50 -0800 Message-ID: <1C1EEC765F843E44996971A80682118B2523DD@OPWINEXCL01> From: Kevin McCandless To: enum@ietf.org Date: Mon, 22 Jan 2001 07:00:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] SIP 6th bake-off and enum Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Did anyone attend the 6th SIP bake-off? I saw a report from pulver.com that mentioned seventeen SIP vendors demostrated early stages of ENUM integrationduring. Any comments?? Seventeen SIP vendors demonstrated early stages of ENUM integration activity at the 6th SIP Bake-off by translating telephone numbers to SIP URI's in the call set-up process through utilizing ENUM services from NetNumber.com. ENUM is the name for the IETF standard (RFC 2916) that defines a DNS-based mechanism for mapping a telephone number to a list of Internet addresses or resources associated with that number. Kevin McCandless Senior Network Planner Illuminet 913-814-6397 kmccandles@illuminet.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 10:58:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07126 for ; Mon, 22 Jan 2001 10:58:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00095; Mon, 22 Jan 2001 10:57:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00064 for ; Mon, 22 Jan 2001 10:57:40 -0500 (EST) Received: from dnspri.npac.com (firewall-user@[208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07108 for ; Mon, 22 Jan 2001 10:57:38 -0500 (EST) Received: by dnspri.npac.com; id JAA26977; Mon, 22 Jan 2001 09:57:37 -0600 (CST) Received: from unknown(192.168.20.111) by dnspri.npac.com via smap (V5.0) id xmab25828; Mon, 22 Jan 01 09:57:14 -0600 Message-Id: <5.0.2.1.2.20010122104905.02a0f7e0@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 22 Jan 2001 10:51:00 -0500 To: Kevin McCandless , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] Fwd: RFC 3026 on Liaison to IETF/ISOC on ENUM Cc: ENUM@ALMSNTSA.LMLIST.STATE.GOV In-Reply-To: <1C1EEC765F843E44996971A80682118B2523DB@OPWINEXCL01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 05:50 AM 1/22/2001 -0800, Kevin McCandless wrote: >Thank you for the information. Have a question on the ITU meeting that took >place last week, January 18. Any notes or comments that can be shared from >last weeks meeting? I think all of the presentations as well as the Chairmans Report are due to be posted on the ITU ENUM website. http://www.itu.int/infocom/enum/ How ever if someone wants copies of the PPT files etc I can forward them on. > >To: IETF-Announce: ; > >Subject: RFC 3026 on Liaison to IETF/ISOC on ENUM > >Cc: rfc-ed@ISI.EDU > >Date: Fri, 19 Jan 2001 10:23:20 -0800 > >From: RFC Editor > > > > > >A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 3026 > > > > Title: Liaison to IETF/ISOC on ENUM > > Author(s): R. Blane > > Status: Informational > > Date: January 2001 > > Mailbox: Roy_Blane@inmarsat.com > > Pages: 6 > > Characters: 11460 > > Updates/Obsoletes/SeeAlso: None > > > > I-D Tag: draft-itu-sg2-liason-enum-01.txt > > > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3026.txt > > > > > >Working Party 1/2, of the International Telecommunication Union > >Telecommunication Standardization Sector (ITU-T) held a meeting of > >its collaborators in Berlin Germany 19-26 October 2000. The agenda > >of the meeting contained several contributions regarding RFC 2916: > >"E.164 Number and DNS" from the Internet Engineering Task Force's > >(IETF) ENUM Working Group - more specifically, the method for > >administering and maintaining the E.164-based resources in the > >Domain Name System (DNS) as related to the ENUM protocol. > >Consequently, in addition to the WP1/2 collaborators, there were > >several members of the IETF present to assist with the discussion of > >issues contained in the aforementioned contributions. > > > >This liaison from WP1/2 to the IETF/ISOC conveys the understandings > >of the WP1/2 collaborators resulting from the discussions. > > > >This memo provides information for the Internet community. It does > >not specify an Internet standard of any kind. Distribution of this > >memo is unlimited. > > > >This announcement is sent to the IETF list and the RFC-DIST list. > >Requests to be added to or deleted from the IETF distribution list > >should be sent to IETF-REQUEST@IETF.ORG. Requests to be > >added to or deleted from the RFC-DIST distribution list should > >be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > > >Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > >an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > >help: ways_to_get_rfcs. For example: > > > > To: rfc-info@RFC-EDITOR.ORG > > Subject: getting rfcs > > > > help: ways_to_get_rfcs > > > >Requests for special distribution should be addressed to either the > >author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > >specifically noted otherwise on the RFC itself, all RFCs are for > >unlimited distribution.echo > >Submissions for Requests for Comments should be sent to > >RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > >Authors, for further information. > > > > > >Joyce K. Reynolds and Sandy Ginoza > >USC/Information Sciences Institute > > > >... > > > >Below is the data which will enable a MIME compliant Mail Reader > >implementation to automatically retrieve the ASCII version > >of the RFCs. > >Content-Type: text/plain > >Content-ID: <010119101914.RFC@RFC-EDITOR.ORG> > > > >RETRIEVE: rfc > >DOC-ID: rfc3026 > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey, Senior Technical Industry Liaison >NeuStar Inc. >1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005 >Voice: 202.533.2811, Cell : 314.503.0640, Fax: 815.333.1237 > or > > ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > >_______________________________________________ >enum mailing list >enum@ietf.org >http://www1.ietf.org/mailman/listinfo/enum > >_______________________________________________ >enum mailing list >enum@ietf.org >http://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005 Voice: 202.533.2811, Cell : 314.503.0640, Fax: 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 11:08:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07483 for ; Mon, 22 Jan 2001 11:08:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00455; Mon, 22 Jan 2001 11:07:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00425 for ; Mon, 22 Jan 2001 11:07:41 -0500 (EST) Received: from dnspri.npac.com (firewall-user@[208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07470 for ; Mon, 22 Jan 2001 11:07:39 -0500 (EST) Received: by dnspri.npac.com; id KAA29172; Mon, 22 Jan 2001 10:07:39 -0600 (CST) Received: from unknown(192.168.20.111) by dnspri.npac.com via smap (V5.0) id xmab28165; Mon, 22 Jan 01 10:06:40 -0600 Message-Id: <5.0.2.1.2.20010122105735.02a38c20@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 22 Jan 2001 11:05:06 -0500 To: Kevin McCandless , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] SIP 6th bake-off and enum In-Reply-To: <1C1EEC765F843E44996971A80682118B2523DD@OPWINEXCL01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 07:00 AM 1/22/2001 -0800, Kevin McCandless wrote: >Did anyone attend the 6th SIP bake-off? I saw a report from pulver.com that >mentioned seventeen SIP vendors demostrated early stages of ENUM >integrationduring. Any comments?? Well this is a "good thing" .. but I'm assuming this was the use of ENUM _technology_ with private dialing plans. >Seventeen SIP vendors demonstrated early stages of ENUM integration >activity at the 6th SIP Bake-off by translating telephone numbers to SIP >URI's in the call set-up process through utilizing ENUM services from >NetNumber.com. ENUM is the name for the IETF standard (RFC 2916) that >defines a DNS-based mechanism for mapping a telephone number to a list of >Internet addresses or resources associated with that number. I hate to be a stickler for detail here but Pulver is a bit off . RFC 2916 is quite clear about this ..ENUM is about the integration of the ITU-T E.164 plan into e164.arpa and the status of that delegation is under active discussion among the Member States of the ITU. No decisions have currently been made on the delegation of the country code zones to the appropriate Member States. >Kevin McCandless >Senior Network Planner >Illuminet >913-814-6397 >kmccandles@illuminet.com > > >_______________________________________________ >enum mailing list >enum@ietf.org >http://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005 Voice: 202.533.2811, Cell : 314.503.0640, Fax: 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 11:11:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07611 for ; Mon, 22 Jan 2001 11:11:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00517; Mon, 22 Jan 2001 11:11:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00490 for ; Mon, 22 Jan 2001 11:11:27 -0500 (EST) Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net [38.202.36.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07584 for ; Mon, 22 Jan 2001 11:11:25 -0500 (EST) From: cjohn@netnumber.com Received: from hvwww01.us.psimail.psi.net ([38.202.35.152]) by hvmta03-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with ESMTP id <20010122161115.UJAX1236.hvmta03-stg@hvwww01.us.psimail.psi.net>; Mon, 22 Jan 2001 11:11:15 -0500 To: Cc: Reply-To: cjohn@netnumber.com Subject: Re: [Enum] SIP 6th bake-off and enum MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-Id: <20010122161115.UJAX1236.hvmta03-stg@hvwww01.us.psimail.psi.net> Date: Mon, 22 Jan 2001 11:11:15 -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Kevin, I am the head of Integration Engineering at NetNumber and I was a participant in the 6th SIP bake-off described in your note. During the event, the seventeen vendors that demonstrated early stages of ENUM activity broke down into two groups. A group of five vendors demonstrated ENUM resolution functionality that was integrated right into their code base. NetNumber provided the resolution code utilized by four of these vendors. The remaining 12 vendors demonstrated early stages of ENUM work by utilizing a SIP redirect capability to query the NetNumber ENUM directory. Redirect servers were provided by NetNumber and a leading SIP server vendor for use by all Bakeoff participants. Please feel free to contact me directly with any further questions. Regards, Chris John NetNumber.com cjohn@netnumber.com 1-617-593-8374 (cell) > Did anyone attend the 6th SIP bake-off? I saw a report from pulver.com that > mentioned seventeen SIP vendors demostrated early stages of ENUM > integrationduring. Any comments?? > > > Seventeen SIP vendors demonstrated early stages of ENUM integration > activity at the 6th SIP Bake-off by translating telephone numbers to SIP > URI's in the call set-up process through utilizing ENUM services from > NetNumber.com. ENUM is the name for the IETF standard (RFC 2916) that > defines a DNS-based mechanism for mapping a telephone number to a list of > Internet addresses or resources associated with that number. > > > > > Kevin McCandless > Senior Network Planner > Illuminet > 913-814-6397 > kmccandles@illuminet.com > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 11:28:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07980 for ; Mon, 22 Jan 2001 11:28:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00714; Mon, 22 Jan 2001 11:27:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00686 for ; Mon, 22 Jan 2001 11:27:00 -0500 (EST) Received: from exchange.chaos.com ([206.5.17.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07952 for ; Mon, 22 Jan 2001 11:26:57 -0500 (EST) Received: from [216.168.250.52] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id ehfkaaaa for enum@ietf.org; Mon, 22 Jan 2001 11:26:57 -0500 Message-Id: <5.0.2.1.2.20010122112423.00ad71b0@mail.netmagic.com> X-Sender: amr@mail.netmagic.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 22 Jan 2001 11:26:56 -0500 To: Kevin McCandless , enum@ietf.org From: "A.M. Rutkowski" Subject: RE: [Enum] Fwd: RFC 3026 on Liaison to IETF/ISOC on ENUM In-Reply-To: <1C1EEC765F843E44996971A80682118B2523DB@OPWINEXCL01> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5041299==_.ALT" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --=====================_5041299==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Kevin, A list of participants for the meeting is available at: http://www.ngi.org/enum/pub/ITU_workshop_010116_participation.htm --tony --=====================_5041299==_.ALT Content-Type: text/html; charset="us-ascii" Hi Kevin,

A list of participants for the meeting is available at:
http://www.ngi.org/enum/pub/ITU_workshop_010116_participation.htm

--tony
--=====================_5041299==_.ALT-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 11:55:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08654 for ; Mon, 22 Jan 2001 11:55:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01233; Mon, 22 Jan 2001 11:54:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01195 for ; Mon, 22 Jan 2001 11:53:13 -0500 (EST) Received: from exchange.chaos.com ([206.5.17.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08561 for ; Mon, 22 Jan 2001 11:53:05 -0500 (EST) Received: from [216.168.250.52] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id rhfkaaaa for enum@ietf.org; Mon, 22 Jan 2001 11:53:04 -0500 Message-Id: <5.0.2.1.2.20010122114402.0468d008@mail.netmagic.com> X-Sender: amr@mail.netmagic.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 22 Jan 2001 11:53:02 -0500 To: Richard Shockey , Kevin McCandless , enum@ietf.org From: "A.M. Rutkowski" Subject: Re: [Enum] SIP 6th bake-off and enum In-Reply-To: <5.0.2.1.2.20010122105735.02a38c20@127.0.0.1> References: <1C1EEC765F843E44996971A80682118B2523DD@OPWINEXCL01> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_6607200==_.ALT" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --=====================_6607200==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Richard, >I hate to be a stickler for detail here but Pulver is a bit off . RFC 2916 >is quite clear about this ..ENUM is about the integration of the ITU-T >E.164 plan into e164.arpa and the status of that delegation is under >active discussion among the Member States of the ITU. > >No decisions have currently been made on the delegation of the country >code zones to the appropriate Member States. As was discussed at the ITU meeting, there are those who disagree with your interpretation ENUM. ENUM is no less ENUM if the protocols are instantiated in a zone other than E164.ARPA. Indeed, in some jurisdictions, it's entirely possible it may never be instantiated in that zone. Indeed, it seems important for IETF to stick to protocol development rather than pre-ordaining competitive opportunities in the marketplace. --amr --=====================_6607200==_.ALT Content-Type: text/html; charset="us-ascii" Hi Richard,

I hate to be a stickler for detail here but Pulver is a bit off . RFC 2916 is quite clear about this ..ENUM is about the integration of the ITU-T E.164 plan into e164.arpa and the status of that delegation is under active discussion among the Member States of the ITU.

No decisions have currently been made on the delegation of the country code zones to the appropriate Member States.

As was discussed at the ITU meeting, there are those
who disagree with your interpretation ENUM.

ENUM is no less ENUM if the protocols are instantiated
in a zone other than E164.ARPA.  Indeed, in some jurisdictions,
it's entirely possible it may never be instantiated in
that zone.  Indeed, it seems important for IETF to stick to
protocol development rather than pre-ordaining competitive
opportunities in the marketplace.

--amr
--=====================_6607200==_.ALT-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 13:04:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10545 for ; Mon, 22 Jan 2001 13:04:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02366; Mon, 22 Jan 2001 13:03:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02338 for ; Mon, 22 Jan 2001 13:03:28 -0500 (EST) Received: from rainier.illuminet.com ([63.116.20.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10498 for ; Mon, 22 Jan 2001 13:03:27 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com ([172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id KAA05558 for ; Mon, 22 Jan 2001 10:02:56 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jan 2001 10:02:54 -0800 Message-ID: <1C1EEC765F843E44996971A80682118B2523E4@OPWINEXCL01> From: Kevin McCandless To: enum@ietf.org Date: Mon, 22 Jan 2001 10:02:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] Tier I database Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hello Everyone: I hope you can help with this question. I just finished updating our executives at my company on ENUM. During my presentation on the Tier I database a question came up on why do we need a Tier I database? I know that the documents say the Tier I is for county code routing. But if this service is very similar to domain names then why the Tier I database. Also I had in my presentation the following " Tier I database directs the request to the controlling country. Then the DNS service translates a domain name representation of an E.164 number into the NS and A record for the Tier II database." Does the Tier I database give the NS and A record information or just translates the E.164 number into a NS and A record? Any clarification or more detailed explanation on why the Tier I database was envisioned and input on my last sentence on the first paragraph. Are we assuming that an ENUM service request would come from an IP device such as a computer, only? If I dialed an ENUM enabled number from the PSTN, would my call be routed just as it is today through the PSTN? Regards, Kevin McCandless Senior Network Planner Illuminet 913-814-6397 kmccandles@illuminet.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 13:42:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11459 for ; Mon, 22 Jan 2001 13:42:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02801; Mon, 22 Jan 2001 13:40:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02764 for ; Mon, 22 Jan 2001 13:39:00 -0500 (EST) Received: from dnspri.npac.com (firewall-user@[208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11386 for ; Mon, 22 Jan 2001 13:38:59 -0500 (EST) Received: by dnspri.npac.com; id MAA25893; Mon, 22 Jan 2001 12:38:58 -0600 (CST) Received: from unknown(192.168.20.111) by dnspri.npac.com via smap (V5.0) id xmac25255; Mon, 22 Jan 01 12:38:03 -0600 Message-Id: <5.0.2.1.2.20010122131423.03064be0@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 22 Jan 2001 13:33:50 -0500 To: "A.M. Rutkowski" , Richard Shockey , Kevin McCandless , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] SIP 6th bake-off and enum In-Reply-To: <5.0.2.1.2.20010122114402.0468d008@mail.netmagic.com> References: <5.0.2.1.2.20010122105735.02a38c20@127.0.0.1> <1C1EEC765F843E44996971A80682118B2523DD@OPWINEXCL01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11:53 AM 1/22/2001 -0500, A.M. Rutkowski wrote: >Hi Richard, > >>I hate to be a stickler for detail here but Pulver is a bit off . RFC >>2916 is quite clear about this ..ENUM is about the integration of the >>ITU-T E.164 plan into e164.arpa and the status of that delegation is >>under active discussion among the Member States of the ITU. >> >>No decisions have currently been made on the delegation of the country >>code zones to the appropriate Member States. > >As was discussed at the ITU meeting, there are those >who disagree with your interpretation ENUM. You disagreed with the interpretation if I recall.... >ENUM is no less ENUM if the protocols are instantiated >in a zone other than E164.ARPA. Wrong... READ RFC 2916 > Indeed, in some jurisdictions, >it's entirely possible it may never be instantiated in >that zone. Unless you know of some DNS resolver technology that I'm unaware of, if we are to map the totality of ITU_T Recommendation E.164 into the DNS it will have to be in a single DNS tree, properly delegated along Member State lines according the recommendations of the plan itself . Classic DNS resolvers cannot recursively search multiple domains to find an authoritive NS. This, of course does not preclude the use of private domains for private dialing plans. > Indeed, it seems important for IETF to stick to >protocol development rather than pre-ordaining competitive >opportunities in the marketplace. With all due respect you are totally incorrect. What is clear is that you do not accept the results of the open consensus based IETF process, the result of the ENUM WG and somehow wish to rewrite or somehow abdicate RFC2916. You are well aware of what RFC 2916 states and states clearly at the beginning of the RFC and at the end when the IANA instructions are made. ENUM is about mapping ITU-T Recommendation E.164 into e164.arpa. If you wish to revisit the decision of the IESG in this matter ....your appeals should be directed at the IAB. ########################### 2. E.164 numbers and DNS The domain "e164.arpa" is being populated in order to provide the infrastructure in DNS for storage of E.164 numbers. In order to facilitate distributed operations, this domain is divided into subdomains. Holders of E.164 numbers which want to be listed in DNS should contact the appropriate zone administrator in order to be listed, by examining the SOA resource record associated with the zone, just like in normal DNS operations. Of course, as with other domains, policies for such listings will be controlled on a subdomain basis and may differ in different parts of the world. To find the DNS names for a specific E.164 number, the following procedure is to be followed: 1. See that the E.164 number is written in its full form, including the countrycode IDDD. Example: +46-8-9761234 2. Remove all non-digit characters with the exception of the leading '+'. Example: +4689761234 3. Remove all characters with the exception of the digits. Example: 4689761234 4. Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4 5. Reverse the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4 6. Append the string ".e164.arpa" to the end. Example: 4.3.2.1.6.7.9.8.6.4.e164.arpa ################################## 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. ########## >--amr >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005 Voice: 202.533.2811, Cell : 314.503.0640, Fax: 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 15:10:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13375 for ; Mon, 22 Jan 2001 15:10:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03809; Mon, 22 Jan 2001 15:10:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03778 for ; Mon, 22 Jan 2001 15:09:55 -0500 (EST) Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net [38.202.36.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13358 for ; Mon, 22 Jan 2001 15:09:53 -0500 (EST) Received: from dranalli ([38.136.73.86]) by hvmta03-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20010122200923.YFLD1236.hvmta03-stg@dranalli>; Mon, 22 Jan 2001 15:09:23 -0500 Message-ID: <01a601c084ae$3d90ce50$56498826@netnumber.com> Reply-To: "Douglas Ranalli" From: "Douglas Ranalli" To: "A.M. Rutkowski" , "Richard Shockey" , "Kevin McCandless" , References: <5.0.2.1.2.20010122105735.02a38c20@127.0.0.1><1C1EEC765F843E44996971A80682118B2523DD@OPWINEXCL01> <5.0.2.1.2.20010122131423.03064be0@127.0.0.1> Date: Mon, 22 Jan 2001 15:02:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Subject: [Enum] ENUM and "e164.arpa" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Richard et al, IMHO, Tony is simply pointing out that there are discussions underway within the ITU and various ITU Member States (including the US) regarding ENUM. By the vary nature of these discussions, multiple approaches are being presented and reviewed. As a participant in the discussions I think it is fair to say that no conclusions have been reached at the ITU or Member State level. The ITU Study Group 2 hasn't concluded its review. Furthermore, the US Department of State just created a new ENUM Ad Hoc working group to study this exact issue starting in mid-February so clearly no conclusions have been reached. Regardless of the outcome of the discussions, the "open consensus building process" is alive and well. Let's let the process work. Doug ----- Original Message ----- From: Richard Shockey To: A.M. Rutkowski ; Richard Shockey ; Kevin McCandless ; Sent: Monday, January 22, 2001 1:33 PM Subject: Re: [Enum] SIP 6th bake-off and enum > At 11:53 AM 1/22/2001 -0500, A.M. Rutkowski wrote: > >Hi Richard, > > > >>I hate to be a stickler for detail here but Pulver is a bit off . RFC > >>2916 is quite clear about this ..ENUM is about the integration of the > >>ITU-T E.164 plan into e164.arpa and the status of that delegation is > >>under active discussion among the Member States of the ITU. > >> > >>No decisions have currently been made on the delegation of the country > >>code zones to the appropriate Member States. > > > >As was discussed at the ITU meeting, there are those > >who disagree with your interpretation ENUM. > > You disagreed with the interpretation if I recall.... > > > >ENUM is no less ENUM if the protocols are instantiated > >in a zone other than E164.ARPA. > > Wrong... READ RFC 2916 > > > Indeed, in some jurisdictions, > >it's entirely possible it may never be instantiated in > >that zone. > > Unless you know of some DNS resolver technology that I'm unaware of, if we > are to map the totality of ITU_T Recommendation E.164 into the DNS it will > have to be in a single DNS tree, properly delegated along Member State > lines according the recommendations of the plan itself . Classic DNS > resolvers cannot recursively search multiple domains to find an authoritive > NS. This, of course does not preclude the use of private domains for > private dialing plans. > > > Indeed, it seems important for IETF to stick to > >protocol development rather than pre-ordaining competitive > >opportunities in the marketplace. > > With all due respect you are totally incorrect. > > What is clear is that you do not accept the results of the open consensus > based IETF process, the result of the ENUM WG and somehow wish to rewrite > or somehow abdicate RFC2916. > > You are well aware of what RFC 2916 states and states clearly at the > beginning of the RFC and at the end when the IANA instructions are made. > ENUM is about mapping ITU-T Recommendation E.164 into e164.arpa. > > If you wish to revisit the decision of the IESG in this matter ....your > appeals should be directed at the IAB. > > ########################### > > 2. E.164 numbers and DNS > > The domain "e164.arpa" is being populated in order to provide the > infrastructure in DNS for storage of E.164 numbers. In order to > facilitate distributed operations, this domain is divided into > subdomains. Holders of E.164 numbers which want to be listed in DNS > should contact the appropriate zone administrator in order to be > listed, by examining the SOA resource record associated with the > zone, just like in normal DNS operations. > > Of course, as with other domains, policies for such listings will be > controlled on a subdomain basis and may differ in different parts of > the world. > > To find the DNS names for a specific E.164 number, the following > procedure is to be followed: > > 1. See that the E.164 number is written in its full form, including > the countrycode IDDD. Example: +46-8-9761234 > > 2. Remove all non-digit characters with the exception of the leading > '+'. Example: +4689761234 > > 3. Remove all characters with the exception of the digits. Example: > 4689761234 > > 4. Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4 > > 5. Reverse the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4 > > 6. Append the string ".e164.arpa" to the end. Example: > 4.3.2.1.6.7.9.8.6.4.e164.arpa > > ################################## > > 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. > ########## > > >--amr > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Technical Industry Liaison > NeuStar Inc. > 1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005 > Voice: 202.533.2811, Cell : 314.503.0640, Fax: 815.333.1237 > or > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 15:24:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13570 for ; Mon, 22 Jan 2001 15:24:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03925; Mon, 22 Jan 2001 15:24:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03895 for ; Mon, 22 Jan 2001 15:24:07 -0500 (EST) Received: from exchange.chaos.com ([206.5.17.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13564 for ; Mon, 22 Jan 2001 15:24:04 -0500 (EST) Received: from [216.168.250.52] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id dnfkaaaa for enum@ietf.org; Mon, 22 Jan 2001 15:23:39 -0500 Message-Id: <5.0.2.1.2.20010122145918.02772ac8@mail.netmagic.com> X-Sender: amr@mail.netmagic.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 22 Jan 2001 15:23:38 -0500 To: Richard Shockey , Richard Shockey , Kevin McCandless , enum@ietf.org From: "A.M. Rutkowski" Subject: Re: [Enum] SIP 6th bake-off and enum In-Reply-To: <5.0.2.1.2.20010122131423.03064be0@127.0.0.1> References: <5.0.2.1.2.20010122114402.0468d008@mail.netmagic.com> <5.0.2.1.2.20010122105735.02a38c20@127.0.0.1> <1C1EEC765F843E44996971A80682118B2523DD@OPWINEXCL01> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_19243050==_.ALT" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --=====================_19243050==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Richard, >You are well aware of what RFC 2916 states and states clearly at the >beginning of the RFC and at the end when the IANA instructions are made. >ENUM is about mapping ITU-T Recommendation E.164 into e164.arpa. ENUM is about the following: 1. Through transformation of E.164 numbers into DNS names and the use of existing DNS services like delegation through NS records, and use of NAPTR [1] records in DNS [2] [3], one can look up what services are available for a specific domain name in a decentralized way with distributed management of the different levels in the lookup process. The reality is that it will have multiple instantiations. Ultimately, as was agreed at the ITU, these will be national matters...and shaped by the marketplace. As such, we should not further burden this list. cheers, tony --=====================_19243050==_.ALT Content-Type: text/html; charset="us-ascii" Hi Richard,

You are well aware of what RFC 2916 states and states clearly at the beginning of the RFC and at the end when the IANA instructions are made. ENUM is about mapping ITU-T Recommendation E.164 into e164.arpa.

ENUM is about the following:

  1.
  Through transformation of E.164 numbers
  into DNS names and the use of existing DNS
  services like delegation through NS records,
  and use of NAPTR [1] records in DNS [2] [3],
  one can look up what services are available
  for a specific domain name in a decentralized
  way with distributed management of the
  different levels in the lookup process.

The reality is that it will have multiple instantiations.
Ultimately, as was agreed at the ITU, these will be national
matters...and shaped by the marketplace.  As such, we should
not further burden this list.

cheers,
tony
--=====================_19243050==_.ALT-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 15:31:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13700 for ; Mon, 22 Jan 2001 15:31:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04168; Mon, 22 Jan 2001 15:31:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04139 for ; Mon, 22 Jan 2001 15:30:59 -0500 (EST) Received: from kcmso1.proxy.att.com ([192.128.133.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13667 for ; Mon, 22 Jan 2001 15:30:56 -0500 (EST) Received: from flf960r1.ems.att.com ([135.71.244.37]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f0MKUP528710; Mon, 22 Jan 2001 15:30:25 -0500 (EST) Received: from njb140bh1.ems.att.com by flf960r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id PAA08651; Mon, 22 Jan 2001 15:28:54 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jan 2001 15:30:24 -0500 Message-ID: <1B08859602C8D211B66F0000C0769CFA0515D080@njc240po03.mt.att.com> From: "Pfautz, Penn L, NNAD" To: Kevin McCandless , enum@ietf.org Subject: RE: [Enum] Tier I database Date: Mon, 22 Jan 2001 15:30:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Kevin: As the term Tier 1 has been used in most of the I-Ds, it refers to the level at which at which invidual numbers or block of numbers *within* country code, say 1 for North America, are mapped to the authoritative Tier 2 (or Service Registrar) that contains the actual NAPTR records for the number. Some more details of possible implementations are in draft-pfautz-na-enum-01 and draft-pfaytz-yu-enum-adm-00 Tier I would have the NS, and perhaps A information for the name server. An ENUM request has to come from some IP-enabled device, but that device could be a gateway or something else. Recall that use of ENUM is optional for both the end user to which the number belongs and to the carrier, if any, that is handling the call for the user. A PSTN originated call *could* be routed to a gateway and information from ENUM *could* be used to route the call, but the presumption, at least for now and at least for the US, is that there is a PSTN point of interface for all numbers. Penn Pfautz -----Original Message----- From: Kevin McCandless [mailto:KMcCandless@Illuminet.com] Sent: Monday, January 22, 2001 1:03 PM To: enum@ietf.org Subject: [Enum] Tier I database Hello Everyone: I hope you can help with this question. I just finished updating our executives at my company on ENUM. During my presentation on the Tier I database a question came up on why do we need a Tier I database? I know that the documents say the Tier I is for county code routing. But if this service is very similar to domain names then why the Tier I database. Also I had in my presentation the following " Tier I database directs the request to the controlling country. Then the DNS service translates a domain name representation of an E.164 number into the NS and A record for the Tier II database." Does the Tier I database give the NS and A record information or just translates the E.164 number into a NS and A record? Any clarification or more detailed explanation on why the Tier I database was envisioned and input on my last sentence on the first paragraph. Are we assuming that an ENUM service request would come from an IP device such as a computer, only? If I dialed an ENUM enabled number from the PSTN, would my call be routed just as it is today through the PSTN? Regards, Kevin McCandless Senior Network Planner Illuminet 913-814-6397 kmccandles@illuminet.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 16:04:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14481 for ; Mon, 22 Jan 2001 16:04:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04521; Mon, 22 Jan 2001 16:03:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04492 for ; Mon, 22 Jan 2001 16:03:50 -0500 (EST) Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net [38.202.36.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14476 for ; Mon, 22 Jan 2001 16:03:47 -0500 (EST) Received: from RWALTER ([38.136.73.75]) by hvmta03-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20010122210318.ZBUV1236.hvmta03-stg@RWALTER>; Mon, 22 Jan 2001 16:03:18 -0500 From: "Robert H. Walter" To: "Kevin McCandless" , Subject: RE: [Enum] Tier I database Date: Mon, 22 Jan 2001 15:58:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <1C1EEC765F843E44996971A80682118B2523E4@OPWINEXCL01> Importance: Normal Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Hi Kevin, > I hope you can help with this question. I just finished updating our > executives at my company on ENUM. During my presentation on the Tier I > database a question came up on why do we need a Tier I database? I know > that the documents say the Tier I is for county code routing. But if this > service is very similar to domain names then why the Tier I database. Both Tier-1 and Tier-2 ENUM DNS represent LOGICAL rather than PHYSICAL control tiers. Tier-1 is the logical abstraction of all physical name servers performing delegation upto but not including the Tier-2 name servers where NAPTR records are stored. Tier-1 intrinsically exists because of the assumption that their will be multiple Tier-2 ENUM providers and/or operators. > Does the Tier I database give the NS and A record information > or just translates the E.164 number into a NS and A record? Typically the handling of delegation in DNS resolution is implicitly performed by client resolvers. A resolver will query an ENUM system for the NAPTR records associated with an E.164 name. Because ENUM has the potential for many physical DNS tiers, the resolver will reissue the query for NAPTR records to one or more of the physical name servers that respond with NS and A records. The resolution process terminates when a name server responds with the NAPTR records or there are no more name servers to query. Regards, Bob _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 16:17:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14721 for ; Mon, 22 Jan 2001 16:17:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04647; Mon, 22 Jan 2001 16:15:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04619 for ; Mon, 22 Jan 2001 16:15:44 -0500 (EST) Received: from dnspri.npac.com (firewall-user@[208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14684 for ; Mon, 22 Jan 2001 16:15:41 -0500 (EST) Received: by dnspri.npac.com; id PAA01345; Mon, 22 Jan 2001 15:14:51 -0600 (CST) Received: from unknown(192.168.20.111) by dnspri.npac.com via smap (V5.0) id xma001228; Mon, 22 Jan 01 15:14:04 -0600 Message-Id: <5.0.2.1.2.20010122151901.03037280@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 22 Jan 2001 16:16:21 -0500 To: "Douglas Ranalli" , "A.M. Rutkowski" , "Richard Shockey" , "Kevin McCandless" , From: Richard Shockey In-Reply-To: <01a601c084ae$3d90ce50$56498826@netnumber.com> References: <5.0.2.1.2.20010122105735.02a38c20@127.0.0.1> <1C1EEC765F843E44996971A80682118B2523DD@OPWINEXCL01> <5.0.2.1.2.20010122131423.03064be0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Re: ENUM and "e164.arpa" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 03:02 PM 1/22/2001 -0500, Douglas Ranalli wrote: >Richard et al, > >IMHO, Tony is simply pointing out that there are discussions underway within >the ITU and various ITU Member States (including the US) regarding ENUM. By >the vary nature of these discussions, multiple approaches are being >presented and reviewed. Oh I'm well aware of that ..but that does not alter the fact that RFC 2916 is about mapping Recommendation E.164 into e164.apra.... its what the document says. I completely agree there are multiple approaches on how achieve such a mapping. > As a participant in the discussions I think it is >fair to say that no conclusions have been reached at the ITU or Member State >level. Correct. > The ITU Study Group 2 hasn't concluded its review. Correct > Furthermore, the >US Department of State just created a new ENUM Ad Hoc working group to study >this exact issue starting in mid-February so clearly no conclusions have >been reached. Regardless of the outcome of the discussions, the "open >consensus building process" is alive and well. Let's let the process work. I'm in violent agreement ... Its just making sure we are discussing the same thing.... this is a discussion on RFC 2916 I presume. So if there is a fundamental problem with RFC 2916 and its mapping of Recommendation E.164 into e164.arpa then it should be made very clear, what those problems are. What I'm having some problems with is the cryptic remarks by some that RFC 2916 is somehow anti-competitive, against private enterprise, an intrusion of government into the Internet etc without spelling out what those objections are and whose economic interest is being harmed here and why those economic interests are being harmed. I'd certainly like to defend RFC 2916 in that IMHO it enables competition in telecom markets, creates new business models and opportunities, enables new services, reduces costs for carriers and enterprises , ends world hunger etc. As for the E.164 plan, it has always been overseen by the Member States in order to insure its global consistency. I do not need to go into the serious consumer protection and equal access issues that are on the table here. I wish I could rewrite the DNS to allow for alternative resolution models..but if some one could describe how this could be done I'd be delighted to listen.. >Doug > >----- Original Message ----- >From: Richard Shockey >To: A.M. Rutkowski ; Richard Shockey >; Kevin McCandless ; > >Sent: Monday, January 22, 2001 1:33 PM >Subject: Re: [Enum] SIP 6th bake-off and enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005 Voice: 202.533.2811, Cell : 314.503.0640, Fax: 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 16:31:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15021 for ; Mon, 22 Jan 2001 16:31:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04918; Mon, 22 Jan 2001 16:31:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04890 for ; Mon, 22 Jan 2001 16:31:07 -0500 (EST) Received: from exchange.chaos.com ([206.5.17.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15018 for ; Mon, 22 Jan 2001 16:31:04 -0500 (EST) Received: from [216.168.250.52] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id zpfkaaaa for enum@ietf.org; Mon, 22 Jan 2001 16:30:59 -0500 Message-Id: <5.0.2.1.2.20010122162308.027a49f8@mail.netmagic.com> X-Sender: amr@mail.netmagic.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 22 Jan 2001 16:30:58 -0500 To: Richard Shockey , "Douglas Ranalli" , "Richard Shockey" , "Kevin McCandless" , From: "A.M. Rutkowski" Subject: Re: [Enum] Re: ENUM and "e164.arpa" In-Reply-To: <5.0.2.1.2.20010122151901.03037280@127.0.0.1> References: <01a601c084ae$3d90ce50$56498826@netnumber.com> <5.0.2.1.2.20010122105735.02a38c20@127.0.0.1> <1C1EEC765F843E44996971A80682118B2523DD@OPWINEXCL01> <5.0.2.1.2.20010122131423.03064be0@127.0.0.1> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_23283049==_.ALT" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --=====================_23283049==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi all, >consistency. I do not need to go into the serious consumer protection and >equal access issues that are on the table here. There is a diverse audience waiting with bated breath at the forum for all these implementation issues at: ENUM@ALMSNTSA.LMLIST.STATE.GOV This will allow for fuller discussions on 12-13 Feb. --tony --=====================_23283049==_.ALT Content-Type: text/html; charset="us-ascii" Hi all,

consistency.  I do not need to go into the serious consumer protection and equal access issues that are on the table here.

There is a diverse audience waiting with bated breath
at the forum for all these implementation issues at:

 ENUM@ALMSNTSA.LMLIST.STATE.GOV

This will allow for fuller discussions on 12-13 Feb.

--tony
--=====================_23283049==_.ALT-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 17:06:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15539 for ; Mon, 22 Jan 2001 17:06:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05382; Mon, 22 Jan 2001 17:06:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05351 for ; Mon, 22 Jan 2001 17:06:19 -0500 (EST) Received: from dnspri.npac.com (firewall-user@[208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15536 for ; Mon, 22 Jan 2001 17:06:16 -0500 (EST) Received: by dnspri.npac.com; id QAA12896; Mon, 22 Jan 2001 16:06:16 -0600 (CST) Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0) id xma012858; Mon, 22 Jan 01 16:06:07 -0600 Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Jan 2001 16:04:05 -0600 Message-ID: From: Andy Gallant To: Richard Shockey , Douglas Ranalli , "A.M. Rutkowski" , Kevin McCandless , enum@ietf.org Subject: RE: [Enum] Re: ENUM and "e164.arpa" Date: Mon, 22 Jan 2001 16:02:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Just a few points for background: 1. The meeting in Berlin produced a document that was sent as a Liaison Statement from ITU-T SG 2 Working Party 1. That document is now RFC 3026. In Berlin, both the outgoing and incoming Study Group chairmen participated, and RFC publication passes through IESG. 2. The calling notice for the US ENUM Admin Ad Hoc states: "SGA Ad-Hoc US Administrative ENUM issues Meeting Notice "At the January meeting of the United States Study Group A meeting, it was agreed to establish a new Ad-Hoc that would develop industry input to identify administrative US ENUM-DNS issues and recommend resolution to the issues in a Report to Study Group A. "The initial meeting of this new Ad-Hoc will be organizational in nature with future meetings requiring contributions relating to the issues identified during this meeting." These seem pretty clear to me. Regards, -Andy Gallant Andrew M. Gallant NeuStar, Inc. Tel: 1 202 533-2812 Fax: 1 202 533-2976 Email: andrew.gallant@neustar.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 17:33:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15910 for ; Mon, 22 Jan 2001 17:33:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05742; Mon, 22 Jan 2001 17:32:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05715 for ; Mon, 22 Jan 2001 17:32:20 -0500 (EST) Received: from heron.verisign.com ([216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15891 for ; Mon, 22 Jan 2001 17:32:19 -0500 (EST) Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id RAA05865; Mon, 22 Jan 2001 17:30:48 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jan 2001 17:26:08 -0500 Message-ID: From: "Conley, Pat" To: Kevin McCandless , enum@ietf.org Subject: RE: [Enum] Tier I database Date: Mon, 22 Jan 2001 17:26:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Kevin, My simple way of thinking about the e164.arpa model of ENUM is as follows. There is a "root layer" that points to the .arpa. There is a "enum layer" that points to e164.arpa. There is some "international layer" that points to the implementation for each country. Within that country there is a layer that contains potentially many physical servers that together implement a "tier 1". Tier 1 by definition contains info that goes all the way to a fully qualified E.164 number. Within tier 1 there are 3 options. 1.) Store URIs directly the NAPTR records of the Tier 1. 2a) Use NS records to point out to a DNS implementation of Tier 2. 2b) Use NAPTR records with LDAP URIs to point out to an LDAP Tier 2 implementation. pat -----Original Message----- From: Robert H. Walter [mailto:rwalter@netnumber.com] Sent: Monday, January 22, 2001 3:58 PM To: Kevin McCandless; enum@ietf.org Subject: RE: [Enum] Tier I database Hi Kevin, > I hope you can help with this question. I just finished updating our > executives at my company on ENUM. During my presentation on the Tier I > database a question came up on why do we need a Tier I database? I know > that the documents say the Tier I is for county code routing. But if this > service is very similar to domain names then why the Tier I database. Both Tier-1 and Tier-2 ENUM DNS represent LOGICAL rather than PHYSICAL control tiers. Tier-1 is the logical abstraction of all physical name servers performing delegation upto but not including the Tier-2 name servers where NAPTR records are stored. Tier-1 intrinsically exists because of the assumption that their will be multiple Tier-2 ENUM providers and/or operators. > Does the Tier I database give the NS and A record information > or just translates the E.164 number into a NS and A record? Typically the handling of delegation in DNS resolution is implicitly performed by client resolvers. A resolver will query an ENUM system for the NAPTR records associated with an E.164 name. Because ENUM has the potential for many physical DNS tiers, the resolver will reissue the query for NAPTR records to one or more of the physical name servers that respond with NS and A records. The resolution process terminates when a name server responds with the NAPTR records or there are no more name servers to query. Regards, Bob _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Jan 22 17:41:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15975 for ; Mon, 22 Jan 2001 17:41:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05879; Mon, 22 Jan 2001 17:41:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05794 for ; Mon, 22 Jan 2001 17:41:15 -0500 (EST) Received: from exchange.chaos.com ([206.5.17.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15969 for ; Mon, 22 Jan 2001 17:41:03 -0500 (EST) Received: from [206.5.17.17] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id crfkaaaa for enum@ietf.org; Mon, 22 Jan 2001 17:40:47 -0500 Message-Id: <5.0.2.1.2.20010122173426.00a7c388@mail.netmagic.com> X-Sender: amr@mail.netmagic.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 22 Jan 2001 17:40:46 -0500 To: Andy Gallant , Richard Shockey , Douglas Ranalli , Kevin McCandless , enum@ietf.org From: "A.M.Rutkowski" Subject: RE: [Enum] Re: ENUM and "e164.arpa" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_932961968==_.ALT" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --=====================_932961968==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Andy, >"The initial meeting of this new Ad-Hoc will be organizational in nature >with future meetings requiring contributions relating to the issues >identified during this meeting." Notwithstanding this preface, it is a two-day meeting, with a rather extensive substantive agenda. >Tentative Agenda: > Tutorials >- ENUM Overview >- DNS Overview >- Administrative Issues from ITU ENUM Workshop (1/17/01) >Identify US Administrative Issues >- Time will be allocated to allow for the presentation of >alternative models that identify administrative issues >- Issues that are identified will be the basis for contributions at >future meetings >Develop Work Plan >Determine Output >Future Meeting Schedule --tony --=====================_932961968==_.ALT Content-Type: text/html; charset="us-ascii" Hi Andy,

"The initial meeting of this new Ad-Hoc will be organizational in nature
with future meetings requiring contributions relating to the issues
identified during this meeting."

Notwithstanding this preface, it is a two-day meeting, with a rather extensive
substantive agenda.

Tentative Agenda:
        Tutorials
-       ENUM Overview
-       DNS Overview
-       Administrative Issues from ITU ENUM Workshop (1/17/01)
Identify US Administrative Issues
-       Time will be allocated to allow for the presentation of alternative models that identify administrative issues
-       Issues that are identified will be the basis for contributions at future meetings
Develop Work Plan
Determine Output
Future Meeting Schedule


--tony
--=====================_932961968==_.ALT-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jan 24 07:54:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19353 for ; Wed, 24 Jan 2001 07:54:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10812; Wed, 24 Jan 2001 07:54:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10784 for ; Wed, 24 Jan 2001 07:54:03 -0500 (EST) Received: from mail2.itu.int ([156.106.192.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19348 for ; Wed, 24 Jan 2001 07:54:02 -0500 (EST) Received: by mail2.itu.ch with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 13:48:38 +0100 Message-ID: From: "Shaw, Robert" To: "'enum@ietf.org'" Date: Wed, 24 Jan 2001 13:53:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] Report on ITU ENUM Workshop - January 17, 2001 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On January 17th, 2001, ITU hosted a one-day ENUM Workshop on administrative issues related to deployment of the ENUM protocol. Related workshop materials, including the Chairman's Report, are now available at: http://www.itu.int/infocom/enum/workshopjan01/ Bob -- Robert Shaw ITU Internet Strategy and Policy Advisor International Telecommunication Union Place des Nations, 1211 Geneva, Switzerland _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jan 24 09:09:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20940 for ; Wed, 24 Jan 2001 09:09:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11781; Wed, 24 Jan 2001 09:06:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11749 for ; Wed, 24 Jan 2001 09:06:16 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20878 for ; Wed, 24 Jan 2001 09:06:17 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id GAA07341 for ; Wed, 24 Jan 2001 06:05:50 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f0ODkt117611 for ; Wed, 24 Jan 2001 05:46:57 -0800 (PST) Received: from [193.0.4.72] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id FAA05513 for ; Wed, 24 Jan 2001 05:46:31 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <808BCB95E77CD21188DB00805F6F99C7057E189B@txdj00exch005u.micro.lucent.com> References: <808BCB95E77CD21188DB00805F6F99C7057E189B@txdj00exch005u.micro.lucent.com> Date: Wed, 24 Jan 2001 14:42:53 +0100 To: enum@ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-4.cisco.com id GAA07341 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA11750 Subject: [Enum] ITU Workshop in january in Geneva Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id JAA11781 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA20940 Report from ENUM workshop at ITU can be found here: http://www.itu.int/infocom/enum/workshopjan01/ paf -- Patrik Fältström Cisco Systems Consulting Engineer Office of the CSO Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jan 24 09:37:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21936 for ; Wed, 24 Jan 2001 09:37:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12197; Wed, 24 Jan 2001 09:37:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12168 for ; Wed, 24 Jan 2001 09:37:04 -0500 (EST) Received: from rainier.illuminet.com ([63.116.20.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21879 for ; Wed, 24 Jan 2001 09:37:05 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com ([172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id GAA18810; Wed, 24 Jan 2001 06:36:02 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jan 2001 06:35:27 -0800 Message-ID: <1C1EEC765F843E44996971A80682118B2523FE@OPWINEXCL01> From: Kevin McCandless To: "'Shaw, Robert'" , "'enum@ietf.org'" Subject: RE: [Enum] Report on ITU ENUM Workshop - January 17, 2001 Date: Wed, 24 Jan 2001 06:35:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Thank you for the link. I have reviewed the power point presentations and wanted to print them out. Can we get access to the actual power point files for easy printing?? -----Original Message----- From: Shaw, Robert [mailto:Robert.Shaw@itu.int] Sent: Wednesday, January 24, 2001 6:54 AM To: 'enum@ietf.org' Subject: [Enum] Report on ITU ENUM Workshop - January 17, 2001 On January 17th, 2001, ITU hosted a one-day ENUM Workshop on administrative issues related to deployment of the ENUM protocol. Related workshop materials, including the Chairman's Report, are now available at: http://www.itu.int/infocom/enum/workshopjan01/ Bob -- Robert Shaw ITU Internet Strategy and Policy Advisor International Telecommunication Union Place des Nations, 1211 Geneva, Switzerland _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jan 24 10:30:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23401 for ; Wed, 24 Jan 2001 10:30:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12729; Wed, 24 Jan 2001 10:29:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12702 for ; Wed, 24 Jan 2001 10:29:50 -0500 (EST) Received: from mail2.itu.int (mail2.itu.ch [156.106.192.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23370 for ; Wed, 24 Jan 2001 10:29:50 -0500 (EST) Received: by mail2.itu.ch with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 16:24:27 +0100 Message-ID: From: "Shaw, Robert" To: "'Kevin McCandless'" Cc: "'enum@ietf.org'" Subject: RE: [Enum] Report on ITU ENUM Workshop - January 17, 2001 Date: Wed, 24 Jan 2001 16:29:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > Thank you for the link. I have reviewed the power point > presentations and wanted to print them out. Can we get > access to the actual power point files for easy printing?? Kevin, They're also posted at: http://www.itu.int/infocom/enum/workshopjan01/ Click on the "(PowerPoint)" link just to the right of each title linked to the htmlized version. Bob -- Robert Shaw ITU Internet Strategy and Policy Advisor International Telecommunication Union Place des Nations, 1211 Geneva, Switzerland _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Jan 26 11:48:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14286 for ; Fri, 26 Jan 2001 11:48:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28270; Fri, 26 Jan 2001 11:45:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28241 for ; Fri, 26 Jan 2001 11:45:37 -0500 (EST) Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14190 for ; Fri, 26 Jan 2001 11:45:35 -0500 (EST) Received: from dranalli ([38.136.73.86]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20010126164451.DBEA20644.hvmta01-stg@dranalli> for ; Fri, 26 Jan 2001 11:44:51 -0500 Message-ID: <01bb01c087b6$5164c4d0$56498826@netnumber.com> Reply-To: "Douglas Ranalli" From: "Douglas Ranalli" To: Date: Fri, 26 Jan 2001 11:37:47 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B8_01C0878C.6826D340" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [Enum] Update on ITAB Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_01B8_01C0878C.6826D340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ENUM Working Group, Here's an update on ITAB in response to the various questions and = comments generated two weeks ago on the ENUM list group. Sorry about = the delay in responding on this issue. The updated mission of the "Internet Telephony Addressing Board" (ITAB) = is to provide an open industry forum for promoting the use of the ENUM = standard by sharing operational experiences and by advancing operational = recommendations for the delivery of ENUM-based communications services. = ITAB was co-founded by Pulver.com and NetNumber back in September 2000 = as part of our ".tel" application to ICANN but we've advanced the vision = of the organization significantly since that time. Please see = www.i-tab.org for more information. =20 NetNumber and Pulver.com are sponsoring ITAB with the goal of advancing = the use of the ENUM standard as an integral component of the overall = IP-communications industry. Within the role that we've carved out for = ITAB, we see no overlap between the "operational" focus of ITAB and the = "standards definition" focus of the IETF and the ITU. Very specifically = we do not see any overlap between ITAB and the on-going discussions = regarding the definition of a public ENUM Registry under "e164.arpa". = Regardless of the outcome of these domain discussions, as an industry, = we still need to figure out how to effectively utilize the ENUM standard = to advance the growth of IP-communications services. ITAB exists to = provide a forum for sharing implementation experiences with the goal of = advancing the growth of ENUM in general. We'll be working over the next few months to fill out the ITAB Board of = Directors with representatives from a broad constituency within the = IP-communications industry. The first meeting of the new ITAB Board of = Directors will be held the afternoon of Tuesday March 20th at the = Pulver.com Spring VON event in Phoenix. New Director's will be elected = at that time and we'll begin work on the first set of ITAB "Operational = Recommendation" documents immediately after the March Board meeting. = ITAB will continue to evolve as the industry evolves and we welcome = participation from everyone who is working on advancing ENUM based = services.=20 If you're interested in participating in the work at ITAB please feel = free to contact me directly with any questions. =20 Regards, Doug Douglas J. Ranalli Founder & Chief Strategy Officer NetNumber 650 Suffolk Street, Suite 307 Lowell, MA 01854 dranalli@netnumber.com www.netnumber.com 978-454-4210 ext 22 978-454-5044 (fax) ------=_NextPart_000_01B8_01C0878C.6826D340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
ENUM Working Group,
 
Here's an update on ITAB in response to = the various=20 questions and comments generated two weeks ago on the ENUM list = group. =20 Sorry about the delay in responding on this issue.
 
The updated mission of the "Internet = Telephony=20 Addressing Board" (ITAB) is to provide an open industry forum for = promoting the=20 use of the ENUM standard by sharing operational experiences and by = advancing=20 operational recommendations for the delivery of ENUM-based = communications=20 services.  ITAB was co-founded by Pulver.com and NetNumber back in=20 September 2000 as part of our ".tel" application to ICANN but we've = advanced the=20 vision of the organization significantly since that time.  = Please see=20 www.i-tab.org for more = information. =20
 
NetNumber and Pulver.com are sponsoring = ITAB with=20 the goal of advancing the use of the ENUM standard as an integral=20 component of the overall IP-communications industry.  = Within the=20 role that we've carved out for ITAB, we see no overlap between the = "operational"=20 focus of ITAB and the "standards definition" focus of the IETF and the=20 ITU.  Very specifically we do not see any overlap between ITAB and = the=20 on-going discussions regarding the definition of a public ENUM Registry = under=20 "e164.arpa".  Regardless of the outcome of these domain = discussions, as an=20 industry, we still need to figure out how to effectively utilize = the ENUM=20 standard to advance the growth of IP-communications services.  = ITAB=20 exists to provide a forum for sharing implementation = experiences with the=20 goal of advancing the growth of ENUM in general.
 
We'll be working over the next few = months to fill=20 out the ITAB Board of Directors with representatives from a broad = constituency=20 within the IP-communications industry.  The first meeting of the = new ITAB=20 Board of Directors will be held the afternoon of Tuesday March 20th at = the=20 Pulver.com Spring VON event in Phoenix.  New Director's will be = elected at=20 that time and we'll begin work on the first set of ITAB "Operational=20 Recommendation" documents immediately after the March Board = meeting.  ITAB=20 will continue to evolve as the industry evolves and we welcome = participation=20 from everyone who is working on advancing ENUM based services. =
 
If you're interested in participating = in the work=20 at ITAB please feel free to contact me directly with any = questions. =20
 
Regards,
 
Doug
 
Douglas J. Ranalli
Founder & = Chief Strategy=20 Officer
NetNumber
650 Suffolk Street, Suite 307
Lowell, = MA =20 01854
dranalli@netnumber.com
www.netnumber.com
978-454-4210 = ext=20 22
978-454-5044 (fax)
------=_NextPart_000_01B8_01C0878C.6826D340-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Jan 30 16:52:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18107 for ; Tue, 30 Jan 2001 16:52:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21363; Tue, 30 Jan 2001 16:51:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21336 for ; Tue, 30 Jan 2001 16:51:07 -0500 (EST) Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18101 for ; Tue, 30 Jan 2001 16:51:05 -0500 (EST) Received: from RWALTER ([38.136.73.81]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20010130215035.CDA20644.hvmta01-stg@RWALTER>; Tue, 30 Jan 2001 16:50:35 -0500 Reply-To: From: "Robert H. Walter" To: Cc: Date: Tue, 30 Jan 2001 16:45:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Enum] Querying Multiple ENUM Domains (e.g. e164.arpa, e.164.com, etc.) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit At 04:16 PM 1/22/2001 -0500, Richard Shockey wrote: > I wish I could rewrite the DNS to allow for alternative resolution > models..but if some one could describe how this could be done I'd be > delighted to listen.. NetNumber faced this exact challenge when we deployed our "commercial" ENUM service under the domain "e164.com" last year. The vendors and customers we were contacting all liked the idea of moving forward with ENUM by utilizing our commercial implementation but they didn't want to be trapped into a single ENUM domain. We addressed this requirement by building an ENUM resolver that can be configured to simultaneously query multiple ENUM domains. Our approach was to enable an application to query a corporate domain like "e164.company.com", one or more commercial domains like "e164.com" and a public domain like "e164.arpa". Here are a few of the underlying assumptions that lead us to implement a multi-domain ENUM resolver: 1. The decision to query one or more ENUM domains is entirely under the control of the ENUM enabled application. It is highly recommeded that the application only query "TRUSTED" ENUM domains. 2. ENUM requires a special DNS resolver to correctly process the NAPTR records per RFC2915 and it is a simple matter to incorporate the ability to simultaneously query multiple ENUM domains. 3. While supporting the domain "e164.arpa" as a viable competitive domain to "e164.com", the regulatory review process surrounding "e164.arpa" will take considerable time to sort out. The NetNumber ENUM resolver is downloadable from the support center of NetNumber's web site and is licensed under the GNU Lesser General Public License. It may be easily configured to query multiple ENUM domains. By default, both "e164.arpa" and "e164.com" are queried. The returned result-set is simply the aggregation of NAPTR records for all domains. The ability to sort the result-set based on the domain order is currently being considered. This may prove useful when dealing with corporate and commercial ENUM systems. For more detailed information see www.netnumber.com/support/downloads.jsp. Bob _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Jan 30 17:38:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18663 for ; Tue, 30 Jan 2001 17:38:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22086; Tue, 30 Jan 2001 17:36:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22058 for ; Tue, 30 Jan 2001 17:36:03 -0500 (EST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18630 for ; Tue, 30 Jan 2001 17:36:00 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id RAA15116; Tue, 30 Jan 2001 17:26:01 -0500 (EST) Date: Tue, 30 Jan 2001 17:26:01 -0500 From: Michael Mealling To: "Robert H. Walter" Cc: rich.shockey@neustar.com, enum@ietf.org Subject: Re: [Enum] Querying Multiple ENUM Domains (e.g. e164.arpa, e.164.com, etc.) Message-ID: <20010130172601.E7879@bailey.dscga.com> Reply-To: michaelm@netsol.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: ; from rwalter@netnumber.com on Tue, Jan 30, 2001 at 04:45:51PM -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Tue, Jan 30, 2001 at 04:45:51PM -0500, Robert H. Walter wrote: > At 04:16 PM 1/22/2001 -0500, Richard Shockey wrote: > > I wish I could rewrite the DNS to allow for alternative resolution > > models..but if some one could describe how this could be done I'd be > > delighted to listen.. > > NetNumber faced this exact challenge when we deployed our > "commercial" ENUM service under the domain "e164.com" last year. > The vendors and customers we were contacting all liked the idea of > moving forward with ENUM by utilizing our commercial implementation > but they didn't want to be trapped into a single ENUM domain. We > addressed this requirement by building an ENUM resolver that can be > configured to simultaneously query multiple ENUM domains. Our > approach was to enable an application to query a corporate domain > like "e164.company.com", one or more commercial domains like "e164.com" > and a public domain like "e164.arpa". Here are a few of the underlying > assumptions that lead us to implement a multi-domain ENUM resolver: > > 1. The decision to query one or more ENUM domains is entirely under > the control of the ENUM enabled application. It is highly > recommeded that the application only query "TRUSTED" ENUM domains. > > 2. ENUM requires a special DNS resolver to correctly process the > NAPTR records per RFC2915 and it is a simple matter to > incorporate the ability to simultaneously query multiple ENUM > domains. > > 3. While supporting the domain "e164.arpa" as a viable competitive > domain to "e164.com", the regulatory review process surrounding > "e164.arpa" will take considerable time to sort out. This is VERY dangerous if not done very carefully. In the case where a NAPTR record's flag field is blank you have started doing the standard DDDS delegation steps. In this case you cannot mix records from multiple nameservers since the entire algorithm breaks. There are two solutions: 1) coordinate all of the nameservers so that the NAPTR delegations don't step on one another 2) each ENUM 'root' corresponds to exactly to one ENUM delegation path. You can combine the resulting _output_ but you _cannot_ combine the actual NAPTR records. Please be very careful if you do this. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jan 31 10:22:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17282 for ; Wed, 31 Jan 2001 10:22:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09482; Wed, 31 Jan 2001 10:21:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09453 for ; Wed, 31 Jan 2001 10:21:19 -0500 (EST) Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net [38.202.36.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17267 for ; Wed, 31 Jan 2001 10:21:18 -0500 (EST) Received: from RWALTER ([38.136.73.81]) by hvmta03-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20010131152048.RRHX1236.hvmta03-stg@RWALTER>; Wed, 31 Jan 2001 10:20:48 -0500 Reply-To: From: "Robert H. Walter" To: Cc: Subject: RE: [Enum] Querying Multiple ENUM Domains (e.g. e164.arpa, e.164.com, etc.) Date: Wed, 31 Jan 2001 10:16:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <20010130172601.E7879@bailey.dscga.com> Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > On Tue, Jan 30, 2001 at 05:26:15PM -0500, Michael Mealling wrote: > This is VERY dangerous if not done very carefully. In the case > where a NAPTR record's flag field is blank you have started > doing the standard DDDS delegation steps. In this case you cannot > mix records from multiple nameservers since the entire algorithm > breaks. There are two solutions: > > 1) coordinate all of the nameservers so that the NAPTR delegations > don't step on one another > > 2) each ENUM 'root' corresponds to exactly to one ENUM delegation > path. You can combine the resulting _output_ but you _cannot_ > combine the actual NAPTR records. Thank you for the feedback... Indeed NetNumber has taken great care with its use of NAPTR. RFC2915 is reasonably flexible on how each application must specialize the basic NAPTR algorithm, hence, the multi-domain ENUM resolver is a degenerate case of the the basic NAPTR algorithm and discards NAPTR records from the result-set if: 1. The flags field contains a value other than "u". 2. The protocol portion of the service field does not match the input service protocol filter. 3. The service field does not end with "+E2U". 4. The regex field is empty. 5. The RR is a duplicate from another ENUM domain. The remaining records are all terminal and the processed output is a set of URI's that are sorted on "order" then "preference". It is important to note the that the underlying use of NAPTR is completely encapsulated from the application and the output of the ENUM resolver is zero or more sorted ENUM Records containing a URI, order and preference. When multiple ENUM Records have the same "order" and "preference" the application must decide which to use. As previously mentioned, we are currently evaluating the effect of additionally sorting the result-set on ENUM sub-domain. For example, the corporate ENUM domain "e164.company.com" may be be configured to take precedence over the commercial ENUM domain "e164.com", etc. Regards, Bob _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jan 31 10:42:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17945 for ; Wed, 31 Jan 2001 10:42:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09921; Wed, 31 Jan 2001 10:41:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09890 for ; Wed, 31 Jan 2001 10:41:04 -0500 (EST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17885 for ; Wed, 31 Jan 2001 10:41:03 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id KAA17408; Wed, 31 Jan 2001 10:31:05 -0500 (EST) Date: Wed, 31 Jan 2001 10:31:05 -0500 From: Michael Mealling To: "Robert H. Walter" Cc: michaelm@netsol.com, enum@ietf.org Subject: Re: [Enum] Querying Multiple ENUM Domains (e.g. e164.arpa, e.164.com, etc.) Message-ID: <20010131103105.A17257@bailey.dscga.com> Reply-To: michaelm@netsol.com References: <20010130172601.E7879@bailey.dscga.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: ; from rwalter@netnumber.com on Wed, Jan 31, 2001 at 10:16:05AM -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Wed, Jan 31, 2001 at 10:16:05AM -0500, Robert H. Walter wrote: > > On Tue, Jan 30, 2001 at 05:26:15PM -0500, Michael Mealling wrote: > > This is VERY dangerous if not done very carefully. > > > Thank you for the feedback... Indeed NetNumber has taken great care > with its use of NAPTR. RFC2915 is reasonably flexible on how each > application must specialize the basic NAPTR algorithm, hence, the > multi-domain ENUM resolver is a degenerate case of the the basic > NAPTR algorithm and discards NAPTR records from the result-set if: > > 1. The flags field contains a value other than "u". > 2. The protocol portion of the service field does not match > the input service protocol filter. > 3. The service field does not end with "+E2U". > 4. The regex field is empty. > 5. The RR is a duplicate from another ENUM domain. This may be Netnumber's degenerate application but its not the ENUM application defined in 2916. If you're going to use ENUM which defines what happens when the flag is empty then simply munging all of the records together that came back on the first request isn't allowed. If ENUM wants to allow this then you have the two alternatives I listed earlier unless someone has an alternative that preserves the delegation paths... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jan 31 10:45:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18046 for ; Wed, 31 Jan 2001 10:45:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10033; Wed, 31 Jan 2001 10:45:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09967 for ; Wed, 31 Jan 2001 10:44:53 -0500 (EST) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18027 for ; Wed, 31 Jan 2001 10:44:52 -0500 (EST) Received: by dnspri.npac.com; id JAA03761; Wed, 31 Jan 2001 09:44:48 -0600 (CST) Received: from unknown(192.168.20.162) by dnspri.npac.com via smap (V5.0) id xmab03644; Wed, 31 Jan 01 09:44:11 -0600 Message-Id: <5.0.2.1.2.20010131093512.03426600@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 31 Jan 2001 10:29:23 -0500 To: "A.M.Rutkowski" , ENUM@ALMSNTSA.LMLIST.STATE.GOV From: Richard Shockey Subject: Re: [ENUM] Report on ITU ENUM Workshop - January 17, 2001 Cc: enum@ietf.org In-Reply-To: <5.0.2.1.2.20010129182240.00a81608@mail.netmagic.com> References: <5.0.2.1.2.20010129145653.00b02f50@localhost> <5.0.2.1.2.20010129162407.0277ce48@mail.netmagic.com> <1B08859602C8D211B66F0000C0769CFA0528342A@njc240po03.mt.att .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 06:31 PM 1/29/2001 -0500, A.M.Rutkowski wrote: >Hi David, > >>Is in-addr.arpa subject to anti-trust protection or extensive >>regulation? Is .COM? > >Yes, indeed. > >>The rub is in "assures uniqueness". > >It's all relative, and different implementations have >different cost-benefit tradeoffs. Generally, less >government and more open competition have proven >the better direction. I'm confident the industry >can work this out. > >e164.arpa might as well be named regulate_me.arpa. And you accuse me of rhetoric... Why don't you attempt to produce a reasoned technical argument instead of political platitudes. The core issue now and has been that if Internet Telephony devices are to consistently and reliable connect with each other there is a need for a single clear DNS tree to retrieve NAPTR records from. In addition to that there must be clear and consistent guidelines to prevent people from registering telephone numbers that do not belong to them. Your non intervention proposal ( essentially anarchy as I see it) guarantees that hijacking and other forms of consumer fraud would proliferate..and a key form of identity on the internet would be rendered useless...and with it the potential for an entire multi-billion dollar industry to grow. RFC 2916 addresses the desire of consumers to be able to use their telephone numbers in the consistent and reliable manner for ALL forms of communications as they do now on the PSTN with the equal reliability of results. The E.164 space is regulated and controlled in order to produce consistency in results. You pick up the phone and dial and it works. the PSTN ..like the Internet cannot search multiple databases to discover reliable end point information. Internet Telephony is no different in that sense from PSTN Telephony. I'd like to share some insights into this problem that the FCC addressed in its First Report and Rule on Number Portability. While not specific to the problem at hand the FCC noted the importance of telephone numbers in creating competitive markets for telecommunications services. I submit that what we are dealing with here is similar in many ways. a. People will not use Internet Telephony IN A BIG WAY if they cannot use their telephone numbers. b. If the resolution of those numbers into the DNS cannot create technically consistent results they will be essentially useless. c. Therefore if it is the desire of Telecom Equipment Manufactures, ISP's, Government and other possible new entrants into Internet Telephony to create TRULY competitive markets for communications services using telephone numbers as names then implementation of RFC2916 is a necessity. And ....I might add clearly is within the spirit of the 1996 Telecommunications Act. ####### From the FCC Order and Report..... 29. We note that several studies described in the record demonstrate the reluctance of both business and residential customers to switch carriers if they must change numbers. For example, MCI has stated that, based on a nationwide Gallup survey, 83 percent of business customers and 80 percent of residential customers would be unlikely to change local service providers if they had to change their telephone numbers. Time Warner Holdings states that consumers are 40 percent less likely to change service providers if a number change is required. Citizens Utilities notes that approximately 85 percent of the discussions that its subsidiary, ELI, has with potential customers about switching providers end when those potential customers learn that they must change their telephone numbers. The study commissioned by Pacific Bell concludes that, without portability, new entrants would be forced to discount their local exchange service and other competing offerings by at least 12 percent below the incumbent LECs' prices in order to induce customers to switch carriers due to customers' resistance to changing numbers. 30. The ability of end users to retain their telephone numbers when changing service providers gives customers flexibility in the quality, price, and variety of telecommunications services they can choose to purchase. Number portability promotes competition between telecommunications service providers by, among other things, allowing customers to respond to price and service changes without changing their telephone numbers. The resulting competition will benefit all users of telecommunications services. Indeed, competition should foster lower local telephone prices and, consequently, stimulate demand for telecommunications services and increase economic growth. 31. Conversely, the record demonstrates that a lack of number portability likely would deter entry by competitive providers of local service because of the value customers place on retaining their telephone numbers. Business customers, in particular, may be reluctant to incur the administrative, marketing, and goodwill costs associated with changing telephone numbers. As indicated above, several studies show that customers are reluctant to switch carriers if they are required to change telephone numbers. To the extent that customers are reluctant to change service providers due to the absence of number portability, demand for services provided by new entrants will be depressed. This could well discourage entry by new service providers and thereby frustrate the pro-competitive goals of the 1996 Act. >--tony >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005 Voice: 202.533.2811, Cell : 314.503.0640, Fax: 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jan 31 10:46:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18068 for ; Wed, 31 Jan 2001 10:46:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10035; Wed, 31 Jan 2001 10:45:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09972 for ; Wed, 31 Jan 2001 10:44:57 -0500 (EST) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18030 for ; Wed, 31 Jan 2001 10:44:56 -0500 (EST) Received: by dnspri.npac.com; id JAA03758; Wed, 31 Jan 2001 09:44:48 -0600 (CST) Received: from unknown(192.168.20.162) by dnspri.npac.com via smap (V5.0) id xma003644; Wed, 31 Jan 01 09:44:09 -0600 Message-Id: <5.0.2.1.2.20010131092856.03423070@127.0.0.1> X-Sender: rshockey@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 31 Jan 2001 09:33:55 -0500 To: michaelm@netsol.com, "Robert H. Walter" From: Richard Shockey Subject: Re: [Enum] Querying Multiple ENUM Domains (e.g. e164.arpa, e.164.com, etc.) Cc: enum@ietf.org In-Reply-To: <20010130172601.E7879@bailey.dscga.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 05:26 PM 1/30/2001 -0500, Michael Mealling wrote: >On Tue, Jan 30, 2001 at 04:45:51PM -0500, Robert H. Walter wrote: > > At 04:16 PM 1/22/2001 -0500, Richard Shockey wrote: > > > I wish I could rewrite the DNS to allow for alternative resolution > > > models..but if some one could describe how this could be done I'd be > > > delighted to listen.. > > > > NetNumber faced this exact challenge when we deployed our > > "commercial" ENUM service under the domain "e164.com" last year. > > The vendors and customers we were contacting all liked the idea of > > moving forward with ENUM by utilizing our commercial implementation > > but they didn't want to be trapped into a single ENUM domain. We > > addressed this requirement by building an ENUM resolver that can be > > configured to simultaneously query multiple ENUM domains. That is all well and good but the vast majority 99.99 % of resolvers do not have that capability and never will. > > > 2. ENUM requires a special DNS resolver to correctly process the > > NAPTR records per RFC2915 and it is a simple matter to > > incorporate the ability to simultaneously query multiple ENUM > > domains. NO it is NOT. It is not a special DNS resolver... the standard BIND 9 libraries can easily process NAPTR records. > > > > 3. While supporting the domain "e164.arpa" as a viable competitive > > domain to "e164.com", the regulatory review process surrounding > > "e164.arpa" will take considerable time to sort out. I reject the notion that e164.arpa is "competitive" ...it is designed to be trusted. >This is VERY dangerous if not done very carefully. In the case >where a NAPTR record's flag field is blank you have started >doing the standard DDDS delegation steps. In this case you cannot >mix records from multiple nameservers since the entire algorithm >breaks. There are two solutions: > >1) coordinate all of the nameservers so that the NAPTR delegations >don't step on one another > >2) each ENUM 'root' corresponds to exactly to one ENUM delegation >path. You can combine the resulting _output_ but you _cannot_ >combine the actual NAPTR records. Thank you mike... >Please be very careful if you do this. > >-MM > >-- >-------------------------------------------------------------------------------- >Michael Mealling | Vote Libertarian! | >www.rwhois.net/michael >Sr. Research Engineer | www.ga.lp.org/gwinnett | >ICQ#: 14198821 >Network Solutions | www.lp.org | michaelm@netsol.com > >_______________________________________________ >enum mailing list >enum@ietf.org >http://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005 Voice: 202.533.2811, Cell : 314.503.0640, Fax: 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jan 31 10:59:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18437 for ; Wed, 31 Jan 2001 10:59:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10250; Wed, 31 Jan 2001 10:58:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10221 for ; Wed, 31 Jan 2001 10:58:38 -0500 (EST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18418 for ; Wed, 31 Jan 2001 10:58:36 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id KAA17510; Wed, 31 Jan 2001 10:48:35 -0500 (EST) Date: Wed, 31 Jan 2001 10:48:35 -0500 From: Michael Mealling To: Richard Shockey Cc: michaelm@netsol.com, "Robert H. Walter" , enum@ietf.org Subject: Re: [Enum] Querying Multiple ENUM Domains (e.g. e164.arpa, e.164.com, etc.) Message-ID: <20010131104835.B17257@bailey.dscga.com> Reply-To: michaelm@netsol.com References: <20010130172601.E7879@bailey.dscga.com> <5.0.2.1.2.20010131092856.03423070@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <5.0.2.1.2.20010131092856.03423070@127.0.0.1>; from rich.shockey@neustar.com on Wed, Jan 31, 2001 at 09:33:55AM -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Wed, Jan 31, 2001 at 09:33:55AM -0500, Richard Shockey wrote: > At 05:26 PM 1/30/2001 -0500, Michael Mealling wrote: > >On Tue, Jan 30, 2001 at 04:45:51PM -0500, Robert H. Walter wrote: > > > At 04:16 PM 1/22/2001 -0500, Richard Shockey wrote: > > > 2. ENUM requires a special DNS resolver to correctly process the > > > NAPTR records per RFC2915 and it is a simple matter to > > > incorporate the ability to simultaneously query multiple ENUM > > > domains. > > NO it is NOT. > > > It is not a special DNS resolver... the standard BIND 9 libraries can > easily process NAPTR records. Actually, any DNS resolver that has the res_* API or some other way of getting the answer data back in raw form can handle NAPTR records with no problems. I think this API goes back to at least BIND 4.8 which dates to the mid 1980s. DNS resolvers aren't supposed to care if they get back an answer they can't parse. Its the servers that are the issue and the latest Bind 8 and Bind 9 servers handle NAPTR just fine (I know cause I'm testing it for URI resolution now). And due to a security problem found recently, if you have a Bind 8 or (heaven forbid) a Bind 4 server then you need to upgrade anyway. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jan 31 11:07:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18712 for ; Wed, 31 Jan 2001 11:07:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10659; Wed, 31 Jan 2001 11:05:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10632 for ; Wed, 31 Jan 2001 11:05:56 -0500 (EST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18685 for ; Wed, 31 Jan 2001 11:05:54 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id KAA17549; Wed, 31 Jan 2001 10:55:52 -0500 (EST) Date: Wed, 31 Jan 2001 10:55:52 -0500 From: Michael Mealling To: Richard Shockey Cc: michaelm@netsol.com, "Robert H. Walter" , enum@ietf.org Subject: Re: [Enum] Querying Multiple ENUM Domains (e.g. e164.arpa, e.164.com, etc.) Message-ID: <20010131105552.C17257@bailey.dscga.com> Reply-To: michaelm@netsol.com References: <20010130172601.E7879@bailey.dscga.com> <5.0.2.1.2.20010131092856.03423070@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <5.0.2.1.2.20010131092856.03423070@127.0.0.1>; from rich.shockey@neustar.com on Wed, Jan 31, 2001 at 09:33:55AM -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Wed, Jan 31, 2001 at 09:33:55AM -0500, Richard Shockey wrote: > At 05:26 PM 1/30/2001 -0500, Michael Mealling wrote: > >On Tue, Jan 30, 2001 at 04:45:51PM -0500, Robert H. Walter wrote: > > > At 04:16 PM 1/22/2001 -0500, Richard Shockey wrote: > > > > I wish I could rewrite the DNS to allow for alternative resolution > > > > models..but if some one could describe how this could be done I'd be > > > > delighted to listen.. > > > > > > NetNumber faced this exact challenge when we deployed our > > > "commercial" ENUM service under the domain "e164.com" last year. > > > The vendors and customers we were contacting all liked the idea of > > > moving forward with ENUM by utilizing our commercial implementation > > > but they didn't want to be trapped into a single ENUM domain. We > > > addressed this requirement by building an ENUM resolver that can be > > > configured to simultaneously query multiple ENUM domains. > > That is all well and good but the vast majority 99.99 % of resolvers do > not have that capability and never will. By resolver do you mean DNS resolver? The DNS resolver doesn't care in this case. Its just being asked to retrieve a DNS record for some domain-name. If in the ENUM resolver you construct the domain-name differently that's up to you. You just have to ensure that you follow the ENUM (2916) rules until you get an output. If you have done that in parallel for e164.com, e164.arpa and e164.boogaloo and gotten three sets of output then you can do whatever you want. Its just that for each of those 'roots' you have to follow the rules until those rules tell you that you have finished.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jan 31 15:45:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25473 for ; Wed, 31 Jan 2001 15:45:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14383; Wed, 31 Jan 2001 15:38:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14356 for ; Wed, 31 Jan 2001 15:38:17 -0500 (EST) Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net [38.202.36.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25346 for ; Wed, 31 Jan 2001 15:38:15 -0500 (EST) Received: from RWALTER ([38.136.73.81]) by hvmta03-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20010131203808.UNDR1236.hvmta03-stg@RWALTER>; Wed, 31 Jan 2001 15:38:08 -0500 Reply-To: From: "Robert H. Walter" To: Cc: Subject: RE: [Enum] Querying Multiple ENUM Domains (e.g. e164.arpa, e.164.com, etc.) Date: Wed, 31 Jan 2001 15:33:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <20010131103105.A17257@bailey.dscga.com> Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > On Wed, Jan 31, 2001 at 10:31:25AM -0500, Michael Mealling wrote: > > This may be Netnumber's degenerate application but its not the ENUM > application defined in 2916. If you're going to use ENUM which defines > what happens when the flag is empty then simply munging all of the > records together that came back on the first request isn't allowed. > > If ENUM wants to allow this then you have the two alternatives > I listed earlier unless someone has an alternative that preserves > the delegation paths... With all due respect, I disagree that with your statement that the ENUM resolver is not compliant with the ENUM application defined in 2916. I can't find any text, example or specfication in either 2915 or 2916 that states or alludes that the flags field for the ENUM application is anything other than "u". In fact, all the specification text and examples related to ENUM in both 2915 and 2916 only use the "u" flag. None the less, the ENUM resolver will most likely encounter a scenario where the NAPTR records are provisioned in an ENUM domain with a blank flag. The remedy in this situation is simple... They are discarded. Thank you for the heads up on processing sets of NAPTR RR's returned from a given domain verses processing the munged NAPTR sets and then combining the output. I will be certain to account for this nuance. Regards, Bob > -----Original Message----- > From: Michael Mealling [mailto:michael@bailey.dscga.com] > Sent: Wednesday, January 31, 2001 10:31 AM > To: Robert H. Walter > Cc: michaelm@netsol.com; enum@ietf.org > Subject: Re: [Enum] Querying Multiple ENUM Domains (e.g. e164.arpa, > e.164.com, etc.) > > > On Wed, Jan 31, 2001 at 10:16:05AM -0500, Robert H. Walter wrote: > > > On Tue, Jan 30, 2001 at 05:26:15PM -0500, Michael Mealling wrote: > > > This is VERY dangerous if not done very carefully. > > > > > Thank you for the feedback... Indeed NetNumber has taken great care > > with its use of NAPTR. RFC2915 is reasonably flexible on how each > > application must specialize the basic NAPTR algorithm, hence, the > > multi-domain ENUM resolver is a degenerate case of the the basic > > NAPTR algorithm and discards NAPTR records from the result-set if: > > > > 1. The flags field contains a value other than "u". > > 2. The protocol portion of the service field does not match > > the input service protocol filter. > > 3. The service field does not end with "+E2U". > > 4. The regex field is empty. > > 5. The RR is a duplicate from another ENUM domain. > > This may be Netnumber's degenerate application but its not the ENUM > application defined in 2916. If you're going to use ENUM which defines > what happens when the flag is empty then simply munging all of the > records together that came back on the first request isn't allowed. > > If ENUM wants to allow this then you have the two alternatives > I listed earlier unless someone has an alternative that preserves > the delegation paths... > > -MM > > > -- > -------------------------------------------------------------------------------- > Michael Mealling | Vote Libertarian! | www.rwhois.net/michael > Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 > Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jan 31 16:00:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25618 for ; Wed, 31 Jan 2001 16:00:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14572; Wed, 31 Jan 2001 16:00:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14537 for ; Wed, 31 Jan 2001 16:00:04 -0500 (EST) Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25609 for ; Wed, 31 Jan 2001 16:00:01 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id PAA18560; Wed, 31 Jan 2001 15:50:04 -0500 (EST) Date: Wed, 31 Jan 2001 15:50:03 -0500 From: Michael Mealling To: "Robert H. Walter" Cc: michaelm@netsol.com, enum@ietf.org Subject: Re: [Enum] Querying Multiple ENUM Domains (e.g. e164.arpa, e.164.com, etc.) Message-ID: <20010131155003.F13331@bailey.dscga.com> Reply-To: michaelm@netsol.com References: <20010131103105.A17257@bailey.dscga.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: ; from rwalter@netnumber.com on Wed, Jan 31, 2001 at 03:33:16PM -0500 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Wed, Jan 31, 2001 at 03:33:16PM -0500, Robert H. Walter wrote: > > On Wed, Jan 31, 2001 at 10:31:25AM -0500, Michael Mealling wrote: > > > > This may be Netnumber's degenerate application but its not the ENUM > > application defined in 2916. If you're going to use ENUM which defines > > what happens when the flag is empty then simply munging all of the > > records together that came back on the first request isn't allowed. > > > > If ENUM wants to allow this then you have the two alternatives > > I listed earlier unless someone has an alternative that preserves > > the delegation paths... > > With all due respect, I disagree that with your statement that the > ENUM resolver is not compliant with the ENUM application defined in > 2916. I can't find any text, example or specfication in either 2915 > or 2916 that states or alludes that the flags field for the ENUM > application is anything other than "u". In fact, all the specification > text and examples related to ENUM in both 2915 and 2916 only use > the "u" flag. You are correct. On second reading I noticed that the ENUM spec never actually defines the contents of the flags field at all but instead seems to inherit it from 2915. 'u' is used in several examples but nothing ever actually says what 'u' means. > None the less, the ENUM resolver will most likely encounter a scenario > where the NAPTR records are provisioned in an ENUM domain with a blank > flag. The remedy in this situation is simple... They are discarded. 2916 doesn't say this either. 2915 specifically says that in the absense of a flag value that specifies terminality that the output of the substitution is a new Key to be looked up. See the section that defines the interaction between the Service field and the Flags field: If a protocol is specified, but the flags field does not state that the NAPTR is terminal, the next lookup MUST be for a NAPTR. The client MAY choose not to perform the next lookup if the protocol is unknown, but that behavior MUST NOT be relied upon. > Thank you for the heads up on processing sets of NAPTR RR's returned > from a given domain verses processing the munged NAPTR sets and then > combining the output. I will be certain to account for this nuance. No problem. Remember, NAPTR and the DDDS aren't just TXT records for stuffing URLs into.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jan 31 18:19:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27742 for ; Wed, 31 Jan 2001 18:19:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16345; Wed, 31 Jan 2001 18:17:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16316 for ; Wed, 31 Jan 2001 18:17:47 -0500 (EST) Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27717 for ; Wed, 31 Jan 2001 18:17:45 -0500 (EST) Received: from dranalli ([38.136.73.86]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20010131231610.JJQS20644.hvmta01-stg@dranalli>; Wed, 31 Jan 2001 18:16:10 -0500 Message-ID: <019a01c08bda$cd2c0740$56498826@netnumber.com> Reply-To: "Douglas Ranalli" From: "Douglas Ranalli" To: , , Subject: Re: [ENUM] Report on ITU ENUM Workshop - January 17, 2001 Date: Wed, 31 Jan 2001 18:09:02 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0197_01C08BB0.E401EBD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0197_01C08BB0.E401EBD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Richard, Earlier today (Wednesday January 31) you wrote a long response to a note = from Tony Rutkowski outlining various reasons for why you believe = "e164.arpa" is the only way to go in delivering ENUM Registry services. = Outlined below are two sections that I'd like to explore further: >In addition to that, there must be clear and consistent guidelines to=20 >prevent people from registering telephone numbers that do not belong to = >them.=20 My sense is that we have broad agreement with the vision that validation = is an important component of ENUM services. Within this vision, there = is no reason why a commercial ENUM service can't implement validation = policies that are as good as, or even better than, the validation = policies implemented by the multiple Registry operators that will exist = around the world under the "e164.arpa" model. As Judith Oppenheimer = pointed out in a note earlier today, the challenges associated with = validating control over an E164 number exist within the PSTN today. = Validation is an issue that needs to be addressed in both "public" and = "commercial" ENUM implementations and I look forward to participating in = this discussion as we move forward. =20 >The E.164 space is regulated and controlled in order to produce = consistency=20 >in results. You pick up the phone and dial and it works.... I'm sure you will agree that the definition of "regulation" in the PSTN = has changed quite dramatically over the past several decades as = "deregulation" has been introduced at multiple layers within the PSTN = infrastructure. Forty years ago this argument was used by AT&T to = prevent end-users from connecting any "non AT&T phones" to the = telephone network. As a commercial ENUM operator under "e164.com" I'm = not against the idea of regulation in the ENUM space, I'm just against = the idea of excluding competition. This is a complex issue and I'll = look forward to learning more about your views at the Ad Hoc meeting on = the 12th to see if there is room for a common ground surrounding a = regulatory definition of acceptable ENUM validation policies. Regards, Doug Douglas J. Ranalli Founder & Chief Strategy Officer NetNumber 650 Suffolk Street, Suite 307 Lowell, MA 01854 dranalli@netnumber.com www.netnumber.com 978-454-4210 ext 22 978-454-5044 (fax) ------=_NextPart_000_0197_01C08BB0.E401EBD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Richard,
 
Earlier today (Wednesday January 31) = you wrote a=20 long response to a note from Tony Rutkowski outlining various = reasons for=20 why you believe "e164.arpa" is the only way to go in delivering = ENUM=20 Registry services.  Outlined below are two sections that I'd like = to=20 explore further:
 
>In addition to that, there must be = clear and=20 consistent guidelines to
>prevent people from registering = telephone=20 numbers that do not belong to
>them.
 
My sense is that we have broad=20 agreement with the vision that validation is an important component = of ENUM=20 services.  Within this vision, there is no reason why a = commercial=20 ENUM service can't implement validation policies that are as good as, or = even=20 better than, the validation policies implemented = by the multiple=20 Registry operators that will exist around the world under the = "e164.arpa"=20 model.  As Judith Oppenheimer pointed out in a note earlier today, = the=20 challenges associated with validating control over an E164 number = exist=20 within the PSTN today.  Validation is an issue that needs to = be=20 addressed in both "public" and "commercial" ENUM = implementations and I=20 look forward to participating in this discussion as we move=20 forward.     
 
>The E.164 space is regulated and = controlled in=20 order to produce consistency
>in results. You pick up the phone = and dial=20 and it works....
 
I'm sure you will agree that the = definition of=20 "regulation" in the PSTN has changed quite dramatically over the past = several=20 decades as "deregulation" has been introduced at multiple layers within = the PSTN=20 infrastructure.  Forty years ago this argument was used by = AT&T to=20 prevent end-users from connecting any "non AT&T phones" to the = telephone network.  As a commercial ENUM operator under "e164.com" = I'm not=20 against the idea of regulation in the ENUM space, I'm just against the = idea of=20 excluding competition.  This is a complex issue and I'll look = forward=20 to learning more about your views at the Ad Hoc meeting on the 12th to = see if=20 there is room for a common ground surrounding a regulatory definition=20 of acceptable ENUM validation policies.
 
Regards,
 
Doug
 
Douglas J. Ranalli
Founder & = Chief Strategy=20 Officer
NetNumber
650 Suffolk Street, Suite 307
Lowell, = MA =20 01854
dranalli@netnumber.com
www.netnumber.com
978-454-4210 = ext=20 22
978-454-5044 (fax)
------=_NextPart_000_0197_01C08BB0.E401EBD0-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Jan 31 21:19:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00833 for ; Wed, 31 Jan 2001 21:19:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18371; Wed, 31 Jan 2001 21:19:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18340 for ; Wed, 31 Jan 2001 21:19:12 -0500 (EST) Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00814 for ; Wed, 31 Jan 2001 21:19:09 -0500 (EST) Received: from worldnet ([12.88.174.231]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.10 201-229-121-110) with SMTP id <20010201021838.OBLV29407.mtiwmhc21.worldnet.att.net@worldnet> for ; Thu, 1 Feb 2001 02:18:38 +0000 From: "Judith Oppenheimer" To: Subject: [ENUM] Report on ITU ENUM Workshop - January 17, 2001 Date: Wed, 31 Jan 2001 20:30:21 -0500 Message-ID: <006b01c08bf5$0556d900$59ac580c@att.net.icbtollfree.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Richard, what are you talking about? I haven't seen any alternate ENUM proposals that exclude subscriber verification. The FCC information on number portability is interesting and as an 800 consultant, something I'm infinitely familiar with. But its a red herring to suggest that any approach outside of .arpa would omit subscriber verification, or interfere with legitimate authorized portability. > guarantees that hijacking and other forms of consumer fraud would > proliferate. > RFC 2916 addresses the desire of consumers to be able to use their > telephone numbers in the consistent and reliable manner for > ALL forms of > communications as they do now on the PSTN with the equal > reliability of results. Let's not fool ourselves. Under today's PSTN telephony in the U.S., slamming by telephone companies is at an all-time high, and local number portability bears little resemblance to the functional portability that toll free number subscribers enjoy. That said, toll free number subscribers, who bear the bulk of number theft - hijacking - due to the value of toll free's, have recourse because regulations specify that the end user subscriber *controls* the toll free number and service. The key to addressing hijacking, is to insure that end user subscribers retain control over their telephone numbers and service, and insure as well, that they initiate or sign off on number entry into any ENUM system. As for consumer fraud, that's largely perpetrated by the PSTN companies themselves. Will PSTN-controlled ENUM provide ways to further exploit that abuse? I don't know, but I have my concerns. Judith --------------------------------------------------------------------------- ---------- Judith Oppenheimer 212 684-7210, 1 800 The Expert Publisher, http://ICBTollFreeNews.com "An important source of inside information," says InfoWorld; "superb", "invaluable", "critically intelligent", "exceedingly useful", report ICB Premium Subscribers. ENTER HERE: http://www.roibot.com/w.cgi?R1764_sig --------------------------------------------------------------------------- ---------- > -----Original Message----- > From: ENUM List for EB/CIP/MA > [mailto:ENUM@ALMSNTSA.LMLIST.STATE.GOV]On > Behalf Of Richard Shockey > Sent: Wednesday, January 31, 2001 10:29 AM > To: ENUM@ALMSNTSA.LMLIST.STATE.GOV > Subject: Re: [ENUM] Report on ITU ENUM Workshop - January 17, 2001 > > > At 06:31 PM 1/29/2001 -0500, A.M.Rutkowski wrote: > >Hi David, > > > >>Is in-addr.arpa subject to anti-trust protection or extensive > >>regulation? Is .COM? > > > >Yes, indeed. > > > >>The rub is in "assures uniqueness". > > > >It's all relative, and different implementations have > >different cost-benefit tradeoffs. Generally, less > >government and more open competition have proven > >the better direction. I'm confident the industry > >can work this out. > > > >e164.arpa might as well be named regulate_me.arpa. > > And you accuse me of rhetoric... > > Why don't you attempt to produce a reasoned technical > argument instead of > political platitudes. > > The core issue now and has been that if Internet Telephony > devices are to > consistently and reliable connect with each other there is a > need for a > single clear DNS tree to retrieve NAPTR records from. > > In addition to that there must be clear and consistent guidelines to > prevent people from registering telephone numbers that do not > belong to > them. Your non intervention proposal ( essentially anarchy as > I see it) > guarantees that hijacking and other forms of consumer fraud would > proliferate..and a key form of identity on the internet would > be rendered > useless...and with it the potential for an entire multi-billion dollar > industry to grow. > > RFC 2916 addresses the desire of consumers to be able to use their > telephone numbers in the consistent and reliable manner for > ALL forms of > communications as they do now on the PSTN with the equal > reliability of > results. > > The E.164 space is regulated and controlled in order to > produce consistency > in results. You pick up the phone and dial and it works. the > PSTN ..like > the Internet cannot search multiple databases to discover reliable end > point information. > > Internet Telephony is no different in that sense from PSTN Telephony. > > I'd like to share some insights into this problem that the > FCC addressed in > its First Report and Rule on Number Portability. > > While not specific to the problem at hand the FCC noted the > importance of > telephone numbers in creating competitive markets for > telecommunications > services. > > I submit that what we are dealing with here is similar in many ways. > > a. People will not use Internet Telephony IN A BIG WAY if > they cannot use > their telephone numbers. > > b. If the resolution of those numbers into the DNS cannot create > technically consistent results they will be essentially useless. > > c. Therefore if it is the desire of Telecom Equipment > Manufactures, ISP's, > Government and other possible new entrants into Internet Telephony to > create TRULY competitive markets for communications services using > telephone numbers as names then implementation of RFC2916 is > a necessity. > > And ....I might add clearly is within the spirit of the 1996 > Telecommunications Act. > > ####### > > From the FCC Order and Report..... > 29. We note that several studies described in the record > demonstrate the reluctance of both business and residential > customers to switch carriers if they must change numbers. For > example, MCI has stated that, based on a nationwide Gallup survey, > 83 percent of business customers and 80 percent of residential > customers would be unlikely to change local service providers if they > had to change their telephone numbers. Time Warner Holdings > states that consumers are 40 percent less likely to change service > providers if a number change is required. Citizens Utilities notes > that approximately 85 percent of the discussions that its subsidiary, > ELI, has with potential customers about switching providers end > when those potential customers learn that they must change their > telephone numbers. The study commissioned by Pacific Bell > concludes that, without portability, new entrants would be forced to > discount their local exchange service and other competing offerings > by at least 12 percent below the incumbent LECs' prices in order to > induce customers to switch carriers due to customers' resistance to > changing numbers. > > 30. The ability of end users to retain their telephone numbers > when changing service providers gives customers flexibility in the > quality, price, and variety of telecommunications services they can > choose to purchase. Number portability promotes competition > between telecommunications service providers by, among other > things, allowing customers to respond to price and service changes > without changing their telephone numbers. The resulting > competition will benefit all users of telecommunications services. > Indeed, competition should foster lower local telephone prices and, > consequently, stimulate demand for telecommunications services > and increase economic growth. > > 31. Conversely, the record demonstrates that a lack of > number portability likely would deter entry by competitive providers > of local service because of the value customers place on retaining > their telephone numbers. Business customers, in particular, may > be reluctant to incur the administrative, marketing, and goodwill > costs associated with changing telephone numbers. As indicated > above, several studies show that customers are reluctant to switch > carriers if they are required to change telephone numbers. To the > extent that customers are reluctant to change service providers due > to the absence of number portability, demand for services provided > by new entrants will be depressed. This could well discourage entry > by new service providers and thereby frustrate the pro-competitive > goals of the 1996 Act. > > > > > >--tony > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Technical Industry Liaison > NeuStar Inc. > 1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005 > Voice: 202.533.2811, Cell : 314.503.0640, Fax: 815.333.1237 > or > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum