From enum-bounces@ietf.org Sat Oct 01 06:12:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELeLv-0000po-9d; Sat, 01 Oct 2005 06:12:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELeLr-0000oH-9r for enum@megatron.ietf.org; Sat, 01 Oct 2005 06:12:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14237 for ; Sat, 1 Oct 2005 06:12:16 -0400 (EDT) Received: from bm.firsthand.net ([80.68.91.165] helo=plesktest.vm.bytemark.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELeTm-0001Jq-7U for enum@ietf.org; Sat, 01 Oct 2005 06:20:38 -0400 Received: (qmail 11116 invoked from network); 1 Oct 2005 12:14:31 +0100 Received: from unknown (HELO ?81.6.214.204?) (81.6.214.204) by bm.firsthand.net with SMTP; 1 Oct 2005 12:14:31 +0100 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4595@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4595@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20FE75C5-F52A-4146-A4B8-D40F30A67A4A@firsthand.net> Content-Transfer-Encoding: 7bit From: Christian de Larrinaga Subject: Re: [Enum] Neustar and GSM create alternate ROOT Date: Sat, 1 Oct 2005 11:10:19 +0100 To: Stastny Richard X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Are GSM members intending to keep access to all domains open for users (ENUM) or to filter out all other domains so only this hybrid carrier ENUM is available to provide (routing) services to mobile users under operator control? Christian de Larrinaga cdel@firsthand.net On 30 Sep 2005, at 20:42, Stastny Richard wrote: > Yes and no, > > Routing in IMS is done via SIP URIs (see ETSI TS 123.228) > It is a complete new root also for SIP routing of "public" User > Identities (finding > the other servers) > > Of course it will also contain a ENUM tree for mapping E.164 to > these SIP URIs, > which will then also resolved within this alternate root > > Richard > > ________________________________ > > Von: Tom-PT Taylor [mailto:taylor@nortel.com] > Gesendet: Fr 30.09.2005 21:37 > An: Stastny Richard > Cc: enum@ietf.org > Betreff: Re: [Enum] Neustar and GSM create alternate ROOT > > > > Do I understand correctly that this is a form of carrier ENUM? > > Stastny Richard wrote: > >> Dear co-chairs, especially Patrik, >> >> what is your opiniion on this press release? >> >> http://www.neustar.com/pressroom/files/announcements/ >> ns_pr_09282005.pdf >> >> GSM Association and NeuStar Sign Agreement to Offer Root DNS >> Services to More than 680 Global GSM Mobile Operators >> >> providing .grps and 3gppnetwork.org as TLD in the GRX network >> using public IP addresses. >> >> I thought the IAB recommended to 3GPP NOT to do this because of >> leakage >> >> Richard >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum >> >> >> > > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Oct 01 06:24:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELeXC-0006Ys-Hs; Sat, 01 Oct 2005 06:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELeX9-0006Xs-S3 for enum@megatron.ietf.org; Sat, 01 Oct 2005 06:24:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18376 for ; Sat, 1 Oct 2005 06:23:56 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ELefB-0001fR-Tp for enum@ietf.org; Sat, 01 Oct 2005 06:32:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Neustar and GSM create alternate ROOT Date: Sat, 1 Oct 2005 12:27:20 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C459C@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Neustar and GSM create alternate ROOT Thread-Index: AcXGcRdsJo7C3q7cT6e9mj/qq7tPFgAALTON From: "Stastny Richard" To: "Christian de Larrinaga" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The GRX network uses public IP addresses, but has NO connection to the public Internet (at least not now). It is only connected to the networks of the mobile operators (via NAT) and they use private 10.x.x.x ranges So there is no way to access other domains in the public DNS. It is a completely separate namespace. The main use of the GRX now is to tunnel roaming subscribers using data access via the visited network and the GRX to the hone network. If you use a data connection say roaming in vodafone.uk and access the Internet, you will be tunneled through and will get your public IP address from the home network. Richard ________________________________ Von: Christian de Larrinaga [mailto:cdel@firsthand.net] Gesendet: Sa 01.10.2005 12:10 An: Stastny Richard Cc: Tom-PT Taylor; enum@ietf.org Betreff: Re: [Enum] Neustar and GSM create alternate ROOT Are GSM members intending to keep access to all domains open for=20 users (ENUM) or to filter out all other domains so only this hybrid=20 carrier ENUM is available to provide (routing) services to mobile=20 users under operator control? Christian de Larrinaga cdel@firsthand.net On 30 Sep 2005, at 20:42, Stastny Richard wrote: > Yes and no, > > Routing in IMS is done via SIP URIs (see ETSI TS 123.228) > It is a complete new root also for SIP routing of "public" User=20 > Identities (finding > the other servers) > > Of course it will also contain a ENUM tree for mapping E.164 to=20 > these SIP URIs, > which will then also resolved within this alternate root > > Richard > > ________________________________ > > Von: Tom-PT Taylor [mailto:taylor@nortel.com] > Gesendet: Fr 30.09.2005 21:37 > An: Stastny Richard > Cc: enum@ietf.org > Betreff: Re: [Enum] Neustar and GSM create alternate ROOT > > > > Do I understand correctly that this is a form of carrier ENUM? > > Stastny Richard wrote: > >> Dear co-chairs, especially Patrik, >> >> what is your opiniion on this press release? >> >> http://www.neustar.com/pressroom/files/announcements/ >> ns_pr_09282005.pdf >> >> GSM Association and NeuStar Sign Agreement to Offer Root DNS=20 >> Services to More than 680 Global GSM Mobile Operators >> >> providing .grps and 3gppnetwork.org as TLD in the GRX network=20 >> using public IP addresses. >> >> I thought the IAB recommended to 3GPP NOT to do this because of=20 >> leakage >> >> Richard >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum >> >> >> > > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Oct 01 06:33:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELeg6-0002HF-VU; Sat, 01 Oct 2005 06:33:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELeg3-0002GN-QC for enum@megatron.ietf.org; Sat, 01 Oct 2005 06:33:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20694 for ; Sat, 1 Oct 2005 06:33:08 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ELeo6-0001wB-I6 for enum@ietf.org; Sat, 01 Oct 2005 06:41:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Neustar and GSM create alternate ROOT - add Date: Sat, 1 Oct 2005 12:33:55 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C459D@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Neustar and GSM create alternate ROOT - add Thread-Index: AcXGcRdsJo7C3q7cT6e9mj/qq7tPFgAAohjS From: "Stastny Richard" To: "Christian de Larrinaga" X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Access to e164.arpa will be not possible from with this network, they plan to use a private carrier ENUM in either e164.3gppnetwork.org or e164enum.net =20 End-users may of course access e164.arpa via GPRS Richard ________________________________ Von: Christian de Larrinaga [mailto:cdel@firsthand.net] Gesendet: Sa 01.10.2005 12:10 An: Stastny Richard Cc: Tom-PT Taylor; enum@ietf.org Betreff: Re: [Enum] Neustar and GSM create alternate ROOT Are GSM members intending to keep access to all domains open for=20 users (ENUM) or to filter out all other domains so only this hybrid=20 carrier ENUM is available to provide (routing) services to mobile=20 users under operator control? Christian de Larrinaga cdel@firsthand.net On 30 Sep 2005, at 20:42, Stastny Richard wrote: > Yes and no, > > Routing in IMS is done via SIP URIs (see ETSI TS 123.228) > It is a complete new root also for SIP routing of "public" User=20 > Identities (finding > the other servers) > > Of course it will also contain a ENUM tree for mapping E.164 to=20 > these SIP URIs, > which will then also resolved within this alternate root > > Richard > > ________________________________ > > Von: Tom-PT Taylor [mailto:taylor@nortel.com] > Gesendet: Fr 30.09.2005 21:37 > An: Stastny Richard > Cc: enum@ietf.org > Betreff: Re: [Enum] Neustar and GSM create alternate ROOT > > > > Do I understand correctly that this is a form of carrier ENUM? > > Stastny Richard wrote: > >> Dear co-chairs, especially Patrik, >> >> what is your opiniion on this press release? >> >> http://www.neustar.com/pressroom/files/announcements/ >> ns_pr_09282005.pdf >> >> GSM Association and NeuStar Sign Agreement to Offer Root DNS=20 >> Services to More than 680 Global GSM Mobile Operators >> >> providing .grps and 3gppnetwork.org as TLD in the GRX network=20 >> using public IP addresses. >> >> I thought the IAB recommended to 3GPP NOT to do this because of=20 >> leakage >> >> Richard >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum >> >> >> > > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 03 04:42:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMLuM-0006Ki-MM; Mon, 03 Oct 2005 04:42:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMLuM-0006Kd-2P for enum@megatron.ietf.org; Mon, 03 Oct 2005 04:42:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12504 for ; Mon, 3 Oct 2005 04:42:48 -0400 (EDT) Received: from cellgate.btcellnet.net ([158.230.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMM2n-0008MB-DO for enum@ietf.org; Mon, 03 Oct 2005 04:51:33 -0400 Received: from brwmsw03.btcellnet.net by cellgate.btcellnet.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Mon, 3 Oct 2005 09:31:15 +0100 Received: from uksthims002.uk.pri.o2.com (uksthims002.uk.pri.o2.com) by uksthmsw003.uk.pri.o2.com (Clearswift SMTPRS 5.0.9) with ESMTP id for ; Mon, 3 Oct 2005 09:42:37 +0100 Received: from UKSTHMSX012.uk.pri.o2.com ([172.17.61.187]) by uksthims002.uk.pri.o2.com with Microsoft SMTPSVC (6.0.3790.1830); Mon, 3 Oct 2005 09:42:36 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Enum] Neustar and GSM create alternate ROOT Date: Mon, 3 Oct 2005 09:42:35 +0100 Message-ID: <0CD3FFEAEC982F489F872AB8DA32D6240258A3E0@Uksthmsx012.uk.pri.o2.com> Thread-Topic: [Enum] Neustar and GSM create alternate ROOT Thread-Index: AcXF9GpVsXpT4AIFRp+qrgQ7u4tGfACAR20g From: "Fullbrook Kim \(UK\)" To: X-OriginalArrivalTime: 03 Oct 2005 08:42:36.0901 (UTC) FILETIME=[67E72150:01C5C7F6] X-Spam-Score: 1.8 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Use of domain names on the GRX network is described in recent version of 3GPP TS 23.003, for example V6.7.1 at: http://www.3gpp.org/ftp/Specs/archive/23_series/23.003/23003-671.zip As a result of the policy, those existing services that use the .gprs domain will continue to use it and any new services will use the 3gppnetwork.org domain. There might be new services in the future that would like to use a different domain name, in which case that domain name must be registered on the public Internet to avoid any potential leakage problem. The Neustar press release describes the implementation of a root DNS to carry the .gprs domain (for some existing services) and 3gppnetwork.org domain for new services. Kim Fullbrook O2 UK (Member of GSMA) -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Stastny Richard Sent: 30 September 2005 20:23 To: enum@ietf.org Subject: [Enum] Neustar and GSM create alternate ROOT Dear co-chairs, especially Patrik, =20 what is your opiniion on this press release? =20 http://www.neustar.com/pressroom/files/announcements/ns_pr_09282005.pdf =20 GSM Association and NeuStar Sign Agreement to Offer Root DNS Services to More than 680 Global GSM Mobile Operators providing .grps and 3gppnetwork.org as TLD in the GRX network using public IP addresses. =20 I thought the IAB recommended to 3GPP NOT to do this because of leakage =20 Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D This electronic message contains information from O2 which may be privilege= d or confidential. The information is intended to be for the use of the ind= ividual(s) or entity named above. If you are not the intended recipient be = aware that any disclosure, copying distribution or use of the contents of t= his information is prohibited. If you have received this electronic message= in error, please notify us by telephone or email (to the numbers or addres= s above) immediately. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 03 05:58:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMN5A-0003cw-Qd; Mon, 03 Oct 2005 05:58:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMN58-0003cI-Dw for enum@megatron.ietf.org; Mon, 03 Oct 2005 05:58:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17590 for ; Mon, 3 Oct 2005 05:57:59 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EMNDW-0001tF-QA for enum@ietf.org; Mon, 03 Oct 2005 06:06:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Neustar and GSM create alternate ROOT Date: Mon, 3 Oct 2005 12:01:17 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2162@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Neustar and GSM create alternate ROOT Thread-Index: AcXF9GpVsXpT4AIFRp+qrgQ7u4tGfACAR20gAALSC8A= From: "Stastny Richard" To: "Fullbrook Kim \(UK\)" , X-Spam-Score: 1.8 (+) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Kim, just one question: If I use a Public User Identity as defined in TS 23.228 in the format of a SIP URI to be used on a business card (as also stated there) - e.g. sip:richard.stastny@o2.co.uk is the domain part of this SIP URI resolved in the GRX DNS or in the public DNS? Richard > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Fullbrook Kim (UK) > Sent: Monday, October 03, 2005 10:43 AM > To: enum@ietf.org > Subject: RE: [Enum] Neustar and GSM create alternate ROOT >=20 > Use of domain names on the GRX network is described in recent version of > 3GPP TS 23.003, for example V6.7.1 at: > http://www.3gpp.org/ftp/Specs/archive/23_series/23.003/23003-671.zip >=20 > As a result of the policy, those existing services that use the .gprs > domain will continue to use it and any new services will use the > 3gppnetwork.org domain. There might be new services in the future that > would like to use a different domain name, in which case that domain > name must be registered on the public Internet to avoid any potential > leakage problem. >=20 > The Neustar press release describes the implementation of a root DNS to > carry the .gprs domain (for some existing services) and 3gppnetwork.org > domain for new services. >=20 > Kim Fullbrook > O2 UK (Member of GSMA) >=20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Stastny Richard > Sent: 30 September 2005 20:23 > To: enum@ietf.org > Subject: [Enum] Neustar and GSM create alternate ROOT >=20 >=20 > Dear co-chairs, especially Patrik, >=20 > what is your opiniion on this press release? >=20 > http://www.neustar.com/pressroom/files/announcements/ns_pr_09282005.pdf >=20 > GSM Association and NeuStar Sign Agreement to Offer Root DNS Services to > More than 680 Global GSM Mobile Operators >=20 > providing .grps and 3gppnetwork.org as TLD in the GRX network using > public IP addresses. >=20 > I thought the IAB recommended to 3GPP NOT to do this because of leakage >=20 > Richard >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > This electronic message contains information from O2 which may be > privileged or confidential. The information is intended to be for the use > of the individual(s) or entity named above. If you are not the intended > recipient be aware that any disclosure, copying distribution or use of the > contents of this information is prohibited. If you have received this > electronic message in error, please notify us by telephone or email (to > the numbers or address above) immediately. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 03 09:13:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMQ8V-0006Vu-2T; Mon, 03 Oct 2005 09:13:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMQ8Q-0006Vd-Ab for enum@megatron.ietf.org; Mon, 03 Oct 2005 09:13:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27779 for ; Mon, 3 Oct 2005 09:13:36 -0400 (EDT) Received: from cellgate.btcellnet.net ([158.230.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMQGs-0006uK-Pi for enum@ietf.org; Mon, 03 Oct 2005 09:22:24 -0400 Received: from ukbrwmsw05.uk.pri.o2.com by cellgate.btcellnet.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Mon, 3 Oct 2005 14:02:02 +0100 Received: from uksthims002.uk.pri.o2.com (uksthims002.uk.pri.o2.com) by uksthmsw005.uk.pri.o2.com (Clearswift SMTPRS 5.0.9) with ESMTP id for ; Mon, 3 Oct 2005 14:13:21 +0100 Received: from UKSTHMSX012.uk.pri.o2.com ([172.17.61.187]) by uksthims002.uk.pri.o2.com with Microsoft SMTPSVC (6.0.3790.1830); Mon, 3 Oct 2005 14:13:20 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Enum] Neustar and GSM create alternate ROOT Date: Mon, 3 Oct 2005 14:13:18 +0100 Message-ID: <0CD3FFEAEC982F489F872AB8DA32D6240258A437@Uksthmsx012.uk.pri.o2.com> Thread-Topic: [Enum] Neustar and GSM create alternate ROOT Thread-Index: AcXF9GpVsXpT4AIFRp+qrgQ7u4tGfACAR20gAALSC8AABnNOgA== From: "Fullbrook Kim \(UK\)" To: X-OriginalArrivalTime: 03 Oct 2005 13:13:20.0880 (UTC) FILETIME=[3A119F00:01C5C81C] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is an interesting question but it's not appropriate for me to comment on an area which has not been fully agreed within the GSMA. What I can say is that whatever solution we adopt needs to be compatible with the need to interwork with non-GSMA carriers in the future. Kim Fullbrook O2 UK -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: 03 October 2005 11:01 To: Fullbrook Kim (UK); enum@ietf.org Subject: RE: [Enum] Neustar and GSM create alternate ROOT Hi Kim, just one question: If I use a Public User Identity as defined in TS 23.228 in the format of a SIP URI to be used on a business card (as also stated there) - e.g. sip:richard.stastny@o2.co.uk is the domain part of this SIP URI resolved in the GRX DNS or in the public DNS? Richard =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D This electronic message contains information from O2 which may be privilege= d or confidential. The information is intended to be for the use of the ind= ividual(s) or entity named above. If you are not the intended recipient be = aware that any disclosure, copying distribution or use of the contents of t= his information is prohibited. If you have received this electronic message= in error, please notify us by telephone or email (to the numbers or addres= s above) immediately. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 03 09:40:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMQYP-0003AN-0I; Mon, 03 Oct 2005 09:40:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMQYN-0003AH-CT for enum@megatron.ietf.org; Mon, 03 Oct 2005 09:40:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28885 for ; Mon, 3 Oct 2005 09:40:25 -0400 (EDT) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMQgp-0007Xe-I9 for enum@ietf.org; Mon, 03 Oct 2005 09:49:13 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id C180B6FB2E; Mon, 3 Oct 2005 14:40:34 +0100 (BST) In-Reply-To: <0CD3FFEAEC982F489F872AB8DA32D6240258A437@Uksthmsx012.uk.pri.o2.com> References: <0CD3FFEAEC982F489F872AB8DA32D6240258A437@Uksthmsx012.uk.pri.o2.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] Neustar and GSM create alternate ROOT Date: Mon, 3 Oct 2005 14:39:37 +0100 To: Fullbrook Kim (UK) X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Kim, folks, thanks for the useful answer. Re. non-GSMA carrier interconnect: Is this a GRX issue or an individual SP issue? IIUC, that's behind Richard's "questions for clarification", and really is the x Billion dollar question. The answer may well shape the future for us all. all the best, Lawrence On 3 Oct 2005, at 14:13, Fullbrook Kim (UK) wrote: > What I can say is that whatever solution we adopt needs to be > compatible with > the need to interwork with non-GSMA carriers in the future. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 03 09:49:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMQhJ-0004qp-T3; Mon, 03 Oct 2005 09:49:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMQhI-0004qg-Hm for enum@megatron.ietf.org; Mon, 03 Oct 2005 09:49:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29272 for ; Mon, 3 Oct 2005 09:49:39 -0400 (EDT) Received: from mail.ficora.fi ([194.100.96.25] helo=portti1.ficora.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMQpl-0007lT-KF for enum@ietf.org; Mon, 03 Oct 2005 09:58:27 -0400 Received: from POSTI.laru.local ([10.1.0.10]) by portti1.ficora.fi with InterScan Messaging Security Suite; Mon, 03 Oct 2005 16:55:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Neustar and GSM create alternate ROOT - add Date: Mon, 3 Oct 2005 16:49:29 +0300 Message-ID: <07BC6C0D40216E44A34BE6701694FE8601862798@POSTI.laru.local> Thread-Topic: [Enum] Neustar and GSM create alternate ROOT - add Thread-Index: AcXGcRdsJo7C3q7cT6e9mj/qq7tPFgAAohjSAF0lDpAADV8ZkA== From: "Nieminen Klaus" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of=20 > Stastny Richard > Sent: 30. syyskuuta 2005 22:23 > providing .grps and 3gppnetwork.org as TLD in the GRX network using public IP > addresses. > > I thought the IAB recommended to 3GPP NOT to do this because of leakage Dear all, At least I have understood that there are use cases that requires the use public IP addresses in 3gppnetwork.org. Last week 3GPP SA plenary noted a LS from SA2 to GSMA IREG PACKET that says: 1. Overall Description: 3GPP SA2 would like to thank the GSMA for the LS on "Use of "pub.3gppnetwork.org" domain".=20 The understanding of SA2 is that the propagation of DNS information on W-APNs in the Internet for I-WLAN does not violate the existing WLAN stage 2, 3GPP TS 23.234. The purpose of the cited sentence in 3GPP TS 23.234 ("It shall be possible to restrict the propagation of DNS information used for the above mechanism to DNS servers controlled by the PLMNs and to DNS servers available only to authorised 3GPP WLAN UEs") is to allow operators the option of whether or not to advertise the domain names of W-APNs in public networks. In order to make this view clear, the attached CR in S2-052428 was agreed at the recent SA2 #48. SA2 does not see any technical problem if operators in GSMA decide to populate the Internet's DNS servers with information about W-APNs. Therefore SA2 is of the opinion that GSMA can specify a solution where the FQDNs of W-APNs are publicly resolvable (solution 1 in the LS from GSMA IREG). regards, - Klaus - _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 03 11:10:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMRxq-0002tp-Gq; Mon, 03 Oct 2005 11:10:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMRxo-0002tN-Iw for enum@megatron.ietf.org; Mon, 03 Oct 2005 11:10:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11254 for ; Mon, 3 Oct 2005 11:10:46 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EMS6H-0002Ng-DE for enum@ietf.org; Mon, 03 Oct 2005 11:19:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Neustar and GSM create alternate ROOT Date: Mon, 3 Oct 2005 17:14:16 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2165@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Neustar and GSM create alternate ROOT Thread-Index: AcXF9GpVsXpT4AIFRp+qrgQ7u4tGfACAR20gAALSC8AABnNOgAAEg61Q From: "Stastny Richard" To: "Fullbrook Kim \(UK\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Kim, > What I can say is that whatever solution we adopt needs to be=20 > compatible with the need to interwork with non-GSMA carriers=20 > in the future. thank you for this statement, I consider it important It would also be interesting what GSMA considers a non-GSMA "Carrier" ;-) Best regards Richard > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Fullbrook Kim (UK) > Sent: Monday, October 03, 2005 3:13 PM > To: enum@ietf.org > Subject: RE: [Enum] Neustar and GSM create alternate ROOT >=20 > This is an interesting question but it's not appropriate for me to > comment on an area which has not been fully agreed within the GSMA. What > I can say is that whatever solution we adopt needs to be compatible with > the need to interwork with non-GSMA carriers in the future. >=20 > Kim Fullbrook > O2 UK >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: 03 October 2005 11:01 > To: Fullbrook Kim (UK); enum@ietf.org > Subject: RE: [Enum] Neustar and GSM create alternate ROOT >=20 >=20 > Hi Kim, >=20 > just one question: If I use a Public User Identity as defined > in TS 23.228 in the format of a SIP URI to be used on > a business card (as also stated there) - e.g. > sip:richard.stastny@o2.co.uk >=20 > is the domain part of this SIP URI resolved in the GRX DNS > or in the public DNS? >=20 > Richard >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > This electronic message contains information from O2 which may be > privileged or confidential. The information is intended to be for the use > of the individual(s) or entity named above. If you are not the intended > recipient be aware that any disclosure, copying distribution or use of the > contents of this information is prohibited. If you have received this > electronic message in error, please notify us by telephone or email (to > the numbers or address above) immediately. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 04 10:32:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMnqG-00010B-Uf; Tue, 04 Oct 2005 10:32:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMnqF-000102-4r for enum@megatron.ietf.org; Tue, 04 Oct 2005 10:32:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23340; Tue, 4 Oct 2005 10:32:24 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMnyv-0002dp-AN; Tue, 04 Oct 2005 10:41:26 -0400 Received: from [10.31.13.114] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j94EWk4Y003450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Oct 2005 07:32:47 -0700 Message-ID: <43429243.70100@shockey.us> Date: Tue, 04 Oct 2005 10:31:31 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: iesg-secretary@ietf.org, Allison Mankin , "Peterson, Jon" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] Request for Publication - draftoietf-enum-voice-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a request for publication for one IETF ENUM WG working group document. WG last call on this document concluded on October 3, 2005. The document listed below is being proposed for Standards Track RFC. Status- Proposed Standard This document is a ENUM Working Group product, which has been discussed during 2005. Working Group Last call indicated no objections. Title : IANA Registration for Enumservice Voice Author(s) : R. Brandner Filename : draft-ietf-enum-voice-00.txt Pages : 13 Date : 2005-9-12 This document registers the ENUMservice ^voice^ (which has a defined sub-type ^tel^), as per the IANA registration process defined in the ENUM specification RFC3761. This service indicates that the contact held in the generated URI can be used to initiate an interactive voice (audio) call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-voice-00.txt -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 04 10:34:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMnsX-0001GS-TR; Tue, 04 Oct 2005 10:34:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMnsW-0001GI-DZ for enum@megatron.ietf.org; Tue, 04 Oct 2005 10:34:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23456; Tue, 4 Oct 2005 10:34:46 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMo1D-0002ge-GP; Tue, 04 Oct 2005 10:43:47 -0400 Received: from [10.31.13.114] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j94EZDfs003836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Oct 2005 07:35:14 -0700 Message-ID: <434292D6.1070502@shockey.us> Date: Tue, 04 Oct 2005 10:33:58 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: iesg-secretary@ietf.org, Allison Mankin , "Peterson, Jon" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] Request for Publication - draft-ietf-enum-iris-ereg-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a request for publication for one IETF ENUM WG working group document. WG last call on this document concluded on October 3, 2005. The document listed below is being proposed for Standards Track RFC. Status- Proposed Standard This document is a ENUM Working Group product, which has been discussed during 2004-2005. Though some have noted they would like enhancements to the protocol there has been consensus that this version is sufficiently mature to bring forward and there will almost certainly be enhanced versions in the future. Working Group Last call indicated no additional objections. Title: An ENUM Registry Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-ietf-enum-iris-ereg-02.txt Pages : 57 Date : 2005-9-12 This document describes an IRIS registry schema for registered ENUM information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-iris-ereg-02.txt -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 04 11:29:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMojA-0001jA-CK; Tue, 04 Oct 2005 11:29:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMoj8-0001j5-L8 for enum@megatron.ietf.org; Tue, 04 Oct 2005 11:29:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02336 for ; Tue, 4 Oct 2005 11:29:08 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMorn-0006D0-3T for enum@ietf.org; Tue, 04 Oct 2005 11:38:10 -0400 Received: from [10.31.13.114] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j94FTWQW009935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Oct 2005 08:29:33 -0700 Message-ID: <43429FAE.5020706@shockey.us> Date: Tue, 04 Oct 2005 11:28:46 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Content-Type: multipart/mixed; boundary="------------060905020403080101050905" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.7 (+) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Subject: [Enum] [Fwd: I-D ACTION:draft-stein-great-00.txt] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------060905020403080101050905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
FYI

-------- Original Message --------
Subject: I-D ACTION:draft-stein-great-00.txt
Date: Fri, 30 Sep 2005 15:50:01 -0400
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Great Real-Time Problem Statement
	Author(s)	: Y. Stein
	Filename	: draft-stein-great-00.txt
	Pages		: 11
	Date		: 2005-9-30
	
   VoIP is commonly perceived to be a low quality, but low cost,
   alternative to standard telephony.  This poor perception is often
   well deserved, being fueled by implementations designed without
   regard to characteristics of IP networks.  This problem statement
   attempts to catalog the shortcomings of current implementations, in
   order to explore the IETF community's interest in working to improve
   this situation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-stein-great-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-stein-great-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-stein-great-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--------------060905020403080101050905 Content-Type: Message/External-body; name="draft-stein-great-00.txt" Content-Disposition: inline; filename="draft-stein-great-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-9-30132608.I-D@ietf.org> --------------060905020403080101050905 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------060905020403080101050905 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------060905020403080101050905-- From enum-bounces@ietf.org Wed Oct 05 05:08:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN5GV-0007tE-2i; Wed, 05 Oct 2005 05:08:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN5GT-0007t9-BA for enum@megatron.ietf.org; Wed, 05 Oct 2005 05:08:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08128 for ; Wed, 5 Oct 2005 05:08:38 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN5PJ-0004X2-69 for enum@ietf.org; Wed, 05 Oct 2005 05:17:50 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 05 Oct 2005 02:08:28 -0700 X-IronPort-AV: i="3.97,175,1125903600"; d="scan'208"; a="217174171:sNHT52357198" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9598P4V027419; Wed, 5 Oct 2005 02:08:26 -0700 (PDT) Received: from [127.0.0.1] (ssh-ams-1.cisco.com [144.254.226.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j959JgKl021080; Wed, 5 Oct 2005 02:19:43 -0700 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C458F@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C458F@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] Neustar and GSM create alternate ROOT Date: Wed, 5 Oct 2005 11:08:20 +0200 To: Stastny Richard X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=803; t=1128503984; x=1128936184; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=paf@cisco.com; z=Subject:Re=3A=20[Enum]=20Neustar=20and=20GSM=20create=20alternate=20ROOT| From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20| Date:Wed,=205=20Oct=202005=2011=3A08=3A20=20+0200| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=UzwKd2x8qim00S04f1uHMNDq+kXxOaXuRNwCBNZELntLKOfG79rxNB7fLRFa9wCYv5QYT/MY s+YDK/bIrtK/iYgFD059UBwK1yLurUshMLdLDVyXbeYuJJh5Cljc04mX96GGtoosP4w80ji8mbJ CXKnPITPXSkg19mTKGsntlY8= Authentication-Results: imail.cisco.com; header.From=paf@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Sep 30, 2005, at 21:23, Stastny Richard wrote: > Dear co-chairs, especially Patrik, > > what is your opiniion on this press release? > Please read RFC 2826 again. 2826 IAB Technical Comment on the Unique DNS Root. Internet Architecture Board. May 2000. (Format: TXT=13400 bytes) (Status: INFORMATIONAL) If someone add one TLD to the root zone, they have created a 2nd root. I don't think any further comments are needed. Patrik > http://www.neustar.com/pressroom/files/announcements/ > ns_pr_09282005.pdf > > GSM Association and NeuStar Sign Agreement to Offer Root DNS > Services to More than 680 Global GSM Mobile Operators > > providing .grps and 3gppnetwork.org as TLD in the GRX network using > public IP addresses. > > I thought the IAB recommended to 3GPP NOT to do this because of > leakage > > Richard > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 05 16:11:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFbf-0000cX-Je; Wed, 05 Oct 2005 16:11:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENBaE-0004AX-JE for enum@megatron.ietf.org; Wed, 05 Oct 2005 11:53:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01572 for ; Wed, 5 Oct 2005 11:53:27 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENBj8-0007p5-6R for enum@ietf.org; Wed, 05 Oct 2005 12:02:43 -0400 Received: from [10.31.32.246] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j95FrmaZ009048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Oct 2005 08:53:49 -0700 Message-ID: <4343F6CC.7070003@shockey.us> Date: Wed, 05 Oct 2005 11:52:44 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [Enum] Its that time again .... Agenda Items for IETF Vancouver X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I currently aware of two new drafts coming through pretty soon. No I do not know what slot we are going to get. One on an ENUM API and a enum registration document for vcard. Obviously we have the recharter issues to deal with when our esteemed AD's respond ot the Chair's proposal etc. Anything else? -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 06 06:49:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENTJH-0007N5-0N; Thu, 06 Oct 2005 06:49:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENTJF-0007N0-Ht for enum@megatron.ietf.org; Thu, 06 Oct 2005 06:49:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23956 for ; Thu, 6 Oct 2005 06:49:06 -0400 (EDT) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENTSJ-0000ym-3p for enum@ietf.org; Thu, 06 Oct 2005 06:58:32 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 7F6CA6FDA9; Thu, 6 Oct 2005 11:49:16 +0100 (BST) In-Reply-To: <4343F6CC.7070003@shockey.us> References: <4343F6CC.7070003@shockey.us> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49D59992-EF65-4104-830D-B0BAC527E64A@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] Its that time again .... Agenda Items for IETF Vancouver Date: Thu, 6 Oct 2005 11:48:26 +0100 To: Richard Shockey X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi There Richard, folks, Fujiwara-san and I will be issuing the updated Experiences draft shortly. From the discussions on (and off) list, I will ALSO be issuing (with Jim Reid) a companion document - this is a "single issue" Standards Track draft mandating EDNS0 support for entities claiming to be involved in ENUM resolution. It will be similar to RFC3226, which did a similar job for entities claiming to support DNSSEC/A6/IPv6/... In principle, one CAN put requirements into an Informational document (as the experiences draft is intended), but it may be simpler to split out the "real" MUSTs into a separate Standards-track document - it is important that this be processed as quickly as possible, so that implementors can incorporate it (potential customers can specify it :). Once that is out, I would greatly appreciate it if the group could think on't, and I would like it if this were to be considered for adoption as a WG draft. (This new "ENUM-EDNS0" draft is the sole reason for the delay in shipping the experiences draft - apologies to all for this). all the best, Lawrence On 5 Oct 2005, at 16:52, Richard Shockey wrote: > I currently aware of two new drafts coming through pretty soon. > > No I do not know what slot we are going to get. > > One on an ENUM API and a enum registration document for vcard. > > Obviously we have the recharter issues to deal with when our > esteemed AD's respond ot the Chair's proposal etc. > > Anything else? > > -- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 06 08:54:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVGt-0006QS-0G; Thu, 06 Oct 2005 08:54:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVGr-0006QJ-Eo for enum@megatron.ietf.org; Thu, 06 Oct 2005 08:54:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00430 for ; Thu, 6 Oct 2005 08:54:47 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENVPw-0006KW-3Q for enum@ietf.org; Thu, 06 Oct 2005 09:04:13 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j96Ct133004019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Oct 2005 05:55:04 -0700 Message-ID: <43451E75.5050000@shockey.us> Date: Thu, 06 Oct 2005 08:54:13 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Mayrhofer Subject: Re: [Enum] Its that time again .... Agenda Items for IETF Vancouver References: <4343F6CC.7070003@shockey.us> <49D59992-EF65-4104-830D-B0BAC527E64A@insensate.co.uk> <43450648.9060200@enum.at> In-Reply-To: <43450648.9060200@enum.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Alexander Mayrhofer wrote: > On 5 Oct 2005, at 16:52, Richard Shockey wrote: > >>> I currently aware of two new drafts coming through pretty soon. >>> >>> No I do not know what slot we are going to get. >>> >>> One on an ENUM API and a enum registration document for vcard. >>> >>> Obviously we have the recharter issues to deal with when our >>> esteemed AD's respond ot the Chair's proposal etc. >>> >>> Anything else? >> > > Richard, > > we're going to update/rename our ENUM validation related documents, as > the working group has agreed to promote them to WG items in Paris. The > following documents are going to be updated (most probably today): > > draft-mayrhofer-enum-validation-arch -> draft-ietf-enum-validation-arch > draft-lendl-enum-validation-token -> draft-ietf-enum-validation-token > draft-ietf-enum-validation-epp (already WG item) > > (given that the esteemed WG chairs approve the file names, of course) > > We have just done minor modifications to those documents - however, > we'd appreciate a short slot to ask for feedback and how to proceed. > sound fine to me ... > cheers > > Alex Mayrhofer > enum.at > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 06 09:03:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVPJ-0000tQ-Hd; Thu, 06 Oct 2005 09:03:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVPG-0000tL-To for enum@megatron.ietf.org; Thu, 06 Oct 2005 09:03:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00961 for ; Thu, 6 Oct 2005 09:03:29 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENVYM-0006h1-I8 for enum@ietf.org; Thu, 06 Oct 2005 09:12:55 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j96D3w9G005031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Oct 2005 06:04:00 -0700 Message-ID: <4345208D.2080805@shockey.us> Date: Thu, 06 Oct 2005 09:03:09 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.8 (+) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: [Enum] [Fwd: I-D ACTION:draft-mayrhofer-enum-vcard-00.txt] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0502181749==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0502181749== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit

-------- Original Message --------
Subject: I-D ACTION:draft-mayrhofer-enum-vcard-00.txt
Date: Wed, 05 Oct 2005 15:50:02 -0400
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: IANA Registration for Enumservice vCard
	Author(s)	: A. Mayrhofer, D. Lindner
	Filename	: draft-mayrhofer-enum-vcard-00.txt
	Pages		: 7
	Date		: 2005-10-5
	
   This memo registers the Enumservice "vCard" using the URI schemes
   "http" and "https" according to the IANA Enumservice registration
   process described in RFC3671.  This Enumservice is to be used to
   refer from an ENUM domain name to the vCard of the entity using the
   corresponding E.164 number.

   Clients may use information gathered from those vCards before, during
   or after inbound or outbound communication takes place.  For example,
   a callee might be presented with the name and association of the
   caller before he picks up the call.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-vcard-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-mayrhofer-enum-vcard-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-mayrhofer-enum-vcard-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--===============0502181749== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0502181749==-- From enum-bounces@ietf.org Thu Oct 06 09:11:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVXI-0002gS-VQ; Thu, 06 Oct 2005 09:11:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVXI-0002gN-8E for enum@megatron.ietf.org; Thu, 06 Oct 2005 09:11:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01513 for ; Thu, 6 Oct 2005 09:11:46 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ENVgN-00073n-3n for enum@ietf.org; Thu, 06 Oct 2005 09:21:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Its that time again .... Agenda Items for IETF Vancouver Date: Thu, 6 Oct 2005 15:12:41 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C45C0@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Its that time again .... Agenda Items for IETF Vancouver Thread-Index: AcXKdcMg6bqDZLPHSNeZVtrkLdlrewAAd7s5 From: "Stastny Richard" To: "Richard Shockey" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >>> Obviously we have the recharter issues to deal with when our=20 >>> esteemed AD's respond ot the Chair's proposal etc. Nevertheless I think we should start to work on the list with the lind-requiremnts draft to move forward at least a bit and have something concrete to discuss in Vancouver =20 Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 06 09:38:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVxV-00034L-Q6; Thu, 06 Oct 2005 09:38:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVxT-00034D-Ty for enum@megatron.ietf.org; Thu, 06 Oct 2005 09:38:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03353 for ; Thu, 6 Oct 2005 09:38:49 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENW6Y-0008LQ-Ug for enum@ietf.org; Thu, 06 Oct 2005 09:48:16 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j96Dd7QZ008453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Oct 2005 06:39:09 -0700 Message-ID: <434528CA.80202@shockey.us> Date: Thu, 06 Oct 2005 09:38:18 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard , "Lind, Steven D, ALABS" , David Meyer , enum@ietf.org Subject: Re: [Enum] Its that time again .... Agenda Items for IETF Vancouver References: <32755D354E6B65498C3BD9FD496C7D462C45C0@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C45C0@oefeg-s04.oefeg.loc> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.4 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0214937326==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0214937326== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Stastny Richard wrote: 
Obviously we have the recharter issues to deal with when our 
esteemed AD's respond ot the Chair's proposal etc.
        

Nevertheless I think we should start to work on the list
with the lind-requiremnts draft to move forward at least
a bit and have something concrete to discuss in Vancouver
Excellent point.  I completely agree.

Some of the issues with the charter have to do with what VOIPEER will propose so the scope issue needs to be narrowly defined. There have been exchanges on that subject. Patrik and I certainly dont see any conflicts with VOIPEER since ENUM is only dealing with the number translation issues.

I'm assuming that VOIPEER will hold a 2nd BOF in Vancouver as well.
-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--===============0214937326== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0214937326==-- From enum-bounces@ietf.org Thu Oct 06 09:58:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWG5-0002QV-9y; Thu, 06 Oct 2005 09:58:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWG3-0002QM-DS for enum@megatron.ietf.org; Thu, 06 Oct 2005 09:58:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04546 for ; Thu, 6 Oct 2005 09:58:01 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENWP8-0000mx-Mw for enum@ietf.org; Thu, 06 Oct 2005 10:07:27 -0400 Received: by zproxy.gmail.com with SMTP id n1so182125nzf for ; Thu, 06 Oct 2005 06:57:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=tkNI/sle7fPmtR0lQkZwxaH7hNYGBancdvK4x+OiBz5QGNyRRsPDq3R2KdX+PO6MVLAhfZjr3wBP9gvr9BlL2bhosdMy3ewDC6jz1EjEVU7atjD2V68l5i8ulP9rVwWTTu0IRn+8uhBhl3uknGJ1YMNpG5vNATkPRSAWoZiwFSs= Received: by 10.36.118.1 with SMTP id q1mr61702nzc; Thu, 06 Oct 2005 06:57:48 -0700 (PDT) Received: by 10.36.46.13 with HTTP; Thu, 6 Oct 2005 06:57:48 -0700 (PDT) Message-ID: Date: Thu, 6 Oct 2005 10:57:48 -0300 From: Voipers Portugal To: enum@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Subject: [Enum] ENUM and E911 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Voipers Portugal List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Can anyone tell me where i can find drafts or RFCs about ENUM and E911? And if anyone here is working on a E911 project, if possible please send me some info. Thanks in advance. Regards, Jose Simoes _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 06 10:02:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWKj-0003FE-TP; Thu, 06 Oct 2005 10:02:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWKh-0003F6-Sg for enum@megatron.ietf.org; Thu, 06 Oct 2005 10:02:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04737 for ; Thu, 6 Oct 2005 10:02:49 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ENWTn-0000yp-1u for enum@ietf.org; Thu, 06 Oct 2005 10:12:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: re: [Enum] Its that time again .... Agenda Items for IETF Vancouver Date: Thu, 6 Oct 2005 16:05:02 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C45C1@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Its that time again .... Agenda Items for IETF Vancouver Thread-Index: AcXKe9GZxMDr1eF3SJmY1yRhKQX2lwAAyC2A From: "Stastny Richard" To: "Richard Shockey" , "Lind, Steven D, ALABS" , "David Meyer" , X-Spam-Score: 0.8 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >I'm assuming that VOIPEER will hold a 2nd BOF in Vancouver as well. Now as you mention it, this is also a good question The voipeer list has gone dead also I needs to be revived Richard ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Do 06.10.2005 15:38 An: Stastny Richard; Lind, Steven D, ALABS; David Meyer; enum@ietf.org Betreff: Re: [Enum] Its that time again .... Agenda Items for IETF = Vancouver Stastny Richard wrote:=20 Obviously we have the recharter issues to deal with when our=20 esteemed AD's respond ot the Chair's proposal etc. =20 Nevertheless I think we should start to work on the list with the lind-requiremnts draft to move forward at least a bit and have something concrete to discuss in Vancouver =20 Excellent point. I completely agree.=20 Some of the issues with the charter have to do with what VOIPEER will = propose so the scope issue needs to be narrowly defined. There have been = exchanges on that subject. Patrik and I certainly dont see any conflicts = with VOIPEER since ENUM is only dealing with the number translation = issues. I'm assuming that VOIPEER will hold a 2nd BOF in Vancouver as well. --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or=20 = =20 ; = =20 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 06 10:06:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWOP-0004wE-Vq; Thu, 06 Oct 2005 10:06:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWOO-0004w9-EL for enum@megatron.ietf.org; Thu, 06 Oct 2005 10:06:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05127 for ; Thu, 6 Oct 2005 10:06:38 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ENWXU-00017b-Jf for enum@ietf.org; Thu, 06 Oct 2005 10:16:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] ENUM and E911 Date: Thu, 6 Oct 2005 16:08:40 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C45C3@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] ENUM and E911 Thread-Index: AcXKfqOR8Dx7kzXyRe6JiBsdwethCAAANCVk From: "Stastny Richard" To: "Voipers Portugal" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org There is none, because ENUM and E911 have nothing to do with each other 911 is not an E.164 number and ENUM is dealing only with E1.64 numbers For E911 you have to look at the drafts of WG ECRIT Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Voipers Portugal Gesendet: Do 06.10.2005 15:57 An: enum@ietf.org Betreff: [Enum] ENUM and E911 Can anyone tell me where i can find drafts or RFCs about ENUM and E911? And if anyone here is working on a E911 project, if possible please send me some info. Thanks in advance. Regards, Jose Simoes _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 06 12:34:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENYhg-0006SK-R6; Thu, 06 Oct 2005 12:34:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENYhe-0006SE-Ok for enum@megatron.ietf.org; Thu, 06 Oct 2005 12:34:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13751 for ; Thu, 6 Oct 2005 12:34:39 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENYql-0007S4-75 for enum@ietf.org; Thu, 06 Oct 2005 12:44:08 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j96GS8cU024061; Thu, 6 Oct 2005 09:28:08 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j96GS7QJ024059; Thu, 6 Oct 2005 09:28:07 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 6 Oct 2005 09:28:07 -0700 From: David Meyer To: Stastny Richard Subject: Re: [Enum] Its that time again .... Agenda Items for IETF Vancouver Message-ID: <20051006162807.GA24030@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D462C45C1@oefeg-s04.oefeg.loc> Mime-Version: 1.0 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C45C1@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "Lind, Steven D, ALABS" , enum@ietf.org, Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1811386885==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1811386885== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 06, 2005 at 04:05:02PM +0200, Stastny Richard wrote: > >I'm assuming that VOIPEER will hold a 2nd BOF in Vancouver as well. >=20 > Now as you mention it, this is also a good question > The voipeer list has gone dead also >=20 > I needs to be revived Definitely, and my fault :-) The list is still there, and I too have been waiting for our ADs to answer up on the chartering question. BTW, I have asked for a 2.5 hr slot for Vancouver.=20 Finally, I have a terminology draft that I'm trying to finish if I can get a few minutes, so that will be input (fodder) for Vancouver.=20 Thanks, Dave --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDRVCXORgD1qCZ2KcRAgTJAKCJFIu2O+LArCqNeyEE3fh1M5NEKwCeJpVv KEFDReldE8nNLzNLLbpz01Y= =ky7H -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- --===============1811386885== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1811386885==-- From enum-bounces@ietf.org Thu Oct 06 13:41:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENZkD-0000GN-2F; Thu, 06 Oct 2005 13:41:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENZkC-0000GI-BQ for enum@megatron.ietf.org; Thu, 06 Oct 2005 13:41:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17349 for ; Thu, 6 Oct 2005 13:41:22 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENZtJ-0001wW-F4 for enum@ietf.org; Thu, 06 Oct 2005 13:50:50 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j96Hfpbm001884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Oct 2005 10:41:53 -0700 Message-ID: <434561AE.3030307@shockey.us> Date: Thu, 06 Oct 2005 13:41:02 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Meyer Subject: Re: [Enum] Its that time again .... Agenda Items for IETF Vancouver References: <32755D354E6B65498C3BD9FD496C7D462C45C1@oefeg-s04.oefeg.loc> <20051006162807.GA24030@1-4-5.net> In-Reply-To: <20051006162807.GA24030@1-4-5.net> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.9 (+) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "Lind, Steven D, ALABS" , enum@ietf.org, Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0036773300==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0036773300== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David Meyer wrote: 
On Thu, Oct 06, 2005 at 04:05:02PM +0200, Stastny Richard wrote:
  
I'm assuming that VOIPEER will hold a 2nd BOF in Vancouver as well.
      
Now as you mention it, this is also a good question
The voipeer list has gone dead also

I needs to be revived
    

	Definitely, and my fault :-) The list is still there, and
	I too have been waiting for our ADs to answer up on the
	chartering question. BTW, I have asked for a 2.5 hr slot
	for Vancouver. 

	Finally, I have a terminology draft that I'm trying to
	finish if I can get a few minutes, so that will be input
	(fodder) for Vancouver.

Hummm ..

What is a carrier ? 

What constitutes peering?

What is truth?

Is there a God?

Dave you have your work cut out for you  :-) 

-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--===============0036773300== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0036773300==-- From enum-bounces@ietf.org Thu Oct 06 13:49:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENZrd-0001Qv-Qk; Thu, 06 Oct 2005 13:49:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENZrc-0001Qi-6d for enum@megatron.ietf.org; Thu, 06 Oct 2005 13:49:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17807 for ; Thu, 6 Oct 2005 13:49:02 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENa0j-0002J8-C8 for enum@ietf.org; Thu, 06 Oct 2005 13:58:30 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j96HjhOb026634; Thu, 6 Oct 2005 10:45:43 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j96Hjggl026633; Thu, 6 Oct 2005 10:45:42 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 6 Oct 2005 10:45:42 -0700 From: David Meyer To: Richard Shockey Subject: Re: [Enum] Its that time again .... Agenda Items for IETF Vancouver Message-ID: <20051006174542.GA26596@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D462C45C1@oefeg-s04.oefeg.loc> <20051006162807.GA24030@1-4-5.net> <434561AE.3030307@shockey.us> Mime-Version: 1.0 In-Reply-To: <434561AE.3030307@shockey.us> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "Lind, Steven D, ALABS" , enum@ietf.org, Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0838036032==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0838036032== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 06, 2005 at 01:41:02PM -0400, Richard Shockey wrote: >=20 > David Meyer wrote: >=20 > On Thu, Oct 06, 2005 at 04:05:02PM +0200, Stastny Richard wrote: > =20 >=20 > I'm assuming that VOIPEER will hold a 2nd BOF in Vancouver as well. > =20 >=20 > Now as you mention it, this is also a good question > The voipeer list has gone dead also >=20 > I needs to be revived > =20 >=20 > Definitely, and my fault :-) The list is still there, and > I too have been waiting for our ADs to answer up on the > chartering question. BTW, I have asked for a 2.5 hr slot > for Vancouver.=20 >=20 > Finally, I have a terminology draft that I'm trying to > finish if I can get a few minutes, so that will be input > (fodder) for Vancouver.=20 >=20 > =20 >=20 > Hummm .. > What is a carrier ? > What constitutes peering? > What is truth? > Is there a God? > Dave you have your work cut out for you :-) That's what I keep hearing :-) Dave --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDRWLGORgD1qCZ2KcRAjjiAJ9cUtMy7TW2SW+0s9bIWbe2gfDLmgCgkRs7 NNWcaBTq9BIwPg3mfhRcXxc= =1QUy -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- --===============0838036032== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0838036032==-- From enum-bounces@ietf.org Thu Oct 06 14:17:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENaJC-0003J6-To; Thu, 06 Oct 2005 14:17:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENaJB-0003Ir-7J for enum@megatron.ietf.org; Thu, 06 Oct 2005 14:17:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20188 for ; Thu, 6 Oct 2005 14:17:31 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ENaSI-0003oU-JU for enum@ietf.org; Thu, 06 Oct 2005 14:27:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Oct 2005 20:20:58 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C45C9@oefeg-s04.oefeg.loc> Thread-Topic: What is a Carrier and who has the right to enter numbers in Carrier ENUM? Thread-Index: AcXKnszNLqhp5BsSR3ijVOhYE79wkAAAMpf7 From: "Stastny Richard" To: "David Meyer" , "Richard Shockey" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: "Lind, Steven D, ALABS" , enum@ietf.org Subject: [Enum] What is a Carrier and who has the right to enter numbers in Carrier ENUM? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org To get the discussion going: =20 I think the answers to these question are the central point of the = definitions in both groups: =20 The answeres are somehow linked, but not necessary the same. =20 Lets start with Carrier ENUM: IMHO an entity should have the right to enter numbers in Carrier ENUM if he has been assigned the number or number range directly from the number assignment authority (NRA for short) for this CC (better wording here needed to cover also global CCs)=20 OR the number is ported by an end-user from such an entity to him =20 Now we have three cases: Case A The above entity is a "carrier" in the sense of a "Carrier-of-Record" (whatever that is) . So the ENUM entry he is providing is pointing to an entry point in his "network" (a SBC) or to a SIP proxy, if he is a "virtual network" provider. This Carrier needs to be able to peer and therefore is a "Carrier" within the scope of voipeer. =20 Case B: The above entity is a company (enterprise) or even an "End-User" = deriving a number from the NRA direct, e.g an 800 number or a coprorate number, but he decides to host the servivce with an above described "Carrier". In this case he decides what is entered in Carrier ENUM, but the entry is pointing to the above described "Carrier". Same result for Voipeer. =20 Case C: The enterprise or end-user is deciding to run their own server and since they are in charge of the Carrier ENUM entry, they enter a pointer to their server in Carrier ENUM. To be able to peer, they also need to be able to participate in the Voipeer club. This case is the most controverry, of course. What are the minimum requirements especially for such "Carriers) =20 It is also interesting in the case C that the company may also decide to enter the same pointer in User ENUM. =20 have phun Richard =20 =20 ________________________________ Von: David Meyer [mailto:dmm@1-4-5.net] Gesendet: Do 06.10.2005 19:45 An: Richard Shockey Cc: Stastny Richard; Lind, Steven D, ALABS; enum@ietf.org Betreff: Re: [Enum] Its that time again .... Agenda Items for IETF = Vancouver On Thu, Oct 06, 2005 at 01:41:02PM -0400, Richard Shockey wrote: > > David Meyer wrote: > > On Thu, Oct 06, 2005 at 04:05:02PM +0200, Stastny Richard wrote: > =20 > > I'm assuming that VOIPEER will hold a 2nd BOF in Vancouver as well. > =20 > > Now as you mention it, this is also a good question > The voipeer list has gone dead also > > I needs to be revived > =20 > > Definitely, and my fault :-) The list is still there, and > I too have been waiting for our ADs to answer up on the > chartering question. BTW, I have asked for a 2.5 hr slot > for Vancouver. > > Finally, I have a terminology draft that I'm trying to > finish if I can get a few minutes, so that will be input > (fodder) for Vancouver. > > =20 > > Hummm .. > What is a carrier ? > What constitutes peering? > What is truth? > Is there a God? > Dave you have your work cut out for you :-) That's what I keep hearing :-) Dave _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 06 14:29:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENaUm-0007nN-1I; Thu, 06 Oct 2005 14:29:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENaUj-0007n4-Nj for enum@megatron.ietf.org; Thu, 06 Oct 2005 14:29:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21143 for ; Thu, 6 Oct 2005 14:29:27 -0400 (EDT) Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ENadm-0004Vh-Hr for enum@ietf.org; Thu, 06 Oct 2005 14:38:56 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-9.tower-124.messagelabs.com!1128623331!5722941!7 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 9521 invoked from network); 6 Oct 2005 18:29:09 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-9.tower-124.messagelabs.com with SMTP; 6 Oct 2005 18:29:09 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 432D90320047D847; Thu, 6 Oct 2005 14:29:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Oct 2005 14:29:07 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0B443842@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [voipeer] What is a Carrier and who has the right to enter numbers in Carrier ENUM? Thread-Index: AcXKnszNLqhp5BsSR3ijVOhYE79wkAAAMpf7AADjBiA= From: "Pfautz, Penn L, NEO" To: "Stastny Richard" , "David Meyer" , "Richard Shockey" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable Cc: "Lind, Steven D, ALABS" , enum@ietf.org Subject: [Enum] RE: [voipeer] What is a Carrier and who has the right to enter numbers in Carrier ENUM? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard: In case B below by "host" I assume you mean that the carrier provides the PSTN point-of-interface for the number. Is this correct? If so, some might suggest that the carrier is still the carrier-of-record and gets to decide about the entry. This moves toward a definition of carrier as the entity that provides the PSTN PoI for a number. What you think? In case C below do you assume the number was directly assigned to the enterprise?=20 Penn -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Stastny Richard Sent: Thursday, October 06, 2005 2:21 PM To: David Meyer; Richard Shockey; voipeer@lists.uoregon.edu Cc: Lind, Steven D, ALABS; enum@ietf.org Subject: [voipeer] What is a Carrier and who has the right to enter numbers in Carrier ENUM? To get the discussion going: =20 I think the answers to these question are the central point of the definitions in both groups: =20 The answeres are somehow linked, but not necessary the same. =20 Lets start with Carrier ENUM: IMHO an entity should have the right to enter numbers in Carrier ENUM if he has been assigned the number or number range directly from the number assignment authority (NRA for short) for this CC (better wording here needed to cover also global CCs)=20 OR the number is ported by an end-user from such an entity to him =20 Now we have three cases: Case A The above entity is a "carrier" in the sense of a "Carrier-of-Record" (whatever that is) . So the ENUM entry he is providing is pointing to an entry point in his "network" (a SBC) or to a SIP proxy, if he is a "virtual network" provider. This Carrier needs to be able to peer and therefore is a "Carrier" within the scope of voipeer. =20 Case B: The above entity is a company (enterprise) or even an "End-User" deriving a number from the NRA direct, e.g an 800 number or a coprorate number, but he decides to host the servivce with an above described "Carrier". In this case he decides what is entered in Carrier ENUM, but the entry is pointing to the above described "Carrier". Same result for Voipeer. =20 Case C: The enterprise or end-user is deciding to run their own server and since they are in charge of the Carrier ENUM entry, they enter a pointer to their server in Carrier ENUM. To be able to peer, they also need to be able to participate in the Voipeer club. This case is the most controverry, of course. What are the minimum requirements especially for such "Carriers) =20 It is also interesting in the case C that the company may also decide to enter the same pointer in User ENUM. =20 have phun Richard =20 =20 ________________________________ Von: David Meyer [mailto:dmm@1-4-5.net] Gesendet: Do 06.10.2005 19:45 An: Richard Shockey Cc: Stastny Richard; Lind, Steven D, ALABS; enum@ietf.org Betreff: Re: [Enum] Its that time again .... Agenda Items for IETF Vancouver On Thu, Oct 06, 2005 at 01:41:02PM -0400, Richard Shockey wrote: > > David Meyer wrote: > > On Thu, Oct 06, 2005 at 04:05:02PM +0200, Stastny Richard wrote: > =20 > > I'm assuming that VOIPEER will hold a 2nd BOF in Vancouver as well. > =20 > > Now as you mention it, this is also a good question > The voipeer list has gone dead also > > I needs to be revived > =20 > > Definitely, and my fault :-) The list is still there, and > I too have been waiting for our ADs to answer up on the > chartering question. BTW, I have asked for a 2.5 hr slot > for Vancouver. > > Finally, I have a terminology draft that I'm trying to > finish if I can get a few minutes, so that will be input > (fodder) for Vancouver. > > =20 > > Hummm .. > What is a carrier ? > What constitutes peering? > What is truth? > Is there a God? > Dave you have your work cut out for you :-) That's what I keep hearing :-) Dave ________________________________________________________________________ _____ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 06 14:45:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENajo-0004b5-Gh; Thu, 06 Oct 2005 14:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENajl-0004Zz-Ou for enum@megatron.ietf.org; Thu, 06 Oct 2005 14:45:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22050 for ; Thu, 6 Oct 2005 14:44:59 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ENasu-0005Hm-7A for enum@ietf.org; Thu, 06 Oct 2005 14:54:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Oct 2005 20:48:37 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C45CA@oefeg-s04.oefeg.loc> Thread-Topic: [voipeer] What is a Carrier and who has the right to enter numbers in Carrier ENUM? Thread-Index: AcXKnszNLqhp5BsSR3ijVOhYE79wkAAAMpf7AADjBiAAAIl/Zg== From: "Stastny Richard" To: "Pfautz, Penn L, NEO" , "David Meyer" , "Richard Shockey" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: quoted-printable Cc: "Lind, Steven D, ALABS" , enum@ietf.org Subject: [Enum] Re: [voipeer] What is a Carrier and who has the right to enter numbers in Carrier ENUM? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org In both cases the numbers are assigned directly =20 The numbers I am talking about here are IN numbers: so the question on the PSTN point of interface is a bit problematic =20 A company eg gets an 800 number (or an 05 number in Austria) and now = decides which carrier should do the (second) IN dip to translate the number to = the real geographic number with his IN-service. The carrier now is the one entered in the IN database for the first IN = dip to route the number. The geonumber now may be with another carrier. =20 Since ENUM is now "bypassing" all this IN dips and no geographic number is required to reach the SIP server of the company (the "Carrier" may = still provide some IN-type time-of-day routing magic, the question of PSTN PoI is not valid. =20 I think that in proctice the carrier still may have the lead and do all = this stuff for the company (as it may also happen in User ENUM) but we are = discussing here the principles. I also beleive that in case B the company and the = carrier have to talk to each oother, at least the carrier has to tel the company = what SIP URU to enter. =20 Richard ________________________________ Von: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] Gesendet: Do 06.10.2005 20:29 An: Stastny Richard; David Meyer; Richard Shockey; = voipeer@lists.uoregon.edu Cc: Lind, Steven D, ALABS; enum@ietf.org Betreff: RE: [voipeer] What is a Carrier and who has the right to enter = numbers in Carrier ENUM? Richard: In case B below by "host" I assume you mean that the carrier provides the PSTN point-of-interface for the number. Is this correct? If so, some might suggest that the carrier is still the carrier-of-record and gets to decide about the entry. This moves toward a definition of carrier as the entity that provides the PSTN PoI for a number. What you think? In case C below do you assume the number was directly assigned to the enterprise? Penn -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Stastny Richard Sent: Thursday, October 06, 2005 2:21 PM To: David Meyer; Richard Shockey; voipeer@lists.uoregon.edu Cc: Lind, Steven D, ALABS; enum@ietf.org Subject: [voipeer] What is a Carrier and who has the right to enter numbers in Carrier ENUM? To get the discussion going: I think the answers to these question are the central point of the definitions in both groups: The answeres are somehow linked, but not necessary the same. Lets start with Carrier ENUM: IMHO an entity should have the right to enter numbers in Carrier ENUM if he has been assigned the number or number range directly from the number assignment authority (NRA for short) for this CC (better wording here needed to cover also global CCs) OR the number is ported by an end-user from such an entity to him Now we have three cases: Case A The above entity is a "carrier" in the sense of a "Carrier-of-Record" (whatever that is) . So the ENUM entry he is providing is pointing to an entry point in his "network" (a SBC) or to a SIP proxy, if he is a "virtual network" provider. This Carrier needs to be able to peer and therefore is a "Carrier" within the scope of voipeer. Case B: The above entity is a company (enterprise) or even an "End-User" deriving a number from the NRA direct, e.g an 800 number or a coprorate number, but he decides to host the servivce with an above described "Carrier". In this case he decides what is entered in Carrier ENUM, but the entry is pointing to the above described "Carrier". Same result for Voipeer. Case C: The enterprise or end-user is deciding to run their own server and since they are in charge of the Carrier ENUM entry, they enter a pointer to their server in Carrier ENUM. To be able to peer, they also need to be able to participate in the Voipeer club. This case is the most controverry, of course. What are the minimum requirements especially for such "Carriers) It is also interesting in the case C that the company may also decide to enter the same pointer in User ENUM. have phun Richard ________________________________ Von: David Meyer [mailto:dmm@1-4-5.net] Gesendet: Do 06.10.2005 19:45 An: Richard Shockey Cc: Stastny Richard; Lind, Steven D, ALABS; enum@ietf.org Betreff: Re: [Enum] Its that time again .... Agenda Items for IETF Vancouver On Thu, Oct 06, 2005 at 01:41:02PM -0400, Richard Shockey wrote: > > David Meyer wrote: > > On Thu, Oct 06, 2005 at 04:05:02PM +0200, Stastny Richard wrote: >=20 > > I'm assuming that VOIPEER will hold a 2nd BOF in Vancouver as well. > =20 > > Now as you mention it, this is also a good question > The voipeer list has gone dead also > > I needs to be revived > =20 > > Definitely, and my fault :-) The list is still there, and > I too have been waiting for our ADs to answer up on the > chartering question. BTW, I have asked for a 2.5 hr slot > for Vancouver. > > Finally, I have a terminology draft that I'm trying to > finish if I can get a few minutes, so that will be input > (fodder) for Vancouver. > >=20 > > Hummm .. > What is a carrier ? > What constitutes peering? > What is truth? > Is there a God? > Dave you have your work cut out for you :-) That's what I keep hearing :-) Dave ________________________________________________________________________ _____ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 06 14:50:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENaon-0006IF-9y; Thu, 06 Oct 2005 14:50:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENaol-0006IA-Rw for enum@megatron.ietf.org; Thu, 06 Oct 2005 14:50:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22219 for ; Thu, 6 Oct 2005 14:50:10 -0400 (EDT) Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ENaxu-0005Q8-Bu for enum@ietf.org; Thu, 06 Oct 2005 14:59:39 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-8.tower-124.messagelabs.com!1128624554!5665883!25 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 19650 invoked from network); 6 Oct 2005 18:50:01 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-8.tower-124.messagelabs.com with SMTP; 6 Oct 2005 18:50:01 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 432D90320047EB64; Thu, 6 Oct 2005 14:50:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Oct 2005 14:49:58 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0B44389E@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [voipeer] What is a Carrier and who has the right to enter numbers in Carrier ENUM? Thread-Index: AcXKnszNLqhp5BsSR3ijVOhYE79wkAAAMpf7AADjBiAAAIl/ZgAAO80Q From: "Pfautz, Penn L, NEO" To: "Stastny Richard" , "David Meyer" , "Richard Shockey" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Cc: "Lind, Steven D, ALABS" , enum@ietf.org Subject: [Enum] RE: [voipeer] What is a Carrier and who has the right to enter numbers in Carrier ENUM? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The IN number question raises interesting questions. The end user direct number assignee certainly has rights to end user ENUM but do they have the carrier ENUM rights? I'm not so sure those don't belong to the hosting carrier. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, October 06, 2005 2:49 PM To: Pfautz, Penn L, NEO; David Meyer; Richard Shockey; voipeer@lists.uoregon.edu Cc: Lind, Steven D, ALABS; enum@ietf.org Subject: Re: [voipeer] What is a Carrier and who has the right to enter numbers in Carrier ENUM? In both cases the numbers are assigned directly =20 The numbers I am talking about here are IN numbers: so the question on the PSTN point of interface is a bit problematic =20 A company eg gets an 800 number (or an 05 number in Austria) and now decides which carrier should do the (second) IN dip to translate the number to the real geographic number with his IN-service. The carrier now is the one entered in the IN database for the first IN dip to route the number. The geonumber now may be with another carrier. =20 Since ENUM is now "bypassing" all this IN dips and no geographic number is required to reach the SIP server of the company (the "Carrier" may still provide some IN-type time-of-day routing magic, the question of PSTN PoI is not valid. =20 I think that in proctice the carrier still may have the lead and do all this stuff for the company (as it may also happen in User ENUM) but we are discussing here the principles. I also beleive that in case B the company and the carrier have to talk to each oother, at least the carrier has to tel the company what SIP URU to enter. =20 Richard ________________________________ Von: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] Gesendet: Do 06.10.2005 20:29 An: Stastny Richard; David Meyer; Richard Shockey; voipeer@lists.uoregon.edu Cc: Lind, Steven D, ALABS; enum@ietf.org Betreff: RE: [voipeer] What is a Carrier and who has the right to enter numbers in Carrier ENUM? Richard: In case B below by "host" I assume you mean that the carrier provides the PSTN point-of-interface for the number. Is this correct? If so, some might suggest that the carrier is still the carrier-of-record and gets to decide about the entry. This moves toward a definition of carrier as the entity that provides the PSTN PoI for a number. What you think? In case C below do you assume the number was directly assigned to the enterprise? Penn -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Stastny Richard Sent: Thursday, October 06, 2005 2:21 PM To: David Meyer; Richard Shockey; voipeer@lists.uoregon.edu Cc: Lind, Steven D, ALABS; enum@ietf.org Subject: [voipeer] What is a Carrier and who has the right to enter numbers in Carrier ENUM? To get the discussion going: I think the answers to these question are the central point of the definitions in both groups: The answeres are somehow linked, but not necessary the same. Lets start with Carrier ENUM: IMHO an entity should have the right to enter numbers in Carrier ENUM if he has been assigned the number or number range directly from the number assignment authority (NRA for short) for this CC (better wording here needed to cover also global CCs) OR the number is ported by an end-user from such an entity to him Now we have three cases: Case A The above entity is a "carrier" in the sense of a "Carrier-of-Record" (whatever that is) . So the ENUM entry he is providing is pointing to an entry point in his "network" (a SBC) or to a SIP proxy, if he is a "virtual network" provider. This Carrier needs to be able to peer and therefore is a "Carrier" within the scope of voipeer. Case B: The above entity is a company (enterprise) or even an "End-User" deriving a number from the NRA direct, e.g an 800 number or a coprorate number, but he decides to host the servivce with an above described "Carrier". In this case he decides what is entered in Carrier ENUM, but the entry is pointing to the above described "Carrier". Same result for Voipeer. Case C: The enterprise or end-user is deciding to run their own server and since they are in charge of the Carrier ENUM entry, they enter a pointer to their server in Carrier ENUM. To be able to peer, they also need to be able to participate in the Voipeer club. This case is the most controverry, of course. What are the minimum requirements especially for such "Carriers) It is also interesting in the case C that the company may also decide to enter the same pointer in User ENUM. have phun Richard [deleted] _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 06 15:25:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENbMp-00007U-6k; Thu, 06 Oct 2005 15:25:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENbMn-00007M-L4 for enum@megatron.ietf.org; Thu, 06 Oct 2005 15:25:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25308 for ; Thu, 6 Oct 2005 15:25:19 -0400 (EDT) From: james.f.baskin@verizon.com Received: from tpamail2.verizon.com ([192.76.82.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENbVu-0006qN-6I for enum@ietf.org; Thu, 06 Oct 2005 15:34:49 -0400 Received: from smtpftw.verizon.com (smtpftw.verizon.com [138.83.130.53]) by tpamail2.verizon.com (8.13.3/8.13.3) with ESMTP id j96JOohv015754; Thu, 6 Oct 2005 15:24:59 -0400 (EDT) Received: from usinftwiccmms03.ent.verizon.com (ftwmms03a.interwan.gte.com [138.83.138.66]) by smtpftw.verizon.com (8.13.3/8.13.3) with ESMTP id j96JOQvn001857; Thu, 6 Oct 2005 14:24:34 -0500 (EST) Received: from 138.83.34.48 by usinftwiccmms03.ent.verizon.com with ESMTP (SMTP Relay); Thu, 06 Oct 2005 15:24:16 -0400 X-Server-Uuid: 2F91DA65-DB13-41BC-8809-D657BCBC59D7 Received: from dwsmtp01.core.verizon.com (dwsmtp01.verizon.com [138.83.35.62]) by coregate2.verizon.com (8.13.3/8.13.3) with ESMTP id j96JOGcT028424; Thu, 6 Oct 2005 14:24:16 -0500 (CDT) To: enum@ietf.org, voipeer@lists.uoregon.edu Subject: Re: [Enum] What is a Carrier and who has the right to enter numbers in Carrier ENUM? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Thu, 6 Oct 2005 15:24:01 -0400 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.5.4HF453 | August 4, 2005) at 10/06/2005 14:24:15, Serialize complete at 10/06/2005 14:24:15 X-WSS-ID: 6F5BA66A4H01138229-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard, I'm not sure if cases B and C are actually "Carrier" ENUM. Maybe I'm being too U.S. centric in my thinking, but I think this applies elsewhere as well. In the U.S., neither subscribers of toll-free ("800") numbers nor other end-users (e.g., enterprises) receive number assignments directly from the "NRA." The North American Numbering Plan Administrator (NANPA) assigns blocks of numbers to carriers who then assign individual numbers or blocks to these users. Thus, there is still a "carrier of record," and we are still dealing with case A. The carrier controls carrier ENUM entries. Any other ENUM entries the subscriber wants to publish would go into end-user ENUM. I believe that the same applies to case C. Where numbers are ported, I take porting to mean the subscriber moving the number from one carrier-of-record to another. The new carrier would be one that also has its own supply of numbers assigned from the NRA. In all of the situations I have described above, the carrier does maintain THE point of interconnection to the PSTN. There can be only one POI for incoming calls from the PSTN to a given number. I there are areas of the world where this carrier-of-record model doesn't apply, please let me know. Maybe an end user can get a number assignment "directly" from an NRA, but doesn't the number come with a default carrier-of-record that maintains the PSTN POI? I'm not suggesting that things could never or should never change, but I think that the concept of a required PSTN POI will be important for quite a few years. Jim Baskin "Stastny Richard" Sent by: enum-bounces@ietf.org 10/06/2005 02:20 PM To: "David Meyer" , "Richard Shockey" , voipeer@lists.uoregon.edu cc: "Lind, Steven D, ALABS" , enum@ietf.org Subject: [Enum] What is a Carrier and who has the right to enter numbers in Carrier ENUM? To get the discussion going: I think the answers to these question are the central point of the definitions in both groups: The answeres are somehow linked, but not necessary the same. Lets start with Carrier ENUM: IMHO an entity should have the right to enter numbers in Carrier ENUM if he has been assigned the number or number range directly from the number assignment authority (NRA for short) for this CC (better wording here needed to cover also global CCs) OR the number is ported by an end-user from such an entity to him Now we have three cases: Case A The above entity is a "carrier" in the sense of a "Carrier-of-Record" (whatever that is) . So the ENUM entry he is providing is pointing to an entry point in his "network" (a SBC) or to a SIP proxy, if he is a "virtual network" provider. This Carrier needs to be able to peer and therefore is a "Carrier" within the scope of voipeer. Case B: The above entity is a company (enterprise) or even an "End-User" deriving a number from the NRA direct, e.g an 800 number or a coprorate number, but he decides to host the servivce with an above described "Carrier". In this case he decides what is entered in Carrier ENUM, but the entry is pointing to the above described "Carrier". Same result for Voipeer. Case C: The enterprise or end-user is deciding to run their own server and since they are in charge of the Carrier ENUM entry, they enter a pointer to their server in Carrier ENUM. To be able to peer, they also need to be able to participate in the Voipeer club. This case is the most controverry, of course. What are the minimum requirements especially for such "Carriers) It is also interesting in the case C that the company may also decide to enter the same pointer in User ENUM. have phun Richard ________________________________ Von: David Meyer [mailto:dmm@1-4-5.net] Gesendet: Do 06.10.2005 19:45 An: Richard Shockey Cc: Stastny Richard; Lind, Steven D, ALABS; enum@ietf.org Betreff: Re: [Enum] Its that time again .... Agenda Items for IETF Vancouver On Thu, Oct 06, 2005 at 01:41:02PM -0400, Richard Shockey wrote: > > David Meyer wrote: > > On Thu, Oct 06, 2005 at 04:05:02PM +0200, Stastny Richard wrote: > > > I'm assuming that VOIPEER will hold a 2nd BOF in Vancouver as well. > > > Now as you mention it, this is also a good question > The voipeer list has gone dead also > > I needs to be revived > > > Definitely, and my fault :-) The list is still there, and > I too have been waiting for our ADs to answer up on the > chartering question. BTW, I have asked for a 2.5 hr slot > for Vancouver. > > Finally, I have a terminology draft that I'm trying to > finish if I can get a few minutes, so that will be input > (fodder) for Vancouver. > > > > Hummm .. > What is a carrier ? > What constitutes peering? > What is truth? > Is there a God? > Dave you have your work cut out for you :-) That's what I keep hearing :-) Dave _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 06 15:50:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENblb-0006zC-8Y; Thu, 06 Oct 2005 15:50:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENbkl-0006XC-9Z; Thu, 06 Oct 2005 15:50:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26708; Thu, 6 Oct 2005 15:50:04 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENbtq-0007uC-Du; Thu, 06 Oct 2005 15:59:31 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ENbkg-0002qQ-8p; Thu, 06 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 06 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-arch-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Validation Architecture Author(s) : A. Mayrhofer, B. Hoeneisen Filename : draft-ietf-enum-validation-arch-00.txt Pages : 16 Date : 2005-10-6 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-validation-arch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-validation-arch-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-6134006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-validation-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-validation-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-6134006.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Thu Oct 06 16:08:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENc31-0006kd-4s; Thu, 06 Oct 2005 16:08:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENc2y-0006dD-SR for enum@megatron.ietf.org; Thu, 06 Oct 2005 16:08:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01685 for ; Thu, 6 Oct 2005 16:08:54 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ENcC4-0001la-V9 for enum@ietf.org; Thu, 06 Oct 2005 16:18:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Oct 2005 22:08:55 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C45CC@oefeg-s04.oefeg.loc> Thread-Topic: [voipeer] What is a Carrier and who has the right to enter numbers in Carrier ENUM? Thread-Index: AcXKnszNLqhp5BsSR3ijVOhYE79wkAAAMpf7AADjBiAAAIl/ZgAAO80QAALj0pU= From: "Stastny Richard" To: "Pfautz, Penn L, NEO" , "David Meyer" , "Richard Shockey" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: quoted-printable Cc: "Lind, Steven D, ALABS" , enum@ietf.org Subject: [Enum] Re: [voipeer] What is a Carrier and who has the right to enter numbers in Carrier ENUM? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I think that is one of the central issues we need to discuss here Richard ________________________________ Von: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] Gesendet: Do 06.10.2005 20:49 An: Stastny Richard; David Meyer; Richard Shockey; = voipeer@lists.uoregon.edu Cc: Lind, Steven D, ALABS; enum@ietf.org Betreff: RE: [voipeer] What is a Carrier and who has the right to enter = numbers in Carrier ENUM? The IN number question raises interesting questions. The end user direct number assignee certainly has rights to end user ENUM but do they have the carrier ENUM rights? I'm not so sure those don't belong to the hosting carrier. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, October 06, 2005 2:49 PM To: Pfautz, Penn L, NEO; David Meyer; Richard Shockey; voipeer@lists.uoregon.edu Cc: Lind, Steven D, ALABS; enum@ietf.org Subject: Re: [voipeer] What is a Carrier and who has the right to enter numbers in Carrier ENUM? In both cases the numbers are assigned directly The numbers I am talking about here are IN numbers: so the question on the PSTN point of interface is a bit problematic A company eg gets an 800 number (or an 05 number in Austria) and now decides which carrier should do the (second) IN dip to translate the number to the real geographic number with his IN-service. The carrier now is the one entered in the IN database for the first IN dip to route the number. The geonumber now may be with another carrier. Since ENUM is now "bypassing" all this IN dips and no geographic number is required to reach the SIP server of the company (the "Carrier" may still provide some IN-type time-of-day routing magic, the question of PSTN PoI is not valid. I think that in proctice the carrier still may have the lead and do all this stuff for the company (as it may also happen in User ENUM) but we are discussing here the principles. I also beleive that in case B the company and the carrier have to talk to each oother, at least the carrier has to tel the company what SIP URU to enter. Richard ________________________________ Von: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] Gesendet: Do 06.10.2005 20:29 An: Stastny Richard; David Meyer; Richard Shockey; voipeer@lists.uoregon.edu Cc: Lind, Steven D, ALABS; enum@ietf.org Betreff: RE: [voipeer] What is a Carrier and who has the right to enter numbers in Carrier ENUM? Richard: In case B below by "host" I assume you mean that the carrier provides the PSTN point-of-interface for the number. Is this correct? If so, some might suggest that the carrier is still the carrier-of-record and gets to decide about the entry. This moves toward a definition of carrier as the entity that provides the PSTN PoI for a number. What you think? In case C below do you assume the number was directly assigned to the enterprise? Penn -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Stastny Richard Sent: Thursday, October 06, 2005 2:21 PM To: David Meyer; Richard Shockey; voipeer@lists.uoregon.edu Cc: Lind, Steven D, ALABS; enum@ietf.org Subject: [voipeer] What is a Carrier and who has the right to enter numbers in Carrier ENUM? To get the discussion going: I think the answers to these question are the central point of the definitions in both groups: The answeres are somehow linked, but not necessary the same. Lets start with Carrier ENUM: IMHO an entity should have the right to enter numbers in Carrier ENUM if he has been assigned the number or number range directly from the number assignment authority (NRA for short) for this CC (better wording here needed to cover also global CCs) OR the number is ported by an end-user from such an entity to him Now we have three cases: Case A The above entity is a "carrier" in the sense of a "Carrier-of-Record" (whatever that is) . So the ENUM entry he is providing is pointing to an entry point in his "network" (a SBC) or to a SIP proxy, if he is a "virtual network" provider. This Carrier needs to be able to peer and therefore is a "Carrier" within the scope of voipeer. Case B: The above entity is a company (enterprise) or even an "End-User" deriving a number from the NRA direct, e.g an 800 number or a coprorate number, but he decides to host the servivce with an above described "Carrier". In this case he decides what is entered in Carrier ENUM, but the entry is pointing to the above described "Carrier". Same result for Voipeer. Case C: The enterprise or end-user is deciding to run their own server and since they are in charge of the Carrier ENUM entry, they enter a pointer to their server in Carrier ENUM. To be able to peer, they also need to be able to participate in the Voipeer club. This case is the most controverry, of course. What are the minimum requirements especially for such "Carriers) It is also interesting in the case C that the company may also decide to enter the same pointer in User ENUM. have phun Richard [deleted] _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 06 16:16:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENcAH-0004F9-DT; Thu, 06 Oct 2005 16:16:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENcAF-0004Eh-Od for enum@megatron.ietf.org; Thu, 06 Oct 2005 16:16:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04726 for ; Thu, 6 Oct 2005 16:16:25 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ENcJN-0002zl-RZ for enum@ietf.org; Thu, 06 Oct 2005 16:25:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] What is a Carrier and who has the right to enternumbers in Carrier ENUM? Date: Thu, 6 Oct 2005 22:16:55 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C45CD@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] What is a Carrier and who has the right to enternumbers in Carrier ENUM? Thread-Index: AcXKrGGgunn9kzNiShKRxgZ5xyBiVQABoQJs From: "Stastny Richard" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org James, =20 >I there are areas of the world where this carrier-of-record model = doesn't >apply, please let me know. Maybe an end user can get a number = assignment >"directly" from an NRA, but doesn't the number come with a default >carrier-of-record that maintains the PSTN POI? I think this is the central question here and it would be nice if some regulators would respond here. There are countries where you get numbers directly, the question is only what is first, the carrier or the user Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von james.f.baskin@verizon.com Gesendet: Do 06.10.2005 21:24 An: enum@ietf.org; voipeer@lists.uoregon.edu Betreff: Re: [Enum] What is a Carrier and who has the right to = enternumbers in Carrier ENUM? Richard, I'm not sure if cases B and C are actually "Carrier" ENUM. Maybe I'm being too U.S. centric in my thinking, but I think this applies = elsewhere as well. In the U.S., neither subscribers of toll-free ("800") numbers nor other end-users (e.g., enterprises) receive number assignments directly from = the "NRA." The North American Numbering Plan Administrator (NANPA) assigns blocks of numbers to carriers who then assign individual numbers or = blocks to these users. Thus, there is still a "carrier of record," and we are still dealing with case A. The carrier controls carrier ENUM entries. = Any other ENUM entries the subscriber wants to publish would go into = end-user ENUM. I believe that the same applies to case C. Where numbers are ported, I take porting to mean the subscriber moving = the number from one carrier-of-record to another. The new carrier would be one that also has its own supply of numbers assigned from the NRA. In = all of the situations I have described above, the carrier does maintain THE point of interconnection to the PSTN. There can be only one POI for incoming calls from the PSTN to a given number. I there are areas of the world where this carrier-of-record model = doesn't apply, please let me know. Maybe an end user can get a number = assignment "directly" from an NRA, but doesn't the number come with a default carrier-of-record that maintains the PSTN POI? I'm not suggesting that things could never or should never change, but I think that the concept of a required PSTN POI will be important for = quite a few years. Jim Baskin "Stastny Richard" Sent by: enum-bounces@ietf.org 10/06/2005 02:20 PM To: "David Meyer" , "Richard Shockey" = , voipeer@lists.uoregon.edu cc: "Lind, Steven D, ALABS" , enum@ietf.org Subject: [Enum] What is a Carrier and who has the right = to enter numbers in Carrier ENUM? To get the discussion going: I think the answers to these question are the central point of the definitions in both groups: The answeres are somehow linked, but not necessary the same. Lets start with Carrier ENUM: IMHO an entity should have the right to enter numbers in Carrier ENUM if he has been assigned the number or number range directly from the number assignment authority (NRA for short) for this CC (better wording here needed to cover also global CCs) OR the number is ported by an end-user from such an entity to him Now we have three cases: Case A The above entity is a "carrier" in the sense of a "Carrier-of-Record" (whatever that is) . So the ENUM entry he is providing is pointing to an entry point in his "network" (a SBC) or to a SIP proxy, if he is a "virtual network" provider. This Carrier needs to be able to peer and therefore is a "Carrier" within the scope of voipeer. Case B: The above entity is a company (enterprise) or even an "End-User" = deriving a number from the NRA direct, e.g an 800 number or a coprorate number, but he decides to host the servivce with an above described "Carrier". In this case he decides what is entered in Carrier ENUM, but the entry is pointing to the above described "Carrier". Same result for Voipeer. Case C: The enterprise or end-user is deciding to run their own server and since they are in charge of the Carrier ENUM entry, they enter a pointer to their server in Carrier ENUM. To be able to peer, they also need to be able to participate in the Voipeer club. This case is the most controverry, of course. What are the minimum requirements especially for such "Carriers) It is also interesting in the case C that the company may also decide to enter the same pointer in User ENUM. have phun Richard ________________________________ Von: David Meyer [mailto:dmm@1-4-5.net] Gesendet: Do 06.10.2005 19:45 An: Richard Shockey Cc: Stastny Richard; Lind, Steven D, ALABS; enum@ietf.org Betreff: Re: [Enum] Its that time again .... Agenda Items for IETF Vancouver On Thu, Oct 06, 2005 at 01:41:02PM -0400, Richard Shockey wrote: > > David Meyer wrote: > > On Thu, Oct 06, 2005 at 04:05:02PM +0200, Stastny Richard wrote: > > > I'm assuming that VOIPEER will hold a 2nd BOF in Vancouver as well. > > > Now as you mention it, this is also a good question > The voipeer list has gone dead also > > I needs to be revived > > > Definitely, and my fault :-) The list is still there, and > I too have been waiting for our ADs to answer up on the > chartering question. BTW, I have asked for a 2.5 hr slot > for Vancouver. > > Finally, I have a terminology draft that I'm trying to > finish if I can get a few minutes, so that will be input > (fodder) for Vancouver. > > > > Hummm .. > What is a carrier ? > What constitutes peering? > What is truth? > Is there a God? > Dave you have your work cut out for you :-) That's what I keep hearing :-) Dave _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 06 19:19:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENf1R-0003Yc-Os; Thu, 06 Oct 2005 19:19:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENf1Q-0003YW-71 for enum@megatron.ietf.org; Thu, 06 Oct 2005 19:19:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26388 for ; Thu, 6 Oct 2005 19:19:28 -0400 (EDT) Received: from twonetom18.sge.net ([152.91.2.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENfAV-00068x-BU for enum@ietf.org; Thu, 06 Oct 2005 19:29:01 -0400 Received: from twonetvs10.sge.net (twonetvs-om [152.91.2.17]) by twonetom18.sge.net (Postfix) with ESMTP id 727A0B347; Fri, 7 Oct 2005 09:19:01 +1000 (EST) Received: from twonetvs10.sge.net (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 44BEF158E5; Fri, 7 Oct 2005 09:19:01 +1000 (EST) Received: from twonetim3.sge.net (twonetim-vs.sge.net [152.91.2.9]) by twonetvs10.sge.net (Postfix) with ESMTP id 2F09515402; Fri, 7 Oct 2005 09:19:01 +1000 (EST) Received: from cletus.lyn.gwy (unknown [152.91.8.11]) by twonetim3.sge.net (Postfix) with ESMTP id 19157A9C9; Fri, 7 Oct 2005 09:19:01 +1000 (EST) Received: from brandine.sge.net (brandine.lyn.gwy [10.1.38.2]) by cletus.lyn.gwy (Postfix) with ESMTP id E906716A3C6; Fri, 7 Oct 2005 09:19:00 +1000 (EST) Received: from acact01marp1 (unknown [165.191.8.15]) by brandine.sge.net (Postfix) with ESMTP id 33D9A237E00; Fri, 7 Oct 2005 09:18:57 +1000 (EST) Received: from ACACT01EXCP1.aca.gov.au (Not Verified[165.191.8.8]) by acact01marp1 with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 07 Oct 2005 09:15:32 +1000 Received: by acact01excp1.aca.gov.au with Internet Mail Service (5.5.2657.72) id <4J77CCSD>; Fri, 7 Oct 2005 09:18:55 +1000 Message-ID: <2C19239EC1F30D459ADAAC7676EE2C7B019CF7E1@acvic01excp1.aca.gov.au> From: Vince Humphries To: "'Stastny Richard'" , james.f.baskin@verizon.com Subject: RE: [voipeer] Re: [Enum] What is a Carrier and who has the right to enternumbers in Carrier ENUM? Date: Fri, 7 Oct 2005 09:18:54 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: enum@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard, James We don't have assignments of numbers directly to end-users in my country (Australia), but I'm aware from my previous job that several European countries -- notably Austria, Germany, the Netherlands and Switzerland -- do make assignments direct to end-users. The types of numbers assigned in this way usually comprise freephone (800), shared cost, premium rate (900) and personal numbers. As far as I'm aware, the assignment is in all these cases made without any carrier-of-record; subsequent to the assignment, it's up to the end-user to arrange for the supply of a service with a chosen carrier in connection with the assigned number. Vince Humphries -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Friday, 7 October 2005 06:17 To: james.f.baskin@verizon.com; enum@ietf.org; voipeer@lists.uoregon.edu Subject: [voipeer] Re: [Enum] What is a Carrier and who has the right to enternumbers in Carrier ENUM? James, >I there are areas of the world where this carrier-of-record model >doesn't apply, please let me know. Maybe an end user can get a number >assignment "directly" from an NRA, but doesn't the number come with a >default carrier-of-record that maintains the PSTN POI? I think this is the central question here and it would be nice if some regulators would respond here. There are countries where you get numbers directly, the question is only what is first, the carrier or the user Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von james.f.baskin@verizon.com Gesendet: Do 06.10.2005 21:24 An: enum@ietf.org; voipeer@lists.uoregon.edu Betreff: Re: [Enum] What is a Carrier and who has the right to enternumbers in Carrier ENUM? Richard, I'm not sure if cases B and C are actually "Carrier" ENUM. Maybe I'm being too U.S. centric in my thinking, but I think this applies elsewhere as well. In the U.S., neither subscribers of toll-free ("800") numbers nor other end-users (e.g., enterprises) receive number assignments directly from the "NRA." The North American Numbering Plan Administrator (NANPA) assigns blocks of numbers to carriers who then assign individual numbers or blocks to these users. Thus, there is still a "carrier of record," and we are still dealing with case A. The carrier controls carrier ENUM entries. Any other ENUM entries the subscriber wants to publish would go into end-user ENUM. I believe that the same applies to case C. Where numbers are ported, I take porting to mean the subscriber moving the number from one carrier-of-record to another. The new carrier would be one that also has its own supply of numbers assigned from the NRA. In all of the situations I have described above, the carrier does maintain THE point of interconnection to the PSTN. There can be only one POI for incoming calls from the PSTN to a given number. I there are areas of the world where this carrier-of-record model doesn't apply, please let me know. Maybe an end user can get a number assignment "directly" from an NRA, but doesn't the number come with a default carrier-of-record that maintains the PSTN POI? I'm not suggesting that things could never or should never change, but I think that the concept of a required PSTN POI will be important for quite a few years. Jim Baskin "Stastny Richard" Sent by: enum-bounces@ietf.org 10/06/2005 02:20 PM To: "David Meyer" , "Richard Shockey" , voipeer@lists.uoregon.edu cc: "Lind, Steven D, ALABS" , enum@ietf.org Subject: [Enum] What is a Carrier and who has the right to enter numbers in Carrier ENUM? To get the discussion going: I think the answers to these question are the central point of the definitions in both groups: The answeres are somehow linked, but not necessary the same. Lets start with Carrier ENUM: IMHO an entity should have the right to enter numbers in Carrier ENUM if he has been assigned the number or number range directly from the number assignment authority (NRA for short) for this CC (better wording here needed to cover also global CCs) OR the number is ported by an end-user from such an entity to him Now we have three cases: Case A The above entity is a "carrier" in the sense of a "Carrier-of-Record" (whatever that is) . So the ENUM entry he is providing is pointing to an entry point in his "network" (a SBC) or to a SIP proxy, if he is a "virtual network" provider. This Carrier needs to be able to peer and therefore is a "Carrier" within the scope of voipeer. Case B: The above entity is a company (enterprise) or even an "End-User" deriving a number from the NRA direct, e.g an 800 number or a coprorate number, but he decides to host the servivce with an above described "Carrier". In this case he decides what is entered in Carrier ENUM, but the entry is pointing to the above described "Carrier". Same result for Voipeer. Case C: The enterprise or end-user is deciding to run their own server and since they are in charge of the Carrier ENUM entry, they enter a pointer to their server in Carrier ENUM. To be able to peer, they also need to be able to participate in the Voipeer club. This case is the most controverry, of course. What are the minimum requirements especially for such "Carriers) It is also interesting in the case C that the company may also decide to enter the same pointer in User ENUM. have phun Richard ________________________________ Von: David Meyer [mailto:dmm@1-4-5.net] Gesendet: Do 06.10.2005 19:45 An: Richard Shockey Cc: Stastny Richard; Lind, Steven D, ALABS; enum@ietf.org Betreff: Re: [Enum] Its that time again .... Agenda Items for IETF Vancouver On Thu, Oct 06, 2005 at 01:41:02PM -0400, Richard Shockey wrote: > > David Meyer wrote: > > On Thu, Oct 06, 2005 at 04:05:02PM +0200, Stastny Richard wrote: > > > I'm assuming that VOIPEER will hold a 2nd BOF in Vancouver as well. > > > Now as you mention it, this is also a good question > The voipeer list has gone dead also > > I needs to be revived > > > Definitely, and my fault :-) The list is still there, and > I too have been waiting for our ADs to answer up on the > chartering question. BTW, I have asked for a 2.5 hr slot > for Vancouver. > > Finally, I have a terminology draft that I'm trying to > finish if I can get a few minutes, so that will be input > (fodder) for Vancouver. > > > > Hummm .. > What is a carrier ? > What constitutes peering? > What is truth? > Is there a God? > Dave you have your work cut out for you :-) That's what I keep hearing :-) Dave _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ____________________________________________________________________________ _ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 07 01:56:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENlDO-0004cT-OK; Fri, 07 Oct 2005 01:56:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENlDM-0004ZF-Nw for enum@megatron.ietf.org; Fri, 07 Oct 2005 01:56:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12313 for ; Fri, 7 Oct 2005 01:56:14 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ENlMa-0004Nv-CP for enum@ietf.org; Fri, 07 Oct 2005 02:05:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [voipeer] Re: [Enum] What is a Carrier and who has the right to enternumbers in Carrier ENUM? Date: Fri, 7 Oct 2005 07:54:54 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C45D1@oefeg-s04.oefeg.loc> Thread-Topic: [voipeer] Re: [Enum] What is a Carrier and who has the right to enternumbers in Carrier ENUM? Thread-Index: AcXKzPmjkDnD0VXHQMWsKteP5MeTZwAAVS9TAA03jcsAAB3KvQ== From: "Stastny Richard" To: X-Spam-Score: 0.8 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Content-Transfer-Encoding: quoted-printable Cc: voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This could be one solution for B and case C? =20 Richard =20 And I have an additional question: =20 >From the responses I got up to now, we should define what a carrier is in carrier ENUM (basically a tool die be used on the Internet) depending on the carriers role and existence on the PSTN (PoI) =20 I do not think that this is a good idea, we should come up with something better =20 Richard ________________________________ Von: Yu, James [mailto:james.yu@neustar.biz] Gesendet: Fr 07.10.2005 01:33 An: Stastny Richard Betreff: Re: [voipeer] Re: [Enum] What is a Carrier and who has the = right to enternumbers in Carrier ENUM? How the phone numbers are assigned is not an issue. So long as there is = a carrier who serves the number, that carrier is the one to = register/provision the data for that phone number in Carrier ENUM. The = end user is not involved. It will be an issue if more than one carriers = can serve the same phone number. James -------------------------- Sent from my BlackBerry Wireless Handheld -----Original Message----- From: enum-bounces@ietf.org To: 'Stastny Richard'; james.f.baskin@verizon.com CC: enum@ietf.org; voipeer@lists.uoregon.edu Sent: Thu Oct 06 19:18:54 2005 Subject: RE: [voipeer] Re: [Enum] What is a Carrier and who has the = right to enternumbers in Carrier ENUM? Richard, James We don't have assignments of numbers directly to end-users in my country (Australia), but I'm aware from my previous job that several European countries -- notably Austria, Germany, the Netherlands and Switzerland = -- do make assignments direct to end-users. The types of numbers assigned in = this way usually comprise freephone (800), shared cost, premium rate (900) = and personal numbers. As far as I'm aware, the assignment is in all these cases made without = any carrier-of-record; subsequent to the assignment, it's up to the end-user = to arrange for the supply of a service with a chosen carrier in connection = with the assigned number. Vince Humphries -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Friday, 7 October 2005 06:17 To: james.f.baskin@verizon.com; enum@ietf.org; voipeer@lists.uoregon.edu Subject: [voipeer] Re: [Enum] What is a Carrier and who has the right to enternumbers in Carrier ENUM? James, >I there are areas of the world where this carrier-of-record model >doesn't apply, please let me know. Maybe an end user can get a number >assignment "directly" from an NRA, but doesn't the number come with a >default carrier-of-record that maintains the PSTN POI? I think this is the central question here and it would be nice if some regulators would respond here. There are countries where you get numbers directly, the question is only what is first, the carrier or the user Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von james.f.baskin@verizon.com Gesendet: Do 06.10.2005 21:24 An: enum@ietf.org; voipeer@lists.uoregon.edu Betreff: Re: [Enum] What is a Carrier and who has the right to = enternumbers in Carrier ENUM? Richard, I'm not sure if cases B and C are actually "Carrier" ENUM. Maybe I'm = being too U.S. centric in my thinking, but I think this applies elsewhere as = well. In the U.S., neither subscribers of toll-free ("800") numbers nor other end-users (e.g., enterprises) receive number assignments directly from = the "NRA." The North American Numbering Plan Administrator (NANPA) assigns blocks of numbers to carriers who then assign individual numbers or = blocks to these users. Thus, there is still a "carrier of record," and we are still dealing with case A. The carrier controls carrier ENUM entries. = Any other ENUM entries the subscriber wants to publish would go into = end-user ENUM. I believe that the same applies to case C. Where numbers are ported, I take porting to mean the subscriber moving = the number from one carrier-of-record to another. The new carrier would be = one that also has its own supply of numbers assigned from the NRA. In all = of the situations I have described above, the carrier does maintain THE = point of interconnection to the PSTN. There can be only one POI for incoming calls from the PSTN to a given number. I there are areas of the world where this carrier-of-record model = doesn't apply, please let me know. Maybe an end user can get a number = assignment "directly" from an NRA, but doesn't the number come with a default carrier-of-record that maintains the PSTN POI? I'm not suggesting that things could never or should never change, but I think that the concept of a required PSTN POI will be important for = quite a few years. Jim Baskin "Stastny Richard" Sent by: enum-bounces@ietf.org 10/06/2005 02:20 PM To: "David Meyer" , "Richard Shockey" , voipeer@lists.uoregon.edu cc: "Lind, Steven D, ALABS" , enum@ietf.org Subject: [Enum] What is a Carrier and who has the right = to enter numbers in Carrier ENUM? To get the discussion going: I think the answers to these question are the central point of the definitions in both groups: The answeres are somehow linked, but not necessary the same. Lets start with Carrier ENUM: IMHO an entity should have the right to enter numbers in Carrier ENUM if = he has been assigned the number or number range directly from the number assignment authority (NRA for short) for this CC (better wording here = needed to cover also global CCs) OR the number is ported by an end-user from = such an entity to him Now we have three cases: Case A The above entity is a "carrier" in the sense of a "Carrier-of-Record" (whatever that is) . So the ENUM entry he is providing is pointing to an entry point in his "network" (a SBC) or to a SIP proxy, if he is a = "virtual network" provider. This Carrier needs to be able to peer and therefore = is a "Carrier" within the scope of voipeer. Case B: The above entity is a company (enterprise) or even an "End-User" = deriving a number from the NRA direct, e.g an 800 number or a coprorate number, but = he decides to host the servivce with an above described "Carrier". In this = case he decides what is entered in Carrier ENUM, but the entry is pointing to = the above described "Carrier". Same result for Voipeer. Case C: The enterprise or end-user is deciding to run their own server and since they are in charge of the Carrier ENUM entry, they enter a pointer to = their server in Carrier ENUM. To be able to peer, they also need to be able to participate in the Voipeer club. This case is the most controverry, of course. What are the minimum requirements especially for such "Carriers) It is also interesting in the case C that the company may also decide to enter the same pointer in User ENUM. have phun Richard ________________________________ Von: David Meyer [mailto:dmm@1-4-5.net] Gesendet: Do 06.10.2005 19:45 An: Richard Shockey Cc: Stastny Richard; Lind, Steven D, ALABS; enum@ietf.org Betreff: Re: [Enum] Its that time again .... Agenda Items for IETF = Vancouver On Thu, Oct 06, 2005 at 01:41:02PM -0400, Richard Shockey wrote: > > David Meyer wrote: > > On Thu, Oct 06, 2005 at 04:05:02PM +0200, Stastny Richard wrote: > > > I'm assuming that VOIPEER will hold a 2nd BOF in Vancouver as well. > > > Now as you mention it, this is also a good question > The voipeer list has gone dead also > > I needs to be revived > > > Definitely, and my fault :-) The list is still there, and > I too have been waiting for our ADs to answer up on the > chartering question. BTW, I have asked for a 2.5 hr slot > for Vancouver. > > Finally, I have a terminology draft that I'm trying to > finish if I can get a few minutes, so that will be input > (fodder) for Vancouver. > > > > Hummm .. > What is a carrier ? > What constitutes peering? > What is truth? > Is there a God? > Dave you have your work cut out for you :-) That's what I keep hearing :-) Dave _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _________________________________________________________________________= ___ _ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 07 02:02:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENlJe-0005oR-Uh; Fri, 07 Oct 2005 02:02:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENlJc-0005ll-3N for enum@megatron.ietf.org; Fri, 07 Oct 2005 02:02:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15247 for ; Fri, 7 Oct 2005 02:02:39 -0400 (EDT) Received: from twonetom19.sge.net ([152.91.2.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENlSl-0004gl-Gr for enum@ietf.org; Fri, 07 Oct 2005 02:12:13 -0400 Received: from twonetvs10.sge.net (twonetvs-om [152.91.2.17]) by twonetom19.sge.net (Postfix) with ESMTP id CDD30B32C; Fri, 7 Oct 2005 16:02:11 +1000 (EST) Received: from twonetvs10.sge.net (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9DE51153F2; Fri, 7 Oct 2005 16:02:11 +1000 (EST) Received: from twonetim3.sge.net (twonetim-vs.sge.net [152.91.2.9]) by twonetvs10.sge.net (Postfix) with ESMTP id 8887F1470D; Fri, 7 Oct 2005 16:02:11 +1000 (EST) Received: from cletus.lyn.gwy (unknown [152.91.8.11]) by twonetim3.sge.net (Postfix) with ESMTP id 76301A9CA; Fri, 7 Oct 2005 16:02:11 +1000 (EST) Received: from brandine.sge.net (brandine.lyn.gwy [10.1.38.2]) by cletus.lyn.gwy (Postfix) with ESMTP id 5579F16A3C6; Fri, 7 Oct 2005 16:02:11 +1000 (EST) Received: from acact01marp1 (unknown [165.191.8.15]) by brandine.sge.net (Postfix) with ESMTP id D9555237E00; Fri, 7 Oct 2005 16:02:08 +1000 (EST) Received: from ACACT01EXCP1.aca.gov.au (Not Verified[165.191.8.8]) by acact01marp1 with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 07 Oct 2005 15:58:43 +1000 Received: by acact01excp1.aca.gov.au with Internet Mail Service (5.5.2657.72) id <4J77CHTY>; Fri, 7 Oct 2005 16:02:07 +1000 Message-ID: <2C19239EC1F30D459ADAAC7676EE2C7B019CF7F0@acvic01excp1.aca.gov.au> From: Vince Humphries To: "'Stastny Richard'" , enum@ietf.org Subject: RE: [voipeer] Re: [Enum] What is a Carrier and who has the right to enternumbers in Carrier ENUM? Date: Fri, 7 Oct 2005 16:02:04 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Cc: voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard I agree, and we need a definition that works in any country. ...Vince Humphries -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Friday, 7 October 2005 15:55 To: enum@ietf.org Cc: voipeer@lists.uoregon.edu Subject: Re: [voipeer] Re: [Enum] What is a Carrier and who has the right to enternumbers in Carrier ENUM? This could be one solution for B and case C? Richard And I have an additional question: >From the responses I got up to now, we should define what a carrier is in carrier ENUM (basically a tool die be used on the Internet) depending on the carriers role and existence on the PSTN (PoI) I do not think that this is a good idea, we should come up with something better Richard ________________________________ Von: Yu, James [mailto:james.yu@neustar.biz] Gesendet: Fr 07.10.2005 01:33 An: Stastny Richard Betreff: Re: [voipeer] Re: [Enum] What is a Carrier and who has the right to enternumbers in Carrier ENUM? How the phone numbers are assigned is not an issue. So long as there is a carrier who serves the number, that carrier is the one to register/provision the data for that phone number in Carrier ENUM. The end user is not involved. It will be an issue if more than one carriers can serve the same phone number. James -------------------------- Sent from my BlackBerry Wireless Handheld -----Original Message----- From: enum-bounces@ietf.org To: 'Stastny Richard'; james.f.baskin@verizon.com CC: enum@ietf.org; voipeer@lists.uoregon.edu Sent: Thu Oct 06 19:18:54 2005 Subject: RE: [voipeer] Re: [Enum] What is a Carrier and who has the right to enternumbers in Carrier ENUM? Richard, James We don't have assignments of numbers directly to end-users in my country (Australia), but I'm aware from my previous job that several European countries -- notably Austria, Germany, the Netherlands and Switzerland -- do make assignments direct to end-users. The types of numbers assigned in this way usually comprise freephone (800), shared cost, premium rate (900) and personal numbers. As far as I'm aware, the assignment is in all these cases made without any carrier-of-record; subsequent to the assignment, it's up to the end-user to arrange for the supply of a service with a chosen carrier in connection with the assigned number. Vince Humphries -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Friday, 7 October 2005 06:17 To: james.f.baskin@verizon.com; enum@ietf.org; voipeer@lists.uoregon.edu Subject: [voipeer] Re: [Enum] What is a Carrier and who has the right to enternumbers in Carrier ENUM? James, >I there are areas of the world where this carrier-of-record model >doesn't apply, please let me know. Maybe an end user can get a number >assignment "directly" from an NRA, but doesn't the number come with a >default carrier-of-record that maintains the PSTN POI? I think this is the central question here and it would be nice if some regulators would respond here. There are countries where you get numbers directly, the question is only what is first, the carrier or the user Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von james.f.baskin@verizon.com Gesendet: Do 06.10.2005 21:24 An: enum@ietf.org; voipeer@lists.uoregon.edu Betreff: Re: [Enum] What is a Carrier and who has the right to enternumbers in Carrier ENUM? Richard, I'm not sure if cases B and C are actually "Carrier" ENUM. Maybe I'm being too U.S. centric in my thinking, but I think this applies elsewhere as well. In the U.S., neither subscribers of toll-free ("800") numbers nor other end-users (e.g., enterprises) receive number assignments directly from the "NRA." The North American Numbering Plan Administrator (NANPA) assigns blocks of numbers to carriers who then assign individual numbers or blocks to these users. Thus, there is still a "carrier of record," and we are still dealing with case A. The carrier controls carrier ENUM entries. Any other ENUM entries the subscriber wants to publish would go into end-user ENUM. I believe that the same applies to case C. Where numbers are ported, I take porting to mean the subscriber moving the number from one carrier-of-record to another. The new carrier would be one that also has its own supply of numbers assigned from the NRA. In all of the situations I have described above, the carrier does maintain THE point of interconnection to the PSTN. There can be only one POI for incoming calls from the PSTN to a given number. I there are areas of the world where this carrier-of-record model doesn't apply, please let me know. Maybe an end user can get a number assignment "directly" from an NRA, but doesn't the number come with a default carrier-of-record that maintains the PSTN POI? I'm not suggesting that things could never or should never change, but I think that the concept of a required PSTN POI will be important for quite a few years. Jim Baskin "Stastny Richard" Sent by: enum-bounces@ietf.org 10/06/2005 02:20 PM To: "David Meyer" , "Richard Shockey" , voipeer@lists.uoregon.edu cc: "Lind, Steven D, ALABS" , enum@ietf.org Subject: [Enum] What is a Carrier and who has the right to enter numbers in Carrier ENUM? To get the discussion going: I think the answers to these question are the central point of the definitions in both groups: The answeres are somehow linked, but not necessary the same. Lets start with Carrier ENUM: IMHO an entity should have the right to enter numbers in Carrier ENUM if he has been assigned the number or number range directly from the number assignment authority (NRA for short) for this CC (better wording here needed to cover also global CCs) OR the number is ported by an end-user from such an entity to him Now we have three cases: Case A The above entity is a "carrier" in the sense of a "Carrier-of-Record" (whatever that is) . So the ENUM entry he is providing is pointing to an entry point in his "network" (a SBC) or to a SIP proxy, if he is a "virtual network" provider. This Carrier needs to be able to peer and therefore is a "Carrier" within the scope of voipeer. Case B: The above entity is a company (enterprise) or even an "End-User" deriving a number from the NRA direct, e.g an 800 number or a coprorate number, but he decides to host the servivce with an above described "Carrier". In this case he decides what is entered in Carrier ENUM, but the entry is pointing to the above described "Carrier". Same result for Voipeer. Case C: The enterprise or end-user is deciding to run their own server and since they are in charge of the Carrier ENUM entry, they enter a pointer to their server in Carrier ENUM. To be able to peer, they also need to be able to participate in the Voipeer club. This case is the most controverry, of course. What are the minimum requirements especially for such "Carriers) It is also interesting in the case C that the company may also decide to enter the same pointer in User ENUM. have phun Richard ________________________________ Von: David Meyer [mailto:dmm@1-4-5.net] Gesendet: Do 06.10.2005 19:45 An: Richard Shockey Cc: Stastny Richard; Lind, Steven D, ALABS; enum@ietf.org Betreff: Re: [Enum] Its that time again .... Agenda Items for IETF Vancouver On Thu, Oct 06, 2005 at 01:41:02PM -0400, Richard Shockey wrote: > > David Meyer wrote: > > On Thu, Oct 06, 2005 at 04:05:02PM +0200, Stastny Richard wrote: > > > I'm assuming that VOIPEER will hold a 2nd BOF in Vancouver as well. > > > Now as you mention it, this is also a good question > The voipeer list has gone dead also > > I needs to be revived > > > Definitely, and my fault :-) The list is still there, and > I too have been waiting for our ADs to answer up on the > chartering question. BTW, I have asked for a 2.5 hr slot > for Vancouver. > > Finally, I have a terminology draft that I'm trying to > finish if I can get a few minutes, so that will be input > (fodder) for Vancouver. > > > > Hummm .. > What is a carrier ? > What constitutes peering? > What is truth? > Is there a God? > Dave you have your work cut out for you :-) That's what I keep hearing :-) Dave _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ____________________________________________________________________________ _ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ____________________________________________________________________________ _ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 07 06:29:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENpUF-0000Wl-2J; Fri, 07 Oct 2005 06:29:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENpTt-0000Ib-3k for enum@megatron.ietf.org; Fri, 07 Oct 2005 06:29:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09302 for ; Fri, 7 Oct 2005 06:29:34 -0400 (EDT) Received: from gw1.domain-registry.nl ([193.176.144.139] helo=gw.domain-registry.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENpd9-0007US-LQ for enum@ietf.org; Fri, 07 Oct 2005 06:39:12 -0400 Received: (from root@localhost) by gw.domain-registry.nl (8.9.3c/8.6.12) id MAA57379; Fri, 7 Oct 2005 12:29:10 +0200 (CEST) Received: by gw1.domain-registry.nl (TUNIX/Firewall SMTP Server) id sma057014; Fri, 7 Oct 05 12:27:52 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [voipeer] Re: [Enum] What is a Carrier and who has the right to enternumbers in Carrier ENUM? Date: Fri, 7 Oct 2005 12:27:52 +0200 Message-ID: <4F9D157E1D347A4E9EBCE02C45FE811001926446@sidn2002000.sidn.nl> Thread-Topic: [voipeer] Re: [Enum] What is a Carrier and who has the right to enternumbers in Carrier ENUM? Thread-Index: AcXKzSqR9geIgdHNQu6MYI8GuHMYEgAULOrA From: "Antoin Verschuren" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Friday, October 07, 2005 1:19 AM Vince Humphries wrote: > As far as I'm aware, the assignment is in all these cases made > without any carrier-of-record; subsequent to the assignment, it's up > to the end-user to arrange for the supply of a service with a chosen > carrier in connection with the assigned number. I can confirm that in NL this is indeed true. Assignments are made directly to end-users that decide they want to keep everything under there own control. The way I see it is that these end-users want to "act" as a carrier. They are usually big enough to have their own pbx, but too small to arrange their own connections and have therefore boarded that part to a real Telco that has access to the PSTN. I see a great similarity to discussions on the IANA function, and who actually has the authority over a delegation or a glue record in the root-zone. I believe that a delegation should be owned by the TLD that is responsible for that domain, but that does not necessarily give him the authority over third party nameserver records that need glue. I think that glue for f.e. ns.ripe.net needs to be maintained by RIPE, and not by a TLD that happens to use that server because they have boarded a secondary nameservice to RIPE. In similarity, I think the assignee of a number range needs to control the delegation of his number range in the carrier enum tree. That the delegation is made -to- a server of a real (third party) PSTN Telco does not change the discussion on who owns the delegation entry. The real (third party) Telco that controls the server should make the peering decisions for that server, but that does not make him the owner of the delegation. He has to be aware that if he offers a service like that, that he is not in control of the delegation, same as he is not in control over the assignment by the NRA. In other words, delegation owner and peering partner are independent, depending on the source or destination of the delegation.=20 Source-> owner of delegation =3D assignee of number range =3D "acting" carrier Destination-> owner of server =3D peering partner I therefore do not agree with James: "How the phone numbers are assigned is not an issue. So long as there is a carrier who serves the number, that carrier is the one to register/provision the data for that phone number in Carrier ENUM. The end user is not involved. It will be an issue if more than one carriers can serve the same phone number." A normal end-user is something different from end-user as assignee of the numberblock. End-user assignees are wanna be carriers with low budget. The NRA does not assign to end-users without a reason. They want to make sure an assignment is carrier independent, and the assignee can keep his assignment when he switches carrier. Making the current "end-carrier" for that assignee the owner of the ENUM delegation will break that concept. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren@sidn.nl W http://www.sidn.nl/ > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, 7 October 2005 06:17 > To: james.f.baskin@verizon.com; enum@ietf.org; > voipeer@lists.uoregon.edu Subject: [voipeer] Re: [Enum] What is a > Carrier and who has the right to enternumbers in Carrier ENUM? >=20 >=20 > James, >=20 >> I there are areas of the world where this carrier-of-record model >> doesn't apply, please let me know. Maybe an end user can get a >> number assignment "directly" from an NRA, but doesn't the number >> come with a default carrier-of-record that maintains the PSTN POI? >=20 > I think this is the central question here and it would be nice if some > regulators would respond here. >=20 > There are countries where you get numbers directly, the question is > only what is first, the carrier or the user >=20 > Richard >=20 >=20 >=20 > ________________________________ >=20 > Von: enum-bounces@ietf.org im Auftrag von james.f.baskin@verizon.com > Gesendet: Do 06.10.2005 21:24 > An: enum@ietf.org; voipeer@lists.uoregon.edu > Betreff: Re: [Enum] What is a Carrier and who has the right to > enternumbers in Carrier ENUM? >=20 >=20 >=20 > Richard, >=20 > I'm not sure if cases B and C are actually "Carrier" ENUM. Maybe I'm > being too U.S. centric in my thinking, but I think this applies > elsewhere as well.=20 >=20 > In the U.S., neither subscribers of toll-free ("800") numbers nor > other end-users (e.g., enterprises) receive number assignments > directly from the "NRA." The North American Numbering Plan > Administrator (NANPA) assigns blocks of numbers to carriers who then > assign individual numbers or blocks to these users. Thus, there is > still a "carrier of record," and we are still dealing with case A.=20 > The carrier controls carrier ENUM entries. Any other ENUM entries the > subscriber wants to publish would go into end-user ENUM. I believe > that the same applies to case C.=20 >=20 > Where numbers are ported, I take porting to mean the subscriber > moving the number from one carrier-of-record to another. The new > carrier would be one that also has its own supply of numbers assigned > from the NRA. In all of the situations I have described above, the > carrier does maintain THE point of interconnection to the PSTN.=20 > There can be only one POI for incoming calls from the PSTN to a given > number.=20 >=20 > I there are areas of the world where this carrier-of-record model > doesn't apply, please let me know. Maybe an end user can get a > number assignment "directly" from an NRA, but doesn't the number come > with a default carrier-of-record that maintains the PSTN POI? >=20 > I'm not suggesting that things could never or should never change, > but I think that the concept of a required PSTN POI will be important > for quite a few years. >=20 > Jim Baskin >=20 >=20 >=20 >=20 >=20 > "Stastny Richard" > Sent by: enum-bounces@ietf.org > 10/06/2005 02:20 PM >=20 >=20 > To: "David Meyer" , "Richard Shockey" > , > voipeer@lists.uoregon.edu > cc: "Lind, Steven D, ALABS" , > enum@ietf.org Subject: [Enum] What is a Carrier and > who has the right to=20 > enter numbers in Carrier > ENUM? >=20 >=20 > To get the discussion going: >=20 > I think the answers to these question are the central point of the > definitions in both groups: >=20 > The answeres are somehow linked, but not necessary the same. >=20 > Lets start with Carrier ENUM: > IMHO an entity should have the right to enter numbers in Carrier ENUM > if he has been assigned the number or number range directly from the > number assignment authority (NRA for short) for this CC (better > wording here needed to cover also global CCs) OR the number is ported > by an end-user from such an entity to him >=20 > Now we have three cases: >=20 > Case A > The above entity is a "carrier" in the sense of a "Carrier-of-Record" > (whatever that is) . So the ENUM entry he is providing is pointing to > an entry point in his "network" (a SBC) or to a SIP proxy, if he is a > "virtual network" provider. This Carrier needs to be able to peer and > therefore is a "Carrier" within the scope of voipeer. >=20 > Case B: > The above entity is a company (enterprise) or even an "End-User" > deriving a number from the NRA direct, e.g an 800 number or a > coprorate number, but he decides to host the servivce with an above > described "Carrier". In this case he decides what is entered in > Carrier ENUM, but the entry is pointing to the above described > "Carrier". Same result for Voipeer.=20 >=20 > Case C: > The enterprise or end-user is deciding to run their own server and > since they are in charge of the Carrier ENUM entry, they enter a > pointer to their server in Carrier ENUM. To be able to peer, they > also need to be able to participate in the Voipeer club. This case is > the most controverry, of course. What are the minimum requirements > especially for such "Carriers)=20 >=20 > It is also interesting in the case C that the company may also decide > to enter the same pointer in User ENUM. >=20 > have phun > Richard >=20 >=20 >=20 > ________________________________ >=20 > Von: David Meyer [mailto:dmm@1-4-5.net] > Gesendet: Do 06.10.2005 19:45 > An: Richard Shockey > Cc: Stastny Richard; Lind, Steven D, ALABS; enum@ietf.org > Betreff: Re: [Enum] Its that time again .... Agenda Items for IETF > Vancouver=20 >=20 >=20 >=20 > On Thu, Oct 06, 2005 at 01:41:02PM -0400, Richard Shockey wrote: >>=20 >> David Meyer wrote: >>=20 >> On Thu, Oct 06, 2005 at 04:05:02PM +0200, Stastny Richard wrote: >>=20 >>=20 >> I'm assuming that VOIPEER will hold a 2nd BOF in Vancouver as well. >>=20 >>=20 >> Now as you mention it, this is also a good question >> The voipeer list has gone dead also >>=20 >> I needs to be revived >>=20 >>=20 >> Definitely, and my fault :-) The list is still there, and >> I too have been waiting for our ADs to answer up on the >> chartering question. BTW, I have asked for a 2.5 hr slot =20 >> for Vancouver.=20 >>=20 >> Finally, I have a terminology draft that I'm trying to >> finish if I can get a few minutes, so that will be input >> (fodder) for Vancouver. >>=20 >>=20 >>=20 >> Hummm .. >> What is a carrier ? >> What constitutes peering? >> What is truth? >> Is there a God? >> Dave you have your work cut out for you :-) >=20 >=20 > That's what I keep hearing :-) >=20 > Dave >=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 >=20 > ________________________________________________________________________ ____ > _ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 07 08:17:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENrAc-00048r-E5; Fri, 07 Oct 2005 08:17:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENrAb-00048j-3C for enum@megatron.ietf.org; Fri, 07 Oct 2005 08:17:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14363 for ; Fri, 7 Oct 2005 08:17:47 -0400 (EDT) Received: from my.nona.net ([193.80.224.122] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENrJr-0003Me-LI for enum@ietf.org; Fri, 07 Oct 2005 08:27:24 -0400 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by kahua with esmtp; Fri, 07 Oct 2005 14:17:14 +0200 id 0001C56F.4346674A.00000AD3 Message-ID: <4346673B.4040703@enum.at> Date: Fri, 07 Oct 2005 14:16:59 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Subject: [Enum] How to provision wildcard NAPTRs using RFC4114? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org All, i'm thinking about options we have regarding provisioning of "carrier" ENUM. Since holding NAPTR records in the registry itself might be one of the options i'm looking at RFC4114, which specifies how to include NAPTR details in EPP requests. Since we have an open numbering plan here in +43-land (which means that the length of a number cannot be derived from the number itself, and may even vary over time when a user decides to change his private numbering plan ;) one of the options to "catch" all extensions of a certain base number would be to use a wildcard NAPTR. However, my impression from RFC4114 is that there's no defined way of transporting wildcard NAPTRs. So, i came up with the following options (namespaces taken from EPP stock RFCs): - add an "*" to the tag: the "eppcom:labelType" would allow this (eg. "*.3.4.5.6.6.e164.arpa") - add an additional "label" tag to each element - would break RFC4114, and would probably be confusing since labels could contain other stuff as well (eg. wildcard and non-wildcard labels). Would probably be a nightmare to implement registry-wise. - and another extension in addition to the RFC4114 extension, which contains just the neccessary "label" tag. I'd appreciate any comments on that issue - i expect other countries to run into this problem as well (hi, bernie ;) cheers alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 07 08:47:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENrdM-0002tz-TY; Fri, 07 Oct 2005 08:47:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENrdL-0002tu-Ru for enum@megatron.ietf.org; Fri, 07 Oct 2005 08:47:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15591 for ; Fri, 7 Oct 2005 08:47:26 -0400 (EDT) Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENrmY-0004Xt-Qj for enum@ietf.org; Fri, 07 Oct 2005 08:57:05 -0400 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j97Cx6M4027675; Fri, 7 Oct 2005 08:59:06 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 08:47:08 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] How to provision wildcard NAPTRs using RFC4114? X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 7 Oct 2005 08:47:16 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07EDD5F1@dul1wnexmb01.vcorp.ad.vrsn.com> Thread-Topic: [Enum] How to provision wildcard NAPTRs using RFC4114? Thread-Index: AcXLOZAR3kK4UX7RSnmEyXthRTEvBgAA0zHA From: "Hollenbeck, Scott" To: "Alexander Mayrhofer" , X-OriginalArrivalTime: 07 Oct 2005 12:47:08.0388 (UTC) FILETIME=[3A716240:01C5CB3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Alexander Mayrhofer > Sent: Friday, October 07, 2005 8:17 AM > To: enum@ietf.org > Subject: [Enum] How to provision wildcard NAPTRs using RFC4114? >=20 > All, >=20 > i'm thinking about options we have regarding provisioning of=20 > "carrier" ENUM.=20 > Since holding NAPTR records in the registry itself might be=20 > one of the=20 > options i'm looking at RFC4114, which specifies how to=20 > include NAPTR details=20 > in EPP requests. >=20 > Since we have an open numbering plan here in +43-land (which=20 > means that the=20 > length of a number cannot be derived from the number itself,=20 > and may even=20 > vary over time when a user decides to change his private=20 > numbering plan ;)=20 > one of the options to "catch" all extensions of a certain=20 > base number would=20 > be to use a wildcard NAPTR. >=20 > However, my impression from RFC4114 is that there's no defined way of=20 > transporting wildcard NAPTRs. So, i came up with the=20 > following options=20 > (namespaces taken from EPP stock RFCs): >=20 > - add an "*" to the tag: the "eppcom:labelType"=20 > would allow=20 > this (eg. "*.3.4.5.6.6.e164.arpa") That's not a problem; the schema allows it now. > - add an additional "label" tag to each element=20 > - would break=20 > RFC4114, and would probably be confusing since labels could=20 > contain other=20 > stuff as well (eg. wildcard and non-wildcard labels). Would=20 > probably be a=20 > nightmare to implement registry-wise. >=20 > - and another extension in addition to the RFC4114 extension,=20 > which contains=20 > just the neccessary "label" tag. I don't understand the additional info you're trying to convey. Can you give me an example? If it's just a wildcard label, you can do that as-is. -Scott- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 07 14:29:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwyM-0006SA-Mz; Fri, 07 Oct 2005 14:29:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwyJ-0006R2-5r for enum@megatron.ietf.org; Fri, 07 Oct 2005 14:29:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04571 for ; Fri, 7 Oct 2005 14:29:29 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENx7e-0002Vx-Bc for enum@ietf.org; Fri, 07 Oct 2005 14:39:10 -0400 Received: from [10.31.13.183] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j97ITwYe009607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Oct 2005 11:30:00 -0700 Message-ID: <4346BE76.3040400@shockey.us> Date: Fri, 07 Oct 2005 14:29:10 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.5 (+) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Subject: [Enum] [Fwd: Internet-Drafts Submission Cutoff Dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1779093016==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1779093016== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit

-------- Original Message --------
Subject: Internet-Drafts Submission Cutoff Dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada
Date: Fri, 07 Oct 2005 00:00:01 -0400
From: ietf-secretariat@ietf.org
To: ietf-announce@ietf.org 


There are two (2) Internet-Draft cutoff dates for the 64th 
IETF Meeting in Vancouver, British Columbia, Canada:

October 17th: Cutoff Date for Initial (i.e., version -00) 
Internet-Draft Submissions 

All initial Internet-Drafts (version -00) must be submitted by Monday, 
October 17th at 9:00 AM ET. As always, all initial submissions with a 
filename beginning with "draft-ietf" must be approved by the 
appropriate WG Chair before they can be processed or announced.  The 
Secretariat would appreciate receiving WG Chair approval by Monday, 
October 10th at 9:00 AM ET.

October 24th: Cutoff Date for Revised (i.e., version -01 and higher) 
Internet-Draft Submissions 

All revised Internet-Drafts (version -01 and higher) must be submitted 
by Monday, October 24th at 9:00 AM ET.

Initial and revised Internet-Drafts received after their respective 
cutoff dates will not be made available in the Internet-Drafts 
directory or announced until on or after Monday, November 7th at 9:00 
AM ET, when Internet-Draft posting resumes.  Please do not wait until 
the last minute to submit.

Thank you for your understanding and cooperation. If you have any 
questions or concerns, then please send a message to 
internet-drafts@ietf.org.

The IETF Secretariat

FYI: The Internet-Draft cutoff dates as well as other significant dates
for the 64th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_64.html.

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



-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--===============1779093016== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1779093016==-- From enum-bounces@ietf.org Sat Oct 08 13:26:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOISe-0003YI-2l; Sat, 08 Oct 2005 13:26:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOISS-0003Qw-PK for enum@megatron.ietf.org; Sat, 08 Oct 2005 13:26:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03163 for ; Sat, 8 Oct 2005 13:26:01 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOIbz-0005gI-31 for enum@ietf.org; Sat, 08 Oct 2005 13:35:56 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j98HQRxV018773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 8 Oct 2005 10:26:32 -0700 Message-ID: <4348010B.3020907@shockey.us> Date: Sat, 08 Oct 2005 13:25:31 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Subject: [Enum] This is notth final agenda .. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org But I know some of you have asked me what the agenda times look like so you can make travel plans. This is not final ... but its looking like Tue PM TUESDAY, November 8, 2005 0800-1800 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Session I APP rui Remote UI BOF INT ipv6 IP Version 6 WG INT monami6 Mobile Nodes and Multiple Interfaces in IPv6 BOF OPS radext Radius Extensions WG RTG mpls MultiProtocol Label Switching WG SEC sasl Simple Authentication and Security Layer WG TSV nfsv4 Network File System Version 4 WG TSV xcon Centralized Conferencing WG 1130-1300 Break 1300-1500 Afternoon Session I APP imapext Internet Message Access Protocol Extension WG INT 16ng IPv6 over IEEE 802.6(e) Network BOF RTG forces Forwarding and Control Element Separation WG RTG idr Inter-Domain Routing WG SEC isms Integrated Security Model for SNMP WG SEC pkix Public-Key Infrastructure (X.509) WG TSV rserpool Reliable Server Pooling WG TSV sip Session Initiation Protocol WG 1510-1710 Afternoon Session II GEN edu EduTeam General Meeting INT mip4 Mobility for IPv4 WG OPS dnsop Domain Name System Operations WG RTG gels GMPLS Controlled Ethernet Label Switching BOF RTG ospf Open Shortest Path First IGP WG SEC tls Transport Layer Security WG TSV behave Behavior Engineering for Hindrance Avoidance WG TSV dccp Datagram Congestion Control Protocol WG 1710-1740 Afternoon Refreshment Break - 1740-1840 Afternoon Session III APP crisp Cross Registry Information Service Protocol WG INT dhc Dynamic Host Configuration WG INT pana Protocol for Carrying Authenticaion for Network Access WG IRTF mobopts IP Mobility Optimizations RG OPS imss Internet and Management Support for Storage WG RTG rtgwg Routing Area WG SEC pki4ipsec Profiling Use of PKI in IPSEC WG TSV enum Telephone Number Mapping WG -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Oct 08 16:12:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOL32-0002jS-PQ; Sat, 08 Oct 2005 16:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOL2z-0002ir-Qq for enum@megatron.ietf.org; Sat, 08 Oct 2005 16:11:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11026 for ; Sat, 8 Oct 2005 16:11:55 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOLCX-0001AM-Ld for enum@ietf.org; Sat, 08 Oct 2005 16:21:51 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j98KBpfX030485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Oct 2005 13:12:07 -0700 Message-ID: <434827B4.9070203@shockey.us> Date: Sat, 08 Oct 2005 16:10:28 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antoin Verschuren References: <4F9D157E1D347A4E9EBCE02C45FE811001926446@sidn2002000.sidn.nl> In-Reply-To: <4F9D157E1D347A4E9EBCE02C45FE811001926446@sidn2002000.sidn.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, voipeer@lists.uoregon.edu Subject: [Enum] My personal definitions X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Peering : The negotiation of reciprocal interconnection arrangements, settlement-free or otherwise, between operationally independent service providers. Carrier: A service provider authorized to issue E.164 numbers for the provisioning of PSTN service under the authority of a National Regulatory Authority (NRA). -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Oct 08 21:31:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOQ2f-0001JE-Oo; Sat, 08 Oct 2005 21:31:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOQ2d-0001J6-EY for enum@megatron.ietf.org; Sat, 08 Oct 2005 21:31:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23776 for ; Sat, 8 Oct 2005 21:31:53 -0400 (EDT) Received: from bay103-f4.bay103.hotmail.com ([65.54.174.14] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOQCE-0007yh-VZ for enum@ietf.org; Sat, 08 Oct 2005 21:41:51 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 8 Oct 2005 18:31:45 -0700 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Sun, 09 Oct 2005 01:31:44 GMT X-Originating-IP: [69.239.153.253] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <434827B4.9070203@shockey.us> From: "Peter Williams" To: richard@shockey.us Subject: RE: [Enum] My personal definitions Date: Sat, 08 Oct 2005 18:31:44 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 09 Oct 2005 01:31:45.0425 (UTC) FILETIME=[35B37010:01C5CC71] X-Spam-Score: 1.5 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org We have learned that, for open numbering plans in certain portions of the Internet that certain PBX operators can "issue" E.164 numbers, without the authority of NRAs - even though the root naming context which they control may have been authorized, and authorized to issue E.164 numbers to PBX terminals or switches. Under your definition, this class of operator is not a "Carrier", despite the numbers that they issue being PSTN routable, and callable. Now, the IETF question: is Carrier ENUM standard to address such operators, or only Big-C Carriers? My expectation was that IETF standards pertain to any operator, acting in the "capacity" of a carrier - whether or not it is regulatedas a Big C Carrier. Compliance to our technical standards does not imply that one is a part of some national regulatory regime: merely that protocols and procedures are correct. Now, if NRA-authorized Carriers are prevented - by national regulatotion - from peering with non-NRA authorized Carriers, that is a proper matter for regulators (tho. not IETF, or IAB, or US govt sponsorship of IAB members. or thier regulatory bodies (ICANN etc)_). The technical standards must not enforce any particular regulatory model, e.g. that of the US govt policy. There should, however, be good evidence that they support the commonest regulatory models, obviously, as a metric of technical adequacy. If we consider the ISO tradition on this matter, X.500 addressed the technical standards on a distributed name service for public names and address, provisioned by individuals, PRMDs, and ADMDs. The F.500 variants address the PTSN model, for ADMD operating under national regulations and licneses. In our Ihistorical ETF tradition, dealing with public addressing policy in the Interent sphere, we have only ever previous address the X.500 _technology_ protocols: never the F.500 series regulatory practices designed for regulated "Carriers" acting as tariffed ADMDs. We should be clear in the revised charter, for Carrier ENUM, that the protocols do not enforce any particular model of operational regulation, and that peering regulation (if any) is a matter for national authorities. Peter. >From: Richard Shockey >To: Antoin Verschuren >CC: enum@ietf.org, voipeer@lists.uoregon.edu >Subject: [Enum] My personal definitions >Date: Sat, 08 Oct 2005 16:10:28 -0400 > > >Peering : The negotiation of reciprocal interconnection arrangements, >settlement-free or otherwise, between operationally independent service >providers. > >Carrier: A service provider authorized to issue E.164 numbers for the >provisioning of PSTN service under the authority of a National Regulatory >Authority (NRA). > >-- > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey, Director - Member of Technical Staff >NeuStar Inc. >46000 Center Oak Plaza - Sterling, VA 20166 >sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >ENUM +87810-13313-31331 >PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >Fax: +1 815.333.1237 > or > ; ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Oct 09 02:42:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOUso-0006nj-OF; Sun, 09 Oct 2005 02:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOUsm-0006nb-8S for enum@megatron.ietf.org; Sun, 09 Oct 2005 02:42:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29555 for ; Sun, 9 Oct 2005 02:42:03 -0400 (EDT) Received: from sip.mah.priv.at ([81.223.16.194] helo=www.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOV2P-0005uu-D9 for enum@ietf.org; Sun, 09 Oct 2005 02:52:02 -0400 Received: from localhost ([127.0.0.1] helo=mah9.inode.at) by www.mah.priv.at with esmtp (Exim 3.36 #1 (Debian)) id 1EOUpF-0004th-00; Sun, 09 Oct 2005 08:38:26 +0200 Message-Id: <6.2.5.6.2.20051009081128.05d23bf8@inode.at> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 09 Oct 2005 08:38:22 +0200 To: "Peter Williams" , richard@shockey.us From: Michael Haberler Subject: RE: [Enum] My personal definitions In-Reply-To: References: <434827B4.9070203@shockey.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-56D9640C X-Spam-Score: 0.8 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org At 03:31 09.10.2005, Peter Williams wrote: >We have learned that, for open numbering plans in certain portions >of the Internet that certain PBX operators can "issue" E.164 >numbers, without the authority of NRAs - even though the root naming >context which they control may have been authorized, and authorized >to issue E.164 numbers to PBX terminals or switches. Allocating a variable-length DDI extension suffixed to a PBX pilot number IMO does not constitute a "number allocation process" and consequently I dont think this process makes a PBX owner a "carrier" for what it's worth. The pilot number still trickles down the usual process NRA->Carrier->PBX owner, at least for geographic numbers over here. The more interesting case are those numbers which are directly allocated to users, like corporate network numbers in Austria (05xxxy) or 800 numbers. As a free-floating number with no carrier to route it is pretty useless, users still turn around and contract a carrier to route it. That entity becomes the carrier-of-record, albeit in a different way. The Shockey Carrier definition still holds in both cases. I do expect though that the distinction between carriers and users will blur over time, just as happend on the Internet where at some point in time a primary attribute of an ISP was "owns an AS number" (that lost its distinguishing factor), and it might be useful to think about likely transition scenarios beforehand. -Michael >Under your definition, this class of operator is not a "Carrier", >despite the numbers that they issue being PSTN routable, and callable. > >Now, the IETF question: is Carrier ENUM standard to address such >operators, or only Big-C Carriers? > >My expectation was that IETF standards pertain to any operator, >acting in the "capacity" of a carrier - whether or not it is >regulatedas a Big C Carrier. Compliance to our technical standards >does not imply that one is a part of some national regulatory >regime: merely that protocols and procedures are correct. > >Now, if NRA-authorized Carriers are prevented - by national >regulatotion - from peering with non-NRA authorized Carriers, that >is a proper matter for regulators (tho. not IETF, or IAB, or US >govt sponsorship of IAB members. or thier regulatory bodies (ICANN >etc)_). The technical standards must not enforce any particular >regulatory model, e.g. that of the US govt policy. There should, >however, be good evidence that they support the commonest regulatory >models, obviously, as a metric of technical adequacy. > >If we consider the ISO tradition on this matter, X.500 addressed the >technical standards on a distributed name service for public names >and address, provisioned by individuals, PRMDs, and ADMDs. The F.500 >variants address the PTSN model, for ADMD operating under national >regulations and licneses. In our Ihistorical ETF tradition, dealing >with public addressing policy in the Interent sphere, we have only >ever previous address the X.500 _technology_ protocols: never the >F.500 series regulatory practices designed for regulated "Carriers" >acting as tariffed ADMDs. > >We should be clear in the revised charter, for Carrier ENUM, that >the protocols do not enforce any particular model of operational >regulation, and that peering regulation (if any) is a matter for >national authorities. > > >Peter. > > >>From: Richard Shockey >>To: Antoin Verschuren >>CC: enum@ietf.org, voipeer@lists.uoregon.edu >>Subject: [Enum] My personal definitions >>Date: Sat, 08 Oct 2005 16:10:28 -0400 >> >> >>Peering : The negotiation of reciprocal interconnection >>arrangements, settlement-free or otherwise, between operationally >>independent service providers. >> >>Carrier: A service provider authorized to issue E.164 numbers for >>the provisioning of PSTN service under the authority of a National >>Regulatory Authority (NRA). >> >>-- >> >> >>Richard Shockey, Director - Member of Technical Staff >>NeuStar Inc. >>46000 Center Oak Plaza - Sterling, VA 20166 >>sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >>ENUM +87810-13313-31331 >>PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >>Fax: +1 815.333.1237 >> or >> ; >><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> >> >>_______________________________________________ >>enum mailing list >>enum@ietf.org >>https://www1.ietf.org/mailman/listinfo/enum > > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Oct 09 11:31:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOd9C-0001Z6-GN; Sun, 09 Oct 2005 11:31:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOd9A-0001Xh-Uw for enum@megatron.ietf.org; Sun, 09 Oct 2005 11:31:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23310 for ; Sun, 9 Oct 2005 11:31:29 -0400 (EDT) Received: from bay103-f16.bay103.hotmail.com ([65.54.174.26] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOdIs-0006cX-2s for enum@ietf.org; Sun, 09 Oct 2005 11:41:34 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 9 Oct 2005 08:31:21 -0700 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Sun, 09 Oct 2005 15:31:20 GMT X-Originating-IP: [69.239.153.253] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <6.2.5.6.2.20051009081128.05d23bf8@inode.at> From: "Peter Williams" To: mah@inode.at Subject: RE: [Enum] My personal definitions Date: Sun, 09 Oct 2005 08:31:20 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 09 Oct 2005 15:31:21.0007 (UTC) FILETIME=[7FE33BF0:01C5CCE6] X-Spam-Score: 0.8 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org "As a free-floating number with no carrier >to route it is pretty useless, users still turn around and contract a >carrier to route it. That entity becomes the carrier-of-record, albeit in a >different way." ... >I do expect though that the distinction between carriers and users will >blur over time, just as happend on the Internet where at some point in time >a primary attribute of an ISP was "owns an AS number" (that lost its >distinguishing factor), and it might be useful to think about likely >transition scenarios beforehand. So lets followup the "beforehand", go one setp further in my original scenario, and address how useless the scenario is, or, is not. Lets consider the wider convegence implications, give we are in charter definition mode. We are beyond, I'd advocate, arguing whether Internet/PSTN "convergence" should or should not address Carrier Enum models. The Interent network admin/mgt culture CAN cope with Carrier ENUM, and retain its traditions through the convergence. For my part, I worry not about Carrier ENUM, per se; its just a provisioning/administration model, and peering/settlement model. We already coped with this culture clash at the packet and email level, for years. What matters now for understanding convergece , post the Carrier ENUM debate, is to understand is "who regulates the multi-protocol capable PBXs", and is there _ever_ any direct regulation of such parties, in _Internet_ culture? ---- We know that the PBX operator (using multi protocol stack equipment) decides (based on "cost point analysis") whether to switch the call over the PSTN, or an alternative protocol stack. For example, creating an H.323 conference capability for a PBX community, the operator of IOS equipment (say) might configure the virtual interfaces to always route packets to a particular IP address (of the centralized H.323 gateway of a multi-national corporation), rather than allow the conference to bridge the terminals directly over the national PSTN interfaces also built into the router/switch, during the Carrier's installation of the equipment. Who decides that this multi-stack config (for a given public address) is a regulated/authorized configuration? The Carrier, the NRA, the professional society of sys. admins? the Interent user? Traditionally, we have said, its the Internet user! Any determined leaf can become a node in an small i internet network. The Internet is only (culturally) a network of small i IP-capable networks, after all. Technically, of course its the PBX that decides which protocol stack to use when switcing connects - of course. Does Carrier ENUM decide it? No. (Carrier ENUM - being about PSTN, and regulated peering and automatic provisioning of directory entries - knows nothing of this local PBX config, which has the opportunity to "bypass" the regulation zone, FOR public numbers.) Does the user know about it? No. (We hope not. They just want to do the conference and whiteboard, not worry about cost or regulation. They may set a security requirement option, tho; inserting their CIK into their secure terminal however, to signal the confidentiality expectation for both end-end and switch-based security countermeasures.) Does the user expect to use a single terminal id, for both PSTN conference and non PSTN conferences? Yes.(The user doesnt given a damn about protocol translation by PBXs, and expects to say, "conference me in at 1300H, at +49 123 1234 X4321; Ill have my camera on, folks!" User doesnt know - or care - that some bridge participants are PSTN-based or on the local Ethernet.) Does the user expect to have ther PSTN carrier suitably register "conference over PSTN bearers, routing info and security infos" in their public ENUM entry, provisioned by the Carrier? Yes. Does the user expect that such Carrier ENUM registration means that only "Carrier-based conference bridge" services will ever be used? No and Yes. (Its a question of user education, about handling cost and requiring security. Does the user expect a conference with a person in the same multi-national company (with a nationwide private IP network) to use the PSTN switching? No. "Thats private and "internal!" clearly!") Does the user "presume/expect" the autonmous PBX operator to enforce the same regulations as required for PSTN switched connects - on the connects "carried" over non PSTN-transports? No. Could a national authority make it unlawful to run PBXs (i.e. small i internets with an MS Win2003 box) that have non PSTN-based peering agreements (and regulation practices), when switching numbers that are also PSTN callable? Yes. Why would a national authority do this? to avoid the potential of users avoiding the lawful covert wiretap. Conclusion: As we re-engineer the WG charter (or, more impertinantly, while we wait for ADs and IAB to negotiate with the US national security authorities over the issue), we must address the next generation convergence question that comes up, post Carrier ENUM: Are we going to let IETF technical standards processes faciliate national regulatory control over whether or not PBXs can switch calls/conferences, nominally setup between two public numbers, over _non_ PSTN channels? Put it another way: does "convergence" from ENUM WG mean: the Internet is subsumed into the PSTN, as just another transport configuration - because any and all switches that are _connected_ to the PSTN are now to be _regulated_ by the PSTN, in _all_ their possible behaviours? I suspect, presumptively, that Richard's answer would be, on behalf of the co-chairs: Yes. The Internet is just a transport layer, finally to be regulated by the PSTN. And, thats the change we are here to bring about (politically), before we (the regulatory community and its outsourcing contractors) lose the ability to wiretap voice. Peter. >From: Michael Haberler >To: "Peter Williams" ,richard@shockey.us >CC: enum@ietf.org >Subject: RE: [Enum] My personal definitions >Date: Sun, 09 Oct 2005 08:38:22 +0200 > >At 03:31 09.10.2005, Peter Williams wrote: > >>We have learned that, for open numbering plans in certain portions of the >>Internet that certain PBX operators can "issue" E.164 numbers, without the >>authority of NRAs - even though the root naming context which they control >>may have been authorized, and authorized to issue E.164 numbers to PBX >>terminals or switches. > >Allocating a variable-length DDI extension suffixed to a PBX pilot number >IMO does not constitute a "number allocation process" and consequently I >dont think this process makes a PBX owner a "carrier" for what it's worth. >The pilot number still trickles down the usual process NRA->Carrier->PBX >owner, at least for geographic numbers over here. > >The more interesting case are those numbers which are directly allocated to >users, like corporate network numbers in Austria (05xxxy) or 800 numbers. >As a free-floating number with no carrier to route it is pretty useless, >users still turn around and contract a carrier to route it. That entity >becomes the carrier-of-record, albeit in a different way. > >The Shockey Carrier definition still holds in both cases. > >I do expect though that the distinction between carriers and users will >blur over time, just as happend on the Internet where at some point in time >a primary attribute of an ISP was "owns an AS number" (that lost its >distinguishing factor), and it might be useful to think about likely >transition scenarios beforehand. > > >-Michael > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 10 04:11:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOslI-00018c-7v; Mon, 10 Oct 2005 04:11:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOslF-00018N-B0 for enum@megatron.ietf.org; Mon, 10 Oct 2005 04:11:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23841 for ; Mon, 10 Oct 2005 04:11:51 -0400 (EDT) Received: from bm.firsthand.net ([80.68.91.165] helo=plesktest.vm.bytemark.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOsuy-0005Cu-Sf for enum@ietf.org; Mon, 10 Oct 2005 04:22:05 -0400 Received: (qmail 27153 invoked from network); 10 Oct 2005 10:17:10 +0100 Received: from unknown (HELO ?81.6.214.204?) (81.6.214.204) by bm.firsthand.net with SMTP; 10 Oct 2005 10:17:10 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4D88C6FF-FC66-47B1-B0A4-9477B4D4CB39@firsthand.net> Content-Transfer-Encoding: 7bit From: Christian de Larrinaga Subject: Re: [Enum] My personal definitions Date: Mon, 10 Oct 2005 08:53:37 +0100 To: "Peter Williams" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, richard@shockey.us X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org yes this is about provisioning capability not authorisation. Christian de Larrinaga cdel@firsthand.net > > We should be clear in the revised charter, for Carrier ENUM, that > the protocols do not enforce any particular model of operational > regulation, and that peering regulation (if any) is a matter for > national authorities. > > > Peter. > > > >> From: Richard Shockey >> To: Antoin Verschuren >> CC: enum@ietf.org, voipeer@lists.uoregon.edu >> Subject: [Enum] My personal definitions >> Date: Sat, 08 Oct 2005 16:10:28 -0400 >> >> >> Peering : The negotiation of reciprocal interconnection >> arrangements, settlement-free or otherwise, between operationally >> independent service providers. >> >> Carrier: A service provider authorized to issue E.164 numbers for >> the provisioning of PSTN service under the authority of a National >> Regulatory Authority (NRA). >> >> -- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 10 06:41:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOv5s-0006v5-Td; Mon, 10 Oct 2005 06:41:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOv5q-0006ur-QD for enum@megatron.ietf.org; Mon, 10 Oct 2005 06:41:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00520 for ; Mon, 10 Oct 2005 06:41:15 -0400 (EDT) Received: from mail.ficora.fi ([194.100.96.25] helo=portti1.ficora.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOvFi-0000V4-3T for enum@ietf.org; Mon, 10 Oct 2005 06:51:31 -0400 Received: from POSTI.laru.local ([10.1.0.10]) by portti1.ficora.fi with InterScan Messaging Security Suite; Mon, 10 Oct 2005 13:47:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] My personal definitions Date: Mon, 10 Oct 2005 13:41:08 +0300 Message-ID: <07BC6C0D40216E44A34BE6701694FE86018627DC@POSTI.laru.local> Thread-Topic: [Enum] My personal definitions Thread-Index: AcXMnM9KrbdWDX3jRWykCS53OKl7iQA5dn2g From: "Nieminen Klaus" To: X-Spam-Score: 0.8 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Michael, >> Carrier: A service provider authorized to issue E.164 numbers for the provisioning of PSTN service under the=20 >> authority of a National Regulatory Authority (NRA). > > The more interesting case are those numbers which are directly allocated to users, like corporate network=20 > numbers in Austria (05xxxy) or 800 numbers. As a free-floating number with no carrier to route it is pretty=20 > useless, users still turn around and contract a carrier to route it. That entity becomes the carrier-of-record,=20 > albeit in a different way. > > The Shockey Carrier definition still holds in both cases. Does it hold? In my understanding a carrier could provide PSTN interconnection without being authorized to issue E.164 numbers? I have two examples: 1. A service provider does not issue E.164 numbers, because users are only allowed to port their existing numbers into the service 2. NRA starts issuing ENUM-only numbers directly to users=20 I think Michael's point of view seems to be reasonable, but should we then modify the carrier definition? My own suggestion: Carrier: A service provider providing PTSN access to the user. regards, - Klaus - -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Michael Haberler Sent: 9. lokakuuta 2005 9:38 To: Peter Williams; richard@shockey.us Cc: enum@ietf.org Subject: RE: [Enum] My personal definitions At 03:31 09.10.2005, Peter Williams wrote: >We have learned that, for open numbering plans in certain portions of=20 >the Internet that certain PBX operators can "issue" E.164 numbers,=20 >without the authority of NRAs - even though the root naming context=20 >which they control may have been authorized, and authorized to issue=20 >E.164 numbers to PBX terminals or switches. Allocating a variable-length DDI extension suffixed to a PBX pilot number IMO does not constitute a "number allocation process" and consequently I dont think this process makes a PBX owner a "carrier"=20 for what it's worth. The pilot number still trickles down the usual process NRA->Carrier->PBX owner, at least for geographic numbers over here. The more interesting case are those numbers which are directly allocated to users, like corporate network numbers in Austria (05xxxy) or 800 numbers. As a free-floating number with no carrier to route it is pretty useless, users still turn around and contract a carrier to route it. That entity becomes the carrier-of-record, albeit in a different way. The Shockey Carrier definition still holds in both cases. I do expect though that the distinction between carriers and users will blur over time, just as happend on the Internet where at some point in time a primary attribute of an ISP was "owns an AS number"=20 (that lost its distinguishing factor), and it might be useful to think about likely transition scenarios beforehand. -Michael >Under your definition, this class of operator is not a "Carrier",=20 >despite the numbers that they issue being PSTN routable, and callable. > >Now, the IETF question: is Carrier ENUM standard to address such=20 >operators, or only Big-C Carriers? > >My expectation was that IETF standards pertain to any operator, acting=20 >in the "capacity" of a carrier - whether or not it is regulatedas a Big >C Carrier. Compliance to our technical standards does not imply that=20 >one is a part of some national regulatory >regime: merely that protocols and procedures are correct. > >Now, if NRA-authorized Carriers are prevented - by national=20 >regulatotion - from peering with non-NRA authorized Carriers, that is a >proper matter for regulators (tho. not IETF, or IAB, or US govt=20 >sponsorship of IAB members. or thier regulatory bodies (ICANN etc)_).=20 >The technical standards must not enforce any particular regulatory=20 >model, e.g. that of the US govt policy. There should, however, be good=20 >evidence that they support the commonest regulatory models, obviously,=20 >as a metric of technical adequacy. > >If we consider the ISO tradition on this matter, X.500 addressed the=20 >technical standards on a distributed name service for public names and=20 >address, provisioned by individuals, PRMDs, and ADMDs. The F.500=20 >variants address the PTSN model, for ADMD operating under national=20 >regulations and licneses. In our Ihistorical ETF tradition, dealing=20 >with public addressing policy in the Interent sphere, we have only=20 >ever previous address the X.500 _technology_ protocols: never the F.500 >series regulatory practices designed for regulated "Carriers" >acting as tariffed ADMDs. > >We should be clear in the revised charter, for Carrier ENUM, that the=20 >protocols do not enforce any particular model of operational=20 >regulation, and that peering regulation (if any) is a matter for=20 >national authorities. > > >Peter. > > >>From: Richard Shockey >>To: Antoin Verschuren >>CC: enum@ietf.org, voipeer@lists.uoregon.edu >>Subject: [Enum] My personal definitions >>Date: Sat, 08 Oct 2005 16:10:28 -0400 >> >> >>Peering : The negotiation of reciprocal interconnection=20 >>arrangements, settlement-free or otherwise, between operationally=20 >>independent service providers. >> >>Carrier: A service provider authorized to issue E.164 numbers for the=20 >>provisioning of PSTN service under the authority of a National=20 >>Regulatory Authority (NRA). >> >>-- >> >> >>Richard Shockey, Director - Member of Technical Staff NeuStar Inc. >>46000 Center Oak Plaza - Sterling, VA 20166 >>sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >>ENUM +87810-13313-31331 >>PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >>Fax: +1 815.333.1237 >> or=20 >> >> ; =20 >><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> >> >>_______________________________________________ >>enum mailing list >>enum@ietf.org >>https://www1.ietf.org/mailman/listinfo/enum > > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 10 10:19:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOyVN-00013J-1R; Mon, 10 Oct 2005 10:19:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOyVL-00012V-Dg for enum@megatron.ietf.org; Mon, 10 Oct 2005 10:19:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12129 for ; Mon, 10 Oct 2005 10:19:48 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EOyfE-0006Ex-Qc for enum@ietf.org; Mon, 10 Oct 2005 10:30:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Oct 2005 16:23:10 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2183@oefeg-s04.oefeg.loc> Thread-Topic: A proposal for Carrier ENUM Thread-Index: AcXMnM9KrbdWDX3jRWykCS53OKl7iQA5dn2gAAcf2VA= From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Subject: [Enum] A proposal for Carrier ENUM X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Dear all, I do not want to define the requirements or rules for the entities defined in voipeer allowing them to peer and if there are different classes. I only want to make a strong recommendation here: entities called "carriers" allowed to make entries in Public Carrier ENUM MUST be a subset of the above set. One requirement of the subset is that all Members of the subset are able to peer with all other members. Otherwise the whole construct does not make sense. Having heard the arguments here, I come to the following conclusion (and I changed my mind ;-) An entity hosting the E.164 number in question as a destination network for the PSTN termination is also allowed to enter the E.164 number in question into Carrier ENUM. Carrier ENUM is the opt-in place for the entities SERVING E.164 numbers=20 On the PSTN (see below) Rationale: For my case A this is trivial, for case B and C even if the number is assigned directly to the End-User, they need a carrier to terminate or translate (in case of an IN-number) the E.164 number in question. The argument I brought forward during the discussion that we should not rely on the PSTN within the Internet is not valid, because E.164 numbers are PSTN names. The argument brought forward by Antion is also not correct in this case: >The real (third party) Telco that controls the server should make the >peering decisions for that server, but that does not make him the owner of >the delegation. If we follow this argument for number portability, we would end up finally with this: NP gives the end-user the right to keep the number, but as long as he ports the number form one carrier to the other. In all countries the number is still connected via a long rubber band to the original donor and zoomes back if given up. If the above statement from Antoin holds true here, the number should be kept by the subscriber. One could also argue that if the entity that has the right to use of a number is always the owner of the delegation, we have exactly what we have now in User ENUM. So it is the decision of the end-user what he is doing with the number =3D opt-in in ENUM. Again, this is USER = ENUM. We all have seen that we have a problem here and that's why we want to=20 create Carrier ENUM: Carrier ENUM is the opt-in of the entities SERVING the E.164 numbers in question and it is assumed that such an entity will opt-in with all his numbers. This implies that an entity running their own servers will still need to use a "carrier" for entries in Carrier ENUM. They may agree with the "carrier" to enter their servers directly in this case (if they are also member of the peering subset - if not, they will need a "carrier"=20 anyways) Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 10 10:51:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOz0N-0007KX-LC; Mon, 10 Oct 2005 10:51:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOz0M-0007KG-7l for enum@megatron.ietf.org; Mon, 10 Oct 2005 10:51:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15564 for ; Mon, 10 Oct 2005 10:51:52 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOzAH-0007NJ-A9 for enum@ietf.org; Mon, 10 Oct 2005 11:02:09 -0400 Received: from [10.31.13.172] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9AEqOfg018116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Oct 2005 07:52:27 -0700 Message-ID: <434A7F82.60902@shockey.us> Date: Mon, 10 Oct 2005 10:49:38 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] A proposal for Carrier ENUM References: <32755D354E6B65498C3BD9FD496C7D461B2183@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B2183@oefeg-s04.oefeg.loc> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.4 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0680428572==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0680428572== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Stastny Richard wrote: 
Dear all,

I do not want to define the requirements or rules for the entities
defined
in voipeer allowing them to peer and if there are different classes.

I only want to make a strong recommendation here: entities called
"carriers" allowed to make entries in Public Carrier ENUM MUST be
a subset of the above set. One requirement of the subset is that all
Members of the subset are able to peer with all other members.

Otherwise the whole construct does not make sense.

Well this whole discussion is interesting but realistically wont it be the NRA's that will define what is the relevant entity(s) authorized to make entries in Public Carrier ENUM?

This is still the e164.apra tree.

Having heard the arguments here, I come to the following conclusion
(and I changed my mind ;-)

An entity hosting the E.164 number in question as a destination
network for the PSTN termination is also allowed to enter the
E.164 number in question into Carrier ENUM. Carrier ENUM is
the opt-in place for the entities SERVING E.164 numbers 
On the PSTN (see below)

Rationale:

For my case A this is trivial, for case B and C even if the
number is assigned directly to the End-User, they need a
carrier to terminate or translate (in case of an IN-number)
the E.164 number in question.

The argument I brought forward during the discussion that we
should not rely on the PSTN within the Internet is not valid, because
E.164 numbers are PSTN names.

The argument brought forward by Antion is also not correct in this case:

  
The real (third party) Telco that controls the server should make the
peering decisions for that server, but that does not make him the owner
    
of >the delegation.

If we follow this argument for number portability, we would end up
finally
with this:

NP gives the end-user the right to keep the number, but as long as
he ports the number form one carrier to the other. In all countries
the number is still connected via a long rubber band to the original
donor
and zoomes back if given up. If the above statement from Antoin holds
true
here, the number should be kept by the subscriber.

One could also argue that if the entity that has the right to use of
a number is always the owner of the delegation, we have exactly what
we have now in User ENUM. So it is the decision of the end-user what
he is doing with the number = opt-in in ENUM. Again, this is USER ENUM.

We all have seen that we have a problem here and that's why we want to 
create Carrier ENUM:

Carrier ENUM is the opt-in of the entities SERVING the E.164 numbers
in question and it is assumed that such an entity will opt-in
with all his numbers.

This implies that an entity running their own servers will still
need to use a "carrier" for entries in Carrier ENUM. They may agree with
the "carrier" to enter their servers directly in this case (if they are
also member of the peering subset - if not, they will need a "carrier" 
anyways)

Richard


_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum

  


-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--===============0680428572== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0680428572==-- From enum-bounces@ietf.org Mon Oct 10 11:53:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOzxv-0006Xm-G9; Mon, 10 Oct 2005 11:53:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOzw4-0006AE-HZ for enum@megatron.ietf.org; Mon, 10 Oct 2005 11:51:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01694 for ; Mon, 10 Oct 2005 11:51:25 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOzvu-0005Re-HM for enum@ietf.org; Mon, 10 Oct 2005 11:51:24 -0400 Received: from [10.31.13.183] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9AFfWSj024095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Oct 2005 08:41:33 -0700 Message-ID: <434A8B7F.4060001@shockey.us> Date: Mon, 10 Oct 2005 11:40:47 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Content-Type: multipart/mixed; boundary="------------070000060400000806040404" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.7 (+) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Subject: [Enum] [Fwd: I-D ACTION:draft-conroy-enum-edns0-00.txt] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------070000060400000806040404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

-------- Original Message --------
Subject: I-D ACTION:draft-conroy-enum-edns0-00.txt
Date: Mon, 10 Oct 2005 10:50:01 -0400
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: ENUM Requirement for EDNS0 Support
	Author(s)	: L. Conroy, J. Reid
	Filename	: draft-conroy-enum-edns0-00.txt
	Pages		: 16
	Date		: 2005-10-10
	
   This document mandates support for EDNS0 (Extension Mechanisms for
   DNS) in DNS entities claiming to support ENUM query resolution.  This
   requirement is needed as DNS responses to ENUM-related questions
   return large RRSets.  Without EDNS0 support in all the involved
   entities, a fallback to TCP transport for ENUM queries and responses
   would typically occur.  That has a severe impact on DNS Server load,
   and on latency of ENUM queries.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-conroy-enum-edns0-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-conroy-enum-edns0-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-conroy-enum-edns0-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--------------070000060400000806040404 Content-Type: Message/External-body; name="draft-conroy-enum-edns0-00.txt" Content-Disposition: inline; filename="draft-conroy-enum-edns0-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-10-10091947.I-D@ietf.org> --------------070000060400000806040404 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------070000060400000806040404 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------070000060400000806040404-- From enum-bounces@ietf.org Mon Oct 10 12:17:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP0LO-0004YP-FZ; Mon, 10 Oct 2005 12:17:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP0LM-0004TA-6d for enum@megatron.ietf.org; Mon, 10 Oct 2005 12:17:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03858 for ; Mon, 10 Oct 2005 12:17:37 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EP0VG-0000Zl-LK for enum@ietf.org; Mon, 10 Oct 2005 12:27:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] A proposal for Carrier ENUM Date: Mon, 10 Oct 2005 18:21:03 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C45D9@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] A proposal for Carrier ENUM Thread-Index: AcXNqq93Yia+0AbySZmTs2W4Pk/g/QACzEjH From: "Stastny Richard" To: "Richard Shockey" X-Spam-Score: 0.8 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >Well this whole discussion is interesting but realistically wont it be = the NRA's that will define what is the >relevant entity(s) authorized to = make entries in Public Carrier ENUM? =20 Agreed, but I would like to have some common understanding and agreement = here before we talk to ITU-T and the NRA's in ernest. If they get the = impression that nothing here is jeopardinzing their laws and regulations, the better. =20 And having aggreed upon pices of text here will also help to write a delayed contribution to SG2 ;-) =20 Richard ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Mo 10.10.2005 16:49 An: Stastny Richard Cc: enum@ietf.org Betreff: Re: [Enum] A proposal for Carrier ENUM Stastny Richard wrote:=20 Dear all, =09 I do not want to define the requirements or rules for the entities defined in voipeer allowing them to peer and if there are different classes. =09 I only want to make a strong recommendation here: entities called "carriers" allowed to make entries in Public Carrier ENUM MUST be a subset of the above set. One requirement of the subset is that all Members of the subset are able to peer with all other members. =09 Otherwise the whole construct does not make sense. =20 Well this whole discussion is interesting but realistically wont it be = the NRA's that will define what is the relevant entity(s) authorized to = make entries in Public Carrier ENUM? This is still the e164.apra tree. Having heard the arguments here, I come to the following conclusion (and I changed my mind ;-) =09 An entity hosting the E.164 number in question as a destination network for the PSTN termination is also allowed to enter the E.164 number in question into Carrier ENUM. Carrier ENUM is the opt-in place for the entities SERVING E.164 numbers=20 On the PSTN (see below) =09 Rationale: =09 For my case A this is trivial, for case B and C even if the number is assigned directly to the End-User, they need a carrier to terminate or translate (in case of an IN-number) the E.164 number in question. =09 The argument I brought forward during the discussion that we should not rely on the PSTN within the Internet is not valid, because E.164 numbers are PSTN names. =09 The argument brought forward by Antion is also not correct in this = case: =09 =20 The real (third party) Telco that controls the server should make the peering decisions for that server, but that does not make him the = owner =20 of >the delegation. =09 If we follow this argument for number portability, we would end up finally with this: =09 NP gives the end-user the right to keep the number, but as long as he ports the number form one carrier to the other. In all countries the number is still connected via a long rubber band to the original donor and zoomes back if given up. If the above statement from Antoin holds true here, the number should be kept by the subscriber. =09 One could also argue that if the entity that has the right to use of a number is always the owner of the delegation, we have exactly what we have now in User ENUM. So it is the decision of the end-user what he is doing with the number =3D opt-in in ENUM. Again, this is USER = ENUM. =09 We all have seen that we have a problem here and that's why we want to=20 create Carrier ENUM: =09 Carrier ENUM is the opt-in of the entities SERVING the E.164 numbers in question and it is assumed that such an entity will opt-in with all his numbers. =09 This implies that an entity running their own servers will still need to use a "carrier" for entries in Carrier ENUM. They may agree = with the "carrier" to enter their servers directly in this case (if they are also member of the peering subset - if not, they will need a "carrier"=20 anyways) =09 Richard =09 =09 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum =09 =20 --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or=20 = =20 ; = =20 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 10 15:50:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP3f8-0005EP-Lq; Mon, 10 Oct 2005 15:50:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP3et-0005A0-C6; Mon, 10 Oct 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17018; Mon, 10 Oct 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP3oq-0006dN-Nc; Mon, 10 Oct 2005 16:00:21 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EP3es-0002Mc-1Z; Mon, 10 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 10 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-token-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Validation Token Format Definition Author(s) : O. Lendl Filename : draft-ietf-enum-validation-token-00.txt Pages : 16 Date : 2005-10-10 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-token-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-validation-token-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-validation-token-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-10110923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-validation-token-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-validation-token-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-10110923.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Mon Oct 10 21:19:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP8nI-0004Nu-NO; Mon, 10 Oct 2005 21:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP8nH-0004Np-VY for enum@megatron.ietf.org; Mon, 10 Oct 2005 21:19:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06326 for ; Mon, 10 Oct 2005 21:19:02 -0400 (EDT) Received: from bay103-f11.bay103.hotmail.com ([65.54.174.21] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP8xI-0007Wv-N2 for enum@ietf.org; Mon, 10 Oct 2005 21:29:25 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 10 Oct 2005 18:18:53 -0700 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Tue, 11 Oct 2005 01:18:53 GMT X-Originating-IP: [71.140.80.125] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: From: "Peter Williams" To: enum@ietf.org Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-validation-token-00.txt Date: Mon, 10 Oct 2005 18:18:53 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 11 Oct 2005 01:18:53.0651 (UTC) FILETIME=[BE839230:01C5CE01] X-Spam-Score: 0.8 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I have not read the I-D, deliberately, but I did read anbd re-read the summary. If folks are willing, perhaps discuss the following issues, so I have retain open mind before I review the text formally: The summary says: a validation token conveys (securely) information pertainting to the completion of a validation method, by a Validation Entity. Presumably, the token conveys the result of the validation, and induces the relying party to verify the authority of the token's issuer. Becuase the security (of the token's communication) depends upon signed XML, we know that the token's origin authentication depends itself on the relying party first authenticating the token signature's verification key (assuming that the signing method for the XML stream depends on crypto). (a) are we assuming that ENUM and/or secure DNS protocols shall be used to distributed information allowing relying parties to authenticate signature verification keys, identifed as being associated with the authority of particular Verification Entities to issue Verification Tokens? (b) is reliance on a Verification Token a matter for the public, or is reliance on the signature/token intended to be limited to only those parties authorized by the Verification Entity? (c) are we assuming that trust model for distributing the signing/issuing authority of Verification Entities shall be "tied to" (or derived from) the the number issuing hierarchy, for the identities being Verified? (d) What IETF disclosures, discussions or contacts have there been between IAB and ISO concerning the relationship of the trust model, providing for authentication of the tokens conveying an Verification Entities confirmation of the domain-name<->E.164 identity? >From: Internet-Drafts@ietf.org >To: i-d-announce@ietf.org >CC: enum@ietf.org >Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-token-00.txt Date: >Mon, 10 Oct 2005 15:50:02 -0400 > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Telephone Number Mapping Working Group of >the IETF. > > Title : ENUM Validation Token Format Definition > Author(s) : O. Lendl > Filename : draft-ietf-enum-validation-token-00.txt > Pages : 16 > Date : 2005-10-10 > > An ENUM domain name is tightly coupled with the underlying E.164 > number. The process of verifying whether the Registrant of an ENUM > domain name is identical to the Assignee of the corresponding E.164 > number is commonly called "validation". This document describes an > signed XML data format -- the Validation Token -- with which > Validation Entities can convey successful completion of a validation > procedure in a secure fashion. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 05:25:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPGOQ-0004UU-Vt; Tue, 11 Oct 2005 05:25:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPGOO-0004RQ-Km for enum@megatron.ietf.org; Tue, 11 Oct 2005 05:25:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09877 for ; Tue, 11 Oct 2005 05:25:49 -0400 (EDT) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPGYO-00021w-C1 for enum@ietf.org; Tue, 11 Oct 2005 05:36:18 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id C4EEC1A3C1; Tue, 11 Oct 2005 11:25:19 +0200 (CEST) Date: Tue, 11 Oct 2005 11:25:19 +0200 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-validation-token-00.txt Message-ID: <20051011092519.GA30739@nic.at> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 2005/10/11 03:10, Peter Williams wrote: > > I have not read the I-D, deliberately, but I did read anbd re-read the > summary. You might want to read the architecture draft by Mayrhofer/Hoeneisen. (ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-enum-validation-arch-00.txt) My token draft operates within the role models and trust-relationships defined there. > have retain open mind before I review the text formally: > > The summary says: a validation token conveys (securely) information > pertainting to the completion of a validation method, by a Validation > Entity. Presumably, the token conveys the result of the validation, and > induces the relying party to verify the authority of the token's issuer. > > Becuase the security (of the token's communication) depends upon signed > XML, we know that the token's origin authentication depends itself on the > relying party first authenticating the token signature's verification key > (assuming that the signing method for the XML stream depends on crypto). > > (a) are we assuming that ENUM and/or secure DNS protocols shall be used to > distributed information allowing relying parties to authenticate signature > verification keys, identifed as being associated with the authority of > particular Verification Entities to issue Verification Tokens? No. >From my draft: Whether the Registry acts as a certificate authority, accepts certs from a public CA, or only accepts pre-registered keys is a local policy choice. > (b) is reliance on a Verification Token a matter for the public, or is > reliance on the signature/token intended to be limited to only those > parties authorized by the Verification Entity? I'm not sure whether I understand the question here. It's only the Tier1 registry which really has to check the validity of a Token while processing a delegation request. If that check goes though, the domain is delegated in a normal fashion. You have to separate the questions * who is authorized to act as a VE? (i.e. whose Tokens will be trusted and accepted by the Registry?) * how does the Registry makes sure that the Token it receive is authentic? Both are local policy choices. In the case of Austria's +43 ENUM production system, the answers are: * Prospective VEs have to sign a contract with the Registry. The content of that contract derives from the NRA's contract with the Registry. * The VE uses out-of-band mechanisms to send its X.509 Cert to the Registry. The Registry will then accept all Token signed with the corresponding key. > (c) are we assuming that trust model for distributing the signing/issuing > authority of Verification Entities shall be "tied to" (or derived from) the > the number issuing hierarchy, for the identities being Verified? Local policy choice. From a technical point of view, it's the Tier1 Registry which decides what to do. On the policy side, the Registry always has to act within the framework set by the NRA. After all the NRA is the one who decided (via the IETF/RIPE/ITU agreement) who can run the Tier1 registry. > (d) What IETF disclosures, discussions or contacts have there been between > IAB and ISO concerning the relationship of the trust model, providing for > authentication of the tokens conveying an Verification Entities > confirmation of the domain-name<->E.164 identity? As this model does not in any way touch the delegation of country-code ENUM domains from the Tier0, everything happens in the Tier1 space. This draft only proposes how individual countries can structure the local role model and provisioning protocols *within* that country's ENUM domain. /ol (NRA = National Regulatory Authority) -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 06:11:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPH6u-0005w0-9j; Tue, 11 Oct 2005 06:11:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPH6s-0005vv-CF for enum@megatron.ietf.org; Tue, 11 Oct 2005 06:11:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11826 for ; Tue, 11 Oct 2005 06:11:47 -0400 (EDT) Received: from gw1.domain-registry.nl ([193.176.144.139] helo=gw.domain-registry.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPHGw-0003De-Pm for enum@ietf.org; Tue, 11 Oct 2005 06:22:16 -0400 Received: (from root@localhost) by gw.domain-registry.nl (8.9.3c/8.6.12) id MAA49514 for ; Tue, 11 Oct 2005 12:11:29 +0200 (CEST) Received: by gw1.domain-registry.nl (TUNIX/Firewall SMTP Server) for id sma049254; Tue, 11 Oct 05 12:10:43 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Enum] A proposal for Carrier ENUM Date: Tue, 11 Oct 2005 12:10:42 +0200 Message-ID: <4F9D157E1D347A4E9EBCE02C45FE811001924E7A@sidn2002000.sidn.nl> Thread-Topic: [Enum] A proposal for Carrier ENUM Thread-Index: AcXMnM9KrbdWDX3jRWykCS53OKl7iQA5dn2gAAcf2VAAKWXKoA== From: "Antoin Verschuren" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Monday, October 10, 2005 4:23 PM Stastny Richard wrote: > An entity hosting the E.164 number in question as a destination > network for the PSTN termination is also allowed to enter the > E.164 number in question into Carrier ENUM. Carrier ENUM is > the opt-in place for the entities SERVING E.164 numbers > On the PSTN (see below) If you look at it this way, and decide that that is the purpose of Carrier ENUM, I agree with your model. However, I see problems in provisioning or validating registrations here. The contract between the number holder and entity terminating in the PSTN is usualy a private contract. The outside world or registry cannot validate this in an easy way. For the terminating party to prove that they are indeed entitled to terminate that number block into the PSTN, they have to go back to the number holder to generate that prove that they are indeed the terminating party. What I'm simply saying is why do we make things more complex here, and simply aquire the prove directly from the number holder. In the private contract between the terminating party and number holder, the terminating party can simply insist that the contract is only valid (they can only offer the service) if the number holder enters his numberblock in the Carier ENUM tree, delegating it to the terminating party. The carrier ENUM tree is then simply the place where a carrier-of-record is defined, as the NRA does not have this information. In this way, validation for a registry is much easier, since they can validate according to the assignment of the NRA. Ease in validation will get deployment faster, and let's be fair, the majority of assignents is directly to the real Carrier. A number holder not being a Carrier is an exception, with the burden that belongs with it. If he wants to be seen as a semi carier, he has to take over some carrier tasks, one of which is entering his numberblock in the carrier ENUM tree. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren@sidn.nl W http://www.sidn.nl/ _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 07:24:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPIEp-0005Xd-SE; Tue, 11 Oct 2005 07:24:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPIEn-0005XY-M8 for enum@megatron.ietf.org; Tue, 11 Oct 2005 07:24:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15227 for ; Tue, 11 Oct 2005 07:24:03 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPIOt-000565-6x for enum@ietf.org; Tue, 11 Oct 2005 07:34:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] A proposal for Carrier ENUM Date: Tue, 11 Oct 2005 13:27:34 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2186@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] A proposal for Carrier ENUM Thread-Index: AcXMnM9KrbdWDX3jRWykCS53OKl7iQA5dn2gAAcf2VAAKWXKoAAEO2vQ From: "Stastny Richard" To: "Antoin Verschuren" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi, I can follow your arguments, but see inline: > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Antoin Verschuren > Sent: Tuesday, October 11, 2005 12:11 PM > To: enum@ietf.org > Subject: RE: [Enum] A proposal for Carrier ENUM >=20 > On Monday, October 10, 2005 4:23 PM Stastny Richard wrote: >=20 > > An entity hosting the E.164 number in question as a destination > > network for the PSTN termination is also allowed to enter the > > E.164 number in question into Carrier ENUM. Carrier ENUM is > > the opt-in place for the entities SERVING E.164 numbers > > On the PSTN (see below) >=20 > If you look at it this way, and decide that that is the purpose of > Carrier ENUM, I agree with your model. > However, I see problems in provisioning or validating registrations > here. > The contract between the number holder and entity terminating in the > PSTN is usualy a private contract. > The outside world or registry cannot validate this in an easy way. > For the terminating party to prove that they are indeed entitled to > terminate that number block into the PSTN, they have to go back to the > number holder to generate that prove that they are indeed the > terminating party. This raises the question how this is "validated" now in the PSTN. How does a carrier now "prove" to the outside world (the other carriers and the NRA that he is serving an IN number on behalf of a number holder and that this number has to be routed now via his network? > What I'm simply saying is why do we make things more complex here, and > simply aquire the prove directly from the number holder. I am not sure that things are more complex, it seems more a chicken and egg problem. Most number holders will be happy that the carrier selected will do the formalities required. > In the private contract between the terminating party and number holder, > the terminating party can simply insist that the contract is only valid > (they can only offer the service) if the number holder enters his > numberblock in the Carier ENUM tree, delegating it to the terminating > party. > The carrier ENUM tree is then simply the place where a carrier-of-record > is defined, as the NRA does not have this information. Is it true that the NRA does not have this information? > In this way, validation for a registry is much easier, since they can > validate according to the assignment of the NRA. > Ease in validation will get deployment faster, and let's be fair, the > majority of assignents is directly to the real Carrier. > A number holder not being a Carrier is an exception, with the burden > that belongs with it. If he wants to be seen as a semi carier, he has to > take over some carrier tasks, one of which is entering his numberblock > in the carrier ENUM tree. See above And, as Rich pointed out, the detailed procedures in this case will be anyway national matter. Richard >=20 > Antoin Verschuren >=20 > Technical Advisor > Policy & Business Development > SIDN > Utrechtseweg 310 > PO Box 5022 > 6802 EA Arnhem > The Netherlands >=20 > T +31 26 3525510 > F +31 26 3525505 > M +31 6 23368970 > E antoin.verschuren@sidn.nl > W http://www.sidn.nl/ >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 08:59:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPJjT-0005XF-Dv; Tue, 11 Oct 2005 08:59:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPJjS-0005WL-1k for enum@megatron.ietf.org; Tue, 11 Oct 2005 08:59:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21617 for ; Tue, 11 Oct 2005 08:59:47 -0400 (EDT) Received: from mail.ficora.fi ([194.100.96.25] helo=portti1.ficora.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPJtX-0008D1-4E for enum@ietf.org; Tue, 11 Oct 2005 09:10:16 -0400 Received: from POSTI.laru.local ([10.1.0.10]) by portti1.ficora.fi with InterScan Messaging Security Suite; Tue, 11 Oct 2005 16:05:59 +0300 Content-class: urn:content-classes:message Subject: RE: [Enum] A proposal for Carrier ENUM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Oct 2005 15:59:36 +0300 Message-ID: <07BC6C0D40216E44A34BE6701694FE86018627E4@POSTI.laru.local> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Enum] A proposal for Carrier ENUM Thread-Index: AcXMnM9KrbdWDX3jRWykCS53OKl7iQA5dn2gAAcf2VAAKWXKoAAEO2vQAALHAJA= From: "Nieminen Klaus" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hello,=20 One clarification: > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Stastny Richard > Sent: 11. lokakuuta 2005 14:28 > To: Antoin Verschuren; enum@ietf.org > Subject: RE: [Enum] A proposal for Carrier ENUM >=20 >> In the private contract between the terminating party and number >> holder, the terminating party can simply insist that the contract is only >> valid (they can only offer the service) if the number holder enters his=20 >> numberblock in the Carier ENUM tree, delegating it to the terminating >> party. The carrier ENUM tree is then simply the place where a >> carrier-of-record is defined, as the NRA does not have this information. > > Is it true that the NRA does not have this information? At least in some cases NRAs do not have information about the network that serves the numbers directly assigned to the users. I do not know, if the same problem exists also for number ranges assigned to telcos, but I assume that this may be tha case at least for numbers that are further delegated to other service providers (e.g. Skype) by a contract. For ported numbers I believe that all implementations involve the use of databases that contain information on the network with which ported numbers are associated. Therefore this should not be a problem. regards, - Klaus - ___________________________________________ KLAUS NIEMINEN Senior Adviser Finnish Communications Regulatory Authority Internet and Information Security P.O. Box 313 FIN-00181 HELSINKI FINLAND tel.: +358 9 6966 634 fax: +358 9 6966 873 e-mail: klaus.nieminen@ficora.fi www: http://www.ficora.fi _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 09:22:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPK59-00033j-UO; Tue, 11 Oct 2005 09:22:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPK58-00033W-5Y for enum@megatron.ietf.org; Tue, 11 Oct 2005 09:22:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22985 for ; Tue, 11 Oct 2005 09:22:12 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPKFF-0000R6-CU for enum@ietf.org; Tue, 11 Oct 2005 09:32:41 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 11 Oct 2005 09:22:06 -0400 X-IronPort-AV: i="3.97,198,1125892800"; d="scan'208"; a="73491473:sNHT25064828" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9BDLuQr029678; Tue, 11 Oct 2005 09:22:03 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 09:21:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] A proposal for Carrier ENUM Date: Tue, 11 Oct 2005 09:21:44 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3A8BFB4@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] A proposal for Carrier ENUM Thread-Index: AcXMnM9KrbdWDX3jRWykCS53OKl7iQA5dn2gAAcf2VAAKWXKoAAEO2vQAALHAJAAAVTWAA== From: "Michael Hammer \(mhammer\)" To: "Nieminen Klaus" , X-OriginalArrivalTime: 11 Oct 2005 13:21:45.0171 (UTC) FILETIME=[B9F45230:01C5CE66] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Klaus, If done right, ENUM would replace the number portability databases eventually. It does not make sense to use one database to validate the data in another database. The operational procedure for validating data should be inherent to the database. Mike > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Nieminen Klaus > Sent: Tuesday, October 11, 2005 9:00 AM > To: enum@ietf.org > Subject: RE: [Enum] A proposal for Carrier ENUM >=20 > Hello,=20 >=20 > One clarification: >=20 > > -----Original Message----- > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Stastny Richard > > Sent: 11. lokakuuta 2005 14:28 > > To: Antoin Verschuren; enum@ietf.org > > Subject: RE: [Enum] A proposal for Carrier ENUM > >=20 > >> In the private contract between the terminating party and number=20 > >> holder, the terminating party can simply insist that the=20 > contract is > only > >> valid (they can only offer the service) if the number holder enters > his=20 > >> numberblock in the Carier ENUM tree, delegating it to the=20 > terminating >=20 > >> party. The carrier ENUM tree is then simply the place where a=20 > >> carrier-of-record is defined, as the NRA does not have this > information. > > > > Is it true that the NRA does not have this information? >=20 > At least in some cases NRAs do not have information about the=20 > network that serves the numbers directly assigned to the=20 > users. I do not know, if the same problem exists also for=20 > number ranges assigned to telcos, but I assume that this may=20 > be tha case at least for numbers that are further delegated=20 > to other service providers (e.g. Skype) by a contract. >=20 > For ported numbers I believe that all implementations involve=20 > the use of databases that contain information on the network=20 > with which ported numbers are associated. Therefore this=20 > should not be a problem. >=20 > regards, >=20 > - Klaus - > ___________________________________________ > KLAUS NIEMINEN > Senior Adviser > Finnish Communications Regulatory Authority Internet and=20 > Information Security P.O. Box 313 > FIN-00181 HELSINKI > FINLAND > tel.: +358 9 6966 634 > fax: +358 9 6966 873 > e-mail: klaus.nieminen@ficora.fi > www: http://www.ficora.fi >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 09:26:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPK8q-0004Vk-VJ; Tue, 11 Oct 2005 09:26:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPK8p-0004US-Dc for enum@megatron.ietf.org; Tue, 11 Oct 2005 09:26:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23175 for ; Tue, 11 Oct 2005 09:26:01 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPKIr-0000Y1-JX for enum@ietf.org; Tue, 11 Oct 2005 09:36:30 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1129037044!5478127!32 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 30390 invoked from network); 11 Oct 2005 13:25:48 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-12.tower-121.messagelabs.com with SMTP; 11 Oct 2005 13:25:48 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 432D903200523481; Tue, 11 Oct 2005 09:25:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] A proposal for Carrier ENUM Date: Tue, 11 Oct 2005 09:25:47 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0B4AFEB9@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Enum] A proposal for Carrier ENUM Thread-Index: AcXMnM9KrbdWDX3jRWykCS53OKl7iQA5dn2gAAcf2VAAKWXKoAAEO2vQAALHAJAAASE/QA== From: "Pfautz, Penn L, NEO" To: "Nieminen Klaus" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Klaus: Unfortunately not all portability implementations use network databases (I assume it's network databases rather Rather than admin ones to which you refer) Maybe some of those whose countries use "onward routing" etc. can confirm whether there is any centralized database outside of the network detailing those arrangements.=20 Nonetheless, I do think that for the most part it will be possible to determine who the carrier providing the PSTN point of interface for an E.164 number is and thus the carrier-of-record for carrier ENUM. If this information were not generally available the E.164 number would not be of much use anyway. I could think of workarounds even in the non-centralized LNP situations and, frankly, if those cause some pain, if should be thought of in terms of penance for making an erroneous choice with respect to the implementation of number portability. (:-) The day may/should/will come when interconnection is all IP-based and some form of ENUM Registry IS the database of record for number assignment and then we can have a debate about what it means to be carrier of record again, but for now the approach of using the entity that provides the number assignment/PSTN PoI is, I think, quite workable. Penn Pfautz -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Nieminen Klaus Sent: Tuesday, October 11, 2005 9:00 AM To: enum@ietf.org Subject: RE: [Enum] A proposal for Carrier ENUM Hello,=20 One clarification: > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Stastny Richard > Sent: 11. lokakuuta 2005 14:28 > To: Antoin Verschuren; enum@ietf.org > Subject: RE: [Enum] A proposal for Carrier ENUM >=20 >> In the private contract between the terminating party and number >> holder, the terminating party can simply insist that the contract is only >> valid (they can only offer the service) if the number holder enters his=20 >> numberblock in the Carier ENUM tree, delegating it to the terminating >> party. The carrier ENUM tree is then simply the place where a >> carrier-of-record is defined, as the NRA does not have this information. > > Is it true that the NRA does not have this information? At least in some cases NRAs do not have information about the network that serves the numbers directly assigned to the users. I do not know, if the same problem exists also for number ranges assigned to telcos, but I assume that this may be tha case at least for numbers that are further delegated to other service providers (e.g. Skype) by a contract. For ported numbers I believe that all implementations involve the use of databases that contain information on the network with which ported numbers are associated. Therefore this should not be a problem. regards, - Klaus - ___________________________________________ KLAUS NIEMINEN Senior Adviser Finnish Communications Regulatory Authority Internet and Information Security P.O. Box 313 FIN-00181 HELSINKI FINLAND tel.: +358 9 6966 634 fax: +358 9 6966 873 e-mail: klaus.nieminen@ficora.fi www: http://www.ficora.fi _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 09:38:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKKs-0007mY-Gc; Tue, 11 Oct 2005 09:38:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKKr-0007mN-GB for enum@megatron.ietf.org; Tue, 11 Oct 2005 09:38:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23867 for ; Tue, 11 Oct 2005 09:38:27 -0400 (EDT) Received: from mail.ficora.fi ([194.100.96.25] helo=portti1.ficora.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPKUy-0000tY-L0 for enum@ietf.org; Tue, 11 Oct 2005 09:48:57 -0400 Received: from POSTI.laru.local ([10.1.0.10]) by portti1.ficora.fi with InterScan Messaging Security Suite; Tue, 11 Oct 2005 16:44:50 +0300 Content-class: urn:content-classes:message Subject: RE: [Enum] A proposal for Carrier ENUM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Oct 2005 16:38:27 +0300 Message-ID: <07BC6C0D40216E44A34BE6701694FE86018627E6@POSTI.laru.local> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Enum] A proposal for Carrier ENUM Thread-Index: AcXMnM9KrbdWDX3jRWykCS53OKl7iQA5dn2gAAcf2VAAKWXKoAAEO2vQAALHAJAAASE/QAAApZqw From: "Nieminen Klaus" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Penn, Michael and all,=20 My message was that in most cases we do have the required information available and I think that we should not focus on the implementation details in this question. As Penn mentioned, I believe that these issues can be solved. However, there are cases that may cause problems and my question is: Should we take also these cases into account in our work or do you think that this is should more likely to be solved nationally? - Klaus - -----Original Message----- From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com]=20 Sent: 11. lokakuuta 2005 16:26 To: Nieminen Klaus; enum@ietf.org Subject: RE: [Enum] A proposal for Carrier ENUM Klaus: Unfortunately not all portability implementations use network databases (I assume it's network databases rather Rather than admin ones to which you refer) Maybe some of those whose countries use "onward routing" etc. can confirm whether there is any centralized database outside of the network detailing those arrangements.=20 Nonetheless, I do think that for the most part it will be possible to determine who the carrier providing the PSTN point of interface for an E.164 number is and thus the carrier-of-record for carrier ENUM. If this information were not generally available the E.164 number would not be of much use anyway. I could think of workarounds even in the non-centralized LNP situations and, frankly, if those cause some pain, if should be thought of in terms of penance for making an erroneous choice with respect to the implementation of number portability. (:-) The day may/should/will come when interconnection is all IP-based and some form of ENUM Registry IS the database of record for number assignment and then we can have a debate about what it means to be carrier of record again, but for now the approach of using the entity that provides the number assignment/PSTN PoI is, I think, quite workable. Penn Pfautz -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Nieminen Klaus Sent: Tuesday, October 11, 2005 9:00 AM To: enum@ietf.org Subject: RE: [Enum] A proposal for Carrier ENUM Hello,=20 One clarification: > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Stastny Richard > Sent: 11. lokakuuta 2005 14:28 > To: Antoin Verschuren; enum@ietf.org > Subject: RE: [Enum] A proposal for Carrier ENUM >=20 >> In the private contract between the terminating party and number=20 >> holder, the terminating party can simply insist that the contract is only >> valid (they can only offer the service) if the number holder enters his=20 >> numberblock in the Carier ENUM tree, delegating it to the terminating >> party. The carrier ENUM tree is then simply the place where a=20 >> carrier-of-record is defined, as the NRA does not have this information. > > Is it true that the NRA does not have this information? At least in some cases NRAs do not have information about the network that serves the numbers directly assigned to the users. I do not know, if the same problem exists also for number ranges assigned to telcos, but I assume that this may be tha case at least for numbers that are further delegated to other service providers (e.g. Skype) by a contract. For ported numbers I believe that all implementations involve the use of databases that contain information on the network with which ported numbers are associated. Therefore this should not be a problem. regards, - Klaus - ___________________________________________ KLAUS NIEMINEN Senior Adviser Finnish Communications Regulatory Authority Internet and Information Security P.O. Box 313 FIN-00181 HELSINKI FINLAND tel.: +358 9 6966 634 fax: +358 9 6966 873 e-mail: klaus.nieminen@ficora.fi www: http://www.ficora.fi _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 09:41:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKNs-0008LD-K9; Tue, 11 Oct 2005 09:41:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKNr-0008L1-6u for enum@megatron.ietf.org; Tue, 11 Oct 2005 09:41:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24008 for ; Tue, 11 Oct 2005 09:41:33 -0400 (EDT) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPKXw-0000xc-Ju for enum@ietf.org; Tue, 11 Oct 2005 09:52:02 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 49E181A3C1; Tue, 11 Oct 2005 15:41:21 +0200 (CEST) Date: Tue, 11 Oct 2005 15:41:21 +0200 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] A proposal for Carrier ENUM Message-ID: <20051011134120.GA1196@nic.at> References: <34DA635B184A644DA4588E260EC0A25A0B4AFEB9@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0B4AFEB9@ACCLUST02EVS1.ugd.att.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 2005/10/11 15:10, "Pfautz, Penn L, NEO" wrote: > > Maybe some of those whose > countries use "onward routing" etc. can confirm > whether there is any centralized database outside of the network > detailing those arrangements. Austria uses onward routing for fixed line NP. There is no centralized DB which shows which number has been ported to whom. The NRA only keeps tabs on what number have been ported, but this DB does not include the information necessary to route calls. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 09:57:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKdE-0003vj-O7; Tue, 11 Oct 2005 09:57:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKdD-0003vY-Gh for enum@megatron.ietf.org; Tue, 11 Oct 2005 09:57:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24743 for ; Tue, 11 Oct 2005 09:57:25 -0400 (EDT) Received: from mail.ficora.fi ([194.100.96.25] helo=portti1.ficora.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPKnJ-0001M1-Rl for enum@ietf.org; Tue, 11 Oct 2005 10:07:55 -0400 Received: from POSTI.laru.local ([10.1.0.10]) by portti1.ficora.fi with InterScan Messaging Security Suite; Tue, 11 Oct 2005 17:03:46 +0300 Content-class: urn:content-classes:message Subject: RE: [Enum] A proposal for Carrier ENUM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Oct 2005 16:57:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <07BC6C0D40216E44A34BE6701694FE86018627E7@POSTI.laru.local> Thread-Topic: [Enum] A proposal for Carrier ENUM Thread-Index: AcXOaa9fWXwvwmUMTRiW7DBar6w88gAAGBSA From: "Nieminen Klaus" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org In most CEPT countries MNP is implemented using centralised NP databases. These are typically managed by a consortia of network operators, so NRAs may not have any information about ported numbers. Well, I think that this fact is not very important. At least also Malta and Cyprus has distributed MNP databases, but does this mean that the validation information is not available or is it possible to gather the required data from multiple databases maintained by different operators? regards, - Klaus - -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Otmar Lendl Sent: 11. lokakuuta 2005 16:41 To: enum@ietf.org Subject: Re: [Enum] A proposal for Carrier ENUM On 2005/10/11 15:10, "Pfautz, Penn L, NEO" wrote: > > Maybe some of those whose=20 > countries use "onward routing" etc. can confirm whether there is any=20 > centralized database outside of the network detailing those=20 > arrangements. Austria uses onward routing for fixed line NP. There is no centralized DB which shows which number has been ported to whom. The NRA only keeps tabs on what number have been ported, but this DB does not include the information necessary to route calls. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 10:00:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKgA-0004KS-99; Tue, 11 Oct 2005 10:00:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKg8-0004KI-D9 for enum@megatron.ietf.org; Tue, 11 Oct 2005 10:00:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24930 for ; Tue, 11 Oct 2005 10:00:26 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPKqE-0001Qa-N2 for enum@ietf.org; Tue, 11 Oct 2005 10:10:56 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-8.tower-121.messagelabs.com!1129039206!6844735!2 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 14718 invoked from network); 11 Oct 2005 14:00:16 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-8.tower-121.messagelabs.com with SMTP; 11 Oct 2005 14:00:16 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 432D903200525442; Tue, 11 Oct 2005 10:00:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] A proposal for Carrier ENUM Date: Tue, 11 Oct 2005 10:00:15 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0B4AFF8D@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Enum] A proposal for Carrier ENUM Thread-Index: AcXOaaYsUqNEZi+VTRmPmqdy0jftLQAAjidA From: "Pfautz, Penn L, NEO" To: "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Otmar: Thanks. As long as the ported-to carrier is indicated in the NRA database that is enough for determining the carrier of record for carrier ENUM. Penn=20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Otmar Lendl Sent: Tuesday, October 11, 2005 9:41 AM To: enum@ietf.org Subject: Re: [Enum] A proposal for Carrier ENUM On 2005/10/11 15:10, "Pfautz, Penn L, NEO" wrote: > > Maybe some of those whose > countries use "onward routing" etc. can confirm > whether there is any centralized database outside of the network > detailing those arrangements.=20 Austria uses onward routing for fixed line NP. There is no centralized DB which shows which number has been ported to whom. The NRA only keeps tabs on what number have been ported, but this DB does not include the information necessary to route calls. /ol --=20 < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 10:06:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKlZ-0005f8-82; Tue, 11 Oct 2005 10:06:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKlX-0005dL-4g for enum@megatron.ietf.org; Tue, 11 Oct 2005 10:06:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25430 for ; Tue, 11 Oct 2005 10:06:00 -0400 (EDT) Received: from bay103-f32.bay103.hotmail.com ([65.54.174.42] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPKve-0001ac-Eo for enum@ietf.org; Tue, 11 Oct 2005 10:16:30 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 11 Oct 2005 07:05:52 -0700 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Tue, 11 Oct 2005 14:05:52 GMT X-Originating-IP: [71.140.80.125] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <20051011092519.GA30739@nic.at> From: "Peter Williams" To: lendl@nic.at, enum@ietf.org Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-validation-token-00.txt Date: Tue, 11 Oct 2005 07:05:52 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 11 Oct 2005 14:05:52.0890 (UTC) FILETIME=[E41E2DA0:01C5CE6C] X-Spam-Score: 0.8 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >From: Otmar Lendl >To: enum@ietf.org >Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-validation-token-00.txt >Date: Tue, 11 Oct 2005 11:25:19 +0200 > > >From my draft: > > Whether the Registry acts as a certificate authority, accepts certs > from a public CA, or only accepts pre-registered keys is a local policy > choice. > > > (b) is reliance on a Verification Token a matter for the public, or is > > reliance on the signature/token intended to be limited to only those > > parties authorized by the Verification Entity? > >I'm not sure whether I understand the question here. We tend to think of digital signatures as Ron Rivest first characterized them, for RSA: replacement for contract signing, where email text (or html/xml) plays the role of the piece of paper bearing the contract terms. Anyone can verify the signature, as such openness of usage is part of the signature function: acknowledge that real people having signed terms on paper, forming agreement ands contracts, so disputes are handled using normal social processes involving evidence and proof of signing intent. In the case of RSA-based certs, DESMAC-based OCSP responses and other crypto-based signing technologies, which can implement Validation Tokens, we may or may not wish the signed token to be a "public" object, that anyone can verify as a proof of something having occured: e,g. validation of the E.164<->d-n identity. The term "token" implied to me (given ISO uses this term carefully) that we were not intending the object to serve as a proof object (which assumes public proving processes), but - like an SSL signed token for client auth - its signature may be designed for only one party to consume, in the context of earlier protocol exchanges. Ill read the architecture draft next. Whats in my mind is understanding the type of validation infrastructure that is being planned; and, whether there is any difference in the deployement models of the Validation Infrastrcuture for the User vs Carrier ENUM cases - given we now have the Carrier ENUM variant to address in the security model. ------ Some Thoughts: In Carrier ENUM, we are dealing with largely closed systems, closed to create a system which satisfies high minimum levels of QoS via controlled peering, in which any security tokens used and shared amongst computers in a provider community (e.g. GSM) may be largely hidden from end users. All disputes within the telematic system involving ENUM will be handled using _regulated_ dispute arbitration, like any other PTT-based telco service. The notion of "reliance" on the Validation Token may be mute, as all reliance and its legal implications within the regulatory framework is defined by the regulator. Many of the legal and policy issues that surrounded certs and signatures in the e-commerce space may be irrelevant, as Carrier ENUM is intended to be a closed system - and a closed reliance system, at that. In User ENUM, we have a different set of issues, where Validation Tokens may be called upon during a dispute to prove something - for one or other party to the dispute. If that argument is free form, and in open litigation, we have a token issuing and use/reliance environment similar to the world of e-commerce: which will require a different set of controls to limit the issuer's risks, and controls on who can and who cannot either use or rely upon the tokens for particular purposes. Peter. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 10:11:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKqR-0007ZW-Hf; Tue, 11 Oct 2005 10:11:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKqQ-0007ZH-Gp for enum@megatron.ietf.org; Tue, 11 Oct 2005 10:11:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26064 for ; Tue, 11 Oct 2005 10:11:04 -0400 (EDT) Received: from mail92.messagelabs.com ([194.106.220.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPL0V-0001lV-CA for enum@ietf.org; Tue, 11 Oct 2005 10:21:34 -0400 X-VirusChecked: Checked X-Env-Sender: Paul.Rosbotham@cwmsg.cwplc.com X-Msg-Ref: server-13.tower-92.messagelabs.com!1129040089!14558886!1 X-StarScan-Version: 5.4.15; banners=cwmsg.cwplc.com,-,- X-Originating-IP: [194.6.6.11] Received: (qmail 19438 invoked from network); 11 Oct 2005 14:14:50 -0000 Received: from relay.cwplc.com (194.6.6.11) by server-13.tower-92.messagelabs.com with SMTP; 11 Oct 2005 14:14:49 -0000 Received: from GBCWSWIEV001.ad.plc.cwintra.com ([148.185.93.211]) by relay.cwplc.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j9BEAw523106 for ; Tue, 11 Oct 2005 15:10:58 +0100 (BST) Received: from GBCWSWIEC002.ad.plc.cwintra.com (unverified) by GBCWSWIEV001.ad.plc.cwintra.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Tue, 11 Oct 2005 15:11:59 +0100 Received: from GBCWSWIEM002.ad.plc.cwintra.com ([148.185.93.204]) by GBCWSWIEC002.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 15:11:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [Enum] A proposal for Carrier ENUM Date: Tue, 11 Oct 2005 15:11:58 +0100 Message-ID: <9322B78036E1534A99B0BC51DEB0F9D6017259B1@GBCWSWIEM002.ad.plc.cwintra.com> Thread-Topic: [Enum] A proposal for Carrier ENUM Thread-Index: AcXOaaYsUqNEZi+VTRmPmqdy0jftLQAAjidAAAB31i0= From: "Rosbotham, Paul" To: , , X-OriginalArrivalTime: 11 Oct 2005 14:11:59.0076 (UTC) FILETIME=[BE61BA40:01C5CE6D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1217312178==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1217312178== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CE6D.BE205178" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CE6D.BE205178 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My=20view=20is=20that=20these=20type=20of=20issues=20are=20firmly=20in=20t= he=20category=20of=20"national=20matter".=20=20All=20that=20need=20be=20ag= reed=20at=20this=20level=20is=20the=20principle=20that=20the=20database=20= be=20populated=20by=20the=20carrier=20that=20provides=20the=20PSTN=20termi= nation=20for=20the=20number=20in=20question.=20=20How=20this=20is=20achiev= ed=20is=20something=20which=20will=20vary=20by=20jurisdiction. As=20it=20happens,=20some=20places=20where=20onward=20routeing=20is=20used= =20are=20considering=20usage=20of=20carrier=20ENUM=20to=20supersede=20the=20= existing=20solution. Regards, Paul=20Rosbotham Manager,=20Interconnect=20Strategy=20&=20Technology=20Regulation Cable=20&=20Wireless=20plc Tel=20:=09+44=201772=20451506 Mob=20:=09+44=207957=20805573 -----Original=20Message----- From:=20enum-bounces@ietf.org=20 To:=20Otmar=20Lendl=20;=20enum@ietf.org=20 Sent:=20Tue=20Oct=2011=2015:00:15=202005 Subject:=20RE:=20[Enum]=20A=20proposal=20for=20Carrier=20ENUM Otmar: Thanks.=20As=20long=20as=20the=20ported-to=20carrier=20is=20indicated=20in= =20the=20NRA database=20that=20is=20enough=20for=20determining=20the=20carrier=20of=20r= ecord=20for carrier=20ENUM. Penn=20 -----Original=20Message----- From:=20enum-bounces@ietf.org=20[mailto:enum-bounces@ietf.org]=20On=20Beha= lf=20Of Otmar=20Lendl Sent:=20Tuesday,=20October=2011,=202005=209:41=20AM To:=20enum@ietf.org Subject:=20Re:=20[Enum]=20A=20proposal=20for=20Carrier=20ENUM On=202005/10/11=2015:10,=20"Pfautz,=20Penn=20L,=20NEO"=20= =20wrote: > >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Maybe=20some=20of= =20those=20whose >=20countries=20use=20"onward=20routing"=20etc.=20can=20confirm >=20whether=20there=20is=20any=20centralized=20database=20outside=20of=20t= he=20network >=20detailing=20those=20arrangements.=20 Austria=20uses=20onward=20routing=20for=20fixed=20line=20NP.=20There=20is=20= no=20centralized DB=20which=20shows=20which=20number=20has=20been=20ported=20to=20whom. The=20NRA=20only=20keeps=20tabs=20on=20what=20number=20have=20been=20porte= d,=20but=20this DB=20does=20not=20include=20the=20information=20necessary=20to=20route=20c= alls. /ol --=20 <=20Otmar=20Lendl=20(lendl@nic.at)=20|=20nic.at=20Systems=20Engineer=20> _______________________________________________ enum=20mailing=20list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum=20mailing=20list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum This=20e-mail=20has=20been=20scanned=20for=20viruses=20by=20the=20Cable=20= &=20Wireless=20e-mail=20security=20system=20-=20powered=20by=20MessageLabs= .=20For=20more=20information=20on=20a=20proactive=20managed=20e-mail=20sec= urity=20service,=20=20visit=20http://www.cw.com/uk/emailprotection/=20 =20 The=20information=20contained=20in=20this=20e-mail=20is=20confidential=20a= nd=20may=20also=20be=20subject=20to=20legal=20privilege.=20It=20is=20inten= ded=20only=20for=20the=20recipient(s)=20named=20above.=20If=20you=20are=20= not=20named=20above=20as=20a=20recipient,=20you=20must=20not=20read,=20cop= y,=20disclose,=20forward=20or=20otherwise=20use=20the=20information=20cont= ained=20in=20this=20email.=20If=20you=20have=20received=20this=20e-mail=20= in=20error,=20please=20notify=20the=20sender=20(whose=20contact=20details=20= are=20above)=20immediately=20by=20reply=20e-mail=20and=20delete=20the=20me= ssage=20and=20any=20attachments=20without=20retaining=20any=20copies. ------_=_NextPart_001_01C5CE6D.BE205178 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re:=20[Enum]=20A=20proposal=20for=20Carrier=20ENUM

My=20view=20is=20that=20these=20type=20of=20issues=20a= re=20firmly=20in=20the=20category=20of=20"national=20matter".&nb= sp;=20All=20that=20need=20be=20agreed=20at=20this=20level=20is=20the=20pri= nciple=20that=20the=20database=20be=20populated=20by=20the=20carrier=20tha= t=20provides=20the=20PSTN=20termination=20for=20the=20number=20in=20questi= on. =20How=20this=20is=20achieved=20is=20something=20which=20will=20v= ary=20by=20jurisdiction.

As=20it=20happens,=20some=20places=20where=20onward=20routeing=20is=20used= =20are=20considering=20usage=20of=20carrier=20ENUM=20to=20supersede=20the=20= existing=20solution.

Regards,


Paul=20Rosbotham
Manager,=20Interconnect=20Strategy=20&=20Technology=20Regulation
Cable=20&=20Wireless=20plc

Tel=20:  =20+44=201772=20451506
Mob=20:  =20+44=207957=20805573


-----Original=20Message-----
From:=20enum-bounces@ietf.org=20<enum-bounces@ietf.org>
To:=20Otmar=20Lendl=20<lendl@nic.at>;=20enum@ietf.org=20<enum@iet= f.org>
Sent:=20Tue=20Oct=2011=2015:00:15=202005
Subject:=20RE:=20[Enum]=20A=20proposal=20for=20Carrier=20ENUM

Otmar:
Thanks.=20As=20long=20as=20the=20ported-to=20carrier=20is=20indicated=20in= =20the=20NRA
database=20that=20is=20enough=20for=20determining=20the=20carrier=20of=20r= ecord=20for
carrier=20ENUM.

Penn

-----Original=20Message-----
From:=20enum-bounces@ietf.org=20[mailto:enum-bounces@ietf.org]=20On=20Behalf=20Of
Otmar=20Lendl
Sent:=20Tuesday,=20October=2011,=202005=209:41=20AM
To:=20enum@ietf.org
Subject:=20Re:=20[Enum]=20A=20proposal=20for=20Carrier=20ENUM


On=202005/10/11=2015:10,=20"Pfautz,=20Penn=20L,=20NEO"=20<ppf= autz@att.com>=20wrote:
>
>           &nbs= p;            =             &n= bsp;      =20Maybe=20some=20of=20those=20who= se
>=20countries=20use=20"onward=20routing"=20etc.=20can=20confi= rm
>=20whether=20there=20is=20any=20centralized=20database=20outside=20of=20= the=20network
>=20detailing=20those=20arrangements.

Austria=20uses=20onward=20routing=20for=20fixed=20line=20NP.=20There=20is=20= no=20centralized
DB=20which=20shows=20which=20number=20has=20been=20ported=20to=20whom.
=
The=20NRA=20only=20keeps=20tabs=20on=20what=20number=20have=20been=20porte= d,=20but=20this
DB=20does=20not=20include=20the=20information=20necessary=20to=20route=20c= alls.

/ol
--
<=20Otmar=20Lendl=20(lendl@nic.at)=20|=20nic.at=20Systems=20Engineer=20= >

_______________________________________________
enum=20mailing=20list
enum@ietf.org
https://www1.iet= f.org/mailman/listinfo/enum

_______________________________________________
enum=20mailing=20list
enum@ietf.org
https://www1.iet= f.org/mailman/listinfo/enum


This=20e-mail=20has=20been=20scanned=20for=20viruses=20by=20the=20Cable=20= &=20Wireless=20e-mail=20security=20system=20-=20powered=20by=20MessageLabs= .=20For=20more=20information=20on=20a=20proactive=20managed=20e-mail=20sec= urity=20service,=20=20visit=20http://www.cw.com/uk/emailprotection/=20
= =20
The=20information=20contained=20in=20this=20e-mail=20is=20confidential=20a= nd=20may=20also=20be=20subject=20to=20legal=20privilege.=20It=20is=20inten= ded=20only=20for=20the=20recipient(s)=20named=20above.=20If=20you=20are=20= not=20named=20above=20as=20a=20recipient,=20you=20must=20not=20read,=20cop= y,=20disclose,=20forward=20or=20otherwise=20use=20the=20information=20cont= ained=20in=20this=20email.=20If=20you=20have=20received=20this=20e-mail=20= in=20error,=20please=20notify=20the=20sender=20(whose=20contact=20details=20= are=20above)=20immediately=20by=20reply=20e-mail=20and=20delete=20the=20me= ssage=20and=20any=20attachments=20without=20retaining=20any=20copies.
------_=_NextPart_001_01C5CE6D.BE205178-- --===============1217312178== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1217312178==-- From enum-bounces@ietf.org Tue Oct 11 10:20:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKzW-0000wX-GU; Tue, 11 Oct 2005 10:20:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKzU-0000wP-Rm for enum@megatron.ietf.org; Tue, 11 Oct 2005 10:20:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27010 for ; Tue, 11 Oct 2005 10:20:26 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPL9b-00020M-UO for enum@ietf.org; Tue, 11 Oct 2005 10:30:56 -0400 Received: from [10.31.13.171] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9BEKj46015811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2005 07:20:46 -0700 Message-ID: <434BCA0F.8030402@shockey.us> Date: Tue, 11 Oct 2005 10:19:59 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nieminen Klaus Subject: Re: [Enum] A proposal for Carrier ENUM References: <07BC6C0D40216E44A34BE6701694FE86018627E6@POSTI.laru.local> In-Reply-To: <07BC6C0D40216E44A34BE6701694FE86018627E6@POSTI.laru.local> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 2.2 (++) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1092142001==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1092142001== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Nieminen Klaus wrote: 
Penn, Michael and all, 

My message was that in most cases we do have the required information
available and I think that we should not focus on the implementation
details in this question. As Penn mentioned, I believe that these issues
can be solved.

However, there are cases that may cause problems and my question is:
Should we take also these cases into account in our work or do you think
that this is should more likely to be solved nationally?
Clearly these are national issues but this brings up the subject of how much information any ENUM registry should keep, carrier or public.

This a well known issue in classic domain registry operations ..the Thick vs Thin model of Registry. Time and Time again its has been conclusively shown that the maintance of a Thick Registry is in the long term best interests of all parties.

One of the things this WG has done is move forward IRIS EREG as a potential repository for information associated with a TN that might be useful to NRA -  LEA etc.

In the US ENUM TAC LLC requirements document we specified the use of IRIS for "Contact-Info"

http://enumllc.com/tac/docs/t1b/V7-052605_TAC_Tier1B-Reqs.doc

Penn is right .. the situation in Europe is complicated by the lack of independent registry data associated with a TN. Way too often the incumbent i is permitted to hold such data which complicates the process of NP.

It is clear that many European countries now realize the disadvantages of centeralized databases and are reconsidering their options. IMHO the Thick ENUM registry is the only way to go ..its only then a question of what data is necessary to keep centrally and how that data is protected by various privacy regulations etc.

NRA's looking at Carrier ENUM should consider carefully what requirements are necessary to maintain ligitimate centralzed ancillary data on a TN that might be useful in the future.




- Klaus -

-----Original Message-----
From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] 
Sent: 11. lokakuuta 2005 16:26
To: Nieminen Klaus; enum@ietf.org
Subject: RE: [Enum] A proposal for Carrier ENUM

Klaus:
Unfortunately not all portability implementations use network databases
(I assume it's network databases rather Rather than admin ones to which
you refer) Maybe some of those whose countries use "onward routing" etc.
can confirm whether there is any centralized database outside of the
network detailing those arrangements. 

Nonetheless, I do think that for the most part it will be possible to
determine who the carrier providing the PSTN point of interface for an
E.164 number is and thus the carrier-of-record for carrier ENUM. If this
information were not generally available the E.164 number would not be
of much use anyway. I could think of workarounds even in the
non-centralized LNP situations and, frankly, if those cause some pain,
if should be thought of in terms of penance for making an erroneous
choice with respect to the implementation of number portability. (:-)

The day may/should/will come when interconnection is all IP-based and
some form of ENUM Registry IS the database of record for number
assignment and then we can have a debate about what it means to be
carrier of record again, but for now the approach of using the entity
that provides the number assignment/PSTN PoI is, I think, quite
workable.

Penn Pfautz

-----Original Message-----
From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of
Nieminen Klaus
Sent: Tuesday, October 11, 2005 9:00 AM
To: enum@ietf.org
Subject: RE: [Enum] A proposal for Carrier ENUM

Hello, 

One clarification:

  
-----Original Message-----
From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf
    
Of Stastny Richard
  
Sent: 11. lokakuuta 2005 14:28
To: Antoin Verschuren; enum@ietf.org
Subject: RE: [Enum] A proposal for Carrier ENUM

    
In the private contract between the terminating party and number 
holder, the terminating party can simply insist that the contract is
      
only
  
valid (they can only offer the service) if the number holder enters
      
his 
  
numberblock in the Carier ENUM tree, delegating it to the terminating
      

  
party. The carrier ENUM tree is then simply the place where a 
carrier-of-record is defined, as the NRA does not have this
      
information.
  
Is it true that the NRA does not have this information?
    

At least in some cases NRAs do not have information about the network
that serves the numbers directly assigned to the users. I do not know,
if the same problem exists also for number ranges assigned to telcos,
but I assume that this may be tha case at least for numbers that are
further delegated to other service providers (e.g. Skype) by a contract.

For ported numbers I believe that all implementations involve the use of
databases that contain information on the network with which ported
numbers are associated. Therefore this should not be a problem.

regards,

- Klaus -
___________________________________________
KLAUS NIEMINEN
Senior Adviser
Finnish Communications Regulatory Authority Internet and Information
Security P.O. Box 313
FIN-00181 HELSINKI
FINLAND
tel.: +358 9 6966 634
fax: +358 9 6966 873
e-mail: klaus.nieminen@ficora.fi
www: http://www.ficora.fi


_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum

  


-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--===============1092142001== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1092142001==-- From enum-bounces@ietf.org Tue Oct 11 10:24:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPL3V-0002At-AN; Tue, 11 Oct 2005 10:24:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPL3T-0002AY-RQ for enum@megatron.ietf.org; Tue, 11 Oct 2005 10:24:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27404 for ; Tue, 11 Oct 2005 10:24:33 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPLDY-000285-MB for enum@ietf.org; Tue, 11 Oct 2005 10:35:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Enum] A proposal for Carrier ENUM Date: Tue, 11 Oct 2005 16:27:55 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B218A@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] A proposal for Carrier ENUM Thread-Index: AcXOaaYsUqNEZi+VTRmPmqdy0jftLQAAjidAAAB31i0AAG9gsA== From: "Stastny Richard" To: "Rosbotham, Paul" , , , X-Spam-Score: 1.1 (+) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0739843181==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============0739843181== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CE6F.F967F45B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CE6F.F967F45B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I could live with the definition Paul provided: =20 Carrier ENUM is a database populated by the carrier that provides the PSTN termination for the number in question. How this is achieved in detail is a national matter.=20 =20 Richard =20 ________________________________ From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Rosbotham, Paul Sent: Tuesday, October 11, 2005 4:12 PM To: ppfautz@att.com; lendl@nic.at; enum@ietf.org Subject: Re: [Enum] A proposal for Carrier ENUM =20 My view is that these type of issues are firmly in the category of "national matter". All that need be agreed at this level is the principle that the database be populated by the carrier that provides the PSTN termination for the number in question. How this is achieved is something which will vary by jurisdiction. As it happens, some places where onward routeing is used are considering usage of carrier ENUM to supersede the existing solution. Regards, Paul Rosbotham Manager, Interconnect Strategy & Technology Regulation Cable & Wireless plc Tel : +44 1772 451506 Mob : +44 7957 805573 -----Original Message----- From: enum-bounces@ietf.org To: Otmar Lendl ; enum@ietf.org Sent: Tue Oct 11 15:00:15 2005 Subject: RE: [Enum] A proposal for Carrier ENUM Otmar: Thanks. As long as the ported-to carrier is indicated in the NRA database that is enough for determining the carrier of record for carrier ENUM. Penn -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Otmar Lendl Sent: Tuesday, October 11, 2005 9:41 AM To: enum@ietf.org Subject: Re: [Enum] A proposal for Carrier ENUM On 2005/10/11 15:10, "Pfautz, Penn L, NEO" wrote: > > Maybe some of those whose > countries use "onward routing" etc. can confirm > whether there is any centralized database outside of the network > detailing those arrangements. Austria uses onward routing for fixed line NP. There is no centralized DB which shows which number has been ported to whom. The NRA only keeps tabs on what number have been ported, but this DB does not include the information necessary to route calls. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/=20 The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. ------_=_NextPart_001_01C5CE6F.F967F45B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Enum] A proposal for Carrier ENUM

I could live = with the definition Paul provided:

 =

Carrier ENUM is = a database populated by the carrier that provides the PSTN termination for = the number in question. How this is achieved in detail is a national matter. =

 =

Richard

 =

From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Rosbotham, Paul
Sent: Tuesday, October = 11, 2005 4:12 PM
To: ppfautz@att.com; = lendl@nic.at; enum@ietf.org
Subject: Re: [Enum] A = proposal for Carrier ENUM

 

My view is that these type of issues are firmly in the category of = "national matter".  All that need be agreed at this level is the = principle that the database be populated by the carrier that provides the PSTN = termination for the number in question.  How this is achieved is something which = will vary by jurisdiction.

As it happens, some places where onward routeing is used are considering = usage of carrier ENUM to supersede the existing solution.

Regards,


Paul Rosbotham
Manager, Interconnect Strategy & Technology Regulation
Cable & Wireless plc

Tel :   +44 1772 451506
Mob :   +44 7957 805573


-----Original Message-----
From: enum-bounces@ietf.org <enum-bounces@ietf.org>
To: Otmar Lendl <lendl@nic.at>; enum@ietf.org = <enum@ietf.org>
Sent: Tue Oct 11 15:00:15 2005
Subject: RE: [Enum] A proposal for Carrier ENUM

Otmar:
Thanks. As long as the ported-to carrier is indicated in the NRA
database that is enough for determining the carrier of record for
carrier ENUM.

Penn

-----Original Message-----
From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of
Otmar Lendl
Sent: Tuesday, October 11, 2005 9:41 AM
To: enum@ietf.org
Subject: Re: [Enum] A proposal for Carrier ENUM


On 2005/10/11 15:10, "Pfautz, Penn L, NEO" = <ppfautz@att.com> wrote:
>
>           &nb= sp;           &nbs= p;            = ;        Maybe some of those whose
> countries use "onward routing" etc. can confirm
> whether there is any centralized database outside of the = network
> detailing those arrangements.

Austria uses onward routing for fixed line NP. There is no = centralized
DB which shows which number has been ported to whom.

The NRA only keeps tabs on what number have been ported, but this
DB does not include the information necessary to route calls.

/ol
--
< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.or= g/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.or= g/mailman/listinfo/enum


This e-mail has been scanned for viruses by the Cable & Wireless = e-mail security system - powered by MessageLabs. For more information on a = proactive managed e-mail security service, visit = http://www.cw.com/uk/emailprotection/

The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) = named above. If you are not named above as a recipient, you must not read, = copy, disclose, forward or otherwise use the information contained in this = email. If you have received this e-mail in error, please notify the sender (whose = contact details are above) immediately by reply e-mail and delete the message = and any attachments without retaining any copies.

------_=_NextPart_001_01C5CE6F.F967F45B-- --===============0739843181== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0739843181==-- From enum-bounces@ietf.org Tue Oct 11 10:28:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPL7U-0004Fd-1g; Tue, 11 Oct 2005 10:28:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPL7R-0004FD-9A for enum@megatron.ietf.org; Tue, 11 Oct 2005 10:28:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27884 for ; Tue, 11 Oct 2005 10:28:38 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPLHV-0002JI-Rc for enum@ietf.org; Tue, 11 Oct 2005 10:39:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Enum] A proposal for Carrier ENUM Date: Tue, 11 Oct 2005 16:32:12 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B218B@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] A proposal for Carrier ENUM Thread-Index: AcXOb+ipi6y6n7d1SUy5AQgnVksXygAAEAmQ From: "Stastny Richard" To: "Richard Shockey" , "Nieminen Klaus" X-Spam-Score: 1.0 (+) X-Scan-Signature: ccea60a1a1487e87cca3105a45afd404 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1373471520==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1373471520== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CE70.92AADE83" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CE70.92AADE83 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, =20 I also agree with the additional statement from Paul and what Rich said =20 >As it happens, some places where onward routeing is used are considering usage of carrier ENUM to supersede the existing solution =20 And =20 >NRA's looking at Carrier ENUM should consider carefully what requirements are necessary to maintain ligitimate >centralzed ancillary data on a TN that might be useful in the future. =20 The Carrier ENUM Registry could very well evolve to such a database. =20 Richard =20 ________________________________ From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, October 11, 2005 4:20 PM To: Nieminen Klaus Cc: enum@ietf.org Subject: Re: [Enum] A proposal for Carrier ENUM =20 Nieminen Klaus wrote:=20 Penn, Michael and all,=20 =20 My message was that in most cases we do have the required information available and I think that we should not focus on the implementation details in this question. As Penn mentioned, I believe that these issues can be solved. =20 However, there are cases that may cause problems and my question is: Should we take also these cases into account in our work or do you think that this is should more likely to be solved nationally? =20 Clearly these are national issues but this brings up the subject of how much information any ENUM registry should keep, carrier or public. This a well known issue in classic domain registry operations ..the Thick vs Thin model of Registry. Time and Time again its has been conclusively shown that the maintance of a Thick Registry is in the long term best interests of all parties. One of the things this WG has done is move forward IRIS EREG as a potential repository for information associated with a TN that might be useful to NRA - LEA etc. In the US ENUM TAC LLC requirements document we specified the use of IRIS for "Contact-Info" http://enumllc.com/tac/docs/t1b/V7-052605_TAC_Tier1B-Reqs.doc Penn is right .. the situation in Europe is complicated by the lack of independent registry data associated with a TN. Way too often the incumbent i is permitted to hold such data which complicates the process of NP.=20 It is clear that many European countries now realize the disadvantages of centeralized databases and are reconsidering their options. IMHO the Thick ENUM registry is the only way to go ..its only then a question of what data is necessary to keep centrally and how that data is protected by various privacy regulations etc. NRA's looking at Carrier ENUM should consider carefully what requirements are necessary to maintain ligitimate centralzed ancillary data on a TN that might be useful in the future. =20 - Klaus - =20 -----Original Message----- From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com]=20 Sent: 11. lokakuuta 2005 16:26 To: Nieminen Klaus; enum@ietf.org Subject: RE: [Enum] A proposal for Carrier ENUM =20 Klaus: Unfortunately not all portability implementations use network databases (I assume it's network databases rather Rather than admin ones to which you refer) Maybe some of those whose countries use "onward routing" etc. can confirm whether there is any centralized database outside of the network detailing those arrangements.=20 =20 Nonetheless, I do think that for the most part it will be possible to determine who the carrier providing the PSTN point of interface for an E.164 number is and thus the carrier-of-record for carrier ENUM. If this information were not generally available the E.164 number would not be of much use anyway. I could think of workarounds even in the non-centralized LNP situations and, frankly, if those cause some pain, if should be thought of in terms of penance for making an erroneous choice with respect to the implementation of number portability. (:-) =20 The day may/should/will come when interconnection is all IP-based and some form of ENUM Registry IS the database of record for number assignment and then we can have a debate about what it means to be carrier of record again, but for now the approach of using the entity that provides the number assignment/PSTN PoI is, I think, quite workable. =20 Penn Pfautz =20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Nieminen Klaus Sent: Tuesday, October 11, 2005 9:00 AM To: enum@ietf.org Subject: RE: [Enum] A proposal for Carrier ENUM =20 Hello,=20 =20 One clarification: =20 =20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf =20 Of Stastny Richard =20 Sent: 11. lokakuuta 2005 14:28 To: Antoin Verschuren; enum@ietf.org Subject: RE: [Enum] A proposal for Carrier ENUM =20 =20 In the private contract between the terminating party and number=20 holder, the terminating party can simply insist that the contract is =20 only =20 valid (they can only offer the service) if the number holder enters =20 his=20 =20 numberblock in the Carier ENUM tree, delegating it to the terminating =20 =20 =20 party. The carrier ENUM tree is then simply the place where a=20 carrier-of-record is defined, as the NRA does not have this =20 information. =20 Is it true that the NRA does not have this information? =20 =20 At least in some cases NRAs do not have information about the network that serves the numbers directly assigned to the users. I do not know, if the same problem exists also for number ranges assigned to telcos, but I assume that this may be tha case at least for numbers that are further delegated to other service providers (e.g. Skype) by a contract. =20 For ported numbers I believe that all implementations involve the use of databases that contain information on the network with which ported numbers are associated. Therefore this should not be a problem. =20 regards, =20 - Klaus - ___________________________________________ KLAUS NIEMINEN Senior Adviser Finnish Communications Regulatory Authority Internet and Information Security P.O. Box 313 FIN-00181 HELSINKI FINLAND tel.: +358 9 6966 634 fax: +358 9 6966 873 e-mail: klaus.nieminen@ficora.fi www: http://www.ficora.fi =20 =20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum =20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum =20 =20 --=20 =20 =20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or=20 =20 ; =20 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<=20 ------_=_NextPart_001_01C5CE70.92AADE83 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes,

 

I also agree = with the additional statement from Paul and what Rich = said

 =

>As it happens, some places = where onward routeing is used are considering usage of carrier ENUM to supersede the existing solution

 

And

 

>NRA's looking at Carrier = ENUM should consider carefully what requirements are necessary to maintain = ligitimate >centralzed ancillary data on a TN that might be useful in the = future.

 

The Carrier ENUM Registry could = very well evolve to such a database.

 

Richard

 =

From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On = Behalf Of Richard Shockey
Sent: Tuesday, October = 11, 2005 4:20 PM
To: Nieminen Klaus
Cc: enum@ietf.org
Subject: Re: [Enum] A = proposal for Carrier ENUM

 

Nieminen Klaus wrote: = 

Penn, Michael and all, =

 
My message was that in most cases we do have =
the required information
available and I think that we should not =
focus on the implementation
details in this question. As Penn mentioned, =
I believe that these issues
can be =
solved.
 
However, there are cases that may cause =
problems and my question is:
Should we take also these cases into account =
in our work or do you think
that this is should more likely to be solved =
nationally?
 

Clearly these are national issues but this = brings up the subject of how much information any ENUM registry should keep, = carrier or public.

This a well known issue in classic domain registry operations ..the = Thick vs Thin model of Registry. Time and Time again its has been conclusively = shown that the maintance of a Thick Registry is in the long term best = interests of all parties.

One of the things this WG has done is move forward IRIS EREG as a = potential repository for information associated with a TN that might be useful to = NRA -  LEA etc.

In the US ENUM TAC LLC requirements document we specified the use of = IRIS for "Contact-Info"

ht= tp://enumllc.com/tac/docs/t1b/V7-052605_TAC_Tier1B-Reqs.doc

Penn is right .. the situation in Europe is complicated by the lack of independent registry data associated with a TN. Way too often the = incumbent i is permitted to hold such data which complicates the process of NP.

It is clear that many European countries now realize the disadvantages = of centeralized databases and are reconsidering their options. IMHO the = Thick ENUM registry is the only way to go ..its only then a question of what data = is necessary to keep centrally and how that data is protected by various = privacy regulations etc.

NRA's looking at Carrier ENUM should consider carefully what = requirements are necessary to maintain ligitimate centralzed ancillary data on a TN that = might be useful in the future.





 
- Klaus =
-
 
-----Original =
Message-----
From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] =

Sent: 11. lokakuuta 2005 =
16:26
To: Nieminen Klaus; enum@ietf.org<=
/pre>
Subject: RE: [Enum] A proposal for Carrier =
ENUM
 
Klaus:
Unfortunately not all portability =
implementations use network =
databases
(I assume it's network databases rather =
Rather than admin ones to which
you refer) Maybe some of those whose =
countries use "onward routing" =
etc.
can confirm whether there is any centralized =
database outside of the
network detailing those arrangements. =

 
Nonetheless, I do think that for the most =
part it will be possible to
determine who the carrier providing the PSTN =
point of interface for an
E.164 number is and thus the =
carrier-of-record for carrier ENUM. If =
this
information were not generally available the =
E.164 number would not be
of much use anyway. I could think of =
workarounds even in the
non-centralized LNP situations and, frankly, =
if those cause some pain,
if should be thought of in terms of penance =
for making an erroneous
choice with respect to the implementation of =
number portability. (:-)
 
The day may/should/will come when =
interconnection is all IP-based =
and
some form of ENUM Registry IS the database of =
record for number
assignment and then we can have a debate =
about what it means to be
carrier of record again, but for now the =
approach of using the entity
that provides the number assignment/PSTN PoI =
is, I think, quite
workable.
<=
font
size=3D2 color=3Dblack face=3D"Courier New"> 
Penn =
Pfautz
 
-----Original =
Message-----
From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] =
On Behalf Of
Nieminen =
Klaus
Sent: Tuesday, October 11, 2005 9:00 =
AM
To: enum@ietf.org<=
/pre>
Subject: RE: [Enum] A proposal for Carrier =
ENUM
 
Hello, =

 
One =
clarification:
 
  



-----Original =
Message-----
From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] =
On Behalf
    =




Of Stastny =
Richard
  



Sent: 11. lokakuuta 2005 =
14:28
To: Antoin Verschuren; enum@ietf.org<=
/pre>
Subject: RE: [Enum] A proposal for Carrier =
ENUM
 
    =




In the private contract between the =
terminating party and number 
holder, the terminating party can simply =
insist that the contract is
      =







only
  






valid (they can only offer the service) if =
the number holder enters
      =







his 
  






numberblock in the Carier ENUM tree, =
delegating it to the =
terminating
      =







 
  






party. The carrier ENUM tree is then simply =
the place where a 
carrier-of-record is defined, as the NRA does =
not have this
      =







information.
  



Is it true that the NRA does not have this =
information?
    =




 
At least in some cases NRAs do not have =
information about the network
that serves the numbers directly assigned to =
the users. I do not know,
if the same problem exists also for number =
ranges assigned to telcos,
but I assume that this may be tha case at =
least for numbers that are
further delegated to other service providers =
(e.g. Skype) by a contract.
 
For ported numbers I believe that all =
implementations involve the use =
of
databases that contain information on the =
network with which ported
numbers are associated. Therefore this should =
not be a problem.
 
regards,
 
- Klaus =
-
___________________________________________
KLAUS =
NIEMINEN
Senior =
Adviser
Finnish Communications Regulatory Authority =
Internet and Information
Security P.O. Box =
313
FIN-00181 =
HELSINKI
FINLAND
tel.: +358 9 6966 =
634
fax: +358 9 6966 =
873
e-mail: klaus.nieminen@ficora.fi
www: http://www.ficora.fi<=
/font>
 
 
______________________________________________=
_
enum mailing =
list
enum@ietf.org<=
/pre>
https://www1.ietf.or=
g/mailman/listinfo/enum
 
______________________________________________=
_
enum mailing =
list
enum@ietf.org<=
/pre>
https://www1.ietf.or=
g/mailman/listinfo/enum
 
  













-- 
 
 
>>>>>>>>>>>&g=
t;>>>>>>>>>>>>>>>>>>=
;>>>>>>>>>>>>>>>>>>=
>>>>> 
Richard Shockey, Director - Member of =
Technical Staff
NeuStar =
Inc.
46000 Center Oak Plaza  -   =
Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM =
+87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 =
703.593.2683
Fax: +1 =
815.333.1237
<mailto:richard(at)shockey.us>=
; or 
<mailto:richard.shockey=
(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<&l=
t;<<<<<<<<<<<<<<<<<<=
;<<<<<<<<<<<<<<<<<<=
<<<<< 
------_=_NextPart_001_01C5CE70.92AADE83-- --===============1373471520== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1373471520==-- From enum-bounces@ietf.org Tue Oct 11 10:35:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLDl-00070g-Fl; Tue, 11 Oct 2005 10:35:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLDj-00070b-Az for enum@megatron.ietf.org; Tue, 11 Oct 2005 10:35:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28420 for ; Tue, 11 Oct 2005 10:35:08 -0400 (EDT) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPLNq-0002VF-6d for enum@ietf.org; Tue, 11 Oct 2005 10:45:39 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 99F531A3DA; Tue, 11 Oct 2005 16:35:00 +0200 (CEST) Date: Tue, 11 Oct 2005 16:35:00 +0200 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] A proposal for Carrier ENUM Message-ID: <20051011143500.GB1196@nic.at> References: <34DA635B184A644DA4588E260EC0A25A0B4AFF8D@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0B4AFF8D@ACCLUST02EVS1.ugd.att.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 2005/10/11 16:10, "Pfautz, Penn L, NEO" wrote: > Otmar: > Thanks. As long as the ported-to carrier is indicated in the NRA > database that is enough for determining the carrier of record for > carrier ENUM. >From what I've heard from our NRA, they just use a flag "This number has been ported", but they do not keep track on where the number was ported to. So they have no idea who the carrier of record is for ported numbers. (Don't ask me why they do it this way. I don't get it, too.) /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 10:45:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLNS-0001k4-Gu; Tue, 11 Oct 2005 10:45:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLNO-0001iX-Vs for enum@megatron.ietf.org; Tue, 11 Oct 2005 10:45:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29017 for ; Tue, 11 Oct 2005 10:45:07 -0400 (EDT) Received: from cyclone.wcom.co.uk ([193.131.254.139] helo=cyclone.emea.mci.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPLXU-0002nj-0F for enum@ietf.org; Tue, 11 Oct 2005 10:55:37 -0400 Received: from localhost ([127.0.0.1] helo=cyclone.emea.mci.com) by cyclone.emea.mci.com with esmtp (Exim 4.42) id 1EPLMm-0000xS-Qr; Tue, 11 Oct 2005 14:44:35 +0000 Received: from breen.emea.mci.com (borasco [170.127.64.31]) by cyclone.emea.mci.com (4.7.0.120) with ESMTP id ; Tue, 11 Oct 2005 15:44:24 +0100 (BST) Received: from ms-lon-exgw01.uk.mcilink.com ([170.127.78.40]) by breen.emea.mci.com with esmtp (Exim 4.42) id 1EPLMe-0000bc-F8; Tue, 11 Oct 2005 14:44:24 +0000 Received: by ms-lon-exgw01.uk.mcilink.com with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Oct 2005 15:44:23 +0100 Message-ID: From: "Lupton, Ronan" To: "'Klaus.Nieminen@ficora.fi'" , "'enum@ietf.org'" Subject: Re: [Enum] A proposal for Carrier ENUM Date: Tue, 11 Oct 2005 15:44:17 +0100 X-Mailer: Internet Mail Service (5.5.2657.72) MIME-Version: 1.0 (Generated by NET-TEL Mailguard SMTP version 4.0.1.40) X-MCI-EMEA-Spam-Score: -98.0 (---------------------------------------------------) X-MCI-EMEA-Signature: c96550aa8acb36ef8b3468b9bd9ffda9 X-Spam-Score: 0.5 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0960769436==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@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. --===============0960769436== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CE72.41A9C8B4" 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_01C5CE72.41A9C8B4 Content-Type: text/plain Klaus, Rick, Richard, Maybe NRAs don't have detailed numbering data, for the purposes of daily admin. But at least they will have administrative or strategic visibility and statistics on national porting activities and know who donors and recipients of numbers are, exactly. In the EU 25 countries the European New Electronic Communications Regulatory Framework directive and Universal Service directives mandate the NRA ownership of national numbering resources along with the national administrations. Provisions are in built to the USO directive recitals 40 to 42 and Article 30 is where you can find the suite of porting reference data. Note the consumer aspects and pro competitive aspects of same. >From a PSTN point of view, both databases and onward routing can unilaterally or co-exist. These decisions are historically entrenched in administration matters including numbering policy and costs of implementation at a national, fixed line and mobile/GSM level. For ENUM and its origins at the beginning, my understanding is that if was derived in order to assist with Number and address portability in the Swedish market. This discussion might assist in a numbering administration and spectrum tidy up. E.g. ENUM early days. I can send these directives out for your perusal if you like. Ronan Lupton MCI International Regulatory Affairs. -----Original Message----- From: enum-bounces@ietf.org To: enum@ietf.org Sent: Tue Oct 11 14:57:23 2005 Subject: RE: [Enum] A proposal for Carrier ENUM In most CEPT countries MNP is implemented using centralised NP databases. These are typically managed by a consortia of network operators, so NRAs may not have any information about ported numbers. Well, I think that this fact is not very important. At least also Malta and Cyprus has distributed MNP databases, but does this mean that the validation information is not available or is it possible to gather the required data from multiple databases maintained by different operators? regards, - Klaus - -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Otmar Lendl Sent: 11. lokakuuta 2005 16:41 To: enum@ietf.org Subject: Re: [Enum] A proposal for Carrier ENUM On 2005/10/11 15:10, "Pfautz, Penn L, NEO" wrote: > > Maybe some of those whose > countries use "onward routing" etc. can confirm whether there is any > centralized database outside of the network detailing those > arrangements. Austria uses onward routing for fixed line NP. There is no centralized DB which shows which number has been ported to whom. The NRA only keeps tabs on what number have been ported, but this DB does not include the information necessary to route calls. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01C5CE72.41A9C8B4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Re: [Enum] A proposal for Carrier ENUM

Klaus, Rick, Richard,

Maybe NRAs don't have detailed numbering data, for = the purposes of daily admin.

But at least they will have administrative or = strategic visibility and statistics on national porting activities and = know who donors and recipients of numbers are, exactly.

In the EU 25 countries the European New Electronic = Communications Regulatory Framework directive and Universal Service = directives mandate the NRA ownership of national numbering resources = along with the national administrations.

Provisions are in built to the USO directive recitals = 40 to 42 and Article 30 is where you can find the suite of porting = reference data.

Note the consumer aspects and pro competitive aspects = of same.

From a PSTN point of view, both databases and onward = routing can unilaterally or co-exist. These decisions are historically = entrenched in administration matters including numbering policy and = costs of implementation at a national, fixed line and mobile/GSM = level.

For ENUM and its origins at the beginning, my = understanding is that if was derived in order to assist with Number and = address portability in the Swedish market.

This discussion might assist in a numbering = administration and spectrum tidy up. E.g. ENUM early days.

I can send these directives out for your perusal if = you like.

Ronan Lupton

MCI International Regulatory Affairs.




-----Original Message-----
From: enum-bounces@ietf.org = <enum-bounces@ietf.org>
To: enum@ietf.org <enum@ietf.org>
Sent: Tue Oct 11 14:57:23 2005
Subject: RE: [Enum] A proposal for Carrier = ENUM

In most CEPT countries MNP is implemented using = centralised NP
databases. These are typically managed by a = consortia of network
operators, so NRAs may not have any information = about ported numbers.
Well, I think that this fact is not very = important.

At least also Malta and Cyprus has distributed MNP = databases, but does
this mean that the validation information is not = available or is it
possible to gather the required data from multiple = databases maintained
by different operators?

regards,

- Klaus -

-----Original Message-----
From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] = On Behalf Of
Otmar Lendl
Sent: 11. lokakuuta 2005 16:41
To: enum@ietf.org
Subject: Re: [Enum] A proposal for Carrier = ENUM


On 2005/10/11 15:10, "Pfautz, Penn L, NEO" = <ppfautz@att.com> wrote:
>
>          = ;            = ;            = ;          Maybe some of = those whose
> countries use "onward routing" etc. = can confirm whether there is any
> centralized database outside of the network = detailing those
> arrangements.

Austria uses onward routing for fixed line NP. There = is no centralized
DB which shows which number has been ported to = whom.

The NRA only keeps tabs on what number have been = ported, but this DB
does not include the information necessary to route = calls.

/ol
--
< Otmar Lendl (lendl@nic.at) | nic.at Systems = Engineer >

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum=

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum=

------_=_NextPart_001_01C5CE72.41A9C8B4-- --===============0960769436== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0960769436==-- From enum-bounces@ietf.org Tue Oct 11 10:47:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLQ7-0002ie-97; Tue, 11 Oct 2005 10:47:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLQ5-0002gQ-9R for enum@megatron.ietf.org; Tue, 11 Oct 2005 10:47:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29164 for ; Tue, 11 Oct 2005 10:47:54 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPLaC-0002sE-5D for enum@ietf.org; Tue, 11 Oct 2005 10:58:25 -0400 Received: from [10.31.13.171] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9BEmLVL018709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2005 07:48:23 -0700 Message-ID: <434BD088.7020301@shockey.us> Date: Tue, 11 Oct 2005 10:47:36 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Otmar Lendl Subject: Re: [Enum] A proposal for Carrier ENUM References: <34DA635B184A644DA4588E260EC0A25A0B4AFF8D@ACCLUST02EVS1.ugd.att.com> <20051011143500.GB1196@nic.at> In-Reply-To: <20051011143500.GB1196@nic.at> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.4 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0863422800==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0863422800== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Otmar Lendl wrote: 
On 2005/10/11 16:10, "Pfautz, Penn L, NEO" <ppfautz@att.com> wrote:
  
Otmar:
Thanks. As long as the ported-to carrier is indicated in the NRA
database that is enough for determining the carrier of record for
carrier ENUM.
    

>From what I've heard from our NRA, they just use a flag "This number
has been ported", but they do not keep track on where the number
was ported to.

So they have no idea who the carrier of record is for ported numbers.

(Don't ask me why they do it this way. I don't get it, too.)
Ask the incumbent Austrian Carrier. :-)   I know why they want it that way ...there isnt an incumbent carrier on the face of planet Earth that likes Number Portability and none of them wants to make it easier to implement or maintain.
/ol
  


-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--===============0863422800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0863422800==-- From enum-bounces@ietf.org Tue Oct 11 10:53:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLVe-000464-HJ; Tue, 11 Oct 2005 10:53:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLVc-00045l-Pf for enum@megatron.ietf.org; Tue, 11 Oct 2005 10:53:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29818 for ; Tue, 11 Oct 2005 10:53:38 -0400 (EDT) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPLfj-0003A5-Fh for enum@ietf.org; Tue, 11 Oct 2005 11:04:08 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id DC9021A3C1; Tue, 11 Oct 2005 16:53:29 +0200 (CEST) Date: Tue, 11 Oct 2005 16:53:29 +0200 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-validation-token-00.txt Message-ID: <20051011145329.GC1196@nic.at> References: <20051011092519.GA30739@nic.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 2005/10/11 16:10, Peter Williams wrote: > > We tend to think of digital signatures as Ron Rivest first characterized > them, for RSA: replacement for contract signing, where email text (or > html/xml) plays the role of the piece of paper bearing the contract terms. > Anyone can verify the signature, as such openness of usage is part of the > signature function: acknowledge that real people having signed terms on > paper, forming agreement ands contracts, so disputes are handled using > normal social processes involving evidence and proof of signing intent. > > In the case of RSA-based certs, DESMAC-based OCSP responses and other > crypto-based signing technologies, which can implement Validation Tokens, > we may or may not wish the signed token to be a "public" object, that > anyone can verify as a proof of something having occured: e,g. validation > of the E.164<->d-n identity. > > The term "token" implied to me (given ISO uses this term carefully) that we > were not intending the object to serve as a proof object (which assumes > public proving processes), but - like an SSL signed token for client auth - > its signature may be designed for only one party to consume, in the context > of earlier protocol exchanges. My draft does not specify what which algorithm of XML DSIG MUST be used, though it suggests RSA-SHA1. So basically the openess of the Token can vary depeding on the crypto used: * SHA-1 with a shared symmetrical key: Only Registry and VE can validate the signature * RSA-SHA1 without a PKI infrastructure: Everybody can verify the correctness of the signature, but needs external information on whether that signature should be trusted. * RSA-SHA1 with a PKI If the Token is signed with a VE-key whose (included) cert is signed by the NRA's CA-key, then no external info (except that CA-cert) is needed to test and judge a Token. Right now, we opted for the second option for User ENUM in Austria. What other word would you use to describe our Tokens? > Ill read the architecture draft next. Whats in my mind is understanding the > type of validation infrastructure that is being planned; and, whether there > is any difference in the deployement models of the Validation > Infrastrcuture for the User vs Carrier ENUM cases - given we now have the > Carrier ENUM variant to address in the security model. We developed our validation model for the User ENUM case. As you note, Carrier ENUM has different requirements which may well lead to a different solution. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 10:55:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLXT-0004rd-EA; Tue, 11 Oct 2005 10:55:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLXR-0004r5-Jt for enum@megatron.ietf.org; Tue, 11 Oct 2005 10:55:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00225 for ; Tue, 11 Oct 2005 10:55:31 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPLhY-0003KW-EV for enum@ietf.org; Tue, 11 Oct 2005 11:06:01 -0400 Received: from [10.31.13.171] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9BEtxdR019595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2005 07:56:00 -0700 Message-ID: <434BD251.1040505@shockey.us> Date: Tue, 11 Oct 2005 10:55:13 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Shockey Subject: Re: [Enum] A proposal for Carrier ENUM - Oops References: <07BC6C0D40216E44A34BE6701694FE86018627E6@POSTI.laru.local> <434BCA0F.8030402@shockey.us> In-Reply-To: <434BCA0F.8030402@shockey.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Nieminen Klaus X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > > > In the US ENUM TAC LLC requirements document we specified the use of > IRIS for "Contact-Info" > > http://enumllc.com/tac/docs/t1b/V7-052605_TAC_Tier1B-Reqs.doc > > Penn is right .. the situation in Europe is complicated by the lack of > independent registry data associated with a TN. Way too often the > incumbent i is permitted to hold such data which complicates the > process of NP. > > It is clear that many European countries now realize the disadvantages > of centeralized databases and are reconsidering their options. IMHO > the Thick ENUM registry is the only way to go ..its only then a > question of what data is necessary to keep centrally and how that data > is protected by various privacy regulations etc. Oops ..I meant many countries ( and incumbents ) now realize the _advantages_ of centralized databases for Number Portability and NRA's are reconsidering their options. The fact is that call forwarding aka "onward routing" eventually places an unacceptable burden on the incumbents infrastructure. The PSTN is beginning to learn what the Internet knew from the beginning is that you need a formal abstraction between naming ( the TN ) and network addressing ( the routing number) and that the PSTN needs to evolve to a "all call query" model. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 11:09:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLky-0003E4-LR; Tue, 11 Oct 2005 11:09:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLkw-0003DU-A8 for enum@megatron.ietf.org; Tue, 11 Oct 2005 11:09:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04465 for ; Tue, 11 Oct 2005 11:09:27 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPLv3-0004wf-4h for enum@ietf.org; Tue, 11 Oct 2005 11:19:58 -0400 Received: from [10.31.13.171] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9BF9ljH021704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2005 08:09:50 -0700 Message-ID: <434BD58C.3090906@shockey.us> Date: Tue, 11 Oct 2005 11:09:00 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Lupton, Ronan" Subject: Re: [Enum] A proposal for Carrier ENUM References: In-Reply-To: X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.7 (+) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: "'enum@ietf.org'" , "'Klaus.Nieminen@ficora.fi'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0144727431==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0144727431== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Lupton, Ronan wrote:
Re: [Enum] A proposal for Carrier ENUM

Klaus, Rick, Richard,

Maybe NRAs don't have detailed numbering data, for the purposes of daily admin.

But at least they will have administrative or strategic visibility and statistics on national porting activities and know who donors and recipients of numbers are, exactly.

In the EU 25 countries the European New Electronic Communications Regulatory Framework directive and Universal Service directives mandate the NRA ownership of national numbering resources along with the national administrations.

Provisions are in built to the USO directive recitals 40 to 42 and Article 30 is where you can find the suite of porting reference data.

But without Thick Registries of data NP is very difficult to maintain or adminster. There is a wide body of experience on this matter  in the US and Canada as you well know. The centralized database system here works, works well and has proven to have enormous advantages to carriers that they did not immediately realize such as fast technology upgrading and "network grooming" of switch resources. The EU needs to reckgonize this ..especially now with emerging ENUM adminstrations.

Note the consumer aspects and pro competitive aspects of same.

From a PSTN point of view, both databases and onward routing can unilaterally or co-exist. These decisions are historically entrenched in administration matters including numbering policy and costs of implementation at a national, fixed line and mobile/GSM level.

Well ..its really a cost issue first ..some one has to pay for centralized databases. Second incumbents do not like LNP, never have and never will. NRA's simply have to put their foot down and demand compliance.

For ENUM and its origins at the beginning, my understanding is that if was derived in order to assist with Number and address portability in the Swedish market.

Yes ..that was Patrik's first thought on the matter ....long long ago.

This discussion might assist in a numbering administration and spectrum tidy up. E.g. ENUM early days.

I can send these directives out for your perusal if you like.

URL's might be useful here ...but again I'm emphasizing the critical requirement for Thick ENUM Registries irrespective of its use in Public or Carrier only environments.

Build it right the first time and you save the industry and the regulators huge headache's in the future.

This, of course, leads to one of my favorite topics which is standardized provisioning interfaces to the ENUM registries.

Nothing will work if you cant get the data into the ENUM Registry in the first place.

Ronan Lupton

MCI International Regulatory Affairs. 




-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--===============0144727431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0144727431==-- From enum-bounces@ietf.org Tue Oct 11 11:13:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLp5-0005dB-3q; Tue, 11 Oct 2005 11:13:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLp3-0005ct-94 for enum@megatron.ietf.org; Tue, 11 Oct 2005 11:13:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05938 for ; Tue, 11 Oct 2005 11:13:42 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPLzA-0005WB-3k for enum@ietf.org; Tue, 11 Oct 2005 11:24:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Oct 2005 17:17:19 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B218D@oefeg-s04.oefeg.loc> Thread-Topic: Validation of Carriers Thread-Index: AcXOcxAhgquxwhl7SlmxhUhqRgfB2wAAYVjA From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Subject: [Enum] Validation of Carriers X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi all, The basic question here is validation of carriers I am not sure if this is a problem at all in Carrier ENUM In User ENUM validation this is an issue to keep ENUM delegations in sync with the existing assignment of E.164 on the PSTN. It is common practice in all ENUM trials that the optimal validation=20 method is the one where the carrier hosting the number is validating=20 the user request. All other methods are considered clumsy workarounds if the carrier is not co-operating. Nobody has ever raised the issue how the carrier is validated in the first place. Q1. Why should a carrier not be trusted in Carrier ENUM in the first place also? Q2. What is the incentive why a carrier should enter wrong data on purpose? and=20 Q3. What is the threat if a carrier enters data wrongly erroneously? Ad Q2 may only happen if there are termination charges and a carrier may hijack calls to charge higher termination charges than he has to pay to finally deliver the call (arbitrage). National regulation may not allow this and provide sanctions. Ad Q3: This may happen, but will immediately be detected by the carrier itself if he receives the first call to this number and not serving it, or it may be detected by the registry if the real serving carrier wants to enter his data. IMHO these problems can be solved easily by a code of practice Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 11:22:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLxT-0005Gx-Jl; Tue, 11 Oct 2005 11:22:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLxR-0005AR-47 for enum@megatron.ietf.org; Tue, 11 Oct 2005 11:22:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09019 for ; Tue, 11 Oct 2005 11:22:22 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPM7Y-0006jj-Ph for enum@ietf.org; Tue, 11 Oct 2005 11:32:53 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-4.tower-121.messagelabs.com!1129044111!6379989!13 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 11948 invoked from network); 11 Oct 2005 15:22:12 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-4.tower-121.messagelabs.com with SMTP; 11 Oct 2005 15:22:12 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 432D90320052B103; Tue, 11 Oct 2005 11:22:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Validation of Carriers Date: Tue, 11 Oct 2005 11:22:10 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0B4B01AF@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Enum] Validation of Carriers Thread-Index: AcXOcxAhgquxwhl7SlmxhUhqRgfB2wAAYVjAAACjiCA= From: "Pfautz, Penn L, NEO" To: "Stastny Richard" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard; I agree that the validation problem is less an issue for carrier ENUM. In the USA, for example, on can simply task the Registry to verify carrier of record based on the Local Exchange Routing Guide and Number Portability Administration databases and you're done. And our fine legal system will ensure that any carrier that tries to game the system will be hung out to dry... Penn -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Stastny Richard Sent: Tuesday, October 11, 2005 11:17 AM To: enum@ietf.org Subject: [Enum] Validation of Carriers Hi all, The basic question here is validation of carriers I am not sure if this is a problem at all in Carrier ENUM In User ENUM validation this is an issue to keep ENUM delegations in sync with the existing assignment of E.164 on the PSTN. It is common practice in all ENUM trials that the optimal validation=20 method is the one where the carrier hosting the number is validating=20 the user request. All other methods are considered clumsy workarounds if the carrier is not co-operating. Nobody has ever raised the issue how the carrier is validated in the first place. Q1. Why should a carrier not be trusted in Carrier ENUM in the first place also? Q2. What is the incentive why a carrier should enter wrong data on purpose? and=20 Q3. What is the threat if a carrier enters data wrongly erroneously? Ad Q2 may only happen if there are termination charges and a carrier may hijack calls to charge higher termination charges than he has to pay to finally deliver the call (arbitrage). National regulation may not allow this and provide sanctions. Ad Q3: This may happen, but will immediately be detected by the carrier itself if he receives the first call to this number and not serving it, or it may be detected by the registry if the real serving carrier wants to enter his data. IMHO these problems can be solved easily by a code of practice Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 11:29:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPM3p-0002T8-6q; Tue, 11 Oct 2005 11:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPM3n-0002QJ-An for enum@megatron.ietf.org; Tue, 11 Oct 2005 11:28:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09512 for ; Tue, 11 Oct 2005 11:28:56 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPMDu-0006y7-IV for enum@ietf.org; Tue, 11 Oct 2005 11:39:27 -0400 Received: from [10.31.13.171] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9BFTQrR024177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2005 08:29:28 -0700 Message-ID: <434BDA29.8090008@shockey.us> Date: Tue, 11 Oct 2005 11:28:41 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] Validation of Carriers References: <32755D354E6B65498C3BD9FD496C7D461B218D@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B218D@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Stastny Richard wrote: >Ad Q3: This may happen, but will immediately be detected by the carrier >itself if he receives the first call to this number and not serving it, >or it may be detected by the registry if the real serving carrier wants >to enter his data. > >IMHO these problems can be solved easily by a code of practice. > > Well I would go much further than a simple code of practice ...this should be a function of the contract between Carrier ENUM Registry and Carrier ENUM Registrar (aka the carriers themselves). In the case of LNP in North America there is an extensive contract between the carriers and the NPAC which defines the terms and conditions for use of data and spells out in some detail what are the policies and underlying dispute resolution procedures are. In practice it works remarkably well with little or no problem. >Richard > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum > > > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 11:33:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPM8Y-0005S8-NX; Tue, 11 Oct 2005 11:33:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPM8X-0005Ol-1x for enum@megatron.ietf.org; Tue, 11 Oct 2005 11:33:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09815 for ; Tue, 11 Oct 2005 11:33:50 -0400 (EDT) Received: from www.nona.net ([193.80.224.122] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPMIe-000751-DF for enum@ietf.org; Tue, 11 Oct 2005 11:44:21 -0400 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by kahua with esmtp; Tue, 11 Oct 2005 17:33:05 +0200 id 0001BF86.434BDB31.0000293C Message-ID: <434BDB1E.7070407@enum.at> Date: Tue, 11 Oct 2005 17:32:46 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: "Pfautz, Penn L, NEO" Subject: Re: [Enum] Validation of Carriers References: <34DA635B184A644DA4588E260EC0A25A0B4B01AF@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0B4B01AF@ACCLUST02EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Pfautz, Penn L, NEO wrote: > In the USA, for example, on can simply task the > Registry to verify carrier of record based on the Local Exchange Routing > Guide and Number Portability Administration databases and you're done. > And our fine legal system will ensure that any carrier that tries to > game the system will be hung out to dry... i agree: I think that registries could be fine with regular "sanity-check" level validation based on comparing the ENUM database with other sources - probably even only for a randomly chosen sample of the numbers. Then, Any carrier that tries to break the rules of the game might risk being banned of the game... (or, probably, the checked samples will include all his numbers before that happens) Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 14:06:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPOWg-0004Pp-H5; Tue, 11 Oct 2005 14:06:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPOWf-0004Pd-1n; Tue, 11 Oct 2005 14:06:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18958; Tue, 11 Oct 2005 14:06:55 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPOgn-0003CY-Lc; Tue, 11 Oct 2005 14:17:27 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9BI6iCc021075; Tue, 11 Oct 2005 11:06:44 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9BI6iOO021074; Tue, 11 Oct 2005 11:06:44 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 11 Oct 2005 11:06:44 -0700 From: David Meyer To: voipeer@lists.uoregon.edu Message-ID: <20051011180644.GA21053@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: enum@ietf.org, sipping@ietf.org, jon.peterson@neustar.biz, mankin@psg.com Subject: [Enum] voipeer agenda/charter uploaded X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1067751477==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1067751477== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Please see http://www3.ietf.org/proceedings/05nov/agenda/voipeer.txt Note that the bulk of our session will be devoted to hammering out our charter (charter bashing). Thanks, Dave --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDS/80ORgD1qCZ2KcRAvnIAJ9BdCX3OcW5a1xSPkqcWUu4ai19/QCfecIq DM5aBdG9OhBrb2wqAT1BwFw= =ld7d -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- --===============1067751477== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1067751477==-- From enum-bounces@ietf.org Tue Oct 11 15:04:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPPPw-0005Bh-Dm; Tue, 11 Oct 2005 15:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPPPu-0005Aq-38 for enum@megatron.ietf.org; Tue, 11 Oct 2005 15:04:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22599 for ; Tue, 11 Oct 2005 15:03:59 -0400 (EDT) Received: from bay103-f1.bay103.hotmail.com ([65.54.174.11] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPPa1-0004tB-Tn for enum@ietf.org; Tue, 11 Oct 2005 15:14:32 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 11 Oct 2005 12:03:49 -0700 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Tue, 11 Oct 2005 19:03:48 GMT X-Originating-IP: [71.140.80.125] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <20051011180644.GA21053@1-4-5.net> From: "Peter Williams" To: enum@ietf.org Subject: RE: [Enum] voipeer agenda/charter uploaded Date: Tue, 11 Oct 2005 12:03:48 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 11 Oct 2005 19:03:49.0244 (UTC) FILETIME=[834153C0:01C5CE96] X-Spam-Score: 1.5 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org FROM Proposed VIOPEER Charter: "Routing fo sessions which are not signaled using SIP. In particular, voipeer is constrained to consider only those scenarios in which call routing is signaled using the SIP protocol and addressed by SIP or SIPS URIs or E.164 (public telephone number) addresses. By extension, national and private formats numbering formats are out of scope for voipeer" ENUM has broader scope, including H.323 URLs. ENUM Charter needs to be session protocol agnostic, in essence. So its the architectural support for multiple session/setup protocols thats required, not any particular love of H.323. Interaction between ENUM and VIOP peering must be only in the generic areas, not SIP-specific areas. I see no reason why ENUM should not be optionally "tuned" for today's SIP, but not "architected" for SIP. There is little doubt that E.164 and ENUM will, given their role, be around far longer than SIP will be. All private and national number formats (that are conforming to E.164 ) are within the scope of ENUM. In essence, ENUM is not just a name server for today's SIP proxies. It has a bigger role to play in the Internet. At the same time, it should play in today's adoption space! >From: David Meyer >To: voipeer@lists.uoregon.edu >CC: enum@ietf.org, sipping@ietf.org, jon.peterson@neustar.biz, >mankin@psg.com >Subject: [Enum] voipeer agenda/charter uploaded >Date: Tue, 11 Oct 2005 11:06:44 -0700 > > > Please see > > http://www3.ietf.org/proceedings/05nov/agenda/voipeer.txt > > Note that the bulk of our session will be devoted to > hammering out our charter (charter bashing). > > Thanks, > > Dave ><< attach4 >> >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 15:13:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPPZL-0007gy-R5; Tue, 11 Oct 2005 15:13:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPPZI-0007gh-SV for enum@megatron.ietf.org; Tue, 11 Oct 2005 15:13:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23067 for ; Tue, 11 Oct 2005 15:13:42 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPPjR-000577-L8 for enum@ietf.org; Tue, 11 Oct 2005 15:24:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] voipeer agenda/charter uploaded Date: Tue, 11 Oct 2005 21:13:38 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C45DD@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] voipeer agenda/charter uploaded Thread-Index: AcXOly3wkmSzaoSBSnac34h3r6wKIAAALR/2 From: "Stastny Richard" To: "Peter Williams" , X-Spam-Score: 0.8 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I do not understand what you want to say? =20 This is the voipeer charter discussion and not the enum charter discussion =20 BTW, estee,ed enum chairs, is there a enum charter proposal to expect = soon. With soon I mean before Vancouver Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Peter Williams Gesendet: Di 11.10.2005 21:03 An: enum@ietf.org Betreff: RE: [Enum] voipeer agenda/charter uploaded FROM Proposed VIOPEER Charter: "Routing fo sessions which are not signaled using SIP. In particular, voipeer is constrained to consider only those scenarios in which call routing is signaled using the SIP protocol and addressed by SIP or SIPS URIs or E.164 (public telephone number) addresses. By extension, national and private formats numbering formats are out of scope for voipeer" ENUM has broader scope, including H.323 URLs. ENUM Charter needs to be session protocol agnostic, in essence. So its = the architectural support for multiple session/setup protocols thats = required, not any particular love of H.323. Interaction between ENUM and VIOP peering must be only in the generic = areas, not SIP-specific areas. I see no reason why ENUM should not be optionally "tuned" for today's = SIP, but not "architected" for SIP. There is little doubt that E.164 and ENUM will, given their role, be around far longer than SIP will be. All private and national number formats (that are conforming to E.164 ) = are within the scope of ENUM. In essence, ENUM is not just a name server for today's SIP proxies. It = has a bigger role to play in the Internet. At the same time, it should play in today's adoption space! >From: David Meyer >To: voipeer@lists.uoregon.edu >CC: enum@ietf.org, sipping@ietf.org, jon.peterson@neustar.biz, >mankin@psg.com >Subject: [Enum] voipeer agenda/charter uploaded >Date: Tue, 11 Oct 2005 11:06:44 -0700 > > > Please see > > http://www3.ietf.org/proceedings/05nov/agenda/voipeer.txt > > Note that the bulk of our session will be devoted to > hammering out our charter (charter bashing). > > Thanks, > > Dave ><< attach4 >> >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 15:23:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPPih-0000kQ-6s; Tue, 11 Oct 2005 15:23:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPPif-0000kL-Gs for enum@megatron.ietf.org; Tue, 11 Oct 2005 15:23:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23583 for ; Tue, 11 Oct 2005 15:23:23 -0400 (EDT) Received: from bay103-f20.bay103.hotmail.com ([65.54.174.30] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPPsp-0005Na-JA for enum@ietf.org; Tue, 11 Oct 2005 15:33:56 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 11 Oct 2005 12:23:14 -0700 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Tue, 11 Oct 2005 19:23:14 GMT X-Originating-IP: [71.140.80.125] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C45DD@oefeg-s04.oefeg.loc> From: "Peter Williams" To: Richard.Stastny@oefeg.at, enum@ietf.org Subject: Re: [Enum] voipeer agenda/charter uploaded Date: Tue, 11 Oct 2005 12:23:14 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 11 Oct 2005 19:23:14.0990 (UTC) FILETIME=[3A180CE0:01C5CE99] X-Spam-Score: 1.5 (+) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org IAB required, in a carefully worded policy communciated through a co-chair that its acceptance of Carrier ENUM work itmes is contingent on aligning voipeer.future and enum.future re-chartering. What this WG and its members wants is irrelevant, per the last WG meeting and IAB considerations: all that matters is satisfying IAB's mandate, which we must assume to be in our interests. We have a good strawman from viopeer; its highly SIP specific, particularly in some ENUM-related areas. We comment on their charter, BECAUSE we are REQUIRED to align with their goals, objectives, methods, timelines, etc - for good and obivous reasons - if we want Carrier ENUM to be adopted into the standards track. Remember Carrier ENUM is not formally an IETF standards track activity today, and the rules on becoming so have been stated (and restated, word for word, indicating its a very sensitive topic). >From: "Stastny Richard" >To: "Peter Williams" , >Subject: Re: [Enum] voipeer agenda/charter uploaded >Date: Tue, 11 Oct 2005 21:13:38 +0200 > >I do not understand what you want to say? > >This is the voipeer charter discussion and not >the enum charter discussion > >BTW, estee,ed enum chairs, is there a enum charter proposal to expect soon. > >With soon I mean before Vancouver > >Richard > > >________________________________ > >Von: enum-bounces@ietf.org im Auftrag von Peter Williams >Gesendet: Di 11.10.2005 21:03 >An: enum@ietf.org >Betreff: RE: [Enum] voipeer agenda/charter uploaded > > > > >FROM Proposed VIOPEER Charter: > >"Routing fo sessions which are not signaled using SIP. In > particular, voipeer is constrained to consider only those > scenarios in which call routing is signaled using the > SIP protocol and addressed by SIP or SIPS URIs or E.164 > (public telephone number) addresses. By extension, national > and private formats numbering formats are out of scope for > voipeer" > >ENUM has broader scope, including H.323 URLs. > >ENUM Charter needs to be session protocol agnostic, in essence. So its the >architectural support for multiple session/setup protocols thats required, >not any particular love of H.323. > >Interaction between ENUM and VIOP peering must be only in the generic >areas, >not SIP-specific areas. > >I see no reason why ENUM should not be optionally "tuned" for today's SIP, >but not "architected" for SIP. There is little doubt that E.164 and ENUM >will, given their role, be around far longer than SIP will be. > >All private and national number formats (that are conforming to E.164 ) are >within the scope of ENUM. > >In essence, ENUM is not just a name server for today's SIP proxies. It has >a >bigger role to play in the Internet. At the same time, it should play in >today's adoption space! > > >From: David Meyer > >To: voipeer@lists.uoregon.edu > >CC: enum@ietf.org, sipping@ietf.org, jon.peterson@neustar.biz, > >mankin@psg.com > >Subject: [Enum] voipeer agenda/charter uploaded > >Date: Tue, 11 Oct 2005 11:06:44 -0700 > > > > > > Please see > > > > http://www3.ietf.org/proceedings/05nov/agenda/voipeer.txt > > > > Note that the bulk of our session will be devoted to > > hammering out our charter (charter bashing). > > > > Thanks, > > > > Dave > > > ><< attach4 >> > > > > > >_______________________________________________ > >enum mailing list > >enum@ietf.org > >https://www1.ietf.org/mailman/listinfo/enum > > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 11 16:53:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPR7W-0003ia-2e; Tue, 11 Oct 2005 16:53:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPR7U-0003iF-8D for enum@megatron.ietf.org; Tue, 11 Oct 2005 16:53:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03145 for ; Tue, 11 Oct 2005 16:53:05 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPRHf-0001EV-2u for enum@ietf.org; Tue, 11 Oct 2005 17:03:39 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9BKqwcb024479; Tue, 11 Oct 2005 13:52:58 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9BKqvq1024478; Tue, 11 Oct 2005 13:52:57 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 11 Oct 2005 13:52:57 -0700 From: David Meyer To: Peter Williams Subject: Re: [Enum] voipeer agenda/charter uploaded Message-ID: <20051011205257.GA24376@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D462C45DD@oefeg-s04.oefeg.loc> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.8 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: enum@ietf.org, Richard.Stastny@oefeg.at X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0684444100==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0684444100== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Peter, On Tue, Oct 11, 2005 at 12:23:14PM -0700, Peter Williams wrote: > IAB required, in a carefully worded policy communciated through a co-chai= r=20 > that its acceptance of Carrier ENUM work itmes is contingent on aligning= =20 > voipeer.future and enum.future re-chartering. What this WG and its member= s=20 > wants is irrelevant, per the last WG meeting and IAB considerations: all= =20 > that matters is satisfying IAB's mandate, which we must assume to be in o= ur=20 > interests. Can you describe how you feel the IAB "required" this? I'm a little confused as=20 (i). I'm not sure how that IAB can "require" anything; perhaps you mean s/IAB/IESG/=20 (that would make more sense), and=20 (ii). I'm not sure what you think was "required" WRT Carrier ENUM alignment; there have been a lot of discussions around this, and it would be good to get everyone's assumptions on the table, and to make sure we're all using the same set. Can you (or anyone else) clarify these for us? > We have a good strawman from viopeer; its highly SIP specific, particular= ly=20 > in some ENUM-related areas. SIP is the Internet-standard signalling protocol, after all. And we are talking about the Internet here (IETF and all). Thanks, Dave > We comment on their charter, BECAUSE we are REQUIRED to align with their= =20 > goals, objectives, methods, timelines, etc - for good and obivous reason= s=20 > - if we want Carrier ENUM to be adopted into the standards track. >=20 > Remember Carrier ENUM is not formally an IETF standards track activity=20 > today, and the rules on becoming so have been stated (and restated, word= =20 > for word, indicating its a very sensitive topic). >=20 >=20 >=20 > >From: "Stastny Richard" > >To: "Peter Williams" , > >Subject: Re: [Enum] voipeer agenda/charter uploaded > >Date: Tue, 11 Oct 2005 21:13:38 +0200 > > > >I do not understand what you want to say? > > > >This is the voipeer charter discussion and not > >the enum charter discussion > > > >BTW, estee,ed enum chairs, is there a enum charter proposal to expect so= on. > > > >With soon I mean before Vancouver > > > >Richard > > > > > >________________________________ > > > >Von: enum-bounces@ietf.org im Auftrag von Peter Williams > >Gesendet: Di 11.10.2005 21:03 > >An: enum@ietf.org > >Betreff: RE: [Enum] voipeer agenda/charter uploaded > > > > > > > > > >FROM Proposed VIOPEER Charter: > > > >"Routing fo sessions which are not signaled using SIP. In > > particular, voipeer is constrained to consider only those > > scenarios in which call routing is signaled using the > > SIP protocol and addressed by SIP or SIPS URIs or E.164 > > (public telephone number) addresses. By extension, national > > and private formats numbering formats are out of scope for > > voipeer" > > > >ENUM has broader scope, including H.323 URLs. > > > >ENUM Charter needs to be session protocol agnostic, in essence. So its t= he > >architectural support for multiple session/setup protocols thats require= d, > >not any particular love of H.323. > > > >Interaction between ENUM and VIOP peering must be only in the generic=20 > >areas, > >not SIP-specific areas. > > > >I see no reason why ENUM should not be optionally "tuned" for today's SI= P, > >but not "architected" for SIP. There is little doubt that E.164 and ENUM > >will, given their role, be around far longer than SIP will be. > > > >All private and national number formats (that are conforming to E.164 ) = are > >within the scope of ENUM. > > > >In essence, ENUM is not just a name server for today's SIP proxies. It h= as=20 > >a > >bigger role to play in the Internet. At the same time, it should play in > >today's adoption space! > > > >>From: David Meyer > >>To: voipeer@lists.uoregon.edu > >>CC: enum@ietf.org, sipping@ietf.org, jon.peterson@neustar.biz, > >>mankin@psg.com > >>Subject: [Enum] voipeer agenda/charter uploaded > >>Date: Tue, 11 Oct 2005 11:06:44 -0700 > >> > >> > >> Please see > >> > >> http://www3.ietf.org/proceedings/05nov/agenda/voipeer.txt > >> > >> Note that the bulk of our session will be devoted to > >> hammering out our charter (charter bashing). > >> > >> Thanks, > >> > >> Dave > > > > > >><< attach4 >> > > > > > > > > > >>_______________________________________________ > >>enum mailing list > >>enum@ietf.org > >>https://www1.ietf.org/mailman/listinfo/enum > > > > > > > >_______________________________________________ > >enum mailing list > >enum@ietf.org > >https://www1.ietf.org/mailman/listinfo/enum > > > > >=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDTCYpORgD1qCZ2KcRAgR7AJ4tWozsUI0c3/tAqARs76aczIwCdgCfXmuE 8JlUMfKbcda0kP4cjSJEcWY= =gKJz -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- --===============0684444100== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0684444100==-- From enum-bounces@ietf.org Tue Oct 11 19:20:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPTPs-0007tG-CL; Tue, 11 Oct 2005 19:20:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPTPr-0007t3-9n; Tue, 11 Oct 2005 19:20:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09771; Tue, 11 Oct 2005 19:20:11 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPTa2-0004vx-5z; Tue, 11 Oct 2005 19:30:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] voipeer agenda/charter uploaded Date: Wed, 12 Oct 2005 01:23:40 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C45DE@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] voipeer agenda/charter uploaded Thread-Index: AcXOj2uiihcERhkZR06kh9fv3PLqiAAKotAB From: "Stastny Richard" To: "David Meyer" , X-Spam-Score: 0.8 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, sipping@ietf.org, jon.peterson@neustar.biz, mankin@psg.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Congatulations, the charter seems quite well done on first reading =20 first questions and remarks: =20 1. The goals and milestones seem to be a bit out-of-order and confusing =20 2. -Jan 07 Submit I-D on the use of DNS SRV and NAPTR -Jan 07 Submit document to IESG on the use of DNS SRV and = NAPTR records as specified by RFC 3263 (BCP) What is the reason for this I-D and what in addition to RFC 3263 should be stated? regards Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von David Meyer Gesendet: Di 11.10.2005 20:06 An: voipeer@lists.uoregon.edu Cc: enum@ietf.org; sipping@ietf.org; jon.peterson@neustar.biz; = mankin@psg.com Betreff: [Enum] voipeer agenda/charter uploaded Please see http://www3.ietf.org/proceedings/05nov/agenda/voipeer.txt Note that the bulk of our session will be devoted to hammering out our charter (charter bashing). Thanks, Dave _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 12 06:22:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPdkv-0006i3-7H; Wed, 12 Oct 2005 06:22:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPdkr-0006hc-0P for enum@megatron.ietf.org; Wed, 12 Oct 2005 06:22:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11459 for ; Wed, 12 Oct 2005 06:22:33 -0400 (EDT) Received: from bm.firsthand.net ([80.68.91.165] helo=plesktest.vm.bytemark.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPdv3-0005Qp-F2 for enum@ietf.org; Wed, 12 Oct 2005 06:33:15 -0400 Received: (qmail 14207 invoked from network); 12 Oct 2005 12:28:49 +0100 Received: from unknown (HELO ?81.6.214.204?) (81.6.214.204) by bm.firsthand.net with SMTP; 12 Oct 2005 12:28:49 +0100 In-Reply-To: <20051011205257.GA24376@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D462C45DD@oefeg-s04.oefeg.loc> <20051011205257.GA24376@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5C612A4A-4B9D-4DA8-A30C-76385A93C3BD@firsthand.net> Content-Transfer-Encoding: 7bit From: Christian de Larrinaga Subject: Re: [Enum] voipeer agenda/charter uploaded Date: Wed, 12 Oct 2005 11:21:43 +0100 To: David Meyer X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.8 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Richard.Stastny@oefeg.at, Peter Williams X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Carrier ENUM is not mentioned here which is good I think. But it is implied. I would support a definition of Carrier ENUM as supporting peering/ transit and routing relationships but not for provisioning user services. The VoiPeer charter seems to agree with this view? If so then it should be taken on board by those working on a carrier ENUM plan? Christian de Larrinaga cdel@firsthand.net Voex Inc. On 11 Oct 2005, at 21:52, David Meyer wrote: > Peter, > > On Tue, Oct 11, 2005 at 12:23:14PM -0700, Peter Williams wrote: > > >> IAB required, in a carefully worded policy communciated through a >> co-chair >> that its acceptance of Carrier ENUM work itmes is contingent on >> aligning >> voipeer.future and enum.future re-chartering. What this WG and its >> members >> wants is irrelevant, per the last WG meeting and IAB >> considerations: all >> that matters is satisfying IAB's mandate, which we must assume to >> be in our >> interests. >> >> > > Can you describe how you feel the IAB "required" this? > I'm a little confused as > > (i). I'm not sure how that IAB can "require" > anything; perhaps you mean s/IAB/IESG/ > (that would make more sense), and > > (ii). I'm not sure what you think was "required" WRT > Carrier ENUM alignment; there have been a lot of > discussions around this, and it would be good to > get everyone's assumptions on the table, and to > make sure we're all using the same set. > > Can you (or anyone else) clarify these for us? > > > >> We have a good strawman from viopeer; its highly SIP specific, >> particularly >> in some ENUM-related areas. >> >> > > SIP is the Internet-standard signalling protocol, after > all. And we are talking about the Internet here (IETF and > all). > > Thanks, > > Dave > > > > >> We comment on their charter, BECAUSE we are REQUIRED to align with >> their >> goals, objectives, methods, timelines, etc - for good and obivous >> reasons >> - if we want Carrier ENUM to be adopted into the standards track. >> >> Remember Carrier ENUM is not formally an IETF standards track >> activity >> today, and the rules on becoming so have been stated (and >> restated, word >> for word, indicating its a very sensitive topic). >> >> >> >> >> >>> From: "Stastny Richard" >>> To: "Peter Williams" , >>> Subject: Re: [Enum] voipeer agenda/charter uploaded >>> Date: Tue, 11 Oct 2005 21:13:38 +0200 >>> >>> I do not understand what you want to say? >>> >>> This is the voipeer charter discussion and not >>> the enum charter discussion >>> >>> BTW, estee,ed enum chairs, is there a enum charter proposal to >>> expect soon. >>> >>> With soon I mean before Vancouver >>> >>> Richard >>> >>> >>> ________________________________ >>> >>> Von: enum-bounces@ietf.org im Auftrag von Peter Williams >>> Gesendet: Di 11.10.2005 21:03 >>> An: enum@ietf.org >>> Betreff: RE: [Enum] voipeer agenda/charter uploaded >>> >>> >>> >>> >>> FROM Proposed VIOPEER Charter: >>> >>> "Routing fo sessions which are not signaled using SIP. In >>> particular, voipeer is constrained to consider only those >>> scenarios in which call routing is signaled using the >>> SIP protocol and addressed by SIP or SIPS URIs or E.164 >>> (public telephone number) addresses. By extension, national >>> and private formats numbering formats are out of scope for >>> voipeer" >>> >>> ENUM has broader scope, including H.323 URLs. >>> >>> ENUM Charter needs to be session protocol agnostic, in essence. >>> So its the >>> architectural support for multiple session/setup protocols thats >>> required, >>> not any particular love of H.323. >>> >>> Interaction between ENUM and VIOP peering must be only in the >>> generic >>> areas, >>> not SIP-specific areas. >>> >>> I see no reason why ENUM should not be optionally "tuned" for >>> today's SIP, >>> but not "architected" for SIP. There is little doubt that E.164 >>> and ENUM >>> will, given their role, be around far longer than SIP will be. >>> >>> All private and national number formats (that are conforming to E. >>> 164 ) are >>> within the scope of ENUM. >>> >>> In essence, ENUM is not just a name server for today's SIP >>> proxies. It has >>> a >>> bigger role to play in the Internet. At the same time, it should >>> play in >>> today's adoption space! >>> >>> >>> >>>> From: David Meyer >>>> To: voipeer@lists.uoregon.edu >>>> CC: enum@ietf.org, sipping@ietf.org, jon.peterson@neustar.biz, >>>> mankin@psg.com >>>> Subject: [Enum] voipeer agenda/charter uploaded >>>> Date: Tue, 11 Oct 2005 11:06:44 -0700 >>>> >>>> >>>> Please see >>>> >>>> http://www3.ietf.org/proceedings/05nov/agenda/voipeer.txt >>>> >>>> Note that the bulk of our session will be devoted to >>>> hammering out our charter (charter bashing). >>>> >>>> Thanks, >>>> >>>> Dave >>>> >>>> >>> >>> >>> >>> >>>> << attach4 >> >>>> >>>> >>> >>> >>> >>> >>> >>> >>>> _______________________________________________ >>>> enum mailing list >>>> enum@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/enum >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> enum mailing list >>> enum@ietf.org >>> https://www1.ietf.org/mailman/listinfo/enum >>> >>> >>> >>> >> >> >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum >> >> > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 12 07:08:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPeSm-00023H-5k; Wed, 12 Oct 2005 07:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPeSk-000239-A9 for enum@megatron.ietf.org; Wed, 12 Oct 2005 07:07:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13223 for ; Wed, 12 Oct 2005 07:07:53 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPecy-0006VB-OM for enum@ietf.org; Wed, 12 Oct 2005 07:18:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] voipeer agenda/charter uploaded Date: Wed, 12 Oct 2005 13:11:18 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2190@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] voipeer agenda/charter uploaded Thread-Index: AcXPF1kFYH6l2WpASbu/i2HT+Tn7agABaJTw From: "Stastny Richard" To: "Christian de Larrinaga" , "David Meyer" X-Spam-Score: 0.8 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Caveat: ENUM (in general) is NOT for defining transit routes. Only the end-user (User ENUM) or the carrier serving the number in question =3D the destination "network" (Carrier ENUM) is allowed to enter a domain, NEVER a "transit network". Richard > -----Original Message----- > From: Christian de Larrinaga [mailto:cdel@firsthand.net] > Sent: Wednesday, October 12, 2005 12:22 PM > To: David Meyer > Cc: Peter Williams; enum@ietf.org; Stastny Richard > Subject: Re: [Enum] voipeer agenda/charter uploaded >=20 > Carrier ENUM is not mentioned here which is good I think. > But it is implied. > I would support a definition of Carrier ENUM as supporting peering/ > transit and routing relationships but not for provisioning user > services. > The VoiPeer charter seems to agree with this view? >=20 > If so then it should be taken on board by those working on a carrier > ENUM plan? >=20 > Christian de Larrinaga > cdel@firsthand.net > Voex Inc. >=20 >=20 > On 11 Oct 2005, at 21:52, David Meyer wrote: >=20 >=20 > > Peter, > > > > On Tue, Oct 11, 2005 at 12:23:14PM -0700, Peter Williams wrote: > > > > > >> IAB required, in a carefully worded policy communciated through a > >> co-chair > >> that its acceptance of Carrier ENUM work itmes is contingent on > >> aligning > >> voipeer.future and enum.future re-chartering. What this WG and its > >> members > >> wants is irrelevant, per the last WG meeting and IAB > >> considerations: all > >> that matters is satisfying IAB's mandate, which we must assume to > >> be in our > >> interests. > >> > >> > > > > Can you describe how you feel the IAB "required" this? > > I'm a little confused as > > > > (i). I'm not sure how that IAB can "require" > > anything; perhaps you mean s/IAB/IESG/ > > (that would make more sense), and > > > > (ii). I'm not sure what you think was "required" WRT > > Carrier ENUM alignment; there have been a lot of > > discussions around this, and it would be good to > > get everyone's assumptions on the table, and to > > make sure we're all using the same set. > > > > Can you (or anyone else) clarify these for us? > > > > > > > >> We have a good strawman from viopeer; its highly SIP specific, > >> particularly > >> in some ENUM-related areas. > >> > >> > > > > SIP is the Internet-standard signalling protocol, after > > all. And we are talking about the Internet here (IETF and > > all). > > > > Thanks, > > > > Dave > > > > > > > > > >> We comment on their charter, BECAUSE we are REQUIRED to align with > >> their > >> goals, objectives, methods, timelines, etc - for good and obivous > >> reasons > >> - if we want Carrier ENUM to be adopted into the standards track. > >> > >> Remember Carrier ENUM is not formally an IETF standards track > >> activity > >> today, and the rules on becoming so have been stated (and > >> restated, word > >> for word, indicating its a very sensitive topic). > >> > >> > >> > >> > >> > >>> From: "Stastny Richard" > >>> To: "Peter Williams" , > >>> Subject: Re: [Enum] voipeer agenda/charter uploaded > >>> Date: Tue, 11 Oct 2005 21:13:38 +0200 > >>> > >>> I do not understand what you want to say? > >>> > >>> This is the voipeer charter discussion and not > >>> the enum charter discussion > >>> > >>> BTW, estee,ed enum chairs, is there a enum charter proposal to > >>> expect soon. > >>> > >>> With soon I mean before Vancouver > >>> > >>> Richard > >>> > >>> > >>> ________________________________ > >>> > >>> Von: enum-bounces@ietf.org im Auftrag von Peter Williams > >>> Gesendet: Di 11.10.2005 21:03 > >>> An: enum@ietf.org > >>> Betreff: RE: [Enum] voipeer agenda/charter uploaded > >>> > >>> > >>> > >>> > >>> FROM Proposed VIOPEER Charter: > >>> > >>> "Routing fo sessions which are not signaled using SIP. In > >>> particular, voipeer is constrained to consider only those > >>> scenarios in which call routing is signaled using the > >>> SIP protocol and addressed by SIP or SIPS URIs or E.164 > >>> (public telephone number) addresses. By extension, national > >>> and private formats numbering formats are out of scope for > >>> voipeer" > >>> > >>> ENUM has broader scope, including H.323 URLs. > >>> > >>> ENUM Charter needs to be session protocol agnostic, in essence. > >>> So its the > >>> architectural support for multiple session/setup protocols thats > >>> required, > >>> not any particular love of H.323. > >>> > >>> Interaction between ENUM and VIOP peering must be only in the > >>> generic > >>> areas, > >>> not SIP-specific areas. > >>> > >>> I see no reason why ENUM should not be optionally "tuned" for > >>> today's SIP, > >>> but not "architected" for SIP. There is little doubt that E.164 > >>> and ENUM > >>> will, given their role, be around far longer than SIP will be. > >>> > >>> All private and national number formats (that are conforming to E. > >>> 164 ) are > >>> within the scope of ENUM. > >>> > >>> In essence, ENUM is not just a name server for today's SIP > >>> proxies. It has > >>> a > >>> bigger role to play in the Internet. At the same time, it should > >>> play in > >>> today's adoption space! > >>> > >>> > >>> > >>>> From: David Meyer > >>>> To: voipeer@lists.uoregon.edu > >>>> CC: enum@ietf.org, sipping@ietf.org, jon.peterson@neustar.biz, > >>>> mankin@psg.com > >>>> Subject: [Enum] voipeer agenda/charter uploaded > >>>> Date: Tue, 11 Oct 2005 11:06:44 -0700 > >>>> > >>>> > >>>> Please see > >>>> > >>>> http://www3.ietf.org/proceedings/05nov/agenda/voipeer.txt > >>>> > >>>> Note that the bulk of our session will be devoted to > >>>> hammering out our charter (charter bashing). > >>>> > >>>> Thanks, > >>>> > >>>> Dave > >>>> > >>>> > >>> > >>> > >>> > >>> > >>>> << attach4 >> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>> _______________________________________________ > >>>> enum mailing list > >>>> enum@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/enum > >>>> > >>>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> enum mailing list > >>> enum@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/enum > >>> > >>> > >>> > >>> > >> > >> > >> > >> _______________________________________________ > >> enum mailing list > >> enum@ietf.org > >> https://www1.ietf.org/mailman/listinfo/enum > >> > >> > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 12 10:44:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPhqU-0003OE-RS; Wed, 12 Oct 2005 10:44:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPhqT-0003O6-Og for enum@megatron.ietf.org; Wed, 12 Oct 2005 10:44:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24965 for ; Wed, 12 Oct 2005 10:44:38 -0400 (EDT) Received: from bay103-f22.bay103.hotmail.com ([65.54.174.32] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPi0l-0004H0-Sm for enum@ietf.org; Wed, 12 Oct 2005 10:55:22 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 12 Oct 2005 07:44:28 -0700 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Wed, 12 Oct 2005 14:44:28 GMT X-Originating-IP: [69.229.195.54] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <5C612A4A-4B9D-4DA8-A30C-76385A93C3BD@firsthand.net> From: "Peter Williams" Cc: enum@ietf.org Subject: Re: [Enum] voipeer agenda/charter uploaded Date: Wed, 12 Oct 2005 07:44:28 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 12 Oct 2005 14:44:28.0886 (UTC) FILETIME=[72F8DF60:01C5CF3B] X-Spam-Score: 1.5 (+) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org It would be natural to break down the strategic goals of ENUM (rechartered) for the Carrier ENUM question, in terms of the following categories:: (If I start using ISO terms and modelling conventions for all this, becuase its all been done before, slap me and remind me we are doing _IETF-styled_ reinvention of carrier-based telephony) There will be multiple Carrier ENUM trees, one of which is public and ultimately, ICANN (i.e. US govt.) controlled. Within an Carrier ENUM tree, - voice providers will practice uniform and consistent peering - voice providers will provision name server entries and their contents - the structure of the tree will reflect the administrative rights of the provider under NRA licensing - the structure of validation entity and security domains is orthogonoal to the structure of the tree reflecting the adminsitrative rights of providers to create and modify entries in the ENUM name servers serving the tree - ENUM name servers will reflect number registration, and number porting, but will not directly perform registration or NP duties - An ENUM name server is not intended to be an identity service for Carriers of Record, for current entries - A carrier's obligation to wiretap a subsriber line shall not impact or influence the adminsitration of or content of, an entry in an ENUM name server. - The adminsitration of entries, and the schema of services declared within an entry, shall be administered by the COR for the E.164 number identifying the entry - Any E.164 number issued pusuant to national regulatory authority license may logically identify an entry. -Entries that declare CORs, NRAs, schema definitions, provider service access points and other administrative meta-data are not within the scope of Carrier ENUM dliverables, though may be addessed in related ENUM series documents. ------------- The ENUM charter SHOULD NOT focus its text on the above! Rather, it needs to characterise Carrier ENUM scheme, to be designed in the next round of WG activity. The deliverables that embody the above need to be identified, timetabled, and characterized, however, using the architectural principles listed above. If the formulation of the charter is not occuring with the direct involvement of the folks who have already written Carrier ENUM drafts, and can improve upon the above considerably, there is SOMETHING VERY WRONG WITH THE TRANSPARENCY. Improve the process, co-chairs, and make it transparent and available to mailing list participants, per our community norms. Peter. >From: Christian de Larrinaga >To: David Meyer >CC: Peter Williams , enum@ietf.org, >Richard.Stastny@oefeg.at >Subject: Re: [Enum] voipeer agenda/charter uploaded >Date: Wed, 12 Oct 2005 11:21:43 +0100 > >Carrier ENUM is not mentioned here which is good I think. >But it is implied. >I would support a definition of Carrier ENUM as supporting peering/ transit >and routing relationships but not for provisioning user services. >The VoiPeer charter seems to agree with this view? > >If so then it should be taken on board by those working on a carrier ENUM >plan? > >Christian de Larrinaga >cdel@firsthand.net >Voex Inc. > > >On 11 Oct 2005, at 21:52, David Meyer wrote: > > >> Peter, >> >>On Tue, Oct 11, 2005 at 12:23:14PM -0700, Peter Williams wrote: >> >> >>>IAB required, in a carefully worded policy communciated through a >>>co-chair >>>that its acceptance of Carrier ENUM work itmes is contingent on aligning >>>voipeer.future and enum.future re-chartering. What this WG and its >>>members >>>wants is irrelevant, per the last WG meeting and IAB considerations: all >>>that matters is satisfying IAB's mandate, which we must assume to be in >>>our >>>interests. >>> >>> >> >> Can you describe how you feel the IAB "required" this? >> I'm a little confused as >> >> (i). I'm not sure how that IAB can "require" >> anything; perhaps you mean s/IAB/IESG/ >> (that would make more sense), and >> >> (ii). I'm not sure what you think was "required" WRT >> Carrier ENUM alignment; there have been a lot of >> discussions around this, and it would be good to >> get everyone's assumptions on the table, and to >> make sure we're all using the same set. >> >> Can you (or anyone else) clarify these for us? >> >> >> >>>We have a good strawman from viopeer; its highly SIP specific, >>>particularly >>>in some ENUM-related areas. >>> >>> >> >> SIP is the Internet-standard signalling protocol, after >> all. And we are talking about the Internet here (IETF and >> all). >> >> Thanks, >> >> Dave >> >> >> >> >>>We comment on their charter, BECAUSE we are REQUIRED to align with their >>>goals, objectives, methods, timelines, etc - for good and obivous >>>reasons >>>- if we want Carrier ENUM to be adopted into the standards track. >>> >>>Remember Carrier ENUM is not formally an IETF standards track activity >>>today, and the rules on becoming so have been stated (and restated, word >>>for word, indicating its a very sensitive topic). >>> >>> >>> >>> >>> >>>>From: "Stastny Richard" >>>>To: "Peter Williams" , >>>>Subject: Re: [Enum] voipeer agenda/charter uploaded >>>>Date: Tue, 11 Oct 2005 21:13:38 +0200 >>>> >>>>I do not understand what you want to say? >>>> >>>>This is the voipeer charter discussion and not >>>>the enum charter discussion >>>> >>>>BTW, estee,ed enum chairs, is there a enum charter proposal to expect >>>>soon. >>>> >>>>With soon I mean before Vancouver >>>> >>>>Richard >>>> >>>> >>>>________________________________ >>>> >>>>Von: enum-bounces@ietf.org im Auftrag von Peter Williams >>>>Gesendet: Di 11.10.2005 21:03 >>>>An: enum@ietf.org >>>>Betreff: RE: [Enum] voipeer agenda/charter uploaded >>>> >>>> >>>> >>>> >>>>FROM Proposed VIOPEER Charter: >>>> >>>>"Routing fo sessions which are not signaled using SIP. In >>>> particular, voipeer is constrained to consider only those >>>> scenarios in which call routing is signaled using the >>>> SIP protocol and addressed by SIP or SIPS URIs or E.164 >>>> (public telephone number) addresses. By extension, national >>>> and private formats numbering formats are out of scope for >>>> voipeer" >>>> >>>>ENUM has broader scope, including H.323 URLs. >>>> >>>>ENUM Charter needs to be session protocol agnostic, in essence. So its >>>>the >>>>architectural support for multiple session/setup protocols thats >>>>required, >>>>not any particular love of H.323. >>>> >>>>Interaction between ENUM and VIOP peering must be only in the generic >>>>areas, >>>>not SIP-specific areas. >>>> >>>>I see no reason why ENUM should not be optionally "tuned" for today's >>>>SIP, >>>>but not "architected" for SIP. There is little doubt that E.164 and >>>>ENUM >>>>will, given their role, be around far longer than SIP will be. >>>> >>>>All private and national number formats (that are conforming to E. 164 ) >>>>are >>>>within the scope of ENUM. >>>> >>>>In essence, ENUM is not just a name server for today's SIP proxies. It >>>>has >>>>a >>>>bigger role to play in the Internet. At the same time, it should play >>>>in >>>>today's adoption space! >>>> >>>> >>>> >>>>>From: David Meyer >>>>>To: voipeer@lists.uoregon.edu >>>>>CC: enum@ietf.org, sipping@ietf.org, jon.peterson@neustar.biz, >>>>>mankin@psg.com >>>>>Subject: [Enum] voipeer agenda/charter uploaded >>>>>Date: Tue, 11 Oct 2005 11:06:44 -0700 >>>>> >>>>> >>>>> Please see >>>>> >>>>> http://www3.ietf.org/proceedings/05nov/agenda/voipeer.txt >>>>> >>>>> Note that the bulk of our session will be devoted to >>>>> hammering out our charter (charter bashing). >>>>> >>>>> Thanks, >>>>> >>>>> Dave >>>>> >>>>> >>>> >>>> >>>> >>>> >>>>><< attach4 >> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>_______________________________________________ >>>>>enum mailing list >>>>>enum@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/enum >>>>> >>>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>enum mailing list >>>>enum@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/enum >>>> >>>> >>>> >>>> >>> >>> >>> >>>_______________________________________________ >>>enum mailing list >>>enum@ietf.org >>>https://www1.ietf.org/mailman/listinfo/enum >>> >>> >>_______________________________________________ >>enum mailing list >>enum@ietf.org >>https://www1.ietf.org/mailman/listinfo/enum >> >> > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 12 10:58:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPi3e-00084Q-9O; Wed, 12 Oct 2005 10:58:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPi3d-00084L-Jt for enum@megatron.ietf.org; Wed, 12 Oct 2005 10:58:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26306 for ; Wed, 12 Oct 2005 10:58:14 -0400 (EDT) Received: from bm.firsthand.net ([80.68.91.165] helo=plesktest.vm.bytemark.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPiDx-0004tp-0I for enum@ietf.org; Wed, 12 Oct 2005 11:08:58 -0400 Received: (qmail 15826 invoked from network); 12 Oct 2005 17:04:52 +0100 Received: from unknown (HELO ?81.6.214.204?) (81.6.214.204) by bm.firsthand.net with SMTP; 12 Oct 2005 17:04:52 +0100 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B2190@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D461B2190@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <56133BD2-7FD5-4919-B420-DD5A88136AFE@firsthand.net> Content-Transfer-Encoding: 7bit From: Christian de Larrinaga Subject: Re: [Enum] voipeer agenda/charter uploaded Date: Wed, 12 Oct 2005 15:57:35 +0100 To: "Stastny Richard" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard Thanks for the caveat. I used the word "supporting" very deliberately. On 12 Oct 2005, at 12:11, Stastny Richard wrote: > Caveat: > > ENUM (in general) is NOT for defining transit routes. > Only the end-user (User ENUM) or the carrier serving the > number in question = the destination "network" (Carrier ENUM) > is allowed to enter a domain, NEVER a "transit network". > Yes indeed. The charter has been very carefully written and the references to sip servers and layer 5 gives a very clear message to both L3 but also to L6/L7. But it is a coded message. Carrier ENUM is just not defined enough to call now but its presence is sitting here looming large over this proposed activity like the uninvited guest who believes he will take over the party. I don't propose we add the carrier enum term to the charter as that would be entirely wrong, but it would be useful in the charter to add stated support for RFC 2826 (L8) principles to protect against the formation of split roots in ENUM and ENUM like services should ancillary ENUM like roots come to be formed. Christian Christian de Larrinaga _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 12 11:51:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPisn-0000xU-Oc; Wed, 12 Oct 2005 11:51:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPism-0000xG-7C; Wed, 12 Oct 2005 11:51:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29759; Wed, 12 Oct 2005 11:51:04 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPj37-0006ad-9g; Wed, 12 Oct 2005 12:01:49 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9CFouF4015521; Wed, 12 Oct 2005 08:50:56 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9CFosb5015520; Wed, 12 Oct 2005 08:50:54 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 12 Oct 2005 08:50:54 -0700 From: David Meyer To: Stastny Richard Subject: Re: [Enum] voipeer agenda/charter uploaded Message-ID: <20051012155054.GA15438@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D462C45DE@oefeg-s04.oefeg.loc> Mime-Version: 1.0 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C45DE@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: enum@ietf.org, voipeer@lists.uoregon.edu, sipping@ietf.org, jon.peterson@neustar.biz, mankin@psg.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0759714242==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0759714242== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 12, 2005 at 01:23:40AM +0200, Stastny Richard wrote: > Congatulations, the charter seems quite well done on first reading Hey, thanks! > first questions and remarks: > =20 > 1. The goals and milestones seem to be a bit out-of-order and confusing > =20 > 2. -Jan 07 Submit I-D on the use of DNS SRV and NAPTR > -Jan 07 Submit document to IESG on the use of DNS SRV and NA= PTR > records as specified by RFC 3263 (BCP) >=20 > What is the reason for this I-D and what in addition to RFC 3263 > should be stated? (i). The dates are clearly botched, thanks for pointing that out. I'll just mention that I'm expecting that we'll hammer out some realistic dates for the work-plan I've described. I put up what I believe is a pretty agressive (and possibly unrealistic), and I'm planning for us to have that discussion in Vancouver. (ii). Regarding RFC 3263, several folks asked for a document that outlines the *deployment issues* (and perhaps BCPs) with 3263. I'll fix (i). above. Does (ii). clarify the situation?=20 Thanks for the comments. Dave --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDTTDeORgD1qCZ2KcRAsK2AJ49bE/E9KMMr7NQVgSoFvJ7LZxRRQCfRumg ZOIe7NLe+l8VAhJ9AJzV314= =9AUH -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- --===============0759714242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0759714242==-- From enum-bounces@ietf.org Wed Oct 12 12:01:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPj39-0004qi-0O; Wed, 12 Oct 2005 12:01:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPj37-0004qN-Dm for enum@megatron.ietf.org; Wed, 12 Oct 2005 12:01:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01581 for ; Wed, 12 Oct 2005 12:01:45 -0400 (EDT) Received: from bay103-f8.bay103.hotmail.com ([65.54.174.18] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPjDP-0007IX-4D for enum@ietf.org; Wed, 12 Oct 2005 12:12:30 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 12 Oct 2005 09:01:32 -0700 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Wed, 12 Oct 2005 16:01:32 GMT X-Originating-IP: [69.229.195.54] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <56133BD2-7FD5-4919-B420-DD5A88136AFE@firsthand.net> From: "Peter Williams" To: cdel@firsthand.net Subject: Re: [Enum] voipeer agenda/charter uploaded Date: Wed, 12 Oct 2005 09:01:32 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 12 Oct 2005 16:01:32.0876 (UTC) FILETIME=[3715C0C0:01C5CF46] X-Spam-Score: 0.8 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >>The charter has been very carefully written and the references to >sip servers and layer 5 gives a very clear message to both L3 but also to >L6/L7. But it is a coded message. I tried to read it as carefully at it was written (as it is declared as being over written, and words/phrases have special semantics that will catch out the average reader). I think it says, in plain language: L5 stack session control entities will be supported by ENUM conforming name servers, whose collective structure is orthonogal to the structure of the L3 routing, and the structure of L7 addressing forms and their administration. I didn't get the L6 reference. Is an ENUM lookup going to supprot SIP proxies and influence the selection of codecs, in realtime, so we have "codec networks" to worry about? If ENUM is going go evolve into supporting registration and online queriying of the functional groups supported by layer stack instances at proxies and terminals, then its certainly going to need further exploitation of directrory (vs DNS) understanding. DNS is good for name translation, but clueless at capability negotiation. RFC 2826 requires us to layer Directories and DNS, so they converge and work together (somehow). >Carrier ENUM is just not defined enough to call now but its presence is >sitting here looming large over this proposed activity like the uninvited >guest who believes he will take over the party. This seems advisable, as there is no chartered Carrier ENUM activity in IETF, today. Viopeer can (a) wait until ENUM has a charter, that it can reference (b) make vauge allusions, use coded messages, and continue the mess. >I don't propose we add the carrier enum term to the charter as that would >be entirely wrong, but it would be useful in the charter to add stated >support for RFC 2826 (L8) principles to protect against the formation of >split roots in ENUM and ENUM like services should ancillary ENUM like >roots come to be formed. RFC 2826 admits the notion that directories will go beyond the DNS to resolve ambiguous names. It also waffles about the single root of the world idea, based in the USA. We used to hear the same in the PKI world, until we disposed of it @VeriSign (while keeping effective control in the USA! through competitive vs anti-competitive IAB-styled mechanisms) In architectectural terms, ENUM is half directory, half DNS enhancement. Its also a third convergence of number portability from telephony and "number portability" a la DNS. There is no point "protecting" against anything, trying to the avoid the dynamics of the directory world, as its our purpose (in ENUM WG) to investigate a suitable convergence. Protecting "now" against what we learn to be the right convegence strategy is not good standards making, though great religion. " The DNS type of unique naming and name-mapping system may not be ideal for a number of purposes for which it was never designed, such a locating information when the user doesn't precisely know the correct names. As the Internet continues to expand, we would expect directory systems to evolve which can assist the user in dealing with vague or ambiguous references. To preserve the many important features of the DNS and its multiple record types -- including the Internet's equivalent of telephone number portability -- we would expect the result of directory lookups and identification of the correct names for a particular purpose to be unique DNS names that are then resolved normally, rather than having directory systems "replace" the DNS. There is no getting away from the unique root of the public DNS." > >Christian > >Christian de Larrinaga > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 12 12:13:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPjEj-0006OI-3c; Wed, 12 Oct 2005 12:13:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPjEh-0006Ny-7W; Wed, 12 Oct 2005 12:13:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02862; Wed, 12 Oct 2005 12:13:43 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPjP1-0007rr-87; Wed, 12 Oct 2005 12:24:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] voipeer agenda/charter uploaded Date: Wed, 12 Oct 2005 18:17:06 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C45E2@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] voipeer agenda/charter uploaded Thread-Index: AcXPRUtjpd0pYOwoT/OOSxMF00LfZAAAmI+I From: "Stastny Richard" To: "David Meyer" X-Spam-Score: 0.8 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu, sipping@ietf.org, jon.peterson@neustar.biz, mankin@psg.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Thanks, =20 >(ii). Regarding RFC 3263, several folks asked for a > document that outlines the *deployment issues* > (and perhaps BCPs) with 3263. > > Does (ii). clarify the situation? Yes and no. I personally considered 3263 sufficent, but on the other hand, if I consider the discussions going on since one year within GSMA to leave out the NAPTR and SRV records (the so-called 4-step approach) because they fear that two additional DNS queries may prolong their = mobile call setup time of 15 seconds by 100 milliseconds ... ... a BCP may be helpful clarifying the issue ;-) =20 Richard ________________________________ Von: David Meyer [mailto:dmm@1-4-5.net] Gesendet: Mi 12.10.2005 17:50 An: Stastny Richard Cc: voipeer@lists.uoregon.edu; enum@ietf.org; sipping@ietf.org; = jon.peterson@neustar.biz; mankin@psg.com Betreff: Re: [Enum] voipeer agenda/charter uploaded On Wed, Oct 12, 2005 at 01:23:40AM +0200, Stastny Richard wrote: > Congatulations, the charter seems quite well done on first reading Hey, thanks! > first questions and remarks: >=20 > 1. The goals and milestones seem to be a bit out-of-order and = confusing >=20 > 2. -Jan 07 Submit I-D on the use of DNS SRV and NAPTR > -Jan 07 Submit document to IESG on the use of DNS SRV and = NAPTR > records as specified by RFC 3263 (BCP) > > What is the reason for this I-D and what in addition to RFC 3263 > should be stated? (i). The dates are clearly botched, thanks for pointing that out. I'll just mention that I'm expecting that we'll hammer out some realistic dates for the work-plan I've described. I put up what I believe is a pretty agressive (and possibly unrealistic), and I'm planning for us to have that discussion in Vancouver. (ii). Regarding RFC 3263, several folks asked for a document that outlines the *deployment issues* (and perhaps BCPs) with 3263. I'll fix (i). above. Does (ii). clarify the situation? Thanks for the comments. Dave _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 12 12:12:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPjDe-0005hL-NG; Wed, 12 Oct 2005 12:12:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPjDd-0005gt-8d for enum@megatron.ietf.org; Wed, 12 Oct 2005 12:12:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02795 for ; Wed, 12 Oct 2005 12:12:37 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPjNx-0007qA-Er for enum@ietf.org; Wed, 12 Oct 2005 12:23:22 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9CGCOhC017231; Wed, 12 Oct 2005 09:12:24 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9CGCKBe017230; Wed, 12 Oct 2005 09:12:20 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 12 Oct 2005 09:12:20 -0700 From: David Meyer To: Christian de Larrinaga Subject: Re: [Enum] voipeer agenda/charter uploaded Message-ID: <20051012161220.GA17197@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D461B2190@oefeg-s04.oefeg.loc> <56133BD2-7FD5-4919-B420-DD5A88136AFE@firsthand.net> Mime-Version: 1.0 In-Reply-To: <56133BD2-7FD5-4919-B420-DD5A88136AFE@firsthand.net> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: enum@ietf.org, Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0032022405==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0032022405== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 12, 2005 at 03:57:35PM +0100, Christian de Larrinaga wrote: > Richard >=20 > Thanks for the caveat. > I used the word "supporting" very deliberately. >=20 > On 12 Oct 2005, at 12:11, Stastny Richard wrote: >=20 > >Caveat: > > > >ENUM (in general) is NOT for defining transit routes. > >Only the end-user (User ENUM) or the carrier serving the > >number in question =3D the destination "network" (Carrier ENUM) > >is allowed to enter a domain, NEVER a "transit network". > > >=20 > Yes indeed. >=20 > The charter has been very carefully written and the references to sip =20 > servers and layer 5 gives a very clear message to both L3 but also to =20 > L6/L7. But it is a coded message. > Carrier ENUM is just not defined enough to call now but its presence =20 > is sitting here looming large over this proposed activity like the =20 > uninvited guest who believes he will take over the party. >=20 > I don't propose we add the carrier enum term to the charter as that =20 > would be entirely wrong, but it would be useful in the charter to =20 > add stated support for RFC 2826 (L8) principles to protect against =20 > the formation of split roots in ENUM and ENUM like services should =20 > ancillary ENUM like roots come to be formed. Christian, I'm not sure why one needs stated support for 2826. Asked another way, what more (than RFC 2826) needs to be said about unique roots?=20 Dave --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDTTXkORgD1qCZ2KcRAgn3AKCSWcbZ/ZWlfmqhJlk17PgQ55yEbACeKLqF k82+0WRY4Hdqcwi/Huog3tI= =Qr67 -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- --===============0032022405== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0032022405==-- From enum-bounces@ietf.org Wed Oct 12 12:20:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPjLM-0008AG-Fy; Wed, 12 Oct 2005 12:20:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPjLK-00089a-Mi for enum@megatron.ietf.org; Wed, 12 Oct 2005 12:20:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03231 for ; Wed, 12 Oct 2005 12:20:35 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPjVd-00084j-CY for enum@ietf.org; Wed, 12 Oct 2005 12:31:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] voipeer agenda/charter uploaded Date: Wed, 12 Oct 2005 18:21:33 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C45E3@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] voipeer agenda/charter uploaded Thread-Index: AcXPPCoCDBntfWVVTeeBhq0+gJDLigADNil1 From: "Stastny Richard" To: "Peter Williams" X-Spam-Score: 0.8 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I cannot fully follow this whole discussion, but definetely I cannot parse this sentence: =20 >- the structure of validation entity and security domains is = orthogonoal to >the structure of the tree reflecting the adminsitrative rights of = providers >to create and modify entries in the ENUM name servers serving the tree could you please explain what this means in plain English? Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Peter Williams Gesendet: Mi 12.10.2005 16:44 Cc: enum@ietf.org Betreff: Re: [Enum] voipeer agenda/charter uploaded It would be natural to break down the strategic goals of ENUM = (rechartered) for the Carrier ENUM question, in terms of the following categories:: (If I start using ISO terms and modelling conventions for all this, = becuase its all been done before, slap me and remind me we are doing = _IETF-styled_ reinvention of carrier-based telephony) There will be multiple Carrier ENUM trees, one of which is public and ultimately, ICANN (i.e. US govt.) controlled. Within an Carrier ENUM tree, - voice providers will practice uniform and consistent peering - voice providers will provision name server entries and their contents - the structure of the tree will reflect the administrative rights of = the provider under NRA licensing - the structure of validation entity and security domains is orthogonoal = to the structure of the tree reflecting the adminsitrative rights of = providers to create and modify entries in the ENUM name servers serving the tree - ENUM name servers will reflect number registration, and number = porting, but will not directly perform registration or NP duties - An ENUM name server is not intended to be an identity service for = Carriers of Record, for current entries - A carrier's obligation to wiretap a subsriber line shall not impact or influence the adminsitration of or content of, an entry in an ENUM name server. - The adminsitration of entries, and the schema of services declared = within an entry, shall be administered by the COR for the E.164 number = identifying the entry - Any E.164 number issued pusuant to national regulatory authority = license may logically identify an entry. -Entries that declare CORs, NRAs, schema definitions, provider service access points and other administrative meta-data are not within the = scope of Carrier ENUM dliverables, though may be addessed in related ENUM series documents. ------------- The ENUM charter SHOULD NOT focus its text on the above! Rather, it = needs to characterise Carrier ENUM scheme, to be designed in the next round of WG activity. The deliverables that embody the above need to be identified, timetabled, and characterized, however, using the architectural = principles listed above. If the formulation of the charter is not occuring with the direct involvement of the folks who have already written Carrier ENUM drafts, = and can improve upon the above considerably, there is SOMETHING VERY WRONG = WITH THE TRANSPARENCY. Improve the process, co-chairs, and make it transparent and available to mailing list participants, per our community norms. Peter. >From: Christian de Larrinaga >To: David Meyer >CC: Peter Williams , enum@ietf.org, >Richard.Stastny@oefeg.at >Subject: Re: [Enum] voipeer agenda/charter uploaded >Date: Wed, 12 Oct 2005 11:21:43 +0100 > >Carrier ENUM is not mentioned here which is good I think. >But it is implied. >I would support a definition of Carrier ENUM as supporting peering/ = transit >and routing relationships but not for provisioning user services. >The VoiPeer charter seems to agree with this view? > >If so then it should be taken on board by those working on a carrier = ENUM >plan? > >Christian de Larrinaga >cdel@firsthand.net >Voex Inc. > > >On 11 Oct 2005, at 21:52, David Meyer wrote: > > >> Peter, >> >>On Tue, Oct 11, 2005 at 12:23:14PM -0700, Peter Williams wrote: >> >> >>>IAB required, in a carefully worded policy communciated through a=20 >>>co-chair >>>that its acceptance of Carrier ENUM work itmes is contingent on = aligning >>>voipeer.future and enum.future re-chartering. What this WG and its=20 >>>members >>>wants is irrelevant, per the last WG meeting and IAB considerations: = all >>>that matters is satisfying IAB's mandate, which we must assume to be = in >>>our >>>interests. >>> >>> >> >> Can you describe how you feel the IAB "required" this? >> I'm a little confused as >> >> (i). I'm not sure how that IAB can "require" >> anything; perhaps you mean s/IAB/IESG/ >> (that would make more sense), and >> >> (ii). I'm not sure what you think was "required" WRT >> Carrier ENUM alignment; there have been a lot of >> discussions around this, and it would be good to >> get everyone's assumptions on the table, and to >> make sure we're all using the same set. >> >> Can you (or anyone else) clarify these for us? >> >> >> >>>We have a good strawman from viopeer; its highly SIP specific,=20 >>>particularly >>>in some ENUM-related areas. >>> >>> >> >> SIP is the Internet-standard signalling protocol, after >> all. And we are talking about the Internet here (IETF and >> all). >> >> Thanks, >> >> Dave >> >> >> >> >>>We comment on their charter, BECAUSE we are REQUIRED to align with = their >>>goals, objectives, methods, timelines, etc - for good and obivous=20 >>>reasons >>>- if we want Carrier ENUM to be adopted into the standards track. >>> >>>Remember Carrier ENUM is not formally an IETF standards track = activity >>>today, and the rules on becoming so have been stated (and restated, = word >>>for word, indicating its a very sensitive topic). >>> >>> >>> >>> >>> >>>>From: "Stastny Richard" >>>>To: "Peter Williams" , >>>>Subject: Re: [Enum] voipeer agenda/charter uploaded >>>>Date: Tue, 11 Oct 2005 21:13:38 +0200 >>>> >>>>I do not understand what you want to say? >>>> >>>>This is the voipeer charter discussion and not >>>>the enum charter discussion >>>> >>>>BTW, estee,ed enum chairs, is there a enum charter proposal to = expect >>>>soon. >>>> >>>>With soon I mean before Vancouver >>>> >>>>Richard >>>> >>>> >>>>________________________________ >>>> >>>>Von: enum-bounces@ietf.org im Auftrag von Peter Williams >>>>Gesendet: Di 11.10.2005 21:03 >>>>An: enum@ietf.org >>>>Betreff: RE: [Enum] voipeer agenda/charter uploaded >>>> >>>> >>>> >>>> >>>>FROM Proposed VIOPEER Charter: >>>> >>>>"Routing fo sessions which are not signaled using SIP. In >>>> particular, voipeer is constrained to consider only those >>>> scenarios in which call routing is signaled using the >>>> SIP protocol and addressed by SIP or SIPS URIs or E.164 >>>> (public telephone number) addresses. By extension, national >>>> and private formats numbering formats are out of scope for >>>> voipeer" >>>> >>>>ENUM has broader scope, including H.323 URLs. >>>> >>>>ENUM Charter needs to be session protocol agnostic, in essence. So = its >>>>the >>>>architectural support for multiple session/setup protocols thats=20 >>>>required, >>>>not any particular love of H.323. >>>> >>>>Interaction between ENUM and VIOP peering must be only in the = generic >>>>areas, >>>>not SIP-specific areas. >>>> >>>>I see no reason why ENUM should not be optionally "tuned" for = today's >>>>SIP, >>>>but not "architected" for SIP. There is little doubt that E.164 and >>>>ENUM >>>>will, given their role, be around far longer than SIP will be. >>>> >>>>All private and national number formats (that are conforming to E. = 164 ) >>>>are >>>>within the scope of ENUM. >>>> >>>>In essence, ENUM is not just a name server for today's SIP proxies. = It >>>>has >>>>a >>>>bigger role to play in the Internet. At the same time, it should = play >>>>in >>>>today's adoption space! >>>> >>>> >>>> >>>>>From: David Meyer >>>>>To: voipeer@lists.uoregon.edu >>>>>CC: enum@ietf.org, sipping@ietf.org, jon.peterson@neustar.biz, >>>>>mankin@psg.com >>>>>Subject: [Enum] voipeer agenda/charter uploaded >>>>>Date: Tue, 11 Oct 2005 11:06:44 -0700 >>>>> >>>>> >>>>> Please see >>>>> >>>>> http://www3.ietf.org/proceedings/05nov/agenda/voipeer.txt >>>>> >>>>> Note that the bulk of our session will be devoted to >>>>> hammering out our charter (charter bashing). >>>>> >>>>> Thanks, >>>>> >>>>> Dave >>>>> >>>>> >>>> >>>> >>>> >>>> >>>>><< attach4 >> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>_______________________________________________ >>>>>enum mailing list >>>>>enum@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/enum >>>>> >>>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>enum mailing list >>>>enum@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/enum >>>> >>>> >>>> >>>> >>> >>> >>> >>>_______________________________________________ >>>enum mailing list >>>enum@ietf.org >>>https://www1.ietf.org/mailman/listinfo/enum >>> >>> >>_______________________________________________ >>enum mailing list >>enum@ietf.org >>https://www1.ietf.org/mailman/listinfo/enum >> >> > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 13 07:36:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ1Ns-0002Gs-UE; Thu, 13 Oct 2005 07:36:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ1Nr-0002GF-HK for enum@megatron.ietf.org; Thu, 13 Oct 2005 07:36:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11395 for ; Thu, 13 Oct 2005 07:36:23 -0400 (EDT) Received: from bm.firsthand.net ([80.68.91.165] helo=plesktest.vm.bytemark.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ1YL-0000HX-PL for enum@ietf.org; Thu, 13 Oct 2005 07:47:19 -0400 Received: (qmail 22171 invoked from network); 13 Oct 2005 13:43:11 +0100 Received: from unknown (HELO ?81.6.214.204?) (81.6.214.204) by bm.firsthand.net with SMTP; 13 Oct 2005 13:43:11 +0100 In-Reply-To: <20051012161220.GA17197@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D461B2190@oefeg-s04.oefeg.loc> <56133BD2-7FD5-4919-B420-DD5A88136AFE@firsthand.net> <20051012161220.GA17197@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v734) Message-Id: From: Christian de Larrinaga Subject: Re: [Enum] voipeer agenda/charter uploaded Date: Thu, 13 Oct 2005 12:35:40 +0100 To: David Meyer X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.3 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: enum@ietf.org, Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1339157932==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1339157932== Content-Type: multipart/alternative; boundary=Apple-Mail-1-572285396 --Apple-Mail-1-572285396 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit David It's a framework for clarity in a murky world. I suspect adding more (than RFC 2826) would only obfuscate rather than enlighten at this point. But I'm willing to listen. Christian David > Christian, > > I'm not sure why one needs stated support for 2826. Asked > another way, what more (than RFC 2826) needs to be said > about unique roots? > Dave > Christian --Apple-Mail-1-572285396 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
David=A0

It's a framework for = clarity in a murky world.=A0
I suspect adding more (than = RFC 2826) would only obfuscate rather than enlighten at this point. But = I'm willing to listen.=A0


Christian=A0


David


=A0 =A0 = Christian,

=A0 =A0 I'm not sure why one needs = stated support for 2826. Asked
=A0 =A0 another way, what more (than RFC 2826) needs = to be said
=A0 =A0 about unique = roots?
=A0 =A0= Dave



Christian=A0

= --Apple-Mail-1-572285396-- --===============1339157932== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1339157932==-- From enum-bounces@ietf.org Thu Oct 13 12:15:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5k0-0004UX-I3; Thu, 13 Oct 2005 12:15:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5jy-0004US-Nk for enum@megatron.ietf.org; Thu, 13 Oct 2005 12:15:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26496 for ; Thu, 13 Oct 2005 12:15:30 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ5uW-00089L-H4 for enum@ietf.org; Thu, 13 Oct 2005 12:26:29 -0400 Received: from [10.31.13.193] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9DGFlBj028110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Oct 2005 09:15:49 -0700 Message-ID: <434E8806.6070602@shockey.us> Date: Thu, 13 Oct 2005 12:15:02 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Subject: [Enum] IETF 43 Vancouver Agenda Items X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is what I have so far. Of note Alex Mayhofer will be joining the podium as our new ENUM WG Secretary ... his first job will be the taking and management of the WG Minutes and assisting the chairs in ID document NIT review and processing. IETF 64 Telephone Number Mapping (ENUM) WG Agenda (Proposed) Chair(s): Patrik Faltstrom Richard Shockey WG Secretary(ies): Alex Mayrhofer Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: Allison Mankin (Tentative) TUESDAY, November 8, 2005 1740-1840 Afternoon Session III TSV enum Telephone Number Mapping WG AGENDA BASHING (5 min) 1. Ready to Go Items. A. ENUM Implementers Draft: (Final Version) + B. Title : ENUM Requirement for EDNS0 Support Author(s) : L. Conroy, J. Reid Filename : draft-conroy-enum-edns0-00.txt Pages : 16 Date : 2005-10-10 This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support ENUM query resolution. This requirement is needed as DNS responses to ENUM-related questions return large RRSets. Without EDNS0 support in all the involved entities, a fallback to TCP transport for ENUM queries and responses would typically occur. That has a severe impact on DNS Server load, and on latency of ENUM queries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-conroy-enum-edns0-00.txt 2. New Work Items. A. Title : IANA Registration for Enumservice vCard Author(s) : A. Mayrhofer, D. Lindner Filename : draft-mayrhofer-enum-vcard-00.txt Pages : 7 Date : 2005-10-5 This memo registers the Enumservice "vCard" using the URI schemes "http" and "https" according to the IANA Enumservice registration process described in RFC3671. This Enumservice is to be used to refer from an ENUM domain name to the vCard of the entity using the corresponding E.164 number. Clients may use information gathered from those vCards before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before he picks up the call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-vcard-00.txt B. ENUM API In the hopper 3 Old Items: A. Carier ENUM Requirements? B IANA Registration for PSTN Signalling Information C. Validation Drafts Title : ENUM Validation Architecture Author(s) : A. Mayrhofer, B. Hoeneisen Filename : draft-ietf-enum-validation-arch-00.txt Pages : 16 Date : 2005-10-6 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-00.txt Title : ENUM Validation Token Format Definition Author(s) : O. Lendl Filename : draft-ietf-enum-validation-token-00.txt Pages : 16 Date : 2005-10-10 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-token-00.txt 4. Recharter Discussion _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 13 12:40:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ67s-00048R-Go; Thu, 13 Oct 2005 12:40:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ67p-000487-Qs for enum@megatron.ietf.org; Thu, 13 Oct 2005 12:40:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27823 for ; Thu, 13 Oct 2005 12:40:09 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ6IM-0000L4-Lj for enum@ietf.org; Thu, 13 Oct 2005 12:51:08 -0400 Received: from [10.31.13.193] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9DGeS2H030324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Oct 2005 09:40:29 -0700 Message-ID: <434E8DCE.2000903@shockey.us> Date: Thu, 13 Oct 2005 12:39:42 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Subject: [Enum] ENUM WG RECHARTER : My initial proposal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Comments are welcome. ############### The ENUM working group has defined a DNS-based architecture and protocol [RFC 3761] by which an E.164 number, as defined in ITU Recommendation E.164, can be expressed as a Fully Qualified Domain Name in a specific Internet Infrastructure domain defined for this purpose (e164.arpa). Background: E.164 numbers are globally unique, language independent identifiers for resources on Public Telecommunication Networks that can support many different services and protocols. There is an emerging desire for network operators to utilize aspects of RFC 3761 to discover points of interconnection necessary to terminate communications sessions identified by a E164 number,in addition to identifying end point protocols and services. Working Group Revised Goals and Scope: 1. The working group will update RFC 3761 and advance to Draft Standard. 2. The working group will examine and document the use of RFC 3761 to facilitate VoIP network interconnection. The Working group will coordinate its activities with other IETF working groups, existing or to be chartered, that are investigating elements of VoIP network peering. 3. The working group will continue examine and document various aspects of ENUM administrative and /or operational procedures irrespective of whether e164.arpa domain is used. 4. The working group will also examine the use of RFC 3761 technology for describing various PSTN signaling data. 5. The Working Group will continue to maintain appropriate contact and liaison with other standards bodies and groups, specifically ITU-T SG2, to provide technical or educational information as needed, such as the appropriate use of DNS. In addition the Working Group will continue to encourage the exchange of technical information within the emerging global ENUM community as well as documentation on practical experiences with implementations, alternate technology uses and the administration and provisioning of RFC 3761. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 13 13:39:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ73V-0005Jc-TP; Thu, 13 Oct 2005 13:39:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ73U-0005JW-Gx for enum@megatron.ietf.org; Thu, 13 Oct 2005 13:39:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01062 for ; Thu, 13 Oct 2005 13:39:43 -0400 (EDT) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQ7Dx-0001z5-8M for enum@ietf.org; Thu, 13 Oct 2005 13:50:43 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1129225097!8510483!29 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 8961 invoked from network); 13 Oct 2005 17:39:31 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-11.tower-120.messagelabs.com with SMTP; 13 Oct 2005 17:39:31 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 432D9032005CF44D; Thu, 13 Oct 2005 13:39:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] ENUM WG RECHARTER : My initial proposal Date: Thu, 13 Oct 2005 13:39:29 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0B512A5E@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Enum] ENUM WG RECHARTER : My initial proposal Thread-Index: AcXQFQHM8dOQiUgoRcC1ksQNWH7wOwABkQqw From: "Pfautz, Penn L, NEO" To: "Richard Shockey" , X-Spam-Score: 0.8 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Rich: Good start. I offer in-line below some suggestions and things to think about. Penn=20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Thursday, October 13, 2005 12:40 PM To: 'enum@ietf.org' Subject: [Enum] ENUM WG RECHARTER : My initial proposal Comments are welcome. ############### The ENUM working group has defined a DNS-based architecture and protocol [RFC 3761] by which an E.164 number, as defined in ITU Recommendation=20 E.164, can be expressed as a Fully Qualified Domain Name in a specific=20 Internet Infrastructure domain defined for this purpose (e164.arpa). Background: E.164 numbers are globally unique, language independent identifiers for=20 resources on Public Telecommunication Networks that can support many=20 different services and protocols. There is an emerging desire for=20 network operators to utilize aspects of RFC 3761 to discover points of=20 interconnection necessary to terminate communications sessions=20 identified by a E164 number,in addition to identifying end point=20 protocols and services. Working Group Revised Goals and Scope: 1. The working group will update RFC 3761 and advance to Draft Standard. 2. The working group will examine and document the use of RFC 3761 to=20 facilitate VoIP network interconnection. The Working group will=20 coordinate its activities with other IETF working groups, existing or to be chartered, that are investigating elements of VoIP network peering. >>> while VoIP is clearly the driver at this point shouldn't scope include >>> interconnection for any E.164 addressed service 3. The working group will continue examine and document various aspects=20 of ENUM administrative and /or operational procedures irrespective of=20 whether e164.arpa domain is used. 4. The working group will also examine the use of RFC 3761 technology=20 for describing various PSTN signaling data. >>> I assume this is the NP data, which is signaled, but I'd prefer a more expansive wording: >>> "use of RFC 3761 technology for making available other information about E.164 numbers >>> needed by carriers, including information for PSTN call routing and signaling." 5. The Working Group will continue to maintain appropriate contact and=20 liaison with other standards bodies and groups, specifically ITU-T SG2,=20 to provide technical or educational information as needed, such as the appropriate use of DNS.=20 >>> this sounds a little one-way. How about adding "and address, as needed, >>> any issues relating to the E.164 numbering plan." In addition the Working Group will continue to=20 encourage the exchange of technical information within the emerging=20 global ENUM community as well as documentation on practical experiences=20 with implementations, alternate technology uses and the administration=20 and provisioning of RFC 3761. --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 13 14:19:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7fQ-0002Hx-MV; Thu, 13 Oct 2005 14:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7fP-0002Hp-5A for enum@megatron.ietf.org; Thu, 13 Oct 2005 14:18:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03658 for ; Thu, 13 Oct 2005 14:18:50 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ7pu-0003BL-3W for enum@ietf.org; Thu, 13 Oct 2005 14:29:50 -0400 Received: from [10.31.13.193] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9DIJExX007841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Oct 2005 11:19:16 -0700 Message-ID: <434EA4F4.7000606@shockey.us> Date: Thu, 13 Oct 2005 14:18:28 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" , "Pfautz, Penn L, NEO" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] ENUM WG RECHARTER : My initial proposal V.01 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Penn ...I like it ! How does this sound? ############### The ENUM working group has defined a DNS-based architecture and protocol [RFC 3761] by which an E.164 number, as defined in ITU Recommendation E.164, can be expressed as a Fully Qualified Domain Name in a specific Internet Infrastructure domain defined for this purpose (e164.arpa). Background: E.164 numbers are globally unique, language independent identifiers for resources on Public Telecommunication Networks that can support many different services and protocols. There is an emerging desire for network operators to utilize aspects of RFC 3761 to discover points of interconnection necessary to terminate communications sessions identified by a E164 number,in addition to identifying end point protocols and services. Working Group Revised Goals and Scope: 1. The working group will update RFC 3761 and advance to Draft Standard. 2. The working group will examine and document the use of RFC 3761 to facilitate network interconnection for services using E.164 addressing. The Working group will coordinate its activities with other IETF working groups, existing or to be chartered, that are investigating elements of VoIP or other service network peering that typically use E.164 addressing. 3. The working group will continue examine and document various aspects of ENUM administrative and /or operational procedures irrespective of whether e164.arpa domain is used. 4. The working group will also examine the use of RFC 3761 technology for defining other information about services addressed by E.164 numbers, for example PSTN call routing and signaling data. 5. The Working Group will continue to maintain appropriate contact and liaison with other standards bodies and groups, specifically ITU-T SG2, to provide technical or educational information and address, as needed, issues related to the use of the E.164 numbering plan for services on IP networks. In addition the Working Group will continue to encourage the exchange of technical information within the emerging global ENUM community as well as documentation on practical experiences with implementations, alternate technology uses and the administration and provisioning of RFC 3761. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 13 17:08:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAJj-0000Hx-C3; Thu, 13 Oct 2005 17:08:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAJe-0000HD-PY; Thu, 13 Oct 2005 17:08:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17458; Thu, 13 Oct 2005 17:08:38 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQAUF-000162-Aa; Thu, 13 Oct 2005 17:19:39 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EQAJd-0001Ss-UO; Thu, 13 Oct 2005 17:08:41 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 13 Oct 2005 17:08:41 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: enum@ietf.org Subject: [Enum] Last Call: 'An ENUM Registry Type for the Internet Registry Information Service' to Proposed Standard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The IESG has received a request from the Telephone Number Mapping WG to consider the following document: - 'An ENUM Registry Type for the Internet Registry Information Service ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-10-27. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-iris-ereg-02.txt _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 14 09:55:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQ1W-00081z-H3; Fri, 14 Oct 2005 09:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQ1U-0007xo-3R for enum@megatron.ietf.org; Fri, 14 Oct 2005 09:55:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11395 for ; Fri, 14 Oct 2005 09:54:54 -0400 (EDT) Received: from sip.mah.priv.at ([81.223.16.194] helo=www.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQQCC-00047C-DE for enum@ietf.org; Fri, 14 Oct 2005 10:06:05 -0400 Received: from localhost ([127.0.0.1] helo=mah9.inode.at) by www.mah.priv.at with esmtp (Exim 3.36 #1 (Debian)) id 1EQQ15-00029A-00; Fri, 14 Oct 2005 15:54:36 +0200 Message-Id: <6.2.5.6.2.20051014150234.047058f8@inode.at> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 14 Oct 2005 15:38:10 +0200 To: Richard Shockey From: Michael Haberler Subject: Re: [Enum] A proposal for Carrier ENUM - Oops In-Reply-To: <434BD251.1040505@shockey.us> References: <07BC6C0D40216E44A34BE6701694FE86018627E6@POSTI.laru.local> <434BCA0F.8030402@shockey.us> <434BD251.1040505@shockey.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-D30F98 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: enum@ietf.org, Nieminen Klaus X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org At 16:55 11.10.2005, Richard Shockey wrote: >The fact is that call forwarding aka "onward routing" eventually >places an unacceptable burden on the incumbents infrastructure. The >PSTN is beginning to learn what the Internet knew from the beginning >is that you need a formal abstraction between naming ( the TN ) and >network addressing ( the routing number) and that the PSTN needs to >evolve to a "all call query" model. Ok, it's out - Austria has no such NP database. So I had the idea to - in the context of emergency call support - collate that database, by starting with the blocks allocated DB from the NRA, tap into the porting data flow, and add that to the DB incrementally. Over time that would become a pretty good picture. And, in exchange for better support of emergency service operators, , tapping into the data flow should be socially acceptable, right? Right - BUT it turned out that this kind of data flow is largely a paper flow - by fax (except for MNP, where the operators *FTP diff files* around..) -Michael _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 14 10:36:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQfe-0006Qm-HS; Fri, 14 Oct 2005 10:36:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQfc-0006Qb-BU for enum@megatron.ietf.org; Fri, 14 Oct 2005 10:36:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14161 for ; Fri, 14 Oct 2005 10:36:22 -0400 (EDT) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQQqK-0005MO-Vc for enum@ietf.org; Fri, 14 Oct 2005 10:47:34 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id j9EEaK0W009472Fri, 14 Oct 2005 14:36:20 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1EQQfU-0008gA-00; Fri, 14 Oct 2005 15:36:20 +0100 Date: Fri, 14 Oct 2005 15:36:20 +0100 From: "Clive D.W. Feather" To: Otmar Lendl Subject: Re: [Enum] A proposal for Carrier ENUM Message-ID: <20051014143620.GA32278@finch-staff-1.thus.net> References: <34DA635B184A644DA4588E260EC0A25A0B4AFEB9@ACCLUST02EVS1.ugd.att.com> <20051011134120.GA1196@nic.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051011134120.GA1196@nic.at> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Otmar Lendl said: >> Maybe some of those whose >> countries use "onward routing" etc. can confirm >> whether there is any centralized database outside of the network >> detailing those arrangements. > > Austria uses onward routing for fixed line NP. There is no centralized > DB which shows which number has been ported to whom. The same is true in the UK. > The NRA only keeps tabs on what number have been ported, but this > DB does not include the information necessary to route calls. The UK doesn't even have that. It's a commercial arrangement between the two operators. [The existence of the arrangement is mandated by EU Directives, but the details aren't.] -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 14 10:39:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQis-0007Vu-MC; Fri, 14 Oct 2005 10:39:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQir-0007Vn-Na for enum@megatron.ietf.org; Fri, 14 Oct 2005 10:39:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14303 for ; Fri, 14 Oct 2005 10:39:45 -0400 (EDT) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQQtb-0005R9-D9 for enum@ietf.org; Fri, 14 Oct 2005 10:50:55 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id j9EEdkn0010628Fri, 14 Oct 2005 14:39:46 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1EQQio-0008r0-00; Fri, 14 Oct 2005 15:39:46 +0100 Date: Fri, 14 Oct 2005 15:39:46 +0100 From: "Clive D.W. Feather" To: "Pfautz, Penn L, NEO" Subject: Re: [Enum] A proposal for Carrier ENUM Message-ID: <20051014143946.GB32278@finch-staff-1.thus.net> References: <34DA635B184A644DA4588E260EC0A25A0B4AFEB9@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0B4AFEB9@ACCLUST02EVS1.ugd.att.com> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: enum@ietf.org, Nieminen Klaus X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Pfautz, Penn L, NEO said: > Nonetheless, I do think that for the most part it will be possible to > determine who the carrier providing the PSTN point of interface for an > E.164 number is and thus the carrier-of-record for carrier ENUM. If this > information were not generally available the E.164 number would not be > of much use anyway. In the UK model, the national call routeing system points at the "donor operator". Calls are routed to that operator, who then adds a prefix to the number - pointing at the terminating operator - and re-injects the call into the network to be re-routed. Thus to identify the carrier providing the PSTN point of interface: (1) You need to identify the donor operator. (2) You need to ask the donor operator to indicate whether the number has been ported and, if so, who the recipient operator is. It's (2) that's the hard bit, because there is no mechanism for it and no commercial or regulatory imperative to create one. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 14 13:58:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQTp5-0003zy-NH; Fri, 14 Oct 2005 13:58:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQTp3-0003yt-QR for enum@megatron.ietf.org; Fri, 14 Oct 2005 13:58:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02943 for ; Fri, 14 Oct 2005 13:58:20 -0400 (EDT) From: james.f.baskin@verizon.com Received: from ftwmail2.verizon.com ([192.76.86.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQTzk-0005FU-50 for enum@ietf.org; Fri, 14 Oct 2005 14:09:33 -0400 Received: from smtptpa.verizon.com (smtptpa.verizon.com [138.83.66.45]) by ftwmail2.verizon.com (8.13.3/8.13.3) with ESMTP id j9EHvrb1013579 for ; Fri, 14 Oct 2005 12:57:53 -0500 (EST) Received: from usflttpstcmms01.ent.verizon.com (TPAMMS01A.interwan.gte.com [138.83.67.219]) by smtptpa.verizon.com (8.13.3/8.13.3) with ESMTP id j9EHvk12001142 for ; Fri, 14 Oct 2005 13:57:49 -0400 (EDT) Received: from 138.83.34.22 by usflttpstcmms01.ent.verizon.com with ESMTP (SMTP Relay); Fri, 14 Oct 2005 13:57:38 -0400 X-Server-Uuid: 6DE10D69-EE37-4E03-9906-4AAEC0FB8277 Received: from dwsmtp01.core.verizon.com (dwsmtp01.verizon.com [138.83.35.62]) by coregate1.verizon.com (8.13.3/8.13.3) with ESMTP id j9EHvZSX017693 for ; Fri, 14 Oct 2005 12:57:37 -0500 ( CDT) To: enum@ietf.org Subject: Re: [Enum] A proposal for Carrier ENUM MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Fri, 14 Oct 2005 13:57:33 -0400 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.5.4HF453 | August 4, 2005) at 10/14/2005 12:57:37, Serialize complete at 10/14/2005 12:57:37 X-WSS-ID: 6F512E1B4YO1409192-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org In the UK number portability model, perhaps the donor operator _should_ be the carrier-of-record for carrier ENUM. The donor is, after all, the only carrier known to PSTN routing databases for a ported number. This could actually work in reasonable ways. (1) The donor could populate carrier ENUM with direct pointers to recipient operators' gateways. Thus, for calls from originating carriers who choose to do a carrier ENUM query, the donor operator could avoid having to handle the prefix and re-injection function. (2) The recipient operator could use End-user ENUM to populate any other NAPTRs that it might determine to be useful (this would require end-user opt-in, but that could be obtained as part of the original porting transaction.) (3) Carrier ENUM could be used to build a number portability database that could eventually eliminate the donor operator's (unwanted and costly?) involvement in PSTN call routing for ported numbers. Determination of which party is the carrier-of-record (PSTN POI) is a national matter. Some countries could use the donor model, and others could use different models. The IETF should design Carrier ENUM to work regardless and independent of the national carrier-of-record decision. Jim Baskin Clive Feather wrote: >Pfautz, Penn L, NEO said: >> Nonetheless, I do think that for the most part it will be possible to >> determine who the carrier providing the PSTN point of interface for an >> E.164 number is and thus the carrier-of-record for carrier ENUM. If this >> information were not generally available the E.164 number would not be >> of much use anyway. > >In the UK model, the national call routeing system points at the "donor >operator". Calls are routed to that operator, who then adds a prefix to the >number - pointing at the terminating operator - and re-injects the call >into the network to be re-routed. Thus to identify the carrier providing >the PSTN point of interface: >(1) You need to identify the donor operator. >(2) You need to ask the donor operator to indicate whether the number has > been ported and, if so, who the recipient operator is. > >It's (2) that's the hard bit, because there is no mechanism for it and no >commercial or regulatory imperative to create one. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 14 15:01:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQUoH-0006s7-RO; Fri, 14 Oct 2005 15:01:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQUoF-0006qb-Ll for enum@megatron.ietf.org; Fri, 14 Oct 2005 15:01:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05269 for ; Fri, 14 Oct 2005 15:01:34 -0400 (EDT) Received: from mail114.messagelabs.com ([195.245.231.163]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQUyx-0006b4-Cq for enum@ietf.org; Fri, 14 Oct 2005 15:12:48 -0400 X-VirusChecked: Checked X-Env-Sender: Paul.Rosbotham@cwmsg.cwplc.com X-Msg-Ref: server-3.tower-114.messagelabs.com!1129316480!22623439!1 X-StarScan-Version: 5.4.15; banners=cwmsg.cwplc.com,-,- X-Originating-IP: [194.6.6.20] Received: (qmail 5987 invoked from network); 14 Oct 2005 19:01:20 -0000 Received: from mx.cwplc.com (194.6.6.20) by server-3.tower-114.messagelabs.com with SMTP; 14 Oct 2005 19:01:20 -0000 Received: from GBCWSWIEV001.ad.plc.cwintra.com ([148.185.93.211]) by mx.cwplc.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j9EIx2C07901 for ; Fri, 14 Oct 2005 19:59:02 +0100 (BST) Received: from GBCWSWIEC002.ad.plc.cwintra.com (unverified) by GBCWSWIEV001.ad.plc.cwintra.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Fri, 14 Oct 2005 20:02:30 +0100 Received: from GBCWSWIEM002.ad.plc.cwintra.com ([148.185.93.204]) by GBCWSWIEC002.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 20:02:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] A proposal for Carrier ENUM Date: Fri, 14 Oct 2005 20:02:30 +0100 Message-ID: <9322B78036E1534A99B0BC51DEB0F9D6017259DF@GBCWSWIEM002.ad.plc.cwintra.com> Thread-Topic: [Enum] A proposal for Carrier ENUM Thread-Index: AcXQ6aAcdhxV0k6gQL6r2KgaFTixgAAB0/hw From: "Rosbotham, Paul" To: X-OriginalArrivalTime: 14 Oct 2005 19:02:30.0500 (UTC) FILETIME=[D38F3240:01C5D0F1] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Cc: james.f.baskin@verizon.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org As=20Chair=20of=20the=20UK=20group=20that's=20looking=20at=20NP=20solution= s=20in=20the=20NGN=20era,=20I'm=20going=20to=20ask=20that=20we=20call=20a=20= halt=20to=20this=20particular=20thread=20because,=20as=20Jim=20says=20in=20= his=20final=20paragraph=20it=20is=20one=20which=20is=20clearly=20a=20natio= nal=20matter=20(no=20offence=20Jim,=20I=20realise=20you're=20only=20trying= =20to=20help).=20=20 Should=20carrier=20ENUM=20come=20to=20fruition,=20it=20could=20well=20form= =20the=20nucleus=20of=20the=20central=20database=20that=20is=20used=20for=20= NP=20in=20the=20UK=20:=20however,=20it=20is=20premature=20to=20determine=20= this,=20and=20once=20again=20this=20is=20clearly=20a=20national=20matter. As=20I=20outlined=20earlier=20in=20the=20week,=20I=20don't=20believe=20tha= t=20IETF=20need=20go=20any=20further=20than=20specifying=20that=20the=20en= tity=20populating=20Carrier=20ENUM=20be=20the=20one=20providing=20PSTN=20s= ervice=20to=20the=20number=20in=20question. Regards Paul=20Rosbotham Manager,=20Interconnect=20Strategy=20&=20Technology=20Regulation Cable=20&=20Wireless=20plc Tel=20:=09+44=201772=20451506 Mob=20:=09+44=207957=20805573 -----Original=20Message----- From:=20enum-bounces@ietf.org=20[mailto:enum-bounces@ietf.org]On=20Behalf=20= Of james.f.baskin@verizon.com Sent:=20Friday,=20October=2014,=202005=206:58=20PM To:=20enum@ietf.org Subject:=20Re:=20[Enum]=20A=20proposal=20for=20Carrier=20ENUM In=20the=20UK=20number=20portability=20model,=20perhaps=20the=20donor=20op= erator=20_should_=20 be=20the=20carrier-of-record=20for=20carrier=20ENUM.=20=20The=20donor=20is= ,=20after=20all,=20 the=20only=20carrier=20known=20to=20PSTN=20routing=20databases=20for=20a=20= ported=20number.=20 This=20could=20actually=20work=20in=20reasonable=20ways.=20 (1)=20The=20donor=20could=20populate=20carrier=20ENUM=20with=20direct=20po= inters=20to=20 =20=20=20=20recipient=20operators'=20gateways.=20=20Thus,=20for=20calls=20= from=20originating=20 =20=20=20=20carriers=20who=20choose=20to=20do=20a=20carrier=20ENUM=20query= ,=20the=20donor=20operator=20 =20=20=20=20could=20avoid=20having=20to=20handle=20the=20prefix=20and=20re= -injection=20function. (2)=20The=20recipient=20operator=20could=20use=20End-user=20ENUM=20to=20po= pulate=20any=20 =20=20=20=20other=20NAPTRs=20that=20it=20might=20determine=20to=20be=20use= ful=20(this=20would=20 =20=20=20=20require=20end-user=20opt-in,=20but=20that=20could=20be=20obtai= ned=20as=20part=20of=20the=20 =20=20=20=20original=20porting=20transaction.)=20 (3)=20Carrier=20ENUM=20could=20be=20used=20to=20build=20a=20number=20porta= bility=20database=20 =20=20=20=20that=20could=20eventually=20eliminate=20the=20donor=20operator= 's=20(unwanted=20and=20 =20=20=20=20costly?)=20involvement=20in=20PSTN=20call=20routing=20for=20po= rted=20numbers.=20 Determination=20of=20which=20party=20is=20the=20carrier-of-record=20(PSTN=20= POI)=20is=20a=20 national=20matter.=20=20Some=20countries=20could=20use=20the=20donor=20mod= el,=20and=20others=20 could=20use=20different=20models.=20=20The=20IETF=20should=20design=20Carr= ier=20ENUM=20to=20work=20 regardless=20and=20independent=20of=20the=20national=20carrier-of-record=20= decision. Jim=20Baskin Clive=20Feather=20wrote: >Pfautz,=20Penn=20L,=20NEO=20said: >>=20Nonetheless,=20I=20do=20think=20that=20for=20the=20most=20part=20it=20= will=20be=20possible=20to >>=20determine=20who=20the=20carrier=20providing=20the=20PSTN=20point=20of= =20interface=20for=20an >>=20E.164=20number=20is=20and=20thus=20the=20carrier-of-record=20for=20ca= rrier=20ENUM.=20If=20 this >>=20information=20were=20not=20generally=20available=20the=20E.164=20numb= er=20would=20not=20be >>=20of=20much=20use=20anyway. > >In=20the=20UK=20model,=20the=20national=20call=20routeing=20system=20poin= ts=20at=20the=20"donor >operator".=20Calls=20are=20routed=20to=20that=20operator,=20who=20then=20= adds=20a=20prefix=20to=20 the >number=20-=20pointing=20at=20the=20terminating=20operator=20-=20and=20re-= injects=20the=20call >into=20the=20network=20to=20be=20re-routed.=20Thus=20to=20identify=20the=20= carrier=20providing >the=20PSTN=20point=20of=20interface: >(1)=20You=20need=20to=20identify=20the=20donor=20operator. >(2)=20You=20need=20to=20ask=20the=20donor=20operator=20to=20indicate=20wh= ether=20the=20number=20has >=20=20=20=20been=20ported=20and,=20if=20so,=20who=20the=20recipient=20ope= rator=20is. > >It's=20(2)=20that's=20the=20hard=20bit,=20because=20there=20is=20no=20mec= hanism=20for=20it=20and=20no >commercial=20or=20regulatory=20imperative=20to=20create=20one. _______________________________________________ enum=20mailing=20list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum This=20e-mail=20has=20been=20scanned=20for=20viruses=20by=20the=20Cable=20= &=20Wireless=20e-mail=20security=20system=20-=20powered=20by=20MessageLabs= .=20For=20more=20information=20on=20a=20proactive=20managed=20e-mail=20sec= urity=20service,=20=20visit=20http://www.cw.com/uk/emailprotection/=20 =20 The=20information=20contained=20in=20this=20e-mail=20is=20confidential=20a= nd=20may=20also=20be=20subject=20to=20legal=20privilege.=20It=20is=20inten= ded=20only=20for=20the=20recipient(s)=20named=20above.=20If=20you=20are=20= not=20named=20above=20as=20a=20recipient,=20you=20must=20not=20read,=20cop= y,=20disclose,=20forward=20or=20otherwise=20use=20the=20information=20cont= ained=20in=20this=20email.=20If=20you=20have=20received=20this=20e-mail=20= in=20error,=20please=20notify=20the=20sender=20(whose=20contact=20details=20= are=20above)=20immediately=20by=20reply=20e-mail=20and=20delete=20the=20me= ssage=20and=20any=20attachments=20without=20retaining=20any=20copies. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 14 16:14:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVwu-0007l7-Qi; Fri, 14 Oct 2005 16:14:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVwt-0007kg-9E for enum@megatron.ietf.org; Fri, 14 Oct 2005 16:14:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14007 for ; Fri, 14 Oct 2005 16:14:33 -0400 (EDT) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQW7d-0001yF-Cv for enum@ietf.org; Fri, 14 Oct 2005 16:25:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] ENUM Working Group Last call on IANA Registration for Enumservice Voice Date: Fri, 14 Oct 2005 16:11:52 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73FF0777@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] ENUM Working Group Last call on IANA Registration for Enumservice Voice Thread-Index: AcW6FIoPxWjOy6v7QzGqPvgADurNIAW5F1BA From: "Livingood, Jason" To: X-OriginalArrivalTime: 14 Oct 2005 20:11:53.0678 (UTC) FILETIME=[8501BEE0:01C5D0FB] X-Spam-Score: 0.8 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: rudolf.brandner@siemens.com, "Conroy, Lawrence \(SMTP\)" , Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > This draft is sufficiently easy to understand that this can=20 > proceed immediately to last call as we discussed in Paris. Not to throw a wrench into the process, but can the authors please insert an examples section into the I-D? (Such as in RFC 3953, section 5, or draft-ietf-enum-void-01, section 6.) I find these very useful and it can often foster better / more efficient discussion about the application intended by drafts in general. I also find the ENUM service registration format from RFC 3953 (also RFC 3764, RFC 4002, draft-ietf-enum-void-01, draft-ietf-enum-msg-05, etc.) to be a good guide as well (copied text below from RFC 3953). It is useful if all of the ENUMservice registrations follow a (somewhat) uniform document format so that they may be more easily referenced by developers and people deploying ENUM-enabled services/technology. ENUM Service Registration As defined in [1], the following is a template covering information needed for the registration of the enumservice specified in this document: Service name: "E2U+pres" URI scheme(s): "pres:" Functional Specification: See section 4. Security considerations: See section 6. Intended usage: COMMON Author: Jon Peterson (jon.peterson@neustar.biz) Any other information that the author deems interesting: See section 3. Just my feedback, take it or leave it. :-) Thanks Jason Livingood =20 > I've noted no substantive issues with it. >=20 > Title : IANA Registration for Enumservice Voice > Author(s) : R. Brandner > Filename : draft-ietf-enum-voice-00.txt > Pages : 13 > Date : 2005-9-12 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 14 17:31:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQX8x-0001zG-L5; Fri, 14 Oct 2005 17:31:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQX8v-0001z1-Fr; Fri, 14 Oct 2005 17:31:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27141; Fri, 14 Oct 2005 17:31:05 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQXJh-0007Hf-Pn; Fri, 14 Oct 2005 17:42:19 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9ELUv17024023; Fri, 14 Oct 2005 14:30:57 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9ELUtHF024022; Fri, 14 Oct 2005 14:30:55 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 14 Oct 2005 14:30:55 -0700 From: David Meyer To: voipeer@lists.uoregon.edu Message-ID: <20051014213055.GA23988@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: enum@ietf.org, sipping@ietf.org Subject: [Enum] "straw-person" terminology draft posted X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1798513905==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1798513905== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks, I just posted draft-meyer-voipeer-terminology-00.txt. Please consider this a straw{man,woman,person} draft; I wanted to get something onto the I-D repository before the -00 cutoff, and so we'd have some canon fodder :-) Have a good weekend all, Dave --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDUCOPORgD1qCZ2KcRAunFAJ4zvf4WoMgKZ9oET5RQuyXOdj50LACdGCPO jaZdOOArRatMs/zbrAGmqR8= =kOfo -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- --===============1798513905== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1798513905==-- From enum-bounces@ietf.org Sat Oct 15 05:59:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQipB-0006Gu-DB; Sat, 15 Oct 2005 05:59:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQip8-0006Gp-S5 for enum@megatron.ietf.org; Sat, 15 Oct 2005 05:59:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01333 for ; Sat, 15 Oct 2005 05:59:25 -0400 (EDT) Received: from central.switch.ch ([130.59.11.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQj01-0007oZ-Gg for enum@ietf.org; Sat, 15 Oct 2005 06:10:46 -0400 Received: from machb.switch.ch ([130.59.6.129]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1EQinm-0006Zd-00; Sat, 15 Oct 2005 11:58:06 +0200 Date: Sat, 15 Oct 2005 11:57:52 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: "Livingood, Jason" Subject: RE: [Enum] ENUM Working Group Last call on IANA Registration for Enumservice Voice In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C73FF0777@PACDCEXCMB01.cable.comcast.com> Message-ID: References: <6EEEACD9D7F52940BEE26F5467C02C73FF0777@PACDCEXCMB01.cable.comcast.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: enum@ietf.org, rudolf.brandner@siemens.com, "Conroy, Lawrence \(SMTP\)" , Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Jason et al. On Fri, 14 Oct 2005, Livingood, Jason wrote: > Not to throw a wrench into the process, but can the authors please > insert an examples section into the I-D? (Such as in RFC 3953, section > 5, or draft-ietf-enum-void-01, section 6.) I find these very useful and > it can often foster better / more efficient discussion about the > application intended by drafts in general. I fully support the idea of having an example section in all ENUM service registration documents. When the ENUM service registration for H.323 URLs I/D (now RFC 3762) was in last call I also made such a LC comment, which unfortunately was ignored / not applied: http://www1.ietf.org/mail-archive/web/enum/current/msg02784.html Your comments bring me to the idea of making a "template" with guidelines for future ENUM service registrations. This would make it easier for the authors to write those and easier for the reader to understand. What do you (and other folks) think about? cheers, Bernie _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Oct 15 14:38:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQqvc-0003Bf-Te; Sat, 15 Oct 2005 14:38:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQqvb-0003BP-54 for enum@megatron.ietf.org; Sat, 15 Oct 2005 14:38:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22414 for ; Sat, 15 Oct 2005 14:38:35 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQr6X-0001zy-5X for enum@ietf.org; Sat, 15 Oct 2005 14:50:02 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9FIcMg01106; Sat, 15 Oct 2005 14:38:22 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] ENUM WG RECHARTER : My initial proposal V.01 Date: Sat, 15 Oct 2005 14:35:50 -0400 Message-ID: Thread-Topic: [Enum] ENUM WG RECHARTER : My initial proposal V.01 Thread-Index: AcXQI4Cx1L/Mjy+ERma74hACiA5PYwBhR06w From: "James McEachern" To: "Richard Shockey" , , "Pfautz, Penn L, NEO" X-Spam-Score: 0.8 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard,=20 A couple more comments in line. Jim -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = Richard Shockey Sent: Thursday, October 13, 2005 2:18 PM To: 'enum@ietf.org'; Pfautz, Penn L, NEO Subject: [Enum] ENUM WG RECHARTER : My initial proposal V.01 Penn ...I like it ! How does this sound? ############### The ENUM working group has defined a DNS-based architecture and protocol [RFC 3761] by which an E.164 number, as defined in ITU Recommendation E.164, can be expressed as a Fully Qualified Domain Name in a specific Internet Infrastructure domain defined for this purpose (e164.arpa). Background: E.164 numbers are globally unique, language independent identifiers for resources on Public Telecommunication Networks that can support many different services and protocols. There is an emerging desire for network operators to utilize aspects of RFC 3761 to discover points of interconnection necessary to terminate communications sessions identified by a E164 number,in addition to identifying end point protocols and services. Working Group Revised Goals and Scope: 1. The working group will update RFC 3761 and advance to Draft Standard. 2. The working group will examine and document the use of RFC 3761 to facilitate network interconnection for services using E.164 addressing.=20 The Working group will coordinate its activities with other IETF working = groups, existing or to be chartered, that are investigating elements of=20 VoIP or other service network peering >>is peering the right word here, or is it interconnection - or do they = mean >>the same thing in this context? that typically use E.164 addressing. 3. The working group will continue examine and document various aspects of ENUM administrative and /or operational procedures irrespective of whether e164.arpa domain is used. 4. The working group will also examine the use of RFC 3761 technology for defining >>"defining" doesn't sound quite right. Aren't we "storing and = >>communicating" this information - or something similar? other information about services addressed by E.164=20 numbers, for example PSTN call routing and signaling data. 5. The Working Group will continue to maintain appropriate contact and liaison with other standards bodies and groups, specifically ITU-T SG2, to provide technical or educational information and address, as needed,=20 issues related to the use of the E.164 numbering plan for services on IP = networks. In addition the Working Group will continue to encourage the=20 exchange of technical information within the emerging global ENUM=20 community as well as documentation on practical experiences with=20 implementations, alternate technology uses and the administration and=20 provisioning of RFC 3761. --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Oct 15 14:38:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQqvd-0003C4-KH; Sat, 15 Oct 2005 14:38:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQqvb-0003BQ-5Y for enum@megatron.ietf.org; Sat, 15 Oct 2005 14:38:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22412 for ; Sat, 15 Oct 2005 14:38:35 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQr6X-0001zp-5b for enum@ietf.org; Sat, 15 Oct 2005 14:50:01 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9FIcJg01103; Sat, 15 Oct 2005 14:38:20 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] A proposal for Carrier ENUM Date: Sat, 15 Oct 2005 14:35:42 -0400 Message-ID: Thread-Topic: [Enum] A proposal for Carrier ENUM Thread-Index: AcXQ6aAcdhxV0k6gQL6r2KgaFTixgAAB0/hwAC2T7hA= From: "James McEachern" To: "Rosbotham, Paul" , X-Spam-Score: 0.2 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: quoted-printable Cc: james.f.baskin@verizon.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Paul, I realize you asked to halt this thread, but I have one question for = clarification. Rather than "specifying that the entity populating = Carrier ENUM be the one providing PSTN service to the number in = question", wouldn't it make more sense to specify that the entity = populating Carrier ENUM be the one authorized by the national regulator = to populate Carrier ENUM for the number in question? Based on the previous discussion I can imagine that in some = circumstances it might be advantageous for the regulator to have the = donor carrier populate Carrier ENUM. If it truly is up to the national = regulator, perhaps we should simply recognize this, rather than presume = what the regulator will decide? Jim -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = Rosbotham, Paul Sent: Friday, October 14, 2005 3:03 PM To: enum@ietf.org Cc: james.f.baskin@verizon.com Subject: RE: [Enum] A proposal for Carrier ENUM As Chair of the UK group that's looking at NP solutions in the NGN era, = I'm going to ask that we call a halt to this particular thread because, = as Jim says in his final paragraph it is one which is clearly a national = matter (no offence Jim, I realise you're only trying to help). =20 Should carrier ENUM come to fruition, it could well form the nucleus of = the central database that is used for NP in the UK : however, it is = premature to determine this, and once again this is clearly a national = matter. As I outlined earlier in the week, I don't believe that IETF need go any = further than specifying that the entity populating Carrier ENUM be the = one providing PSTN service to the number in question. Regards Paul Rosbotham Manager, Interconnect Strategy & Technology Regulation Cable & Wireless plc Tel : +44 1772 451506 Mob : +44 7957 805573 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of james.f.baskin@verizon.com Sent: Friday, October 14, 2005 6:58 PM To: enum@ietf.org Subject: Re: [Enum] A proposal for Carrier ENUM In the UK number portability model, perhaps the donor operator _should_=20 be the carrier-of-record for carrier ENUM. The donor is, after all,=20 the only carrier known to PSTN routing databases for a ported number.=20 This could actually work in reasonable ways.=20 (1) The donor could populate carrier ENUM with direct pointers to=20 recipient operators' gateways. Thus, for calls from originating=20 carriers who choose to do a carrier ENUM query, the donor operator=20 could avoid having to handle the prefix and re-injection function. (2) The recipient operator could use End-user ENUM to populate any=20 other NAPTRs that it might determine to be useful (this would=20 require end-user opt-in, but that could be obtained as part of the=20 original porting transaction.)=20 (3) Carrier ENUM could be used to build a number portability database=20 that could eventually eliminate the donor operator's (unwanted and=20 costly?) involvement in PSTN call routing for ported numbers.=20 Determination of which party is the carrier-of-record (PSTN POI) is a=20 national matter. Some countries could use the donor model, and others=20 could use different models. The IETF should design Carrier ENUM to work = regardless and independent of the national carrier-of-record decision. Jim Baskin Clive Feather wrote: >Pfautz, Penn L, NEO said: >> Nonetheless, I do think that for the most part it will be possible to >> determine who the carrier providing the PSTN point of interface for = an >> E.164 number is and thus the carrier-of-record for carrier ENUM. If=20 this >> information were not generally available the E.164 number would not = be >> of much use anyway. > >In the UK model, the national call routeing system points at the "donor >operator". Calls are routed to that operator, who then adds a prefix to = the >number - pointing at the terminating operator - and re-injects the call >into the network to be re-routed. Thus to identify the carrier = providing >the PSTN point of interface: >(1) You need to identify the donor operator. >(2) You need to ask the donor operator to indicate whether the number = has > been ported and, if so, who the recipient operator is. > >It's (2) that's the hard bit, because there is no mechanism for it and = no >commercial or regulatory imperative to create one. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum This e-mail has been scanned for viruses by the Cable & Wireless e-mail = security system - powered by MessageLabs. For more information on a = proactive managed e-mail security service, visit = http://www.cw.com/uk/emailprotection/=20 =20 The information contained in this e-mail is confidential and may also be = subject to legal privilege. It is intended only for the recipient(s) = named above. If you are not named above as a recipient, you must not = read, copy, disclose, forward or otherwise use the information contained = in this email. If you have received this e-mail in error, please notify = the sender (whose contact details are above) immediately by reply e-mail = and delete the message and any attachments without retaining any copies. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Oct 16 13:10:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERC2D-00075S-MZ; Sun, 16 Oct 2005 13:10:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERC28-00075N-HU for enum@megatron.ietf.org; Sun, 16 Oct 2005 13:10:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11031 for ; Sun, 16 Oct 2005 13:10:46 -0400 (EDT) Received: from mail123.messagelabs.com ([85.158.136.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERCD9-00086l-Q8 for enum@ietf.org; Sun, 16 Oct 2005 13:22:24 -0400 X-VirusChecked: Checked X-Env-Sender: Paul.Rosbotham@cwmsg.cwplc.com X-Msg-Ref: server-5.tower-123.messagelabs.com!1129482628!13467251!1 X-StarScan-Version: 5.4.15; banners=cwmsg.cwplc.com,-,- X-Originating-IP: [195.44.11.58] Received: (qmail 18389 invoked from network); 16 Oct 2005 17:10:28 -0000 Received: from unknown (HELO latona.cwplc.com) (195.44.11.58) by server-5.tower-123.messagelabs.com with SMTP; 16 Oct 2005 17:10:28 -0000 Received: from GBCWSWIEV002.ad.plc.cwintra.com ([148.185.93.212]) by latona.cwplc.com (8.12.9/Switch-3.0.0) with ESMTP id j9GH9hjH003999 for ; Sun, 16 Oct 2005 18:09:43 +0100 (BST) Received: from GBCWSWIEC001.ad.plc.cwintra.com (unverified) by GBCWSWIEV002.ad.plc.cwintra.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Sun, 16 Oct 2005 18:11:39 +0100 Received: from GBCWSWIEM002.ad.plc.cwintra.com ([148.185.93.204]) by GBCWSWIEC001.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 16 Oct 2005 18:11:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] A proposal for Carrier ENUM Date: Sun, 16 Oct 2005 18:11:38 +0100 Message-ID: <9322B78036E1534A99B0BC51DEB0F9D6017259E0@GBCWSWIEM002.ad.plc.cwintra.com> Thread-Topic: [Enum] A proposal for Carrier ENUM Thread-Index: AcXQ6aAcdhxV0k6gQL6r2KgaFTixgAAB0/hwAC2T7hAAMxZmsA== From: "Rosbotham, Paul" To: X-OriginalArrivalTime: 16 Oct 2005 17:11:38.0718 (UTC) FILETIME=[AB9D4FE0:01C5D274] X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: James McEachern X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jim I=20could=20live=20with=20that=20modification.=20=20The=20one=20"gotcha"=20= I=20would=20caution=20of,=20however,=20is=20that=20in=20some=20cases=20the= =20regulator=20may=20not=20be=20willing=20to=20get=20involved,=20and=20pre= fer=20to=20leave=20it=20to=20the=20industry=20players=20to=20sort=20out=20= amongst=20themselves.=20=20For=20example,=20I=20know=20that=20in=20some=20= countries=20Administrations=20have=20grappled=20with=20how=20to=20deal=20w= ith=20(user)=20ENUM=20because=20they=20are=20barred=20by=20statute=20from=20= involvement=20in=20internet=20addressing=20issues.=20=20As=20a=20compromis= e,=20how=20about=20we=20agree=20something=20along=20the=20lines=20of=20"Or= dinarily=20the=20entity=20populating=20Carrier=20ENUM=20will=20be=20the=20= one=20providing=20PSTN=20service=20to=20the=20number=20in=20question,=20bu= t=20the=20detail=20of=20this=20is=20one=20which=20may=20specified=20by=20t= he=20relevant=20national=20regulator." Regards Paul=20 -----Original=20Message----- From:=20James=20McEachern=20[mailto:jmce@nortel.com] Sent:=20Saturday,=20October=2015,=202005=207:36=20PM To:=20Rosbotham,=20Paul;=20enum@ietf.org Cc:=20james.f.baskin@verizon.com Subject:=20RE:=20[Enum]=20A=20proposal=20for=20Carrier=20ENUM Paul, I=20realize=20you=20asked=20to=20halt=20this=20thread,=20but=20I=20have=20= one=20question=20for=20clarification.=20=20Rather=20than=20"specifying=20t= hat=20the=20entity=20populating=20Carrier=20ENUM=20be=20the=20one=20provid= ing=20PSTN=20service=20to=20the=20number=20in=20question",=20wouldn't=20it= =20make=20more=20sense=20to=20specify=20that=20the=20entity=20populating=20= Carrier=20ENUM=20be=20the=20one=20authorized=20by=20the=20national=20regul= ator=20to=20populate=20Carrier=20ENUM=20for=20the=20number=20in=20question= ? Based=20on=20the=20previous=20discussion=20I=20can=20imagine=20that=20in=20= some=20circumstances=20it=20might=20be=20advantageous=20for=20the=20regula= tor=20to=20have=20the=20donor=20carrier=20populate=20Carrier=20ENUM.=20=20= If=20it=20truly=20is=20up=20to=20the=20national=20regulator,=20perhaps=20w= e=20should=20simply=20recognize=20this,=20rather=20than=20presume=20what=20= the=20regulator=20will=20decide? Jim This=20e-mail=20has=20been=20scanned=20for=20viruses=20by=20the=20Cable=20= &=20Wireless=20e-mail=20security=20system=20-=20powered=20by=20MessageLabs= .=20For=20more=20information=20on=20a=20proactive=20managed=20e-mail=20sec= urity=20service,=20=20visit=20http://www.cw.com/uk/emailprotection/=20 =20 The=20information=20contained=20in=20this=20e-mail=20is=20confidential=20a= nd=20may=20also=20be=20subject=20to=20legal=20privilege.=20It=20is=20inten= ded=20only=20for=20the=20recipient(s)=20named=20above.=20If=20you=20are=20= not=20named=20above=20as=20a=20recipient,=20you=20must=20not=20read,=20cop= y,=20disclose,=20forward=20or=20otherwise=20use=20the=20information=20cont= ained=20in=20this=20email.=20If=20you=20have=20received=20this=20e-mail=20= in=20error,=20please=20notify=20the=20sender=20(whose=20contact=20details=20= are=20above)=20immediately=20by=20reply=20e-mail=20and=20delete=20the=20me= ssage=20and=20any=20attachments=20without=20retaining=20any=20copies. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Oct 16 16:04:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EREkW-0005zR-0D; Sun, 16 Oct 2005 16:04:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EREkU-0005yX-7w for enum@megatron.ietf.org; Sun, 16 Oct 2005 16:04:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19867 for ; Sun, 16 Oct 2005 16:04:43 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EREvd-00042q-NJ for enum@ietf.org; Sun, 16 Oct 2005 16:16:24 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9GK50bA007868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Oct 2005 13:05:02 -0700 Message-ID: <4352B23B.9000209@shockey.us> Date: Sun, 16 Oct 2005 16:04:11 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James McEachern Subject: Re: [Enum] ENUM WG RECHARTER : My initial proposal V.01 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "Pfautz, Penn L, NEO" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org James McEachern wrote: > Richard, > A couple more comments in line. Excellent points ... I will incorporate them into the final revision. I think we will shortly have consensus from the AD's on the charter. I'll have proposed Goals and Milestones ready in a day or so. > > Jim > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey > Sent: Thursday, October 13, 2005 2:18 PM > To: 'enum@ietf.org'; Pfautz, Penn L, NEO > Subject: [Enum] ENUM WG RECHARTER : My initial proposal V.01 > > > Penn ...I like it ! How does this sound? > > ############### > > The ENUM working group has defined a DNS-based architecture and protocol > [RFC 3761] by which an E.164 number, as defined in ITU Recommendation > E.164, can be expressed as a Fully Qualified Domain Name in a specific > Internet Infrastructure domain defined for this purpose (e164.arpa). > > Background: > > E.164 numbers are globally unique, language independent identifiers for > resources on Public Telecommunication Networks that can support many > different services and protocols. There is an emerging desire for > network operators to utilize aspects of RFC 3761 to discover points of > interconnection necessary to terminate communications sessions > identified by a E164 number,in addition to identifying end point > protocols and services. > > Working Group Revised Goals and Scope: > > 1. The working group will update RFC 3761 and advance to Draft Standard. > > 2. The working group will examine and document the use of RFC 3761 to > facilitate network interconnection for services using E.164 addressing. > The Working group will coordinate its activities with other IETF working > groups, existing or to be chartered, that are investigating elements of > VoIP or other service network peering > >>>is peering the right word here, or is it interconnection - or do they mean >>the same thing It depends on what someone ate that day .. in this context? > > that typically use E.164 addressing. > > 3. The working group will continue examine and document various aspects > of ENUM administrative and /or operational procedures irrespective of > whether e164.arpa domain is used. > > 4. The working group will also examine the use of RFC 3761 technology > for defining > >>>"defining" doesn't sound quite right. Aren't we "storing and >>communicating" this information - or something similar? > I agree your language is much more "defining" than mine .. > other information about services addressed by E.164 > numbers, for example PSTN call routing and signaling data. > > 5. The Working Group will continue to maintain appropriate contact and > liaison with other standards bodies and groups, specifically ITU-T SG2, > to provide technical or educational information and address, as needed, > issues related to the use of the E.164 numbering plan for services on IP > networks. In addition the Working Group will continue to encourage the > exchange of technical information within the emerging global ENUM > community as well as documentation on practical experiences with > implementations, alternate technology uses and the administration and > provisioning of RFC 3761. > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 18 02:04:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERkZw-0006cc-KO; Tue, 18 Oct 2005 02:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERkZu-0006a1-T8 for enum@megatron.ietf.org; Tue, 18 Oct 2005 02:04:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05905 for ; Tue, 18 Oct 2005 02:03:53 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERklM-0001bD-EL for enum@ietf.org; Tue, 18 Oct 2005 02:15:53 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9I618F11321; Tue, 18 Oct 2005 02:01:08 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] A proposal for Carrier ENUM Date: Tue, 18 Oct 2005 02:03:39 -0400 Message-ID: Thread-Topic: [Enum] A proposal for Carrier ENUM Thread-Index: AcXQ6aAcdhxV0k6gQL6r2KgaFTixgAAB0/hwAC2T7hAAMxZmsAAhczWg From: "James McEachern" To: "Rosbotham, Paul" , X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Paul, I'd be happy with your proposed modification - or even simply stating = that "the entity populating Carrier ENUM is a national matter". Jim =20 -----Original Message----- From: Rosbotham, Paul [mailto:Paul.Rosbotham@cwmsg.cwplc.com]=20 Sent: Sunday, October 16, 2005 1:12 PM To: enum@ietf.org Cc: McEachern, James [CAR:5N00:EXCH] Subject: RE: [Enum] A proposal for Carrier ENUM Jim I could live with that modification. The one "gotcha" I would caution = of, however, is that in some cases the regulator may not be willing to = get involved, and prefer to leave it to the industry players to sort out = amongst themselves. For example, I know that in some countries = Administrations have grappled with how to deal with (user) ENUM because = they are barred by statute from involvement in internet addressing = issues. As a compromise, how about we agree something along the lines = of "Ordinarily the entity populating Carrier ENUM will be the one = providing PSTN service to the number in question, but the detail of this = is one which may specified by the relevant national regulator." Regards Paul=20 -----Original Message----- From: James McEachern [mailto:jmce@nortel.com] Sent: Saturday, October 15, 2005 7:36 PM To: Rosbotham, Paul; enum@ietf.org Cc: james.f.baskin@verizon.com Subject: RE: [Enum] A proposal for Carrier ENUM Paul, I realize you asked to halt this thread, but I have one question for = clarification. Rather than "specifying that the entity populating = Carrier ENUM be the one providing PSTN service to the number in = question", wouldn't it make more sense to specify that the entity = populating Carrier ENUM be the one authorized by the national regulator = to populate Carrier ENUM for the number in question? Based on the previous discussion I can imagine that in some = circumstances it might be advantageous for the regulator to have the = donor carrier populate Carrier ENUM. If it truly is up to the national = regulator, perhaps we should simply recognize this, rather than presume = what the regulator will decide? Jim This e-mail has been scanned for viruses by the Cable & Wireless e-mail = security system - powered by MessageLabs. For more information on a = proactive managed e-mail security service, visit = http://www.cw.com/uk/emailprotection/=20 =20 The information contained in this e-mail is confidential and may also be = subject to legal privilege. It is intended only for the recipient(s) = named above. If you are not named above as a recipient, you must not = read, copy, disclose, forward or otherwise use the information contained = in this email. If you have received this e-mail in error, please notify = the sender (whose contact details are above) immediately by reply e-mail = and delete the message and any attachments without retaining any copies. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 18 11:00:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERswr-0000Mb-Ub; Tue, 18 Oct 2005 11:00:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERswp-0000Lb-TW for enum@megatron.ietf.org; Tue, 18 Oct 2005 11:00:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06752 for ; Tue, 18 Oct 2005 11:00:07 -0400 (EDT) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERt8M-0008NT-KL for enum@ietf.org; Tue, 18 Oct 2005 11:12:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] ENUM Working Group Last call on IANA Registration for Enumservice Voice Date: Tue, 18 Oct 2005 10:59:29 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73FF07D6@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] ENUM Working Group Last call on IANA Registration for Enumservice Voice Thread-Index: AcXRbyPX6F6ABYrCSPmJOkR7fgcqRAChU6Fw From: "Livingood, Jason" To: "Bernie Hoeneisen" X-OriginalArrivalTime: 18 Oct 2005 14:59:29.0927 (UTC) FILETIME=[8A835170:01C5D3F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, rudolf.brandner@siemens.com, "Conroy, Lawrence \(SMTP\)" , Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > Your comments bring me to the idea of making a "template"=20 > with guidelines for future ENUM service registrations. This=20 > would make it easier for the authors to write those and=20 > easier for the reader to understand. What do you (and other=20 > folks) think about? I think it is a great idea!=20 Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 18 11:14:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtAA-00029y-8g; Tue, 18 Oct 2005 11:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtA8-00028a-32 for enum@megatron.ietf.org; Tue, 18 Oct 2005 11:14:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09188 for ; Tue, 18 Oct 2005 11:13:52 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERtLf-0000vv-EL for enum@ietf.org; Tue, 18 Oct 2005 11:25:56 -0400 Received: from [10.31.32.123] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9IFEOeb021179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Oct 2005 08:14:25 -0700 Message-ID: <43551124.2090402@shockey.us> Date: Tue, 18 Oct 2005 11:13:40 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Livingood, Jason" Subject: Re: [Enum] ENUM Working Group Last call on IANA Registration for Enumservice Voice References: <6EEEACD9D7F52940BEE26F5467C02C73FF07D6@PACDCEXCMB01.cable.comcast.com> In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C73FF07D6@PACDCEXCMB01.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, rudolf.brandner@siemens.com, "Conroy, Lawrence \(SMTP\)" , Bernie Hoeneisen , Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Livingood, Jason wrote: >>Your comments bring me to the idea of making a "template" >>with guidelines for future ENUM service registrations. This >>would make it easier for the authors to write those and >>easier for the reader to understand. What do you (and other >>folks) think about? > > > I think it is a great idea! So do I ! Write it up ! -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 18 11:22:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtHy-0004Nu-Um; Tue, 18 Oct 2005 11:22:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtHw-0004KH-V2 for enum@megatron.ietf.org; Tue, 18 Oct 2005 11:22:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09565 for ; Tue, 18 Oct 2005 11:21:56 -0400 (EDT) Received: from kahua.nona.net ([193.80.224.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERtTS-00016R-Et for enum@ietf.org; Tue, 18 Oct 2005 11:34:01 -0400 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by kahua with esmtp; Tue, 18 Oct 2005 17:21:20 +0200 id 0001BEB4.435512F0.00006595 Message-ID: <435512D6.80801@enum.at> Date: Tue, 18 Oct 2005 17:20:54 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: "Livingood, Jason" Subject: Re: [Enum] ENUM Working Group Last call on IANA Registration for Enumservice Voice References: <6EEEACD9D7F52940BEE26F5467C02C73FF07D6@PACDCEXCMB01.cable.comcast.com> In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C73FF07D6@PACDCEXCMB01.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, rudolf.brandner@siemens.com, "Conroy, Lawrence \(SMTP\)" , Bernie Hoeneisen , Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Livingood, Jason wrote: >> Your comments bring me to the idea of making a "template" >> with guidelines for future ENUM service registrations. This >> would make it easier for the authors to write those and >> easier for the reader to understand. What do you (and other >> folks) think about? > > I think it is a great idea! > i agree. when writing draft-mayrhofer-enum-vcard-00 i looked at various other enumservice registrations, and tried to combine their "look and feel" into the document. What took me the most time was the "Security Considerations" section, so i think a few generic sentences about Enumservice security considerations would be most valuable. I also think that an "Example" section should be mandatory in Enumservice registrations, probably a "User experience" section as well? (The "user experience" section is a bit twofold: It could help achieving a more consistent user experience, but it could also hinder implementors who use the enumservice in a probably more innovative way than the author imagined - any comments on such a section?) Anyway, if someone goes for a template document, feel free to peruse whatever makes sense from my draft. cheers Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 18 11:41:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtag-000376-DJ; Tue, 18 Oct 2005 11:41:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtae-000363-8r for enum@megatron.ietf.org; Tue, 18 Oct 2005 11:41:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10732 for ; Tue, 18 Oct 2005 11:41:16 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERtmB-0001bC-Qf for enum@ietf.org; Tue, 18 Oct 2005 11:53:21 -0400 Received: from [10.31.13.186] (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id j9IFfBFg024974 for ; Tue, 18 Oct 2005 15:41:11 GMT Message-ID: <43551798.7020800@neustar.biz> Date: Tue, 18 Oct 2005 11:41:12 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Enum] Current Proposed Agenda for IETF 64 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org http://www3.ietf.org/proceedings/05nov/agenda/enum.txt -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 18 11:48:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERth4-0005Y6-2P; Tue, 18 Oct 2005 11:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERth2-0005QL-HG for enum@megatron.ietf.org; Tue, 18 Oct 2005 11:48:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11195 for ; Tue, 18 Oct 2005 11:47:52 -0400 (EDT) Received: from mail126.messagelabs.com ([216.82.254.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERtsT-0001k9-RB for enum@ietf.org; Tue, 18 Oct 2005 11:59:57 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-2.tower-126.messagelabs.com!1129650459!8560602!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 4552 invoked from network); 18 Oct 2005 15:47:39 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-2.tower-126.messagelabs.com with SMTP; 18 Oct 2005 15:47:39 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 43527A32000DCB28; Tue, 18 Oct 2005 11:47:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Current Proposed Agenda for IETF 64 Date: Tue, 18 Oct 2005 11:47:20 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0B579737@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Enum] Current Proposed Agenda for IETF 64 Thread-Index: AcXT+rYm58nJT2foTACq0BQ08l2wngAAD5dg From: "Pfautz, Penn L, NEO" To: "Richard Shockey" , X-Spam-Score: 0.8 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org FYI, Steve Lind and I will be submitting a Carrier ENUM Requirements document in the next day or so. Penn=20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, October 18, 2005 11:41 AM To: 'enum@ietf.org' Subject: [Enum] Current Proposed Agenda for IETF 64 http://www3.ietf.org/proceedings/05nov/agenda/enum.txt --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or=20 ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 18 11:54:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtnB-0000pe-Qj; Tue, 18 Oct 2005 11:54:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtn9-0000ot-U8 for enum@megatron.ietf.org; Tue, 18 Oct 2005 11:54:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11403 for ; Tue, 18 Oct 2005 11:54:11 -0400 (EDT) Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERtyh-0001s7-DL for enum@ietf.org; Tue, 18 Oct 2005 12:06:17 -0400 Received: from ([10.20.62.13]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.14318878; Tue, 18 Oct 2005 11:53:50 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 11:53:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5D3FC.212C2145" Date: Tue, 18 Oct 2005 11:53:49 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73FF07DC@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: yes Thread-Topic: ENUM WG I-D: draft-ietf-enum-pstn-00.txt Thread-Index: AcXTUUsLXfr5i2swS5myHjmmqd0+hAAqnt4g From: "Livingood, Jason" To: X-OriginalArrivalTime: 18 Oct 2005 15:53:50.0027 (UTC) FILETIME=[21AF19B0:01C5D3FC] X-Spam-Score: 0.8 (/) X-Scan-Signature: 563af5038a5e1dade28c8affc0fff375 Subject: [Enum] FW: ENUM WG I-D: draft-ietf-enum-pstn-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D3FC.212C2145 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This I-D will be presented as part of agenda item #4-B in the ENUM WG session. This doc should be forwarded by IETF soon, but here's an advance copy for review. This was originally "draft-livingood-shockey-enum-npd-00" at IETF 63 in Paris, but was formally adopted as a WG item and subsequently revised and expanded as "draft-ietf-enum-pstn-00" for "IANA Registration for an Enumservice Containing PSTN Signaling Information." =20 Regards Jason Livingood ------_=_NextPart_001_01C5D3FC.212C2145 Content-Type: text/plain; name="draft-ietf-enum-pstn-00.txt" Content-Description: draft-ietf-enum-pstn-00.txt Content-Disposition: attachment; filename="draft-ietf-enum-pstn-00.txt" Content-Transfer-Encoding: base64 DQoNCkVOVU0gV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgSi4gTGl2aW5nb29kIA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIENvbWNhc3QgQ2FibGUgQ29tbXVuaWNhdGlvbnMgDQpFeHBpcmVzOiBBcHJpbCAxNiwg MjAwNiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUi4gU2hvY2tleSANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBOZXVTdGFyIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDUgDQogICAgDQogICAgDQogICAgICAgICAgICAg ICAgICAgSUFOQSBSZWdpc3RyYXRpb24gZm9yIGFuIEVudW1zZXJ2aWNlIA0KICAgICAgICAgICAg ICAgICAgIENvbnRhaW5pbmcgUFNUTiBTaWduYWxpbmcgSW5mb3JtYXRpb24gDQogICAgICAgICAg ICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtZW51bS1wc3RuLTAwIA0KICAgIA0KICAgIA0KU3Rh dHVzIG9mIHRoaXMgTWVtbyANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQt RHJhZnQgYW5kIGlzIHN1YmplY3QgdG8gYWxsIHByb3Zpc2lvbnMgDQogICBvZiBTZWN0aW9uIDMg b2YgUkZDIDM2NjcuICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggDQog ICBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueSBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJ UFIgY2xhaW1zIG9mIA0KICAgd2hpY2ggaGUgb3Igc2hlIGlzIGF3YXJlIGhhdmUgYmVlbiBvciB3 aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiANCiAgIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVz IGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggDQogICBTZWN0aW9u IDYgb2YgQkNQIDc5LiANCiAgICANCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1 bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIA0KICAgVGFzayBGb3JjZSAoSUVURiks IGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCAgICAgIA0KICAg b3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50 ZXJuZXQtDQogICBEcmFmdHMuIA0KICAgIA0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzIA0KICAgYW5kIG1heSBi ZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBh bnkgDQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRz IGFzIHJlZmVyZW5jZSANCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFz ICJ3b3JrIGluIHByb2dyZXNzLiIgDQogICAgDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVy bmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQgDQogICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dCANCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0 IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQgDQogICAgICAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuIA0KICAgIA0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3 aWxsIGV4cGlyZSBvbiBBcHJpbCAxNiwgMjAwNi4gIA0KICAgIA0KQ29weXJpZ2h0IE5vdGljZSAN CiAgICANCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDUpLiANCiAg ICANCiAgICANCkFic3RyYWN0IA0KICAgIA0KICAgVGhpcyBkb2N1bWVudCByZWdpc3RlcnMgdGhl IEVudW1zZXJ2aWNlIJNwc3RulCBhbmQgc3VidHlwZSCTdGVslCANCiAgIHVzaW5nIHRoZSBVUkkg c2NoZW1lIJF0ZWw6kiwgYXMgd2VsbCBhcyB0aGUgc3VidHlwZSCTc2lwlCB1c2luZyB0aGUgDQog ICBVUkkgc2NoZW1lIJFzaXCSIGFzIHBlciB0aGUgSUFOQSByZWdpc3RyYXRpb24gcHJvY2VzcyBk ZWZpbmVkIGluIHRoZSANCiAgIEVOVU0gc3BlY2lmaWNhdGlvbiwgUkZDIDM3NjEuICBUaGlzIGRh dGEgaXMgdXNlZCB0byBmYWNpbGl0YXRlIHRoZSANCg0KIA0KIA0KTGl2aW5nb29kICYgU2hvY2tl eSAgICAgRXhwaXJlcyBBcHJpbCAxNiwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAxXSANCgxJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBQU1ROIEVudW1zZXJ2aWNlICAgICAgICAgICAgICAg T2N0b2JlciAyMDA1IA0KIA0KIA0KICAgcm91dGluZyBvZiB0ZWxlcGhvbmUgY2FsbHMgaW4gdGhv c2UgY291bnRyaWVzIHdoZXJlIE51bWJlciANCiAgIFBvcnRhYmlsaXR5IGV4aXN0cy4gDQogICAg DQogDQpUYWJsZSBvZiBDb250ZW50cyANCiAgICANCiAgIDEuIFRlcm1pbm9sb2d5Li4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIgDQogICAyLiBJbnRy b2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4yIA0KICAgMy4gRGlzdHJpYnV0aW9uIG9mIERhdGEuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uNCANCiAgIDQuIFJlY29yZCBDb25mbGljdCBSZXNvbHV0aW9uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQgDQogICA1LiBFTlVNIFNlcnZpY2Ug UmVnaXN0cmF0aW9uIGZvciBQU1ROLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40IA0KICAg Ni4gRXhhbXBsZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uNSANCiAgICAgIDYuMSBFeGFtcGxlIG9mIGEgUG9ydGVkIE51bWJlciwgVXNpbmcg YSCRdGVskiBVUkkgU2NoZW1lLi4uLi4uLjUgDQogICAgICA2LjIgRXhhbXBsZSBvZiBhIFBvcnRl ZCBOdW1iZXIsIFVzaW5nIGEgkXNpcJIgVVJJIFNjaGVtZS4uLi4uLi41IA0KICAgICAgNi4zIEV4 YW1wbGUgb2YgYSBOb24tUG9ydGVkIE51bWJlciwgVXNpbmcgYSCRdGVskiBVUkkgU2NoZW1lLi4u NiANCiAgICAgIDYuNCBFeGFtcGxlIG9mIGEgTm9uLVBvcnRlZCBOdW1iZXIsIFVzaW5nIGEgkXNp cJIgVVJJIFNjaGVtZS4uLjYgDQogICA3LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42IA0KICAgOC4gSUFOQSBDb25zaWRlcmF0 aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNyANCiAgIDku IEFja25vd2xlZGdlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjcgDQogICAxMC4gUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi43IA0KICAgICAgMTAuMSBOb3JtYXRpdmUgUmVmZXJlbmNl cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNyANCiAgICAgIDEwLjIgSW5m b3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjgg DQogICBBdXRob3JzkiBBZGRyZXNzZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi44IA0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFuZCBDb3B5cmlnaHQg U3RhdGVtZW50cy4uLi4uLi4uLi4uLi4uLi4uLi4uOSANCiAgICANCiAgICANCjEuICAgVGVybWlu b2xvZ3kgDQogICAgDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJ UkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsIA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwg IlJFQ09NTUVOREVEIiwgICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIA0KICAgZG9jdW1l bnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBCQ1AgMTQsIFJGQy0yMTE5 IFsxXS4gDQogICAgDQoyLiAgIEludHJvZHVjdGlvbiANCiAgICANCiAgIEVOVU0gKEUuMTY0IE51 bWJlciBNYXBwaW5nLCBSRkMgMzc2MSBbMV0pIGlzIGEgc3lzdGVtIHRoYXQgdHJhbnNmb3JtcyAN CiAgIEUuMTY0IG51bWJlcnMgKFRoZSBJbnRlcm5hdGlvbmFsIFB1YmxpYyBUZWxlY29tbXVuaWNh dGlvbiBOdW1iZXIgDQogICBQbGFuLCBJVFUtVCBSZWNvbW1lbmRhdGlvbiBFLjE2NCBbMl0pIGlu dG8gZG9tYWluIG5hbWVzIGFuZCB0aGVuIHVzZXMgDQogICBETlMgKERvbWFpbiBOYW1lIFNlcnZp Y2UsIFJGQyAxMDM0IFszXSkgZGVsZWdhdGlvbiB0aHJvdWdoIE5TIHJlY29yZHMgDQogICBhbmQg TkFQVFIgcmVjb3JkcyAoRHluYW1pYyBEZWxlZ2F0aW9uIERpc2NvdmVyeSBTeXN0ZW0gKERERFMp IFBhcnQgDQogICBUaHJlZTogVGhlIERvbWFpbiBOYW1lIFN5c3RlbSAoRE5TKSBEYXRhYmFzZSwg UkZDIDM0MDMgWzRdKSB0byBsb29rIA0KICAgdXAgd2hhdCBzZXJ2aWNlcyBhcmUgYXZhaWxhYmxl IGZvciBhIHNwZWNpZmljIGRvbWFpbiBuYW1lLiANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgcmVn aXN0ZXJzIEVudW1zZXJ2aWNlcyBhY2NvcmRpbmcgdG8gdGhlIGd1aWRlbGluZXMgDQogICBnaXZl biBpbiBSRkMgMzc2MSBbMV0gdG8gYmUgdXNlZCBmb3IgcHJvdmlzaW9uaW5nIGluIHRoZSBzZXJ2 aWNlcyANCiAgIGZpZWxkIG9mIGEgTkFQVFIgWzRdIHJlc291cmNlIHJlY29yZCB0byBpbmRpY2F0 ZSB0aGUgdHlwZXMgb2YgDQogICBmdW5jdGlvbmFsaXR5IGFzc29jaWF0ZWQgd2l0aCBhbiBlbmQg cG9pbnQgYW5kL29yIHRlbGVwaG9uZSBudW1iZXIuICANCiAgIFRoZSByZWdpc3RyYXRpb24gaXMg ZGVmaW5lZCB3aXRoaW4gdGhlIERERFMgKER5bmFtaWMgRGVsZWdhdGlvbiANCiAgIERpc2NvdmVy eSBTeXN0ZW0gWzRdWzVdWzZdWzddWzhdKSBoaWVyYXJjaHksIGZvciB1c2Ugd2l0aCB0aGUgIkUy VSIgDQogICBERERTIEFwcGxpY2F0aW9uIGRlZmluZWQgaW4gUkZDIDM3NjEuIA0KIA0KIA0KTGl2 aW5nb29kICYgU2hvY2tleSAgICAgRXhwaXJlcyBBcHJpbCAxNiwgMjAwNiAgICAgICAgICAgICAg ICBbUGFnZSAyXSANCgxJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBQU1ROIEVudW1zZXJ2aWNl ICAgICAgICAgICAgICAgT2N0b2JlciAyMDA1IA0KIA0KIA0KICAgIA0KICAgTnVtYmVyIFBvcnRh YmlsaXR5IGFsbG93cyB0ZWxlcGhvbmUgc3Vic2NyaWJlcnMgdG8ga2VlcCB0aGVpciANCiAgIHRl bGVwaG9uZSBudW1iZXJzIHdoZW4gdGhleSBjaGFuZ2Ugc2VydmljZSBwcm92aWRlciwgbW92ZSB0 byBhIG5ldyANCiAgIGxvY2F0aW9uLCBvciBjaGFuZ2UgdGhlIHN1YnNjcmliZWQgc2VydmljZXMg WzE0XS4gIEluIG1hbnkgY291bnRpZXMsIA0KICAgc3VjaCBhcyB0aGUgVW5pdGVkIFN0YXRlcyBh bmQgQ2FuYWRhLCB0aGUgZnVuY3Rpb25zIG9mIG5hbWluZyBhbmQgDQogICBhZGRyZXNzaW5nIG9u IHRoZSBQU1ROIGhhdmUgYmVlbiBhYnN0cmFjdGVkLiAgVGhlIGRpYWxlZCBudW1iZXIgaXMgDQog ICBub3QgZGlyZWN0bHkgcm91dGFibGUgb24gdGhlIFBTVE4gYW5kIG11c3QgYmUgdHJhbnNsYXRl ZCBpbnRvIGEgDQogICByb3V0aW5nIG51bWJlciBmb3IgY2FsbCBjb21wbGV0aW9uLiAgT3RoZXIg bnVtYmVycywgd2hpY2ggYXJlIG5vdCANCiAgIHBvcnRlZCwgYW5kIHdoaWNoIGNhbiBiZSByb3V0 ZWQgZGlyZWN0bHkgb24gdGhlIFBTVE4gYmFzZWQgb24gdGhlIA0KICAgZGlhbGVkIG51bWJlciwg YXJlIHR5cGljYWxseSBhc3NpZ25lZCB0byBjYXJyaWVycyBhbmQgb3RoZXIgZW50aXRpZXMgDQog ICBpbiBsYXJnZSBibG9ja3Mgb3IgcG9vbHMuICBUaGlzIG5vbi1wb3J0ZWQgbnVtYmVyaW5nIGlu Zm9ybWF0aW9uIGlzIA0KICAgZGlzdHJpYnV0ZWQgaW4gYSB2YXJpZXR5IG9mIG1ldGhvZHMgYW5k IGZvcm1hdHMgYXJvdW5kIHRoZSB3b3JsZC4gIA0KICAgIA0KICAgVGhlIGZvbGxvd2luZyBFbnVt c2VydmljZSBpcyByZWdpc3RlcmVkIHdpdGggdGhpcyBkb2N1bWVudDogInBzdG4iIHRvIA0KICAg aW5kaWNhdGUgUFNUTiByb3V0aW5nIGRhdGEsIGluY2x1ZGluZyBudW1iZXIgcG9ydGFiaWxpdHkg ZGF0YS4gIFRoZSANCiAgIHB1cnBvc2Ugb2YgdGhpcyBFbnVtc2VydmljZSBpcyB0byBkZXNjcmli ZSBpbmZvcm1hdGlvbiBhYm91dCANCiAgIHRlbGVwaG9uZSBudW1iZXJzIHdoaWNoIGNhbm5vdCBi ZSB1c2VkIG9uIHRoZSBwdWJsaWMgSW50ZXJuZXQgb3IgYSANCiAgIHByaXZhdGUvcGVlcmVkIElu dGVybmV0IFByb3RvY29sIChJUCkgbmV0d29yay4gIFRodXMsIHRoZXNlIGFyZSANCiAgIG51bWJl cnMgd2hpY2ggYXJlIG9ubHkgcmVhY2hhYmxlIHZpYSB0aGUgdHJhZGl0aW9uYWwgUHVibGljIFN3 aXRjaGVkIA0KICAgVGVsZXBob25lIE5ldHdvcmsgKFBTVE4pLiANCiAgICANCiAgIFRoaXMgRW51 bXNlcnZpY2UgY291bGQgZW5hYmxlIGNhcnJpZXJzLCBhcyB3ZWxsIGFzIG90aGVyIHNlcnZpY2Ug DQogICBwcm92aWRlcnMgYW5kIHVzZXJzLCB0byBwbGFjZSBwb3J0ZWQsIHBvb2xlZCwgYW5kIGJs b2NrcyBvZiBudW1iZXJzIA0KICAgYW5kIHRoZWlyIGFzc29jaWF0ZWQgUFNUTiBjb250YWN0IGlu Zm9ybWF0aW9uLCBpbnRvIEVOVU0gZGF0YWJhc2VzLCANCiAgIHVzaW5nIHN0YW5kYXJkaXplZCwg bm9uLXByb3ByaWV0YXJ5IG1ldGhvZHMuICBUaGlzLCBpbiB0dXJuLCBjb3VsZCANCiAgIGVuYWJs ZSBzdWNoIHBhcnRpZXMgdG8gY29uc29saWRhdGUgYWxsIHRlbGVwaG9uZSBudW1iZXIgbG9va3Vw cyBpbiANCiAgIHRoZWlyIG5ldHdvcmtzIGludG8gYSBzaW5nbGUgRU5VTSBsb29rdXAsIHRoZXJl Ynkgc2ltcGxpZnlpbmcgY2FsbCANCiAgIHJvdXRpbmcgYW5kIG5ldHdvcmsgb3BlcmF0aW9ucywg d2hpY2ggd291bGQgdGhlbiByZXN1bHQgaW4gZWl0aGVyIGFuIA0KICAgb24tbmV0LCBvciBJUC1i YXNlZCByZXNwb25zZSwgb3Igb2ZmLW5ldCwgb3IgUFNUTi1iYXNlZCByZXNwb25zZS4gIEl0IA0K ICAgaXMgY29uY2VpdmFibGUgdGhhdCBiZWluZyBhYmxlIHRvIHF1ZXJ5IGZvciB0aGlzIGluZm9y bWF0aW9uIGluIEVOVU0gDQogICBjb3VsZCBzaWduaWZpY2FudGx5IHJlZHVjZSBvciBlbGltaW5h dGUgdGhlIG5lZWQgZm9yIHRoZXNlIHBhcnRpZXMgdG8gDQogICBtYWludGFpbiB0cmFkaXRpb25h bCwgU1M3L1RDQVAvU0lHVFJBTi1iYXNlZCBxdWVyeSBnYXRld2F5cywgDQogICBhcHBsaWNhdGlv bnMsIGFuZCBwcm90b2NvbHMgaW4gdGhlaXIgbmV0d29ya3MuIA0KICAgIA0KICAgVGhlIHNlcnZp Y2UgcGFyYW1ldGVycyBkZWZpbmVkIGluIFJGQyAzNzYxIGRpY3RhdGUgdGhhdCBhICJ0eXBlIiBh bmQgDQogICBhICJzdWJ0eXBlIiBzaG91bGQgYmUgc3BlY2lmaWVkLiAgV2l0aGluIHRoaXMgc2V0 IG9mIHNwZWNpZmljYXRpb25zIA0KICAgdGhlIGNvbnZlbnRpb24gaXMgYXNzdW1lZCB0aGF0IHRo ZSAidHlwZSIgKGJlaW5nIHRoZSBtb3JlIGdlbmVyaWMgDQogICB0ZXJtKSBkZWZpbmVzIHRoZSBz ZXJ2aWNlIGFuZCB0aGUgInN1YnR5cGUiIGRlZmluZXMgdGhlIFVSSSBzY2hlbWUuIA0KICAgIA0K ICAgV2hlbiBvbmx5IG9uZSBVUkkgc2NoZW1lIGlzIGFzc29jaWF0ZWQgd2l0aCBhIGdpdmVuIHNl cnZpY2UsIGl0IA0KICAgc2hvdWxkIGJlIGFzc3VtZWQgdGhhdCBhbiBhZGRpdGlvbmFsIFVSSSBz Y2hlbWUgdG8gYmUgdXNlZCB3aXRoIHRoaXMgDQogICBzZXJ2aWNlIG1heSBiZSBhZGRlZCBhdCBh IGxhdGVyIHRpbWUuICBUaHVzLCB0aGUgc3VidHlwZSBpcyBuZWVkZWQgdG8gDQogICBpZGVudGlm eSB0aGUgc3BlY2lmaWMgRW51bXNlcnZpY2UgaW50ZW5kZWQuIA0KICAgIA0KICAgSW4gdGhpcyBk b2N1bWVudCwgdHdvIFVSSSBzY2hlbWVzIGFyZSBzcGVjaWZpZWQuICBUaGUgZmlyc3QgaXMgDQog ICAndGVsOicsIGFzIHNwZWNpZmllZCBpbiBSRkMgMzk2NiBbOV0sIGFuZCBhcyBmdXJ0aGVyIHNw ZWNpZmllZCB3aXRoIA0KICAgbnVtYmVyIHBvcnRhYmlsaXR5IGRhdGEgaW4gZHJhZnQtaWV0Zi1p cHRlbC10ZWwtbnAtMDcudHh0IFsxMF0gDQogICAoSW50ZXJuZXQtRHJhZnQgTmV3IFBhcmFtZXRl cnMgZm9yIHRoZSAidGVsIiBVUkkgdG8gU3VwcG9ydCBOdW1iZXIgDQogICBQb3J0YWJpbGl0eSwg ZHJhZnQtaWV0Zi1pcHRlbC10ZWwtbnAtMDcudHh0IFsxMF0pLiAgQW5kIHNpbmNlIA0KIA0KIA0K TGl2aW5nb29kICYgU2hvY2tleSAgICAgRXhwaXJlcyBBcHJpbCAxNiwgMjAwNiAgICAgICAgICAg ICAgICBbUGFnZSAzXSANCgxJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBQU1ROIEVudW1zZXJ2 aWNlICAgICAgICAgICAgICAgT2N0b2JlciAyMDA1IA0KIA0KIA0KICAgc29mdHdhcmUgaW1wbGVt ZW50YXRpb25zIHVzaW5nIJF0ZWySIFVSSXMgYXJlIHNvbWV3aGF0IGxpbWl0ZWQsIGEgDQogICBz ZWNvbmQgVVJJIHNjaGVtZSBjYW4gYmUgdXNlZCwgkXNpcDqSLCBhcyBzcGVjaWZpZWQgaW4gUkZD IDMyNjEgWzExXS4gDQogICAgDQozLiAgIERpc3RyaWJ1dGlvbiBvZiBEYXRhIA0KICAgIA0KICAg VGhlIGRpc3RyaWJ1dGlvbiBvZiBudW1iZXIgcG9ydGFiaWxpdHkgZGF0YSBpcyBvZnRlbiBoaWdo bHkgDQogICByZXN0cmljdGVkIGVpdGhlciBieSBjb250cmFjdCBvciByZWd1bGF0aW9uIG9mIGEg TmF0aW9uYWwgUmVndWxhdG9yeSANCiAgIEF1dGhvcml0eSAoTlJBKS4gDQogICAgDQogICBUaGUg TkFQVFIgcmVjb3JkcyBkZXNjcmliZWQgaGVyZWluIHByb2JhYmx5IHdvdWxkIG5vdCBiZSBwYXJ0 IG9mIHRoZSANCiAgIGUxNjQuYXJwYSBETlMgdHJlZS4gIERpc3RyaWJ1dGlvbiBvZiB0aGlzIE5B UFRSIGRhdGEgd291bGQgYmUgZWl0aGVyIA0KICAgKGEpIG9uIGEgcHJpdmF0ZSBiYXNpcyAod2l0 aGluIGEgc2VydmljZSBwcm92aWRlcpJzIGludGVybmFsIG5ldHdvcmssIA0KICAgb3Igb24gYSBw cml2YXRlIGJhc2lzIGJldHdlZW4gb25lIG9yIG1vcmUgcGFydGllcyB1c2luZyBhIHZhcmlldHkg b2YgDQogICBzZWN1cml0eSBtZWNoYW5pc21zIHRvIHByb2hpYml0IGdlbmVyYWwgcHVibGljIGFj Y2Vzcykgb3IgKGIpIG9wZW5seSANCiAgIGF2YWlsYWJsZSBvbiBhIG5hdGlvbmFsIGJhc2lzIGFj Y29yZGluZyB0byBuYXRpb25hbCByZWd1bGF0b3J5IA0KICAgcG9saWN5LiAgDQogICAgDQogICBU aGUgYXV0aG9ycyBiZWxpZXZlIHRoYXQgaXQgaXMgbW9yZSBsaWtlbHkgdGhhdCB0aGVzZSByZWNv cmRzIHdpbGwgYmUgDQogICBkaXN0cmlidXRlZCBvbiBhIHB1cmVseSBwcml2YXRlIGJhc2lzLiAg SWYgc3VjaCBkYXRhIHdhcyBkaXN0cmlidXRlZCANCiAgIG5hdGlvbmFsbHksIHRoZSBuYXRpb25h bCB0ZWxlcGhvbmUgbnVtYmVyaW5nIGF1dGhvcml0eSwgb3Igc29tZSBvdGhlciANCiAgIHJlZ3Vs YXRvcnkgYm9keSwgbWF5IGhhdmUganVyaXNkaWN0aW9uLiAgU3VjaCBhIGJvZHkgbWF5IGNob29z ZSB0byANCiAgIHJlc3RyaWN0IGRpc3RyaWJ1dGlvbiBvZiB0aGUgZGF0YSBpbiBzdWNoIGEgd2F5 IHRoYXQgaXQgbWF5IG5vdCBwYXNzIA0KICAgb3ZlciB0aGF0IGNvdW50cnmScyBuYXRpb25hbCBi b3JkZXJzLiAgSG93IG51bWJlciBwb3J0YWJpbGl0eSBkYXRhIGlzIA0KICAgY29sbGVjdGVkIGFu ZCBkaXN0cmlidXRlZCBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBkb2N1bWVudCANCiAgICANCjQu ICAgUmVjb3JkIENvbmZsaWN0IFJlc29sdXRpb24gDQogICAgDQogICBJdCBpcyBsaWtlbHkgdGhh dCwgaW4gc29tZSBjYXNlcywgYSBxdWVyeSB3aWxsIHJldHVybiBtdWx0aXBsZSANCiAgIHJlY29y ZHMuICBJbiB0aGlzIGNhc2UsIHRoaXMgY291bGQgcmVzdWx0IGluIHdoYXQgaXMgZXNzZW50aWFs bHkgYW4gDQogICBvbi1uZXQgYW5kIG9mZi1uZXQgcmVjb3JkLiAgVGh1cywgb25lIHJlY29yZCBn aXZlcyB0aGUgYXNzb2NpYXRlZCANCiAgIGFkZHJlc3Mgb24gYW4gSVAgbmV0d29yaywgd2hpbGUg dGhlIG90aGVyIGdpdmVzIHRoZSBhc3NvY2lhdGVkIA0KICAgYWRkcmVzcyBvbiB0aGUgUFNUTi4g IEFzIHdpdGggbXVsdGlwbGUgcmVjb3JkcyByZXN1bHRpbmcgZnJvbSBhIA0KICAgdHlwaWNhbCBF TlVNIHF1ZXJ5IG9mIHRoZSBlMTY0LmFycGEgdHJlZSwgaXQgaXMgdXAgdG8gdGhlIGFwcGxpY2F0 aW9uIA0KICAgdXNpbmcgYW4gRU5VTSByZXNvbHZlciB0byBkZXRlcm1pbmUgd2hpY2ggcmVjb3Jk KHMpIHRvIHVzZSBhbmQgd2hpY2ggDQogICByZWNvcmQocykgdG8gaWdub3JlLiAgRm9yIGV4YW1w bGUsIHN1Y2ggYSByZXNvbHZlciBjb3VsZCBiZSANCiAgIGNvbmZpZ3VyZWQgdG8gZ3JhbnQgcHJl ZmVyZW5jZSB0byB0aGUgb24tbmV0IHJlY29yZCwgb3IgZXhlY3V0ZSBvdGhlciANCiAgIGxvZ2lj IGFzIHJlcXVpcmVkIGJ5IHRoZSBhcHBsaWNhdGlvbi4gDQogICAgDQo1LiAgIEVOVU0gU2Vydmlj ZSBSZWdpc3RyYXRpb24gZm9yIFBTVE4gDQogICAgDQogICBFbnVtc2VydmljZSBOYW1lOiAiUFNU TiIgDQogICAgDQogICBFbnVtc2VydmljZSBUeXBlOiAiUFNUTiIgDQogICAgDQogICBFbnVtc2Vy dmljZSBTdWJ0eXBlczogInRlbCIsIJNTSVCUIA0KICAgIA0KICAgVVJJIFNjaGVtZXM6ICd0ZWw6 JywgkXNpcDqSIA0KICAgIA0KICAgRnVuY3Rpb25hbCBTcGVjaWZpY2F0aW9uOiANCiANCiANCkxp dmluZ29vZCAmIFNob2NrZXkgICAgIEV4cGlyZXMgQXByaWwgMTYsIDIwMDYgICAgICAgICAgICAg ICAgW1BhZ2UgNF0gDQoMSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgUFNUTiBFbnVtc2Vydmlj ZSAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwNSANCiANCiANCiAgICANCiAgIFRoZXNlIEVudW1z ZXJ2aWNlcyBpbmRpY2F0ZSB0aGF0IHRoZSByZW1vdGUgcmVzb3VyY2UgaWRlbnRpZmllZCBjYW4g DQogICBiZSBhZGRyZXNzZWQgYnkgdGhlIGFzc29jaWF0ZWQgVVJJIHNjaGVtZSBpbiBvcmRlciB0 byBpbml0aWF0ZSBhIA0KICAgdGVsZWNvbW11bmljYXRpb24gc2Vzc2lvbiwgd2hpY2ggbWF5IGlu Y2x1ZGUgdHdvLXdheSB2b2ljZSBvciBvdGhlciANCiAgIGNvbW11bmljYXRpb25zLCB0byB0aGUg UFNUTi4gDQogICAgDQogICBTZWN1cml0eSBDb25zaWRlcmF0aW9uczogU2VlIFNlY3Rpb24gNS4g DQogICAgDQogICBJbnRlbmRlZCBVc2FnZTogQ09NTU9OIA0KICAgIA0KICAgQXV0aG9yczogDQog ICAgDQogICBKYXNvbiBMaXZpbmdvb2QgYW5kIFJpY2hhcmQgU2hvY2tleSAoZm9yIGF1dGhvciBj b250YWN0IGRldGFpbCBzZWUgDQogICBBdXRob3JzJyBBZGRyZXNzZXMgc2VjdGlvbikgDQogICAg DQogICBBbnkgb3RoZXIgaW5mb3JtYXRpb24gdGhlIGF1dGhvciBkZWVtcyBpbnRlcmVzdGluZzog DQogICAgDQogICBOb25lIA0KICAgIA0KNi4gICBFeGFtcGxlcyANCiANCiAgIFRoZSBmb2xsb3dp bmcgc3ViLXNlY3Rpb25zIGRvY3VtZW50IHNldmVyYWwgZXhhbXBsZXMgZm9yIGlsbHVzdHJhdGl2 ZSANCiAgIHB1cnBvc2VzLiAgVGhlc2UgZXhhbXBsZXMgc2hhbGwgaW4gbm8gd2F5IGxpbWl0IHRo ZSB2YXJpb3VzIGZvcm1zIA0KICAgdGhhdCB0aGlzIEVudW1zZXJ2aWNlIG1heSB0YWtlLiANCiAg ICANCjYuMSAgICBFeGFtcGxlIG9mIGEgUG9ydGVkIE51bWJlciwgVXNpbmcgYSCRdGVskiBVUkkg U2NoZW1lIA0KICAgIA0KICAgJE9SSUdJTiAzLjEuOC43LjEuOC45LjUuMS4yLjEuZTE2NC5hcnBh LiANCiAgIE5BUFRSIDEwIDEwMCAidSIgIkUyVStQU1ROOnRlbCIgDQogICAiIV4uKiQhdGVsOisx LTIxNS05ODEtNzgxMztybj0rMS0yMTUtOTgxLTc2MDA7bnBkaSEiIA0KICAgIA0KICAgSW4gdGhp cyBleGFtcGxlLCBhIFJvdXRpbmcgTnVtYmVyIChybikgYW5kIGEgTnVtYmVyIFBvcnRhYmlsaXR5 IERpcCANCiAgIEluZGljYXRvciAobnBkaSkgYXJlIHVzZWQgYXMgc2hvd24gaW4gZHJhZnQtaWV0 Zi1pcHRlbC10ZWwtbnAtMDcudHh0IA0KICAgWzEwXSAoSW50ZXJuZXQtRHJhZnQgTmV3IFBhcmFt ZXRlcnMgZm9yIHRoZSAidGVsIiBVUkkgdG8gU3VwcG9ydCANCiAgIE51bWJlciBQb3J0YWJpbGl0 eSwgZHJhZnQtaWV0Zi1pcHRlbC10ZWwtbnAtMDcudHh0IFsxMF0pLiAgVGhlIJFucGRpkiANCiAg IGZpZWxkIGlzIGluY2x1ZGVkIGluIG9yZGVyIHRvIHByZXZlbnQgc3Vic2VxdWVudCBsb29rdXBz IGluIGxlZ2FjeS0NCiAgIHN0eWxlIFBTVE4gZGF0YWJhc2VzLiANCiAgICANCjYuMiAgICBFeGFt cGxlIG9mIGEgUG9ydGVkIE51bWJlciwgVXNpbmcgYSCRc2lwkiBVUkkgU2NoZW1lIA0KICAgIA0K ICAgJE9SSUdJTiAzLjEuOC43LjEuOC45LjUuMS4yLjEuZTE2NC5hcnBhLiANCiAgIE5BUFRSIDEw IDEwMCAidSIgIkUyVStQU1ROOnNpcCIgDQogICAiIV4uKiQhc2lwOisxLTIxNS05ODEtNzgxMzty bj0rMS0yMTUtOTgxLQ0KICAgNzYwMDtucGRpQGd3LmV4YW1wbGUuY29tO3VzZXI9cGhvbmUhIiAN CiAgICANCiAgIEluIHRoaXMgZXhhbXBsZSwgYSBSb3V0aW5nIE51bWJlciAocm4pIGFuZCBhIE51 bWJlciBQb3J0YWJpbGl0eSBEaXAgDQogICBJbmRpY2F0b3IgKG5wZGkpIGFyZSB1c2VkIGFzIHNo b3duIGluIGRyYWZ0LWlldGYtaXB0ZWwtdGVsLW5wLTA3LnR4dCANCiAgIFsxMF0gKEludGVybmV0 LURyYWZ0IE5ldyBQYXJhbWV0ZXJzIGZvciB0aGUgInRlbCIgVVJJIHRvIFN1cHBvcnQgDQogICBO dW1iZXIgUG9ydGFiaWxpdHksIGRyYWZ0LWlldGYtaXB0ZWwtdGVsLW5wLTA3LnR4dCBbMTBdKS4g IFRoZSCRbnBkaZIgDQogDQogDQpMaXZpbmdvb2QgJiBTaG9ja2V5ICAgICBFeHBpcmVzIEFwcmls IDE2LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDVdIA0KDEludGVybmV0LURyYWZ0ICAgICAg ICAgICAgIFBTVE4gRW51bXNlcnZpY2UgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDUgDQogDQog DQogICBmaWVsZCBpcyBpbmNsdWRlZCBpbiBvcmRlciB0byBwcmV2ZW50IHN1YnNlcXVlbnQgbG9v a3VwcyBpbiBsZWdhY3ktDQogICBzdHlsZSBQU1ROIGRhdGFiYXNlcy4gIFRoZSBtZXRob2Qgb2Yg Y29udmVyc2lvbiBmcm9tIGEgdGVsIHRvIGEgU0lQIA0KICAgVVJJIGlzIGFzIGRlbW9uc3RyYXRl ZCBpbiBSRkMgMzI2MSwgU2VjdGlvbiAxOS4xLjYgWzExXSwgYXMgd2VsbCBhcyANCiAgIGluICwg ZHJhZnQtaWV0Zi1pcHRlbC10ZWwtbnAtMDcudHh0IFNlY3Rpb24gNi4zIFsxMF0uIA0KICAgIA0K Ni4zICAgIEV4YW1wbGUgb2YgYSBOb24tUG9ydGVkIE51bWJlciwgVXNpbmcgYSCRdGVskiBVUkkg U2NoZW1lIA0KICAgIA0KICAgJE9SSUdJTiAzLjEuOC43LjEuOC45LjUuMS4yLjEuZTE2NC5hcnBh LiANCiAgIE5BUFRSIDEwIDEwMCAidSIgIkUyVStQU1ROOnRlbCIgDQogICAiIV4uKiQhdGVsOisx LTIxNS05ODEtNzgxMztucGRpISIgDQogICAgDQogICBJbiB0aGlzIGV4YW1wbGUsIGEgTnVtYmVy IFBvcnRhYmlsaXR5IERpcCBJbmRpY2F0b3IgKG5wZGkpIGlzIHVzZWQgDQogICBbMTBdLiAgVGhl IJFucGRpkiBmaWVsZCBpcyBpbmNsdWRlZCBpbiBvcmRlciB0byBwcmV2ZW50IHN1YnNlcXVlbnQg DQogICBsb29rdXBzIGluIGxlZ2FjeS1zdHlsZSBQU1ROIGRhdGFiYXNlcy4gDQogICAgDQo2LjQg ICAgRXhhbXBsZSBvZiBhIE5vbi1Qb3J0ZWQgTnVtYmVyLCBVc2luZyBhIJFzaXCSIFVSSSBTY2hl bWUgDQogICAgDQogICAkT1JJR0lOIDMuMS44LjcuMS44LjkuNS4xLjIuMS5lMTY0LmFycGEuIA0K ICAgTkFQVFIgMTAgMTAwICJ1IiAiRTJVK1BTVE46c2lwIiANCiAgICIhXi4qJCFzaXA6KzEtMjE1 LTk4MS03ODEzO25wZGlAZ3cuZXhhbXBsZS5jb207dXNlcj1waG9uZSEiIA0KICAgIA0KICAgSW4g dGhpcyBleGFtcGxlLCBhIE51bWJlciBQb3J0YWJpbGl0eSBEaXAgSW5kaWNhdG9yIChucGRpKSBp cyB1c2VkIA0KICAgWzEwXS4gIFRoZSCRbnBkaZIgZmllbGQgaXMgaW5jbHVkZWQgaW4gb3JkZXIg dG8gcHJldmVudCBzdWJzZXF1ZW50IA0KICAgbG9va3VwcyBpbiBsZWdhY3ktc3R5bGUgUFNUTiBk YXRhYmFzZXMuICBUaGUgbWV0aG9kIG9mIGNvbnZlcnNpb24gDQogICBmcm9tIGEgdGVsIHRvIGEg U0lQIFVSSSBpcyBhcyBkZW1vbnN0cmF0ZWQgaW4gUkZDIDMyNjEsIFNlY3Rpb24gDQogICAxOS4x LjYgWzExXSwgYXMgd2VsbCBhcyBpbiAsIGRyYWZ0LWlldGYtaXB0ZWwtdGVsLW5wLTA3LnR4dCBT ZWN0aW9uIA0KICAgNi4zIFsxMF0uIA0KICAgIA0KNy4gICBTZWN1cml0eSBDb25zaWRlcmF0aW9u cyANCiAgICANCiAgIEROUywgYXMgdXNlZCBieSBFTlVNLCBpcyBhIGdsb2JhbCwgZGlzdHJpYnV0 ZWQgZGF0YWJhc2UuICBUaHVzIGFueSANCiAgIGluZm9ybWF0aW9uIHN0b3JlZCB0aGVyZSBpcyB2 aXNpYmxlIHRvIGFueW9uZSBhbm9ueW1vdXNseS4gIFdoaWxlIA0KICAgdGhpcyBpcyBub3QgcXVh bGl0YXRpdmVseSBkaWZmZXJlbnQgZnJvbSBwdWJsaWNhdGlvbiBpbiBhIFRlbGVwaG9uZSANCiAg IERpcmVjdG9yeSwgaXQgZG9lcyBvcGVuIG9yIGVhc2UgYWNjZXNzIHRvIHN1Y2ggZGF0YSB3aXRo b3V0IGFueSANCiAgIGluZGljYXRpb24gdGhhdCBzdWNoIGRhdGEgaGFzIGJlZW4gYWNjZXNzZWQg b3IgYnkgd2hvbSBpdCBoYXMgYmVlbiANCiAgIGFjY2Vzc2VkLiANCiAgICANCiAgIFN1Y2ggZGF0 YSBoYXJ2ZXN0aW5nIGJ5IHRoaXJkIHBhcnRpZXMgaXMgb2Z0ZW4gdXNlZCB0byBnZW5lcmF0ZSBs aXN0cyANCiAgIG9mIHRhcmdldHMgZm9yIHVuc29saWNpdGVkIGluZm9ybWF0aW9uLiAgVGh1cywg YSB0aGlyZCBwYXJ0eSBjb3VsZCANCiAgIHVzZSB0aGlzIHRvIGdlbmVyYXRlIGEgbGlzdCB0aGF0 IHRoZXkgY2FuIHVzZSB0byBtYWtlIHVuc29saWNpdGVkIA0KICAgInRlbGVtYXJrZXRpbmciIHBo b25lIGNhbGxzLiAgTWFueSBjb3VudHJpZXMgaGF2ZSBkby1ub3QtY2FsbCANCiAgIHJlZ2lzdHJp ZXMgb3Igb3RoZXIgbGVnYWwgb3IgcmVndWxhdG9yeSBtZWNoYW5pc21zIGluIHBsYWNlIHRvIGRl YWwgDQogICB3aXRoIHN1Y2ggYWJ1c2VzLiAgIA0KICAgIA0KICAgQ2FycmllcnMsIHNlcnZpY2Ug cHJvdmlkZXJzLCBhbmQgb3RoZXIgdXNlcnMgbWF5IHNpbXBseSBjaG9vc2Ugbm90IHRvIA0KICAg cHVibGlzaCBzdWNoIGluZm9ybWF0aW9uIGluIHRoZSBwdWJsaWMgRTE2NC5BUlBBIHRyZWUsIGJ1 dCBtYXkgDQogICBpbnN0ZWFkIHNpbXBseSBwdWJsaXNoIHRoaXMgaW4gdGhlaXIgaW50ZXJuYWwg RU5VTSByb3V0aW5nIGRhdGFiYXNlIA0KICAgd2hpY2ggaXMgb25seSBhYmxlIHRvIGJlIHF1ZXJp ZWQgYnkgdHJ1c3RlZCBlbGVtZW50cyBvZiB0aGVpciANCiAgIG5ldHdvcmssIHN1Y2ggYXMgc29m dHN3aXRjaGVzIGFuZCBTSVAgcHJveHkgc2VydmVycy4gDQogDQogDQpMaXZpbmdvb2QgJiBTaG9j a2V5ICAgICBFeHBpcmVzIEFwcmlsIDE2LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDZdIA0K DEludGVybmV0LURyYWZ0ICAgICAgICAgICAgIFBTVE4gRW51bXNlcnZpY2UgICAgICAgICAgICAg ICBPY3RvYmVyIDIwMDUgDQogDQogDQogICAgDQogICBBbHRob3VnaCBhbiBFLjE2NCB0ZWxlcGhv bmUgbnVtYmVyIGRvZXMgbm90IGFwcGVhciB0byByZXZlYWwgYXMgbXVjaCANCiAgIGlkZW50aXR5 IGluZm9ybWF0aW9uIGFib3V0IGEgdXNlciBhcyBhIG5hbWUgaW4gdGhlIGZvcm1hdCANCiAgIHNp cDp1c2VybmFtZUBob3N0bmFtZSBvciBlbWFpbDp1c2VybmFtZUBob3N0bmFtZSwgdGhlIGluZm9y bWF0aW9uIGlzIA0KICAgc3RpbGwgcHVibGljbHkgYXZhaWxhYmxlLCB0aHVzIHRoZXJlIGlzIHN0 aWxsIHRoZSByaXNrIG9mIHVud2FudGVkIA0KICAgY29tbXVuaWNhdGlvbi4gDQogICAgDQogICBB biBhbmFseXNpcyBvZiB0aHJlYXRzIHNwZWNpZmljIHRvIHRoZSBkZXBlbmRlbmNlIG9mIEVOVU0g b24gdGhlIEROUyANCiAgIGFuZCB0aGUgYXBwbGljYWJpbGl0eSBvZiBETlNTRUMgWzEzXSB0byB0 aGlzIGlzIHByb3ZpZGVkIGluIFJGQyAzNzYxIA0KICAgWzFdLiAgQSB0aG9yb3VnaCBhbmFseXNp cyBvZiB0aHJlYXRzIHRvIHRoZSBETlMgaXRzZWxmIGlzIGNvdmVyZWQgaW4gDQogICBSRkMgMzgz MyBbMTRdLiANCiAgICANCiAgICANCjguICAgSUFOQSBDb25zaWRlcmF0aW9ucyANCiAgICANCiAg IFRoaXMgZG9jdW1lbnQgcmVnaXN0ZXJzIHRoZSAncHN0bicgRW51bXNlcnZpY2UgYW5kIHRoZSBz dWJ0eXBlIJN0ZWyUIA0KICAgYW5kIJNTSVCUIHVuZGVyIHRoZSBFbnVtc2VydmljZSByZWdpc3Ry eSBkZXNjcmliZWQgaW4gdGhlIElBTkEgDQogICBjb25zaWRlcmF0aW9ucyBpbiBSRkMgMzc2MS4g IERldGFpbHMgb2YgdGhpcyByZWdpc3RyYXRpb24gYXJlIA0KICAgcHJvdmlkZWQgaW4gc2VjdGlv bnMgMyBhbmQgNCBvZiB0aGlzIGRvY3VtZW50LiANCiAgICANCjkuICAgQWNrbm93bGVkZ2VtZW50 cyANCiAgICANCiAgIFRoZSBhdXRob3JzIHdpc2ggdG8gdGhhbmsgVG9tIENyZWlnaHRvbiwgSmFz b24gR2FlZHRrZSwgSmFpbWUgDQogICBKaW1lbmV6LCBhbmQgQ2hyaXMgS2VubmVkeSBmcm9tIENv bWNhc3QgQ2FibGUsIEpvbmF0aGFuIFJvc2VuYmVyZyANCiAgIGZyb20gQ2lzY28sIERvdWcgUmFu YWxsaSBhbmQgQm9iIFdhbHRlciBmcm9tIE5ldE51bWJlciwgYW5kIEphbWVzIFl1IA0KICAgZnJv bSBOZXVTdGFyLCBmb3IgdGhlaXIgaGVscGZ1bCBkaXNjdXNzaW9uIG9uIHRoaXMgdG9waWMuIA0K ICAgIA0KMTAuICAgIFJlZmVyZW5jZXMgDQogICAgDQoxMC4xICAgICBOb3JtYXRpdmUgUmVmZXJl bmNlcyANCiAgICANCiAgIFsxXSBGYWx0c3Ryb20sIFAuIGFuZCBNLiBNZWFsbGluZywgIlRoZSBF LjE2NCB0byBVbmlmb3JtIFJlc291cmNlIA0KICAgSWRlbnRpZmllcnMgKFVSSSkgRHluYW1pYyBE ZWxlZ2F0aW9uIERpc2NvdmVyeSBTeXN0ZW0gKERERFMpIA0KICAgQXBwbGljYXRpb24gKEVOVU0p IiwgUkZDIDM3NjEsIEFwcmlsIDIwMDQuIA0KICAgIA0KICAgWzJdIElUVS1ULCAiVGhlIEludGVy bmF0aW9uYWwgUHVibGljIFRlbGVjb21tdW5pY2F0aW9uIE51bWJlciBQbGFuIiwgDQogICBSZWNv bW1lbmRhdGlvbiBFLjE2NCwgTWF5IDE5OTcuIA0KICAgIA0KICAgWzNdIE1vY2thcGV0cmlzLCBQ LiwgIkRPTUFJTiBOQU1FUyAtIENPTkNFUFRTIEFORCBGQUNJTElUSUVTIiwgUkZDIA0KICAgMTAz NCwgTm92ZW1iZXIgMTk4Ny4gDQogICAgDQogICBbNF0gTWVhbGxpbmcsIE0uLCAiRHluYW1pYyBE ZWxlZ2F0aW9uIERpc2NvdmVyeSBTeXN0ZW0gKERERFMpIFBhcnQgDQogICBUaHJlZTogVGhlIERv bWFpbiBOYW1lIFN5c3RlbSAoRE5TKSBEYXRhYmFzZSIsIFJGQyAzNDAzLCBPY3RvYmVyIA0KICAg MjAwMi4gDQogICAgDQogICBbNV0gTWVhbGxpbmcsIE0uLCAiRHluYW1pYyBEZWxlZ2F0aW9uIERp c2NvdmVyeSBTeXN0ZW0gKERERFMpIFBhcnQgDQogICBPbmU6IFRoZSBDb21wcmVoZW5zaXZlIERE RFMiLCBSRkMgMzQwMSwgT2N0b2JlciAyMDAyLiANCiAgICANCg0KIA0KIA0KTGl2aW5nb29kICYg U2hvY2tleSAgICAgRXhwaXJlcyBBcHJpbCAxNiwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSA3 XSANCgxJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBQU1ROIEVudW1zZXJ2aWNlICAgICAgICAg ICAgICAgT2N0b2JlciAyMDA1IA0KIA0KIA0KICAgWzZdIE1lYWxsaW5nLCBNLiwgIkR5bmFtaWMg RGVsZWdhdGlvbiBEaXNjb3ZlcnkgU3lzdGVtIChERERTKSBQYXJ0IA0KICAgVHdvOiBUaGUgQWxn b3JpdGhtIiwgUkZDIDM0MDIsIE9jdG9iZXIgMjAwMi4gDQogICAgDQogICBbN10gTWVhbGxpbmcs IE0uLCAiRHluYW1pYyBEZWxlZ2F0aW9uIERpc2NvdmVyeSBTeXN0ZW0gKERERFMpIFBhcnQgDQog ICBGb3VyOiBUaGUgVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVycyAoVVJJKSIsIFJGQyAzNDA0 LCBPY3RvYmVyIA0KICAgMjAwMi4gDQogICAgDQogICBbOF0gTWVhbGxpbmcsIE0uLCAiRHluYW1p YyBEZWxlZ2F0aW9uIERpc2NvdmVyeSBTeXN0ZW0gKERERFMpIFBhcnQgDQogICBGaXZlOiBVUkku QVJQQSBBc3NpZ25tZW50IFByb2NlZHVyZXMiLCBSRkMgMzQwNSwgT2N0b2JlciAyMDAyLiANCiAg ICANCiAgIFs5XSBTY2h1bHpyaW5uZSwgSC4sICJUaGUgdGVsIFVSSSBmb3IgVGVsZXBob25lIE51 bWJlcnMiLCBSRkMgMzk2NiwgDQogICBEZWNlbWJlciAyMDA0LiANCiAgICANCiAgIFsxMF0gWXUs IEouLCAiTmV3IFBhcmFtZXRlcnMgZm9yIHRoZSAidGVsIiBVUkkgdG8gU3VwcG9ydCBOdW1iZXIg DQogICBQb3J0YWJpbGl0eSIsIGRyYWZ0LWlldGYtaXB0ZWwtdGVsLW5wLTA3LnR4dCwgSnVseSAy MDA1LiANCiAgICANCiAgIFsxMV0gUm9zZW5iZXJnLCBKLiwgZXQgYWwuLCCTU0lQOiBTZXNzaW9u IEluaXRpYXRpb24gUHJvdG9jb2yULCBSRkMgDQogICAzMjYxLCBKdW5lIDIwMDIuIA0KICAgIA0K ICAgIA0KMTAuMiAgICAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyANCiAgICANCiAgIFsxMl0gQnJh ZG5lciwgZXQgYWwuLCAiSUFOQSBSZWdpc3RyYXRpb24gZm9yIEVudW1zZXJ2aWNlcyBlbWFpbCwg ZmF4LCANCiAgIG1tcywgZW1zIGFuZCBzbXMiLCBkcmFmdC1pZXRmLWVudW0tbXNnLTA1LnR4dCwg TWF5IDIwMDUuIA0KICAgIA0KICAgWzEzXSBBcmVuZHMsIFIuIGFuZCBldCBhbC4sICJQcm90b2Nv bCBNb2RpZmljYXRpb25zIGZvciB0aGUgRE5TIA0KICAgU2VjdXJpdHkgRXh0ZW5zaW9ucyIsIFJG QyA0MDM1LCBNYXJjaCAyMDA1LiANCiAgICANCiAgIFsxNF0gQXRraW5zLCBELiBhbmQgQXVzdGVp biwgUi4sICJUaHJlYXQgQW5hbHlzaXMgb2YgdGhlIERvbWFpbiBOYW1lIA0KICAgU3lzdGVtIChE TlMpIiwgUkZDIDM4MzMsIEF1Z3VzdCAyMDA0LiANCiAgICANCiAgIFsxNV0gRm9zdGVyLCBNLiwg TWNHYXJyeSwgVC4sIGFuZCBZdSwgSi4sICJOdW1iZXIgUG9ydGFiaWxpdHkgaW4gdGhlIA0KICAg R1NUTjogQW4gT3ZlcnZpZXciLCBSRkMgMzQ4MiwgRmVicnVhcnkgMjAwMy4gDQogICAgDQogICAg DQogICBbMTZdIFBldGVyc29uLCBKLiwgImVudW1zZXJ2aWNlIFJlZ2lzdHJhdGlvbiBmb3IgU2Vz c2lvbiBJbml0aWF0aW9uIA0KICAgUHJvdG9jb2wgKFNJUCkgQWRkcmVzc2VzLW9mLVJlY29yZJQs IFJGQyAzNzY0LCBBcHJpbCAyMDA0LiANCiAgICANCkF1dGhvcnOSIEFkZHJlc3NlcyANCiAgICAN CiAgIEphc29uIExpdmluZ29vZCANCiAgIENvbWNhc3QgQ2FibGUgQ29tbXVuaWNhdGlvbnMgDQog ICAxNTAwIE1hcmtldCBTdHJlZXQgDQogICBQaGlsYWRlbHBoaWEsIFBBIDE5MTAyIA0KICAgVVNB IA0KICAgIA0KICAgUGhvbmU6ICsxLTIxNS05ODEtNzgxMyANCiAgIEVtYWlsOiBqYXNvbl9saXZp bmdvb2RAY2FibGUuY29tY2FzdC5jb20gDQogICAgDQogDQogDQpMaXZpbmdvb2QgJiBTaG9ja2V5 ICAgICBFeHBpcmVzIEFwcmlsIDE2LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDhdIA0KDElu dGVybmV0LURyYWZ0ICAgICAgICAgICAgIFBTVE4gRW51bXNlcnZpY2UgICAgICAgICAgICAgICBP Y3RvYmVyIDIwMDUgDQogDQogDQogICAgDQogICBSaWNoYXJkIFNob2NrZXkgDQogICBOZXVTdGFy IA0KICAgNDYwMDAgQ2VudGVyIE9hayBQbGF6YSANCiAgIFN0ZXJsaW5nLCBWQSAyMDE2NiANCiAg IFVTQSANCiAgICANCiAgIFBob25lOiArMS01NzEtNDM0LTU2NTEgDQogICBFbWFpbDogcmljaGFy ZC5zaG9ja2V5QG5ldXN0YXIuYml6IA0KICAgIA0KICAgICANCkludGVsbGVjdHVhbCBQcm9wZXJ0 eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgDQogICAgDQogICBJbnRlbGxlY3R1YWwgUHJvcGVy dHkgU3RhdGVtZW50IA0KICAgIA0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJk aW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkgDQogICBJbnRlbGxlY3R1YWwgUHJvcGVy dHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8gDQogICBw ZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVz Y3JpYmVkIGluIA0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBs aWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzIA0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWls YWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzIA0KICAgbWFkZSBhbnkgaW5k ZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9u IA0KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9j dW1lbnRzIGNhbiBiZSANCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5LiANCiAgICANCiAg IENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBh bmQgYW55IA0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwg b3IgdGhlIHJlc3VsdCBvZiBhbiANCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFs IGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZiANCiAgIHN1Y2ggcHJvcHJpZXRh cnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzIA0KICAgc3BlY2lmaWNh dGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5 IGF0IA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuIA0KICAgIA0KICAgVGhlIElFVEYgaW52 aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueSAN CiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIg cHJvcHJpZXRhcnkgDQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1h eSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQgDQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFk ZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0ICANCiAgIGlldGYtaXByQGlldGYu b3JnLiANCiANCiAgIERpc2NsYWltZXIgb2YgVmFsaWRpdHkgDQogICAgDQogICBUaGlzIGRvY3Vt ZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24g YW4gDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJ T04gSEUvU0hFIFJFUFJFU0VOVFMgDQogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRI RSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQgDQogICBFTkdJTkVFUklORyBUQVNL IEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIA0KICAg SU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9G IFRIRSANCiAgIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRT IE9SIEFOWSBJTVBMSUVEIA0KICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklU TkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIA0KICAgIA0KICAgIA0KICAgQ29weXJpZ2h0 IFN0YXRlbWVudCANCiANCiANCkxpdmluZ29vZCAmIFNob2NrZXkgICAgIEV4cGlyZXMgQXByaWwg MTYsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgOV0gDQoMSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgUFNUTiBFbnVtc2VydmljZSAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwNSANCiANCiAN CiAgICANCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDUpLiAgVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IA0KICAgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJl c3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQgDQogICBleGNlcHQgYXMgc2V0IGZv cnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLiANCiAgICAN CiAgICANCiAgIEFja25vd2xlZGdtZW50IA0KICAgIA0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBF ZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZSANCiAgIEludGVybmV0 IFNvY2lldHkuIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KIA0KIA0KTGl2aW5nb29kICYgU2hvY2tl eSAgICAgRXhwaXJlcyBBcHJpbCAxNiwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDEwXSANCgw= ------_=_NextPart_001_01C5D3FC.212C2145 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01C5D3FC.212C2145-- From enum-bounces@ietf.org Tue Oct 18 13:46:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERvXX-0006Iq-3X; Tue, 18 Oct 2005 13:46:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERvXT-0006IW-NL for enum@megatron.ietf.org; Tue, 18 Oct 2005 13:46:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18477 for ; Tue, 18 Oct 2005 13:46:06 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERvj2-0005JW-MG for enum@ietf.org; Tue, 18 Oct 2005 13:58:13 -0400 Received: from [10.31.13.186] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9IHkeFm007142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Oct 2005 10:46:41 -0700 Message-ID: <435534CD.5040309@shockey.us> Date: Tue, 18 Oct 2005 13:45:49 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: multipart/mixed; boundary="------------060206080908090402020004" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 47dfdcb76bc7cdf600c30037ff1750ed Subject: [Enum] [Fwd: I-D submission: draft-lind-infrastructure-enum-reqs-01] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------060206080908090402020004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ENUM S. Lind Internet-Draft AT&T Labs Expires: April 22, 2006 P. Pfautz AT&T October 18, 2005 Carrier/Infrastructure ENUM Requirements draft-lind-infrastructure-enum-reqs-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 22, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document provides requirements for "infrastructure" or "carrier" ENUM, defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP. Lind & Pfautz Expires April 22, 2006 [Page 1] Internet-Draft Carrier ENUM Requirements October 2005 Conventions used in this document RFC2119 [1] provides the interpretations for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. 1. Infrastructure ENUM 1.1. Definition Infrastructure ENUM is defined as the use of the technology in RFC3761 [2] by the carrier-of-record for a specific E.164 number [3] to map a telephone number into a URI that identifies a specific point of interconnection to that service provider's network that could enable the originating party to establish communication with the associated terminating party. It is separate from any URIs that the end-user, who registers their E.164 number, may wish to associate with that E.164 number. For purposes of this document, "Carrier of Record" refers to the entity that provides PSTN service for an E.164 number with the understanding that this definition is ultimately a matter for national authorities to determine. 1.2. Background Carriers use E.164 numbers currently as their main naming and routing vehicle. Carrier ENUM in e164.arpa or another publicly available tree allows Carriers to link Internet based resources such as URIs to E.164 numbers (Note: this is the other way round then User ENUM). This allows Carrier in addition to interconnecting via the PSTN (or exclusively) to peer via IP-based protocols. Carriers may announce all E.164 numbers or number ranges they host, regardless if the final end-user device is on the Internet, on IP-based closed NGNs or on the PSTN, provided an access (e.g. SBC or gateway) to the destination carriers network is available on the Internet. There is also no guarantee that the originating carrier querying Carrier ENUM is able to access the ingress network element of the destination carriers network. Additional peering and accounting agreements requiring authentication may be necessary. The access provided may also be to a shared network of a group of carriers, resolving the final destination network within the shared network. 2. Requirements for Infrastructure ENUM Lind & Pfautz Expires April 22, 2006 [Page 2] Internet-Draft Carrier ENUM Requirements October 2005 2.1. Infrastructure ENUM SHALL provide a means for a carrier to populate DNS RRs in a common publicly accessible namespace for the E.164 numbering resources for which it is the carrier-of-record. 2.2. Queries of infrastructure ENUM FQDNs MUST return a result, even if the result is NXDOMAIN. Queries must not be rejected, e.g. based on ACLs. 2.3. Infrastructure ENUM SHALL support RRs providing a URI that can identify a point of interconnection for delivery of communications addressed to the E.164 number. 2.4. Infrastructure ENUM SHALL support an IRIS capability that allows qualified parties to obtain information regarding the E.164 numbering resources and the corresponding carrier-of-record. 2.5. Implementation of Infrastructure ENUM MUST NOT restrict the ability of an end-user, in a competitive environment, to choose a Registrar and/or Tier 2 name server provider for end-user ENUM registrations. 2.6. Infrastructure ENUM SHALL be implemented under a TLD that can support reliability and performance suitable for PSTN applications. 2.7. Infrastructure ENUM MUST meet all reasonable privacy concerns about visibility of information an end user has no control over, for example discovery of unlisted numbers, or inadvertent disclosure of user identity. 2.8. Proposed implementations of Infrastructure ENUM SHOULD a. Minimize changes required to existing requirements that are part of RFC 3761 Lind & Pfautz Expires April 22, 2006 [Page 3] Internet-Draft Carrier ENUM Requirements October 2005 b. Work with open numbering plans c. Restrict additional functionality to carrier resolvers. d. Minimize the number of lookups required to obtain as many NAPTR records (end-user and carrier) as possible. e. Minimize the client knowledge of the numbering plan required. f. Maximize synergies with end-user ENUM g. Support interworking with private ENUM trees. 3. Security Considerations Existing security considerations for ENUM detailed in [2] still apply. Note that some registration validation issues concerning end user ENUM may not apply to carrier ENUM. Where the Tier 1 registry is able to identify the carrier serving a number e.g., based on industry data for number block assignments and number portability, registration might be more easily automated and a separate registrar not required. Some parties have expressed concern that a carrier ENUM could compromise end user privacy by making it possible for others to identify unlisted or unpublished numbers based on their registration in ENUM. This can be avoided if carriers register all of the their allocated (as opposed to assigned) numbers. Unassigned numbers should be provisioned to route to the carrier's network in the same fashion as assigned numbers and only then provide an indication that they are unassigned. In that way, carrier registration of a number in ENUM provides no more information about status of a number than could be obtained by dialing it. 4. IANA Considerations IANA considerations will depend on the architecture ultimately chosen to meet the requirements. 5. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Lind & Pfautz Expires April 22, 2006 [Page 4] Internet-Draft Carrier ENUM Requirements October 2005 Application (ENUM)", RFC 3761, April 2004. [3] International Telecommunications Union-T, "The International Public Telecommunication Number Plan", Recommendation E.164", May 1997. Lind & Pfautz Expires April 22, 2006 [Page 5] Internet-Draft Carrier ENUM Requirements October 2005 Authors' Addresses Steven Lind AT&T Labs 180 Park Ave Florham Park, NJ 07932-0971 USA Email: slind@att.com Penn Pfautz AT&T 200 S. Laurel Ave Middletown, NJ 07748 USA Email: ppfautz@att.com Lind & Pfautz Expires April 22, 2006 [Page 6] Internet-Draft Carrier ENUM Requirements October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lind & Pfautz Expires April 22, 2006 [Page 7] -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --------------060206080908090402020004 Content-Type: text/plain; name="draft-lind-infrastructure-enum-reqs-01.txt" Content-Disposition: inline; filename="draft-lind-infrastructure-enum-reqs-01.txt" Content-Transfer-Encoding: 7bit ENUM S. Lind Internet-Draft AT&T Labs Expires: April 22, 2006 P. Pfautz AT&T October 18, 2005 Carrier/Infrastrucure ENUM Requirements draft-lind-infrastructure-enum-reqs-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 22, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document provides requirements for "infrastructure" or "carrier" ENUM, defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP. Lind & Pfautz Expires April 22, 2006 [Page 1] Internet-Draft Carrier ENUM Requirements October 2005 Conventions used in this document RFC2119 [1] provides the interpretations for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. 1. Infrastructure ENUM 1.1. Definition Infrastructure ENUM is defined as the use of the technology in RFC3761 [2] by the carrier-of-record for a specific E.164 number [3] to map a telephone number into a URI that identifies a specific point of interconnection to that service provider's network that could enable the originating party to establish communication with the associated terminating party. It is separate from any URIs that the end-user, who registers their E.164 number, may wish to associate with that E.164 number. For purposes of this document, "Carrier of Record" refers to the entity that provides PSTN service for an E.164 number with the understanding that this definition is ultimately a matter for national authorities to determine. 1.2. Background Carriers use E.164 numbers currently as their main naming and routing vehicle. Carrier ENUM in e164.arpa or another publicly available tree allows Carriers to link Internet based resources such as URIs to E.164 numbers (Note: this is the other way round then User ENUM). This allows Carrier in addition to interconnecting via the PSTN (or exclusively) to peer via IP-based protocols. Carriers may announce all E.164 numbers or number ranges they host, regardless if the final end-user device is on the Internet, on IP-based closed NGNs or on the PSTN, provided an access (e.g. SBC or gateway) to the destination carriers network is available on the Internet. There is also no guarantee that the originating carrier querying Carrier ENUM is able to access the ingress network element of the destination carriers network. Additional peering and accounting agreements requiring authentication may be necessary. The access provided may also be to a shared network of a group of carriers, resolving the final destination network within the shared network. 2. Requirements for Infrastructure ENUM Lind & Pfautz Expires April 22, 2006 [Page 2] Internet-Draft Carrier ENUM Requirements October 2005 2.1. Infrastructure ENUM SHALL provide a means for a carrier to populate DNS RRs in a common publicly accessible namespace for the E.164 numbering resources for which it is the carrier-of-record. 2.2. Queries of infrastructure ENUM FQDNs MUST return a result, even if the result is NXDOMAIN. Queries must not be rejected, e.g. based on ACLs. 2.3. Infrastructure ENUM SHALL support RRs providing a URI that can identify a point of interconnection for delivery of communications addressed to the E.164 number. 2.4. Infrastructure ENUM SHALL support an IRIS capability that allows qualified parties to obtain information regarding the E.164 numbering resources and the corresponding carrier-of-record. 2.5. Implementation of Infrastructure ENUM MUST NOT restrict the ability of an end-user, in a competitive environment, to choose a Registrar and/or Tier 2 name server provider for end-user ENUM registrations. 2.6. Infrastructure ENUM SHALL be implemented under a TLD that can support reliability and performance suitable for PSTN applications. 2.7. Infrastructure ENUM MUST meet all reasonable privacy concerns about visibility of information an end user has no control over, for example discovery of unlisted numbers, or inadvertent disclosure of user identity. 2.8. Proposed implementations of Infrastructure ENUM SHOULD a. Minimize changes required to existing requirements that are part of RFC 3761 Lind & Pfautz Expires April 22, 2006 [Page 3] Internet-Draft Carrier ENUM Requirements October 2005 b. Work with open numbering plans c. Restrict additional functionality to carrier resolvers. d. Minimize the number of lookups required to obtain as many NAPTR records (end-user and carrier) as possible. e. Minimize the client knowledge of the numbering plan required. f. Maximize synergies with end-user ENUM g. Support interworking with private ENUM trees. 3. Security Considerations Existing security considerations for ENUM detailed in [2] still apply. Note that some registration validation issues concerning end user ENUM may not apply to carrier ENUM. Where the Tier 1 registry is able to identify the carrier serving a number e.g., based on industry data for number block assignments and number portability, registration might be more easily automated and a separate registrar not required. Some parties have expressed concern that a carrier ENUM could compromise end user privacy by making it possible for others to identify unlisted or unpublished numbers based on their registration in ENUM. This can be avoided if carriers register all of the their allocated (as opposed to assigned) numbers. Unassigned numbers should be provisioned to route to the carrier's network in the same fashion as assigned numbers and only then provide an indication that they are unassigned. In that way, carrier registration of a number in ENUM provides no more information about status of a number than could be obtained by dialing it. 4. IANA Considerations IANA considerations will depend on the architecture ultimately chosen to meet the requirements. 5. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Lind & Pfautz Expires April 22, 2006 [Page 4] Internet-Draft Carrier ENUM Requirements October 2005 Application (ENUM)", RFC 3761, April 2004. [3] International Telecommunications Union-T, "The International Public Telecommunication Number Plan", Recommendation E.164", May 1997. Lind & Pfautz Expires April 22, 2006 [Page 5] Internet-Draft Carrier ENUM Requirements October 2005 Authors' Addresses Steven Lind AT&T Labs 180 Park Ave Florham Park, NJ 07932-0971 USA Email: slind@att.com Penn Pfautz AT&T 200 S. Laurel Ave Middletown, NJ 07748 USA Email: ppfautz@att.com Lind & Pfautz Expires April 22, 2006 [Page 6] Internet-Draft Carrier ENUM Requirements October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lind & Pfautz Expires April 22, 2006 [Page 7] --------------060206080908090402020004 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------060206080908090402020004-- From enum-bounces@ietf.org Tue Oct 18 15:53:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxWB-0007Se-0E; Tue, 18 Oct 2005 15:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxTR-0006x1-QV; Tue, 18 Oct 2005 15:50:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24508; Tue, 18 Oct 2005 15:50:06 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERxes-0000BU-PA; Tue, 18 Oct 2005 16:02:06 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ERxTG-0001c5-Oh; Tue, 18 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 18 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-experiences-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-03.txt Pages : 33 Date : 2005-10-18 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is advisory, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-experiences-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-experiences-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-18135849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-experiences-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-experiences-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-18135849.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Tue Oct 18 16:23:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERy01-00078V-Iu; Tue, 18 Oct 2005 16:23:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERxzz-000786-ST for enum@megatron.ietf.org; Tue, 18 Oct 2005 16:23:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05230 for ; Tue, 18 Oct 2005 16:23:43 -0400 (EDT) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERyBZ-0004BQ-EF for enum@ietf.org; Tue, 18 Oct 2005 16:35:50 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id BCA1370735 for ; Tue, 18 Oct 2005 21:23:39 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "'enum@ietf.org' ENUM" From: lconroy Date: Tue, 18 Oct 2005 21:23:20 +0100 X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Subject: [Enum] More Experienced X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Folks, On the subject of drafts, the next version of the Experiences draft has just popped out. For those of you who haven't discovered the wonderful rfcdiff web service at: This version adds a new issue (Interpretation of 3403 and 3761) on what the heck the text means about non-terminals. YMMV. It also tightens up the DNS requirements a lot (in section 6). NOTE - this does not explicitly rely on the new edns0 draft, so there is currently some duplication. Speaking purely for myself, after the fiasco with the MSG document [that was blown into limbo by a requirement to insert a pointless normative (rather than informative) reference to a document that was then un-approved], caution is advisable (for which read "never again" or "fooled me once, shame on you, ..."). Seriously folks, please look at the recommendation on the suggested EDNS0 size value (1280 octets). This is in line with RFC3226. I for one would appreciate any comments on this value (too low, too high, breaks everything, ...). It seems to work well from the end points we've tried, but... all the best, Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 18 16:44:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERyKM-0004MQ-EJ; Tue, 18 Oct 2005 16:44:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERyKK-0004Gn-IA for enum@megatron.ietf.org; Tue, 18 Oct 2005 16:44:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14677 for ; Tue, 18 Oct 2005 16:44:44 -0400 (EDT) Received: from smartmx-04.inode.at ([213.229.60.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERyVp-0007no-Ic for enum@ietf.org; Tue, 18 Oct 2005 16:56:52 -0400 Received: from [62.99.233.54] (port=28905 helo=mah9.inode.at) by smartmx-04.inode.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1ERyK1-0003KK-W0; Tue, 18 Oct 2005 22:44:34 +0200 Message-Id: <6.2.5.6.2.20051018223716.05b8bd08@inode.at> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 18 Oct 2005 22:44:34 +0200 To: Alexander Mayrhofer , "Livingood, Jason" From: Michael Haberler Subject: Re: [Enum] ENUM Working Group Last call on IANA Registration for Enumservice Voice In-Reply-To: <435512D6.80801@enum.at> References: <6EEEACD9D7F52940BEE26F5467C02C73FF07D6@PACDCEXCMB01.cable.comcast.com> <435512D6.80801@enum.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-1F9E7C39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: enum@ietf.org, rudolf.brandner@siemens.com, "Conroy, Lawrence \(SMTP\)" , Bernie Hoeneisen , Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org At 17:20 18.10.2005, Alexander Mayrhofer wrote: >I also think that an "Example" section should be mandatory in >Enumservice registrations, probably a "User experience" section as >well? (The "user experience" section is a bit twofold: It could help >achieving a more consistent user experience, but it could also >hinder implementors who use the enumservice in a probably more >innovative way than the author imagined - any comments on such a section?) I would go a step further and suggest a requirement to define the operational semantics of the enumservice interpretation. example: i.e. if you see this URI, these steps are supposed to happen 1).., 2)... 3)... -Michael ps: that's a hint for the folks "defining" enumservices, leaving that part out, and cause headscratching years on end on this and other lists... servus Richard!! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 19 04:45:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES9a8-0006P5-TE; Wed, 19 Oct 2005 04:45:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES9a6-0006J1-Kl for enum@megatron.ietf.org; Wed, 19 Oct 2005 04:45:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00291 for ; Wed, 19 Oct 2005 04:45:46 -0400 (EDT) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES9ln-0003sk-5I for enum@ietf.org; Wed, 19 Oct 2005 04:58:00 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j9J8jnmO013295; Wed, 19 Oct 2005 10:45:50 +0200 Received: from mail3.siemens.de (localhost [127.0.0.1]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j9J8jnXG003154; Wed, 19 Oct 2005 10:45:49 +0200 Received: from mhpahx0c.ww002.siemens.net (mhpahx0c.ww002.siemens.net [139.25.165.42]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j9J8jmX0003130; Wed, 19 Oct 2005 10:45:48 +0200 Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by mhpahx0c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 10:45:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] ENUM Working Group Last call on IANA Registration for Enumservice Voice Date: Wed, 19 Oct 2005 10:45:47 +0200 Message-ID: <861E081CFA823A47B92BA4E1E1B92C2E5A3521@MCHP7R5A.ww002.siemens.net> Thread-Topic: [Enum] ENUM Working Group Last call on IANA Registration for Enumservice Voice Thread-Index: AcW6FIoPxWjOy6v7QzGqPvgADurNIAW5F1BAAOMf6ZA= From: "Brandner, Rudolf" To: "Livingood, Jason" X-OriginalArrivalTime: 19 Oct 2005 08:45:48.0384 (UTC) FILETIME=[80A51E00:01C5D489] X-Spam-Score: 0.8 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, Stastny Richard , "Conroy, Lawrence \(SMTP\)" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Many thanks for your comment on an examples section in this I-D. Adding this section seems to me a non-editorial change and might trigger a full circle. Therefore, if needed, we could add this section during IESG processing to avoid further delay. I would like to note that the original I-D came into ENUM WG almost 3 years ago, so it took a little while to get to WG LC. Since it came in the typical layout for the Enumservice Registration was changed. IMHO, there seems little point in changing the original layout and delay it further more. And that was not the intention of your comment, as I read it. Many thanks, Rudi > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Friday, October 14, 2005 10:12 PM > To: enum@ietf.org > Cc: Brandner, Rudolf; Stastny Richard; Conroy, Lawrence (SMTP) > Subject: RE: [Enum] ENUM Working Group Last call on IANA=20 > Registration for Enumservice Voice >=20 > > This draft is sufficiently easy to understand that this can=20 > > proceed immediately to last call as we discussed in Paris. >=20 > Not to throw a wrench into the process, but can the authors please > insert an examples section into the I-D? (Such as in RFC=20 > 3953, section > 5, or draft-ietf-enum-void-01, section 6.) I find these very=20 > useful and > it can often foster better / more efficient discussion about the > application intended by drafts in general. >=20 > I also find the ENUM service registration format from RFC=20 > 3953 (also RFC > 3764, RFC 4002, draft-ietf-enum-void-01, draft-ietf-enum-msg-05, etc.) > to be a good guide as well (copied text below from RFC 3953). It is > useful if all of the ENUMservice registrations follow a (somewhat) > uniform document format so that they may be more easily referenced by > developers and people deploying ENUM-enabled services/technology. >=20 > ENUM Service Registration >=20 > As defined in [1], the following is a template covering > information > needed for the registration of the enumservice specified in this > document: >=20 > Service name: "E2U+pres" >=20 > URI scheme(s): "pres:" >=20 > Functional Specification: See section 4. >=20 > Security considerations: See section 6. >=20 > Intended usage: COMMON >=20 > Author: Jon Peterson (jon.peterson@neustar.biz) >=20 > Any other information that the author deems interesting: See > section 3. >=20 > Just my feedback, take it or leave it. :-) >=20 > Thanks > Jason Livingood > =20 > > I've noted no substantive issues with it. > >=20 > > Title : IANA Registration for Enumservice Voice > > Author(s) : R. Brandner > > Filename : draft-ietf-enum-voice-00.txt > > Pages : 13 > > Date : 2005-9-12 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 19 07:16:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESBvN-0003ah-CE; Wed, 19 Oct 2005 07:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESBvM-0003aZ-0L for enum@megatron.ietf.org; Wed, 19 Oct 2005 07:16:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07751 for ; Wed, 19 Oct 2005 07:15:51 -0400 (EDT) Message-Id: <200510191115.HAA07751@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESC74-0007tm-0Z for enum@ietf.org; Wed, 19 Oct 2005 07:28:07 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ESBvH-0000Ns-Do; Wed, 19 Oct 2005 11:15:55 +0000 To: "Brandner, Rudolf" Subject: Re: [Enum] ENUM Working Group Last call on IANA Registration for Enumservice Voice Date: Wed, 19 Oct 2005 04:15:55 -0700 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi, Actually I'm glad this came up: I also think it is better to follow the standard format for the Enumservices at this time (as my AD review) because this makes it a one-step process for IANA to enter the document in the registry, which is very important for IANA delay. (IANA should not have to do too much protocol-specific analysis - there are hundreds of protocols). If you'll revise by the deadline, we can IETF Last Call after that. Allison _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 19 08:31:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESD6h-0003MC-Nw; Wed, 19 Oct 2005 08:31:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESD6f-0003M7-Vd for enum@megatron.ietf.org; Wed, 19 Oct 2005 08:31:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12945 for ; Wed, 19 Oct 2005 08:31:36 -0400 (EDT) Received: from sheridan.swishmail.com ([209.10.110.74] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESDIP-0001u8-BH for enum@ietf.org; Wed, 19 Oct 2005 08:43:54 -0400 Received: (qmail 86467 invoked by uid 89); 19 Oct 2005 12:31:28 -0000 Received: from unknown (HELO dranalli2) (65.203.166.40) by sheridan.swishmail.com with SMTP; 19 Oct 2005 12:31:26 -0000 From: "Douglas Ranalli" To: "'Richard Shockey'" , Subject: RE: [Enum] [Fwd: I-D submission: draft-lind-infrastructure-enum-reqs-01] Date: Wed, 19 Oct 2005 08:31:25 -0400 Organization: NetNumber, Inc. Message-ID: <001301c5d4a9$0628b5e0$28a6cb41@netnumber.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <435534CD.5040309@shockey.us> Importance: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dranalli@netnumber.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Penn and Steve, Nice work on this first draft of Carrier-ENUM requirements. One comment regarding scope of the solution. Section 1.1 "Definition" defines Infrastructure-ENUM as a service that returns a single URI identifying a point of interconnection. Consider broadening the scope of the first sentence of section 1.1 as follows: "...to map a telephone number into one or more URIs that identify protocol or service specific points of interconnection..." Doug -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, October 18, 2005 12:46 PM To: 'enum@ietf.org' Subject: [Enum] [Fwd: I-D submission: draft-lind-infrastructure-enum-reqs-01] ENUM S. Lind Internet-Draft AT&T Labs Expires: April 22, 2006 P. Pfautz AT&T October 18, 2005 Carrier/Infrastructure ENUM Requirements draft-lind-infrastructure-enum-reqs-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 22, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document provides requirements for "infrastructure" or "carrier" ENUM, defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP. Lind & Pfautz Expires April 22, 2006 [Page 1] Internet-Draft Carrier ENUM Requirements October 2005 Conventions used in this document RFC2119 [1] provides the interpretations for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. 1. Infrastructure ENUM 1.1. Definition Infrastructure ENUM is defined as the use of the technology in RFC3761 [2] by the carrier-of-record for a specific E.164 number [3] to map a telephone number into a URI that identifies a specific point of interconnection to that service provider's network that could enable the originating party to establish communication with the associated terminating party. It is separate from any URIs that the end-user, who registers their E.164 number, may wish to associate with that E.164 number. For purposes of this document, "Carrier of Record" refers to the entity that provides PSTN service for an E.164 number with the understanding that this definition is ultimately a matter for national authorities to determine. 1.2. Background Carriers use E.164 numbers currently as their main naming and routing vehicle. Carrier ENUM in e164.arpa or another publicly available tree allows Carriers to link Internet based resources such as URIs to E.164 numbers (Note: this is the other way round then User ENUM). This allows Carrier in addition to interconnecting via the PSTN (or exclusively) to peer via IP-based protocols. Carriers may announce all E.164 numbers or number ranges they host, regardless if the final end-user device is on the Internet, on IP-based closed NGNs or on the PSTN, provided an access (e.g. SBC or gateway) to the destination carriers network is available on the Internet. There is also no guarantee that the originating carrier querying Carrier ENUM is able to access the ingress network element of the destination carriers network. Additional peering and accounting agreements requiring authentication may be necessary. The access provided may also be to a shared network of a group of carriers, resolving the final destination network within the shared network. 2. Requirements for Infrastructure ENUM Lind & Pfautz Expires April 22, 2006 [Page 2] Internet-Draft Carrier ENUM Requirements October 2005 2.1. Infrastructure ENUM SHALL provide a means for a carrier to populate DNS RRs in a common publicly accessible namespace for the E.164 numbering resources for which it is the carrier-of-record. 2.2. Queries of infrastructure ENUM FQDNs MUST return a result, even if the result is NXDOMAIN. Queries must not be rejected, e.g. based on ACLs. 2.3. Infrastructure ENUM SHALL support RRs providing a URI that can identify a point of interconnection for delivery of communications addressed to the E.164 number. 2.4. Infrastructure ENUM SHALL support an IRIS capability that allows qualified parties to obtain information regarding the E.164 numbering resources and the corresponding carrier-of-record. 2.5. Implementation of Infrastructure ENUM MUST NOT restrict the ability of an end-user, in a competitive environment, to choose a Registrar and/or Tier 2 name server provider for end-user ENUM registrations. 2.6. Infrastructure ENUM SHALL be implemented under a TLD that can support reliability and performance suitable for PSTN applications. 2.7. Infrastructure ENUM MUST meet all reasonable privacy concerns about visibility of information an end user has no control over, for example discovery of unlisted numbers, or inadvertent disclosure of user identity. 2.8. Proposed implementations of Infrastructure ENUM SHOULD a. Minimize changes required to existing requirements that are part of RFC 3761 Lind & Pfautz Expires April 22, 2006 [Page 3] Internet-Draft Carrier ENUM Requirements October 2005 b. Work with open numbering plans c. Restrict additional functionality to carrier resolvers. d. Minimize the number of lookups required to obtain as many NAPTR records (end-user and carrier) as possible. e. Minimize the client knowledge of the numbering plan required. f. Maximize synergies with end-user ENUM g. Support interworking with private ENUM trees. 3. Security Considerations Existing security considerations for ENUM detailed in [2] still apply. Note that some registration validation issues concerning end user ENUM may not apply to carrier ENUM. Where the Tier 1 registry is able to identify the carrier serving a number e.g., based on industry data for number block assignments and number portability, registration might be more easily automated and a separate registrar not required. Some parties have expressed concern that a carrier ENUM could compromise end user privacy by making it possible for others to identify unlisted or unpublished numbers based on their registration in ENUM. This can be avoided if carriers register all of the their allocated (as opposed to assigned) numbers. Unassigned numbers should be provisioned to route to the carrier's network in the same fashion as assigned numbers and only then provide an indication that they are unassigned. In that way, carrier registration of a number in ENUM provides no more information about status of a number than could be obtained by dialing it. 4. IANA Considerations IANA considerations will depend on the architecture ultimately chosen to meet the requirements. 5. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Lind & Pfautz Expires April 22, 2006 [Page 4] Internet-Draft Carrier ENUM Requirements October 2005 Application (ENUM)", RFC 3761, April 2004. [3] International Telecommunications Union-T, "The International Public Telecommunication Number Plan", Recommendation E.164", May 1997. Lind & Pfautz Expires April 22, 2006 [Page 5] Internet-Draft Carrier ENUM Requirements October 2005 Authors' Addresses Steven Lind AT&T Labs 180 Park Ave Florham Park, NJ 07932-0971 USA Email: slind@att.com Penn Pfautz AT&T 200 S. Laurel Ave Middletown, NJ 07748 USA Email: ppfautz@att.com Lind & Pfautz Expires April 22, 2006 [Page 6] Internet-Draft Carrier ENUM Requirements October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lind & Pfautz Expires April 22, 2006 [Page 7] -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 19 08:41:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDGH-0007eV-RL; Wed, 19 Oct 2005 08:41:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDGG-0007d9-BF for enum@megatron.ietf.org; Wed, 19 Oct 2005 08:41:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13342 for ; Wed, 19 Oct 2005 08:41:30 -0400 (EDT) Received: from mail126.messagelabs.com ([216.82.254.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESDRx-00027F-0y for enum@ietf.org; Wed, 19 Oct 2005 08:53:48 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-5.tower-126.messagelabs.com!1129725686!8694660!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 4000 invoked from network); 19 Oct 2005 12:41:26 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-5.tower-126.messagelabs.com with SMTP; 19 Oct 2005 12:41:26 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 4355D4090003D7B7; Wed, 19 Oct 2005 08:41:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] [Fwd: I-D submission:draft-lind-infrastructure-enum-reqs-01] Date: Wed, 19 Oct 2005 08:40:44 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0B57A012@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Enum] [Fwd: I-D submission:draft-lind-infrastructure-enum-reqs-01] Thread-Index: AcXUqUyYZFbbOYc8RVSGPOdzUXDJOgAAK+bw From: "Pfautz, Penn L, NEO" To: , "Richard Shockey" , X-Spam-Score: 0.8 (/) X-Scan-Signature: 6a817af60e4281a101681ecb646dffff Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Doug: Thanks. Your point is a good one; we did not intend to imply a single URI for all services or protocols but I see upon reflection our language might be taken in that way. Penn=20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Douglas Ranalli Sent: Wednesday, October 19, 2005 8:31 AM To: 'Richard Shockey'; enum@ietf.org Subject: RE: [Enum] [Fwd: I-D submission:draft-lind-infrastructure-enum-reqs-01] Penn and Steve, Nice work on this first draft of Carrier-ENUM requirements. One comment regarding scope of the solution. Section 1.1 "Definition" defines Infrastructure-ENUM as a service that returns a single URI identifying a point of interconnection. Consider broadening the scope of the first sentence of section 1.1 as follows:=20 "...to map a telephone number into one or more URIs that identify protocol or service specific points of interconnection..."=20 Doug -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, October 18, 2005 12:46 PM To: 'enum@ietf.org' Subject: [Enum] [Fwd: I-D submission: draft-lind-infrastructure-enum-reqs-01] ENUM S. Lind Internet-Draft AT&T Labs Expires: April 22, 2006 P. Pfautz =20 AT&T October 18, 2005 Carrier/Infrastructure ENUM Requirements draft-lind-infrastructure-enum-reqs-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 22, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document provides requirements for "infrastructure" or "carrier" ENUM, defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP. Lind & Pfautz Expires April 22, 2006 [Page 1] Internet-Draft Carrier ENUM Requirements October 2005 Conventions used in this document RFC2119 [1] provides the interpretations for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. 1. Infrastructure ENUM 1.1. Definition Infrastructure ENUM is defined as the use of the technology in RFC3761 [2] by the carrier-of-record for a specific E.164 number [3] to map a telephone number into a URI that identifies a specific point of interconnection to that service provider's network that could enable the originating party to establish communication with the associated terminating party. It is separate from any URIs that the end-user, who registers their E.164 number, may wish to associate with that E.164 number. For purposes of this document, "Carrier of Record" refers to the entity that provides PSTN service for an E.164 number with the understanding that this definition is ultimately a matter for national authorities to determine. 1.2. Background Carriers use E.164 numbers currently as their main naming and routing vehicle. Carrier ENUM in e164.arpa or another publicly available tree allows Carriers to link Internet based resources such as URIs to E.164 numbers (Note: this is the other way round then User ENUM). This allows Carrier in addition to interconnecting via the PSTN (or exclusively) to peer via IP-based protocols. Carriers may announce all E.164 numbers or number ranges they host, regardless if the final end-user device is on the Internet, on IP-based closed NGNs or on the PSTN, provided an access (e.g. SBC or gateway) to the destination carriers network is available on the Internet. There is also no guarantee that the originating carrier querying Carrier ENUM is able to access the ingress network element of the destination carriers network. Additional peering and accounting agreements requiring authentication may be necessary. The access provided may also be to a shared network of a group of carriers, resolving the final destination network within the shared network. 2. Requirements for Infrastructure ENUM Lind & Pfautz Expires April 22, 2006 [Page 2] Internet-Draft Carrier ENUM Requirements October 2005 2.1. Infrastructure ENUM SHALL provide a means for a carrier to populate DNS RRs in a common publicly accessible namespace for the E.164 numbering resources for which it is the carrier-of-record. 2.2. Queries of infrastructure ENUM FQDNs MUST return a result, even if the result is NXDOMAIN. Queries must not be rejected, e.g. based on ACLs. 2.3. Infrastructure ENUM SHALL support RRs providing a URI that can identify a point of interconnection for delivery of communications addressed to the E.164 number. 2.4. Infrastructure ENUM SHALL support an IRIS capability that allows qualified parties to obtain information regarding the E.164 numbering resources and the corresponding carrier-of-record. 2.5. Implementation of Infrastructure ENUM MUST NOT restrict the ability of an end-user, in a competitive environment, to choose a Registrar and/or Tier 2 name server provider for end-user ENUM registrations. 2.6. Infrastructure ENUM SHALL be implemented under a TLD that can support reliability and performance suitable for PSTN applications. 2.7. Infrastructure ENUM MUST meet all reasonable privacy concerns about visibility of information an end user has no control over, for example discovery of unlisted numbers, or inadvertent disclosure of user identity. 2.8. Proposed implementations of Infrastructure ENUM SHOULD a. Minimize changes required to existing requirements that are part of RFC 3761 Lind & Pfautz Expires April 22, 2006 [Page 3] Internet-Draft Carrier ENUM Requirements October 2005 b. Work with open numbering plans c. Restrict additional functionality to carrier resolvers. d. Minimize the number of lookups required to obtain as many NAPTR records (end-user and carrier) as possible. e. Minimize the client knowledge of the numbering plan required. f. Maximize synergies with end-user ENUM g. Support interworking with private ENUM trees. 3. Security Considerations Existing security considerations for ENUM detailed in [2] still apply. Note that some registration validation issues concerning end user ENUM may not apply to carrier ENUM. Where the Tier 1 registry is able to identify the carrier serving a number e.g., based on industry data for number block assignments and number portability, registration might be more easily automated and a separate registrar not required. Some parties have expressed concern that a carrier ENUM could compromise end user privacy by making it possible for others to identify unlisted or unpublished numbers based on their registration in ENUM. This can be avoided if carriers register all of the their allocated (as opposed to assigned) numbers. Unassigned numbers should be provisioned to route to the carrier's network in the same fashion as assigned numbers and only then provide an indication that they are unassigned. In that way, carrier registration of a number in ENUM provides no more information about status of a number than could be obtained by dialing it. 4. IANA Considerations IANA considerations will depend on the architecture ultimately chosen to meet the requirements. 5. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Lind & Pfautz Expires April 22, 2006 [Page 4] Internet-Draft Carrier ENUM Requirements October 2005 Application (ENUM)", RFC 3761, April 2004. [3] International Telecommunications Union-T, "The International Public Telecommunication Number Plan", Recommendation E.164", May 1997. Lind & Pfautz Expires April 22, 2006 [Page 5] Internet-Draft Carrier ENUM Requirements October 2005 Authors' Addresses Steven Lind AT&T Labs 180 Park Ave Florham Park, NJ 07932-0971 USA Email: slind@att.com Penn Pfautz AT&T 200 S. Laurel Ave Middletown, NJ 07748 USA Email: ppfautz@att.com Lind & Pfautz Expires April 22, 2006 [Page 6] Internet-Draft Carrier ENUM Requirements October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lind & Pfautz Expires April 22, 2006 [Page 7] --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 19 10:00:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESEUk-0001L4-K5; Wed, 19 Oct 2005 10:00:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESEUi-0001Kw-GW for enum@megatron.ietf.org; Wed, 19 Oct 2005 10:00:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19013 for ; Wed, 19 Oct 2005 10:00:30 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESEgS-0004VS-UL for enum@ietf.org; Wed, 19 Oct 2005 10:12:49 -0400 Received: from [10.31.32.123] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9JE11Sl003773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Oct 2005 07:01:02 -0700 Message-ID: <43565170.5040007@shockey.us> Date: Wed, 19 Oct 2005 10:00:16 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6?= =?ISO-8859-1?Q?m?= , Allison Mankin , "Peterson, Jon" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] Pretty much Final WG Charter Revision X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The chairs have consulted with the AD's on the recharter effort and we've agreed on the following text. This should go before the IESG shortly. ################### The ENUM working group has defined a DNS-based architecture and protocol [RFC 3761] by which an E.164 number, as defined in ITU Recommendation E.164, can be expressed as a Fully Qualified Domain Name in a specific Internet Infrastructure domain defined for this purpose (e164.arpa). Background: E.164 numbers are globally unique, language independent identifiers for resources on Public Telecommunication Networks that can support many different services and protocols. There is an emerging desire for network operators to utilize aspects of RFC 3761 to discover points of interconnection necessary to terminate communications sessions identified by a E164 number,in addition to identifying end point protocols and services. Working Group Revised Goals and Scope: 1. The working group will update RFC 3761 and advance to Draft Standard. 2. The working group will examine and document the use of RFC 3761 to facilitate network interconnection for services using E.164 addressing. The working group will coordinate its activities with other IETF working groups, existing or to be chartered, that are investigating elements of peering and or interconnection for VoIP or other services that typically use E.164 addressing. 3. The working group will continue examine and document various aspects of ENUM administrative and /or operational procedures irrespective of whether e164.arpa domain is used. 4. The working group will also examine the use of RFC 3761 technology for storing and delivering other information about services addressed by E.164 numbers, for example PSTN call routing and signaling data. 5. The Working Group will continue to maintain appropriate contact and liaison with other standards bodies and groups, specifically ITU-T SG2, to provide technical or educational information and address, as needed, issues related to the use of the E.164 numbering plan for services on IP networks. In addition the Working Group will continue to encourage the exchange of technical information within the emerging global ENUM community as well as documentation on practical experiences with implementations, alternate technology uses and the administration and provisioning of RFC 3761. 6. As described in RFC 3761, the IETF documents and registers the Enumservices. While extant, it is the ENUM working group that performs the technical review and development of the Enumservices for the Internet community. The working group determines whether to advance them and how to progress them technically. Coordination with other WGs will be taken into account on these. Other than Enumservices, all proposed deliverables of the working group will be discussed with and approved by the Area Directors, who may require wider review due to the broad impact of the subject. Goals and Milestones March 06 Enumservice Registration for Local Number Portability and Related Data as a Proposed Standard April 06 Requirements for Carrier Interconnection using ENUM as an Informational June 06 Carrier Interconnection using ENUM as a Proposed Standard July 06 ENUM Privacy and Security Considerations as an Informational August 06 Advancement of RFC 3761 to Draft Standard -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 19 11:59:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESGLv-0000aV-JW; Wed, 19 Oct 2005 11:59:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESGLs-0000aQ-3x for enum@megatron.ietf.org; Wed, 19 Oct 2005 11:59:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24836 for ; Wed, 19 Oct 2005 11:59:31 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESGXd-0007hd-AI for enum@ietf.org; Wed, 19 Oct 2005 12:11:50 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Oct 2005 08:59:30 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,231,1125903600"; d="scan'208"; a="13482663:sNHT28100314" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9JFx2F8020479; Wed, 19 Oct 2005 11:59:28 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 11:59:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] [Fwd: I-Dsubmission:draft-lind-infrastructure-enum-reqs-01] Date: Wed, 19 Oct 2005 11:59:26 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3AE6148@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] [Fwd: I-Dsubmission:draft-lind-infrastructure-enum-reqs-01] Thread-Index: AcXUqUyYZFbbOYc8RVSGPOdzUXDJOgAAK+bwAAbskzA= From: "Michael Hammer \(mhammer\)" To: "Pfautz, Penn L, NEO" , , "Richard Shockey" , X-OriginalArrivalTime: 19 Oct 2005 15:59:27.0607 (UTC) FILETIME=[154F7870:01C5D4C6] X-Spam-Score: 0.8 (/) X-Scan-Signature: 6f51ba5266426a53fc06c7d32a3c18b6 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Penn, Good draft. I think you can drop the parenthetical (Note:..) in section 1.2. I couldn't figure out what it means, but don't think it is important. Mike=20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Pfautz, Penn L, NEO > Sent: Wednesday, October 19, 2005 8:41 AM > To: dranalli@netnumber.com; Richard Shockey; enum@ietf.org > Subject: RE: [Enum] [Fwd:=20 > I-Dsubmission:draft-lind-infrastructure-enum-reqs-01] >=20 > Doug: > Thanks. Your point is a good one; we did not intend to imply=20 > a single URI for all services or protocols but I see upon=20 > reflection our language might be taken in that way. >=20 >=20 > Penn=20 >=20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Douglas Ranalli > Sent: Wednesday, October 19, 2005 8:31 AM > To: 'Richard Shockey'; enum@ietf.org > Subject: RE: [Enum] [Fwd: I-D > submission:draft-lind-infrastructure-enum-reqs-01] >=20 > Penn and Steve, >=20 > Nice work on this first draft of Carrier-ENUM requirements. =20 > One comment regarding scope of the solution. Section 1.1=20 > "Definition" defines Infrastructure-ENUM as a service that=20 > returns a single URI identifying a point of interconnection. =20 > Consider broadening the scope of the first sentence of=20 > section 1.1 as follows:=20 >=20 > "...to map a telephone number into one or more URIs that=20 > identify protocol or service specific points of interconnection..."=20 >=20 > Doug >=20 >=20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Richard Shockey > Sent: Tuesday, October 18, 2005 12:46 PM > To: 'enum@ietf.org' > Subject: [Enum] [Fwd: I-D submission: > draft-lind-infrastructure-enum-reqs-01] >=20 >=20 > ENUM =20 > S. Lind > Internet-Draft =20 > AT&T Labs > Expires: April 22, 2006 =20 > P. Pfautz > =20 > AT&T > October 18, > 2005 >=20 >=20 > Carrier/Infrastructure ENUM Requirements > draft-lind-infrastructure-enum-reqs-01 >=20 > Status of this Memo >=20 > This document is an Internet-Draft and is subject to all=20 > provisions > of Section 3 of RFC 3667. By submitting this Internet-Draft, each > author represents that any applicable patent or other IPR=20 > claims of > which he or she is aware have been or will be disclosed,=20 > and any of > which he or she becomes aware will be disclosed, in=20 > accordance with > Section 6 of BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. >=20 > Internet-Drafts are draft documents valid for a maximum=20 > of six months > and may be updated, replaced, or obsoleted by other=20 > documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. >=20 > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. >=20 > This Internet-Draft will expire on April 22, 2006. >=20 > Copyright Notice >=20 > Copyright (C) The Internet Society (2005). >=20 > Abstract >=20 > This document provides requirements for "infrastructure"=20 > or "carrier" > ENUM, defined as the use of RFC 3761 technology to facilitate > interconnection of networks for E.164 number addressed=20 > services, in > particular but not restricted to VoIP. >=20 >=20 >=20 >=20 > Lind & Pfautz Expires April 22, 2006 =20 > [Page 1] >=20 > Internet-Draft Carrier ENUM Requirements =20 > October 2005 >=20 >=20 > Conventions used in this document >=20 > RFC2119 [1] provides the interpretations for the key words "MUST", > "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",=20 > "SHOULD NOT", > "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. >=20 >=20 > 1. Infrastructure ENUM >=20 > 1.1. Definition >=20 > Infrastructure ENUM is defined as the use of the technology in > RFC3761 [2] by the carrier-of-record for a specific E.164=20 > number [3] > to map a telephone number into a URI that identifies a=20 > specific point > of interconnection to that service provider's network that could > enable the originating party to establish communication with the > associated terminating party. It is separate from any=20 > URIs that the > end-user, who registers their E.164 number, may wish to associate > with that E.164 number. >=20 > For purposes of this document, "Carrier of Record" refers to the > entity that provides PSTN service for an E.164 number with the > understanding that this definition is ultimately a matter for > national authorities to determine. >=20 > 1.2. Background >=20 > Carriers use E.164 numbers currently as their main naming=20 > and routing > vehicle. Carrier ENUM in e164.arpa or another publicly available > tree allows Carriers to link Internet based resources=20 > such as URIs to > E.164 numbers (Note: this is the other way round then User ENUM). > This allows Carrier in addition to interconnecting via=20 > the PSTN (or > exclusively) to peer via IP-based protocols. Carriers=20 > may announce > all E.164 numbers or number ranges they host, regardless=20 > if the final > end-user device is on the Internet, on IP-based closed=20 > NGNs or on the > PSTN, provided an access (e.g. SBC or gateway) to the destination > carriers network is available on the Internet. There is also no > guarantee that the originating carrier querying Carrier=20 > ENUM is able > to access the ingress network element of the destination carriers > network. Additional peering and accounting agreements requiring > authentication may be necessary. The access provided may=20 > also be to > a shared network of a group of carriers, resolving the final > destination network within the shared network. >=20 >=20 > 2. Requirements for Infrastructure ENUM >=20 >=20 >=20 >=20 >=20 > Lind & Pfautz Expires April 22, 2006 =20 > [Page 2] >=20 > Internet-Draft Carrier ENUM Requirements =20 > October 2005 >=20 >=20 > 2.1. >=20 > Infrastructure ENUM SHALL provide a means for a carrier=20 > to populate > DNS RRs in a common publicly accessible namespace for the E.164 > numbering resources for which it is the carrier-of-record. >=20 > 2.2. >=20 > Queries of infrastructure ENUM FQDNs MUST return a result, even if > the result is NXDOMAIN. Queries must not be rejected,=20 > e.g. based on > ACLs. >=20 > 2.3. >=20 > Infrastructure ENUM SHALL support RRs providing a URI that can > identify a point of interconnection for delivery of communications > addressed to the E.164 number. >=20 > 2.4. >=20 > Infrastructure ENUM SHALL support an IRIS capability that allows > qualified parties to obtain information regarding the=20 > E.164 numbering > resources and the corresponding carrier-of-record. >=20 > 2.5. >=20 > Implementation of Infrastructure ENUM MUST NOT restrict=20 > the ability > of an end-user, in a competitive environment, to choose a=20 > Registrar > and/or Tier 2 name server provider for end-user ENUM=20 > registrations. >=20 > 2.6. >=20 > Infrastructure ENUM SHALL be implemented under a TLD that=20 > can support > reliability and performance suitable for PSTN applications. >=20 > 2.7. >=20 > Infrastructure ENUM MUST meet all reasonable privacy=20 > concerns about > visibility of information an end user has no control over, for > example discovery of unlisted numbers, or inadvertent=20 > disclosure of > user identity. >=20 > 2.8. >=20 > Proposed implementations of Infrastructure ENUM SHOULD >=20 > a. Minimize changes required to existing requirements=20 > that are part > of RFC 3761 >=20 >=20 >=20 > Lind & Pfautz Expires April 22, 2006 =20 > [Page 3] >=20 > Internet-Draft Carrier ENUM Requirements =20 > October 2005 >=20 >=20 > b. Work with open numbering plans >=20 > c. Restrict additional functionality to carrier resolvers. >=20 > d. Minimize the number of lookups required to obtain as=20 > many NAPTR > records (end-user and carrier) as possible. >=20 > e. Minimize the client knowledge of the numbering plan required. >=20 > f. Maximize synergies with end-user ENUM >=20 > g. Support interworking with private ENUM trees. >=20 >=20 > 3. Security Considerations >=20 > Existing security considerations for ENUM detailed in [2] still > apply. Note that some registration validation issues=20 > concerning end > user ENUM may not apply to carrier ENUM. Where the Tier=20 > 1 registry > is able to identify the carrier serving a number e.g., based on > industry data for number block assignments and number portability, > registration might be more easily automated and a=20 > separate registrar > not required. >=20 > Some parties have expressed concern that a carrier ENUM could > compromise end user privacy by making it possible for others to > identify unlisted or unpublished numbers based on their=20 > registration > in ENUM. This can be avoided if carriers register all of=20 > the their > allocated (as opposed to assigned) numbers. Unassigned numbers > should be provisioned to route to the carrier's network=20 > in the same > fashion as assigned numbers and only then provide an=20 > indication that > they are unassigned. In that way, carrier registration=20 > of a number > in ENUM provides no more information about status of a number than > could be obtained by dialing it. >=20 >=20 > 4. IANA Considerations >=20 > IANA considerations will depend on the architecture=20 > ultimately chosen > to meet the requirements. >=20 > 5. Normative References >=20 > [1] Bradner, S., "Key words for use in RFCs to Indicate=20 > Requirement > Levels", BCP 14, RFC 2119, March 1997. >=20 > [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource > Identifiers (URI) Dynamic Delegation Discovery System (DDDS) >=20 >=20 >=20 > Lind & Pfautz Expires April 22, 2006 =20 > [Page 4] >=20 > Internet-Draft Carrier ENUM Requirements =20 > October 2005 >=20 >=20 > Application (ENUM)", RFC 3761, April 2004. >=20 > [3] International Telecommunications Union-T, "The International > Public Telecommunication Number Plan", Recommendation E.164", > May 1997. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Lind & Pfautz Expires April 22, 2006 =20 > [Page 5] >=20 > Internet-Draft Carrier ENUM Requirements =20 > October 2005 >=20 >=20 > Authors' Addresses >=20 > Steven Lind > AT&T Labs > 180 Park Ave > Florham Park, NJ 07932-0971 > USA >=20 > Email: slind@att.com >=20 >=20 > Penn Pfautz > AT&T > 200 S. Laurel Ave > Middletown, NJ 07748 > USA >=20 > Email: ppfautz@att.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Lind & Pfautz Expires April 22, 2006 =20 > [Page 6] >=20 > Internet-Draft Carrier ENUM Requirements =20 > October 2005 >=20 >=20 > Intellectual Property Statement >=20 > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might=20 > be claimed to > pertain to the implementation or use of the technology=20 > described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. > Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. >=20 > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission=20 > for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR=20 > repository at > http://www.ietf.org/ipr. >=20 > The IETF invites any interested party to bring to its=20 > attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. >=20 >=20 > Disclaimer of Validity >=20 > This document and the information contained herein are=20 > provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION=20 > HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=20 > OR IMPLIED, > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. >=20 >=20 > Copyright Statement >=20 > Copyright (C) The Internet Society (2005). This document=20 > is subject > to the rights, licenses and restrictions contained in BCP 78, and > except as set forth therein, the authors retain all their rights. >=20 >=20 > Acknowledgment >=20 > Funding for the RFC Editor function is currently provided by the > Internet Society. >=20 >=20 >=20 >=20 > Lind & Pfautz Expires April 22, 2006 =20 > [Page 7] >=20 >=20 > --=20 >=20 >=20 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Director - Member of Technical Staff NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 > Fax: +1 815.333.1237 > or > > ; =20 > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 19 16:01:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESK80-0006RF-0B; Wed, 19 Oct 2005 16:01:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESK7x-0006Qj-MB for enum@megatron.ietf.org; Wed, 19 Oct 2005 16:01:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11620 for ; Wed, 19 Oct 2005 16:01:22 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESKJj-0007YV-2E for enum@ietf.org; Wed, 19 Oct 2005 16:13:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Oct 2005 22:04:47 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C45FF@oefeg-s04.oefeg.loc> Thread-Topic: Comments on draft-meyer-voipeer-terminology-00.txt Thread-Index: AcXRB3ODVLbhazncScWxF/XFNpktLQD4CxKu From: "Stastny Richard" To: "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org Subject: [Enum] Comments on draft-meyer-voipeer-terminology-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi all, =20 I am posting this on both the enum and the voipeer list, because there are some interdependencies in this draft. =20 ad Figure 1 =20 I consider this figure very important and I suggest to draw a line = above: =20 SIP URI <--- Call Routing Data (CRD) =20 This line indicates the scope boundary between ENUM WG and voipeer. =20 The main task of ENUM is to deliver a SIP URI that can be used as Call Routing Data as defined in 3.1 =20 How to deal with this call routing data is the task of voipeer. =20 Therefore I suggest to change the text below the figure from: =20 Note that voipeer is primarily concerned with the acquisition and use of the Call Routing Data (CRD) shown in in Figure 1. Importantly, the CRD can be derived from an E.164 entry, as shown in Figure 1, or via any other mechanism available to the user. =20 to =20 Note that ENUM is primarily concerned with the acquisition and=20 voipeer primarily with the use of the Call Routing Data (CRD) shown in in Figure 1. Importantly, the CRD can be derived from an E.164 entry in ENUM, as shown in = Figure 1, or via any other mechanism available to the user. ad 3.1. Call Routing Data (CRD) Call Routing Data, or CRD, is a SIP URI used to route a (real-time, voice or other type) call to its termination point. [ed: do we need a definition of "termination point"?] =20 yes and no: =20 I propose to change the text to: Call Routing Data, or CRD, is a SIP URI used to route a (real-time, voice or other type) call to the destination network, where network is defined in 3.4 =20 ad 3.4. Network For purposes of this document and the voipeer work, a network is defined to be the set of SIP servers and customers that are controlled by a single administration.=20 =20 change to: For purposes of this document and the voipeer and ENUM work, a=20 network is defined to be the set of SIP servers and end-users (customers) that are controlled by a single administrative domain. The network may also contain end-users on the PSTN. =20 ad 3.6 Carrier (of Record) =20 The definition of a carrier is irrelevant for voipeer, voipeer is only dealing with L5 peering between VoIP Service providers as defined in 3.5 so either the definition is deleted or the definition of ENUM in draft-lind-infrastructure-enum-reqs-01 is used: =20 For purposes of this document, "Carrier of Record" refers to the entity that provides PSTN service for an E.164 number with the understanding that this definition is ultimately a matter for national authorities to determine. =20 Proposal: =20 4.1 User ENUM =20 In User ENUM the end-user having the right to use the E.164 number in question is responsible for the data entered in the corresponding domain within e164.arpa The end user hosted within a VoIP service providers network may enter CRD (a SIP URI) given to him by this VoIP=20 service provider. =20 Another VoIP service provider or end-user may query User ENUM=20 and use the retrieved CDR to route calls to the VoIP service providers network of the first user. =20 4.2 Carrier ENUM =20 In carrier ENUM only Carrier of Records as defined in 3.6=20 (or ENUM) may enter data in the corresponding domain within tbd.=20 The Carrier of Record may enter may enter CRD (a SIP URI)=20 to allow other VoIP Service Providers to route calls to his network as defined within voipeer. =20 Note: ENUM may also contain other data beyond the CRD as defined in voipeer. This is out of scope for voipeer. This is especially true for data containing tel URIs. Tel URis are used to interconnect with the PSTN directly and are out of scope of voipeer. Endpoints on the PSTN served by a Carrier of Record and reachable via CDR and networks as defined in 3.4 are NOT out of scope. best regards Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von David Meyer Gesendet: Fr 14.10.2005 23:30 An: voipeer@lists.uoregon.edu Cc: enum@ietf.org; sipping@ietf.org Betreff: [Enum] "straw-person" terminology draft posted Folks, I just posted draft-meyer-voipeer-terminology-00.txt. Please consider this a straw{man,woman,person} draft; I wanted to get something onto the I-D repository before the -00 cutoff, and so we'd have some canon fodder :-) Have a good weekend all, Dave _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 19 18:14:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESMCX-0005hj-VB; Wed, 19 Oct 2005 18:14:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESMCV-0005fw-P3 for enum@megatron.ietf.org; Wed, 19 Oct 2005 18:14:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08061 for ; Wed, 19 Oct 2005 18:14:14 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESMOK-0001N5-GP for enum@ietf.org; Wed, 19 Oct 2005 18:26:36 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9JMEEd9010938; Wed, 19 Oct 2005 15:14:14 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9JMEDrj010937; Wed, 19 Oct 2005 15:14:13 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 19 Oct 2005 15:14:13 -0700 From: David Meyer To: Stastny Richard Message-ID: <20051019221413.GA10929@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D462C45FF@oefeg-s04.oefeg.loc> Mime-Version: 1.0 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C45FF@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: enum@ietf.org, voipeer@lists.uoregon.edu Subject: [Enum] Re: Comments on draft-meyer-voipeer-terminology-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1098295955==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1098295955== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 19, 2005 at 10:04:47PM +0200, Stastny Richard wrote: > Hi all, > =20 > I am posting this on both the enum and the voipeer list, because there > are some interdependencies in this draft. > =20 > ad Figure 1 > =20 > I consider this figure very important and I suggest to draw a line above: > =20 > SIP URI <--- Call Routing Data (CRD) > =20 > This line indicates the scope boundary between ENUM WG and voipeer. Good point. I'll try to make that clear. > The main task of ENUM is to deliver a SIP URI that > can be used as Call Routing Data as defined in 3.1 > =20 > How to deal with this call routing data is the task of voipeer. > =20 > Therefore I suggest to change the text below the figure from: > =20 > Note that voipeer is primarily concerned with the acquisition and use > of the Call Routing Data (CRD) shown in in Figure 1. Importantly, > the CRD can be derived from an E.164 entry, as shown in Figure 1, or > via any other mechanism available to the user. > =20 > to > =20 > Note that ENUM is primarily concerned with the acquisition and=20 > voipeer primarily with the use > of the Call Routing Data (CRD) shown in in Figure 1. Importantly, > the CRD can be derived from an E.164 entry in ENUM, as shown in Figure= 1, or > via any other mechanism available to the user. Sure. I think we had different meanings of "acquisition", but this is clear. > ad 3.1. Call Routing Data (CRD) > Call Routing Data, or CRD, is a SIP URI used to route a (real-time, > voice or other type) call to its termination point. > [ed: do we need a definition of "termination point"?] > =20 > yes and no: > =20 > I propose to change the text to: > Call Routing Data, or CRD, is a SIP URI used to route a (real-time, > voice or other type) call to the destination network, where network > is defined in 3.4 Sure. > =20 > ad 3.4. Network > For purposes of this document and the voipeer work, a network is > defined to be the set of SIP servers and customers that are > controlled by a single administration.=20 > =20 > change to: > For purposes of this document and the voipeer and ENUM work, a=20 > network is > defined to be the set of SIP servers and end-users (customers) > that are controlled by a single administrative domain. > The network may also contain end-users on the PSTN. Yep. > ad 3.6 Carrier (of Record) > =20 > The definition of a carrier is irrelevant for voipeer, voipeer > is only dealing with L5 peering between VoIP Service providers > as defined in 3.5 so either >=20 > the definition is deleted or the definition of ENUM in > draft-lind-infrastructure-enum-reqs-01 is used: > =20 > For purposes of this document, "Carrier of Record" refers to the > entity that provides PSTN service for an E.164 number with the > understanding that this definition is ultimately a matter for > national authorities to determine. Ok, no problem with that either. > Proposal: > =20 > 4.1 User ENUM > =20 > In User ENUM the end-user having the right to use the > E.164 number in question is responsible for the data > entered in the corresponding domain within e164.arpa > The end user hosted within a VoIP service providers network > may enter CRD (a SIP URI) given to him by this VoIP=20 > service provider. > =20 > Another VoIP service provider or end-user may query User ENUM=20 > and use the retrieved CDR to route calls to the VoIP service > providers network of the first user. > =20 > 4.2 Carrier ENUM > =20 > In carrier ENUM only Carrier of Records as defined in 3.6=20 > (or ENUM) may enter data in the corresponding domain within tbd.=20 > The Carrier of Record may enter may enter CRD (a SIP URI)=20 > to allow other VoIP Service Providers to route calls to his network > as defined within voipeer. > =20 > Note: ENUM may also contain other data beyond the CRD as defined > in voipeer. This is out of scope for voipeer. This is especially true > for data containing tel URIs. Tel URis are used to interconnect > with the PSTN directly and are out of scope of voipeer. Endpoints > on the PSTN served by a Carrier of Record and reachable via CDR > and networks as defined in 3.4 are NOT out of scope. I'll fit this in too.=20 Thanks for the detailed comments, Dave --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDVsU1ORgD1qCZ2KcRAiuUAJ419R3t1g8u7xQHQ/Gag/g8nBmyeQCcD39k 57utWGxnMxqeHKfBsgGgIKM= =8u9g -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- --===============1098295955== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1098295955==-- From enum-bounces@ietf.org Thu Oct 20 13:40:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESeP7-0006nM-E4; Thu, 20 Oct 2005 13:40:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESeP5-0006kt-Qh for enum@megatron.ietf.org; Thu, 20 Oct 2005 13:40:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02565 for ; Thu, 20 Oct 2005 13:40:26 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESeb1-00029j-SV for enum@ietf.org; Thu, 20 Oct 2005 13:52:59 -0400 Received: from [10.31.13.214] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9KHeqkC028356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 10:40:53 -0700 Message-ID: <4357D678.9050408@shockey.us> Date: Thu, 20 Oct 2005 13:40:08 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Lind, Steven D, ALABS" , "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] What is this? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Can you be more specific here 2.2. Queries of infrastructure ENUM FQDNs MUST return a result, even if the result is NXDOMAIN. Queries must not be rejected, e.g. based on ACLs. ALC's ????? -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 20 13:53:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESec0-0004ig-4z; Thu, 20 Oct 2005 13:53:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESeby-0004ib-Pt for enum@megatron.ietf.org; Thu, 20 Oct 2005 13:53:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03390 for ; Thu, 20 Oct 2005 13:53:45 -0400 (EDT) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESenw-0002eB-RU for enum@ietf.org; Thu, 20 Oct 2005 14:06:18 -0400 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j9KHrZd3006388; Thu, 20 Oct 2005 18:53:36 +0100 (BST) In-Reply-To: <4357D678.9050408@shockey.us> References: <4357D678.9050408@shockey.us> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <393B88F0-C62F-430E-9BB7-21F80C4F8944@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] What is this? Date: Thu, 20 Oct 2005 18:53:30 +0100 To: Richard Shockey X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: "Lind, Steven D, ALABS" , "'enum@ietf.org'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Oct 20, 2005, at 18:40, Richard Shockey wrote: > Can you be more specific here > > 2.2. > > Queries of infrastructure ENUM FQDNs MUST return a result, even if > the result is NXDOMAIN. Queries must not be rejected, e.g. > based on > ACLs. > > ALC's ????? Access control lists, I presume. If a query matches an ACL in BIND, the server returns REFUSED rather than answer the query, even if it knows the answer. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 20 14:12:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESetu-0003e0-Hf; Thu, 20 Oct 2005 14:12:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESett-0003cn-Lf for enum@megatron.ietf.org; Thu, 20 Oct 2005 14:12:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04455 for ; Thu, 20 Oct 2005 14:12:15 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESf5r-0003Fd-Uo for enum@ietf.org; Thu, 20 Oct 2005 14:24:49 -0400 Received: from [10.31.13.214] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9KICpN9031960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 11:12:53 -0700 Message-ID: <4357DDFA.4040107@shockey.us> Date: Thu, 20 Oct 2005 14:12:10 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Reid Subject: Re: [Enum] What is this? References: <4357D678.9050408@shockey.us> <393B88F0-C62F-430E-9BB7-21F80C4F8944@rfc1035.com> In-Reply-To: <393B88F0-C62F-430E-9BB7-21F80C4F8944@rfc1035.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: "Lind, Steven D, ALABS" , "'enum@ietf.org'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jim Reid wrote: > On Oct 20, 2005, at 18:40, Richard Shockey wrote: > >> Can you be more specific here >> >> 2.2. >> >> Queries of infrastructure ENUM FQDNs MUST return a result, even if >> the result is NXDOMAIN. Queries must not be rejected, e.g. based on >> ACLs. >> >> ALC's ????? > > > Access control lists, I presume. If a query matches an ACL in BIND, the > server returns REFUSED rather than answer the query, even if it knows > the answer. > Ah thank you ... and folks, in future versions of ID's not just this one please take the time to spell out acronyms at least once in the document so we can try and figure out what people are talking about. Thanks .. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 20 16:22:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgvS-0002n4-EZ; Thu, 20 Oct 2005 16:22:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgvP-0002lr-JC for enum@megatron.ietf.org; Thu, 20 Oct 2005 16:22:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21883 for ; Thu, 20 Oct 2005 16:21:55 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESh7L-0002dX-21 for enum@ietf.org; Thu, 20 Oct 2005 16:34:29 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9KKLqCB007526; Thu, 20 Oct 2005 13:21:52 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9KKLqOP007525; Thu, 20 Oct 2005 13:21:52 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 20 Oct 2005 13:21:52 -0700 From: David Meyer To: voipeer@lists.uoregon.edu Message-ID: <20051020202152.GA7498@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: ea10c7a57c6f5d0512401188e6188235 Cc: enum@ietf.org Subject: [Enum] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0193412955==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0193412955== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks, Here's the latest on this one (posted here as I'm not sure what the secretariat's posting rate is these days). I've included all the comments, AFAICT.=20 There had been another suggestion to "harmonize" with G.8080 terminology, which I am so far resisting (comments on that)?=20 Thanks, Dave --- Network Working Group D. Meyer Internet-Draft October 20, 2005 Expires: April 23, 2006 Terminology for Describing VoIP Peering and Interconnect draft-meyer-voipeer-terminology-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 23, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines the terminology that is to be used by the Voice Over IP Peering and Interconnect Working Group (voipeer), and has as its primary objective to focus the VOIPEER Working Group during its discussions, and when writing requirements, gap analysis and other solutions oriented documents. Meyer Expires April 23, 2006 [Page 1] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. General Definitions . . . . . . . . . . . . . . . . . . . . . 4 3.1. Call Routing Data . . . . . . . . . . . . . . . . . . . . 4 3.2. Call Routing . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Network . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5. VoIP Service Provider . . . . . . . . . . . . . . . . . . 5 3.6. Carrier . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7. Peering . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . . . . . . 6 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . . . . . . 6 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . . . . . . 6 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Carrier of Record . . . . . . . . . . . . . . . . . . . . 6 4.2. Public ENUM . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Private ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Meyer Expires April 23, 2006 [Page 2] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 1. Introduction The term "VoIP Peering" has historically been used to describe a wide variety of aspects pertaining to the interconnection of service provider networks and to the delivery of SIP call termination over those interconnections. The discussion of these interconnections has at times been confused by the fact that the term "peering" is used in various contexts to relate to interconnection at different levels in a protocol stack. VoIP peering focuses on how to identify and route calls at the application layer, and it does not (necessarily) involve the exchange of packet routing data or media sessions. In particular, "layer 5 network" is used here to refer to the interconnection between SIP servers, as opposed to interconnection at the IP layer ("layer 3"). Finally, the terms "peering" and "interconnect" are used interchangeably throughout this document. This document introduces standard terminology for use in characterizing VoIP interconnection. Note however, that while this document is primarily targeted at the VoIP interconnect case, the terminology described here is applicable to those cases in which service providers interconnect using SIP signaling for real-time or quasi-real-time communications. The remainder of this document is organized as follows: Section 2 provides the general context for the VOIPEER Working Group, and Section 3 provides the general definitions for real-time SIP based communication, with focus on the VoIP interconnect case. Section 4 briefly touches on terms from the ENUM Working Group. Finally, Section 5 provides comments on usage. 2. Context Figure 1 depicts the general VoIP interconnect context. In this case, the caller uses an E.164 number [ITU.E164.1991] as the "name" of the called user. Note that this E.164 number is not an address, since at this point we do not have information about where the named endpoint is located. In the case shown here, an E.164 number is used as a key to retrieve a NAPTR recored [RFC3404] from the DNS, which in turn resolved into a SIP URI. Call routing is based on this SIP URI. The call routing step does not depend on the presence of an E.164 number; the SIP URI can be advertised in various other ways, such as on a web page. Finally, note that the subsequent lookup steps, namely, look up of SRV, A, and AAAA records (as well as any routing steps below that) are outside the scope of VOIPEER. Meyer Expires April 23, 2006 [Page 3] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 E.164 number <--- Peer Discovery | | <--- ENUM lookup of NAPTR in DNS | | | ENUM Working Group Scope =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | VOIPEER Working Group Scope | | SIP URI <--- Call Routing Data (CRD) | | <--- Service Location (Lookup of SRV in DNS) | | Hostname <--- VoIP addressing and session establishment | | <---- Lookup of A and AAAA in DNS | Ip address | | <---- Routing protocols, ARP etc | Mac-address Figure 1: VoIP Interconnect Context The ENUM Working Group is primarily concerned with the acquisition of Call Routing Data, or CRD (i.e., above the double line in Figure 1), while the VOIPEER Working Group is focused on the use of such CRD. Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS entry), or via any other mechanism available to the user. 3. General Definitions 3.1. Call Routing Data Call Routing Data, or CRD, is a SIP URI used to route a call (real- time, voice or other type) to the called domain's ingress point. A domain's ingress point can be thought of as the location pointed to by the SRV record that resulted from the resolution of the CRD (i.e., a SIP URI). 3.2. Call Routing Call routing is the set of processes, rules, and CRD used to route a VoIP call to its proper (SIP) destination. More generally, call Meyer Expires April 23, 2006 [Page 4] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 routing can be thought of as the set of processes, rules and CRD which are used to route a real-time session to its termination (ingress) point. 3.3. PSTN The term "PSTN" refers to the Public Switched Telephone Network. In particular, the PSTN refers to the collection of interconnected circuit-switched voice-oriented public telephone networks, both commercial and government-owned. In general, PSTN terminals are addressed using E.164 numbers, noting that various dial-plans (such as emergency services dial-plans) may not directly use E.164 numbers. 3.4. Network For purposes of this document and the VOIPEER and ENUM Working Groups, a network is defined to be the set of SIP servers and end- users (customers) that are controlled by a single administrative domain. The network may also contain end-users who are located on the PSTN. 3.5. VoIP Service Provider A VoIP service provider is an entity that provides transport of SIP signaling (and possibly media streams) to its customers. Such a service provider may additionally be interconnected with other service providers; that is, it may "peer" with other service providers. A VoIP service provider may also interconnect with the PSTN. Note that as soon as a ingress point is advertised via a SRV record, anyone can find that ingress point and hence can send calls there. This is very similar to sending mail to a SMTP server based on the existence of a MX record. 3.6. Carrier The term carrier is defined to be a service provider authorized to issue E.164 numbers [ITU.E164.1991] for the provisioning of PSTN service under the authority of a National Regulatory Authority (NRA). 3.7. Peering While the precise definition of the term "peering" is the subject of some debate, peering in general refers to the negotiation of reciprocal interconnection arrangements, settlement-free or otherwise, between operationally independent service providers. Meyer Expires April 23, 2006 [Page 5] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 This document distinguishes two types of peering, Layer 3 Peering and Layer 5 peering, which are described below. 3.7.1. Layer 3 Peering Layer 3 peering refers to interconnection of two service providers for the purposes of exchanging IP packets. Layer 3 peering is generally agnostic to the IP payload, and is frequently achieved using a routing protocol such as BGP [RFC1771] to exchange the required routing information. 3.7.2. Layer 5 Peering Layer 5 peering refers to interconnection of two service providers for the purposes of SIP signaling. Note that in the layer 5 peering case, there is no intervening network. That is, for purposes of this discussion, there is no such thing as a "Layer 5 Transit Network". 3.8. VoIP Peering VoIP peering is defined to be a layer 5 peering between two VoIP providers for purposes of routing real-time (or quasi-real time) call signaling between their respective customers. Media streams associated with this signaling (if any) are not constrained to follow the same set of paths. 4. ENUM ENUM [RFC3761] defines how the Domain Name System (DNS) can be used for identifying available services connected to one E.164 number. 4.1. Carrier of Record For purposes of this document, "Carrier of Record", or COR, refers to the entity that provides PSTN service for an E.164 number [I-D.lind- infrastructure-enum-reqs]. The exact definition of who and what is a COR is ultimately the responsibility of the relevant national authority. 4.2. Public ENUM Public ENUM is generally defined as the set administrative policies and procedures surrounding the use of the e164.arpa domain for Telephone Number to URI resolution [RFC3966]. Policies and procedures for the registration of telephone numbers within all branches of the e164.arpa tree are Nation State issues by agreement with the IAB and ITU. National Regulatory Authorities have generally Meyer Expires April 23, 2006 [Page 6] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 defined Public ENUM Registrants as the E.164 number holder as opposed to the COR that issued the phone number. 4.3. Private ENUM Private ENUM is generally regarded as one or more technologies (including DNS and SIP Redirect) that service providers or enterprises may use to exchange phone number to URI mappings in a private secure manner. Private ENUM may be used in any mutually agreed upon domain. Records in Private ENUM may be globally visible but in most cases are not visible to the global Internet and are protected using a variety of security technologies such as split-DNS, VPN's or various forms or authentication and authorization. Technical comments on issues surrounding split-DNS can be found in [RFC2826]. 4.4. Carrier ENUM Carrier ENUM is generally regarded as the use of a separate branch the e164.arpa tree, such as 4.4.c.e164.arpa to permit service providers to exchange phone number to URI data in order to find points of interconnection. The current theory of Carrier ENUM is that only the COR for a particular E.164 number is permitted to provision data for that E.164 within that portion of the e164.arpa tree. In carrier ENUM case, only the COR may enter data in the corresponding domain. The COR may also enter CRD (i.e., a SIP URI) to allow other VoIP Service Providers to route calls to its network. Finally, note that ENUM is not constrained to carry only data (CDR) as defined by VOIPEER. In particular, an an important class of CRD, the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are most frequently used to interconnect with the PSTN directly, and are out of scope for VOIPEER. On the other hand, PSTN endpoints served by a COR and reachable via CDR and networks as defined in Section 3.1 and Section 3.4 are in scope for VOIPEER. 5. Conclusions 6. Acknowledgments Many of the definitions were gleaned from detailed discussions on the VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer, Jean-Francois Mule, Richard Shocky, and Richard Stastny made valuable contributions to early revisions of this document. Patrik Faltstrom Meyer Expires April 23, 2006 [Page 7] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 also made many insightful comments to early versions of this draft, and contributed the basis of Figure 1. 7. Security Considerations This document itself introduces no new security considerations. However, it is important to note that VoIP interconnect has a wide variety of security issues that should be considered in documents addressing both protocol and use case analyzes. 8. IANA Considerations This document creates no new requirements on IANA namespaces [RFC2434]. 9. References 9.1. Normative References [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [ITU.E164.1991] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU- T Recommendation E.164, 1991. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. 9.2. Informative References [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2826] Internet Architecture Board, "IAB Technical Comment on the Meyer Expires April 23, 2006 [Page 8] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Unique DNS Root", RFC 2826, May 2000. [I-D.lind-infrastructure-enum-reqs] Lind, S., "Infrastructure ENUM Requirements", draft-lind-infrastructure-enum-reqs-00 (work in progress), July 2005. Meyer Expires April 23, 2006 [Page 9] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Author's Address David Meyer Email: dmm@1-4-5.net Meyer Expires April 23, 2006 [Page 10] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Meyer Expires April 23, 2006 [Page 11] =0C --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDV/xgORgD1qCZ2KcRAuduAJ98qlwsYphDsDmWZmfQv+DaBOwAeACfRBoF IQ3+1uZ4aNL+0MVA6LP+IlQ= =KMYo -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- --===============0193412955== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0193412955==-- From enum-bounces@ietf.org Thu Oct 20 16:52:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EShOt-0005be-H7; Thu, 20 Oct 2005 16:52:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EShOs-0005bJ-1f for enum@megatron.ietf.org; Thu, 20 Oct 2005 16:52:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00905 for ; Thu, 20 Oct 2005 16:52:20 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EShWl-0001oc-PY for enum@ietf.org; Thu, 20 Oct 2005 17:00:45 -0400 Received: from [10.31.13.214] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9KKmkhk018143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Oct 2005 13:48:49 -0700 Message-ID: <43580281.6070702@shockey.us> Date: Thu, 20 Oct 2005 16:48:01 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: multipart/mixed; boundary="------------020002040600080101090707" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: [Enum] [Fwd: I-D ACTION:draft-guy-enumiax-00.txt] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------020002040600080101090707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-guy-enumiax-00.txt Date: Thu, 20 Oct 2005 15:50:02 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IANA Registration for IAX Enumservice Author(s) : E. Guy Filename : draft-guy-enumiax-00.txt Pages : 11 Date : 2005-10-20 This document registers the IAX2 Enumservice using the URI scheme 'iax2:' as per the IANA registration process defined in the ENUM specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-guy-enumiax-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-guy-enumiax-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-guy-enumiax-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --------------020002040600080101090707 Content-Type: Message/External-body; name="draft-guy-enumiax-00.txt" Content-Disposition: inline; filename="draft-guy-enumiax-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-10-20122349.I-D@ietf.org> --------------020002040600080101090707 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------020002040600080101090707 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------020002040600080101090707-- From enum-bounces@ietf.org Thu Oct 20 17:41:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESiAg-0005y3-2I; Thu, 20 Oct 2005 17:41:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESiAe-0005xB-8c for enum@megatron.ietf.org; Thu, 20 Oct 2005 17:41:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14103 for ; Thu, 20 Oct 2005 17:41:44 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESiE1-0005lw-NI for enum@ietf.org; Thu, 20 Oct 2005 17:45:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Oct 2005 23:36:19 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C460F@oefeg-s04.oefeg.loc> Thread-Topic: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXVtvc4gaJjZdnpQcC8u6eUhPOdqgABqFT5 From: "Stastny Richard" To: "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 570a5b81f8c75fea8dcc4c9f6a8a6e54 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org Subject: [Enum] Re: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Dave, =20 I think this now quite a nice document, also useful for the Carrier ENUM = work in ENUM WG =20 There are some minor typos and I think in section 4.2 the reference should be to RFC3761 =20 Just for curiosity: Can anyone out there explain to me what Layer 4 Peering is? =20 cheers Richard ________________________________ Von: owner-voipeer@lists.uoregon.edu im Auftrag von David Meyer Gesendet: Do 20.10.2005 22:21 An: voipeer@lists.uoregon.edu Cc: enum@ietf.org Betreff: [voipeer] draft-meyer-voipeer-terminology-03.txt Folks, Here's the latest on this one (posted here as I'm not sure what the secretariat's posting rate is these days). I've included all the comments, AFAICT. There had been another suggestion to "harmonize" with G.8080 terminology, which I am so far resisting (comments on that)? Thanks, Dave --- Network Working Group D. Meyer Internet-Draft October 20, 2005 Expires: April 23, 2006 Terminology for Describing VoIP Peering and Interconnect draft-meyer-voipeer-terminology-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 23, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines the terminology that is to be used by the Voice Over IP Peering and Interconnect Working Group (voipeer), and has as its primary objective to focus the VOIPEER Working Group during its discussions, and when writing requirements, gap analysis and other solutions oriented documents. Meyer Expires April 23, 2006 [Page 1] Internet-Draft Terminology for Describing VoIP Peering October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. General Definitions . . . . . . . . . . . . . . . . . . . . . 4 3.1. Call Routing Data . . . . . . . . . . . . . . . . . . . . 4 3.2. Call Routing . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Network . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5. VoIP Service Provider . . . . . . . . . . . . . . . . . . 5 3.6. Carrier . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7. Peering . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . . . . . . 6 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . . . . . . 6 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . . . . . . 6 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Carrier of Record . . . . . . . . . . . . . . . . . . . . 6 4.2. Public ENUM . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Private ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Meyer Expires April 23, 2006 [Page 2] Internet-Draft Terminology for Describing VoIP Peering October 2005 1. Introduction The term "VoIP Peering" has historically been used to describe a wide variety of aspects pertaining to the interconnection of service provider networks and to the delivery of SIP call termination over those interconnections. The discussion of these interconnections has at times been confused by the fact that the term "peering" is used in various contexts to relate to interconnection at different levels in a protocol stack. VoIP peering focuses on how to identify and route calls at the application layer, and it does not (necessarily) involve the exchange of packet routing data or media sessions. In particular, "layer 5 network" is used here to refer to the interconnection between SIP servers, as opposed to interconnection at the IP layer ("layer 3"). Finally, the terms "peering" and "interconnect" are used interchangeably throughout this document. This document introduces standard terminology for use in characterizing VoIP interconnection. Note however, that while this document is primarily targeted at the VoIP interconnect case, the terminology described here is applicable to those cases in which service providers interconnect using SIP signaling for real-time or quasi-real-time communications. The remainder of this document is organized as follows: Section 2 provides the general context for the VOIPEER Working Group, and Section 3 provides the general definitions for real-time SIP based communication, with focus on the VoIP interconnect case. Section 4 briefly touches on terms from the ENUM Working Group. Finally, Section 5 provides comments on usage. 2. Context Figure 1 depicts the general VoIP interconnect context. In this case, the caller uses an E.164 number [ITU.E164.1991] as the "name" of the called user. Note that this E.164 number is not an address, since at this point we do not have information about where the named endpoint is located. In the case shown here, an E.164 number is used as a key to retrieve a NAPTR recored [RFC3404] from the DNS, which in turn resolved into a SIP URI. Call routing is based on this SIP URI. The call routing step does not depend on the presence of an E.164 number; the SIP URI can be advertised in various other ways, such as on a web page. Finally, note that the subsequent lookup steps, namely, look up of SRV, A, and AAAA records (as well as any routing steps below that) are outside the scope of VOIPEER. Meyer Expires April 23, 2006 [Page 3] Internet-Draft Terminology for Describing VoIP Peering October 2005 E.164 number <--- Peer Discovery | | <--- ENUM lookup of NAPTR in DNS | | | ENUM Working Group Scope = =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | VOIPEER Working Group Scope | | SIP URI <--- Call Routing Data (CRD) | | <--- Service Location (Lookup of SRV in DNS) | | Hostname <--- VoIP addressing and session establishment | | <---- Lookup of A and AAAA in DNS | Ip address | | <---- Routing protocols, ARP etc | Mac-address Figure 1: VoIP Interconnect Context The ENUM Working Group is primarily concerned with the acquisition of Call Routing Data, or CRD (i.e., above the double line in Figure 1), while the VOIPEER Working Group is focused on the use of such CRD. Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS entry), or via any other mechanism available to the user. 3. General Definitions 3.1. Call Routing Data Call Routing Data, or CRD, is a SIP URI used to route a call (real- time, voice or other type) to the called domain's ingress point. A domain's ingress point can be thought of as the location pointed to by the SRV record that resulted from the resolution of the CRD (i.e., a SIP URI). 3.2. Call Routing Call routing is the set of processes, rules, and CRD used to route a VoIP call to its proper (SIP) destination. More generally, call Meyer Expires April 23, 2006 [Page 4] Internet-Draft Terminology for Describing VoIP Peering October 2005 routing can be thought of as the set of processes, rules and CRD which are used to route a real-time session to its termination (ingress) point. 3.3. PSTN The term "PSTN" refers to the Public Switched Telephone Network. In particular, the PSTN refers to the collection of interconnected circuit-switched voice-oriented public telephone networks, both commercial and government-owned. In general, PSTN terminals are addressed using E.164 numbers, noting that various dial-plans (such as emergency services dial-plans) may not directly use E.164 numbers. 3.4. Network For purposes of this document and the VOIPEER and ENUM Working Groups, a network is defined to be the set of SIP servers and end- users (customers) that are controlled by a single administrative domain. The network may also contain end-users who are located on the PSTN. 3.5. VoIP Service Provider A VoIP service provider is an entity that provides transport of SIP signaling (and possibly media streams) to its customers. Such a service provider may additionally be interconnected with other service providers; that is, it may "peer" with other service providers. A VoIP service provider may also interconnect with the PSTN. Note that as soon as a ingress point is advertised via a SRV record, anyone can find that ingress point and hence can send calls there. This is very similar to sending mail to a SMTP server based on the existence of a MX record. 3.6. Carrier The term carrier is defined to be a service provider authorized to issue E.164 numbers [ITU.E164.1991] for the provisioning of PSTN service under the authority of a National Regulatory Authority (NRA). 3.7. Peering While the precise definition of the term "peering" is the subject of some debate, peering in general refers to the negotiation of reciprocal interconnection arrangements, settlement-free or otherwise, between operationally independent service providers. Meyer Expires April 23, 2006 [Page 5] Internet-Draft Terminology for Describing VoIP Peering October 2005 This document distinguishes two types of peering, Layer 3 Peering and Layer 5 peering, which are described below. 3.7.1. Layer 3 Peering Layer 3 peering refers to interconnection of two service providers for the purposes of exchanging IP packets. Layer 3 peering is generally agnostic to the IP payload, and is frequently achieved using a routing protocol such as BGP [RFC1771] to exchange the required routing information. 3.7.2. Layer 5 Peering Layer 5 peering refers to interconnection of two service providers for the purposes of SIP signaling. Note that in the layer 5 peering case, there is no intervening network. That is, for purposes of this discussion, there is no such thing as a "Layer 5 Transit Network". 3.8. VoIP Peering VoIP peering is defined to be a layer 5 peering between two VoIP providers for purposes of routing real-time (or quasi-real time) call signaling between their respective customers. Media streams associated with this signaling (if any) are not constrained to follow the same set of paths. 4. ENUM ENUM [RFC3761] defines how the Domain Name System (DNS) can be used for identifying available services connected to one E.164 number. 4.1. Carrier of Record For purposes of this document, "Carrier of Record", or COR, refers to the entity that provides PSTN service for an E.164 number [I-D.lind- infrastructure-enum-reqs]. The exact definition of who and what is a COR is ultimately the responsibility of the relevant national authority. 4.2. Public ENUM Public ENUM is generally defined as the set administrative policies and procedures surrounding the use of the e164.arpa domain for Telephone Number to URI resolution [RFC3966]. Policies and procedures for the registration of telephone numbers within all branches of the e164.arpa tree are Nation State issues by agreement with the IAB and ITU. National Regulatory Authorities have generally Meyer Expires April 23, 2006 [Page 6] Internet-Draft Terminology for Describing VoIP Peering October 2005 defined Public ENUM Registrants as the E.164 number holder as opposed to the COR that issued the phone number. 4.3. Private ENUM Private ENUM is generally regarded as one or more technologies (including DNS and SIP Redirect) that service providers or enterprises may use to exchange phone number to URI mappings in a private secure manner. Private ENUM may be used in any mutually agreed upon domain. Records in Private ENUM may be globally visible but in most cases are not visible to the global Internet and are protected using a variety of security technologies such as split-DNS, VPN's or various forms or authentication and authorization. Technical comments on issues surrounding split-DNS can be found in [RFC2826]. 4.4. Carrier ENUM Carrier ENUM is generally regarded as the use of a separate branch the e164.arpa tree, such as 4.4.c.e164.arpa to permit service providers to exchange phone number to URI data in order to find points of interconnection. The current theory of Carrier ENUM is that only the COR for a particular E.164 number is permitted to provision data for that E.164 within that portion of the e164.arpa tree. In carrier ENUM case, only the COR may enter data in the corresponding domain. The COR may also enter CRD (i.e., a SIP URI) to allow other VoIP Service Providers to route calls to its network. Finally, note that ENUM is not constrained to carry only data (CDR) as defined by VOIPEER. In particular, an an important class of CRD, the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are most frequently used to interconnect with the PSTN directly, and are out of scope for VOIPEER. On the other hand, PSTN endpoints served by a COR and reachable via CDR and networks as defined in Section 3.1 and Section 3.4 are in scope for VOIPEER. 5. Conclusions 6. Acknowledgments Many of the definitions were gleaned from detailed discussions on the VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer, Jean-Francois Mule, Richard Shocky, and Richard Stastny made valuable contributions to early revisions of this document. Patrik Faltstrom Meyer Expires April 23, 2006 [Page 7] Internet-Draft Terminology for Describing VoIP Peering October 2005 also made many insightful comments to early versions of this draft, and contributed the basis of Figure 1. 7. Security Considerations This document itself introduces no new security considerations. However, it is important to note that VoIP interconnect has a wide variety of security issues that should be considered in documents addressing both protocol and use case analyzes. 8. IANA Considerations This document creates no new requirements on IANA namespaces [RFC2434]. 9. References 9.1. Normative References [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [ITU.E164.1991] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU- T Recommendation E.164, 1991. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. 9.2. Informative References [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2826] Internet Architecture Board, "IAB Technical Comment on the Meyer Expires April 23, 2006 [Page 8] Internet-Draft Terminology for Describing VoIP Peering October 2005 Unique DNS Root", RFC 2826, May 2000. [I-D.lind-infrastructure-enum-reqs] Lind, S., "Infrastructure ENUM Requirements", draft-lind-infrastructure-enum-reqs-00 (work in progress), July 2005. Meyer Expires April 23, 2006 [Page 9] Internet-Draft Terminology for Describing VoIP Peering October 2005 Author's Address David Meyer Email: dmm@1-4-5.net Meyer Expires April 23, 2006 [Page 10] Internet-Draft Terminology for Describing VoIP Peering October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Meyer Expires April 23, 2006 [Page 11] _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 21 09:51:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxJA-0006iO-0V; Fri, 21 Oct 2005 09:51:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxJ8-0006et-DI for enum@megatron.ietf.org; Fri, 21 Oct 2005 09:51:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22600 for ; Fri, 21 Oct 2005 09:51:31 -0400 (EDT) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESxVA-0001fO-LD for enum@ietf.org; Fri, 21 Oct 2005 10:04:16 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1129902675!6103016!3 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 17966 invoked from network); 21 Oct 2005 13:51:21 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-15.tower-120.messagelabs.com with SMTP; 21 Oct 2005 13:51:21 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 4355D40900248E84; Fri, 21 Oct 2005 09:51:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Oct 2005 09:51:17 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0B5E3EE2@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXVtFheWSwuBw7WQKSNku1/Qu0oMwAkJznw From: "Pfautz, Penn L, NEO" To: "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 111b48b3edee1f6fe0a892c95423c18d Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Dave: This is a nice start (indeed more than a start). I just have two comments at this point: 1. The definition of carrier in 3.6 is probably too restrictive. I would not make it contingent on issuance of E.164 numbers but rather just the provision of PSTN service. I appreciate your use our carrier-of-record definition in 4.1. 2. In reference to Layer 3 Peering (Section 3.7.1) I would like to see included the concepts that a) peering involves delivery of packets that terminate on the peer's network and b) peering is done without traffic settlement charges. Penn -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of David Meyer Sent: Thursday, October 20, 2005 4:22 PM To: voipeer@lists.uoregon.edu Cc: enum@ietf.org Subject: [voipeer] draft-meyer-voipeer-terminology-03.txt Folks, Here's the latest on this one (posted here as I'm not sure what the secretariat's posting rate is these days). I've included all the comments, AFAICT.=20 There had been another suggestion to "harmonize" with G.8080 terminology, which I am so far resisting (comments on that)?=20 Thanks, Dave --- Network Working Group D. Meyer Internet-Draft October 20, 2005 Expires: April 23, 2006 Terminology for Describing VoIP Peering and Interconnect draft-meyer-voipeer-terminology-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 23, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines the terminology that is to be used by the Voice Over IP Peering and Interconnect Working Group (voipeer), and has as its primary objective to focus the VOIPEER Working Group during its discussions, and when writing requirements, gap analysis and other solutions oriented documents. Meyer Expires April 23, 2006 [Page 1] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. General Definitions . . . . . . . . . . . . . . . . . . . . . 4 3.1. Call Routing Data . . . . . . . . . . . . . . . . . . . . 4 3.2. Call Routing . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Network . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5. VoIP Service Provider . . . . . . . . . . . . . . . . . . 5 3.6. Carrier . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7. Peering . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . . . . . . 6 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . . . . . . 6 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . . . . . . 6 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Carrier of Record . . . . . . . . . . . . . . . . . . . . 6 4.2. Public ENUM . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Private ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Meyer Expires April 23, 2006 [Page 2] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 1. Introduction The term "VoIP Peering" has historically been used to describe a wide variety of aspects pertaining to the interconnection of service provider networks and to the delivery of SIP call termination over those interconnections. The discussion of these interconnections has at times been confused by the fact that the term "peering" is used in various contexts to relate to interconnection at different levels in a protocol stack. VoIP peering focuses on how to identify and route calls at the application layer, and it does not (necessarily) involve the exchange of packet routing data or media sessions. In particular, "layer 5 network" is used here to refer to the interconnection between SIP servers, as opposed to interconnection at the IP layer ("layer 3"). Finally, the terms "peering" and "interconnect" are used interchangeably throughout this document. This document introduces standard terminology for use in characterizing VoIP interconnection. Note however, that while this document is primarily targeted at the VoIP interconnect case, the terminology described here is applicable to those cases in which service providers interconnect using SIP signaling for real-time or quasi-real-time communications. The remainder of this document is organized as follows: Section 2 provides the general context for the VOIPEER Working Group, and Section 3 provides the general definitions for real-time SIP based communication, with focus on the VoIP interconnect case. Section 4 briefly touches on terms from the ENUM Working Group. Finally, Section 5 provides comments on usage. 2. Context Figure 1 depicts the general VoIP interconnect context. In this case, the caller uses an E.164 number [ITU.E164.1991] as the "name" of the called user. Note that this E.164 number is not an address, since at this point we do not have information about where the named endpoint is located. In the case shown here, an E.164 number is used as a key to retrieve a NAPTR recored [RFC3404] from the DNS, which in turn resolved into a SIP URI. Call routing is based on this SIP URI. The call routing step does not depend on the presence of an E.164 number; the SIP URI can be advertised in various other ways, such as on a web page. Finally, note that the subsequent lookup steps, namely, look up of SRV, A, and AAAA records (as well as any routing steps below that) are outside the scope of VOIPEER. Meyer Expires April 23, 2006 [Page 3] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 E.164 number <--- Peer Discovery | | <--- ENUM lookup of NAPTR in DNS | | | ENUM Working Group Scope = =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | VOIPEER Working Group Scope | | SIP URI <--- Call Routing Data (CRD) | | <--- Service Location (Lookup of SRV in DNS) | | Hostname <--- VoIP addressing and session establishment | | <---- Lookup of A and AAAA in DNS | Ip address | | <---- Routing protocols, ARP etc | Mac-address Figure 1: VoIP Interconnect Context The ENUM Working Group is primarily concerned with the acquisition of Call Routing Data, or CRD (i.e., above the double line in Figure 1), while the VOIPEER Working Group is focused on the use of such CRD. Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS entry), or via any other mechanism available to the user. 3. General Definitions 3.1. Call Routing Data Call Routing Data, or CRD, is a SIP URI used to route a call (real- time, voice or other type) to the called domain's ingress point. A domain's ingress point can be thought of as the location pointed to by the SRV record that resulted from the resolution of the CRD (i.e., a SIP URI). 3.2. Call Routing Call routing is the set of processes, rules, and CRD used to route a VoIP call to its proper (SIP) destination. More generally, call Meyer Expires April 23, 2006 [Page 4] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 routing can be thought of as the set of processes, rules and CRD which are used to route a real-time session to its termination (ingress) point. 3.3. PSTN The term "PSTN" refers to the Public Switched Telephone Network. In particular, the PSTN refers to the collection of interconnected circuit-switched voice-oriented public telephone networks, both commercial and government-owned. In general, PSTN terminals are addressed using E.164 numbers, noting that various dial-plans (such as emergency services dial-plans) may not directly use E.164 numbers. 3.4. Network For purposes of this document and the VOIPEER and ENUM Working Groups, a network is defined to be the set of SIP servers and end- users (customers) that are controlled by a single administrative domain. The network may also contain end-users who are located on the PSTN. 3.5. VoIP Service Provider A VoIP service provider is an entity that provides transport of SIP signaling (and possibly media streams) to its customers. Such a service provider may additionally be interconnected with other service providers; that is, it may "peer" with other service providers. A VoIP service provider may also interconnect with the PSTN. Note that as soon as a ingress point is advertised via a SRV record, anyone can find that ingress point and hence can send calls there. This is very similar to sending mail to a SMTP server based on the existence of a MX record. 3.6. Carrier The term carrier is defined to be a service provider authorized to issue E.164 numbers [ITU.E164.1991] for the provisioning of PSTN service under the authority of a National Regulatory Authority (NRA). 3.7. Peering While the precise definition of the term "peering" is the subject of some debate, peering in general refers to the negotiation of reciprocal interconnection arrangements, settlement-free or otherwise, between operationally independent service providers. Meyer Expires April 23, 2006 [Page 5] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 This document distinguishes two types of peering, Layer 3 Peering and Layer 5 peering, which are described below. 3.7.1. Layer 3 Peering Layer 3 peering refers to interconnection of two service providers for the purposes of exchanging IP packets. Layer 3 peering is generally agnostic to the IP payload, and is frequently achieved using a routing protocol such as BGP [RFC1771] to exchange the required routing information. 3.7.2. Layer 5 Peering Layer 5 peering refers to interconnection of two service providers for the purposes of SIP signaling. Note that in the layer 5 peering case, there is no intervening network. That is, for purposes of this discussion, there is no such thing as a "Layer 5 Transit Network". 3.8. VoIP Peering VoIP peering is defined to be a layer 5 peering between two VoIP providers for purposes of routing real-time (or quasi-real time) call signaling between their respective customers. Media streams associated with this signaling (if any) are not constrained to follow the same set of paths. 4. ENUM ENUM [RFC3761] defines how the Domain Name System (DNS) can be used for identifying available services connected to one E.164 number. 4.1. Carrier of Record For purposes of this document, "Carrier of Record", or COR, refers to the entity that provides PSTN service for an E.164 number [I-D.lind- infrastructure-enum-reqs]. The exact definition of who and what is a COR is ultimately the responsibility of the relevant national authority. 4.2. Public ENUM Public ENUM is generally defined as the set administrative policies and procedures surrounding the use of the e164.arpa domain for Telephone Number to URI resolution [RFC3966]. Policies and procedures for the registration of telephone numbers within all branches of the e164.arpa tree are Nation State issues by agreement with the IAB and ITU. National Regulatory Authorities have generally Meyer Expires April 23, 2006 [Page 6] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 defined Public ENUM Registrants as the E.164 number holder as opposed to the COR that issued the phone number. 4.3. Private ENUM Private ENUM is generally regarded as one or more technologies (including DNS and SIP Redirect) that service providers or enterprises may use to exchange phone number to URI mappings in a private secure manner. Private ENUM may be used in any mutually agreed upon domain. Records in Private ENUM may be globally visible but in most cases are not visible to the global Internet and are protected using a variety of security technologies such as split-DNS, VPN's or various forms or authentication and authorization. Technical comments on issues surrounding split-DNS can be found in [RFC2826]. 4.4. Carrier ENUM Carrier ENUM is generally regarded as the use of a separate branch the e164.arpa tree, such as 4.4.c.e164.arpa to permit service providers to exchange phone number to URI data in order to find points of interconnection. The current theory of Carrier ENUM is that only the COR for a particular E.164 number is permitted to provision data for that E.164 within that portion of the e164.arpa tree. In carrier ENUM case, only the COR may enter data in the corresponding domain. The COR may also enter CRD (i.e., a SIP URI) to allow other VoIP Service Providers to route calls to its network. Finally, note that ENUM is not constrained to carry only data (CDR) as defined by VOIPEER. In particular, an an important class of CRD, the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are most frequently used to interconnect with the PSTN directly, and are out of scope for VOIPEER. On the other hand, PSTN endpoints served by a COR and reachable via CDR and networks as defined in Section 3.1 and Section 3.4 are in scope for VOIPEER. 5. Conclusions 6. Acknowledgments Many of the definitions were gleaned from detailed discussions on the VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer, Jean-Francois Mule, Richard Shocky, and Richard Stastny made valuable contributions to early revisions of this document. Patrik Faltstrom Meyer Expires April 23, 2006 [Page 7] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 also made many insightful comments to early versions of this draft, and contributed the basis of Figure 1. 7. Security Considerations This document itself introduces no new security considerations. However, it is important to note that VoIP interconnect has a wide variety of security issues that should be considered in documents addressing both protocol and use case analyzes. 8. IANA Considerations This document creates no new requirements on IANA namespaces [RFC2434]. 9. References 9.1. Normative References [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [ITU.E164.1991] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU- T Recommendation E.164, 1991. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. 9.2. Informative References [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2826] Internet Architecture Board, "IAB Technical Comment on the Meyer Expires April 23, 2006 [Page 8] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Unique DNS Root", RFC 2826, May 2000. [I-D.lind-infrastructure-enum-reqs] Lind, S., "Infrastructure ENUM Requirements", draft-lind-infrastructure-enum-reqs-00 (work in progress), July 2005. Meyer Expires April 23, 2006 [Page 9] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Author's Address David Meyer Email: dmm@1-4-5.net Meyer Expires April 23, 2006 [Page 10] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Meyer Expires April 23, 2006 [Page 11] =0C _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 21 10:03:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxU9-0002RM-Oe; Fri, 21 Oct 2005 10:03:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxU4-0002Qh-Ov for enum@megatron.ietf.org; Fri, 21 Oct 2005 10:03:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23288 for ; Fri, 21 Oct 2005 10:02:49 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESxgC-00026I-Q2 for enum@ietf.org; Fri, 21 Oct 2005 10:15:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5D648.A058913B" Date: Fri, 21 Oct 2005 16:03:38 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4616@oefeg-s04.oefeg.loc> X-MS-Has-Attach: yes Thread-Topic: I-D submission draft-haberler-carrier-enum-01 Thread-Index: AcXWQeV6FV/9J4FESg+fF6SChLt7twABlZvG From: "Stastny Richard" To: X-Spam-Score: 1.0 (+) X-Scan-Signature: d273fad2623d4a35a7bb17d92c76f399 Cc: enum@ietf.org Subject: [Enum] WG: I-D submission draft-haberler-carrier-enum-01 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D648.A058913B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, =20 since I-D submission turn around is very slow currently, here a peek = preview of our Carrier ENUM draft =20 Richard ________________________________ Von: Michael Haberler [mailto:mah@inode.at] Gesendet: Fr 21.10.2005 15:14 An: internet-drafts@ietf.org Cc: richard.shockey@neustar.biz; paf@cisco.com; = Jason_Livingood@cable.comcast.com; Tom_Creighton@cable.comcast.com; = Pfautz, Penn L, NEO; lwc@roke.co.uk; Stastny Richard; axelm@nic.at; = lendl@nic.at Betreff: I-D submission draft-haberler-carrier-enum-01 Dear IETF I-D team, please find attached an updated Internet-Draft submission titled "Combined User and Carrier ENUM in the e164.arpa tree" - draft-haberler-carrier-enum-01.txt . Abstract: ENUM as defined now in RFC3761 is not well suited for the purpose of interconnection by carriers, as can be seen by the use of various private tree arrangements based on ENUM mechanisms. A combined end-user and carrier ENUM tree solution would leverage the ENUM infrastructure in e164.arpa, increase resolution rates, and decrease the cost per registered telephone number. This document describes a minimally invasive scheme to provide both end-user and carrier data in = ENUM. This draft is intended for the ENUM working group. The draft is also available on my web page at: http://mah.priv.at/i-d/draft-haberler-carrier-enum-01.txt http://mah.priv.at/i-d/draft-haberler-carrier-enum-01.html best regards Michael Haberler Internet Foundation Austria +43 664 4213465=20 ------_=_NextPart_001_01C5D648.A058913B Content-Type: text/plain; name="draft-haberler-carrier-enum-01.txt" Content-Description: draft-haberler-carrier-enum-01.txt Content-Disposition: attachment; filename="draft-haberler-carrier-enum-01.txt" Content-Transfer-Encoding: base64 DQoNCg0KRU5VTSAtLSBUZWxlcGhvbmUgTnVtYmVyIE1hcHBpbmcgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIE0uIEhhYmVybGVyDQpXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJUEENCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUi4gU3Rhc3RueQ0K RXhwaXJlczogQXByaWwgMjQsIDIwMDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIE9lZmVnDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE9jdG9iZXIgMjEsIDIwMDUNCg0KDQogICAgICAgICAgQ29tYmluZWQg VXNlciBhbmQgQ2FycmllciBFTlVNIGluIHRoZSBlMTY0LmFycGEgdHJlZQ0KICAgICAgICAgICAg ICAgICAgICAgZHJhZnQtaGFiZXJsZXItY2Fycmllci1lbnVtLTAxDQoNClN0YXR1cyBvZiB0aGlz IE1lbW8NCg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNoIGF1dGhv ciByZXByZXNlbnRzIHRoYXQgYW55DQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIg Y2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZQ0KICAgaGF2ZSBiZWVuIG9yIHdpbGwg YmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzDQogICBhd2Fy ZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBCQ1Ag NzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIElu dGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQg aXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28g ZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4NCg0K ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11 bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNv bGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9y IHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhl IGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBo dHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAgIFRoZSBsaXN0 IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQN CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50ZXJuZXQt RHJhZnQgd2lsbCBleHBpcmUgb24gQXByaWwgMjQsIDIwMDYuDQoNCkNvcHlyaWdodCBOb3RpY2UN Cg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNSkuDQoNCkFic3Ry YWN0DQoNCiAgIEVOVU0gYXMgZGVmaW5lZCBub3cgaW4gUkZDMzc2MSBbMV0gaXMgbm90IHdlbGwg c3VpdGVkIGZvciB0aGUgcHVycG9zZQ0KICAgb2YgaW50ZXJjb25uZWN0aW9uIGJ5IGNhcnJpZXJz LCBhcyBjYW4gYmUgc2VlbiBieSB0aGUgdXNlIG9mIHZhcmlvdXMNCiAgIHByaXZhdGUgdHJlZSBh cnJhbmdlbWVudHMgYmFzZWQgb24gRU5VTSBtZWNoYW5pc21zLiAgQSBjb21iaW5lZCBlbmQtDQog ICB1c2VyIGFuZCBjYXJyaWVyIEVOVU0gdHJlZSBzb2x1dGlvbiB3b3VsZCBsZXZlcmFnZSB0aGUg RU5VTQ0KICAgaW5mcmFzdHJ1Y3R1cmUgaW4gZTE2NC5hcnBhLCBpbmNyZWFzZSByZXNvbHV0aW9u IHJhdGVzLCBhbmQgZGVjcmVhc2UNCiAgIHRoZSBjb3N0IHBlciByZWdpc3RlcmVkIHRlbGVwaG9u ZSBudW1iZXIuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhDQogICBtaW5pbWFsbHkgaW52YXNp dmUgc2NoZW1lIHRvIHByb3ZpZGUgYm90aCBlbmQtdXNlciBhbmQgY2FycmllciBkYXRhDQoNCg0K DQpIYWJlcmxlciAmIFN0YXN0bnkgICAgICAgRXhwaXJlcyBBcHJpbCAyNCwgMjAwNiAgICAgICAg ICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIENvbWJpbmVkIFVzZXIg YW5kIENhcnJpZXIgRU5VTSAgICAgICAgIE9jdG9iZXIgMjAwNQ0KDQoNCiAgIGluIEVOVU0uDQoN ClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMw0KDQogICAyLiAgIFRoZSBDYXJy aWVyIG9mIFJlY29yZCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMN Cg0KICAgMy4gICBSZXF1aXJlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA0DQoNCiAgIDQuICAgSW50cm9kdWNpbmcgYSBicmFuY2ggaW50byB0 aGUgZTE2NC5hcnBhIHRyZWUgLiAuIC4gLiAuIC4gLiAuICAgNA0KDQogICA1LiAgIFJlc29sdmVy IGJlaGF2aW91ciBvcHRpb25zIGFuZCB0aGUgQ2FycmllciBFTlVNIGJyYW5jaA0KICAgICAgICBs b2NhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA1DQoNCiAgIDYuICAgUmVjb21tZW5kZWQgcmVzb2x2ZXIgYmVoYXZpb3VyIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNw0KDQogICA3LiAgIFpvbmUgZmlsZSBleGFtcGxlcyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgNCg0KICAgOC4gICBU aGUgQnJhbmNoIExvY2F0aW9uIFJlY29yZCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDExDQoNCiAgIDkuICAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMg0KDQogICAxMC4gIElBTkEgY29uc2lkZXJhdGlvbnMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTMNCg0KICAgMTEuICBJ bnRlcm9wZXJhYmlsaXR5IGNvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDEzDQoNCiAgIDEyLiAgQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMw0KDQogICAxMy4gIFJlZmVyZW5jZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTQNCiAgICAgMTMuMSAg IE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAxNA0KICAgICAxMy4yICAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDE0DQoNCiAgICAgICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNA0KDQogICAgICAgIEludGVs bGVjdHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAg MTUNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhhYmVybGVyICYgU3Rhc3RueSAgICAg ICBFeHBpcmVzIEFwcmlsIDI0LCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgQ29tYmluZWQgVXNlciBhbmQgQ2FycmllciBFTlVNICAgICAgICAg T2N0b2JlciAyMDA1DQoNCg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBFTlVNIGFzIGRlZmluZWQg aW4gUkZDMzc2MSBpcyBiYXNlZCBvbiB0aGUgZW5kLXVzZXIgb3B0LWluIHByaW5jaXBsZS4NCiAg IFdoaWxlIHRoaXMgaGFzIGdyZWF0IHBvdGVudGlhbCB0byBmb3N0ZXIgbmV3IHNlcnZpY2VzIGFu ZCBlbmQtdXNlcg0KICAgY2hvaWNlIGluIHRoZSBsb25nLXRlcm0sIHRoZSBjdXJyZW50IHJlcXVp cmVtZW50cyBmb3IgSVAtYmFzZWQNCiAgIGludGVyY29ubmVjdGlvbiBvZiBjYXJyaWVycyBhbmQg Vm9JUCBTZXJ2aWNlIFByb3ZpZGVycyByZXF1aXJlIHRoZQ0KICAgcHJvdmlzaW9uaW5nIG9mIGFs bCBhbGxvY2F0ZWQgb3Igc2VydmVkIChob3N0ZWQpIG51bWJlcnMgb2YgYQ0KICAgcGFydGljaXBh dGluZyBjYXJyaWVyIG9mIHJlY29yZC4gIEFsc28sIGFuIGludGVyY29ubmVjdGlvbiBzY2VuYXJp bw0KICAgdGhyb3VnaCBDYXJyaWVyIEVOVU0gdHlwaWNhbGx5IGltcGxpZXMgdW5kZXJseWluZyBj bG9zZWQgdXNlcg0KICAgYXJyYW5nZW1lbnRzIHdoZXJlIFVSSXMgYXJlIHVzZWQgaW4gYXV0aGVu dGljYXRlZCBjb250ZXh0LCBhbg0KICAgYXNzdW1wdGlvbiB3aGljaCBjYW5ub3QgcmVhc29uYWJs eSBiZSBpbXBvc2VkIG9uIFVzZXIgRU5VTSBlbnRyaWVzLg0KICAgV2hpbGUgaW4gcHJpbmNpcGxl IHNvbHV0aW9ucyBsaWtlIGNvbXB1bHNvcnkgb3B0LWluIHRocm91Z2ggdGVybXMgYW5kDQogICBj b25kaXRpb25zIGZvciBlbmQgdXNlcnMgYXJlIGNvbmNlaXZhYmxlLCB0aGVyZSBhcmUgc3Vic3Rh bnRpYWwNCiAgIGRvd25zaWRlcyB0byBzdWNoIGFuIGFwcHJvYWNoLiAgRU5VTSBmb3IgZW5kLXVz ZXIgcHJvdmlzaW9uaW5nDQogICByZW1haW5zIGFuIGlsbC1zdWl0ZWQgc29sdXRpb24gZm9yIHRo ZSBQb0kgKHBvaW50LW9mLWludGVyY29ubmVjdCkNCiAgIGluZm9ybWF0aW9uIGRpc2NvdmVyeSBw cm9ibGVtLg0KDQogICBCb3RoIGZyb20gYW4gT1BFWCAoT3BlcmF0aW9uYWwgRXhwZW5kaXR1cmUp IHBlcnNwZWN0aXZlIGFzIHdlbGwgYXMNCiAgIG92ZXJhbGwgcmVzb2x1dGlvbiByYXRlcyBhY2hp ZXZhYmxlIHRocm91Z2ggYSBnaXZlbiBhcHByb2FjaCwgYQ0KICAgY29tYmluZWQgRU5VTSB0cmVl IGJvdGggZm9yIGVuZC11c2VycyBhbmQgY2FycmllciBvZiByZWNvcmQgRU5VTQ0KICAgc3RhbmRz IHRvIGJlIHN1cGVyaW9yIG92ZXIgYSBmb3Jlc3Qgb2YgZGlzcGFyYXRlIHByaXZhdGUgdHJlZXMg bm93IGFzDQogICB3ZWxsIGFzIGxvbmctdGVybS4gIEFsc28sIGFzIGEgY29tbW9uIGluZnJhc3Ry dWN0dXJlIGVhc2lseSBzdXBwb3J0cw0KICAgYm90aCB1c2FnZSBzY2VuYXJpb3MsIGEgY29tYmlu ZWQgYXBwcm9hY2ggd2lsbCBzdXBwb3J0IHRoZSBlbmQtdXNlcg0KICAgRU5VTSB2aXNpb24gYnkg ZHJpdmluZyBkb3duIHRoZSBhdmVyYWdlIGNvc3QgcGVyIG51bWJlci4gIExhc3RseSwgYW55DQog ICBsYXRlciBjb252ZXJnZW5jZSBiZXR3ZWVuIEVOVU0gZm9yIGVuZC11c2VycyBhbmQgY2Fycmll cnMgb2YgcmVjb3JkDQogICB3aWxsIGJlIHNpZ25pZmljYW50bHkgZWFzaWVyIGFuZCBjaGVhcGVy LCB0aHVzIGJlbmVmaXRpbmcgdXNlcnMgYXMNCiAgIHdlbGwgYXMgY2FycmllcnMuICBGb3IgdGhl IHJlc3Qgb2YgdGhlIGRvY3VtZW50IHRoZSB0ZXJtcyBVc2VyIEVOVU0NCiAgIGFuZCBDYXJyaWVy IEVOVU0gd2lsbCBiZSB1c2VkIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gdGhlIHR3bw0KICAgYXBw cm9hY2hlcy4NCg0KMi4gIFRoZSBDYXJyaWVyIG9mIFJlY29yZA0KDQogICBJbiBVc2VyIEVOVU0s IHRoZSBlbnRpdHkgb3IgcGVyc29uIGhhdmluZyB0aGUgcmlnaHQtdG8tdXNlIGluIGENCiAgIG51 bWJlciBoYXMgdGhlIHNvbGUgZGlzY3JldGlvbiBhYm91dCB0aGUgY29udGVudCBvZiB0aGUgYXNz b2NpYXRlZA0KICAgZG9tYWluIGFuZCB0aHVzIHRoZSB6b25lIGNvbnRlbnQuDQoNCiAgIFdpdGhp biBhIENhcnJpZXIgRU5VTSBuYW1lc3BhY2UsIHdlIHVzZSB0aGUgdGVybSAiY2FycmllciBvZiBy ZWNvcmQiDQogICBmb3IgdGhlIGVudGl0eSBoYXZpbmcgdGhhdCBkaXNjcmV0aW9uLiAgVGhpcyBy aWdodCB0eXBpY2FsbHkgbGllcw0KICAgd2l0aCBhIHNlcnZpY2UgcHJvdmlkZXIgYXV0aG9yaXpl ZCB0byBpc3N1ZSBFLjE2NCBudW1iZXJzIGZvciB0aGUNCiAgIHByb3Zpc2lvbmluZyBvZiBQU1RO IHNlcnZpY2UgdW5kZXIgdGhlIGF1dGhvcml0eSBvZiBhIE5hdGlvbmFsDQogICBSZWd1bGF0b3J5 IEF1dGhvcml0eSAoTlJBKSwgYnV0IGdlbmVyYWxseSBleGhpYml0cyBvbmUgb3IgbW9yZSBvZiB0 aGUNCiAgIGZvbGxvd2luZyBwcm9wZXJ0aWVzOg0KDQogICBvICBpdCBoYXMgYmVlbiBhc3NpZ25l ZCBvbmUgb3IgbW9yZSBuYXRpb25hbCBudW1iZXIgcmFuZ2VzIGJ5IGFuIE5SQS4NCiAgIG8gIGl0 IGhhcyBiZWVuIGFzc2lnbmVkIGEgbnVtYmVyIHJhbmdlIGRpcmVjdGx5IGJ5IHRoZSBJVFUsIGZv cg0KICAgICAgaW5zdGFuY2UgYSBjb2RlIHVuZGVyICJJbnRlcm5hdGlvbmFsIE5ldHdvcmtzIiAo Kzg4Mikgb3INCiAgICAgICJVbml2ZXJzYWwgUGVyc29uYWwgVGVsZWNvbW11bmljYXRpb25zIChV UFQpIiAoKzg3OCkuDQoNCg0KDQoNCkhhYmVybGVyICYgU3Rhc3RueSAgICAgICBFeHBpcmVzIEFw cmlsIDI0LCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgQ29tYmluZWQgVXNlciBhbmQgQ2FycmllciBFTlVNICAgICAgICAgT2N0b2JlciAyMDA1 DQoNCg0KICAgbyAgaXQgY2FuIGJlIHRoZSByZWNpcGllbnQgb2YgYSBudW1iZXIgcG9ydGluZyBv cGVyYXRpb24uDQogICBvICBpdCBwcm92aWRlcyBhIFBTVE4gcG9pbnQtb2YtaW50ZXJjb25uZWN0 IGZvciB0aGUgbnVtYmVyLg0KDQogICBDYXJyaWVyIEVOVU0gaXMgdW5kZXJzdG9vZCB0byBtZWFu IGEgZm9ybSBvZiBFTlVNIHdoZXJlIHN1Y2gNCiAgIGVudGl0aXRlcyBoYXZlIGV4Y2x1c2l2ZSBk aXNjcmV0aW9uIGFib3V0IHpvbmUgY29udGVudC4NCg0KMy4gIFJlcXVpcmVtZW50cw0KDQogICBB IHNvbHV0aW9uIGZvciBjb21iaW5lZCBVc2VyIGFuZCBDYXJyaWVyIEVOVU0gd2l0aGluIHRoZSBl MTY0LmFycGENCiAgIHRyZWUgc2hvdWxkIG1lZXQgdGhlIGZvbGxvd2luZyByZXF1aXJlbWVudHM6 DQoNCiAgIG8gIEEgc2luZ2xlIEROUyBsb29rdXAgc2hvdWxkIHN1ZmZpY2UgdG8gcmVzb2x2ZSBh bnkgZ2l2ZW4gbnVtYmVyIGluDQogICAgICB0aGUgcHVibGljIEROUyBpbiBib3RoIHNjZW5hcmlv cy4NCiAgIG8gIEl0IHNob3VsZCBsZWF2ZSBVc2VyIEVOVU0gcmVzb2x1dGlvbiBzZW1hbnRpY3Mg YW5kIHRyZWUgc2hhcGUNCiAgICAgIGludGFjdCwgaS5lLiByZXF1aXJpbmcgbm8gd2hvbGVzYWxl IGNoYW5nZXMgdG8gZXhpc3RpbmcgVXNlciBFTlVNDQogICAgICByZXNvbHZlcnMgb3IgdHJlZSBs YXlvdXQuDQogICBvICBBZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdHkgc2hvdWxkIG9ubHkgYmUgaW1w b3NlZCBvbiBjYXJyaWVyIEVOVU0NCiAgICAgIHJlc29sdmVycy4NCiAgIG8gIEl0IHNob3VsZCB3 b3JrIHdpdGggYm90aCBjbG9zZWQgYW5kIG9wZW4gbnVtYmVyaW5nIHBsYW5zIHdpdGhvdXQNCiAg ICAgIHJlc29ydGluZyB0byB3aWxkY2FyZCByZWNvcmRzIGluIHRoZSBub24tdXNlciBjb250cm9s bGVkIHBhcnQgb2YNCiAgICAgIHRoZSBETlMsIGJvdGggdG8gYXZvaWQgYXNzb2NpYXRlZCBzZW1h bnRpYyBwcm9ibGVtcyBhcyB3ZWxsIGFzDQogICAgICBrZWVwaW5nIHRoZSByb3V0ZSB0byBETlNT RUMgZGVwbG95bWVudCBvcGVuLg0KICAgbyAgSXQgc2hvdWxkIG5vdCByZXF1aXJlIHRoZSBpbnRy b2R1Y3Rpb24gb2YgbmV3IGNvbnN0cnVjdHMgd2l0aGluDQogICAgICBleGlzdGluZyBzdGFuZGFy ZHMsIHN1Y2ggYXMgbmV3IHR5cGVzIG9yIGNoYW5nZWQgc2VtYW50aWNzIG9mDQogICAgICBOQVBU UiByZWNvcmRzLg0KICAgbyAgSXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGludHJvZHVjZSB0aGUg c2NoZW1lIGluIGEgdGltZWx5IG1hbm5lciwNCiAgICAgIHN1cHBvcnRpbmcgY3VycmVudCBjYXJy aWVyIG5lZWRzLiAgQ29uc2VxdWVudGx5LCBpdCBpcyBkZXNpcmFibGUNCiAgICAgIHRvIGRlcGxv eSB0aGUgc2NoZW1lIHdpdGhvdXQgcmUtb3BlbmluZyBhbHJlYWR5IHNldHRsZWQgcXVlc3Rpb25z DQogICAgICBvZiByb2xlcywgcmVzcG9uc2liaWxpdGllcyBhbmQgaW50ZXJuYXRpb25hbCBjb29y ZGluYXRpb24sIGFuZCBpbg0KICAgICAgcGFydGljdWxhciB0aGUgY291bnRyeSBjb2RlIGRlbGVn YXRpb24gcHJvY2Vzcy4NCiAgIG8gIEl0IHNob3VsZCBtZWV0IGFsbCByZWFzb25hYmxlIHByaXZh Y3kgY29uY2VybnMgYWJvdXQgdmlzaWJpbGl0eSBvZg0KICAgICAgaW5mb3JtYXRpb24gYW4gZW5k IHVzZXIgaGFzIG5vIGNvbnRyb2wgb3ZlciwgZm9yIGV4YW1wbGUgZGlzY292ZXJ5DQogICAgICBv ZiB1bmxpc3RlZCBudW1iZXJzLCBvciBpbmFkdmVydGVudCBkaXNjbG9zdXJlIG9mIHVzZXIgaWRl bnRpdHkuDQogICBvICBJdCBzaG91bGQga2VlcCB0aGUgb3B0aW9uIG9wZW4gZm9yIG90aGVyIHR5 cGVzIG9mIGNsb3NlZC11c2VyLQ0KICAgICAgZ3JvdXAgdHlwZSBhcHBsaWNhdGlvbnMsIHdoaWNo IG1pZ2h0IG5vdCBuYXR1cmFsbHkgZml0IGludG8gdGhlIC0NCiAgICAgIHByZWRvbWluYW50bHkg dm9pY2Ugb3JpZW50ZWQgLSBDYXJyaWVyIEVOVU0gc2NlbmFyaW8uDQoNCiAgIE5vdGUgaW4gcGFy dGljdWxhciB0aGF0IHdlIGFzc3VtZSBhbGwgZW50cmllcyB0byBwcm9wZXJseSByZXNvbHZlIGlu DQogICB0aGUgcHVibGljIEROUywgYm90aCB1c2VyIGFuZCBjYXJyaWVyLiAgVXNhZ2UgcmVzdHJp Y3Rpb25zIG9uIENhcnJpZXINCiAgIEVOVU0gcmVjb3JkcyBhcmUgdG8gYmUgaGFuZGxlZCBhdCB0 aGUgVVJJIGxldmVsLCBhbmQgbm90IGJ5DQogICByZXN0cmljdGlvbiBvbiB0aGUgdmlzaWJpbGl0 eSBvZiBlbnRyaWVzIGluIHRoZSBwdWJsaWMgRE5TLg0KDQo0LiAgSW50cm9kdWNpbmcgYSBicmFu Y2ggaW50byB0aGUgZTE2NC5hcnBhIHRyZWUNCg0KICAgVGhlIG1ldGhvZCBtb3N0IGVhc2lseSBm dWxmaWxsaW5nIHRoZSBhYm92ZW1lbnRpb25lZCByZXF1aXJlbWVudHMgaXMNCiAgIHRvIGJyYW5j aCBvZmYgdGhlIGUxNjQuYXJwYSB0cmVlIGludG8gYSBzdWJkb21haW4gYXQgYSBnaXZlbiBwb2lu dCwNCiAgIGFuZCBkZXBsb3kgYSBDYXJyaWVyIEVOVU0gc3VidHJlZSB1bmRlcm5lYXRoIHdpdGhv dXQgdG91Y2hpbmcgVXNlcg0KICAgRU5VTSBzZW1hbnRpY3MgYXQgYWxsLiAgRm9yIHJlYWRhYmls aXR5LCB3ZSB3aWxsIHVzZSB0aGUgJ2NhcnJpZXInDQoNCg0KDQpIYWJlcmxlciAmIFN0YXN0bnkg ICAgICAgRXhwaXJlcyBBcHJpbCAyNCwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgIENvbWJpbmVkIFVzZXIgYW5kIENhcnJpZXIgRU5VTSAgICAg ICAgIE9jdG9iZXIgMjAwNQ0KDQoNCiAgIHN1YmRvbWFpbiBmcm9tIG5vdyBvbiwgd2hpbGUgaW4g cHJhY3RpY2UgYSBzaW5nbGUgY2hhcmFjdGVyIHN1YmRvbWFpbg0KICAgbGlrZSAnYycgd2lsbCBz dWZmaWNlLg0KDQogICBGb3IgaW50ZXJvcGVyYWJpbGl0eSBpdCBpcyBkZXNpcmFibGUgdG8gaGF2 ZSB0aGF0IGJyYW5jaCBzaXQgaW4gYQ0KICAgY29tbW9ubHkgYWdyZWVkLCBvciBlYXNpbHkgZGlz Y292ZXJhYmxlIHBsYWNlLiAgU2V2ZXJhbCBvcHRpb25zIGZvcg0KICAgdGhpcyBicmFuY2ggbG9j YXRpb24gZXhpc3QsIGFtb25nIHRoZW0gYXJlOg0KICAgbyAgYWJvdmUgdGhlIGNvdW50cnkgY29k ZSBkZWxlZ2F0aW9uIGxldmVsLCBlLmcuDQogICAgICAnNC45LjcuMS5jYXJyaWVyLmUxNjQuYXJw YScsIGFsdGVybmF0aXZlbHk6DQogICBvICBzb21ld2hlcmUgYmVsb3cgdGhlIGNvdW50cnkgY29k ZSBkZWxlZ2F0aW9uIGxldmVsLCBlLmcuDQogICAgICAnNC45LjcuY2Fycmllci4xLmUxNjQuYXJw YScgb3IgJ2NhcnJpZXIuNC45LjcuMS5lMTY0LmFycGEnLg0KDQogICBJbiB0aGUgZmlyc3QgY2Fz ZSwgaGVhdnkgaW52b2x2ZW1lbnQgb2YgSVRVLVQsIFJJUEUgYXMgd2VsbCBhcyB0aGUNCiAgIGFw cGxpY2FibGUgTlJBcyAoTmF0aW9uYWwgUmVndWxhdG9yeSBBdXRob3JpdGllcykgaXMgbmVlZGVk IGR1cmluZw0KICAgdGhlIHNldHVwIHBoYXNlLiAgQWxzbywgcmVvcGVuaW5nIHRoZSBkaXNjdXNz aW9uIG9mIHRoZSBpbnRlcmltDQogICBwcm9jZWR1cmVzIGFscmVhZHkgYWdyZWVkIGlzIGEgdGVk aW91cyBwcm9jZXNzLCBhcyBpcyB0aGUgYWRhcHRhdGlvbg0KICAgb2YgdGhlIGN1cnJlbnQgZGVs ZWdhdGlvbiBtZWNoYW5pc20uICBIb3dldmVyLCBubyBjaGFuZ2VzIHRvIHJlc29sdmVyDQogICBz ZW1hbnRpY3MgYXJlIHJlcXVpcmVkIGFzIHRoaXMgYXBwcm9hY2ggYW1vdW50cyB0byBqdXN0IGEg ZGlmZmVyZW50DQogICBhcGV4IGRlZmluaXRpb24gZm9yIHRoZSByZXNvbHZlci4gIFRoZXJlZm9y ZSB0aGUgcmVtYWluZGVyIG9mIHRoaXMNCiAgIHBhcGVyIGFkZHJlc3NlcyBvbmx5IHRoZSBzZWNv bmQgc2NlbmFyaW8uICBUaGlzIGFwcHJvYWNoLCBwdXR0aW5nDQogICBhc2lkZSBzaWduaWZpY2Fu dCBwcm9jZXNzIGFuZCB0aW1pbmcgY29uY2VybnMsIGFwcGVhcnMgdG8gYmUgYW4NCiAgIGVhc2ll ciB0byBtYW5hZ2UgbG9uZy10ZXJtIGFwcHJvYWNoIHRvIHRyZWUgbmFtaW5nLg0KDQogICBJbiB0 aGUgc2Vjb25kIGNhc2UgaXNzdWVzIGNvdWxkIGJlIHJlc29sdmVkIGFzIGEgbmF0aW9uYWwgbWF0 dGVyLCBvcg0KICAgYXMgYSByZWdpb25hbCBvcHQtaW4gd2l0aGluIGluIGEgZ2l2ZW4gTnVtYmVy aW5nIFBsYW4gQXJlYSBzdWNoIGFzDQogICB0aGUgTm9ydGggQW1lcmljYW4gTlBBLiAgSG93ZXZl ciwgYSBjb252ZW50aW9uIGlzIG5lZWRlZCBob3csIGdpdmVuIGENCiAgIGZ1bGx5IHF1YWxpZmll ZCBFLjE2NCBbMl0gbnVtYmVyLCBhIHJlc29sdmVyIGNhbiBkZXRlcm1pbmUgdGhlDQogICBsb2Nh dGlvbiBvZiB0aGUgY2FycmllciBzdWJkb21haW4uICBIb3dldmVyLCBJVFUtVCBhbmQgSUVURiAo SUFCKQ0KICAgaW52b2x2ZW1lbnQgaXMgb25seSBsaWdodHdlaWdodCwgZS5nLiB0byByZWNvbW1l bmQgdGhlIHByb3Blcg0KICAgYWxnb3JpdGhtIGRlZmluZWQgaGVyZSB0byBlbmFibGUgaW50ZXJu YXRpb25hbCBpbnRlcm9wZXJhYmlsaXR5Lg0KDQogICBCZXlvbmQgdGhlIHNldHVwIHBoYXNlLCBh biBOUkEgbmVlZCBub3QgYmUgaW52b2x2ZWQgb3BlcmF0aW9uYWxseSAtDQogICBpdCBpcyBzdWZm aWNpZW50IHRvIGVzdGFibGlzaCBhIGNvbnZlbnRpb24gbGlua2luZyB0aGUgbmF0aW9uYWwNCiAg IGRlZmluaXRpb24gb2YgYSBjYXJyaWVyIG9mIHJlY29yZCB0byB0aGUgY3JlZGVudGlhbHMgZm9y IHdyaXRlIGFjY2Vzcw0KICAgdG8gdGhlIENhcnJpZXIgRU5VTSB0cmVlLg0KDQogICBXZSBiZWxp ZXZlIHRoZSBjaG9pY2UgYW1vbmcgdGhlIGFib3ZlIG9wdGlvbnMgc2hvdWxkIG5vdCBiZQ0KICAg cHJlZGV0ZXJtaW5lZCBmb3IgbWF4aW11bSBmbGV4aWJpbGl0eSBhbmQgbGVmdCB0byBuYXRpb25h bCBvcg0KICAgcmVnaW9uYWwgZW52aXJvbm1lbnRzIHRvIGRlY2lkZS4gIFRoaXMgc3VnZ2VzdHMg YSBtZXRob2QgZm9yIENhcnJpZXINCiAgIEVOVU0gcmVzb2x1dGlvbiB3aGljaCBjYW4gZGVhbCBh dCBydW50aW1lIHdpdGggd2hhdGV2ZXIgdGhlIGRlY2lzaW9uDQogICBmb3IgYSBjb3VudHJ5IGNv ZGUsIG9yIGEgZ3JvdXAgb2YgY291bnRyaWVzLCBoYXBwZW5zIHRvIGJlLg0KDQo1LiAgUmVzb2x2 ZXIgYmVoYXZpb3VyIG9wdGlvbnMgYW5kIHRoZSBDYXJyaWVyIEVOVU0gYnJhbmNoIGxvY2F0aW9u DQoNCiAgIEEgQ2FycmllciBFTlVNIHJlc29sdmVyIHRodXMgbmVlZHMgdG8gZGV0ZXJtaW5lIHRo ZSBwbGFjZSBhcHBsaWNhYmxlDQogICBpbiBhIGdpdmVuIG51bWJlciB0byBzZWFyY2ggZm9yIHRo ZSAnY2Fycmllcicgc3ViZG9tYWluIGZvcg0KICAgaW50ZXJuYXRpb25hbCBpbnRlcm9wZXJhYmls aXR5LCByZWdhcmRsZXNzIHdoYXQgdGhlIG5hdGlvbmFsIG9yDQogICBncm91cC1vZi1jb3VudHJp ZXMgc2V0dXAgZGVjaXNpb24gd2FzLg0KDQoNCg0KDQpIYWJlcmxlciAmIFN0YXN0bnkgICAgICAg RXhwaXJlcyBBcHJpbCAyNCwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgIENvbWJpbmVkIFVzZXIgYW5kIENhcnJpZXIgRU5VTSAgICAgICAgIE9j dG9iZXIgMjAwNQ0KDQoNCiAgIFdlIHByb3Bvc2UgYSBtZWNoYW5pc20gdG8gZGlzY292ZXIgdGhp cyBib3VuZGFyeSBkeW5hbWljYWxseSBmb3IgYW55DQogICBnaXZlbiBzaGFwZSBhcyBmb2xsb3dz Og0KICAgbyAgdGhlIG5hdGlvbmFsIG9yIGdyb3VwLW9mLWNvdW50cmllcyBkZWNpc2lvbiBhYm91 dCBzdWJkb21haW4NCiAgICAgIGxvY2F0aW9uIGlzIGRvY3VtZW50ZWQgaW4gdGhlIGUxNjQuYXJw YSB0cmVlIHByb3BlciBieSBpbnNlcnRpbmcgYQ0KICAgICAgc3BlY2lhbCBETlMgcmVjb3JkIGlu dG8gdGhlIGNvdW50cnkgY29kZSB6b25lLiAgVGhpcyBicmFuY2gNCiAgICAgIGxvY2F0aW9uIHJl Y29yZCAoU2VjdGlvbiA4KSAoQkxSKSBjYXJyaWVzIGFuIGludGVnZXIgdmFsdWUgd2hpY2gNCiAg ICAgIHBvaW50cyB0byB0aGUgbGV2ZWwgaW4gdGhlIHRyZWUgd2hlcmUgdGhlIGNhcnJpZXIgc3Vi dHJlZSBicmFuY2hlcw0KICAgICAgb2ZmLiAgSW1wbGVtZW50YXRpb24gb3B0aW9ucyBmb3IgdGhl IEJMUiBhcmUgZGlzdXNzZWQgYmVsb3cuDQogICBvICBhIHJlc29sdmVyIGxvb2tpbmcgZm9yIGEg Q2FycmllciBFTlVNIGRvbWFpbiBuZWVkcyB0byByZXRyaWV2ZQ0KICAgICAgdGhpcyBCTFIgb25j ZSBkdXJpbmcgZmlyc3QgcmVzb2x1dGlvbiB3aXRoaW4gYSBjb3VudHJ5IGNvZGUsDQogICAgICBj YWNoaW5nIHRoZSByZXN1bHQgaW4gYSBsb2NhbCB0YWJsZSBmb3IgbGF0ZXIgcmV1c2UuDQogICBv ICB3aGlsZSBjb25zdHJ1Y3RpbmcgdGhlIEZRRE4sIHRoZSAnY2FycmllcicgbGFiZWwgaXMgaW5z ZXJ0ZWQgYXQNCiAgICAgIHRoZSBwb3NpdGlvbiBpbmRpY2F0ZWQgYnkgdGhlIEJMUidzIGludGVn ZXIgdmFsdWUuDQoNCiAgIEZvciB0aGUgYWJvdmVtZW50aW9uZWQgdHJlZSBzaGFwZSBvcHRpb25z IChTZWN0aW9uIDQpLCB0aGUNCiAgIGNvcnJlc3BvbmRpbmcgYnJhbmNoIGxvY2F0aW9uIHJlY29y ZCB2YWx1ZXMgaW4gdGhlIDEuZTE2NC5hcnBhIHpvbmUNCiAgIHdvdWxkIGJlIGFzIGZvbGxvd3M6 DQoNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rDQog ICB8ICAgICAgICAgc2hhcGUgICAgICAgICAgICAgfCBicmFuY2ggbG9jYXRpb24gfA0KICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgNC45Ljcu MS5jYXJyaWVyLmUxNjQuYXJwYSB8ICAgICAgICAwICAgICAgICB8DQogICB8IDQuOS43LmNhcnJp ZXIuMS5lMTY0LmFycGEgfCAgICAgICAgMSAgICAgICAgfA0KICAgfCBjYXJyaWVyLjQuOS43LjEu ZTE2NC5hcnBhIHwgICAgICAgIDQgICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEZpZ3VyZSAxDQoNCiAgIFRoZSBvbmx5IHJlbWFpbmluZyBhLXByaW9yaSBrbm93bGVkZ2Ug YSBDYXJyaWVyIEVOVU0gcmVzb2x2ZXIgc2hvdWxkDQogICBoYXZlIGlzIHRoZSBjdXJyZW50IGxp c3Qgb2YgY291bnRyeSBjb2Rlcywgb3IgYW4gZXF1aXZhbGVudCBtZXRob2QgdG8NCiAgIGRldGVy bWluZSB3aGVyZSB0aGUgY291bnRyeSBjb2RlIGluIHRoZSBudW1iZXIgZW5kcy4NCg0KICAgVG8g cHJpbWUgdGhlIGFsZ29yaXRobSwgdGhlIHRoZSBjdXJyZW50IHNjaGVtZSB0byBkZXRlcm1pbmUg Y291bnRyeQ0KICAgY29kZSBsZW5ndGggYXMgZm9sbG93cyBjb3VsZCBiZSBlbXBsb3llZDoNCiAg IG8gIDMgZGlnaXRzIGlzIHRoZSBkZWZhdWx0IGxlbmd0aCBvZiBhIGNvdW50cnkgY29kZS4NCiAg IG8gIGNvdW50cnkgY29kZXMgMSBhbmQgNyBhcmUgYSBzaW5nbGUgZGlnaXQuDQogICBvICB0aGUg Zm9sbG93aW5nIGNvdW50cnkgY29kZXMgYXJlIHR3byBkaWdpdHM6IDIwLCAyNywgMzAtMzQsIDM2 LCAzOSwNCiAgICAgIDQwLCA0MSwgNDMtNDksIDUxLTU4LCA2MC02NiwgODEsIDgyLCA4NCwgODYs IDkwLTk1LCA5OC4NCg0KICAgR2l2ZW4gdGhlIGZhY3QgdGhhdCB0aGUgSVRVIHJlY2VudGx5IGFs bG9jYXRlZCBvbmx5IDMtZGlnaXQgY291bnRyeQ0KICAgY29kZXMsIHRoZXJlIGFyZSBubyBtb3Jl IHNwYXJlIDEtIGFuZCAyLWRpZ2l0IGNvdW50cnkgY29kZXMgYW5kDQogICBleGlzdGluZyAxLSBh bmQgMi1kaWdpdCBjb3VudHJ5IGNvZGVzIGFyZSBleHRyZW1lbHkgdW5saWtlbHkgdG8gYmUNCiAg IHJlY292ZXJlZCwgdGhlIGFib3ZlIHRhYmxlIGNvbnNpc3Rpbmcgb2YgdGhlIGV4aXN0aW5nIDEt IGFuZCAyLWRpZ2l0DQogICBjb3VudHJ5IGNvZGVzIGNhbiBiZSBjb25zaWRlcmVkIHZlcnkgc3Rh YmxlLiAgVGhlIG9ubHkgcHJvYmxlbSBtYXkgYmUNCiAgIGEgY291bnRyeSBzcGxpdCBhcyBoYXBw ZW5lZCByZWNlbnRseSBlLmcuIHRvIFl1Z29zbGF2aWEuDQoNCiAgIElmIGEgYnJhbmNoIGxvY2F0 aW9uIHJlY29yZCBpcyBub3QgZm91bmQgdGhhdCB3YXkgKGZvciBpbnN0YW5jZSwgaW4NCiAgIHRo ZSB1bmxpa2VseSBjYXNlIHRoZSBJVFUgYWxsb2NhdGVzIGEgY291bnRyeSBjb2RlIG5vdCBhY2Nv cmRpbmcgdG8NCg0KDQoNCkhhYmVybGVyICYgU3Rhc3RueSAgICAgICBFeHBpcmVzIEFwcmlsIDI0 LCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg Q29tYmluZWQgVXNlciBhbmQgQ2FycmllciBFTlVNICAgICAgICAgT2N0b2JlciAyMDA1DQoNCg0K ICAgdGhlc2UgcnVsZXMpLCBpdCBpcyBzdGlsbCBwb3NzaWJsZSB0byBkZXRlcm1pbmUgdGhlIGJy YW5jaCBsb2NhdGlvbg0KICAgcmVjb3JkIGJ5ICJpdGVyYXRpbmcgZG93biIgdGhlIHRyZWUuICBT dWNoIGEgZmFsbGJhY2sgc3RyYXRlZ3kgd291bGQNCiAgIHJlbHkgb24gdGhlIGFzc3VtcHRpb24g dGhhdCB0aGVyZSBpcyBuZXZlciBhIGJyYW5jaCBsb2NhdGlvbiByZWNvcmQNCiAgIGluc2VydGVk IGFib3ZlIHRoZSBjb3VudHJ5IGNvZGUgem9uZSwgZm9yIHdoaWNoIHRoZXJlIHdvdWxkIGJlIG5v IHVzZQ0KICAgaW4gdGhlIGZpcnN0IHBsYWNlLg0KDQogICBJdCBzZWVtcyB1bmxpa2VseSB0aGF0 IGluc3BlY3Rpb24gb2YgbW9yZSB0aGFuIHRoZSBmaXJzdCBmaXZlIGRpZ2l0cw0KICAgd2lsbCBi ZSByZXF1aXJlZCB0byBsb2NhdGUgdGhlIGJyYW5jaCBsb2NhdGlvbiByZWNvcmQgdW5kZXIgYW55 DQogICByZWFsaXN0aWMgbnVtYmVyaW5nIGFkbWluaXN0cmF0aXZlIHBhcnRpdGlvbmluZy4NCg0K Ni4gIFJlY29tbWVuZGVkIHJlc29sdmVyIGJlaGF2aW91cg0KDQogICBBIFVzZXIgRU5VTSByZXNv bHZlciBhcyBwZXIgUkZDMzc2MSBuZWVkIG5vdCBiZSBhd2FyZSBvZiBhbnkgQ2Fycmllcg0KICAg RU5VTSBjb252ZW50aW9ucyBhdCBhbGwuICBBIGNvbWJpbmVkIFVzZXIgYW5kIENhcnJpZXIgRU5V TSByZXNvbHZlcg0KICAgc2hhbGwgYmVoYXZlIGFzIGZvbGxvd3M6DQoNCiAgIFRoZSBpbnB1dCB0 byB0aGUgcmVzb2x2ZXIgcm91dGluZSBzaGFsbCBiZToNCiAgIDEuICB0aGUgY2FsbGVkIG51bWJl ciBpbiBmdWxseSBxdWFsaWZpZWQgRS4xNjQgKGludGVybmF0aW9uYWwpDQogICAgICAgZm9ybWF0 LA0KICAgMi4gIGEgJ3N1YnRyZWUnIHBhcmFtZXRlciBpbmRpY2F0aW5nIHdoZXRoZXIgdGhlIHNl YXJjaCBzaG91bGQNCiAgICAgICBwcm9jZWVkIGluIHRoZSBVc2VyIEVOVU0gdHJlZSwgb3IgaW4g dGhlIHN1YnRyZWUgaW5kaWNhdGVkIGJ5IHRoZQ0KICAgICAgIHBhcmFtZXRlciAoZXhhbXBsZTog J2NhcnJpZXInIHRvIGluZGljYXRlIENhcnJpZXIgRU5VTQ0KICAgICAgIHJlc29sdXRpb24sIG9y IGEgbnVsbCB2YWx1ZSBmb3IgZGVmYXVsdGluZyB0byBVc2VyIEVOVU0NCiAgICAgICByZXNvbHV0 aW9uKSwNCiAgIDMuICBvcHRpb25hbGx5IGEgdGFibGUgb3IgYWxnb3JpdGhtIHRvIGVhc2lseSBk ZXRlY3QgY291bnRyeSBjb2Rlcw0KICAgICAgIChTZWN0aW9uIDUpLA0KICAgNC4gIGFueSBvdGhl ciBwYXJhbWV0ZXJzIHVzZWQgdG8gZHJpdmUgdGhlIHNlYXJjaCwgZm9yIGluc3RhbmNlIGFuDQog ICAgICAgZW51bXNlcnZpY2UgdHlwZS4gIFRoZXNlIHBhcmFtZXRlcnMgYXJlIG91dHNpZGUgdGhl IHNjb3BlIG9mIHRoaXMNCiAgICAgICBkcmFmdC4NCg0KICAgVGhlIHJlc29sdmVyIHNoYWxsIHBy b2NlZWQgYXMgZm9sbG93czoNCiAgIDEuICBpZiB0aGUgc3VidHJlZSBwYXJhbWV0ZXIgaW5kaWNh dGVzIGEgVXNlciBFTlVNIHNlYXJjaCwgcHJvY2VlZCBhcw0KICAgICAgIHBlciBSRkMzNzYxLg0K ICAgMi4gIElmIHRoZSBzdWJ0cmVlIHBhcmFtZXRlciBpbmRpY2F0ZXMgYSBDYXJyaWVyIEVOVU0g cXVlcnk6DQogICAgICAgMS4gIGRldGVybWluZSBjb3VudHJ5IGNvZGUgbGVuZ3RoLg0KICAgICAg IDIuICBjb25zdWx0IGNhY2hlIHRhYmxlIGlmIGEgYnJhbmNoIGxvY2F0aW9uIGZvciB0aGlzIGNv dW50cnkNCiAgICAgICAgICAgY29kZSB3YXMgYWxyZWFkeSByZXRyaWV2ZWQgc2luY2UgcmVzb2x2 ZXIgYm9vdCB0aW1lLg0KICAgICAgIDMuICBpZiBub3Q6DQogICAgICAgICAgICAgIHJldHJpZXZl IHRoZSBicmFuY2ggbG9jYXRpb24gcmVjb3JkIGZyb20gdGhlIGNvdW50cnkgY29kZQ0KICAgICAg ICAgICAgICB6b25lLCBhbmQgc3RvcmUgdGhlIGNvdW50cnkgY29kZS9icmFuY2ggbG9jYXRpb24g cGFpciBpbg0KICAgICAgICAgICAgICB0aGUgY2FjaGUgdGFibGUuDQogICAgICAgICAgICAgICgi aXRlcmF0aW5nIGRvd24iIC0gb3B0aW9uYWwgZmFsbGJhY2sgZm9yIGlycmVndWxhcg0KICAgICAg ICAgICAgICBjb3VudHJ5IGNvZGUpIGlmIHRoZSBsYXN0IHN0ZXAgZmFpbHMsIGl0ZXJhdGUgb3Zl ciB0aGUNCiAgICAgICAgICAgICAgbnVtYmVyIHVwIHRvIGZpdmUgZGlnaXRzIGFuZCB0cnkgdG8g cmV0cmlldmUgdGhlIGJyYW5jaA0KICAgICAgICAgICAgICBsb2NhdGlvbiByZWNvcmQgZWFjaCB0 aW1lLCBhZ2FpbiBzdG9yaW5nIHRoZSBjb3VudHJ5IGNvZGUvDQogICAgICAgICAgICAgIGJyYW5j aCBsb2NhdGlvbiBwYWlyIGluIHRoZSBjYWNoZSB0YWJsZSBpZiBzdWNjZXNzZnVsLg0KDQoNCg0K DQoNCkhhYmVybGVyICYgU3Rhc3RueSAgICAgICBFeHBpcmVzIEFwcmlsIDI0LCAyMDA2ICAgICAg ICAgICAgICAgICBbUGFnZSA3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgQ29tYmluZWQgVXNl ciBhbmQgQ2FycmllciBFTlVNICAgICAgICAgT2N0b2JlciAyMDA1DQoNCg0KICAgICAgICAgICAg ICBpZiBib3RoIGF0dGVtcHRzIGZhaWwsIHJldHVybiBmYWlsdXJlIGFuZCBpbmRpY2F0ZQ0KICAg ICAgICAgICAgICBOWERPTUFJTi4NCiAgICAgICA0LiAgKHZhbGlkIGJyYW5jaCBsb2NhdGlvbiBm b3VuZCk6IGluc2VydCB0aGUgY2FycmllciBsYWJlbA0KICAgICAgICAgICBhY2NvcmRpbmdseSB3 aGlsZSBjcmVhdGluZyB0aGUgaW52ZXJ0ZWQgZG90dGVkIGRvbWFpbiBuYW1lLg0KICAgICAgIDUu ICBzZWFyY2ggdGhlIEROUyBmb3IgYW55IE5BUFRSIHJlY29yZHMgZm9yIHRoZSBnaXZlbiBudW1i ZXIuDQoNCiAgIEl0IGlzIGFzc3VtZWQgdGhhdCBhbHJlYWR5IGRpc2NvdmVyZWQgYnJhbmNoIGxv Y2F0aW9uIHZhbHVlcyBhcmUNCiAgIHN0b3JlZCBpbiBhIGNhY2hlIHRhYmxlIG9mIGNvdW50cnkg Y29kZS9icmFuY2ggbG9jYXRpb24gcGFpcnMuDQoNCjcuICBab25lIGZpbGUgZXhhbXBsZXMNCg0K ICAgRXhhbXBsZSAxIC0gY2FycmllciBzdWJ0cmVlIGJyYW5jaGVzIG9mIHJpZ2h0IHVuZGVyIHRo ZSBjb3VudHJ5IGNvZGUNCiAgICs0MyBsZXZlbCwgem9uZSBmaWxlcyBmb3IgY291bnRyeSBjb2Rl IHpvbmUgYW5kIGNhcnJpZXIgc3VidHJlZSB6b25lLg0KICAgVGhlIEJMUiBoYXBwZW5zIHRvIGJl IGF0IHRoZSBzYW1lIGxldmVsIGFzIHRoZSBjYXJyaWVyIHN1YnRyZWUuDQogICBTaW5jZSB0aGV5 IHVzZSB0aGUgc2FtZSBuYW1lLCB0aGUgQkxSIG5lZWRzIHRvIGJlIGJlbG93IHRoZSB6b25lIGN1 dA0KICAgaW4gdGhlIGNhcnJpZXIuMy40LmUxNjQuYXJwYSB6b25lLiAgTm90ZSB0aGVyZSBpcyBu byBjaGFuZ2UgaW4gdGhlDQogICBlMTY0LmFycGEgem9uZSBpbiB0aGlzIGNhc2UsIHRoZSBjYXJy aWVyIHN1YnRyZWUgY2FuIGJlIGludHJvZHVjZWQgYnkNCiAgIG5hdGlvbmFsbHkgd2l0aG91dCBm dXJ0aGVyIGV4dGVybmFsIGludGVyYWN0aW9uLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSGFiZXJsZXIgJiBTdGFzdG55 ICAgICAgIEV4cGlyZXMgQXByaWwgMjQsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICBDb21iaW5lZCBVc2VyIGFuZCBDYXJyaWVyIEVOVU0gICAg ICAgICBPY3RvYmVyIDIwMDUNCg0KDQogICA7ICs0MyBjb3VudHJ5IGNvZGUgem9uZQ0KDQogICAk T1JJR0lOIDMuNC5lMTY0LmFycGEuDQoNCiAgIEAgICAgICAgICAgICAgICAgICBOUyAgICAgIG5z MS5lbnVtLmF0Lg0KDQogICBAICAgICAgICAgICAgICAgICAgTlMgICAgICBuczIuZW51bS5hdC4N Cg0KICAgOyBjYXJyaWVyIHN1YnRyZWUgc3RhcnRzIGhlcmUNCg0KICAgY2FycmllciAgICAgICAg ICAgIElOICAgICAgTlMgICAgICBuczEtY2UuZW51bS5hdC4NCg0KICAgY2FycmllciAgICAgICAg ICAgIElOICAgICAgTlMgICAgICBuczItY2UuZW51bS5hdC4NCg0KICAgOyBCTFIgaXMgYXQgdGhl IHNhbWUgbGFiZWwsIHRodXMgaW4gdGhlIHN1YmRvbWFpbi4NCg0KDQoNCiAgIDsgdG9wIG9mICs0 MyBDYXJyaWVyIHN1YnRyZWUgem9uZQ0KDQogICAkT1JJR0lOIGNhcnJpZXIuMy40LmUxNjQuYXJw YS4NCg0KICAgQCAgICAgICAgICAgICAgICAgIE5TICAgICAgbnMxLWNlLmVudW0uYXQuDQoNCiAg IEAgICAgICAgICAgICAgICAgICBOUyAgICAgIG5zMi1jZS5lbnVtLmF0Lg0KDQogICA7IEJyYW5j aCBsb2NhdGlvbiByZWNvcmQgLSB2YWx1ZSAyDQogICA7IG1lYW5pbmcgY2FycmllciBzdWJ0cmVl IHN0YXJ0cyBpbiBDQyB6b25lOg0KDQogICBAICAgICAgICAgICAgICAgICAgQkxSICAgICAyDQoN CiAgIDsgQ2FycmllciBFTlVNIE5BUFRSIGV4YW1wbGUgZm9yICs0MygxKTIzNDU2DQoNCiAgIDYu NS40LjMuMi4xIE5BUFRSIDEwMCAxMCAidSIgIkUyVStzaXAiICIhXiguKikkIXNpcDpcXDFAdGVs Y28uYXQhIiAuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDIN Cg0KICAgRXhhbXBsZSAyIC0gY291bnRyeSBjb2RlICs3IG9wdGVkIGZvciBjYXJyaWVyIHN1YnRy ZWUgdW5kZXINCiAgIDcuY2Fycmllci5lMTY0LmFycGEsIHdoaWNoIGlzIGRvY3VtZW50ZWQgYnkg dGhlIEJMUiAgd2l0aCB2YWx1ZSAwIGluDQogICB0aGUgNy5lMTY0LmFycGEgem9uZS4gIFRoaXMg aW1wbGllcyBjb25zZW50IHdpdGggSVRVIGFuZCBSSVBFLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpI YWJlcmxlciAmIFN0YXN0bnkgICAgICAgRXhwaXJlcyBBcHJpbCAyNCwgMjAwNiAgICAgICAgICAg ICAgICAgW1BhZ2UgOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIENvbWJpbmVkIFVzZXIgYW5k IENhcnJpZXIgRU5VTSAgICAgICAgIE9jdG9iZXIgMjAwNQ0KDQoNCiAgICRPUklHSU4gNy5lMTY0 LmFycGEuDQoNCiAgIEAgICAgICAgICAgICAgICAgICBOUyAgICAgIG5zMS5lbnVtLnJ1Lg0KDQog ICBAICAgICAgICAgICAgICAgICAgTlMgICAgICBuczIuZW51bS5ydS4NCg0KICAgOw0KDQogICA7 IEJyYW5jaCBsb2NhdGlvbiByZWNvcmQgLSB2YWx1ZSAwLCBtZWFuaW5nIGNhcnJpZXIgdHJlZQ0K ICAgOyBzdGFydHMgaW4gY2Fycmllci5lMTY0LmFycGE6DQoNCiAgIGMgICAgICAgICAgICAgICAg ICBJTiAgICAgIEJMUiAgICAgMA0KDQoNCg0KICAgOyB0b3Agb2YgQ2FycmllciBzdWJ0cmVlIHpv bmUNCg0KICAgJE9SSUdJTiA3LmNhcnJpZXIuZTE2NC5hcnBhLg0KDQogICBAICAgICAgICAgICAg ICAgICAgTlMgICAgICBuczEtY2UuZW51bS5ydS4NCg0KICAgQCAgICAgICAgICAgICAgICAgIE5T ICAgICAgbnMyLWNlLmVudW0ucnUuDQoNCg0KDQogICA7IENhcnJpZXIgRU5VTSBOQVBUUiBleGFt cGxlIGZvciArNyg5MCkxMjM0NQ0KDQogICA1LjQuMy4yLjEuMC45IE5BUFRSIDEwMCAxMCAidSIg IkUyVStzaXAiICIhXiguKikkIXNpcDpcXDFAZm9vLnJ1ISIgLg0KDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAzDQoNCiAgIEV4YW1wbGUgMyAtIGNvdW50cnkgY29k ZSArMSBvcHRlZCBmb3IgY2FycmllciBzdWJ0cmVlIHVuZGVyICsxIChOUEEpLA0KICAgaS5lLiA0 IGRpZ2l0cyBpbnRvIHRoZSBudW1iZXIuICBUaGlzIHdvdWxkIGltcGx5IG9uZSB6b25lIHBlciBO UEEuDQogICBXZSBzaG93IGFuIGV4YW1wbGUgZm9yIHRoZSA3OTQgTlBBLiAgVGhpcyBzY2VuYXJp bywgYWdhaW4sIGNhbiBiZQ0KICAgaW50cm9kdWNlZCB3aXRob3V0IElUVSBhbmQgUklQRSBpbnZv bHZlbWVudC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhhYmVybGVyICYgU3Rhc3Ru eSAgICAgICBFeHBpcmVzIEFwcmlsIDI0LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgQ29tYmluZWQgVXNlciBhbmQgQ2FycmllciBFTlVNICAg ICAgICAgT2N0b2JlciAyMDA1DQoNCg0KICAgJE9SSUdJTiAxLmUxNjQuYXJwYS4NCg0KICAgQCAg ICAgICAgICAgICAgICAgIE5TICAgICAgbnMxLmNjMWVudW0uY2EuDQoNCiAgIEAgICAgICAgICAg ICAgICAgICBOUyAgICAgIG5zMi5jYzFlbnVtLmNhLg0KDQogICA7DQoNCiAgIDsgQnJhbmNoIGxv Y2F0aW9uIHJlY29yZCAtIHZhbHVlIDQNCg0KICAgY2FycmllciAgICAgICAgICAgIEJMUiAgICAg NA0KDQogICA7IGRlbGVnYXRpb24gZm9yIDc5NCBOUEEgLSBVc2VyIEVOVU0NCg0KICAgNC45Ljcg ICAgICAgICAgICAgIElOICAgICAgTlMgbnMxLXVlLmNjMWVudW0ub3JnLg0KDQogICA0LjkuNyAg ICAgICAgICAgICAgSU4gICAgICBOUyBuczItdWUuY2MxZW51bS5vcmcuDQoNCiAgIDsgZGVsZWdh dGlvbiBmb3IgNzk0IE5QQSAtIENhcnJpZXIgRU5VTQ0KDQogICBjYXJyaWVyLjQuOS43ICAgICAg SU4gICAgICBOUyBuczEtY2UuY2MxZW51bS5vcmcuDQoNCiAgIGNhcnJpZXIuNC45LjcgICAgICBJ TiAgICAgIE5TIG5zMi1jZS5jYzFlbnVtLm9yZy4NCg0KDQoNCiAgIDsgQ2FycmllciBzdWJ0cmVl IGZvciArMSA3OTQgTlBBDQoNCiAgICRPUklHSU4gY2Fycmllci40LjkuNy4xLmUxNjQuYXJwYQ0K DQogICBAICAgICAgICAgICAgICAgICAgTlMgICAgICBuczEtY2UuY2MxZW51bS5vcmcuDQoNCiAg IEAgICAgICAgICAgICAgICAgICBOUyAgICAgIG5zMi1jZS5jYzFlbnVtLm9yZy4NCg0KDQoNCiAg IDsgQ2FycmllciBFTlVNIE5BUFRSIGV4YW1wbGUgZm9yICsxKDc5NCkgMTIzIDQ1NjcNCg0KICAg Ny42LjUuNC4zLjIuMSBOQVBUUiAxMDAgMTAgInUiICJFMlUrc2lwIiAiIV4oLiopJCFzaXA6XFwx QGZvby5jb20hIiAuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJl IDQNCg0KDQo4LiAgVGhlIEJyYW5jaCBMb2NhdGlvbiBSZWNvcmQNCg0KICAgVGhlIEJMUiBpcyBs b2NhdGVkIGJlbG93IHRoZSBjb3VudHJ5IGNvZGUgbGV2ZWwgYW5kIGNvbnZleXMgdGhlIG5hbWUN CiAgIGFuZCBsb2NhdGlvbiBvZiBhIHNwZWNpZmljIHN1YnRyZWUuICBJdCBoYXMgdGhlIHNhbWUg bmFtZSBhcyB0aGUNCg0KDQoNCkhhYmVybGVyICYgU3Rhc3RueSAgICAgICBFeHBpcmVzIEFwcmls IDI0LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgQ29tYmluZWQgVXNlciBhbmQgQ2FycmllciBFTlVNICAgICAgICAgT2N0b2JlciAyMDA1DQoN Cg0KICAgc3VidHJlZSBicmFuY2ggbGFiZWwgKHRodXMgYm90aCAnY2FycmllcicgaW4gdGhlIENh cnJpZXIgRU5VTQ0KICAgcmVzb2x1dGlvbiBjb250ZXh0KSBhbmQgcmV0dXJucyBhbiBpbnRlZ2Vy IHZhbHVlLCBpbmRpY2F0aW5nIHRoZQ0KICAgcG9zaXRpb24gaW4gdGhlIG51bWJlciB3aGVyZSB0 aGUgc3VidHJlZSBicmFuY2ggbGFiZWwgaXMgaW5zZXJ0ZWQNCiAgIHdoaWxlIGNvbnN0cnVjdGlu ZyB0aGUgRlFETi4NCg0KICAgV2UgZW52aXNhZ2Ugc2V2ZXJhbCBpbXBsZW1lbnRhdGlvbiBvcHRp b25zLCBzdWNoIGFzOg0KICAgbyAgYSBuZXcgRE5TIFJlc291cmNlIFJlY29yZCAoYXMgdXNlZCBp biB0aGUgem9uZSBmaWxlIGV4YW1wbGVzDQogICAgICBhYm92ZSkNCiAgIG8gIGEgTkFQVFIgcmVj b3JkIHdpdGggYSBuZXcgc2VydmljZSBkZWZpbml0aW9uIGZvciB0aGF0IHB1cnBvc2UuDQogICBv ICBmb3IgdHJpYWwgcHVycG9zZXMsIGEgVFhUIHJlY29yZCBjYXJyeWluZyB0aGUgYnJhbmNoIGxv Y2F0aW9uIGFzDQogICAgICBhbiBpbnRlZ2VyIHZhbHVlIGluIHRoZSBzdHJpbmcgYXJndW1lbnQu DQoNCiAgIFdoaWxlIHRlY2huaWNhbGx5IGVxdWl2YWxlbnQsIHdlIGJlbGlldmUgdGhlIE5BUFRS IG9wdGlvbiB0byBiZSB0aGUNCiAgIG1vc3QgZmxleGlibGUuICBXZSBzb2xpY2l0IHN1Z2dlc3Rp b25zIGZvciB0aGUgZmluYWwgY2hvaWNlLg0KDQogICBOb3RlIHRoYXQgdGhpcyBzY2hlbWUgaXMg ZXh0ZW5zaWJsZTogaWYsIGZvciBleGFtcGxlLCBpdCB3b3VsZCBiZQ0KICAgY29uc2lkZXJlZCB1 c2VmdWwgdG8gY3JlYXRlIHRyZWVzIGZvciBvdGhlciByZXNvbHV0aW9uIGNvbnRleHRzIHRoYW4N CiAgIGNhcnJpZXIgRU5VTSwgdGhhdCBjb3VsZCBiZSBkb25lIGJ5IGludHJvZHVjaW5nIGFub3Ro ZXIgbGFiZWwuICBPbmUNCiAgIHN1Y2ggZXhhbXBsZSBjb3VsZCBiZSB0aGUgJ2NhcnJpZXIgZGVm YXVsdCByZWdpc3RyYXRpb24nIChudW1iZXINCiAgIHJhbmdlIGFsbG9jYXRpb24gaW5mb3JtYXRp b24pIHJlY2VudGx5IHN1Z2dlc3RlZCBieSB0aGUgVUsgRU5VTQ0KICAgZ3JvdXAuDQoNCjkuICBT ZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KDQogICBQcml2YWN5IGlzc3VlcyBoYXZlIGJlZW4gcmFp c2VkIHJlZ2FyZGluZyB1bndhcnJhbnRlZCBkaXNjbG9zdXJlIG9mDQogICB1c2VyIGluZm9ybWF0 aW9uIGJ5IHB1Ymxpc2hpbmcgQ2FycmllciBFTlVNIGluZm9ybWF0aW9uIGluIHRoZSBwdWJsaWMN CiAgIEROUywgZm9yIGluc3RhbmNlIHRoZSB1c2UgZm9yIGhhcnZlc3Rpbmcgb2YgbnVtYmVycyBp biBzZXJ2aWNlLCBvcg0KICAgdW5saXN0ZWQgbnVtYmVycy4NCg0KICAgR2l2ZW4gdGhhdCBudW1i ZXIgcmFuZ2UgYWxsb2NhdGlvbiBpcyBwdWJsaWMgaW5mb3JtYXRpb24sIHdlIGJlbGlldmUNCiAg IHRoZSBlYXNpZXN0IHdheSB0byBjb3BlIHdpdGggc3VjaCBjb25jZXJucyBpcyB0byBmdWxseSB1 bnJvbGwNCiAgIGFsbG9jYXRlZCBudW1iZXIgcmFuZ2VzIGluIHRoZSBDYXJyaWVyIEVOVU0gc3Vi dHJlZSwgd2hlcmV2ZXIgc3VjaA0KICAgcHJpdmFjeSBjb25jZXJucyBleGlzdC4gIFdoZXRoZXIg YSBudW1iZXIgaXMgc2VydmVkIG9yIG5vdCB3b3VsZCBiZQ0KICAgZXhwb3NlZCBieSB0aGUgY2Fy cmllciBvZiByZWNvcmQgd2hlbiBhbiBhdHRlbXB0IGlzIG1hZGUgdG8gY29udGFjdA0KICAgdGhl IGNvcnJlc3BvbmRpbmcgVVJJLiAgV2UgYXNzdW1lIHRoaXMgdG8gYmUgYW4gYXV0aGVudGljYXRl ZA0KICAgb3BlcmF0aW9uLCB3aGljaCB3b3VsZCBub3QgbGVhayBpbmZvcm1hdGlvbiB0byB1bmF1 dGhvcml6ZWQgcGFydGllcy4NCg0KICAgRW50ZXJpbmcgYWxsIG51bWJlcnMgaW4gYW4gYWxsb2Nh dGVkIG51bWJlciByYW5nZSwgd2hldGhlciBzZXJ2aWNlZA0KICAgb3Igbm90LCBvciBsaXN0ZWQg b3IgdW5saXN0ZWQsIHdpbGwgcHJldmVudCBtaW5pbmcgYXR0ZW1wdHMgZm9yIHN1Y2gNCiAgIG51 bWJlciBhdHRyaWJ1dGVzLg0KDQogICBUaGUgcmVzdWx0IHdvdWxkIGJlIHRoYXQgdGhlIGluZm9y bWF0aW9uIGluIHRoZSBwdWJsaWMgRE5TIHdvdWxkDQogICBtaXJyb3IgbnVtYmVyIHJhbmdlIGFs bG9jYXRpb24gaW5mb3JtYXRpb24sIGJ1dCBub3QgbW9yZS4gIENhcnJpZXINCiAgIEVOVU0gd2ls bCBub3QgdGVsbCB5b3UgbW9yZSB0aGFuIHlvdSBjYW4gZ2V0IGJ5IGp1c3QgZGlhbGluZyBudW1i ZXJzLg0KDQogICBUaGUgVVJJIHBvaW50aW5nIHRvIHRoZSBkZXN0aW5hdGlvbiBuZXR3b3JrIG9m IHRoZSBDYXJyaWVyIG9mIFJlY29yZA0KICAgc2hvdWxkIGFsc28gbm90IGRpc2Nsb3NlIGFueSBw cml2YWN5IGluZm9ybWF0aW9uIGFib3V0IHRoZSBpZGVudGl0eQ0KICAgb2YgZW5kLXVzZXIsIGl0 IGlzIHRoZXJlZm9yZSByZWNvbW1lbmRlZCB0byB1c2UgaW4gdGhlIHVzZXItcGFydCBvZg0KDQoN Cg0KSGFiZXJsZXIgJiBTdGFzdG55ICAgICAgIEV4cGlyZXMgQXByaWwgMjQsIDIwMDYgICAgICAg ICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBDb21iaW5lZCBVc2Vy IGFuZCBDYXJyaWVyIEVOVU0gICAgICAgICBPY3RvYmVyIDIwMDUNCg0KDQogICB0aGUgU0lQIFVS SSBlaXRoZXIgYW5vbnltaXplZCBVc2VySURzIG9yIHRoZSBFLjE2NCBudW1iZXIgaXRzZWxmLA0K ICAgc3VjaCBhcyBzaXA6NDQxNjMyOTYwMDg0QGV4YW1wbGUudGVsY28uY29tIC4NCg0KICAgVGhl IGRlZmluaXRpb24gb2YgYSBuZXcgUlIgdHlwZSBvciBhIG5ldyBlbnVtc2VydmljZSBkb2VzIG5v dA0KICAgaW50cm9kdWNlIHNlY3VyaXR5IHByb2JsZW1zIGludG8gdGhlIEROUy4gIFVzYWdlIG9m IHRoZSBCcmFuY2gNCiAgIExvY2F0aW9uIHJlY29yZCBjb252ZXlzIG9ubHkgc3RhdGljIHNldHVw IGluZm9ybWF0aW9uIHVuZGVyIGEgY291bnRyeQ0KICAgY29kZSBzdWJ0cmVlIG9mIGUxNjQuYXJw YS4gIFRoZSBpbnRlbmRlZCB1c2Ugb2YgRE5TU0VDIHdpdGhpbiBFTlVNDQogICB3aWxsIHByb3Zl IGF1dGhlbnRpY2l0eSBvZiB0aGUgY29udmV5ZWQgdmFsdWUuDQoNCjEwLiAgSUFOQSBjb25zaWRl cmF0aW9ucw0KDQogICBUaGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgbmVlZCB0byBiZSByZWdpc3Rl cmVkIHdpdGggSUFOQToNCg0KICAgMS4gIFRoZSBuYW1lIG9mIHRoZSBDYXJyaWVyIEVOVU0gc3Vi ZG9tYWluLCBmb3IgZXhhbXBsZSAnY2FycmllcicgKG9yDQogICAgICAgJ2MnIGZvciBicmV2aXR5 KS4gIEluIHRoZSBmdXR1cmUgb3RoZXIgbGFiZWxzIGNvdWxkIGJlIHJlZ2lzdGVyZWQNCiAgICAg ICBmb3IgZGlmZmVyZW50IHB1cnBvc2VzLg0KICAgMi4gIEFjY29yZGluZyB0byBSRkMgMzc2MSwg dGhlIElFVEYgcmVxdWVzdGVkIElBTkEgdG8gZGVsZWdhdGUgdGhlDQogICAgICAgRTE2NC5BUlBB IGRvbWFpbiBmb2xsb3dpbmcgaW5zdHJ1Y3Rpb25zIHByb3ZpZGVkIGJ5IHRoZSBJQUIuDQogICAg ICAgTmFtZXMgd2l0aGluIHRoaXMgem9uZSBhcmUgdG8gYmUgZGVsZWdhdGVkIHRvIHBhcnRpZXMg YWNjb3JkaW5nDQogICAgICAgdG8gdGhlIElUVS1UIFJlY29tbWVuZGF0aW9uIEUuMTY0LiAgSWYg dGhlIHNlY29uZCBvcHRpb24gb3V0bGluZWQNCiAgICAgICBpbiB0aGlzIHByb3Bvc2FsIGlzIGFj Y2VwdGVkLCB0aGVyZSB3aWxsIGJlIG5vIGNoYW5nZXMgcmVxdWVzdGVkDQogICAgICAgb2YgSUFO QSB3aXRoIHJlc3BlY3QgdG8gdGhlIEUxNjQuQVJQQSBkb21haW4uICBIb3dldmVyLCBpZiB0aGUN CiAgICAgICBmaXJzdCBvcHRpb24gb3V0bGluZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBhY2NlcHRl ZCwgdGhpcyB3b3VsZA0KICAgICAgIHJlcXVpcmUgSUVURiB0byByZXF1ZXN0IElBTkEgdG8gY3Jl YXRlIGEgbmV3IHN1Yi1kb21haW4NCiAgICAgICBDQVJSSUVSLkUxNjQuQVJQQS4NCiAgIDMuICBm b3IgdGhlIGJyYW5jaCBsb2NhdGlvbiByZWNvcmQsIGFuIFJSIHR5cGUgb3IgTkFQVFIgc2Vydmlj ZQ0KICAgICAgIGRlZmludGlvbi4NCg0KMTEuICBJbnRlcm9wZXJhYmlsaXR5IGNvbnNpZGVyYXRp b25zDQoNCiAgIEEgcmVzb2x2ZXIgbmVlZHMgdG8gaW5kaWNhdGUgd2hpY2ggaW5mb3JtYXRpb24g aXMgcmVxdWVzdGVkIC0gVXNlciBvcg0KICAgQ2FycmllciBFTlVNLCBvciBib3RoLiAgQSB1c2Vy LUVOVU0tb25seSByZXNvbHZlciBuZWVkIG5vdCBiZSBhd2FyZQ0KICAgb2YgdGhlIGNhcnJpZXIg c3VidHJlZSBhbmQgbm8gY2hhbmdlcyB3aXRoIHJlc3BlY3QgdG8gUkZDMzc2MQ0KICAgc2VtYW50 aWNzIGFyZSByZXF1aXJlZC4gIEEgcmVzb2x2ZXIgZGVzaXJpbmcgdG8gcmV0cmlldmUgQ2Fycmll ciBFTlVNDQogICBvciBib3RoIHR5cGVzIG9mIHJlY29yZHMgbmVlZHMgdG8gYmUgYXdhcmUgb2Yg dGhlIGNvbnZlbnRpb25zIGxhaWQNCiAgIG91dCBpbiB0aGlzIGRyYWZ0Lg0KDQoxMi4gIEFja25v d2xlZGdlbWVudHMNCg0KICAgV2UgZ3JhdGVmdWxseSBhY2tub3dsZWRnZSBzdWdnZXN0aW9ucyBh bmQgaW1wcm92ZW1lbnRzIGJ5IEphc29uDQogICBMaXZpbmdvb2QgYW5kIFRvbSBDcmVpZ2h0b24g b2YgQ29tY2FzdCwgUGVubiBQZmF1dHogb2YgQVRULCBvZg0KICAgTGF3cmVuY2UgQ29ucm95IG9m IFJva2UgTWFub3IgUmVzZWFyY2gsIGFuZCBBbGV4YW5kZXIgTWF5cmhvZmVyIGFuZA0KICAgT3Rt YXIgTGVuZGwgb2YgZW51bS5hdC4NCg0KMTMuICBSZWZlcmVuY2VzDQoNCg0KDQoNCg0KDQpIYWJl cmxlciAmIFN0YXN0bnkgICAgICAgRXhwaXJlcyBBcHJpbCAyNCwgMjAwNiAgICAgICAgICAgICAg ICBbUGFnZSAxM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIENvbWJpbmVkIFVzZXIgYW5kIENh cnJpZXIgRU5VTSAgICAgICAgIE9jdG9iZXIgMjAwNQ0KDQoNCjEzLjEgIE5vcm1hdGl2ZSBSZWZl cmVuY2VzDQoNCiAgIFsxXSAgRmFsdHN0cm9tLCBQLiBhbmQgTS4gTWVhbGxpbmcsICJUaGUgRS4x NjQgdG8gVW5pZm9ybSBSZXNvdXJjZQ0KICAgICAgICBJZGVudGlmaWVycyAoVVJJKSBEeW5hbWlj IERlbGVnYXRpb24gRGlzY292ZXJ5IFN5c3RlbSAoREREUykNCiAgICAgICAgQXBwbGljYXRpb24g KEVOVU0pIiwgUkZDIDM3NjEsIEFwcmlsIDIwMDQuDQoNCjEzLjIgIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMNCg0KICAgWzJdICBJVFUtVCwgIlRoZSBJbnRlcm5hdGlvbmFsIFB1YmxpYyBUZWxlY29t bXVuaWNhdGlvbiBOdW1iZXIgUGxhbiIsDQogICAgICAgIFJlY29tbWVuZGF0aW9uIEUuMTY0LCBN YXkgMTk5Ny4NCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAgTWljaGFlbCBIYWJlcmxlcg0K ICAgSW50ZXJuZXQgRm91bmRhdGlvbiBBdXN0cmlhDQogICBXYWVocmluZ2Vyc3RyYXNzZSAzLzE5 DQogICBXaWVuICBBLTEwOTANCiAgIEF1c3RyaWENCg0KICAgUGhvbmU6ICs0MyA2NjQgNDIxMzQ2 NQ0KICAgRW1haWw6IG1haEBldW5ldC5hdA0KICAgVVJJOiAgIGh0dHA6Ly93d3cubmljLmF0L2lw YS8NCg0KDQogICBSaWNoYXJkIFN0YXN0bnkNCiAgIE9lZmVnDQogICBQb3N0Ym94IDE0Nw0KICAg Vmllbm5hICBBLTEwMzANCiAgIEF1c3RyaWENCg0KICAgUGhvbmU6ICs0MyA2NjQgNDIwIDQxMDAN CiAgIEVtYWlsOiByaWNoYXJkLnN0YXN0bnlAb2VmZWcuYXQNCiAgIFVSSTogICBodHRwOi8vd3d3 Lm9lZmVnLmF0DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSGFiZXJsZXIgJiBT dGFzdG55ICAgICAgIEV4cGlyZXMgQXByaWwgMjQsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2Ug MTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBDb21iaW5lZCBVc2VyIGFuZCBDYXJyaWVyIEVO VU0gICAgICAgICBPY3RvYmVyIDIwMDUNCg0KDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVt ZW50DQoNCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRp dHkgb3Igc2NvcGUgb2YgYW55DQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90 aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8NCiAgIHBlcnRhaW4gdG8gdGhlIGlt cGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4NCiAgIHRo aXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNo IHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQg cmVwcmVzZW50IHRoYXQgaXQgaGFzDQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8g aWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24NCiAgIG9uIHRoZSBwcm9jZWR1 cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUNCiAgIGZv dW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVz IG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQ0KICAgYXNzdXJhbmNlcyBvZiBs aWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0KICAgYXR0 ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0 aGUgdXNlIG9mDQogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3Ig dXNlcnMgb2YgdGhpcw0KICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUg SUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lw ci4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0 byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBw bGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQ0KICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVy IHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50DQogICB0aGlzIHN0 YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0DQog ICBpZXRmLWlwckBpZXRmLm9yZy4NCg0KDQpEaXNjbGFpbWVyIG9mIFZhbGlkaXR5DQoNCiAgIFRo aXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92 aWRlZCBvbiBhbg0KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JH QU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTDQogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFO WSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQNCiAgIEVOR0lORUVSSU5H IFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwN CiAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVT RSBPRiBUSEUNCiAgIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklH SFRTIE9SIEFOWSBJTVBMSUVEDQogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBG SVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpDb3B5cmlnaHQgU3RhdGVtZW50 DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDUpLiAgVGhpcyBk b2N1bWVudCBpcyBzdWJqZWN0DQogICB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJp Y3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZA0KICAgZXhjZXB0IGFzIHNldCBmb3J0aCB0 aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4NCg0KDQpBY2tub3ds ZWRnbWVudA0KDQogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBjdXJy ZW50bHkgcHJvdmlkZWQgYnkgdGhlDQogICBJbnRlcm5ldCBTb2NpZXR5Lg0KDQoNCg0KDQpIYWJl cmxlciAmIFN0YXN0bnkgICAgICAgRXhwaXJlcyBBcHJpbCAyNCwgMjAwNiAgICAgICAgICAgICAg ICBbUGFnZSAxNV0NCgwNCg== ------_=_NextPart_001_01C5D648.A058913B Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01C5D648.A058913B-- From enum-bounces@ietf.org Fri Oct 21 10:50:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyE5-0002aF-IC; Fri, 21 Oct 2005 10:50:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyDc-0002M7-NL; Fri, 21 Oct 2005 10:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25788; Fri, 21 Oct 2005 10:49:52 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESyPk-0003rE-VF; Fri, 21 Oct 2005 11:02:37 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ESyDZ-0008Ec-UG; Fri, 21 Oct 2005 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Oct 2005 10:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for Enumservice VOID Author(s) : R. Stastny, et al. Filename : draft-ietf-enum-void-02.txt Pages : 19 Date : 2005-10-21 This document registers the Enumservice 'void' using the URI schemes 'mailto:' and 'http:' as per the IANA registration process defined in the ENUM specification, RFC3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-void-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-void-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-void-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-21094503.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-void-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-void-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-21094503.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Fri Oct 21 10:50:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyEP-0002hq-3m; Fri, 21 Oct 2005 10:50:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyDe-0002Ng-Mx; Fri, 21 Oct 2005 10:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25821; Fri, 21 Oct 2005 10:49:55 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESyPl-0003rd-9Y; Fri, 21 Oct 2005 11:02:38 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ESyDa-0008Fn-C5; Fri, 21 Oct 2005 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Oct 2005 10:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-voice-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for Enumservice Voice Author(s) : R. Brandner, et al. Filename : draft-ietf-enum-voice-01.txt Pages : 14 Date : 2005-10-21 This document registers the ENUMservice "voice" (which has a defined sub-type "tel"), as per the IANA registration process defined in the ENUM specification RFC3761. This service indicates that the contact held in the generated URI can be used to initiate an interactive voice (audio) call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-voice-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-voice-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-voice-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-21103011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-voice-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-voice-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-21103011.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Fri Oct 21 11:02:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyPx-00068I-BA; Fri, 21 Oct 2005 11:02:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyPv-000688-PR for enum@megatron.ietf.org; Fri, 21 Oct 2005 11:02:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28296 for ; Fri, 21 Oct 2005 11:02:36 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESyc1-0004ws-IT for enum@ietf.org; Fri, 21 Oct 2005 11:15:22 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9LF2W0E027537; Fri, 21 Oct 2005 08:02:32 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9LF2W1c027536; Fri, 21 Oct 2005 08:02:32 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 21 Oct 2005 08:02:32 -0700 From: David Meyer To: Stastny Richard Message-ID: <20051021150232.GA27461@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D462C460F@oefeg-s04.oefeg.loc> Mime-Version: 1.0 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C460F@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: aafd3813f49c1dfb11e9623a3ab5d812 Cc: enum@ietf.org, voipeer@lists.uoregon.edu Subject: [Enum] Re: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0307432036==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0307432036== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 20, 2005 at 11:36:19PM +0200, Stastny Richard wrote: > Hi Dave, > =20 > I think this now quite a nice document, also useful for the Carrier ENUM = work > in ENUM WG Thanks, and that is good to hear. > There are some minor typos and I think in section 4.2 > the reference should be to RFC3761 I fixed the reference, sill looking for the typos :-) Dave > =20 > Just for curiosity: > Can anyone out there explain to me what > Layer 4 Peering is? > =20 > cheers > Richard >=20 > ________________________________ >=20 > Von: owner-voipeer@lists.uoregon.edu im Auftrag von David Meyer > Gesendet: Do 20.10.2005 22:21 > An: voipeer@lists.uoregon.edu > Cc: enum@ietf.org > Betreff: [voipeer] draft-meyer-voipeer-terminology-03.txt >=20 >=20 >=20 > Folks, >=20 > Here's the latest on this one (posted here as I'm not > sure what the secretariat's posting rate is these > days). I've included all the comments, AFAICT. >=20 > There had been another suggestion to "harmonize" with > G.8080 terminology, which I am so far resisting > (comments on that)? >=20 >=20 > Thanks, >=20 > Dave >=20 > --- >=20 > Network Working Group D. Meyer > Internet-Draft October 20, 2005 > Expires: April 23, 2006 >=20 >=20 > Terminology for Describing VoIP Peering and Interconnect > draft-meyer-voipeer-terminology-03.txt >=20 > Status of this Memo >=20 > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. >=20 > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. >=20 > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. >=20 > This Internet-Draft will expire on April 23, 2006. >=20 > Copyright Notice >=20 > Copyright (C) The Internet Society (2005). >=20 > Abstract >=20 > This document defines the terminology that is to be used by the Voice > Over IP Peering and Interconnect Working Group (voipeer), and has as > its primary objective to focus the VOIPEER Working Group during its > discussions, and when writing requirements, gap analysis and other > solutions oriented documents. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 1] >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 3. General Definitions . . . . . . . . . . . . . . . . . . . . . 4 > 3.1. Call Routing Data . . . . . . . . . . . . . . . . . . . . 4 > 3.2. Call Routing . . . . . . . . . . . . . . . . . . . . . . . 4 > 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.4. Network . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.5. VoIP Service Provider . . . . . . . . . . . . . . . . . . 5 > 3.6. Carrier . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.7. Peering . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . . . . . . 6 > 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . . . . . . 6 > 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . . . . . . 6 > 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 4.1. Carrier of Record . . . . . . . . . . . . . . . . . . . . 6 > 4.2. Public ENUM . . . . . . . . . . . . . . . . . . . . . . . 6 > 4.3. Private ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 > 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 > 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 > 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 > Intellectual Property and Copyright Statements . . . . . . . . . . 11 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 2] >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > 1. Introduction >=20 > The term "VoIP Peering" has historically been used to describe a wide > variety of aspects pertaining to the interconnection of service > provider networks and to the delivery of SIP call termination over > those interconnections. The discussion of these interconnections has > at times been confused by the fact that the term "peering" is used in > various contexts to relate to interconnection at different levels in > a protocol stack. VoIP peering focuses on how to identify and route > calls at the application layer, and it does not (necessarily) involve > the exchange of packet routing data or media sessions. In > particular, "layer 5 network" is used here to refer to the > interconnection between SIP servers, as opposed to interconnection at > the IP layer ("layer 3"). Finally, the terms "peering" and > "interconnect" are used interchangeably throughout this document. >=20 > This document introduces standard terminology for use in > characterizing VoIP interconnection. Note however, that while this > document is primarily targeted at the VoIP interconnect case, the > terminology described here is applicable to those cases in which > service providers interconnect using SIP signaling for real-time or > quasi-real-time communications. >=20 > The remainder of this document is organized as follows: Section 2 > provides the general context for the VOIPEER Working Group, and > Section 3 provides the general definitions for real-time SIP based > communication, with focus on the VoIP interconnect case. Section 4 > briefly touches on terms from the ENUM Working Group. Finally, > Section 5 provides comments on usage. >=20 >=20 > 2. Context >=20 > Figure 1 depicts the general VoIP interconnect context. In this > case, the caller uses an E.164 number [ITU.E164.1991] as the "name" > of the called user. Note that this E.164 number is not an address, > since at this point we do not have information about where the named > endpoint is located. In the case shown here, an E.164 number is used > as a key to retrieve a NAPTR recored [RFC3404] from the DNS, which in > turn resolved into a SIP URI. Call routing is based on this SIP URI. > The call routing step does not depend on the presence of an E.164 > number; the SIP URI can be advertised in various other ways, such as > on a web page. Finally, note that the subsequent lookup steps, > namely, look up of SRV, A, and AAAA records (as well as any routing > steps below that) are outside the scope of VOIPEER. >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 3] >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > E.164 number <--- Peer Discovery > | > | <--- ENUM lookup of NAPTR in DNS > | > | > | ENUM Working Group Scope > =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | VOIPEER Working Group Scope > | > | > SIP URI <--- Call Routing Data (CRD) > | > | <--- Service Location (Lookup of SRV in DNS) > | > | > Hostname <--- VoIP addressing and session establishment > | > | <---- Lookup of A and AAAA in DNS > | > Ip address > | > | <---- Routing protocols, ARP etc > | > Mac-address >=20 > Figure 1: VoIP Interconnect Context >=20 > The ENUM Working Group is primarily concerned with the acquisition of > Call Routing Data, or CRD (i.e., above the double line in Figure 1), > while the VOIPEER Working Group is focused on the use of such CRD. > Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS > entry), or via any other mechanism available to the user. >=20 >=20 > 3. General Definitions >=20 > 3.1. Call Routing Data >=20 > Call Routing Data, or CRD, is a SIP URI used to route a call (real- > time, voice or other type) to the called domain's ingress point. A > domain's ingress point can be thought of as the location pointed to > by the SRV record that resulted from the resolution of the CRD (i.e., > a SIP URI). >=20 > 3.2. Call Routing >=20 > Call routing is the set of processes, rules, and CRD used to route a > VoIP call to its proper (SIP) destination. More generally, call >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 4] >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > routing can be thought of as the set of processes, rules and CRD > which are used to route a real-time session to its termination > (ingress) point. >=20 > 3.3. PSTN >=20 > The term "PSTN" refers to the Public Switched Telephone Network. In > particular, the PSTN refers to the collection of interconnected > circuit-switched voice-oriented public telephone networks, both > commercial and government-owned. In general, PSTN terminals are > addressed using E.164 numbers, noting that various dial-plans (such > as emergency services dial-plans) may not directly use E.164 numbers. >=20 > 3.4. Network >=20 > For purposes of this document and the VOIPEER and ENUM Working > Groups, a network is defined to be the set of SIP servers and end- > users (customers) that are controlled by a single administrative > domain. The network may also contain end-users who are located on > the PSTN. >=20 > 3.5. VoIP Service Provider >=20 > A VoIP service provider is an entity that provides transport of SIP > signaling (and possibly media streams) to its customers. Such a > service provider may additionally be interconnected with other > service providers; that is, it may "peer" with other service > providers. A VoIP service provider may also interconnect with the > PSTN. >=20 > Note that as soon as a ingress point is advertised via a SRV record, > anyone can find that ingress point and hence can send calls there. > This is very similar to sending mail to a SMTP server based on the > existence of a MX record. >=20 > 3.6. Carrier >=20 > The term carrier is defined to be a service provider authorized to > issue E.164 numbers [ITU.E164.1991] for the provisioning of PSTN > service under the authority of a National Regulatory Authority (NRA). >=20 > 3.7. Peering >=20 > While the precise definition of the term "peering" is the subject of > some debate, peering in general refers to the negotiation of > reciprocal interconnection arrangements, settlement-free or > otherwise, between operationally independent service providers. >=20 >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 5] >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > This document distinguishes two types of peering, Layer 3 Peering and > Layer 5 peering, which are described below. >=20 > 3.7.1. Layer 3 Peering >=20 > Layer 3 peering refers to interconnection of two service providers > for the purposes of exchanging IP packets. Layer 3 peering is > generally agnostic to the IP payload, and is frequently achieved > using a routing protocol such as BGP [RFC1771] to exchange the > required routing information. >=20 > 3.7.2. Layer 5 Peering >=20 > Layer 5 peering refers to interconnection of two service providers > for the purposes of SIP signaling. Note that in the layer 5 peering > case, there is no intervening network. That is, for purposes of this > discussion, there is no such thing as a "Layer 5 Transit Network". >=20 > 3.8. VoIP Peering >=20 > VoIP peering is defined to be a layer 5 peering between two VoIP > providers for purposes of routing real-time (or quasi-real time) call > signaling between their respective customers. Media streams > associated with this signaling (if any) are not constrained to follow > the same set of paths. >=20 >=20 > 4. ENUM >=20 > ENUM [RFC3761] defines how the Domain Name System (DNS) can be used > for identifying available services connected to one E.164 number. >=20 > 4.1. Carrier of Record >=20 > For purposes of this document, "Carrier of Record", or COR, refers to > the entity that provides PSTN service for an E.164 number [I-D.lind- > infrastructure-enum-reqs]. The exact definition of who and what is a > COR is ultimately the responsibility of the relevant national > authority. >=20 > 4.2. Public ENUM >=20 > Public ENUM is generally defined as the set administrative policies > and procedures surrounding the use of the e164.arpa domain for > Telephone Number to URI resolution [RFC3966]. Policies and > procedures for the registration of telephone numbers within all > branches of the e164.arpa tree are Nation State issues by agreement > with the IAB and ITU. National Regulatory Authorities have generally >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 6] >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > defined Public ENUM Registrants as the E.164 number holder as opposed > to the COR that issued the phone number. >=20 > 4.3. Private ENUM >=20 > Private ENUM is generally regarded as one or more technologies > (including DNS and SIP Redirect) that service providers or > enterprises may use to exchange phone number to URI mappings in a > private secure manner. Private ENUM may be used in any mutually > agreed upon domain. Records in Private ENUM may be globally visible > but in most cases are not visible to the global Internet and are > protected using a variety of security technologies such as split-DNS, > VPN's or various forms or authentication and authorization. > Technical comments on issues surrounding split-DNS can be found in > [RFC2826]. >=20 > 4.4. Carrier ENUM >=20 > Carrier ENUM is generally regarded as the use of a separate branch > the e164.arpa tree, such as 4.4.c.e164.arpa to permit service > providers to exchange phone number to URI data in order to find > points of interconnection. The current theory of Carrier ENUM is > that only the COR for a particular E.164 number is permitted to > provision data for that E.164 within that portion of the e164.arpa > tree. >=20 > In carrier ENUM case, only the COR may enter data in the > corresponding domain. The COR may also enter CRD (i.e., a SIP URI) > to allow other VoIP Service Providers to route calls to its network. >=20 > Finally, note that ENUM is not constrained to carry only data (CDR) > as defined by VOIPEER. In particular, an an important class of CRD, > the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are > most frequently used to interconnect with the PSTN directly, and are > out of scope for VOIPEER. On the other hand, PSTN endpoints served > by a COR and reachable via CDR and networks as defined in Section 3.1 > and Section 3.4 are in scope for VOIPEER. >=20 >=20 > 5. Conclusions >=20 >=20 > 6. Acknowledgments >=20 > Many of the definitions were gleaned from detailed discussions on the > VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer, > Jean-Francois Mule, Richard Shocky, and Richard Stastny made valuable > contributions to early revisions of this document. Patrik Faltstrom >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 7] >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > also made many insightful comments to early versions of this draft, > and contributed the basis of Figure 1. >=20 >=20 > 7. Security Considerations >=20 > This document itself introduces no new security considerations. > However, it is important to note that VoIP interconnect has a wide > variety of security issues that should be considered in documents > addressing both protocol and use case analyzes. >=20 >=20 > 8. IANA Considerations >=20 > This document creates no new requirements on IANA namespaces > [RFC2434]. >=20 >=20 > 9. References >=20 > 9.1. Normative References >=20 > [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) > Part Four: The Uniform Resource Identifiers (URI)", > RFC 3404, October 2002. >=20 > [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform > Resource Identifiers (URI) Dynamic Delegation Discovery > System (DDDS) Application (ENUM)", RFC 3761, April 2004. >=20 > [ITU.E164.1991] > International Telecommunications Union, "The International > Public Telecommunication Numbering Plan", ITU- > T Recommendation E.164, 1991. >=20 > [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", > RFC 3966, December 2004. >=20 > 9.2. Informative References >=20 > [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 > (BGP-4)", RFC 1771, March 1995. >=20 > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an > IANA Considerations Section in RFCs", BCP 26, RFC 2434, > October 1998. >=20 > [RFC2826] Internet Architecture Board, "IAB Technical Comment on the >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 8] >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > Unique DNS Root", RFC 2826, May 2000. >=20 > [I-D.lind-infrastructure-enum-reqs] > Lind, S., "Infrastructure ENUM Requirements", > draft-lind-infrastructure-enum-reqs-00 (work in progress), > July 2005. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 9] >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > Author's Address >=20 > David Meyer >=20 > Email: dmm@1-4-5.net >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 10] >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > Intellectual Property Statement >=20 > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. >=20 > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. >=20 > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. >=20 >=20 > Disclaimer of Validity >=20 > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. >=20 >=20 > Copyright Statement >=20 > Copyright (C) The Internet Society (2005). This document is subject > to the rights, licenses and restrictions contained in BCP 78, and > except as set forth therein, the authors retain all their rights. >=20 >=20 > Acknowledgment >=20 > Funding for the RFC Editor function is currently provided by the > Internet Society. >=20 >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 11] >=20 >=20 >=20 >=20 > _________________________________________________________________________= ____ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDWQMIORgD1qCZ2KcRAhO/AJ9+7o+MzSSRoD5iT8smgNhpUazHaACfREA0 dBi6XKmnGZXuX/2NaRg44aE= =3X4l -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- --===============0307432036== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0307432036==-- From enum-bounces@ietf.org Fri Oct 21 11:06:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyTH-0007Jl-Jr; Fri, 21 Oct 2005 11:06:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyTF-0007Ij-Q1 for enum@megatron.ietf.org; Fri, 21 Oct 2005 11:06:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29055 for ; Fri, 21 Oct 2005 11:06:02 -0400 (EDT) Received: from bay103-f20.bay103.hotmail.com ([65.54.174.30] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESyfM-0005Fg-G8 for enum@ietf.org; Fri, 21 Oct 2005 11:18:47 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 21 Oct 2005 08:05:56 -0700 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Fri, 21 Oct 2005 15:05:55 GMT X-Originating-IP: [69.229.210.56] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4616@oefeg-s04.oefeg.loc> From: "Peter Williams" Cc: enum@ietf.org Subject: RE: [Enum] WG: I-D submission draft-haberler-carrier-enum-01 Date: Fri, 21 Oct 2005 08:05:55 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Oct 2005 15:05:56.0405 (UTC) FILETIME=[F01C6E50:01C5D650] X-Spam-Score: 1.8 (+) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org So I REALLY did NOT like this ID, as it continues the traditional debate over the legitimacy of the Carrier ENUM, continuing a debate that is now passe. We must move ON from wheter we want to address the CarrierENUM question in the WG per se, to characterizing it in a wider architecture so that various IETF activities (in various WGs) can co-exist and cooperate. I suggest the document needs a good reorganization, focussing on harmonizing its content with the current I-D set that are fashioning a set of terminology set , and a common reference point for requirements. If modernised, the draft will fit into the improving architecture discussion that is clearly going on in and around the rechartering of the WGs mission to now make Carrier ENUM into a creditable standards track effort. But it was useful to read, in the RFC tradition: it identified to me certain issues that need resolving, structurally within the set of standards under consideration, now that we HAVE (finally) the Carrier ENUM question before us: (1) The I-D identified that current standard track document concerning ENUM means "User ENUM" today - based on a history of dogma and politics. We need to define ENUM as something that is NOT tied to the User ENUM model of provisioning entries, and/or exercising control over zone content. ENUM needs to be a generic telematic service, and associated DNS-level protocols/procedures: User ENUM vs Carrier ENUM are two models for an EMO (ENUM Management Organization) to manage and adminster the generic telematic service (ENUM) at certain access points. Two further models will emerge, if history repeats: so we should prepare architecturally. (2) The interconnects between ENUM providers must be distinguished from the notion of interconnect being used in VOIP Peering. VIOP Peering has a VERY restricted notion of interconnect (the weird and wonderful "layer 5" term), that does not take into account non-SIP usage environments for ENUM, and does not take into account interworking arrangements between ENUM providers cooperating to delivery of a shared ENUM telematic service by those parties, in a particular "Carrier ENUM adminsitrative region" of a public or private tree. (3) All discussion of Carrier ENUM model of deploying an ENUM telematic service should not involve any DNS layer protocol/procedure discussion. Whether an EMO coalition of providers opts to deploy a Carrier ENUM service in the e164.arpa tree (IANA/DARPA controlled) or under another DNS tree (ICANN but not IANA controlled directly), or a walled-garden name service using non Internet domain names, should not influence how Carrier ENUM model is distinguished from User ENUM or the underlying ENUM telematic service. How does one use the above three comments: they are suggestions that address how the content will be appreciated by readers of the future standard, not detailed debating points about text or the underlying politics of the issues. If the authors agree, use the material. If the authors do not agree with the style of the comments, they should ignore them! Peter. >From: "Stastny Richard" >To: >CC: enum@ietf.org >Subject: [Enum] WG: I-D submission draft-haberler-carrier-enum-01 >Date: Fri, 21 Oct 2005 16:03:38 +0200 > >Dear all, > >since I-D submission turn around is very slow currently, here a peek >preview >of our Carrier ENUM draft > >Richard > >________________________________ > >Von: Michael Haberler [mailto:mah@inode.at] >Gesendet: Fr 21.10.2005 15:14 >An: internet-drafts@ietf.org >Cc: richard.shockey@neustar.biz; paf@cisco.com; >Jason_Livingood@cable.comcast.com; Tom_Creighton@cable.comcast.com; Pfautz, >Penn L, NEO; lwc@roke.co.uk; Stastny Richard; axelm@nic.at; lendl@nic.at >Betreff: I-D submission draft-haberler-carrier-enum-01 > > > >Dear IETF I-D team, > >please find attached an updated Internet-Draft submission titled >"Combined User and Carrier ENUM in the e164.arpa tree" - >draft-haberler-carrier-enum-01.txt . > >Abstract: > >ENUM as defined now in RFC3761 is not well suited for the purpose of >interconnection by carriers, as can be seen by the use of various >private tree arrangements based on ENUM mechanisms. A combined >end-user and carrier ENUM tree solution would leverage the ENUM >infrastructure in e164.arpa, increase resolution rates, and decrease >the cost per registered telephone number. This document describes a >minimally invasive scheme to provide both end-user and carrier data in >ENUM. > >This draft is intended for the ENUM working group. > >The draft is also available on my web page at: > >http://mah.priv.at/i-d/draft-haberler-carrier-enum-01.txt >http://mah.priv.at/i-d/draft-haberler-carrier-enum-01.html > >best regards > >Michael Haberler >Internet Foundation Austria >+43 664 4213465 > ><< draft-haberler-carrier-enum-01.txt >> >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 21 11:12:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyZ2-00020y-6n; Fri, 21 Oct 2005 11:12:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyYz-00020f-RX for enum@megatron.ietf.org; Fri, 21 Oct 2005 11:12:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01329 for ; Fri, 21 Oct 2005 11:11:58 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESyl9-0006Af-1o for enum@ietf.org; Fri, 21 Oct 2005 11:24:44 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9LFBtfM027631; Fri, 21 Oct 2005 08:11:55 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9LFBt6q027630; Fri, 21 Oct 2005 08:11:55 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 21 Oct 2005 08:11:55 -0700 From: David Meyer To: "Pfautz, Penn L, NEO" Message-ID: <20051021151155.GB27461@1-4-5.net> References: <34DA635B184A644DA4588E260EC0A25A0B5E3EE2@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0B5E3EE2@ACCLUST02EVS1.ugd.att.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: a6ea8837e8866a83aa68ed7cf9155ec9 Cc: enum@ietf.org, voipeer@lists.uoregon.edu Subject: [Enum] Re: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0368779535==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0368779535== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cmJC7u66zC7hs+87" Content-Disposition: inline --cmJC7u66zC7hs+87 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 21, 2005 at 09:51:17AM -0400, Pfautz, Penn L, NEO wrote: > Dave: > This is a nice start (indeed more than a start). I just have two > comments at this point: >=20 > 1. The definition of carrier in 3.6 is probably too restrictive. I > would not make it contingent on issuance of E.164 numbers but rather > just the provision of PSTN service. I appreciate your use our > carrier-of-record definition in 4.1. How about: 3.6. Carrier A carrier is defined to be a service provider authorized to provision PSTN services. Note that the provision of such services is usually coupled with the authority to issue E.164 numbers [ITU.E164.1991] under the authority of a National Regulatory Authority (NRA). =09 > 2. In reference to Layer 3 Peering (Section 3.7.1) I would like to see > included the concepts that a) peering involves delivery of packets that > terminate on the peer's network and b) peering is done without traffic > settlement charges. I'm ok with a) termination of traffic, but I'd like to avoid discussing SFI more than I have (see section 3.7). So how about: 3.7.1. Layer 3 Peering Layer 3 peering refers to interconnection of two service providers for the purposes of exchanging IP packets which destined for one (or both) of the peer's networks. Layer 3 peering is generally agnostic to the IP payload, and is frequently achieved using a routing protocol such as BGP [RFC1771] to exchange the required routing information. An alternate, perhaps more operational definition of layer 3 peering is that two peers exchange their customer routers (only), and hence any traffic between peers terminates on on the peer's network. =09 Dave --- Network Working Group D. Meyer Internet-Draft October 21, 2005 Expires: April 24, 2006 Terminology for Describing VoIP Peering and Interconnect draft-meyer-voipeer-terminology-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 24, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines the terminology that is to be used by the Voice Over IP Peering and Interconnect Working Group (voipeer), and has as its primary objective to focus the VOIPEER Working Group during its discussions, and when writing requirements, gap analysis and other solutions oriented documents. Meyer Expires April 24, 2006 [Page 1] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. General Definitions . . . . . . . . . . . . . . . . . . . . . 4 3.1. Call Routing Data . . . . . . . . . . . . . . . . . . . . 4 3.2. Call Routing . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Network . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5. VoIP Service Provider . . . . . . . . . . . . . . . . . . 5 3.6. Carrier . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7. Peering . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . . . . . . 6 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . . . . . . 6 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . . . . . . 6 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Carrier of Record . . . . . . . . . . . . . . . . . . . . 6 4.2. Public ENUM . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Private ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Meyer Expires April 24, 2006 [Page 2] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 1. Introduction The term "VoIP Peering" has historically been used to describe a wide variety of aspects pertaining to the interconnection of service provider networks and to the delivery of SIP call termination over those interconnections. The discussion of these interconnections has at times been confused by the fact that the term "peering" is used in various contexts to relate to interconnection at different levels in a protocol stack. VoIP peering focuses on how to identify and route calls at the application layer, and it does not (necessarily) involve the exchange of packet routing data or media sessions. In particular, "layer 5 network" is used here to refer to the interconnection between SIP servers, as opposed to interconnection at the IP layer ("layer 3"). Finally, the terms "peering" and "interconnect" are used interchangeably throughout this document. This document introduces standard terminology for use in characterizing VoIP interconnection. Note however, that while this document is primarily targeted at the VoIP interconnect case, the terminology described here is applicable to those cases in which service providers interconnect using SIP signaling for real-time or quasi-real-time communications. The remainder of this document is organized as follows: Section 2 provides the general context for the VOIPEER Working Group, and Section 3 provides the general definitions for real-time SIP based communication, with focus on the VoIP interconnect case. Section 4 briefly touches on terms from the ENUM Working Group. Finally, Section 5 provides comments on usage. 2. Context Figure 1 depicts the general VoIP interconnect context. In this case, the caller uses an E.164 number [ITU.E164.1991] as the "name" of the called user. Note that this E.164 number is not an address, since at this point we do not have information about where the named endpoint is located. In the case shown here, an E.164 number is used as a key to retrieve a NAPTR recored [RFC3404] from the DNS, which in turn resolved into a SIP URI. Call routing is based on this SIP URI. The call routing step does not depend on the presence of an E.164 number; the SIP URI can be advertised in various other ways, such as on a web page. Finally, note that the subsequent lookup steps, namely, lookup of SRV, A, and AAAA records (as well as any routing steps below that) are outside the scope of VOIPEER. Meyer Expires April 24, 2006 [Page 3] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 E.164 number <--- Peer Discovery | | <--- ENUM lookup of NAPTR in DNS | | | ENUM Working Group Scope =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | VOIPEER Working Group Scope | | SIP URI <--- Call Routing Data (CRD) | | <--- Service Location (Lookup of SRV in DNS) | | Hostname <--- VoIP addressing and session establishment | | <---- Lookup of A and AAAA in DNS | Ip address | | <---- Routing protocols, ARP etc | Mac-address Figure 1: VoIP Interconnect Context The ENUM Working Group is primarily concerned with the acquisition of Call Routing Data, or CRD (i.e., above the double line in Figure 1), while the VOIPEER Working Group is focused on the use of such CRD. Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS entry), or via any other mechanism available to the user. 3. General Definitions 3.1. Call Routing Data Call Routing Data, or CRD, is a SIP URI used to route a call (real- time, voice or other type) to the called domain's ingress point. A domain's ingress point can be thought of as the location pointed to by the SRV record that resulted from the resolution of the CRD (i.e., a SIP URI). 3.2. Call Routing Call routing is the set of processes, rules, and CRD used to route a VoIP call to its proper (SIP) destination. More generally, call Meyer Expires April 24, 2006 [Page 4] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 routing can be thought of as the set of processes, rules and CRD which are used to route a real-time session to its termination (ingress) point. 3.3. PSTN The term "PSTN" refers to the Public Switched Telephone Network. In particular, the PSTN refers to the collection of interconnected circuit-switched voice-oriented public telephone networks, both commercial and government-owned. In general, PSTN terminals are addressed using E.164 numbers, noting that various dial-plans (such as emergency services dial-plans) may not directly use E.164 numbers. 3.4. Network For purposes of this document and the VOIPEER and ENUM Working Groups, a network is defined to be the set of SIP servers and end- users (customers) that are controlled by a single administrative domain. The network may also contain end-users who are located on the PSTN. 3.5. VoIP Service Provider A VoIP service provider is an entity that provides transport of SIP signaling (and possibly media streams) to its customers. Such a service provider may additionally be interconnected with other service providers; that is, it may "peer" with other service providers. A VoIP service provider may also interconnect with the PSTN. Note that as soon as a ingress point is advertised via a SRV record, anyone can find that ingress point and hence can send calls there. This is very similar to sending mail to a SMTP server based on the existence of a MX record. 3.6. Carrier A carrier is defined to be a service provider authorized to provision PSTN services. Note that the provision of such services is usually coupled with the authority to issue E.164 numbers [ITU.E164.1991] under the authority of a National Regulatory Authority (NRA). 3.7. Peering While the precise definition of the term "peering" is the subject of some debate, peering in general refers to the negotiation of reciprocal interconnection arrangements, settlement-free or otherwise, between operationally independent service providers. Meyer Expires April 24, 2006 [Page 5] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 This document distinguishes two types of peering, Layer 3 Peering and Layer 5 peering, which are described below. 3.7.1. Layer 3 Peering Layer 3 peering refers to interconnection of two service providers for the purposes of exchanging IP packets which destined for one (or both) of the peer's networks. Layer 3 peering is generally agnostic to the IP payload, and is frequently achieved using a routing protocol such as BGP [RFC1771] to exchange the required routing information. An alternate, perhaps more operational definition of layer 3 peering is that two peers exchange their customer routers (only), and hence any traffic between peers terminates on on the peer's network. 3.7.2. Layer 5 Peering Layer 5 peering refers to interconnection of two service providers for the purposes of SIP signaling. Note that in the layer 5 peering case, there is no intervening network. That is, for purposes of this discussion, there is no such thing as a "Layer 5 Transit Network". 3.8. VoIP Peering VoIP peering is defined to be a layer 5 peering between two VoIP providers for purposes of routing real-time (or quasi-real time) call signaling between their respective customers. Media streams associated with this signaling (if any) are not constrained to follow the same set of paths. 4. ENUM ENUM [RFC3761] defines how the Domain Name System (DNS) can be used for identifying available services connected to one E.164 number. 4.1. Carrier of Record For purposes of this document, "Carrier of Record", or COR, refers to the entity that provides PSTN service for an E.164 number [I-D.lind- infrastructure-enum-reqs]. The exact definition of who and what is a COR is ultimately the responsibility of the relevant NRA. 4.2. Public ENUM Public ENUM is generally defined as the set administrative policies and procedures surrounding the use of the e164.arpa domain for Meyer Expires April 24, 2006 [Page 6] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Telephone Number to URI resolution [RFC3761]. Policies and procedures for the registration of telephone numbers within all branches of the e164.arpa tree are Nation State issues by agreement with the IAB and ITU. National Regulatory Authorities have generally defined Public ENUM Registrants as the E.164 number holder as opposed to the COR that issued the phone number. 4.3. Private ENUM Private ENUM is generally regarded as one or more technologies (including DNS and SIP Redirect) that service providers or enterprises may use to exchange phone number to URI mappings in a private secure manner. Private ENUM may be used in any mutually agreed upon domain. Records in Private ENUM may be globally visible but in most cases are not visible to the global Internet and are protected using a variety of security technologies such as split-DNS, VPN's or various forms or authentication and authorization. Technical comments on issues surrounding split-DNS can be found in [RFC2826]. 4.4. Carrier ENUM Carrier ENUM is generally regarded as the use of a separate branch the e164.arpa tree, such as 4.4.c.e164.arpa to permit service providers to exchange phone number to URI data in order to find points of interconnection. The current theory of Carrier ENUM is that only the COR for a particular E.164 number is permitted to provision data for that E.164 within that portion of the e164.arpa tree. In carrier ENUM case, only the COR may enter data in the corresponding domain. The COR may also enter CRD (i.e., a SIP URI) to allow other VoIP Service Providers to route calls to its network. Finally, note that ENUM is not constrained to carry only data (CDR) as defined by VOIPEER. In particular, an an important class of CRD, the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are most frequently used to interconnect with the PSTN directly, and are out of scope for VOIPEER. On the other hand, PSTN endpoints served by a COR and reachable via CDR and networks as defined in Section 3.1 and Section 3.4 are in scope for VOIPEER. 5. Conclusions 6. Acknowledgments Meyer Expires April 24, 2006 [Page 7] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Many of the definitions were gleaned from detailed discussions on the VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer, Jean-Francois Mule, Richard Shocky, and Richard Stastny made valuable contributions to early revisions of this document. Patrik Faltstrom also made many insightful comments to early versions of this draft, and contributed the basis of Figure 1. 7. Security Considerations This document itself introduces no new security considerations. However, it is important to note that VoIP interconnect has a wide variety of security issues that should be considered in documents addressing both protocol and use case analyzes. 8. IANA Considerations This document creates no new requirements on IANA namespaces [RFC2434]. 9. References 9.1. Normative References [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [ITU.E164.1991] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU- T Recommendation E.164, 1991. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. 9.2. Informative References [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an Meyer Expires April 24, 2006 [Page 8] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000. [I-D.lind-infrastructure-enum-reqs] Lind, S., "Infrastructure ENUM Requirements", draft-lind-infrastructure-enum-reqs-00 (work in progress), July 2005. Meyer Expires April 24, 2006 [Page 9] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Author's Address David Meyer Email: dmm@1-4-5.net Meyer Expires April 24, 2006 [Page 10] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Meyer Expires April 24, 2006 [Page 11] =0C --cmJC7u66zC7hs+87 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDWQU7ORgD1qCZ2KcRAqKcAJ9QJuO47U6tNCxv4PdhPg1k8hDf3gCfRW8O zoBe5xDjimh03temjMMvaek= =66sn -----END PGP SIGNATURE----- --cmJC7u66zC7hs+87-- --===============0368779535== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0368779535==-- From enum-bounces@ietf.org Fri Oct 21 11:15:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESycd-0004JV-G1; Fri, 21 Oct 2005 11:15:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyca-0004I6-34 for enum@megatron.ietf.org; Fri, 21 Oct 2005 11:15:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02684 for ; Fri, 21 Oct 2005 11:15:40 -0400 (EDT) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESyoh-0006g3-9W for enum@ietf.org; Fri, 21 Oct 2005 11:28:25 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1129907510!8603808!11 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 27911 invoked from network); 21 Oct 2005 15:15:35 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-10.tower-120.messagelabs.com with SMTP; 21 Oct 2005 15:15:35 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 4355D40900258705; Fri, 21 Oct 2005 11:15:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Oct 2005 11:15:40 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0B5E40A5@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXWUcpZwcEkRbZxRX6zI5wPKYmZSwAAEU2Q From: "Pfautz, Penn L, NEO" To: "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: fe6e20eef2d8927c50910823cd0d1c84 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org OK with just a couple typos below=20 Penn -----Original Message----- From: David Meyer [mailto:dmm@1-4-5.net]=20 Sent: Friday, October 21, 2005 11:12 AM To: Pfautz, Penn L, NEO Cc: voipeer@lists.uoregon.edu; enum@ietf.org Subject: Re: [voipeer] draft-meyer-voipeer-terminology-03.txt On Fri, Oct 21, 2005 at 09:51:17AM -0400, Pfautz, Penn L, NEO wrote: > Dave: > This is a nice start (indeed more than a start). I just have two > comments at this point: >=20 > 1. The definition of carrier in 3.6 is probably too restrictive. I > would not make it contingent on issuance of E.164 numbers but rather > just the provision of PSTN service. I appreciate your use our > carrier-of-record definition in 4.1. How about: 3.6. Carrier A carrier is defined to be a service provider authorized to provision PSTN services. Note that the provision of such services is usually coupled with the authority to issue E.164 numbers [ITU.E164.1991] under the authority of a National Regulatory Authority (NRA). =09 > 2. In reference to Layer 3 Peering (Section 3.7.1) I would like to see > included the concepts that a) peering involves delivery of packets that > terminate on the peer's network and b) peering is done without traffic > settlement charges. I'm ok with a) termination of traffic, but I'd like to avoid discussing SFI more than I have (see section 3.7). So how about: 3.7.1. Layer 3 Peering Layer 3 peering refers to interconnection of two service providers for the purposes of exchanging IP packets which destined for one (or both) of the peer's networks. Layer 3 peering is generally agnostic to the IP payload, and is frequently achieved using a routing protocol such as BGP [RFC1771] to exchange the required routing information. An alternate, perhaps more operational definition of layer 3 peering is that two peers exchange their customer router (only), and hence ^ any traffic between peers terminates on one of the peer's network. ^^^^^^^^ =09 Dave --- Network Working Group D. Meyer Internet-Draft October 21, 2005 Expires: April 24, 2006 Terminology for Describing VoIP Peering and Interconnect draft-meyer-voipeer-terminology-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 24, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines the terminology that is to be used by the Voice Over IP Peering and Interconnect Working Group (voipeer), and has as its primary objective to focus the VOIPEER Working Group during its discussions, and when writing requirements, gap analysis and other solutions oriented documents. Meyer Expires April 24, 2006 [Page 1] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. General Definitions . . . . . . . . . . . . . . . . . . . . . 4 3.1. Call Routing Data . . . . . . . . . . . . . . . . . . . . 4 3.2. Call Routing . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Network . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5. VoIP Service Provider . . . . . . . . . . . . . . . . . . 5 3.6. Carrier . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7. Peering . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . . . . . . 6 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . . . . . . 6 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . . . . . . 6 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Carrier of Record . . . . . . . . . . . . . . . . . . . . 6 4.2. Public ENUM . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Private ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Meyer Expires April 24, 2006 [Page 2] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 1. Introduction The term "VoIP Peering" has historically been used to describe a wide variety of aspects pertaining to the interconnection of service provider networks and to the delivery of SIP call termination over those interconnections. The discussion of these interconnections has at times been confused by the fact that the term "peering" is used in various contexts to relate to interconnection at different levels in a protocol stack. VoIP peering focuses on how to identify and route calls at the application layer, and it does not (necessarily) involve the exchange of packet routing data or media sessions. In particular, "layer 5 network" is used here to refer to the interconnection between SIP servers, as opposed to interconnection at the IP layer ("layer 3"). Finally, the terms "peering" and "interconnect" are used interchangeably throughout this document. This document introduces standard terminology for use in characterizing VoIP interconnection. Note however, that while this document is primarily targeted at the VoIP interconnect case, the terminology described here is applicable to those cases in which service providers interconnect using SIP signaling for real-time or quasi-real-time communications. The remainder of this document is organized as follows: Section 2 provides the general context for the VOIPEER Working Group, and Section 3 provides the general definitions for real-time SIP based communication, with focus on the VoIP interconnect case. Section 4 briefly touches on terms from the ENUM Working Group. Finally, Section 5 provides comments on usage. 2. Context Figure 1 depicts the general VoIP interconnect context. In this case, the caller uses an E.164 number [ITU.E164.1991] as the "name" of the called user. Note that this E.164 number is not an address, since at this point we do not have information about where the named endpoint is located. In the case shown here, an E.164 number is used as a key to retrieve a NAPTR recored [RFC3404] from the DNS, which in turn resolved into a SIP URI. Call routing is based on this SIP URI. The call routing step does not depend on the presence of an E.164 number; the SIP URI can be advertised in various other ways, such as on a web page. Finally, note that the subsequent lookup steps, namely, lookup of SRV, A, and AAAA records (as well as any routing steps below that) are outside the scope of VOIPEER. Meyer Expires April 24, 2006 [Page 3] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 E.164 number <--- Peer Discovery | | <--- ENUM lookup of NAPTR in DNS | | | ENUM Working Group Scope = =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | VOIPEER Working Group Scope | | SIP URI <--- Call Routing Data (CRD) | | <--- Service Location (Lookup of SRV in DNS) | | Hostname <--- VoIP addressing and session establishment | | <---- Lookup of A and AAAA in DNS | Ip address | | <---- Routing protocols, ARP etc | Mac-address Figure 1: VoIP Interconnect Context The ENUM Working Group is primarily concerned with the acquisition of Call Routing Data, or CRD (i.e., above the double line in Figure 1), while the VOIPEER Working Group is focused on the use of such CRD. Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS entry), or via any other mechanism available to the user. 3. General Definitions 3.1. Call Routing Data Call Routing Data, or CRD, is a SIP URI used to route a call (real- time, voice or other type) to the called domain's ingress point. A domain's ingress point can be thought of as the location pointed to by the SRV record that resulted from the resolution of the CRD (i.e., a SIP URI). 3.2. Call Routing Call routing is the set of processes, rules, and CRD used to route a VoIP call to its proper (SIP) destination. More generally, call Meyer Expires April 24, 2006 [Page 4] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 routing can be thought of as the set of processes, rules and CRD which are used to route a real-time session to its termination (ingress) point. 3.3. PSTN The term "PSTN" refers to the Public Switched Telephone Network. In particular, the PSTN refers to the collection of interconnected circuit-switched voice-oriented public telephone networks, both commercial and government-owned. In general, PSTN terminals are addressed using E.164 numbers, noting that various dial-plans (such as emergency services dial-plans) may not directly use E.164 numbers. 3.4. Network For purposes of this document and the VOIPEER and ENUM Working Groups, a network is defined to be the set of SIP servers and end- users (customers) that are controlled by a single administrative domain. The network may also contain end-users who are located on the PSTN. 3.5. VoIP Service Provider A VoIP service provider is an entity that provides transport of SIP signaling (and possibly media streams) to its customers. Such a service provider may additionally be interconnected with other service providers; that is, it may "peer" with other service providers. A VoIP service provider may also interconnect with the PSTN. Note that as soon as a ingress point is advertised via a SRV record, anyone can find that ingress point and hence can send calls there. This is very similar to sending mail to a SMTP server based on the existence of a MX record. 3.6. Carrier A carrier is defined to be a service provider authorized to provision PSTN services. Note that the provision of such services is usually coupled with the authority to issue E.164 numbers [ITU.E164.1991] under the authority of a National Regulatory Authority (NRA). 3.7. Peering While the precise definition of the term "peering" is the subject of some debate, peering in general refers to the negotiation of reciprocal interconnection arrangements, settlement-free or otherwise, between operationally independent service providers. Meyer Expires April 24, 2006 [Page 5] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 This document distinguishes two types of peering, Layer 3 Peering and Layer 5 peering, which are described below. 3.7.1. Layer 3 Peering Layer 3 peering refers to interconnection of two service providers for the purposes of exchanging IP packets which destined for one (or both) of the peer's networks. Layer 3 peering is generally agnostic to the IP payload, and is frequently achieved using a routing protocol such as BGP [RFC1771] to exchange the required routing information. An alternate, perhaps more operational definition of layer 3 peering is that two peers exchange their customer routers (only), and hence any traffic between peers terminates on on the peer's network. 3.7.2. Layer 5 Peering Layer 5 peering refers to interconnection of two service providers for the purposes of SIP signaling. Note that in the layer 5 peering case, there is no intervening network. That is, for purposes of this discussion, there is no such thing as a "Layer 5 Transit Network". 3.8. VoIP Peering VoIP peering is defined to be a layer 5 peering between two VoIP providers for purposes of routing real-time (or quasi-real time) call signaling between their respective customers. Media streams associated with this signaling (if any) are not constrained to follow the same set of paths. 4. ENUM ENUM [RFC3761] defines how the Domain Name System (DNS) can be used for identifying available services connected to one E.164 number. 4.1. Carrier of Record For purposes of this document, "Carrier of Record", or COR, refers to the entity that provides PSTN service for an E.164 number [I-D.lind- infrastructure-enum-reqs]. The exact definition of who and what is a COR is ultimately the responsibility of the relevant NRA. 4.2. Public ENUM Public ENUM is generally defined as the set administrative policies and procedures surrounding the use of the e164.arpa domain for Meyer Expires April 24, 2006 [Page 6] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Telephone Number to URI resolution [RFC3761]. Policies and procedures for the registration of telephone numbers within all branches of the e164.arpa tree are Nation State issues by agreement with the IAB and ITU. National Regulatory Authorities have generally defined Public ENUM Registrants as the E.164 number holder as opposed to the COR that issued the phone number. 4.3. Private ENUM Private ENUM is generally regarded as one or more technologies (including DNS and SIP Redirect) that service providers or enterprises may use to exchange phone number to URI mappings in a private secure manner. Private ENUM may be used in any mutually agreed upon domain. Records in Private ENUM may be globally visible but in most cases are not visible to the global Internet and are protected using a variety of security technologies such as split-DNS, VPN's or various forms or authentication and authorization. Technical comments on issues surrounding split-DNS can be found in [RFC2826]. 4.4. Carrier ENUM Carrier ENUM is generally regarded as the use of a separate branch the e164.arpa tree, such as 4.4.c.e164.arpa to permit service providers to exchange phone number to URI data in order to find points of interconnection. The current theory of Carrier ENUM is that only the COR for a particular E.164 number is permitted to provision data for that E.164 within that portion of the e164.arpa tree. In carrier ENUM case, only the COR may enter data in the corresponding domain. The COR may also enter CRD (i.e., a SIP URI) to allow other VoIP Service Providers to route calls to its network. Finally, note that ENUM is not constrained to carry only data (CDR) as defined by VOIPEER. In particular, an an important class of CRD, the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are most frequently used to interconnect with the PSTN directly, and are out of scope for VOIPEER. On the other hand, PSTN endpoints served by a COR and reachable via CDR and networks as defined in Section 3.1 and Section 3.4 are in scope for VOIPEER. 5. Conclusions 6. Acknowledgments Meyer Expires April 24, 2006 [Page 7] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Many of the definitions were gleaned from detailed discussions on the VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer, Jean-Francois Mule, Richard Shocky, and Richard Stastny made valuable contributions to early revisions of this document. Patrik Faltstrom also made many insightful comments to early versions of this draft, and contributed the basis of Figure 1. 7. Security Considerations This document itself introduces no new security considerations. However, it is important to note that VoIP interconnect has a wide variety of security issues that should be considered in documents addressing both protocol and use case analyzes. 8. IANA Considerations This document creates no new requirements on IANA namespaces [RFC2434]. 9. References 9.1. Normative References [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [ITU.E164.1991] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU- T Recommendation E.164, 1991. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. 9.2. Informative References [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an Meyer Expires April 24, 2006 [Page 8] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000. [I-D.lind-infrastructure-enum-reqs] Lind, S., "Infrastructure ENUM Requirements", draft-lind-infrastructure-enum-reqs-00 (work in progress), July 2005. Meyer Expires April 24, 2006 [Page 9] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Author's Address David Meyer Email: dmm@1-4-5.net Meyer Expires April 24, 2006 [Page 10] =0C Internet-Draft Terminology for Describing VoIP Peering October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Meyer Expires April 24, 2006 [Page 11] =0C _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 21 13:30:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET0j0-0002SP-3g; Fri, 21 Oct 2005 13:30:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET0iy-0002SK-75 for enum@megatron.ietf.org; Fri, 21 Oct 2005 13:30:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20348 for ; Fri, 21 Oct 2005 13:30:26 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET0v8-0006wj-Rt for enum@ietf.org; Fri, 21 Oct 2005 13:43:12 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 21 Oct 2005 10:30:26 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9LHU796026853; Fri, 21 Oct 2005 10:30:23 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 13:30:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Oct 2005 13:30:06 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3AE681F@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXWUrED2MtA7e4tT0aJ5p50zQ1crQAEXG5A From: "Michael Hammer \(mhammer\)" To: "David Meyer" , "Pfautz, Penn L, NEO" X-OriginalArrivalTime: 21 Oct 2005 17:30:07.0378 (UTC) FILETIME=[147E2720:01C5D665] X-Spam-Score: 0.0 (/) X-Scan-Signature: a3962d9f28f80f517c050a4675f65235 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org David, A slight modification suggestion below.=20 > -----Original Message----- > From: owner-voipeer@lists.uoregon.edu=20 > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of David Meyer > Sent: Friday, October 21, 2005 11:12 AM > To: Pfautz, Penn L, NEO > Cc: voipeer@lists.uoregon.edu; enum@ietf.org > Subject: Re: [voipeer] draft-meyer-voipeer-terminology-03.txt >=20 > On Fri, Oct 21, 2005 at 09:51:17AM -0400, Pfautz, Penn L, NEO wrote: > > Dave: > > This is a nice start (indeed more than a start). I just have two=20 > > comments at this point: > >=20 > > 1. The definition of carrier in 3.6 is probably too restrictive. I=20 > > would not make it contingent on issuance of E.164 numbers=20 > but rather=20 > > just the provision of PSTN service. I appreciate your use our=20 > > carrier-of-record definition in 4.1. >=20 >=20 > How about: >=20 > 3.6. Carrier >=20 > A carrier is defined to be a service provider authorized=20 > to provision PSTN=20 The term PSTN is often used to mean the TDM networks offering publicly available telephony services. In order to get away from the TDM aspects, which some day might go away, how about: a service provider authorized to offer telephony services to the public. That should cover both cases and gets away from unintended baggage. I am assuming that the enterprises are not considered pseudo-carriers and intended to be covered here. Mike > services. Note that the provision of such services is usually > coupled with the authority to issue E.164 numbers [ITU.E164.1991] > under the authority of a National Regulatory Authority (NRA). >=20 > =09 > > 2. In reference to Layer 3 Peering (Section 3.7.1) I would=20 > like to see=20 > > included the concepts that a) peering involves delivery of packets=20 > > that terminate on the peer's network and b) peering is done without=20 > > traffic settlement charges. >=20 > I'm ok with a) termination of traffic, but I'd like to > avoid discussing SFI more than I have (see section > 3.7). So how about: >=20 > 3.7.1. Layer 3 Peering >=20 > Layer 3 peering refers to interconnection of two service providers > for the purposes of exchanging IP packets which destined=20 > for one (or > both) of the peer's networks. Layer 3 peering is=20 > generally agnostic > to the IP payload, and is frequently achieved using a routing > protocol such as BGP [RFC1771] to exchange the required routing > information. >=20 > An alternate, perhaps more operational definition of layer=20 > 3 peering > is that two peers exchange their customer routers (only), and hence > any traffic between peers terminates on on the peer's network. >=20 > =09 > Dave >=20 > --- >=20 >=20 >=20 >=20 > Network Working Group =20 > D. Meyer > Internet-Draft =20 > October 21, 2005 > Expires: April 24, 2006 >=20 >=20 > Terminology for Describing VoIP Peering and Interconnect > draft-meyer-voipeer-terminology-04.txt >=20 > Status of this Memo >=20 > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. >=20 > Internet-Drafts are draft documents valid for a maximum of=20 > six months > and may be updated, replaced, or obsoleted by other=20 > documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. >=20 > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. >=20 > This Internet-Draft will expire on April 24, 2006. >=20 > Copyright Notice >=20 > Copyright (C) The Internet Society (2005). >=20 > Abstract >=20 > This document defines the terminology that is to be used=20 > by the Voice > Over IP Peering and Interconnect Working Group (voipeer),=20 > and has as > its primary objective to focus the VOIPEER Working Group during its > discussions, and when writing requirements, gap analysis and other > solutions oriented documents. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 24, 2006 =20 > [Page 1] > =0C>=20 > Internet-Draft Terminology for Describing VoIP Peering =20 > October 2005 >=20 >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . .=20 > . . . . 3 > 2. Context . . . . . . . . . . . . . . . . . . . . . . .=20 > . . . . 3 > 3. General Definitions . . . . . . . . . . . . . . . . .=20 > . . . . 4 > 3.1. Call Routing Data . . . . . . . . . . . . . . . .=20 > . . . . 4 > 3.2. Call Routing . . . . . . . . . . . . . . . . . . .=20 > . . . . 4 > 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . .=20 > . . . . 5 > 3.4. Network . . . . . . . . . . . . . . . . . . . . .=20 > . . . . 5 > 3.5. VoIP Service Provider . . . . . . . . . . . . . .=20 > . . . . 5 > 3.6. Carrier . . . . . . . . . . . . . . . . . . . . .=20 > . . . . 5 > 3.7. Peering . . . . . . . . . . . . . . . . . . . . .=20 > . . . . 5 > 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . .=20 > . . . . 6 > 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . .=20 > . . . . 6 > 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . .=20 > . . . . 6 > 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . .=20 > . . . . 6 > 4.1. Carrier of Record . . . . . . . . . . . . . . . .=20 > . . . . 6 > 4.2. Public ENUM . . . . . . . . . . . . . . . . . . .=20 > . . . . 6 > 4.3. Private ENUM . . . . . . . . . . . . . . . . . . .=20 > . . . . 7 > 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . .=20 > . . . . 7 > 5. Conclusions . . . . . . . . . . . . . . . . . . . . .=20 > . . . . 7 > 6. Acknowledgments . . . . . . . . . . . . . . . . . . .=20 > . . . . 7 > 7. Security Considerations . . . . . . . . . . . . . . .=20 > . . . . 8 > 8. IANA Considerations . . . . . . . . . . . . . . . . .=20 > . . . . 8 > 9. References . . . . . . . . . . . . . . . . . . . . . .=20 > . . . . 8 > 9.1. Normative References . . . . . . . . . . . . . . .=20 > . . . . 8 > 9.2. Informative References . . . . . . . . . . . . . .=20 > . . . . 8 > Author's Address . . . . . . . . . . . . . . . . . . . . .=20 > . . . . 10 > Intellectual Property and Copyright Statements . . . . . .=20 > . . . . 11 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 24, 2006 =20 > [Page 2] > =0C>=20 > Internet-Draft Terminology for Describing VoIP Peering =20 > October 2005 >=20 >=20 > 1. Introduction >=20 > The term "VoIP Peering" has historically been used to=20 > describe a wide > variety of aspects pertaining to the interconnection of service > provider networks and to the delivery of SIP call termination over > those interconnections. The discussion of these=20 > interconnections has > at times been confused by the fact that the term "peering"=20 > is used in > various contexts to relate to interconnection at different=20 > levels in > a protocol stack. VoIP peering focuses on how to identify=20 > and route > calls at the application layer, and it does not=20 > (necessarily) involve > the exchange of packet routing data or media sessions. In > particular, "layer 5 network" is used here to refer to the > interconnection between SIP servers, as opposed to=20 > interconnection at > the IP layer ("layer 3"). Finally, the terms "peering" and > "interconnect" are used interchangeably throughout this document. >=20 > This document introduces standard terminology for use in > characterizing VoIP interconnection. Note however, that while this > document is primarily targeted at the VoIP interconnect case, the > terminology described here is applicable to those cases in which > service providers interconnect using SIP signaling for real-time or > quasi-real-time communications. >=20 > The remainder of this document is organized as follows: Section 2 > provides the general context for the VOIPEER Working Group, and > Section 3 provides the general definitions for real-time SIP based > communication, with focus on the VoIP interconnect case. Section 4 > briefly touches on terms from the ENUM Working Group. Finally, > Section 5 provides comments on usage. >=20 >=20 > 2. Context >=20 > Figure 1 depicts the general VoIP interconnect context. In this > case, the caller uses an E.164 number [ITU.E164.1991] as the "name" > of the called user. Note that this E.164 number is not an address, > since at this point we do not have information about where=20 > the named > endpoint is located. In the case shown here, an E.164=20 > number is used > as a key to retrieve a NAPTR recored [RFC3404] from the=20 > DNS, which in > turn resolved into a SIP URI. Call routing is based on=20 > this SIP URI. > The call routing step does not depend on the presence of an E.164 > number; the SIP URI can be advertised in various other=20 > ways, such as > on a web page. Finally, note that the subsequent lookup steps, > namely, lookup of SRV, A, and AAAA records (as well as any routing > steps below that) are outside the scope of VOIPEER. >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 24, 2006 =20 > [Page 3] > =0C>=20 > Internet-Draft Terminology for Describing VoIP Peering =20 > October 2005 >=20 >=20 > E.164 number <--- Peer Discovery > | > | <--- ENUM lookup of NAPTR in DNS > | > | > | ENUM Working Group Scope > = =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | VOIPEER Working Group Scope > | > | > SIP URI <--- Call Routing Data (CRD) > | > | <--- Service Location (Lookup of SRV in DNS) > | > | > Hostname <--- VoIP addressing and session establishment > | > | <---- Lookup of A and AAAA in DNS > | > Ip address > | > | <---- Routing protocols, ARP etc > | > Mac-address >=20 > Figure 1: VoIP Interconnect Context >=20 > The ENUM Working Group is primarily concerned with the=20 > acquisition of > Call Routing Data, or CRD (i.e., above the double line in=20 > Figure 1), > while the VOIPEER Working Group is focused on the use of such CRD. > Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS > entry), or via any other mechanism available to the user. >=20 >=20 > 3. General Definitions >=20 > 3.1. Call Routing Data >=20 > Call Routing Data, or CRD, is a SIP URI used to route a call (real- > time, voice or other type) to the called domain's ingress point. A > domain's ingress point can be thought of as the location pointed to > by the SRV record that resulted from the resolution of the=20 > CRD (i.e., > a SIP URI). >=20 > 3.2. Call Routing >=20 > Call routing is the set of processes, rules, and CRD used=20 > to route a > VoIP call to its proper (SIP) destination. More generally, call >=20 >=20 >=20 > Meyer Expires April 24, 2006 =20 > [Page 4] > =0C>=20 > Internet-Draft Terminology for Describing VoIP Peering =20 > October 2005 >=20 >=20 > routing can be thought of as the set of processes, rules and CRD > which are used to route a real-time session to its termination > (ingress) point. >=20 > 3.3. PSTN >=20 > The term "PSTN" refers to the Public Switched Telephone=20 > Network. In > particular, the PSTN refers to the collection of interconnected > circuit-switched voice-oriented public telephone networks, both > commercial and government-owned. In general, PSTN terminals are > addressed using E.164 numbers, noting that various dial-plans (such > as emergency services dial-plans) may not directly use=20 > E.164 numbers. >=20 > 3.4. Network >=20 > For purposes of this document and the VOIPEER and ENUM Working > Groups, a network is defined to be the set of SIP servers and end- > users (customers) that are controlled by a single administrative > domain. The network may also contain end-users who are located on > the PSTN. >=20 > 3.5. VoIP Service Provider >=20 > A VoIP service provider is an entity that provides transport of SIP > signaling (and possibly media streams) to its customers. Such a > service provider may additionally be interconnected with other > service providers; that is, it may "peer" with other service > providers. A VoIP service provider may also interconnect with the > PSTN. >=20 > Note that as soon as a ingress point is advertised via a=20 > SRV record, > anyone can find that ingress point and hence can send calls there. > This is very similar to sending mail to a SMTP server based on the > existence of a MX record. >=20 > 3.6. Carrier >=20 > A carrier is defined to be a service provider authorized=20 > to provision > PSTN services. Note that the provision of such services is usually > coupled with the authority to issue E.164 numbers [ITU.E164.1991] > under the authority of a National Regulatory Authority (NRA). >=20 > 3.7. Peering >=20 > While the precise definition of the term "peering" is the=20 > subject of > some debate, peering in general refers to the negotiation of > reciprocal interconnection arrangements, settlement-free or > otherwise, between operationally independent service providers. >=20 >=20 >=20 > Meyer Expires April 24, 2006 =20 > [Page 5] > =0C>=20 > Internet-Draft Terminology for Describing VoIP Peering =20 > October 2005 >=20 >=20 > This document distinguishes two types of peering, Layer 3=20 > Peering and > Layer 5 peering, which are described below. >=20 > 3.7.1. Layer 3 Peering >=20 > Layer 3 peering refers to interconnection of two service providers > for the purposes of exchanging IP packets which destined=20 > for one (or > both) of the peer's networks. Layer 3 peering is=20 > generally agnostic > to the IP payload, and is frequently achieved using a routing > protocol such as BGP [RFC1771] to exchange the required routing > information. >=20 > An alternate, perhaps more operational definition of layer=20 > 3 peering > is that two peers exchange their customer routers (only), and hence > any traffic between peers terminates on on the peer's network. >=20 > 3.7.2. Layer 5 Peering >=20 > Layer 5 peering refers to interconnection of two service providers > for the purposes of SIP signaling. Note that in the layer=20 > 5 peering > case, there is no intervening network. That is, for=20 > purposes of this > discussion, there is no such thing as a "Layer 5 Transit Network". >=20 > 3.8. VoIP Peering >=20 > VoIP peering is defined to be a layer 5 peering between two VoIP > providers for purposes of routing real-time (or quasi-real=20 > time) call > signaling between their respective customers. Media streams > associated with this signaling (if any) are not=20 > constrained to follow > the same set of paths. >=20 >=20 > 4. ENUM >=20 > ENUM [RFC3761] defines how the Domain Name System (DNS) can be used > for identifying available services connected to one E.164 number. >=20 > 4.1. Carrier of Record >=20 > For purposes of this document, "Carrier of Record", or=20 > COR, refers to > the entity that provides PSTN service for an E.164 number=20 > [I-D.lind- > infrastructure-enum-reqs]. The exact definition of who=20 > and what is a > COR is ultimately the responsibility of the relevant NRA. >=20 > 4.2. Public ENUM >=20 > Public ENUM is generally defined as the set administrative policies > and procedures surrounding the use of the e164.arpa domain for >=20 >=20 >=20 > Meyer Expires April 24, 2006 =20 > [Page 6] > =0C>=20 > Internet-Draft Terminology for Describing VoIP Peering =20 > October 2005 >=20 >=20 > Telephone Number to URI resolution [RFC3761]. Policies and > procedures for the registration of telephone numbers within all > branches of the e164.arpa tree are Nation State issues by agreement > with the IAB and ITU. National Regulatory Authorities=20 > have generally > defined Public ENUM Registrants as the E.164 number holder=20 > as opposed > to the COR that issued the phone number. >=20 > 4.3. Private ENUM >=20 > Private ENUM is generally regarded as one or more technologies > (including DNS and SIP Redirect) that service providers or > enterprises may use to exchange phone number to URI mappings in a > private secure manner. Private ENUM may be used in any mutually > agreed upon domain. Records in Private ENUM may be=20 > globally visible > but in most cases are not visible to the global Internet and are > protected using a variety of security technologies such as=20 > split-DNS, > VPN's or various forms or authentication and authorization. > Technical comments on issues surrounding split-DNS can be found in > [RFC2826]. >=20 > 4.4. Carrier ENUM >=20 > Carrier ENUM is generally regarded as the use of a separate branch > the e164.arpa tree, such as 4.4.c.e164.arpa to permit service > providers to exchange phone number to URI data in order to find > points of interconnection. The current theory of Carrier ENUM is > that only the COR for a particular E.164 number is permitted to > provision data for that E.164 within that portion of the e164.arpa > tree. >=20 > In carrier ENUM case, only the COR may enter data in the > corresponding domain. The COR may also enter CRD (i.e., a SIP URI) > to allow other VoIP Service Providers to route calls to=20 > its network. >=20 > Finally, note that ENUM is not constrained to carry only data (CDR) > as defined by VOIPEER. In particular, an an important=20 > class of CRD, > the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are > most frequently used to interconnect with the PSTN=20 > directly, and are > out of scope for VOIPEER. On the other hand, PSTN endpoints served > by a COR and reachable via CDR and networks as defined in=20 > Section 3.1 > and Section 3.4 are in scope for VOIPEER. >=20 >=20 > 5. Conclusions >=20 >=20 > 6. Acknowledgments >=20 >=20 >=20 >=20 > Meyer Expires April 24, 2006 =20 > [Page 7] > =0C>=20 > Internet-Draft Terminology for Describing VoIP Peering =20 > October 2005 >=20 >=20 > Many of the definitions were gleaned from detailed=20 > discussions on the > VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer, > Jean-Francois Mule, Richard Shocky, and Richard Stastny=20 > made valuable > contributions to early revisions of this document. Patrik=20 > Faltstrom > also made many insightful comments to early versions of this draft, > and contributed the basis of Figure 1. >=20 >=20 > 7. Security Considerations >=20 > This document itself introduces no new security considerations. > However, it is important to note that VoIP interconnect has a wide > variety of security issues that should be considered in documents > addressing both protocol and use case analyzes. >=20 >=20 > 8. IANA Considerations >=20 > This document creates no new requirements on IANA namespaces > [RFC2434]. >=20 >=20 > 9. References >=20 > 9.1. Normative References >=20 > [RFC3404] Mealling, M., "Dynamic Delegation Discovery=20 > System (DDDS) > Part Four: The Uniform Resource Identifiers (URI)", > RFC 3404, October 2002. >=20 > [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform > Resource Identifiers (URI) Dynamic Delegation Discovery > System (DDDS) Application (ENUM)", RFC 3761, April 2004. >=20 > [ITU.E164.1991] > International Telecommunications Union, "The=20 > International > Public Telecommunication Numbering Plan", ITU- > T Recommendation E.164, 1991. >=20 > [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", > RFC 3966, December 2004. >=20 > 9.2. Informative References >=20 > [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 > (BGP-4)", RFC 1771, March 1995. >=20 > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an >=20 >=20 >=20 > Meyer Expires April 24, 2006 =20 > [Page 8] > =0C>=20 > Internet-Draft Terminology for Describing VoIP Peering =20 > October 2005 >=20 >=20 > IANA Considerations Section in RFCs", BCP 26, RFC 2434, > October 1998. >=20 > [RFC2826] Internet Architecture Board, "IAB Technical=20 > Comment on the > Unique DNS Root", RFC 2826, May 2000. >=20 > [I-D.lind-infrastructure-enum-reqs] > Lind, S., "Infrastructure ENUM Requirements", > draft-lind-infrastructure-enum-reqs-00 (work in=20 > progress), > July 2005. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 24, 2006 =20 > [Page 9] > =0C>=20 > Internet-Draft Terminology for Describing VoIP Peering =20 > October 2005 >=20 >=20 > Author's Address >=20 > David Meyer >=20 > Email: dmm@1-4-5.net >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 24, 2006 =20 > [Page 10] > =0C>=20 > Internet-Draft Terminology for Describing VoIP Peering =20 > October 2005 >=20 >=20 > Intellectual Property Statement >=20 > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be=20 > claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. =20 > Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. >=20 > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for=20 > the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR=20 > repository at > http://www.ietf.org/ipr. >=20 > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. >=20 >=20 > Disclaimer of Validity >=20 > This document and the information contained herein are=20 > provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE=20 > REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. >=20 >=20 > Copyright Statement >=20 > Copyright (C) The Internet Society (2005). This document=20 > is subject > to the rights, licenses and restrictions contained in BCP 78, and > except as set forth therein, the authors retain all their rights. >=20 >=20 > Acknowledgment >=20 > Funding for the RFC Editor function is currently provided by the > Internet Society. >=20 >=20 >=20 >=20 > Meyer Expires April 24, 2006 =20 > [Page 11] > =0C>=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 21 13:44:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET0wh-00039h-ET; Fri, 21 Oct 2005 13:44:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET0wf-00039W-UB for enum@megatron.ietf.org; Fri, 21 Oct 2005 13:44:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21090 for ; Fri, 21 Oct 2005 13:44:35 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET18q-0007UF-GI for enum@ietf.org; Fri, 21 Oct 2005 13:57:21 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9LHiYKr000514; Fri, 21 Oct 2005 10:44:34 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9LHiY5v000513; Fri, 21 Oct 2005 10:44:34 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 21 Oct 2005 10:44:34 -0700 From: David Meyer To: "Michael Hammer (mhammer)" Message-ID: <20051021174434.GA464@1-4-5.net> References: <072C5B76F7CEAB488172C6F64B30B5E3AE681F@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3AE681F@xmb-rtp-20b.amer.cisco.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: enum@ietf.org, voipeer@lists.uoregon.edu, "Pfautz, Penn L, NEO" Subject: [Enum] Re: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1083490256==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1083490256== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 21, 2005 at 01:30:06PM -0400, Michael Hammer (mhammer) wrote: > David, >=20 > A slight modification suggestion below.=20 >=20 > > -----Original Message----- > > From: owner-voipeer@lists.uoregon.edu=20 > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of David Meyer > > Sent: Friday, October 21, 2005 11:12 AM > > To: Pfautz, Penn L, NEO > > Cc: voipeer@lists.uoregon.edu; enum@ietf.org > > Subject: Re: [voipeer] draft-meyer-voipeer-terminology-03.txt > >=20 > > On Fri, Oct 21, 2005 at 09:51:17AM -0400, Pfautz, Penn L, NEO wrote: > > > Dave: > > > This is a nice start (indeed more than a start). I just have two=20 > > > comments at this point: > > >=20 > > > 1. The definition of carrier in 3.6 is probably too restrictive. I= =20 > > > would not make it contingent on issuance of E.164 numbers=20 > > but rather=20 > > > just the provision of PSTN service. I appreciate your use our=20 > > > carrier-of-record definition in 4.1. > >=20 > >=20 > > How about: > >=20 > > 3.6. Carrier > >=20 > > A carrier is defined to be a service provider authorized=20 > > to provision PSTN=20 >=20 > The term PSTN is often used to mean the TDM networks offering publicly > available telephony services. In order to get away from the TDM > aspects, which some day might go away, how about: >=20 > a service provider authorized to offer telephony services to the public. >=20 > That should cover both cases and gets away from unintended baggage. I > am assuming that the enterprises are not considered pseudo-carriers and > intended to be covered here. Sure. Thanks. Dave --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDWSkCORgD1qCZ2KcRAvx1AJ9PUTnztJEX81co5UudBsSV7Ol/LQCcCBCW foP7gFxMab2GNRSyohcsrK8= =9zto -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- --===============1083490256== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1083490256==-- From enum-bounces@ietf.org Fri Oct 21 14:09:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1KZ-0001Wi-96; Fri, 21 Oct 2005 14:09:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1KT-0001Si-A1; Fri, 21 Oct 2005 14:09:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22276; Fri, 21 Oct 2005 14:09:10 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET1Wf-0008KH-Av; Fri, 21 Oct 2005 14:21:57 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1ET1KS-00059m-Hz; Fri, 21 Oct 2005 14:09:20 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 21 Oct 2005 14:09:20 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: enum@ietf.org Subject: [Enum] Last Call: 'IANA Registration for Enumservice Voice' to Proposed Standard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The IESG has received a request from the Telephone Number Mapping WG to consider the following document: - 'IANA Registration for Enumservice Voice ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-11-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-voice-01.txt _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 21 14:33:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1iF-0006Nn-In; Fri, 21 Oct 2005 14:33:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1iD-0006Ni-Qe for enum@megatron.ietf.org; Fri, 21 Oct 2005 14:33:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24243 for ; Fri, 21 Oct 2005 14:33:42 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ET1uO-0000yP-Fc for enum@ietf.org; Fri, 21 Oct 2005 14:46:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Date: Fri, 21 Oct 2005 20:37:19 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4618@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXWUrED2MtA7e4tT0aJ5p50zQ1crQAEXG5AAAJanXQ= From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "David Meyer" , "Pfautz, Penn L, NEO" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Mike, Dave, =20 >> A carrier is defined to be a service provider authorized >> to provision PSTN >The term PSTN is often used to mean the TDM networks offering publicly >available telephony services. In order to get away from the TDM >aspects, which some day might go away, how about: >a service provider authorized to offer telephony services to the = public. >That should cover both cases and gets away from unintended baggage. I >am assuming that the enterprises are not considered pseudo-carriers and i>ntended to be covered here. I have no solution to offer at the moment, but I have a problem with the term public available telephony service (PATS). This term has a special meaning in Europe and is a subset of the term electronic communication service (ECS), both defined in the framework and under heavy discussion in the context of VoIP. =20 Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 21 15:03:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2Av-00086z-DQ; Fri, 21 Oct 2005 15:03:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2As-00086q-Dh for enum@megatron.ietf.org; Fri, 21 Oct 2005 15:03:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25946 for ; Fri, 21 Oct 2005 15:03:19 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET2N4-00029h-2R for enum@ietf.org; Fri, 21 Oct 2005 15:16:07 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 21 Oct 2005 12:03:20 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,240,1125903600"; d="scan'208"; a="13646335:sNHT33486660" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9LJ2v2J006728; Fri, 21 Oct 2005 15:03:17 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 15:02:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Oct 2005 15:02:55 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3AE688F@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXWUrED2MtA7e4tT0aJ5p50zQ1crQAEXG5AAAEYuFAAAlve4A== From: "Michael Hammer \(mhammer\)" To: , "David Meyer" , "Pfautz, Penn L, NEO" X-OriginalArrivalTime: 21 Oct 2005 19:02:56.0422 (UTC) FILETIME=[0BE6D460:01C5D672] X-Spam-Score: 0.0 (/) X-Scan-Signature: 81deca529f15c4b23c0e7af81dbe55c5 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Are they using E.164 numbers yet? If so, who are they getting them from? Mike =20 > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com]=20 > Sent: Friday, October 21, 2005 1:57 PM > To: Michael Hammer (mhammer); 'David Meyer'; 'Pfautz, Penn L, NEO' > Cc: voipeer@lists.uoregon.edu; enum@ietf.org > Subject: RE: [voipeer] draft-meyer-voipeer-terminology-03.txt >=20 > > a service provider authorized to offer telephony services=20 > to the public. >=20 > Does this include Skype? It's the biggest anyway. >=20 > :-) Thanks, Henry >=20 >=20 > =20 >=20 > -----Original Message----- > From: owner-voipeer@lists.uoregon.edu > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Hammer > (mhammer) > Sent: Friday, October 21, 2005 12:30 PM > To: David Meyer; Pfautz, Penn L, NEO > Cc: voipeer@lists.uoregon.edu; enum@ietf.org > Subject: RE: [voipeer] draft-meyer-voipeer-terminology-03.txt >=20 > David, >=20 > A slight modification suggestion below.=20 >=20 > > -----Original Message----- > > From: owner-voipeer@lists.uoregon.edu=20 > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of David Meyer > > Sent: Friday, October 21, 2005 11:12 AM > > To: Pfautz, Penn L, NEO > > Cc: voipeer@lists.uoregon.edu; enum@ietf.org > > Subject: Re: [voipeer] draft-meyer-voipeer-terminology-03.txt > >=20 > > On Fri, Oct 21, 2005 at 09:51:17AM -0400, Pfautz, Penn L, NEO wrote: > > > Dave: > > > This is a nice start (indeed more than a start). I just have two=20 > > > comments at this point: > > >=20 > > > 1. The definition of carrier in 3.6 is probably too=20 > restrictive. I=20 > > > would not make it contingent on issuance of E.164 numbers > > but rather > > > just the provision of PSTN service. I appreciate your use our=20 > > > carrier-of-record definition in 4.1. > >=20 > >=20 > > How about: > >=20 > > 3.6. Carrier > >=20 > > A carrier is defined to be a service provider authorized=20 > > to provision PSTN >=20 > The term PSTN is often used to mean the TDM networks offering=20 > publicly available telephony services. In order to get away=20 > from the TDM aspects, which some day might go away, how about: >=20 > a service provider authorized to offer telephony services to=20 > the public. >=20 > That should cover both cases and gets away from unintended=20 > baggage. I am assuming that the enterprises are not=20 > considered pseudo-carriers and intended to be covered here. >=20 > Mike >=20 > > services. Note that the provision of such services is usually > > coupled with the authority to issue E.164 numbers [ITU.E164.1991] > > under the authority of a National Regulatory Authority (NRA). > >=20 > > =09 > > > 2. In reference to Layer 3 Peering (Section 3.7.1) I would > > like to see > > > included the concepts that a) peering involves delivery=20 > of packets=20 > > > that terminate on the peer's network and b) peering is=20 > done without=20 > > > traffic settlement charges. > >=20 > > I'm ok with a) termination of traffic, but I'd like to > > avoid discussing SFI more than I have (see section > > 3.7). So how about: > >=20 > > 3.7.1. Layer 3 Peering > >=20 > > Layer 3 peering refers to interconnection of two service=20 > providers > > for the purposes of exchanging IP packets which destined for one=20 > > (or > > both) of the peer's networks. Layer 3 peering is generally=20 > > agnostic > > to the IP payload, and is frequently achieved using a routing > > protocol such as BGP [RFC1771] to exchange the required routing > > information. > >=20 > > An alternate, perhaps more operational definition of layer > > 3 peering > > is that two peers exchange their customer routers=20 > (only), and hence > > any traffic between peers terminates on on the peer's network. > >=20 > > =09 > > Dave > >=20 > > --- > >=20 > >=20 > >=20 > >=20 > > Network Working Group =20 > > D. Meyer > > Internet-Draft =20 > > October 21, 2005 > > Expires: April 24, 2006 > >=20 > >=20 > > Terminology for Describing VoIP Peering and Interconnect > > draft-meyer-voipeer-terminology-04.txt > >=20 > > Status of this Memo > >=20 > > By submitting this Internet-Draft, each author=20 > represents that any > > applicable patent or other IPR claims of which he or she is aware > > have been or will be disclosed, and any of which he or=20 > she becomes > > aware will be disclosed, in accordance with Section 6 of BCP 79. > >=20 > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF), its areas, and its working groups. Note that > > other groups may also distribute working documents as Internet- > > Drafts. > >=20 > > Internet-Drafts are draft documents valid for a maximum of six=20 > > months > > and may be updated, replaced, or obsoleted by other documents at=20 > > any > > time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as "work in progress." > >=20 > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/ietf/1id-abstracts.txt. > >=20 > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html. > >=20 > > This Internet-Draft will expire on April 24, 2006. > >=20 > > Copyright Notice > >=20 > > Copyright (C) The Internet Society (2005). > >=20 > > Abstract > >=20 > > This document defines the terminology that is to be used by the=20 > > Voice > > Over IP Peering and Interconnect Working Group=20 > (voipeer), and has=20 > > as > > its primary objective to focus the VOIPEER Working Group=20 > during its > > discussions, and when writing requirements, gap analysis=20 > and other > > solutions oriented documents. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 1] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > Table of Contents > >=20 > > 1. Introduction . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 3 > > 2. Context . . . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 3 > > 3. General Definitions . . . . . . . . . . . . . . . . .=20 > > . . . . 4 > > 3.1. Call Routing Data . . . . . . . . . . . . . . . .=20 > > . . . . 4 > > 3.2. Call Routing . . . . . . . . . . . . . . . . . . .=20 > > . . . . 4 > > 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 5 > > 3.4. Network . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 5 > > 3.5. VoIP Service Provider . . . . . . . . . . . . . .=20 > > . . . . 5 > > 3.6. Carrier . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 5 > > 3.7. Peering . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 5 > > 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 4.1. Carrier of Record . . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 4.2. Public ENUM . . . . . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 4.3. Private ENUM . . . . . . . . . . . . . . . . . . .=20 > > . . . . 7 > > 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . .=20 > > . . . . 7 > > 5. Conclusions . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 7 > > 6. Acknowledgments . . . . . . . . . . . . . . . . . . .=20 > > . . . . 7 > > 7. Security Considerations . . . . . . . . . . . . . . .=20 > > . . . . 8 > > 8. IANA Considerations . . . . . . . . . . . . . . . . .=20 > > . . . . 8 > > 9. References . . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 8 > > 9.1. Normative References . . . . . . . . . . . . . . .=20 > > . . . . 8 > > 9.2. Informative References . . . . . . . . . . . . . .=20 > > . . . . 8 > > Author's Address . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 10 > > Intellectual Property and Copyright Statements . . . . . .=20 > > . . . . 11 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 2] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > 1. Introduction > >=20 > > The term "VoIP Peering" has historically been used to describe a=20 > > wide > > variety of aspects pertaining to the interconnection of service > > provider networks and to the delivery of SIP call=20 > termination over > > those interconnections. The discussion of these=20 > interconnections=20 > > has > > at times been confused by the fact that the term "peering"=20 > > is used in > > various contexts to relate to interconnection at=20 > different levels=20 > > in > > a protocol stack. VoIP peering focuses on how to identify and=20 > > route > > calls at the application layer, and it does not > > (necessarily) involve > > the exchange of packet routing data or media sessions. In > > particular, "layer 5 network" is used here to refer to the > > interconnection between SIP servers, as opposed to=20 > interconnection=20 > > at > > the IP layer ("layer 3"). Finally, the terms "peering" and > > "interconnect" are used interchangeably throughout this document. > >=20 > > This document introduces standard terminology for use in > > characterizing VoIP interconnection. Note however, that=20 > while this > > document is primarily targeted at the VoIP interconnect case, the > > terminology described here is applicable to those cases in which > > service providers interconnect using SIP signaling for=20 > real-time or > > quasi-real-time communications. > >=20 > > The remainder of this document is organized as follows: Section 2 > > provides the general context for the VOIPEER Working Group, and > > Section 3 provides the general definitions for real-time=20 > SIP based > > communication, with focus on the VoIP interconnect case.=20 > Section 4 > > briefly touches on terms from the ENUM Working Group. Finally, > > Section 5 provides comments on usage. > >=20 > >=20 > > 2. Context > >=20 > > Figure 1 depicts the general VoIP interconnect context. In this > > case, the caller uses an E.164 number [ITU.E164.1991] as=20 > the "name" > > of the called user. Note that this E.164 number is not=20 > an address, > > since at this point we do not have information about where the=20 > > named > > endpoint is located. In the case shown here, an E.164 number is=20 > > used > > as a key to retrieve a NAPTR recored [RFC3404] from the=20 > DNS, which=20 > > in > > turn resolved into a SIP URI. Call routing is based on this SIP=20 > > URI. > > The call routing step does not depend on the presence of an E.164 > > number; the SIP URI can be advertised in various other=20 > ways, such=20 > > as > > on a web page. Finally, note that the subsequent lookup steps, > > namely, lookup of SRV, A, and AAAA records (as well as=20 > any routing > > steps below that) are outside the scope of VOIPEER. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 3] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > E.164 number <--- Peer Discovery > > | > > | <--- ENUM lookup of NAPTR in DNS > > | > > | > > | ENUM Working Group Scope > > = =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > | VOIPEER Working Group Scope > > | > > | > > SIP URI <--- Call Routing Data (CRD) > > | > > | <--- Service Location (Lookup of SRV in DNS) > > | > > | > > Hostname <--- VoIP addressing and session establishment > > | > > | <---- Lookup of A and AAAA in DNS > > | > > Ip address > > | > > | <---- Routing protocols, ARP etc > > | > > Mac-address > >=20 > > Figure 1: VoIP Interconnect Context > >=20 > > The ENUM Working Group is primarily concerned with the=20 > acquisition=20 > > of > > Call Routing Data, or CRD (i.e., above the double line in Figure=20 > > 1), > > while the VOIPEER Working Group is focused on the use of=20 > such CRD. > > Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS > > entry), or via any other mechanism available to the user. > >=20 > >=20 > > 3. General Definitions > >=20 > > 3.1. Call Routing Data > >=20 > > Call Routing Data, or CRD, is a SIP URI used to route a=20 > call (real- > > time, voice or other type) to the called domain's=20 > ingress point. A > > domain's ingress point can be thought of as the location=20 > pointed to > > by the SRV record that resulted from the resolution of the CRD=20 > > (i.e., > > a SIP URI). > >=20 > > 3.2. Call Routing > >=20 > > Call routing is the set of processes, rules, and CRD=20 > used to route=20 > > a > > VoIP call to its proper (SIP) destination. More generally, call > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 4] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > routing can be thought of as the set of processes, rules and CRD > > which are used to route a real-time session to its termination > > (ingress) point. > >=20 > > 3.3. PSTN > >=20 > > The term "PSTN" refers to the Public Switched Telephone=20 > Network. =20 > > In > > particular, the PSTN refers to the collection of interconnected > > circuit-switched voice-oriented public telephone networks, both > > commercial and government-owned. In general, PSTN terminals are > > addressed using E.164 numbers, noting that various=20 > dial-plans (such > > as emergency services dial-plans) may not directly use > > E.164 numbers. > >=20 > > 3.4. Network > >=20 > > For purposes of this document and the VOIPEER and ENUM Working > > Groups, a network is defined to be the set of SIP=20 > servers and end- > > users (customers) that are controlled by a single administrative > > domain. The network may also contain end-users who are=20 > located on > > the PSTN. > >=20 > > 3.5. VoIP Service Provider > >=20 > > A VoIP service provider is an entity that provides=20 > transport of SIP > > signaling (and possibly media streams) to its customers. Such a > > service provider may additionally be interconnected with other > > service providers; that is, it may "peer" with other service > > providers. A VoIP service provider may also=20 > interconnect with the > > PSTN. > >=20 > > Note that as soon as a ingress point is advertised via a SRV=20 > > record, > > anyone can find that ingress point and hence can send=20 > calls there. > > This is very similar to sending mail to a SMTP server=20 > based on the > > existence of a MX record. > >=20 > > 3.6. Carrier > >=20 > > A carrier is defined to be a service provider authorized to=20 > > provision > > PSTN services. Note that the provision of such services=20 > is usually > > coupled with the authority to issue E.164 numbers [ITU.E164.1991] > > under the authority of a National Regulatory Authority (NRA). > >=20 > > 3.7. Peering > >=20 > > While the precise definition of the term "peering" is=20 > the subject=20 > > of > > some debate, peering in general refers to the negotiation of > > reciprocal interconnection arrangements, settlement-free or > > otherwise, between operationally independent service providers. > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 5] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > This document distinguishes two types of peering, Layer=20 > 3 Peering=20 > > and > > Layer 5 peering, which are described below. > >=20 > > 3.7.1. Layer 3 Peering > >=20 > > Layer 3 peering refers to interconnection of two service=20 > providers > > for the purposes of exchanging IP packets which destined for one=20 > > (or > > both) of the peer's networks. Layer 3 peering is generally=20 > > agnostic > > to the IP payload, and is frequently achieved using a routing > > protocol such as BGP [RFC1771] to exchange the required routing > > information. > >=20 > > An alternate, perhaps more operational definition of layer > > 3 peering > > is that two peers exchange their customer routers=20 > (only), and hence > > any traffic between peers terminates on on the peer's network. > >=20 > > 3.7.2. Layer 5 Peering > >=20 > > Layer 5 peering refers to interconnection of two service=20 > providers > > for the purposes of SIP signaling. Note that in the layer > > 5 peering > > case, there is no intervening network. That is, for purposes of=20 > > this > > discussion, there is no such thing as a "Layer 5 Transit=20 > Network". > >=20 > > 3.8. VoIP Peering > >=20 > > VoIP peering is defined to be a layer 5 peering between two VoIP > > providers for purposes of routing real-time (or quasi-real > > time) call > > signaling between their respective customers. Media streams > > associated with this signaling (if any) are not constrained to=20 > > follow > > the same set of paths. > >=20 > >=20 > > 4. ENUM > >=20 > > ENUM [RFC3761] defines how the Domain Name System (DNS)=20 > can be used > > for identifying available services connected to one E.164 number. > >=20 > > 4.1. Carrier of Record > >=20 > > For purposes of this document, "Carrier of Record", or=20 > COR, refers=20 > > to > > the entity that provides PSTN service for an E.164 number > > [I-D.lind- > > infrastructure-enum-reqs]. The exact definition of who=20 > and what is=20 > > a > > COR is ultimately the responsibility of the relevant NRA. > >=20 > > 4.2. Public ENUM > >=20 > > Public ENUM is generally defined as the set=20 > administrative policies > > and procedures surrounding the use of the e164.arpa domain for > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 6] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > Telephone Number to URI resolution [RFC3761]. Policies and > > procedures for the registration of telephone numbers within all > > branches of the e164.arpa tree are Nation State issues=20 > by agreement > > with the IAB and ITU. National Regulatory Authorities have=20 > > generally > > defined Public ENUM Registrants as the E.164 number holder as=20 > > opposed > > to the COR that issued the phone number. > >=20 > > 4.3. Private ENUM > >=20 > > Private ENUM is generally regarded as one or more technologies > > (including DNS and SIP Redirect) that service providers or > > enterprises may use to exchange phone number to URI mappings in a > > private secure manner. Private ENUM may be used in any mutually > > agreed upon domain. Records in Private ENUM may be globally=20 > > visible > > but in most cases are not visible to the global Internet and are > > protected using a variety of security technologies such as=20 > > split-DNS, > > VPN's or various forms or authentication and authorization. > > Technical comments on issues surrounding split-DNS can=20 > be found in > > [RFC2826]. > >=20 > > 4.4. Carrier ENUM > >=20 > > Carrier ENUM is generally regarded as the use of a=20 > separate branch > > the e164.arpa tree, such as 4.4.c.e164.arpa to permit service > > providers to exchange phone number to URI data in order to find > > points of interconnection. The current theory of Carrier ENUM is > > that only the COR for a particular E.164 number is permitted to > > provision data for that E.164 within that portion of the=20 > e164.arpa > > tree. > >=20 > > In carrier ENUM case, only the COR may enter data in the > > corresponding domain. The COR may also enter CRD (i.e.,=20 > a SIP URI) > > to allow other VoIP Service Providers to route calls to its=20 > > network. > >=20 > > Finally, note that ENUM is not constrained to carry only=20 > data (CDR) > > as defined by VOIPEER. In particular, an an important class of=20 > > CRD, > > the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are > > most frequently used to interconnect with the PSTN directly, and=20 > > are > > out of scope for VOIPEER. On the other hand, PSTN=20 > endpoints served > > by a COR and reachable via CDR and networks as defined=20 > in Section=20 > > 3.1 > > and Section 3.4 are in scope for VOIPEER. > >=20 > >=20 > > 5. Conclusions > >=20 > >=20 > > 6. Acknowledgments > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 7] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > Many of the definitions were gleaned from detailed=20 > discussions on=20 > > the > > VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim,=20 > Mike Hammer, > > Jean-Francois Mule, Richard Shocky, and Richard Stastny made=20 > > valuable > > contributions to early revisions of this document. Patrik=20 > > Faltstrom > > also made many insightful comments to early versions of=20 > this draft, > > and contributed the basis of Figure 1. > >=20 > >=20 > > 7. Security Considerations > >=20 > > This document itself introduces no new security considerations. > > However, it is important to note that VoIP interconnect=20 > has a wide > > variety of security issues that should be considered in documents > > addressing both protocol and use case analyzes. > >=20 > >=20 > > 8. IANA Considerations > >=20 > > This document creates no new requirements on IANA namespaces > > [RFC2434]. > >=20 > >=20 > > 9. References > >=20 > > 9.1. Normative References > >=20 > > [RFC3404] Mealling, M., "Dynamic Delegation Discovery System=20 > > (DDDS) > > Part Four: The Uniform Resource Identifiers (URI)", > > RFC 3404, October 2002. > >=20 > > [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform > > Resource Identifiers (URI) Dynamic Delegation=20 > Discovery > > System (DDDS) Application (ENUM)", RFC 3761,=20 > April 2004. > >=20 > > [ITU.E164.1991] > > International Telecommunications Union, "The=20 > > International > > Public Telecommunication Numbering Plan", ITU- > > T Recommendation E.164, 1991. > >=20 > > [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", > > RFC 3966, December 2004. > >=20 > > 9.2. Informative References > >=20 > > [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 > > (BGP-4)", RFC 1771, March 1995. > >=20 > > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for=20 > Writing an > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 8] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > IANA Considerations Section in RFCs", BCP 26,=20 > RFC 2434, > > October 1998. > >=20 > > [RFC2826] Internet Architecture Board, "IAB Technical=20 > Comment on=20 > > the > > Unique DNS Root", RFC 2826, May 2000. > >=20 > > [I-D.lind-infrastructure-enum-reqs] > > Lind, S., "Infrastructure ENUM Requirements", > > draft-lind-infrastructure-enum-reqs-00 (work in=20 > > progress), > > July 2005. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 9] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > Author's Address > >=20 > > David Meyer > >=20 > > Email: dmm@1-4-5.net > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 10] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > Intellectual Property Statement > >=20 > > The IETF takes no position regarding the validity or scope of any > > Intellectual Property Rights or other rights that might=20 > be claimed=20 > > to > > pertain to the implementation or use of the technology=20 > described in > > this document or the extent to which any license under=20 > such rights > > might or might not be available; nor does it represent=20 > that it has > > made any independent effort to identify any such rights. =20 > > Information > > on the procedures with respect to rights in RFC documents can be > > found in BCP 78 and BCP 79. > >=20 > > Copies of IPR disclosures made to the IETF Secretariat and any > > assurances of licenses to be made available, or the result of an > > attempt made to obtain a general license or permission=20 > for the use=20 > > of > > such proprietary rights by implementers or users of this > > specification can be obtained from the IETF on-line IPR=20 > repository=20 > > at > > http://www.ietf.org/ipr. > >=20 > > The IETF invites any interested party to bring to its=20 > attention any > > copyrights, patents or patent applications, or other proprietary > > rights that may cover technology that may be required to=20 > implement > > this standard. Please address the information to the IETF at > > ietf-ipr@ietf.org. > >=20 > >=20 > > Disclaimer of Validity > >=20 > > This document and the information contained herein are=20 > provided on=20 > > an > > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE=20 > > REPRESENTS > > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND=20 > THE INTERNET > > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=20 > OR IMPLIED, > > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A=20 > PARTICULAR PURPOSE. > >=20 > >=20 > > Copyright Statement > >=20 > > Copyright (C) The Internet Society (2005). This document is=20 > > subject > > to the rights, licenses and restrictions contained in BCP 78, and > > except as set forth therein, the authors retain all their rights. > >=20 > >=20 > > Acknowledgment > >=20 > > Funding for the RFC Editor function is currently provided by the > > Internet Society. > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 11] > >=20 > >=20 > >=20 >=20 > ______________________________________________________________ > ______________ > _ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 21 15:04:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2BV-0008Ey-47; Fri, 21 Oct 2005 15:04:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2BT-0008Cz-GZ for enum@megatron.ietf.org; Fri, 21 Oct 2005 15:04:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26010 for ; Fri, 21 Oct 2005 15:03:56 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET2Nf-0002BW-5N for enum@ietf.org; Fri, 21 Oct 2005 15:16:44 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 21 Oct 2005 12:03:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,240,1125903600"; d="scan'208"; a="13646389:sNHT31847176" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9LJ3g2D006884; Fri, 21 Oct 2005 15:03:55 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 15:03:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Oct 2005 15:03:51 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3AE6892@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXWUrED2MtA7e4tT0aJ5p50zQ1crQAEXG5AAAEYuFAAAmbfcA== From: "Michael Hammer \(mhammer\)" To: , "David Meyer" , "Pfautz, Penn L, NEO" X-OriginalArrivalTime: 21 Oct 2005 19:03:52.0969 (UTC) FILETIME=[2D9B3790:01C5D672] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3ed10f57ffa811c79ed5316fc175578d Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org p.s. There are no carriers in Skype, correct? Mike=20 > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com]=20 > Sent: Friday, October 21, 2005 1:57 PM > To: Michael Hammer (mhammer); 'David Meyer'; 'Pfautz, Penn L, NEO' > Cc: voipeer@lists.uoregon.edu; enum@ietf.org > Subject: RE: [voipeer] draft-meyer-voipeer-terminology-03.txt >=20 > > a service provider authorized to offer telephony services=20 > to the public. >=20 > Does this include Skype? It's the biggest anyway. >=20 > :-) Thanks, Henry >=20 >=20 > =20 >=20 > -----Original Message----- > From: owner-voipeer@lists.uoregon.edu > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Hammer > (mhammer) > Sent: Friday, October 21, 2005 12:30 PM > To: David Meyer; Pfautz, Penn L, NEO > Cc: voipeer@lists.uoregon.edu; enum@ietf.org > Subject: RE: [voipeer] draft-meyer-voipeer-terminology-03.txt >=20 > David, >=20 > A slight modification suggestion below.=20 >=20 > > -----Original Message----- > > From: owner-voipeer@lists.uoregon.edu=20 > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of David Meyer > > Sent: Friday, October 21, 2005 11:12 AM > > To: Pfautz, Penn L, NEO > > Cc: voipeer@lists.uoregon.edu; enum@ietf.org > > Subject: Re: [voipeer] draft-meyer-voipeer-terminology-03.txt > >=20 > > On Fri, Oct 21, 2005 at 09:51:17AM -0400, Pfautz, Penn L, NEO wrote: > > > Dave: > > > This is a nice start (indeed more than a start). I just have two=20 > > > comments at this point: > > >=20 > > > 1. The definition of carrier in 3.6 is probably too=20 > restrictive. I=20 > > > would not make it contingent on issuance of E.164 numbers > > but rather > > > just the provision of PSTN service. I appreciate your use our=20 > > > carrier-of-record definition in 4.1. > >=20 > >=20 > > How about: > >=20 > > 3.6. Carrier > >=20 > > A carrier is defined to be a service provider authorized=20 > > to provision PSTN >=20 > The term PSTN is often used to mean the TDM networks offering=20 > publicly available telephony services. In order to get away=20 > from the TDM aspects, which some day might go away, how about: >=20 > a service provider authorized to offer telephony services to=20 > the public. >=20 > That should cover both cases and gets away from unintended=20 > baggage. I am assuming that the enterprises are not=20 > considered pseudo-carriers and intended to be covered here. >=20 > Mike >=20 > > services. Note that the provision of such services is usually > > coupled with the authority to issue E.164 numbers [ITU.E164.1991] > > under the authority of a National Regulatory Authority (NRA). > >=20 > > =09 > > > 2. In reference to Layer 3 Peering (Section 3.7.1) I would > > like to see > > > included the concepts that a) peering involves delivery=20 > of packets=20 > > > that terminate on the peer's network and b) peering is=20 > done without=20 > > > traffic settlement charges. > >=20 > > I'm ok with a) termination of traffic, but I'd like to > > avoid discussing SFI more than I have (see section > > 3.7). So how about: > >=20 > > 3.7.1. Layer 3 Peering > >=20 > > Layer 3 peering refers to interconnection of two service=20 > providers > > for the purposes of exchanging IP packets which destined for one=20 > > (or > > both) of the peer's networks. Layer 3 peering is generally=20 > > agnostic > > to the IP payload, and is frequently achieved using a routing > > protocol such as BGP [RFC1771] to exchange the required routing > > information. > >=20 > > An alternate, perhaps more operational definition of layer > > 3 peering > > is that two peers exchange their customer routers=20 > (only), and hence > > any traffic between peers terminates on on the peer's network. > >=20 > > =09 > > Dave > >=20 > > --- > >=20 > >=20 > >=20 > >=20 > > Network Working Group =20 > > D. Meyer > > Internet-Draft =20 > > October 21, 2005 > > Expires: April 24, 2006 > >=20 > >=20 > > Terminology for Describing VoIP Peering and Interconnect > > draft-meyer-voipeer-terminology-04.txt > >=20 > > Status of this Memo > >=20 > > By submitting this Internet-Draft, each author=20 > represents that any > > applicable patent or other IPR claims of which he or she is aware > > have been or will be disclosed, and any of which he or=20 > she becomes > > aware will be disclosed, in accordance with Section 6 of BCP 79. > >=20 > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF), its areas, and its working groups. Note that > > other groups may also distribute working documents as Internet- > > Drafts. > >=20 > > Internet-Drafts are draft documents valid for a maximum of six=20 > > months > > and may be updated, replaced, or obsoleted by other documents at=20 > > any > > time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as "work in progress." > >=20 > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/ietf/1id-abstracts.txt. > >=20 > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html. > >=20 > > This Internet-Draft will expire on April 24, 2006. > >=20 > > Copyright Notice > >=20 > > Copyright (C) The Internet Society (2005). > >=20 > > Abstract > >=20 > > This document defines the terminology that is to be used by the=20 > > Voice > > Over IP Peering and Interconnect Working Group=20 > (voipeer), and has=20 > > as > > its primary objective to focus the VOIPEER Working Group=20 > during its > > discussions, and when writing requirements, gap analysis=20 > and other > > solutions oriented documents. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 1] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > Table of Contents > >=20 > > 1. Introduction . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 3 > > 2. Context . . . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 3 > > 3. General Definitions . . . . . . . . . . . . . . . . .=20 > > . . . . 4 > > 3.1. Call Routing Data . . . . . . . . . . . . . . . .=20 > > . . . . 4 > > 3.2. Call Routing . . . . . . . . . . . . . . . . . . .=20 > > . . . . 4 > > 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 5 > > 3.4. Network . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 5 > > 3.5. VoIP Service Provider . . . . . . . . . . . . . .=20 > > . . . . 5 > > 3.6. Carrier . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 5 > > 3.7. Peering . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 5 > > 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 4.1. Carrier of Record . . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 4.2. Public ENUM . . . . . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 4.3. Private ENUM . . . . . . . . . . . . . . . . . . .=20 > > . . . . 7 > > 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . .=20 > > . . . . 7 > > 5. Conclusions . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 7 > > 6. Acknowledgments . . . . . . . . . . . . . . . . . . .=20 > > . . . . 7 > > 7. Security Considerations . . . . . . . . . . . . . . .=20 > > . . . . 8 > > 8. IANA Considerations . . . . . . . . . . . . . . . . .=20 > > . . . . 8 > > 9. References . . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 8 > > 9.1. Normative References . . . . . . . . . . . . . . .=20 > > . . . . 8 > > 9.2. Informative References . . . . . . . . . . . . . .=20 > > . . . . 8 > > Author's Address . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 10 > > Intellectual Property and Copyright Statements . . . . . .=20 > > . . . . 11 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 2] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > 1. Introduction > >=20 > > The term "VoIP Peering" has historically been used to describe a=20 > > wide > > variety of aspects pertaining to the interconnection of service > > provider networks and to the delivery of SIP call=20 > termination over > > those interconnections. The discussion of these=20 > interconnections=20 > > has > > at times been confused by the fact that the term "peering"=20 > > is used in > > various contexts to relate to interconnection at=20 > different levels=20 > > in > > a protocol stack. VoIP peering focuses on how to identify and=20 > > route > > calls at the application layer, and it does not > > (necessarily) involve > > the exchange of packet routing data or media sessions. In > > particular, "layer 5 network" is used here to refer to the > > interconnection between SIP servers, as opposed to=20 > interconnection=20 > > at > > the IP layer ("layer 3"). Finally, the terms "peering" and > > "interconnect" are used interchangeably throughout this document. > >=20 > > This document introduces standard terminology for use in > > characterizing VoIP interconnection. Note however, that=20 > while this > > document is primarily targeted at the VoIP interconnect case, the > > terminology described here is applicable to those cases in which > > service providers interconnect using SIP signaling for=20 > real-time or > > quasi-real-time communications. > >=20 > > The remainder of this document is organized as follows: Section 2 > > provides the general context for the VOIPEER Working Group, and > > Section 3 provides the general definitions for real-time=20 > SIP based > > communication, with focus on the VoIP interconnect case.=20 > Section 4 > > briefly touches on terms from the ENUM Working Group. Finally, > > Section 5 provides comments on usage. > >=20 > >=20 > > 2. Context > >=20 > > Figure 1 depicts the general VoIP interconnect context. In this > > case, the caller uses an E.164 number [ITU.E164.1991] as=20 > the "name" > > of the called user. Note that this E.164 number is not=20 > an address, > > since at this point we do not have information about where the=20 > > named > > endpoint is located. In the case shown here, an E.164 number is=20 > > used > > as a key to retrieve a NAPTR recored [RFC3404] from the=20 > DNS, which=20 > > in > > turn resolved into a SIP URI. Call routing is based on this SIP=20 > > URI. > > The call routing step does not depend on the presence of an E.164 > > number; the SIP URI can be advertised in various other=20 > ways, such=20 > > as > > on a web page. Finally, note that the subsequent lookup steps, > > namely, lookup of SRV, A, and AAAA records (as well as=20 > any routing > > steps below that) are outside the scope of VOIPEER. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 3] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > E.164 number <--- Peer Discovery > > | > > | <--- ENUM lookup of NAPTR in DNS > > | > > | > > | ENUM Working Group Scope > > = =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > | VOIPEER Working Group Scope > > | > > | > > SIP URI <--- Call Routing Data (CRD) > > | > > | <--- Service Location (Lookup of SRV in DNS) > > | > > | > > Hostname <--- VoIP addressing and session establishment > > | > > | <---- Lookup of A and AAAA in DNS > > | > > Ip address > > | > > | <---- Routing protocols, ARP etc > > | > > Mac-address > >=20 > > Figure 1: VoIP Interconnect Context > >=20 > > The ENUM Working Group is primarily concerned with the=20 > acquisition=20 > > of > > Call Routing Data, or CRD (i.e., above the double line in Figure=20 > > 1), > > while the VOIPEER Working Group is focused on the use of=20 > such CRD. > > Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS > > entry), or via any other mechanism available to the user. > >=20 > >=20 > > 3. General Definitions > >=20 > > 3.1. Call Routing Data > >=20 > > Call Routing Data, or CRD, is a SIP URI used to route a=20 > call (real- > > time, voice or other type) to the called domain's=20 > ingress point. A > > domain's ingress point can be thought of as the location=20 > pointed to > > by the SRV record that resulted from the resolution of the CRD=20 > > (i.e., > > a SIP URI). > >=20 > > 3.2. Call Routing > >=20 > > Call routing is the set of processes, rules, and CRD=20 > used to route=20 > > a > > VoIP call to its proper (SIP) destination. More generally, call > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 4] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > routing can be thought of as the set of processes, rules and CRD > > which are used to route a real-time session to its termination > > (ingress) point. > >=20 > > 3.3. PSTN > >=20 > > The term "PSTN" refers to the Public Switched Telephone=20 > Network. =20 > > In > > particular, the PSTN refers to the collection of interconnected > > circuit-switched voice-oriented public telephone networks, both > > commercial and government-owned. In general, PSTN terminals are > > addressed using E.164 numbers, noting that various=20 > dial-plans (such > > as emergency services dial-plans) may not directly use > > E.164 numbers. > >=20 > > 3.4. Network > >=20 > > For purposes of this document and the VOIPEER and ENUM Working > > Groups, a network is defined to be the set of SIP=20 > servers and end- > > users (customers) that are controlled by a single administrative > > domain. The network may also contain end-users who are=20 > located on > > the PSTN. > >=20 > > 3.5. VoIP Service Provider > >=20 > > A VoIP service provider is an entity that provides=20 > transport of SIP > > signaling (and possibly media streams) to its customers. Such a > > service provider may additionally be interconnected with other > > service providers; that is, it may "peer" with other service > > providers. A VoIP service provider may also=20 > interconnect with the > > PSTN. > >=20 > > Note that as soon as a ingress point is advertised via a SRV=20 > > record, > > anyone can find that ingress point and hence can send=20 > calls there. > > This is very similar to sending mail to a SMTP server=20 > based on the > > existence of a MX record. > >=20 > > 3.6. Carrier > >=20 > > A carrier is defined to be a service provider authorized to=20 > > provision > > PSTN services. Note that the provision of such services=20 > is usually > > coupled with the authority to issue E.164 numbers [ITU.E164.1991] > > under the authority of a National Regulatory Authority (NRA). > >=20 > > 3.7. Peering > >=20 > > While the precise definition of the term "peering" is=20 > the subject=20 > > of > > some debate, peering in general refers to the negotiation of > > reciprocal interconnection arrangements, settlement-free or > > otherwise, between operationally independent service providers. > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 5] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > This document distinguishes two types of peering, Layer=20 > 3 Peering=20 > > and > > Layer 5 peering, which are described below. > >=20 > > 3.7.1. Layer 3 Peering > >=20 > > Layer 3 peering refers to interconnection of two service=20 > providers > > for the purposes of exchanging IP packets which destined for one=20 > > (or > > both) of the peer's networks. Layer 3 peering is generally=20 > > agnostic > > to the IP payload, and is frequently achieved using a routing > > protocol such as BGP [RFC1771] to exchange the required routing > > information. > >=20 > > An alternate, perhaps more operational definition of layer > > 3 peering > > is that two peers exchange their customer routers=20 > (only), and hence > > any traffic between peers terminates on on the peer's network. > >=20 > > 3.7.2. Layer 5 Peering > >=20 > > Layer 5 peering refers to interconnection of two service=20 > providers > > for the purposes of SIP signaling. Note that in the layer > > 5 peering > > case, there is no intervening network. That is, for purposes of=20 > > this > > discussion, there is no such thing as a "Layer 5 Transit=20 > Network". > >=20 > > 3.8. VoIP Peering > >=20 > > VoIP peering is defined to be a layer 5 peering between two VoIP > > providers for purposes of routing real-time (or quasi-real > > time) call > > signaling between their respective customers. Media streams > > associated with this signaling (if any) are not constrained to=20 > > follow > > the same set of paths. > >=20 > >=20 > > 4. ENUM > >=20 > > ENUM [RFC3761] defines how the Domain Name System (DNS)=20 > can be used > > for identifying available services connected to one E.164 number. > >=20 > > 4.1. Carrier of Record > >=20 > > For purposes of this document, "Carrier of Record", or=20 > COR, refers=20 > > to > > the entity that provides PSTN service for an E.164 number > > [I-D.lind- > > infrastructure-enum-reqs]. The exact definition of who=20 > and what is=20 > > a > > COR is ultimately the responsibility of the relevant NRA. > >=20 > > 4.2. Public ENUM > >=20 > > Public ENUM is generally defined as the set=20 > administrative policies > > and procedures surrounding the use of the e164.arpa domain for > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 6] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > Telephone Number to URI resolution [RFC3761]. Policies and > > procedures for the registration of telephone numbers within all > > branches of the e164.arpa tree are Nation State issues=20 > by agreement > > with the IAB and ITU. National Regulatory Authorities have=20 > > generally > > defined Public ENUM Registrants as the E.164 number holder as=20 > > opposed > > to the COR that issued the phone number. > >=20 > > 4.3. Private ENUM > >=20 > > Private ENUM is generally regarded as one or more technologies > > (including DNS and SIP Redirect) that service providers or > > enterprises may use to exchange phone number to URI mappings in a > > private secure manner. Private ENUM may be used in any mutually > > agreed upon domain. Records in Private ENUM may be globally=20 > > visible > > but in most cases are not visible to the global Internet and are > > protected using a variety of security technologies such as=20 > > split-DNS, > > VPN's or various forms or authentication and authorization. > > Technical comments on issues surrounding split-DNS can=20 > be found in > > [RFC2826]. > >=20 > > 4.4. Carrier ENUM > >=20 > > Carrier ENUM is generally regarded as the use of a=20 > separate branch > > the e164.arpa tree, such as 4.4.c.e164.arpa to permit service > > providers to exchange phone number to URI data in order to find > > points of interconnection. The current theory of Carrier ENUM is > > that only the COR for a particular E.164 number is permitted to > > provision data for that E.164 within that portion of the=20 > e164.arpa > > tree. > >=20 > > In carrier ENUM case, only the COR may enter data in the > > corresponding domain. The COR may also enter CRD (i.e.,=20 > a SIP URI) > > to allow other VoIP Service Providers to route calls to its=20 > > network. > >=20 > > Finally, note that ENUM is not constrained to carry only=20 > data (CDR) > > as defined by VOIPEER. In particular, an an important class of=20 > > CRD, > > the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are > > most frequently used to interconnect with the PSTN directly, and=20 > > are > > out of scope for VOIPEER. On the other hand, PSTN=20 > endpoints served > > by a COR and reachable via CDR and networks as defined=20 > in Section=20 > > 3.1 > > and Section 3.4 are in scope for VOIPEER. > >=20 > >=20 > > 5. Conclusions > >=20 > >=20 > > 6. Acknowledgments > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 7] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > Many of the definitions were gleaned from detailed=20 > discussions on=20 > > the > > VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim,=20 > Mike Hammer, > > Jean-Francois Mule, Richard Shocky, and Richard Stastny made=20 > > valuable > > contributions to early revisions of this document. Patrik=20 > > Faltstrom > > also made many insightful comments to early versions of=20 > this draft, > > and contributed the basis of Figure 1. > >=20 > >=20 > > 7. Security Considerations > >=20 > > This document itself introduces no new security considerations. > > However, it is important to note that VoIP interconnect=20 > has a wide > > variety of security issues that should be considered in documents > > addressing both protocol and use case analyzes. > >=20 > >=20 > > 8. IANA Considerations > >=20 > > This document creates no new requirements on IANA namespaces > > [RFC2434]. > >=20 > >=20 > > 9. References > >=20 > > 9.1. Normative References > >=20 > > [RFC3404] Mealling, M., "Dynamic Delegation Discovery System=20 > > (DDDS) > > Part Four: The Uniform Resource Identifiers (URI)", > > RFC 3404, October 2002. > >=20 > > [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform > > Resource Identifiers (URI) Dynamic Delegation=20 > Discovery > > System (DDDS) Application (ENUM)", RFC 3761,=20 > April 2004. > >=20 > > [ITU.E164.1991] > > International Telecommunications Union, "The=20 > > International > > Public Telecommunication Numbering Plan", ITU- > > T Recommendation E.164, 1991. > >=20 > > [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", > > RFC 3966, December 2004. > >=20 > > 9.2. Informative References > >=20 > > [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 > > (BGP-4)", RFC 1771, March 1995. > >=20 > > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for=20 > Writing an > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 8] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > IANA Considerations Section in RFCs", BCP 26,=20 > RFC 2434, > > October 1998. > >=20 > > [RFC2826] Internet Architecture Board, "IAB Technical=20 > Comment on=20 > > the > > Unique DNS Root", RFC 2826, May 2000. > >=20 > > [I-D.lind-infrastructure-enum-reqs] > > Lind, S., "Infrastructure ENUM Requirements", > > draft-lind-infrastructure-enum-reqs-00 (work in=20 > > progress), > > July 2005. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 9] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > Author's Address > >=20 > > David Meyer > >=20 > > Email: dmm@1-4-5.net > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 10] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > Intellectual Property Statement > >=20 > > The IETF takes no position regarding the validity or scope of any > > Intellectual Property Rights or other rights that might=20 > be claimed=20 > > to > > pertain to the implementation or use of the technology=20 > described in > > this document or the extent to which any license under=20 > such rights > > might or might not be available; nor does it represent=20 > that it has > > made any independent effort to identify any such rights. =20 > > Information > > on the procedures with respect to rights in RFC documents can be > > found in BCP 78 and BCP 79. > >=20 > > Copies of IPR disclosures made to the IETF Secretariat and any > > assurances of licenses to be made available, or the result of an > > attempt made to obtain a general license or permission=20 > for the use=20 > > of > > such proprietary rights by implementers or users of this > > specification can be obtained from the IETF on-line IPR=20 > repository=20 > > at > > http://www.ietf.org/ipr. > >=20 > > The IETF invites any interested party to bring to its=20 > attention any > > copyrights, patents or patent applications, or other proprietary > > rights that may cover technology that may be required to=20 > implement > > this standard. Please address the information to the IETF at > > ietf-ipr@ietf.org. > >=20 > >=20 > > Disclaimer of Validity > >=20 > > This document and the information contained herein are=20 > provided on=20 > > an > > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE=20 > > REPRESENTS > > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND=20 > THE INTERNET > > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=20 > OR IMPLIED, > > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A=20 > PARTICULAR PURPOSE. > >=20 > >=20 > > Copyright Statement > >=20 > > Copyright (C) The Internet Society (2005). This document is=20 > > subject > > to the rights, licenses and restrictions contained in BCP 78, and > > except as set forth therein, the authors retain all their rights. > >=20 > >=20 > > Acknowledgment > >=20 > > Funding for the RFC Editor function is currently provided by the > > Internet Society. > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 11] > >=20 > >=20 > >=20 >=20 > ______________________________________________________________ > ______________ > _ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 21 15:09:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2Gh-0001y4-NO; Fri, 21 Oct 2005 15:09:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2Gf-0001xz-TU for enum@megatron.ietf.org; Fri, 21 Oct 2005 15:09:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26413 for ; Fri, 21 Oct 2005 15:09:18 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET2Sr-0002Qs-1l for enum@ietf.org; Fri, 21 Oct 2005 15:22:06 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 21 Oct 2005 12:09:19 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9LJ8x9C027451; Fri, 21 Oct 2005 12:09:16 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 15:09:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Date: Fri, 21 Oct 2005 15:09:10 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3AE6897@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXWUrED2MtA7e4tT0aJ5p50zQ1crQAEXG5AAAJanXQAAU5aMA== From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "David Meyer" , "Pfautz, Penn L, NEO" X-OriginalArrivalTime: 21 Oct 2005 19:09:11.0364 (UTC) FILETIME=[EB627040:01C5D672] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Is the issue that you want to define an entity that may or may not be regulated, but could still be a carrier? Maybe an example would help point out the case that is problematic. Mike =20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Friday, October 21, 2005 2:37 PM > To: Michael Hammer (mhammer); David Meyer; Pfautz, Penn L, NEO > Cc: enum@ietf.org; voipeer@lists.uoregon.edu > Subject: RE: [Enum] RE: [voipeer]=20 > draft-meyer-voipeer-terminology-03.txt >=20 > Mike, Dave, > =20 > >> A carrier is defined to be a service provider authorized > >> to provision PSTN >=20 > >The term PSTN is often used to mean the TDM networks=20 > offering publicly=20 > >available telephony services. In order to get away from the TDM=20 > >aspects, which some day might go away, how about: >=20 > >a service provider authorized to offer telephony services to=20 > the public. >=20 > >That should cover both cases and gets away from unintended=20 > baggage. I=20 > >am assuming that the enterprises are not considered=20 > pseudo-carriers and > i>ntended to be covered here. >=20 > I have no solution to offer at the moment, but I have a=20 > problem with the term public available telephony service=20 > (PATS). This term has a special meaning in Europe and is a=20 > subset of the term electronic communication service (ECS),=20 > both defined in the framework and under heavy discussion in=20 > the context of VoIP. > =20 > Richard >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 21 15:10:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2Hu-0002ej-OM; Fri, 21 Oct 2005 15:10:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2Hs-0002d3-UL for enum@megatron.ietf.org; Fri, 21 Oct 2005 15:10:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26545 for ; Fri, 21 Oct 2005 15:10:33 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ET2U1-0002TK-G1 for enum@ietf.org; Fri, 21 Oct 2005 15:23:21 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1129921728!6071165!38 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 17436 invoked from network); 21 Oct 2005 19:10:30 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-12.tower-121.messagelabs.com with SMTP; 21 Oct 2005 19:10:30 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 4355D409002670BF; Fri, 21 Oct 2005 15:10:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Oct 2005 15:10:26 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0B5E451E@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXWUrED2MtA7e4tT0aJ5p50zQ1crQAEXG5AAAEYuFAAAlve4AAAGtvg From: "Pfautz, Penn L, NEO" To: "Michael Hammer \(mhammer\)" , , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: e19fe12a2b60f5c397f73b74149e8776 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org In terms of the terminology Dave offered, Skype is a VoIP Service Provider but not a Carrier (I exclude SkypeIn which is probably offered through another carrier anyway)=20 -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Friday, October 21, 2005 3:03 PM To: henry@pulver.com; David Meyer; Pfautz, Penn L, NEO Cc: voipeer@lists.uoregon.edu; enum@ietf.org Subject: RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Are they using E.164 numbers yet? If so, who are they getting them from? Mike =20 > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com]=20 > Sent: Friday, October 21, 2005 1:57 PM > To: Michael Hammer (mhammer); 'David Meyer'; 'Pfautz, Penn L, NEO' > Cc: voipeer@lists.uoregon.edu; enum@ietf.org > Subject: RE: [voipeer] draft-meyer-voipeer-terminology-03.txt >=20 > > a service provider authorized to offer telephony services=20 > to the public. >=20 > Does this include Skype? It's the biggest anyway. >=20 > :-) Thanks, Henry >=20 >=20 > =20 >=20 > -----Original Message----- > From: owner-voipeer@lists.uoregon.edu > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Hammer > (mhammer) > Sent: Friday, October 21, 2005 12:30 PM > To: David Meyer; Pfautz, Penn L, NEO > Cc: voipeer@lists.uoregon.edu; enum@ietf.org > Subject: RE: [voipeer] draft-meyer-voipeer-terminology-03.txt >=20 > David, >=20 > A slight modification suggestion below.=20 >=20 > > -----Original Message----- > > From: owner-voipeer@lists.uoregon.edu=20 > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of David Meyer > > Sent: Friday, October 21, 2005 11:12 AM > > To: Pfautz, Penn L, NEO > > Cc: voipeer@lists.uoregon.edu; enum@ietf.org > > Subject: Re: [voipeer] draft-meyer-voipeer-terminology-03.txt > >=20 > > On Fri, Oct 21, 2005 at 09:51:17AM -0400, Pfautz, Penn L, NEO wrote: > > > Dave: > > > This is a nice start (indeed more than a start). I just have two=20 > > > comments at this point: > > >=20 > > > 1. The definition of carrier in 3.6 is probably too=20 > restrictive. I=20 > > > would not make it contingent on issuance of E.164 numbers > > but rather > > > just the provision of PSTN service. I appreciate your use our=20 > > > carrier-of-record definition in 4.1. > >=20 > >=20 > > How about: > >=20 > > 3.6. Carrier > >=20 > > A carrier is defined to be a service provider authorized=20 > > to provision PSTN >=20 > The term PSTN is often used to mean the TDM networks offering=20 > publicly available telephony services. In order to get away=20 > from the TDM aspects, which some day might go away, how about: >=20 > a service provider authorized to offer telephony services to=20 > the public. >=20 > That should cover both cases and gets away from unintended=20 > baggage. I am assuming that the enterprises are not=20 > considered pseudo-carriers and intended to be covered here. >=20 > Mike >=20 > > services. Note that the provision of such services is usually > > coupled with the authority to issue E.164 numbers [ITU.E164.1991] > > under the authority of a National Regulatory Authority (NRA). > >=20 > > =09 > > > 2. In reference to Layer 3 Peering (Section 3.7.1) I would > > like to see > > > included the concepts that a) peering involves delivery=20 > of packets=20 > > > that terminate on the peer's network and b) peering is=20 > done without=20 > > > traffic settlement charges. > >=20 > > I'm ok with a) termination of traffic, but I'd like to > > avoid discussing SFI more than I have (see section > > 3.7). So how about: > >=20 > > 3.7.1. Layer 3 Peering > >=20 > > Layer 3 peering refers to interconnection of two service=20 > providers > > for the purposes of exchanging IP packets which destined for one=20 > > (or > > both) of the peer's networks. Layer 3 peering is generally=20 > > agnostic > > to the IP payload, and is frequently achieved using a routing > > protocol such as BGP [RFC1771] to exchange the required routing > > information. > >=20 > > An alternate, perhaps more operational definition of layer > > 3 peering > > is that two peers exchange their customer routers=20 > (only), and hence > > any traffic between peers terminates on on the peer's network. > >=20 > > =09 > > Dave > >=20 > > --- > >=20 > >=20 > >=20 > >=20 > > Network Working Group =20 > > D. Meyer > > Internet-Draft =20 > > October 21, 2005 > > Expires: April 24, 2006 > >=20 > >=20 > > Terminology for Describing VoIP Peering and Interconnect > > draft-meyer-voipeer-terminology-04.txt > >=20 > > Status of this Memo > >=20 > > By submitting this Internet-Draft, each author=20 > represents that any > > applicable patent or other IPR claims of which he or she is aware > > have been or will be disclosed, and any of which he or=20 > she becomes > > aware will be disclosed, in accordance with Section 6 of BCP 79. > >=20 > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF), its areas, and its working groups. Note that > > other groups may also distribute working documents as Internet- > > Drafts. > >=20 > > Internet-Drafts are draft documents valid for a maximum of six=20 > > months > > and may be updated, replaced, or obsoleted by other documents at=20 > > any > > time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as "work in progress." > >=20 > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/ietf/1id-abstracts.txt. > >=20 > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html. > >=20 > > This Internet-Draft will expire on April 24, 2006. > >=20 > > Copyright Notice > >=20 > > Copyright (C) The Internet Society (2005). > >=20 > > Abstract > >=20 > > This document defines the terminology that is to be used by the=20 > > Voice > > Over IP Peering and Interconnect Working Group=20 > (voipeer), and has=20 > > as > > its primary objective to focus the VOIPEER Working Group=20 > during its > > discussions, and when writing requirements, gap analysis=20 > and other > > solutions oriented documents. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 1] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > Table of Contents > >=20 > > 1. Introduction . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 3 > > 2. Context . . . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 3 > > 3. General Definitions . . . . . . . . . . . . . . . . .=20 > > . . . . 4 > > 3.1. Call Routing Data . . . . . . . . . . . . . . . .=20 > > . . . . 4 > > 3.2. Call Routing . . . . . . . . . . . . . . . . . . .=20 > > . . . . 4 > > 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 5 > > 3.4. Network . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 5 > > 3.5. VoIP Service Provider . . . . . . . . . . . . . .=20 > > . . . . 5 > > 3.6. Carrier . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 5 > > 3.7. Peering . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 5 > > 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 4.1. Carrier of Record . . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 4.2. Public ENUM . . . . . . . . . . . . . . . . . . .=20 > > . . . . 6 > > 4.3. Private ENUM . . . . . . . . . . . . . . . . . . .=20 > > . . . . 7 > > 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . .=20 > > . . . . 7 > > 5. Conclusions . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 7 > > 6. Acknowledgments . . . . . . . . . . . . . . . . . . .=20 > > . . . . 7 > > 7. Security Considerations . . . . . . . . . . . . . . .=20 > > . . . . 8 > > 8. IANA Considerations . . . . . . . . . . . . . . . . .=20 > > . . . . 8 > > 9. References . . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 8 > > 9.1. Normative References . . . . . . . . . . . . . . .=20 > > . . . . 8 > > 9.2. Informative References . . . . . . . . . . . . . .=20 > > . . . . 8 > > Author's Address . . . . . . . . . . . . . . . . . . . . .=20 > > . . . . 10 > > Intellectual Property and Copyright Statements . . . . . .=20 > > . . . . 11 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 2] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > 1. Introduction > >=20 > > The term "VoIP Peering" has historically been used to describe a=20 > > wide > > variety of aspects pertaining to the interconnection of service > > provider networks and to the delivery of SIP call=20 > termination over > > those interconnections. The discussion of these=20 > interconnections=20 > > has > > at times been confused by the fact that the term "peering"=20 > > is used in > > various contexts to relate to interconnection at=20 > different levels=20 > > in > > a protocol stack. VoIP peering focuses on how to identify and=20 > > route > > calls at the application layer, and it does not > > (necessarily) involve > > the exchange of packet routing data or media sessions. In > > particular, "layer 5 network" is used here to refer to the > > interconnection between SIP servers, as opposed to=20 > interconnection=20 > > at > > the IP layer ("layer 3"). Finally, the terms "peering" and > > "interconnect" are used interchangeably throughout this document. > >=20 > > This document introduces standard terminology for use in > > characterizing VoIP interconnection. Note however, that=20 > while this > > document is primarily targeted at the VoIP interconnect case, the > > terminology described here is applicable to those cases in which > > service providers interconnect using SIP signaling for=20 > real-time or > > quasi-real-time communications. > >=20 > > The remainder of this document is organized as follows: Section 2 > > provides the general context for the VOIPEER Working Group, and > > Section 3 provides the general definitions for real-time=20 > SIP based > > communication, with focus on the VoIP interconnect case.=20 > Section 4 > > briefly touches on terms from the ENUM Working Group. Finally, > > Section 5 provides comments on usage. > >=20 > >=20 > > 2. Context > >=20 > > Figure 1 depicts the general VoIP interconnect context. In this > > case, the caller uses an E.164 number [ITU.E164.1991] as=20 > the "name" > > of the called user. Note that this E.164 number is not=20 > an address, > > since at this point we do not have information about where the=20 > > named > > endpoint is located. In the case shown here, an E.164 number is=20 > > used > > as a key to retrieve a NAPTR recored [RFC3404] from the=20 > DNS, which=20 > > in > > turn resolved into a SIP URI. Call routing is based on this SIP=20 > > URI. > > The call routing step does not depend on the presence of an E.164 > > number; the SIP URI can be advertised in various other=20 > ways, such=20 > > as > > on a web page. Finally, note that the subsequent lookup steps, > > namely, lookup of SRV, A, and AAAA records (as well as=20 > any routing > > steps below that) are outside the scope of VOIPEER. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 3] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > E.164 number <--- Peer Discovery > > | > > | <--- ENUM lookup of NAPTR in DNS > > | > > | > > | ENUM Working Group Scope > > = =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > | VOIPEER Working Group Scope > > | > > | > > SIP URI <--- Call Routing Data (CRD) > > | > > | <--- Service Location (Lookup of SRV in DNS) > > | > > | > > Hostname <--- VoIP addressing and session establishment > > | > > | <---- Lookup of A and AAAA in DNS > > | > > Ip address > > | > > | <---- Routing protocols, ARP etc > > | > > Mac-address > >=20 > > Figure 1: VoIP Interconnect Context > >=20 > > The ENUM Working Group is primarily concerned with the=20 > acquisition=20 > > of > > Call Routing Data, or CRD (i.e., above the double line in Figure=20 > > 1), > > while the VOIPEER Working Group is focused on the use of=20 > such CRD. > > Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS > > entry), or via any other mechanism available to the user. > >=20 > >=20 > > 3. General Definitions > >=20 > > 3.1. Call Routing Data > >=20 > > Call Routing Data, or CRD, is a SIP URI used to route a=20 > call (real- > > time, voice or other type) to the called domain's=20 > ingress point. A > > domain's ingress point can be thought of as the location=20 > pointed to > > by the SRV record that resulted from the resolution of the CRD=20 > > (i.e., > > a SIP URI). > >=20 > > 3.2. Call Routing > >=20 > > Call routing is the set of processes, rules, and CRD=20 > used to route=20 > > a > > VoIP call to its proper (SIP) destination. More generally, call > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 4] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > routing can be thought of as the set of processes, rules and CRD > > which are used to route a real-time session to its termination > > (ingress) point. > >=20 > > 3.3. PSTN > >=20 > > The term "PSTN" refers to the Public Switched Telephone=20 > Network. =20 > > In > > particular, the PSTN refers to the collection of interconnected > > circuit-switched voice-oriented public telephone networks, both > > commercial and government-owned. In general, PSTN terminals are > > addressed using E.164 numbers, noting that various=20 > dial-plans (such > > as emergency services dial-plans) may not directly use > > E.164 numbers. > >=20 > > 3.4. Network > >=20 > > For purposes of this document and the VOIPEER and ENUM Working > > Groups, a network is defined to be the set of SIP=20 > servers and end- > > users (customers) that are controlled by a single administrative > > domain. The network may also contain end-users who are=20 > located on > > the PSTN. > >=20 > > 3.5. VoIP Service Provider > >=20 > > A VoIP service provider is an entity that provides=20 > transport of SIP > > signaling (and possibly media streams) to its customers. Such a > > service provider may additionally be interconnected with other > > service providers; that is, it may "peer" with other service > > providers. A VoIP service provider may also=20 > interconnect with the > > PSTN. > >=20 > > Note that as soon as a ingress point is advertised via a SRV=20 > > record, > > anyone can find that ingress point and hence can send=20 > calls there. > > This is very similar to sending mail to a SMTP server=20 > based on the > > existence of a MX record. > >=20 > > 3.6. Carrier > >=20 > > A carrier is defined to be a service provider authorized to=20 > > provision > > PSTN services. Note that the provision of such services=20 > is usually > > coupled with the authority to issue E.164 numbers [ITU.E164.1991] > > under the authority of a National Regulatory Authority (NRA). > >=20 > > 3.7. Peering > >=20 > > While the precise definition of the term "peering" is=20 > the subject=20 > > of > > some debate, peering in general refers to the negotiation of > > reciprocal interconnection arrangements, settlement-free or > > otherwise, between operationally independent service providers. > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 5] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > This document distinguishes two types of peering, Layer=20 > 3 Peering=20 > > and > > Layer 5 peering, which are described below. > >=20 > > 3.7.1. Layer 3 Peering > >=20 > > Layer 3 peering refers to interconnection of two service=20 > providers > > for the purposes of exchanging IP packets which destined for one=20 > > (or > > both) of the peer's networks. Layer 3 peering is generally=20 > > agnostic > > to the IP payload, and is frequently achieved using a routing > > protocol such as BGP [RFC1771] to exchange the required routing > > information. > >=20 > > An alternate, perhaps more operational definition of layer > > 3 peering > > is that two peers exchange their customer routers=20 > (only), and hence > > any traffic between peers terminates on on the peer's network. > >=20 > > 3.7.2. Layer 5 Peering > >=20 > > Layer 5 peering refers to interconnection of two service=20 > providers > > for the purposes of SIP signaling. Note that in the layer > > 5 peering > > case, there is no intervening network. That is, for purposes of=20 > > this > > discussion, there is no such thing as a "Layer 5 Transit=20 > Network". > >=20 > > 3.8. VoIP Peering > >=20 > > VoIP peering is defined to be a layer 5 peering between two VoIP > > providers for purposes of routing real-time (or quasi-real > > time) call > > signaling between their respective customers. Media streams > > associated with this signaling (if any) are not constrained to=20 > > follow > > the same set of paths. > >=20 > >=20 > > 4. ENUM > >=20 > > ENUM [RFC3761] defines how the Domain Name System (DNS)=20 > can be used > > for identifying available services connected to one E.164 number. > >=20 > > 4.1. Carrier of Record > >=20 > > For purposes of this document, "Carrier of Record", or=20 > COR, refers=20 > > to > > the entity that provides PSTN service for an E.164 number > > [I-D.lind- > > infrastructure-enum-reqs]. The exact definition of who=20 > and what is=20 > > a > > COR is ultimately the responsibility of the relevant NRA. > >=20 > > 4.2. Public ENUM > >=20 > > Public ENUM is generally defined as the set=20 > administrative policies > > and procedures surrounding the use of the e164.arpa domain for > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 6] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > Telephone Number to URI resolution [RFC3761]. Policies and > > procedures for the registration of telephone numbers within all > > branches of the e164.arpa tree are Nation State issues=20 > by agreement > > with the IAB and ITU. National Regulatory Authorities have=20 > > generally > > defined Public ENUM Registrants as the E.164 number holder as=20 > > opposed > > to the COR that issued the phone number. > >=20 > > 4.3. Private ENUM > >=20 > > Private ENUM is generally regarded as one or more technologies > > (including DNS and SIP Redirect) that service providers or > > enterprises may use to exchange phone number to URI mappings in a > > private secure manner. Private ENUM may be used in any mutually > > agreed upon domain. Records in Private ENUM may be globally=20 > > visible > > but in most cases are not visible to the global Internet and are > > protected using a variety of security technologies such as=20 > > split-DNS, > > VPN's or various forms or authentication and authorization. > > Technical comments on issues surrounding split-DNS can=20 > be found in > > [RFC2826]. > >=20 > > 4.4. Carrier ENUM > >=20 > > Carrier ENUM is generally regarded as the use of a=20 > separate branch > > the e164.arpa tree, such as 4.4.c.e164.arpa to permit service > > providers to exchange phone number to URI data in order to find > > points of interconnection. The current theory of Carrier ENUM is > > that only the COR for a particular E.164 number is permitted to > > provision data for that E.164 within that portion of the=20 > e164.arpa > > tree. > >=20 > > In carrier ENUM case, only the COR may enter data in the > > corresponding domain. The COR may also enter CRD (i.e.,=20 > a SIP URI) > > to allow other VoIP Service Providers to route calls to its=20 > > network. > >=20 > > Finally, note that ENUM is not constrained to carry only=20 > data (CDR) > > as defined by VOIPEER. In particular, an an important class of=20 > > CRD, > > the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are > > most frequently used to interconnect with the PSTN directly, and=20 > > are > > out of scope for VOIPEER. On the other hand, PSTN=20 > endpoints served > > by a COR and reachable via CDR and networks as defined=20 > in Section=20 > > 3.1 > > and Section 3.4 are in scope for VOIPEER. > >=20 > >=20 > > 5. Conclusions > >=20 > >=20 > > 6. Acknowledgments > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 7] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > Many of the definitions were gleaned from detailed=20 > discussions on=20 > > the > > VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim,=20 > Mike Hammer, > > Jean-Francois Mule, Richard Shocky, and Richard Stastny made=20 > > valuable > > contributions to early revisions of this document. Patrik=20 > > Faltstrom > > also made many insightful comments to early versions of=20 > this draft, > > and contributed the basis of Figure 1. > >=20 > >=20 > > 7. Security Considerations > >=20 > > This document itself introduces no new security considerations. > > However, it is important to note that VoIP interconnect=20 > has a wide > > variety of security issues that should be considered in documents > > addressing both protocol and use case analyzes. > >=20 > >=20 > > 8. IANA Considerations > >=20 > > This document creates no new requirements on IANA namespaces > > [RFC2434]. > >=20 > >=20 > > 9. References > >=20 > > 9.1. Normative References > >=20 > > [RFC3404] Mealling, M., "Dynamic Delegation Discovery System=20 > > (DDDS) > > Part Four: The Uniform Resource Identifiers (URI)", > > RFC 3404, October 2002. > >=20 > > [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform > > Resource Identifiers (URI) Dynamic Delegation=20 > Discovery > > System (DDDS) Application (ENUM)", RFC 3761,=20 > April 2004. > >=20 > > [ITU.E164.1991] > > International Telecommunications Union, "The=20 > > International > > Public Telecommunication Numbering Plan", ITU- > > T Recommendation E.164, 1991. > >=20 > > [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", > > RFC 3966, December 2004. > >=20 > > 9.2. Informative References > >=20 > > [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 > > (BGP-4)", RFC 1771, March 1995. > >=20 > > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for=20 > Writing an > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 8] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > IANA Considerations Section in RFCs", BCP 26,=20 > RFC 2434, > > October 1998. > >=20 > > [RFC2826] Internet Architecture Board, "IAB Technical=20 > Comment on=20 > > the > > Unique DNS Root", RFC 2826, May 2000. > >=20 > > [I-D.lind-infrastructure-enum-reqs] > > Lind, S., "Infrastructure ENUM Requirements", > > draft-lind-infrastructure-enum-reqs-00 (work in=20 > > progress), > > July 2005. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 9] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > Author's Address > >=20 > > David Meyer > >=20 > > Email: dmm@1-4-5.net > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 10] > >=20 > >=20 > > Internet-Draft Terminology for Describing VoIP Peering =20 > > October 2005 > >=20 > >=20 > > Intellectual Property Statement > >=20 > > The IETF takes no position regarding the validity or scope of any > > Intellectual Property Rights or other rights that might=20 > be claimed=20 > > to > > pertain to the implementation or use of the technology=20 > described in > > this document or the extent to which any license under=20 > such rights > > might or might not be available; nor does it represent=20 > that it has > > made any independent effort to identify any such rights. =20 > > Information > > on the procedures with respect to rights in RFC documents can be > > found in BCP 78 and BCP 79. > >=20 > > Copies of IPR disclosures made to the IETF Secretariat and any > > assurances of licenses to be made available, or the result of an > > attempt made to obtain a general license or permission=20 > for the use=20 > > of > > such proprietary rights by implementers or users of this > > specification can be obtained from the IETF on-line IPR=20 > repository=20 > > at > > http://www.ietf.org/ipr. > >=20 > > The IETF invites any interested party to bring to its=20 > attention any > > copyrights, patents or patent applications, or other proprietary > > rights that may cover technology that may be required to=20 > implement > > this standard. Please address the information to the IETF at > > ietf-ipr@ietf.org. > >=20 > >=20 > > Disclaimer of Validity > >=20 > > This document and the information contained herein are=20 > provided on=20 > > an > > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE=20 > > REPRESENTS > > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND=20 > THE INTERNET > > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=20 > OR IMPLIED, > > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A=20 > PARTICULAR PURPOSE. > >=20 > >=20 > > Copyright Statement > >=20 > > Copyright (C) The Internet Society (2005). This document is=20 > > subject > > to the rights, licenses and restrictions contained in BCP 78, and > > except as set forth therein, the authors retain all their rights. > >=20 > >=20 > > Acknowledgment > >=20 > > Funding for the RFC Editor function is currently provided by the > > Internet Society. > >=20 > >=20 > >=20 > >=20 > > Meyer Expires April 24, 2006 =20 > > [Page 11] > >=20 > >=20 > >=20 >=20 > ______________________________________________________________ > ______________ > _ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 21 15:31:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2cD-0001Eq-UK; Fri, 21 Oct 2005 15:31:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2cC-0001Ee-Hp for enum@megatron.ietf.org; Fri, 21 Oct 2005 15:31:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28385 for ; Fri, 21 Oct 2005 15:31:33 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ET2oO-0003VK-1M for enum@ietf.org; Fri, 21 Oct 2005 15:44:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Date: Fri, 21 Oct 2005 21:35:19 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C461B@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXWUrED2MtA7e4tT0aJ5p50zQ1crQAEXG5AAAJanXQAAU5aMAAAt5aa From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "David Meyer" , "Pfautz, Penn L, NEO" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is exactly the discussion I wanted to avoid in voipeer =20 voippeer is dealing with peering between VoIP Service providers, regardless if they are carriers, carriers of record, PATS, ECS or (unregulated) Infromation Service Providers. =20 So I originally proposed NOT to define carrier within voipeer =20 enum is within the discussion of carrier ENUM dealing with entities entitles to be domain name holders for E.164 numbers in the carrier ENUM tree. Here we have the definition in =20 =20 ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Fr 21.10.2005 21:09 An: Stastny Richard; David Meyer; Pfautz, Penn L, NEO Cc: enum@ietf.org; voipeer@lists.uoregon.edu Betreff: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Is the issue that you want to define an entity that may or may not be regulated, but could still be a carrier? Maybe an example would help point out the case that is problematic. Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, October 21, 2005 2:37 PM > To: Michael Hammer (mhammer); David Meyer; Pfautz, Penn L, NEO > Cc: enum@ietf.org; voipeer@lists.uoregon.edu > Subject: RE: [Enum] RE: [voipeer] > draft-meyer-voipeer-terminology-03.txt > > Mike, Dave, >=20 > >> A carrier is defined to be a service provider authorized > >> to provision PSTN > > >The term PSTN is often used to mean the TDM networks > offering publicly > >available telephony services. In order to get away from the TDM > >aspects, which some day might go away, how about: > > >a service provider authorized to offer telephony services to > the public. > > >That should cover both cases and gets away from unintended > baggage. I > >am assuming that the enterprises are not considered > pseudo-carriers and > i>ntended to be covered here. > > I have no solution to offer at the moment, but I have a > problem with the term public available telephony service > (PATS). This term has a special meaning in Europe and is a > subset of the term electronic communication service (ECS), > both defined in the framework and under heavy discussion in > the context of VoIP. >=20 > Richard > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 21 15:35:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2fr-0004hb-Fw; Fri, 21 Oct 2005 15:35:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2fp-0004f2-R9 for enum@megatron.ietf.org; Fri, 21 Oct 2005 15:35:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28677 for ; Fri, 21 Oct 2005 15:35:19 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ET2s2-0003hW-DC for enum@ietf.org; Fri, 21 Oct 2005 15:48:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Date: Fri, 21 Oct 2005 21:35:55 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C461C@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXWUrED2MtA7e4tT0aJ5p50zQ1crQAEXG5AAAJanXQAAU5aMAAAt5aaAABAouE= From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "David Meyer" , "Pfautz, Penn L, NEO" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Sorry hit the send button too early =20 This is exactly the discussion I wanted to avoid in voipeer =20 voippeer is dealing with peering between VoIP Service providers, regardless if they are carriers, carriers of record, PATS, ECS or (unregulated) Infromation Service Providers. =20 So I originally proposed NOT to define carrier within voipeer. =20 In WG enum is within the discussion of carrier ENUM dealing with entities entitled to be domain name holders for E.164 numbers in the carrier ENUM tree. Here we have the definition in draft-lind-infrastructure-enum-reqs-01: =20 For purposes of this document, "Carrier of Record" refers to the entity that provides PSTN service for an E.164 number with the understanding that this definition is ultimately a matter for national authorities to determine. =20 Richard =20 ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Fr 21.10.2005 21:09 An: Stastny Richard; David Meyer; Pfautz, Penn L, NEO Cc: enum@ietf.org; voipeer@lists.uoregon.edu Betreff: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Is the issue that you want to define an entity that may or may not be regulated, but could still be a carrier? Maybe an example would help point out the case that is problematic. Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, October 21, 2005 2:37 PM > To: Michael Hammer (mhammer); David Meyer; Pfautz, Penn L, NEO > Cc: enum@ietf.org; voipeer@lists.uoregon.edu > Subject: RE: [Enum] RE: [voipeer] > draft-meyer-voipeer-terminology-03.txt > > Mike, Dave, >=20 > >> A carrier is defined to be a service provider authorized > >> to provision PSTN > > >The term PSTN is often used to mean the TDM networks > offering publicly > >available telephony services. In order to get away from the TDM > >aspects, which some day might go away, how about: > > >a service provider authorized to offer telephony services to > the public. > > >That should cover both cases and gets away from unintended > baggage. I > >am assuming that the enterprises are not considered > pseudo-carriers and > i>ntended to be covered here. > > I have no solution to offer at the moment, but I have a > problem with the term public available telephony service > (PATS). This term has a special meaning in Europe and is a > subset of the term electronic communication service (ECS), > both defined in the framework and under heavy discussion in > the context of VoIP. >=20 > Richard > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 21 16:06:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET39M-0004ii-9z; Fri, 21 Oct 2005 16:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET39K-0004i3-JA for enum@megatron.ietf.org; Fri, 21 Oct 2005 16:05:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06289 for ; Fri, 21 Oct 2005 16:05:47 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET3LS-00070x-Hg for enum@ietf.org; Fri, 21 Oct 2005 16:18:32 -0400 Received: from [10.31.32.123] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9LK6MwD028015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Oct 2005 13:06:23 -0700 Message-ID: <43594A11.4010807@shockey.us> Date: Fri, 21 Oct 2005 16:05:37 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: multipart/mixed; boundary="------------040409000300040000030600" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Subject: [Enum] [Fwd: I-D ACTION:draft-lind-infrastructure-enum-reqs-01.txt] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------040409000300040000030600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-lind-infrastructure-enum-reqs-01.txt Date: Fri, 21 Oct 2005 15:50:01 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Carrier/Infrastrucure ENUM Requirements Author(s) : S. Lind, et al. Filename : draft-lind-infrastructure-enum-reqs-01.txt Pages : 7 Date : 2005-10-21 This document provides requirements for "infrastructure" or "carrier" ENUM, defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoI A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lind-infrastructure-enum-reqs-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lind-infrastructure-enum-reqs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lind-infrastructure-enum-reqs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --------------040409000300040000030600 Content-Type: Message/External-body; name="draft-lind-infrastructure-enum-reqs-01.txt" Content-Disposition: inline; filename="draft-lind-infrastructure-enum-reqs-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-10-21134541.I-D@ietf.org> --------------040409000300040000030600 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------040409000300040000030600 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------040409000300040000030600-- From enum-bounces@ietf.org Fri Oct 21 16:36:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET3dD-0004WI-QL; Fri, 21 Oct 2005 16:36:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET3dB-0004Ug-B2 for enum@megatron.ietf.org; Fri, 21 Oct 2005 16:36:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23982 for ; Fri, 21 Oct 2005 16:36:37 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET3pL-0005Sx-3X for enum@ietf.org; Fri, 21 Oct 2005 16:49:26 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9LKaZnP003251; Fri, 21 Oct 2005 13:36:35 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9LKaVkf003250; Fri, 21 Oct 2005 13:36:31 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 21 Oct 2005 13:36:31 -0700 From: David Meyer To: Henry Sinnreich Message-ID: <20051021203631.GA3188@1-4-5.net> References: <072C5B76F7CEAB488172C6F64B30B5E3AE6892@xmb-rtp-20b.amer.cisco.com> <200510211949.j9LJnd0N002468@m106.maoz.com> Mime-Version: 1.0 In-Reply-To: <200510211949.j9LJnd0N002468@m106.maoz.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: enum@ietf.org, voipeer@lists.uoregon.edu, "'Pfautz, Penn L, NEO'" , "'Michael Hammer \(mhammer\)'" Subject: [Enum] Re: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0437049575==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0437049575== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 21, 2005 at 02:49:36PM -0500, Henry Sinnreich wrote: > > There are no carriers in Skype, correct? >=20 > Skype is reselling E.164 phone numbers in an increasing number of countri= es. >=20 > It makes sense therefore to _test the definitions_ here on the Skype case > and there are other VoIP and IM services in similar situation. Some are > really far too big to be overlooked. >=20 > Unless the definition is refined in terms of facilities based and non > facilities based. But there are VMNO's in the wireless world... >=20 > Hint: The carrier definition is hopeless. "The Internet Is The Service" (= Jon > Peterson) and voice is an application IMHO. Let's go back to the layers in > the I-D. Yep. There's no real value add in defining carrier IMO. Best solution: remove the definition of carrier.=20 Dave --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDWVFPORgD1qCZ2KcRAh1dAKCVBUSx5CXCiLDfXPI6LS83AH8o3ACdELyc guMzlLN0LJBWslEhxKSJOFg= =Ucu7 -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- --===============0437049575== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0437049575==-- From enum-bounces@ietf.org Fri Oct 21 17:56:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET4s9-0005pu-11; Fri, 21 Oct 2005 17:56:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET4s7-0005lo-Qg for enum@megatron.ietf.org; Fri, 21 Oct 2005 17:56:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20602 for ; Fri, 21 Oct 2005 17:56:08 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET54K-0007rj-NC for enum@ietf.org; Fri, 21 Oct 2005 18:08:58 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 21 Oct 2005 14:56:10 -0700 X-IronPort-AV: i="3.97,240,1125903600"; d="scan'208"; a="668322829:sNHT26859128" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9LLtu9C000436; Fri, 21 Oct 2005 14:56:07 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 17:55:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Date: Fri, 21 Oct 2005 17:55:47 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3AE68FA@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXWUrED2MtA7e4tT0aJ5p50zQ1crQAEXG5AAAJanXQAAU5aMAAAt5aaAABAouEABNdUIA== From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "David Meyer" , "Pfautz, Penn L, NEO" X-OriginalArrivalTime: 21 Oct 2005 21:55:48.0986 (UTC) FILETIME=[326E7DA0:01C5D68A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Can you still change "PSTN service" to "public telephone service" ? I still want to avoid the TDM implication. Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Friday, October 21, 2005 3:36 PM > To: Michael Hammer (mhammer); David Meyer; Pfautz, Penn L, NEO > Cc: enum@ietf.org; voipeer@lists.uoregon.edu > Subject: Re: [Enum] RE: [voipeer]=20 > draft-meyer-voipeer-terminology-03.txt >=20 > Sorry hit the send button too early >=20 > =20 > This is exactly the discussion I wanted to avoid in voipeer > =20 > voippeer is dealing with peering between VoIP Service=20 > providers, regardless if they are carriers, carriers of=20 > record, PATS, ECS or > (unregulated) Infromation Service Providers. > =20 > So I originally proposed NOT to define carrier within voipeer. > =20 > In WG enum is within the discussion of carrier ENUM dealing=20 > with entities entitled to be domain name holders for E.164=20 > numbers in the carrier ENUM tree. Here we have the definition in > draft-lind-infrastructure-enum-reqs-01: > =20 > For purposes of this document, "Carrier of Record" refers to the > entity that provides PSTN service for an E.164 number with the > understanding that this definition is ultimately a matter for > national authorities to determine. > =20 > Richard > =20 >=20 > ________________________________ >=20 > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Gesendet: Fr 21.10.2005 21:09 > An: Stastny Richard; David Meyer; Pfautz, Penn L, NEO > Cc: enum@ietf.org; voipeer@lists.uoregon.edu > Betreff: RE: [Enum] RE: [voipeer]=20 > draft-meyer-voipeer-terminology-03.txt >=20 >=20 >=20 > Is the issue that you want to define an entity that may or=20 > may not be regulated, but could still be a carrier? >=20 > Maybe an example would help point out the case that is problematic. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Friday, October 21, 2005 2:37 PM > > To: Michael Hammer (mhammer); David Meyer; Pfautz, Penn L, NEO > > Cc: enum@ietf.org; voipeer@lists.uoregon.edu > > Subject: RE: [Enum] RE: [voipeer] > > draft-meyer-voipeer-terminology-03.txt > > > > Mike, Dave, > >=20 > > >> A carrier is defined to be a service provider authorized > > >> to provision PSTN > > > > >The term PSTN is often used to mean the TDM networks > > offering publicly > > >available telephony services. In order to get away from the TDM=20 > > >aspects, which some day might go away, how about: > > > > >a service provider authorized to offer telephony services to > > the public. > > > > >That should cover both cases and gets away from unintended > > baggage. I > > >am assuming that the enterprises are not considered > > pseudo-carriers and > > i>ntended to be covered here. > > > > I have no solution to offer at the moment, but I have a=20 > problem with=20 > > the term public available telephony service (PATS). This term has a=20 > > special meaning in Europe and is a subset of the term electronic=20 > > communication service (ECS), both defined in the framework=20 > and under=20 > > heavy discussion in the context of VoIP. > >=20 > > Richard > > >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 21 21:45:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET8SD-0001gG-RR; Fri, 21 Oct 2005 21:45:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET8SC-0001gB-H6 for enum@megatron.ietf.org; Fri, 21 Oct 2005 21:45:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11189 for ; Fri, 21 Oct 2005 21:45:37 -0400 (EDT) Received: from bay103-f20.bay103.hotmail.com ([65.54.174.30] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET8eR-0001uf-L9 for enum@ietf.org; Fri, 21 Oct 2005 21:58:28 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 21 Oct 2005 18:45:37 -0700 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Sat, 22 Oct 2005 01:45:37 GMT X-Originating-IP: [69.109.8.125] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3AE68FA@xmb-rtp-20b.amer.cisco.com> From: "Peter Williams" Cc: enum@ietf.org Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Date: Fri, 21 Oct 2005 18:45:37 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Oct 2005 01:45:37.0677 (UTC) FILETIME=[4D21C3D0:01C5D6AA] X-Spam-Score: 0.9 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org ENUM was (and may still be) about convergence of two communities - PSTN and INTERNET. Much of the WG capital likes in the trust between these two communities, and their business practices in particular. As IP never had the slighest problem converging with the PSDN (e.g. TCP over MILNETs old DOD X.25 variant) and IP over B-ISDN, its hard to see why ENUM should stuggle to converge with the PSTN - and its various generations of technology. Lets remember, that we are here to define a convergence strategy, not to implement internet style telephony or voice conferencing (we did all that 10 years ago, over dartnet, etc!) Of course, in rechartering ENUM, we could always opt to dump the PSTN Convergence mission. We may want to consult IAB here, given they liase on IETF's behalf with ISO, on such policy and liason matters. >From: "Michael Hammer (mhammer)" >To: "Stastny Richard" ,"David Meyer" >, "Pfautz, Penn L, NEO" >CC: enum@ietf.org, voipeer@lists.uoregon.edu >Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt >Date: Fri, 21 Oct 2005 17:55:47 -0400 > >Can you still change "PSTN service" to "public telephone service" ? > >I still want to avoid the TDM implication. > >Mike > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Friday, October 21, 2005 3:36 PM > > To: Michael Hammer (mhammer); David Meyer; Pfautz, Penn L, NEO > > Cc: enum@ietf.org; voipeer@lists.uoregon.edu > > Subject: Re: [Enum] RE: [voipeer] > > draft-meyer-voipeer-terminology-03.txt > > > > Sorry hit the send button too early > > > > > > This is exactly the discussion I wanted to avoid in voipeer > > > > voippeer is dealing with peering between VoIP Service > > providers, regardless if they are carriers, carriers of > > record, PATS, ECS or > > (unregulated) Infromation Service Providers. > > > > So I originally proposed NOT to define carrier within voipeer. > > > > In WG enum is within the discussion of carrier ENUM dealing > > with entities entitled to be domain name holders for E.164 > > numbers in the carrier ENUM tree. Here we have the definition in > > draft-lind-infrastructure-enum-reqs-01: > > > > For purposes of this document, "Carrier of Record" refers to the > > entity that provides PSTN service for an E.164 number with the > > understanding that this definition is ultimately a matter for > > national authorities to determine. > > > > Richard > > > > > > ________________________________ > > > > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Gesendet: Fr 21.10.2005 21:09 > > An: Stastny Richard; David Meyer; Pfautz, Penn L, NEO > > Cc: enum@ietf.org; voipeer@lists.uoregon.edu > > Betreff: RE: [Enum] RE: [voipeer] > > draft-meyer-voipeer-terminology-03.txt > > > > > > > > Is the issue that you want to define an entity that may or > > may not be regulated, but could still be a carrier? > > > > Maybe an example would help point out the case that is problematic. > > > > Mike > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Friday, October 21, 2005 2:37 PM > > > To: Michael Hammer (mhammer); David Meyer; Pfautz, Penn L, NEO > > > Cc: enum@ietf.org; voipeer@lists.uoregon.edu > > > Subject: RE: [Enum] RE: [voipeer] > > > draft-meyer-voipeer-terminology-03.txt > > > > > > Mike, Dave, > > > > > > >> A carrier is defined to be a service provider authorized > > > >> to provision PSTN > > > > > > >The term PSTN is often used to mean the TDM networks > > > offering publicly > > > >available telephony services. In order to get away from the TDM > > > >aspects, which some day might go away, how about: > > > > > > >a service provider authorized to offer telephony services to > > > the public. > > > > > > >That should cover both cases and gets away from unintended > > > baggage. I > > > >am assuming that the enterprises are not considered > > > pseudo-carriers and > > > i>ntended to be covered here. > > > > > > I have no solution to offer at the moment, but I have a > > problem with > > > the term public available telephony service (PATS). This term has a > > > special meaning in Europe and is a subset of the term electronic > > > communication service (ECS), both defined in the framework > > and under > > > heavy discussion in the context of VoIP. > > > > > > Richard > > > > > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Oct 22 11:46:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETLa2-0002rC-MV; Sat, 22 Oct 2005 11:46:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETLa0-0002r2-SJ for enum@megatron.ietf.org; Sat, 22 Oct 2005 11:46:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17225 for ; Sat, 22 Oct 2005 11:46:33 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETLmO-0003RG-4f for enum@ietf.org; Sat, 22 Oct 2005 11:59:32 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9MFlEQV023614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 22 Oct 2005 08:47:16 -0700 Message-ID: <435A5ED5.8070100@shockey.us> Date: Sat, 22 Oct 2005 11:46:29 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Subject: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org -------- Original Message -------- Subject: I-D ACTION:draft-sajitha-enum-api-00.txt Date: Fri, 21 Oct 2005 15:50:01 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An ENUM Library API Author(s) : T. Sajitha Filename : draft-sajitha-enum-api-00.txt Pages : 7 Date : 2005-10-21 This draft defines a library API for ENUM. The API takes telephone number as input and returns the URI associated with that telephone number. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sajitha-enum-api-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-sajitha-enum-api-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-sajitha-enum-api-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Oct 22 11:48:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETLbn-0004DA-BI; Sat, 22 Oct 2005 11:48:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETLbl-0004Cz-G8 for enum@megatron.ietf.org; Sat, 22 Oct 2005 11:48:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17279 for ; Sat, 22 Oct 2005 11:48:21 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETLo8-0003VS-PE for enum@ietf.org; Sat, 22 Oct 2005 12:01:21 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9MFmvxt023717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 22 Oct 2005 08:49:00 -0700 Message-ID: <435A5F3D.6010407@shockey.us> Date: Sat, 22 Oct 2005 11:48:13 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: multipart/mixed; boundary="------------090304070200030603050803" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Subject: [Enum] [Fwd: I-D ACTION:draft-haberler-carrier-enum-01.txt] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------090304070200030603050803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-haberler-carrier-enum-01.txt Date: Fri, 21 Oct 2005 15:50:02 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Combined User and Carrier ENUM in the e164.arpa tree Author(s) : M. Haberler, R. Stastny Filename : draft-haberler-carrier-enum-01.txt Pages : 15 Date : 2005-10-21 ENUM as defined now in RFC3761 [1] is not well suited for the purpose of interconnection by carriers, as can be seen by the use of various private tree arrangements based on ENUM mechanisms. A combined end- user and carrier ENUM tree solution would leverage the ENUM infrastructure in e164.arpa, increase resolution rates, and decrease the cost per registered telephone number. This document describes a minimally invasive scheme to provide both end-user and carrier data in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-haberler-carrier-enum-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-haberler-carrier-enum-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --------------090304070200030603050803 Content-Type: Message/External-body; name="draft-haberler-carrier-enum-01.txt" Content-Disposition: inline; filename="draft-haberler-carrier-enum-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-10-21145430.I-D@ietf.org> --------------090304070200030603050803 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------090304070200030603050803 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------090304070200030603050803-- From enum-bounces@ietf.org Sat Oct 22 12:43:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETMSe-0006Jz-NT; Sat, 22 Oct 2005 12:43:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET18f-0008QX-Ag for enum@megatron.ietf.org; Fri, 21 Oct 2005 13:57:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21754 for ; Fri, 21 Oct 2005 13:56:59 -0400 (EDT) Message-Id: <200510211756.NAA21754@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET1Kq-0007wG-GP for enum@ietf.org; Fri, 21 Oct 2005 14:09:45 -0400 Received: (qmail 2698 invoked by uid 510); 21 Oct 2005 14:11:03 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.136.53):. Processed in 2.12456 secs); 21 Oct 2005 18:11:03 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.136.53):. Processed in 2.12456 secs Process 2685) Received: from c-24-1-136-53.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.136.53) by 192.246.69.184 with SMTP; Fri, 21 Oct 2005 18:11:01 +0000 From: "Henry Sinnreich" To: "'Michael Hammer \(mhammer\)'" , "'David Meyer'" , "'Pfautz, Penn L, NEO'" Date: Fri, 21 Oct 2005 12:56:55 -0500 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3AE681F@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXWUrED2MtA7e4tT0aJ5p50zQ1crQAEXG5AAAEYuFA= X-Antivirus-MYDOMAIN-Message-ID: <11299182618352685@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 6a5c486139a804859f37cd11eb5255b5 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 22 Oct 2005 12:42:46 -0400 Cc: enum@ietf.org, voipeer@lists.uoregon.edu Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > a service provider authorized to offer telephony services to the public. Does this include Skype? It's the biggest anyway. :-) Thanks, Henry -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Hammer (mhammer) Sent: Friday, October 21, 2005 12:30 PM To: David Meyer; Pfautz, Penn L, NEO Cc: voipeer@lists.uoregon.edu; enum@ietf.org Subject: RE: [voipeer] draft-meyer-voipeer-terminology-03.txt David, A slight modification suggestion below. > -----Original Message----- > From: owner-voipeer@lists.uoregon.edu > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of David Meyer > Sent: Friday, October 21, 2005 11:12 AM > To: Pfautz, Penn L, NEO > Cc: voipeer@lists.uoregon.edu; enum@ietf.org > Subject: Re: [voipeer] draft-meyer-voipeer-terminology-03.txt > > On Fri, Oct 21, 2005 at 09:51:17AM -0400, Pfautz, Penn L, NEO wrote: > > Dave: > > This is a nice start (indeed more than a start). I just have two > > comments at this point: > > > > 1. The definition of carrier in 3.6 is probably too restrictive. I > > would not make it contingent on issuance of E.164 numbers > but rather > > just the provision of PSTN service. I appreciate your use our > > carrier-of-record definition in 4.1. > > > How about: > > 3.6. Carrier > > A carrier is defined to be a service provider authorized > to provision PSTN The term PSTN is often used to mean the TDM networks offering publicly available telephony services. In order to get away from the TDM aspects, which some day might go away, how about: a service provider authorized to offer telephony services to the public. That should cover both cases and gets away from unintended baggage. I am assuming that the enterprises are not considered pseudo-carriers and intended to be covered here. Mike > services. Note that the provision of such services is usually > coupled with the authority to issue E.164 numbers [ITU.E164.1991] > under the authority of a National Regulatory Authority (NRA). > > > > 2. In reference to Layer 3 Peering (Section 3.7.1) I would > like to see > > included the concepts that a) peering involves delivery of packets > > that terminate on the peer's network and b) peering is done without > > traffic settlement charges. > > I'm ok with a) termination of traffic, but I'd like to > avoid discussing SFI more than I have (see section > 3.7). So how about: > > 3.7.1. Layer 3 Peering > > Layer 3 peering refers to interconnection of two service providers > for the purposes of exchanging IP packets which destined > for one (or > both) of the peer's networks. Layer 3 peering is > generally agnostic > to the IP payload, and is frequently achieved using a routing > protocol such as BGP [RFC1771] to exchange the required routing > information. > > An alternate, perhaps more operational definition of layer > 3 peering > is that two peers exchange their customer routers (only), and hence > any traffic between peers terminates on on the peer's network. > > > Dave > > --- > > > > > Network Working Group > D. Meyer > Internet-Draft > October 21, 2005 > Expires: April 24, 2006 > > > Terminology for Describing VoIP Peering and Interconnect > draft-meyer-voipeer-terminology-04.txt > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of > six months > and may be updated, replaced, or obsoleted by other > documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on April 24, 2006. > > Copyright Notice > > Copyright (C) The Internet Society (2005). > > Abstract > > This document defines the terminology that is to be used > by the Voice > Over IP Peering and Interconnect Working Group (voipeer), > and has as > its primary objective to focus the VOIPEER Working Group during its > discussions, and when writing requirements, gap analysis and other > solutions oriented documents. > > > > > > > > Meyer Expires April 24, 2006 > [Page 1] > > > Internet-Draft Terminology for Describing VoIP Peering > October 2005 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . > . . . . 3 > 2. Context . . . . . . . . . . . . . . . . . . . . . . . > . . . . 3 > 3. General Definitions . . . . . . . . . . . . . . . . . > . . . . 4 > 3.1. Call Routing Data . . . . . . . . . . . . . . . . > . . . . 4 > 3.2. Call Routing . . . . . . . . . . . . . . . . . . . > . . . . 4 > 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . . > . . . . 5 > 3.4. Network . . . . . . . . . . . . . . . . . . . . . > . . . . 5 > 3.5. VoIP Service Provider . . . . . . . . . . . . . . > . . . . 5 > 3.6. Carrier . . . . . . . . . . . . . . . . . . . . . > . . . . 5 > 3.7. Peering . . . . . . . . . . . . . . . . . . . . . > . . . . 5 > 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . . > . . . . 6 > 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . . > . . . . 6 > 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . . > . . . . 6 > 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . > . . . . 6 > 4.1. Carrier of Record . . . . . . . . . . . . . . . . > . . . . 6 > 4.2. Public ENUM . . . . . . . . . . . . . . . . . . . > . . . . 6 > 4.3. Private ENUM . . . . . . . . . . . . . . . . . . . > . . . . 7 > 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . . > . . . . 7 > 5. Conclusions . . . . . . . . . . . . . . . . . . . . . > . . . . 7 > 6. Acknowledgments . . . . . . . . . . . . . . . . . . . > . . . . 7 > 7. Security Considerations . . . . . . . . . . . . . . . > . . . . 8 > 8. IANA Considerations . . . . . . . . . . . . . . . . . > . . . . 8 > 9. References . . . . . . . . . . . . . . . . . . . . . . > . . . . 8 > 9.1. Normative References . . . . . . . . . . . . . . . > . . . . 8 > 9.2. Informative References . . . . . . . . . . . . . . > . . . . 8 > Author's Address . . . . . . . . . . . . . . . . . . . . . > . . . . 10 > Intellectual Property and Copyright Statements . . . . . . > . . . . 11 > > > > > > > > > > > > > > > > > > > > > > > Meyer Expires April 24, 2006 > [Page 2] > > > Internet-Draft Terminology for Describing VoIP Peering > October 2005 > > > 1. Introduction > > The term "VoIP Peering" has historically been used to > describe a wide > variety of aspects pertaining to the interconnection of service > provider networks and to the delivery of SIP call termination over > those interconnections. The discussion of these > interconnections has > at times been confused by the fact that the term "peering" > is used in > various contexts to relate to interconnection at different > levels in > a protocol stack. VoIP peering focuses on how to identify > and route > calls at the application layer, and it does not > (necessarily) involve > the exchange of packet routing data or media sessions. In > particular, "layer 5 network" is used here to refer to the > interconnection between SIP servers, as opposed to > interconnection at > the IP layer ("layer 3"). Finally, the terms "peering" and > "interconnect" are used interchangeably throughout this document. > > This document introduces standard terminology for use in > characterizing VoIP interconnection. Note however, that while this > document is primarily targeted at the VoIP interconnect case, the > terminology described here is applicable to those cases in which > service providers interconnect using SIP signaling for real-time or > quasi-real-time communications. > > The remainder of this document is organized as follows: Section 2 > provides the general context for the VOIPEER Working Group, and > Section 3 provides the general definitions for real-time SIP based > communication, with focus on the VoIP interconnect case. Section 4 > briefly touches on terms from the ENUM Working Group. Finally, > Section 5 provides comments on usage. > > > 2. Context > > Figure 1 depicts the general VoIP interconnect context. In this > case, the caller uses an E.164 number [ITU.E164.1991] as the "name" > of the called user. Note that this E.164 number is not an address, > since at this point we do not have information about where > the named > endpoint is located. In the case shown here, an E.164 > number is used > as a key to retrieve a NAPTR recored [RFC3404] from the > DNS, which in > turn resolved into a SIP URI. Call routing is based on > this SIP URI. > The call routing step does not depend on the presence of an E.164 > number; the SIP URI can be advertised in various other > ways, such as > on a web page. Finally, note that the subsequent lookup steps, > namely, lookup of SRV, A, and AAAA records (as well as any routing > steps below that) are outside the scope of VOIPEER. > > > > > > > Meyer Expires April 24, 2006 > [Page 3] > > > Internet-Draft Terminology for Describing VoIP Peering > October 2005 > > > E.164 number <--- Peer Discovery > | > | <--- ENUM lookup of NAPTR in DNS > | > | > | ENUM Working Group Scope > =====+======================================= > | VOIPEER Working Group Scope > | > | > SIP URI <--- Call Routing Data (CRD) > | > | <--- Service Location (Lookup of SRV in DNS) > | > | > Hostname <--- VoIP addressing and session establishment > | > | <---- Lookup of A and AAAA in DNS > | > Ip address > | > | <---- Routing protocols, ARP etc > | > Mac-address > > Figure 1: VoIP Interconnect Context > > The ENUM Working Group is primarily concerned with the > acquisition of > Call Routing Data, or CRD (i.e., above the double line in > Figure 1), > while the VOIPEER Working Group is focused on the use of such CRD. > Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS > entry), or via any other mechanism available to the user. > > > 3. General Definitions > > 3.1. Call Routing Data > > Call Routing Data, or CRD, is a SIP URI used to route a call (real- > time, voice or other type) to the called domain's ingress point. A > domain's ingress point can be thought of as the location pointed to > by the SRV record that resulted from the resolution of the > CRD (i.e., > a SIP URI). > > 3.2. Call Routing > > Call routing is the set of processes, rules, and CRD used > to route a > VoIP call to its proper (SIP) destination. More generally, call > > > > Meyer Expires April 24, 2006 > [Page 4] > > > Internet-Draft Terminology for Describing VoIP Peering > October 2005 > > > routing can be thought of as the set of processes, rules and CRD > which are used to route a real-time session to its termination > (ingress) point. > > 3.3. PSTN > > The term "PSTN" refers to the Public Switched Telephone > Network. In > particular, the PSTN refers to the collection of interconnected > circuit-switched voice-oriented public telephone networks, both > commercial and government-owned. In general, PSTN terminals are > addressed using E.164 numbers, noting that various dial-plans (such > as emergency services dial-plans) may not directly use > E.164 numbers. > > 3.4. Network > > For purposes of this document and the VOIPEER and ENUM Working > Groups, a network is defined to be the set of SIP servers and end- > users (customers) that are controlled by a single administrative > domain. The network may also contain end-users who are located on > the PSTN. > > 3.5. VoIP Service Provider > > A VoIP service provider is an entity that provides transport of SIP > signaling (and possibly media streams) to its customers. Such a > service provider may additionally be interconnected with other > service providers; that is, it may "peer" with other service > providers. A VoIP service provider may also interconnect with the > PSTN. > > Note that as soon as a ingress point is advertised via a > SRV record, > anyone can find that ingress point and hence can send calls there. > This is very similar to sending mail to a SMTP server based on the > existence of a MX record. > > 3.6. Carrier > > A carrier is defined to be a service provider authorized > to provision > PSTN services. Note that the provision of such services is usually > coupled with the authority to issue E.164 numbers [ITU.E164.1991] > under the authority of a National Regulatory Authority (NRA). > > 3.7. Peering > > While the precise definition of the term "peering" is the > subject of > some debate, peering in general refers to the negotiation of > reciprocal interconnection arrangements, settlement-free or > otherwise, between operationally independent service providers. > > > > Meyer Expires April 24, 2006 > [Page 5] > > > Internet-Draft Terminology for Describing VoIP Peering > October 2005 > > > This document distinguishes two types of peering, Layer 3 > Peering and > Layer 5 peering, which are described below. > > 3.7.1. Layer 3 Peering > > Layer 3 peering refers to interconnection of two service providers > for the purposes of exchanging IP packets which destined > for one (or > both) of the peer's networks. Layer 3 peering is > generally agnostic > to the IP payload, and is frequently achieved using a routing > protocol such as BGP [RFC1771] to exchange the required routing > information. > > An alternate, perhaps more operational definition of layer > 3 peering > is that two peers exchange their customer routers (only), and hence > any traffic between peers terminates on on the peer's network. > > 3.7.2. Layer 5 Peering > > Layer 5 peering refers to interconnection of two service providers > for the purposes of SIP signaling. Note that in the layer > 5 peering > case, there is no intervening network. That is, for > purposes of this > discussion, there is no such thing as a "Layer 5 Transit Network". > > 3.8. VoIP Peering > > VoIP peering is defined to be a layer 5 peering between two VoIP > providers for purposes of routing real-time (or quasi-real > time) call > signaling between their respective customers. Media streams > associated with this signaling (if any) are not > constrained to follow > the same set of paths. > > > 4. ENUM > > ENUM [RFC3761] defines how the Domain Name System (DNS) can be used > for identifying available services connected to one E.164 number. > > 4.1. Carrier of Record > > For purposes of this document, "Carrier of Record", or > COR, refers to > the entity that provides PSTN service for an E.164 number > [I-D.lind- > infrastructure-enum-reqs]. The exact definition of who > and what is a > COR is ultimately the responsibility of the relevant NRA. > > 4.2. Public ENUM > > Public ENUM is generally defined as the set administrative policies > and procedures surrounding the use of the e164.arpa domain for > > > > Meyer Expires April 24, 2006 > [Page 6] > > > Internet-Draft Terminology for Describing VoIP Peering > October 2005 > > > Telephone Number to URI resolution [RFC3761]. Policies and > procedures for the registration of telephone numbers within all > branches of the e164.arpa tree are Nation State issues by agreement > with the IAB and ITU. National Regulatory Authorities > have generally > defined Public ENUM Registrants as the E.164 number holder > as opposed > to the COR that issued the phone number. > > 4.3. Private ENUM > > Private ENUM is generally regarded as one or more technologies > (including DNS and SIP Redirect) that service providers or > enterprises may use to exchange phone number to URI mappings in a > private secure manner. Private ENUM may be used in any mutually > agreed upon domain. Records in Private ENUM may be > globally visible > but in most cases are not visible to the global Internet and are > protected using a variety of security technologies such as > split-DNS, > VPN's or various forms or authentication and authorization. > Technical comments on issues surrounding split-DNS can be found in > [RFC2826]. > > 4.4. Carrier ENUM > > Carrier ENUM is generally regarded as the use of a separate branch > the e164.arpa tree, such as 4.4.c.e164.arpa to permit service > providers to exchange phone number to URI data in order to find > points of interconnection. The current theory of Carrier ENUM is > that only the COR for a particular E.164 number is permitted to > provision data for that E.164 within that portion of the e164.arpa > tree. > > In carrier ENUM case, only the COR may enter data in the > corresponding domain. The COR may also enter CRD (i.e., a SIP URI) > to allow other VoIP Service Providers to route calls to > its network. > > Finally, note that ENUM is not constrained to carry only data (CDR) > as defined by VOIPEER. In particular, an an important > class of CRD, > the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are > most frequently used to interconnect with the PSTN > directly, and are > out of scope for VOIPEER. On the other hand, PSTN endpoints served > by a COR and reachable via CDR and networks as defined in > Section 3.1 > and Section 3.4 are in scope for VOIPEER. > > > 5. Conclusions > > > 6. Acknowledgments > > > > > Meyer Expires April 24, 2006 > [Page 7] > > > Internet-Draft Terminology for Describing VoIP Peering > October 2005 > > > Many of the definitions were gleaned from detailed > discussions on the > VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer, > Jean-Francois Mule, Richard Shocky, and Richard Stastny > made valuable > contributions to early revisions of this document. Patrik > Faltstrom > also made many insightful comments to early versions of this draft, > and contributed the basis of Figure 1. > > > 7. Security Considerations > > This document itself introduces no new security considerations. > However, it is important to note that VoIP interconnect has a wide > variety of security issues that should be considered in documents > addressing both protocol and use case analyzes. > > > 8. IANA Considerations > > This document creates no new requirements on IANA namespaces > [RFC2434]. > > > 9. References > > 9.1. Normative References > > [RFC3404] Mealling, M., "Dynamic Delegation Discovery > System (DDDS) > Part Four: The Uniform Resource Identifiers (URI)", > RFC 3404, October 2002. > > [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform > Resource Identifiers (URI) Dynamic Delegation Discovery > System (DDDS) Application (ENUM)", RFC 3761, April 2004. > > [ITU.E164.1991] > International Telecommunications Union, "The > International > Public Telecommunication Numbering Plan", ITU- > T Recommendation E.164, 1991. > > [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", > RFC 3966, December 2004. > > 9.2. Informative References > > [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 > (BGP-4)", RFC 1771, March 1995. > > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an > > > > Meyer Expires April 24, 2006 > [Page 8] > > > Internet-Draft Terminology for Describing VoIP Peering > October 2005 > > > IANA Considerations Section in RFCs", BCP 26, RFC 2434, > October 1998. > > [RFC2826] Internet Architecture Board, "IAB Technical > Comment on the > Unique DNS Root", RFC 2826, May 2000. > > [I-D.lind-infrastructure-enum-reqs] > Lind, S., "Infrastructure ENUM Requirements", > draft-lind-infrastructure-enum-reqs-00 (work in > progress), > July 2005. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Meyer Expires April 24, 2006 > [Page 9] > > > Internet-Draft Terminology for Describing VoIP Peering > October 2005 > > > Author's Address > > David Meyer > > Email: dmm@1-4-5.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Meyer Expires April 24, 2006 > [Page 10] > > > Internet-Draft Terminology for Describing VoIP Peering > October 2005 > > > Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be > claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. > Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for > the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR > repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > Disclaimer of Validity > > This document and the information contained herein are > provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Copyright Statement > > Copyright (C) The Internet Society (2005). This document > is subject > to the rights, licenses and restrictions contained in BCP 78, and > except as set forth therein, the authors retain all their rights. > > > Acknowledgment > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > > > Meyer Expires April 24, 2006 > [Page 11] > > > ____________________________________________________________________________ _ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Oct 22 12:43:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETMSk-0006O4-Vo; Sat, 22 Oct 2005 12:43:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2tZ-0003eS-O2 for enum@megatron.ietf.org; Fri, 21 Oct 2005 15:49:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29852 for ; Fri, 21 Oct 2005 15:49:30 -0400 (EDT) Message-Id: <200510211949.PAA29852@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET35l-0004TF-9g for enum@ietf.org; Fri, 21 Oct 2005 16:02:18 -0400 Received: (qmail 17235 invoked by uid 510); 21 Oct 2005 16:03:42 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.136.53):. Processed in 1.450121 secs); 21 Oct 2005 20:03:42 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.136.53):. Processed in 1.450121 secs Process 17228) Received: from c-24-1-136-53.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.136.53) by 192.246.69.184 with SMTP; Fri, 21 Oct 2005 20:03:40 +0000 From: "Henry Sinnreich" To: "'Michael Hammer \(mhammer\)'" , "'David Meyer'" , "'Pfautz, Penn L, NEO'" Date: Fri, 21 Oct 2005 14:49:36 -0500 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3AE6892@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXWUrED2MtA7e4tT0aJ5p50zQ1crQAEXG5AAAEYuFAAAmbfcAABMUbw X-Antivirus-MYDOMAIN-Message-ID: <112992502083517228@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 507ad05d8e517f8285c14ade4dc3acf0 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 22 Oct 2005 12:42:46 -0400 Cc: enum@ietf.org, voipeer@lists.uoregon.edu Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > There are no carriers in Skype, correct? Skype is reselling E.164 phone numbers in an increasing number of countries. It makes sense therefore to _test the definitions_ here on the Skype case and there are other VoIP and IM services in similar situation. Some are really far too big to be overlooked. Unless the definition is refined in terms of facilities based and non facilities based. But there are VMNO's in the wireless world... Hint: The carrier definition is hopeless. "The Internet Is The Service" (Jon Peterson) and voice is an application IMHO. Let's go back to the layers in the I-D. Thanks, Henry -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Hammer (mhammer) Sent: Friday, October 21, 2005 2:04 PM To: henry@pulver.com; David Meyer; Pfautz, Penn L, NEO Cc: voipeer@lists.uoregon.edu; enum@ietf.org Subject: RE: [voipeer] draft-meyer-voipeer-terminology-03.txt p.s. There are no carriers in Skype, correct? Mike > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com] > Sent: Friday, October 21, 2005 1:57 PM > To: Michael Hammer (mhammer); 'David Meyer'; 'Pfautz, Penn L, NEO' > Cc: voipeer@lists.uoregon.edu; enum@ietf.org > Subject: RE: [voipeer] draft-meyer-voipeer-terminology-03.txt > > > a service provider authorized to offer telephony services > to the public. > > Does this include Skype? It's the biggest anyway. > > :-) Thanks, Henry > > > > > -----Original Message----- > From: owner-voipeer@lists.uoregon.edu > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Hammer > (mhammer) > Sent: Friday, October 21, 2005 12:30 PM > To: David Meyer; Pfautz, Penn L, NEO > Cc: voipeer@lists.uoregon.edu; enum@ietf.org > Subject: RE: [voipeer] draft-meyer-voipeer-terminology-03.txt > > David, > > A slight modification suggestion below. > > > -----Original Message----- > > From: owner-voipeer@lists.uoregon.edu > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of David Meyer > > Sent: Friday, October 21, 2005 11:12 AM > > To: Pfautz, Penn L, NEO > > Cc: voipeer@lists.uoregon.edu; enum@ietf.org > > Subject: Re: [voipeer] draft-meyer-voipeer-terminology-03.txt > > > > On Fri, Oct 21, 2005 at 09:51:17AM -0400, Pfautz, Penn L, NEO wrote: > > > Dave: > > > This is a nice start (indeed more than a start). I just have two > > > comments at this point: > > > > > > 1. The definition of carrier in 3.6 is probably too > restrictive. I > > > would not make it contingent on issuance of E.164 numbers > > but rather > > > just the provision of PSTN service. I appreciate your use our > > > carrier-of-record definition in 4.1. > > > > > > How about: > > > > 3.6. Carrier > > > > A carrier is defined to be a service provider authorized > > to provision PSTN > > The term PSTN is often used to mean the TDM networks offering > publicly available telephony services. In order to get away > from the TDM aspects, which some day might go away, how about: > > a service provider authorized to offer telephony services to > the public. > > That should cover both cases and gets away from unintended > baggage. I am assuming that the enterprises are not > considered pseudo-carriers and intended to be covered here. > > Mike > > > services. Note that the provision of such services is usually > > coupled with the authority to issue E.164 numbers [ITU.E164.1991] > > under the authority of a National Regulatory Authority (NRA). > > > > > > > 2. In reference to Layer 3 Peering (Section 3.7.1) I would > > like to see > > > included the concepts that a) peering involves delivery > of packets > > > that terminate on the peer's network and b) peering is > done without > > > traffic settlement charges. > > > > I'm ok with a) termination of traffic, but I'd like to > > avoid discussing SFI more than I have (see section > > 3.7). So how about: > > > > 3.7.1. Layer 3 Peering > > > > Layer 3 peering refers to interconnection of two service > providers > > for the purposes of exchanging IP packets which destined for one > > (or > > both) of the peer's networks. Layer 3 peering is generally > > agnostic > > to the IP payload, and is frequently achieved using a routing > > protocol such as BGP [RFC1771] to exchange the required routing > > information. > > > > An alternate, perhaps more operational definition of layer > > 3 peering > > is that two peers exchange their customer routers > (only), and hence > > any traffic between peers terminates on on the peer's network. > > > > > > Dave > > > > --- > > > > > > > > > > Network Working Group > > D. Meyer > > Internet-Draft > > October 21, 2005 > > Expires: April 24, 2006 > > > > > > Terminology for Describing VoIP Peering and Interconnect > > draft-meyer-voipeer-terminology-04.txt > > > > Status of this Memo > > > > By submitting this Internet-Draft, each author > represents that any > > applicable patent or other IPR claims of which he or she is aware > > have been or will be disclosed, and any of which he or > she becomes > > aware will be disclosed, in accordance with Section 6 of BCP 79. > > > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF), its areas, and its working groups. Note that > > other groups may also distribute working documents as Internet- > > Drafts. > > > > Internet-Drafts are draft documents valid for a maximum of six > > months > > and may be updated, replaced, or obsoleted by other documents at > > any > > time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as "work in progress." > > > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/ietf/1id-abstracts.txt. > > > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html. > > > > This Internet-Draft will expire on April 24, 2006. > > > > Copyright Notice > > > > Copyright (C) The Internet Society (2005). > > > > Abstract > > > > This document defines the terminology that is to be used by the > > Voice > > Over IP Peering and Interconnect Working Group > (voipeer), and has > > as > > its primary objective to focus the VOIPEER Working Group > during its > > discussions, and when writing requirements, gap analysis > and other > > solutions oriented documents. > > > > > > > > > > > > > > > > Meyer Expires April 24, 2006 > > [Page 1] > > > > > > Internet-Draft Terminology for Describing VoIP Peering > > October 2005 > > > > > > Table of Contents > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . > > . . . . 3 > > 2. Context . . . . . . . . . . . . . . . . . . . . . . . > > . . . . 3 > > 3. General Definitions . . . . . . . . . . . . . . . . . > > . . . . 4 > > 3.1. Call Routing Data . . . . . . . . . . . . . . . . > > . . . . 4 > > 3.2. Call Routing . . . . . . . . . . . . . . . . . . . > > . . . . 4 > > 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . . > > . . . . 5 > > 3.4. Network . . . . . . . . . . . . . . . . . . . . . > > . . . . 5 > > 3.5. VoIP Service Provider . . . . . . . . . . . . . . > > . . . . 5 > > 3.6. Carrier . . . . . . . . . . . . . . . . . . . . . > > . . . . 5 > > 3.7. Peering . . . . . . . . . . . . . . . . . . . . . > > . . . . 5 > > 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . . > > . . . . 6 > > 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . . > > . . . . 6 > > 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . . > > . . . . 6 > > 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . > > . . . . 6 > > 4.1. Carrier of Record . . . . . . . . . . . . . . . . > > . . . . 6 > > 4.2. Public ENUM . . . . . . . . . . . . . . . . . . . > > . . . . 6 > > 4.3. Private ENUM . . . . . . . . . . . . . . . . . . . > > . . . . 7 > > 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . . > > . . . . 7 > > 5. Conclusions . . . . . . . . . . . . . . . . . . . . . > > . . . . 7 > > 6. Acknowledgments . . . . . . . . . . . . . . . . . . . > > . . . . 7 > > 7. Security Considerations . . . . . . . . . . . . . . . > > . . . . 8 > > 8. IANA Considerations . . . . . . . . . . . . . . . . . > > . . . . 8 > > 9. References . . . . . . . . . . . . . . . . . . . . . . > > . . . . 8 > > 9.1. Normative References . . . . . . . . . . . . . . . > > . . . . 8 > > 9.2. Informative References . . . . . . . . . . . . . . > > . . . . 8 > > Author's Address . . . . . . . . . . . . . . . . . . . . . > > . . . . 10 > > Intellectual Property and Copyright Statements . . . . . . > > . . . . 11 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Meyer Expires April 24, 2006 > > [Page 2] > > > > > > Internet-Draft Terminology for Describing VoIP Peering > > October 2005 > > > > > > 1. Introduction > > > > The term "VoIP Peering" has historically been used to describe a > > wide > > variety of aspects pertaining to the interconnection of service > > provider networks and to the delivery of SIP call > termination over > > those interconnections. The discussion of these > interconnections > > has > > at times been confused by the fact that the term "peering" > > is used in > > various contexts to relate to interconnection at > different levels > > in > > a protocol stack. VoIP peering focuses on how to identify and > > route > > calls at the application layer, and it does not > > (necessarily) involve > > the exchange of packet routing data or media sessions. In > > particular, "layer 5 network" is used here to refer to the > > interconnection between SIP servers, as opposed to > interconnection > > at > > the IP layer ("layer 3"). Finally, the terms "peering" and > > "interconnect" are used interchangeably throughout this document. > > > > This document introduces standard terminology for use in > > characterizing VoIP interconnection. Note however, that > while this > > document is primarily targeted at the VoIP interconnect case, the > > terminology described here is applicable to those cases in which > > service providers interconnect using SIP signaling for > real-time or > > quasi-real-time communications. > > > > The remainder of this document is organized as follows: Section 2 > > provides the general context for the VOIPEER Working Group, and > > Section 3 provides the general definitions for real-time > SIP based > > communication, with focus on the VoIP interconnect case. > Section 4 > > briefly touches on terms from the ENUM Working Group. Finally, > > Section 5 provides comments on usage. > > > > > > 2. Context > > > > Figure 1 depicts the general VoIP interconnect context. In this > > case, the caller uses an E.164 number [ITU.E164.1991] as > the "name" > > of the called user. Note that this E.164 number is not > an address, > > since at this point we do not have information about where the > > named > > endpoint is located. In the case shown here, an E.164 number is > > used > > as a key to retrieve a NAPTR recored [RFC3404] from the > DNS, which > > in > > turn resolved into a SIP URI. Call routing is based on this SIP > > URI. > > The call routing step does not depend on the presence of an E.164 > > number; the SIP URI can be advertised in various other > ways, such > > as > > on a web page. Finally, note that the subsequent lookup steps, > > namely, lookup of SRV, A, and AAAA records (as well as > any routing > > steps below that) are outside the scope of VOIPEER. > > > > > > > > > > > > > > Meyer Expires April 24, 2006 > > [Page 3] > > > > > > Internet-Draft Terminology for Describing VoIP Peering > > October 2005 > > > > > > E.164 number <--- Peer Discovery > > | > > | <--- ENUM lookup of NAPTR in DNS > > | > > | > > | ENUM Working Group Scope > > =====+======================================= > > | VOIPEER Working Group Scope > > | > > | > > SIP URI <--- Call Routing Data (CRD) > > | > > | <--- Service Location (Lookup of SRV in DNS) > > | > > | > > Hostname <--- VoIP addressing and session establishment > > | > > | <---- Lookup of A and AAAA in DNS > > | > > Ip address > > | > > | <---- Routing protocols, ARP etc > > | > > Mac-address > > > > Figure 1: VoIP Interconnect Context > > > > The ENUM Working Group is primarily concerned with the > acquisition > > of > > Call Routing Data, or CRD (i.e., above the double line in Figure > > 1), > > while the VOIPEER Working Group is focused on the use of > such CRD. > > Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS > > entry), or via any other mechanism available to the user. > > > > > > 3. General Definitions > > > > 3.1. Call Routing Data > > > > Call Routing Data, or CRD, is a SIP URI used to route a > call (real- > > time, voice or other type) to the called domain's > ingress point. A > > domain's ingress point can be thought of as the location > pointed to > > by the SRV record that resulted from the resolution of the CRD > > (i.e., > > a SIP URI). > > > > 3.2. Call Routing > > > > Call routing is the set of processes, rules, and CRD > used to route > > a > > VoIP call to its proper (SIP) destination. More generally, call > > > > > > > > Meyer Expires April 24, 2006 > > [Page 4] > > > > > > Internet-Draft Terminology for Describing VoIP Peering > > October 2005 > > > > > > routing can be thought of as the set of processes, rules and CRD > > which are used to route a real-time session to its termination > > (ingress) point. > > > > 3.3. PSTN > > > > The term "PSTN" refers to the Public Switched Telephone > Network. > > In > > particular, the PSTN refers to the collection of interconnected > > circuit-switched voice-oriented public telephone networks, both > > commercial and government-owned. In general, PSTN terminals are > > addressed using E.164 numbers, noting that various > dial-plans (such > > as emergency services dial-plans) may not directly use > > E.164 numbers. > > > > 3.4. Network > > > > For purposes of this document and the VOIPEER and ENUM Working > > Groups, a network is defined to be the set of SIP > servers and end- > > users (customers) that are controlled by a single administrative > > domain. The network may also contain end-users who are > located on > > the PSTN. > > > > 3.5. VoIP Service Provider > > > > A VoIP service provider is an entity that provides > transport of SIP > > signaling (and possibly media streams) to its customers. Such a > > service provider may additionally be interconnected with other > > service providers; that is, it may "peer" with other service > > providers. A VoIP service provider may also > interconnect with the > > PSTN. > > > > Note that as soon as a ingress point is advertised via a SRV > > record, > > anyone can find that ingress point and hence can send > calls there. > > This is very similar to sending mail to a SMTP server > based on the > > existence of a MX record. > > > > 3.6. Carrier > > > > A carrier is defined to be a service provider authorized to > > provision > > PSTN services. Note that the provision of such services > is usually > > coupled with the authority to issue E.164 numbers [ITU.E164.1991] > > under the authority of a National Regulatory Authority (NRA). > > > > 3.7. Peering > > > > While the precise definition of the term "peering" is > the subject > > of > > some debate, peering in general refers to the negotiation of > > reciprocal interconnection arrangements, settlement-free or > > otherwise, between operationally independent service providers. > > > > > > > > Meyer Expires April 24, 2006 > > [Page 5] > > > > > > Internet-Draft Terminology for Describing VoIP Peering > > October 2005 > > > > > > This document distinguishes two types of peering, Layer > 3 Peering > > and > > Layer 5 peering, which are described below. > > > > 3.7.1. Layer 3 Peering > > > > Layer 3 peering refers to interconnection of two service > providers > > for the purposes of exchanging IP packets which destined for one > > (or > > both) of the peer's networks. Layer 3 peering is generally > > agnostic > > to the IP payload, and is frequently achieved using a routing > > protocol such as BGP [RFC1771] to exchange the required routing > > information. > > > > An alternate, perhaps more operational definition of layer > > 3 peering > > is that two peers exchange their customer routers > (only), and hence > > any traffic between peers terminates on on the peer's network. > > > > 3.7.2. Layer 5 Peering > > > > Layer 5 peering refers to interconnection of two service > providers > > for the purposes of SIP signaling. Note that in the layer > > 5 peering > > case, there is no intervening network. That is, for purposes of > > this > > discussion, there is no such thing as a "Layer 5 Transit > Network". > > > > 3.8. VoIP Peering > > > > VoIP peering is defined to be a layer 5 peering between two VoIP > > providers for purposes of routing real-time (or quasi-real > > time) call > > signaling between their respective customers. Media streams > > associated with this signaling (if any) are not constrained to > > follow > > the same set of paths. > > > > > > 4. ENUM > > > > ENUM [RFC3761] defines how the Domain Name System (DNS) > can be used > > for identifying available services connected to one E.164 number. > > > > 4.1. Carrier of Record > > > > For purposes of this document, "Carrier of Record", or > COR, refers > > to > > the entity that provides PSTN service for an E.164 number > > [I-D.lind- > > infrastructure-enum-reqs]. The exact definition of who > and what is > > a > > COR is ultimately the responsibility of the relevant NRA. > > > > 4.2. Public ENUM > > > > Public ENUM is generally defined as the set > administrative policies > > and procedures surrounding the use of the e164.arpa domain for > > > > > > > > Meyer Expires April 24, 2006 > > [Page 6] > > > > > > Internet-Draft Terminology for Describing VoIP Peering > > October 2005 > > > > > > Telephone Number to URI resolution [RFC3761]. Policies and > > procedures for the registration of telephone numbers within all > > branches of the e164.arpa tree are Nation State issues > by agreement > > with the IAB and ITU. National Regulatory Authorities have > > generally > > defined Public ENUM Registrants as the E.164 number holder as > > opposed > > to the COR that issued the phone number. > > > > 4.3. Private ENUM > > > > Private ENUM is generally regarded as one or more technologies > > (including DNS and SIP Redirect) that service providers or > > enterprises may use to exchange phone number to URI mappings in a > > private secure manner. Private ENUM may be used in any mutually > > agreed upon domain. Records in Private ENUM may be globally > > visible > > but in most cases are not visible to the global Internet and are > > protected using a variety of security technologies such as > > split-DNS, > > VPN's or various forms or authentication and authorization. > > Technical comments on issues surrounding split-DNS can > be found in > > [RFC2826]. > > > > 4.4. Carrier ENUM > > > > Carrier ENUM is generally regarded as the use of a > separate branch > > the e164.arpa tree, such as 4.4.c.e164.arpa to permit service > > providers to exchange phone number to URI data in order to find > > points of interconnection. The current theory of Carrier ENUM is > > that only the COR for a particular E.164 number is permitted to > > provision data for that E.164 within that portion of the > e164.arpa > > tree. > > > > In carrier ENUM case, only the COR may enter data in the > > corresponding domain. The COR may also enter CRD (i.e., > a SIP URI) > > to allow other VoIP Service Providers to route calls to its > > network. > > > > Finally, note that ENUM is not constrained to carry only > data (CDR) > > as defined by VOIPEER. In particular, an an important class of > > CRD, > > the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are > > most frequently used to interconnect with the PSTN directly, and > > are > > out of scope for VOIPEER. On the other hand, PSTN > endpoints served > > by a COR and reachable via CDR and networks as defined > in Section > > 3.1 > > and Section 3.4 are in scope for VOIPEER. > > > > > > 5. Conclusions > > > > > > 6. Acknowledgments > > > > > > > > > > Meyer Expires April 24, 2006 > > [Page 7] > > > > > > Internet-Draft Terminology for Describing VoIP Peering > > October 2005 > > > > > > Many of the definitions were gleaned from detailed > discussions on > > the > > VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim, > Mike Hammer, > > Jean-Francois Mule, Richard Shocky, and Richard Stastny made > > valuable > > contributions to early revisions of this document. Patrik > > Faltstrom > > also made many insightful comments to early versions of > this draft, > > and contributed the basis of Figure 1. > > > > > > 7. Security Considerations > > > > This document itself introduces no new security considerations. > > However, it is important to note that VoIP interconnect > has a wide > > variety of security issues that should be considered in documents > > addressing both protocol and use case analyzes. > > > > > > 8. IANA Considerations > > > > This document creates no new requirements on IANA namespaces > > [RFC2434]. > > > > > > 9. References > > > > 9.1. Normative References > > > > [RFC3404] Mealling, M., "Dynamic Delegation Discovery System > > (DDDS) > > Part Four: The Uniform Resource Identifiers (URI)", > > RFC 3404, October 2002. > > > > [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform > > Resource Identifiers (URI) Dynamic Delegation > Discovery > > System (DDDS) Application (ENUM)", RFC 3761, > April 2004. > > > > [ITU.E164.1991] > > International Telecommunications Union, "The > > International > > Public Telecommunication Numbering Plan", ITU- > > T Recommendation E.164, 1991. > > > > [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", > > RFC 3966, December 2004. > > > > 9.2. Informative References > > > > [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 > > (BGP-4)", RFC 1771, March 1995. > > > > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for > Writing an > > > > > > > > Meyer Expires April 24, 2006 > > [Page 8] > > > > > > Internet-Draft Terminology for Describing VoIP Peering > > October 2005 > > > > > > IANA Considerations Section in RFCs", BCP 26, > RFC 2434, > > October 1998. > > > > [RFC2826] Internet Architecture Board, "IAB Technical > Comment on > > the > > Unique DNS Root", RFC 2826, May 2000. > > > > [I-D.lind-infrastructure-enum-reqs] > > Lind, S., "Infrastructure ENUM Requirements", > > draft-lind-infrastructure-enum-reqs-00 (work in > > progress), > > July 2005. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Meyer Expires April 24, 2006 > > [Page 9] > > > > > > Internet-Draft Terminology for Describing VoIP Peering > > October 2005 > > > > > > Author's Address > > > > David Meyer > > > > Email: dmm@1-4-5.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Meyer Expires April 24, 2006 > > [Page 10] > > > > > > Internet-Draft Terminology for Describing VoIP Peering > > October 2005 > > > > > > Intellectual Property Statement > > > > The IETF takes no position regarding the validity or scope of any > > Intellectual Property Rights or other rights that might > be claimed > > to > > pertain to the implementation or use of the technology > described in > > this document or the extent to which any license under > such rights > > might or might not be available; nor does it represent > that it has > > made any independent effort to identify any such rights. > > Information > > on the procedures with respect to rights in RFC documents can be > > found in BCP 78 and BCP 79. > > > > Copies of IPR disclosures made to the IETF Secretariat and any > > assurances of licenses to be made available, or the result of an > > attempt made to obtain a general license or permission > for the use > > of > > such proprietary rights by implementers or users of this > > specification can be obtained from the IETF on-line IPR > repository > > at > > http://www.ietf.org/ipr. > > > > The IETF invites any interested party to bring to its > attention any > > copyrights, patents or patent applications, or other proprietary > > rights that may cover technology that may be required to > implement > > this standard. Please address the information to the IETF at > > ietf-ipr@ietf.org. > > > > > > Disclaimer of Validity > > > > This document and the information contained herein are > provided on > > an > > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > > REPRESENTS > > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND > THE INTERNET > > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, > > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A > PARTICULAR PURPOSE. > > > > > > Copyright Statement > > > > Copyright (C) The Internet Society (2005). This document is > > subject > > to the rights, licenses and restrictions contained in BCP 78, and > > except as set forth therein, the authors retain all their rights. > > > > > > Acknowledgment > > > > Funding for the RFC Editor function is currently provided by the > > Internet Society. > > > > > > > > > > Meyer Expires April 24, 2006 > > [Page 11] > > > > > > > > ______________________________________________________________ > ______________ > _ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > ____________________________________________________________________________ _ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 24 03:10:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETwTr-0000Aw-V8; Mon, 24 Oct 2005 03:10:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETwTp-00008r-RY for enum@megatron.ietf.org; Mon, 24 Oct 2005 03:10:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20894 for ; Mon, 24 Oct 2005 03:10:35 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETwgW-0007nh-HB for enum@ietf.org; Mon, 24 Oct 2005 03:23:57 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9O7AJL01212; Mon, 24 Oct 2005 03:10:19 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 24 Oct 2005 03:10:15 -0400 Message-ID: Thread-Topic: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXWUcpZwcEkRbZxRX6zI5wPKYmZSwAAEU2QAIVcXnA= From: "James McEachern" To: "Pfautz, Penn L, NEO" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5c4dbf5b8b26864121f8d3a6e6be1ee0 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The discussion about the definition of a carrier makes me wonder what is = the important aspect of being a carrier (or not) that we are trying to = get at here. Usually, when we develop a technical (or legal/regulatory) definition = for a term (say "foo") it is because some action will be required, or = precluded, based on whether or not an entity satisfies the definition of = "foo". Because of this, the definition of "foo" is often tuned to = ensure we achieve the desired discrimination between entities that are a = member of "foo" and those that are not.=20 Unfortunately, in this context, I do not understand what subsequent = decision will depend on whether or not an entity qualifies as a carrier. = (If no subsequent decisions depend on being a carrier, then any = definition will do.) Can anyone explain what will be allowed, or precluded if an entity is = deemed to be a carrier by this group? Once we all agree on that, the = correct definition may be clearer. Concerning Henry's comment about Skype, as I read the definitions, it = would appear that Skype may well be a carrier - at least for Skype = In/Out. I also suspect Skype could be the carrier of record for Skype = In numbers. Interestingly, I believe the current definitions suggest = that Skype is *not* a VoIP Service provider, since (as I understand) it = does not generally use SIP for its service (or application). This does = seem somewhat counter intuitive.=20 Jim =20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = Pfautz, Penn L, NEO Sent: Friday, October 21, 2005 11:16 AM To: David Meyer Cc: enum@ietf.org; voipeer@lists.uoregon.edu Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt OK with just a couple typos below=20 Penn -----Original Message----- From: David Meyer [mailto:dmm@1-4-5.net]=20 Sent: Friday, October 21, 2005 11:12 AM To: Pfautz, Penn L, NEO Cc: voipeer@lists.uoregon.edu; enum@ietf.org Subject: Re: [voipeer] draft-meyer-voipeer-terminology-03.txt On Fri, Oct 21, 2005 at 09:51:17AM -0400, Pfautz, Penn L, NEO wrote: > Dave: > This is a nice start (indeed more than a start). I just have two > comments at this point: >=20 > 1. The definition of carrier in 3.6 is probably too restrictive. I > would not make it contingent on issuance of E.164 numbers but rather > just the provision of PSTN service. I appreciate your use our > carrier-of-record definition in 4.1. How about: 3.6. Carrier A carrier is defined to be a service provider authorized to provision PSTN services. Note that the provision of such services is usually coupled with the authority to issue E.164 numbers [ITU.E164.1991] under the authority of a National Regulatory Authority (NRA). =09 > 2. In reference to Layer 3 Peering (Section 3.7.1) I would like to see > included the concepts that a) peering involves delivery of packets that > terminate on the peer's network and b) peering is done without traffic > settlement charges. I'm ok with a) termination of traffic, but I'd like to avoid discussing SFI more than I have (see section 3.7). So how about: 3.7.1. Layer 3 Peering Layer 3 peering refers to interconnection of two service providers for the purposes of exchanging IP packets which destined for one (or both) of the peer's networks. Layer 3 peering is generally agnostic to the IP payload, and is frequently achieved using a routing protocol such as BGP [RFC1771] to exchange the required routing information. An alternate, perhaps more operational definition of layer 3 peering is that two peers exchange their customer router (only), and hence ^ any traffic between peers terminates on one of the peer's network. ^^^^^^^^ =09 Dave --- Network Working Group D. Meyer Internet-Draft October 21, 2005 Expires: April 24, 2006 Terminology for Describing VoIP Peering and Interconnect draft-meyer-voipeer-terminology-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 24, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines the terminology that is to be used by the Voice Over IP Peering and Interconnect Working Group (voipeer), and has as its primary objective to focus the VOIPEER Working Group during its discussions, and when writing requirements, gap analysis and other solutions oriented documents. Meyer Expires April 24, 2006 [Page 1] Internet-Draft Terminology for Describing VoIP Peering October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. General Definitions . . . . . . . . . . . . . . . . . . . . . 4 3.1. Call Routing Data . . . . . . . . . . . . . . . . . . . . 4 3.2. Call Routing . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Network . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5. VoIP Service Provider . . . . . . . . . . . . . . . . . . 5 3.6. Carrier . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7. Peering . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . . . . . . 6 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . . . . . . 6 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . . . . . . 6 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Carrier of Record . . . . . . . . . . . . . . . . . . . . 6 4.2. Public ENUM . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Private ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Meyer Expires April 24, 2006 [Page 2] Internet-Draft Terminology for Describing VoIP Peering October 2005 1. Introduction The term "VoIP Peering" has historically been used to describe a wide variety of aspects pertaining to the interconnection of service provider networks and to the delivery of SIP call termination over those interconnections. The discussion of these interconnections has at times been confused by the fact that the term "peering" is used in various contexts to relate to interconnection at different levels in a protocol stack. VoIP peering focuses on how to identify and route calls at the application layer, and it does not (necessarily) involve the exchange of packet routing data or media sessions. In particular, "layer 5 network" is used here to refer to the interconnection between SIP servers, as opposed to interconnection at the IP layer ("layer 3"). Finally, the terms "peering" and "interconnect" are used interchangeably throughout this document. This document introduces standard terminology for use in characterizing VoIP interconnection. Note however, that while this document is primarily targeted at the VoIP interconnect case, the terminology described here is applicable to those cases in which service providers interconnect using SIP signaling for real-time or quasi-real-time communications. The remainder of this document is organized as follows: Section 2 provides the general context for the VOIPEER Working Group, and Section 3 provides the general definitions for real-time SIP based communication, with focus on the VoIP interconnect case. Section 4 briefly touches on terms from the ENUM Working Group. Finally, Section 5 provides comments on usage. 2. Context Figure 1 depicts the general VoIP interconnect context. In this case, the caller uses an E.164 number [ITU.E164.1991] as the "name" of the called user. Note that this E.164 number is not an address, since at this point we do not have information about where the named endpoint is located. In the case shown here, an E.164 number is used as a key to retrieve a NAPTR recored [RFC3404] from the DNS, which in turn resolved into a SIP URI. Call routing is based on this SIP URI. The call routing step does not depend on the presence of an E.164 number; the SIP URI can be advertised in various other ways, such as on a web page. Finally, note that the subsequent lookup steps, namely, lookup of SRV, A, and AAAA records (as well as any routing steps below that) are outside the scope of VOIPEER. Meyer Expires April 24, 2006 [Page 3] Internet-Draft Terminology for Describing VoIP Peering October 2005 E.164 number <--- Peer Discovery | | <--- ENUM lookup of NAPTR in DNS | | | ENUM Working Group Scope = =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | VOIPEER Working Group Scope | | SIP URI <--- Call Routing Data (CRD) | | <--- Service Location (Lookup of SRV in DNS) | | Hostname <--- VoIP addressing and session establishment | | <---- Lookup of A and AAAA in DNS | Ip address | | <---- Routing protocols, ARP etc | Mac-address Figure 1: VoIP Interconnect Context The ENUM Working Group is primarily concerned with the acquisition of Call Routing Data, or CRD (i.e., above the double line in Figure 1), while the VOIPEER Working Group is focused on the use of such CRD. Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS entry), or via any other mechanism available to the user. 3. General Definitions 3.1. Call Routing Data Call Routing Data, or CRD, is a SIP URI used to route a call (real- time, voice or other type) to the called domain's ingress point. A domain's ingress point can be thought of as the location pointed to by the SRV record that resulted from the resolution of the CRD (i.e., a SIP URI). 3.2. Call Routing Call routing is the set of processes, rules, and CRD used to route a VoIP call to its proper (SIP) destination. More generally, call Meyer Expires April 24, 2006 [Page 4] Internet-Draft Terminology for Describing VoIP Peering October 2005 routing can be thought of as the set of processes, rules and CRD which are used to route a real-time session to its termination (ingress) point. 3.3. PSTN The term "PSTN" refers to the Public Switched Telephone Network. In particular, the PSTN refers to the collection of interconnected circuit-switched voice-oriented public telephone networks, both commercial and government-owned. In general, PSTN terminals are addressed using E.164 numbers, noting that various dial-plans (such as emergency services dial-plans) may not directly use E.164 numbers. 3.4. Network For purposes of this document and the VOIPEER and ENUM Working Groups, a network is defined to be the set of SIP servers and end- users (customers) that are controlled by a single administrative domain. The network may also contain end-users who are located on the PSTN. 3.5. VoIP Service Provider A VoIP service provider is an entity that provides transport of SIP signaling (and possibly media streams) to its customers. Such a service provider may additionally be interconnected with other service providers; that is, it may "peer" with other service providers. A VoIP service provider may also interconnect with the PSTN. Note that as soon as a ingress point is advertised via a SRV record, anyone can find that ingress point and hence can send calls there. This is very similar to sending mail to a SMTP server based on the existence of a MX record. 3.6. Carrier A carrier is defined to be a service provider authorized to provision PSTN services. Note that the provision of such services is usually coupled with the authority to issue E.164 numbers [ITU.E164.1991] under the authority of a National Regulatory Authority (NRA). 3.7. Peering While the precise definition of the term "peering" is the subject of some debate, peering in general refers to the negotiation of reciprocal interconnection arrangements, settlement-free or otherwise, between operationally independent service providers. Meyer Expires April 24, 2006 [Page 5] Internet-Draft Terminology for Describing VoIP Peering October 2005 This document distinguishes two types of peering, Layer 3 Peering and Layer 5 peering, which are described below. 3.7.1. Layer 3 Peering Layer 3 peering refers to interconnection of two service providers for the purposes of exchanging IP packets which destined for one (or both) of the peer's networks. Layer 3 peering is generally agnostic to the IP payload, and is frequently achieved using a routing protocol such as BGP [RFC1771] to exchange the required routing information. An alternate, perhaps more operational definition of layer 3 peering is that two peers exchange their customer routers (only), and hence any traffic between peers terminates on on the peer's network. 3.7.2. Layer 5 Peering Layer 5 peering refers to interconnection of two service providers for the purposes of SIP signaling. Note that in the layer 5 peering case, there is no intervening network. That is, for purposes of this discussion, there is no such thing as a "Layer 5 Transit Network". 3.8. VoIP Peering VoIP peering is defined to be a layer 5 peering between two VoIP providers for purposes of routing real-time (or quasi-real time) call signaling between their respective customers. Media streams associated with this signaling (if any) are not constrained to follow the same set of paths. 4. ENUM ENUM [RFC3761] defines how the Domain Name System (DNS) can be used for identifying available services connected to one E.164 number. 4.1. Carrier of Record For purposes of this document, "Carrier of Record", or COR, refers to the entity that provides PSTN service for an E.164 number [I-D.lind- infrastructure-enum-reqs]. The exact definition of who and what is a COR is ultimately the responsibility of the relevant NRA. 4.2. Public ENUM Public ENUM is generally defined as the set administrative policies and procedures surrounding the use of the e164.arpa domain for Meyer Expires April 24, 2006 [Page 6] Internet-Draft Terminology for Describing VoIP Peering October 2005 Telephone Number to URI resolution [RFC3761]. Policies and procedures for the registration of telephone numbers within all branches of the e164.arpa tree are Nation State issues by agreement with the IAB and ITU. National Regulatory Authorities have generally defined Public ENUM Registrants as the E.164 number holder as opposed to the COR that issued the phone number. 4.3. Private ENUM Private ENUM is generally regarded as one or more technologies (including DNS and SIP Redirect) that service providers or enterprises may use to exchange phone number to URI mappings in a private secure manner. Private ENUM may be used in any mutually agreed upon domain. Records in Private ENUM may be globally visible but in most cases are not visible to the global Internet and are protected using a variety of security technologies such as split-DNS, VPN's or various forms or authentication and authorization. Technical comments on issues surrounding split-DNS can be found in [RFC2826]. 4.4. Carrier ENUM Carrier ENUM is generally regarded as the use of a separate branch the e164.arpa tree, such as 4.4.c.e164.arpa to permit service providers to exchange phone number to URI data in order to find points of interconnection. The current theory of Carrier ENUM is that only the COR for a particular E.164 number is permitted to provision data for that E.164 within that portion of the e164.arpa tree. In carrier ENUM case, only the COR may enter data in the corresponding domain. The COR may also enter CRD (i.e., a SIP URI) to allow other VoIP Service Providers to route calls to its network. Finally, note that ENUM is not constrained to carry only data (CDR) as defined by VOIPEER. In particular, an an important class of CRD, the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are most frequently used to interconnect with the PSTN directly, and are out of scope for VOIPEER. On the other hand, PSTN endpoints served by a COR and reachable via CDR and networks as defined in Section 3.1 and Section 3.4 are in scope for VOIPEER. 5. Conclusions 6. Acknowledgments Meyer Expires April 24, 2006 [Page 7] Internet-Draft Terminology for Describing VoIP Peering October 2005 Many of the definitions were gleaned from detailed discussions on the VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer, Jean-Francois Mule, Richard Shocky, and Richard Stastny made valuable contributions to early revisions of this document. Patrik Faltstrom also made many insightful comments to early versions of this draft, and contributed the basis of Figure 1. 7. Security Considerations This document itself introduces no new security considerations. However, it is important to note that VoIP interconnect has a wide variety of security issues that should be considered in documents addressing both protocol and use case analyzes. 8. IANA Considerations This document creates no new requirements on IANA namespaces [RFC2434]. 9. References 9.1. Normative References [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [ITU.E164.1991] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU- T Recommendation E.164, 1991. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. 9.2. Informative References [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an Meyer Expires April 24, 2006 [Page 8] Internet-Draft Terminology for Describing VoIP Peering October 2005 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000. [I-D.lind-infrastructure-enum-reqs] Lind, S., "Infrastructure ENUM Requirements", draft-lind-infrastructure-enum-reqs-00 (work in progress), July 2005. Meyer Expires April 24, 2006 [Page 9] Internet-Draft Terminology for Describing VoIP Peering October 2005 Author's Address David Meyer Email: dmm@1-4-5.net Meyer Expires April 24, 2006 [Page 10] Internet-Draft Terminology for Describing VoIP Peering October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Meyer Expires April 24, 2006 [Page 11] _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 24 04:34:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxml-0006bw-8W; Mon, 24 Oct 2005 04:34:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxmi-0006bV-Dg for enum@megatron.ietf.org; Mon, 24 Oct 2005 04:34:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24855 for ; Mon, 24 Oct 2005 04:34:09 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ETxzO-0002BE-R0 for enum@ietf.org; Mon, 24 Oct 2005 04:47:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Date: Mon, 24 Oct 2005 10:37:44 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B21D6@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXWUcpZwcEkRbZxRX6zI5wPKYmZSwAAEU2QAIVcXnAAAY4r4A== From: "Stastny Richard" To: "James McEachern" , "Pfautz, Penn L, NEO" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a1775db2061587296285ba70384116 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Correct, That is what I was trying to get at in a previous post: Voipeer is dealing with routing between VoIP service providers using SIP URIs. So the definition of a VoIP Service provider is needed to be clear about is role in voipeer. Skype is a VoIP service provider if Skype is peering with other via SIP. Currently it is not. This means that E.164 numbers are out of scope in voipeer. They are in scope in enum WG. Within scope of enum WG is the mapping from E.164 numbers to SIP URIs. This separation is now clearly stated in draft-meyer-voipeer-terminology-03 Since the definition of a carrier and especially a Carrier-of-Record (see draft-lind-infrastucture-enmum-reqs-01) is tightly linked to E.164 numbers and PSTN connectivity), it is out of scope in voipeer. Cheers Richard > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > James McEachern > Sent: Monday, October 24, 2005 9:10 AM > To: Pfautz, Penn L, NEO; David Meyer > Cc: enum@ietf.org; voipeer@lists.uoregon.edu > Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt >=20 > The discussion about the definition of a carrier makes me wonder what is > the important aspect of being a carrier (or not) that we are trying to get > at here. >=20 > Usually, when we develop a technical (or legal/regulatory) definition for > a term (say "foo") it is because some action will be required, or > precluded, based on whether or not an entity satisfies the definition of > "foo". Because of this, the definition of "foo" is often tuned to ensure > we achieve the desired discrimination between entities that are a member > of "foo" and those that are not. >=20 > Unfortunately, in this context, I do not understand what subsequent > decision will depend on whether or not an entity qualifies as a carrier. > (If no subsequent decisions depend on being a carrier, then any definition > will do.) >=20 > Can anyone explain what will be allowed, or precluded if an entity is > deemed to be a carrier by this group? Once we all agree on that, the > correct definition may be clearer. >=20 > Concerning Henry's comment about Skype, as I read the definitions, it > would appear that Skype may well be a carrier - at least for Skype In/Out. > I also suspect Skype could be the carrier of record for Skype In numbers. > Interestingly, I believe the current definitions suggest that Skype is > *not* a VoIP Service provider, since (as I understand) it does not > generally use SIP for its service (or application). This does seem > somewhat counter intuitive. >=20 > Jim >=20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Pfautz, Penn L, NEO > Sent: Friday, October 21, 2005 11:16 AM > To: David Meyer > Cc: enum@ietf.org; voipeer@lists.uoregon.edu > Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt >=20 > OK with just a couple typos below >=20 > Penn >=20 > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net] > Sent: Friday, October 21, 2005 11:12 AM > To: Pfautz, Penn L, NEO > Cc: voipeer@lists.uoregon.edu; enum@ietf.org > Subject: Re: [voipeer] draft-meyer-voipeer-terminology-03.txt >=20 > On Fri, Oct 21, 2005 at 09:51:17AM -0400, Pfautz, Penn L, NEO wrote: > > Dave: > > This is a nice start (indeed more than a start). I just have two > > comments at this point: > > > > 1. The definition of carrier in 3.6 is probably too restrictive. I > > would not make it contingent on issuance of E.164 numbers but rather > > just the provision of PSTN service. I appreciate your use our > > carrier-of-record definition in 4.1. >=20 >=20 > How about: >=20 > 3.6. Carrier >=20 > A carrier is defined to be a service provider authorized to provision > PSTN services. Note that the provision of such services is usually > coupled with the authority to issue E.164 numbers [ITU.E164.1991] > under the authority of a National Regulatory Authority (NRA). >=20 >=20 > > 2. In reference to Layer 3 Peering (Section 3.7.1) I would like to see > > included the concepts that a) peering involves delivery of packets > that > > terminate on the peer's network and b) peering is done without traffic > > settlement charges. >=20 > I'm ok with a) termination of traffic, but I'd like to > avoid discussing SFI more than I have (see section > 3.7). So how about: >=20 > 3.7.1. Layer 3 Peering >=20 > Layer 3 peering refers to interconnection of two service providers > for the purposes of exchanging IP packets which destined for one (or > both) of the peer's networks. Layer 3 peering is generally agnostic > to the IP payload, and is frequently achieved using a routing > protocol such as BGP [RFC1771] to exchange the required routing > information. >=20 > An alternate, perhaps more operational definition of layer 3 peering > is that two peers exchange their customer router (only), and hence > ^ > any traffic between peers terminates on one of the peer's network. > ^^^^^^^^ >=20 > Dave >=20 > --- >=20 >=20 >=20 >=20 > Network Working Group D. Meyer > Internet-Draft October 21, 2005 > Expires: April 24, 2006 >=20 >=20 > Terminology for Describing VoIP Peering and Interconnect > draft-meyer-voipeer-terminology-04.txt >=20 > Status of this Memo >=20 > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. >=20 > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. >=20 > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. >=20 > This Internet-Draft will expire on April 24, 2006. >=20 > Copyright Notice >=20 > Copyright (C) The Internet Society (2005). >=20 > Abstract >=20 > This document defines the terminology that is to be used by the Voice > Over IP Peering and Interconnect Working Group (voipeer), and has as > its primary objective to focus the VOIPEER Working Group during its > discussions, and when writing requirements, gap analysis and other > solutions oriented documents. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 24, 2006 [Page 1] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 3. General Definitions . . . . . . . . . . . . . . . . . . . . . 4 > 3.1. Call Routing Data . . . . . . . . . . . . . . . . . . . . 4 > 3.2. Call Routing . . . . . . . . . . . . . . . . . . . . . . . 4 > 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.4. Network . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.5. VoIP Service Provider . . . . . . . . . . . . . . . . . . 5 > 3.6. Carrier . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.7. Peering . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . . . . . . 6 > 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . . . . . . 6 > 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . . . . . . 6 > 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 4.1. Carrier of Record . . . . . . . . . . . . . . . . . . . . 6 > 4.2. Public ENUM . . . . . . . . . . . . . . . . . . . . . . . 6 > 4.3. Private ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 > 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 > 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 > 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 > Intellectual Property and Copyright Statements . . . . . . . . . . 11 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 24, 2006 [Page 2] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > 1. Introduction >=20 > The term "VoIP Peering" has historically been used to describe a wide > variety of aspects pertaining to the interconnection of service > provider networks and to the delivery of SIP call termination over > those interconnections. The discussion of these interconnections has > at times been confused by the fact that the term "peering" is used in > various contexts to relate to interconnection at different levels in > a protocol stack. VoIP peering focuses on how to identify and route > calls at the application layer, and it does not (necessarily) involve > the exchange of packet routing data or media sessions. In > particular, "layer 5 network" is used here to refer to the > interconnection between SIP servers, as opposed to interconnection at > the IP layer ("layer 3"). Finally, the terms "peering" and > "interconnect" are used interchangeably throughout this document. >=20 > This document introduces standard terminology for use in > characterizing VoIP interconnection. Note however, that while this > document is primarily targeted at the VoIP interconnect case, the > terminology described here is applicable to those cases in which > service providers interconnect using SIP signaling for real-time or > quasi-real-time communications. >=20 > The remainder of this document is organized as follows: Section 2 > provides the general context for the VOIPEER Working Group, and > Section 3 provides the general definitions for real-time SIP based > communication, with focus on the VoIP interconnect case. Section 4 > briefly touches on terms from the ENUM Working Group. Finally, > Section 5 provides comments on usage. >=20 >=20 > 2. Context >=20 > Figure 1 depicts the general VoIP interconnect context. In this > case, the caller uses an E.164 number [ITU.E164.1991] as the "name" > of the called user. Note that this E.164 number is not an address, > since at this point we do not have information about where the named > endpoint is located. In the case shown here, an E.164 number is used > as a key to retrieve a NAPTR recored [RFC3404] from the DNS, which in > turn resolved into a SIP URI. Call routing is based on this SIP URI. > The call routing step does not depend on the presence of an E.164 > number; the SIP URI can be advertised in various other ways, such as > on a web page. Finally, note that the subsequent lookup steps, > namely, lookup of SRV, A, and AAAA records (as well as any routing > steps below that) are outside the scope of VOIPEER. >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 24, 2006 [Page 3] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > E.164 number <--- Peer Discovery > | > | <--- ENUM lookup of NAPTR in DNS > | > | > | ENUM Working Group Scope > = =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | VOIPEER Working Group Scope > | > | > SIP URI <--- Call Routing Data (CRD) > | > | <--- Service Location (Lookup of SRV in DNS) > | > | > Hostname <--- VoIP addressing and session establishment > | > | <---- Lookup of A and AAAA in DNS > | > Ip address > | > | <---- Routing protocols, ARP etc > | > Mac-address >=20 > Figure 1: VoIP Interconnect Context >=20 > The ENUM Working Group is primarily concerned with the acquisition of > Call Routing Data, or CRD (i.e., above the double line in Figure 1), > while the VOIPEER Working Group is focused on the use of such CRD. > Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS > entry), or via any other mechanism available to the user. >=20 >=20 > 3. General Definitions >=20 > 3.1. Call Routing Data >=20 > Call Routing Data, or CRD, is a SIP URI used to route a call (real- > time, voice or other type) to the called domain's ingress point. A > domain's ingress point can be thought of as the location pointed to > by the SRV record that resulted from the resolution of the CRD (i.e., > a SIP URI). >=20 > 3.2. Call Routing >=20 > Call routing is the set of processes, rules, and CRD used to route a > VoIP call to its proper (SIP) destination. More generally, call >=20 >=20 >=20 > Meyer Expires April 24, 2006 [Page 4] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > routing can be thought of as the set of processes, rules and CRD > which are used to route a real-time session to its termination > (ingress) point. >=20 > 3.3. PSTN >=20 > The term "PSTN" refers to the Public Switched Telephone Network. In > particular, the PSTN refers to the collection of interconnected > circuit-switched voice-oriented public telephone networks, both > commercial and government-owned. In general, PSTN terminals are > addressed using E.164 numbers, noting that various dial-plans (such > as emergency services dial-plans) may not directly use E.164 numbers. >=20 > 3.4. Network >=20 > For purposes of this document and the VOIPEER and ENUM Working > Groups, a network is defined to be the set of SIP servers and end- > users (customers) that are controlled by a single administrative > domain. The network may also contain end-users who are located on > the PSTN. >=20 > 3.5. VoIP Service Provider >=20 > A VoIP service provider is an entity that provides transport of SIP > signaling (and possibly media streams) to its customers. Such a > service provider may additionally be interconnected with other > service providers; that is, it may "peer" with other service > providers. A VoIP service provider may also interconnect with the > PSTN. >=20 > Note that as soon as a ingress point is advertised via a SRV record, > anyone can find that ingress point and hence can send calls there. > This is very similar to sending mail to a SMTP server based on the > existence of a MX record. >=20 > 3.6. Carrier >=20 > A carrier is defined to be a service provider authorized to provision > PSTN services. Note that the provision of such services is usually > coupled with the authority to issue E.164 numbers [ITU.E164.1991] > under the authority of a National Regulatory Authority (NRA). >=20 > 3.7. Peering >=20 > While the precise definition of the term "peering" is the subject of > some debate, peering in general refers to the negotiation of > reciprocal interconnection arrangements, settlement-free or > otherwise, between operationally independent service providers. >=20 >=20 >=20 > Meyer Expires April 24, 2006 [Page 5] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > This document distinguishes two types of peering, Layer 3 Peering and > Layer 5 peering, which are described below. >=20 > 3.7.1. Layer 3 Peering >=20 > Layer 3 peering refers to interconnection of two service providers > for the purposes of exchanging IP packets which destined for one (or > both) of the peer's networks. Layer 3 peering is generally agnostic > to the IP payload, and is frequently achieved using a routing > protocol such as BGP [RFC1771] to exchange the required routing > information. >=20 > An alternate, perhaps more operational definition of layer 3 peering > is that two peers exchange their customer routers (only), and hence > any traffic between peers terminates on on the peer's network. >=20 > 3.7.2. Layer 5 Peering >=20 > Layer 5 peering refers to interconnection of two service providers > for the purposes of SIP signaling. Note that in the layer 5 peering > case, there is no intervening network. That is, for purposes of this > discussion, there is no such thing as a "Layer 5 Transit Network". >=20 > 3.8. VoIP Peering >=20 > VoIP peering is defined to be a layer 5 peering between two VoIP > providers for purposes of routing real-time (or quasi-real time) call > signaling between their respective customers. Media streams > associated with this signaling (if any) are not constrained to follow > the same set of paths. >=20 >=20 > 4. ENUM >=20 > ENUM [RFC3761] defines how the Domain Name System (DNS) can be used > for identifying available services connected to one E.164 number. >=20 > 4.1. Carrier of Record >=20 > For purposes of this document, "Carrier of Record", or COR, refers to > the entity that provides PSTN service for an E.164 number [I-D.lind- > infrastructure-enum-reqs]. The exact definition of who and what is a > COR is ultimately the responsibility of the relevant NRA. >=20 > 4.2. Public ENUM >=20 > Public ENUM is generally defined as the set administrative policies > and procedures surrounding the use of the e164.arpa domain for >=20 >=20 >=20 > Meyer Expires April 24, 2006 [Page 6] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > Telephone Number to URI resolution [RFC3761]. Policies and > procedures for the registration of telephone numbers within all > branches of the e164.arpa tree are Nation State issues by agreement > with the IAB and ITU. National Regulatory Authorities have generally > defined Public ENUM Registrants as the E.164 number holder as opposed > to the COR that issued the phone number. >=20 > 4.3. Private ENUM >=20 > Private ENUM is generally regarded as one or more technologies > (including DNS and SIP Redirect) that service providers or > enterprises may use to exchange phone number to URI mappings in a > private secure manner. Private ENUM may be used in any mutually > agreed upon domain. Records in Private ENUM may be globally visible > but in most cases are not visible to the global Internet and are > protected using a variety of security technologies such as split-DNS, > VPN's or various forms or authentication and authorization. > Technical comments on issues surrounding split-DNS can be found in > [RFC2826]. >=20 > 4.4. Carrier ENUM >=20 > Carrier ENUM is generally regarded as the use of a separate branch > the e164.arpa tree, such as 4.4.c.e164.arpa to permit service > providers to exchange phone number to URI data in order to find > points of interconnection. The current theory of Carrier ENUM is > that only the COR for a particular E.164 number is permitted to > provision data for that E.164 within that portion of the e164.arpa > tree. >=20 > In carrier ENUM case, only the COR may enter data in the > corresponding domain. The COR may also enter CRD (i.e., a SIP URI) > to allow other VoIP Service Providers to route calls to its network. >=20 > Finally, note that ENUM is not constrained to carry only data (CDR) > as defined by VOIPEER. In particular, an an important class of CRD, > the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are > most frequently used to interconnect with the PSTN directly, and are > out of scope for VOIPEER. On the other hand, PSTN endpoints served > by a COR and reachable via CDR and networks as defined in Section 3.1 > and Section 3.4 are in scope for VOIPEER. >=20 >=20 > 5. Conclusions >=20 >=20 > 6. Acknowledgments >=20 >=20 >=20 >=20 > Meyer Expires April 24, 2006 [Page 7] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > Many of the definitions were gleaned from detailed discussions on the > VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer, > Jean-Francois Mule, Richard Shocky, and Richard Stastny made valuable > contributions to early revisions of this document. Patrik Faltstrom > also made many insightful comments to early versions of this draft, > and contributed the basis of Figure 1. >=20 >=20 > 7. Security Considerations >=20 > This document itself introduces no new security considerations. > However, it is important to note that VoIP interconnect has a wide > variety of security issues that should be considered in documents > addressing both protocol and use case analyzes. >=20 >=20 > 8. IANA Considerations >=20 > This document creates no new requirements on IANA namespaces > [RFC2434]. >=20 >=20 > 9. References >=20 > 9.1. Normative References >=20 > [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) > Part Four: The Uniform Resource Identifiers (URI)", > RFC 3404, October 2002. >=20 > [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform > Resource Identifiers (URI) Dynamic Delegation Discovery > System (DDDS) Application (ENUM)", RFC 3761, April 2004. >=20 > [ITU.E164.1991] > International Telecommunications Union, "The International > Public Telecommunication Numbering Plan", ITU- > T Recommendation E.164, 1991. >=20 > [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", > RFC 3966, December 2004. >=20 > 9.2. Informative References >=20 > [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 > (BGP-4)", RFC 1771, March 1995. >=20 > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an >=20 >=20 >=20 > Meyer Expires April 24, 2006 [Page 8] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > IANA Considerations Section in RFCs", BCP 26, RFC 2434, > October 1998. >=20 > [RFC2826] Internet Architecture Board, "IAB Technical Comment on the > Unique DNS Root", RFC 2826, May 2000. >=20 > [I-D.lind-infrastructure-enum-reqs] > Lind, S., "Infrastructure ENUM Requirements", > draft-lind-infrastructure-enum-reqs-00 (work in progress), > July 2005. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 24, 2006 [Page 9] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > Author's Address >=20 > David Meyer >=20 > Email: dmm@1-4-5.net >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 24, 2006 [Page 10] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > Intellectual Property Statement >=20 > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. >=20 > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. >=20 > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. >=20 >=20 > Disclaimer of Validity >=20 > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. >=20 >=20 > Copyright Statement >=20 > Copyright (C) The Internet Society (2005). This document is subject > to the rights, licenses and restrictions contained in BCP 78, and > except as set forth therein, the authors retain all their rights. >=20 >=20 > Acknowledgment >=20 > Funding for the RFC Editor function is currently provided by the > Internet Society. >=20 >=20 >=20 >=20 > Meyer Expires April 24, 2006 [Page 11] >=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 24 04:39:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxrK-0007Fl-TP; Mon, 24 Oct 2005 04:39:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxrI-0007Em-Ts for enum@megatron.ietf.org; Mon, 24 Oct 2005 04:39:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25031 for ; Mon, 24 Oct 2005 04:38:54 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ETy40-0002L6-FD for enum@ietf.org; Mon, 24 Oct 2005 04:52:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Oct 2005 10:42:43 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B21D7@oefeg-s04.oefeg.loc> Thread-Topic: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXVtvc4gaJjZdnpQcC8u6eUhPOdqgCv4sbQ From: "Stastny Richard" To: "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 47d6e33caab9a47557c20591160ac87c Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Dave, I minor comment to Figure 1 In the ENUM scope, E.164 number <--- Peer Discovery | | <--- ENUM lookup of NAPTR in DNS | | | ENUM Working Group Scope I would add for clarification E.164 number <--- Peer Discovery | | <--- ENUM lookup of NAPTR in DNS to retrieve Call Routing Data (CRD) e.g. a SIP URI | | | ENUM Working Group Scope Cheers Richard > -----Original Message----- > From: owner-voipeer@lists.uoregon.edu [mailto:owner- > voipeer@lists.uoregon.edu] On Behalf Of David Meyer > Sent: Thursday, October 20, 2005 10:22 PM > To: voipeer@lists.uoregon.edu > Cc: enum@ietf.org > Subject: [voipeer] draft-meyer-voipeer-terminology-03.txt >=20 > Folks, >=20 > Here's the latest on this one (posted here as I'm not > sure what the secretariat's posting rate is these > days). I've included all the comments, AFAICT. >=20 > There had been another suggestion to "harmonize" with > G.8080 terminology, which I am so far resisting > (comments on that)? >=20 >=20 > Thanks, >=20 > Dave >=20 > --- >=20 > Network Working Group D. Meyer > Internet-Draft October 20, 2005 > Expires: April 23, 2006 >=20 >=20 > Terminology for Describing VoIP Peering and Interconnect > draft-meyer-voipeer-terminology-03.txt >=20 > Status of this Memo >=20 > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. >=20 > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. >=20 > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. >=20 > This Internet-Draft will expire on April 23, 2006. >=20 > Copyright Notice >=20 > Copyright (C) The Internet Society (2005). >=20 > Abstract >=20 > This document defines the terminology that is to be used by the Voice > Over IP Peering and Interconnect Working Group (voipeer), and has as > its primary objective to focus the VOIPEER Working Group during its > discussions, and when writing requirements, gap analysis and other > solutions oriented documents. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 1] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 3. General Definitions . . . . . . . . . . . . . . . . . . . . . 4 > 3.1. Call Routing Data . . . . . . . . . . . . . . . . . . . . 4 > 3.2. Call Routing . . . . . . . . . . . . . . . . . . . . . . . 4 > 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.4. Network . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.5. VoIP Service Provider . . . . . . . . . . . . . . . . . . 5 > 3.6. Carrier . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.7. Peering . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . . . . . . 6 > 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . . . . . . 6 > 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . . . . . . 6 > 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 4.1. Carrier of Record . . . . . . . . . . . . . . . . . . . . 6 > 4.2. Public ENUM . . . . . . . . . . . . . . . . . . . . . . . 6 > 4.3. Private ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 > 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 > 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 > 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 > Intellectual Property and Copyright Statements . . . . . . . . . . 11 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 2] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > 1. Introduction >=20 > The term "VoIP Peering" has historically been used to describe a wide > variety of aspects pertaining to the interconnection of service > provider networks and to the delivery of SIP call termination over > those interconnections. The discussion of these interconnections has > at times been confused by the fact that the term "peering" is used in > various contexts to relate to interconnection at different levels in > a protocol stack. VoIP peering focuses on how to identify and route > calls at the application layer, and it does not (necessarily) involve > the exchange of packet routing data or media sessions. In > particular, "layer 5 network" is used here to refer to the > interconnection between SIP servers, as opposed to interconnection at > the IP layer ("layer 3"). Finally, the terms "peering" and > "interconnect" are used interchangeably throughout this document. >=20 > This document introduces standard terminology for use in > characterizing VoIP interconnection. Note however, that while this > document is primarily targeted at the VoIP interconnect case, the > terminology described here is applicable to those cases in which > service providers interconnect using SIP signaling for real-time or > quasi-real-time communications. >=20 > The remainder of this document is organized as follows: Section 2 > provides the general context for the VOIPEER Working Group, and > Section 3 provides the general definitions for real-time SIP based > communication, with focus on the VoIP interconnect case. Section 4 > briefly touches on terms from the ENUM Working Group. Finally, > Section 5 provides comments on usage. >=20 >=20 > 2. Context >=20 > Figure 1 depicts the general VoIP interconnect context. In this > case, the caller uses an E.164 number [ITU.E164.1991] as the "name" > of the called user. Note that this E.164 number is not an address, > since at this point we do not have information about where the named > endpoint is located. In the case shown here, an E.164 number is used > as a key to retrieve a NAPTR recored [RFC3404] from the DNS, which in > turn resolved into a SIP URI. Call routing is based on this SIP URI. > The call routing step does not depend on the presence of an E.164 > number; the SIP URI can be advertised in various other ways, such as > on a web page. Finally, note that the subsequent lookup steps, > namely, look up of SRV, A, and AAAA records (as well as any routing > steps below that) are outside the scope of VOIPEER. >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 3] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > E.164 number <--- Peer Discovery > | > | <--- ENUM lookup of NAPTR in DNS > | > | > | ENUM Working Group Scope > = =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | VOIPEER Working Group Scope > | > | > SIP URI <--- Call Routing Data (CRD) > | > | <--- Service Location (Lookup of SRV in DNS) > | > | > Hostname <--- VoIP addressing and session establishment > | > | <---- Lookup of A and AAAA in DNS > | > Ip address > | > | <---- Routing protocols, ARP etc > | > Mac-address >=20 > Figure 1: VoIP Interconnect Context >=20 > The ENUM Working Group is primarily concerned with the acquisition of > Call Routing Data, or CRD (i.e., above the double line in Figure 1), > while the VOIPEER Working Group is focused on the use of such CRD. > Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS > entry), or via any other mechanism available to the user. >=20 >=20 > 3. General Definitions >=20 > 3.1. Call Routing Data >=20 > Call Routing Data, or CRD, is a SIP URI used to route a call (real- > time, voice or other type) to the called domain's ingress point. A > domain's ingress point can be thought of as the location pointed to > by the SRV record that resulted from the resolution of the CRD (i.e., > a SIP URI). >=20 > 3.2. Call Routing >=20 > Call routing is the set of processes, rules, and CRD used to route a > VoIP call to its proper (SIP) destination. More generally, call >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 4] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > routing can be thought of as the set of processes, rules and CRD > which are used to route a real-time session to its termination > (ingress) point. >=20 > 3.3. PSTN >=20 > The term "PSTN" refers to the Public Switched Telephone Network. In > particular, the PSTN refers to the collection of interconnected > circuit-switched voice-oriented public telephone networks, both > commercial and government-owned. In general, PSTN terminals are > addressed using E.164 numbers, noting that various dial-plans (such > as emergency services dial-plans) may not directly use E.164 numbers. >=20 > 3.4. Network >=20 > For purposes of this document and the VOIPEER and ENUM Working > Groups, a network is defined to be the set of SIP servers and end- > users (customers) that are controlled by a single administrative > domain. The network may also contain end-users who are located on > the PSTN. >=20 > 3.5. VoIP Service Provider >=20 > A VoIP service provider is an entity that provides transport of SIP > signaling (and possibly media streams) to its customers. Such a > service provider may additionally be interconnected with other > service providers; that is, it may "peer" with other service > providers. A VoIP service provider may also interconnect with the > PSTN. >=20 > Note that as soon as a ingress point is advertised via a SRV record, > anyone can find that ingress point and hence can send calls there. > This is very similar to sending mail to a SMTP server based on the > existence of a MX record. >=20 > 3.6. Carrier >=20 > The term carrier is defined to be a service provider authorized to > issue E.164 numbers [ITU.E164.1991] for the provisioning of PSTN > service under the authority of a National Regulatory Authority (NRA). >=20 > 3.7. Peering >=20 > While the precise definition of the term "peering" is the subject of > some debate, peering in general refers to the negotiation of > reciprocal interconnection arrangements, settlement-free or > otherwise, between operationally independent service providers. >=20 >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 5] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > This document distinguishes two types of peering, Layer 3 Peering and > Layer 5 peering, which are described below. >=20 > 3.7.1. Layer 3 Peering >=20 > Layer 3 peering refers to interconnection of two service providers > for the purposes of exchanging IP packets. Layer 3 peering is > generally agnostic to the IP payload, and is frequently achieved > using a routing protocol such as BGP [RFC1771] to exchange the > required routing information. >=20 > 3.7.2. Layer 5 Peering >=20 > Layer 5 peering refers to interconnection of two service providers > for the purposes of SIP signaling. Note that in the layer 5 peering > case, there is no intervening network. That is, for purposes of this > discussion, there is no such thing as a "Layer 5 Transit Network". >=20 > 3.8. VoIP Peering >=20 > VoIP peering is defined to be a layer 5 peering between two VoIP > providers for purposes of routing real-time (or quasi-real time) call > signaling between their respective customers. Media streams > associated with this signaling (if any) are not constrained to follow > the same set of paths. >=20 >=20 > 4. ENUM >=20 > ENUM [RFC3761] defines how the Domain Name System (DNS) can be used > for identifying available services connected to one E.164 number. >=20 > 4.1. Carrier of Record >=20 > For purposes of this document, "Carrier of Record", or COR, refers to > the entity that provides PSTN service for an E.164 number [I-D.lind- > infrastructure-enum-reqs]. The exact definition of who and what is a > COR is ultimately the responsibility of the relevant national > authority. >=20 > 4.2. Public ENUM >=20 > Public ENUM is generally defined as the set administrative policies > and procedures surrounding the use of the e164.arpa domain for > Telephone Number to URI resolution [RFC3966]. Policies and > procedures for the registration of telephone numbers within all > branches of the e164.arpa tree are Nation State issues by agreement > with the IAB and ITU. National Regulatory Authorities have generally >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 6] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > defined Public ENUM Registrants as the E.164 number holder as opposed > to the COR that issued the phone number. >=20 > 4.3. Private ENUM >=20 > Private ENUM is generally regarded as one or more technologies > (including DNS and SIP Redirect) that service providers or > enterprises may use to exchange phone number to URI mappings in a > private secure manner. Private ENUM may be used in any mutually > agreed upon domain. Records in Private ENUM may be globally visible > but in most cases are not visible to the global Internet and are > protected using a variety of security technologies such as split-DNS, > VPN's or various forms or authentication and authorization. > Technical comments on issues surrounding split-DNS can be found in > [RFC2826]. >=20 > 4.4. Carrier ENUM >=20 > Carrier ENUM is generally regarded as the use of a separate branch > the e164.arpa tree, such as 4.4.c.e164.arpa to permit service > providers to exchange phone number to URI data in order to find > points of interconnection. The current theory of Carrier ENUM is > that only the COR for a particular E.164 number is permitted to > provision data for that E.164 within that portion of the e164.arpa > tree. >=20 > In carrier ENUM case, only the COR may enter data in the > corresponding domain. The COR may also enter CRD (i.e., a SIP URI) > to allow other VoIP Service Providers to route calls to its network. >=20 > Finally, note that ENUM is not constrained to carry only data (CDR) > as defined by VOIPEER. In particular, an an important class of CRD, > the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are > most frequently used to interconnect with the PSTN directly, and are > out of scope for VOIPEER. On the other hand, PSTN endpoints served > by a COR and reachable via CDR and networks as defined in Section 3.1 > and Section 3.4 are in scope for VOIPEER. >=20 >=20 > 5. Conclusions >=20 >=20 > 6. Acknowledgments >=20 > Many of the definitions were gleaned from detailed discussions on the > VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer, > Jean-Francois Mule, Richard Shocky, and Richard Stastny made valuable > contributions to early revisions of this document. Patrik Faltstrom >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 7] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > also made many insightful comments to early versions of this draft, > and contributed the basis of Figure 1. >=20 >=20 > 7. Security Considerations >=20 > This document itself introduces no new security considerations. > However, it is important to note that VoIP interconnect has a wide > variety of security issues that should be considered in documents > addressing both protocol and use case analyzes. >=20 >=20 > 8. IANA Considerations >=20 > This document creates no new requirements on IANA namespaces > [RFC2434]. >=20 >=20 > 9. References >=20 > 9.1. Normative References >=20 > [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) > Part Four: The Uniform Resource Identifiers (URI)", > RFC 3404, October 2002. >=20 > [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform > Resource Identifiers (URI) Dynamic Delegation Discovery > System (DDDS) Application (ENUM)", RFC 3761, April 2004. >=20 > [ITU.E164.1991] > International Telecommunications Union, "The International > Public Telecommunication Numbering Plan", ITU- > T Recommendation E.164, 1991. >=20 > [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", > RFC 3966, December 2004. >=20 > 9.2. Informative References >=20 > [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 > (BGP-4)", RFC 1771, March 1995. >=20 > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an > IANA Considerations Section in RFCs", BCP 26, RFC 2434, > October 1998. >=20 > [RFC2826] Internet Architecture Board, "IAB Technical Comment on the >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 8] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > Unique DNS Root", RFC 2826, May 2000. >=20 > [I-D.lind-infrastructure-enum-reqs] > Lind, S., "Infrastructure ENUM Requirements", > draft-lind-infrastructure-enum-reqs-00 (work in progress), > July 2005. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 9] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > Author's Address >=20 > David Meyer >=20 > Email: dmm@1-4-5.net >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 10] >=20 >=20 > Internet-Draft Terminology for Describing VoIP Peering October 2005 >=20 >=20 > Intellectual Property Statement >=20 > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. >=20 > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. >=20 > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. >=20 >=20 > Disclaimer of Validity >=20 > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. >=20 >=20 > Copyright Statement >=20 > Copyright (C) The Internet Society (2005). This document is subject > to the rights, licenses and restrictions contained in BCP 78, and > except as set forth therein, the authors retain all their rights. >=20 >=20 > Acknowledgment >=20 > Funding for the RFC Editor function is currently provided by the > Internet Society. >=20 >=20 >=20 >=20 > Meyer Expires April 23, 2006 [Page 11] >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 24 05:48:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETyw8-0007sF-Md; Mon, 24 Oct 2005 05:48:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETyw4-0007qP-Md for enum@megatron.ietf.org; Mon, 24 Oct 2005 05:48:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27856 for ; Mon, 24 Oct 2005 05:47:52 -0400 (EDT) Received: from philipp.labs.nic.at ([83.136.32.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETz8j-0004PD-Lb for enum@ietf.org; Mon, 24 Oct 2005 06:01:15 -0400 Received: from nat.labs.nic.at ([83.136.33.3] helo=[10.10.0.50]) by philipp.labs.nic.at with esmtp (Exim 3.36 #1 (Debian)) id 1ETyvS-000221-00; Mon, 24 Oct 2005 11:47:30 +0200 Message-ID: <435CADB9.10805@pernau.at> Date: Mon, 24 Oct 2005 11:47:37 +0200 From: Klaus Darilion User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" References: <435A5ED5.8070100@shockey.us> In-Reply-To: <435A5ED5.8070100@shockey.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] comments on draft-sajitha-enum-api-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi! Some comments to this draft: The API is very simple and thus easy to use in simple applications. But IMO the API is too simple. Consider the case of an universal messaging application which supports voice (sip,h323,iax), email, fax and sms. Then it will be useful to retrieve all supported service types and ask the user which service it would like to use. Using this API you would have to call geturiinfo() several times for each service type suported by the application (which probably ends up with multiple DNS lookups). I would suggest a more flexible API which seperates the ENUM lookup into smaller pieces. eg.: int get_enum(const char *telephonenum, int enumhandle); This makes the DNS lookup and stores the NAPTRs somewehere ... get_servicetypes(int enumhandle); returns the supported servicetypes (a pointer to a list of strings or something simmilar) int get_uri(int enumhandle, char *service_type, struct uriinfo **res); get the URI for a certain service type void free_enum(int enumhandle); free the ENUM resources regards klaus Richard Shockey wrote: > > > -------- Original Message -------- > Subject: I-D ACTION:draft-sajitha-enum-api-00.txt > Date: Fri, 21 Oct 2005 15:50:01 -0400 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : An ENUM Library API > Author(s) : T. Sajitha > Filename : draft-sajitha-enum-api-00.txt > Pages : 7 > Date : 2005-10-21 > > This draft defines a library API for ENUM. The API takes telephone > number as input and returns the URI associated with that telephone > number. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sajitha-enum-api-00.txt _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 24 09:13:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU28m-0006cY-Uo; Mon, 24 Oct 2005 09:13:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU28l-0006ZE-8u for enum@megatron.ietf.org; Mon, 24 Oct 2005 09:13:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08963 for ; Mon, 24 Oct 2005 09:13:12 -0400 (EDT) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU2LQ-0003Ad-FQ for enum@ietf.org; Mon, 24 Oct 2005 09:26:38 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id B6D991A371; Mon, 24 Oct 2005 15:12:57 +0200 (CEST) Date: Mon, 24 Oct 2005 15:12:57 +0200 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt] Message-ID: <20051024131257.GA14425@nic.at> References: <435A5ED5.8070100@shockey.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <435A5ED5.8070100@shockey.us> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sajitha-enum-api-00.txt This API misses one rather critical aspect for production system ENUM deployment: Configurable timeouts. Misconfigured ENUM delegations/nameservers can lead to significant delays before the resolver program gives up. It should thus be possible to tell the ENUM resolver API to give up after x seconds. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 24 10:55:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3jf-000387-Jv; Mon, 24 Oct 2005 10:55:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3jd-00037w-EN for enum@megatron.ietf.org; Mon, 24 Oct 2005 10:55:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13868 for ; Mon, 24 Oct 2005 10:55:22 -0400 (EDT) Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU3wM-0006R8-IN for enum@ietf.org; Mon, 24 Oct 2005 11:08:48 -0400 Received: from ([10.20.9.172]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.14448740; Mon, 24 Oct 2005 10:55:05 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Oct 2005 10:55:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Date: Mon, 24 Oct 2005 10:55:04 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A39757@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXWUcpZwcEkRbZxRX6zI5wPKYmZSwAAEU2QAIVcXnAAAY4r4AAOmtkw From: "Livingood, Jason" To: "Stastny Richard" , "James McEachern" , "Pfautz, Penn L, NEO" , "David Meyer" X-OriginalArrivalTime: 24 Oct 2005 14:55:06.0556 (UTC) FILETIME=[EC0297C0:01C5D8AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > Voipeer is dealing with routing between VoIP service=20 > providers using SIP URIs. So the definition of a VoIP Service=20 > provider is needed to be clear about is role in voipeer.=20 > Skype is a VoIP service provider if Skype is peering with=20 > other via SIP. Currently it is not. Nor are many other VoIP SPs are peering and that doesn't prevent their being considered VoIP SPs. For example, I'd submit that we can probably agree that Vonage is a VoIP SP but they do not peer with others via SIP. I think the reason we're all here is that there is little to no communications / voip peering taking place in practice today. Regards Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 24 11:00:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3oa-0004HY-LT; Mon, 24 Oct 2005 11:00:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3oY-0004HP-FX for enum@megatron.ietf.org; Mon, 24 Oct 2005 11:00:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14137 for ; Mon, 24 Oct 2005 11:00:27 -0400 (EDT) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU41J-0006aP-GH for enum@ietf.org; Mon, 24 Oct 2005 11:13:54 -0400 Received: from ([10.20.9.172]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.14364559; Mon, 24 Oct 2005 11:00:14 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Oct 2005 11:00:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Oct 2005 11:00:12 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A39758@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXWf4LfB4VXmBuOTZeQ7arD3GQMYQCJ5Xeg From: "Livingood, Jason" To: "David Meyer" , "Henry Sinnreich" X-OriginalArrivalTime: 24 Oct 2005 15:00:13.0433 (UTC) FILETIME=[A2EC4E90:01C5D8AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu, "Pfautz, Penn L, NEO" , "Michael Hammer \(mhammer\)" Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > > Hint: The carrier definition is hopeless. "The Internet Is The=20 > > Service" (Jon > > Peterson) and voice is an application IMHO. Let's go back to the=20 > > layers in the I-D. >=20 > Yep. There's no real value add in defining carrier > IMO. Best solution: remove the definition of carrier.=20 >=20 > Dave Sounds fine. But if we did have to include something like this in the future, I suggest discarding the term 'carrier' completely as a quaint, outdated, and baggage-laden term. ;-) (no flames please, I am half-joking, half-serious) I might suggest, as I did before on the list, something very broad and inclusive such as Real-Time Communications Service Provider (RTCSP). This could encompass folks ranging from SBC and Verizon, to Skype, FWD and Vonage, to Vodafone and Telefonica. But I am not sure we need to concern ourselves with this for now based on recent discussion here. On a related definition, I think the definition of VoIP Service Provider in the I-D is fine. However, in the future, we should consider including a definition of a SP that offers more than Voice. Perhaps we are unnecessarily constraining our work by defining the group as "Voice" over IP peering, as many apps will begin to evolve such that voice is but one component of the real-time communications stream between two or more users. This could voice along with IM/chat and video, looking at apps available today. Then again, there is something to be said for constraining the boundaries of the problem we are trying to solve. If we can solve the peering problem for VoIP we can move on and broaden the definitions and the problem scope later. Regards, Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 24 11:41:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4Rj-0007av-5Z; Mon, 24 Oct 2005 11:41:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4Re-0007ak-St for enum@megatron.ietf.org; Mon, 24 Oct 2005 11:41:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16025 for ; Mon, 24 Oct 2005 11:40:54 -0400 (EDT) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU4eQ-0007rI-FA for enum@ietf.org; Mon, 24 Oct 2005 11:54:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] [Fwd: I-D ACTION:draft-guy-enumiax-00.txt] Date: Mon, 24 Oct 2005 11:39:42 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3975D@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] [Fwd: I-D ACTION:draft-guy-enumiax-00.txt] Thread-Index: AcXVvFMMlxlcSoVlQryos52d28P1XAC88gkw From: "Livingood, Jason" To: , X-OriginalArrivalTime: 24 Oct 2005 15:39:44.0375 (UTC) FILETIME=[281D5870:01C5D8B1] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > Title : IANA Registration for IAX Enumservice > Author(s) : E. Guy > Filename : draft-guy-enumiax-00.txt > Pages : 11 > Date : 2005-10-20 > =09 > This document registers the IAX2 Enumservice using the URI scheme > 'iax2:' as per the IANA registration process defined in the ENUM > specification RFC3761. I like the format - easy to follow. One minor comment. You may want to break up section 4 (examples) into sub-sections, since you list multiple examples. This may make it easier for readers to differentiate between each discrete example, and make it easier for you to expand the section in the future. Regards Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 24 11:49:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4Ze-0002HR-Gq; Mon, 24 Oct 2005 11:49:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4Zc-0002G4-GP for enum@megatron.ietf.org; Mon, 24 Oct 2005 11:49:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16600 for ; Mon, 24 Oct 2005 11:49:07 -0400 (EDT) Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU4mN-0008A4-Q3 for enum@ietf.org; Mon, 24 Oct 2005 12:02:33 -0400 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.14451881; Mon, 24 Oct 2005 11:48:52 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Oct 2005 11:48:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt Date: Mon, 24 Oct 2005 11:48:51 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3975E@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt Thread-Index: AcXWU+B8oHe/eLs9R0W9viMm8yBp0QCXaQPA From: "Livingood, Jason" To: , , , X-OriginalArrivalTime: 24 Oct 2005 15:48:52.0307 (UTC) FILETIME=[6EB52230:01C5D8B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > Title : IANA Registration for Enumservice VOID > Author(s) : R. Stastny, et al. > Filename : draft-ietf-enum-void-02.txt > Pages : 19 > Date : 2005-10-21 I know this draft has been around for awhile so excuse me if I inadvertently bring up a question that may have been discussed previously. Is there any reason the draft could not also include subtypes for SIP and tel URIs? Regards Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 24 20:21:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUCZB-0005p2-9k; Mon, 24 Oct 2005 20:21:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUCZ8-0005or-M4 for enum@megatron.ietf.org; Mon, 24 Oct 2005 20:21:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07219 for ; Mon, 24 Oct 2005 20:21:08 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUCly-0007LP-0P for enum@ietf.org; Mon, 24 Oct 2005 20:34:39 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9P0Kt628949; Mon, 24 Oct 2005 20:20:55 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Date: Mon, 24 Oct 2005 20:20:52 -0400 Message-ID: Thread-Topic: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXWf4LfB4VXmBuOTZeQ7arD3GQMYQCJ5XegABEHvYA= From: "James McEachern" To: "Livingood, Jason" , "David Meyer" , "Henry Sinnreich" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu, "Pfautz, Penn L, NEO" , "Michael Hammer \(mhammer\)" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jason, I think your idea of not constraining the group to "Voice" over IP = peering is worth considering. =20 In practice it appears that we are all agreed to limiting ourselves to = SIP as the signaling mechanism for voice. If we were to change the = focus to "Peering for SIP services (or applications) including, but not = limited to, voice" would it really complicate things that much? It = might actually provide some useful focus, and get us away from these red = herring discussions around legacy voice. =20 Just a thought. Jim -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = Livingood, Jason Sent: Monday, October 24, 2005 11:00 AM To: David Meyer; Henry Sinnreich Cc: enum@ietf.org; voipeer@lists.uoregon.edu; Pfautz, Penn L,NEO; = Michael Hammer (mhammer) Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt > > Hint: The carrier definition is hopeless. "The Internet Is The=20 > > Service" (Jon > > Peterson) and voice is an application IMHO. Let's go back to the=20 > > layers in the I-D. >=20 > Yep. There's no real value add in defining carrier > IMO. Best solution: remove the definition of carrier.=20 >=20 > Dave Sounds fine. But if we did have to include something like this in the future, I suggest discarding the term 'carrier' completely as a quaint, outdated, and baggage-laden term. ;-) (no flames please, I am half-joking, half-serious) I might suggest, as I did before on the list, something very broad and inclusive such as Real-Time Communications Service Provider (RTCSP). This could encompass folks ranging from SBC and Verizon, to Skype, FWD and Vonage, to Vodafone and Telefonica. But I am not sure we need to concern ourselves with this for now based on recent discussion here. On a related definition, I think the definition of VoIP Service Provider in the I-D is fine. However, in the future, we should consider including a definition of a SP that offers more than Voice. Perhaps we are unnecessarily constraining our work by defining the group as "Voice" over IP peering, as many apps will begin to evolve such that voice is but one component of the real-time communications stream between two or more users. This could voice along with IM/chat and video, looking at apps available today. Then again, there is something to be said for constraining the boundaries of the problem we are trying to solve. If we can solve the peering problem for VoIP we can move on and broaden the definitions and the problem scope later. Regards, Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 24 20:21:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUCZQ-00062S-SU; Mon, 24 Oct 2005 20:21:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUCZP-00062K-5I for enum@megatron.ietf.org; Mon, 24 Oct 2005 20:21:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07224 for ; Mon, 24 Oct 2005 20:21:25 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUCmF-0007MD-6b for enum@ietf.org; Mon, 24 Oct 2005 20:34:56 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9P0LKe01521; Mon, 24 Oct 2005 20:21:20 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Date: Mon, 24 Oct 2005 20:21:05 -0400 Message-ID: Thread-Topic: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXVtvc4gaJjZdnpQcC8u6eUhPOdqgCv4sbQABffmfA= From: "James McEachern" To: "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Dave, I have one additional question on figure 1 of the voipeer terminology = draft. =20 The paragraph immediately before the figure states that: Finally, note that the subsequent lookup steps, namely, lookup of SRV, A, and AAAA records (as well as any routing steps below that) are outside the scope of VOIPEER. This suggests that in addition to drawing the boundary between ENUM and = VOIPEER WGs, we should also draw the boundary between VOIPEER WG and = other WGs. This suggests something like the following changes to the = diagram to align with the text in the draft: E.164 number <--- Peer Discovery | | <--- ENUM lookup of NAPTR in DNS | | | ENUM Working Group Scope = =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | VOIPEER Working Group Scope | | SIP URI <--- Call Routing Data (CRD) = =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | Out of scope for VOIPEER Working Group | | <--- Service Location (Lookup of SRV in DNS) | | Hostname <--- VoIP addressing and session establishment | | <---- Lookup of A and AAAA in DNS | Ip address | | <---- Routing protocols, ARP etc | Mac-address Figure 1: VoIP Interconnect Context =20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 24 20:22:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUCZx-00065Z-CX; Mon, 24 Oct 2005 20:22:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUCZv-00064w-Gi for enum@megatron.ietf.org; Mon, 24 Oct 2005 20:22:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07229 for ; Mon, 24 Oct 2005 20:21:57 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUCmm-0007Mu-JC for enum@ietf.org; Mon, 24 Oct 2005 20:35:28 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9P0Lq629006; Mon, 24 Oct 2005 20:21:52 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Date: Mon, 24 Oct 2005 20:21:35 -0400 Message-ID: Thread-Topic: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXWUcpZwcEkRbZxRX6zI5wPKYmZSwAAEU2QAIVcXnAADQ/04AAOUb9w From: "James McEachern" To: , "Pfautz, Penn L, NEO" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >Henry Sinnreich wrote:=20 > >Conclusion: VoIP peering makes little sense, but application peering >probably does. If voice is simply an application, aren't VoIP peering and Application = peering the same thing? =20 Jim _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 25 04:39:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUKLH-0005ij-KK; Tue, 25 Oct 2005 04:39:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU2Zj-0005yS-1l for enum@megatron.ietf.org; Mon, 24 Oct 2005 09:41:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10244 for ; Mon, 24 Oct 2005 09:41:04 -0400 (EDT) Message-Id: <200510241341.JAA10244@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU2mR-00044E-Om for enum@ietf.org; Mon, 24 Oct 2005 09:54:29 -0400 Received: (qmail 9926 invoked by uid 510); 24 Oct 2005 09:56:10 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.136.53):. Processed in 1.451361 secs); 24 Oct 2005 13:56:10 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.136.53):. Processed in 1.451361 secs Process 9921) Received: from c-24-1-136-53.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.136.53) by 192.246.69.184 with SMTP; Mon, 24 Oct 2005 13:56:08 +0000 From: "Henry Sinnreich" To: "'James McEachern'" , "'Pfautz, Penn L, NEO'" , "'David Meyer'" Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Date: Mon, 24 Oct 2005 08:41:08 -0500 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcXWUcpZwcEkRbZxRX6zI5wPKYmZSwAAEU2QAIVcXnAADQ/04A== X-Antivirus-MYDOMAIN-Message-ID: <11301621698359921@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ea58f9afed4c81098229b1759fb296b Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 25 Oct 2005 04:39:34 -0400 Cc: enum@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Maybe the whole notion of "VoIP Service Provider" and "VoIP Peering" stems from historic thinking when voice was the main source of revenue for what used to be called the carriers. Since VoIP is really becoming an often free application that may or may not be hosted (when P2P) by an _"Application Service Provider"_ like the IM ASPs Yahoo, Google, Skype, MSN, AOL, one cannot help thinking: - VoIP peering makes little sense (and even less money), - SIP application interaction is what makes sense. Like the integration of an application (advertising?) with communications (click to call?). Or any Health Care app (this is homework for you all)... Now we are talking $Bs from real application interaction. Though this is not a protocol fact, Google has roughly the same market valuation as has Verizon and health care outfits are much bigger. Conclusion: VoIP peering makes little sense, but application peering probably does. Ready for the flames! :-) Thanks, Henry -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of James McEachern Sent: Monday, October 24, 2005 2:10 AM To: Pfautz, Penn L, NEO; David Meyer Cc: enum@ietf.org; voipeer@lists.uoregon.edu Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt The discussion about the definition of a carrier makes me wonder what is the important aspect of being a carrier (or not) that we are trying to get at here. Usually, when we develop a technical (or legal/regulatory) definition for a term (say "foo") it is because some action will be required, or precluded, based on whether or not an entity satisfies the definition of "foo". Because of this, the definition of "foo" is often tuned to ensure we achieve the desired discrimination between entities that are a member of "foo" and those that are not. Unfortunately, in this context, I do not understand what subsequent decision will depend on whether or not an entity qualifies as a carrier. (If no subsequent decisions depend on being a carrier, then any definition will do.) Can anyone explain what will be allowed, or precluded if an entity is deemed to be a carrier by this group? Once we all agree on that, the correct definition may be clearer. Concerning Henry's comment about Skype, as I read the definitions, it would appear that Skype may well be a carrier - at least for Skype In/Out. I also suspect Skype could be the carrier of record for Skype In numbers. Interestingly, I believe the current definitions suggest that Skype is *not* a VoIP Service provider, since (as I understand) it does not generally use SIP for its service (or application). This does seem somewhat counter intuitive. Jim -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Pfautz, Penn L, NEO Sent: Friday, October 21, 2005 11:16 AM To: David Meyer Cc: enum@ietf.org; voipeer@lists.uoregon.edu Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt OK with just a couple typos below Penn -----Original Message----- From: David Meyer [mailto:dmm@1-4-5.net] Sent: Friday, October 21, 2005 11:12 AM To: Pfautz, Penn L, NEO Cc: voipeer@lists.uoregon.edu; enum@ietf.org Subject: Re: [voipeer] draft-meyer-voipeer-terminology-03.txt On Fri, Oct 21, 2005 at 09:51:17AM -0400, Pfautz, Penn L, NEO wrote: > Dave: > This is a nice start (indeed more than a start). I just have two > comments at this point: > > 1. The definition of carrier in 3.6 is probably too restrictive. I > would not make it contingent on issuance of E.164 numbers but rather > just the provision of PSTN service. I appreciate your use our > carrier-of-record definition in 4.1. How about: 3.6. Carrier A carrier is defined to be a service provider authorized to provision PSTN services. Note that the provision of such services is usually coupled with the authority to issue E.164 numbers [ITU.E164.1991] under the authority of a National Regulatory Authority (NRA). > 2. In reference to Layer 3 Peering (Section 3.7.1) I would like to see > included the concepts that a) peering involves delivery of packets that > terminate on the peer's network and b) peering is done without traffic > settlement charges. I'm ok with a) termination of traffic, but I'd like to avoid discussing SFI more than I have (see section 3.7). So how about: 3.7.1. Layer 3 Peering Layer 3 peering refers to interconnection of two service providers for the purposes of exchanging IP packets which destined for one (or both) of the peer's networks. Layer 3 peering is generally agnostic to the IP payload, and is frequently achieved using a routing protocol such as BGP [RFC1771] to exchange the required routing information. An alternate, perhaps more operational definition of layer 3 peering is that two peers exchange their customer router (only), and hence ^ any traffic between peers terminates on one of the peer's network. ^^^^^^^^ Dave --- Network Working Group D. Meyer Internet-Draft October 21, 2005 Expires: April 24, 2006 Terminology for Describing VoIP Peering and Interconnect draft-meyer-voipeer-terminology-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 24, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines the terminology that is to be used by the Voice Over IP Peering and Interconnect Working Group (voipeer), and has as its primary objective to focus the VOIPEER Working Group during its discussions, and when writing requirements, gap analysis and other solutions oriented documents. Meyer Expires April 24, 2006 [Page 1] Internet-Draft Terminology for Describing VoIP Peering October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. General Definitions . . . . . . . . . . . . . . . . . . . . . 4 3.1. Call Routing Data . . . . . . . . . . . . . . . . . . . . 4 3.2. Call Routing . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Network . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5. VoIP Service Provider . . . . . . . . . . . . . . . . . . 5 3.6. Carrier . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7. Peering . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7.1. Layer 3 Peering . . . . . . . . . . . . . . . . . . . 6 3.7.2. Layer 5 Peering . . . . . . . . . . . . . . . . . . . 6 3.8. VoIP Peering . . . . . . . . . . . . . . . . . . . . . . . 6 4. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Carrier of Record . . . . . . . . . . . . . . . . . . . . 6 4.2. Public ENUM . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Private ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Carrier ENUM . . . . . . . . . . . . . . . . . . . . . . . 7 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Meyer Expires April 24, 2006 [Page 2] Internet-Draft Terminology for Describing VoIP Peering October 2005 1. Introduction The term "VoIP Peering" has historically been used to describe a wide variety of aspects pertaining to the interconnection of service provider networks and to the delivery of SIP call termination over those interconnections. The discussion of these interconnections has at times been confused by the fact that the term "peering" is used in various contexts to relate to interconnection at different levels in a protocol stack. VoIP peering focuses on how to identify and route calls at the application layer, and it does not (necessarily) involve the exchange of packet routing data or media sessions. In particular, "layer 5 network" is used here to refer to the interconnection between SIP servers, as opposed to interconnection at the IP layer ("layer 3"). Finally, the terms "peering" and "interconnect" are used interchangeably throughout this document. This document introduces standard terminology for use in characterizing VoIP interconnection. Note however, that while this document is primarily targeted at the VoIP interconnect case, the terminology described here is applicable to those cases in which service providers interconnect using SIP signaling for real-time or quasi-real-time communications. The remainder of this document is organized as follows: Section 2 provides the general context for the VOIPEER Working Group, and Section 3 provides the general definitions for real-time SIP based communication, with focus on the VoIP interconnect case. Section 4 briefly touches on terms from the ENUM Working Group. Finally, Section 5 provides comments on usage. 2. Context Figure 1 depicts the general VoIP interconnect context. In this case, the caller uses an E.164 number [ITU.E164.1991] as the "name" of the called user. Note that this E.164 number is not an address, since at this point we do not have information about where the named endpoint is located. In the case shown here, an E.164 number is used as a key to retrieve a NAPTR recored [RFC3404] from the DNS, which in turn resolved into a SIP URI. Call routing is based on this SIP URI. The call routing step does not depend on the presence of an E.164 number; the SIP URI can be advertised in various other ways, such as on a web page. Finally, note that the subsequent lookup steps, namely, lookup of SRV, A, and AAAA records (as well as any routing steps below that) are outside the scope of VOIPEER. Meyer Expires April 24, 2006 [Page 3] Internet-Draft Terminology for Describing VoIP Peering October 2005 E.164 number <--- Peer Discovery | | <--- ENUM lookup of NAPTR in DNS | | | ENUM Working Group Scope =====+======================================= | VOIPEER Working Group Scope | | SIP URI <--- Call Routing Data (CRD) | | <--- Service Location (Lookup of SRV in DNS) | | Hostname <--- VoIP addressing and session establishment | | <---- Lookup of A and AAAA in DNS | Ip address | | <---- Routing protocols, ARP etc | Mac-address Figure 1: VoIP Interconnect Context The ENUM Working Group is primarily concerned with the acquisition of Call Routing Data, or CRD (i.e., above the double line in Figure 1), while the VOIPEER Working Group is focused on the use of such CRD. Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS entry), or via any other mechanism available to the user. 3. General Definitions 3.1. Call Routing Data Call Routing Data, or CRD, is a SIP URI used to route a call (real- time, voice or other type) to the called domain's ingress point. A domain's ingress point can be thought of as the location pointed to by the SRV record that resulted from the resolution of the CRD (i.e., a SIP URI). 3.2. Call Routing Call routing is the set of processes, rules, and CRD used to route a VoIP call to its proper (SIP) destination. More generally, call Meyer Expires April 24, 2006 [Page 4] Internet-Draft Terminology for Describing VoIP Peering October 2005 routing can be thought of as the set of processes, rules and CRD which are used to route a real-time session to its termination (ingress) point. 3.3. PSTN The term "PSTN" refers to the Public Switched Telephone Network. In particular, the PSTN refers to the collection of interconnected circuit-switched voice-oriented public telephone networks, both commercial and government-owned. In general, PSTN terminals are addressed using E.164 numbers, noting that various dial-plans (such as emergency services dial-plans) may not directly use E.164 numbers. 3.4. Network For purposes of this document and the VOIPEER and ENUM Working Groups, a network is defined to be the set of SIP servers and end- users (customers) that are controlled by a single administrative domain. The network may also contain end-users who are located on the PSTN. 3.5. VoIP Service Provider A VoIP service provider is an entity that provides transport of SIP signaling (and possibly media streams) to its customers. Such a service provider may additionally be interconnected with other service providers; that is, it may "peer" with other service providers. A VoIP service provider may also interconnect with the PSTN. Note that as soon as a ingress point is advertised via a SRV record, anyone can find that ingress point and hence can send calls there. This is very similar to sending mail to a SMTP server based on the existence of a MX record. 3.6. Carrier A carrier is defined to be a service provider authorized to provision PSTN services. Note that the provision of such services is usually coupled with the authority to issue E.164 numbers [ITU.E164.1991] under the authority of a National Regulatory Authority (NRA). 3.7. Peering While the precise definition of the term "peering" is the subject of some debate, peering in general refers to the negotiation of reciprocal interconnection arrangements, settlement-free or otherwise, between operationally independent service providers. Meyer Expires April 24, 2006 [Page 5] Internet-Draft Terminology for Describing VoIP Peering October 2005 This document distinguishes two types of peering, Layer 3 Peering and Layer 5 peering, which are described below. 3.7.1. Layer 3 Peering Layer 3 peering refers to interconnection of two service providers for the purposes of exchanging IP packets which destined for one (or both) of the peer's networks. Layer 3 peering is generally agnostic to the IP payload, and is frequently achieved using a routing protocol such as BGP [RFC1771] to exchange the required routing information. An alternate, perhaps more operational definition of layer 3 peering is that two peers exchange their customer routers (only), and hence any traffic between peers terminates on on the peer's network. 3.7.2. Layer 5 Peering Layer 5 peering refers to interconnection of two service providers for the purposes of SIP signaling. Note that in the layer 5 peering case, there is no intervening network. That is, for purposes of this discussion, there is no such thing as a "Layer 5 Transit Network". 3.8. VoIP Peering VoIP peering is defined to be a layer 5 peering between two VoIP providers for purposes of routing real-time (or quasi-real time) call signaling between their respective customers. Media streams associated with this signaling (if any) are not constrained to follow the same set of paths. 4. ENUM ENUM [RFC3761] defines how the Domain Name System (DNS) can be used for identifying available services connected to one E.164 number. 4.1. Carrier of Record For purposes of this document, "Carrier of Record", or COR, refers to the entity that provides PSTN service for an E.164 number [I-D.lind- infrastructure-enum-reqs]. The exact definition of who and what is a COR is ultimately the responsibility of the relevant NRA. 4.2. Public ENUM Public ENUM is generally defined as the set administrative policies and procedures surrounding the use of the e164.arpa domain for Meyer Expires April 24, 2006 [Page 6] Internet-Draft Terminology for Describing VoIP Peering October 2005 Telephone Number to URI resolution [RFC3761]. Policies and procedures for the registration of telephone numbers within all branches of the e164.arpa tree are Nation State issues by agreement with the IAB and ITU. National Regulatory Authorities have generally defined Public ENUM Registrants as the E.164 number holder as opposed to the COR that issued the phone number. 4.3. Private ENUM Private ENUM is generally regarded as one or more technologies (including DNS and SIP Redirect) that service providers or enterprises may use to exchange phone number to URI mappings in a private secure manner. Private ENUM may be used in any mutually agreed upon domain. Records in Private ENUM may be globally visible but in most cases are not visible to the global Internet and are protected using a variety of security technologies such as split-DNS, VPN's or various forms or authentication and authorization. Technical comments on issues surrounding split-DNS can be found in [RFC2826]. 4.4. Carrier ENUM Carrier ENUM is generally regarded as the use of a separate branch the e164.arpa tree, such as 4.4.c.e164.arpa to permit service providers to exchange phone number to URI data in order to find points of interconnection. The current theory of Carrier ENUM is that only the COR for a particular E.164 number is permitted to provision data for that E.164 within that portion of the e164.arpa tree. In carrier ENUM case, only the COR may enter data in the corresponding domain. The COR may also enter CRD (i.e., a SIP URI) to allow other VoIP Service Providers to route calls to its network. Finally, note that ENUM is not constrained to carry only data (CDR) as defined by VOIPEER. In particular, an an important class of CRD, the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are most frequently used to interconnect with the PSTN directly, and are out of scope for VOIPEER. On the other hand, PSTN endpoints served by a COR and reachable via CDR and networks as defined in Section 3.1 and Section 3.4 are in scope for VOIPEER. 5. Conclusions 6. Acknowledgments Meyer Expires April 24, 2006 [Page 7] Internet-Draft Terminology for Describing VoIP Peering October 2005 Many of the definitions were gleaned from detailed discussions on the VOIPEER, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer, Jean-Francois Mule, Richard Shocky, and Richard Stastny made valuable contributions to early revisions of this document. Patrik Faltstrom also made many insightful comments to early versions of this draft, and contributed the basis of Figure 1. 7. Security Considerations This document itself introduces no new security considerations. However, it is important to note that VoIP interconnect has a wide variety of security issues that should be considered in documents addressing both protocol and use case analyzes. 8. IANA Considerations This document creates no new requirements on IANA namespaces [RFC2434]. 9. References 9.1. Normative References [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [ITU.E164.1991] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU- T Recommendation E.164, 1991. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. 9.2. Informative References [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an Meyer Expires April 24, 2006 [Page 8] Internet-Draft Terminology for Describing VoIP Peering October 2005 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000. [I-D.lind-infrastructure-enum-reqs] Lind, S., "Infrastructure ENUM Requirements", draft-lind-infrastructure-enum-reqs-00 (work in progress), July 2005. Meyer Expires April 24, 2006 [Page 9] Internet-Draft Terminology for Describing VoIP Peering October 2005 Author's Address David Meyer Email: dmm@1-4-5.net Meyer Expires April 24, 2006 [Page 10] Internet-Draft Terminology for Describing VoIP Peering October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Meyer Expires April 24, 2006 [Page 11] _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ____________________________________________________________________________ _ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 25 04:39:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUKLI-0005j8-Ac; Tue, 25 Oct 2005 04:39:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUDG5-00043S-GX for enum@megatron.ietf.org; Mon, 24 Oct 2005 21:05:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08793 for ; Mon, 24 Oct 2005 21:05:31 -0400 (EDT) Message-Id: <200510250105.VAA08793@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUDSu-0008FC-Gj for enum@ietf.org; Mon, 24 Oct 2005 21:19:02 -0400 Received: (qmail 14757 invoked by uid 510); 24 Oct 2005 21:20:42 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.136.53):. Processed in 1.304063 secs); 25 Oct 2005 01:20:42 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.136.53):. Processed in 1.304063 secs Process 14752) Received: from c-24-1-136-53.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.136.53) by 192.246.69.184 with SMTP; Tue, 25 Oct 2005 01:20:41 +0000 From: "Henry Sinnreich" To: "'Stephen Kingham'" , "'Livingood, Jason'" Date: Mon, 24 Oct 2005 20:05:32 -0500 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <435D6A44.7030401@aarnet.edu.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcXY8+1P3VjQWLSiTlOahcVefGgoFwAC4TBg X-Antivirus-MYDOMAIN-Message-ID: <113020324183514752@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 25 Oct 2005 04:39:34 -0400 Cc: voipeer@lists.uoregon.edu, enum@ietf.org, "'Pfautz, Penn L, NEO'" , "'Michael Hammer \(mhammer\)'" Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The term carrier is indeed loaded with meanings, for example: - AT&T, MCI, SBC, etc. are carriers for the FCC... - RTP and RTSP are carriers for media on the Internet. This is a great source of confusion and since we really speak of applications running on servers or in the endpoints, _applications_ they are indeed and SIP is defined as an application layer protocol anyway. Thanks, Henry -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Stephen Kingham Sent: Monday, October 24, 2005 6:12 PM To: Livingood, Jason Cc: David Meyer; Henry Sinnreich; Michael Hammer (mhammer); Pfautz, Penn L, NEO; voipeer@lists.uoregon.edu; enum@ietf.org Subject: Re: [voipeer] draft-meyer-voipeer-terminology-03.txt Hi Jason makes a good point about 'unnecessarily constraining our work by defining the group as "Voice"' only. Like SMS for Cellular Mobiles, we should keep in mind that the new technology includes other forms of communications. Jason you mention IM and Chat as possibilities and another is presence. I think Henry's Application peering is much the same as Jason's suggestions and a very good point, but voip peering is still important and is the underlying technology. Solve VoIP peering and we help solve the others, provided we keep them in mind that we are trying to solve more than just Voice? Well that is what I learn from Henry's and Jason's comments. The word "Carrier" does have considerable baggage which is encompassing (includes VoIP providers) and restricting at the same time (only including VoIP providers) all depending on the perspective of the reader. Carrier has a lot of ambiguity in this context but it is an easily recogniseable term. RTCSP seams to be another acronym that is as good as any other new acronym, seams okay ;-)! I think RTC and SP are widely recognizable, I would suggest a slight change to make it "RTC-SP", or at the extreme risk of including the work Carrier, what about "RTC Carrier". Stephen Livingood, Jason wrote: >>>Hint: The carrier definition is hopeless. "The Internet Is The >>>Service" (Jon >>>Peterson) and voice is an application IMHO. Let's go back to the >>>layers in the I-D. >>> >>> >> Yep. There's no real value add in defining carrier >> IMO. Best solution: remove the definition of carrier. >> >> Dave >> >> > >Sounds fine. But if we did have to include something like this in the >future, I suggest discarding the term 'carrier' completely as a quaint, >outdated, and baggage-laden term. ;-) (no flames please, I am >half-joking, half-serious) I might suggest, as I did before on the >list, something very broad and inclusive such as Real-Time >Communications Service Provider (RTCSP). This could encompass folks >ranging from SBC and Verizon, to Skype, FWD and Vonage, to Vodafone and >Telefonica. But I am not sure we need to concern ourselves with this >for now based on recent discussion here. > >On a related definition, I think the definition of VoIP Service Provider >in the I-D is fine. However, in the future, we should consider >including a definition of a SP that offers more than Voice. Perhaps we >are unnecessarily constraining our work by defining the group as "Voice" >over IP peering, as many apps will begin to evolve such that voice is >but one component of the real-time communications stream between two or >more users. This could voice along with IM/chat and video, looking at >apps available today. Then again, there is something to be said for >constraining the boundaries of the problem we are trying to solve. If >we can solve the peering problem for VoIP we can move on and broaden the >definitions and the problem scope later. > >Regards, >Jason > >___________________________________________________________________________ __ >List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > > -- Stephen Kingham, MIT, BSc, E&C Cert Project Manager and Consulting Engineer mailto:Stephen.Kingham@aarnet.edu.au Telephone +61 2 6222 3575 (office) +61 419 417 471 (mobile) sip:Stephen.Kingham@aarnet.edu.au Voice and Video over IP for The Australian Academic Research Network (AARNet) http://www.aarnet.edu.au ____________________________________________________________________________ _ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 25 04:39:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUKLI-0005jX-TL; Tue, 25 Oct 2005 04:39:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUDG5-00043R-GY for enum@megatron.ietf.org; Mon, 24 Oct 2005 21:05:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08791 for ; Mon, 24 Oct 2005 21:05:31 -0400 (EDT) Message-Id: <200510250105.VAA08791@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUDSu-0008FR-Gi for enum@ietf.org; Mon, 24 Oct 2005 21:19:02 -0400 Received: (qmail 14787 invoked by uid 510); 24 Oct 2005 21:20:46 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.136.53):. Processed in 0.964478 secs); 25 Oct 2005 01:20:46 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.136.53):. Processed in 0.964478 secs Process 14776) Received: from c-24-1-136-53.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.136.53) by 192.246.69.184 with SMTP; Tue, 25 Oct 2005 01:20:45 +0000 From: "Henry Sinnreich" To: "'James McEachern'" , "'Pfautz, Penn L, NEO'" , "'David Meyer'" Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Date: Mon, 24 Oct 2005 20:05:32 -0500 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcXWUcpZwcEkRbZxRX6zI5wPKYmZSwAAEU2QAIVcXnAADQ/04AAOUb9wAApq7SA= X-Antivirus-MYDOMAIN-Message-ID: <113020324583514776@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 25 Oct 2005 04:39:34 -0400 Cc: enum@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jim, >If voice is simply an application, aren't VoIP peering and >Application peering the same thing? I believe yes, at least for all SIP/SIMMPLE/SIPPING/XCON applications and for all those applications that understand the SIP Event Architecture - games for example. Thanks, Henry -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of James McEachern Sent: Monday, October 24, 2005 7:22 PM To: henry@pulver.com; Pfautz, Penn L, NEO; David Meyer Cc: enum@ietf.org; voipeer@lists.uoregon.edu Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt >Henry Sinnreich wrote: > >Conclusion: VoIP peering makes little sense, but application peering >probably does. If voice is simply an application, aren't VoIP peering and Application peering the same thing? Jim ____________________________________________________________________________ _ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 25 07:38:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUN8P-0007uD-4z; Tue, 25 Oct 2005 07:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUN8M-0007tz-OF for enum@megatron.ietf.org; Tue, 25 Oct 2005 07:38:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08439 for ; Tue, 25 Oct 2005 07:38:12 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUNLG-0007CQ-6i for enum@ietf.org; Tue, 25 Oct 2005 07:51:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt Date: Tue, 25 Oct 2005 13:41:43 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B21E0@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt Thread-Index: AcXWU+B8oHe/eLs9R0W9viMm8yBp0QCXaQPAACm/rfA= From: "Stastny Richard" To: "Livingood, Jason" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jason, I can remember we considered this, but left it to e-mail and web, and I personally consider even e-mail problematic, because There will be at least one client designer out there having had not enough coffee in the morning and program a client directly sending an e-mail during call set-up IMHO the best solution for an NRA is to point to a web-page where the NRA may list e-mail addresses or phone numbers for contact id something is wrong with the entry Richard > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, October 24, 2005 5:49 PM > To: enum@ietf.org; Stastny Richard; lwc@roke.co.uk; jim@dns-moda.org > Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt >=20 >=20 > > Title : IANA Registration for Enumservice VOID > > Author(s) : R. Stastny, et al. > > Filename : draft-ietf-enum-void-02.txt > > Pages : 19 > > Date : 2005-10-21 >=20 > I know this draft has been around for awhile so excuse me if I > inadvertently bring up a question that may have been discussed > previously. Is there any reason the draft could not also include > subtypes for SIP and tel URIs? >=20 > Regards > Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 25 09:42:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUP4S-00055E-Gl; Tue, 25 Oct 2005 09:42:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUP4Q-00054l-0o for enum@megatron.ietf.org; Tue, 25 Oct 2005 09:42:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17586 for ; Tue, 25 Oct 2005 09:42:15 -0400 (EDT) Received: from c2bthomr05.btconnect.com ([194.73.73.220] ident=mirapoint) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUPHK-00030R-Q9 for enum@ietf.org; Tue, 25 Oct 2005 09:55:54 -0400 Received: from RAY.bango.net ([62.254.208.140]) by C2bthomr05.btconnect.com (MOS 3.5.9-GR) with ESMTP id CKG91692 (AUTH randerson001); Tue, 25 Oct 2005 14:42:06 +0100 (BST) Message-Id: <7.0.0.8.2.20051025131031.02682218@bango.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.8 (Beta) Date: Tue, 25 Oct 2005 14:41:27 +0100 To: "Stastny Richard" , "Livingood, Jason" , , , From: Ray Anderson Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B21E0@oefeg-s04.oefeg.loc > References: <32755D354E6B65498C3BD9FD496C7D461B21E0@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org And make sure that the web page works on the more popular devices like phones, as well as on PC's (i.e. support WML, XHTML etc.) Ray At 12:41 25/10/2005, Stastny Richard wrote: >Jason, > >I can remember we considered this, but left it to e-mail and web, >and I personally consider even e-mail problematic, because >There will be at least one client designer out there having >had not enough coffee in the morning and program a client >directly sending an e-mail during call set-up > >IMHO the best solution for an NRA is to point to a web-page >where the NRA may list e-mail addresses or phone numbers for >contact id something is wrong with the entry > >Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 25 11:21:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQcM-0007br-Ti; Tue, 25 Oct 2005 11:21:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQcK-0007Ye-94 for enum@megatron.ietf.org; Tue, 25 Oct 2005 11:21:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29137 for ; Tue, 25 Oct 2005 11:21:21 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUQpF-0007tI-Tq for enum@ietf.org; Tue, 25 Oct 2005 11:35:01 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9PFL8bX021339; Tue, 25 Oct 2005 08:21:08 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9PFL24q021338; Tue, 25 Oct 2005 08:21:02 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 25 Oct 2005 08:21:02 -0700 From: David Meyer To: James McEachern Subject: Re: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Message-ID: <20051025152102.GA21317@1-4-5.net> References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: enum@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1032454865==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1032454865== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 24, 2005 at 08:21:05PM -0400, James McEachern wrote: > Dave, > I have one additional question on figure 1 of the voipeer terminology dra= ft. =20 >=20 > The paragraph immediately before the figure states that: >=20 > Finally, note that the subsequent lookup steps, > namely, lookup of SRV, A, and AAAA records (as well as any routing > steps below that) are outside the scope of VOIPEER. >=20 > This suggests that in addition to drawing the boundary between ENUM and V= OIPEER WGs, we should also draw the boundary between VOIPEER WG and other W= Gs. This suggests something like the following changes to the diagram to a= lign with the text in the draft: >=20 >=20 >=20 >=20 >=20 > E.164 number <--- Peer Discovery > | > | <--- ENUM lookup of NAPTR in DNS > | > | > | ENUM Working Group Scope > =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | VOIPEER Working Group Scope > | > | > SIP URI <--- Call Routing Data (CRD) > =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | Out of scope for VOIPEER Working Group > | > | <--- Service Location (Lookup of SRV in DNS) > | > | > Hostname <--- VoIP addressing and session establishment > | > | <---- Lookup of A and AAAA in DNS > | > Ip address > | > | <---- Routing protocols, ARP etc > | > Mac-address >=20 > Figure 1: VoIP Interconnect Context >=20 Yeah, I'd thought about doing that but at first look the picture was getting to complicated (as its utility is sort of inversely proportional to its complexity). In any event, I'll take a look at including the "lower bound". Dave --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDXk1eORgD1qCZ2KcRAk7NAJ4rwDfgpMvyXg36qYa72D+EVJAeTgCgioaW 5taG5is4rE4mkelINaCuZHU= =Jiuq -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- --===============1032454865== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1032454865==-- From enum-bounces@ietf.org Tue Oct 25 11:39:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQtD-0005X5-KY; Tue, 25 Oct 2005 11:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQtC-0005X0-FX for enum@megatron.ietf.org; Tue, 25 Oct 2005 11:39:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00193 for ; Tue, 25 Oct 2005 11:38:47 -0400 (EDT) Received: from bay103-f33.bay103.hotmail.com ([65.54.174.43] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUR6A-0008P2-5g for enum@ietf.org; Tue, 25 Oct 2005 11:52:27 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 25 Oct 2005 08:38:51 -0700 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Tue, 25 Oct 2005 15:38:49 GMT X-Originating-IP: [66.218.34.195] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <20051025152102.GA21317@1-4-5.net> From: "Peter Williams" Cc: enum@ietf.org Subject: Re: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Date: Tue, 25 Oct 2005 08:38:49 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Oct 2005 15:38:51.0118 (UTC) FILETIME=[32C8B8E0:01C5D97A] X-Spam-Score: 0.8 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This looks fine. We have the seperation of efforts, in some architecture, without arguing over the politics of everyones' charters. VIOPeer interacts with ENUM in the area of SIP URLs, particular concerning Carrier ENUM question. If Carrier ENUM has impacts upon ENUM in areas other than SIP URLs, they are handled within ENUM WG. Folks with interest in this area, perhaps to enforce the faith surrounding call routing data in URI theory for SIP proxy interworking, just join in the fun of ENUM WG. Now where can I find that IBM Germany paper from 10 years ago that stuck a proxy outreach network on the front of visanet, to make Internet commerce fit for mass adoption.... some history is repeating itself in VOIPeering and ENUM! >From: David Meyer >To: James McEachern >CC: enum@ietf.org, voipeer@lists.uoregon.edu >Subject: Re: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt >Date: Tue, 25 Oct 2005 08:21:02 -0700 > >On Mon, Oct 24, 2005 at 08:21:05PM -0400, James McEachern wrote: > > Dave, > > I have one additional question on figure 1 of the voipeer terminology >draft. > > > > The paragraph immediately before the figure states that: > > > > Finally, note that the subsequent lookup steps, > > namely, lookup of SRV, A, and AAAA records (as well as any routing > > steps below that) are outside the scope of VOIPEER. > > > > This suggests that in addition to drawing the boundary between ENUM and >VOIPEER WGs, we should also draw the boundary between VOIPEER WG and other >WGs. This suggests something like the following changes to the diagram to >align with the text in the draft: > > > > > > > > > > > > E.164 number <--- Peer Discovery > > | > > | <--- ENUM lookup of NAPTR in DNS > > | > > | > > | ENUM Working Group Scope > > =====+======================================= > > | VOIPEER Working Group Scope > > | > > | > > SIP URI <--- Call Routing Data (CRD) > > =====+======================================= > > | Out of scope for VOIPEER Working Group > > | > > | <--- Service Location (Lookup of SRV in DNS) > > | > > | > > Hostname <--- VoIP addressing and session establishment > > | > > | <---- Lookup of A and AAAA in DNS > > | > > Ip address > > | > > | <---- Routing protocols, ARP etc > > | > > Mac-address > > > > Figure 1: VoIP Interconnect Context > > > > Yeah, I'd thought about doing that but at first look the > picture was getting to complicated (as its utility is > sort of inversely proportional to its complexity). In any > event, I'll take a look at including the "lower bound". > > Dave ><< attach4 >> >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 25 14:14:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTK1-000261-Rz; Tue, 25 Oct 2005 14:14:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTK0-00023Y-7y for enum@megatron.ietf.org; Tue, 25 Oct 2005 14:14:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10106 for ; Tue, 25 Oct 2005 14:14:38 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUTWz-0004tM-Jq for enum@ietf.org; Tue, 25 Oct 2005 14:28:18 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Oct 2005 11:14:42 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,250,1125903600"; d="scan'208"; a="13863867:sNHT24211672" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9PIEN2H008287; Tue, 25 Oct 2005 14:14:39 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 14:14:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Date: Tue, 25 Oct 2005 14:14:36 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3B45B18@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXZeqMghOG44vonTH6u8rhlc89ErgAE5x1w From: "Michael Hammer \(mhammer\)" To: "Peter Williams" X-OriginalArrivalTime: 25 Oct 2005 18:14:38.0233 (UTC) FILETIME=[F6194890:01C5D98F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Peter et all, Trying to catch the tail of this thread... My original comments were simply not to use an overly restrictive definition of carrier tied to a term that implies *only* TDM networks. =20 E.164 can be used beyond TDM networks. =20 The term carrier may carry additional regulatory baggage over that of service provider. Henning raises the point that Skype can be a service, but may not want to admit being a service provider until they admit to having servers providing service. There may be regulatory implications then. SIP peering is broader than VoIP peering in that SIP can do more than voice. VoIP peering may be broader than SIP in that H.323 and Skype do VoIP too. Application peering goes beyond all the above, but does restrict it to being above transport layer. I don't see a need for flames as all these points are valid. Mike =20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Peter Williams > Sent: Tuesday, October 25, 2005 11:39 AM > Cc: enum@ietf.org > Subject: Re: [Enum] RE: [voipeer]=20 > draft-meyer-voipeer-terminology-03.txt >=20 > This looks fine. >=20 > We have the seperation of efforts, in some architecture,=20 > without arguing over the politics of everyones' charters. >=20 > VIOPeer interacts with ENUM in the area of SIP URLs,=20 > particular concerning Carrier ENUM question. If Carrier ENUM=20 > has impacts upon ENUM in areas other than SIP URLs, they are=20 > handled within ENUM WG. Folks with interest in this area,=20 > perhaps to enforce the faith surrounding call routing data in=20 > URI theory for SIP proxy interworking, just join in the fun=20 > of ENUM WG. >=20 > Now where can I find that IBM Germany paper from 10 years=20 > ago that stuck a proxy outreach network on the front of=20 > visanet, to make Internet commerce fit for mass adoption....=20 > some history is repeating itself in VOIPeering and ENUM! >=20 > >From: David Meyer > >To: James McEachern > >CC: enum@ietf.org, voipeer@lists.uoregon.edu > >Subject: Re: [Enum] RE: [voipeer]=20 > >draft-meyer-voipeer-terminology-03.txt > >Date: Tue, 25 Oct 2005 08:21:02 -0700 > > > >On Mon, Oct 24, 2005 at 08:21:05PM -0400, James McEachern wrote: > > > Dave, > > > I have one additional question on figure 1 of the voipeer=20 > > > terminology > >draft. > > > > > > The paragraph immediately before the figure states that: > > > > > > Finally, note that the subsequent lookup steps, > > > namely, lookup of SRV, A, and AAAA records (as well as=20 > any routing > > > steps below that) are outside the scope of VOIPEER. > > > > > > This suggests that in addition to drawing the boundary=20 > between ENUM=20 > > > and > >VOIPEER WGs, we should also draw the boundary between VOIPEER WG and=20 > >other WGs. This suggests something like the following=20 > changes to the=20 > >diagram to align with the text in the draft: > > > > > > > > > > > > > > > > > > E.164 number <--- Peer Discovery > > > | > > > | <--- ENUM lookup of NAPTR in DNS > > > | > > > | > > > | ENUM Working Group Scope > > > = =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > | VOIPEER Working Group Scope > > > | > > > | > > > SIP URI <--- Call Routing Data (CRD) > > > = =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > | Out of scope for VOIPEER Working Group > > > | > > > | <--- Service Location (Lookup of SRV in DNS) > > > | > > > | > > > Hostname <--- VoIP addressing and session establishment > > > | > > > | <---- Lookup of A and AAAA in DNS > > > | > > > Ip address > > > | > > > | <---- Routing protocols, ARP etc > > > | > > > Mac-address > > > > > > Figure 1: VoIP Interconnect Context > > > > > > > Yeah, I'd thought about doing that but at first look the > > picture was getting to complicated (as its utility is > > sort of inversely proportional to its complexity). In any > > event, I'll take a look at including the "lower bound". > > > > Dave >=20 >=20 > ><< attach4 >> >=20 >=20 >=20 >=20 > >_______________________________________________ > >enum mailing list > >enum@ietf.org > >https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 25 15:06:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUU8I-000418-8s; Tue, 25 Oct 2005 15:06:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUU8E-00040c-7A for enum@megatron.ietf.org; Tue, 25 Oct 2005 15:06:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13014 for ; Tue, 25 Oct 2005 15:06:31 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUULD-0006QC-Vu for enum@ietf.org; Tue, 25 Oct 2005 15:20:13 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 25 Oct 2005 12:06:36 -0700 X-IronPort-AV: i="3.97,250,1125903600"; d="scan'208"; a="356559712:sNHT28423148" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9PJ61K5029042; Tue, 25 Oct 2005 12:06:32 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 15:06:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2005 15:06:31 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3B45B49@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [voipeer] draft-meyer-voipeer-terminology-03.txt Thread-Index: AcXY8IzJvVECME3cSf2Dp9dgYA2gLgApUGOg From: "Michael Hammer \(mhammer\)" To: "Stephen Kingham" , "Livingood, Jason" X-OriginalArrivalTime: 25 Oct 2005 19:06:32.0197 (UTC) FILETIME=[362A7B50:01C5D997] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable Cc: Henry Sinnreich , enum@ietf.org, "Pfautz, Penn L, NEO" , voipeer@lists.uoregon.edu Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org RTCoIP SP? :) Mike=20 > -----Original Message----- > From: Stephen Kingham [mailto:Stephen.Kingham@aarnet.edu.au]=20 > Sent: Monday, October 24, 2005 7:12 PM > To: Livingood, Jason > Cc: David Meyer; Henry Sinnreich; Michael Hammer (mhammer);=20 > Pfautz, Penn L, NEO; voipeer@lists.uoregon.edu; enum@ietf.org > Subject: Re: [voipeer] draft-meyer-voipeer-terminology-03.txt >=20 > Hi >=20 > Jason makes a good point about 'unnecessarily constraining=20 > our work by defining the group as "Voice"' only. Like SMS=20 > for Cellular Mobiles, we should keep in mind that the new=20 > technology includes other forms of communications. Jason you=20 > mention IM and Chat as possibilities and another is presence.=20 >=20 > I think Henry's Application peering is much the same as=20 > Jason's suggestions and a very good point, but voip peering=20 > is still important and is the underlying technology. Solve=20 > VoIP peering and we help solve the others, provided we keep=20 > them in mind that we are trying to solve more than just=20 > Voice? Well that is what I learn from Henry's and Jason's comments. >=20 > The word "Carrier" does have considerable baggage which is=20 > encompassing (includes VoIP providers) and restricting at the=20 > same time (only including VoIP providers) all depending on=20 > the perspective of the reader. Carrier has a lot of=20 > ambiguity in this context but it is an easily recogniseable=20 > term. RTCSP seams to be another acronym that is as good as=20 > any other new acronym, seams okay ;-)! I think RTC and SP=20 > are widely recognizable, I would suggest a slight change to=20 > make it "RTC-SP", or at the extreme risk of including the=20 > work Carrier, what about "RTC Carrier". >=20 > Stephen >=20 >=20 > Livingood, Jason wrote: >=20 > >>>Hint: The carrier definition is hopeless. "The Internet Is The=20 > >>>Service" (Jon > >>>Peterson) and voice is an application IMHO. Let's go back to the=20 > >>>layers in the I-D. > >>> =20 > >>> > >> Yep. There's no real value add in defining carrier > >> IMO. Best solution: remove the definition of carrier.=20 > >> > >> Dave > >> =20 > >> > > > >Sounds fine. But if we did have to include something like=20 > this in the > >future, I suggest discarding the term 'carrier' completely=20 > as a quaint, > >outdated, and baggage-laden term. ;-) (no flames please, I am > >half-joking, half-serious) I might suggest, as I did before on the > >list, something very broad and inclusive such as Real-Time > >Communications Service Provider (RTCSP). This could encompass folks > >ranging from SBC and Verizon, to Skype, FWD and Vonage, to=20 > Vodafone and > >Telefonica. But I am not sure we need to concern ourselves with this > >for now based on recent discussion here. > > > >On a related definition, I think the definition of VoIP=20 > Service Provider > >in the I-D is fine. However, in the future, we should consider > >including a definition of a SP that offers more than Voice. =20 > Perhaps we > >are unnecessarily constraining our work by defining the=20 > group as "Voice" > >over IP peering, as many apps will begin to evolve such that voice is > >but one component of the real-time communications stream=20 > between two or > >more users. This could voice along with IM/chat and video,=20 > looking at > >apps available today. Then again, there is something to be said for > >constraining the boundaries of the problem we are trying to=20 > solve. If > >we can solve the peering problem for VoIP we can move on and=20 > broaden the > >definitions and the problem scope later. > > > >Regards, > >Jason > > > >_____________________________________________________________ > ________________ > >List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > > =20 > > >=20 > --=20 > Stephen Kingham, MIT, BSc, E&C Cert > Project Manager and Consulting Engineer=20 > mailto:Stephen.Kingham@aarnet.edu.au > Telephone +61 2 6222 3575 (office) > +61 419 417 471 (mobile) > sip:Stephen.Kingham@aarnet.edu.au >=20 > Voice and Video over IP > for The Australian Academic Research Network (AARNet) > http://www.aarnet.edu.au >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 25 17:07:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUW0v-0001ys-Ar; Tue, 25 Oct 2005 17:07:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUW0s-0001pq-Nc for enum@megatron.ietf.org; Tue, 25 Oct 2005 17:07:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14531 for ; Tue, 25 Oct 2005 17:07:03 -0400 (EDT) Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUWDu-00022Z-Df for enum@ietf.org; Tue, 25 Oct 2005 17:20:46 -0400 Received: from ([10.52.116.10]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.14498146; Tue, 25 Oct 2005 17:06:43 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 17:06:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt Date: Tue, 25 Oct 2005 17:06:25 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A39794@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt Thread-Index: AcXWU+B8oHe/eLs9R0W9viMm8yBp0QCXaQPAACm/rfAAEvZ+MA== From: "Livingood, Jason" To: "Stastny Richard" , , , X-OriginalArrivalTime: 25 Oct 2005 21:06:27.0783 (UTC) FILETIME=[F711C570:01C5D9A7] X-Spam-Score: 0.2 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > I can remember we considered this, but left it to e-mail and=20 > web, and I personally consider even e-mail problematic,=20 > because There will be at least one client designer out there=20 > having had not enough coffee in the morning and program a=20 > client directly sending an e-mail during call set-up >=20 > IMHO the best solution for an NRA is to point to a web-page=20 > where the NRA may list e-mail addresses or phone numbers for=20 > contact id something is wrong with the entry Thank you for the reply. =20 If I understand how the I-D would be used in practice - when a switch or client sees a VOID record, that will probably trigger it to play an announcement to tell the user the number is inactive ("dee-doo-dee. This number is not currently in service. Please check your number and dial again."). I suspect some clients may choose to discard / ignore the extra contact info provided, such as the http address, and just play this locally-stored announcement. =20 But thinking beyond the traditional phone instrument to soft phones and how announcements are viewed today, there may be more possibilities (I am no expert here, btw). Perhaps a tel URI could be used for the display the telephone number of the service provider's customer service line (similar to the URL for the customer service department) if it appears in the VOID record. Or perhaps some service providers will want a SIP URI to achieve the same end, or even to route the caller to a specialized announcement instead of the one that is stored by the switch/client (sip:TNnotAssigned@xyzVoIP.domain, IVR system on the line picks up and plays "This XYZ VoIP number is not currently in service. If you believe you have received this message in error, press 1 now. To sign up for service now, press 2." etc, etc.). Or maybe the SP didn't even buy a traditional announcement server and the URI goes to some generic, to-be-created service like sip:TNnotAssigned@opensourceAnnouncements.domain. ?? Of course, clients may choose to ignore this information as well. But at least the info would be present as an option in the future so we needn't come back to revise VOID. I could also see SPs trying to do the example above anyway, by not using VOIDs at all and simply populating a generic not-in-service SIP URI using E2U+SIP. I do not feel that is the desired result or necessarily advisable from an architecture perspective. But I'd rather give them the alternative of indicating the number as VOID and additionally giving a client the option of acting on a SIP or tel URI. Anyway, something to mull over a bit perhaps... Regards, Jason > Richard >=20 > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Monday, October 24, 2005 5:49 PM > > To: enum@ietf.org; Stastny Richard; lwc@roke.co.uk; jim@dns-moda.org > > Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt > >=20 > >=20 > > > Title : IANA Registration for Enumservice VOID > > > Author(s) : R. Stastny, et al. > > > Filename : draft-ietf-enum-void-02.txt > > > Pages : 19 > > > Date : 2005-10-21 > >=20 > > I know this draft has been around for awhile so excuse me if I=20 > > inadvertently bring up a question that may have been discussed=20 > > previously. Is there any reason the draft could not also include=20 > > subtypes for SIP and tel URIs? > >=20 > > Regards > > Jason >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 25 17:42:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWZ2-0008L7-K8; Tue, 25 Oct 2005 17:42:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWZ0-0008Kt-O9 for enum@megatron.ietf.org; Tue, 25 Oct 2005 17:42:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16484 for ; Tue, 25 Oct 2005 17:42:19 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUWm2-00035R-Kw for enum@ietf.org; Tue, 25 Oct 2005 17:56:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt Date: Tue, 25 Oct 2005 23:46:02 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C462C@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt Thread-Index: AcXWU+B8oHe/eLs9R0W9viMm8yBp0QCXaQPAACm/rfAAEvZ+MAAB1Nz1 From: "Stastny Richard" To: "Livingood, Jason" , , , X-Spam-Score: 0.2 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jason, =20 I think there is a misunderstanding here on the basic purpose of the VOID Enumservice, basically regarding the responsibility for the domain containing this NAPTR =20 You assumption is that a number range is assigned to a=20 VoIP provider and the VOIP has not yet assigned the number to the end-user. The assumption here is that the VoIP provider is already responsible for the number in question. This may be the case, and it is up to the VOIP provider if he simple enters a VOID NAPTR triggering the default dee-do-dee you mention OR providing an special announcement, but then eg with a normal SIP URI pointing somewhere (eg your examples) =20 But there is also an other approach possible, eg with our number range 0780 for ENUM. Numbers are assigend here 1 by one to end-users and the end-user in turn assignes the number to a VoIP service provider by pointing the URI to the VoIP SP. A similar case may happen fcarrier ENUM or 800 numbers=20 or corporate numbers assigned 1 by 1 first to the customer and then by the customer to the VoIP provider. In this cases an assigned number is NOT assigned to any=20 VoIP provider yet, it is really unassigend and still belongs to the pool of the regulator. So the basic idea was to point here to the webpage of the regulator only in the RARE case somebody believes that something is wrong here. The void enumservice is also intended to be used for yet unassigned area codes eg 1-747 in the US.Also this range still "belongs" to the NANP admin. I hope this clarifies the isuue somewhat. regards Richard ________________________________ Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Gesendet: Di 25.10.2005 23:06 An: Stastny Richard; enum@ietf.org; lwc@roke.co.uk; jim@dns-moda.org Betreff: RE: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt=20 > I can remember we considered this, but left it to e-mail and > web, and I personally consider even e-mail problematic, > because There will be at least one client designer out there > having had not enough coffee in the morning and program a > client directly sending an e-mail during call set-up > > IMHO the best solution for an NRA is to point to a web-page > where the NRA may list e-mail addresses or phone numbers for > contact id something is wrong with the entry Thank you for the reply.=20 If I understand how the I-D would be used in practice - when a switch or client sees a VOID record, that will probably trigger it to play an announcement to tell the user the number is inactive ("dee-doo-dee. This number is not currently in service. Please check your number and dial again."). I suspect some clients may choose to discard / ignore the extra contact info provided, such as the http address, and just play this locally-stored announcement.=20 But thinking beyond the traditional phone instrument to soft phones and how announcements are viewed today, there may be more possibilities (I am no expert here, btw). Perhaps a tel URI could be used for the display the telephone number of the service provider's customer service line (similar to the URL for the customer service department) if it appears in the VOID record. Or perhaps some service providers will want a SIP URI to achieve the same end, or even to route the caller to a specialized announcement instead of the one that is stored by the switch/client (sip:TNnotAssigned@xyzVoIP.domain, IVR system on the line picks up and plays "This XYZ VoIP number is not currently in service. If you believe you have received this message in error, press 1 now. To sign up for service now, press 2." etc, etc.). Or maybe the SP didn't even buy a traditional announcement server and the URI goes to some generic, to-be-created service like sip:TNnotAssigned@opensourceAnnouncements.domain. ?? Of course, clients may choose to ignore this information as well. But at least the info would be present as an option in the future so we needn't come back to revise VOID. I could also see SPs trying to do the example above anyway, by not using VOIDs at all and simply populating a generic not-in-service SIP URI using E2U+SIP. I do not feel that is the desired result or necessarily advisable from an architecture perspective. But I'd rather give them the alternative of indicating the number as VOID and additionally giving a client the option of acting on a SIP or tel URI. Anyway, something to mull over a bit perhaps... Regards, Jason > Richard > > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Monday, October 24, 2005 5:49 PM > > To: enum@ietf.org; Stastny Richard; lwc@roke.co.uk; jim@dns-moda.org > > Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt > > > > > > > Title : IANA Registration for Enumservice VOID > > > Author(s) : R. Stastny, et al. > > > Filename : draft-ietf-enum-void-02.txt > > > Pages : 19 > > > Date : 2005-10-21 > > > > I know this draft has been around for awhile so excuse me if I > > inadvertently bring up a question that may have been discussed > > previously. Is there any reason the draft could not also include > > subtypes for SIP and tel URIs? > > > > Regards > > Jason > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 26 00:01:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUcTW-0004nl-AO; Wed, 26 Oct 2005 00:01:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUcTV-0004nW-0q for enum@megatron.ietf.org; Wed, 26 Oct 2005 00:01:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19611 for ; Wed, 26 Oct 2005 00:00:58 -0400 (EDT) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUcgW-0001Ao-IL for enum@ietf.org; Wed, 26 Oct 2005 00:14:46 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel11.hp.com (Postfix) with ESMTP id 7965640E2; Tue, 25 Oct 2005 21:01:06 -0700 (PDT) Received: from anoop ([16.150.200.52]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id JAA29523; Wed, 26 Oct 2005 09:26:08 +0530 (IST) Message-Id: <200510260356.JAA29523@iconsrv6.india.hp.com> From: "sajitha" To: "'Otmar Lendl'" , Subject: RE: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt] Date: Wed, 26 Oct 2005 09:30:38 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcXYnGrn5LFP7unhQqy8dVcQTb22JwA1jAgg In-Reply-To: <20051024131257.GA14425@nic.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi, The timeout configuration comes as part of the API implementation. The implementation can use res_*() calls for DNS look-ups wherein many vendors already provide the timeout configuration option. Does this make sense for the ENUM deployment? Do you think there is a need for timeout configuration which is specific to ENUM resolution as compared to any other DNS resolution? Regards, Sajitha -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Otmar Lendl Sent: Monday, October 24, 2005 6:43 PM To: enum@ietf.org Subject: Re: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt] > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sajitha-enum-api-00.txt This API misses one rather critical aspect for production system ENUM deployment: Configurable timeouts. Misconfigured ENUM delegations/nameservers can lead to significant delays before the resolver program gives up. It should thus be possible to tell the ENUM resolver API to give up after x seconds. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 26 00:01:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUcTp-0004pu-0Z; Wed, 26 Oct 2005 00:01:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUcTn-0004pg-9b for enum@megatron.ietf.org; Wed, 26 Oct 2005 00:01:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19650 for ; Wed, 26 Oct 2005 00:01:18 -0400 (EDT) Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUcgs-0001Bi-3P for enum@ietf.org; Wed, 26 Oct 2005 00:15:06 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel8.hp.com (Postfix) with ESMTP id A23D62B4C; Wed, 26 Oct 2005 00:01:31 -0400 (EDT) Received: from anoop ([16.150.200.52]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id JAA29577; Wed, 26 Oct 2005 09:26:32 +0530 (IST) Message-Id: <200510260356.JAA29577@iconsrv6.india.hp.com> From: "sajitha" To: "'Klaus Darilion'" , Date: Wed, 26 Oct 2005 09:30:38 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcXYgSQ4F8p2UsMBTXyiE0a6q0xduQBVzA8Q In-Reply-To: <435CADB9.10805@pernau.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] RE: comments on draft-sajitha-enum-api-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi, A NULL service type argument to the API will retrieve all supported service types. Applications can traverse the uriinfo linked list returned by this API to get all the information. Please see page 3 of the draft : "The DNS response should be parsed by the API as given below: 1. If service type is NULL, all URIs corresponding to this E.164 number should be returned along with the corresponding service type, service type length, all service subtypes & service subtype length. In case of non NULL service type, all the records in the DNS response should be parsed one by one applying the following rule: ..." So multiple DNS lookups or call to geturiinfo() is not required. Regards, Sajitha -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Sent: Monday, October 24, 2005 3:18 PM To: 'enum@ietf.org' Cc: sajitha@india.hp.com Subject: comments on draft-sajitha-enum-api-00.txt Hi! Some comments to this draft: The API is very simple and thus easy to use in simple applications. But IMO the API is too simple. Consider the case of an universal messaging application which supports voice (sip,h323,iax), email, fax and sms. Then it will be useful to retrieve all supported service types and ask the user which service it would like to use. Using this API you would have to call geturiinfo() several times for each service type suported by the application (which probably ends up with multiple DNS lookups). I would suggest a more flexible API which seperates the ENUM lookup into smaller pieces. eg.: int get_enum(const char *telephonenum, int enumhandle); This makes the DNS lookup and stores the NAPTRs somewehere ... get_servicetypes(int enumhandle); returns the supported servicetypes (a pointer to a list of strings or something simmilar) int get_uri(int enumhandle, char *service_type, struct uriinfo **res); get the URI for a certain service type void free_enum(int enumhandle); free the ENUM resources regards klaus Richard Shockey wrote: > > > -------- Original Message -------- > Subject: I-D ACTION:draft-sajitha-enum-api-00.txt > Date: Fri, 21 Oct 2005 15:50:01 -0400 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : An ENUM Library API > Author(s) : T. Sajitha > Filename : draft-sajitha-enum-api-00.txt > Pages : 7 > Date : 2005-10-21 > > This draft defines a library API for ENUM. The API takes telephone > number as input and returns the URI associated with that telephone > number. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sajitha-enum-api-00.txt _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 26 03:42:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUfvg-0003wW-Rv; Wed, 26 Oct 2005 03:42:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPHF-0001qC-Cg for enum@megatron.ietf.org; Tue, 25 Oct 2005 09:55:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18631 for ; Tue, 25 Oct 2005 09:55:30 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUPU9-0003RT-0c for enum@ietf.org; Tue, 25 Oct 2005 10:09:09 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9PDs6WA027337; Tue, 25 Oct 2005 14:54:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from [127.0.0.1] (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VGTHYD1X; Tue, 25 Oct 2005 14:58:39 +0100 MIME-Version: 1.0 Content-class: urn:content-classes:message Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt Date: Tue, 25 Oct 2005 14:53:49 +0100 Message-ID: <02CFB703-A54F-44FA-833A-F523946D0594@roke.co.uk> Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt Thread-Index: AcXZbDNgRhBYSYPoTDqXztlNiBm71Q== From: "Conroy, Lawrence \(SMTP\)" To: "Ray Anderson" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: lwc@roke.co.uk X-Spam-Score: 0.8 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c X-Mailman-Approved-At: Wed, 26 Oct 2005 03:42:35 -0400 Cc: enum@ietf.org, Stastny Richard , jim@dns-moda.org, "Livingood, Jason" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1255647650==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1255647650== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D96C.33485180" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D96C.33485180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ray, folks, Forgive, but why on a phone? This is NOT during call setup. Only offline, if there's a problem (e.g. your assignment is marked as =20 VOID). all the best, Lawrence On 25 Oct 2005, at 14:41, Ray Anderson wrote: > And make sure that the web page works on the more popular devices =20 > like phones, as well as on PC's > (i.e. support WML, XHTML etc.) > Ray > At 12:41 25/10/2005, Stastny Richard wrote: > >> Jason, >> >> I can remember we considered this, but left it to e-mail and web, >> and I personally consider even e-mail problematic, because >> There will be at least one client designer out there having >> had not enough coffee in the morning and program a client >> directly sending an e-mail during call set-up >> >> IMHO the best solution for an NRA is to point to a web-page >> where the NRA may list e-mail addresses or phone numbers for >> contact id something is wrong with the entry >> >> Richard >> > > ------_=_NextPart_001_01C5D96C.33485180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt

Hi Ray, folks,
   Forgive, but why on a phone?
This is NOT during call setup.
Only offline, if there's a problem (e.g. your = assignment is marked as 
VOID).

all the best,
   Lawrence

On 25 Oct 2005, at 14:41, Ray Anderson wrote:
> And make sure that the web page works on the = more popular devices 
> like phones, as well as on PC's
> (i.e. support WML, XHTML etc.)
> Ray
> At 12:41 25/10/2005, Stastny Richard = wrote:
>
>> Jason,
>>
>> I can remember we considered this, but left = it to e-mail and web,
>> and I personally consider even e-mail = problematic, because
>> There will be at least one client designer = out there having
>> had not enough coffee in the morning and = program a client
>> directly sending an e-mail during call = set-up
>>
>> IMHO the best solution for an NRA is to = point to a web-page
>> where the NRA may list e-mail addresses or = phone numbers for
>> contact id something is wrong with the = entry
>>
>> Richard
>>
>
>

------_=_NextPart_001_01C5D96C.33485180-- --===============1255647650== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1255647650==-- From enum-bounces@ietf.org Wed Oct 26 10:04:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUlsr-0007F8-LU; Wed, 26 Oct 2005 10:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUlsq-0007EX-D0 for enum@megatron.ietf.org; Wed, 26 Oct 2005 10:04:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21445 for ; Wed, 26 Oct 2005 10:03:49 -0400 (EDT) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUm61-0002hv-0a for enum@ietf.org; Wed, 26 Oct 2005 10:17:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt Date: Wed, 26 Oct 2005 10:01:55 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A39798@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt Thread-Index: AcXWU+B8oHe/eLs9R0W9viMm8yBp0QCXaQPAACm/rfAAEvZ+MAAB1Nz1ACIDRnA= From: "Livingood, Jason" To: "Stastny Richard" , , , X-OriginalArrivalTime: 26 Oct 2005 14:01:58.0235 (UTC) FILETIME=[D472EAB0:01C5DA35] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Okay, I better understand your use case now. =20 So to summarize, there is an entity that holds a block of numbers. Let us say 1,000 numbers for example. This entity in the case of Austria could be the enum.at registry or other entity that hands 0780 numbers out to users directly, on an individual basis (please excuse my lack of understanding of who hands out the special 0780 numbers). In the US, it could be a SP that has been delegated a block of 1,000 numbers by the NRA that are, in turn, handed out to subscribers. Or perhaps it is a university campus that has a big IP-PBX with 1,000 numbers and activates the numbers when students come to school each year.=20 In all of these cases, using the 1,000 number example, 900 of the numbers are not yet activated and 100 are active with E2U+SIP NAPTRs. The other 900 have VOID records. In the case of Austria and the 0780 range, you may want E2U+void:http, to give the homepage of enum.at or whatever, in case someone wishes to report an error or figure out why it is not active. =20 So I suppose what I am asking is, do you think that the http, https, and mailto subtypes of VOID solve all potential and future use cases of VOID that one could imagine? To that end, is it worth considering the addition of tel and SIP subtypes to VOID (based on a few quick possibilities outlined in my earlier email)? As I said, if we think they may be useful by someone in the future, perhaps it is better to consider them now than have to revise the draft in 2 years to make some additions. Regards, Jason > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Tuesday, October 25, 2005 5:46 PM > To: Livingood, Jason; enum@ietf.org; lwc@roke.co.uk; jim@dns-moda.org > Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt=20 >=20 > Jason, > =20 > I think there is a misunderstanding here on the basic purpose=20 > of the VOID Enumservice, basically regarding the=20 > responsibility for the domain containing this NAPTR > =20 > You assumption is that a number range is assigned to a VoIP=20 > provider and the VOIP has not yet assigned the number to the=20 > end-user. The assumption here is that the VoIP provider is=20 > already responsible for the number in question. >=20 > This may be the case, and it is up to the VOIP provider if he=20 > simple enters a VOID NAPTR triggering the default dee-do-dee=20 > you mention OR providing an special announcement, but then eg=20 > with a normal SIP URI pointing somewhere (eg your examples) > =20 > But there is also an other approach possible, eg with our=20 > number range 0780 for ENUM. Numbers are assigend here 1 by=20 > one to end-users and the end-user in turn assignes the number=20 > to a VoIP service provider by pointing the URI to the VoIP SP. >=20 > A similar case may happen fcarrier ENUM or 800 numbers or=20 > corporate numbers assigned > 1 by 1 first to the customer and then by the customer to the=20 > VoIP provider. >=20 > In this cases an assigned number is NOT assigned to any VoIP=20 > provider yet, it is really unassigend and still belongs to=20 > the pool of the regulator. So the basic idea was to point=20 > here to the webpage of the regulator only in the RARE case=20 > somebody believes that something is wrong here. >=20 > The void enumservice is also intended to be used for yet=20 > unassigned area codes eg 1-747 in the US.Also this range=20 > still "belongs" to the NANP admin. >=20 > I hope this clarifies the isuue somewhat. >=20 > regards >=20 > Richard >=20 >=20 >=20 > ________________________________ >=20 > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Gesendet: Di 25.10.2005 23:06 > An: Stastny Richard; enum@ietf.org; lwc@roke.co.uk; jim@dns-moda.org > Betreff: RE: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt=20 >=20 >=20 >=20 > > I can remember we considered this, but left it to e-mail=20 > and web, and=20 > > I personally consider even e-mail problematic, because=20 > There will be=20 > > at least one client designer out there having had not=20 > enough coffee in=20 > > the morning and program a client directly sending an e-mail during=20 > > call set-up > > > > IMHO the best solution for an NRA is to point to a web-page=20 > where the=20 > > NRA may list e-mail addresses or phone numbers for contact id=20 > > something is wrong with the entry >=20 > Thank you for the reply.=20 >=20 > If I understand how the I-D would be used in practice - when=20 > a switch or client sees a VOID record, that will probably=20 > trigger it to play an announcement to tell the user the=20 > number is inactive ("dee-doo-dee. > This number is not currently in service. Please check your=20 > number and dial again."). I suspect some clients may choose=20 > to discard / ignore the extra contact info provided, such as=20 > the http address, and just play this locally-stored announcement.=20 >=20 > But thinking beyond the traditional phone instrument to soft=20 > phones and how announcements are viewed today, there may be=20 > more possibilities (I am no expert here, btw). Perhaps a tel=20 > URI could be used for the display the telephone number of the=20 > service provider's customer service line (similar to the URL=20 > for the customer service department) if it appears in the=20 > VOID record. Or perhaps some service providers will want a=20 > SIP URI to achieve the same end, or even to route the caller=20 > to a specialized announcement instead of the one that is=20 > stored by the switch/client=20 > (sip:TNnotAssigned@xyzVoIP.domain, IVR system on the line=20 > picks up and plays "This XYZ VoIP number is not currently in service. > If you believe you have received this message in error, press=20 > 1 now. To sign up for service now, press 2." etc, etc.). =20 > Or maybe the SP didn't even buy a traditional announcement=20 > server and the URI goes to some generic, to-be-created=20 > service like sip:TNnotAssigned@opensourceAnnouncements.domain. ?? >=20 > Of course, clients may choose to ignore this information as=20 > well. But at least the info would be present as an option in=20 > the future so we needn't come back to revise VOID. I could=20 > also see SPs trying to do the example above anyway, by not=20 > using VOIDs at all and simply populating a generic=20 > not-in-service SIP URI using E2U+SIP. I do not feel that is=20 > the desired result or necessarily advisable from an=20 > architecture perspective. But I'd rather give them the=20 > alternative of indicating the number as VOID and additionally=20 > giving a client the option of acting on a SIP or tel URI. >=20 > Anyway, something to mull over a bit perhaps... >=20 > Regards, > Jason >=20 > > Richard > > > > > -----Original Message----- > > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Sent: Monday, October 24, 2005 5:49 PM > > > To: enum@ietf.org; Stastny Richard; lwc@roke.co.uk;=20 > jim@dns-moda.org > > > Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt > > > > > > > > > > Title : IANA Registration for Enumservice VOID > > > > Author(s) : R. Stastny, et al. > > > > Filename : draft-ietf-enum-void-02.txt > > > > Pages : 19 > > > > Date : 2005-10-21 > > > > > > I know this draft has been around for awhile so excuse me if I=20 > > > inadvertently bring up a question that may have been discussed=20 > > > previously. Is there any reason the draft could not also include=20 > > > subtypes for SIP and tel URIs? > > > > > > Regards > > > Jason > > >=20 >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 26 12:09:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnqV-0001L8-Ln; Wed, 26 Oct 2005 12:09:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnqT-0001Kj-DZ for enum@megatron.ietf.org; Wed, 26 Oct 2005 12:09:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04118 for ; Wed, 26 Oct 2005 12:09:29 -0400 (EDT) Received: from mail2.hutchison.com.au ([203.18.188.195] helo=mailsweeper2.orange.net.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUo3b-0008UE-R5 for enum@ietf.org; Wed, 26 Oct 2005 12:23:23 -0400 Received: from mail.hutch.com.au (unverified [203.31.24.24]) by mailsweeper2.orange.net.au (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Thu, 27 Oct 2005 02:05:48 +1000 Received: from GWACCESS-MTA by mail.hutch.com.au with Novell_GroupWise; Thu, 27 Oct 2005 02:09:20 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Date: Thu, 27 Oct 2005 02:08:56 +1000 From: "Philip Walls" To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: [Enum] Re: enum Digest, Vol 18, Issue 49 (Out of office) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Thanks for your email. Sorry, but I'll be out of the office on Thurs 27/10 & Fri 28/10. I'll be b= ack on Mon 31/10. I will not be contactable on Thursday, but may be able to respond to voicem= ails on Friday. Cheers Phil _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 26 13:49:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUpPP-0004e9-3m; Wed, 26 Oct 2005 13:49:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUpPM-0004Xp-EX for enum@megatron.ietf.org; Wed, 26 Oct 2005 13:49:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10173 for ; Wed, 26 Oct 2005 13:49:36 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUpcW-0003JT-95 for enum@ietf.org; Wed, 26 Oct 2005 14:03:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Re: enum Digest, Vol 18, Issue 49 (Out of office) Date: Wed, 26 Oct 2005 19:52:47 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C462F@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Re: enum Digest, Vol 18, Issue 49 (Out of office) Thread-Index: AcXaSM+1lnn1Ox6bSD23PLvYOuBGVAADUNnh From: "Stastny Richard" To: "Philip Walls" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Interesting =20 Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Philip Walls Gesendet: Mi 26.10.2005 18:08 An: enum@ietf.org Betreff: [Enum] Re: enum Digest, Vol 18, Issue 49 (Out of office) Thanks for your email. Sorry, but I'll be out of the office on Thurs 27/10 & Fri 28/10. I'll = be back on Mon 31/10. I will not be contactable on Thursday, but may be able to respond to = voicemails on Friday. Cheers Phil _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 26 14:22:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUpub-0004an-08; Wed, 26 Oct 2005 14:22:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUpuX-0004aS-M8 for enum@megatron.ietf.org; Wed, 26 Oct 2005 14:22:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11728 for ; Wed, 26 Oct 2005 14:21:51 -0400 (EDT) Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUq7j-0004FV-Av for enum@ietf.org; Wed, 26 Oct 2005 14:35:45 -0400 Received: from mail-int1.denic.de (mail-int1.denic.de [192.168.0.45]) by smtp.denic.de with esmtp id 1EUpuE-00011n-3k; Wed, 26 Oct 2005 20:21:46 +0200 Received: from localhost by mail-int1.denic.de with local id 1EUpuA-0006jw-00; Wed, 26 Oct 2005 20:21:42 +0200 Date: Wed, 26 Oct 2005 20:21:42 +0200 From: Peter Koch To: IETF ENUM WG Message-ID: <20051026182142.GU16044@denics7.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Subject: [Enum] Re: I-D ACTION:draft-conroy-enum-edns0-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Dear WG, this is a first review of draft-conroy-enum-edns0-00/01.txt. The document technically looks good and I agree with the general idea - not necassarily with the approacvh chosen. Some details need to be clarified and it would be good to solicit broader review. My main concern is that it's not clear how to achieve the goal of having "everything involved in ENUM" support large DNS responses. It is obvious that servers and application resolvers must "support" EDNS0 and those might even be under control of an entity motivated to adapt. Speaking of intermediaries (firewalls, packet filters, recursive resolvers, ...) I am not convinced that it's useful to specify requirements in normative language. I'd have a similar problem with RFC 3226, but the situation is different. DNSSEC is a protocol extension to the DNS, ENUM is not. ENUM is a DDDS application (and thus the EDNS0 "requirement" would most likely apply to all DDDS usages) using (primarily) the NAPTR RR in a dedicated namespace. So, instead of heading standards track, a collection of pitfalls to avoid in a BCP "What you need to know and do to support ENUM in your DNS and network infrastructure" seems more appropriate at least when it comes to defining the behaviour of firewalls etc. (see below). Detailed comments interspersed: > 2. Introduction > Entities involved in processing ENUM queries and responses have to The document does not clearly define what an ENUM query (and therefore a response) is. Is it a query for anything in the e164.arpa domain or just NAPTR queries? > 2.1. DNS - Background > > DNS is based on a simple question and answer model. In the standard > approach described in RFC1035, a Resolver will construct and send a > question to a DNS Server using UDP transport. s/question/query/ > Supporting UDP queries is mandatory, but support for TCP queries is > recommended also, and is (in effect) required as RFC1123 requires > that a DNS Resolver discard a truncated response and retry using > another transport protocol. In effect, Authoritative Name Servers > that do not answer TCP queries after returning truncated responses > are misconfigured. The problem is that this is data dependent. If I am absolutely positively sure my responses will always fit into 512 octets, there's no pressing need for TCP (well, one might argue that TCP solves other problems than the size as well, but this is a different topic). So, 1123 doesn't really generally require TCP support. The second sentence is true but the error may or may not be due to configuration (could be UDP only SW). > With the introduction of the Extension mechanisms described in > RFC2671, there is now a mechanism by which a DNS entity can indicate > that it is capable of handling messages larger than those implied in > the scheme described in RFC1035, so that it can use UDP transport but > still receive DNS messages up to the size it specifies in its request s/request/query/ > or response. > 3. Problem > While the percentage of queries processed that exceed the UDP size > limit specified in RFC1035 is relatively small, the impact on normal s/while/since/ ? Also, it should be noted that thi is an obeservation from (parts of) the none-ENUM (non-NAPTR, non-RR-suffering-from-the-subtyping-problem) DNS. > 4.1. Required Aspects of EDNS0 Support > receives answers. The list of involved Servers includes any DNS > Servers authoritative for delegated ENUM domains, but also the DNS > Servers authoritative for .arpa, the ENUM Tier 0 DNS Servers > authoritative for .e164.arpa, and all ENUM Tier 1 DNS Servers with > zones delegated from those Tier 0 Servers. It is not immediately clear why arpa and e164.arpa would need EDNS0 support while at the same time the root servers are missing from this list. A reason I could imagine is that you'd want to avoid failing EDNS0 negotiations, but those would occur on relatively rare occasions anyway. In practice those servers will most likely support EDNS0 but making this a requirement needs more justification. > Of course, support is one thing, but use is another. To clarify, the Indeed. The document not only needs to ask for EDNS0 support but would also have to suggest minimum DNS payload sizes acceptable. > 4.1.2. Fragmentation Requirement > > Second, a DNS Server may receive queries that indicate a given size > of response is acceptable. However, the Resolver may be connected > via a network with a lower MTU, in which case the response packet > will undergo fragmentation and reassembly in transit. > > Thus, although obvious (and not directly related to its use in > processing ENUM requests), this means that: > > A DNS Server responding to a query that includes the EDNS0 size > option MUST NOT set the DF (Don't Fragment) bit in the UDP packet > holding its answer. (s/UDP packet holding its answer/UDP response packet/) This clarification/addendum to EDNS0 is "obvious" but doesn't belong into this document IMHO. > 4.1.3. Intermediary Node Requirement > > The final point concerns intermediate nodes. It has been noticed > that some intermediate nodes exhibit overly aggressive behaviour. > > Specifically: > > Intermediate nodes MUST NOT block valid ENUM queries and responses > that indicate EDNS0 support, even if these are larger that the > size given in RFC1035. In particular, intermediate packet filters > MUST NOT assume that large DNS queries and responses are invalid; > they are not if they indicate EDNS0 support correctly. Such > packet discard strategies are in error. > > Intermediate nodes MUST NOT block valid ENUM queries and responses > sent over TCP transport. "Firewalls must not interfere with solicited legal traffic." This is a problematic approach in that I can't imagine what the practical outcome is. This is a "don't drink and drive" style recommendation. Also, the question whether or not these strategies are "in error" may be viewed differently. The "unknown==hostile" approach isn't too uncommon. > This last requirement means that intermediary packet filters MUST NOT > simply block all TCP traffic; it is perfectly reasonable for DNS > queries to be sent over TCP transport, and a more selective strategy > will need to be chosen. Again, I doubt that ruling the behaviour of any such device with normative language is helpful. > 5. Security Considerations > > This document does appear to introduce any extra security issues over > and above those mentioned in RFC3761 and in RFC2671, as well as those > listed in the thorough analysis of the threats to DNS in RFC3833 > [11]. Any "not" missing in this paragraph? > It should be noted that mandating the use of EDNS0 by ENUM-related > entities also facilitates the deployment of Secure DNS, DNSSEC, > currently defined in RFC4033 [12], RFC4034 [13] and RFC4035 [14]. > Secure DNS will be necessary to verify the integrity of ENUM > responses. RFC3225 [9] states that clients signal their ability to > handle signed responses via the DO (DNSSEC OK) bit in the EDNS0 > header and a name server will not return these unless this bit is > set. So unless EDNS0 is used, ENUM-related entities will be unable > to verify DNSSEC-signed responses from the DNS. Signed replies from This is already covered by the DNSSEC spec, and thus is misleading here. In addition, the document uses EDNS0 as synonym for "payload size negotiation" and then now concludes that you'd need the OK bit? I'm glad to see a recommendation for DNSSEC in ENUMland, but this particular linking appears a bit arbitrary. > the DNS are also much larger than unsigned ones, which provides an > added incentive to use larger UDP payloads. Which is why the to-be-determined minimum payload size should also (optionally) account for the DNSSEC payload growth, too. > 8.2. Informative References > > [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", RFC 2119, BCP 14, March 1997. At least this one needs to be normative. Finally, in addition to all these considerations of size, the WG should also discuss the NAPTR RR's subtyping problem and potential consequences of the proliferation of enum service specifications. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 27 06:26:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV4yJ-0002ra-28; Thu, 27 Oct 2005 06:26:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV4yH-0002q5-0t for enum@megatron.ietf.org; Thu, 27 Oct 2005 06:26:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20416 for ; Thu, 27 Oct 2005 06:26:40 -0400 (EDT) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV5BY-0005cT-BF for enum@ietf.org; Thu, 27 Oct 2005 06:40:45 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 8992F1A360; Thu, 27 Oct 2005 12:26:32 +0200 (CEST) Date: Thu, 27 Oct 2005 12:26:32 +0200 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt] Message-ID: <20051027102632.GA27446@nic.at> References: <20051024131257.GA14425@nic.at> <200510260356.JAA29523@iconsrv6.india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510260356.JAA29523@iconsrv6.india.hp.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 2005/10/26 06:10, sajitha wrote: > Hi, > > The timeout configuration comes as part of the API implementation. The > implementation can use res_*() calls for DNS look-ups wherein many vendors > already provide the timeout configuration option. Does this make sense for > the ENUM deployment? Do you think there is a need for timeout configuration > which is specific to ENUM resolution as compared to any other DNS > resolution? The timeout requirements regarding ENUM may be different than for other DNS lookups. Typically DNS resolutions need to complete before the application can proceed. e.g. SRV and A lookups for SIP calls. If the DNS fails, then your application fails and you notify your user that "sorry, I tried everything I could but it don't work out". ENUM can be different: if your application does transparent re-routing of calls to VoIP based on ENUM then a DNS failure during the ENUM lookup does cause the call to fail. It just means that the VoIP path is not possible. But you don't want to spend 60 seconds trying a set of unreachable nameserver to get that info. The user-experience would be terrible. You want a definite upper bound on how long that ENUM lookup can take before you give up and go for the PSTN route. I don't like your reference to res_*(). These calls are not defined in your API. You're implying that any implementation of your API will be based on libresolv and not some other DNS library like adns or firedns. (see http://www.chiark.greenend.org.uk/~ian/adns/ http://freshmeat.net/projects/firedns/) But even I we assume libresolv, your API does not expose the underlying res_state structure, so I have to conclude that you use res_init() and not res_ninit(). This implies the user cannot set the timeouts in a thread-safe way. Furthermore, I don't think that the timeout configuration in libresolv is all that helpful as you can only set RES_RETRANS and RES_RETRY for individual servers and not an overall timeout. IMHO a feature-complete ENUM API should also contain functions to: * query more than one tree in parallel * asynchronous operation As I'm doing some programming on the Asterisk ENUM code again I would really appreciate a decent API for ENUM lookups to rely on. Your API is a fine first step, but it does not solve all the issues that crop up in production use. Cheers, /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 27 08:05:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV6VY-0007CD-I3; Thu, 27 Oct 2005 08:05:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV67J-0002Tk-GS for enum@megatron.ietf.org; Thu, 27 Oct 2005 07:40:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23002 for ; Thu, 27 Oct 2005 07:40:02 -0400 (EDT) Received: from emcsw.com ([69.28.242.167] helo=www.eguy.org ident=Debian-exim) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV6Kd-0007GB-Na for enum@ietf.org; Thu, 27 Oct 2005 07:54:08 -0400 Received: from host-24-149-134-164.patmedia.net ([24.149.134.164] helo=[192.168.1.4]) by www.eguy.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EV66u-0007ub-FR; Thu, 27 Oct 2005 07:39:56 -0400 Message-ID: <4360BCFC.3090300@emcsw.com> Date: Thu, 27 Oct 2005 07:41:48 -0400 From: Ed Guy User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: [Enum] [Fwd: I-D ACTION:draft-guy-enumiax-00.txt] References: <6EEEACD9D7F52940BEE26F5467C02C7302A3975D@PACDCEXCMB01.cable.comcast.com> In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302A3975D@PACDCEXCMB01.cable.comcast.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e X-Mailman-Approved-At: Thu, 27 Oct 2005 08:05:23 -0400 Cc: enum@ietf.org, edguy@emcsw.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1611422511==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1611422511== Content-Type: multipart/alternative; boundary="------------040901070605090702000704" This is a multi-part message in MIME format. --------------040901070605090702000704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jason, Thank you for the feedback. I'll incorporate this change into the next revision. Best Regards /ed guy Livingood, Jason wrote: >> Title : IANA Registration for IAX Enumservice >> Author(s) : E. Guy >> Filename : draft-guy-enumiax-00.txt >> Pages : 11 >> Date : 2005-10-20 >> >> This document registers the IAX2 Enumservice using the URI scheme >> 'iax2:' as per the IANA registration process defined in the ENUM >> specification RFC3761. >> >> > >I like the format - easy to follow. > >One minor comment. You may want to break up section 4 (examples) into >sub-sections, since you list multiple examples. This may make it easier >for readers to differentiate between each discrete example, and make it >easier for you to expand the section in the future. > >Regards >Jason > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum > > > --------------040901070605090702000704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jason,

Thank you for the feedback.  I'll incorporate this change into the next revision.

Best Regards
/ed guy


Livingood, Jason wrote: 
	Title		: IANA Registration for IAX Enumservice
	Author(s)	: E. Guy
	Filename	: draft-guy-enumiax-00.txt
	Pages		: 11
	Date		: 2005-10-20
	
    This document registers the IAX2 Enumservice using the URI scheme
    'iax2:' as per the IANA registration process defined in the ENUM
    specification RFC3761.
    

I like the format - easy to follow.

One minor comment.  You may want to break up section 4 (examples) into
sub-sections, since you list multiple examples.  This may make it easier
for readers to differentiate between each discrete example, and make it
easier for you to expand the section in the future.

Regards
Jason

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum
--------------040901070605090702000704-- --===============1611422511== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1611422511==-- From enum-bounces@ietf.org Thu Oct 27 10:08:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8QJ-0006of-EL; Thu, 27 Oct 2005 10:08:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8QH-0006oa-E3 for enum@megatron.ietf.org; Thu, 27 Oct 2005 10:08:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01687 for ; Thu, 27 Oct 2005 10:07:49 -0400 (EDT) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV8dc-0003GN-Ff for enum@ietf.org; Thu, 27 Oct 2005 10:21:55 -0400 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j9RE7gd3020367; Thu, 27 Oct 2005 15:07:42 +0100 (BST) In-Reply-To: <20051026182142.GU16044@denics7.denic.de> References: <20051026182142.GU16044@denics7.denic.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5247FEA3-3AA3-45DF-B169-F872AAC47A8B@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] Re: I-D ACTION:draft-conroy-enum-edns0-01.txt Date: Thu, 27 Oct 2005 15:07:36 +0100 To: Peter Koch X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 7bit Cc: IETF ENUM WG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Peter, thanks for reviewing the draft and for your comments. I'm puzzled by some of them. On Oct 26, 2005, at 19:21, Peter Koch wrote: > My main concern is that it's not clear how to achieve the goal of > having > "everything involved in ENUM" support large DNS responses. It is > obvious > that servers and application resolvers must "support" EDNS0 and those > might even be under control of an entity motivated to adapt. Speaking > of intermediaries (firewalls, packet filters, recursive > resolvers, ...) > I am not convinced that it's useful to specify requirements in > normative > language. Well if it's not done in that way through some sort of standards- track RFC, what other approach would you suggest? IMO without such a document, implementors have nothing to go on. If there's nothing that says "you've got to support EDNS0" (and explains why), there's a good chance EDNS0 support won't make it into ENUM-aware handsets. Making EDNS0 support mandatory should mean it doesn't get dropped from the feature set in the OS for these types of embedded devices. ie Unless someone/something tells those developers to put in EDNS0, they won't. > So, instead of heading standards track, a collection of pitfalls to > avoid > in a BCP "What you need to know and do to support ENUM in your DNS and > network infrastructure" seems more appropriate at least when it > comes to > defining the behaviour of firewalls etc. (see below). Maybe. But this draft isn't really about firewalls or routers. And these should alredy be supporting EDNS0 anyway. And again, unless there's something that says EDNS0 is mandatory in ENUM -- which I think we agree it should be -- where's the incentive for vendors to incorporate support for this in their products? > The document does not clearly define what an ENUM query (and therefore > a response) is. Is it a query for anything in the e164.arpa domain or > just NAPTR queries? Queries in e164.arpa, obviously. >> Supporting UDP queries is mandatory, but support for TCP >> queries is >> recommended also, and is (in effect) required as RFC1123 requires >> that a DNS Resolver discard a truncated response and retry using >> another transport protocol. In effect, Authoritative Name Servers >> that do not answer TCP queries after returning truncated responses >> are misconfigured. > > The problem is that this is data dependent. If I am absolutely > positively > sure my responses will always fit into 512 octets, there's no pressing > need for TCP (well, one might argue that TCP solves other problems > than > the size as well, but this is a different topic). So, 1123 doesn't > really > generally require TCP support. You are Dan Bernstein and I claim my 5 dollars! :-) > The second sentence is true but the error > may or may not be due to configuration (could be UDP only SW). Peter, you're picking nits. A server that doesn't do TCP after a truncated response is misconfigured. Whether that is caused by a broken configuration file or a faulty implementation is neither here nor there. It's more diplomatic to just say such setups are misconfigured. I would have preferred to say they were broken beyond belief but my co-author's wiser head prevailed. >> While the percentage of queries processed that exceed the UDP size >> limit specified in RFC1035 is relatively small, the impact on >> normal > > s/while/since/ ? > Also, it should be noted that thi is an obeservation from (parts > of) the > none-ENUM (non-NAPTR, non-RR-suffering-from-the-subtyping-problem) > DNS. True enough, but that's a discussion for another working group. > It is not immediately clear why arpa and e164.arpa would need EDNS0 > support while at the same time the root servers are missing from this > list. A reason I could imagine is that you'd want to avoid failing > EDNS0 > negotiations, but those would occur on relatively rare occasions > anyway. > In practice those servers will most likely support EDNS0 but making > this > a requirement needs more justification. We deliberately avoided references to the root servers for the obvious reasons. Anything that affects root server operations is a political nightmare. Anyway, all the root servers already support EDNS0 -- as you know. Besides, those servers need EDNS0 for other political horrors that are coming to the root zone Real Soon Now like IPv6 glue and Secure DNS. Now we could have said "lookups under e164.arpa must use EDNS0". But that would pre-judge whatever domain name is chosen for Carrier ENUM. It would also exclude the ENUM-like stuff that the GSM people are doing under their bogus .gprs TLD. Sigh. > Indeed. The document not only needs to ask for EDNS0 support but would > also have to suggest minimum DNS payload sizes acceptable. If it's not already there, that should be in the next iteration of the ENUM Experiences Draft. Some history Peter: The text about EDNS0 started out in that draft by Lawrence and Kazunori Fujiwara. It was felt that it needed to be extracted and put into a standards-track draft. Since the experiences draft is likely to end up as an informational RFC, that would not be the appropriate place for documenting mandatory implementation requirements. So this is why we have the EDNS0 draft and normative references to it in the experiences draft. Hopefully this means we end up with a short standards-track RFC that says "use EDNS0" and an experiences draft that recommends appropriate payload sizes based on, well... operational experience. > "Firewalls must not interfere with solicited legal traffic." > This is a problematic approach in that I can't imagine what the > practical outcome is. This is a "don't drink and drive" style > recommendation. > Also, the question whether or not these strategies are "in error" > may be > viewed differently. The "unknown==hostile" approach isn't too > uncommon. True enough. But without a document that says EDNS0 to be expected and must not be blocked, what hope is there of getting broken stuff fixed or expecting new stuff to work properly? If my firewall is broken, there's more chance of the vendor doing something about that if I can point them at a standards-track RFC that says why it's broken. ie It can be proven that the problem is a bug and not a feature. > Again, I doubt that ruling the behaviour of any such device with > normative > language is helpful. Let's turn this around. Is this normative language unhelpful? In the worst-case scenario, it makes no difference IMO. For anything better than that, it provides an unambiguous reference to developers to do the Right Thing. Of course whether they choose to do that or not is another story. But at least the requirement has been documented. >> It should be noted that mandating the use of EDNS0 by ENUM-related >> entities also facilitates the deployment of Secure DNS, DNSSEC, >> currently defined in RFC4033 [12], RFC4034 [13] and RFC4035 [14]. >> Secure DNS will be necessary to verify the integrity of ENUM >> responses. RFC3225 [9] states that clients signal their >> ability to >> handle signed responses via the DO (DNSSEC OK) bit in the EDNS0 >> header and a name server will not return these unless this bit is >> set. So unless EDNS0 is used, ENUM-related entities will be >> unable >> to verify DNSSEC-signed responses from the DNS. Signed replies >> from > > This is already covered by the DNSSEC spec, and thus is misleading > here. > In addition, the document uses EDNS0 as synonym for "payload size > negotiation" and then now concludes that you'd need the OK bit? > I'm glad to see a recommendation for DNSSEC in ENUMland, but this > particular > linking appears a bit arbitrary. I don't understand why you think this is misleading or arbitrary. Perhaps you could provide alternate text? The text above is just telling implementors that they're eventually going to need EDNS0 anyway because of DNSSEC. So if a developer thinks they might be able to weasel out of supporting EDNS0 -- say because they believe everyone will have tiny NAPTR RRsets -- they can think again. In other words, if you're writing an ENUM client for a handset you're going to need EDNS0 support because DNSSEC is just around the corner. Secure DNS is going to be done in six months, isn't it? :-) > Finally, in addition to all these considerations of size, the WG > should > also discuss the NAPTR RR's subtyping problem and potential > consequences of > the proliferation of enum service specifications. IMO that's for the experiences draft (or maybe another one on enum service definitions), not this one. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 27 10:19:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8bm-0003a6-Ub; Thu, 27 Oct 2005 10:19:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8bl-0003Wx-NM for enum@megatron.ietf.org; Thu, 27 Oct 2005 10:19:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02431 for ; Thu, 27 Oct 2005 10:19:42 -0400 (EDT) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV8p8-0003fG-3e for enum@ietf.org; Thu, 27 Oct 2005 10:33:47 -0400 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j9REJsd3020391; Thu, 27 Oct 2005 15:19:54 +0100 (BST) In-Reply-To: <20051027102632.GA27446@nic.at> References: <20051024131257.GA14425@nic.at> <200510260356.JAA29523@iconsrv6.india.hp.com> <20051027102632.GA27446@nic.at> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt] Date: Thu, 27 Oct 2005 15:19:48 +0100 To: Otmar Lendl X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Oct 27, 2005, at 11:26, Otmar Lendl wrote: > The timeout requirements regarding ENUM may be different than for > other > DNS lookups. Agreed. Someone needs to capture those requirements: ie how long will it be after someone picks up an ENUM handset before they get a ring signal? > I don't like your reference to res_*(). These calls are not defined > in your API. > You're implying that any implementation of your API will be based on > libresolv and not some other DNS library like adns or firedns. True enough, but libresolv (for all its many faults) is ubiquitous. The DNS is badly in need of a decent API. And not just for ENUM. So far nobody has shown much interest in working on this or funding it. So until that changes, we're pretty much stuck with an API that's almost 20 years old. > Furthermore, I don't think that the timeout configuration in libresolv > is all that helpful as you can only set RES_RETRANS and RES_RETRY for > individual servers and not an overall timeout. These parameters only affect the stub resolver. So they're not much help if the recursive server that gets these queries is playing by different rules. > IMHO a feature-complete ENUM API should also contain functions to: > > * query more than one tree in parallel > * asynchronous operation > > As I'm doing some programming on the Asterisk ENUM code again I would > really appreciate a decent API for ENUM lookups to rely on. Indeed. But who can develop this API and steer it through the likes of X/Open or IEEE? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 27 10:51:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV96P-0003zI-EZ; Thu, 27 Oct 2005 10:51:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV953-0003Vd-VZ; Thu, 27 Oct 2005 10:50:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04010; Thu, 27 Oct 2005 10:49:57 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV9II-0004XU-1N; Thu, 27 Oct 2005 11:03:57 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EV94t-0000Kb-Bj; Thu, 27 Oct 2005 10:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 27 Oct 2005 10:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-epp-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Validation Information Mapping for the Extensible Provisioning Protocol Author(s) : B. Hoeneisen Filename : draft-ietf-enum-validation-epp-01.txt Pages : 25 Date : 2005-10-27 This document describes an EPP extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range), which the ENUM domain name is based on. Specified in XML, this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM domain names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-epp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-validation-epp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-validation-epp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-27103543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-validation-epp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-validation-epp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27103543.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Thu Oct 27 13:55:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVByB-00052L-Bf; Thu, 27 Oct 2005 13:55:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBy9-00051w-GD for enum@megatron.ietf.org; Thu, 27 Oct 2005 13:55:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18689 for ; Thu, 27 Oct 2005 13:55:00 -0400 (EDT) Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVCBX-0005Y0-L7 for enum@ietf.org; Thu, 27 Oct 2005 14:09:09 -0400 Received: from mail-int1.denic.de (mail-int1.denic.de [192.168.0.45]) by smtp.denic.de with esmtp id 1EVBxu-0006Mn-8p; Thu, 27 Oct 2005 19:55:02 +0200 Received: from localhost by mail-int1.denic.de with local id 1EVBxq-0000j0-00; Thu, 27 Oct 2005 19:54:58 +0200 Date: Thu, 27 Oct 2005 19:54:58 +0200 From: Peter Koch To: IETF ENUM WG Subject: Re: [Enum] Re: I-D ACTION:draft-conroy-enum-edns0-01.txt Message-ID: <20051027175458.GB10983@denics7.denic.de> References: <20051026182142.GU16044@denics7.denic.de> <5247FEA3-3AA3-45DF-B169-F872AAC47A8B@rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5247FEA3-3AA3-45DF-B169-F872AAC47A8B@rfc1035.com> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jim Reid wrote: > Well if it's not done in that way through some sort of standards- > track RFC, what other approach would you suggest? IMO without such a It depends on who you want to address. First, there's vendors of applications issuing ENUM queries, then there's vendors and operators of servers for e164.arpa zones, vendors and operators of intermediate DNS systems (recursive servers, caches, ...) and vendors and operators of other infrastructure. A standards document might be aimed at the first group, but for the other ones it's an operational issue. E.g. there is no "ENUM (aware) name server", it's the operator's task to pick the right gear. How would you assess that a requirement like this Intermediate nodes MUST NOT block valid ENUM queries and responses that indicate EDNS0 support, even if these are larger that the size given in RFC1035. is ready for Draft status? Do those firewalls implement ENUM? > document, implementors have nothing to go on. If there's nothing that > says "you've got to support EDNS0" (and explains why), there's a good > chance EDNS0 support won't make it into ENUM-aware handsets. Making Ok, this covers the client/querier side. > Maybe. But this draft isn't really about firewalls or routers. And See the above quote. > these should alredy be supporting EDNS0 anyway. And again, unless > there's something that says EDNS0 is mandatory in ENUM -- which I > think we agree it should be -- where's the incentive for vendors to > incorporate support for this in their products? They want them to be usable? > >The document does not clearly define what an ENUM query (and therefore > >a response) is. Is it a query for anything in the e164.arpa domain or > >just NAPTR queries? > > Queries in e164.arpa, obviously. Sorry, that's not obvious to me (and below it seems not to you either). > >The second sentence is true but the error > >may or may not be due to configuration (could be UDP only SW). > > Peter, you're picking nits. A server that doesn't do TCP after a > truncated response is misconfigured. It is ``broken'' but there might be different reasons. What I was trying to say is that this type of assessment seems misplaced in a requirements doc, especially if this one is about "ENUM queries". > >Also, it should be noted that thi is an obeservation from (parts > >of) the > >none-ENUM (non-NAPTR, non-RR-suffering-from-the-subtyping-problem) > >DNS. > > True enough, but that's a discussion for another working group. Sorry? > We deliberately avoided references to the root servers for the > obvious reasons. Anything that affects root server operations is a > political nightmare. Anyway, all the root servers already support > EDNS0 -- as you know. Besides, those servers need EDNS0 for other > political horrors that are coming to the root zone Real Soon Now like > IPv6 glue and Secure DNS. So what? If it's a requirement that is already fulfilled, where's the problem to state it? ARPA happens to be served by the root servers as well, but you listed that explicitly. But you did not answer my question: why would e164.arpa and arpa servers need to support EDNS0? (and it's irrelevant that they do anyway) > Now we could have said "lookups under > e164.arpa must use EDNS0". But that would pre-judge whatever domain > name is chosen for Carrier ENUM. > It would also exclude the ENUM-like stuff that the GSM people are > doing under their bogus .gprs TLD. Sigh. In one of the earlier responses you said that en "ENUM query" is for anything below "e164.arpa", now you're extending the scope? > experiences draft. Hopefully this means we end up with a short > standards-track RFC that says "use EDNS0" and an experiences draft > that recommends appropriate payload sizes based on, well... > operational experience. Thanks for that explanation, my last read of the experiences draft dates a while back. However, I don't follow here. What's the point of mandating the EDNS0 feature without at the same time setting minimum standards for the payload size? > True enough. But without a document that says EDNS0 to be expected > and must not be blocked, what hope is there of getting broken stuff > fixed or expecting new stuff to work properly? If my firewall is > broken, there's more chance of the vendor doing something about that > if I can point them at a standards-track RFC that says why it's > broken. ie It can be proven that the problem is a bug and not a feature. So, you are saying that the firewall vendor is more "impressed" by normative language in an RFC that they've never heard of than by a DNS protocol extension used by their customers (and that they've also never heard of)? You're mixing policy and protocol. > Let's turn this around. Is this normative language unhelpful? In the That's a weak justification. > another story. But at least the requirement has been documented. Yes, but that's an operational requirement. > to weasel out of supporting EDNS0 -- say because they believe > everyone will have tiny NAPTR RRsets -- they can think again. In > other words, if you're writing an ENUM client for a handset you're > going to need EDNS0 support because DNSSEC is just around the corner. This effort looks more like an application developers "pick the right DNS underwear" guideline than a standards track document. DNSSEC is more complex than EDNS0; EDNS0 is mandatory for DNSSEC, but it's not the enabler as your text suggested. What's more important is the combined size requirements. Personally I like the "Secure DNS will be necessary to verify the integrity of ENUM responses" easter egg. Attempt of summary: We agree that EDNS0 (with reasonable payload sizes) is the right way to deal with huge NAPTR responses. My suggestion is that the document should skip the normative language on firewalls ("intermediaries") and all the side issues but instead should clearly focus on the resolver (application using the ~) side. In fact, doing this once for all DDDS applications would even be better. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 27 15:55:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDqc-0000RA-UD; Thu, 27 Oct 2005 15:55:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDqZ-0000QI-PA for enum@megatron.ietf.org; Thu, 27 Oct 2005 15:55:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26027 for ; Thu, 27 Oct 2005 15:55:19 -0400 (EDT) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVE3x-0000xh-Gv for enum@ietf.org; Thu, 27 Oct 2005 16:09:28 -0400 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j9RJtRd3020681; Thu, 27 Oct 2005 20:55:28 +0100 (BST) In-Reply-To: <20051027175458.GB10983@denics7.denic.de> References: <20051026182142.GU16044@denics7.denic.de> <5247FEA3-3AA3-45DF-B169-F872AAC47A8B@rfc1035.com> <20051027175458.GB10983@denics7.denic.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <409D8662-809A-44B2-8667-44253211B2F6@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] Re: I-D ACTION:draft-conroy-enum-edns0-01.txt Date: Thu, 27 Oct 2005 20:55:21 +0100 To: Peter Koch X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Cc: IETF ENUM WG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Oct 27, 2005, at 18:54, Peter Koch wrote: > How would you assess that a requirement like this > > Intermediate nodes MUST NOT block valid ENUM queries and > responses > that indicate EDNS0 support, even if these are larger that the > size given in RFC1035. > > is ready for Draft status? IMO, yes. Besides, this is for the WG to decide. > Do those firewalls implement ENUM? I don't care. All that matters is they don't erroneously block EDNS0 traffic. As some well-known firewalls are currently known to do. >> Maybe. But this draft isn't really about firewalls or routers. And > > See the above quote. You're obsessing about this Peter. The context should be simple. If ENUM clients use EDNS0 and ENUM name servers use EDNS0, anything in between shouldn't mess with those packets. That's all. >> these should alredy be supporting EDNS0 anyway. And again, unless >> there's something that says EDNS0 is mandatory in ENUM -- which I >> think we agree it should be -- where's the incentive for vendors to >> incorporate support for this in their products? > > They want them to be usable? Well it hasn't worked so far. We seem to agree that EDNS0 support in clients and name servers makes them more usable. From our perspective, this is a Good Thing as it cuts down on TCP retries. An applications developer's perspective will be different: I do an ENUM lookup and get an answer. Eventually. I don't care if this causes extra delays or TCP queries. My code never sees what goes on underneath a call to the resolver API. My code is "usable" because it works and I get an answer from the DNS. So it all depends on the definition of "usable". >> Peter, you're picking nits. A server that doesn't do TCP after a >> truncated response is misconfigured. > > It is ``broken'' but there might be different reasons. What I was > trying to > say is that this type of assessment seems misplaced in a > requirements doc, > especially if this one is about "ENUM queries". s/misconfigured/broken/ Does that satisfy you? >>> Also, it should be noted that thi is an obeservation from (parts >>> of) the none-ENUM (non-NAPTR, non-RR-suffering-from-the-subtyping- >>> problem) DNS. >> >> True enough, but that's a discussion for another working group. > > Sorry? Debates about the merits of RR subtyping largely belong elsewhere -- dnsext? > In one of the earlier responses you said that en "ENUM query" is for > anything below "e164.arpa", now you're extending the scope? No. I'm just not prejudging the outcome of what might emerge from the WG's Carrier ENUM discussions or the documents that ETSI or the GSMA could chuck over the wall to the WG. >> experiences draft. Hopefully this means we end up with a short >> standards-track RFC that says "use EDNS0" and an experiences draft >> that recommends appropriate payload sizes based on, well... >> operational experience. > > Thanks for that explanation, my last read of the experiences draft > dates > a while back. However, I don't follow here. What's the point of > mandating > the EDNS0 feature without at the same time setting minimum > standards for > the payload size? To be sure EDNS0 support makes it into ENUM clients, especially handsets. Payload size comes later. FWIW, RFC3225 says nothing about DNSSEC payload size either. > So, you are saying that the firewall vendor is more "impressed" by > normative > language in an RFC that they've never heard of than by a DNS protocol > extension used by their customers (and that they've also never > heard of)? > You're mixing policy and protocol. No. I'm saying that if ENDS0 is made mandatory for ENUM, operators have something they can add to their procurement criteria. And show to their suppliers who might otherwise quibble about supporting EDNS0. >> to weasel out of supporting EDNS0 -- say because they believe >> everyone will have tiny NAPTR RRsets -- they can think again. In >> other words, if you're writing an ENUM client for a handset you're >> going to need EDNS0 support because DNSSEC is just around the corner. > > This effort looks more like an application developers "pick the right > DNS underwear" guideline than a standards track document. That may well be true. However if that "choose the right DNS underwear" guidance doesn't appear as some sort of standards track document, you can be sure manufacturers will not pay enough attention to it. Especially in the telco world. > We agree that EDNS0 (with reasonable payload sizes) is the right > way to deal > with huge NAPTR responses. My suggestion is that the document > should skip > the normative language on firewalls ("intermediaries") and all the > side > issues but instead should clearly focus on the resolver (application > using the ~) side. I wish I could agree Peter. IMO the draft can't talk about EDNS0 support in clients (and by implication for ENUM name servers) without mentioning intermediate nodes. There's no point in my client talking EDNS0 to your name server if some box in between is going to barf over those packets. How can we resolve this? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 28 11:52:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWWz-000354-7P; Fri, 28 Oct 2005 11:52:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWWx-00034z-NT for enum@megatron.ietf.org; Fri, 28 Oct 2005 11:52:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25837 for ; Fri, 28 Oct 2005 11:52:19 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVWkX-0001g8-Jf for enum@ietf.org; Fri, 28 Oct 2005 12:06:39 -0400 Received: from [10.31.13.210] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9SFqwd0017780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Oct 2005 08:53:00 -0700 Message-ID: <4362492E.9050808@shockey.us> Date: Fri, 28 Oct 2005 11:52:14 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: multipart/mixed; boundary="------------040302090405030809000705" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [Enum] [Fwd: I-D ACTION:draft-shin-enum-emib-00.txt] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------040302090405030809000705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-shin-enum-emib-00.txt Date: Thu, 27 Oct 2005 02:50:01 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extension MIB for ENUM management Author(s) : Y. Shin Filename : draft-shin-enum-emib-00.txt Pages : 8 Date : 2005-10-26 It is service that ENUM replaces existent IP by telephone number and a user does various kinds devices so that is available by one peculiar number. As this ENUM's DNS becomes bulky, we need monitoring for ENUM. There is MIB to monitoring method that is used present. We propose standard for efficient ENUM DNS administration applying extension MIB that is this MIB's extension to ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shin-enum-emib-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shin-enum-emib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shin-enum-emib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --------------040302090405030809000705 Content-Type: Message/External-body; name="draft-shin-enum-emib-00.txt" Content-Disposition: inline; filename="draft-shin-enum-emib-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-10-26190014.I-D@ietf.org> --------------040302090405030809000705 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------040302090405030809000705-- From enum-bounces@ietf.org Fri Oct 28 12:10:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWob-0008At-D5; Fri, 28 Oct 2005 12:10:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWoa-00089q-83 for enum@megatron.ietf.org; Fri, 28 Oct 2005 12:10:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26646 for ; Fri, 28 Oct 2005 12:10:31 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVX2A-00028K-Q9 for enum@ietf.org; Fri, 28 Oct 2005 12:24:51 -0400 Received: from [10.31.13.210] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9SGB9a9019770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Oct 2005 09:11:12 -0700 Message-ID: <43624D70.3040201@shockey.us> Date: Fri, 28 Oct 2005 12:10:24 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Content-Transfer-Encoding: 7bit Subject: [Enum] FINAL AGENDA ENUM WG IETF 64 Vancouver X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org IETF 64 Vancouver Telephone Number Mapping (ENUM) WG Agenda FINAL Chair(s): Patrik Faltstrom Richard Shockey WG Secretary: Alex Mayrhofer Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: Allison Mankin TUESDAY, November 8, 2005 AGENDA BASHING (5 min) RECHARTER DISCUSSION (CURRENT PROPOSAL) (15 MIN ) The ENUM working group has defined a DNS-based architecture and protocol [RFC 3761] by which an E.164 number, as defined in ITU Recommendation E.164, can be expressed as a Fully Qualified Domain Name in a specific Internet Infrastructure domain defined for this purpose (e164.arpa). Background: E.164 numbers are globally unique, language independent identifiers for resources on Public Telecommunication Networks that can support many different services and protocols. There is an emerging desire for network operators to utilize aspects of RFC 3761 to discover points of interconnection necessary to terminate communications sessions identified by a E164 number,in addition to identifying end point protocols and services. Working Group Revised Goals and Scope: 1. The working group will update RFC 3761 and advance to Draft Standard. 2. The working group will examine and document the use of RFC 3761 to facilitate network interconnection for services using E.164 addressing. The working group will coordinate its activities with other IETF working groups, existing or to be chartered, that are investigating elements of peering and or interconnection for VoIP or other services that typically use E.164 addressing. 3. The working group will continue examine and document various aspects of ENUM administrative and /or operational procedures irrespective of whether e164.arpa domain is used. 4. The working group will also examine the use of RFC 3761 technology for storing and delivering other information about services addressed by E.164 numbers, for example PSTN call routing and signaling data. 5. The Working Group will continue to maintain appropriate contact and liaison with other standards bodies and groups, specifically ITU-T SG2, to provide technical or educational information and address, as needed, issues related to the use of the E.164 numbering plan for services on IP networks. In addition the Working Group will continue to encourage the exchange of technical information within the emerging global ENUM community as well as documentation on practical experiences with implementations, alternate technology uses and the administration and provisioning of RFC 3761. 6. As described in RFC 3761, the IETF documents and registers the Enumservices. While extant, it is the ENUM working group that performs the technical review and development of the Enumservices for the Internet community. The working group determines whether to advance them and how to progress them technically. Coordination with other WGs will be taken into account on these. Other than Enumservices, all proposed deliverables of the working group will be discussed with and approved by the Area Directors, who may require wider review due to the broad impact of the subject. Goals and Milestones March 06 Enumservice Registration for Local Number Portability and Related Data as a Proposed Standard April 06 Requirements for Carrier Interconnection using ENUM as an Informational June 06 Carrier Interconnection using ENUM as a Proposed Standard July 06 ENUM Privacy and Security Considerations as an Informational August 06 Advancement of RFC 3761 to Draft Standard 2. Ready to Go Items. ENUM Implementers Draft: (Final Version) 5 MIN Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-03.txt Pages : 33 Date : 2005-10-18 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is advisory, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-03.txt DNS issues 10-M B. Title : ENUM Requirement for EDNS0 Support Author(s) : L. Conroy, J. Reid Filename : draft-conroy-enum-edns0-01.txt Pages : 16 Date : 2005-10-25 This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support ENUM query resolution (as defined in RFC3761). This requirement is needed as DNS responses to ENUM-related questions return larger sets of Resource Records than typical DNS messages. Without EDNS0 support in all the involved entities, a fallback to TCP transport for ENUM queries and responses would typically occur. That has a severe impact on DNS Server load, and on latency of ENUM queries. This document updates RFC3761 only in adding this requirement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-conroy-enum-edns0-01.txt 3. New Work Items. A. Title : IANA Registration for Enumservice vCard 10-Min Author(s) : A. Mayrhofer, D. Lindner Filename : draft-mayrhofer-enum-vcard-00.txt Pages : 7 Date : 2005-10-5 This memo registers the Enumservice "vCard" using the URI schemes "http" and "https" according to the IANA Enumservice registration process described in RFC3671. This Enumservice is to be used to refer from an ENUM domain name to the vCard of the entity using the corresponding E.164 number. Clients may use information gathered from those vCards before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before he picks up the call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-vcard-00.txt B. Title : IANA Registration for IAX Enumservice ( 10-Min ) Author(s) : E. Guy Filename : draft-guy-enumiax-00.txt Pages : 11 Date : 2005-10-20 This document registers the IAX2 Enumservice using the URI scheme 'iax2:' as per the IANA registration process defined in the ENUM specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-guy-enumiax-00.txt Title : An ENUM Library API ( 5 Min WG Chairs will lead discussion ) Author(s) : T. Sajitha Filename : draft-sajitha-enum-api-00.txt Pages : 7 Date : 2005-10-21 This draft defines a library API for ENUM. The API takes telephone number as input and returns the URI associated with that telephone number. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sajitha-enum-api-00.txt 4 Old Items: A. Carrier ENUM Requirements? ( 15 - M ) Title : Carrier/Infrastrucure ENUM Requirements Author(s) : S. Lind, et al. Filename : draft-lind-infrastructure-enum-reqs-01.txt Pages : 7 Date : 2005-10-21 This document provides requirements for "infrastructure" or "carrier" ENUM, defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoI A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lind-infrastructure-enum-reqs-01.txt Title : Combined User and Carrier ENUM in the e164.arpa tree ( 15 - M ) Author(s) : M. Haberler, R. Stastny Filename : draft-haberler-carrier-enum-01.txt Pages : 15 Date : 2005-10-21 ENUM as defined now in RFC3761 [1] is not well suited for the purpose of interconnection by carriers, as can be seen by the use of various private tree arrangements based on ENUM mechanisms. A combined end- user and carrier ENUM tree solution would leverage the ENUM infrastructure in e164.arpa, increase resolution rates, and decrease the cost per registered telephone number. This document describes a minimally invasive scheme to provide both end-user and carrier data in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-01.txt B. IANA Registration for an Enumservice Containing PSTN Signaling Information draft-ietf-enum-pstn-01 ( 10 Min ) C. Validation Drafts ( 10 Min ) Title : ENUM Validation Architecture Author(s) : A. Mayrhofer, B. Hoeneisen Filename : draft-ietf-enum-validation-arch-00.txt Pages : 16 Date : 2005-10-6 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-00.txt Title : ENUM Validation Token Format Definition Author(s) : O. Lendl Filename : draft-ietf-enum-validation-token-00.txt Pages : 16 Date : 2005-10-10 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-token-00.txt Title : ENUM Validation Information Mapping for the Extensible Provisioning Protocol Author(s) : B. Hoeneisen Filename : draft-ietf-enum-validation-epp-01.txt Pages : 25 Date : 2005-10-27 This document describes an EPP extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range), which the ENUM domain name is based on. Specified in XML, this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM domain names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-epp-01.txt ???????????? Title : Extension MIB for ENUM management Author(s) : Y. Shin Filename : draft-shin-enum-emib-00.txt Pages : 8 Date : 2005-10-26 It is service that ENUM replaces existent IP by telephone number and a user does various kinds devices so that is available by one peculiar number. As this ENUM's DNS becomes bulky, we need monitoring for ENUM. There is MIB to monitoring method that is used present. We propose standard for efficient ENUM DNS administration applying extension MIB that is this MIB's extension to ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shin-enum-emib-00.txt 5 General Discussion. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 28 12:17:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWvS-0005Xh-0V; Fri, 28 Oct 2005 12:17:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWvQ-0005Uq-Nn for enum@megatron.ietf.org; Fri, 28 Oct 2005 12:17:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27107 for ; Fri, 28 Oct 2005 12:17:35 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVX90-0002Mp-Nm for enum@ietf.org; Fri, 28 Oct 2005 12:31:56 -0400 Received: from [10.31.13.210] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9SGIGF7020533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Oct 2005 09:18:17 -0700 Message-ID: <43624F1B.2040801@shockey.us> Date: Fri, 28 Oct 2005 12:17:31 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: [Enum] Presentation Materials for IETF 64 Vancouver X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The situation is different this year in that the WG Chairs must manage the process of posting Presentation materials for the Proceedings themselves. This is not a big deal but I can also post meeting materials in advance so people can take a look at them before or during the meeting etc. https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64 So all PPT files you plan on presenting etc send to me and I'll get them posted in advance if you wish. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 28 12:35:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVXC1-0006WT-RW; Fri, 28 Oct 2005 12:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVXBy-0006WE-Jb for enum@megatron.ietf.org; Fri, 28 Oct 2005 12:35:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27678 for ; Fri, 28 Oct 2005 12:34:41 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVXPY-0002lU-TA for enum@ietf.org; Fri, 28 Oct 2005 12:49:02 -0400 Received: from [10.31.13.210] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9SGZM8P023235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 09:35:24 -0700 Message-ID: <4362531F.8030106@shockey.us> Date: Fri, 28 Oct 2005 12:34:39 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Reid Subject: Re: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt] References: <20051024131257.GA14425@nic.at> <200510260356.JAA29523@iconsrv6.india.hp.com> <20051027102632.GA27446@nic.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Otmar Lendl X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > > These parameters only affect the stub resolver. So they're not much > help if the recursive server that gets these queries is playing by > different rules. > >> IMHO a feature-complete ENUM API should also contain functions to: >> >> * query more than one tree in parallel >> * asynchronous operation >> >> As I'm doing some programming on the Asterisk ENUM code again I would >> really appreciate a decent API for ENUM lookups to rely on. > > > Indeed. But who can develop this API and steer it through the likes of > X/Open or IEEE? This is the question I have for this document. Are API's an appropriate standardization task for the IETF? IMHO no. but I'd like some one to convince me otherwise or show me other examples of API's in the IETF along with the underlying justification and problem statement as to why the work should be done here. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 28 12:38:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVXFm-00010d-Mw; Fri, 28 Oct 2005 12:38:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVXFl-00010Y-3H for enum@megatron.ietf.org; Fri, 28 Oct 2005 12:38:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27938 for ; Fri, 28 Oct 2005 12:38:36 -0400 (EDT) Received: from bay103-f15.bay103.hotmail.com ([65.54.174.25] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVXTK-0002tf-BT for enum@ietf.org; Fri, 28 Oct 2005 12:52:56 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 28 Oct 2005 09:38:39 -0700 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Fri, 28 Oct 2005 16:38:38 GMT X-Originating-IP: [66.218.34.195] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <43624D70.3040201@shockey.us> From: "Peter Williams" To: enum@ietf.org Subject: RE: [Enum] FINAL AGENDA ENUM WG IETF 64 Vancouver Date: Fri, 28 Oct 2005 09:38:38 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Oct 2005 16:38:39.0528 (UTC) FILETIME=[0CE1E280:01C5DBDE] X-Spam-Score: 1.5 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org "Other than Enumservices, all proposed deliverables of the working group will be discussed with and approved by the Area Directors, who may require wider review due to the broad impact of the subject. " We need to address this proposed amendment, transparently. We already have the IESG issued last call that call for outside comments on the WGs opinion on last call standing. Why does ENUM WG need such a special rule, and what issues motivated this amendment? Less formally, this issue addresses the ADs job. If our ADs needs such "special agent powers" to be assigned in the WG charter, are they suited to being an IETF AD? The scope of the requested powers is conventional AD work, after all, working with IESG to further the standards track status of documents, and IAB to perform oversight. Why would a AD want a AD-specific veto, when an AD can and should influence IESG to use existing procedural powers to require changes? If something remarkable in the ENUM WG rechartering case requires the special powers, we need a _transparent_ process for administering the new powers of the ENUM ADs. One assumes that such powers are required on the basis of the new questions that FORCED rechartering. It is a fascinating, proposed amendment. >From: Richard Shockey >To: "'enum@ietf.org'" >Subject: [Enum] FINAL AGENDA ENUM WG IETF 64 Vancouver >Date: Fri, 28 Oct 2005 12:10:24 -0400 > >IETF 64 Vancouver Telephone Number Mapping (ENUM) WG Agenda FINAL > >Chair(s): >Patrik Faltstrom >Richard Shockey > > >WG Secretary: >Alex Mayrhofer > > >Transport Area Director(s): >Allison Mankin >Jon Peterson > >Transport Area Advisor: >Allison Mankin _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 28 15:50:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVaFX-0007DC-EN; Fri, 28 Oct 2005 15:50:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVaEm-00071a-Vt; Fri, 28 Oct 2005 15:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05195; Fri, 28 Oct 2005 15:49:46 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVaSN-0007kE-R5; Fri, 28 Oct 2005 16:04:08 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EVaEj-0007qw-Rg; Fri, 28 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 28 Oct 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-pstn-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA05195 A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Telephone Number Mapping Working Group o= f the IETF. Title : IANA Registration for an Enumservice Containing PSTN Signaling = Information Author(s) : J. Livingood, R. Shockey Filename : draft-ietf-enum-pstn-00.txt Pages : 11 Date : 2005-10-28 =09 This document registers the Enumservice =93pstn=94 and subtype =93tel=94=20 using the URI scheme =91tel:=92, as well as the subtype =93sip=94 usin= g the=20 URI scheme =91sip=92 as per the IANA registration process defined in t= he=20 ENUM specification, RFC 3761. This data is used to facilitate the=20 routing of telephone calls in those countries where Number=20 Portability exists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-pstn-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of th= e message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the usern= ame "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-pstn-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-pstn-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-28135327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-pstn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-pstn-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-28135327.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Sat Oct 29 16:31:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVxMq-0005nd-Bq; Sat, 29 Oct 2005 16:31:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVxMo-0005nU-Jn; Sat, 29 Oct 2005 16:31:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23290; Sat, 29 Oct 2005 16:31:35 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVxac-0006kG-KB; Sat, 29 Oct 2005 16:46:13 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9TKWArL028351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Oct 2005 13:32:17 -0700 Message-ID: <4363DC1D.6090705@shockey.us> Date: Sat, 29 Oct 2005 16:31:25 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id j9TKWArL028351 X-Spam-Score: 0.8 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: "iptel@ietf.org" , "'enum@ietf.org'" Subject: [Enum] Re: [Iptel] Do we need an IANA registry for tel parameters X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Cullen Jennings wrote: > We decided long ago that we needed one and put the creation of it in th= e > trunk-group draft. However, in tel-np draft we decided not to have a > registry. I don't particularly care one way or the other but I think we= need > to be consistent on this. >=20 > What do folks think? Is there some part of this I am forgetting? Yep times change and IMHO you need a TEL orinented registry if for no=20 other reason some of us want to eventually append a TEL or a SIP URI=20 with other static SS7 paramaters like ;CNAM=3DGeorge W Bush etc. GTT you= =20 name it. Those parameters need to be defined and registered. This btw is the fundamental thrust of my and Jason Livingood's draft Title : IANA Registration for an Enumservice Containing PSTN Signaling=20 Information Author(s) : J. Livingood, R. Shockey Filename : draft-ietf-enum-pstn-00.txt Pages : 11 Date : 2005-10-28 =09 This document registers the Enumservice =93pstn=94 and subtype =93tel=94 using the URI scheme =91tel:=92, as well as the subtype =93sip=94 usi= ng the URI scheme =91sip=92 as per the IANA registration process defined in = the ENUM specification, RFC 3761. This data is used to facilitate the routing of telephone calls in those countries where Number Portability exists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-pstn-00.txt >=20 > Thanks, Cullen >=20 > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel >=20 --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Oct 30 14:24:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWInL-0006Uj-Pz; Sun, 30 Oct 2005 14:24:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWInJ-0006UI-QJ for enum@megatron.ietf.org; Sun, 30 Oct 2005 14:24:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09119 for ; Sun, 30 Oct 2005 14:24:22 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWEav-0004LC-HO for enum@ietf.org; Sun, 30 Oct 2005 09:55:38 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9UEfOBm013351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 30 Oct 2005 06:41:26 -0800 Message-ID: <4364DB68.3090606@shockey.us> Date: Sun, 30 Oct 2005 09:40:40 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Subject: [Enum] [Fwd: [Iptel] IANA Registry Draft] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org FYI ... what is being proposed here is a IANA registry of TEL parameters. IMHO this is a "good thing" tm. -------- Original Message -------- Subject: [Iptel] IANA Registry Draft Date: Sat, 29 Oct 2005 16:49:11 -0700 From: Cullen Jennings To: iptel@ietf.org If we decide we are going to have a registry (and Richard gave some good reasons), we need to define it. In the name of expediting this, I slammed together a draft. Until it shows up in the drafts directory, you can find it at http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-iptel-tel-re g-00.html or ASCII version at http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-iptel-tel-re g-00.txt I apologize if my email mangled the URL. Please note one important item. This draft normatively depends on the existing WG drafts, not the other way around. Cullen (not as chair) _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 31 10:18:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbQv-0004xt-HO; Mon, 31 Oct 2005 10:18:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbQs-0004xI-Mj for enum@megatron.ietf.org; Mon, 31 Oct 2005 10:18:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13738 for ; Mon, 31 Oct 2005 10:18:26 -0500 (EST) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWbf4-0005tY-9h for enum@ietf.org; Mon, 31 Oct 2005 10:33:27 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id j9VFIch4025756Mon, 31 Oct 2005 15:18:39 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1EWbQk-00018y-00; Mon, 31 Oct 2005 15:18:38 +0000 Date: Mon, 31 Oct 2005 15:18:38 +0000 From: "Clive D.W. Feather" To: Richard Shockey Subject: Re: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt] Message-ID: <20051031151838.GK99325@finch-staff-1.thus.net> References: <20051024131257.GA14425@nic.at> <200510260356.JAA29523@iconsrv6.india.hp.com> <20051027102632.GA27446@nic.at> <4362531F.8030106@shockey.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4362531F.8030106@shockey.us> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: enum@ietf.org, Jim Reid , Otmar Lendl X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard Shockey said: > This is the question I have for this document. > > Are API's an appropriate standardization task for the IETF? No. > IMHO no. but I'd like some one to convince me otherwise or show me other > examples of API's in the IETF along with the underlying justification > and problem statement as to why the work should be done here. The only one I've seen as an RFC contained significant fallacies based on a lack of understanding of the C Standard. APIs should be developed in IEEE, X/Open, ISO/IEC, Austin Group, etc. Pick one and petition them to do it. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 31 11:01:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWc60-0006Ge-2m; Mon, 31 Oct 2005 11:01:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWc5y-0006GM-0H for enum@megatron.ietf.org; Mon, 31 Oct 2005 11:01:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16174 for ; Mon, 31 Oct 2005 11:00:53 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcK7-00022S-Qj for enum@ietf.org; Mon, 31 Oct 2005 11:15:55 -0500 Received: from [10.10.0.106] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Mon, 31 Oct 2005 17:00:39 +0100 id 00068361.43663FAB.000008FD Message-ID: <43663F7B.9090105@enum.at> Date: Mon, 31 Oct 2005 16:59:55 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Subject: [Enum] review of draft-ietf-enum-experiences-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org All, having reviewed the ENUM experiences draft, i'd appreciate your comments on the following issues [sorry, comments are a bit out of order]: - The term "ENUM" should be expanded somewhere in the document, most probably in the "Introduction" section where it is mentioned first (if not considering the abstract). Same for "NAPTR". - Section 6 is closely related to the EDNS0 draft - so imho there should be at least a reference to it. However, one of the authors of the EDNS0 draft has already indicated that recent progress there might trigger an update of this section anyways. Other issue: I'm unsure if we want to introduce a dependency here.. - [small nit] The document asks developers to raise "other issues" in the ENUM WG - However, the ID-Checklist recommends to avoid reference to a specific WG for future actions (just in case the WG does not exist anymore). Anyway, i think we're fine here since there is a second contact option (the authors) listed as well. - Section 3, character sets: "SED-like" should be changed to "sed-like" (at least that's how it appears in RFC3402. The RegExp seperator falls a bit short in this section: Unless i've overlooked something, any octec except digits 1-9 and 'i' can be used as seperator according to RFC3402 (section 3.2) - I think that using 0xff (or even 0x00 ?) as seperator would definitely confuse most current clients... The "Client" recommendation should at least mention this. Generally, clients should be prepared for "bad" octets even in the fields where such octects would be illegal. They should be able to drop such records without affecting other records still to be processes. I'm missing a sentence about this somewhere. I could not find out what the acronym "UCS" means in the document - please expand. - Examples: Please change those domain names to RFC2606 compatible names (example.com/net/org). - around Section 4.2 (including the two paragraphs before this section) Please enlighten my where NAPTRs with the same ORDER and PREFERENCE collide with the specs (as long as they bear different services). I read [again] thorugh the relevant sections in RFC3761 and RFC3403, without any luck - am i the guy with the "buggy provisioning system"? ;) that's all for now -- cheers Alex Mayrhofer _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 31 17:23:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWi46-0003UJ-VQ; Mon, 31 Oct 2005 17:23:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWi44-0003U4-0x for enum@megatron.ietf.org; Mon, 31 Oct 2005 17:23:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16113 for ; Mon, 31 Oct 2005 17:23:19 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWiIJ-0005GU-F8 for enum@ietf.org; Mon, 31 Oct 2005 17:38:24 -0500 Received: from [10.31.13.203] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j9VMO1sB014219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Oct 2005 14:24:02 -0800 Message-ID: <43669955.8060000@shockey.us> Date: Mon, 31 Oct 2005 17:23:17 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" , Kerri Hughes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] There are preliinary plans for another ENUM Summit in the US. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Many of you know there was a "ENUM Summit" Conference earlier this year in Miami that was rather successful. The Conference organizers have contacted me again to indicate they are planning on the 2nd Annual ENUM Summit with yours truly once again as Conference Chair. Timing as of this date looks like early to mid April so no conflicts with IETF or VON. Venue TBD but I'm pressing for either JFK/LGA, ORD, SFO or possibly BOS. Folks interested in the conference or have speaking proposals should contact. Kerri Hughes IQPC (International Quality & Productivity Center) 535 5th Ave, 8th Floor New York, NY 10017 P: 212-885-2760 * F: 212-885-2762 kerri.hughes@iqpc.com www.iqpc.com -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 31 21:22:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWlnc-0006m0-N8; Mon, 31 Oct 2005 21:22:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWlna-0006le-A7 for enum@megatron.ietf.org; Mon, 31 Oct 2005 21:22:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03684 for ; Mon, 31 Oct 2005 21:22:34 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWm1s-00031A-QQ for enum@ietf.org; Mon, 31 Oct 2005 21:37:41 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jA12N7nC006580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 31 Oct 2005 18:23:10 -0800 Message-ID: <4366D15F.6070900@shockey.us> Date: Mon, 31 Oct 2005 21:22:23 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: multipart/mixed; boundary="------------090506090903050801080906" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Subject: [Enum] [Fwd: RFC 4238 on Voice Message Routing Service] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------090506090903050801080906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: RFC 4238 on Voice Message Routing Service Date: Mon, 31 Oct 2005 16:56:33 -0800 From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org CC: vpim@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 4238 Title: Voice Message Routing Service Author(s): G. Vaudreuil Status: Standards Track Date: October 2005 Mailbox: GregV@ieee.org Pages: 10 Characters: 18902 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-vpim-routing-10.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4238.txt Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The complete service uses the Voice Profile for Internet Mail (VPIM) Directory service to lookup a VPIM email address with a telephone number and confirm that the address is both valid and associated with the intended recipient. However, this service will take time to become widely deployed in the near term. This document also describes a basic send-and-pray service that routes and delivers messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilities. This document is a product of the Voice Profile for Internet Mail Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. 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. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --------------090506090903050801080906 Content-Type: Message/External-body; name="rfc4238.txt" Content-Disposition: inline; filename="rfc4238.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <051031165521.RFC@RFC-EDITOR.ORG> --------------090506090903050801080906 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --------------090506090903050801080906 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------090506090903050801080906--