From enum-bounces@ietf.org Thu Dec 01 02:16:22 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 1Ehig2-00034P-3C; Thu, 01 Dec 2005 02:16:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehify-000321-3x for enum@megatron.ietf.org; Thu, 01 Dec 2005 02:16:20 -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 CAA00088 for ; Thu, 1 Dec 2005 02:15:30 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehj0O-00021w-Nr for enum@ietf.org; Thu, 01 Dec 2005 02:37:25 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 30 Nov 2005 23:16:11 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jB17G66a001831; Wed, 30 Nov 2005 23:16:06 -0800 (PST) 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 jB17NjeT028376; Wed, 30 Nov 2005 23:23:52 -0800 In-Reply-To: <0IQS000Q6F6CFR@dgismtp06.mcilink.com> References: <0IQS000Q6F6CFR@dgismtp06.mcilink.com> Mime-Version: 1.0 (Apple Message framework v746.2) 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] Re: Update of Carrier ENUM requirements I-D Date: Thu, 1 Dec 2005 08:13:17 +0100 To: timothy.dwight@mci.com X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=2834; t=1133421833; x=1133854033; 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]=20Re=3A=20Update=20of=20Carrier=20ENUM=20requirements=20I -D| From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20| Date:Thu,=201=20Dec=202005=2008=3A13=3A17=20+0100| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=Dt6BQXwyZ3pVV6rs+l36R2FN8fTyi/8oon4DzojJYpiD37oDszjOfTMW6coLQ07UW32eOsS/ 8/45wmtid8R+r1/s3nhBlrRH6Ba2aL83k703AfwtgP/O3Z6XrsVrRLbUI6yy+eyxs4QATBGUMNs Wg6cc9kpg7nFCnAQeHWf+rIs= Authentication-Results: imail.cisco.com; header.From=paf@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.8 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 Be careful... When running DNS, we have one party that is responsible for the DNS service that make DNS records available. We might have a different organization that is deciding what the records are. And then a third party responsible for the service the record refer to. And of course a fourth that is administrative responsible for the domain name itself. Example: Organization A is the registrant for example.com. Organization B is asked to administer the example.com zone (do the provisioning). Organization C is running the DNS that holds the example.com zone. Organization D is running the mailserver MX record for example.com refer to. If you are curious of difference between B and C, think of the root zone where ICANN decide what the content of the root zone is, and the root server operators as a collective is making the zone available. What term you use doesn't matter. The important thing is that you in a terminology section is extremely explicit with what you talk about. paf On 30 nov 2005, at 22.47, Tim Dwight wrote: > I'm not sure that I agree with changing "carrier of record" to > "service > provider of record". Depends on what the latter means I suppose. > If (as > seems intuitive) "service provider" means "the entity that the > customer > perceives as providing the service", and "carrier of record" means > "the > entity providing PSTN access for calls to or from the customer", > then is a > "service provider of record" an entity that does both? And is that > the > appropriate semantic? > > At the risk of inviting flames I'd say that "carrier of record" is the > appropriate term and the Telco-bashing that seems to motivate this > change, > is juvenile. > > Tim > > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > Behalf Of > Richard Shockey > Sent: Wednesday, November 30, 2005 3:31 PM > To: Pfautz, Penn L, NEO > Cc: enum@ietf.org > Subject: [Enum] Re: Update of Carrier ENUM requirements I-D > > Pfautz, Penn L, NEO wrote: >> Having looked over the Vancouver minutes of the WG I want to ask >> if I >> should replace "carrier ENUM" with "infrastructure ENUM" before >> resubmitting draft-lind-infrastructure-enum-reqs-01 as >> draft-ietf-enum-infrastructure-enum-reqs-00. > > Yes .. it seemed to be the consensus of the WG that the word > carrier seems > to be associated with some form of disease. > > >> If so, I would also propose to render "carrier of record" as "service >> provider of record" going forward. > > excellent idea. > >> >> Your views? >> >> Thanks, >> Penn > > -- > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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 Thu Dec 01 03:54:37 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 1EhkD6-0002Ju-Vb; Thu, 01 Dec 2005 03:54:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhkD5-0002Jk-NY for enum@megatron.ietf.org; Thu, 01 Dec 2005 03:54:35 -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 DAA09023 for ; Thu, 1 Dec 2005 03:53:47 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhkXW-0005RE-6y for enum@ietf.org; Thu, 01 Dec 2005 04:15:43 -0500 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 pahula with esmtp; Thu, 01 Dec 2005 09:53:57 +0100 id 0006815F.438EBA25.00004397 Message-ID: <438EBA07.8050501@enum.at> Date: Thu, 01 Dec 2005 09:53:27 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: enum@ietf.org Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-vcard-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Telephone Number Mapping Working Group of the IETF. > > Title : IANA Registration for Enumservice vCard > Author(s) : A. Mayrhofer, D. Lindner > Filename : draft-ietf-enum-vcard-00.txt > Pages : 9 > Date : 2005-11-30 For those who are not going to read this, a short summary of document updates: - name changed to reflect WG adoption - Enumservice now uses subtypes - 4 subtypes defined atm: - "vcard:plain" - simple vCard over http(s) - "vcard:rdf" - vCard as RDF according to W3C note over http(s) - "vcard:xml" - same, but slightly different schema, same W3C note - "vcard:sink" - that's an experimental ided: It defines an email address where the user of the ENUM domain wishes to receive vCards via email. comments appreciated. I have _not_ (yet) added "vcard:carddav" (draft-daboo-carddav-00.txt) now - the author of this draft didn't bother to respond to my mails yet, and adding a dependency on this would definitely slow down the progress of the Enumservice draft. I also have _not_ added IRIS since there is currently no way to represent a vCard in IRIS (there are, however, ways to represent personal data in IRIS, but those would probably be only useful in a more generic "whitepages" Enumservice). I've not modified the security considerations section yet - please send text here if you have better ideas than what is currently in the draft. Feedback is of course appreciated - i'd like to get a feeling if the subtypes chosen reflect what the group considers useful. thanks alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Dec 01 07:57:21 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 1Eho01-00077o-UV; Thu, 01 Dec 2005 07:57:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehnzy-000735-2Z for enum@megatron.ietf.org; Thu, 01 Dec 2005 07:57:20 -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 HAA16379 for ; Thu, 1 Dec 2005 07:56:31 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EhoKQ-0004K9-Sb for enum@ietf.org; Thu, 01 Dec 2005 08:18:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D Date: Thu, 1 Dec 2005 14:00:30 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2265@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Re: Update of Carrier ENUM requirements I-D Thread-Index: AcX2R8hHaAVms+MFSNmmEtLLuJZP6QALe+Tw From: "Stastny Richard" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , X-Spam-Score: 0.8 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff 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 Agreed, but the Carrier-of-Record in Infrastructure ENUM is the pendant to the End-user in User ENUM. I propose to leave the term Carrier-of-Record Reading the meeting minutes, it was agreed to move the definitions in the Haberler draft over to the requirements draft I copy here the relevant part: 2. The Carrier of Record In User ENUM, the entity or person having the right-to-use in a number has the sole discretion about the content of the associated domain and thus the zone content. Within a Carrier ENUM namespace, we use the term "carrier of record" for the entity having that discretion. This right typically lies with a service provider authorized to issue E.164 numbers for the provisioning of PSTN service under the authority of a National Regulatory Authority (NRA), but generally exhibits one or more of the following properties: o it has been assigned one or more national number ranges by an NRA. o it has been assigned a number range directly by the ITU, for instance a code under "International Networks" (+882) or "Universal Personal Telecommunications (UPT)" (+878). o it can be the recipient of a number porting operation. o it provides a PSTN point-of-interconnect for the number. Since it was also mentioned on the list that the term PSTN was too narrow, I propose to replace the term PSTN with=20 Public Available Telephony Service So the sentence will read: This right typically lies with a service provider authorized to issue E.164 numbers for the provisioning of a Publicly Available Telephony Service under the =20 authority of a National Regulatory Authority (NRA), ... This sentence includes BTW also the term "service provider" ;-) Regards Richard > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf = Of > Patrik F=E4ltstr=F6m > Sent: Thursday, December 01, 2005 8:13 AM > To: timothy.dwight@mci.com > Cc: enum@ietf.org > Subject: Re: [Enum] Re: Update of Carrier ENUM requirements I-D >=20 > Be careful... >=20 > When running DNS, we have one party that is responsible for the DNS > service that make DNS records available. We might have a different > organization that is deciding what the records are. And then a third > party responsible for the service the record refer to. And of course > a fourth that is administrative responsible for the domain name = itself. >=20 > Example: >=20 > Organization A is the registrant for example.com. >=20 > Organization B is asked to administer the example.com zone (do the > provisioning). >=20 > Organization C is running the DNS that holds the example.com zone. >=20 > Organization D is running the mailserver MX record for example.com > refer to. >=20 > If you are curious of difference between B and C, think of the root > zone where ICANN decide what the content of the root zone is, and the > root server operators as a collective is making the zone available. >=20 >=20 > What term you use doesn't matter. The important thing is that you in > a terminology section is extremely explicit with what you talk about. >=20 > paf >=20 > On 30 nov 2005, at 22.47, Tim Dwight wrote: >=20 > > I'm not sure that I agree with changing "carrier of record" to > > "service > > provider of record". Depends on what the latter means I suppose. > > If (as > > seems intuitive) "service provider" means "the entity that the > > customer > > perceives as providing the service", and "carrier of record" means > > "the > > entity providing PSTN access for calls to or from the customer", > > then is a > > "service provider of record" an entity that does both? And is that > > the > > appropriate semantic? > > > > At the risk of inviting flames I'd say that "carrier of record" is = the > > appropriate term and the Telco-bashing that seems to motivate this > > change, > > is juvenile. > > > > Tim > > > > > > -----Original Message----- > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > > Behalf Of > > Richard Shockey > > Sent: Wednesday, November 30, 2005 3:31 PM > > To: Pfautz, Penn L, NEO > > Cc: enum@ietf.org > > Subject: [Enum] Re: Update of Carrier ENUM requirements I-D > > > > Pfautz, Penn L, NEO wrote: > >> Having looked over the Vancouver minutes of the WG I want to ask > >> if I > >> should replace "carrier ENUM" with "infrastructure ENUM" before > >> resubmitting draft-lind-infrastructure-enum-reqs-01 as > >> draft-ietf-enum-infrastructure-enum-reqs-00. > > > > Yes .. it seemed to be the consensus of the WG that the word > > carrier seems > > to be associated with some form of disease. > > > > > >> If so, I would also propose to render "carrier of record" as = "service > >> provider of record" going forward. > > > > excellent idea. > > > >> > >> Your views? > >> > >> Thanks, > >> Penn > > > > -- > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > 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 >=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 Thu Dec 01 09:27:59 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 1EhpPj-0005gm-SK; Thu, 01 Dec 2005 09:27:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhpPi-0005dp-2e for enum@megatron.ietf.org; Thu, 01 Dec 2005 09:27:58 -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 JAA26661 for ; Thu, 1 Dec 2005 09:27:10 -0500 (EST) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ehpk8-0007Yt-D2 for enum@ietf.org; Thu, 01 Dec 2005 09:49:09 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-15.tower-121.messagelabs.com!1133447073!7876558!85 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 26497 invoked from network); 1 Dec 2005 14:27:43 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-15.tower-121.messagelabs.com with SMTP; 1 Dec 2005 14:27:43 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 4380ACBE0016833B; Thu, 1 Dec 2005 09:27:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D Date: Thu, 1 Dec 2005 09:27:42 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0BA6C1C5@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Enum] Re: Update of Carrier ENUM requirements I-D Thread-Index: AcX2R8hHaAVms+MFSNmmEtLLuJZP6QALe+TwAANZpYA= From: "Pfautz, Penn L, NEO" To: "Stastny Richard" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , X-Spam-Score: 0.8 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b 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 Richard: I'm fine with the other changes but would prefer to keep the term PSTN. = My memory of PATS is that is has an even more specific meaning and that = some parties issued numbers by NRAs are not PATS. Penn=20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = Stastny Richard Sent: Thursday, December 01, 2005 8:01 AM To: Patrik F=E4ltstr=F6m; timothy.dwight@mci.com Cc: enum@ietf.org Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D Agreed, but the Carrier-of-Record in Infrastructure ENUM is the pendant to the End-user in User ENUM. I propose to leave the term Carrier-of-Record Reading the meeting minutes, it was agreed to move the definitions in the Haberler draft over to the requirements draft I copy here the relevant part: 2. The Carrier of Record In User ENUM, the entity or person having the right-to-use in a number has the sole discretion about the content of the associated domain and thus the zone content. Within a Carrier ENUM namespace, we use the term "carrier of record" for the entity having that discretion. This right typically lies with a service provider authorized to issue E.164 numbers for the provisioning of PSTN service under the authority of a National Regulatory Authority (NRA), but generally exhibits one or more of the following properties: o it has been assigned one or more national number ranges by an NRA. o it has been assigned a number range directly by the ITU, for instance a code under "International Networks" (+882) or "Universal Personal Telecommunications (UPT)" (+878). o it can be the recipient of a number porting operation. o it provides a PSTN point-of-interconnect for the number. Since it was also mentioned on the list that the term PSTN was too narrow, I propose to replace the term PSTN with=20 Public Available Telephony Service So the sentence will read: This right typically lies with a service provider authorized to issue E.164 numbers for the provisioning of a Publicly Available Telephony Service under the =20 authority of a National Regulatory Authority (NRA), ... This sentence includes BTW also the term "service provider" ;-) Regards Richard > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf = Of > Patrik F=E4ltstr=F6m > Sent: Thursday, December 01, 2005 8:13 AM > To: timothy.dwight@mci.com > Cc: enum@ietf.org > Subject: Re: [Enum] Re: Update of Carrier ENUM requirements I-D >=20 > Be careful... >=20 > When running DNS, we have one party that is responsible for the DNS > service that make DNS records available. We might have a different > organization that is deciding what the records are. And then a third > party responsible for the service the record refer to. And of course > a fourth that is administrative responsible for the domain name = itself. >=20 > Example: >=20 > Organization A is the registrant for example.com. >=20 > Organization B is asked to administer the example.com zone (do the > provisioning). >=20 > Organization C is running the DNS that holds the example.com zone. >=20 > Organization D is running the mailserver MX record for example.com > refer to. >=20 > If you are curious of difference between B and C, think of the root > zone where ICANN decide what the content of the root zone is, and the > root server operators as a collective is making the zone available. >=20 >=20 > What term you use doesn't matter. The important thing is that you in > a terminology section is extremely explicit with what you talk about. >=20 > paf >=20 > On 30 nov 2005, at 22.47, Tim Dwight wrote: >=20 > > I'm not sure that I agree with changing "carrier of record" to > > "service > > provider of record". Depends on what the latter means I suppose. > > If (as > > seems intuitive) "service provider" means "the entity that the > > customer > > perceives as providing the service", and "carrier of record" means > > "the > > entity providing PSTN access for calls to or from the customer", > > then is a > > "service provider of record" an entity that does both? And is that > > the > > appropriate semantic? > > > > At the risk of inviting flames I'd say that "carrier of record" is = the > > appropriate term and the Telco-bashing that seems to motivate this > > change, > > is juvenile. > > > > Tim > > > > > > -----Original Message----- > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > > Behalf Of > > Richard Shockey > > Sent: Wednesday, November 30, 2005 3:31 PM > > To: Pfautz, Penn L, NEO > > Cc: enum@ietf.org > > Subject: [Enum] Re: Update of Carrier ENUM requirements I-D > > > > Pfautz, Penn L, NEO wrote: > >> Having looked over the Vancouver minutes of the WG I want to ask > >> if I > >> should replace "carrier ENUM" with "infrastructure ENUM" before > >> resubmitting draft-lind-infrastructure-enum-reqs-01 as > >> draft-ietf-enum-infrastructure-enum-reqs-00. > > > > Yes .. it seemed to be the consensus of the WG that the word > > carrier seems > > to be associated with some form of disease. > > > > > >> If so, I would also propose to render "carrier of record" as = "service > >> provider of record" going forward. > > > > excellent idea. > > > >> > >> Your views? > >> > >> Thanks, > >> Penn > > > > -- > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > 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 >=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 From enum-bounces@ietf.org Thu Dec 01 09:44:41 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 1Ehpft-0005rk-CE; Thu, 01 Dec 2005 09:44:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehpfr-0005pu-4D for enum@megatron.ietf.org; Thu, 01 Dec 2005 09:44:39 -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 JAA28387 for ; Thu, 1 Dec 2005 09:43:47 -0500 (EST) 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 1Ehq0H-0008Ab-AW for enum@ietf.org; Thu, 01 Dec 2005 10:05:46 -0500 Received: from localhost ([127.0.0.1] helo=cyclone.emea.mci.com) by cyclone.emea.mci.com with esmtp (Exim 4.42) id 1EhpfJ-0001Kw-PL; Thu, 01 Dec 2005 14:44:09 +0000 Received: from ocampa.emea.mci.com (borasco [170.127.64.31]) by cyclone.emea.mci.com (4.7.0.120) with ESMTP id ; Thu, 1 Dec 2005 14:43:57 GMT Received: from ms-lon-exgw01.uk.mcilink.com ([170.127.78.40]) by ocampa.emea.mci.com with esmtp (Exim 4.42) id 1EhpfA-0000vi-Te; Thu, 01 Dec 2005 14:43:56 +0000 Received: by ms-lon-exgw01.uk.mcilink.com with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Dec 2005 14:44:13 -0000 Message-ID: From: "Lupton, Ronan" To: "'Pfautz, Penn L, NEO'" , Stastny Richard , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , timothy.dwight@mci.com Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D Date: Thu, 1 Dec 2005 14:43:40 -0000 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: -97.2 (---------------------------------------------------) X-MCI-EMEA-Signature: 0572db9e04a693444d742d1dee02d899 X-Spam-Score: 1.3 (+) X-Scan-Signature: 85fe3afc5d9560be77aa81420052017a 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="===============1872751073==" 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. --===============1872751073== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F685.9ECCCDE8" 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_01C5F685.9ECCCDE8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Penn, I think you might be correct. Richard, as your aware OFCOM are querying the PATS logic and definition below with the EU Commission DG Information Soc. It's highly contentious with XoIP and NGN services, which may be uni or multi directional. *Old might be good e.g. PSTN* (See Or option below which might offer a compromise in meaning) Definition of PATS: Publicly Available Telephone Service Means a service available to the public for originating and receiving national and international calls and access to emergency services = through a number or numbers in a national or international telephone numbering = plan, and in addition may, where relevant, include one or more of the = following services: the provision of operator assistance, directory enquiry = services, directories, provision of public pay phones, provision of service under special terms, provision of special facilities for customers with disabilities or with special social needs and/or the provision of non-geographic services. Ref: http://europa.eu.int/eur-lex/pri/en/oj/dat/2002/l_108/l_10820020424en005= 1007 7.pdf Article 2. Definitions. Page 9 of 27. (c) -> Or we could use this text (b) Ibid: Public Telephone Network Means an electronic communications network which is used to provide = publicly available telephone services; it supports the transfer between network termination points of speech communications, and also other forms of communication, such as facsimile and data. Ronan Lupton -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Pfautz, Penn L, NEO Sent: 01 December 2005 14:28 To: Stastny Richard; Patrik F=E4ltstr=F6m; timothy.dwight@mci.com Cc: enum@ietf.org Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D Richard: I'm fine with the other changes but would prefer to keep the term PSTN. = My memory of PATS is that is has an even more specific meaning and that = some parties issued numbers by NRAs are not PATS. Penn=20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Stastny Richard Sent: Thursday, December 01, 2005 8:01 AM To: Patrik F=E4ltstr=F6m; timothy.dwight@mci.com Cc: enum@ietf.org Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D Agreed, but the Carrier-of-Record in Infrastructure ENUM is the pendant to the End-user in User ENUM. I propose to leave the term Carrier-of-Record Reading the meeting minutes, it was agreed to move the definitions in = the Haberler draft over to the requirements draft I copy here the relevant part: 2. The Carrier of Record In User ENUM, the entity or person having the right-to-use in a number has the sole discretion about the content of the associated domain and thus the zone content. Within a Carrier ENUM namespace, we use the term "carrier of record" for the entity having that discretion. This right typically lies with a service provider authorized to issue E.164 numbers for the provisioning of PSTN service under the authority of a National Regulatory Authority (NRA), but generally exhibits one or more of = the following properties: o it has been assigned one or more national number ranges by an = NRA. o it has been assigned a number range directly by the ITU, for instance a code under "International Networks" (+882) or "Universal Personal Telecommunications (UPT)" (+878). o it can be the recipient of a number porting operation. o it provides a PSTN point-of-interconnect for the number. Since it was also mentioned on the list that the term PSTN was too = narrow, I propose to replace the term PSTN with=20 Public Available Telephony Service So the sentence will read: This right typically lies with a service provider authorized to issue E.164 numbers for the provisioning of a Publicly Available Telephony Service under the =20 authority of a National Regulatory Authority (NRA), ... This sentence includes BTW also the term "service provider" ;-) Regards Richard > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf=20 > Of Patrik F=E4ltstr=F6m > Sent: Thursday, December 01, 2005 8:13 AM > To: timothy.dwight@mci.com > Cc: enum@ietf.org > Subject: Re: [Enum] Re: Update of Carrier ENUM requirements I-D >=20 > Be careful... >=20 > When running DNS, we have one party that is responsible for the DNS=20 > service that make DNS records available. We might have a different=20 > organization that is deciding what the records are. And then a third=20 > party responsible for the service the record refer to. And of course = a=20 > fourth that is administrative responsible for the domain name itself. >=20 > Example: >=20 > Organization A is the registrant for example.com. >=20 > Organization B is asked to administer the example.com zone (do the=20 > provisioning). >=20 > Organization C is running the DNS that holds the example.com zone. >=20 > Organization D is running the mailserver MX record for example.com=20 > refer to. >=20 > If you are curious of difference between B and C, think of the root=20 > zone where ICANN decide what the content of the root zone is, and the = > root server operators as a collective is making the zone available. >=20 >=20 > What term you use doesn't matter. The important thing is that you in = a=20 > terminology section is extremely explicit with what you talk about. >=20 > paf >=20 > On 30 nov 2005, at 22.47, Tim Dwight wrote: >=20 > > I'm not sure that I agree with changing "carrier of record" to=20 > > "service provider of record". Depends on what the latter means I=20 > > suppose. If (as > > seems intuitive) "service provider" means "the entity that the > > customer > > perceives as providing the service", and "carrier of record" means > > "the > > entity providing PSTN access for calls to or from the customer", > > then is a > > "service provider of record" an entity that does both? And is that > > the > > appropriate semantic? > > > > At the risk of inviting flames I'd say that "carrier of record" is=20 > > the appropriate term and the Telco-bashing that seems to motivate=20 > > this change, is juvenile. > > > > Tim > > > > > > -----Original Message----- > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On = Behalf=20 > > Of Richard Shockey > > Sent: Wednesday, November 30, 2005 3:31 PM > > To: Pfautz, Penn L, NEO > > Cc: enum@ietf.org > > Subject: [Enum] Re: Update of Carrier ENUM requirements I-D > > > > Pfautz, Penn L, NEO wrote: > >> Having looked over the Vancouver minutes of the WG I want to ask=20 > >> if I should replace "carrier ENUM" with "infrastructure ENUM"=20 > >> before resubmitting draft-lind-infrastructure-enum-reqs-01 as > >> draft-ietf-enum-infrastructure-enum-reqs-00. > > > > Yes .. it seemed to be the consensus of the WG that the word = carrier=20 > > seems to be associated with some form of disease. > > > > > >> If so, I would also propose to render "carrier of record" as=20 > >> "service provider of record" going forward. > > > > excellent idea. > > > >> > >> Your views? > >> > >> Thanks, > >> Penn > > > > -- > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > 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 >=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 ------_=_NextPart_001_01C5F685.9ECCCDE8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Enum] Re: Update of Carrier ENUM requirements I-D

Penn, I think you might be correct.

Richard, as your aware OFCOM are querying the PATS = logic and definition below with the EU Commission DG Information = Soc.

It's highly contentious with XoIP and NGN services, = which may be uni or multi directional.

*Old might be good e.g. PSTN* (See Or option below = which might offer a compromise in meaning)

Definition of PATS:

Publicly Available Telephone Service

Means a service available to the public for = originating and receiving national and international calls and access = to emergency services through a number or numbers in a national or = international telephone numbering plan, and in addition may, where = relevant, include one or more of the following services: the provision = of operator assistance, directory enquiry services, directories, = provision of public pay phones, provision of service under special = terms, provision of special facilities for customers with disabilities = or with special social needs and/or the provision of non-geographic = services.

Ref: http://europa.eu.int/eur-lex/pri/en/oj/dat/2002/l_108/= l_10820020424en00510077.pdf

Article 2. Definitions. Page 9 of 27. (c)

-> Or we could use this text (b) Ibid:

Public Telephone Network

Means an electronic communications network which is = used to provide publicly available telephone services; it supports the = transfer between network termination points of speech communications, = and also other forms of communication, such as facsimile and = data.



Ronan Lupton


-----Original Message-----
From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] = On Behalf Of Pfautz, Penn L, NEO
Sent: 01 December 2005 14:28
To: Stastny Richard; Patrik F=E4ltstr=F6m; = timothy.dwight@mci.com
Cc: enum@ietf.org
Subject: RE: [Enum] Re: Update of Carrier ENUM = requirements I-D


Richard:
I'm fine with the other changes but would prefer to = keep the term PSTN. My memory of PATS is that is has an even more = specific meaning and that some parties issued numbers by NRAs are not = PATS.

Penn

-----Original Message-----
From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] = On Behalf Of Stastny Richard
Sent: Thursday, December 01, 2005 8:01 AM
To: Patrik F=E4ltstr=F6m; = timothy.dwight@mci.com
Cc: enum@ietf.org
Subject: RE: [Enum] Re: Update of Carrier ENUM = requirements I-D

Agreed,

but the Carrier-of-Record in Infrastructure ENUM is = the pendant to the End-user in User ENUM.

I propose to leave the term Carrier-of-Record

Reading the meeting minutes, it was agreed to move = the definitions in the Haberler draft over to the requirements draft

I copy here the relevant part:

<snip>

2.  The Carrier of Record

   In User ENUM, the entity or person = having the right-to-use in a
   number has the sole discretion about = the content of the associated
   domain and thus the zone = content.

   Within a Carrier ENUM namespace, we use = the term "carrier of record"
   for the entity having that = discretion.  This right typically lies
   with a service provider authorized to = issue E.164 numbers for the
   provisioning of PSTN service under the = authority of a National
   Regulatory Authority (NRA), but = generally exhibits one or more of the
   following properties:

   o  it has been assigned one or more = national number ranges by an NRA.
   o  it has been assigned a number = range directly by the ITU, for
      instance a code under = "International Networks" (+882) or
      "Universal = Personal Telecommunications (UPT)" (+878).
   o  it can be the recipient of a = number porting operation.
   o  it provides a PSTN = point-of-interconnect for the number.

</snip>

Since it was also mentioned on the list that the term = PSTN was too narrow, I propose to replace the term PSTN with
Public Available Telephony Service

So the sentence will read:
   This right typically lies
   with a service provider authorized to = issue E.164 numbers for the
   provisioning of a Publicly Available = Telephony Service under the 
   authority of a National Regulatory = Authority (NRA), ...

This sentence includes BTW also the term = "service provider" ;-)

Regards
Richard


> -----Original Message-----
> From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] = On Behalf
> Of Patrik F=E4ltstr=F6m
> Sent: Thursday, December 01, 2005 8:13 = AM
> To: timothy.dwight@mci.com
> Cc: enum@ietf.org
> Subject: Re: [Enum] Re: Update of Carrier ENUM = requirements I-D
>
> Be careful...
>
> When running DNS, we have one party that is = responsible for the DNS
> service that make DNS records available. We = might have a different
> organization that is deciding what the records = are. And then a third
> party responsible for the service the record = refer to. And of course a
> fourth that is administrative responsible for = the domain name itself.
>
> Example:
>
>   Organization A is the registrant = for example.com.
>
>   Organization B is asked to = administer the example.com zone (do the
> provisioning).
>
>   Organization C is running the DNS = that holds the example.com zone.
>
>   Organization D is running the = mailserver MX record for example.com
> refer to.
>
> If you are curious of difference between B and = C, think of the root
> zone where ICANN decide what the content of the = root zone is, and the
> root server operators as a collective is making = the zone available.
>
>
> What term you use doesn't matter. The important = thing is that you in a
> terminology section is extremely explicit with = what you talk about.
>
>      paf
>
> On 30 nov 2005, at 22.47, Tim Dwight = wrote:
>
> > I'm not sure that I agree with changing = "carrier of record" to
> > "service provider of = record".  Depends on what the latter means I
> > suppose. If (as
> > seems intuitive) "service = provider" means "the entity that the
> > customer
> > perceives as providing the service", = and "carrier of record" means
> > "the
> > entity providing PSTN access for calls to = or from the customer",
> > then is a
> > "service provider of record" an = entity that does both?  And is that
> > the
> > appropriate semantic?
> >
> > At the risk of inviting flames I'd say = that "carrier of record" is
> > the appropriate term and the Telco-bashing = that seems to motivate
> > this change, is juvenile.
> >
> > Tim
> >
> >
> > -----Original Message-----
> > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] = On Behalf
> > Of Richard Shockey
> > Sent: Wednesday, November 30, 2005 3:31 = PM
> > To: Pfautz, Penn L, NEO
> > Cc: enum@ietf.org
> > Subject: [Enum] Re: Update of Carrier ENUM = requirements I-D
> >
> > Pfautz, Penn L, NEO wrote:
> >>  Having looked over the Vancouver = minutes of the WG I want to ask
> >> if I should replace "carrier = ENUM" with "infrastructure ENUM"
> >> before resubmitting = draft-lind-infrastructure-enum-reqs-01 as
> >> = draft-ietf-enum-infrastructure-enum-reqs-00.
> >
> > Yes .. it seemed to be the consensus of = the WG that the word carrier
> > seems to be associated with some form of = disease.
> >
> >
> >> If so, I would also propose to render = "carrier of record" as
> >> "service provider of record" = going forward.
> >
> > excellent idea.
> >
> >>
> >> Your views?
> >>
> >> Thanks,
> >> Penn
> >
> > --
> >
> >
> = >>>>>>>>>>>>>>>>>>= >>>>>>>>>>>>>>>>>>= >>>>>>>>>>>>>>>>>>=
> > 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&g= t; or
> > <mailto:richard.shockey(at= )neustar.biz>
> > <http://www.neustar.biz> ; <http://www.enum.org>
> > = <<<<<<<<<<<<<<<<<<= <<<<<<<<<<<<<<<<<<= <<<<<<<<<<<<<<<<<
> >
> > = _______________________________________________
> > 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=

------_=_NextPart_001_01C5F685.9ECCCDE8-- --===============1872751073== 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 --===============1872751073==-- From enum-bounces@ietf.org Thu Dec 01 09:55:05 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 1Ehppx-00070U-81; Thu, 01 Dec 2005 09:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehppv-0006y0-L3 for enum@megatron.ietf.org; Thu, 01 Dec 2005 09:55:03 -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 JAA00091 for ; Thu, 1 Dec 2005 09:54:16 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EhqAO-00007K-Aw for enum@ietf.org; Thu, 01 Dec 2005 10:16:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Re: Update of Carrier ENUM requirements I-D Date: Thu, 1 Dec 2005 15:58:39 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C46D8@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Re: Update of Carrier ENUM requirements I-D Thread-Index: AcX2hj7ZrdZbTG7YQRa0+NzvR2EokQAAKnT8 From: "Stastny Richard" To: "Lupton, Ronan" , "Pfautz, Penn L, NEO" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Spam-Score: 0.8 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Yes, you both may be correct, Was just a try ;-) =20 PATS may be too restrictive in some countries (note that I did not use the abbreviation) BTW, in Austria the regulator just decided that any "interconnected" VoIP service (in FCC Emergency service meaning) is PATS. There is no ECS. =20 PSTN could do, if we do not find anything else some other proposals: ITU and ETSI sometimes use: PSTN/ISDN/PLMN we could also use Telephone Services according E.105 =20 Richard =20 =20 ________________________________ Von: Lupton, Ronan [mailto:ronan.lupton@ie.mci.com] Gesendet: Do 01.12.2005 15:43 An: 'Pfautz, Penn L, NEO'; Stastny Richard; Patrik F=E4ltstr=F6m; = timothy.dwight@mci.com Cc: enum@ietf.org Betreff: RE: [Enum] Re: Update of Carrier ENUM requirements I-D Penn, I think you might be correct.=20 Richard, as your aware OFCOM are querying the PATS logic and definition = below with the EU Commission DG Information Soc. It's highly contentious with XoIP and NGN services, which may be uni or = multi directional.=20 *Old might be good e.g. PSTN* (See Or option below which might offer a = compromise in meaning)=20 Definition of PATS:=20 Publicly Available Telephone Service=20 Means a service available to the public for originating and receiving = national and international calls and access to emergency services = through a number or numbers in a national or international telephone = numbering plan, and in addition may, where relevant, include one or more = of the following services: the provision of operator assistance, = directory enquiry services, directories, provision of public pay phones, = provision of service under special terms, provision of special = facilities for customers with disabilities or with special social needs = and/or the provision of non-geographic services. Ref: = http://europa.eu.int/eur-lex/pri/en/oj/dat/2002/l_108/l_10820020424en0051= 0077.pdf=20 Article 2. Definitions. Page 9 of 27. (c)=20 -> Or we could use this text (b) Ibid:=20 Public Telephone Network=20 Means an electronic communications network which is used to provide = publicly available telephone services; it supports the transfer between = network termination points of speech communications, and also other = forms of communication, such as facsimile and data. Ronan Lupton=20 -----Original Message-----=20 From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = Pfautz, Penn L, NEO=20 Sent: 01 December 2005 14:28=20 To: Stastny Richard; Patrik F=E4ltstr=F6m; timothy.dwight@mci.com=20 Cc: enum@ietf.org=20 Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D=20 Richard:=20 I'm fine with the other changes but would prefer to keep the term PSTN. = My memory of PATS is that is has an even more specific meaning and that = some parties issued numbers by NRAs are not PATS. Penn=20 -----Original Message-----=20 From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = Stastny Richard=20 Sent: Thursday, December 01, 2005 8:01 AM=20 To: Patrik F=E4ltstr=F6m; timothy.dwight@mci.com=20 Cc: enum@ietf.org=20 Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D=20 Agreed,=20 but the Carrier-of-Record in Infrastructure ENUM is the pendant to the = End-user in User ENUM.=20 I propose to leave the term Carrier-of-Record=20 Reading the meeting minutes, it was agreed to move the definitions in = the Haberler draft over to the requirements draft=20 I copy here the relevant part:=20 =20 2. The Carrier of Record=20 In User ENUM, the entity or person having the right-to-use in a=20 number has the sole discretion about the content of the associated=20 domain and thus the zone content.=20 Within a Carrier ENUM namespace, we use the term "carrier of record"=20 for the entity having that discretion. This right typically lies=20 with 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), but generally exhibits one or more of the = following properties:=20 o it has been assigned one or more national number ranges by an NRA. = o it has been assigned a number range directly by the ITU, for=20 instance a code under "International Networks" (+882) or=20 "Universal Personal Telecommunications (UPT)" (+878).=20 o it can be the recipient of a number porting operation.=20 o it provides a PSTN point-of-interconnect for the number.=20 =20 Since it was also mentioned on the list that the term PSTN was too = narrow, I propose to replace the term PSTN with=20 Public Available Telephony Service=20 So the sentence will read:=20 This right typically lies=20 with a service provider authorized to issue E.164 numbers for the=20 provisioning of a Publicly Available Telephony Service under the =20 authority of a National Regulatory Authority (NRA), ...=20 This sentence includes BTW also the term "service provider" ;-)=20 Regards=20 Richard=20 > -----Original Message-----=20 > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf=20 > Of Patrik F=E4ltstr=F6m=20 > Sent: Thursday, December 01, 2005 8:13 AM=20 > To: timothy.dwight@mci.com=20 > Cc: enum@ietf.org=20 > Subject: Re: [Enum] Re: Update of Carrier ENUM requirements I-D=20 >=20 > Be careful...=20 >=20 > When running DNS, we have one party that is responsible for the DNS=20 > service that make DNS records available. We might have a different=20 > organization that is deciding what the records are. And then a third=20 > party responsible for the service the record refer to. And of course a = > fourth that is administrative responsible for the domain name itself.=20 >=20 > Example:=20 >=20 > Organization A is the registrant for example.com.=20 >=20 > Organization B is asked to administer the example.com zone (do the=20 > provisioning).=20 >=20 > Organization C is running the DNS that holds the example.com zone.=20 >=20 > Organization D is running the mailserver MX record for example.com=20 > refer to.=20 >=20 > If you are curious of difference between B and C, think of the root=20 > zone where ICANN decide what the content of the root zone is, and the=20 > root server operators as a collective is making the zone available.=20 >=20 >=20 > What term you use doesn't matter. The important thing is that you in a = > terminology section is extremely explicit with what you talk about.=20 >=20 > paf=20 >=20 > On 30 nov 2005, at 22.47, Tim Dwight wrote:=20 >=20 > > I'm not sure that I agree with changing "carrier of record" to=20 > > "service provider of record". Depends on what the latter means I=20 > > suppose. If (as=20 > > seems intuitive) "service provider" means "the entity that the=20 > > customer=20 > > perceives as providing the service", and "carrier of record" means=20 > > "the=20 > > entity providing PSTN access for calls to or from the customer",=20 > > then is a=20 > > "service provider of record" an entity that does both? And is that=20 > > the=20 > > appropriate semantic?=20 > >=20 > > At the risk of inviting flames I'd say that "carrier of record" is=20 > > the appropriate term and the Telco-bashing that seems to motivate=20 > > this change, is juvenile.=20 > >=20 > > Tim=20 > >=20 > >=20 > > -----Original Message-----=20 > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf = > > Of Richard Shockey=20 > > Sent: Wednesday, November 30, 2005 3:31 PM=20 > > To: Pfautz, Penn L, NEO=20 > > Cc: enum@ietf.org=20 > > Subject: [Enum] Re: Update of Carrier ENUM requirements I-D=20 > >=20 > > Pfautz, Penn L, NEO wrote:=20 > >> Having looked over the Vancouver minutes of the WG I want to ask=20 > >> if I should replace "carrier ENUM" with "infrastructure ENUM"=20 > >> before resubmitting draft-lind-infrastructure-enum-reqs-01 as=20 > >> draft-ietf-enum-infrastructure-enum-reqs-00.=20 > >=20 > > Yes .. it seemed to be the consensus of the WG that the word carrier = > > seems to be associated with some form of disease.=20 > >=20 > >=20 > >> If so, I would also propose to render "carrier of record" as=20 > >> "service provider of record" going forward.=20 > >=20 > > excellent idea.=20 > >=20 > >>=20 > >> Your views?=20 > >>=20 > >> Thanks,=20 > >> Penn=20 > >=20 > > --=20 > >=20 > >=20 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 > > Richard Shockey, Director - Member of Technical Staff NeuStar Inc.=20 > > 46000 Center Oak Plaza - Sterling, VA 20166=20 > > sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com=20 > > ENUM +87810-13313-31331=20 > > PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683=20 > > Fax: +1 815.333.1237=20 > > or=20 > > =20 > > ; =20 > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<=20 > >=20 > > _______________________________________________=20 > > enum mailing list=20 > > enum@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/enum=20 > >=20 > >=20 > > _______________________________________________=20 > > enum mailing list=20 > > enum@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/enum=20 >=20 > _______________________________________________=20 > enum mailing list=20 > enum@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/enum=20 _______________________________________________=20 enum mailing list=20 enum@ietf.org=20 https://www1.ietf.org/mailman/listinfo/enum=20 _______________________________________________=20 enum mailing list=20 enum@ietf.org=20 https://www1.ietf.org/mailman/listinfo/enum=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Dec 01 10:25:55 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 1EhqJn-0000Yy-GB; Thu, 01 Dec 2005 10:25:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhqJm-0000Yt-N4 for enum@megatron.ietf.org; Thu, 01 Dec 2005 10:25: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 KAA04261 for ; Thu, 1 Dec 2005 10:25:08 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhqeH-0001WK-5u for enum@ietf.org; Thu, 01 Dec 2005 10:47:06 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id jB1FPcnv003536 for ; Thu, 1 Dec 2005 15:25:38 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Dec 2005 10:24:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D Date: Thu, 1 Dec 2005 10:24:27 -0500 Message-ID: <165FCC93A820D240A62F98E028CEFED005786E0B@stntexch01.cis.neustar.com> Thread-Topic: [Enum] Re: Update of Carrier ENUM requirements I-D Thread-Index: AcX2R8hHaAVms+MFSNmmEtLLuJZP6QALe+TwAAKrpTA= From: "McGarry, Tom" To: X-OriginalArrivalTime: 01 Dec 2005 15:24:27.0553 (UTC) FILETIME=[5157E910:01C5F68B] X-Spam-Score: 0.8 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 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 The definition of carrier (or infrastructure) ENUM is - the carrier of = record (as defined here) is the registrant. This is as opposed to end = user ENUM where - the end user is the registrant. This is important = because it defines "who" chooses to register the TN in Tier 1. =20 I don't believe either of the carrier ENUM documents have made this = point explicitly. Of course one of the problems is that end user ENUM = has never been defined. =20 The definitions of the two types of ENUM is as simple as that. =20 In addition, most of the requirements listed in Section 2 of = draft-lind-infrastructure-enum-reqs-01 would not be unique to carrier = ENUM, e.g., privacy, high reliability and performance, choice, support = for open numbering plans, etc. Also, most of the requirements seem to = be very local (country specific) in nature. Do the existing ENUM Tier = 1s provide IRIS? If not, should they be excluded from providing carrier = ENUM (if it were to come around)? Is that really something we should be = dictating to countries? =20 In the case of carrier ENUM definitions and requirements, I believe less = is more. =20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of Stastny Richard Sent: Thursday, December 01, 2005 8:01 AM To: Patrik F=E4ltstr=F6m; timothy.dwight@mci.com Cc: enum@ietf.org Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D Agreed, but the Carrier-of-Record in Infrastructure ENUM is the pendant to the End-user in User ENUM. I propose to leave the term Carrier-of-Record Reading the meeting minutes, it was agreed to move the definitions in the Haberler draft over to the requirements draft I copy here the relevant part: 2. The Carrier of Record In User ENUM, the entity or person having the right-to-use in a number has the sole discretion about the content of the associated domain and thus the zone content. Within a Carrier ENUM namespace, we use the term "carrier of record" for the entity having that discretion. This right typically lies with a service provider authorized to issue E.164 numbers for the provisioning of PSTN service under the authority of a National Regulatory Authority (NRA), but generally exhibits one or more of the following properties: o it has been assigned one or more national number ranges by an NRA. o it has been assigned a number range directly by the ITU, for instance a code under "International Networks" (+882) or "Universal Personal Telecommunications (UPT)" (+878). o it can be the recipient of a number porting operation. o it provides a PSTN point-of-interconnect for the number. Since it was also mentioned on the list that the term PSTN was too narrow, I propose to replace the term PSTN with=20 Public Available Telephony Service So the sentence will read: This right typically lies with a service provider authorized to issue E.164 numbers for the provisioning of a Publicly Available Telephony Service under the =20 authority of a National Regulatory Authority (NRA), ... This sentence includes BTW also the term "service provider" ;-) Regards Richard > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf = Of > Patrik F=E4ltstr=F6m > Sent: Thursday, December 01, 2005 8:13 AM > To: timothy.dwight@mci.com > Cc: enum@ietf.org > Subject: Re: [Enum] Re: Update of Carrier ENUM requirements I-D >=20 > Be careful... >=20 > When running DNS, we have one party that is responsible for the DNS > service that make DNS records available. We might have a different > organization that is deciding what the records are. And then a third > party responsible for the service the record refer to. And of course > a fourth that is administrative responsible for the domain name = itself. >=20 > Example: >=20 > Organization A is the registrant for example.com. >=20 > Organization B is asked to administer the example.com zone (do the > provisioning). >=20 > Organization C is running the DNS that holds the example.com zone. >=20 > Organization D is running the mailserver MX record for example.com > refer to. >=20 > If you are curious of difference between B and C, think of the root > zone where ICANN decide what the content of the root zone is, and the > root server operators as a collective is making the zone available. >=20 >=20 > What term you use doesn't matter. The important thing is that you in > a terminology section is extremely explicit with what you talk about. >=20 > paf >=20 > On 30 nov 2005, at 22.47, Tim Dwight wrote: >=20 > > I'm not sure that I agree with changing "carrier of record" to > > "service > > provider of record". Depends on what the latter means I suppose. > > If (as > > seems intuitive) "service provider" means "the entity that the > > customer > > perceives as providing the service", and "carrier of record" means > > "the > > entity providing PSTN access for calls to or from the customer", > > then is a > > "service provider of record" an entity that does both? And is that > > the > > appropriate semantic? > > > > At the risk of inviting flames I'd say that "carrier of record" is = the > > appropriate term and the Telco-bashing that seems to motivate this > > change, > > is juvenile. > > > > Tim > > > > > > -----Original Message----- > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > > Behalf Of > > Richard Shockey > > Sent: Wednesday, November 30, 2005 3:31 PM > > To: Pfautz, Penn L, NEO > > Cc: enum@ietf.org > > Subject: [Enum] Re: Update of Carrier ENUM requirements I-D > > > > Pfautz, Penn L, NEO wrote: > >> Having looked over the Vancouver minutes of the WG I want to ask > >> if I > >> should replace "carrier ENUM" with "infrastructure ENUM" before > >> resubmitting draft-lind-infrastructure-enum-reqs-01 as > >> draft-ietf-enum-infrastructure-enum-reqs-00. > > > > Yes .. it seemed to be the consensus of the WG that the word > > carrier seems > > to be associated with some form of disease. > > > > > >> If so, I would also propose to render "carrier of record" as = "service > >> provider of record" going forward. > > > > excellent idea. > > > >> > >> Your views? > >> > >> Thanks, > >> Penn > > > > -- > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > 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 >=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 From enum-bounces@ietf.org Thu Dec 01 10:53:10 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 1EhqkA-0000Iy-MY; Thu, 01 Dec 2005 10:53:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehqk7-0000HV-Rj for enum@megatron.ietf.org; Thu, 01 Dec 2005 10:53:09 -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 KAA07912 for ; Thu, 1 Dec 2005 10:52:21 -0500 (EST) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ehr4b-0002Z9-M7 for enum@ietf.org; Thu, 01 Dec 2005 11:14:19 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1133452341!9347163!4 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 2209 invoked from network); 1 Dec 2005 15:52:54 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-9.tower-120.messagelabs.com with SMTP; 1 Dec 2005 15:52:54 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 4380ACBE0016D599; Thu, 1 Dec 2005 10:52:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D Date: Thu, 1 Dec 2005 10:52:52 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0BA6C376@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Enum] Re: Update of Carrier ENUM requirements I-D Thread-Index: AcX2R8hHaAVms+MFSNmmEtLLuJZP6QALe+TwAAKrpTAAA4De8A== From: "Pfautz, Penn L, NEO" To: "McGarry, Tom" , X-Spam-Score: 0.8 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 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 Tom: I can include a statement that COR=3Dregistrant in the next draft. I = agree that it's useful to be explicit here. In the same spirit, I see = most of the requirements as useful to state even where they might = logically be inferred from end user ENUM. I do see a use for a properly restricted IRIS capability but obviously = the IETF can't dictate to anyone except in matter of protocol = capabilities. I believe other service providers would also like to see = this particular capability. Penn -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = McGarry, Tom Sent: Thursday, December 01, 2005 10:24 AM To: enum@ietf.org Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D The definition of carrier (or infrastructure) ENUM is - the carrier of = record (as defined here) is the registrant. This is as opposed to end = user ENUM where - the end user is the registrant. This is important = because it defines "who" chooses to register the TN in Tier 1. =20 I don't believe either of the carrier ENUM documents have made this = point explicitly. Of course one of the problems is that end user ENUM = has never been defined. =20 The definitions of the two types of ENUM is as simple as that. =20 In addition, most of the requirements listed in Section 2 of = draft-lind-infrastructure-enum-reqs-01 would not be unique to carrier = ENUM, e.g., privacy, high reliability and performance, choice, support = for open numbering plans, etc. Also, most of the requirements seem to = be very local (country specific) in nature. Do the existing ENUM Tier = 1s provide IRIS? If not, should they be excluded from providing carrier = ENUM (if it were to come around)? Is that really something we should be = dictating to countries? =20 In the case of carrier ENUM definitions and requirements, I believe less = is more. =20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of Stastny Richard Sent: Thursday, December 01, 2005 8:01 AM To: Patrik F=E4ltstr=F6m; timothy.dwight@mci.com Cc: enum@ietf.org Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D Agreed, but the Carrier-of-Record in Infrastructure ENUM is the pendant to the End-user in User ENUM. I propose to leave the term Carrier-of-Record Reading the meeting minutes, it was agreed to move the definitions in the Haberler draft over to the requirements draft I copy here the relevant part: 2. The Carrier of Record In User ENUM, the entity or person having the right-to-use in a number has the sole discretion about the content of the associated domain and thus the zone content. Within a Carrier ENUM namespace, we use the term "carrier of record" for the entity having that discretion. This right typically lies with a service provider authorized to issue E.164 numbers for the provisioning of PSTN service under the authority of a National Regulatory Authority (NRA), but generally exhibits one or more of the following properties: o it has been assigned one or more national number ranges by an NRA. o it has been assigned a number range directly by the ITU, for instance a code under "International Networks" (+882) or "Universal Personal Telecommunications (UPT)" (+878). o it can be the recipient of a number porting operation. o it provides a PSTN point-of-interconnect for the number. Since it was also mentioned on the list that the term PSTN was too narrow, I propose to replace the term PSTN with=20 Public Available Telephony Service So the sentence will read: This right typically lies with a service provider authorized to issue E.164 numbers for the provisioning of a Publicly Available Telephony Service under the =20 authority of a National Regulatory Authority (NRA), ... This sentence includes BTW also the term "service provider" ;-) Regards Richard > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf = Of > Patrik F=E4ltstr=F6m > Sent: Thursday, December 01, 2005 8:13 AM > To: timothy.dwight@mci.com > Cc: enum@ietf.org > Subject: Re: [Enum] Re: Update of Carrier ENUM requirements I-D >=20 > Be careful... >=20 > When running DNS, we have one party that is responsible for the DNS > service that make DNS records available. We might have a different > organization that is deciding what the records are. And then a third > party responsible for the service the record refer to. And of course > a fourth that is administrative responsible for the domain name = itself. >=20 > Example: >=20 > Organization A is the registrant for example.com. >=20 > Organization B is asked to administer the example.com zone (do the > provisioning). >=20 > Organization C is running the DNS that holds the example.com zone. >=20 > Organization D is running the mailserver MX record for example.com > refer to. >=20 > If you are curious of difference between B and C, think of the root > zone where ICANN decide what the content of the root zone is, and the > root server operators as a collective is making the zone available. >=20 >=20 > What term you use doesn't matter. The important thing is that you in > a terminology section is extremely explicit with what you talk about. >=20 > paf >=20 > On 30 nov 2005, at 22.47, Tim Dwight wrote: >=20 > > I'm not sure that I agree with changing "carrier of record" to > > "service > > provider of record". Depends on what the latter means I suppose. > > If (as > > seems intuitive) "service provider" means "the entity that the > > customer > > perceives as providing the service", and "carrier of record" means > > "the > > entity providing PSTN access for calls to or from the customer", > > then is a > > "service provider of record" an entity that does both? And is that > > the > > appropriate semantic? > > > > At the risk of inviting flames I'd say that "carrier of record" is = the > > appropriate term and the Telco-bashing that seems to motivate this > > change, > > is juvenile. > > > > Tim > > > > > > -----Original Message----- > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > > Behalf Of > > Richard Shockey > > Sent: Wednesday, November 30, 2005 3:31 PM > > To: Pfautz, Penn L, NEO > > Cc: enum@ietf.org > > Subject: [Enum] Re: Update of Carrier ENUM requirements I-D > > > > Pfautz, Penn L, NEO wrote: > >> Having looked over the Vancouver minutes of the WG I want to ask > >> if I > >> should replace "carrier ENUM" with "infrastructure ENUM" before > >> resubmitting draft-lind-infrastructure-enum-reqs-01 as > >> draft-ietf-enum-infrastructure-enum-reqs-00. > > > > Yes .. it seemed to be the consensus of the WG that the word > > carrier seems > > to be associated with some form of disease. > > > > > >> If so, I would also propose to render "carrier of record" as = "service > >> provider of record" going forward. > > > > excellent idea. > > > >> > >> Your views? > >> > >> Thanks, > >> Penn > > > > -- > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > 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 >=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 Thu Dec 01 11:15: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 1Ehr6C-0006cX-3Q; Thu, 01 Dec 2005 11:15:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehr6B-0006cN-19 for enum@megatron.ietf.org; Thu, 01 Dec 2005 11:15:55 -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 LAA10808 for ; Thu, 1 Dec 2005 11:15:08 -0500 (EST) Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhrQf-0003P9-Nk for enum@ietf.org; Thu, 01 Dec 2005 11:37:07 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 00AB875BA7; Thu, 1 Dec 2005 16:15:06 +0000 (GMT) In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0BA6C376@ACCLUST02EVS1.ugd.att.com> References: <34DA635B184A644DA4588E260EC0A25A0BA6C376@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <283FA310-BC2C-4C95-8CD2-4DF27B8BB443@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] Re: Update of Carrier ENUM requirements I-D Date: Thu, 1 Dec 2005 16:15:04 +0000 To: "Pfautz, Penn L, NEO" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "McGarry, Tom" X-BeenThere: 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 Penn, Tom, folks, Less is undoubtedly more - anything not needed is superfluous. Also, why are we trying to specify anything that is going to be ignored (or, more specifically, can safely be ignored)? Re. IRIS: If COR/SPoR/... is the Registrant, and as Patrik points out, there can be many different organisations involved, what exactly does IRIR bring to the party? It won't have ANY information on the end user who is provided service via this number - he or she is not the registrant. Perhaps someone should spell out exactly WHAT one might use IRIS to provide, and leave it up to the Infrastructure people using an implementation of this system to decide if they need this. My feeling is that some will, some won't, and (allegedly :) some will want to include this just to b*gg*r up any players who don't support it already (or use some other means of providing the same information to their peers). all the best, Lawrence On 1 Dec 2005, at 15:52, Pfautz, Penn L, NEO wrote: > Tom: > I can include a statement that COR=registrant in the next draft. I > agree that it's useful to be explicit here. In the same spirit, I > see most of the requirements as useful to state even where they > might logically be inferred from end user ENUM. > > I do see a use for a properly restricted IRIS capability but > obviously the IETF can't dictate to anyone except in matter of > protocol capabilities. I believe other service providers would also > like to see this particular capability. > > Penn > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > Behalf Of McGarry, Tom > Sent: Thursday, December 01, 2005 10:24 AM > To: enum@ietf.org > Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D > > The definition of carrier (or infrastructure) ENUM is - the carrier > of record (as defined here) is the registrant. This is as opposed > to end user ENUM where - the end user is the registrant. This is > important because it defines "who" chooses to register the TN in > Tier 1. > > I don't believe either of the carrier ENUM documents have made this > point explicitly. Of course one of the problems is that end user > ENUM has never been defined. > > The definitions of the two types of ENUM is as simple as that. > > In addition, most of the requirements listed in Section 2 of draft- > lind-infrastructure-enum-reqs-01 would not be unique to carrier > ENUM, e.g., privacy, high reliability and performance, choice, > support for open numbering plans, etc. Also, most of the > requirements seem to be very local (country specific) in nature. > Do the existing ENUM Tier 1s provide IRIS? If not, should they be > excluded from providing carrier ENUM (if it were to come around)? > Is that really something we should be dictating to countries? > > In the case of carrier ENUM definitions and requirements, I believe > less is more. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Dec 01 11:33:29 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 1EhrNB-0007JP-K9; Thu, 01 Dec 2005 11:33:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhrN9-0007HJ-G5 for enum@megatron.ietf.org; Thu, 01 Dec 2005 11:33:27 -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 LAA13465 for ; Thu, 1 Dec 2005 11:32:41 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehrhf-0004A3-5s for enum@ietf.org; Thu, 01 Dec 2005 11:54:39 -0500 Received: from [10.31.13.127] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jB1GXmME016112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Dec 2005 08:33:50 -0800 Message-ID: <438F25C1.6040808@shockey.us> Date: Thu, 01 Dec 2005 11:33:05 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: lconroy Subject: Re: [Enum] Re: Update of Carrier ENUM requirements I-D References: <34DA635B184A644DA4588E260EC0A25A0BA6C376@ACCLUST02EVS1.ugd.att.com> <283FA310-BC2C-4C95-8CD2-4DF27B8BB443@insensate.co.uk> In-Reply-To: <283FA310-BC2C-4C95-8CD2-4DF27B8BB443@insensate.co.uk> 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: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "Pfautz, Penn L, NEO" , "McGarry, Tom" X-BeenThere: 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 lconroy wrote: > Hi Penn, Tom, folks, > Less is undoubtedly more - anything not needed is superfluous. > Also, why are we trying to specify anything that is going to be ignored > (or, more specifically, can safely be ignored)? > > Re. IRIS: > If COR/SPoR/... is the Registrant, and as Patrik points out, there can > be many different organisations involved, what exactly does IRIR bring > to the party? It won't have ANY information on the end user who is > provided service via this number - he or she is not the registrant. maybe maybe not ..it depends on what the local requirements are.... and there are lots of LEA's and NRA's these days with lots of requiremnts. Its principal function, in theory, provide contact data on the network operators responsible for that TN. In DNS registration terms terms that is classic stuff. It answers questions about who is responsible for a domain. Say 'm trying to get a call through it doesnt work who .. is the nitwit running their proxies SBC's or DNS infrastructure so you can tell them ot fix it. > Perhaps someone should spell out exactly WHAT one might use IRIS to > provide, and leave it up to the Infrastructure people using an > implementation of this system to decide if they need this. > > My feeling is that some will, some won't, It would be almost foolish to run a Infrastructure ENUM system without an IRIS service associated with it. You cant maintain the integrity of the network without it. and (allegedly :) some will > want to include this just to b*gg*r up any players who don't support it > already (or use some other means of providing the same information to > their peers). > > all the best, > Lawrence > > On 1 Dec 2005, at 15:52, Pfautz, Penn L, NEO wrote: > >> Tom: >> I can include a statement that COR=registrant in the next draft. I >> agree that it's useful to be explicit here. In the same spirit, I see >> most of the requirements as useful to state even where they might >> logically be inferred from end user ENUM. >> >> I do see a use for a properly restricted IRIS capability but >> obviously the IETF can't dictate to anyone except in matter of >> protocol capabilities. I believe other service providers would also >> like to see this particular capability. >> >> Penn >> >> -----Original Message----- >> From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf >> Of McGarry, Tom >> Sent: Thursday, December 01, 2005 10:24 AM >> To: enum@ietf.org >> Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D >> >> The definition of carrier (or infrastructure) ENUM is - the carrier >> of record (as defined here) is the registrant. This is as opposed to >> end user ENUM where - the end user is the registrant. This is >> important because it defines "who" chooses to register the TN in Tier 1. >> >> I don't believe either of the carrier ENUM documents have made this >> point explicitly. Of course one of the problems is that end user >> ENUM has never been defined. >> >> The definitions of the two types of ENUM is as simple as that. >> >> In addition, most of the requirements listed in Section 2 of draft- >> lind-infrastructure-enum-reqs-01 would not be unique to carrier ENUM, >> e.g., privacy, high reliability and performance, choice, support for >> open numbering plans, etc. Also, most of the requirements seem to be >> very local (country specific) in nature. Do the existing ENUM Tier >> 1s provide IRIS? If not, should they be excluded from providing >> carrier ENUM (if it were to come around)? Is that really something >> we should be dictating to countries? >> >> In the case of carrier ENUM definitions and requirements, I believe >> less is more. >> > > > _______________________________________________ > 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 Thu Dec 01 13:31:57 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 1EhtDp-0007u4-7m; Thu, 01 Dec 2005 13:31:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhtDn-0007tu-9n for enum@megatron.ietf.org; Thu, 01 Dec 2005 13:31:55 -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 NAA29263 for ; Thu, 1 Dec 2005 13:31:08 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EhtYJ-0000EG-ES for enum@ietf.org; Thu, 01 Dec 2005 13:53:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Re: Update of Carrier ENUM requirements I-D Date: Thu, 1 Dec 2005 19:31:20 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C46DA@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Re: Update of Carrier ENUM requirements I-D Thread-Index: AcX2R8hHaAVms+MFSNmmEtLLuJZP6QALe+TwAAKrpTAACUGUQA== From: "Stastny Richard" To: "McGarry, Tom" , X-Spam-Score: 0.8 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d 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 =20 >The definition of carrier (or infrastructure) ENUM is - the carrier of = record (as defined here) is the registrant. This is as >opposed to end = user ENUM where - the end user is the registrant. This is important = because it defines "who" chooses to >register the TN in Tier 1. =20 I thought this was clear in the definition form the haberler-draft:, so = I fully agree that this is important, basically we define it via this property = ;-) =20 "In User ENUM, the entity or person having the right-to-use in a number has the sole discretion about the content of the associated domain and thus the zone content. Within a Carrier ENUM namespace, we use the term "carrier of record" for the entity having that discretion. " =20 This is exactly what you say above in other words =20 Richard =20 =20 ________________________________ Von: enum-bounces@ietf.org im Auftrag von McGarry, Tom Gesendet: Do 01.12.2005 16:24 An: enum@ietf.org Betreff: RE: [Enum] Re: Update of Carrier ENUM requirements I-D The definition of carrier (or infrastructure) ENUM is - the carrier of = record (as defined here) is the registrant. This is as opposed to end = user ENUM where - the end user is the registrant. This is important = because it defines "who" chooses to register the TN in Tier 1.=20 I don't believe either of the carrier ENUM documents have made this = point explicitly. Of course one of the problems is that end user ENUM = has never been defined.=20 The definitions of the two types of ENUM is as simple as that.=20 In addition, most of the requirements listed in Section 2 of = draft-lind-infrastructure-enum-reqs-01 would not be unique to carrier = ENUM, e.g., privacy, high reliability and performance, choice, support = for open numbering plans, etc. Also, most of the requirements seem to = be very local (country specific) in nature. Do the existing ENUM Tier = 1s provide IRIS? If not, should they be excluded from providing carrier = ENUM (if it were to come around)? Is that really something we should be = dictating to countries?=20 In the case of carrier ENUM definitions and requirements, I believe less = is more.=20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of Stastny Richard Sent: Thursday, December 01, 2005 8:01 AM To: Patrik F=E4ltstr=F6m; timothy.dwight@mci.com Cc: enum@ietf.org Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D Agreed, but the Carrier-of-Record in Infrastructure ENUM is the pendant to the End-user in User ENUM. I propose to leave the term Carrier-of-Record Reading the meeting minutes, it was agreed to move the definitions in the Haberler draft over to the requirements draft I copy here the relevant part: 2. The Carrier of Record In User ENUM, the entity or person having the right-to-use in a number has the sole discretion about the content of the associated domain and thus the zone content. Within a Carrier ENUM namespace, we use the term "carrier of record" for the entity having that discretion. This right typically lies with a service provider authorized to issue E.164 numbers for the provisioning of PSTN service under the authority of a National Regulatory Authority (NRA), but generally exhibits one or more of the following properties: o it has been assigned one or more national number ranges by an NRA. o it has been assigned a number range directly by the ITU, for instance a code under "International Networks" (+882) or "Universal Personal Telecommunications (UPT)" (+878). o it can be the recipient of a number porting operation. o it provides a PSTN point-of-interconnect for the number. Since it was also mentioned on the list that the term PSTN was too narrow, I propose to replace the term PSTN with Public Available Telephony Service So the sentence will read: This right typically lies with a service provider authorized to issue E.164 numbers for the provisioning of a Publicly Available Telephony Service under the=20 authority of a National Regulatory Authority (NRA), ... This sentence includes BTW also the term "service provider" ;-) Regards Richard > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf = Of > Patrik F=E4ltstr=F6m > Sent: Thursday, December 01, 2005 8:13 AM > To: timothy.dwight@mci.com > Cc: enum@ietf.org > Subject: Re: [Enum] Re: Update of Carrier ENUM requirements I-D > > Be careful... > > When running DNS, we have one party that is responsible for the DNS > service that make DNS records available. We might have a different > organization that is deciding what the records are. And then a third > party responsible for the service the record refer to. And of course > a fourth that is administrative responsible for the domain name = itself. > > Example: > > Organization A is the registrant for example.com. > > Organization B is asked to administer the example.com zone (do the > provisioning). > > Organization C is running the DNS that holds the example.com zone. > > Organization D is running the mailserver MX record for example.com > refer to. > > If you are curious of difference between B and C, think of the root > zone where ICANN decide what the content of the root zone is, and the > root server operators as a collective is making the zone available. > > > What term you use doesn't matter. The important thing is that you in > a terminology section is extremely explicit with what you talk about. > > paf > > On 30 nov 2005, at 22.47, Tim Dwight wrote: > > > I'm not sure that I agree with changing "carrier of record" to > > "service > > provider of record". Depends on what the latter means I suppose. > > If (as > > seems intuitive) "service provider" means "the entity that the > > customer > > perceives as providing the service", and "carrier of record" means > > "the > > entity providing PSTN access for calls to or from the customer", > > then is a > > "service provider of record" an entity that does both? And is that > > the > > appropriate semantic? > > > > At the risk of inviting flames I'd say that "carrier of record" is = the > > appropriate term and the Telco-bashing that seems to motivate this > > change, > > is juvenile. > > > > Tim > > > > > > -----Original Message----- > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > > Behalf Of > > Richard Shockey > > Sent: Wednesday, November 30, 2005 3:31 PM > > To: Pfautz, Penn L, NEO > > Cc: enum@ietf.org > > Subject: [Enum] Re: Update of Carrier ENUM requirements I-D > > > > Pfautz, Penn L, NEO wrote: > >> Having looked over the Vancouver minutes of the WG I want to ask > >> if I > >> should replace "carrier ENUM" with "infrastructure ENUM" before > >> resubmitting draft-lind-infrastructure-enum-reqs-01 as > >> draft-ietf-enum-infrastructure-enum-reqs-00. > > > > Yes .. it seemed to be the consensus of the WG that the word > > carrier seems > > to be associated with some form of disease. > > > > > >> If so, I would also propose to render "carrier of record" as = "service > >> provider of record" going forward. > > > > excellent idea. > > > >> > >> Your views? > >> > >> Thanks, > >> Penn > > > > -- > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > 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 _______________________________________________ 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 Dec 01 13:51:44 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 1EhtWy-0004p6-IU; Thu, 01 Dec 2005 13:51:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhtWw-0004ov-Hr for enum@megatron.ietf.org; Thu, 01 Dec 2005 13:51: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 NAA01196 for ; Thu, 1 Dec 2005 13:50:55 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhtrT-0000qx-O0 for enum@ietf.org; Thu, 01 Dec 2005 14:12:56 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id jB1IpVnv018937; Thu, 1 Dec 2005 18:51:31 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Dec 2005 13:50:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D Date: Thu, 1 Dec 2005 13:50:19 -0500 Message-ID: <165FCC93A820D240A62F98E028CEFED005786E17@stntexch01.cis.neustar.com> Thread-Topic: [Enum] Re: Update of Carrier ENUM requirements I-D Thread-Index: AcX2R8hHaAVms+MFSNmmEtLLuJZP6QALe+TwAAKrpTAACUGUQAAAjCig From: "McGarry, Tom" To: "Stastny Richard" , X-OriginalArrivalTime: 01 Dec 2005 18:50:20.0077 (UTC) FILETIME=[14057DD0:01C5F6A8] X-Spam-Score: 0.8 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 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 Registrant is a well understood domain name industry term. I would = suggest using that term. =20 -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, December 01, 2005 1:31 PM To: McGarry, Tom; enum@ietf.org Subject: Re: [Enum] Re: Update of Carrier ENUM requirements I-D =20 >The definition of carrier (or infrastructure) ENUM is - the carrier of = record (as defined here) is the registrant. This is as >opposed to end = user ENUM where - the end user is the registrant. This is important = because it defines "who" chooses to >register the TN in Tier 1. =20 I thought this was clear in the definition form the haberler-draft:, so = I fully agree that this is important, basically we define it via this property = ;-) =20 "In User ENUM, the entity or person having the right-to-use in a number has the sole discretion about the content of the associated domain and thus the zone content. Within a Carrier ENUM namespace, we use the term "carrier of record" for the entity having that discretion. " =20 This is exactly what you say above in other words =20 Richard =20 =20 ________________________________ Von: enum-bounces@ietf.org im Auftrag von McGarry, Tom Gesendet: Do 01.12.2005 16:24 An: enum@ietf.org Betreff: RE: [Enum] Re: Update of Carrier ENUM requirements I-D The definition of carrier (or infrastructure) ENUM is - the carrier of = record (as defined here) is the registrant. This is as opposed to end = user ENUM where - the end user is the registrant. This is important = because it defines "who" chooses to register the TN in Tier 1.=20 I don't believe either of the carrier ENUM documents have made this = point explicitly. Of course one of the problems is that end user ENUM = has never been defined.=20 The definitions of the two types of ENUM is as simple as that.=20 In addition, most of the requirements listed in Section 2 of = draft-lind-infrastructure-enum-reqs-01 would not be unique to carrier = ENUM, e.g., privacy, high reliability and performance, choice, support = for open numbering plans, etc. Also, most of the requirements seem to = be very local (country specific) in nature. Do the existing ENUM Tier = 1s provide IRIS? If not, should they be excluded from providing carrier = ENUM (if it were to come around)? Is that really something we should be = dictating to countries?=20 In the case of carrier ENUM definitions and requirements, I believe less = is more.=20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of Stastny Richard Sent: Thursday, December 01, 2005 8:01 AM To: Patrik F=E4ltstr=F6m; timothy.dwight@mci.com Cc: enum@ietf.org Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D Agreed, but the Carrier-of-Record in Infrastructure ENUM is the pendant to the End-user in User ENUM. I propose to leave the term Carrier-of-Record Reading the meeting minutes, it was agreed to move the definitions in the Haberler draft over to the requirements draft I copy here the relevant part: 2. The Carrier of Record In User ENUM, the entity or person having the right-to-use in a number has the sole discretion about the content of the associated domain and thus the zone content. Within a Carrier ENUM namespace, we use the term "carrier of record" for the entity having that discretion. This right typically lies with a service provider authorized to issue E.164 numbers for the provisioning of PSTN service under the authority of a National Regulatory Authority (NRA), but generally exhibits one or more of the following properties: o it has been assigned one or more national number ranges by an NRA. o it has been assigned a number range directly by the ITU, for instance a code under "International Networks" (+882) or "Universal Personal Telecommunications (UPT)" (+878). o it can be the recipient of a number porting operation. o it provides a PSTN point-of-interconnect for the number. Since it was also mentioned on the list that the term PSTN was too narrow, I propose to replace the term PSTN with Public Available Telephony Service So the sentence will read: This right typically lies with a service provider authorized to issue E.164 numbers for the provisioning of a Publicly Available Telephony Service under the=20 authority of a National Regulatory Authority (NRA), ... This sentence includes BTW also the term "service provider" ;-) Regards Richard > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf = Of > Patrik F=E4ltstr=F6m > Sent: Thursday, December 01, 2005 8:13 AM > To: timothy.dwight@mci.com > Cc: enum@ietf.org > Subject: Re: [Enum] Re: Update of Carrier ENUM requirements I-D > > Be careful... > > When running DNS, we have one party that is responsible for the DNS > service that make DNS records available. We might have a different > organization that is deciding what the records are. And then a third > party responsible for the service the record refer to. And of course > a fourth that is administrative responsible for the domain name = itself. > > Example: > > Organization A is the registrant for example.com. > > Organization B is asked to administer the example.com zone (do the > provisioning). > > Organization C is running the DNS that holds the example.com zone. > > Organization D is running the mailserver MX record for example.com > refer to. > > If you are curious of difference between B and C, think of the root > zone where ICANN decide what the content of the root zone is, and the > root server operators as a collective is making the zone available. > > > What term you use doesn't matter. The important thing is that you in > a terminology section is extremely explicit with what you talk about. > > paf > > On 30 nov 2005, at 22.47, Tim Dwight wrote: > > > I'm not sure that I agree with changing "carrier of record" to > > "service > > provider of record". Depends on what the latter means I suppose. > > If (as > > seems intuitive) "service provider" means "the entity that the > > customer > > perceives as providing the service", and "carrier of record" means > > "the > > entity providing PSTN access for calls to or from the customer", > > then is a > > "service provider of record" an entity that does both? And is that > > the > > appropriate semantic? > > > > At the risk of inviting flames I'd say that "carrier of record" is = the > > appropriate term and the Telco-bashing that seems to motivate this > > change, > > is juvenile. > > > > Tim > > > > > > -----Original Message----- > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > > Behalf Of > > Richard Shockey > > Sent: Wednesday, November 30, 2005 3:31 PM > > To: Pfautz, Penn L, NEO > > Cc: enum@ietf.org > > Subject: [Enum] Re: Update of Carrier ENUM requirements I-D > > > > Pfautz, Penn L, NEO wrote: > >> Having looked over the Vancouver minutes of the WG I want to ask > >> if I > >> should replace "carrier ENUM" with "infrastructure ENUM" before > >> resubmitting draft-lind-infrastructure-enum-reqs-01 as > >> draft-ietf-enum-infrastructure-enum-reqs-00. > > > > Yes .. it seemed to be the consensus of the WG that the word > > carrier seems > > to be associated with some form of disease. > > > > > >> If so, I would also propose to render "carrier of record" as = "service > >> provider of record" going forward. > > > > excellent idea. > > > >> > >> Your views? > >> > >> Thanks, > >> Penn > > > > -- > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > 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 _______________________________________________ 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 Dec 01 13:57:31 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 1EhtcZ-00023l-Fo; Thu, 01 Dec 2005 13:57:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhtcX-000205-8r for enum@megatron.ietf.org; Thu, 01 Dec 2005 13:57:29 -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 NAA02033 for ; Thu, 1 Dec 2005 13:56:42 -0500 (EST) Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehtx3-00011C-Ua for enum@ietf.org; Thu, 01 Dec 2005 14:18:42 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 23C6075C1C; Thu, 1 Dec 2005 18:57:18 +0000 (GMT) In-Reply-To: <438F25C1.6040808@shockey.us> References: <34DA635B184A644DA4588E260EC0A25A0BA6C376@ACCLUST02EVS1.ugd.att.com> <283FA310-BC2C-4C95-8CD2-4DF27B8BB443@insensate.co.uk> <438F25C1.6040808@shockey.us> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9C78758F-265C-4E67-9B3E-D1FB1BFEE010@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] Re: Update of Carrier ENUM requirements I-D Date: Thu, 1 Dec 2005 18:57:16 +0000 To: Richard Shockey X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.8 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "Pfautz, Penn L, NEO" , "McGarry, Tom" X-BeenThere: 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 again Richard, Penn, Tom, folks, Yup - an NRA/LEA *may* have many interesting and arcane requirements. Other NRAs may want nothing to do with this, leaving it up to the Carriers/SPs to do their own thing. There are a number of possible architectural models: - a Centralised system (with or without governmental oversight) is one solution, but not the only one. I hope that the requirements will reflect more than one approach. If the particular solution involves delegation, then you get some help from the SOA record. It depends on who you want to contact, and what you want them to fix (see Patrik's excellent earlier mail in this thread for some of the potential nitwits you may need to call). I am still not clear if IRIS is always needed to maintain network integrity, and hope that someone can spell out WHY this is the case in the document. (i.e. what needs to be done, and how IRIS [or whatever] can do this) all the best, Lawrence On 1 Dec 2005, at 16:33, Richard Shockey wrote (and I corrected): > lconroy wrote: >> Hi Penn, Tom, folks, >> Less is undoubtedly more - anything not needed is superfluous. >> Also, why are we trying to specify anything that is going to be >> ignored (or, more specifically, can safely be ignored)? >> Re. IRIS: >> If COR/SPoR/... is the Registrant, and as Patrik points out, >> there can be many different organisations involved, what exactly >> does IRIR bring to the party? It won't have ANY information on >> the end user who is provided service via this number - he or she >> is not the registrant. > maybe maybe not ..it depends on what the local requirements are.... > and there are lots of LEAs and NRAs these days with lots of > requiremnts. > > Its principal function, in theory, provide contact data on the > network operators responsible for that TN. In DNS registration > terms terms that is classic stuff. It answers questions about who > is responsible for a domain. > > Say I'm trying to get a call through it doesnt work who .. is the > nitwit running their proxies SBC's or DNS infrastructure so you can > tell them to fix it. > >> Perhaps someone should spell out exactly WHAT one might use IRIS >> to provide, and leave it up to the Infrastructure people using >> an implementation of this system to decide if they need this. >> My feeling is that some will, some won't, > It would be almost foolish to run a Infrastructure ENUM system > without an IRIS service associated with it. You cant maintain the > integrity of the network without it. > > and (allegedly :) some will want to include this just to b*gg*r up > any players who don't support it already (or use some other means > of providing the same information to their peers). >> all the best, >> Lawrence >> On 1 Dec 2005, at 15:52, Pfautz, Penn L, NEO wrote: >>> Tom: >>> I can include a statement that COR=registrant in the next draft. >>> I agree that it's useful to be explicit here. In the same >>> spirit, I see most of the requirements as useful to state even >>> where they might logically be inferred from end user ENUM. >>> >>> I do see a use for a properly restricted IRIS capability but >>> obviously the IETF can't dictate to anyone except in matter of >>> protocol capabilities. I believe other service providers would >>> also like to see this particular capability. >>> >>> Penn >>> >>> -----Original Message----- >>> From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On >>> Behalf Of McGarry, Tom >>> Sent: Thursday, December 01, 2005 10:24 AM >>> To: enum@ietf.org >>> Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D >>> >>> The definition of carrier (or infrastructure) ENUM is - the >>> carrier of record (as defined here) is the registrant. This is >>> as opposed to end user ENUM where - the end user is the >>> registrant. This is important because it defines "who" chooses >>> to register the TN in Tier 1. >>> >>> I don't believe either of the carrier ENUM documents have made >>> this point explicitly. Of course one of the problems is that >>> end user ENUM has never been defined. >>> >>> The definitions of the two types of ENUM is as simple as that. >>> >>> In addition, most of the requirements listed in Section 2 of >>> draft- lind-infrastructure-enum-reqs-01 would not be unique to >>> carrier ENUM, e.g., privacy, high reliability and performance, >>> choice, support for open numbering plans, etc. Also, most of >>> the requirements seem to be very local (country specific) in >>> nature. Do the existing ENUM Tier 1s provide IRIS? If not, >>> should they be excluded from providing carrier ENUM (if it were >>> to come around)? Is that really something we should be >>> dictating to countries? >>> >>> In the case of carrier ENUM definitions and requirements, I >>> believe less is more. >>> >> _______________________________________________ >> 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Dec 01 14:17:06 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 1EhtvW-0006Nd-IZ; Thu, 01 Dec 2005 14:17:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhtvU-0006NY-P5 for enum@megatron.ietf.org; Thu, 01 Dec 2005 14:17:04 -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 OAA03888 for ; Thu, 1 Dec 2005 14:16:15 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EhuFn-0001aI-7Y for enum@ietf.org; Thu, 01 Dec 2005 14:38:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D Date: Thu, 1 Dec 2005 20:20:29 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C46DC@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Re: Update of Carrier ENUM requirements I-D Thread-Index: AcX2qbeuk4I/Z+RGQNe7ZmZrh4vLvwAAbwj7 From: "Stastny Richard" To: "lconroy" , "Richard Shockey" X-Spam-Score: 0.8 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, "Pfautz, Penn L, NEO" , "McGarry, Tom" X-BeenThere: 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, =20 as Lawrence and Patrik correctly point out, there are many=20 potentitial scenarios how to implement Infrastructure ENUM. =20 Therefore IETF should take the same path here as for User ENUM, namely not to define anything beyond the normal DNS delegation procedures and leave it to the same bodies to define guidance to the NRAs. This would also save a lot of discussions and time in IETF. =20 I already talked to Tony that ETSI TISPAN WG4 may do the same here as they did for User ENUM in TS 102 055 "(user) ENUM Administration for Europe" for Infrastructure ENUM. =20 Richard =20 ________________________________ Von: enum-bounces@ietf.org im Auftrag von lconroy Gesendet: Do 01.12.2005 19:57 An: Richard Shockey Cc: enum@ietf.org; Pfautz, Penn L, NEO; McGarry,Tom Betreff: Re: [Enum] Re: Update of Carrier ENUM requirements I-D Hi again Richard, Penn, Tom, folks, Yup - an NRA/LEA *may* have many interesting and arcane requirements. Other NRAs may want nothing to do with this, leaving it up to the Carriers/SPs to do their own thing. There are a number of possible architectural models: - a Centralised system (with or without governmental oversight) is one solution, but not the only one. I hope that the requirements will reflect more than one approach. If the particular solution involves delegation, then you get some help from the SOA record. It depends on who you want to contact, and what you want them to fix (see Patrik's excellent earlier mail in this thread for some of the potential nitwits you may need to call). I am still not clear if IRIS is always needed to maintain network=20 integrity, and hope that someone can spell out WHY this is the case in the=20 document. (i.e. what needs to be done, and how IRIS [or whatever] can do this) all the best, Lawrence On 1 Dec 2005, at 16:33, Richard Shockey wrote (and I corrected): > lconroy wrote: >> Hi Penn, Tom, folks, >> Less is undoubtedly more - anything not needed is superfluous. >> Also, why are we trying to specify anything that is going to be =20 >> ignored (or, more specifically, can safely be ignored)? >> Re. IRIS: >> If COR/SPoR/... is the Registrant, and as Patrik points out,=20 >> there can be many different organisations involved, what exactly=20 >> does IRIR bring to the party? It won't have ANY information on=20 >> the end user who is provided service via this number - he or she=20 >> is not the registrant. > maybe maybe not ..it depends on what the local requirements are....=20 > and there are lots of LEAs and NRAs these days with lots of=20 > requiremnts. > > Its principal function, in theory, provide contact data on the=20 > network operators responsible for that TN. In DNS registration=20 > terms terms that is classic stuff. It answers questions about who=20 > is responsible for a domain. > > Say I'm trying to get a call through it doesnt work who .. is the=20 > nitwit running their proxies SBC's or DNS infrastructure so you can=20 > tell them to fix it. > >> Perhaps someone should spell out exactly WHAT one might use IRIS=20 >> to provide, and leave it up to the Infrastructure people using=20 >> an implementation of this system to decide if they need this. >> My feeling is that some will, some won't, > It would be almost foolish to run a Infrastructure ENUM system=20 > without an IRIS service associated with it. You cant maintain the=20 > integrity of the network without it. > > and (allegedly :) some will want to include this just to b*gg*r up=20 > any players who don't support it already (or use some other means=20 > of providing the same information to their peers). >> all the best, >> Lawrence >> On 1 Dec 2005, at 15:52, Pfautz, Penn L, NEO wrote: >>> Tom: >>> I can include a statement that COR=3Dregistrant in the next draft.=20 >>> I agree that it's useful to be explicit here. In the same=20 >>> spirit, I see most of the requirements as useful to state even=20 >>> where they might logically be inferred from end user ENUM. >>> >>> I do see a use for a properly restricted IRIS capability but =20 >>> obviously the IETF can't dictate to anyone except in matter of =20 >>> protocol capabilities. I believe other service providers would=20 >>> also like to see this particular capability. >>> >>> Penn >>> >>> -----Original Message----- >>> From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On =20 >>> Behalf Of McGarry, Tom >>> Sent: Thursday, December 01, 2005 10:24 AM >>> To: enum@ietf.org >>> Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D >>> >>> The definition of carrier (or infrastructure) ENUM is - the=20 >>> carrier of record (as defined here) is the registrant. This is=20 >>> as opposed to end user ENUM where - the end user is the=20 >>> registrant. This is important because it defines "who" chooses=20 >>> to register the TN in Tier 1. >>> >>> I don't believe either of the carrier ENUM documents have made=20 >>> this point explicitly. Of course one of the problems is that=20 >>> end user ENUM has never been defined. >>> >>> The definitions of the two types of ENUM is as simple as that. >>> >>> In addition, most of the requirements listed in Section 2 of=20 >>> draft- lind-infrastructure-enum-reqs-01 would not be unique to=20 >>> carrier ENUM, e.g., privacy, high reliability and performance,=20 >>> choice, support for open numbering plans, etc. Also, most of=20 >>> the requirements seem to be very local (country specific) in=20 >>> nature. Do the existing ENUM Tier 1s provide IRIS? If not,=20 >>> should they be excluded from providing carrier ENUM (if it were=20 >>> to come around)? Is that really something we should be=20 >>> dictating to countries? >>> >>> In the case of carrier ENUM definitions and requirements, I=20 >>> believe less is more. >>> >> _______________________________________________ >> 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 _______________________________________________ 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 Dec 02 03:19:54 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 1Ei694-0005rB-Fc; Fri, 02 Dec 2005 03:19:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei693-0005pa-K5 for enum@megatron.ietf.org; Fri, 02 Dec 2005 03:19:53 -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 DAA21733 for ; Fri, 2 Dec 2005 03:19:05 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei6Tg-0004zs-GB for enum@ietf.org; Fri, 02 Dec 2005 03:41:13 -0500 Received: from [192.168.1.206] (85-124-86-41.dynamic.xdsl-line.inode.at [::ffff:85.124.86.41]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Fri, 02 Dec 2005 09:19:38 +0100 id 00068368.4390039C.00007B93 Message-ID: <4390037C.8000406@enum.at> Date: Fri, 02 Dec 2005 09:19:08 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: enum@ietf.org, voipeer@lists.uoregon.edu Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] cablelabs & VoIP peering X-BeenThere: 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 mentioned as "critical to the IP peering effort". http://www.cabledatacomnews.com/dec05/dec05-3.html cheers Alex Mayrhofer _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 02 15:51:12 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 1EiHs8-000723-1b; Fri, 02 Dec 2005 15:51:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiHr9-0006Y8-Fq; Fri, 02 Dec 2005 15:50:11 -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 PAA12578; Fri, 2 Dec 2005 15:49:21 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiIBo-0005sj-3w; Fri, 02 Dec 2005 16:11:34 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EiHr0-0003FC-K6; Fri, 02 Dec 2005 15:50:02 -0500 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, 02 Dec 2005 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-pstn-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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA12578 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-01.txt Pages : 11 Date : 2005-12-2 =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-01.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-01.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-01.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-12-2152314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-pstn-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-pstn-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-2152314.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 Dec 05 12:16:20 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 1EjJwq-0003YC-Hy; Mon, 05 Dec 2005 12:16:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjJwo-0003Xy-QT for enum@megatron.ietf.org; Mon, 05 Dec 2005 12:16:18 -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 MAA15215 for ; Mon, 5 Dec 2005 12:15:28 -0500 (EST) Message-Id: <200512051715.MAA15215@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjKI9-0001ER-1l for enum@ietf.org; Mon, 05 Dec 2005 12:38:21 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjJwg-000BgA-ED for enum@ietf.org; Mon, 05 Dec 2005 17:16:10 +0000 To: enum@ietf.org Date: Mon, 05 Dec 2005 09:16:10 -0800 From: Allison Mankin X-Spam-Score: 0.8 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Subject: [Enum] WG Review: Recharter of Telephone Number Mapping (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 Rich, Patrick, ENUM folks, The ENUM re-charter has been approved. You'll see an announcement sometime in the coming week. The IESG did not have a telechat between 27 October and 1 December, because of scheduling issues around the IETF meeting, so this was the first opportunity for approval. I appreciate the excellent discussions by this working group, which got us to this charter. Your Chairs did an excellent job here. And I look forward to seeing you guys accomplish these goals (on time :) both during my watch for a while longer and with your next AD. Best, Allison ------ To: new-work@ietf.org From: The IESG Date: Thu, 03 Nov 2005 10:55:50 -0500 Subject: WG Review: Recharter of Telephone Number Mapping (enum) A modified charter has been submitted for the Telephone Number Mapping (enum) working group in the Transport Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by November 9th. +++ Telephone Number Mapping (enum) ================================ Current Status: Active Working Group Chair(s): Patrik Faltstrom Richard Shockey Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: Allison Mankin Secretary(ies): Alex Mayrhofer Mailing Lists: General Discussion: enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/enum/index.html 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Dec 05 16:40:25 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 1EjO4P-0002Lk-LW; Mon, 05 Dec 2005 16:40:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjO4K-0002KH-KK; Mon, 05 Dec 2005 16:40:20 -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 QAA14728; Mon, 5 Dec 2005 16:39:30 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjOPh-0002Aa-9d; Mon, 05 Dec 2005 17:02:25 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EjO4J-0008IM-4B; Mon, 05 Dec 2005 16:40:19 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 05 Dec 2005 16:40:19 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: enum mailing list , Internet Architecture Board , enum chair , enum chair , RFC Editor Subject: [Enum] Protocol Action: '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 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 approved the following document: - 'An ENUM Registry Type for the Internet Registry Information Service ' as a Proposed Standard This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-iris-ereg-02.txt-02.txt Technical Summary This document describes an IRIS (RFCs 3981-3983) 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. The document includes support for privacy labeling of objects in the registries. Working Group Summary The working group gave a detailed consensus to this document, after many cycles of discussion and review. Protocol Quality Allison Mankin reviewed the specification for the IESG and notes that the specification should be reviewed to see if new enumservices such as the local number portability data will need extensions from it in future. Elwyn Davies gave a useful review for the General Area Directorate. Notes to RFC Editor: 1. Delete the following from Section 3.2.5, and delete reference [15] o - elements containing an e-mail address within an internationalized domain name [15]. 2. Section 8.2 OLD: S-NAPTR application service label NEW: S-NAPTR application service tag [20] [20] is a normative reference to RFC 3958 3. Section 3.24 OLD: o - the fully qualified domain name of the host. The contents of this element are a domain name and MUST conform to RFC 1035 [9]. NEW: o - the fully qualified domain name of the host. The contents of this element are a host name and MUST conform to RFC 1123 [xx]. Add a normative Reference to RFC 1123. 4. Section 3.4 OLD: o enum - the fully qualified name of an ENUM domain. This is a domain name as specified by RFC 1035 [9]. It yields a (Section 3.2.3) in the response. NEW: o enum - the fully qualified name of an ENUM domain. This is a domain name as specified by RFC 3761 [18]. It yields a (Section 3.2.3) in the response. 5. Normative References: Replace [3] and [4] with [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML Schema, October 2004, . [4] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML Schema, October 2004, 6. Section 3.2.3 OLD: +1 7035 555 1212 NEW: +1 703 555 1212 There are four occurrences of the number 555 1212 in this section. Please replace 1212 with 1234. (1212 is a working number, whereas 1234 is a valid example). _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 06 04:50:50 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 1EjZTG-0006qC-IM; Tue, 06 Dec 2005 04:50:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjZTE-0006pS-QO; Tue, 06 Dec 2005 04:50:49 -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 EAA00682; Tue, 6 Dec 2005 04:49:57 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EjZof-0001hE-Kn; Tue, 06 Dec 2005 05:12:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Dec 2005 10:54:12 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B227B@oefeg-s04.oefeg.loc> Thread-Topic: SIP AoR, tel and ENUM Thread-Index: AcX6SwJitdWYiDMnQBa1ILCKsfjKoA== From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, sip@ietf.org Subject: [Enum] SIP AoR, tel and 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 Folks, This post is primarily to SPEER, but since it also concerns ENUM and SIP I cross-post it. I need (urgently) some guidance on the question what SIP URIs to use in Infrastructure ENUM. User ENUM as defined in RFC 3761 provides a mapping from E.164 numbers to SIP URIs for primarily for end-users. So what you get back is the AoR pointing to the destination SIP server. If you get something back on the ENUM query such as sip:Richard@stastny.com, this is definetely an AoR. Because of privacy reasons, more and more people start using SIP URI such as sip:4319793321@provider.net or (an AoR) sip:+4319793321@provider.net;user=3Dphone (IMHO not an AoR) or even sip:+4319793321@provider.net IMHO the last one should not be used, and some guidance is also needed here. but it only concerns the destination server and if the destination servers can deal with it, fine. Now with Infrastructure ENUM (and especially in combination with private ENUMs) the situation is different. The purpose of Infrastructure ENUM is according to the re-chartered ENUM WG "to discover points of interconnection necessary to terminate communications sessions identified by a E164 number, in addition to identifying end point protocols and services." This translates to: Infrastructure ENUM does not necessarily contain end-point information (AoR), but routing information. Routing, in my definition here, is basically to provide you with the information what the next hop is. A very common scenario is the following one: a walled garden network is using private ENUM to detect the border element for a given number, Some border element may lead to another private (extranet), using a federated ENUM for this number, another may be connected to the=20 Internet using public Infrastructure ENUM for another number. Public Infrastructure ENUM is giving back the ingress border element, which in turn uses private ENUM again to find the SIP server hosting the user with this number. In addition, again for privacy reasons, in most cases the above mentioned SIP URIs containing E.164 numbers are used. This raises two issues, an architectural one and a BCP one: To principally different scenarios are possible Scenario A ENUM is providing ONLY the mapping from the E.164 number to an AoR. (=3D name to address mapping) The above described routing between the networks to find the destination network is done via the AoR. How this is done is completely within the scope of SPEER. Note: this is the only future proof way, because a user may use the AoR in the first place and then the routing MUST work anyway. So any additional routing information in ENUM would be duplicated and therefore error-prone. I propose in addition to use in this case a SIP in the format sip:4319793321@provider.net, to clearly indicate that this has no relationship to an E.164 number. Scenario B: This is the scenario proposed in most current implementations and also in the RFI on ENUM popping up everywhere. The reason is that most scenarios currently concentrate solely on the peering with E.164 numbers and completely forget the peering with SIP URIs The ENUM entry is giving you the next hop: This is in case of the walled garden originating network either the server hosting the end-user or the egress border element (e.g. IBCF, THIG, or whatchamacallit). This element is again querying another kind of ENUM, getting back the ingress border element of the destination network (or even of a "transit" L5 network), and so on. The ingress border element is the again calling its private ENUM to finally find the hosting server. Note: I have a sub-question here: Some implementations are even proposing here to skip the SRV query and directly pointing to the SIP server(s) in ENUM. Does this make sense? If this scenario is used, I propose to use only SIP URIs in the format sip:+4319793321@provider.net;user=3Dphone or better SIP:+4319793321@sbc.prov.net; user=3Dphone to clearly indicate that this is still basically a=20 tel: URI combined with a routing info and that it may=20 be used in another ENUM query. My questions to the crowd are the following: 1. is this proposed use of SIP URIs within the context of ENUM ok? 2. What should be the preferred scenario for VoIP peering?=20 Is some kind of combination between the scenarios feasible?=20 And what are the arguments pro and con? I consider the outcome of this discussion as substantial input to the deliverables of SPEER, but some first guidance is urgently required now, because many entities are making basic decisions in this direction NOW. Please also excuse and correct incorrect use of terminology. Regards Richard Stastny _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 06 10:21:39 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 1EjedP-0006Kp-3Y; Tue, 06 Dec 2005 10:21:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjedN-0006HO-2X; Tue, 06 Dec 2005 10:21:37 -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 KAA12188; Tue, 6 Dec 2005 10:20:45 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejeys-0005oJ-5P; Tue, 06 Dec 2005 10:43:51 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 06 Dec 2005 07:21:27 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jB6FLHMi027262; Tue, 6 Dec 2005 07:21:24 -0800 (PST) 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, 6 Dec 2005 10:21:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Dec 2005 10:21:19 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA0353@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] SIP AoR, tel and ENUM Thread-Index: AcX6SwJitdWYiDMnQBa1ILCKsfjKoAAK+G+Q From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , X-OriginalArrivalTime: 06 Dec 2005 15:21:20.0835 (UTC) FILETIME=[B61DC130:01C5FA78] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, sip@ietf.org Subject: [Enum] RE: [Sip] SIP AoR, tel and 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 et al, Before going down this path too far, can we ask where the results of the ENUM queries will go in the SIP message to control routing? Hypothetically, the egress and ingress gateways could be identified in Route headers rather than in the Request-URI. An external ENUM dip and an internal ENUM dip might lead to something along the lines of: INVITE tel:+17775551111 SIP/2.0 ... Route: Route: ... I am also suggesting that the ENUM result be an AoR, since one might want some reliability in choosing which server in the gateway cluster to go to based on further DNS queries, load balancing, etc. Mike > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Stastny Richard > Sent: Tuesday, December 06, 2005 4:54 AM > To: voipeer@lists.uoregon.edu > Cc: enum@ietf.org; sip@ietf.org > Subject: [Sip] SIP AoR, tel and ENUM >=20 > Folks, >=20 > This post is primarily to SPEER, but since it also concerns=20 > ENUM and SIP I cross-post it. >=20 > I need (urgently) some guidance on the question what SIP URIs=20 > to use in Infrastructure ENUM. >=20 > User ENUM as defined in RFC 3761 provides a mapping from=20 > E.164 numbers to SIP URIs for primarily for end-users. So=20 > what you get back is the AoR pointing to the destination SIP server. >=20 > If you get something back on the ENUM query such as=20 > sip:Richard@stastny.com, this is definetely an AoR. Because=20 > of privacy reasons, more and more people start using SIP URI=20 > such as sip:4319793321@provider.net or (an AoR)=20 > sip:+4319793321@provider.net;user=3Dphone (IMHO not an AoR) or=20 > even sip:+4319793321@provider.net >=20 > IMHO the last one should not be used, and some guidance is=20 > also needed here. but it only concerns the destination server=20 > and if the destination servers can deal with it, fine. >=20 > Now with Infrastructure ENUM (and especially in combination=20 > with private ENUMs) the situation is different. >=20 > The purpose of Infrastructure ENUM is according to the=20 > re-chartered ENUM WG "to discover points of interconnection=20 > necessary to terminate communications sessions identified by=20 > a E164 number, in addition to identifying end point protocols=20 > and services." >=20 > This translates to: Infrastructure ENUM does not necessarily=20 > contain end-point information (AoR), but routing information.=20 > Routing, in my definition here, is basically to provide you=20 > with the information what the next hop is. >=20 > A very common scenario is the following one: a walled garden=20 > network is using private ENUM to detect the border element=20 > for a given number, Some border element may lead to another=20 > private (extranet), using a federated ENUM for this number,=20 > another may be connected to the Internet using public=20 > Infrastructure ENUM for another number. > Public Infrastructure ENUM is giving back the ingress border=20 > element, which in turn uses private ENUM again to find the=20 > SIP server hosting the user with this number. >=20 > In addition, again for privacy reasons, in most cases the=20 > above mentioned SIP URIs containing E.164 numbers are used. >=20 > This raises two issues, an architectural one and a BCP one: >=20 > To principally different scenarios are possible >=20 > Scenario A >=20 > ENUM is providing ONLY the mapping from the E.164 number to=20 > an AoR. (=3D name to address mapping) The above described=20 > routing between the networks to find the destination network=20 > is done via the AoR. How this is done is completely within=20 > the scope of SPEER. >=20 > Note: this is the only future proof way, because a user may=20 > use the AoR in the first place and then the routing MUST work=20 > anyway. So any additional routing information in ENUM would=20 > be duplicated and therefore error-prone. >=20 > I propose in addition to use in this case a SIP in the format=20 > sip:4319793321@provider.net, to clearly indicate that this=20 > has no relationship to an E.164 number. >=20 > Scenario B: >=20 > This is the scenario proposed in most current implementations=20 > and also in the RFI on ENUM popping up everywhere. The reason=20 > is that most scenarios currently concentrate solely on the=20 > peering with E.164 numbers and completely forget the peering=20 > with SIP URIs >=20 > The ENUM entry is giving you the next hop: This is in case of=20 > the walled garden originating network either the server=20 > hosting the end-user or the egress border element (e.g. IBCF,=20 > THIG, or whatchamacallit). This element is again querying=20 > another kind of ENUM, getting back the ingress border element=20 > of the destination network (or even of a "transit" L5=20 > network), and so on. The ingress border element is the again=20 > calling its private ENUM to finally find the hosting server. >=20 > Note: I have a sub-question here: Some implementations are=20 > even proposing here to skip the SRV query and directly=20 > pointing to the SIP server(s) in ENUM. Does this make sense? >=20 > If this scenario is used, I propose to use only SIP URIs in=20 > the format sip:+4319793321@provider.net;user=3Dphone or better=20 > SIP:+4319793321@sbc.prov.net; user=3Dphone >=20 > to clearly indicate that this is still basically a > tel: URI combined with a routing info and that it may be used=20 > in another ENUM query. >=20 > My questions to the crowd are the following: >=20 > 1. is this proposed use of SIP URIs within the context of ENUM ok? >=20 > 2. What should be the preferred scenario for VoIP peering?=20 > Is some kind of combination between the scenarios feasible?=20 > And what are the arguments pro and con? >=20 > I consider the outcome of this discussion as substantial=20 > input to the deliverables of SPEER, but some first guidance=20 > is urgently required now, because many entities are making=20 > basic decisions in this direction NOW. >=20 > Please also excuse and correct incorrect use of terminology. >=20 > Regards > Richard Stastny >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 06 10:44:00 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 1Ejez2-0004f3-V1; Tue, 06 Dec 2005 10:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejez2-0004eJ-5I; Tue, 06 Dec 2005 10:44:00 -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 KAA14876; Tue, 6 Dec 2005 10:43:07 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EjfKX-0006ag-Bn; Tue, 06 Dec 2005 11:06:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Dec 2005 16:47:29 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C46F4@oefeg-s04.oefeg.loc> Thread-Topic: [Sip] SIP AoR, tel and ENUM Thread-Index: AcX6SwJitdWYiDMnQBa1ILCKsfjKoAAK+G+QAAEpMrU= From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, sip@ietf.org Subject: [Enum] Re: [Sip] SIP AoR, tel and 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 Mike wrote: >Before going down this path too far, can we ask where the results of = the >ENUM queries will go in the SIP message to control routing? >Hypothetically, the egress and ingress gateways could be identified in >Route headers rather than in the Request-URI. An external ENUM dip and >an internal ENUM dip might lead to something along the lines of: =20 Correct, =20 Jonathan proposed this some time ago, but this thread somewhere stranded =20 So basically an interneal ENUM entry of sip:+1777555111@egress.provider3.com;user=3Dphone =20 would result in INVITE tel:+17775551111 SIP/2.0 ... Route: =20 an the external ENUM entry would be sip:+1777555111@provider17.com =20 result in Route: =20 This is basically what I am after ... >I am also suggesting that the ENUM result be an AoR, since one might >want some reliability in choosing which server in the gateway cluster = to >go to based on further DNS queries, load balancing, etc. =20 Now this is in contradiction to the above =20 Richard >Mike > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Stastny Richard > Sent: Tuesday, December 06, 2005 4:54 AM > To: voipeer@lists.uoregon.edu > Cc: enum@ietf.org; sip@ietf.org > Subject: [Sip] SIP AoR, tel and ENUM > > Folks, > > This post is primarily to SPEER, but since it also concerns > ENUM and SIP I cross-post it. > > I need (urgently) some guidance on the question what SIP URIs > to use in Infrastructure ENUM. > > User ENUM as defined in RFC 3761 provides a mapping from > E.164 numbers to SIP URIs for primarily for end-users. So > what you get back is the AoR pointing to the destination SIP server. > > If you get something back on the ENUM query such as > sip:Richard@stastny.com, this is definetely an AoR. Because > of privacy reasons, more and more people start using SIP URI > such as sip:4319793321@provider.net or (an AoR) > sip:+4319793321@provider.net;user=3Dphone (IMHO not an AoR) or > even sip:+4319793321@provider.net > > IMHO the last one should not be used, and some guidance is > also needed here. but it only concerns the destination server > and if the destination servers can deal with it, fine. > > Now with Infrastructure ENUM (and especially in combination > with private ENUMs) the situation is different. > > The purpose of Infrastructure ENUM is according to the > re-chartered ENUM WG "to discover points of interconnection > necessary to terminate communications sessions identified by > a E164 number, in addition to identifying end point protocols > and services." > > This translates to: Infrastructure ENUM does not necessarily > contain end-point information (AoR), but routing information. > Routing, in my definition here, is basically to provide you > with the information what the next hop is. > > A very common scenario is the following one: a walled garden > network is using private ENUM to detect the border element > for a given number, Some border element may lead to another > private (extranet), using a federated ENUM for this number, > another may be connected to the Internet using public > Infrastructure ENUM for another number. > Public Infrastructure ENUM is giving back the ingress border > element, which in turn uses private ENUM again to find the > SIP server hosting the user with this number. > > In addition, again for privacy reasons, in most cases the > above mentioned SIP URIs containing E.164 numbers are used. > > This raises two issues, an architectural one and a BCP one: > > To principally different scenarios are possible > > Scenario A > > ENUM is providing ONLY the mapping from the E.164 number to > an AoR. (=3D name to address mapping) The above described > routing between the networks to find the destination network > is done via the AoR. How this is done is completely within > the scope of SPEER. > > Note: this is the only future proof way, because a user may > use the AoR in the first place and then the routing MUST work > anyway. So any additional routing information in ENUM would > be duplicated and therefore error-prone. > > I propose in addition to use in this case a SIP in the format > sip:4319793321@provider.net, to clearly indicate that this > has no relationship to an E.164 number. > > Scenario B: > > This is the scenario proposed in most current implementations > and also in the RFI on ENUM popping up everywhere. The reason > is that most scenarios currently concentrate solely on the > peering with E.164 numbers and completely forget the peering > with SIP URIs > > The ENUM entry is giving you the next hop: This is in case of > the walled garden originating network either the server > hosting the end-user or the egress border element (e.g. IBCF, > THIG, or whatchamacallit). This element is again querying > another kind of ENUM, getting back the ingress border element > of the destination network (or even of a "transit" L5 > network), and so on. The ingress border element is the again > calling its private ENUM to finally find the hosting server. > > Note: I have a sub-question here: Some implementations are > even proposing here to skip the SRV query and directly > pointing to the SIP server(s) in ENUM. Does this make sense? > > If this scenario is used, I propose to use only SIP URIs in > the format sip:+4319793321@provider.net;user=3Dphone or better > SIP:+4319793321@sbc.prov.net; user=3Dphone > > to clearly indicate that this is still basically a > tel: URI combined with a routing info and that it may be used > in another ENUM query. > > My questions to the crowd are the following: > > 1. is this proposed use of SIP URIs within the context of ENUM ok? > > 2. What should be the preferred scenario for VoIP peering? > Is some kind of combination between the scenarios feasible? > And what are the arguments pro and con? > > I consider the outcome of this discussion as substantial > input to the deliverables of SPEER, but some first guidance > is urgently required now, because many entities are making > basic decisions in this direction NOW. > > Please also excuse and correct incorrect use of terminology. > > Regards > Richard Stastny > > > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 06 11:07:44 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 1EjfM0-0001fO-Ry; Tue, 06 Dec 2005 11:07:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjfM0-0001fE-9L for enum@megatron.ietf.org; Tue, 06 Dec 2005 11:07:44 -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 LAA17277 for ; Tue, 6 Dec 2005 11:06:53 -0500 (EST) Resent-From: dmm@1-4-5.net Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjfhW-0007PE-G6 for enum@ietf.org; Tue, 06 Dec 2005 11:29:59 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id jB6G7Yth017164 for ; Tue, 6 Dec 2005 08:07:34 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id jB6G7YvD017163 for enum@ietf.org; Tue, 6 Dec 2005 08:07:34 -0800 Resent-Message-Id: <200512061607.jB6G7YvD017163@m106.maoz.com> X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id jB6Ft34A016635 for ; Tue, 6 Dec 2005 07:55:03 -0800 Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/JbmijLMaogcja+eUuvWBaMd0tVDtprS0@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id jB6FsnNo021812; Tue, 6 Dec 2005 07:54:49 -0800 Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.5/8.13.5/Submit) id jB6Fsn71021811; Tue, 6 Dec 2005 07:54:49 -0800 Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by mailapps.uoregon.edu (8.13.5/8.13.5) with ESMTP id jB6Fsigc021806 for ; Tue, 6 Dec 2005 07:54:44 -0800 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id jB6Fsh9T016630; Tue, 6 Dec 2005 07:54:43 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id jB6FseMj016629; Tue, 6 Dec 2005 07:54:40 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 6 Dec 2005 07:54:40 -0800 From: David Meyer To: voipeer@lists.uoregon.edu Message-ID: <20051206155440.GA16571@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-Virus-Scanned: ClamAV 0.87.1/1204/Mon Dec 5 02:09:54 2005 on mailapps X-Virus-Status: Clean Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on m106.maoz.com X-Spam-Status: No, score=-2.4 required=4.5 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.4 Resent-Date: Tue, 6 Dec 2005 08:07:34 -0800 Resent-To: enum@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: Jason_Livingood@cable.comcast.com, jon.peterson@neustar.biz, mankin@psg.com Subject: [Enum] [voipeer] Revised VOIPEER Charter (note name change...) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1631917358==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1631917358== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks,=20 Please find enclosed the most recent rev of the charter. Note also that the name has changed to speermint; there were various problems with the name SPEER (which came to light over various email discussions). Credit Jason with name speermint :-)=20 Finally, we're working on getting speermint@lists.ietf.org=20 going; I will let you know when that is complete.=20 Dave --- Session PEERing for Multimedia INTerconnect (speermint) Last Modified: 2005-12-06 Chair(s): Jason Livingood David Meyer Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: Allison Mankin Mailing Lists: General Discussion: speermint@ietf.org To Subscribe: speermint-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/speermint/index.= html Description of Working Group: The term "VoIP Peering" has historically been used to describe inter-provider network interconnect and the delivery of voice calls over interconnection points. While voice calls are the primary motivation for this today, other forms of real-time communications are and will continue to evolve as natural additions to such peering. Therefore, the focus of this working group is best generalized to describe calls as sessions, and to note that that such communications are inherently real-time in nature. SPEERMINT focuses architectures to identify, signal, and route delay-sensitive (real-time) communication sessions at the application level ("layer 5"). These sessions use the SIP signaling protocol to enable peering between two or more administrative domains over IP networks. Where these domains peer, or meet, the establishment of trust, security, and a resistance to abuse and attack are all important considerations. Note that the term "Layer 5 network" is used here to refer to the interconnection between application layer entities such as SIP servers, as opposed to interconnection at the IP network layer. However, in order to achieve real-time Session PEERing, both signaling and media flows must be taken into consideration. In addition, the working group recognizes that there will be use cases that require SPEERMINT to focus on the interaction between the application layer and lower network layers, or the dependence of specific application layer use cases on lower layers, so SPEERMINT will have to be prepared to solve these problems as they arise. More specifically, SPEERMINT focuses on real-time session routing architectures for layer 5 networks and their associated use cases. This includes the specification of the various types of application flows, such as signaling and media flows, in such networks, and includes both trunking and peer-to-peer flows. In addition, SPEERMINT considers requirements for the feedback of operational conditions (e.g., congestion control) that enables the application of dynamic policy and recognizes that various mechanisms for achieving this should be studied as a potential part of any architecture. SPEERMINT may also consider various mechanisms to support the application of Quality of Service (QoS) in some manner. In particular, SPEERMINT specifies mechanisms for layer 2 and/or layer 3 peering in support of real-time Session PEERing. It is important to note that these mechanisms may be developed in other working groups. In addition, SPEERMINT develops best current practices regarding exchange of real-time sessions among VoIP and other real-time application service providers and, in particular, how such calls are routed. SPEERMINT recognizes that some of these providers also control underlying access networks (facilities-based), while others do not (not facilities-based), and this fact may present various additional requirements or use cases for consideration, as well as guides SPEERMINT to maintain the greatest possible separation of the application layer from lower layers. The SPEERMINT work plan is also intimately related to the work plans being pursued by the ENUM and SIPPING working groups. In particular, while the ENUM Working Group is primarily concerned with the structure and lookup of data for the translation of E.164 numbers into URIs (RFC3761), SPEERMINT is concerned with the use of the resulting URI data, as well as non-ENUM-derived URI data, for use in signaling and routing of real-time sessions. Further issues that are out of scope for SPEERMINT include:=20 o Interoperability, and NITS/profiling of existing protocols such as SIP, RTP, and SRTP, o SPIT prevention. Note, however, that other working groups may release relevant specifications that become required or are referenced by various SPEERMINT uses cases and BCPs, o Routing of sessions which are not signaled using SIP. In particular, SPEERMINT is constrained to consider only those scenarios in which call routing is signaled using the SIP protocol and addressed by SIP or SIPS URIs. E.164 numbers and other national or private formats may only be used as defined within the SIP protocols, and=20 o H.323 --- Goals and Milestones: Mar 2006 Submit SPEERMINT terminology I-D. Mar 2006 Submit I-D defining the SPEERMINT routing architecture (Informational). Dec 2006 Submit I-D defining the message flows associated=20 with the SPEERMINT routing architecture (Informational). =20 Jan 2007 Submit I-D on the use of DNS SRV and NAPTR records as specified by RFC 3263 (BCP). =20 Jan 2007 Submit I-D on the minimum set of requirements for SIP-based VoIP interconnection (BCP). =20 Mar 2007 Submit I-D specifying the use of addressing forms and provides strong identities (BCP). =20 Jun 2007 Submit I-D(s) on use cases (BCP). Jun 2006 Submit SPEERMINT terminology document to IESG (Informational).=20 Mar 2007 Submit document to the IESG on the minimum set of requirements for SIP-based VoIP interconnection. =20 Mar 2007 Submit document defining the call flows associated with the SPEERMINT routing architecture to the IESG (Proposed Standard).=20 Jul 2006 Submit document defining the SPEERMINT routing architecture to the IESG (Informational). =20 Mar 2007 Submit document to IESG specifying the use of addressing forms and provides strong identities (BCP). Jun 2007 Submit document to IESG on the use of DNS SRV and NAPTR records as specified by RFC 3263 (BCP). =20 Jun 2007 Submit document(s) to IESG on use cases (BCP) (ongoing). Internet-Drafts: draft-meyer-voipeer-terminology-01.txt Request For Comments: None --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDlbRAORgD1qCZ2KcRAkyuAJ4kHvKU46JpzPT/V7cSsIGNs+1QZwCfWTZ7 7msz2Ue5VviNRN6JKdem9vs= =Lcgr -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- _____________________________________________________________________________ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html --===============1631917358== 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 --===============1631917358==-- _____________________________________________________________________________ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html From enum-bounces@ietf.org Tue Dec 06 11:49:23 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 1Ejg0J-0000dG-Ls; Tue, 06 Dec 2005 11:49:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejg0H-0000c7-RO; Tue, 06 Dec 2005 11:49:22 -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 LAA22487; Tue, 6 Dec 2005 11:48:31 -0500 (EST) Received: from nat.labs.nic.at ([83.136.33.3] helo=whistler) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjgLo-0000WW-0u; Tue, 06 Dec 2005 12:11:36 -0500 Received: from klauspc.intern ([10.10.0.50]) by whistler with esmtp (Exim 3.36 #1 (Debian)) id 1Ejfzm-0003N0-00; Tue, 06 Dec 2005 17:48:50 +0100 Message-ID: <4395C0DA.4040206@pernau.at> Date: Tue, 06 Dec 2005 17:48:26 +0100 From: Klaus Darilion User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard References: <32755D354E6B65498C3BD9FD496C7D462C46F4@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C46F4@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, voipeer@lists.uoregon.edu, sip@ietf.org, "Michael Hammer \(mhammer\)" Subject: [Enum] Re: [Sip] SIP AoR, tel and 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 Stastny Richard wrote: > Mike wrote: > > >>Before going down this path too far, can we ask where the results of the >>ENUM queries will go in the SIP message to control routing? >>Hypothetically, the egress and ingress gateways could be identified in >>Route headers rather than in the Request-URI. An external ENUM dip and >>an internal ENUM dip might lead to something along the lines of: > > > Correct, > > Jonathan proposed this some time ago, but this thread somewhere stranded > > So basically an interneal ENUM entry of > > sip:+1777555111@egress.provider3.com;user=phone > > would result in > > INVITE tel:+17775551111 SIP/2.0 > ... > Route: > > an the external ENUM entry would be > sip:+1777555111@provider17.com > > result in > Route: > > This is basically what I am after > ... > Hi folks. What is the benefit of splitting the ENUM result (the SIP URI) into a Route header and into a request URI? IMO there should be no semantic for the internal routing (the routing from the main proxy to the egress proxy). This should be out of scope of all WGs. Also the internal routing of the ingress provider should be out of scope. The ingress provider should have SIP URI which can be used to address its customers. If this URI is sip:431505641636@in.mydomain.com or foobar666@in.mydomain.com, or sip:klaus.darilion@mydomain.com is the ingress provider's choice. Maybe the ingress provider also allows all of the previous SIP URIs to reach a certain user. The incoming provider just has to make sure that these SIP URIs map to the corresponding user (to the user's AoR). If this user also has an E.164 number which is in I-ENUM, then it's again the ingress provider's choice which URI to put into the NAPTR. IMO there should not not be any semantics how to create a request URI and a pre-loaded route set of the SIP URI received from ENUM. The egress proxy sends the request to the ingress proxy in the format choosen by the ingress provider (e.g. publish via ENUM or an business cards). We should not complicate things. I do not see any problems with this simple approach. If there are some problems, please correct me. regards klaus > >>I am also suggesting that the ENUM result be an AoR, since one might >>want some reliability in choosing which server in the gateway cluster to >>go to based on further DNS queries, load balancing, etc. > > > Now this is in contradiction to the above > > Richard > > >>Mike > > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>Behalf Of Stastny Richard >>Sent: Tuesday, December 06, 2005 4:54 AM >>To: voipeer@lists.uoregon.edu >>Cc: enum@ietf.org; sip@ietf.org >>Subject: [Sip] SIP AoR, tel and ENUM >> >>Folks, >> >>This post is primarily to SPEER, but since it also concerns >>ENUM and SIP I cross-post it. >> >>I need (urgently) some guidance on the question what SIP URIs >>to use in Infrastructure ENUM. >> >>User ENUM as defined in RFC 3761 provides a mapping from >>E.164 numbers to SIP URIs for primarily for end-users. So >>what you get back is the AoR pointing to the destination SIP server. >> >>If you get something back on the ENUM query such as >>sip:Richard@stastny.com, this is definetely an AoR. Because >>of privacy reasons, more and more people start using SIP URI >>such as sip:4319793321@provider.net or (an AoR) >>sip:+4319793321@provider.net;user=phone (IMHO not an AoR) or >>even sip:+4319793321@provider.net >> >>IMHO the last one should not be used, and some guidance is >>also needed here. but it only concerns the destination server >>and if the destination servers can deal with it, fine. >> >>Now with Infrastructure ENUM (and especially in combination >>with private ENUMs) the situation is different. >> >>The purpose of Infrastructure ENUM is according to the >>re-chartered ENUM WG "to discover points of interconnection >>necessary to terminate communications sessions identified by >>a E164 number, in addition to identifying end point protocols >>and services." >> >>This translates to: Infrastructure ENUM does not necessarily >>contain end-point information (AoR), but routing information. >>Routing, in my definition here, is basically to provide you >>with the information what the next hop is. >> >>A very common scenario is the following one: a walled garden >>network is using private ENUM to detect the border element >>for a given number, Some border element may lead to another >>private (extranet), using a federated ENUM for this number, >>another may be connected to the Internet using public >>Infrastructure ENUM for another number. >>Public Infrastructure ENUM is giving back the ingress border >>element, which in turn uses private ENUM again to find the >>SIP server hosting the user with this number. >> >>In addition, again for privacy reasons, in most cases the >>above mentioned SIP URIs containing E.164 numbers are used. >> >>This raises two issues, an architectural one and a BCP one: >> >>To principally different scenarios are possible >> >>Scenario A >> >>ENUM is providing ONLY the mapping from the E.164 number to >>an AoR. (= name to address mapping) The above described >>routing between the networks to find the destination network >>is done via the AoR. How this is done is completely within >>the scope of SPEER. >> >>Note: this is the only future proof way, because a user may >>use the AoR in the first place and then the routing MUST work >>anyway. So any additional routing information in ENUM would >>be duplicated and therefore error-prone. >> >>I propose in addition to use in this case a SIP in the format >>sip:4319793321@provider.net, to clearly indicate that this >>has no relationship to an E.164 number. >> >>Scenario B: >> >>This is the scenario proposed in most current implementations >>and also in the RFI on ENUM popping up everywhere. The reason >>is that most scenarios currently concentrate solely on the >>peering with E.164 numbers and completely forget the peering >>with SIP URIs >> >>The ENUM entry is giving you the next hop: This is in case of >>the walled garden originating network either the server >>hosting the end-user or the egress border element (e.g. IBCF, >>THIG, or whatchamacallit). This element is again querying >>another kind of ENUM, getting back the ingress border element >>of the destination network (or even of a "transit" L5 >>network), and so on. The ingress border element is the again >>calling its private ENUM to finally find the hosting server. >> >>Note: I have a sub-question here: Some implementations are >>even proposing here to skip the SRV query and directly >>pointing to the SIP server(s) in ENUM. Does this make sense? >> >>If this scenario is used, I propose to use only SIP URIs in >>the format sip:+4319793321@provider.net;user=phone or better >>SIP:+4319793321@sbc.prov.net; user=phone >> >>to clearly indicate that this is still basically a >>tel: URI combined with a routing info and that it may be used >>in another ENUM query. >> >>My questions to the crowd are the following: >> >>1. is this proposed use of SIP URIs within the context of ENUM ok? >> >>2. What should be the preferred scenario for VoIP peering? >>Is some kind of combination between the scenarios feasible? >>And what are the arguments pro and con? >> >>I consider the outcome of this discussion as substantial >>input to the deliverables of SPEER, but some first guidance >>is urgently required now, because many entities are making >>basic decisions in this direction NOW. >> >>Please also excuse and correct incorrect use of terminology. >> >>Regards >>Richard Stastny >> >> >> >> >> >> >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol Use >>sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 06 13:11:14 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 1EjhHW-0007R7-Qv; Tue, 06 Dec 2005 13:11:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjhHO-0007FZ-1Z; Tue, 06 Dec 2005 13:11:11 -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 NAA02594; Tue, 6 Dec 2005 13:10:15 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejhcv-0003Y2-ME; Tue, 06 Dec 2005 13:33:22 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 06 Dec 2005 10:10:57 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,222,1131350400"; d="scan'208"; a="16694417:sNHT26910960" 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 jB6IAAV5002126; Tue, 6 Dec 2005 13:10:53 -0500 (EST) 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, 6 Dec 2005 13:10:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Dec 2005 13:10:43 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA042E@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] SIP AoR, tel and ENUM Thread-Index: AcX6hPf2sLmw0BxGQvS5LPQgRR8+DwAClYDg From: "Michael Hammer \(mhammer\)" To: "Klaus Darilion" , "Stastny Richard" X-OriginalArrivalTime: 06 Dec 2005 18:10:44.0665 (UTC) FILETIME=[603B2290:01C5FA90] X-Spam-Score: 1.1 (+) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu, sip@ietf.org Subject: [Enum] RE: [Sip] SIP AoR, tel and 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 Klaus, It has to do with the difference between re-targeting and routing. Is the point of interconnect the real target of the request or just a waypoint in the route to get to the target? In the User ENUM case, it seems as though the addresses are all about the target users and their devices. But, here it seemed a bit different. It is a route through an intermediate point. It seems like the semantic and syntactical element would be more coherent and no more complicated. Thus, I posed the question. Mike > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 > Sent: Tuesday, December 06, 2005 11:48 AM > To: Stastny Richard > Cc: Michael Hammer (mhammer); voipeer@lists.uoregon.edu;=20 > enum@ietf.org; sip@ietf.org > Subject: Re: [Sip] SIP AoR, tel and ENUM >=20 > Stastny Richard wrote: > > Mike wrote: > >=20 > >=20 > >>Before going down this path too far, can we ask where the=20 > results of=20 > >>the ENUM queries will go in the SIP message to control routing? > >>Hypothetically, the egress and ingress gateways could be=20 > identified in=20 > >>Route headers rather than in the Request-URI. An external ENUM dip=20 > >>and an internal ENUM dip might lead to something along the lines of: > >=20 > > =20 > > Correct, > > =20 > > Jonathan proposed this some time ago, but this thread somewhere=20 > > stranded > > =20 > > So basically an interneal ENUM entry of > >=20 > > sip:+1777555111@egress.provider3.com;user=3Dphone > > =20 > > would result in > >=20 > > INVITE tel:+17775551111 SIP/2.0 > > ... > > Route: > > =20 > > an the external ENUM entry would be > > sip:+1777555111@provider17.com > > =20 > > result in > > Route: > > =20 > > This is basically what I am after > > ... > >=20 >=20 > Hi folks. >=20 > What is the benefit of splitting the ENUM result (the SIP=20 > URI) into a Route header and into a request URI? >=20 > IMO there should be no semantic for the internal routing (the=20 > routing from the main proxy to the egress proxy). This should=20 > be out of scope of all WGs. Also the internal routing of the=20 > ingress provider should be out of scope. The ingress provider=20 > should have SIP URI which can be used to address its customers. >=20 > If this URI is sip:431505641636@in.mydomain.com or=20 > foobar666@in.mydomain.com, or sip:klaus.darilion@mydomain.com=20 > is the ingress provider's choice. Maybe the ingress provider=20 > also allows all of the previous SIP URIs to reach a certain=20 > user. The incoming provider just has to make sure that these=20 > SIP URIs map to the corresponding user (to the user's AoR).=20 > If this user also has an E.164 number which is in I-ENUM,=20 > then it's again the ingress provider's choice which URI to=20 > put into the NAPTR. >=20 > IMO there should not not be any semantics how to create a=20 > request URI and a pre-loaded route set of the SIP URI=20 > received from ENUM. The egress proxy sends the request to the=20 > ingress proxy in the format choosen by the ingress provider=20 > (e.g. publish via ENUM or an business cards). >=20 > We should not complicate things. I do not see any problems=20 > with this simple approach. If there are some problems, please=20 > correct me. >=20 > regards > klaus >=20 >=20 >=20 > >=20 > >>I am also suggesting that the ENUM result be an AoR, since=20 > one might=20 > >>want some reliability in choosing which server in the=20 > gateway cluster=20 > >>to go to based on further DNS queries, load balancing, etc. > >=20 > > =20 > > Now this is in contradiction to the above > > =20 > > Richard > >=20 > >=20 > >>Mike > >=20 > >=20 > >>-----Original Message----- > >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of=20 > >>Stastny Richard > >>Sent: Tuesday, December 06, 2005 4:54 AM > >>To: voipeer@lists.uoregon.edu > >>Cc: enum@ietf.org; sip@ietf.org > >>Subject: [Sip] SIP AoR, tel and ENUM > >> > >>Folks, > >> > >>This post is primarily to SPEER, but since it also concerns=20 > ENUM and=20 > >>SIP I cross-post it. > >> > >>I need (urgently) some guidance on the question what SIP=20 > URIs to use=20 > >>in Infrastructure ENUM. > >> > >>User ENUM as defined in RFC 3761 provides a mapping from > >>E.164 numbers to SIP URIs for primarily for end-users. So=20 > what you get=20 > >>back is the AoR pointing to the destination SIP server. > >> > >>If you get something back on the ENUM query such as=20 > >>sip:Richard@stastny.com, this is definetely an AoR. Because=20 > of privacy=20 > >>reasons, more and more people start using SIP URI such as=20 > >>sip:4319793321@provider.net or (an AoR)=20 > >>sip:+4319793321@provider.net;user=3Dphone (IMHO not an AoR) or even=20 > >>sip:+4319793321@provider.net > >> > >>IMHO the last one should not be used, and some guidance is=20 > also needed=20 > >>here. but it only concerns the destination server and if the=20 > >>destination servers can deal with it, fine. > >> > >>Now with Infrastructure ENUM (and especially in combination with=20 > >>private ENUMs) the situation is different. > >> > >>The purpose of Infrastructure ENUM is according to the re-chartered=20 > >>ENUM WG "to discover points of interconnection necessary to=20 > terminate=20 > >>communications sessions identified by a E164 number, in addition to=20 > >>identifying end point protocols and services." > >> > >>This translates to: Infrastructure ENUM does not=20 > necessarily contain=20 > >>end-point information (AoR), but routing information. > >>Routing, in my definition here, is basically to provide you=20 > with the=20 > >>information what the next hop is. > >> > >>A very common scenario is the following one: a walled=20 > garden network=20 > >>is using private ENUM to detect the border element for a=20 > given number,=20 > >>Some border element may lead to another private (extranet), using a=20 > >>federated ENUM for this number, another may be connected to the=20 > >>Internet using public Infrastructure ENUM for another number. > >>Public Infrastructure ENUM is giving back the ingress=20 > border element,=20 > >>which in turn uses private ENUM again to find the SIP=20 > server hosting=20 > >>the user with this number. > >> > >>In addition, again for privacy reasons, in most cases the above=20 > >>mentioned SIP URIs containing E.164 numbers are used. > >> > >>This raises two issues, an architectural one and a BCP one: > >> > >>To principally different scenarios are possible > >> > >>Scenario A > >> > >>ENUM is providing ONLY the mapping from the E.164 number to=20 > an AoR. (=3D=20 > >>name to address mapping) The above described routing between the=20 > >>networks to find the destination network is done via the=20 > AoR. How this=20 > >>is done is completely within the scope of SPEER. > >> > >>Note: this is the only future proof way, because a user may use the=20 > >>AoR in the first place and then the routing MUST work=20 > anyway. So any=20 > >>additional routing information in ENUM would be duplicated and=20 > >>therefore error-prone. > >> > >>I propose in addition to use in this case a SIP in the format=20 > >>sip:4319793321@provider.net, to clearly indicate that this has no=20 > >>relationship to an E.164 number. > >> > >>Scenario B: > >> > >>This is the scenario proposed in most current=20 > implementations and also=20 > >>in the RFI on ENUM popping up everywhere. The reason is that most=20 > >>scenarios currently concentrate solely on the peering with E.164=20 > >>numbers and completely forget the peering with SIP URIs > >> > >>The ENUM entry is giving you the next hop: This is in case of the=20 > >>walled garden originating network either the server hosting the=20 > >>end-user or the egress border element (e.g. IBCF, THIG, or=20 > >>whatchamacallit). This element is again querying another=20 > kind of ENUM,=20 > >>getting back the ingress border element of the destination=20 > network (or=20 > >>even of a "transit" L5 network), and so on. The ingress=20 > border element=20 > >>is the again calling its private ENUM to finally find the hosting=20 > >>server. > >> > >>Note: I have a sub-question here: Some implementations are even=20 > >>proposing here to skip the SRV query and directly pointing=20 > to the SIP=20 > >>server(s) in ENUM. Does this make sense? > >> > >>If this scenario is used, I propose to use only SIP URIs in=20 > the format=20 > >>sip:+4319793321@provider.net;user=3Dphone or better=20 > >>SIP:+4319793321@sbc.prov.net; user=3Dphone > >> > >>to clearly indicate that this is still basically a > >>tel: URI combined with a routing info and that it may be used in=20 > >>another ENUM query. > >> > >>My questions to the crowd are the following: > >> > >>1. is this proposed use of SIP URIs within the context of ENUM ok? > >> > >>2. What should be the preferred scenario for VoIP peering? > >>Is some kind of combination between the scenarios feasible? > >>And what are the arguments pro and con? > >> > >>I consider the outcome of this discussion as substantial=20 > input to the=20 > >>deliverables of SPEER, but some first guidance is urgently required=20 > >>now, because many entities are making basic decisions in this=20 > >>direction NOW. > >> > >>Please also excuse and correct incorrect use of terminology. > >> > >>Regards > >>Richard Stastny > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol Use=20 > >>sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>sipping@ietf.org for new developments on the application of sip > >> > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 > >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 06 13:24:26 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 1EjhUI-0004yc-1q; Tue, 06 Dec 2005 13:24:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjhUF-0004v1-GS; Tue, 06 Dec 2005 13:24:23 -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 NAA04578; Tue, 6 Dec 2005 13:23:31 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejhpl-00047h-CM; Tue, 06 Dec 2005 13:46:38 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 06 Dec 2005 13:24:12 -0500 X-IronPort-AV: i="3.99,222,1131339600"; d="scan'208"; a="77229485:sNHT35272500" 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 jB6IO64Z003451; Tue, 6 Dec 2005 13:24:10 -0500 (EST) 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, 6 Dec 2005 13:24:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Dec 2005 13:24:08 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA043B@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] SIP AoR, tel and ENUM Thread-Index: AcX6SwJitdWYiDMnQBa1ILCKsfjKoAAK+G+QAAEpMrUABUXZ0A== From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , X-OriginalArrivalTime: 06 Dec 2005 18:24:09.0561 (UTC) FILETIME=[3FFC8490:01C5FA92] X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, sip@ietf.org Subject: [Enum] RE: [Sip] SIP AoR, tel and 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 Hmmm... should I have said?: Route: Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Tuesday, December 06, 2005 10:47 AM > To: Michael Hammer (mhammer); voipeer@lists.uoregon.edu > Cc: enum@ietf.org; sip@ietf.org > Subject: Re: [Sip] SIP AoR, tel and ENUM >=20 > Mike wrote: >=20 > >Before going down this path too far, can we ask where the results of=20 > >the ENUM queries will go in the SIP message to control routing? > >Hypothetically, the egress and ingress gateways could be=20 > identified in=20 > >Route headers rather than in the Request-URI. An external=20 > ENUM dip and=20 > >an internal ENUM dip might lead to something along the lines of: > =20 > Correct, > =20 > Jonathan proposed this some time ago, but this thread=20 > somewhere stranded > =20 > So basically an interneal ENUM entry of >=20 > sip:+1777555111@egress.provider3.com;user=3Dphone > =20 > would result in >=20 > INVITE tel:+17775551111 SIP/2.0 > ... > Route: > =20 > an the external ENUM entry would be > sip:+1777555111@provider17.com > =20 > result in > Route: > =20 > This is basically what I am after > ... >=20 > >I am also suggesting that the ENUM result be an AoR, since one might=20 > >want some reliability in choosing which server in the=20 > gateway cluster=20 > >to go to based on further DNS queries, load balancing, etc. > =20 > Now this is in contradiction to the above > =20 > Richard >=20 > >Mike >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of=20 > > Stastny Richard > > Sent: Tuesday, December 06, 2005 4:54 AM > > To: voipeer@lists.uoregon.edu > > Cc: enum@ietf.org; sip@ietf.org > > Subject: [Sip] SIP AoR, tel and ENUM > > > > Folks, > > > > This post is primarily to SPEER, but since it also concerns=20 > ENUM and=20 > > SIP I cross-post it. > > > > I need (urgently) some guidance on the question what SIP=20 > URIs to use=20 > > in Infrastructure ENUM. > > > > User ENUM as defined in RFC 3761 provides a mapping from > > E.164 numbers to SIP URIs for primarily for end-users. So=20 > what you get=20 > > back is the AoR pointing to the destination SIP server. > > > > If you get something back on the ENUM query such as=20 > > sip:Richard@stastny.com, this is definetely an AoR. Because=20 > of privacy=20 > > reasons, more and more people start using SIP URI such as=20 > > sip:4319793321@provider.net or (an AoR)=20 > > sip:+4319793321@provider.net;user=3Dphone (IMHO not an AoR) or even=20 > > sip:+4319793321@provider.net > > > > IMHO the last one should not be used, and some guidance is=20 > also needed=20 > > here. but it only concerns the destination server and if the=20 > > destination servers can deal with it, fine. > > > > Now with Infrastructure ENUM (and especially in combination with=20 > > private ENUMs) the situation is different. > > > > The purpose of Infrastructure ENUM is according to the re-chartered=20 > > ENUM WG "to discover points of interconnection necessary to=20 > terminate=20 > > communications sessions identified by a E164 number, in addition to=20 > > identifying end point protocols and services." > > > > This translates to: Infrastructure ENUM does not=20 > necessarily contain=20 > > end-point information (AoR), but routing information. > > Routing, in my definition here, is basically to provide you=20 > with the=20 > > information what the next hop is. > > > > A very common scenario is the following one: a walled=20 > garden network=20 > > is using private ENUM to detect the border element for a=20 > given number,=20 > > Some border element may lead to another private (extranet), using a=20 > > federated ENUM for this number, another may be connected to the=20 > > Internet using public Infrastructure ENUM for another number. > > Public Infrastructure ENUM is giving back the ingress=20 > border element,=20 > > which in turn uses private ENUM again to find the SIP=20 > server hosting=20 > > the user with this number. > > > > In addition, again for privacy reasons, in most cases the above=20 > > mentioned SIP URIs containing E.164 numbers are used. > > > > This raises two issues, an architectural one and a BCP one: > > > > To principally different scenarios are possible > > > > Scenario A > > > > ENUM is providing ONLY the mapping from the E.164 number to=20 > an AoR. (=3D=20 > > name to address mapping) The above described routing between the=20 > > networks to find the destination network is done via the=20 > AoR. How this=20 > > is done is completely within the scope of SPEER. > > > > Note: this is the only future proof way, because a user may use the=20 > > AoR in the first place and then the routing MUST work=20 > anyway. So any=20 > > additional routing information in ENUM would be duplicated and=20 > > therefore error-prone. > > > > I propose in addition to use in this case a SIP in the format=20 > > sip:4319793321@provider.net, to clearly indicate that this has no=20 > > relationship to an E.164 number. > > > > Scenario B: > > > > This is the scenario proposed in most current=20 > implementations and also=20 > > in the RFI on ENUM popping up everywhere. The reason is that most=20 > > scenarios currently concentrate solely on the peering with E.164=20 > > numbers and completely forget the peering with SIP URIs > > > > The ENUM entry is giving you the next hop: This is in case of the=20 > > walled garden originating network either the server hosting the=20 > > end-user or the egress border element (e.g. IBCF, THIG, or=20 > > whatchamacallit). This element is again querying another=20 > kind of ENUM,=20 > > getting back the ingress border element of the destination=20 > network (or=20 > > even of a "transit" L5 network), and so on. The ingress=20 > border element=20 > > is the again calling its private ENUM to finally find the hosting=20 > > server. > > > > Note: I have a sub-question here: Some implementations are even=20 > > proposing here to skip the SRV query and directly pointing=20 > to the SIP=20 > > server(s) in ENUM. Does this make sense? > > > > If this scenario is used, I propose to use only SIP URIs in=20 > the format=20 > > sip:+4319793321@provider.net;user=3Dphone or better=20 > > SIP:+4319793321@sbc.prov.net; user=3Dphone > > > > to clearly indicate that this is still basically a > > tel: URI combined with a routing info and that it may be used in=20 > > another ENUM query. > > > > My questions to the crowd are the following: > > > > 1. is this proposed use of SIP URIs within the context of ENUM ok? > > > > 2. What should be the preferred scenario for VoIP peering? > > Is some kind of combination between the scenarios feasible? > > And what are the arguments pro and con? > > > > I consider the outcome of this discussion as substantial=20 > input to the=20 > > deliverables of SPEER, but some first guidance is urgently required=20 > > now, because many entities are making basic decisions in this=20 > > direction NOW. > > > > Please also excuse and correct incorrect use of terminology. > > > > Regards > > Richard Stastny > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > > >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 06 14:02:47 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 1Eji5P-0003lD-Im; Tue, 06 Dec 2005 14:02:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eji5N-0003kw-Vz; Tue, 06 Dec 2005 14:02: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 OAA09074; Tue, 6 Dec 2005 14:01:54 -0500 (EST) Received: from erdbert.netzquadrat.de ([217.10.64.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjiQu-0005Yv-M1; Tue, 06 Dec 2005 14:25:02 -0500 Received: from [217.10.64.186] (helo=workstation-186.netzquadrat.de ident=salmon) by erdbert.netzquadrat.de with esmtp (Exim 3.12 #1 (Debian)) id 1Eji53-00056v-00; Tue, 06 Dec 2005 20:02:25 +0100 Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM From: Thilo Salmon To: Klaus Darilion In-Reply-To: <4395C0DA.4040206@pernau.at> References: <32755D354E6B65498C3BD9FD496C7D462C46F4@oefeg-s04.oefeg.loc> <4395C0DA.4040206@pernau.at> Content-Type: text/plain Date: Tue, 06 Dec 2005 20:05:35 +0100 Message-Id: <1133895935.21571.170.camel@gw12> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , enum@ietf.org, "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 Richard, Klaus, et al. Apparently, I have missed an important developlement lately. > What is the benefit of splitting the ENUM result (the SIP URI) into a > Route header and into a request URI? [...] > IMO there should be no semantic for the internal routing (the routing > from the main proxy to the egress proxy). This should be out of scope of > all WGs. Also the internal routing of the ingress provider should be out > of scope. The ingress provider should have SIP URI which can be used to > address its customers. I absolutely second that statement. If for any reason (we all have enough a vivid enough phantasy to imagine a good reason, I suppose) an ingress provider wishes to feed a different set of SIP URIs to each and every of his egress partners, he should not be stripped of this option. The scenario I have in mind is one in which an ingress provider chooses to encrypt the user part of all his SIP URIs with a key uniquely assigns to his egress partner. Just as Klaus I feel this complicates things and takes authority over internal adressing away from the ingress provider for no reason apparent (to me). Thilo _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 06 16:36:58 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 1EjkUc-0000Sl-0P; Tue, 06 Dec 2005 16:36:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjkUa-0000Rh-Kl; Tue, 06 Dec 2005 16:36:56 -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 QAA25366; Tue, 6 Dec 2005 16:36:04 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejkq9-0002TX-6y; Tue, 06 Dec 2005 16:59:14 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 06 Dec 2005 13:36:47 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB6LZTAE026366; Tue, 6 Dec 2005 13:36:30 -0800 (PST) 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, 6 Dec 2005 16:36:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Tue, 6 Dec 2005 16:36:14 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA0533@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] Re: [Sip] SIP AoR, tel and ENUM Thread-Index: AcX6l7ng7d5gWyzJReGGP+c21C99TwAEhbpA From: "Michael Hammer \(mhammer\)" To: "Thilo Salmon" , "Klaus Darilion" X-OriginalArrivalTime: 06 Dec 2005 21:36:17.0617 (UTC) FILETIME=[173E4410:01C5FAAD] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 am having trouble parsing these statements. A provider is a provider. I used the terms ingress and egress to indicate some server that sits on the edge of a provider's network and does peering to some other provider. The usage below seems to mix egress with originating being the network where the caller is attached. I was noting that the called party terminal and the interconnect points were different hosts and therefore may have different identities. To keep maximum flexibility, the format of those identities would need to be fully under the control of the domain of each provider. However, conflating all that into a single URI in the Request-URI seemed constraining to me. Having three URIs in separate headers seemed the most flexible. Splitting. I don't understand what got split or how. ENUM -- Tel:URI in, Point-of-interconnect URI out. Put in Route header. I only suggested that there might be two route headers because the terminating provider would indicate in ENUM, to get to this end-user, go to this entrance first. But, to get to that entrance, the originating provider needs to determine what the corresponding exit point is from his network, i.e. another Route header. The format and content of that URI is up to each provider. The advertised entrance point is I think by definition the (Inter-) Carrier ENUM. The internal determination of the exit point could be termed (Intra-) Carrier ENUM. Maybe peering is concerned only with the inter-carrier aspect. The Request-URI could be a normalized public identity of the user totally independent of interconnect naming schemes. I was just teasing out what are the assumptions and constraints in the original email. Mike > -----Original Message----- > From: Thilo Salmon [mailto:salmon@sipgate.de]=20 > Sent: Tuesday, December 06, 2005 2:06 PM > To: Klaus Darilion > Cc: Michael Hammer (mhammer); sip@ietf.org;=20 > voipeer@lists.uoregon.edu; enum@ietf.org; Stastny Richard > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM >=20 > Richard, Klaus, et al. >=20 > Apparently, I have missed an important developlement lately.=20 >=20 > > What is the benefit of splitting the ENUM result (the SIP=20 > URI) into a=20 > > Route header and into a request URI? > [...] > > IMO there should be no semantic for the internal routing=20 > (the routing=20 > > from the main proxy to the egress proxy). This should be=20 > out of scope=20 > > of all WGs. Also the internal routing of the ingress=20 > provider should=20 > > be out of scope. The ingress provider should have SIP URI=20 > which can be=20 > > used to address its customers. >=20 > I absolutely second that statement. If for any reason (we all=20 > have enough a vivid enough phantasy to imagine a good reason,=20 > I suppose) an ingress provider wishes to feed a different set=20 > of SIP URIs to each and every of his egress partners, he=20 > should not be stripped of this option. > The scenario I have in mind is one in which an ingress=20 > provider chooses to encrypt the user part of all his SIP URIs=20 > with a key uniquely assigns to his egress partner. >=20 > Just as Klaus I feel this complicates things and takes=20 > authority over internal adressing away from the ingress=20 > provider for no reason apparent (to me). >=20 > Thilo >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 06 18:24:09 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 1EjmAL-0005Ul-DV; Tue, 06 Dec 2005 18:24:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjmAJ-0005TM-8C; Tue, 06 Dec 2005 18:24:07 -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 SAA06277; Tue, 6 Dec 2005 18:23:16 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjmVt-0005zM-JA; Tue, 06 Dec 2005 18:46:26 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 06 Dec 2005 15:23:58 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jB6NN7N6014376; Tue, 6 Dec 2005 15:23:51 -0800 (PST) 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, 6 Dec 2005 18:23:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Tue, 6 Dec 2005 18:23:47 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA058E@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Thread-Index: AcX6l7ng7d5gWyzJReGGP+c21C99TwAEhbpAAAJAsEAAAi0/IA== From: "Michael Hammer \(mhammer\)" To: , "Thilo Salmon" , "Klaus Darilion" X-OriginalArrivalTime: 06 Dec 2005 23:23:48.0210 (UTC) FILETIME=[1C18A520:01C5FABC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 My looking glass is smudged today. What does one call a provider of service? =20 I don't understand the aversion to service provider.=20 I thought it was only the "carrier" word that invoked regulatory burdens (or PATS!). I'd rather leave legal word games to lawyers and lobbyists. Mike > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com]=20 > Sent: Tuesday, December 06, 2005 5:30 PM > To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion' > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20 > 'Stastny Richard' > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM >=20 > Sorry for nitpicking: >=20 > >A provider is a provider. >=20 > A provider is a business model and att/SBC may differ from=20 > Google who uses a different business model (which is more=20 > significant measured in $$$?). >=20 > Didn't we agree to use the term "Internet domain owner" (we=20 > could shorten to IDOM or such)?=20 >=20 > Internet domains are well defined in the IETF.=20 > Business models for VoIP are better suited for other=20 > organizations, consortia or innovators who work to disrupt them :-) >=20 > Thanks, Henry >=20 > -----Original Message----- > From: owner-voipeer@lists.uoregon.edu > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Hammer > (mhammer) > Sent: Tuesday, December 06, 2005 3:36 PM > To: Thilo Salmon; Klaus Darilion > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20 > Stastny Richard > Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM >=20 > I am having trouble parsing these statements. >=20 > A provider is a provider. I used the terms ingress and=20 > egress to indicate some server that sits on the edge of a=20 > provider's network and does peering to some other provider. =20 > The usage below seems to mix egress with originating being=20 > the network where the caller is attached. >=20 > I was noting that the called party terminal and the=20 > interconnect points were different hosts and therefore may=20 > have different identities. To keep maximum flexibility, the=20 > format of those identities would need to be fully under the=20 > control of the domain of each provider. However, conflating=20 > all that into a single URI in the Request-URI seemed=20 > constraining to me. Having three URIs in separate headers=20 > seemed the most flexible. >=20 > Splitting. I don't understand what got split or how. ENUM=20 > -- Tel:URI in, Point-of-interconnect URI out. Put in Route=20 > header. I only suggested that there might be two route=20 > headers because the terminating provider would indicate in=20 > ENUM, to get to this end-user, go to this entrance first. =20 > But, to get to that entrance, the originating provider needs=20 > to determine what the corresponding exit point is from his=20 > network, i.e. another Route header. The format and content=20 > of that URI is up to each provider. The advertised entrance=20 > point is I think by definition the (Inter-) Carrier ENUM. =20 > The internal determination of the exit point could be termed=20 > (Intra-) Carrier ENUM. Maybe peering is concerned only with=20 > the inter-carrier aspect. >=20 > The Request-URI could be a normalized public identity of the=20 > user totally independent of interconnect naming schemes. I=20 > was just teasing out what are the assumptions and constraints=20 > in the original email. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Thilo Salmon [mailto:salmon@sipgate.de] > > Sent: Tuesday, December 06, 2005 2:06 PM > > To: Klaus Darilion > > Cc: Michael Hammer (mhammer); sip@ietf.org;=20 > voipeer@lists.uoregon.edu;=20 > > enum@ietf.org; Stastny Richard > > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM > >=20 > > Richard, Klaus, et al. > >=20 > > Apparently, I have missed an important developlement lately.=20 > >=20 > > > What is the benefit of splitting the ENUM result (the SIP > > URI) into a > > > Route header and into a request URI? > > [...] > > > IMO there should be no semantic for the internal routing > > (the routing > > > from the main proxy to the egress proxy). This should be > > out of scope > > > of all WGs. Also the internal routing of the ingress > > provider should > > > be out of scope. The ingress provider should have SIP URI > > which can be > > > used to address its customers. > >=20 > > I absolutely second that statement. If for any reason (we all have=20 > > enough a vivid enough phantasy to imagine a good reason, I=20 > suppose) an=20 > > ingress provider wishes to feed a different set of SIP URIs to each=20 > > and every of his egress partners, he should not be stripped of this=20 > > option. > > The scenario I have in mind is one in which an ingress provider=20 > > chooses to encrypt the user part of all his SIP URIs with a key=20 > > uniquely assigns to his egress partner. > >=20 > > Just as Klaus I feel this complicates things and takes=20 > authority over=20 > > internal adressing away from the ingress provider for no reason=20 > > apparent (to me). > >=20 > > Thilo > >=20 >=20 > ______________________________________________________________ > ______________ > _ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 07 03:34:04 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 1EjukW-0003Xq-Ku; Wed, 07 Dec 2005 03:34:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjukU-0003XN-Rm; Wed, 07 Dec 2005 03:34:03 -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 DAA01511; Wed, 7 Dec 2005 03:33:10 -0500 (EST) Received: from nat.labs.nic.at ([83.136.33.3] helo=whistler) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejv69-0006GQ-An; Wed, 07 Dec 2005 03:56:26 -0500 Received: from klauspc.intern ([10.10.0.50]) by whistler with esmtp (Exim 3.36 #1 (Debian)) id 1Ejujs-0003YJ-00; Wed, 07 Dec 2005 09:33:24 +0100 Message-ID: <43969E3E.4060207@pernau.at> Date: Wed, 07 Dec 2005 09:33:02 +0100 From: Klaus Darilion User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" References: <072C5B76F7CEAB488172C6F64B30B5E3DA042E@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3DA042E@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 58b614506802734014829a093beb6879 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , sip@ietf.org Subject: [Enum] Re: [Sip] SIP AoR, tel and ENUM X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Michael! As there are some concerns about the terminology. Thus I will use AD (adminsitrative domain, from the SPEERMINT charter) as synonym for ITSP, carrier, telco, VoIP enabled enterprise ..... Michael Hammer (mhammer) wrote: > Klaus, > > It has to do with the difference between re-targeting and routing. Is > the point of interconnect the real target of the request or just a > waypoint in the route to get to the target? In the User ENUM case, it > seems as though the addresses are all about the target users and their > devices. But, here it seemed a bit different. It is a route through an > intermediate point. It seems like the semantic and syntactical element > would be more coherent and no more complicated. Thus, I posed the > question. I can not really see a difference to user ENUM. There is only one Infrastructure ENUM tree. Thus, all ADs which query this tree will get the same URI back from ENUM. Thus, the ingress point announced by the receiving AD is the same for all outgoing ADs. Further, if the outgoing AD does not send the request directly to the announced ingress point (maybe no peering relationship), but to an intermediate point (transit provider, clearinghouse, ....), this routing is different for each AD. Thus, such kind of routing information can not be in ENUM. Once the request reaches the ingress point of the receiving AD, there will be further routing inside the receiving AD. Maybe the route is for example: 1. ingresspoint1.ad 2. accountingbox.ad 3. mainproxy.ad 4. ..... Publishing such a route in ENUM makes no sense, as the route is the same for all incoming requests. Thus, the route should be applied by the previous hop. That means, ingresspoint1.ad knows that it should formward to accountingbox.ad, and so on. IMO, ENUM is a simple routing and re-targeting in one step. If complex re-routing and re-targeting is required it should be done by the receiving AD. The outoing AD is not interested in the internal routing of the receiving AD. Maybe you can give me an example of a scenario were my model does not fit. regards klaus > > Mike > > > >>-----Original Message----- >>From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >>Sent: Tuesday, December 06, 2005 11:48 AM >>To: Stastny Richard >>Cc: Michael Hammer (mhammer); voipeer@lists.uoregon.edu; >>enum@ietf.org; sip@ietf.org >>Subject: Re: [Sip] SIP AoR, tel and ENUM >> >>Stastny Richard wrote: >> >>>Mike wrote: >>> >>> >>> >>>>Before going down this path too far, can we ask where the >> >>results of >> >>>>the ENUM queries will go in the SIP message to control routing? >>>>Hypothetically, the egress and ingress gateways could be >> >>identified in >> >>>>Route headers rather than in the Request-URI. An external ENUM dip >>>>and an internal ENUM dip might lead to something along the lines of: >>> >>> >>>Correct, >>> >>>Jonathan proposed this some time ago, but this thread somewhere >>>stranded >>> >>>So basically an interneal ENUM entry of >>> >>>sip:+1777555111@egress.provider3.com;user=phone >>> >>>would result in >>> >>>INVITE tel:+17775551111 SIP/2.0 >>>... >>>Route: >>> >>>an the external ENUM entry would be >>>sip:+1777555111@provider17.com >>> >>>result in >>>Route: >>> >>>This is basically what I am after >>>... >>> >> >>Hi folks. >> >>What is the benefit of splitting the ENUM result (the SIP >>URI) into a Route header and into a request URI? >> >>IMO there should be no semantic for the internal routing (the >>routing from the main proxy to the egress proxy). This should >>be out of scope of all WGs. Also the internal routing of the >>ingress provider should be out of scope. The ingress provider >>should have SIP URI which can be used to address its customers. >> >>If this URI is sip:431505641636@in.mydomain.com or >>foobar666@in.mydomain.com, or sip:klaus.darilion@mydomain.com >>is the ingress provider's choice. Maybe the ingress provider >>also allows all of the previous SIP URIs to reach a certain >>user. The incoming provider just has to make sure that these >>SIP URIs map to the corresponding user (to the user's AoR). >>If this user also has an E.164 number which is in I-ENUM, >>then it's again the ingress provider's choice which URI to >>put into the NAPTR. >> >>IMO there should not not be any semantics how to create a >>request URI and a pre-loaded route set of the SIP URI >>received from ENUM. The egress proxy sends the request to the >>ingress proxy in the format choosen by the ingress provider >>(e.g. publish via ENUM or an business cards). >> >>We should not complicate things. I do not see any problems >>with this simple approach. If there are some problems, please >>correct me. >> >>regards >>klaus >> >> >> >> >>>>I am also suggesting that the ENUM result be an AoR, since >> >>one might >> >>>>want some reliability in choosing which server in the >> >>gateway cluster >> >>>>to go to based on further DNS queries, load balancing, etc. >>> >>> >>>Now this is in contradiction to the above >>> >>>Richard >>> >>> >>> >>>>Mike >>> >>> >>>>-----Original Message----- >>>>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> >>Behalf Of >> >>>>Stastny Richard >>>>Sent: Tuesday, December 06, 2005 4:54 AM >>>>To: voipeer@lists.uoregon.edu >>>>Cc: enum@ietf.org; sip@ietf.org >>>>Subject: [Sip] SIP AoR, tel and ENUM >>>> >>>>Folks, >>>> >>>>This post is primarily to SPEER, but since it also concerns >> >>ENUM and >> >>>>SIP I cross-post it. >>>> >>>>I need (urgently) some guidance on the question what SIP >> >>URIs to use >> >>>>in Infrastructure ENUM. >>>> >>>>User ENUM as defined in RFC 3761 provides a mapping from >>>>E.164 numbers to SIP URIs for primarily for end-users. So >> >>what you get >> >>>>back is the AoR pointing to the destination SIP server. >>>> >>>>If you get something back on the ENUM query such as >>>>sip:Richard@stastny.com, this is definetely an AoR. Because >> >>of privacy >> >>>>reasons, more and more people start using SIP URI such as >>>>sip:4319793321@provider.net or (an AoR) >>>>sip:+4319793321@provider.net;user=phone (IMHO not an AoR) or even >>>>sip:+4319793321@provider.net >>>> >>>>IMHO the last one should not be used, and some guidance is >> >>also needed >> >>>>here. but it only concerns the destination server and if the >>>>destination servers can deal with it, fine. >>>> >>>>Now with Infrastructure ENUM (and especially in combination with >>>>private ENUMs) the situation is different. >>>> >>>>The purpose of Infrastructure ENUM is according to the re-chartered >>>>ENUM WG "to discover points of interconnection necessary to >> >>terminate >> >>>>communications sessions identified by a E164 number, in addition to >>>>identifying end point protocols and services." >>>> >>>>This translates to: Infrastructure ENUM does not >> >>necessarily contain >> >>>>end-point information (AoR), but routing information. >>>>Routing, in my definition here, is basically to provide you >> >>with the >> >>>>information what the next hop is. >>>> >>>>A very common scenario is the following one: a walled >> >>garden network >> >>>>is using private ENUM to detect the border element for a >> >>given number, >> >>>>Some border element may lead to another private (extranet), using a >>>>federated ENUM for this number, another may be connected to the >>>>Internet using public Infrastructure ENUM for another number. >>>>Public Infrastructure ENUM is giving back the ingress >> >>border element, >> >>>>which in turn uses private ENUM again to find the SIP >> >>server hosting >> >>>>the user with this number. >>>> >>>>In addition, again for privacy reasons, in most cases the above >>>>mentioned SIP URIs containing E.164 numbers are used. >>>> >>>>This raises two issues, an architectural one and a BCP one: >>>> >>>>To principally different scenarios are possible >>>> >>>>Scenario A >>>> >>>>ENUM is providing ONLY the mapping from the E.164 number to >> >>an AoR. (= >> >>>>name to address mapping) The above described routing between the >>>>networks to find the destination network is done via the >> >>AoR. How this >> >>>>is done is completely within the scope of SPEER. >>>> >>>>Note: this is the only future proof way, because a user may use the >>>>AoR in the first place and then the routing MUST work >> >>anyway. So any >> >>>>additional routing information in ENUM would be duplicated and >>>>therefore error-prone. >>>> >>>>I propose in addition to use in this case a SIP in the format >>>>sip:4319793321@provider.net, to clearly indicate that this has no >>>>relationship to an E.164 number. >>>> >>>>Scenario B: >>>> >>>>This is the scenario proposed in most current >> >>implementations and also >> >>>>in the RFI on ENUM popping up everywhere. The reason is that most >>>>scenarios currently concentrate solely on the peering with E.164 >>>>numbers and completely forget the peering with SIP URIs >>>> >>>>The ENUM entry is giving you the next hop: This is in case of the >>>>walled garden originating network either the server hosting the >>>>end-user or the egress border element (e.g. IBCF, THIG, or >>>>whatchamacallit). This element is again querying another >> >>kind of ENUM, >> >>>>getting back the ingress border element of the destination >> >>network (or >> >>>>even of a "transit" L5 network), and so on. The ingress >> >>border element >> >>>>is the again calling its private ENUM to finally find the hosting >>>>server. >>>> >>>>Note: I have a sub-question here: Some implementations are even >>>>proposing here to skip the SRV query and directly pointing >> >>to the SIP >> >>>>server(s) in ENUM. Does this make sense? >>>> >>>>If this scenario is used, I propose to use only SIP URIs in >> >>the format >> >>>>sip:+4319793321@provider.net;user=phone or better >>>>SIP:+4319793321@sbc.prov.net; user=phone >>>> >>>>to clearly indicate that this is still basically a >>>>tel: URI combined with a routing info and that it may be used in >>>>another ENUM query. >>>> >>>>My questions to the crowd are the following: >>>> >>>>1. is this proposed use of SIP URIs within the context of ENUM ok? >>>> >>>>2. What should be the preferred scenario for VoIP peering? >>>>Is some kind of combination between the scenarios feasible? >>>>And what are the arguments pro and con? >>>> >>>>I consider the outcome of this discussion as substantial >> >>input to the >> >>>>deliverables of SPEER, but some first guidance is urgently required >>>>now, because many entities are making basic decisions in this >>>>direction NOW. >>>> >>>>Please also excuse and correct incorrect use of terminology. >>>> >>>>Regards >>>>Richard Stastny >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol Use >>>>sip-implementors@cs.columbia.edu for questions on current sip Use >>>>sipping@ietf.org for new developments on the application of sip >>>> >>> >>> >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol Use >>>sip-implementors@cs.columbia.edu for questions on current sip Use >>>sipping@ietf.org for new developments on the application of sip >>> >>> >> > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 07 06:58:07 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 1Ejxvz-0007ad-Gx; Wed, 07 Dec 2005 06:58:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejxvv-0007ZF-NN; Wed, 07 Dec 2005 06:58:03 -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 GAA24781; Wed, 7 Dec 2005 06:57:12 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EjyHb-00052g-Bv; Wed, 07 Dec 2005 07:20:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Dec 2005 13:01:28 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B228B@oefeg-s04.oefeg.loc> Thread-Topic: SIP AoR, tel and ENUM - Second Try Thread-Index: AcX6l7ng7d5gWyzJReGGP+c21C99TwAEhbpAAAJAsEAAGzinsA== From: "Stastny Richard" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Enum] SIP AoR, tel and ENUM - Second Try X-BeenThere: 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, thanks for the statements sofar, but I am still confused (maybe even more ;-) It seems also that my first post was not too well formulated The basic question was: Should Infrastructure ENUM contain a routing information to the next hop only (the ingress border element of Provider B (or administrative domain B)=20 or simply a mapping from an E.164 number to an AoR? I will try to give another example and start from within the scope of SPEERMINT (I hope this is the last iteration before the name gets too lomg ;-) I subscribe with provider B and get a default public user identity (AoR) from this provider: e.g. sip:foo@provB.net This "foo" can be anything the provider chooses it to be: e.g. an alphanumeric string such as ywzabcd, a numeric string such as 16241 (my FWD number) or 019793321 or 4319793321 Any other provider A having a peering agreement with Provider B must be able to route a SIP call given this SIP AoR to provider B, either to the SIP proxy hosting this account or at least to the ingress proxy(s) in provider B network. On way to do so is to use SRV records within the zone of provB.net pointing to e.g ingress14.provB.net and ingress21.provB.net Question: is this correct? Note: after the ingress proxy provider B may use another mapping mechanism to find the real hosting server e.g. srv21.provB.net Now I as a user are not happy with this default public user identity, I want to have some aliases eg:=20 1)sip:richard@stastny.com and 2) +43 1 9793321 In case 1) I assume that provider B needs to provide me with redirect server(s), and I need to enter in stastny.com SRV records to point to these redirect servers e.g. redirect.provB.net sip:richard.stastny.com is redirected to sip:foo@provB.net Question: is this correct? In case 2) we need Infrastructure ENUM [Side note; in my user ENUM I would either enter sip:richard@stastny.com or sip:foo@provB.net this is my choice] Now the question is: what goes into Infrastructure ENUM for say +4319793321? Is it: Sip:foo@provB.net (if plain sip:foo@provB.net works this must also work) OR sip:+4319793321@provB.net;user=3Dphone (correct?) OR sip:+4319793321@provB.net (wrong?) OR sip:4319793321@provB.net (valid only if 4319793321 =3D foo) OR is it sip:+4319793321@ingress14.provB.net;user=3Dphone (and the above = variants) AND sip:+4319793321@ingress21.provB.net;user=3Dphone In this last case one would not need to query the SRV records in provB.net I hope I did not confuse the issue even more Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 07 07:40:30 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 1Ejyb0-0000FI-C7; Wed, 07 Dec 2005 07:40:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejyax-0000EB-HQ; Wed, 07 Dec 2005 07:40:27 -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 HAA29126; Wed, 7 Dec 2005 07:39:36 -0500 (EST) Received: from nat.labs.nic.at ([83.136.33.3] helo=whistler) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejywe-0006co-RM; Wed, 07 Dec 2005 08:02:53 -0500 Received: from klauspc.intern ([10.10.0.50]) by whistler with esmtp (Exim 3.36 #1 (Debian)) id 1Ejyac-0003c6-00; Wed, 07 Dec 2005 13:40:06 +0100 Message-ID: <4396D807.8000406@pernau.at> Date: Wed, 07 Dec 2005 13:39:35 +0100 From: Klaus Darilion User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] SIP AoR, tel and ENUM - Second Try References: <32755D354E6B65498C3BD9FD496C7D461B228B@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B228B@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 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 Richard! comments inline Stastny Richard wrote: > Should Infrastructure ENUM contain a routing information > to the next hop only (the ingress border element of Provider B > (or administrative domain B) > or simply a mapping from an E.164 number to an AoR? IMHO it should be a mapping to an AoR as in user ENUM. > I will try to give another example and start from ... > I subscribe with provider B and get a default public > user identity (AoR) from this provider: > e.g. sip:foo@provB.net > > This "foo" can be anything the provider chooses it to be: > e.g. an alphanumeric string such as ywzabcd, > a numeric string such as 16241 (my FWD number) > or 019793321 or 4319793321 > > Any other provider A having a peering agreement > with Provider B must be able to route a SIP call > given this SIP AoR to provider B, either to the > SIP proxy hosting this account or at least to > the ingress proxy(s) in provider B network. > > On way to do so is to use SRV records within > the zone of provB.net pointing to e.g > > ingress14.provB.net > and > ingress21.provB.net > > Question: is this correct? IMO yes. Thus, A sends "INVITE sip:foo@provB.net" to ingress14.provB.net > Note: after the ingress proxy provider B > may use another mapping mechanism to find > the real hosting server e.g. srv21.provB.net > > Now I as a user are not happy with this default > public user identity, I want to have some aliases > > eg: > 1)sip:richard@stastny.com and > 2) +43 1 9793321 > > In case 1) I assume that provider B needs > to provide me with redirect server(s), and I > need to enter in stastny.com SRV records > to point to these redirect servers > e.g. redirect.provB.net > > sip:richard.stastny.com is redirected to > sip:foo@provB.net > > Question: is this correct? This is a working scenario. But a redirect server is not mandatory. It may also be a proxy which forwards the request "INVITE sip:richard.stastny.com" to "INVITE sip:foo@provB.net". It is also possbile that SRV for stastny.com points directly to ingress12.provB.net and ingress12 knows about all hosted SIP domains and knows how to forward the request to the end user. But this is a design decision of the provB and IMO should be out of scope of SPEERMINT. provB may use redirect server, provC may accept all hosted SIP domains directly on their ingress points, ..... I personally prefer relaying instead of redirect. E.g. redirect raises questions like: How should intercept the redirect response and forward to the new URI? The UA client or the SIP proxy of provA or the egress proxy? The important thing is that the originator (provA) should not have to take care how provB implemented the hosting of SIP domains. > In case 2) we need Infrastructure ENUM > [Side note; in my user ENUM I would either enter > sip:richard@stastny.com or sip:foo@provB.net > this is my choice] > > Now the question is: what goes into Infrastructure > ENUM for say +4319793321? > > Is it: > Sip:foo@provB.net (if plain sip:foo@provB.net works > this must also work) > OR > sip:+4319793321@provB.net;user=phone (correct?) > OR > sip:+4319793321@provB.net (wrong?) > OR > sip:4319793321@provB.net (valid only if 4319793321 = foo) > > OR is it > sip:+4319793321@ingress14.provB.net;user=phone (and the above variants) > AND > sip:+4319793321@ingress21.provB.net;user=phone IMO all of these are valid. It's up to the choice of provB. provB can put anything into ENUM as long as provB is able to map from the URI in I-ENUM to the end user. If I would design the network for provB, I would use version 2 (without user=phone as the user are not limited to phones). > In this last case one would not need to query the > SRV records in provB.net Also in the last case (if beeing conform with RFC3263), the egress proxy has to perform NAPTR and SRV lookups. If you want to avoid them, just put the IP address or the port into the host part, e.g. sip:+4319793321@ingress21.provB.net:5060;user=phone regards klaus _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 07 11:23:19 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 1Ek24d-0001kL-A2; Wed, 07 Dec 2005 11:23:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek24a-0001iK-3B; Wed, 07 Dec 2005 11:23:16 -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 LAA25522; Wed, 7 Dec 2005 11:22:22 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ek2QI-0005jj-M0; Wed, 07 Dec 2005 11:45:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] SIP AoR, tel and ENUM - Second Try Date: Wed, 7 Dec 2005 17:23:52 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C46FC@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] SIP AoR, tel and ENUM - Second Try Thread-Index: AcX7K+OV505wavEbRymxIc1sIbE0oQAHrk1p From: "Stastny Richard" To: "Klaus Darilion" X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 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 Thanx Klaus Also for answering a question I did not (yet) ask regarding redirect vs proxy >I personally prefer relaying instead of redirect. Me too and I see your arguments. Are there any arguments out there why to prefer redriect? =20 Richard ________________________________ Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Gesendet: Mi 07.12.2005 13:39 An: Stastny Richard Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org Betreff: Re: [Enum] SIP AoR, tel and ENUM - Second Try Hi Richard! comments inline Stastny Richard wrote: > Should Infrastructure ENUM contain a routing information > to the next hop only (the ingress border element of Provider B > (or administrative domain B) > or simply a mapping from an E.164 number to an AoR? IMHO it should be a mapping to an AoR as in user ENUM. > I will try to give another example and start from ... > I subscribe with provider B and get a default public > user identity (AoR) from this provider: > e.g. sip:foo@provB.net > > This "foo" can be anything the provider chooses it to be: > e.g. an alphanumeric string such as ywzabcd, > a numeric string such as 16241 (my FWD number) > or 019793321 or 4319793321 > > Any other provider A having a peering agreement > with Provider B must be able to route a SIP call > given this SIP AoR to provider B, either to the > SIP proxy hosting this account or at least to > the ingress proxy(s) in provider B network. > > On way to do so is to use SRV records within > the zone of provB.net pointing to e.g > > ingress14.provB.net > and > ingress21.provB.net > > Question: is this correct? IMO yes. Thus, A sends "INVITE sip:foo@provB.net" to ingress14.provB.net > Note: after the ingress proxy provider B > may use another mapping mechanism to find > the real hosting server e.g. srv21.provB.net > > Now I as a user are not happy with this default > public user identity, I want to have some aliases > > eg: > 1)sip:richard@stastny.com and > 2) +43 1 9793321 > > In case 1) I assume that provider B needs > to provide me with redirect server(s), and I > need to enter in stastny.com SRV records > to point to these redirect servers > e.g. redirect.provB.net > > sip:richard.stastny.com is redirected to > sip:foo@provB.net > > Question: is this correct? This is a working scenario. But a redirect server is not mandatory. It may also be a proxy which forwards the request "INVITE sip:richard.stastny.com" to "INVITE sip:foo@provB.net". It is also possbile that SRV for stastny.com points directly to ingress12.provB.net and ingress12 knows about all hosted SIP domains and knows how to forward the request to the end user. But this is a design decision of the provB and IMO should be out of scope of SPEERMINT. provB may use redirect server, provC may accept all hosted SIP domains directly on their ingress points, ..... I personally prefer relaying instead of redirect. E.g. redirect raises questions like: How should intercept the redirect response and forward to the new URI? The UA client or the SIP proxy of provA or the egress = proxy? The important thing is that the originator (provA) should not have to take care how provB implemented the hosting of SIP domains. > In case 2) we need Infrastructure ENUM > [Side note; in my user ENUM I would either enter > sip:richard@stastny.com or sip:foo@provB.net > this is my choice] > > Now the question is: what goes into Infrastructure > ENUM for say +4319793321? > > Is it: > Sip:foo@provB.net (if plain sip:foo@provB.net works > this must also work) > OR > sip:+4319793321@provB.net;user=3Dphone (correct?) > OR > sip:+4319793321@provB.net (wrong?) > OR > sip:4319793321@provB.net (valid only if 4319793321 =3D foo) > > OR is it > sip:+4319793321@ingress14.provB.net;user=3Dphone (and the above = variants) > AND > sip:+4319793321@ingress21.provB.net;user=3Dphone IMO all of these are valid. It's up to the choice of provB. provB can put anything into ENUM as long as provB is able to map from the URI in I-ENUM to the end user. If I would design the network for provB, I would use version 2 (without user=3Dphone as the user are not limited to phones). > In this last case one would not need to query the > SRV records in provB.net Also in the last case (if beeing conform with RFC3263), the egress proxy has to perform NAPTR and SRV lookups. If you want to avoid them, just put the IP address or the port into the host part, e.g. sip:+4319793321@ingress21.provB.net:5060;user=3Dphone regards klaus _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 07 11:27:32 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 1Ek28i-0002yJ-5c; Wed, 07 Dec 2005 11:27:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek28f-0002wF-In; Wed, 07 Dec 2005 11:27:29 -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 LAA25823; Wed, 7 Dec 2005 11:26:36 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ek2UO-0005te-Mq; Wed, 07 Dec 2005 11:49:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] SIP AoR, tel and ENUM - Second Try Date: Wed, 7 Dec 2005 17:27:27 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C46FD@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] SIP AoR, tel and ENUM - Second Try Thread-Index: AcX7K+OV505wavEbRymxIc1sIbE0oQAHzluu From: "Stastny Richard" To: "Klaus Darilion" X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 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 Klaus wrote: >If I would design the network for provB, I would use version 2 (without >user=3Dphone as the user are not limited to phones). You mean: > sip:+4319793321@provB.net;user=3Dphone=20 =20 IMHO this does not imply that the user uses a phone, it implies that the user-part is a Tel URI ! =20 =20 Richard ________________________________ Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Gesendet: Mi 07.12.2005 13:39 An: Stastny Richard Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org Betreff: Re: [Enum] SIP AoR, tel and ENUM - Second Try Hi Richard! comments inline Stastny Richard wrote: > Should Infrastructure ENUM contain a routing information > to the next hop only (the ingress border element of Provider B > (or administrative domain B) > or simply a mapping from an E.164 number to an AoR? IMHO it should be a mapping to an AoR as in user ENUM. > I will try to give another example and start from ... > I subscribe with provider B and get a default public > user identity (AoR) from this provider: > e.g. sip:foo@provB.net > > This "foo" can be anything the provider chooses it to be: > e.g. an alphanumeric string such as ywzabcd, > a numeric string such as 16241 (my FWD number) > or 019793321 or 4319793321 > > Any other provider A having a peering agreement > with Provider B must be able to route a SIP call > given this SIP AoR to provider B, either to the > SIP proxy hosting this account or at least to > the ingress proxy(s) in provider B network. > > On way to do so is to use SRV records within > the zone of provB.net pointing to e.g > > ingress14.provB.net > and > ingress21.provB.net > > Question: is this correct? IMO yes. Thus, A sends "INVITE sip:foo@provB.net" to ingress14.provB.net > Note: after the ingress proxy provider B > may use another mapping mechanism to find > the real hosting server e.g. srv21.provB.net > > Now I as a user are not happy with this default > public user identity, I want to have some aliases > > eg: > 1)sip:richard@stastny.com and > 2) +43 1 9793321 > > In case 1) I assume that provider B needs > to provide me with redirect server(s), and I > need to enter in stastny.com SRV records > to point to these redirect servers > e.g. redirect.provB.net > > sip:richard.stastny.com is redirected to > sip:foo@provB.net > > Question: is this correct? This is a working scenario. But a redirect server is not mandatory. It may also be a proxy which forwards the request "INVITE sip:richard.stastny.com" to "INVITE sip:foo@provB.net". It is also possbile that SRV for stastny.com points directly to ingress12.provB.net and ingress12 knows about all hosted SIP domains and knows how to forward the request to the end user. But this is a design decision of the provB and IMO should be out of scope of SPEERMINT. provB may use redirect server, provC may accept all hosted SIP domains directly on their ingress points, ..... I personally prefer relaying instead of redirect. E.g. redirect raises questions like: How should intercept the redirect response and forward to the new URI? The UA client or the SIP proxy of provA or the egress = proxy? The important thing is that the originator (provA) should not have to take care how provB implemented the hosting of SIP domains. > In case 2) we need Infrastructure ENUM > [Side note; in my user ENUM I would either enter > sip:richard@stastny.com or sip:foo@provB.net > this is my choice] > > Now the question is: what goes into Infrastructure > ENUM for say +4319793321? > > Is it: > Sip:foo@provB.net (if plain sip:foo@provB.net works > this must also work) > OR > sip:+4319793321@provB.net;user=3Dphone (correct?) > OR > sip:+4319793321@provB.net (wrong?) > OR > sip:4319793321@provB.net (valid only if 4319793321 =3D foo) > > OR is it > sip:+4319793321@ingress14.provB.net;user=3Dphone (and the above = variants) > AND > sip:+4319793321@ingress21.provB.net;user=3Dphone IMO all of these are valid. It's up to the choice of provB. provB can put anything into ENUM as long as provB is able to map from the URI in I-ENUM to the end user. If I would design the network for provB, I would use version 2 (without user=3Dphone as the user are not limited to phones). > In this last case one would not need to query the > SRV records in provB.net Also in the last case (if beeing conform with RFC3263), the egress proxy has to perform NAPTR and SRV lookups. If you want to avoid them, just put the IP address or the port into the host part, e.g. sip:+4319793321@ingress21.provB.net:5060;user=3Dphone regards klaus _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 07 14:50:11 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 1Ek5Ip-0006bs-C6; Wed, 07 Dec 2005 14:50:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek5Ik-0006Y7-S8; Wed, 07 Dec 2005 14:50:08 -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 OAA19261; Wed, 7 Dec 2005 14:49:14 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek5eU-00050N-VI; Wed, 07 Dec 2005 15:12:35 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 07 Dec 2005 11:49:56 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,226,1131350400"; d="scan'208"; a="16795355:sNHT28643328" 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 jB7JnR4t000270; Wed, 7 Dec 2005 14:49:53 -0500 (EST) 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, 7 Dec 2005 14:49:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Dec 2005 14:49:05 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA080A@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] SIP AoR, tel and ENUM Thread-Index: AcX7CP/OGhXFobDjTDK4lvWZXNCGcQAXeDow From: "Michael Hammer \(mhammer\)" To: "Klaus Darilion" X-OriginalArrivalTime: 07 Dec 2005 19:49:06.0042 (UTC) FILETIME=[48238DA0:01C5FB67] X-Spam-Score: 1.1 (+) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , sip@ietf.org Subject: [Enum] RE: [Sip] SIP AoR, tel and 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 don't have issues with what you have said. I was trying to discover what was objectionable in what I had said, but thre doesn't seem to be anything. Mike =20 > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 > Sent: Wednesday, December 07, 2005 3:33 AM > To: Michael Hammer (mhammer) > Cc: Stastny Richard; voipeer@lists.uoregon.edu;=20 > enum@ietf.org; sip@ietf.org > Subject: Re: [Sip] SIP AoR, tel and ENUM >=20 > Hi Michael! >=20 > As there are some concerns about the terminology. Thus I will=20 > use AD (adminsitrative domain, from the SPEERMINT charter) as=20 > synonym for ITSP, carrier, telco, VoIP enabled enterprise ..... >=20 > Michael Hammer (mhammer) wrote: > > Klaus, > >=20 > > It has to do with the difference between re-targeting and=20 > routing. Is=20 > > the point of interconnect the real target of the request or just a=20 > > waypoint in the route to get to the target? In the User=20 > ENUM case, it=20 > > seems as though the addresses are all about the target=20 > users and their=20 > > devices. But, here it seemed a bit different. It is a=20 > route through=20 > > an intermediate point. It seems like the semantic and syntactical=20 > > element would be more coherent and no more complicated. =20 > Thus, I posed=20 > > the question. >=20 > I can not really see a difference to user ENUM. There is only=20 > one Infrastructure ENUM tree. Thus, all ADs which query this=20 > tree will get the same URI back from ENUM. Thus, the ingress=20 > point announced by the receiving AD is the same for all outgoing ADs. >=20 > Further, if the outgoing AD does not send the request=20 > directly to the announced ingress point (maybe no peering=20 > relationship), but to an intermediate point (transit=20 > provider, clearinghouse, ....), this routing is different for=20 > each AD. Thus, such kind of routing information can not be in ENUM. >=20 > Once the request reaches the ingress point of the receiving=20 > AD, there will be further routing inside the receiving AD.=20 > Maybe the route is for > example: > 1. ingresspoint1.ad > 2. accountingbox.ad > 3. mainproxy.ad > 4. ..... >=20 > Publishing such a route in ENUM makes no sense, as the route=20 > is the same for all incoming requests. Thus, the route should=20 > be applied by the previous hop. That means, ingresspoint1.ad=20 > knows that it should formward to accountingbox.ad, and so on. >=20 > IMO, ENUM is a simple routing and re-targeting in one step.=20 > If complex re-routing and re-targeting is required it should=20 > be done by the receiving AD. The outoing AD is not interested=20 > in the internal routing of the receiving AD. >=20 > Maybe you can give me an example of a scenario were my model=20 > does not fit. >=20 > regards > klaus >=20 >=20 >=20 > >=20 > > Mike > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > >>Sent: Tuesday, December 06, 2005 11:48 AM > >>To: Stastny Richard > >>Cc: Michael Hammer (mhammer); voipeer@lists.uoregon.edu;=20 > >>enum@ietf.org; sip@ietf.org > >>Subject: Re: [Sip] SIP AoR, tel and ENUM > >> > >>Stastny Richard wrote: > >> > >>>Mike wrote: > >>> > >>> > >>> > >>>>Before going down this path too far, can we ask where the > >> > >>results of > >> > >>>>the ENUM queries will go in the SIP message to control routing? > >>>>Hypothetically, the egress and ingress gateways could be > >> > >>identified in > >> > >>>>Route headers rather than in the Request-URI. An=20 > external ENUM dip=20 > >>>>and an internal ENUM dip might lead to something along=20 > the lines of: > >>> > >>>=20 > >>>Correct, > >>>=20 > >>>Jonathan proposed this some time ago, but this thread somewhere=20 > >>>stranded > >>>=20 > >>>So basically an interneal ENUM entry of > >>> > >>>sip:+1777555111@egress.provider3.com;user=3Dphone > >>>=20 > >>>would result in > >>> > >>>INVITE tel:+17775551111 SIP/2.0 > >>>... > >>>Route: > >>>=20 > >>>an the external ENUM entry would be > >>>sip:+1777555111@provider17.com > >>>=20 > >>>result in > >>>Route: > >>>=20 > >>>This is basically what I am after > >>>... > >>> > >> > >>Hi folks. > >> > >>What is the benefit of splitting the ENUM result (the SIP > >>URI) into a Route header and into a request URI? > >> > >>IMO there should be no semantic for the internal routing=20 > (the routing=20 > >>from the main proxy to the egress proxy). This should be=20 > out of scope=20 > >>of all WGs. Also the internal routing of the ingress=20 > provider should=20 > >>be out of scope. The ingress provider should have SIP URI=20 > which can be=20 > >>used to address its customers. > >> > >>If this URI is sip:431505641636@in.mydomain.com or=20 > >>foobar666@in.mydomain.com, or=20 > sip:klaus.darilion@mydomain.com is the=20 > >>ingress provider's choice. Maybe the ingress provider also=20 > allows all=20 > >>of the previous SIP URIs to reach a certain user. The incoming=20 > >>provider just has to make sure that these SIP URIs map to the=20 > >>corresponding user (to the user's AoR). > >>If this user also has an E.164 number which is in I-ENUM, then it's=20 > >>again the ingress provider's choice which URI to put into the NAPTR. > >> > >>IMO there should not not be any semantics how to create a=20 > request URI=20 > >>and a pre-loaded route set of the SIP URI received from ENUM. The=20 > >>egress proxy sends the request to the ingress proxy in the format=20 > >>choosen by the ingress provider (e.g. publish via ENUM or=20 > an business=20 > >>cards). > >> > >>We should not complicate things. I do not see any problems=20 > with this=20 > >>simple approach. If there are some problems, please correct me. > >> > >>regards > >>klaus > >> > >> > >> > >> > >>>>I am also suggesting that the ENUM result be an AoR, since > >> > >>one might > >> > >>>>want some reliability in choosing which server in the > >> > >>gateway cluster > >> > >>>>to go to based on further DNS queries, load balancing, etc. > >>> > >>>=20 > >>>Now this is in contradiction to the above > >>>=20 > >>>Richard > >>> > >>> > >>> > >>>>Mike > >>> > >>> > >>>>-----Original Message----- > >>>>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > >> > >>Behalf Of > >> > >>>>Stastny Richard > >>>>Sent: Tuesday, December 06, 2005 4:54 AM > >>>>To: voipeer@lists.uoregon.edu > >>>>Cc: enum@ietf.org; sip@ietf.org > >>>>Subject: [Sip] SIP AoR, tel and ENUM > >>>> > >>>>Folks, > >>>> > >>>>This post is primarily to SPEER, but since it also concerns > >> > >>ENUM and > >> > >>>>SIP I cross-post it. > >>>> > >>>>I need (urgently) some guidance on the question what SIP > >> > >>URIs to use > >> > >>>>in Infrastructure ENUM. > >>>> > >>>>User ENUM as defined in RFC 3761 provides a mapping from > >>>>E.164 numbers to SIP URIs for primarily for end-users. So > >> > >>what you get > >> > >>>>back is the AoR pointing to the destination SIP server. > >>>> > >>>>If you get something back on the ENUM query such as=20 > >>>>sip:Richard@stastny.com, this is definetely an AoR. Because > >> > >>of privacy > >> > >>>>reasons, more and more people start using SIP URI such as=20 > >>>>sip:4319793321@provider.net or (an AoR)=20 > >>>>sip:+4319793321@provider.net;user=3Dphone (IMHO not an AoR) or = even=20 > >>>>sip:+4319793321@provider.net > >>>> > >>>>IMHO the last one should not be used, and some guidance is > >> > >>also needed > >> > >>>>here. but it only concerns the destination server and if the=20 > >>>>destination servers can deal with it, fine. > >>>> > >>>>Now with Infrastructure ENUM (and especially in combination with=20 > >>>>private ENUMs) the situation is different. > >>>> > >>>>The purpose of Infrastructure ENUM is according to the=20 > re-chartered=20 > >>>>ENUM WG "to discover points of interconnection necessary to > >> > >>terminate > >> > >>>>communications sessions identified by a E164 number, in=20 > addition to=20 > >>>>identifying end point protocols and services." > >>>> > >>>>This translates to: Infrastructure ENUM does not > >> > >>necessarily contain > >> > >>>>end-point information (AoR), but routing information. > >>>>Routing, in my definition here, is basically to provide you > >> > >>with the > >> > >>>>information what the next hop is. > >>>> > >>>>A very common scenario is the following one: a walled > >> > >>garden network > >> > >>>>is using private ENUM to detect the border element for a > >> > >>given number, > >> > >>>>Some border element may lead to another private=20 > (extranet), using a=20 > >>>>federated ENUM for this number, another may be connected to the=20 > >>>>Internet using public Infrastructure ENUM for another number. > >>>>Public Infrastructure ENUM is giving back the ingress > >> > >>border element, > >> > >>>>which in turn uses private ENUM again to find the SIP > >> > >>server hosting > >> > >>>>the user with this number. > >>>> > >>>>In addition, again for privacy reasons, in most cases the above=20 > >>>>mentioned SIP URIs containing E.164 numbers are used. > >>>> > >>>>This raises two issues, an architectural one and a BCP one: > >>>> > >>>>To principally different scenarios are possible > >>>> > >>>>Scenario A > >>>> > >>>>ENUM is providing ONLY the mapping from the E.164 number to > >> > >>an AoR. (=3D > >> > >>>>name to address mapping) The above described routing between the=20 > >>>>networks to find the destination network is done via the > >> > >>AoR. How this > >> > >>>>is done is completely within the scope of SPEER. > >>>> > >>>>Note: this is the only future proof way, because a user=20 > may use the=20 > >>>>AoR in the first place and then the routing MUST work > >> > >>anyway. So any > >> > >>>>additional routing information in ENUM would be duplicated and=20 > >>>>therefore error-prone. > >>>> > >>>>I propose in addition to use in this case a SIP in the format=20 > >>>>sip:4319793321@provider.net, to clearly indicate that this has no=20 > >>>>relationship to an E.164 number. > >>>> > >>>>Scenario B: > >>>> > >>>>This is the scenario proposed in most current > >> > >>implementations and also > >> > >>>>in the RFI on ENUM popping up everywhere. The reason is that most=20 > >>>>scenarios currently concentrate solely on the peering with E.164=20 > >>>>numbers and completely forget the peering with SIP URIs > >>>> > >>>>The ENUM entry is giving you the next hop: This is in case of the=20 > >>>>walled garden originating network either the server hosting the=20 > >>>>end-user or the egress border element (e.g. IBCF, THIG, or=20 > >>>>whatchamacallit). This element is again querying another > >> > >>kind of ENUM, > >> > >>>>getting back the ingress border element of the destination > >> > >>network (or > >> > >>>>even of a "transit" L5 network), and so on. The ingress > >> > >>border element > >> > >>>>is the again calling its private ENUM to finally find the hosting=20 > >>>>server. > >>>> > >>>>Note: I have a sub-question here: Some implementations are even=20 > >>>>proposing here to skip the SRV query and directly pointing > >> > >>to the SIP > >> > >>>>server(s) in ENUM. Does this make sense? > >>>> > >>>>If this scenario is used, I propose to use only SIP URIs in > >> > >>the format > >> > >>>>sip:+4319793321@provider.net;user=3Dphone or better=20 > >>>>SIP:+4319793321@sbc.prov.net; user=3Dphone > >>>> > >>>>to clearly indicate that this is still basically a > >>>>tel: URI combined with a routing info and that it may be used in=20 > >>>>another ENUM query. > >>>> > >>>>My questions to the crowd are the following: > >>>> > >>>>1. is this proposed use of SIP URIs within the context of ENUM ok? > >>>> > >>>>2. What should be the preferred scenario for VoIP peering? > >>>>Is some kind of combination between the scenarios feasible? > >>>>And what are the arguments pro and con? > >>>> > >>>>I consider the outcome of this discussion as substantial > >> > >>input to the > >> > >>>>deliverables of SPEER, but some first guidance is=20 > urgently required=20 > >>>>now, because many entities are making basic decisions in this=20 > >>>>direction NOW. > >>>> > >>>>Please also excuse and correct incorrect use of terminology. > >>>> > >>>>Regards > >>>>Richard Stastny > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>This list is for NEW development of the core SIP Protocol Use=20 > >>>>sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>>>sipping@ietf.org for new developments on the application of sip > >>>> > >>> > >>> > >>> > >>>_______________________________________________ > >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>This list is for NEW development of the core SIP Protocol Use=20 > >>>sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>>sipping@ietf.org for new developments on the application of sip > >>> > >>> > >> > >=20 > >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 07 15:23:34 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 1Ek5p8-0007FJ-M9; Wed, 07 Dec 2005 15:23:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek5p6-0007DV-NQ; Wed, 07 Dec 2005 15:23:33 -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 PAA22515; Wed, 7 Dec 2005 15:22:40 -0500 (EST) 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 1Ek6As-00068b-2D; Wed, 07 Dec 2005 15:46:02 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 07 Dec 2005 12:23:23 -0800 X-IronPort-AV: i="3.99,226,1131350400"; d="scan'208"; a="375315478:sNHT1282961368" 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 jB7KM5Bt017107; Wed, 7 Dec 2005 12:23:19 -0800 (PST) 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); Wed, 7 Dec 2005 15:23:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Wed, 7 Dec 2005 15:23:06 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA082B@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Thread-Index: AcX6yySCxyyxZ86zQZWvC9QFGn/uPQAoDi3g From: "Michael Hammer \(mhammer\)" To: "James Polk \(jmpolk\)" , , "Thilo Salmon" , "Klaus Darilion" X-OriginalArrivalTime: 07 Dec 2005 20:23:07.0752 (UTC) FILETIME=[0917C680:01C5FB6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 James, This is d=E9j=E0 vu from the FG-NGN discussion on the exact same topic. = I have no issues with making distinctions of this type. It was just not = clear to me which of these various types (or the ones that Henry = mentions) was in scope or not, but that seemed secondary to the point = being made at the time that had to do with what the X entity did with an = ENUM response that affected the constraints on what could be contained = in such responses. Mike > -----Original Message----- > From: James Polk (jmpolk)=20 > Sent: Tuesday, December 06, 2005 8:11 PM > To: Michael Hammer (mhammer); henry@pulver.com; Thilo Salmon;=20 > Klaus Darilion > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20 > Stastny Richard > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM >=20 > Mike >=20 > This seems to be creeping into more than one WG at about the=20 > same time. >=20 > ISP used to be (roughly) the company you or you employer=20 > bought service from to gain access to the Internet. Now that=20 > is a little too generic for a lot of people's tastes as there=20 > are different SPs that an individual many have now that=20 > weren't available not so long ago. Hence the recent push to=20 > separate them somehow. >=20 > Application Providers, to me, include a Vonage for Voice=20 > services, and a Yahoo for IM. >=20 > Service Providers or Internet Providers, to me, connect one=20 > to the Internet for L3 access >=20 > Access Providers, to me, are the organizations like the DSL=20 > and Cable and WiFi connectivity providers. >=20 > Often times, to me, the Internet Providers and the Access=20 > Providers are either the same company - while perhaps=20 > different divisions, but they can be totally different companies too. >=20 > The separation I'm seeing is between the organization that=20 > gives you you Internet access and the organizations that=20 > provider you with all the services required for a particular=20 > application - such as Voice or Video. >=20 > Everything used to be best effort, and services were either=20 > at your device or at the provider's server. Now there's an=20 > overlay at layer 7 (typically) and we're struggling with how=20 > to name and describe it. >=20 >=20 >=20 > At 06:23 PM 12/6/2005 -0500, Michael Hammer \(mhammer\) wrote: > >My looking glass is smudged today. > > > >What does one call a provider of service? > >I don't understand the aversion to service provider. > > > >I thought it was only the "carrier" word that invoked regulatory=20 > >burdens (or PATS!). I'd rather leave legal word games to=20 > lawyers and lobbyists. > > > >Mike > > > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:henry@pulver.com] > > > Sent: Tuesday, December 06, 2005 5:30 PM > > > To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion' > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20 > enum@ietf.org; 'Stastny=20 > > > Richard' > > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > > > Sorry for nitpicking: > > > > > > >A provider is a provider. > > > > > > A provider is a business model and att/SBC may differ from Google=20 > > > who uses a different business model (which is more significant=20 > > > measured in $$$?). > > > > > > Didn't we agree to use the term "Internet domain owner" (we could=20 > > > shorten to IDOM or such)? > > > > > > Internet domains are well defined in the IETF. > > > Business models for VoIP are better suited for other=20 > organizations,=20 > > > consortia or innovators who work to disrupt them :-) > > > > > > Thanks, Henry > > > > > > -----Original Message----- > > > From: owner-voipeer@lists.uoregon.edu=20 > > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of=20 > Michael Hammer > > > (mhammer) > > > Sent: Tuesday, December 06, 2005 3:36 PM > > > To: Thilo Salmon; Klaus Darilion > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20 > enum@ietf.org; Stastny=20 > > > Richard > > > Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > > > I am having trouble parsing these statements. > > > > > > A provider is a provider. I used the terms ingress and egress to=20 > > > indicate some server that sits on the edge of a=20 > provider's network=20 > > > and does peering to some other provider. > > > The usage below seems to mix egress with originating being the=20 > > > network where the caller is attached. > > > > > > I was noting that the called party terminal and the interconnect=20 > > > points were different hosts and therefore may have different=20 > > > identities. To keep maximum flexibility, the format of those=20 > > > identities would need to be fully under the control of=20 > the domain of=20 > > > each provider. However, conflating all that into a single URI in=20 > > > the Request-URI seemed constraining to me. Having three URIs in=20 > > > separate headers seemed the most flexible. > > > > > > Splitting. I don't understand what got split or how. ENUM > > > -- Tel:URI in, Point-of-interconnect URI out. Put in=20 > Route header. =20 > > > I only suggested that there might be two route headers=20 > because the=20 > > > terminating provider would indicate in ENUM, to get to this=20 > > > end-user, go to this entrance first. > > > But, to get to that entrance, the originating provider needs to=20 > > > determine what the corresponding exit point is from his network,=20 > > > i.e. another Route header. The format and content of=20 > that URI is up=20 > > > to each provider. The advertised entrance point is I think by=20 > > > definition the (Inter-) Carrier ENUM. > > > The internal determination of the exit point could be termed > > > (Intra-) Carrier ENUM. Maybe peering is concerned only with the=20 > > > inter-carrier aspect. > > > > > > The Request-URI could be a normalized public identity of the user=20 > > > totally independent of interconnect naming schemes. I was just=20 > > > teasing out what are the assumptions and constraints in=20 > the original=20 > > > email. > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Thilo Salmon [mailto:salmon@sipgate.de] > > > > Sent: Tuesday, December 06, 2005 2:06 PM > > > > To: Klaus Darilion > > > > Cc: Michael Hammer (mhammer); sip@ietf.org; > > > voipeer@lists.uoregon.edu; > > > > enum@ietf.org; Stastny Richard > > > > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > > > > > Richard, Klaus, et al. > > > > > > > > Apparently, I have missed an important developlement lately. > > > > > > > > > What is the benefit of splitting the ENUM result (the SIP > > > > URI) into a > > > > > Route header and into a request URI? > > > > [...] > > > > > IMO there should be no semantic for the internal routing > > > > (the routing > > > > > from the main proxy to the egress proxy). This should be > > > > out of scope > > > > > of all WGs. Also the internal routing of the ingress > > > > provider should > > > > > be out of scope. The ingress provider should have SIP URI > > > > which can be > > > > > used to address its customers. > > > > > > > > I absolutely second that statement. If for any reason=20 > (we all have=20 > > > > enough a vivid enough phantasy to imagine a good reason, I > > > suppose) an > > > > ingress provider wishes to feed a different set of SIP URIs to=20 > > > > each and every of his egress partners, he should not be=20 > stripped=20 > > > > of this option. > > > > The scenario I have in mind is one in which an ingress provider=20 > > > > chooses to encrypt the user part of all his SIP URIs with a key=20 > > > > uniquely assigns to his egress partner. > > > > > > > > Just as Klaus I feel this complicates things and takes > > > authority over > > > > internal adressing away from the ingress provider for no reason=20 > > > > apparent (to me). > > > > > > > > Thilo > > > > > > > > > > ______________________________________________________________ > > > ______________ > > > _ > > > 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 >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 07 16:38:01 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 1Ek6zB-0005mm-48; Wed, 07 Dec 2005 16:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek6z5-0005m8-Gk; Wed, 07 Dec 2005 16:37:57 -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 QAA03463; Wed, 7 Dec 2005 16:37:02 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek7Kr-0001N8-EW; Wed, 07 Dec 2005 17:00:25 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1Ek6z3-0002Ql-Na; Wed, 07 Dec 2005 16:37:53 -0500 Content-Type: text/plain Mime-Version: 1.0 To: IETF Announcement list From: The IESG Message-Id: Date: Wed, 07 Dec 2005 16:37:53 -0500 X-Spam-Score: 0.8 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: enum@ietf.org, Patrik Faltstrom , Richard Shockey Subject: [Enum] WG Action: RECHARTER: Telephone Number Mapping (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 Telephone Number Mapping (enum) working group in the Transport Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. +++ Telephone Number Mapping (enum) -------------------------------- Current Status: Active Working Group Chair(s): Patrik Faltstrom Richard Shockey Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: Allison Mankin Secretary(ies): Alex Mayrhofer Mailing Lists: General Discussion: enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/enum/index.html Description of Working Group: 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: Done Initial draft of Service ENUM Requirements Done Initial draft of ENUM Protocol Done Revised draft of ENUM Protocol Done Submit ENUM Protocol document to IESG for publication as Proposed Done Revise and update RFC 2916 appropriate to DDDS (revision of 2915) Done ENUM service registrations for SIP and H.323 Mar 06 Enumservice Registration for Local Number Portability and Related Data as a Proposed Standard Apr 06 Requirements for Carrier Interconnection using ENUM as an Informational Jun 06 Carrier Interconnection using ENUM as a Proposed Standard Jul 06 ENUM Privacy and Security Considerations as an Informational Aug 06 Advancement of RFC 3761 to Draft Standard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 07 18:52:34 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 1Ek95O-00076C-DI; Wed, 07 Dec 2005 18:52:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek95M-00075u-BQ; Wed, 07 Dec 2005 18:52:32 -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 SAA18942; Wed, 7 Dec 2005 18:51:40 -0500 (EST) 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 1Ek9R8-0006Jw-Pb; Wed, 07 Dec 2005 19:15:03 -0500 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 jB7Nmqx05052; Wed, 7 Dec 2005 18:48:52 -0500 (EST) 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, 7 Dec 2005 18:51:54 -0500 Message-ID: Thread-Topic: [Sip] SIP AoR, tel and ENUM - Second Try Thread-Index: AcX6l7ng7d5gWyzJReGGP+c21C99TwAEhbpAAAJAsEAAGzinsAAZVNyQ From: "James McEachern" To: "Stastny Richard" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Enum] RE: [Sip] SIP AoR, tel and ENUM - Second Try X-BeenThere: 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, It seems to me there are two basic options here, both of which are = roughly equivalent. 1. I-ENUM contains an AoR, (probably in a format like = sip:+4319793321@provB.net;user=3Dphone, rather than something like = sip:richard@stastny.com, to protect user privacy). The SRV records for = provB could then point to ingress14.provB.net and ingress21.provB.net. OR 2. I-ENUM contains "sip:+4319793321@ingress14.provB.net;user=3Dphone" = AND "sip:+4319793321@ingress21.provB.net;user=3Dphone". Presumably provB controls the content of its information in both I-ENUM = and its SRV records, so it could even be left up to provB to decide = which method to use. The main difference I can see is that option 2 would allow provB to = identify different ingress gateways for different customers, which might = be useful. However, option 2 would result in different treatment = depending on whether the call was originated with an E.164 number or a = SIP URI, which seems undesirable. Does this sound reasonable? Jim -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Stastny Richard Sent: Wednesday, December 07, 2005 7:01 AM To: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org Subject: [Sip] SIP AoR, tel and ENUM - Second Try Hi folks, thanks for the statements sofar, but I am still confused (maybe even more ;-) It seems also that my first post was not too well formulated The basic question was: Should Infrastructure ENUM contain a routing information to the next hop only (the ingress border element of Provider B (or administrative domain B)=20 or simply a mapping from an E.164 number to an AoR? I will try to give another example and start from within the scope of SPEERMINT (I hope this is the last iteration before the name gets too lomg ;-) I subscribe with provider B and get a default public user identity (AoR) from this provider: e.g. sip:foo@provB.net This "foo" can be anything the provider chooses it to be: e.g. an alphanumeric string such as ywzabcd, a numeric string such as 16241 (my FWD number) or 019793321 or 4319793321 Any other provider A having a peering agreement with Provider B must be able to route a SIP call given this SIP AoR to provider B, either to the SIP proxy hosting this account or at least to the ingress proxy(s) in provider B network. On way to do so is to use SRV records within the zone of provB.net pointing to e.g ingress14.provB.net and ingress21.provB.net Question: is this correct? Note: after the ingress proxy provider B may use another mapping mechanism to find the real hosting server e.g. srv21.provB.net Now I as a user are not happy with this default public user identity, I want to have some aliases eg:=20 1)sip:richard@stastny.com and 2) +43 1 9793321 In case 1) I assume that provider B needs to provide me with redirect server(s), and I need to enter in stastny.com SRV records to point to these redirect servers e.g. redirect.provB.net sip:richard.stastny.com is redirected to sip:foo@provB.net Question: is this correct? In case 2) we need Infrastructure ENUM [Side note; in my user ENUM I would either enter sip:richard@stastny.com or sip:foo@provB.net this is my choice] Now the question is: what goes into Infrastructure ENUM for say +4319793321? Is it: Sip:foo@provB.net (if plain sip:foo@provB.net works this must also work) OR sip:+4319793321@provB.net;user=3Dphone (correct?) OR sip:+4319793321@provB.net (wrong?) OR sip:4319793321@provB.net (valid only if 4319793321 =3D foo) OR is it sip:+4319793321@ingress14.provB.net;user=3Dphone (and the above = variants) AND sip:+4319793321@ingress21.provB.net;user=3Dphone In this last case one would not need to query the SRV records in provB.net I hope I did not confuse the issue even more Richard _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Dec 08 03:52:45 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 1EkHW9-0002PS-98; Thu, 08 Dec 2005 03:52:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkHW8-0002PI-Fm for enum@megatron.ietf.org; Thu, 08 Dec 2005 03:52:44 -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 DAA14609 for ; Thu, 8 Dec 2005 03:51:51 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkHry-0007bi-9X for enum@ietf.org; Thu, 08 Dec 2005 04:15:20 -0500 Received: from [127.0.0.1] (na.nona.net [::ffff:193.80.224.124]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 08 Dec 2005 09:52:07 +0100 id 000682DC.4397F437.00000742 Message-ID: <4397F417.1050104@enum.at> Date: Thu, 08 Dec 2005 09:51:35 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5 (Windows/20051025) 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: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Enum] NITS review request of draft-ietf-enum-vcard X-BeenThere: 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 Guys, since i'm one of the co-author of draft-ietf-enum-vcard i cannot NITS review that draft. A volunteer reviewing this document would be highly appreciated. thanks, Alex Mayrhofer _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Dec 08 09:52:34 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 1EkN8M-00061N-JZ; Thu, 08 Dec 2005 09:52:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkN8G-0005yT-68; Thu, 08 Dec 2005 09:52:33 -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 JAA23116; Thu, 8 Dec 2005 09:51:30 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkN8A-0002z9-LX; Thu, 08 Dec 2005 09:52:23 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 08 Dec 2005 06:52:13 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jB8EpJNG003428; Thu, 8 Dec 2005 06:52:09 -0800 (PST) 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); Thu, 8 Dec 2005 09:52:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Thu, 8 Dec 2005 09:52:02 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA09F8@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Thread-Index: AcX6yySCxyyxZ86zQZWvC9QFGn/uPQAoDi3gAAbserAAH9g8AA== From: "Michael Hammer \(mhammer\)" To: , "James Polk \(jmpolk\)" , "Thilo Salmon" , "Klaus Darilion" X-OriginalArrivalTime: 08 Dec 2005 14:52:03.0638 (UTC) FILETIME=[F3924560:01C5FC06] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 Henry, An IT department of an enterprise that operates VoIP servers is a = service provider, albeit a private versus a public one. Thus, I don't = see the limit you speak of. Adding an additional adjective "public" and you get a PATS or Carrier = that has narrower connotations. Mike > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com]=20 > Sent: Wednesday, December 07, 2005 7:10 PM > To: Michael Hammer (mhammer); James Polk (jmpolk); 'Thilo=20 > Salmon'; 'Klaus Darilion' > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20 > 'Stastny Richard' > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM >=20 > The VoIP calls in our offices can go directly between the two=20 > enterprise networks without any VoIP service providers being=20 > involved and this is as valid VoIP peering as any other. This=20 > is one of the reasons not to limit the VoIP peering models to=20 > only one, that with VoIP service providers in the middle.=20 >=20 > Sorry, I was not sure if the attached has taken this=20 > enterprise-enterprise into consideration and obviously there=20 > are other user scenarios as well. >=20 > Thanks, Henry >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, December 07, 2005 2:23 PM > To: James Polk (jmpolk); henry@pulver.com; Thilo Salmon;=20 > Klaus Darilion > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20 > Stastny Richard > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM >=20 > James, >=20 > This is d=E9j=E0 vu from the FG-NGN discussion on the exact same=20 > topic. I have no issues with making distinctions of this=20 > type. It was just not clear to me which of these various=20 > types (or the ones that Henry mentions) was in scope or not,=20 > but that seemed secondary to the point being made at the time=20 > that had to do with what the X entity did with an ENUM=20 > response that affected the constraints on what could be=20 > contained in such responses. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: James Polk (jmpolk) > > Sent: Tuesday, December 06, 2005 8:11 PM > > To: Michael Hammer (mhammer); henry@pulver.com; Thilo Salmon; Klaus=20 > > Darilion > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; Stastny=20 > > Richard > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > >=20 > > Mike > >=20 > > This seems to be creeping into more than one WG at about the same=20 > > time. > >=20 > > ISP used to be (roughly) the company you or you employer bought=20 > > service from to gain access to the Internet. Now that is a=20 > little too=20 > > generic for a lot of people's tastes as there are different=20 > SPs that=20 > > an individual many have now that weren't available not so=20 > long ago. =20 > > Hence the recent push to separate them somehow. > >=20 > > Application Providers, to me, include a Vonage for Voice=20 > services, and=20 > > a Yahoo for IM. > >=20 > > Service Providers or Internet Providers, to me, connect one to the=20 > > Internet for L3 access > >=20 > > Access Providers, to me, are the organizations like the DSL=20 > and Cable=20 > > and WiFi connectivity providers. > >=20 > > Often times, to me, the Internet Providers and the Access Providers=20 > > are either the same company - while perhaps different=20 > divisions, but=20 > > they can be totally different companies too. > >=20 > > The separation I'm seeing is between the organization that=20 > gives you=20 > > you Internet access and the organizations that provider you=20 > with all=20 > > the services required for a particular application - such=20 > as Voice or=20 > > Video. > >=20 > > Everything used to be best effort, and services were either at your=20 > > device or at the provider's server. Now there's an overlay=20 > at layer 7=20 > > (typically) and we're struggling with how to name and describe it. > >=20 > >=20 > >=20 > > At 06:23 PM 12/6/2005 -0500, Michael Hammer \(mhammer\) wrote: > > >My looking glass is smudged today. > > > > > >What does one call a provider of service? > > >I don't understand the aversion to service provider. > > > > > >I thought it was only the "carrier" word that invoked regulatory=20 > > >burdens (or PATS!). I'd rather leave legal word games to=20 > > lawyers and lobbyists. > > > > > >Mike > > > > > > > > > > -----Original Message----- > > > > From: Henry Sinnreich [mailto:henry@pulver.com] > > > > Sent: Tuesday, December 06, 2005 5:30 PM > > > > To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion' > > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20 > > enum@ietf.org; 'Stastny=20 > > > > Richard' > > > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR,=20 > tel and ENUM > > > > > > > > Sorry for nitpicking: > > > > > > > > >A provider is a provider. > > > > > > > > A provider is a business model and att/SBC may differ=20 > from Google=20 > > > > who uses a different business model (which is more significant=20 > > > > measured in $$$?). > > > > > > > > Didn't we agree to use the term "Internet domain owner"=20 > (we could=20 > > > > shorten to IDOM or such)? > > > > > > > > Internet domains are well defined in the IETF. > > > > Business models for VoIP are better suited for other=20 > > organizations,=20 > > > > consortia or innovators who work to disrupt them :-) > > > > > > > > Thanks, Henry > > > > > > > > -----Original Message----- > > > > From: owner-voipeer@lists.uoregon.edu=20 > > > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of=20 > > Michael Hammer > > > > (mhammer) > > > > Sent: Tuesday, December 06, 2005 3:36 PM > > > > To: Thilo Salmon; Klaus Darilion > > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20 > > enum@ietf.org; Stastny=20 > > > > Richard > > > > Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > > > > > I am having trouble parsing these statements. > > > > > > > > A provider is a provider. I used the terms ingress and=20 > egress to=20 > > > > indicate some server that sits on the edge of a=20 > > provider's network=20 > > > > and does peering to some other provider. > > > > The usage below seems to mix egress with originating being the=20 > > > > network where the caller is attached. > > > > > > > > I was noting that the called party terminal and the=20 > interconnect=20 > > > > points were different hosts and therefore may have different=20 > > > > identities. To keep maximum flexibility, the format of those=20 > > > > identities would need to be fully under the control of=20 > > the domain of=20 > > > > each provider. However, conflating all that into a=20 > single URI in=20 > > > > the Request-URI seemed constraining to me. Having=20 > three URIs in=20 > > > > separate headers seemed the most flexible. > > > > > > > > Splitting. I don't understand what got split or how. ENUM > > > > -- Tel:URI in, Point-of-interconnect URI out. Put in=20 > > Route header. =20 > > > > I only suggested that there might be two route headers=20 > > because the=20 > > > > terminating provider would indicate in ENUM, to get to this=20 > > > > end-user, go to this entrance first. > > > > But, to get to that entrance, the originating provider needs to=20 > > > > determine what the corresponding exit point is from his=20 > network,=20 > > > > i.e. another Route header. The format and content of=20 > > that URI is up=20 > > > > to each provider. The advertised entrance point is I think by=20 > > > > definition the (Inter-) Carrier ENUM. > > > > The internal determination of the exit point could be termed > > > > (Intra-) Carrier ENUM. Maybe peering is concerned only=20 > with the=20 > > > > inter-carrier aspect. > > > > > > > > The Request-URI could be a normalized public identity=20 > of the user=20 > > > > totally independent of interconnect naming schemes. I was just=20 > > > > teasing out what are the assumptions and constraints in=20 > > the original=20 > > > > email. > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Thilo Salmon [mailto:salmon@sipgate.de] > > > > > Sent: Tuesday, December 06, 2005 2:06 PM > > > > > To: Klaus Darilion > > > > > Cc: Michael Hammer (mhammer); sip@ietf.org; > > > > voipeer@lists.uoregon.edu; > > > > > enum@ietf.org; Stastny Richard > > > > > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > > > > > > > Richard, Klaus, et al. > > > > > > > > > > Apparently, I have missed an important developlement lately. > > > > > > > > > > > What is the benefit of splitting the ENUM result (the SIP > > > > > URI) into a > > > > > > Route header and into a request URI? > > > > > [...] > > > > > > IMO there should be no semantic for the internal routing > > > > > (the routing > > > > > > from the main proxy to the egress proxy). This should be > > > > > out of scope > > > > > > of all WGs. Also the internal routing of the ingress > > > > > provider should > > > > > > be out of scope. The ingress provider should have SIP URI > > > > > which can be > > > > > > used to address its customers. > > > > > > > > > > I absolutely second that statement. If for any reason=20 > > (we all have=20 > > > > > enough a vivid enough phantasy to imagine a good reason, I > > > > suppose) an > > > > > ingress provider wishes to feed a different set of=20 > SIP URIs to=20 > > > > > each and every of his egress partners, he should not be=20 > > stripped=20 > > > > > of this option. > > > > > The scenario I have in mind is one in which an=20 > ingress provider=20 > > > > > chooses to encrypt the user part of all his SIP URIs=20 > with a key=20 > > > > > uniquely assigns to his egress partner. > > > > > > > > > > Just as Klaus I feel this complicates things and takes > > > > authority over > > > > > internal adressing away from the ingress provider for=20 > no reason=20 > > > > > apparent (to me). > > > > > > > > > > Thilo > > > > > > > > > > > > > ______________________________________________________________ > > > > ______________ > > > > _ > > > > 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 > >=20 > >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Dec 08 10:55:08 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 1EkO6u-0005DI-5i; Thu, 08 Dec 2005 10:55:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkO6j-000590-5D; Thu, 08 Dec 2005 10:55:05 -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 KAA02186; Thu, 8 Dec 2005 10:53:49 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EkO6T-0005bu-JR; Thu, 08 Dec 2005 10:54:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Dec 2005 16:58:08 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4704@oefeg-s04.oefeg.loc> Thread-Topic: [Sip] SIP AoR, tel and ENUM - Second Try Thread-Index: AcX6l7ng7d5gWyzJReGGP+c21C99TwAEhbpAAAJAsEAAGzinsAAZVNyQACKAXZA= From: "Stastny Richard" To: "James McEachern" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Enum] Re: [Sip] SIP AoR, tel and ENUM - Second Try X-BeenThere: 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 wrote: >Presumably provB controls the content of its information in both I-ENUM = and its SRV records, so it could even be left up >to provB to decide = which method to use. This seems to be the consensus we are converging here There are only two caveats: 1. This is only easy if ProvB controls the NAPTRs directly (in a multi-Tier approach) If the data are held in a central DB (say a Peering Provider) and the provisioning is done via other means, a common approach may=20 be required for the whole DB. 2. All ProvAs querying the tree need also have a common understanding how to interpret the NAPTRs retrieved. So according to Klaus, the second entry should look: 2. I-ENUM contains = "sip:+4319793321@ingress14.provB.net:5060;user=3Dphone" AND "sip:+4319793321@ingress21.provB.net:5060;user=3Dphone". Richard ________________________________ Von: James McEachern [mailto:jmce@nortel.com] Gesendet: Do 08.12.2005 00:51 An: Stastny Richard; sip@ietf.org; voipeer@lists.uoregon.edu; = enum@ietf.org Betreff: RE: [Sip] SIP AoR, tel and ENUM - Second Try Richard, It seems to me there are two basic options here, both of which are = roughly equivalent. 1. I-ENUM contains an AoR, (probably in a format like = sip:+4319793321@provB.net;user=3Dphone, rather than something like = sip:richard@stastny.com, to protect user privacy). The SRV records for = provB could then point to ingress14.provB.net and ingress21.provB.net. OR 2. I-ENUM contains "sip:+4319793321@ingress14.provB.net;user=3Dphone" = AND "sip:+4319793321@ingress21.provB.net;user=3Dphone". Presumably provB controls the content of its information in both I-ENUM = and its SRV records, so it could even be left up to provB to decide = which method to use. The main difference I can see is that option 2 would allow provB to = identify different ingress gateways for different customers, which might = be useful. However, option 2 would result in different treatment = depending on whether the call was originated with an E.164 number or a = SIP URI, which seems undesirable. Does this sound reasonable? Jim -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Stastny Richard Sent: Wednesday, December 07, 2005 7:01 AM To: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org Subject: [Sip] SIP AoR, tel and ENUM - Second Try Hi folks, thanks for the statements sofar, but I am still confused (maybe even more ;-) It seems also that my first post was not too well formulated The basic question was: Should Infrastructure ENUM contain a routing information to the next hop only (the ingress border element of Provider B (or administrative domain B) or simply a mapping from an E.164 number to an AoR? I will try to give another example and start from within the scope of SPEERMINT (I hope this is the last iteration before the name gets too lomg ;-) I subscribe with provider B and get a default public user identity (AoR) from this provider: e.g. sip:foo@provB.net This "foo" can be anything the provider chooses it to be: e.g. an alphanumeric string such as ywzabcd, a numeric string such as 16241 (my FWD number) or 019793321 or 4319793321 Any other provider A having a peering agreement with Provider B must be able to route a SIP call given this SIP AoR to provider B, either to the SIP proxy hosting this account or at least to the ingress proxy(s) in provider B network. On way to do so is to use SRV records within the zone of provB.net pointing to e.g ingress14.provB.net and ingress21.provB.net Question: is this correct? Note: after the ingress proxy provider B may use another mapping mechanism to find the real hosting server e.g. srv21.provB.net Now I as a user are not happy with this default public user identity, I want to have some aliases eg: 1)sip:richard@stastny.com and 2) +43 1 9793321 In case 1) I assume that provider B needs to provide me with redirect server(s), and I need to enter in stastny.com SRV records to point to these redirect servers e.g. redirect.provB.net sip:richard.stastny.com is redirected to sip:foo@provB.net Question: is this correct? In case 2) we need Infrastructure ENUM [Side note; in my user ENUM I would either enter sip:richard@stastny.com or sip:foo@provB.net this is my choice] Now the question is: what goes into Infrastructure ENUM for say +4319793321? Is it: Sip:foo@provB.net (if plain sip:foo@provB.net works this must also work) OR sip:+4319793321@provB.net;user=3Dphone (correct?) OR sip:+4319793321@provB.net (wrong?) OR sip:4319793321@provB.net (valid only if 4319793321 =3D foo) OR is it sip:+4319793321@ingress14.provB.net;user=3Dphone (and the above = variants) AND sip:+4319793321@ingress21.provB.net;user=3Dphone In this last case one would not need to query the SRV records in provB.net I hope I did not confuse the issue even more Richard _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Dec 08 12:08:28 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 1EkPFs-00006b-Lt; Thu, 08 Dec 2005 12:08:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkPFh-0008VL-Rv; Thu, 08 Dec 2005 12:08:27 -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 MAA11643; Thu, 8 Dec 2005 12:07:16 -0500 (EST) 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 1EkPFX-00008y-VP; Thu, 08 Dec 2005 12:08:10 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 08 Dec 2005 09:07:57 -0800 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 jB8H7oQM017111; Thu, 8 Dec 2005 09:07:53 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 12:07:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Thu, 8 Dec 2005 12:07:47 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA0ADF@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Thread-Index: AcX6yySCxyyxZ86zQZWvC9QFGn/uPQAoDi3gAAbserAAH9g8AAABkrKgAAM2ItA= From: "Michael Hammer \(mhammer\)" To: , "James Polk \(jmpolk\)" , "Thilo Salmon" , "Klaus Darilion" X-OriginalArrivalTime: 08 Dec 2005 17:07:48.0455 (UTC) FILETIME=[EA42B770:01C5FC19] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 Would it be possible to leverage through reference to and adoption of = the work of that other group rather than repeat the time-consuming = (painful) process of defining terms in this group? Mike =20 > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com]=20 > Sent: Thursday, December 08, 2005 10:57 AM > To: Michael Hammer (mhammer); James Polk (jmpolk); 'Thilo=20 > Salmon'; 'Klaus Darilion' > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20 > 'Stastny Richard' > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM >=20 > Mike, >=20 > I agree. If you want to say "service provider", the term has=20 > to be defined (as you have just contributed) to include cable=20 > networks, IT departments, government organizations, community=20 > networks, family/home networks, etc.=20 >=20 > Without a definition there is ample room for different=20 > meanings, technically, legally and commercial. But should=20 > such a definition be done in this WG? >=20 > The technical meaning is _Internet domain_ in all cases. >=20 > Thanks, Henry >=20 > =20 >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, December 08, 2005 8:52 AM > To: henry@pulver.com; James Polk (jmpolk); Thilo Salmon;=20 > Klaus Darilion > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20 > Stastny Richard > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM >=20 > Henry, >=20 > An IT department of an enterprise that operates VoIP servers=20 > is a service provider, albeit a private versus a public one. =20 > Thus, I don't see the limit you speak of. >=20 > Adding an additional adjective "public" and you get a PATS or=20 > Carrier that has narrower connotations. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Henry Sinnreich [mailto:henry@pulver.com] > > Sent: Wednesday, December 07, 2005 7:10 PM > > To: Michael Hammer (mhammer); James Polk (jmpolk); 'Thilo Salmon';=20 > > 'Klaus Darilion' > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20 > 'Stastny=20 > > Richard' > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > >=20 > > The VoIP calls in our offices can go directly between the two=20 > > enterprise networks without any VoIP service providers=20 > being involved=20 > > and this is as valid VoIP peering as any other. This is one of the=20 > > reasons not to limit the VoIP peering models to only one, that with=20 > > VoIP service providers in the middle. > >=20 > > Sorry, I was not sure if the attached has taken this=20 > > enterprise-enterprise into consideration and obviously=20 > there are other=20 > > user scenarios as well. > >=20 > > Thanks, Henry > >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Wednesday, December 07, 2005 2:23 PM > > To: James Polk (jmpolk); henry@pulver.com; Thilo Salmon; Klaus=20 > > Darilion > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; Stastny=20 > > Richard > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > >=20 > > James, > >=20 > > This is d=E9j=E0 vu from the FG-NGN discussion on the exact=20 > same topic. I=20 > > have no issues with making distinctions of this type. It=20 > was just not=20 > > clear to me which of these various types (or the ones that Henry=20 > > mentions) was in scope or not, but that seemed secondary to=20 > the point=20 > > being made at the time that had to do with what the X=20 > entity did with=20 > > an ENUM response that affected the constraints on what could be=20 > > contained in such responses. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: James Polk (jmpolk) > > > Sent: Tuesday, December 06, 2005 8:11 PM > > > To: Michael Hammer (mhammer); henry@pulver.com; Thilo=20 > Salmon; Klaus=20 > > > Darilion > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20 > enum@ietf.org; Stastny=20 > > > Richard > > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > >=20 > > > Mike > > >=20 > > > This seems to be creeping into more than one WG at about the same=20 > > > time. > > >=20 > > > ISP used to be (roughly) the company you or you employer bought=20 > > > service from to gain access to the Internet. Now that is a > > little too > > > generic for a lot of people's tastes as there are different > > SPs that > > > an individual many have now that weren't available not so > > long ago. =20 > > > Hence the recent push to separate them somehow. > > >=20 > > > Application Providers, to me, include a Vonage for Voice > > services, and > > > a Yahoo for IM. > > >=20 > > > Service Providers or Internet Providers, to me, connect=20 > one to the=20 > > > Internet for L3 access > > >=20 > > > Access Providers, to me, are the organizations like the DSL > > and Cable > > > and WiFi connectivity providers. > > >=20 > > > Often times, to me, the Internet Providers and the Access=20 > Providers=20 > > > are either the same company - while perhaps different > > divisions, but > > > they can be totally different companies too. > > >=20 > > > The separation I'm seeing is between the organization that > > gives you > > > you Internet access and the organizations that provider you > > with all > > > the services required for a particular application - such > > as Voice or > > > Video. > > >=20 > > > Everything used to be best effort, and services were=20 > either at your=20 > > > device or at the provider's server. Now there's an overlay > > at layer 7 > > > (typically) and we're struggling with how to name and describe it. > > >=20 > > >=20 > > >=20 > > > At 06:23 PM 12/6/2005 -0500, Michael Hammer \(mhammer\) wrote: > > > >My looking glass is smudged today. > > > > > > > >What does one call a provider of service? > > > >I don't understand the aversion to service provider. > > > > > > > >I thought it was only the "carrier" word that invoked regulatory=20 > > > >burdens (or PATS!). I'd rather leave legal word games to > > > lawyers and lobbyists. > > > > > > > >Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Henry Sinnreich [mailto:henry@pulver.com] > > > > > Sent: Tuesday, December 06, 2005 5:30 PM > > > > > To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion' > > > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; > > > enum@ietf.org; 'Stastny > > > > > Richard' > > > > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, > > tel and ENUM > > > > > > > > > > Sorry for nitpicking: > > > > > > > > > > >A provider is a provider. > > > > > > > > > > A provider is a business model and att/SBC may differ > > from Google > > > > > who uses a different business model (which is more=20 > significant=20 > > > > > measured in $$$?). > > > > > > > > > > Didn't we agree to use the term "Internet domain owner"=20 > > (we could > > > > > shorten to IDOM or such)? > > > > > > > > > > Internet domains are well defined in the IETF. > > > > > Business models for VoIP are better suited for other > > > organizations, > > > > > consortia or innovators who work to disrupt them :-) > > > > > > > > > > Thanks, Henry > > > > > > > > > > -----Original Message----- > > > > > From: owner-voipeer@lists.uoregon.edu=20 > > > > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of > > > Michael Hammer > > > > > (mhammer) > > > > > Sent: Tuesday, December 06, 2005 3:36 PM > > > > > To: Thilo Salmon; Klaus Darilion > > > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; > > > enum@ietf.org; Stastny > > > > > Richard > > > > > Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > > > > > > > I am having trouble parsing these statements. > > > > > > > > > > A provider is a provider. I used the terms ingress and > > egress to > > > > > indicate some server that sits on the edge of a > > > provider's network > > > > > and does peering to some other provider. > > > > > The usage below seems to mix egress with originating=20 > being the=20 > > > > > network where the caller is attached. > > > > > > > > > > I was noting that the called party terminal and the > > interconnect > > > > > points were different hosts and therefore may have different=20 > > > > > identities. To keep maximum flexibility, the format of those=20 > > > > > identities would need to be fully under the control of > > > the domain of > > > > > each provider. However, conflating all that into a > > single URI in > > > > > the Request-URI seemed constraining to me. Having > > three URIs in > > > > > separate headers seemed the most flexible. > > > > > > > > > > Splitting. I don't understand what got split or how. ENUM > > > > > -- Tel:URI in, Point-of-interconnect URI out. Put in > > > Route header. =20 > > > > > I only suggested that there might be two route headers > > > because the > > > > > terminating provider would indicate in ENUM, to get to this=20 > > > > > end-user, go to this entrance first. > > > > > But, to get to that entrance, the originating=20 > provider needs to=20 > > > > > determine what the corresponding exit point is from his > > network, > > > > > i.e. another Route header. The format and content of > > > that URI is up > > > > > to each provider. The advertised entrance point is I=20 > think by=20 > > > > > definition the (Inter-) Carrier ENUM. > > > > > The internal determination of the exit point could be termed > > > > > (Intra-) Carrier ENUM. Maybe peering is concerned only > > with the > > > > > inter-carrier aspect. > > > > > > > > > > The Request-URI could be a normalized public identity > > of the user > > > > > totally independent of interconnect naming schemes. =20 > I was just=20 > > > > > teasing out what are the assumptions and constraints in > > > the original > > > > > email. > > > > > > > > > > Mike > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Thilo Salmon [mailto:salmon@sipgate.de] > > > > > > Sent: Tuesday, December 06, 2005 2:06 PM > > > > > > To: Klaus Darilion > > > > > > Cc: Michael Hammer (mhammer); sip@ietf.org; > > > > > voipeer@lists.uoregon.edu; > > > > > > enum@ietf.org; Stastny Richard > > > > > > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > > > > > > > > > Richard, Klaus, et al. > > > > > > > > > > > > Apparently, I have missed an important developlement lately. > > > > > > > > > > > > > What is the benefit of splitting the ENUM result (the SIP > > > > > > URI) into a > > > > > > > Route header and into a request URI? > > > > > > [...] > > > > > > > IMO there should be no semantic for the internal routing > > > > > > (the routing > > > > > > > from the main proxy to the egress proxy). This should be > > > > > > out of scope > > > > > > > of all WGs. Also the internal routing of the ingress > > > > > > provider should > > > > > > > be out of scope. The ingress provider should have SIP URI > > > > > > which can be > > > > > > > used to address its customers. > > > > > > > > > > > > I absolutely second that statement. If for any reason > > > (we all have > > > > > > enough a vivid enough phantasy to imagine a good reason, I > > > > > suppose) an > > > > > > ingress provider wishes to feed a different set of > > SIP URIs to > > > > > > each and every of his egress partners, he should not be > > > stripped > > > > > > of this option. > > > > > > The scenario I have in mind is one in which an > > ingress provider > > > > > > chooses to encrypt the user part of all his SIP URIs > > with a key > > > > > > uniquely assigns to his egress partner. > > > > > > > > > > > > Just as Klaus I feel this complicates things and takes > > > > > authority over > > > > > > internal adressing away from the ingress provider for > > no reason > > > > > > apparent (to me). > > > > > > > > > > > > Thilo > > > > > > > > > > > > > > > > ______________________________________________________________ > > > > > ______________ > > > > > _ > > > > > 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 > > >=20 > > >=20 > >=20 >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 06:32: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 1EkgUi-00056f-9g; Fri, 09 Dec 2005 06:32:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkgUe-00053w-Ol; Fri, 09 Dec 2005 06:32:52 -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 GAA20935; Fri, 9 Dec 2005 06:31:46 -0500 (EST) Received: from nat.labs.nic.at ([83.136.33.3] helo=whistler) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkgUb-0007ox-6g; Fri, 09 Dec 2005 06:32:51 -0500 Received: from klauspc.intern ([10.10.0.50]) by whistler with esmtp (Exim 3.36 #1 (Debian)) id 1EkgTz-0004CX-00; Fri, 09 Dec 2005 12:32:12 +0100 Message-ID: <43996B20.9040908@pernau.at> Date: Fri, 09 Dec 2005 12:31:44 +0100 From: Klaus Darilion User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try References: <32755D354E6B65498C3BD9FD496C7D462C46FD@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C46FD@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 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: > Klaus wrote: > >>If I would design the network for provB, I would use version 2 (without >>user=phone as the user are not limited to phones). > > You mean: > >>sip:+4319793321@provB.net;user=phone > > > IMHO this does not imply that the user uses a phone, > it implies that the user-part is a Tel URI ! Yes. This makes more sense. (I've never knowed what the user=phone parameter is really for). Thus, IMO the paramter is more interesting for the outgoing provider. If the proxy of provA receives a request from its customer for sip:+4312345@provA.com this would adress the lokal user +4312345. A request for sip:+4312345@provA.com;user=phone would address the E.164 phone number +4312345 Thanks for clarification, Klaus > > Richard > > > > ________________________________ > > Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Gesendet: Mi 07.12.2005 13:39 > An: Stastny Richard > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org > Betreff: Re: [Enum] SIP AoR, tel and ENUM - Second Try > > > > Hi Richard! > > comments inline > > Stastny Richard wrote: > >>Should Infrastructure ENUM contain a routing information >>to the next hop only (the ingress border element of Provider B >>(or administrative domain B) >>or simply a mapping from an E.164 number to an AoR? > > > IMHO it should be a mapping to an AoR as in user ENUM. > > >>I will try to give another example and start from > > ... > >>I subscribe with provider B and get a default public >>user identity (AoR) from this provider: >>e.g. sip:foo@provB.net >> >>This "foo" can be anything the provider chooses it to be: >>e.g. an alphanumeric string such as ywzabcd, >>a numeric string such as 16241 (my FWD number) >>or 019793321 or 4319793321 >> >>Any other provider A having a peering agreement >>with Provider B must be able to route a SIP call >>given this SIP AoR to provider B, either to the >>SIP proxy hosting this account or at least to >>the ingress proxy(s) in provider B network. >> >>On way to do so is to use SRV records within >>the zone of provB.net pointing to e.g >> >>ingress14.provB.net >>and >>ingress21.provB.net >> >>Question: is this correct? > > > IMO yes. Thus, A sends "INVITE sip:foo@provB.net" to ingress14.provB.net > > >>Note: after the ingress proxy provider B >>may use another mapping mechanism to find >>the real hosting server e.g. srv21.provB.net >> >>Now I as a user are not happy with this default >>public user identity, I want to have some aliases >> >>eg: >>1)sip:richard@stastny.com and >>2) +43 1 9793321 >> >>In case 1) I assume that provider B needs >>to provide me with redirect server(s), and I >>need to enter in stastny.com SRV records >>to point to these redirect servers >>e.g. redirect.provB.net >> >>sip:richard.stastny.com is redirected to >>sip:foo@provB.net >> >>Question: is this correct? > > > This is a working scenario. But a redirect server is not mandatory. It > may also be a proxy which forwards the request "INVITE > sip:richard.stastny.com" to "INVITE sip:foo@provB.net". > > It is also possbile that SRV for stastny.com points directly to > ingress12.provB.net and ingress12 knows about all hosted SIP domains and > knows how to forward the request to the end user. > > But this is a design decision of the provB and IMO should be out of > scope of SPEERMINT. provB may use redirect server, provC may accept all > hosted SIP domains directly on their ingress points, ..... > > I personally prefer relaying instead of redirect. E.g. redirect raises > questions like: How should intercept the redirect response and forward > to the new URI? The UA client or the SIP proxy of provA or the egress proxy? > > The important thing is that the originator (provA) should not have to > take care how provB implemented the hosting of SIP domains. > > >>In case 2) we need Infrastructure ENUM >>[Side note; in my user ENUM I would either enter >>sip:richard@stastny.com or sip:foo@provB.net >>this is my choice] >> >>Now the question is: what goes into Infrastructure >>ENUM for say +4319793321? >> >>Is it: >>Sip:foo@provB.net (if plain sip:foo@provB.net works >>this must also work) >>OR >>sip:+4319793321@provB.net;user=phone (correct?) >>OR >>sip:+4319793321@provB.net (wrong?) >>OR >>sip:4319793321@provB.net (valid only if 4319793321 = foo) >> >>OR is it >>sip:+4319793321@ingress14.provB.net;user=phone (and the above variants) >>AND >>sip:+4319793321@ingress21.provB.net;user=phone > > > IMO all of these are valid. It's up to the choice of provB. provB can > put anything into ENUM as long as provB is able to map from the URI in > I-ENUM to the end user. > > If I would design the network for provB, I would use version 2 (without > user=phone as the user are not limited to phones). > > >>In this last case one would not need to query the >>SRV records in provB.net > > > Also in the last case (if beeing conform with RFC3263), the egress proxy > has to perform NAPTR and SRV lookups. If you want to avoid them, just > put the IP address or the port into the host part, e.g. > > sip:+4319793321@ingress21.provB.net:5060;user=phone > > regards > klaus > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 06:41: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 1Ekgcm-0006IC-0F; Fri, 09 Dec 2005 06:41:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekgcj-0006Gf-NO; Fri, 09 Dec 2005 06:41:13 -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 GAA21680; Fri, 9 Dec 2005 06:40:11 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ekgcm-00082K-AP; Fri, 09 Dec 2005 06:41:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try Date: Fri, 9 Dec 2005 12:41:11 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc> Thread-Topic: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try Thread-Index: AcX8tLvugOQOUjqsTLG48DzXFpRL8wAALf62 From: "Stastny Richard" To: "Klaus Darilion" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 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 >Thus, IMO the paramter is more interesting for the outgoing provider. = If >the proxy of provA receives a request from its customer for > sip:+4312345@provA.com >this would adress the lokal user +4312345. A request for > sip:+4312345@provA.com;user=3Dphone >would address the E.164 phone number +4312345 Yesss, exactly ;-) And since you rarely have local users start with +, sip:4312345@provA.com is more usual and sip:+4312345@provA.com should not happen, causeing always confusion Richard ________________________________ Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Gesendet: Fr 09.12.2005 12:31 An: Stastny Richard Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org Betreff: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try Stastny Richard wrote: > Klaus wrote: > >>If I would design the network for provB, I would use version 2 = (without >>user=3Dphone as the user are not limited to phones). > > You mean: > >>sip:+4319793321@provB.net;user=3Dphone > >=20 > IMHO this does not imply that the user uses a phone, > it implies that the user-part is a Tel URI ! Yes. This makes more sense. (I've never knowed what the user=3Dphone parameter is really for). Thus, IMO the paramter is more interesting for the outgoing provider. If the proxy of provA receives a request from its customer for sip:+4312345@provA.com this would adress the lokal user +4312345. A request for sip:+4312345@provA.com;user=3Dphone would address the E.164 phone number +4312345 Thanks for clarification, Klaus >=20 > Richard > > > > ________________________________ > > Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Gesendet: Mi 07.12.2005 13:39 > An: Stastny Richard > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org > Betreff: Re: [Enum] SIP AoR, tel and ENUM - Second Try > > > > Hi Richard! > > comments inline > > Stastny Richard wrote: > >>Should Infrastructure ENUM contain a routing information >>to the next hop only (the ingress border element of Provider B >>(or administrative domain B) >>or simply a mapping from an E.164 number to an AoR? > > > IMHO it should be a mapping to an AoR as in user ENUM. > > >>I will try to give another example and start from > > ... > >>I subscribe with provider B and get a default public >>user identity (AoR) from this provider: >>e.g. sip:foo@provB.net >> >>This "foo" can be anything the provider chooses it to be: >>e.g. an alphanumeric string such as ywzabcd, >>a numeric string such as 16241 (my FWD number) >>or 019793321 or 4319793321 >> >>Any other provider A having a peering agreement >>with Provider B must be able to route a SIP call >>given this SIP AoR to provider B, either to the >>SIP proxy hosting this account or at least to >>the ingress proxy(s) in provider B network. >> >>On way to do so is to use SRV records within >>the zone of provB.net pointing to e.g >> >>ingress14.provB.net >>and >>ingress21.provB.net >> >>Question: is this correct? > > > IMO yes. Thus, A sends "INVITE sip:foo@provB.net" to = ingress14.provB.net > > >>Note: after the ingress proxy provider B >>may use another mapping mechanism to find >>the real hosting server e.g. srv21.provB.net >> >>Now I as a user are not happy with this default >>public user identity, I want to have some aliases >> >>eg: >>1)sip:richard@stastny.com and >>2) +43 1 9793321 >> >>In case 1) I assume that provider B needs >>to provide me with redirect server(s), and I >>need to enter in stastny.com SRV records >>to point to these redirect servers >>e.g. redirect.provB.net >> >>sip:richard.stastny.com is redirected to >>sip:foo@provB.net >> >>Question: is this correct? > > > This is a working scenario. But a redirect server is not mandatory. It > may also be a proxy which forwards the request "INVITE > sip:richard.stastny.com" to "INVITE sip:foo@provB.net". > > It is also possbile that SRV for stastny.com points directly to > ingress12.provB.net and ingress12 knows about all hosted SIP domains = and > knows how to forward the request to the end user. > > But this is a design decision of the provB and IMO should be out of > scope of SPEERMINT. provB may use redirect server, provC may accept = all > hosted SIP domains directly on their ingress points, ..... > > I personally prefer relaying instead of redirect. E.g. redirect raises > questions like: How should intercept the redirect response and forward > to the new URI? The UA client or the SIP proxy of provA or the egress = proxy? > > The important thing is that the originator (provA) should not have to > take care how provB implemented the hosting of SIP domains. > > >>In case 2) we need Infrastructure ENUM >>[Side note; in my user ENUM I would either enter >>sip:richard@stastny.com or sip:foo@provB.net >>this is my choice] >> >>Now the question is: what goes into Infrastructure >>ENUM for say +4319793321? >> >>Is it: >>Sip:foo@provB.net (if plain sip:foo@provB.net works >>this must also work) >>OR >>sip:+4319793321@provB.net;user=3Dphone (correct?) >>OR >>sip:+4319793321@provB.net (wrong?) >>OR >>sip:4319793321@provB.net (valid only if 4319793321 =3D foo) >> >>OR is it >>sip:+4319793321@ingress14.provB.net;user=3Dphone (and the above = variants) >>AND >>sip:+4319793321@ingress21.provB.net;user=3Dphone > > > IMO all of these are valid. It's up to the choice of provB. provB can > put anything into ENUM as long as provB is able to map from the URI in > I-ENUM to the end user. > > If I would design the network for provB, I would use version 2 = (without > user=3Dphone as the user are not limited to phones). > > >>In this last case one would not need to query the >>SRV records in provB.net > > > Also in the last case (if beeing conform with RFC3263), the egress = proxy > has to perform NAPTR and SRV lookups. If you want to avoid them, just > put the IP address or the port into the host part, e.g. > > sip:+4319793321@ingress21.provB.net:5060;user=3Dphone > > regards > klaus > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 06:53:32 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 1Ekgoe-00028V-8l; Fri, 09 Dec 2005 06:53:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekgob-00027g-18; Fri, 09 Dec 2005 06:53:29 -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 GAA23030; Fri, 9 Dec 2005 06:52:26 -0500 (EST) Received: from nat.labs.nic.at ([83.136.33.3] helo=whistler) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekgod-0008UW-V8; Fri, 09 Dec 2005 06:53:32 -0500 Received: from klauspc.intern ([10.10.0.50]) by whistler with esmtp (Exim 3.36 #1 (Debian)) id 1EkgoO-0004Ci-00; Fri, 09 Dec 2005 12:53:16 +0100 Message-ID: <43997011.7000805@pernau.at> Date: Fri, 09 Dec 2005 12:52:49 +0100 From: Klaus Darilion User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try References: <32755D354E6B65498C3BD9FD496C7D462C46FC@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C46FC@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 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: > Thanx Klaus > > Also for answering a question I did not (yet) ask > regarding redirect vs proxy > > > >>I personally prefer relaying instead of redirect. > > > Me too and I see your arguments. > Are there any arguments out there why to prefer redriect? I just made some signaling pictures to visualize the difference: From the signaling, there is no big difference. Both versions do need approximately the same amount of signaling packets sent (depends onthe actual SIP network design). I do not see any technical reason why to prefer one version over the other. It's just a personal preference. regards klaus UAC proxyA borderProxyA redirectProxy borderProxyB proxyB UAS | | | | | | | |-INVITE>| | | | | | |<-100---|-INVITE-->| | | | | | |<--100----|-------INVITE---->| | | | | | | | | | | | | |<------302--------| | | | | |<-302-----|-------ACK------->| | | | | |--ACK---->| | | | | | |--INVITE->| | | | | | |<-100-----|--------------INVITE----------->| | | | | |<--------------100--------------|-INVITE>| | | | | | |<-100---|-INVITE>| | | | | | |<-100---| | | | | | | | | | | | | |<-180---| | | | | |<--180--| | | | |<---------------180-------------| | | | |<--180----| | | | | |<--180--| | | | |<--200--| | | | | |<--200--| | | | |<---------------200-------------| | | | |<---200---| | | | | |<---200-| | | | | | | | | | | | | |--ACK-->| | | | | | | |----ACK-->| | | | | | | |--------------ACK-------------->| | | | | | | |--ACK-->| | | | | | | |--ACK-->| | | | | | | | | | | | | | | | | | | | | | 32 Packets UAC proxyA borderProxyA forwardProxy borderProxyB proxyB UAS | | | | | | | |-INVITE>| | | | | | |<-100---|-INVITE-->| | | | | | |<--100----|-------INVITE---->| | | | | | |<-------100-------|---INVITE--->| | | | | | |<----100-----|-INVITE>| | | | | | |<-100---|-INVITE>| | | | | | |<-100---| | | | | | | | | | | | | |<-180---| | | | | |<--180--| | | | | |<---180------| | | | | |<----- -180-------| | | | | |<--180----| | | | | |<--180--| | | | |<--200--| | | | | |<--200--| | | | | |<---200------| | | | | |<-------200-------| | | | | |<---200---| | | | | |<---200-| | | | | | | | | | | | | |--ACK-->| | | | | | | |----ACK-->| | | | | | | |--------------ACK-------------->| | | | | | | |--ACK-->| | | | | | | |--ACK-->| 29 Packets _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 07:15:08 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 1Ekh9Y-0000AY-1S; Fri, 09 Dec 2005 07:15:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekh9T-00007L-6W; Fri, 09 Dec 2005 07:15:05 -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 HAA25218; Fri, 9 Dec 2005 07:14:00 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ekh9W-0000jf-2I; Fri, 09 Dec 2005 07:15:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try Date: Fri, 9 Dec 2005 13:17:27 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C470E@oefeg-s04.oefeg.loc> Thread-Topic: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try Thread-Index: AcX8t62w821JMsoqQGCdm3aV0mJTAAAAtcKN From: "Stastny Richard" To: "Klaus Darilion" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 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 Thanx Klaus for the work ;-) Now the next question: What are the implications proxy vs redirect if you are using TLS? =20 Richard ________________________________ Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Gesendet: Fr 09.12.2005 12:52 An: Stastny Richard Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try Stastny Richard wrote: > Thanx Klaus > > Also for answering a question I did not (yet) ask > regarding redirect vs proxy > > > >>I personally prefer relaying instead of redirect. > > > Me too and I see your arguments. > Are there any arguments out there why to prefer redriect? I just made some signaling pictures to visualize the difference: From the signaling, there is no big difference. Both versions do need approximately the same amount of signaling packets sent (depends onthe actual SIP network design). I do not see any technical reason why to prefer one version over the other. It's just a personal preference. regards klaus UAC proxyA borderProxyA redirectProxy borderProxyB proxyB UAS | | | | | | | |-INVITE>| | | | | | |<-100---|-INVITE-->| | | | | | |<--100----|-------INVITE---->| | | | | | | | | | | | | |<------302--------| | | | | |<-302-----|-------ACK------->| | | | | |--ACK---->| | | | | | |--INVITE->| | | | | | |<-100-----|--------------INVITE----------->| | | | | |<--------------100--------------|-INVITE>| | | | | | |<-100---|-INVITE>| | | | | | |<-100---| | | | | | | | | | | | | |<-180---| | | | | |<--180--| | | | |<---------------180-------------| | | | |<--180----| | | | | |<--180--| | | | |<--200--| | | | | |<--200--| | | | |<---------------200-------------| | | | |<---200---| | | | | |<---200-| | | | | | | | | | | | | |--ACK-->| | | | | | | |----ACK-->| | | | | | | |--------------ACK-------------->| | | | | | | |--ACK-->| | | | | | | |--ACK-->| | | | | | | | | | | | | | | | | | | | | | 32 Packets UAC proxyA borderProxyA forwardProxy borderProxyB proxyB UAS | | | | | | | |-INVITE>| | | | | | |<-100---|-INVITE-->| | | | | | |<--100----|-------INVITE---->| | | | | | |<-------100-------|---INVITE--->| | | | | | |<----100-----|-INVITE>| | | | | | |<-100---|-INVITE>| | | | | | |<-100---| | | | | | | | | | | | | |<-180---| | | | | |<--180--| | | | | |<---180------| | | | | |<----- -180-------| | | | | |<--180----| | | | | |<--180--| | | | |<--200--| | | | | |<--200--| | | | | |<---200------| | | | | |<-------200-------| | | | | |<---200---| | | | | |<---200-| | | | | | | | | | | | | |--ACK-->| | | | | | | |----ACK-->| | | | | | | |--------------ACK-------------->| | | | | | | |--ACK-->| | | | | | | |--ACK-->| 29 Packets _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 07:42:10 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 1EkhZi-0006nd-68; Fri, 09 Dec 2005 07:42:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkhZS-0006m6-F5; Fri, 09 Dec 2005 07:42:07 -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 HAA27799; Fri, 9 Dec 2005 07:40:48 -0500 (EST) Received: from nat.labs.nic.at ([83.136.33.3] helo=whistler) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkhZS-0001XS-Jw; Fri, 09 Dec 2005 07:41:55 -0500 Received: from klauspc.intern ([10.10.0.50]) by whistler with esmtp (Exim 3.36 #1 (Debian)) id 1EkhYv-0004F2-00; Fri, 09 Dec 2005 13:41:21 +0100 Message-ID: <43997B56.1000208@pernau.at> Date: Fri, 09 Dec 2005 13:40:54 +0100 From: Klaus Darilion User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try References: <32755D354E6B65498C3BD9FD496C7D462C470E@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C470E@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 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: > Thanx Klaus > > for the work ;-) > > Now the next question: > What are the implications proxy vs redirect > if you are using TLS? Now it's getting complicated ;-) With the redirect server, there will be 2 TLS handshakes: 1. borderProxyA redirectProxy 2. borderProxyA borderProxyB With the forwarding proxy, one TLS connection is mandatory: 1. borderProxyA forwardingProxy If the forwardin proxy is within the network of provB, there is no need to use TLS inside the network of prov if other means can be used to authetnicate (e.g. src_IP). But, if the forwarding proxy stays of of signaling for in-dialog messages, there is also a must for the second TLS conenction between 2. borderProxyA borderProxyB The more complicated thing is the certificate validation. RFC 3263 mandates, that the SIP domain (before NAPTR, SRV lookups) must be identical to the domain in the certificate. If provB hosts thousands of SIP domains for its clients, e.g. sip:fobar@stastny.com, sip:foobar@darilion.com, .... and requires TLS for incoming connections, provB must present a valid certificate for all hosted domains. Thus, you have to give your private key for stastny.com to you SIP provider. Furthermore, plain TLS requires the server to send the certificate without any knowledge of which domain the UAC is trying to contact. Thus, provB needs a dedicated socket for each hosted domain on its border proxy to differ the requests and present the proper certificate. IMO that does not scale. It can be avoided using the "server_name" TLS extension, but this is e.g. not supported in openssl which is used most for proxy servers. This could be also solved by changing RFC 3263 to validate the certificate against the domain name revealed after SRV lookups. This was forbidden to detect DNS spoofing, but IMO DNS problems should be fixed in DNS, not in SIP. regards klaus > > Richard > > ________________________________ > > Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Gesendet: Fr 09.12.2005 12:52 > An: Stastny Richard > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org > Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try > > > > Stastny Richard wrote: > >>Thanx Klaus >> >>Also for answering a question I did not (yet) ask >>regarding redirect vs proxy >> >> >> >> >>>I personally prefer relaying instead of redirect. >> >> >>Me too and I see your arguments. >>Are there any arguments out there why to prefer redriect? > > > I just made some signaling pictures to visualize the difference: > From the signaling, there is no big difference. Both versions do need > approximately the same amount of signaling packets sent (depends onthe > actual SIP network design). > > I do not see any technical reason why to prefer one version over the > other. It's just a personal preference. > > regards > klaus > > > UAC proxyA borderProxyA redirectProxy borderProxyB proxyB UAS > | | | | | | | > |-INVITE>| | | | | | > |<-100---|-INVITE-->| | | | | > | |<--100----|-------INVITE---->| | | | > | | | | | | | > | | |<------302--------| | | | > | |<-302-----|-------ACK------->| | | | > | |--ACK---->| | | | | > | |--INVITE->| | | | | > | |<-100-----|--------------INVITE----------->| | | > | | |<--------------100--------------|-INVITE>| | > | | | | |<-100---|-INVITE>| > | | | | | |<-100---| > | | | | | | | > | | | | | |<-180---| > | | | | |<--180--| | > | | |<---------------180-------------| | | > | |<--180----| | | | | > |<--180--| | | | |<--200--| > | | | | |<--200--| | > | | |<---------------200-------------| | | > | |<---200---| | | | | > |<---200-| | | | | | > | | | | | | | > |--ACK-->| | | | | | > | |----ACK-->| | | | | > | | |--------------ACK-------------->| | | > | | | | |--ACK-->| | > | | | | | |--ACK-->| > | | | | | | | > | | | | | | | > | | | | | | | > > 32 Packets > > > UAC proxyA borderProxyA forwardProxy borderProxyB proxyB UAS > | | | | | | | > |-INVITE>| | | | | | > |<-100---|-INVITE-->| | | | | > | |<--100----|-------INVITE---->| | | | > | | |<-------100-------|---INVITE--->| | | > | | | |<----100-----|-INVITE>| | > | | | | |<-100---|-INVITE>| > | | | | | |<-100---| > | | | | | | | > | | | | | |<-180---| > | | | | |<--180--| | > | | | |<---180------| | | > | | |<----- -180-------| | | | > | |<--180----| | | | | > |<--180--| | | | |<--200--| > | | | | |<--200--| | > | | | |<---200------| | | > | | |<-------200-------| | | | > | |<---200---| | | | | > |<---200-| | | | | | > | | | | | | | > |--ACK-->| | | | | | > | |----ACK-->| | | | | > | | |--------------ACK-------------->| | | > | | | | |--ACK-->| | > | | | | | |--ACK-->| > > 29 Packets > > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 09:28:50 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 1EkjEw-0005Am-Bj; Fri, 09 Dec 2005 09:28:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkjEt-00059l-OF; Fri, 09 Dec 2005 09:28:47 -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 JAA10783; Fri, 9 Dec 2005 09:27:54 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EkjF6-0005Uc-00; Fri, 09 Dec 2005 09:29:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try Date: Fri, 9 Dec 2005 15:28:59 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4712@oefeg-s04.oefeg.loc> Thread-Topic: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try Thread-Index: AcX8vmW1+WGge9X1TxeEkgJLJ9ThNgADn8Gt From: "Stastny Richard" To: "Klaus Darilion" X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 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 Now my next question: =20 Is the problem Klaus described below a problem to be sovled within the SPEERMINT problem (scope) space? =20 "The more complicated thing is the certificate validation. RFC 3263 mandates, that the SIP domain (before NAPTR, SRV lookups) must be identical to the domain in the certificate. If provB hosts thousands of SIP domains for its clients, e.g. sip:fobar@stastny.com, sip:foobar@darilion.com, .... and requires TLS for incoming connections, provB must present a valid certificate for all hosted domains. Thus, you have to give your private key for stastny.com to you SIP provider. Furthermore, plain TLS requires the server to send the certificate without any knowledge of which domain the UAC is trying to contact. Thus, provB needs a dedicated socket for each hosted domain on its border proxy to differ the requests and present the proper certificate. IMO that does not scale. It can be avoided using the "server_name" TLS extension, but this is e.g. not supported in openssl which is used most for proxy servers. This could be also solved by changing RFC 3263 to validate the certificate against the domain name revealed after SRV lookups. This was forbidden to detect DNS spoofing, but IMO DNS problems should be fixed in DNS, not in SIP." Richard ________________________________ Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Gesendet: Fr 09.12.2005 13:40 An: Stastny Richard Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try Stastny Richard wrote: > Thanx Klaus > > for the work ;-) > > Now the next question: > What are the implications proxy vs redirect > if you are using TLS? Now it's getting complicated ;-) With the redirect server, there will be 2 TLS handshakes: 1. borderProxyA redirectProxy 2. borderProxyA borderProxyB With the forwarding proxy, one TLS connection is mandatory: 1. borderProxyA forwardingProxy If the forwardin proxy is within the network of provB, there is no need to use TLS inside the network of prov if other means can be used to authetnicate (e.g. src_IP). But, if the forwarding proxy stays of of signaling for in-dialog messages, there is also a must for the second TLS conenction between 2. borderProxyA borderProxyB The more complicated thing is the certificate validation. RFC 3263 mandates, that the SIP domain (before NAPTR, SRV lookups) must be identical to the domain in the certificate. If provB hosts thousands of SIP domains for its clients, e.g. sip:fobar@stastny.com, sip:foobar@darilion.com, .... and requires TLS for incoming connections, provB must present a valid certificate for all hosted domains. Thus, you have to give your private key for stastny.com to you SIP provider. Furthermore, plain TLS requires the server to send the certificate without any knowledge of which domain the UAC is trying to contact. Thus, provB needs a dedicated socket for each hosted domain on its border proxy to differ the requests and present the proper certificate. IMO that does not scale. It can be avoided using the "server_name" TLS extension, but this is e.g. not supported in openssl which is used most for proxy servers. This could be also solved by changing RFC 3263 to validate the certificate against the domain name revealed after SRV lookups. This was forbidden to detect DNS spoofing, but IMO DNS problems should be fixed in DNS, not in SIP. regards klaus >=20 > Richard > > ________________________________ > > Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Gesendet: Fr 09.12.2005 12:52 > An: Stastny Richard > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org > Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try > > > > Stastny Richard wrote: > >>Thanx Klaus >> >>Also for answering a question I did not (yet) ask >>regarding redirect vs proxy >> >> >> >> >>>I personally prefer relaying instead of redirect. >> >> >>Me too and I see your arguments. >>Are there any arguments out there why to prefer redriect? > > > I just made some signaling pictures to visualize the difference: > From the signaling, there is no big difference. Both versions do need > approximately the same amount of signaling packets sent (depends onthe > actual SIP network design). > > I do not see any technical reason why to prefer one version over the > other. It's just a personal preference. > > regards > klaus > > > UAC proxyA borderProxyA redirectProxy borderProxyB proxyB = UAS > | | | | | | | > |-INVITE>| | | | | = | > |<-100---|-INVITE-->| | | | = | > | |<--100----|-------INVITE---->| | | = | > | | | | | | = | > | | |<------302--------| | | = | > | |<-302-----|-------ACK------->| | | = | > | |--ACK---->| | | | = | > | |--INVITE->| | | | = | > | |<-100-----|--------------INVITE----------->| | = | > | | |<--------------100--------------|-INVITE>| = | > | | | | = |<-100---|-INVITE>| > | | | | | = |<-100---| > | | | | | | = | > | | | | | = |<-180---| > | | | | |<--180--| = | > | | |<---------------180-------------| | = | > | |<--180----| | | | = | > |<--180--| | | | = |<--200--| > | | | | |<--200--| = | > | | |<---------------200-------------| | = | > | |<---200---| | | | = | > |<---200-| | | | | = | > | | | | | | = | > |--ACK-->| | | | | = | > | |----ACK-->| | | | = | > | | |--------------ACK-------------->| | = | > | | | | |--ACK-->| = | > | | | | | = |--ACK-->| > | | | | | | = | > | | | | | | = | > | | | | | | = | > > 32 Packets > > > UAC proxyA borderProxyA forwardProxy borderProxyB proxyB = UAS > | | | | | | = | > |-INVITE>| | | | | = | > |<-100---|-INVITE-->| | | | = | > | |<--100----|-------INVITE---->| | | = | > | | |<-------100-------|---INVITE--->| | = | > | | | |<----100-----|-INVITE>| = | > | | | | = |<-100---|-INVITE>| > | | | | | = |<-100---| > | | | | | | = | > | | | | | = |<-180---| > | | | | |<--180--| = | > | | | |<---180------| | = | > | | |<----- -180-------| | | = | > | |<--180----| | | | = | > |<--180--| | | | = |<--200--| > | | | | |<--200--| = | > | | | |<---200------| | = | > | | |<-------200-------| | | = | > | |<---200---| | | | = | > |<---200-| | | | | = | > | | | | | | = | > |--ACK-->| | | | | = | > | |----ACK-->| | | | = | > | | |--------------ACK-------------->| | = | > | | | | |--ACK-->| = | > | | | | | = |--ACK-->| > > 29 Packets > > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 09:35:45 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 1EkjLd-0008Kc-09; Fri, 09 Dec 2005 09:35:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkjLY-0008Gh-UN; Fri, 09 Dec 2005 09:35:41 -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 JAA12095; Fri, 9 Dec 2005 09:34:47 -0500 (EST) Received: from nat.labs.nic.at ([83.136.33.3] helo=whistler) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkjLi-0005kq-6m; Fri, 09 Dec 2005 09:35:53 -0500 Received: from klauspc.intern ([10.10.0.50]) by whistler with esmtp (Exim 3.36 #1 (Debian)) id 1EkjL8-0004GR-00; Fri, 09 Dec 2005 15:35:14 +0100 Message-ID: <43999607.7060900@pernau.at> Date: Fri, 09 Dec 2005 15:34:47 +0100 From: Klaus Darilion User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc> <43998FD7.20207@cisco.com> In-Reply-To: <43998FD7.20207@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 Paul! Thanks for clarification. I always had problem to understand the proper meaning of this parameter. Is this somewhere described in detail? I also rememeber a discussion to remove this parameter completly. regards klaus Paul Kyzivat wrote: > > > Stastny Richard wrote: > >>> Thus, IMO the paramter is more interesting for the outgoing provider. If >>> the proxy of provA receives a request from its customer for >>> sip:+4312345@provA.com >>> this would adress the lokal user +4312345. A request for >>> sip:+4312345@provA.com;user=phone >>> would address the E.164 phone number +4312345 >> >> >> >> Yesss, exactly ;-) >> >> And since you rarely have local users start with +, >> sip:4312345@provA.com is more usual >> >> and >> sip:+4312345@provA.com >> should not happen, causeing always confusion > > > It seems that many people intend to use a namespace for usernames where > there is no overlap of names and numbers: there is no possibility for a > *name* +4312345 that has a different meaning than the E.164 number > +4312345. In that case the presence or absence of the ";user=phone" is > irrelevant as far as its meaning within the owning domain. In that case > the ";user=phone" is more a matter of informing the world that this is > intended to be a phone number. > > Also, as it happens, while > sip:+4312345@provA.com > sip:+4312345@provA.com;user=phone > are not equal by uri comparison rules, they are equal according to the > rules that 3261 applies to the targets of registration. So, you can't > really have them mean different things. > > Paul > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 09:40: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 1EkjQZ-0001na-G5; Fri, 09 Dec 2005 09:40:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkjQV-0001fm-LW; Fri, 09 Dec 2005 09:40:47 -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 JAA12780; Fri, 9 Dec 2005 09:39:49 -0500 (EST) Received: from nat.labs.nic.at ([83.136.33.3] helo=whistler) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkjQc-0005yL-Qx; Fri, 09 Dec 2005 09:40:55 -0500 Received: from klauspc.intern ([10.10.0.50]) by whistler with esmtp (Exim 3.36 #1 (Debian)) id 1EkjQL-0004Gb-00; Fri, 09 Dec 2005 15:40:37 +0100 Message-ID: <4399974A.30104@pernau.at> Date: Fri, 09 Dec 2005 15:40:10 +0100 From: Klaus Darilion User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try References: <32755D354E6B65498C3BD9FD496C7D462C4712@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4712@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 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: > Now my next question: > > Is the problem Klaus described below a problem to be sovled within > the SPEERMINT problem (scope) space? IMHO yes, as long as the SIP WGs do not provide a solution which fit real life scenarios. klaus > "The more complicated thing is the certificate validation. RFC 3263 > mandates, that the SIP domain (before NAPTR, SRV lookups) must be > identical to the domain in the certificate. If provB hosts thousands of > SIP domains for its clients, e.g. sip:fobar@stastny.com, > sip:foobar@darilion.com, .... and requires TLS for incoming connections, > provB must present a valid certificate for all hosted domains. Thus, you > have to give your private key for stastny.com to you SIP provider. > Furthermore, plain TLS requires the server to send the certificate > without any knowledge of which domain the UAC is trying to contact. > Thus, provB needs a dedicated socket for each hosted domain on its > border proxy to differ the requests and present the proper certificate. > IMO that does not scale. It can be avoided using the "server_name" TLS > extension, but this is e.g. not supported in openssl which is used most > for proxy servers. > > This could be also solved by changing RFC 3263 to validate the > certificate against the domain name revealed after SRV lookups. This was > forbidden to detect DNS spoofing, but IMO DNS problems should be fixed > in DNS, not in SIP." > > Richard > > > > ________________________________ > > Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Gesendet: Fr 09.12.2005 13:40 > An: Stastny Richard > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org > Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try > > > > Stastny Richard wrote: > >>Thanx Klaus >> >>for the work ;-) >> >>Now the next question: >>What are the implications proxy vs redirect >>if you are using TLS? > > > Now it's getting complicated ;-) > > With the redirect server, there will be 2 TLS handshakes: > 1. borderProxyA redirectProxy > 2. borderProxyA borderProxyB > > With the forwarding proxy, one TLS connection is mandatory: > 1. borderProxyA forwardingProxy > > If the forwardin proxy is within the network of provB, there is no need > to use TLS inside the network of prov if other means can be used to > authetnicate (e.g. src_IP). But, if the forwarding proxy stays of of > signaling for in-dialog messages, there is also a must for the second > TLS conenction between > 2. borderProxyA borderProxyB > > The more complicated thing is the certificate validation. RFC 3263 > mandates, that the SIP domain (before NAPTR, SRV lookups) must be > identical to the domain in the certificate. If provB hosts thousands of > SIP domains for its clients, e.g. sip:fobar@stastny.com, > sip:foobar@darilion.com, .... and requires TLS for incoming connections, > provB must present a valid certificate for all hosted domains. Thus, you > have to give your private key for stastny.com to you SIP provider. > Furthermore, plain TLS requires the server to send the certificate > without any knowledge of which domain the UAC is trying to contact. > Thus, provB needs a dedicated socket for each hosted domain on its > border proxy to differ the requests and present the proper certificate. > IMO that does not scale. It can be avoided using the "server_name" TLS > extension, but this is e.g. not supported in openssl which is used most > for proxy servers. > > This could be also solved by changing RFC 3263 to validate the > certificate against the domain name revealed after SRV lookups. This was > forbidden to detect DNS spoofing, but IMO DNS problems should be fixed > in DNS, not in SIP. > > regards > klaus > > >>Richard >> >>________________________________ >> >>Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >>Gesendet: Fr 09.12.2005 12:52 >>An: Stastny Richard >>Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org >>Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try >> >> >> >>Stastny Richard wrote: >> >> >>>Thanx Klaus >>> >>>Also for answering a question I did not (yet) ask >>>regarding redirect vs proxy >>> >>> >>> >>> >>> >>>>I personally prefer relaying instead of redirect. >>> >>> >>>Me too and I see your arguments. >>>Are there any arguments out there why to prefer redriect? >> >> >>I just made some signaling pictures to visualize the difference: >> From the signaling, there is no big difference. Both versions do need >>approximately the same amount of signaling packets sent (depends onthe >>actual SIP network design). >> >>I do not see any technical reason why to prefer one version over the >>other. It's just a personal preference. >> >>regards >>klaus >> >> >>UAC proxyA borderProxyA redirectProxy borderProxyB proxyB UAS >>| | | | | | | >>|-INVITE>| | | | | | >>|<-100---|-INVITE-->| | | | | >>| |<--100----|-------INVITE---->| | | | >>| | | | | | | >>| | |<------302--------| | | | >>| |<-302-----|-------ACK------->| | | | >>| |--ACK---->| | | | | >>| |--INVITE->| | | | | >>| |<-100-----|--------------INVITE----------->| | | >>| | |<--------------100--------------|-INVITE>| | >>| | | | |<-100---|-INVITE>| >>| | | | | |<-100---| >>| | | | | | | >>| | | | | |<-180---| >>| | | | |<--180--| | >>| | |<---------------180-------------| | | >>| |<--180----| | | | | >>|<--180--| | | | |<--200--| >>| | | | |<--200--| | >>| | |<---------------200-------------| | | >>| |<---200---| | | | | >>|<---200-| | | | | | >>| | | | | | | >>|--ACK-->| | | | | | >>| |----ACK-->| | | | | >>| | |--------------ACK-------------->| | | >>| | | | |--ACK-->| | >>| | | | | |--ACK-->| >>| | | | | | | >>| | | | | | | >>| | | | | | | >> >>32 Packets >> >> >>UAC proxyA borderProxyA forwardProxy borderProxyB proxyB UAS >>| | | | | | | >>|-INVITE>| | | | | | >>|<-100---|-INVITE-->| | | | | >>| |<--100----|-------INVITE---->| | | | >>| | |<-------100-------|---INVITE--->| | | >>| | | |<----100-----|-INVITE>| | >>| | | | |<-100---|-INVITE>| >>| | | | | |<-100---| >>| | | | | | | >>| | | | | |<-180---| >>| | | | |<--180--| | >>| | | |<---180------| | | >>| | |<----- -180-------| | | | >>| |<--180----| | | | | >>|<--180--| | | | |<--200--| >>| | | | |<--200--| | >>| | | |<---200------| | | >>| | |<-------200-------| | | | >>| |<---200---| | | | | >>|<---200-| | | | | | >>| | | | | | | >>|--ACK-->| | | | | | >>| |----ACK-->| | | | | >>| | |--------------ACK-------------->| | | >>| | | | |--ACK-->| | >>| | | | | |--ACK-->| >> >>29 Packets >> >> >> >> > > > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 11:13:15 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 1Ekkrz-0006Yd-LC; Fri, 09 Dec 2005 11:13:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekkry-0006Xu-Ml for enum@megatron.ietf.org; Fri, 09 Dec 2005 11:13: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 LAA24813 for ; Fri, 9 Dec 2005 11:12:12 -0500 (EST) Received: from bay103-f21.bay103.hotmail.com ([65.54.174.31] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekks3-0000yk-DW for enum@ietf.org; Fri, 09 Dec 2005 11:13:20 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 9 Dec 2005 08:12:55 -0800 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Fri, 09 Dec 2005 16:12:54 GMT X-Originating-IP: [64.119.36.136] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <4399974A.30104@pernau.at> From: "Peter Williams" Cc: enum@ietf.org Subject: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try Date: Fri, 09 Dec 2005 08:12:54 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 09 Dec 2005 16:12:55.0465 (UTC) FILETIME=[69E61190:01C5FCDB] X-Spam-Score: 0.8 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 X-BeenThere: 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: Klaus Darilion >To: Stastny Richard >CC: sip@ietf.org, voipeer@lists.uoregon.edu, enum@ietf.org >Subject: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try >Date: Fri, 09 Dec 2005 15:40:10 +0100 > >>"The more complicated thing is the certificate validation. RFC 3263 >>mandates, that the SIP domain (before NAPTR, SRV lookups) must be >>identical to the domain in the certificate. If provB hosts thousands of >>SIP domains for its clients, e.g. sip:fobar@stastny.com, >>sip:foobar@darilion.com, .... and requires TLS for incoming connections, >>provB must present a valid certificate for all hosted domains. ok. so we are in the same situation as were the website hosters of 1000 sites in 1995, who selected the certificate to idendity the TLS responder based on the HTTP-level header created by the initiator (versus initiator TCP/ICMP info determined from the server-side socket). >>Thus, you >>have to give your private key for stastny.com to you SIP provider. Well...the responder must deliver a cert with value "cn=*.stastny.com", and it must have a private key the corresponds to the embedded public key. However, these two assertions are not linked, beyond the AND. TLS for HTTP hosting (which is analagous to TLS for SIP 'user hosting'") does NOT impose any obligtation to deliver any particular private keys around. Another solution is that the hosting site hoster issues suitable certs, for those "sites/ENUMusers that it webhosts/siphosts. And, there are yet other solutions, not involving hierarchical PKI, and its well-known hangups. >>Furthermore, plain TLS requires the server to send the certificate >>without any knowledge of which domain the UAC is trying to contact. _plain_ TLS has NO rules concerning the selection of the cert, given an inbound handshake on a conenction, or a session restart. SSL and its IETF variety was architected to ensure that upper layers drive cert selection - originally intended to be a hook function in the winsock API. Never forget, despite the popularity of https profile, that TLS itself is not a cert-based handshake design, per se. How public keys are inidicated in one of the handshake types (.e.g the standardized handshake), and how said public keys are authenticated is not a TLS matter. its a matter for ftps, https, pptps etc etc profiling of SSL to any problem domain that has a reliable channel in support (.e.g. TCP) >>Thus, provB needs a dedicated socket for each hosted domain on its >>border proxy to differ the requests and present the proper certificate. >>IMO that does not scale. It can be avoided using the "server_name" TLS >>extension, but this is e.g. not supported in openssl which is used most >>for proxy servers. well done openssl. IETF hacking of SSL architecture to impose PKI into the body of a T-layer protocol machine is subjectively the wrong thing to do. Go back to 1000 winsock hooks, the way we intended it to all work so we could have a 1000 varieties of re-handshaking (and session key storage), during session restarts. >>This could be also solved by changing RFC 3263 to validate the >>certificate against the domain name revealed after SRV lookups. This was >>forbidden to detect DNS spoofing, but IMO DNS problems should be fixed >>in DNS, not in SIP." TLS/SSL is a TCP-level solution. Dont attempt to solve N-layer security issues at the T-layer. I know SSL is popular; we know all IPSEC application on end-user host is a miserable deployment experience. Given SIP URI can already be resolved with or without DNS-based ENUM, with SSL involvement, lets not force IETF changes into the SSL architecturem just becuase we are forcing DNS security issues into the SSL equation. The DNS hammer and DNS nails metaphor comes to mind. >>Richard >> >> >> >>________________________________ >> >>Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >>Gesendet: Fr 09.12.2005 13:40 >>An: Stastny Richard >>Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org >>Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try >> >> >> >>Stastny Richard wrote: >> >>>Thanx Klaus >>> >>>for the work ;-) >>> >>>Now the next question: >>>What are the implications proxy vs redirect >>>if you are using TLS? >> >> >>Now it's getting complicated ;-) >> >>With the redirect server, there will be 2 TLS handshakes: >> 1. borderProxyA redirectProxy >> 2. borderProxyA borderProxyB >> >>With the forwarding proxy, one TLS connection is mandatory: >> 1. borderProxyA forwardingProxy >> >>If the forwardin proxy is within the network of provB, there is no need >>to use TLS inside the network of prov if other means can be used to >>authetnicate (e.g. src_IP). But, if the forwarding proxy stays of of >>signaling for in-dialog messages, there is also a must for the second >>TLS conenction between >> 2. borderProxyA borderProxyB >> >>The more complicated thing is the certificate validation. RFC 3263 >>mandates, that the SIP domain (before NAPTR, SRV lookups) must be >>identical to the domain in the certificate. If provB hosts thousands of >>SIP domains for its clients, e.g. sip:fobar@stastny.com, >>sip:foobar@darilion.com, .... and requires TLS for incoming connections, >>provB must present a valid certificate for all hosted domains. Thus, you >>have to give your private key for stastny.com to you SIP provider. >>Furthermore, plain TLS requires the server to send the certificate >>without any knowledge of which domain the UAC is trying to contact. >>Thus, provB needs a dedicated socket for each hosted domain on its >>border proxy to differ the requests and present the proper certificate. >>IMO that does not scale. It can be avoided using the "server_name" TLS >>extension, but this is e.g. not supported in openssl which is used most >>for proxy servers. >> >>This could be also solved by changing RFC 3263 to validate the >>certificate against the domain name revealed after SRV lookups. This was >>forbidden to detect DNS spoofing, but IMO DNS problems should be fixed >>in DNS, not in SIP. >> >>regards >>klaus >> >> >>>Richard >>> >>>________________________________ >>> >>>Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >>>Gesendet: Fr 09.12.2005 12:52 >>>An: Stastny Richard >>>Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org >>>Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try >>> >>> >>> >>>Stastny Richard wrote: >>> >>> >>>>Thanx Klaus >>>> >>>>Also for answering a question I did not (yet) ask >>>>regarding redirect vs proxy >>>> >>>> >>>> >>>> >>>> >>>>>I personally prefer relaying instead of redirect. >>>> >>>> >>>>Me too and I see your arguments. >>>>Are there any arguments out there why to prefer redriect? >>> >>> >>>I just made some signaling pictures to visualize the difference: >>>From the signaling, there is no big difference. Both versions do need >>>approximately the same amount of signaling packets sent (depends onthe >>>actual SIP network design). >>> >>>I do not see any technical reason why to prefer one version over the >>>other. It's just a personal preference. >>> >>>regards >>>klaus >>> >>> >>>UAC proxyA borderProxyA redirectProxy borderProxyB proxyB UAS >>>| | | | | | | >>>|-INVITE>| | | | | | >>>|<-100---|-INVITE-->| | | | | >>>| |<--100----|-------INVITE---->| | | | >>>| | | | | | | >>>| | |<------302--------| | | | >>>| |<-302-----|-------ACK------->| | | | >>>| |--ACK---->| | | | | >>>| |--INVITE->| | | | | >>>| |<-100-----|--------------INVITE----------->| | | >>>| | |<--------------100--------------|-INVITE>| | >>>| | | | |<-100---|-INVITE>| >>>| | | | | |<-100---| >>>| | | | | | | >>>| | | | | |<-180---| >>>| | | | |<--180--| | >>>| | |<---------------180-------------| | | >>>| |<--180----| | | | | >>>|<--180--| | | | |<--200--| >>>| | | | |<--200--| | >>>| | |<---------------200-------------| | | >>>| |<---200---| | | | | >>>|<---200-| | | | | | >>>| | | | | | | >>>|--ACK-->| | | | | | >>>| |----ACK-->| | | | | >>>| | |--------------ACK-------------->| | | >>>| | | | |--ACK-->| | >>>| | | | | |--ACK-->| >>>| | | | | | | >>>| | | | | | | >>>| | | | | | | >>> >>>32 Packets >>> >>> >>>UAC proxyA borderProxyA forwardProxy borderProxyB proxyB UAS >>>| | | | | | | >>>|-INVITE>| | | | | | >>>|<-100---|-INVITE-->| | | | | >>>| |<--100----|-------INVITE---->| | | | >>>| | |<-------100-------|---INVITE--->| | | >>>| | | |<----100-----|-INVITE>| | >>>| | | | |<-100---|-INVITE>| >>>| | | | | |<-100---| >>>| | | | | | | >>>| | | | | |<-180---| >>>| | | | |<--180--| | >>>| | | |<---180------| | | >>>| | |<----- -180-------| | | | >>>| |<--180----| | | | | >>>|<--180--| | | | |<--200--| >>>| | | | |<--200--| | >>>| | | |<---200------| | | >>>| | |<-------200-------| | | | >>>| |<---200---| | | | | >>>|<---200-| | | | | | >>>| | | | | | | >>>|--ACK-->| | | | | | >>>| |----ACK-->| | | | | >>>| | |--------------ACK-------------->| | | >>>| | | | |--ACK-->| | >>>| | | | | |--ACK-->| >>> >>>29 Packets >>> >>> >>> >>> >> >> >> >> >> > > >_______________________________________________ >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 Dec 09 12:24:34 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 1Eklz0-0006uP-6c; Fri, 09 Dec 2005 12:24:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjlJi-0006pO-F8 for enum@megatron.ietf.org; Tue, 06 Dec 2005 17:29: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 RAA00582 for ; Tue, 6 Dec 2005 17:28:55 -0500 (EST) Message-Id: <200512062228.RAA00582@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjlfH-00041m-Rr for enum@ietf.org; Tue, 06 Dec 2005 17:52:04 -0500 Received: (qmail 27888 invoked by uid 510); 6 Dec 2005 17:34:07 -0500 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.142.34):. Processed in 0.942406 secs); 06 Dec 2005 22:34:07 -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.142.34):. Processed in 0.942406 secs Process 27881) Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.34) by 192.246.69.184 with SMTP; Tue, 06 Dec 2005 22:34:06 +0000 From: "Henry Sinnreich" To: "'Michael Hammer \(mhammer\)'" , "'Thilo Salmon'" , "'Klaus Darilion'" Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Tue, 6 Dec 2005 16:29:34 -0600 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: <072C5B76F7CEAB488172C6F64B30B5E3DA0533@xmb-rtp-20b.amer.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcX6l7ng7d5gWyzJReGGP+c21C99TwAEhbpAAAJAsEA= X-Antivirus-MYDOMAIN-Message-ID: <113390844683527881@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 09 Dec 2005 12:24:32 -0500 Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 'Stastny Richard' , enum@ietf.org 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 Sorry for nitpicking: >A provider is a provider. A provider is a business model and att/SBC may differ from Google who uses a different business model (which is more significant measured in $$$?). Didn't we agree to use the term "Internet domain owner" (we could shorten to IDOM or such)? Internet domains are well defined in the IETF. Business models for VoIP are better suited for other organizations, consortia or innovators who work to disrupt them :-) Thanks, Henry -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Hammer (mhammer) Sent: Tuesday, December 06, 2005 3:36 PM To: Thilo Salmon; Klaus Darilion Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; Stastny Richard Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM I am having trouble parsing these statements. A provider is a provider. I used the terms ingress and egress to indicate some server that sits on the edge of a provider's network and does peering to some other provider. The usage below seems to mix egress with originating being the network where the caller is attached. I was noting that the called party terminal and the interconnect points were different hosts and therefore may have different identities. To keep maximum flexibility, the format of those identities would need to be fully under the control of the domain of each provider. However, conflating all that into a single URI in the Request-URI seemed constraining to me. Having three URIs in separate headers seemed the most flexible. Splitting. I don't understand what got split or how. ENUM -- Tel:URI in, Point-of-interconnect URI out. Put in Route header. I only suggested that there might be two route headers because the terminating provider would indicate in ENUM, to get to this end-user, go to this entrance first. But, to get to that entrance, the originating provider needs to determine what the corresponding exit point is from his network, i.e. another Route header. The format and content of that URI is up to each provider. The advertised entrance point is I think by definition the (Inter-) Carrier ENUM. The internal determination of the exit point could be termed (Intra-) Carrier ENUM. Maybe peering is concerned only with the inter-carrier aspect. The Request-URI could be a normalized public identity of the user totally independent of interconnect naming schemes. I was just teasing out what are the assumptions and constraints in the original email. Mike > -----Original Message----- > From: Thilo Salmon [mailto:salmon@sipgate.de] > Sent: Tuesday, December 06, 2005 2:06 PM > To: Klaus Darilion > Cc: Michael Hammer (mhammer); sip@ietf.org; > voipeer@lists.uoregon.edu; enum@ietf.org; Stastny Richard > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > Richard, Klaus, et al. > > Apparently, I have missed an important developlement lately. > > > What is the benefit of splitting the ENUM result (the SIP > URI) into a > > Route header and into a request URI? > [...] > > IMO there should be no semantic for the internal routing > (the routing > > from the main proxy to the egress proxy). This should be > out of scope > > of all WGs. Also the internal routing of the ingress > provider should > > be out of scope. The ingress provider should have SIP URI > which can be > > used to address its customers. > > I absolutely second that statement. If for any reason (we all > have enough a vivid enough phantasy to imagine a good reason, > I suppose) an ingress provider wishes to feed a different set > of SIP URIs to each and every of his egress partners, he > should not be stripped of this option. > The scenario I have in mind is one in which an ingress > provider chooses to encrypt the user part of all his SIP URIs > with a key uniquely assigns to his egress partner. > > Just as Klaus I feel this complicates things and takes > authority over internal adressing away from the ingress > provider for no reason apparent (to me). > > Thilo > ____________________________________________________________________________ _ 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 Dec 09 12:24:34 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 1Eklz0-0006uq-K1; Fri, 09 Dec 2005 12:24:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjnqM-0007hE-3Z; Tue, 06 Dec 2005 20:11: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 UAA16450; Tue, 6 Dec 2005 20:10:46 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjoBx-0000z4-Hd; Tue, 06 Dec 2005 20:33:57 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 06 Dec 2005 17:11:29 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,223,1131350400"; d="scan'208"; a="16740014:sNHT24720444" 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 jB71BOUR018672; Tue, 6 Dec 2005 20:11:25 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 20:11:24 -0500 Received: from jmpolk-wxp.cisco.com ([10.86.242.192]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 20:11:24 -0500 Message-Id: <4.3.2.7.2.20051206190139.0325d688@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Dec 2005 19:11:22 -0600 To: "Michael Hammer \(mhammer\)" , , "Thilo Salmon" , "Klaus Darilion" From: "James M. Polk" Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3DA058E@xmb-rtp-20b.amer.ci sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 07 Dec 2005 01:11:24.0129 (UTC) FILETIME=[241FB510:01C5FACB] X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 X-Mailman-Approved-At: Fri, 09 Dec 2005 12:24:32 -0500 Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 Mike This seems to be creeping into more than one WG at about the same time. ISP used to be (roughly) the company you or you employer bought service from to gain access to the Internet. Now that is a little too generic for a lot of people's tastes as there are different SPs that an individual many have now that weren't available not so long ago. Hence the recent push to separate them somehow. Application Providers, to me, include a Vonage for Voice services, and a Yahoo for IM. Service Providers or Internet Providers, to me, connect one to the Internet for L3 access Access Providers, to me, are the organizations like the DSL and Cable and WiFi connectivity providers. Often times, to me, the Internet Providers and the Access Providers are either the same company - while perhaps different divisions, but they can be totally different companies too. The separation I'm seeing is between the organization that gives you you Internet access and the organizations that provider you with all the services required for a particular application - such as Voice or Video. Everything used to be best effort, and services were either at your device or at the provider's server. Now there's an overlay at layer 7 (typically) and we're struggling with how to name and describe it. At 06:23 PM 12/6/2005 -0500, Michael Hammer \(mhammer\) wrote: >My looking glass is smudged today. > >What does one call a provider of service? >I don't understand the aversion to service provider. > >I thought it was only the "carrier" word that invoked regulatory burdens >(or PATS!). I'd rather leave legal word games to lawyers and lobbyists. > >Mike > > > > -----Original Message----- > > From: Henry Sinnreich [mailto:henry@pulver.com] > > Sent: Tuesday, December 06, 2005 5:30 PM > > To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion' > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; > > 'Stastny Richard' > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > Sorry for nitpicking: > > > > >A provider is a provider. > > > > A provider is a business model and att/SBC may differ from > > Google who uses a different business model (which is more > > significant measured in $$$?). > > > > Didn't we agree to use the term "Internet domain owner" (we > > could shorten to IDOM or such)? > > > > Internet domains are well defined in the IETF. > > Business models for VoIP are better suited for other > > organizations, consortia or innovators who work to disrupt them :-) > > > > Thanks, Henry > > > > -----Original Message----- > > From: owner-voipeer@lists.uoregon.edu > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Hammer > > (mhammer) > > Sent: Tuesday, December 06, 2005 3:36 PM > > To: Thilo Salmon; Klaus Darilion > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; > > Stastny Richard > > Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > I am having trouble parsing these statements. > > > > A provider is a provider. I used the terms ingress and > > egress to indicate some server that sits on the edge of a > > provider's network and does peering to some other provider. > > The usage below seems to mix egress with originating being > > the network where the caller is attached. > > > > I was noting that the called party terminal and the > > interconnect points were different hosts and therefore may > > have different identities. To keep maximum flexibility, the > > format of those identities would need to be fully under the > > control of the domain of each provider. However, conflating > > all that into a single URI in the Request-URI seemed > > constraining to me. Having three URIs in separate headers > > seemed the most flexible. > > > > Splitting. I don't understand what got split or how. ENUM > > -- Tel:URI in, Point-of-interconnect URI out. Put in Route > > header. I only suggested that there might be two route > > headers because the terminating provider would indicate in > > ENUM, to get to this end-user, go to this entrance first. > > But, to get to that entrance, the originating provider needs > > to determine what the corresponding exit point is from his > > network, i.e. another Route header. The format and content > > of that URI is up to each provider. The advertised entrance > > point is I think by definition the (Inter-) Carrier ENUM. > > The internal determination of the exit point could be termed > > (Intra-) Carrier ENUM. Maybe peering is concerned only with > > the inter-carrier aspect. > > > > The Request-URI could be a normalized public identity of the > > user totally independent of interconnect naming schemes. I > > was just teasing out what are the assumptions and constraints > > in the original email. > > > > Mike > > > > > > > -----Original Message----- > > > From: Thilo Salmon [mailto:salmon@sipgate.de] > > > Sent: Tuesday, December 06, 2005 2:06 PM > > > To: Klaus Darilion > > > Cc: Michael Hammer (mhammer); sip@ietf.org; > > voipeer@lists.uoregon.edu; > > > enum@ietf.org; Stastny Richard > > > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > > > Richard, Klaus, et al. > > > > > > Apparently, I have missed an important developlement lately. > > > > > > > What is the benefit of splitting the ENUM result (the SIP > > > URI) into a > > > > Route header and into a request URI? > > > [...] > > > > IMO there should be no semantic for the internal routing > > > (the routing > > > > from the main proxy to the egress proxy). This should be > > > out of scope > > > > of all WGs. Also the internal routing of the ingress > > > provider should > > > > be out of scope. The ingress provider should have SIP URI > > > which can be > > > > used to address its customers. > > > > > > I absolutely second that statement. If for any reason (we all have > > > enough a vivid enough phantasy to imagine a good reason, I > > suppose) an > > > ingress provider wishes to feed a different set of SIP URIs to each > > > and every of his egress partners, he should not be stripped of this > > > option. > > > The scenario I have in mind is one in which an ingress provider > > > chooses to encrypt the user part of all his SIP URIs with a key > > > uniquely assigns to his egress partner. > > > > > > Just as Klaus I feel this complicates things and takes > > authority over > > > internal adressing away from the ingress provider for no reason > > > apparent (to me). > > > > > > Thilo > > > > > > > ______________________________________________________________ > > ______________ > > _ > > 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 Fri Dec 09 12:24:35 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 1Eklz1-0006vJ-3G; Fri, 09 Dec 2005 12:24:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek0xg-0002mq-G5 for enum@megatron.ietf.org; Wed, 07 Dec 2005 10:12:05 -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 KAA17713 for ; Wed, 7 Dec 2005 10:11:11 -0500 (EST) Message-Id: <200512071511.KAA17713@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek1JO-0003QJ-HX for enum@ietf.org; Wed, 07 Dec 2005 10:34:31 -0500 Received: (qmail 18523 invoked by uid 510); 7 Dec 2005 10:16:40 -0500 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.142.34):. Processed in 1.221155 secs); 07 Dec 2005 15:16:40 -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.142.34):. Processed in 1.221155 secs Process 18514) Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.34) by 192.246.69.184 with SMTP; Wed, 07 Dec 2005 15:16:38 +0000 From: "Henry Sinnreich" To: "'James M. Polk'" , "'Michael Hammer \(mhammer\)'" , "'Thilo Salmon'" , "'Klaus Darilion'" Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Wed, 7 Dec 2005 09:11:53 -0600 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX6zl2SX6z2UfpvRNe3OEvi6GgSqAAbpzmA In-Reply-To: <4.3.2.7.2.20051206190139.0325d688@email.cisco.com> X-Antivirus-MYDOMAIN-Message-ID: <113396859983518514@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 09 Dec 2005 12:24:32 -0500 Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 'Stastny Richard' , enum@ietf.org 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 James, > Now there's an overlay at layer 7 (typically) and we're struggling > with how to name and describe it. How about the following business models for domain administrators: - Individuals (Henry's residential network) - Enterprises (the Cisco IT network, including VoIP) - "Web (add 2.0)" companies: AOL, Apple, IBM, Google, Microsoft, Yahoo, - Facility based "Carriers" (ATT, Verizon) - Government, military, - VoIP and IM companies: FWD, Skype, Vonage. The last ones (VoIP and IM companies) carry most of the public VoIP traffic anyway, while the residential network domain may be clearly the preference of some users. Mike Hammer writes: > I don't understand the aversion to service provider. No need to elaborate :-) Besides, I just happen to like my own network domain better! The above is only another attempt to stay out of business/legal models in this IETF WG. Just say: Network Domains and/or Network Administrators. Thanks, Henry -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of James M. Polk Sent: Tuesday, December 06, 2005 7:11 PM To: Michael Hammer (mhammer); henry@pulver.com; Thilo Salmon; Klaus Darilion Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; Stastny Richard Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Mike This seems to be creeping into more than one WG at about the same time. ISP used to be (roughly) the company you or you employer bought service from to gain access to the Internet. Now that is a little too generic for a lot of people's tastes as there are different SPs that an individual many have now that weren't available not so long ago. Hence the recent push to separate them somehow. Application Providers, to me, include a Vonage for Voice services, and a Yahoo for IM. Service Providers or Internet Providers, to me, connect one to the Internet for L3 access Access Providers, to me, are the organizations like the DSL and Cable and WiFi connectivity providers. Often times, to me, the Internet Providers and the Access Providers are either the same company - while perhaps different divisions, but they can be totally different companies too. The separation I'm seeing is between the organization that gives you you Internet access and the organizations that provider you with all the services required for a particular application - such as Voice or Video. Everything used to be best effort, and services were either at your device or at the provider's server. Now there's an overlay at layer 7 (typically) and we're struggling with how to name and describe it. At 06:23 PM 12/6/2005 -0500, Michael Hammer \(mhammer\) wrote: >My looking glass is smudged today. > >What does one call a provider of service? >I don't understand the aversion to service provider. > >I thought it was only the "carrier" word that invoked regulatory burdens >(or PATS!). I'd rather leave legal word games to lawyers and lobbyists. > >Mike > > > > -----Original Message----- > > From: Henry Sinnreich [mailto:henry@pulver.com] > > Sent: Tuesday, December 06, 2005 5:30 PM > > To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion' > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; > > 'Stastny Richard' > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > Sorry for nitpicking: > > > > >A provider is a provider. > > > > A provider is a business model and att/SBC may differ from > > Google who uses a different business model (which is more > > significant measured in $$$?). > > > > Didn't we agree to use the term "Internet domain owner" (we > > could shorten to IDOM or such)? > > > > Internet domains are well defined in the IETF. > > Business models for VoIP are better suited for other > > organizations, consortia or innovators who work to disrupt them :-) > > > > Thanks, Henry > > > > -----Original Message----- > > From: owner-voipeer@lists.uoregon.edu > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Hammer > > (mhammer) > > Sent: Tuesday, December 06, 2005 3:36 PM > > To: Thilo Salmon; Klaus Darilion > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; > > Stastny Richard > > Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > I am having trouble parsing these statements. > > > > A provider is a provider. I used the terms ingress and > > egress to indicate some server that sits on the edge of a > > provider's network and does peering to some other provider. > > The usage below seems to mix egress with originating being > > the network where the caller is attached. > > > > I was noting that the called party terminal and the > > interconnect points were different hosts and therefore may > > have different identities. To keep maximum flexibility, the > > format of those identities would need to be fully under the > > control of the domain of each provider. However, conflating > > all that into a single URI in the Request-URI seemed > > constraining to me. Having three URIs in separate headers > > seemed the most flexible. > > > > Splitting. I don't understand what got split or how. ENUM > > -- Tel:URI in, Point-of-interconnect URI out. Put in Route > > header. I only suggested that there might be two route > > headers because the terminating provider would indicate in > > ENUM, to get to this end-user, go to this entrance first. > > But, to get to that entrance, the originating provider needs > > to determine what the corresponding exit point is from his > > network, i.e. another Route header. The format and content > > of that URI is up to each provider. The advertised entrance > > point is I think by definition the (Inter-) Carrier ENUM. > > The internal determination of the exit point could be termed > > (Intra-) Carrier ENUM. Maybe peering is concerned only with > > the inter-carrier aspect. > > > > The Request-URI could be a normalized public identity of the > > user totally independent of interconnect naming schemes. I > > was just teasing out what are the assumptions and constraints > > in the original email. > > > > Mike > > > > > > > -----Original Message----- > > > From: Thilo Salmon [mailto:salmon@sipgate.de] > > > Sent: Tuesday, December 06, 2005 2:06 PM > > > To: Klaus Darilion > > > Cc: Michael Hammer (mhammer); sip@ietf.org; > > voipeer@lists.uoregon.edu; > > > enum@ietf.org; Stastny Richard > > > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > > > Richard, Klaus, et al. > > > > > > Apparently, I have missed an important developlement lately. > > > > > > > What is the benefit of splitting the ENUM result (the SIP > > > URI) into a > > > > Route header and into a request URI? > > > [...] > > > > IMO there should be no semantic for the internal routing > > > (the routing > > > > from the main proxy to the egress proxy). This should be > > > out of scope > > > > of all WGs. Also the internal routing of the ingress > > > provider should > > > > be out of scope. The ingress provider should have SIP URI > > > which can be > > > > used to address its customers. > > > > > > I absolutely second that statement. If for any reason (we all have > > > enough a vivid enough phantasy to imagine a good reason, I > > suppose) an > > > ingress provider wishes to feed a different set of SIP URIs to each > > > and every of his egress partners, he should not be stripped of this > > > option. > > > The scenario I have in mind is one in which an ingress provider > > > chooses to encrypt the user part of all his SIP URIs with a key > > > uniquely assigns to his egress partner. > > > > > > Just as Klaus I feel this complicates things and takes > > authority over > > > internal adressing away from the ingress provider for no reason > > > apparent (to me). > > > > > > Thilo > > > > > > > ______________________________________________________________ > > ______________ > > _ > > 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 ____________________________________________________________________________ _ 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 Dec 09 12:24:35 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 1Eklz1-0006vi-Fr; Fri, 09 Dec 2005 12:24:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek9MZ-0005HB-7B for enum@megatron.ietf.org; Wed, 07 Dec 2005 19:10:19 -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 TAA24745 for ; Wed, 7 Dec 2005 19:09:26 -0500 (EST) Message-Id: <200512080009.TAA24745@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek9iL-0008G1-D6 for enum@ietf.org; Wed, 07 Dec 2005 19:32:50 -0500 Received: (qmail 31894 invoked by uid 510); 7 Dec 2005 19:14:58 -0500 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.142.34):. Processed in 2.825078 secs); 08 Dec 2005 00:14:58 -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.142.34):. Processed in 2.825078 secs Process 31835) Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.34) by 192.246.69.184 with SMTP; Thu, 08 Dec 2005 00:14:54 +0000 From: "Henry Sinnreich" To: "'Michael Hammer \(mhammer\)'" , "'James Polk \(jmpolk\)'" , "'Thilo Salmon'" , "'Klaus Darilion'" Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Wed, 7 Dec 2005 18:09:51 -0600 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX6yySCxyyxZ86zQZWvC9QFGn/uPQAoDi3gAAbserA= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3DA082B@xmb-rtp-20b.amer.cisco.com> X-Antivirus-MYDOMAIN-Message-ID: <113400089583531835@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 09 Dec 2005 12:24:32 -0500 Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 'Stastny Richard' , enum@ietf.org 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 VoIP calls in our offices can go directly between the two enterprise networks without any VoIP service providers being involved and this is = as valid VoIP peering as any other. This is one of the reasons not to limit = the VoIP peering models to only one, that with VoIP service providers in the middle.=20 Sorry, I was not sure if the attached has taken this = enterprise-enterprise into consideration and obviously there are other user scenarios as well. Thanks, Henry -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Wednesday, December 07, 2005 2:23 PM To: James Polk (jmpolk); henry@pulver.com; Thilo Salmon; Klaus Darilion Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; Stastny = Richard Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM James, This is d=E9j=E0 vu from the FG-NGN discussion on the exact same topic. = I have no issues with making distinctions of this type. It was just not clear = to me which of these various types (or the ones that Henry mentions) was in scope or not, but that seemed secondary to the point being made at the = time that had to do with what the X entity did with an ENUM response that affected the constraints on what could be contained in such responses. Mike > -----Original Message----- > From: James Polk (jmpolk)=20 > Sent: Tuesday, December 06, 2005 8:11 PM > To: Michael Hammer (mhammer); henry@pulver.com; Thilo Salmon;=20 > Klaus Darilion > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20 > Stastny Richard > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM >=20 > Mike >=20 > This seems to be creeping into more than one WG at about the=20 > same time. >=20 > ISP used to be (roughly) the company you or you employer=20 > bought service from to gain access to the Internet. Now that=20 > is a little too generic for a lot of people's tastes as there=20 > are different SPs that an individual many have now that=20 > weren't available not so long ago. Hence the recent push to=20 > separate them somehow. >=20 > Application Providers, to me, include a Vonage for Voice=20 > services, and a Yahoo for IM. >=20 > Service Providers or Internet Providers, to me, connect one=20 > to the Internet for L3 access >=20 > Access Providers, to me, are the organizations like the DSL=20 > and Cable and WiFi connectivity providers. >=20 > Often times, to me, the Internet Providers and the Access=20 > Providers are either the same company - while perhaps=20 > different divisions, but they can be totally different companies too. >=20 > The separation I'm seeing is between the organization that=20 > gives you you Internet access and the organizations that=20 > provider you with all the services required for a particular=20 > application - such as Voice or Video. >=20 > Everything used to be best effort, and services were either=20 > at your device or at the provider's server. Now there's an=20 > overlay at layer 7 (typically) and we're struggling with how=20 > to name and describe it. >=20 >=20 >=20 > At 06:23 PM 12/6/2005 -0500, Michael Hammer \(mhammer\) wrote: > >My looking glass is smudged today. > > > >What does one call a provider of service? > >I don't understand the aversion to service provider. > > > >I thought it was only the "carrier" word that invoked regulatory=20 > >burdens (or PATS!). I'd rather leave legal word games to=20 > lawyers and lobbyists. > > > >Mike > > > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:henry@pulver.com] > > > Sent: Tuesday, December 06, 2005 5:30 PM > > > To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion' > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20 > enum@ietf.org; 'Stastny=20 > > > Richard' > > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > > > Sorry for nitpicking: > > > > > > >A provider is a provider. > > > > > > A provider is a business model and att/SBC may differ from Google=20 > > > who uses a different business model (which is more significant=20 > > > measured in $$$?). > > > > > > Didn't we agree to use the term "Internet domain owner" (we could=20 > > > shorten to IDOM or such)? > > > > > > Internet domains are well defined in the IETF. > > > Business models for VoIP are better suited for other=20 > organizations,=20 > > > consortia or innovators who work to disrupt them :-) > > > > > > Thanks, Henry > > > > > > -----Original Message----- > > > From: owner-voipeer@lists.uoregon.edu=20 > > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of=20 > Michael Hammer > > > (mhammer) > > > Sent: Tuesday, December 06, 2005 3:36 PM > > > To: Thilo Salmon; Klaus Darilion > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20 > enum@ietf.org; Stastny=20 > > > Richard > > > Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > > > I am having trouble parsing these statements. > > > > > > A provider is a provider. I used the terms ingress and egress to=20 > > > indicate some server that sits on the edge of a=20 > provider's network=20 > > > and does peering to some other provider. > > > The usage below seems to mix egress with originating being the=20 > > > network where the caller is attached. > > > > > > I was noting that the called party terminal and the interconnect=20 > > > points were different hosts and therefore may have different=20 > > > identities. To keep maximum flexibility, the format of those=20 > > > identities would need to be fully under the control of=20 > the domain of=20 > > > each provider. However, conflating all that into a single URI in=20 > > > the Request-URI seemed constraining to me. Having three URIs in=20 > > > separate headers seemed the most flexible. > > > > > > Splitting. I don't understand what got split or how. ENUM > > > -- Tel:URI in, Point-of-interconnect URI out. Put in=20 > Route header. =20 > > > I only suggested that there might be two route headers=20 > because the=20 > > > terminating provider would indicate in ENUM, to get to this=20 > > > end-user, go to this entrance first. > > > But, to get to that entrance, the originating provider needs to=20 > > > determine what the corresponding exit point is from his network,=20 > > > i.e. another Route header. The format and content of=20 > that URI is up=20 > > > to each provider. The advertised entrance point is I think by=20 > > > definition the (Inter-) Carrier ENUM. > > > The internal determination of the exit point could be termed > > > (Intra-) Carrier ENUM. Maybe peering is concerned only with the=20 > > > inter-carrier aspect. > > > > > > The Request-URI could be a normalized public identity of the user=20 > > > totally independent of interconnect naming schemes. I was just=20 > > > teasing out what are the assumptions and constraints in=20 > the original=20 > > > email. > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Thilo Salmon [mailto:salmon@sipgate.de] > > > > Sent: Tuesday, December 06, 2005 2:06 PM > > > > To: Klaus Darilion > > > > Cc: Michael Hammer (mhammer); sip@ietf.org; > > > voipeer@lists.uoregon.edu; > > > > enum@ietf.org; Stastny Richard > > > > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > > > > > Richard, Klaus, et al. > > > > > > > > Apparently, I have missed an important developlement lately. > > > > > > > > > What is the benefit of splitting the ENUM result (the SIP > > > > URI) into a > > > > > Route header and into a request URI? > > > > [...] > > > > > IMO there should be no semantic for the internal routing > > > > (the routing > > > > > from the main proxy to the egress proxy). This should be > > > > out of scope > > > > > of all WGs. Also the internal routing of the ingress > > > > provider should > > > > > be out of scope. The ingress provider should have SIP URI > > > > which can be > > > > > used to address its customers. > > > > > > > > I absolutely second that statement. If for any reason=20 > (we all have=20 > > > > enough a vivid enough phantasy to imagine a good reason, I > > > suppose) an > > > > ingress provider wishes to feed a different set of SIP URIs to=20 > > > > each and every of his egress partners, he should not be=20 > stripped=20 > > > > of this option. > > > > The scenario I have in mind is one in which an ingress provider=20 > > > > chooses to encrypt the user part of all his SIP URIs with a key=20 > > > > uniquely assigns to his egress partner. > > > > > > > > Just as Klaus I feel this complicates things and takes > > > authority over > > > > internal adressing away from the ingress provider for no reason=20 > > > > apparent (to me). > > > > > > > > Thilo > > > > > > > > > > ______________________________________________________________ > > > ______________ > > > _ > > > 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 >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 12:24:35 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 1Eklz1-0006wH-Sv; Fri, 09 Dec 2005 12:24:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkCtd-0007wp-FC; Wed, 07 Dec 2005 22:56:43 -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 WAA18686; Wed, 7 Dec 2005 22:55:48 -0500 (EST) 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 1EkDFS-0007gK-Kn; Wed, 07 Dec 2005 23:19:15 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 07 Dec 2005 19:56:31 -0800 X-IronPort-AV: i="3.99,228,1131350400"; d="scan'208"; a="375500539:sNHT36091340" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB83uBBV025379; Wed, 7 Dec 2005 19:56:28 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Dec 2005 19:56:26 -0800 Received: from [10.21.80.55] ([10.21.80.55]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Dec 2005 19:56:24 -0800 Message-ID: <4397AEE7.8020303@cisco.com> Date: Wed, 07 Dec 2005 22:56:23 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Klaus Darilion Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try References: <32755D354E6B65498C3BD9FD496C7D461B228B@oefeg-s04.oefeg.loc> <4396D807.8000406@pernau.at> In-Reply-To: <4396D807.8000406@pernau.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2005 03:56:25.0246 (UTC) FILETIME=[5C1003E0:01C5FBAB] X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 09 Dec 2005 12:24:32 -0500 Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 - this second try is much more successful than the first! Paul Klaus Darilion wrote: > Hi Richard! > > comments inline > > Stastny Richard wrote: > >> Should Infrastructure ENUM contain a routing information >> to the next hop only (the ingress border element of Provider B >> (or administrative domain B) or simply a mapping from an E.164 number >> to an AoR? > > IMHO it should be a mapping to an AoR as in user ENUM. I think Richard has some specific ideas about what form of sip URI may be an AOR ans which may not. I am not entirely sure what those are, but suspect I disagree at least somewhat. For this application, it should be something known to be stable by whoever is making the entry. Beyond that I don't see there is a need to be very specific. If the user "owning" this number also has an "email-style" AOR that is intended to be fully equivalent to the phone number then that is probably one good choice. But it may be that a provider would rather set up the ENUM to simply route the numbers to itself using the user=phone form. I see nothing wrong with that either. >> I will try to give another example and start from > > ... > >> I subscribe with provider B and get a default public >> user identity (AoR) from this provider: >> e.g. sip:foo@provB.net >> This "foo" can be anything the provider chooses it to be: >> e.g. an alphanumeric string such as ywzabcd, >> a numeric string such as 16241 (my FWD number) >> or 019793321 or 4319793321 If it is a telephony-oriented provider, there may be no reason to assign such an AOR. It might prefer simply to assign an AOR of the form: sip:+4319793321@provB.net;user=phone. >> Any other provider A having a peering agreement >> with Provider B must be able to route a SIP call >> given this SIP AoR to provider B, either to the >> SIP proxy hosting this account or at least to >> the ingress proxy(s) in provider B network. >> >> On way to do so is to use SRV records within >> the zone of provB.net pointing to e.g >> >> ingress14.provB.net >> and >> ingress21.provB.net >> >> Question: is this correct? > > > IMO yes. Thus, A sends "INVITE sip:foo@provB.net" to ingress14.provB.net > >> Note: after the ingress proxy provider B >> may use another mapping mechanism to find >> the real hosting server e.g. srv21.provB.net >> >> Now I as a user are not happy with this default >> public user identity, I want to have some aliases >> >> eg: 1)sip:richard@stastny.com and >> 2) +43 1 9793321 I guess (2) is really: tel:+4319793321 >> In case 1) I assume that provider B needs >> to provide me with redirect server(s), and I >> need to enter in stastny.com SRV records >> to point to these redirect servers >> e.g. redirect.provB.net >> >> sip:richard.stastny.com is redirected to >> sip:foo@provB.net >> >> Question: is this correct? > > This is a working scenario. But a redirect server is not mandatory. It > may also be a proxy which forwards the request "INVITE > sip:richard.stastny.com" to "INVITE sip:foo@provB.net". > > It is also possbile that SRV for stastny.com points directly to > ingress12.provB.net and ingress12 knows about all hosted SIP domains and > knows how to forward the request to the end user. > > But this is a design decision of the provB and IMO should be out of > scope of SPEERMINT. provB may use redirect server, provC may accept all > hosted SIP domains directly on their ingress points, ..... I agree with the above. It also depends on how you got stastny.com as your own domain. Is it hosted by somebody that can provide the forwarding service for you? Do they manage the DNS for you? Perhaps provB provides this service for you. If so there are many things it can do. > I personally prefer relaying instead of redirect. E.g. redirect raises > questions like: How should intercept the redirect response and forward > to the new URI? The UA client or the SIP proxy of provA or the egress > proxy? > > The important thing is that the originator (provA) should not have to > take care how provB implemented the hosting of SIP domains. > >> In case 2) we need Infrastructure ENUM You need for than that! You need for the number +43 1 9793321 to be assigned to you and set up so that pstn calls are routed to provB. >> [Side note; in my user ENUM I would either enter >> sip:richard@stastny.com or sip:foo@provB.net >> this is my choice] You only get to do this if *you* have control over your entry in the user ENUM. Will that always be the case, or will the provider manage it on your behalf? One way to get the number would be for provB to get it for you. It might do as you suggest. Or it might consider this to be a separate AOR. In that case it might use something like IMS implicit registration sets to ensure that your same UA gets calls to both address forms. >> Now the question is: what goes into Infrastructure >> ENUM for say +4319793321? >> >> Is it: >> Sip:foo@provB.net (if plain sip:foo@provB.net works >> this must also work) >> OR >> sip:+4319793321@provB.net;user=phone (correct?) >> OR >> sip:+4319793321@provB.net (wrong?) This is ok I guess. I think this is a provider option. I like it less because it is less explicit about what it means. >> OR >> sip:4319793321@provB.net (valid only if 4319793321 = foo) >> >> OR is it >> sip:+4319793321@ingress14.provB.net;user=phone (and the above variants) >> AND >> sip:+4319793321@ingress21.provB.net;user=phone > > IMO all of these are valid. It's up to the choice of provB. provB can > put anything into ENUM as long as provB is able to map from the URI in > I-ENUM to the end user. > > If I would design the network for provB, I would use version 2 (without > user=phone as the user are not limited to phones). (Isn't the one without user=phone option 3?) I would use use sip:+4319793321@provB.net;user=phone The presence of user=phone in no way prevents use for things other than phones. Of course it is not very convenient to type for those that enter URIs from a keyboard. If use for purposes like IM on a PC is expected, then sip:foo@provB.net may be preferred. Or else sip:foo@provB.net can just be supported also on the same device. I also hope that as we go forward, pc apps will allow either sip URIs phone numbers (entered as a dial string and represented as a tel uri) to be used. So the "caller" would be using tel:+4319793321 and that will be appropriately routed. >> In this last case one would not need to query the >> SRV records in provB.net > > > Also in the last case (if beeing conform with RFC3263), the egress proxy > has to perform NAPTR and SRV lookups. If you want to avoid them, just > put the IP address or the port into the host part, e.g. > > sip:+4319793321@ingress21.provB.net:5060;user=phone > > regards > klaus > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 12:24:36 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 1Eklz2-0006wo-SQ; Fri, 09 Dec 2005 12:24:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkO9c-0005oH-2j for enum@megatron.ietf.org; Thu, 08 Dec 2005 10:57:58 -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 KAA02416 for ; Thu, 8 Dec 2005 10:56:43 -0500 (EST) Message-Id: <200512081556.KAA02416@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkO9J-0005i1-CI for enum@ietf.org; Thu, 08 Dec 2005 10:57:37 -0500 Received: (qmail 3668 invoked by uid 510); 8 Dec 2005 11:02:27 -0500 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.142.34):. Processed in 1.018343 secs); 08 Dec 2005 16:02:27 -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.142.34):. Processed in 1.018343 secs Process 3660) Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.34) by 192.246.69.184 with SMTP; Thu, 08 Dec 2005 16:02:26 +0000 From: "Henry Sinnreich" To: "'Michael Hammer \(mhammer\)'" , "'James Polk \(jmpolk\)'" , "'Thilo Salmon'" , "'Klaus Darilion'" Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Thu, 8 Dec 2005 09:57:18 -0600 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3DA09F8@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX6yySCxyyxZ86zQZWvC9QFGn/uPQAoDi3gAAbserAAH9g8AAABkrKg X-Antivirus-MYDOMAIN-Message-ID: <11340577468353660@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 09 Dec 2005 12:24:32 -0500 Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 'Stastny Richard' , enum@ietf.org 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 Mike, I agree. If you want to say "service provider", the term has to be = defined (as you have just contributed) to include cable networks, IT = departments, government organizations, community networks, family/home networks, etc. = Without a definition there is ample room for different meanings, technically, legally and commercial. But should such a definition be = done in this WG? The technical meaning is _Internet domain_ in all cases. Thanks, Henry =20 -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Thursday, December 08, 2005 8:52 AM To: henry@pulver.com; James Polk (jmpolk); Thilo Salmon; Klaus Darilion Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; Stastny = Richard Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Henry, An IT department of an enterprise that operates VoIP servers is a = service provider, albeit a private versus a public one. Thus, I don't see the = limit you speak of. Adding an additional adjective "public" and you get a PATS or Carrier = that has narrower connotations. Mike > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com]=20 > Sent: Wednesday, December 07, 2005 7:10 PM > To: Michael Hammer (mhammer); James Polk (jmpolk); 'Thilo=20 > Salmon'; 'Klaus Darilion' > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20 > 'Stastny Richard' > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM >=20 > The VoIP calls in our offices can go directly between the two=20 > enterprise networks without any VoIP service providers being=20 > involved and this is as valid VoIP peering as any other. This=20 > is one of the reasons not to limit the VoIP peering models to=20 > only one, that with VoIP service providers in the middle.=20 >=20 > Sorry, I was not sure if the attached has taken this=20 > enterprise-enterprise into consideration and obviously there=20 > are other user scenarios as well. >=20 > Thanks, Henry >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, December 07, 2005 2:23 PM > To: James Polk (jmpolk); henry@pulver.com; Thilo Salmon;=20 > Klaus Darilion > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20 > Stastny Richard > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM >=20 > James, >=20 > This is d=E9j=E0 vu from the FG-NGN discussion on the exact same=20 > topic. I have no issues with making distinctions of this=20 > type. It was just not clear to me which of these various=20 > types (or the ones that Henry mentions) was in scope or not,=20 > but that seemed secondary to the point being made at the time=20 > that had to do with what the X entity did with an ENUM=20 > response that affected the constraints on what could be=20 > contained in such responses. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: James Polk (jmpolk) > > Sent: Tuesday, December 06, 2005 8:11 PM > > To: Michael Hammer (mhammer); henry@pulver.com; Thilo Salmon; Klaus=20 > > Darilion > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; Stastny=20 > > Richard > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > >=20 > > Mike > >=20 > > This seems to be creeping into more than one WG at about the same=20 > > time. > >=20 > > ISP used to be (roughly) the company you or you employer bought=20 > > service from to gain access to the Internet. Now that is a=20 > little too=20 > > generic for a lot of people's tastes as there are different=20 > SPs that=20 > > an individual many have now that weren't available not so=20 > long ago. =20 > > Hence the recent push to separate them somehow. > >=20 > > Application Providers, to me, include a Vonage for Voice=20 > services, and=20 > > a Yahoo for IM. > >=20 > > Service Providers or Internet Providers, to me, connect one to the=20 > > Internet for L3 access > >=20 > > Access Providers, to me, are the organizations like the DSL=20 > and Cable=20 > > and WiFi connectivity providers. > >=20 > > Often times, to me, the Internet Providers and the Access Providers=20 > > are either the same company - while perhaps different=20 > divisions, but=20 > > they can be totally different companies too. > >=20 > > The separation I'm seeing is between the organization that=20 > gives you=20 > > you Internet access and the organizations that provider you=20 > with all=20 > > the services required for a particular application - such=20 > as Voice or=20 > > Video. > >=20 > > Everything used to be best effort, and services were either at your=20 > > device or at the provider's server. Now there's an overlay=20 > at layer 7=20 > > (typically) and we're struggling with how to name and describe it. > >=20 > >=20 > >=20 > > At 06:23 PM 12/6/2005 -0500, Michael Hammer \(mhammer\) wrote: > > >My looking glass is smudged today. > > > > > >What does one call a provider of service? > > >I don't understand the aversion to service provider. > > > > > >I thought it was only the "carrier" word that invoked regulatory=20 > > >burdens (or PATS!). I'd rather leave legal word games to=20 > > lawyers and lobbyists. > > > > > >Mike > > > > > > > > > > -----Original Message----- > > > > From: Henry Sinnreich [mailto:henry@pulver.com] > > > > Sent: Tuesday, December 06, 2005 5:30 PM > > > > To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion' > > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20 > > enum@ietf.org; 'Stastny=20 > > > > Richard' > > > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR,=20 > tel and ENUM > > > > > > > > Sorry for nitpicking: > > > > > > > > >A provider is a provider. > > > > > > > > A provider is a business model and att/SBC may differ=20 > from Google=20 > > > > who uses a different business model (which is more significant=20 > > > > measured in $$$?). > > > > > > > > Didn't we agree to use the term "Internet domain owner"=20 > (we could=20 > > > > shorten to IDOM or such)? > > > > > > > > Internet domains are well defined in the IETF. > > > > Business models for VoIP are better suited for other=20 > > organizations,=20 > > > > consortia or innovators who work to disrupt them :-) > > > > > > > > Thanks, Henry > > > > > > > > -----Original Message----- > > > > From: owner-voipeer@lists.uoregon.edu=20 > > > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of=20 > > Michael Hammer > > > > (mhammer) > > > > Sent: Tuesday, December 06, 2005 3:36 PM > > > > To: Thilo Salmon; Klaus Darilion > > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20 > > enum@ietf.org; Stastny=20 > > > > Richard > > > > Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > > > > > I am having trouble parsing these statements. > > > > > > > > A provider is a provider. I used the terms ingress and=20 > egress to=20 > > > > indicate some server that sits on the edge of a=20 > > provider's network=20 > > > > and does peering to some other provider. > > > > The usage below seems to mix egress with originating being the=20 > > > > network where the caller is attached. > > > > > > > > I was noting that the called party terminal and the=20 > interconnect=20 > > > > points were different hosts and therefore may have different=20 > > > > identities. To keep maximum flexibility, the format of those=20 > > > > identities would need to be fully under the control of=20 > > the domain of=20 > > > > each provider. However, conflating all that into a=20 > single URI in=20 > > > > the Request-URI seemed constraining to me. Having=20 > three URIs in=20 > > > > separate headers seemed the most flexible. > > > > > > > > Splitting. I don't understand what got split or how. ENUM > > > > -- Tel:URI in, Point-of-interconnect URI out. Put in=20 > > Route header. =20 > > > > I only suggested that there might be two route headers=20 > > because the=20 > > > > terminating provider would indicate in ENUM, to get to this=20 > > > > end-user, go to this entrance first. > > > > But, to get to that entrance, the originating provider needs to=20 > > > > determine what the corresponding exit point is from his=20 > network,=20 > > > > i.e. another Route header. The format and content of=20 > > that URI is up=20 > > > > to each provider. The advertised entrance point is I think by=20 > > > > definition the (Inter-) Carrier ENUM. > > > > The internal determination of the exit point could be termed > > > > (Intra-) Carrier ENUM. Maybe peering is concerned only=20 > with the=20 > > > > inter-carrier aspect. > > > > > > > > The Request-URI could be a normalized public identity=20 > of the user=20 > > > > totally independent of interconnect naming schemes. I was just=20 > > > > teasing out what are the assumptions and constraints in=20 > > the original=20 > > > > email. > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Thilo Salmon [mailto:salmon@sipgate.de] > > > > > Sent: Tuesday, December 06, 2005 2:06 PM > > > > > To: Klaus Darilion > > > > > Cc: Michael Hammer (mhammer); sip@ietf.org; > > > > voipeer@lists.uoregon.edu; > > > > > enum@ietf.org; Stastny Richard > > > > > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > > > > > > > Richard, Klaus, et al. > > > > > > > > > > Apparently, I have missed an important developlement lately. > > > > > > > > > > > What is the benefit of splitting the ENUM result (the SIP > > > > > URI) into a > > > > > > Route header and into a request URI? > > > > > [...] > > > > > > IMO there should be no semantic for the internal routing > > > > > (the routing > > > > > > from the main proxy to the egress proxy). This should be > > > > > out of scope > > > > > > of all WGs. Also the internal routing of the ingress > > > > > provider should > > > > > > be out of scope. The ingress provider should have SIP URI > > > > > which can be > > > > > > used to address its customers. > > > > > > > > > > I absolutely second that statement. If for any reason=20 > > (we all have=20 > > > > > enough a vivid enough phantasy to imagine a good reason, I > > > > suppose) an > > > > > ingress provider wishes to feed a different set of=20 > SIP URIs to=20 > > > > > each and every of his egress partners, he should not be=20 > > stripped=20 > > > > > of this option. > > > > > The scenario I have in mind is one in which an=20 > ingress provider=20 > > > > > chooses to encrypt the user part of all his SIP URIs=20 > with a key=20 > > > > > uniquely assigns to his egress partner. > > > > > > > > > > Just as Klaus I feel this complicates things and takes > > > > authority over > > > > > internal adressing away from the ingress provider for=20 > no reason=20 > > > > > apparent (to me). > > > > > > > > > > Thilo > > > > > > > > > > > > > ______________________________________________________________ > > > > ______________ > > > > _ > > > > 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 > >=20 > >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 12:24:38 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 1Eklz4-0006xJ-Oy; Fri, 09 Dec 2005 12:24:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekivj-00064Z-OY; Fri, 09 Dec 2005 09:09:12 -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 JAA08515; Fri, 9 Dec 2005 09:07:58 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekivm-0004lL-1k; Fri, 09 Dec 2005 09:09:04 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 09 Dec 2005 06:08:39 -0800 X-IronPort-AV: i="3.99,234,1131350400"; d="scan'208"; a="239225149:sNHT34114880" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB9E84Qo015297; Fri, 9 Dec 2005 06:08:37 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Dec 2005 06:08:24 -0800 Received: from [10.21.88.169] ([10.21.88.169]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Dec 2005 06:08:23 -0800 Message-ID: <43998FD7.20207@cisco.com> Date: Fri, 09 Dec 2005 09:08:23 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Dec 2005 14:08:24.0066 (UTC) FILETIME=[04990E20:01C5FCCA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 09 Dec 2005 12:24:32 -0500 Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 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: >>Thus, IMO the paramter is more interesting for the outgoing provider. If >>the proxy of provA receives a request from its customer for >> sip:+4312345@provA.com >>this would adress the lokal user +4312345. A request for >> sip:+4312345@provA.com;user=phone >>would address the E.164 phone number +4312345 > > > Yesss, exactly ;-) > > And since you rarely have local users start with +, > sip:4312345@provA.com is more usual > > and > sip:+4312345@provA.com > should not happen, causeing always confusion It seems that many people intend to use a namespace for usernames where there is no overlap of names and numbers: there is no possibility for a *name* +4312345 that has a different meaning than the E.164 number +4312345. In that case the presence or absence of the ";user=phone" is irrelevant as far as its meaning within the owning domain. In that case the ";user=phone" is more a matter of informing the world that this is intended to be a phone number. Also, as it happens, while sip:+4312345@provA.com sip:+4312345@provA.com;user=phone are not equal by uri comparison rules, they are equal according to the rules that 3261 applies to the targets of registration. So, you can't really have them mean different things. Paul _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 12:24:39 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 1Eklz5-0006xp-5x; Fri, 09 Dec 2005 12:24:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkjlL-0001ZW-4E; Fri, 09 Dec 2005 10:02:19 -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 KAA16382; Fri, 9 Dec 2005 10:01:25 -0500 (EST) Received: from vivo117.gprs.dnafinland.fi ([62.78.127.117] helo=rautu.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkjlR-0006xm-Nh; Fri, 09 Dec 2005 10:02:31 -0500 Received: from rautu.tutpro.com (jh@localhost [127.0.0.1]) by rautu.tutpro.com (8.13.4/8.13.4/Debian-3) with ESMTP id jB9ExnPC004394; Fri, 9 Dec 2005 16:59:49 +0200 Received: (from jh@localhost) by rautu.tutpro.com (8.13.4/8.13.4/Submit) id jB9ExnC0004391; Fri, 9 Dec 2005 16:59:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17305.39909.629606.843484@rautu.tutpro.com> Date: Fri, 9 Dec 2005 16:59:49 +0200 From: Juha Heinanen To: Paul Kyzivat Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try In-Reply-To: <43998FD7.20207@cisco.com> References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc> <43998FD7.20207@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 09 Dec 2005 12:24:32 -0500 Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 Paul Kyzivat writes: > Also, as it happens, while > sip:+4312345@provA.com > sip:+4312345@provA.com;user=phone > are not equal by uri comparison rules, they are equal according to the > rules that 3261 applies to the targets of registration. So, you can't > really have them mean different things. if UA is to send a request to sip:+4312345@provA.com, it MUST send it to provA.com. in case of sip:+4312345@provA.com;user=phone, it can (and usually MUST) send it wherever it is sending requests to e.164 numbers, i.e., where it would send tel:+4312345, because the UA may not have any deal to use provA.com as its outbound proxy. -- juha _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 12:24:39 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 1Eklz5-0006yI-IB; Fri, 09 Dec 2005 12:24:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkkBG-0008LU-Tc; Fri, 09 Dec 2005 10:29:07 -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 KAA19327; Fri, 9 Dec 2005 10:28:05 -0500 (EST) 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 1EkkBK-0007rT-PS; Fri, 09 Dec 2005 10:29:12 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 09 Dec 2005 07:28:47 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB9FSBQm000204; Fri, 9 Dec 2005 07:28:44 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Dec 2005 07:28:43 -0800 Received: from [10.21.121.11] ([10.21.121.11]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Dec 2005 07:28:42 -0800 Message-ID: <4399A2AA.1020506@cisco.com> Date: Fri, 09 Dec 2005 10:28:42 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc> <43998FD7.20207@cisco.com> <17305.39909.629606.843484@rautu.tutpro.com> In-Reply-To: <17305.39909.629606.843484@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Dec 2005 15:28:42.0751 (UTC) FILETIME=[3CC208F0:01C5FCD5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 09 Dec 2005 12:24:32 -0500 Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 Juha Heinanen wrote: > Paul Kyzivat writes: > > > Also, as it happens, while > > sip:+4312345@provA.com > > sip:+4312345@provA.com;user=phone > > are not equal by uri comparison rules, they are equal according to the > > rules that 3261 applies to the targets of registration. So, you can't > > really have them mean different things. > > if UA is to send a request to sip:+4312345@provA.com, it MUST send it to > provA.com. in case of sip:+4312345@provA.com;user=phone, it can (and > usually MUST) send it wherever it is sending requests to e.164 numbers, > i.e., where it would send tel:+4312345, because the UA may not have any > deal to use provA.com as its outbound proxy. I disagree with you Juha. AFAIK the routing of *either* form MUST be routed solely based on the provA.com domain. Unless you are responsible for the domain in question you are not to interpret the user part in any way. There is no dispensation to violate this when the user=phone parameter is present. Paul _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 12:24:39 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 1Eklz5-0006yh-Ts; Fri, 09 Dec 2005 12:24:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EklKo-000835-NV; Fri, 09 Dec 2005 11:43:06 -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 LAA29004; Fri, 9 Dec 2005 11:41:57 -0500 (EST) Received: from dhcp6.tutpro.com ([192.98.100.133] helo=rautu.tutpro.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EklKk-000268-TT; Fri, 09 Dec 2005 11:43:05 -0500 Received: from rautu.tutpro.com (jh@localhost [127.0.0.1]) by rautu.tutpro.com (8.13.4/8.13.4/Debian-3) with ESMTP id jB9FhvpK010229; Fri, 9 Dec 2005 17:43:57 +0200 Received: (from jh@localhost) by rautu.tutpro.com (8.13.4/8.13.4/Submit) id jB9FhBt9010224; Fri, 9 Dec 2005 17:43:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17305.42511.328358.495586@rautu.tutpro.com> Date: Fri, 9 Dec 2005 17:43:11 +0200 From: Juha Heinanen To: Paul Kyzivat Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try In-Reply-To: <4399A2AA.1020506@cisco.com> References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc> <43998FD7.20207@cisco.com> <17305.39909.629606.843484@rautu.tutpro.com> <4399A2AA.1020506@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 09 Dec 2005 12:24:32 -0500 Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 Paul Kyzivat writes: > I disagree with you Juha. AFAIK the routing of *either* form MUST be > routed solely based on the provA.com domain. Unless you are responsible > for the domain in question you are not to interpret the user part in any > way. There is no dispensation to violate this when the user=phone > parameter is present. i'm pretty sure that i have read in some rfc that sip:+@;user=phone is EQUIVALENT with tel:+, i.e., they are two textual representations of the same thing, but can't check it now, because i'm travelling in train. i have seen some SIP UAs to use sip:+@;user=phone format in 302, when the user has made call redirect to a PSTN number. if this 302 is received by someone in another domain, it cannot reach pstn via the proxy of the other domain. so it must interpret sip:+@;user=phone as a tel uri and use its own proxy. -- juha _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 12:55:42 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 1EkmT8-00011v-MR; Fri, 09 Dec 2005 12:55:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkmT1-0000zu-Tl; Fri, 09 Dec 2005 12:55:36 -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 MAA07886; Fri, 9 Dec 2005 12:54:41 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkmTD-0004h5-Qb; Fri, 09 Dec 2005 12:55:50 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 09 Dec 2005 09:55:22 -0800 X-IronPort-AV: i="3.99,235,1131350400"; d="scan'208"; a="239305897:sNHT1541909740" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB9HseBn013616; Fri, 9 Dec 2005 09:55:18 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Dec 2005 09:55:16 -0800 Received: from [10.21.121.11] ([10.21.121.11]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Dec 2005 09:55:15 -0800 Message-ID: <4399C502.1060702@cisco.com> Date: Fri, 09 Dec 2005 12:55:14 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc> <43998FD7.20207@cisco.com> <17305.39909.629606.843484@rautu.tutpro.com> <4399A2AA.1020506@cisco.com> <17305.42511.328358.495586@rautu.tutpro.com> In-Reply-To: <17305.42511.328358.495586@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Dec 2005 17:55:15.0670 (UTC) FILETIME=[B5BEFF60:01C5FCE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 Juha Heinanen wrote: > Paul Kyzivat writes: > > > I disagree with you Juha. AFAIK the routing of *either* form MUST be > > routed solely based on the provA.com domain. Unless you are responsible > > for the domain in question you are not to interpret the user part in any > > way. There is no dispensation to violate this when the user=phone > > parameter is present. > > i'm pretty sure that i have read in some rfc that > sip:+@;user=phone is EQUIVALENT with tel:+, I forget where that is. 3261 isn't the full story - it got clarified somewhere. The point is that if the user=phone parameter is present, then the user part MUST conform to the tel syntax. But that is really a constraint on the owner of the domain, because others shouldn't be interpretting the user part, even to determine its validity. > i.e., they are two textual representations of the same thing, but can't > check it now, because i'm travelling in train. > > i have seen some SIP UAs to use sip:+@;user=phone format > in 302, when the user has made call redirect to a PSTN number. if this > 302 is received by someone in another domain, it cannot reach pstn via > the proxy of the other domain. so it must interpret > sip:+@;user=phone as a tel uri and use its own proxy. This is a good argument for not doing this. Putting this form in the 302 is exactly the right thing to do if you want to *force* the recipient to go to the specified domain. And there could be reasons why you might want to do that. E.g. you want to use media only available via SIP, or you want to use SIPS for security. If you don't want to force the caller to do that, and want to allow the option for the caller to reach you indirectly via the PSTN, then you ought to use a tel uri. Then the user that gets it has lots of options. Paul _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 13:03:18 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 1EkmaT-0001jv-V6; Fri, 09 Dec 2005 13:03:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkmaL-0001iz-Ux; Fri, 09 Dec 2005 13:03:10 -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 NAA08490; Fri, 9 Dec 2005 13:02:15 -0500 (EST) Received: from harjus.tutpro.com ([192.98.100.3] ident=Debian-exim) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkmaZ-0004vc-6q; Fri, 09 Dec 2005 13:03:24 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1Ekma8-00017x-JK; Fri, 09 Dec 2005 20:02:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17305.50896.571552.38180@harjus.tutpro.com> Date: Fri, 9 Dec 2005 20:02:56 +0200 To: Paul Kyzivat Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try In-Reply-To: <4399C502.1060702@cisco.com> References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc> <43998FD7.20207@cisco.com> <17305.39909.629606.843484@rautu.tutpro.com> <4399A2AA.1020506@cisco.com> <17305.42511.328358.495586@rautu.tutpro.com> <4399C502.1060702@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 Paul Kyzivat writes: > If you don't want to force the caller to do that, and want to allow the > option for the caller to reach you indirectly via the PSTN, then you > ought to use a tel uri. Then the user that gets it has lots of > options. yes, that is what i have figured out too. the problem is that there is lots of sip phones on the market that don't support tel uris although this application clearly requires the use of them. the root of the problem lies with rfc3261 that doesn't mandate that sip ua support tel uris (it is MAY) although this application clearly shows that tel uri support is mandatory in any sip ua. -- juha _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 13:19:54 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 1EkmqY-0006OY-MN; Fri, 09 Dec 2005 13:19:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkmqW-0006FM-Ec; Fri, 09 Dec 2005 13:19:52 -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 NAA10269; Fri, 9 Dec 2005 13:18:53 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekmqd-0005d5-VN; Fri, 09 Dec 2005 13:20:02 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 09 Dec 2005 10:19:28 -0800 X-IronPort-AV: i="3.99,235,1131350400"; d="scan'208"; a="239319519:sNHT1182596242" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jB9IIxMu020501; Fri, 9 Dec 2005 10:19:25 -0800 (PST) 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, 9 Dec 2005 13:19:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try Date: Fri, 9 Dec 2005 13:19:03 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA0E93@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try Thread-Index: AcX84WOnltFqCuSbSHKDfno6PulYyQAC3mPQ From: "Michael Hammer \(mhammer\)" To: "Juha Heinanen" , "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 09 Dec 2005 18:19:05.0430 (UTC) FILETIME=[09F30F60:01C5FCED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 Juha, That was in the yu-np-08 draft now dead, but did not survive to the present draft np-07. Even so, it described how to map from tel: into sip: but not vice versa. Mike > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Juha Heinanen > Sent: Friday, December 09, 2005 10:43 AM > To: Paul Kyzivat (pkyzivat) > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard;=20 > enum@ietf.org; Klaus Darilion > Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try >=20 > Paul Kyzivat writes: >=20 > > I disagree with you Juha. AFAIK the routing of *either*=20 > form MUST be > routed solely based on the provA.com domain.=20 > Unless you are responsible > for the domain in question you=20 > are not to interpret the user part in any > way. There is no=20 > dispensation to violate this when the user=3Dphone > parameter=20 > is present. >=20 > i'm pretty sure that i have read in some rfc that=20 > sip:+@;user=3Dphone is EQUIVALENT with=20 > tel:+, i.e., they are two textual representations of=20 > the same thing, but can't check it now, because i'm=20 > travelling in train. >=20 > i have seen some SIP UAs to use=20 > sip:+@;user=3Dphone format in 302, when the=20 > user has made call redirect to a PSTN number. if this > 302 is received by someone in another domain, it cannot reach=20 > pstn via the proxy of the other domain. so it must interpret=20 > sip:+@;user=3Dphone as a tel uri and use its own = proxy. >=20 > -- juha >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 13:36:17 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 1Ekn6P-0007GG-0O; Fri, 09 Dec 2005 13:36:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekn6I-00073b-Cd; Fri, 09 Dec 2005 13:36:13 -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 NAA12543; Fri, 9 Dec 2005 13:35:15 -0500 (EST) Received: from 65-118-85-140.dia.cust.qwest.net ([65.118.85.140] helo=FILEVAULT.windows.deltel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekn6V-0006JS-K0; Fri, 09 Dec 2005 13:36:25 -0500 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.5 Subject: RE: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try Date: Fri, 9 Dec 2005 10:35:48 -0800 Message-ID: <383A9E7C48D9694FAD43334A7563AA6C8C4170@FILEVAULT.windows.deltel.com> Thread-Topic: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try thread-index: AcX84nHqNtMi51ZnRp+QvykWgs7kWAACqElA From: "Tolga Tarhan" To: "Juha Heinanen" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: Sip , 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 All, Just to be clear, let me define my understanding of Juha's scenario: 1) UserA@provA sends an invite to his local proxy (provA) for UserB@provB. 2) UserB has told his provider that he wants all of his calls redirected to his PSTN number. Clearly, userB's intent is that the call be completed through a media gateway to the PSTN. For this example, let's say the number was +17205551212. 3) provB receives the request from provA and now needs to send a redirect to the PSTN number. Assume for this example that provA and provB have no business relationship, and therefore, provB will not accept a call to the PSTN from provA. That being said, probably the simplest thing that provB can do is use a tel: URI in the redirect. That avoids all ambiguity and logically requests that provA use a local media gateway to complete the call to the PSTN. If the tel: URI is not an option for some reason, then provB should send the redirect to sip:+17205551212@provA;user=3Dphone. Notice the use of provA, which the proxy at provB would have to derive, presumably using the "From" header. I don't think this is a good option, because there may be no reliable way to consistently derive the correct URI. I have to side with Paul, however, in saying that IF the redirect from provB actually refers to sip:+17205551212@provB (regardless of the presence of a user attribute), then the RFC is fairly clear -- the request that results from the redirect must be sent to provB, which will almost certainly fail. -- Tolga Tarhan -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Juha Heinanen Sent: Friday, December 09, 2005 8:59 AM To: Stastny Richard Cc: Sip Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try Stastny Richard writes: > A user enters a phone number, the UA sends it by default > to his provider A with > sip:+4312345@provA.com;user=3Dphone that is fine if the user is placing the call, but how about when the user wants to refer the calling party with 302 to his number on pstn network? =20 last time i checked, phones from paul's company use sip uri format, which according to paul's interpretation must be routed to whatever host part is listed there, which for sure get blocked by the proxy if the caller belongs to a different domain. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 13:51:37 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 1EknLF-0004br-Ju; Fri, 09 Dec 2005 13:51:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EknLA-0004b1-LP; Fri, 09 Dec 2005 13:51:32 -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 NAA14543; Fri, 9 Dec 2005 13:50:37 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EknLO-0006rZ-0b; Fri, 09 Dec 2005 13:51:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try Date: Fri, 9 Dec 2005 19:52:35 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C471E@oefeg-s04.oefeg.loc> Thread-Topic: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try Thread-Index: AcX84nHqNtMi51ZnRp+QvykWgs7kWAACqElAAAEpSZw= From: "Stastny Richard" To: "Tolga Tarhan" , "Juha Heinanen" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Cc: Sip , 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 example below is very interesting, but not a very realistic one. =20 As long a calls to the PSTN are charged, this will never work with re-direct, only with forwarding (as it is now in the PSTN with all such scenarios). In case of forwarding User B gets charged =20 Richard ________________________________ Von: Tolga Tarhan [mailto:Tolga.Tarhan@deltel.com] Gesendet: Fr 09.12.2005 19:35 An: Juha Heinanen; Paul Kyzivat Cc: Sip; enum@ietf.org; Stastny Richard Betreff: RE: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try All, Just to be clear, let me define my understanding of Juha's scenario: 1) UserA@provA sends an invite to his local proxy (provA) for UserB@provB. 2) UserB has told his provider that he wants all of his calls redirected to his PSTN number. Clearly, userB's intent is that the call be completed through a media gateway to the PSTN. For this example, let's say the number was +17205551212. 3) provB receives the request from provA and now needs to send a redirect to the PSTN number. Assume for this example that provA and provB have no business relationship, and therefore, provB will not accept a call to the PSTN from provA. That being said, probably the simplest thing that provB can do is use a tel: URI in the redirect. That avoids all ambiguity and logically requests that provA use a local media gateway to complete the call to the PSTN. If the tel: URI is not an option for some reason, then provB should send the redirect to sip:+17205551212@provA;user=3Dphone. Notice the use of provA, which the proxy at provB would have to derive, presumably using the "From" header. I don't think this is a good option, because there may be no reliable way to consistently derive the correct URI. I have to side with Paul, however, in saying that IF the redirect from provB actually refers to sip:+17205551212@provB (regardless of the presence of a user attribute), then the RFC is fairly clear -- the request that results from the redirect must be sent to provB, which will almost certainly fail. -- Tolga Tarhan -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Juha Heinanen Sent: Friday, December 09, 2005 8:59 AM To: Stastny Richard Cc: Sip Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try Stastny Richard writes: > A user enters a phone number, the UA sends it by default > to his provider A with > sip:+4312345@provA.com;user=3Dphone that is fine if the user is placing the call, but how about when the user wants to refer the calling party with 302 to his number on pstn network?=20 last time i checked, phones from paul's company use sip uri format, which according to paul's interpretation must be routed to whatever host part is listed there, which for sure get blocked by the proxy if the caller belongs to a different domain. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 13:55:52 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 1EknPL-0005Ql-QU; Fri, 09 Dec 2005 13:55:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EknPH-0005Of-I4; Fri, 09 Dec 2005 13:55:50 -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 NAA15185; Fri, 9 Dec 2005 13:54:52 -0500 (EST) 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 1EknPV-00072Z-Kl; Fri, 09 Dec 2005 13:56:02 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 09 Dec 2005 10:55:36 -0800 X-IronPort-AV: i="3.99,235,1131350400"; d="scan'208"; a="376241480:sNHT35167866" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB9It1AA022619; Fri, 9 Dec 2005 10:55:32 -0800 (PST) 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, 9 Dec 2005 13:55:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Fri, 9 Dec 2005 13:55:28 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA0EB9@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Thread-Index: AcX87Gb2NcBxC9lLRMGN4H2K6f935wAAzTQQ From: "Michael Hammer \(mhammer\)" To: , , "Thilo Salmon" , "Klaus Darilion" X-OriginalArrivalTime: 09 Dec 2005 18:55:29.0412 (UTC) FILETIME=[1FB44440:01C5FCF2] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 Is it not possible to be a domain owner and not provide any services? (cyber-squatter?) Being a domain owner is a bit removed from focus at hand. The relevant matter is that some entity is providing a service, be it data transport or session setup, an application, or whatever. I don't understand what the hang up is with using plain English to describe what it is. What happens when you take the next step and start to distinguish between public domain owners and private domain owners? Do we start saying that one entity is a transport domain owner versus a session setup domain owner? And what is it when they are both? A session transport domain owner? What happens when the entity operates or supports many domains? This could get really obtuse quickly. I don't object to using the domain owner as a litmus test for sorting out who is targeted with requests. But, let's not invent some affected form of speech just to confuse the uninitiated. Mike > -----Original Message----- > From: royrr@us.saic.com [mailto:royrr@us.saic.com]=20 > Sent: Friday, December 09, 2005 1:08 PM > To: henry@pulver.com; Michael Hammer (mhammer); Thilo Salmon;=20 > Klaus Darilion > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard;=20 > enum@ietf.org > Subject: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum]=20 > Re: [Sip] SIP AoR, tel and ENUM >=20 > Henry: > =20 > I think that it is the time to write an informational RFC on=20 > this because it is confusing to use the loose words like=20 > "service providers" in the context of the public Internet in the IETF. > =20 > Let us focus on the RFC what it should be like "Internet=20 > Domain Owner" and others in the context of IETF standardization works. > =20 > Best regards, > Radhika >=20 > _____ =20 >=20 > From: enum-bounces@ietf.org on behalf of Henry Sinnreich > Sent: Tue 12/6/2005 5:29 PM > To: 'Michael Hammer (mhammer)'; 'Thilo Salmon'; 'Klaus Darilion' > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny=20 > Richard'; enum@ietf.org > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM >=20 >=20 >=20 > Sorry for nitpicking: >=20 > >A provider is a provider. >=20 > A provider is a business model and att/SBC may differ from=20 > Google who uses a different business model (which is more=20 > significant measured in $$$?). >=20 > Didn't we agree to use the term "Internet domain owner" (we=20 > could shorten to IDOM or such)? >=20 > Internet domains are well defined in the IETF. > Business models for VoIP are better suited for other=20 > organizations, consortia or innovators who work to disrupt them :-) >=20 > Thanks, Henry >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 19:11:28 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 1EksKm-0002CH-2b; Fri, 09 Dec 2005 19:11:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EksKb-0001wI-39 for enum@megatron.ietf.org; Fri, 09 Dec 2005 19:11:26 -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 TAA04876 for ; Fri, 9 Dec 2005 19:10:22 -0500 (EST) Message-Id: <200512100010.TAA04876@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EksKq-0005ix-P4 for enum@ietf.org; Fri, 09 Dec 2005 19:11:34 -0500 Received: (qmail 23723 invoked by uid 510); 9 Dec 2005 19:16:32 -0500 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.142.34):. Processed in 0.960981 secs); 10 Dec 2005 00:16:32 -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.142.34):. Processed in 0.960981 secs Process 23718) Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.34) by 192.246.69.184 with SMTP; Sat, 10 Dec 2005 00:16:31 +0000 From: "Henry Sinnreich" To: "'Michael Hammer \(mhammer\)'" , , "'Thilo Salmon'" , "'Klaus Darilion'" , Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Fri, 9 Dec 2005 18:11:00 -0600 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX87Gb2NcBxC9lLRMGN4H2K6f935wAAzTQQAAq3O0A= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3DA0EB9@xmb-rtp-20b.amer.cisco.com> X-Antivirus-MYDOMAIN-Message-ID: <113417379183523718@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 'Stastny Richard' , enum@ietf.org 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 Radhika has a good proposal: > I think that it is the time to write an informational RFC on > this because it is confusing to use the loose words like > "service providers" in the context of the public Internet in the IETF. I disagree with Mike: > But, let's not invent some affected form of speech just to > confuse the uninitiated. This list is followed by experts who understand the principle of peering services layer by layer, independently. This was discussed and agreed in the WG during the 64 IETF. It is also related to "Internet Neutrality". Service provider at what layer? - Internet access, or - Application layer (L5 for SIP and RTP) for VoIP? There are scenarios without any VoIP service provider, such as when two IT networks exchange VoIP traffic and much other stuff, and they have different ISPs as well. Lots of people do happily VoIP without a service provider (a la carrier offering VoIP in some "triple play"). Neither does a home network or a community network qualify as a service provider though they are using VoIP outside their network. The proposed informational RFC (by Radhika) needs to accommodate such scenarious and an _IT network_ or a _home network_ are not _VoIP service providers_ even if you may want to make it sound like it is. Thanks, Henry -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Friday, December 09, 2005 12:55 PM To: royrr@us.saic.com; henry@pulver.com; Thilo Salmon; Klaus Darilion Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; enum@ietf.org Subject: RE: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Is it not possible to be a domain owner and not provide any services? (cyber-squatter?) Being a domain owner is a bit removed from focus at hand. The relevant matter is that some entity is providing a service, be it data transport or session setup, an application, or whatever. I don't understand what the hang up is with using plain English to describe what it is. What happens when you take the next step and start to distinguish between public domain owners and private domain owners? Do we start saying that one entity is a transport domain owner versus a session setup domain owner? And what is it when they are both? A session transport domain owner? What happens when the entity operates or supports many domains? This could get really obtuse quickly. I don't object to using the domain owner as a litmus test for sorting out who is targeted with requests. But, let's not invent some affected form of speech just to confuse the uninitiated. Mike > -----Original Message----- > From: royrr@us.saic.com [mailto:royrr@us.saic.com] > Sent: Friday, December 09, 2005 1:08 PM > To: henry@pulver.com; Michael Hammer (mhammer); Thilo Salmon; > Klaus Darilion > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; > enum@ietf.org > Subject: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum] > Re: [Sip] SIP AoR, tel and ENUM > > Henry: > > I think that it is the time to write an informational RFC on > this because it is confusing to use the loose words like > "service providers" in the context of the public Internet in the IETF. > > Let us focus on the RFC what it should be like "Internet > Domain Owner" and others in the context of IETF standardization works. > > Best regards, > Radhika > > _____ > > From: enum-bounces@ietf.org on behalf of Henry Sinnreich > Sent: Tue 12/6/2005 5:29 PM > To: 'Michael Hammer (mhammer)'; 'Thilo Salmon'; 'Klaus Darilion' > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny > Richard'; enum@ietf.org > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > Sorry for nitpicking: > > >A provider is a provider. > > A provider is a business model and att/SBC may differ from > Google who uses a different business model (which is more > significant measured in $$$?). > > Didn't we agree to use the term "Internet domain owner" (we > could shorten to IDOM or such)? > > Internet domains are well defined in the IETF. > Business models for VoIP are better suited for other > organizations, consortia or innovators who work to disrupt them :-) > > Thanks, Henry > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 19:47:30 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 1Ekste-0007Z8-NC; Fri, 09 Dec 2005 19:47:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkstY-0007YE-SP; Fri, 09 Dec 2005 19:47:29 -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 TAA16171; Fri, 9 Dec 2005 19:46:22 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eksti-00011k-A6; Fri, 09 Dec 2005 19:47:35 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Dec 2005 16:47:06 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,236,1131350400"; d="scan'208"; a="16959432:sNHT26028828" 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 jBA0ks4X008587; Fri, 9 Dec 2005 19:46:54 -0500 (EST) 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, 9 Dec 2005 19:46:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Fri, 9 Dec 2005 19:46:53 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA0FC4@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Thread-Index: AcX87Gb2NcBxC9lLRMGN4H2K6f935wAAzTQQAAq3O0AAAUUlwA== From: "Michael Hammer \(mhammer\)" To: , , "Thilo Salmon" , "Klaus Darilion" X-OriginalArrivalTime: 10 Dec 2005 00:46:54.0373 (UTC) FILETIME=[3751FD50:01C5FD23] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 Henry, I try to follow discussion through the mail list and in what gets reported in meeting notes, but must have missed where this terminology was discussed and decided. Could you provide me a pointer to which WG meeting notes to review on this. For the benefit of those that need to know this long after IETF 64 is forgotten, this should be documented, so I support the idea of an informational RFC. It would be good to share this with other groups, so we are all on the same sheet of music. And I will be sure to use initial caps to highlight use of the formal term. > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com]=20 > Sent: Friday, December 09, 2005 7:11 PM > To: Michael Hammer (mhammer); royrr@us.saic.com; 'Thilo=20 > Salmon'; 'Klaus Darilion'; royrr@us.saic.com > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny=20 > Richard'; enum@ietf.org > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM >=20 > Radhika has a good proposal: >=20 > > I think that it is the time to write an informational RFC on this=20 > > because it is confusing to use the loose words like "service=20 > > providers" in the context of the public Internet in the IETF. >=20 > I disagree with Mike: >=20 > > But, let's not invent some affected form of speech just to=20 > confuse the=20 > > uninitiated. >=20 > This list is followed by experts who understand the principle=20 > of peering services layer by layer, independently. This was=20 > discussed and agreed in the WG during the 64 IETF. It is also=20 > related to "Internet Neutrality". >=20 > Service provider at what layer? > - Internet access, or > - Application layer (L5 for SIP and RTP) for VoIP? Your own words indicate that services are provided at multiple layers. > There are scenarios without any VoIP service provider, such=20 > as when two IT networks exchange VoIP traffic and much other=20 > stuff, and they have different ISPs as well. Lots of people=20 > do happily VoIP without a service provider (a la carrier=20 > offering VoIP in some "triple play"). "without a SP" with example of "carrier offering VoIP" seems self-contradictory > Neither does a home network or a community network qualify as=20 > a service provider though they are using VoIP outside their network. So, if a service (e.g. Internet access) is provided for free, there is no service provider? But, if a service (e.g. Internet access) is provided for cost, an ISP is a service provider? This is when I feel like Alice in Wonderland. But, I guess we can agree to disagree, and move on with what the "experts" have chosen. Mike > The proposed informational RFC (by Radhika) needs to=20 > accommodate such scenarious and an _IT network_ or a _home=20 > network_ are not _VoIP service providers_ even if you may=20 > want to make it sound like it is.=20 >=20 > Thanks, Henry > =20 >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, December 09, 2005 12:55 PM > To: royrr@us.saic.com; henry@pulver.com; Thilo Salmon; Klaus Darilion > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard;=20 > enum@ietf.org > Subject: RE: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE:=20 > [Enum] Re: [Sip] SIP AoR, tel and ENUM >=20 > Is it not possible to be a domain owner and not provide any services? > (cyber-squatter?) >=20 > Being a domain owner is a bit removed from focus at hand. =20 > The relevant matter is that some entity is providing a=20 > service, be it data transport or session setup, an=20 > application, or whatever. I don't understand what the hang=20 > up is with using plain English to describe what it is. What=20 > happens when you take the next step and start to distinguish=20 > between public domain owners and private domain owners? Do=20 > we start saying that one entity is a transport domain owner=20 > versus a session setup domain owner? And what is it when=20 > they are both? A session transport domain owner? What=20 > happens when the entity operates or supports many domains? >=20 > This could get really obtuse quickly. I don't object to=20 > using the domain owner as a litmus test for sorting out who=20 > is targeted with requests. But, let's not invent some=20 > affected form of speech just to confuse the uninitiated. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: royrr@us.saic.com [mailto:royrr@us.saic.com] > > Sent: Friday, December 09, 2005 1:08 PM > > To: henry@pulver.com; Michael Hammer (mhammer); Thilo Salmon; Klaus=20 > > Darilion > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard;=20 > > enum@ietf.org > > Subject: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum] > > Re: [Sip] SIP AoR, tel and ENUM > >=20 > > Henry: > > =20 > > I think that it is the time to write an informational RFC on this=20 > > because it is confusing to use the loose words like "service=20 > > providers" in the context of the public Internet in the IETF. > > =20 > > Let us focus on the RFC what it should be like "Internet=20 > Domain Owner"=20 > > and others in the context of IETF standardization works. > > =20 > > Best regards, > > Radhika > >=20 > > _____ > >=20 > > From: enum-bounces@ietf.org on behalf of Henry Sinnreich > > Sent: Tue 12/6/2005 5:29 PM > > To: 'Michael Hammer (mhammer)'; 'Thilo Salmon'; 'Klaus Darilion' > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny Richard';=20 > > enum@ietf.org > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > >=20 > >=20 > >=20 > > Sorry for nitpicking: > >=20 > > >A provider is a provider. > >=20 > > A provider is a business model and att/SBC may differ from=20 > Google who=20 > > uses a different business model (which is more significant=20 > measured in=20 > > $$$?). > >=20 > > Didn't we agree to use the term "Internet domain owner" (we could=20 > > shorten to IDOM or such)? > >=20 > > Internet domains are well defined in the IETF. > > Business models for VoIP are better suited for other organizations,=20 > > consortia or innovators who work to disrupt them :-) > >=20 > > Thanks, Henry > >=20 > >=20 >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Dec 09 20:50:22 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 1EktsU-0002LJ-Ar; Fri, 09 Dec 2005 20:50:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EktsO-0002Hk-Kf for enum@megatron.ietf.org; Fri, 09 Dec 2005 20:50:21 -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 UAA23794 for ; Fri, 9 Dec 2005 20:49:12 -0500 (EST) Message-Id: <200512100149.UAA23794@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EktsX-0003DA-JA for enum@ietf.org; Fri, 09 Dec 2005 20:50:26 -0500 Received: (qmail 28388 invoked by uid 510); 9 Dec 2005 20:55:31 -0500 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.142.34):. Processed in 0.987271 secs); 10 Dec 2005 01:55:31 -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.142.34):. Processed in 0.987271 secs Process 28383) Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.34) by 192.246.69.184 with SMTP; Sat, 10 Dec 2005 01:55:30 +0000 From: "Henry Sinnreich" To: "'Michael Hammer \(mhammer\)'" , , "'Thilo Salmon'" , "'Klaus Darilion'" Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Fri, 9 Dec 2005 19:49:57 -0600 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX87Gb2NcBxC9lLRMGN4H2K6f935wAAzTQQAAq3O0AAAUUlwAACZzOg In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3DA0FC4@xmb-rtp-20b.amer.cisco.com> X-Antivirus-MYDOMAIN-Message-ID: <113417973083528383@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 'Stastny Richard' , enum@ietf.org 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 Mike, I am happy there are three of us in agreement and I suppose we can conclude the trail on this topic: >For the benefit of those that need to know this long after IETF 64 is >forgotten, this should be documented, so I support the idea of an >informational RFC. Thanks, Henry -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Friday, December 09, 2005 6:47 PM To: henry@pulver.com; royrr@us.saic.com; Thilo Salmon; Klaus Darilion Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; enum@ietf.org Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Henry, I try to follow discussion through the mail list and in what gets reported in meeting notes, but must have missed where this terminology was discussed and decided. Could you provide me a pointer to which WG meeting notes to review on this. For the benefit of those that need to know this long after IETF 64 is forgotten, this should be documented, so I support the idea of an informational RFC. It would be good to share this with other groups, so we are all on the same sheet of music. And I will be sure to use initial caps to highlight use of the formal term. > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com] > Sent: Friday, December 09, 2005 7:11 PM > To: Michael Hammer (mhammer); royrr@us.saic.com; 'Thilo > Salmon'; 'Klaus Darilion'; royrr@us.saic.com > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny > Richard'; enum@ietf.org > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > Radhika has a good proposal: > > > I think that it is the time to write an informational RFC on this > > because it is confusing to use the loose words like "service > > providers" in the context of the public Internet in the IETF. > > I disagree with Mike: > > > But, let's not invent some affected form of speech just to > confuse the > > uninitiated. > > This list is followed by experts who understand the principle > of peering services layer by layer, independently. This was > discussed and agreed in the WG during the 64 IETF. It is also > related to "Internet Neutrality". > > Service provider at what layer? > - Internet access, or > - Application layer (L5 for SIP and RTP) for VoIP? Your own words indicate that services are provided at multiple layers. > There are scenarios without any VoIP service provider, such > as when two IT networks exchange VoIP traffic and much other > stuff, and they have different ISPs as well. Lots of people > do happily VoIP without a service provider (a la carrier > offering VoIP in some "triple play"). "without a SP" with example of "carrier offering VoIP" seems self-contradictory > Neither does a home network or a community network qualify as > a service provider though they are using VoIP outside their network. So, if a service (e.g. Internet access) is provided for free, there is no service provider? But, if a service (e.g. Internet access) is provided for cost, an ISP is a service provider? This is when I feel like Alice in Wonderland. But, I guess we can agree to disagree, and move on with what the "experts" have chosen. Mike > The proposed informational RFC (by Radhika) needs to > accommodate such scenarious and an _IT network_ or a _home > network_ are not _VoIP service providers_ even if you may > want to make it sound like it is. > > Thanks, Henry > > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, December 09, 2005 12:55 PM > To: royrr@us.saic.com; henry@pulver.com; Thilo Salmon; Klaus Darilion > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; > enum@ietf.org > Subject: RE: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: > [Enum] Re: [Sip] SIP AoR, tel and ENUM > > Is it not possible to be a domain owner and not provide any services? > (cyber-squatter?) > > Being a domain owner is a bit removed from focus at hand. > The relevant matter is that some entity is providing a > service, be it data transport or session setup, an > application, or whatever. I don't understand what the hang > up is with using plain English to describe what it is. What > happens when you take the next step and start to distinguish > between public domain owners and private domain owners? Do > we start saying that one entity is a transport domain owner > versus a session setup domain owner? And what is it when > they are both? A session transport domain owner? What > happens when the entity operates or supports many domains? > > This could get really obtuse quickly. I don't object to > using the domain owner as a litmus test for sorting out who > is targeted with requests. But, let's not invent some > affected form of speech just to confuse the uninitiated. > > Mike > > > > -----Original Message----- > > From: royrr@us.saic.com [mailto:royrr@us.saic.com] > > Sent: Friday, December 09, 2005 1:08 PM > > To: henry@pulver.com; Michael Hammer (mhammer); Thilo Salmon; Klaus > > Darilion > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; > > enum@ietf.org > > Subject: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum] > > Re: [Sip] SIP AoR, tel and ENUM > > > > Henry: > > > > I think that it is the time to write an informational RFC on this > > because it is confusing to use the loose words like "service > > providers" in the context of the public Internet in the IETF. > > > > Let us focus on the RFC what it should be like "Internet > Domain Owner" > > and others in the context of IETF standardization works. > > > > Best regards, > > Radhika > > > > _____ > > > > From: enum-bounces@ietf.org on behalf of Henry Sinnreich > > Sent: Tue 12/6/2005 5:29 PM > > To: 'Michael Hammer (mhammer)'; 'Thilo Salmon'; 'Klaus Darilion' > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny Richard'; > > enum@ietf.org > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > > > > > Sorry for nitpicking: > > > > >A provider is a provider. > > > > A provider is a business model and att/SBC may differ from > Google who > > uses a different business model (which is more significant > measured in > > $$$?). > > > > Didn't we agree to use the term "Internet domain owner" (we could > > shorten to IDOM or such)? > > > > Internet domains are well defined in the IETF. > > Business models for VoIP are better suited for other organizations, > > consortia or innovators who work to disrupt them :-) > > > > Thanks, Henry > > > > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Dec 10 10:46:25 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 1El6vZ-0004xG-8B; Sat, 10 Dec 2005 10:46:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkmSH-0000tr-Uu; Fri, 09 Dec 2005 12:55:11 -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 MAA07681; Fri, 9 Dec 2005 12:53:43 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkmSJ-0004fO-9W; Fri, 09 Dec 2005 12:54:52 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 60CB86C017; Fri, 9 Dec 2005 12:54:29 -0500 (EST) Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try From: "Dale R. Worley" To: Juha Heinanen In-Reply-To: <17305.42511.328358.495586@rautu.tutpro.com> References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc> <43998FD7.20207@cisco.com> <17305.39909.629606.843484@rautu.tutpro.com> <4399A2AA.1020506@cisco.com> <17305.42511.328358.495586@rautu.tutpro.com> Content-Type: text/plain Date: Fri, 09 Dec 2005 12:54:29 -0500 Message-Id: <1134150869.919.18.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 10 Dec 2005 10:46:22 -0500 Cc: enum@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , Sip , Paul Kyzivat X-BeenThere: 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 Fri, 2005-12-09 at 17:43 +0200, Juha Heinanen wrote: > i'm pretty sure that i have read in some rfc that > sip:+@;user=phone is EQUIVALENT with tel:+, > i.e., they are two textual representations of the same thing, but can't > check it now, because i'm travelling in train. A lot of RFCs hint at such a thing. The closest I've seen is section 3 of RFC 3824. But the general drift is not that they are *equivalent*, but that the tel: URI can be mapped into the sip: URI; there seems to be no hint that the mapping can be reversed. Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Dec 10 10:46:25 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 1El6vZ-0004xo-Q7; Sat, 10 Dec 2005 10:46:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekmkj-0004Er-Cy; Fri, 09 Dec 2005 13:13: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 NAA09821; Fri, 9 Dec 2005 13:12:57 -0500 (EST) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekmku-0005Q9-Vf; Fri, 09 Dec 2005 13:14:06 -0500 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Fri, 9 Dec 2005 13:13:18 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005120913131726881 ; Fri, 09 Dec 2005 13:13:18 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Fri, 9 Dec 2005 13:13:13 -0500 Message-Id: <84E5D7F15F52D34DA84C9C90ACE6554F623382@0591-its-exmp01.us.saic.com> From: "Roy, Radhika R." To: henry@pulver.com, "Michael Hammer (mhammer)" , Thilo Salmon , Klaus Darilion Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Fri, 9 Dec 2005 13:07:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-Mailman-Approved-At: Sat, 10 Dec 2005 10:46:21 -0500 Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 Henry: I think that it is the time to write an informational RFC on this because it is confusing to use the loose words like "service providers" in the context of the public Internet in the IETF. Let us focus on the RFC what it should be like "Internet Domain Owner" and others in the context of IETF standardization works. Best regards, Radhika _____ From: enum-bounces@ietf.org on behalf of Henry Sinnreich Sent: Tue 12/6/2005 5:29 PM To: 'Michael Hammer (mhammer)'; 'Thilo Salmon'; 'Klaus Darilion' Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny Richard'; enum@ietf.org Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Sorry for nitpicking: >A provider is a provider. A provider is a business model and att/SBC may differ from Google who uses a different business model (which is more significant measured in $$$?). Didn't we agree to use the term "Internet domain owner" (we could shorten to IDOM or such)? Internet domains are well defined in the IETF. Business models for VoIP are better suited for other organizations, consortia or innovators who work to disrupt them :-) Thanks, Henry _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Dec 12 09:13:46 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 1EloR0-0000iJ-I4; Mon, 12 Dec 2005 09:13:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EloQv-0000gh-06; Mon, 12 Dec 2005 09:13:45 -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 JAA26983; Mon, 12 Dec 2005 09:12:36 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EloRb-0005h9-0C; Mon, 12 Dec 2005 09:14:23 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Dec 2005 09:13:23 -0500 X-IronPort-AV: i="3.99,243,1131339600"; d="scan'208"; a="77582927:sNHT32373192" 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 jBCED0Ub008016; Mon, 12 Dec 2005 09:13:17 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Dec 2005 09:13:08 -0500 Received: from [161.44.79.233] ([161.44.79.233]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Dec 2005 09:13:07 -0500 Message-ID: <439D8572.1050909@cisco.com> Date: Mon, 12 Dec 2005 09:13:06 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tolga Tarhan Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try References: <383A9E7C48D9694FAD43334A7563AA6C8C4170@FILEVAULT.windows.deltel.com> In-Reply-To: <383A9E7C48D9694FAD43334A7563AA6C8C4170@FILEVAULT.windows.deltel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2005 14:13:07.0843 (UTC) FILETIME=[2CFB3D30:01C5FF26] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: Sip , enum@ietf.org, Juha Heinanen , 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 Tolga Tarhan wrote: > All, > > Just to be clear, let me define my understanding of Juha's scenario: > > 1) UserA@provA sends an invite to his local proxy (provA) for > UserB@provB. > > 2) UserB has told his provider that he wants all of his calls redirected > to his PSTN number. Clearly, userB's intent is that the call be > completed through a media gateway to the PSTN. For this example, let's > say the number was +17205551212. > > 3) provB receives the request from provA and now needs to send a > redirect to the PSTN number. Assume for this example that provA and > provB have no business relationship, and therefore, provB will not > accept a call to the PSTN from provA. > > > That being said, probably the simplest thing that provB can do is use a > tel: URI in the redirect. That avoids all ambiguity and logically > requests that provA use a local media gateway to complete the call to > the PSTN. > > If the tel: URI is not an option for some reason, then provB should send > the redirect to sip:+17205551212@provA;user=phone. If provA and provB have no business relationship, then it is inappropriate for provB to create a uri in the domain of provA. This is different from the case Richard gave, where a uri is rewritten to the domain of the target when forwarding, because that presumes a business relationship. > Notice the use of > provA, which the proxy at provB would have to derive, presumably using > the "From" header. I don't think this is a good option, because there > may be no reliable way to consistently derive the correct URI. Right! > I have to side with Paul, however, in saying that IF the redirect from > provB actually refers to sip:+17205551212@provB (regardless of the > presence of a user attribute), then the RFC is fairly clear -- the > request that results from the redirect must be sent to provB, which will > almost certainly fail. Paul > -- > Tolga Tarhan > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Juha Heinanen > Sent: Friday, December 09, 2005 8:59 AM > To: Stastny Richard > Cc: Sip > Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try > > Stastny Richard writes: > > > A user enters a phone number, the UA sends it by default > > to his provider A with > > sip:+4312345@provA.com;user=phone > > that is fine if the user is placing the call, but how about when the > user wants to refer the calling party with 302 to his number on pstn > network? > > last time i checked, phones from paul's company use sip uri format, > which according to paul's interpretation must be routed to whatever host > part is listed there, which for sure get blocked by the proxy if the > caller belongs to a different domain. > > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Dec 12 09:19:02 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 1EloW6-0001KQ-GO; Mon, 12 Dec 2005 09:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EloW2-0001Jk-VJ; Mon, 12 Dec 2005 09:19:01 -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 JAA27490; Mon, 12 Dec 2005 09:18:02 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EloWq-0005rx-6N; Mon, 12 Dec 2005 09:19:49 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 12 Dec 2005 06:18:48 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBCEIGMw000075; Mon, 12 Dec 2005 06:18:43 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Dec 2005 09:18:40 -0500 Received: from [161.44.79.233] ([161.44.79.233]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Dec 2005 09:18:40 -0500 Message-ID: <439D86BF.1090506@cisco.com> Date: Mon, 12 Dec 2005 09:18:39 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Klaus Darilion Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc> <43998FD7.20207@cisco.com> <43999607.7060900@pernau.at> In-Reply-To: <43999607.7060900@pernau.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2005 14:18:40.0040 (UTC) FILETIME=[F2FC7A80:01C5FF26] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , 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 Klaus Darilion wrote: > Hi Paul! > > Thanks for clarification. I always had problem to understand the proper > meaning of this parameter. Is this somewhere described in detail? I also > rememeber a discussion to remove this parameter completly. I'm not sure there is a good description anywhere. It has been debated many times. What I wrote is my best understanding given all the discussion that has gone on in the past. Paul > regards > klaus > > Paul Kyzivat wrote: > >> >> >> Stastny Richard wrote: >> >>>> Thus, IMO the paramter is more interesting for the outgoing >>>> provider. If >>>> the proxy of provA receives a request from its customer for >>>> sip:+4312345@provA.com >>>> this would adress the lokal user +4312345. A request for >>>> sip:+4312345@provA.com;user=phone >>>> would address the E.164 phone number +4312345 >>> >>> >>> >>> >>> Yesss, exactly ;-) >>> >>> And since you rarely have local users start with +, >>> sip:4312345@provA.com is more usual >>> >>> and >>> sip:+4312345@provA.com >>> should not happen, causeing always confusion >> >> >> >> It seems that many people intend to use a namespace for usernames >> where there is no overlap of names and numbers: there is no >> possibility for a *name* +4312345 that has a different meaning than >> the E.164 number +4312345. In that case the presence or absence of the >> ";user=phone" is irrelevant as far as its meaning within the owning >> domain. In that case the ";user=phone" is more a matter of informing >> the world that this is intended to be a phone number. >> >> Also, as it happens, while >> sip:+4312345@provA.com >> sip:+4312345@provA.com;user=phone >> are not equal by uri comparison rules, they are equal according to the >> rules that 3261 applies to the targets of registration. So, you can't >> really have them mean different things. >> >> Paul >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Dec 12 13:30:57 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 1ElsRt-0008H0-LC; Mon, 12 Dec 2005 13:30:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElsRq-0008C2-LI for enum@megatron.ietf.org; Mon, 12 Dec 2005 13:30:55 -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 NAA27786 for ; Mon, 12 Dec 2005 13:29:50 -0500 (EST) Received: from mail.twang.net ([62.105.161.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElsSX-0006MG-Iv for enum@ietf.org; Mon, 12 Dec 2005 13:31:39 -0500 Received: from [62.105.167.210] by mail.twang.net (GMS 10.03.3304/NY1676.00.b5a0c909) with ESMTP id dfeihbba for enum@ietf.org; Mon, 12 Dec 2005 18:21:31 +0000 Received: from mail pickup service by exchange01.twang.net with Microsoft SMTPSVC; Mon, 12 Dec 2005 18:21:23 +0000 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mailcleaner.twang.net (Vircom SMTPRS 4.2.425.16) with ESMTP id for ; Mon, 12 Dec 2005 08:06:23 +0000 X-Modus-ReverseDNS: OK X-Modus-BlackList: 132.151.6.71=OK;sip-bounces@ietf.org=OK X-Modus-RBL: 132.151.6.71=OK X-Modus-Trusted: 132.151.6.71=NO 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 1EliZQ-0004ry-L4; Mon, 12 Dec 2005 02:58:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EktsO-0002Hj-CK for sip@megatron.ietf.org; Fri, 09 Dec 2005 20:50:21 -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 UAA23796 for ; Fri, 9 Dec 2005 20:49:12 -0500 (EST) Message-Id: <200512100149.UAA23796@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EktsX-0003DB-JE for sip@ietf.org; Fri, 09 Dec 2005 20:50:26 -0500 Received: (qmail 28388 invoked by uid 510); 9 Dec 2005 20:55:31 -0500 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.142.34):. Processed in 0.987271 secs); 10 Dec 2005 01:55:31 -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.142.34):. Processed in 0.987271 secs Process 28383) Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.34) by 192.246.69.184 with SMTP; Sat, 10 Dec 2005 01:55:30 +0000 From: "Henry Sinnreich" To: "'Michael Hammer \(mhammer\)'" , , "'Thilo Salmon'" , "'Klaus Darilion'" Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Fri, 9 Dec 2005 19:49:57 -0600 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX87Gb2NcBxC9lLRMGN4H2K6f935wAAzTQQAAq3O0AAAUUlwAACZzOg In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3DA0FC4@xmb-rtp-20b.amer.cisco.com> X-Antivirus-MYDOMAIN-Message-ID: <113417973083528383@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 12 Dec 2005 02:58:00 -0500 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 12 Dec 2005 18:21:23.0421 (UTC) FILETIME=[DB7010D0:01C5FF48] X-AntiSpam: Checked for restricted content by Gordano's AntiSpam Software X-Spam-Score: 0.9 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 'Stastny Richard' , enum@ietf.org X-BeenThere: enum@ietf.org 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 Mike, I am happy there are three of us in agreement and I suppose we can conclude the trail on this topic: >For the benefit of those that need to know this long after IETF 64 is >forgotten, this should be documented, so I support the idea of an >informational RFC. Thanks, Henry -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Friday, December 09, 2005 6:47 PM To: henry@pulver.com; royrr@us.saic.com; Thilo Salmon; Klaus Darilion Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; enum@ietf.org Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Henry, I try to follow discussion through the mail list and in what gets reported in meeting notes, but must have missed where this terminology was discussed and decided. Could you provide me a pointer to which WG meeting notes to review on this. For the benefit of those that need to know this long after IETF 64 is forgotten, this should be documented, so I support the idea of an informational RFC. It would be good to share this with other groups, so we are all on the same sheet of music. And I will be sure to use initial caps to highlight use of the formal term. > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com] > Sent: Friday, December 09, 2005 7:11 PM > To: Michael Hammer (mhammer); royrr@us.saic.com; 'Thilo > Salmon'; 'Klaus Darilion'; royrr@us.saic.com > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny > Richard'; enum@ietf.org > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > Radhika has a good proposal: > > > I think that it is the time to write an informational RFC on this > > because it is confusing to use the loose words like "service > > providers" in the context of the public Internet in the IETF. > > I disagree with Mike: > > > But, let's not invent some affected form of speech just to > confuse the > > uninitiated. > > This list is followed by experts who understand the principle > of peering services layer by layer, independently. This was > discussed and agreed in the WG during the 64 IETF. It is also > related to "Internet Neutrality". > > Service provider at what layer? > - Internet access, or > - Application layer (L5 for SIP and RTP) for VoIP? Your own words indicate that services are provided at multiple layers. > There are scenarios without any VoIP service provider, such > as when two IT networks exchange VoIP traffic and much other > stuff, and they have different ISPs as well. Lots of people > do happily VoIP without a service provider (a la carrier > offering VoIP in some "triple play"). "without a SP" with example of "carrier offering VoIP" seems self-contradictory > Neither does a home network or a community network qualify as > a service provider though they are using VoIP outside their network. So, if a service (e.g. Internet access) is provided for free, there is no service provider? But, if a service (e.g. Internet access) is provided for cost, an ISP is a service provider? This is when I feel like Alice in Wonderland. But, I guess we can agree to disagree, and move on with what the "experts" have chosen. Mike > The proposed informational RFC (by Radhika) needs to > accommodate such scenarious and an _IT network_ or a _home > network_ are not _VoIP service providers_ even if you may > want to make it sound like it is. > > Thanks, Henry > > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, December 09, 2005 12:55 PM > To: royrr@us.saic.com; henry@pulver.com; Thilo Salmon; Klaus Darilion > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; > enum@ietf.org > Subject: RE: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: > [Enum] Re: [Sip] SIP AoR, tel and ENUM > > Is it not possible to be a domain owner and not provide any services? > (cyber-squatter?) > > Being a domain owner is a bit removed from focus at hand. > The relevant matter is that some entity is providing a > service, be it data transport or session setup, an > application, or whatever. I don't understand what the hang > up is with using plain English to describe what it is. What > happens when you take the next step and start to distinguish > between public domain owners and private domain owners? Do > we start saying that one entity is a transport domain owner > versus a session setup domain owner? And what is it when > they are both? A session transport domain owner? What > happens when the entity operates or supports many domains? > > This could get really obtuse quickly. I don't object to > using the domain owner as a litmus test for sorting out who > is targeted with requests. But, let's not invent some > affected form of speech just to confuse the uninitiated. > > Mike > > > > -----Original Message----- > > From: royrr@us.saic.com [mailto:royrr@us.saic.com] > > Sent: Friday, December 09, 2005 1:08 PM > > To: henry@pulver.com; Michael Hammer (mhammer); Thilo Salmon; Klaus > > Darilion > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; > > enum@ietf.org > > Subject: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum] > > Re: [Sip] SIP AoR, tel and ENUM > > > > Henry: > > > > I think that it is the time to write an informational RFC on this > > because it is confusing to use the loose words like "service > > providers" in the context of the public Internet in the IETF. > > > > Let us focus on the RFC what it should be like "Internet > Domain Owner" > > and others in the context of IETF standardization works. > > > > Best regards, > > Radhika > > > > _____ > > > > From: enum-bounces@ietf.org on behalf of Henry Sinnreich > > Sent: Tue 12/6/2005 5:29 PM > > To: 'Michael Hammer (mhammer)'; 'Thilo Salmon'; 'Klaus Darilion' > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny Richard'; > > enum@ietf.org > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > > > > > Sorry for nitpicking: > > > > >A provider is a provider. > > > > A provider is a business model and att/SBC may differ from > Google who > > uses a different business model (which is more significant > measured in > > $$$?). > > > > Didn't we agree to use the term "Internet domain owner" (we could > > shorten to IDOM or such)? > > > > Internet domains are well defined in the IETF. > > Business models for VoIP are better suited for other organizations, > > consortia or innovators who work to disrupt them :-) > > > > Thanks, Henry > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Dec 12 13:31:01 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 1ElsRx-0008Hj-LT; Mon, 12 Dec 2005 13:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElsRu-0008HZ-NS for enum@megatron.ietf.org; Mon, 12 Dec 2005 13:31:00 -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 NAA27816 for ; Mon, 12 Dec 2005 13:30:02 -0500 (EST) Received: from mail.twang.net ([62.105.161.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElsSj-0006P6-M3 for enum@ietf.org; Mon, 12 Dec 2005 13:31:51 -0500 Received: from [62.105.167.210] by mail.twang.net (GMS 10.03.3304/NY1676.00.b5a0c909) with ESMTP id dzdihbba for enum@ietf.org; Mon, 12 Dec 2005 18:21:12 +0000 Received: from mail pickup service by exchange01.twang.net with Microsoft SMTPSVC; Mon, 12 Dec 2005 18:20:13 +0000 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mailcleaner.twang.net (Vircom SMTPRS 4.2.425.16) with ESMTP id for ; Mon, 12 Dec 2005 08:10:57 +0000 X-Modus-ReverseDNS: OK X-Modus-BlackList: 132.151.6.71=OK;sip-bounces@ietf.org=OK X-Modus-RBL: 132.151.6.71=OK X-Modus-Trusted: 132.151.6.71=NO 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 1EliZP-0004rU-Ik; Mon, 12 Dec 2005 02:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EksKb-0001wO-24 for sip@megatron.ietf.org; Fri, 09 Dec 2005 19:11:22 -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 TAA04878 for ; Fri, 9 Dec 2005 19:10:22 -0500 (EST) Message-Id: <200512100010.TAA04878@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EksKq-0005iy-P3 for sip@ietf.org; Fri, 09 Dec 2005 19:11:34 -0500 Received: (qmail 23723 invoked by uid 510); 9 Dec 2005 19:16:32 -0500 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.142.34):. Processed in 0.960981 secs); 10 Dec 2005 00:16:32 -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.142.34):. Processed in 0.960981 secs Process 23718) Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.34) by 192.246.69.184 with SMTP; Sat, 10 Dec 2005 00:16:31 +0000 From: "Henry Sinnreich" To: "'Michael Hammer \(mhammer\)'" , , "'Thilo Salmon'" , "'Klaus Darilion'" , Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Fri, 9 Dec 2005 18:11:00 -0600 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX87Gb2NcBxC9lLRMGN4H2K6f935wAAzTQQAAq3O0A= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3DA0EB9@xmb-rtp-20b.amer.cisco.com> X-Antivirus-MYDOMAIN-Message-ID: <113417379183523718@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 12 Dec 2005 02:58:00 -0500 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 12 Dec 2005 18:20:13.0249 (UTC) FILETIME=[B19CAB10:01C5FF48] X-AntiSpam: Checked for restricted content by Gordano's AntiSpam Software X-Spam-Score: 0.9 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, voipeer@lists.uoregon.edu, 'Stastny Richard' , enum@ietf.org X-BeenThere: enum@ietf.org 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 Radhika has a good proposal: > I think that it is the time to write an informational RFC on > this because it is confusing to use the loose words like > "service providers" in the context of the public Internet in the IETF. I disagree with Mike: > But, let's not invent some affected form of speech just to > confuse the uninitiated. This list is followed by experts who understand the principle of peering services layer by layer, independently. This was discussed and agreed in the WG during the 64 IETF. It is also related to "Internet Neutrality". Service provider at what layer? - Internet access, or - Application layer (L5 for SIP and RTP) for VoIP? There are scenarios without any VoIP service provider, such as when two IT networks exchange VoIP traffic and much other stuff, and they have different ISPs as well. Lots of people do happily VoIP without a service provider (a la carrier offering VoIP in some "triple play"). Neither does a home network or a community network qualify as a service provider though they are using VoIP outside their network. The proposed informational RFC (by Radhika) needs to accommodate such scenarious and an _IT network_ or a _home network_ are not _VoIP service providers_ even if you may want to make it sound like it is. Thanks, Henry -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Friday, December 09, 2005 12:55 PM To: royrr@us.saic.com; henry@pulver.com; Thilo Salmon; Klaus Darilion Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; enum@ietf.org Subject: RE: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Is it not possible to be a domain owner and not provide any services? (cyber-squatter?) Being a domain owner is a bit removed from focus at hand. The relevant matter is that some entity is providing a service, be it data transport or session setup, an application, or whatever. I don't understand what the hang up is with using plain English to describe what it is. What happens when you take the next step and start to distinguish between public domain owners and private domain owners? Do we start saying that one entity is a transport domain owner versus a session setup domain owner? And what is it when they are both? A session transport domain owner? What happens when the entity operates or supports many domains? This could get really obtuse quickly. I don't object to using the domain owner as a litmus test for sorting out who is targeted with requests. But, let's not invent some affected form of speech just to confuse the uninitiated. Mike > -----Original Message----- > From: royrr@us.saic.com [mailto:royrr@us.saic.com] > Sent: Friday, December 09, 2005 1:08 PM > To: henry@pulver.com; Michael Hammer (mhammer); Thilo Salmon; > Klaus Darilion > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; > enum@ietf.org > Subject: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum] > Re: [Sip] SIP AoR, tel and ENUM > > Henry: > > I think that it is the time to write an informational RFC on > this because it is confusing to use the loose words like > "service providers" in the context of the public Internet in the IETF. > > Let us focus on the RFC what it should be like "Internet > Domain Owner" and others in the context of IETF standardization works. > > Best regards, > Radhika > > _____ > > From: enum-bounces@ietf.org on behalf of Henry Sinnreich > Sent: Tue 12/6/2005 5:29 PM > To: 'Michael Hammer (mhammer)'; 'Thilo Salmon'; 'Klaus Darilion' > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny > Richard'; enum@ietf.org > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM > > > > Sorry for nitpicking: > > >A provider is a provider. > > A provider is a business model and att/SBC may differ from > Google who uses a different business model (which is more > significant measured in $$$?). > > Didn't we agree to use the term "Internet domain owner" (we > could shorten to IDOM or such)? > > Internet domains are well defined in the IETF. > Business models for VoIP are better suited for other > organizations, consortia or innovators who work to disrupt them :-) > > Thanks, Henry > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Dec 12 20:30:06 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 1ElyzW-0003aR-18; Mon, 12 Dec 2005 20:30:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElyzU-0003Yj-5c for enum@megatron.ietf.org; Mon, 12 Dec 2005 20:30:04 -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 UAA04840 for ; Mon, 12 Dec 2005 20:28:57 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Elz0D-00019I-K8 for enum@ietf.org; Mon, 12 Dec 2005 20:30:50 -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 jBD1ULnH012726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Dec 2005 17:30:22 -0800 Message-ID: <439E2403.4000307@shockey.us> Date: Mon, 12 Dec 2005 20:29:39 -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="------------000500030906040702020907" 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: 1676547e4f33b5e63227e9c02bd359e3 Subject: [Enum] [Fwd: I-D ACTION:draft-ietf-iptel-tel-enumdi-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 multi-part message in MIME format. --------------000500030906040702020907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: I-D ACTION:draft-ietf-iptel-tel-enumdi-02.txt Date: Mon, 12 Dec 2005 18:50:01 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: iptel@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : The ENUM Dip Indicator parameter for the "tel" URI Author(s) : R. Stastny, et al. Filename : draft-ietf-iptel-tel-enumdi-02.txt Pages : 12 Date : 2005-12-12 This document defines a new parameter "enumdi" in the "tel" Uniform Resource Identifier (URI) as defined in RFC3966 to support the handling of ENUM queries in SIP proxies, H.323 gatekeepers and other VoIP network elements. The presence of the "enumdi" parameter indicates to the VoIP network element receiving an URI containing an E.164 number that an ENUM query as defined in RFC3761 has already been performed on the E.164 number indicated by the previous VoIP network element. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-enumdi-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-iptel-tel-enumdi-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-iptel-tel-enumdi-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. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --------------000500030906040702020907 Content-Type: Message/External-body; name="draft-ietf-iptel-tel-enumdi-02.txt" Content-Disposition: inline; filename="draft-ietf-iptel-tel-enumdi-02.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-12-12173402.I-D@ietf.org> --------------000500030906040702020907 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 --------------000500030906040702020907 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 --------------000500030906040702020907-- From enum-bounces@ietf.org Tue Dec 13 08:50:59 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 1EmAYV-00038D-3X; Tue, 13 Dec 2005 08:50:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElsRJ-00086X-SB for enum@megatron.ietf.org; Mon, 12 Dec 2005 13:30:33 -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 NAA27674 for ; Mon, 12 Dec 2005 13:29:21 -0500 (EST) Received: from mail.twang.net ([62.105.161.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElsRt-0006MG-20 for enum@ietf.org; Mon, 12 Dec 2005 13:31:09 -0500 Received: from [62.105.167.210] by mail.twang.net (GMS 10.03.3304/NY1676.00.b5a0c909) with ESMTP id rsdihbba for enum@ietf.org; Mon, 12 Dec 2005 18:21:09 +0000 Received: from mail pickup service by exchange01.twang.net with Microsoft SMTPSVC; Mon, 12 Dec 2005 18:19:12 +0000 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mailcleaner.twang.net (Vircom SMTPRS 4.2.425.16) with ESMTP id for ; Mon, 12 Dec 2005 08:08:02 +0000 X-Modus-ReverseDNS: OK X-Modus-BlackList: 132.151.6.71=OK;sip-bounces@ietf.org=OK X-Modus-RBL: 132.151.6.71=OK X-Modus-Trusted: 132.151.6.71=NO 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 1EliZO-0004r0-GF; Mon, 12 Dec 2005 02:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekmkj-0004Er-Cy; Fri, 09 Dec 2005 13:13: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 NAA09821; Fri, 9 Dec 2005 13:12:57 -0500 (EST) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekmku-0005Q9-Vf; Fri, 09 Dec 2005 13:14:06 -0500 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Fri, 9 Dec 2005 13:13:18 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005120913131726881 ; Fri, 09 Dec 2005 13:13:18 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Fri, 9 Dec 2005 13:13:13 -0500 Message-Id: <84E5D7F15F52D34DA84C9C90ACE6554F623382@0591-its-exmp01.us.saic.com> From: "Roy, Radhika R." To: henry@pulver.com, "Michael Hammer (mhammer)" , Thilo Salmon , Klaus Darilion Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Date: Fri, 9 Dec 2005 13:07:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-Mailman-Approved-At: Mon, 12 Dec 2005 02:57:59 -0500 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 12 Dec 2005 18:19:12.0999 (UTC) FILETIME=[8DB33F70:01C5FF48] X-AntiSpam: Checked for restricted content by Gordano's AntiSpam Software X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Tue, 13 Dec 2005 08:50:57 -0500 Cc: sip@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , enum@ietf.org X-BeenThere: enum@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 Henry: I think that it is the time to write an informational RFC on this because it is confusing to use the loose words like "service providers" in the context of the public Internet in the IETF. Let us focus on the RFC what it should be like "Internet Domain Owner" and others in the context of IETF standardization works. Best regards, Radhika _____ From: enum-bounces@ietf.org on behalf of Henry Sinnreich Sent: Tue 12/6/2005 5:29 PM To: 'Michael Hammer (mhammer)'; 'Thilo Salmon'; 'Klaus Darilion' Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny Richard'; enum@ietf.org Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM Sorry for nitpicking: >A provider is a provider. A provider is a business model and att/SBC may differ from Google who uses a different business model (which is more significant measured in $$$?). Didn't we agree to use the term "Internet domain owner" (we could shorten to IDOM or such)? Internet domains are well defined in the IETF. Business models for VoIP are better suited for other organizations, consortia or innovators who work to disrupt them :-) Thanks, Henry _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 14 00:48:24 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 1EmPV2-0002dV-2n; Wed, 14 Dec 2005 00:48:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmPUt-0002T1-RX; Wed, 14 Dec 2005 00:48:22 -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 AAA29512; Wed, 14 Dec 2005 00:47:12 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmPVv-0005sy-5g; Wed, 14 Dec 2005 00:49:21 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 13 Dec 2005 21:47:25 -0800 X-IronPort-AV: i="3.99,250,1131350400"; d="scan'208"; a="240735957:sNHT8437282708" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBE5lMpf001883; Tue, 13 Dec 2005 21:47:23 -0800 (PST) Received: from 10.21.96.130 ([10.21.96.130]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Dec 2005 05:47:22 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 13 Dec 2005 21:47:29 -0800 Subject: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try From: Cullen Jennings To: Stastny Richard , Klaus Darilion Message-ID: Thread-Topic: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try Thread-Index: AcX8t62w821JMsoqQGCdm3aV0mJTAAAAtcKNAO3WbuI= In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C470E@oefeg-s04.oefeg.loc> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , VoIPeer , 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 Seems to me that the redirect model, with TLS, provide much more information to the parties about the level of trust. It allows a two separate trust transaction between two parties instead of a three way transitive trust problem that TLS has no machinery to deal with. On 12/9/05 4:17 AM, "Stastny Richard" wrote: > Thanx Klaus > > for the work ;-) > > Now the next question: > What are the implications proxy vs redirect > if you are using TLS? > > Richard > > ________________________________ > > Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Gesendet: Fr 09.12.2005 12:52 > An: Stastny Richard > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org > Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try > > > > Stastny Richard wrote: >> Thanx Klaus >> >> Also for answering a question I did not (yet) ask >> regarding redirect vs proxy >> >> >> >>> I personally prefer relaying instead of redirect. >> >> >> Me too and I see your arguments. >> Are there any arguments out there why to prefer redriect? > > I just made some signaling pictures to visualize the difference: > From the signaling, there is no big difference. Both versions do need > approximately the same amount of signaling packets sent (depends onthe > actual SIP network design). > > I do not see any technical reason why to prefer one version over the > other. It's just a personal preference. > > regards > klaus > > > UAC proxyA borderProxyA redirectProxy borderProxyB proxyB UAS > | | | | | | | > |-INVITE>| | | | | | > |<-100---|-INVITE-->| | | | | > | |<--100----|-------INVITE---->| | | | > | | | | | | | > | | |<------302--------| | | | > | |<-302-----|-------ACK------->| | | | > | |--ACK---->| | | | | > | |--INVITE->| | | | | > | |<-100-----|--------------INVITE----------->| | | > | | |<--------------100--------------|-INVITE>| | > | | | | |<-100---|-INVITE>| > | | | | | |<-100---| > | | | | | | | > | | | | | |<-180---| > | | | | |<--180--| | > | | |<---------------180-------------| | | > | |<--180----| | | | | > |<--180--| | | | |<--200--| > | | | | |<--200--| | > | | |<---------------200-------------| | | > | |<---200---| | | | | > |<---200-| | | | | | > | | | | | | | > |--ACK-->| | | | | | > | |----ACK-->| | | | | > | | |--------------ACK-------------->| | | > | | | | |--ACK-->| | > | | | | | |--ACK-->| > | | | | | | | > | | | | | | | > | | | | | | | > > 32 Packets > > > UAC proxyA borderProxyA forwardProxy borderProxyB proxyB UAS > | | | | | | | > |-INVITE>| | | | | | > |<-100---|-INVITE-->| | | | | > | |<--100----|-------INVITE---->| | | | > | | |<-------100-------|---INVITE--->| | | > | | | |<----100-----|-INVITE>| | > | | | | |<-100---|-INVITE>| > | | | | | |<-100---| > | | | | | | | > | | | | | |<-180---| > | | | | |<--180--| | > | | | |<---180------| | | > | | |<----- -180-------| | | | > | |<--180----| | | | | > |<--180--| | | | |<--200--| > | | | | |<--200--| | > | | | |<---200------| | | > | | |<-------200-------| | | | > | |<---200---| | | | | > |<---200-| | | | | | > | | | | | | | > |--ACK-->| | | | | | > | |----ACK-->| | | | | > | | |--------------ACK-------------->| | | > | | | | |--ACK-->| | > | | | | | |--ACK-->| > > 29 Packets > > > > > _______________________________________________ > 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 Dec 15 17:20:06 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 1En1SH-0007Z9-Ir; Thu, 15 Dec 2005 17:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En1SF-0007Yc-OG for enum@megatron.ietf.org; Thu, 15 Dec 2005 17:20:03 -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 RAA24027 for ; Thu, 15 Dec 2005 17:19:05 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1En1Th-0000GD-RJ for enum@ietf.org; Thu, 15 Dec 2005 17:21:36 -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 jBFMKNFT019550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Dec 2005 14:20:26 -0800 Message-ID: <43A1EBFD.7000006@shockey.us> Date: Thu, 15 Dec 2005 17:19:41 -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: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Subject: [Enum] [Fwd: I-D ACTION:draft-ietf-iptel-tel-reg-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 FYI -------- Original Message -------- Subject: I-D ACTION:draft-ietf-iptel-tel-reg-00.txt Date: Thu, 15 Dec 2005 15:50:02 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: iptel@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry Author(s) : C. Jennings, V. Gurbani Filename : draft-ietf-iptel-tel-reg-00.txt Pages : 7 Date : 2005-12-15 This document creates an Internet Assigned Number Authority (IANA) registry for the tel Uniform Resource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-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-iptel-tel-reg-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-iptel-tel-reg-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 Fri Dec 16 09:02:36 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 1EnGAO-0007Uf-AF; Fri, 16 Dec 2005 09:02:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnGA5-0007Qk-MQ; Fri, 16 Dec 2005 09:02:18 -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 JAA21663; Fri, 16 Dec 2005 09:01:16 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnGBf-00089b-Kv; Fri, 16 Dec 2005 09:03:56 -0500 Received: from [10.131.244.250] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 16 Dec 2005 09:01:35 -0500 id 015880C4.43A2C8BF.00000864 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85883F5B-A4AF-4DAB-9CCB-4A04C7995133@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Fri, 16 Dec 2005 09:01:56 -0500 To: "Thomson, Martin" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: GEOPRIV WG , enum@ietf.org, Otmar Lendl Subject: [Enum] Re: [Geopriv] ENUM input request X-BeenThere: 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 [ adding the ENUM wg to this thread since this is mostly about their work ] On Dec 15, 2005, at 4:13 PM, Thomson, Martin wrote: > These things need to be localized. Just like language settings, > each field would have a name that is meaningful to the user. A > fair number of fields wouldn't even appear. I think the ENUM working group needs to define the use case a little more. Are we talking about users from Japan submitting validation tokens to Austria? Or is it just users in Austria submitting tokens to the Austrian powers-that-be? If the validation is within one border, doing the local- >international->local translation seems to be two steps too many. Mechanically, there are two answers. 1) Define a separate schema for each local form. 2) Define a profile for PIDF-LO:civicLoc for each local form. The first seems to be something that usually requires a Standards Track RFC. The second seems to be something that could easily be accomplished with an Informational RFC or perhaps an IANA registry. -andy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Dec 19 17:11:45 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 1EoTEP-0003LO-UF; Mon, 19 Dec 2005 17:11:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoTEL-0003KC-BI; Mon, 19 Dec 2005 17:11:41 -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 RAA21080; Mon, 19 Dec 2005 17:10:38 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoTGc-0007b5-G7; Mon, 19 Dec 2005 17:14:02 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EoTEI-0004eJ-O2; Mon, 19 Dec 2005 17:11:38 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 19 Dec 2005 17:11:38 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: enum mailing list , Internet Architecture Board , enum chair , enum chair , RFC Editor Subject: [Enum] Protocol Action: 'IANA Registration for Enumservice Voice' to Proposed Standard X-BeenThere: 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 IESG has approved the following document: - 'IANA Registration for Enumservice Voice ' as a Proposed Standard This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-voice-01.txt-01.txt Technical Summary ENUM (E.164 Number Mapping, RFC3761) is a system that transforms E.164 numbers into domain names and then uses DNS (Domain Name Service, RFC1034) features such as delegation through NS records, and the use of NAPTR records, to look up the communication services available for a specific domain name. 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. Working Group Summary The working group reached consensus to advance this enumservice for Proposed Standard status with no difficulty. Protocol Quality This specification has been implemented as a prototype. Allison Mankin reviewed this document for the IESG. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Dec 29 10:32: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 1Erzlr-0004NR-4U; Thu, 29 Dec 2005 10:32:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erzlo-0004NG-VJ for enum@megatron.ietf.org; Thu, 29 Dec 2005 10:32:49 -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 KAA08806 for ; Thu, 29 Dec 2005 10:31:37 -0500 (EST) Received: from smartmx-02.inode.at ([213.229.60.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Erzpx-0000lm-Kp for enum@ietf.org; Thu, 29 Dec 2005 10:37:13 -0500 Received: from [81.223.16.194] (port=2627 helo=mah9.inode.at) by smartmx-02.inode.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Erzle-0004Bc-Vu; Thu, 29 Dec 2005 16:32:39 +0100 Message-Id: <6.2.5.6.2.20051229161919.08110568@inode.at> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 29 Dec 2005 16:32:35 +0100 To: voipeer@lists.uoregon.edu From: Michael Haberler Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-3E511B0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: enum@ietf.org, lendl@nic.at Subject: [Enum] I-D: Publishing SIP Peering Policy X-BeenThere: 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've worked out a method to publish SIP peering policy through the DNS. It falls into SPEERMINT territory but I think it's relevant for ENUM as well. here's the gist in a nutshell - flames on. -mah] -- There will be many, potentially incompatible SIP peering schemes, and looking at a SIP URI does not help in deciding wether it is reachable (or "peerable"). Such information could be managed in local tables at the egress point. However, such static setup information is unwieldy to manage and similar in nature to a hosts.txt table, or static routes, and associated disadvantages. To aid runtime discovery of "peerable" destinations, and facilitate management of peering arrangements (including auto-discovery of new peering partners which subscribe to the same set of policies), we propose to name the scheme(s) used by a provider and publish them in the DNS, by specialized NAPTR RRs. This enables the egress point to decide - in advance and without pre-configuration of peers - wether the ingress point will accept a SIP INVITE, and which technique should be employed. Our proposal also allows smooth migration between peering methods and helps reduce the complexity of arrangements by introducing federations, of which a bilateral arrangement is just a special case. Our proposal focuses on the URI level, and assumes that E.164 numbers are already mapped to a URI, for instance by some form of ENUM. This draft addresses the problem of managing the peering fabric from an end-to-end perspective, which is a core task of the SPEERMINT charter. Michael Haberler Otmar Lendl On 2005/12/28 16:12, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Publishing SIP Peering Policy > Author(s) : O. Lendl > Filename : draft-lendl-sip-peering-policy-00.txt > Pages : 16 > Date : 2005-12-28 > > This documents proposes the use of DNS entries to publish a SIP > proxy's policy for accepting incoming calls. Such published policies > can be used to selectively establish peering relationships between > VoIP service providers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lendl-sip-peering-policy-00.txt > > [...] _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Dec 29 17:33:08 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 1Es6Ka-0001Gf-3p; Thu, 29 Dec 2005 17:33:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es6KY-0001GR-1Q for enum@megatron.ietf.org; Thu, 29 Dec 2005 17:33:06 -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 RAA26485 for ; Thu, 29 Dec 2005 17:31:54 -0500 (EST) Message-Id: <200512292231.RAA26485@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es6Oq-0007R4-00 for enum@ietf.org; Thu, 29 Dec 2005 17:37:34 -0500 Received: (qmail 17074 invoked by uid 510); 29 Dec 2005 17:44:54 -0500 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.142.34):. Processed in 0.847888 secs); 29 Dec 2005 22:44:54 -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.142.34):. Processed in 0.847888 secs Process 17069) Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.34) by 192.246.69.184 with SMTP; Thu, 29 Dec 2005 22:44:53 +0000 From: "Henry Sinnreich" To: "'Michael Haberler'" , Date: Thu, 29 Dec 2005 16:32:49 -0600 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 Thread-Index: AcYMkd8iNpMb9PkOQTW0+NjE9VvqEgAMpg3A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6.2.5.6.2.20051229161919.08110568@inode.at> X-Antivirus-MYDOMAIN-Message-ID: <113589629383517069@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, lendl@nic.at Subject: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy 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 This is seems to be an excellent approach and I suggest we discuss it on the list and close at the 65 IETF meeting in March. Are there any issues with overloading the DNS? Maybe it would be useful to define XML based policy profiles and have them registered at IANA? Thanks, Henry -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Haberler Sent: Thursday, December 29, 2005 9:33 AM To: voipeer@lists.uoregon.edu Cc: enum@ietf.org; lendl@nic.at Subject: [voipeer] I-D: Publishing SIP Peering Policy [we've worked out a method to publish SIP peering policy through the DNS. It falls into SPEERMINT territory but I think it's relevant for ENUM as well. here's the gist in a nutshell - flames on. -mah] -- There will be many, potentially incompatible SIP peering schemes, and looking at a SIP URI does not help in deciding wether it is reachable (or "peerable"). Such information could be managed in local tables at the egress point. However, such static setup information is unwieldy to manage and similar in nature to a hosts.txt table, or static routes, and associated disadvantages. To aid runtime discovery of "peerable" destinations, and facilitate management of peering arrangements (including auto-discovery of new peering partners which subscribe to the same set of policies), we propose to name the scheme(s) used by a provider and publish them in the DNS, by specialized NAPTR RRs. This enables the egress point to decide - in advance and without pre-configuration of peers - wether the ingress point will accept a SIP INVITE, and which technique should be employed. Our proposal also allows smooth migration between peering methods and helps reduce the complexity of arrangements by introducing federations, of which a bilateral arrangement is just a special case. Our proposal focuses on the URI level, and assumes that E.164 numbers are already mapped to a URI, for instance by some form of ENUM. This draft addresses the problem of managing the peering fabric from an end-to-end perspective, which is a core task of the SPEERMINT charter. Michael Haberler Otmar Lendl On 2005/12/28 16:12, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Publishing SIP Peering Policy > Author(s) : O. Lendl > Filename : draft-lendl-sip-peering-policy-00.txt > Pages : 16 > Date : 2005-12-28 > > This documents proposes the use of DNS entries to publish a SIP > proxy's policy for accepting incoming calls. Such published policies > can be used to selectively establish peering relationships between > VoIP service providers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lendl-sip-peering-policy-00.txt > > [...] ____________________________________________________________________________ _ 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 Dec 30 11:01:06 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 1EsMgk-0000hz-HQ; Fri, 30 Dec 2005 11:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsMgj-0000hm-DD for enum@megatron.ietf.org; Fri, 30 Dec 2005 11:01:05 -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 KAA06363 for ; Fri, 30 Dec 2005 10:59:54 -0500 (EST) 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 1EsMl7-0007Nf-9Z for enum@ietf.org; Fri, 30 Dec 2005 11:05:43 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id D93871A725; Fri, 30 Dec 2005 17:00:39 +0100 (CET) Date: Fri, 30 Dec 2005 17:00:39 +0100 From: Otmar Lendl To: Henry Sinnreich Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Message-ID: <20051230160039.GA20444@nic.at> Mail-Followup-To: Otmar Lendl , Henry Sinnreich , 'Michael Haberler' , voipeer@lists.uoregon.edu, enum@ietf.org References: <6.2.5.6.2.20051229161919.08110568@inode.at> <200512292231.RAA26485@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512292231.RAA26485@ietf.org> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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 On 2005/12/29 23:12, Henry Sinnreich wrote: > This is seems to be an excellent approach and I suggest we discuss it on the > list and close at the 65 IETF meeting in March. We're looking forward to a lively discussion. There are a lot of open questions (marked by "FIXME") in the draft where we hope that input from the list will lead to good solutions. The actual ressource record format is open for discussion as well. > Are there any issues with overloading the DNS? The basic questions which are answered by the scheme proposed in this draft are very close to those where DNS has traditionally been the answer. e.g. "I have this URI, what communication parameters do I need to use it?". This being the DNS, the answers need to be concise. There is no room for elaborate policy documents to be sent in the DNS answer. > Maybe it would be useful to define XML based policy profiles and have them > registered at IANA? The draft talks about two distinct types of policies. a) Federation rules. Definition and publication of these rules are out of scope for this draft. I see no need to parse those rules at call-setup time in an automatic fashion. Either your own VSP is a member of this federation, in which case you already made sure that you agree and follow that policy, or you are not, making the question whether you could follow the rules of that federation moot. A clear definition language for federation rules comes in handy when you consider to join a given federation. My guess here is that such rules will have at least twice as much legalese (who is allowed to do what, settlement, dispute resolution, abuse handling, ...) than actual technical rules (SIP/TLS details, Layer 3 arrangements, ...). I expect such rules to be similar to the contracts you have to sign when you connect to a layer 3 exchange point. See e.g. https://www.linx.net/www_public/about/corporate_governance/index_html/contentpanels_view?pageIndex=2 b) Technical restrictions. These are independent to any federation membership. While I think that typical VoIP providers will use federations to peer with each other, smaller entities (corporations, educational institutions, ...) will want to enable ad-hoc peering. They don't want or need to sign contracts with peering partners. But they might want not to run a completely open SIP server. Consider the email case: These days most SMTP servers already implement restrictions like "The sender domain must exist" or "client IP address not listed in blackhole lists". As email is not real-time, it does not really hurt to just try to deliver the mail and be told "no, sorry, we don't want your mail this way". Your MTA will fall back to other MXs or smart-relays. With SIP, we're in real-time communications where call-setup times are important. The sender prefers to know about such restrictions before connecting to the destination. [A similar idea was recently implemented in BGP4 as ORF (Outbound Route Filtering) where one BGP speaker tells his peer about his filter-rules so that route announcements can be tailored on the sender side.] For this case, a clear description language for restrictions is indeed helpful. As the DNS answers cannot hold the full text of such XML descriptions I agree that an IANA registry which maps rule descriptions to simple unique identifier is needed. [A similar solution was used in the XML DSIG standard regarding transformations, see http://www.w3.org/TR/xmldsig-core/#sec-TransformAlg ] I'm not 100% sure whether it's possible to design a XML scheme which can cover all possible policies. Once again, email could act as model. If one can design a scheme which covers all the currently employed email restrictions, then the same should be possible for SIP. Full XML syntax is only needed for automatic processing of such restrictions. For most cases I think that SIP senders will just compare the announced policy-identifiers with locally configured ones. No XML processing will be done at call-setup time. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum