From speermint-bounces@ietf.org Thu Jan 03 18:44:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAZjJ-0000Hp-Fa; Thu, 03 Jan 2008 18:44:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAZjI-0000Hk-1b for speermint@ietf.org; Thu, 03 Jan 2008 18:44:04 -0500 Received: from mail164.messagelabs.com ([216.82.253.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JAZjH-0002Zy-MJ for speermint@ietf.org; Thu, 03 Jan 2008 18:44:04 -0500 X-VirusChecked: Checked X-Env-Sender: daryl@level3.net X-Msg-Ref: server-11.tower-164.messagelabs.com!1199403842!25444909!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.106] Received: (qmail 14873 invoked from network); 3 Jan 2008 23:44:02 -0000 Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106) by server-11.tower-164.messagelabs.com with SMTP; 3 Jan 2008 23:44:02 -0000 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f10bb8-10 (Postfix) with ESMTP id 365B34445 for ; Thu, 3 Jan 2008 23:44:02 +0000 (GMT) Subject: [Speermint] Change of email address From: Daryl Malas To: speermint@ietf.org Content-Type: text/plain Date: Thu, 03 Jan 2008 16:56:50 -0700 Message-Id: <1199404611.7806.84.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org As of January 4, 2008, this email address (daryl@level3.net) and daryl.malas@level3.com will no longer be a valid address to reach me regarding comments or questions for the following two drafts: draft-ietf-speermint-terminology-14 draft-ietf-speermint-architecture-04 Please use the interim email address of dmalas@gmail.com until further notice. Thank you, Daryl Malas _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jan 14 11:50:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JESWC-0003pO-8h; Mon, 14 Jan 2008 11:50:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JESWB-0003pI-G2 for speermint@ietf.org; Mon, 14 Jan 2008 11:50:35 -0500 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JESWB-0006Zq-82 for speermint@ietf.org; Mon, 14 Jan 2008 11:50:35 -0500 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 93A5690F1 for ; Mon, 14 Jan 2008 11:50:34 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jan 2008 11:50:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Jan 2008 11:50:32 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Categorization of Federations Thread-Index: AchWzZPngi+5ig5MR7mNh+clNee1QA== From: "Uzelac, Adam" To: X-OriginalArrivalTime: 14 Jan 2008 16:50:34.0503 (UTC) FILETIME=[94D06970:01C856CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Speermint] Categorization of Federations X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org In the next release of the VoIP use-case ID for SPEERMINT, there is going to be an effort to consolidate the Federation section of the document into the agreed upon categorizations of Static/On-Demand, and the subsequent subdivision of direct and indirect. I am of the camp that Federations should fall into the Static/Direct categorization, while an argument can also be made to have Federations in the On-Demand/Direct scenario.=20 I would like to get a feel from the list on this topic. Please comment. Adam Uzelac Director, Converged Network Arch and Planning Global Crossing 585-563-4359 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jan 15 16:57:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEtmd-0005Mj-Qu; Tue, 15 Jan 2008 16:57:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEtmZ-0004jH-DK; Tue, 15 Jan 2008 16:57:19 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEtmZ-0007Af-5p; Tue, 15 Jan 2008 16:57:19 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id E65353289C; Tue, 15 Jan 2008 21:57:18 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JEtmY-0006bP-Lr; Tue, 15 Jan 2008 16:57:18 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 15 Jan 2008 16:57:18 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: speermint@ietf.org Subject: [Speermint] Last Call: draft-ietf-speermint-consolidated-presence-im-usecases (Presence & Instant Messaging Peering Use Cases) to Informational RFC X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org The IESG has received a request from the Session PEERing for Multimedia INTerconnect WG (speermint) to consider the following document: - 'Presence & Instant Messaging Peering Use Cases ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-01-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-speermint-consolidated-presence-im-usecases-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15839&rfc_flag=0 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 17 16:38:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFcRT-0007bn-5m; Thu, 17 Jan 2008 16:38:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFcRR-0007bT-Oy for speermint@ietf.org; Thu, 17 Jan 2008 16:38:29 -0500 Received: from nz-out-0506.google.com ([64.233.162.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFcRR-0006te-Ce for speermint@ietf.org; Thu, 17 Jan 2008 16:38:29 -0500 Received: by nz-out-0506.google.com with SMTP id n1so611763nzf.4 for ; Thu, 17 Jan 2008 13:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=mbMTGH89ezf9P+uLZCDTzO6SrWQNqhQ4ve2GPakal2I=; b=cvmuvx2ub4LFSW1gDlq/A5STNyrcfzEKA5ktZAqCxDe4Q/zco0hyAnOGNjfx82f8/6qMsz6MZM9eXPqvsl/Kn7eWQ3VcH+Pl1i1F6Lc0+/zdGKLx3/kn4vGejwsz2Mhky7cYBPNBO/DY47l9JO79ajSDNGuf6cwFhKqQ1A7Sqys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=OnuStQU6/5m1a7NelJf43gjawRgny1mPEVLDSEXNZxX3AiJCx+p0mw8i8LRLZFYNye0rkQZzwvOzNYmWGl63z+vAoK7iTJCXqKokgXPY4zgTnrsvl4kv/guyZz2zDG68/JnHiR9hbSQfRjhATdRiSo+xR4/E8/WEnwvm8oFOxOM= Received: by 10.114.78.1 with SMTP id a1mr491649wab.102.1200605908478; Thu, 17 Jan 2008 13:38:28 -0800 (PST) Received: by 10.115.15.16 with HTTP; Thu, 17 Jan 2008 13:38:28 -0800 (PST) Message-ID: <19f9b0170801171338o5a9d97eeobe50f0da2ccba270@mail.gmail.com> Date: Thu, 17 Jan 2008 14:38:28 -0700 From: "Daryl Malas" To: speermint@ietf.org Subject: [Speermint] re:LUF vs. LF MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I apologize for not responding to this discussion for awhile. I would like to propose the following updates: >From this.... 4.3.1. Look-Up Function The Look-Up Function (LUF) provides a mechanism for querying an internal and/or external database, which maintains a list of peered host domains. 4.3.2. Location Function The Location Function (LF) develops SED by discovering the Signaling Function (SF), and SF's reachable host (IP Address and port). In some cases, some entity (usually a 3rd party or federation) provides peering assistance to either the originating SSP by providing this function. The assisting entity may provide information relating to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as necessary. To this.... 4.3.1. Look-Up Function The Look-Up Function (LUF) provides a mechanism for querying an external centralized database of records accessible between two peers or within the federation. This database assists peers in the discovery of target user agents by hosting a centralized set of records between them. (In some cases, a local replication of this database may be used to potentially improve query performance; however, functionally it is still the use of a centralized common database among the peers.) These records are a set of addresses associated with the user agents within the individual peer networks. An example of this would be an external database hosted within a federation utilized as a common registry among the peers of the federation. A peer queries (i.e. LUF) the database requesting an address of record (AoR) by which it may deduce, though other means, a URI necessary for routing correctly to the target destination user agent. 4.3.2. Location Function The Location Function (LF) takes the output of the LUF and further develops the SED (See Section 3.3) by discovering the Signaling Function (SF), and SF's reachable host (IP Address and port) of the peer hosting the target destination user agent. In some cases, some entity (usually a 3rd party or federation) provides peering assistance to either the originating SSP by providing this function. The assisting entity may provide information relating to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as necessary. Comments? --Daryl _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 17 17:24:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFdA7-0003TM-Gr; Thu, 17 Jan 2008 17:24:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFdA6-0003TE-Gj for speermint@ietf.org; Thu, 17 Jan 2008 17:24:38 -0500 Received: from wa-out-1112.google.com ([209.85.146.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFdA5-0007uV-QP for speermint@ietf.org; Thu, 17 Jan 2008 17:24:38 -0500 Received: by wa-out-1112.google.com with SMTP id k40so1751641wah.25 for ; Thu, 17 Jan 2008 14:24:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Dci5t8GmjIZ4pu9rE3G1M3whY7brx+3OWBBJhorffRQ=; b=erAurAqM20pe42UlW2FYhNf37VGw853fpYbyIfQuvxy0ZKhVWcsJtgxHQ1zvfxfIJGhUihHqHEkNOtMkkQufGWyvAZ0+kthO8FbGP19+6vxlqD1CGkQ54hk/K/JGpQiF6lGFyC4lI8ze0aNsmLETVnJ0AzLhWqx3ho/9wSr1x2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RqqN6LP1NGM8H0DO8x8yUvDl4sIuIUCuULDb2MWSwbDYdBX3z1kpuhlvqISgqajIiBRqdyzsvijo1EZf6WFJPom3Y1M3o8Ol4o5JdRKoDWa8jyOF1mKKC81dEKTp0rEVe43Salh4bDrknucuZPY5ZUuCZT0LedRVZmPr2m3w/+E= Received: by 10.114.135.1 with SMTP id i1mr3006139wad.88.1200608676408; Thu, 17 Jan 2008 14:24:36 -0800 (PST) Received: by 10.115.15.16 with HTTP; Thu, 17 Jan 2008 14:24:36 -0800 (PST) Message-ID: <19f9b0170801171424p1fb69e97t38af2692ac91a406@mail.gmail.com> Date: Thu, 17 Jan 2008 15:24:36 -0700 From: "Daryl Malas" To: "Uzelac, Adam" Subject: Re: [Speermint] Categorization of Federations In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Adam, The definition of a Federation is directly polarized to the concept of On-demand, please see below: 4.2.3. On-demand Peering SSPs are said to peer on-demand when they are able to exchange traffic without any pre-association prior to the origination of a real-time transaction (like a SIP message) between the domains. [...without any pre-association prior...] 5. Federations A federation is a group of SSPs which agree to receive calls from each other via SIP, and who agree on a set of administrative rules for such calls (settlement, abuse-handling, ...) and the specific rules for the technical details of the peering. I can add some verbiage to Section 5 to indicate Federations may only peer in a static manner if it will clear up confusion. --Daryl On Jan 14, 2008 9:50 AM, Uzelac, Adam wrote: > In the next release of the VoIP use-case ID for SPEERMINT, there is > going to be an effort to consolidate the Federation section of the > document into the agreed upon categorizations of Static/On-Demand, and > the subsequent subdivision of direct and indirect. I am of the camp > that Federations should fall into the Static/Direct categorization, > while an argument can also be made to have Federations in the > On-Demand/Direct scenario. > > I would like to get a feel from the list on this topic. Please comment. > > Adam Uzelac > Director, Converged Network Arch and Planning > Global Crossing > 585-563-4359 > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jan 18 04:20:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFnOu-0002nL-5S; Fri, 18 Jan 2008 04:20:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFnOt-0002nG-B6 for speermint@ietf.org; Fri, 18 Jan 2008 04:20:35 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFnOr-0002On-It for speermint@ietf.org; Fri, 18 Jan 2008 04:20:35 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUU00A6Y1Y8PV@siemenscomms.co.uk> for speermint@ietf.org; Fri, 18 Jan 2008 09:20:33 +0000 (GMT) Date: Fri, 18 Jan 2008 09:20:32 +0000 From: "Elwell, John" Subject: RE: [Speermint] re:LUF vs. LF In-reply-to: <19f9b0170801171338o5a9d97eeobe50f0da2ccba270@mail.gmail.com> To: Daryl Malas , speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D059408A@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Speermint] re:LUF vs. LF thread-index: AchZUVyN9UnEhJoORyS578bgqy++GQAWuy3w Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <19f9b0170801171338o5a9d97eeobe50f0da2ccba270@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl, I think it is wrong to talk about UAs here. The existence of UAs will be known only within the target domain, i.e., by the that domain's registrar and domain proxy. A peer domain trying to route to a target domain just needs to know how to do that - to route to the target domain. It does not need to know (and indeed should not be able to find out) anything about UAs in the target domain. The proposed definition of LuF completely confuses me. It would also be helpful to say what is the input to the LuF. Is it just a telephone number (in other words, the LuF is a kind of ENUM look-up, resulting in a SIP URI for the target user)? Also, my reading of the definition of LF is that it could simply comprise the functionality specified in RFC 3263. I other words, it takes a target SIP/SIPS URI and locates a server. If this is the case, it might be better to express it in those terms. If there is some distinguishing feature that makes a LF somehow different from RFC 3263 server location functionality, then the definition must be more precise. By the way, is the term "location function" liable to be confused with the well-established RFC 3261 term "location service"? We may need to find a different term, but until I understand what the two terms are intended to mean, I cannot propose an alternative. John > -----Original Message----- > From: Daryl Malas [mailto:dmalas@gmail.com]=20 > Sent: 17 January 2008 21:38 > To: speermint@ietf.org > Subject: [Speermint] re:LUF vs. LF >=20 > I apologize for not responding to this discussion for awhile. I would > like to propose the following updates: >=20 > >From this.... >=20 > 4.3.1. Look-Up Function > The Look-Up Function (LUF) provides a mechanism for querying an > internal and/or external database, which maintains a list of peered > host domains. >=20 > 4.3.2. Location Function > The Location Function (LF) develops SED by discovering the Signaling > Function (SF), and SF's reachable host (IP Address and port). >=20 > In some cases, some entity (usually a 3rd party or federation) > provides peering assistance to either the originating SSP by providing > this function. The assisting entity may provide information relating > to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as > necessary. >=20 > To this.... >=20 > 4.3.1. Look-Up Function > The Look-Up Function (LUF) provides a mechanism for querying an > external centralized database of records accessible between two peers > or within the federation. This database assists peers in the > discovery of target user agents by hosting a centralized set of > records between them. (In some cases, a local replication of this > database may be used to potentially improve query performance; > however, functionally it is still the use of a centralized common > database among the peers.) These records are a set of addresses > associated with the user agents within the individual peer networks. > An example of this would be an external database hosted within a > federation utilized as a common registry among the peers of the > federation. A peer queries (i.e. LUF) the database requesting an > address of record (AoR) by which it may deduce, though other means, a > URI necessary for routing correctly to the target destination user > agent. >=20 > 4.3.2. Location Function > The Location Function (LF) takes the output of the LUF and further > develops the SED (See Section 3.3) by discovering the Signaling > Function (SF), and SF's reachable host (IP Address and port) of the > peer hosting the target destination user agent. >=20 > In some cases, some entity (usually a 3rd party or federation) > provides peering assistance to either the originating SSP by providing > this function. The assisting entity may provide information relating > to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as > necessary. >=20 > Comments? >=20 > --Daryl >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jan 18 10:16:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFswt-0000fp-Iz; Fri, 18 Jan 2008 10:16:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsws-0000fj-UR for speermint@ietf.org; Fri, 18 Jan 2008 10:16:02 -0500 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFswp-0001Oj-TX for speermint@ietf.org; Fri, 18 Jan 2008 10:16:02 -0500 Received: by wa-out-1112.google.com with SMTP id k40so2360710wah.25 for ; Fri, 18 Jan 2008 07:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=vdQVO33pPFb7+l50YBbCE1KSC+S7G5J+O56WL+uAWH8=; b=OuxKfwfExPPcwlEeCXeLbQCQrE4spcY1yLiuB+ZPesL7vX1K/TDqFMq/gOHxIZGSzUGPpGKWtIcgz1QK3DkXCsNJTepUN2+isk3s0DgdTDQ2hkKQ/VxY92kQrwPsr0hZWBKH4weLDGdFoj/uaPJjMBPgeji6yjR0Mc5ESf80hk4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=M2gj2PtS+rj+KLNfTVGTcbC95DCAlHzKE1aY9uwksBqJtenV5H4S4epJ7I1hX0JWiv1khrvlKIyEIp88zNylatWBPMXe7jO6ihJYcADqr29C+fw3VA3HIN6Ex+ckPJT3HSemHJcMaL28qTztlovb1tmgMVuYIZKSwNbbXE9VEmo= Received: by 10.114.169.2 with SMTP id r2mr1542100wae.30.1200669359217; Fri, 18 Jan 2008 07:15:59 -0800 (PST) Received: by 10.115.15.16 with HTTP; Fri, 18 Jan 2008 07:15:59 -0800 (PST) Message-ID: <19f9b0170801180715t5e635bf3l849b0e2a6fe77123@mail.gmail.com> Date: Fri, 18 Jan 2008 08:15:59 -0700 From: "Daryl Malas" To: "Elwell, John" Subject: Re: [Speermint] re:LUF vs. LF In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D059408A@GBNTHT12009MSX.gb002.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <19f9b0170801171338o5a9d97eeobe50f0da2ccba270@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D059408A@GBNTHT12009MSX.gb002.siemens.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org John, I can easily remove UA's and simplify it to domains. Since, you are still confused by the definition, can you please propose some new wording for these two terms? IMO, this draft is being held up by these two terms. Thanks... Daryl On 1/18/08, Elwell, John wrote: > Daryl, > > I think it is wrong to talk about UAs here. The existence of UAs will be > known only within the target domain, i.e., by the that domain's > registrar and domain proxy. A peer domain trying to route to a target > domain just needs to know how to do that - to route to the target > domain. It does not need to know (and indeed should not be able to find > out) anything about UAs in the target domain. The proposed definition of > LuF completely confuses me. > > It would also be helpful to say what is the input to the LuF. Is it just > a telephone number (in other words, the LuF is a kind of ENUM look-up, > resulting in a SIP URI for the target user)? > > Also, my reading of the definition of LF is that it could simply > comprise the functionality specified in RFC 3263. I other words, it > takes a target SIP/SIPS URI and locates a server. If this is the case, > it might be better to express it in those terms. If there is some > distinguishing feature that makes a LF somehow different from RFC 3263 > server location functionality, then the definition must be more precise. > > By the way, is the term "location function" liable to be confused with > the well-established RFC 3261 term "location service"? We may need to > find a different term, but until I understand what the two terms are > intended to mean, I cannot propose an alternative. > > John > > > -----Original Message----- > > From: Daryl Malas [mailto:dmalas@gmail.com] > > Sent: 17 January 2008 21:38 > > To: speermint@ietf.org > > Subject: [Speermint] re:LUF vs. LF > > > > I apologize for not responding to this discussion for awhile. I would > > like to propose the following updates: > > > > >From this.... > > > > 4.3.1. Look-Up Function > > The Look-Up Function (LUF) provides a mechanism for querying an > > internal and/or external database, which maintains a list of peered > > host domains. > > > > 4.3.2. Location Function > > The Location Function (LF) develops SED by discovering the Signaling > > Function (SF), and SF's reachable host (IP Address and port). > > > > In some cases, some entity (usually a 3rd party or federation) > > provides peering assistance to either the originating SSP by providing > > this function. The assisting entity may provide information relating > > to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as > > necessary. > > > > To this.... > > > > 4.3.1. Look-Up Function > > The Look-Up Function (LUF) provides a mechanism for querying an > > external centralized database of records accessible between two peers > > or within the federation. This database assists peers in the > > discovery of target user agents by hosting a centralized set of > > records between them. (In some cases, a local replication of this > > database may be used to potentially improve query performance; > > however, functionally it is still the use of a centralized common > > database among the peers.) These records are a set of addresses > > associated with the user agents within the individual peer networks. > > An example of this would be an external database hosted within a > > federation utilized as a common registry among the peers of the > > federation. A peer queries (i.e. LUF) the database requesting an > > address of record (AoR) by which it may deduce, though other means, a > > URI necessary for routing correctly to the target destination user > > agent. > > > > 4.3.2. Location Function > > The Location Function (LF) takes the output of the LUF and further > > develops the SED (See Section 3.3) by discovering the Signaling > > Function (SF), and SF's reachable host (IP Address and port) of the > > peer hosting the target destination user agent. > > > > In some cases, some entity (usually a 3rd party or federation) > > provides peering assistance to either the originating SSP by providing > > this function. The assisting entity may provide information relating > > to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as > > necessary. > > > > Comments? > > > > --Daryl > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jan 18 10:39:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtJt-0007cy-2r; Fri, 18 Jan 2008 10:39:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtJr-0007cp-LJ for speermint@ietf.org; Fri, 18 Jan 2008 10:39:47 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFtJq-0006bE-Q7 for speermint@ietf.org; Fri, 18 Jan 2008 10:39:47 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUU00A6YJI9BO@siemenscomms.co.uk> for speermint@ietf.org; Fri, 18 Jan 2008 15:39:46 +0000 (GMT) Date: Fri, 18 Jan 2008 15:39:44 +0000 From: "Elwell, John" Subject: RE: [Speermint] re:LUF vs. LF In-reply-to: <19f9b0170801180715t5e635bf3l849b0e2a6fe77123@mail.gmail.com> To: Daryl Malas Message-id: <0D5F89FAC29E2C41B98A6A762007F5D05941DD@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Speermint] re:LUF vs. LF thread-index: AchZ5QuDoYNqqZqYTXWVaJxFl3poqQAAe08w Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <19f9b0170801171338o5a9d97eeobe50f0da2ccba270@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D059408A@GBNTHT12009MSX.gb002.siemens.net> <19f9b0170801180715t5e635bf3l849b0e2a6fe77123@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl, Trying to keep it simple, how about the following? LuF: A function that determines for a given request the domain to which the request should be routed. LF: A function that determines for a given domain the location of a SIP server in that domain and optionally other information needed to route a request to that domain. I have tried to keep this to a minimum, but if it is heading in the right direction we can add to it if necessary. However, I am in favour of concise definitions. John > -----Original Message----- > From: Daryl Malas [mailto:dmalas@gmail.com]=20 > Sent: 18 January 2008 15:16 > To: Elwell, John > Cc: speermint@ietf.org > Subject: Re: [Speermint] re:LUF vs. LF >=20 > John, >=20 > I can easily remove UA's and simplify it to domains. Since, you are > still confused by the definition, can you please propose some new > wording for these two terms? >=20 > IMO, this draft is being held up by these two terms. >=20 > Thanks... >=20 > Daryl >=20 > On 1/18/08, Elwell, John wrote: > > Daryl, > > > > I think it is wrong to talk about UAs here. The existence=20 > of UAs will be > > known only within the target domain, i.e., by the that domain's > > registrar and domain proxy. A peer domain trying to route=20 > to a target > > domain just needs to know how to do that - to route to the target > > domain. It does not need to know (and indeed should not be=20 > able to find > > out) anything about UAs in the target domain. The proposed=20 > definition of > > LuF completely confuses me. > > > > It would also be helpful to say what is the input to the=20 > LuF. Is it just > > a telephone number (in other words, the LuF is a kind of=20 > ENUM look-up, > > resulting in a SIP URI for the target user)? > > > > Also, my reading of the definition of LF is that it could simply > > comprise the functionality specified in RFC 3263. I other words, it > > takes a target SIP/SIPS URI and locates a server. If this=20 > is the case, > > it might be better to express it in those terms. If there is some > > distinguishing feature that makes a LF somehow different=20 > from RFC 3263 > > server location functionality, then the definition must be=20 > more precise. > > > > By the way, is the term "location function" liable to be=20 > confused with > > the well-established RFC 3261 term "location service"? We=20 > may need to > > find a different term, but until I understand what the two terms are > > intended to mean, I cannot propose an alternative. > > > > John > > > > > -----Original Message----- > > > From: Daryl Malas [mailto:dmalas@gmail.com] > > > Sent: 17 January 2008 21:38 > > > To: speermint@ietf.org > > > Subject: [Speermint] re:LUF vs. LF > > > > > > I apologize for not responding to this discussion for=20 > awhile. I would > > > like to propose the following updates: > > > > > > >From this.... > > > > > > 4.3.1. Look-Up Function > > > The Look-Up Function (LUF) provides a mechanism for querying an > > > internal and/or external database, which maintains a list=20 > of peered > > > host domains. > > > > > > 4.3.2. Location Function > > > The Location Function (LF) develops SED by discovering=20 > the Signaling > > > Function (SF), and SF's reachable host (IP Address and port). > > > > > > In some cases, some entity (usually a 3rd party or federation) > > > provides peering assistance to either the originating SSP=20 > by providing > > > this function. The assisting entity may provide=20 > information relating > > > to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as > > > necessary. > > > > > > To this.... > > > > > > 4.3.1. Look-Up Function > > > The Look-Up Function (LUF) provides a mechanism for querying an > > > external centralized database of records accessible=20 > between two peers > > > or within the federation. This database assists peers in the > > > discovery of target user agents by hosting a centralized set of > > > records between them. (In some cases, a local replication of this > > > database may be used to potentially improve query performance; > > > however, functionally it is still the use of a centralized common > > > database among the peers.) These records are a set of addresses > > > associated with the user agents within the individual=20 > peer networks. > > > An example of this would be an external database hosted within a > > > federation utilized as a common registry among the peers of the > > > federation. A peer queries (i.e. LUF) the database requesting an > > > address of record (AoR) by which it may deduce, though=20 > other means, a > > > URI necessary for routing correctly to the target destination user > > > agent. > > > > > > 4.3.2. Location Function > > > The Location Function (LF) takes the output of the LUF and further > > > develops the SED (See Section 3.3) by discovering the Signaling > > > Function (SF), and SF's reachable host (IP Address and=20 > port) of the > > > peer hosting the target destination user agent. > > > > > > In some cases, some entity (usually a 3rd party or federation) > > > provides peering assistance to either the originating SSP=20 > by providing > > > this function. The assisting entity may provide=20 > information relating > > > to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as > > > necessary. > > > > > > Comments? > > > > > > --Daryl > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jan 18 10:55:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtZN-000208-Rv; Fri, 18 Jan 2008 10:55:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtZM-000201-8a for speermint@ietf.org; Fri, 18 Jan 2008 10:55:48 -0500 Received: from nz-out-0506.google.com ([64.233.162.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFtZL-00029B-F0 for speermint@ietf.org; Fri, 18 Jan 2008 10:55:48 -0500 Received: by nz-out-0506.google.com with SMTP id n1so811697nzf.4 for ; Fri, 18 Jan 2008 07:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=trhB+jY+HzehJbWkJZZ6tmITE8+a+IC33nAj1fYsFKE=; b=OLHTaFDFFnXEs82lyn3Azf5ok8unea2/Nmhm8v+b3ncY2e11zejcN/vK5F0i6qMn2Vie9gqKgg2rrtCGBUYET8iilazPXP89bkXSD8p82/RNpEj4ZHhg1P9KW/9RtIxBzJUlttCN/+eXpRQSuuMqK+m62YqVSODsi/zhhzpzm9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=vMo9mQHeGVSPtYMHtBDLAzoG7M0wSkHPIfPWoCD3fINl4IcvJ02LsGvL+S2our7jMLl7IWer8QzVgvJPbFFBNz5tKab6jsHBag/i3JfA3FNq5M5ul7BIX/VrBOd3U2jhGsey7oGHQV/aL9mD7U/ozWzsAimjl/ewaYjgyYzRs+E= Received: by 10.115.46.9 with SMTP id y9mr1020226waj.129.1200671746489; Fri, 18 Jan 2008 07:55:46 -0800 (PST) Received: by 10.115.15.16 with HTTP; Fri, 18 Jan 2008 07:55:46 -0800 (PST) Message-ID: <19f9b0170801180755w791c32e0xc08e11bd1d4c5dc9@mail.gmail.com> Date: Fri, 18 Jan 2008 08:55:46 -0700 From: "Daryl Malas" To: "Elwell, John" Subject: Re: [Speermint] re:LUF vs. LF In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D05941DD@GBNTHT12009MSX.gb002.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <19f9b0170801171338o5a9d97eeobe50f0da2ccba270@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D059408A@GBNTHT12009MSX.gb002.siemens.net> <19f9b0170801180715t5e635bf3l849b0e2a6fe77123@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D05941DD@GBNTHT12009MSX.gb002.siemens.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org John, Thank you for suggesting some new language. Please review these updated definitions, and provide feedback. I also suggested some possible term changes to make sure there is no confusion with 'Location Service' in 3261. LUF: The Look-Up Function (LUF) provides a mechanism for determining for a given request the target domain to which the request should be routed. Suggested term change from Location Function to: Location Determination Function Location Routing Function (I prefer this one.) LRF: The Location Routing Function (LRF) determines for a given domain the location of the SF in the target domain and optionally develops other SED required to route the associated request to that domain. Thanks...--Daryl On 1/18/08, Elwell, John wrote: > Daryl, > > Trying to keep it simple, how about the following? > > LuF: A function that determines for a given request the domain to which > the request should be routed. > LF: A function that determines for a given domain the location of a SIP > server in that domain and optionally other information needed to route a > request to that domain. > > I have tried to keep this to a minimum, but if it is heading in the > right direction we can add to it if necessary. However, I am in favour > of concise definitions. > > John > > > -----Original Message----- > > From: Daryl Malas [mailto:dmalas@gmail.com] > > Sent: 18 January 2008 15:16 > > To: Elwell, John > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] re:LUF vs. LF > > > > John, > > > > I can easily remove UA's and simplify it to domains. Since, you are > > still confused by the definition, can you please propose some new > > wording for these two terms? > > > > IMO, this draft is being held up by these two terms. > > > > Thanks... > > > > Daryl > > > > On 1/18/08, Elwell, John wrote: > > > Daryl, > > > > > > I think it is wrong to talk about UAs here. The existence > > of UAs will be > > > known only within the target domain, i.e., by the that domain's > > > registrar and domain proxy. A peer domain trying to route > > to a target > > > domain just needs to know how to do that - to route to the target > > > domain. It does not need to know (and indeed should not be > > able to find > > > out) anything about UAs in the target domain. The proposed > > definition of > > > LuF completely confuses me. > > > > > > It would also be helpful to say what is the input to the > > LuF. Is it just > > > a telephone number (in other words, the LuF is a kind of > > ENUM look-up, > > > resulting in a SIP URI for the target user)? > > > > > > Also, my reading of the definition of LF is that it could simply > > > comprise the functionality specified in RFC 3263. I other words, it > > > takes a target SIP/SIPS URI and locates a server. If this > > is the case, > > > it might be better to express it in those terms. If there is some > > > distinguishing feature that makes a LF somehow different > > from RFC 3263 > > > server location functionality, then the definition must be > > more precise. > > > > > > By the way, is the term "location function" liable to be > > confused with > > > the well-established RFC 3261 term "location service"? We > > may need to > > > find a different term, but until I understand what the two terms are > > > intended to mean, I cannot propose an alternative. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Daryl Malas [mailto:dmalas@gmail.com] > > > > Sent: 17 January 2008 21:38 > > > > To: speermint@ietf.org > > > > Subject: [Speermint] re:LUF vs. LF > > > > > > > > I apologize for not responding to this discussion for > > awhile. I would > > > > like to propose the following updates: > > > > > > > > >From this.... > > > > > > > > 4.3.1. Look-Up Function > > > > The Look-Up Function (LUF) provides a mechanism for querying an > > > > internal and/or external database, which maintains a list > > of peered > > > > host domains. > > > > > > > > 4.3.2. Location Function > > > > The Location Function (LF) develops SED by discovering > > the Signaling > > > > Function (SF), and SF's reachable host (IP Address and port). > > > > > > > > In some cases, some entity (usually a 3rd party or federation) > > > > provides peering assistance to either the originating SSP > > by providing > > > > this function. The assisting entity may provide > > information relating > > > > to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as > > > > necessary. > > > > > > > > To this.... > > > > > > > > 4.3.1. Look-Up Function > > > > The Look-Up Function (LUF) provides a mechanism for querying an > > > > external centralized database of records accessible > > between two peers > > > > or within the federation. This database assists peers in the > > > > discovery of target user agents by hosting a centralized set of > > > > records between them. (In some cases, a local replication of this > > > > database may be used to potentially improve query performance; > > > > however, functionally it is still the use of a centralized common > > > > database among the peers.) These records are a set of addresses > > > > associated with the user agents within the individual > > peer networks. > > > > An example of this would be an external database hosted within a > > > > federation utilized as a common registry among the peers of the > > > > federation. A peer queries (i.e. LUF) the database requesting an > > > > address of record (AoR) by which it may deduce, though > > other means, a > > > > URI necessary for routing correctly to the target destination user > > > > agent. > > > > > > > > 4.3.2. Location Function > > > > The Location Function (LF) takes the output of the LUF and further > > > > develops the SED (See Section 3.3) by discovering the Signaling > > > > Function (SF), and SF's reachable host (IP Address and > > port) of the > > > > peer hosting the target destination user agent. > > > > > > > > In some cases, some entity (usually a 3rd party or federation) > > > > provides peering assistance to either the originating SSP > > by providing > > > > this function. The assisting entity may provide > > information relating > > > > to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as > > > > necessary. > > > > > > > > Comments? > > > > > > > > --Daryl > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jan 18 11:16:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFttB-0002v8-W8; Fri, 18 Jan 2008 11:16:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFttA-0002pv-S4 for speermint@ietf.org; Fri, 18 Jan 2008 11:16:16 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFtt9-00080h-Qz for speermint@ietf.org; Fri, 18 Jan 2008 11:16:16 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUU00D7AL730K@siemenscomms.co.uk> for speermint@ietf.org; Fri, 18 Jan 2008 16:16:15 +0000 (GMT) Date: Fri, 18 Jan 2008 16:16:14 +0000 From: "Elwell, John" Subject: RE: [Speermint] re:LUF vs. LF In-reply-to: <19f9b0170801180755w791c32e0xc08e11bd1d4c5dc9@mail.gmail.com> To: Daryl Malas Message-id: <0D5F89FAC29E2C41B98A6A762007F5D05941F9@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Speermint] re:LUF vs. LF thread-index: AchZ6uD5uECq06GYSoqXjVrSrnlNFwAAcDNw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <19f9b0170801171338o5a9d97eeobe50f0da2ccba270@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D059408A@GBNTHT12009MSX.gb002.siemens.net> <19f9b0170801180715t5e635bf3l849b0e2a6fe77123@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D05941DD@GBNTHT12009MSX.gb002.siemens.net> <19f9b0170801180755w791c32e0xc08e11bd1d4c5dc9@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl, See below. John=20 > -----Original Message----- > From: Daryl Malas [mailto:dmalas@gmail.com]=20 > Sent: 18 January 2008 15:56 > To: Elwell, John > Cc: speermint@ietf.org > Subject: Re: [Speermint] re:LUF vs. LF >=20 > John, >=20 > Thank you for suggesting some new language. Please review these > updated definitions, and provide feedback. I also suggested some > possible term changes to make sure there is no confusion with > 'Location Service' in 3261. >=20 > LUF: >=20 > The Look-Up Function (LUF) provides a mechanism for determining for a > given request the target domain to which the request should be routed. [JRE] OK >=20 > Suggested term change from Location Function to: > Location Determination Function > Location Routing Function (I prefer this one.) [JRE] OK >=20 > LRF: > The Location Routing Function (LRF) determines for a given domain the > location of the SF in the target domain and optionally develops other > SED required to route the associated request to that domain. [JRE] Slight word change (e.g., don't like switching from "a given domain" to "the target domain"): "The Location Routing Function (LRF) determines for the target domain of a given request the location of the SF in that domain and optionally develops other SED required to route the request to that domain." With these changes I think the definitions are simple, relate to each other well, and clearly differentiate the two functions. >=20 > Thanks...--Daryl >=20 > On 1/18/08, Elwell, John wrote: > > Daryl, > > > > Trying to keep it simple, how about the following? > > > > LuF: A function that determines for a given request the=20 > domain to which > > the request should be routed. > > LF: A function that determines for a given domain the=20 > location of a SIP > > server in that domain and optionally other information=20 > needed to route a > > request to that domain. > > > > I have tried to keep this to a minimum, but if it is heading in the > > right direction we can add to it if necessary. However, I=20 > am in favour > > of concise definitions. > > > > John > > > > > -----Original Message----- > > > From: Daryl Malas [mailto:dmalas@gmail.com] > > > Sent: 18 January 2008 15:16 > > > To: Elwell, John > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] re:LUF vs. LF > > > > > > John, > > > > > > I can easily remove UA's and simplify it to domains. =20 > Since, you are > > > still confused by the definition, can you please propose some new > > > wording for these two terms? > > > > > > IMO, this draft is being held up by these two terms. > > > > > > Thanks... > > > > > > Daryl > > > > > > On 1/18/08, Elwell, John wrote: > > > > Daryl, > > > > > > > > I think it is wrong to talk about UAs here. The existence > > > of UAs will be > > > > known only within the target domain, i.e., by the that domain's > > > > registrar and domain proxy. A peer domain trying to route > > > to a target > > > > domain just needs to know how to do that - to route to=20 > the target > > > > domain. It does not need to know (and indeed should not be > > > able to find > > > > out) anything about UAs in the target domain. The proposed > > > definition of > > > > LuF completely confuses me. > > > > > > > > It would also be helpful to say what is the input to the > > > LuF. Is it just > > > > a telephone number (in other words, the LuF is a kind of > > > ENUM look-up, > > > > resulting in a SIP URI for the target user)? > > > > > > > > Also, my reading of the definition of LF is that it could simply > > > > comprise the functionality specified in RFC 3263. I=20 > other words, it > > > > takes a target SIP/SIPS URI and locates a server. If this > > > is the case, > > > > it might be better to express it in those terms. If=20 > there is some > > > > distinguishing feature that makes a LF somehow different > > > from RFC 3263 > > > > server location functionality, then the definition must be > > > more precise. > > > > > > > > By the way, is the term "location function" liable to be > > > confused with > > > > the well-established RFC 3261 term "location service"? We > > > may need to > > > > find a different term, but until I understand what the=20 > two terms are > > > > intended to mean, I cannot propose an alternative. > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Daryl Malas [mailto:dmalas@gmail.com] > > > > > Sent: 17 January 2008 21:38 > > > > > To: speermint@ietf.org > > > > > Subject: [Speermint] re:LUF vs. LF > > > > > > > > > > I apologize for not responding to this discussion for > > > awhile. I would > > > > > like to propose the following updates: > > > > > > > > > > >From this.... > > > > > > > > > > 4.3.1. Look-Up Function > > > > > The Look-Up Function (LUF) provides a mechanism for=20 > querying an > > > > > internal and/or external database, which maintains a list > > > of peered > > > > > host domains. > > > > > > > > > > 4.3.2. Location Function > > > > > The Location Function (LF) develops SED by discovering > > > the Signaling > > > > > Function (SF), and SF's reachable host (IP Address and port). > > > > > > > > > > In some cases, some entity (usually a 3rd party or federation) > > > > > provides peering assistance to either the originating SSP > > > by providing > > > > > this function. The assisting entity may provide > > > information relating > > > > > to direct (Section 4.2.1) or indirect (Section 4.2.2)=20 > peering as > > > > > necessary. > > > > > > > > > > To this.... > > > > > > > > > > 4.3.1. Look-Up Function > > > > > The Look-Up Function (LUF) provides a mechanism for=20 > querying an > > > > > external centralized database of records accessible > > > between two peers > > > > > or within the federation. This database assists peers in the > > > > > discovery of target user agents by hosting a=20 > centralized set of > > > > > records between them. (In some cases, a local=20 > replication of this > > > > > database may be used to potentially improve query performance; > > > > > however, functionally it is still the use of a=20 > centralized common > > > > > database among the peers.) These records are a set of=20 > addresses > > > > > associated with the user agents within the individual > > > peer networks. > > > > > An example of this would be an external database=20 > hosted within a > > > > > federation utilized as a common registry among the=20 > peers of the > > > > > federation. A peer queries (i.e. LUF) the database=20 > requesting an > > > > > address of record (AoR) by which it may deduce, though > > > other means, a > > > > > URI necessary for routing correctly to the target=20 > destination user > > > > > agent. > > > > > > > > > > 4.3.2. Location Function > > > > > The Location Function (LF) takes the output of the=20 > LUF and further > > > > > develops the SED (See Section 3.3) by discovering the=20 > Signaling > > > > > Function (SF), and SF's reachable host (IP Address and > > > port) of the > > > > > peer hosting the target destination user agent. > > > > > > > > > > In some cases, some entity (usually a 3rd party or federation) > > > > > provides peering assistance to either the originating SSP > > > by providing > > > > > this function. The assisting entity may provide > > > information relating > > > > > to direct (Section 4.2.1) or indirect (Section 4.2.2)=20 > peering as > > > > > necessary. > > > > > > > > > > Comments? > > > > > > > > > > --Daryl > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jan 18 11:28:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFu4v-0004h6-5a; Fri, 18 Jan 2008 11:28:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFu4u-0004gq-0m for speermint@ietf.org; Fri, 18 Jan 2008 11:28:24 -0500 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFu4t-0003VX-D1 for speermint@ietf.org; Fri, 18 Jan 2008 11:28:23 -0500 Received: by wa-out-1112.google.com with SMTP id k40so2406253wah.25 for ; Fri, 18 Jan 2008 08:28:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=8Fcc6kz7qduD+6QYS+IbzjTEAwHTbEgMMmhM21iImfM=; b=KwhuNOdVq9IJRmslVEq3T1Fyyx2TojgiKiWDO8MygJ+TUZ2Rlx+bxvcwTRznzsuZjES/9N0m3BTgeoW8mfB2ELK/s9hX54RGBVFqr6ESB+M1pCTk38QZgrUVKYGWiItJXBh+XbrVEBPT40k8h+/BLShRAAYv88j8KQHoAIlijUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Wra/Q/MuJ5yMnOaTQ7gGebgNVYS3NBCwJVIPOuW6N51qyXqGh1dNRIBwx5qlXxQOkZVAY8NP8ORHavq08R6uEoD2tZEzcQs48MWXLEITR3jV2QMd3pfFSw/AM3SThCCUJGnt6F5PErUd8ta6z6bpW8+DXMq0gcpd+2DBFDC6n/A= Received: by 10.114.120.1 with SMTP id s1mr1403005wac.107.1200673702245; Fri, 18 Jan 2008 08:28:22 -0800 (PST) Received: by 10.115.15.16 with HTTP; Fri, 18 Jan 2008 08:28:22 -0800 (PST) Message-ID: <19f9b0170801180828s6b081380h1c0508a94e3c9cdd@mail.gmail.com> Date: Fri, 18 Jan 2008 09:28:22 -0700 From: "Daryl Malas" To: "Elwell, John" Subject: Re: [Speermint] re:LUF vs. LF In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D05941F9@GBNTHT12009MSX.gb002.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <19f9b0170801171338o5a9d97eeobe50f0da2ccba270@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D059408A@GBNTHT12009MSX.gb002.siemens.net> <19f9b0170801180715t5e635bf3l849b0e2a6fe77123@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D05941DD@GBNTHT12009MSX.gb002.siemens.net> <19f9b0170801180755w791c32e0xc08e11bd1d4c5dc9@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D05941F9@GBNTHT12009MSX.gb002.siemens.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Thanks, John. (John, please make sure I captured your last updated correctly.) Okay, here are the updated terms and definitions: Look-up Function: The Look-Up Function (LUF) provides a mechanism for determining for a given request the target domain to which the request should be routed. Location Routing Function: The Location Routing Function (LRF) determines for the target domain of a given request the location of the SF in that domain and optionally develops other SED required to route the request to that domain. Please provide feedback if anyone has concerns. Thanks...--Daryl On 1/18/08, Elwell, John wrote: > Daryl, > > See below. > > John > > > -----Original Message----- > > From: Daryl Malas [mailto:dmalas@gmail.com] > > Sent: 18 January 2008 15:56 > > To: Elwell, John > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] re:LUF vs. LF > > > > John, > > > > Thank you for suggesting some new language. Please review these > > updated definitions, and provide feedback. I also suggested some > > possible term changes to make sure there is no confusion with > > 'Location Service' in 3261. > > > > LUF: > > > > The Look-Up Function (LUF) provides a mechanism for determining for a > > given request the target domain to which the request should be routed. > [JRE] OK > > > > > Suggested term change from Location Function to: > > Location Determination Function > > Location Routing Function (I prefer this one.) > [JRE] OK > > > > > LRF: > > The Location Routing Function (LRF) determines for a given domain the > > location of the SF in the target domain and optionally develops other > > SED required to route the associated request to that domain. > [JRE] Slight word change (e.g., don't like switching from "a given > domain" to "the target domain"): > "The Location Routing Function (LRF) determines for the target domain of > a given request the location of the SF in that domain and optionally > develops other SED required to route the request to that domain." > > With these changes I think the definitions are simple, relate to each > other well, and clearly differentiate the two functions. > > > > > Thanks...--Daryl > > > > On 1/18/08, Elwell, John wrote: > > > Daryl, > > > > > > Trying to keep it simple, how about the following? > > > > > > LuF: A function that determines for a given request the > > domain to which > > > the request should be routed. > > > LF: A function that determines for a given domain the > > location of a SIP > > > server in that domain and optionally other information > > needed to route a > > > request to that domain. > > > > > > I have tried to keep this to a minimum, but if it is heading in the > > > right direction we can add to it if necessary. However, I > > am in favour > > > of concise definitions. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Daryl Malas [mailto:dmalas@gmail.com] > > > > Sent: 18 January 2008 15:16 > > > > To: Elwell, John > > > > Cc: speermint@ietf.org > > > > Subject: Re: [Speermint] re:LUF vs. LF > > > > > > > > John, > > > > > > > > I can easily remove UA's and simplify it to domains. > > Since, you are > > > > still confused by the definition, can you please propose some new > > > > wording for these two terms? > > > > > > > > IMO, this draft is being held up by these two terms. > > > > > > > > Thanks... > > > > > > > > Daryl > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jan 18 13:15:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFvkj-0006Xe-PN; Fri, 18 Jan 2008 13:15:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFvki-0006XU-Vh for speermint@ietf.org; Fri, 18 Jan 2008 13:15:41 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFvki-0005Jr-Bv for speermint@ietf.org; Fri, 18 Jan 2008 13:15:40 -0500 Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.41319416; Fri, 18 Jan 2008 13:15:25 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 13:15:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] re:LUF vs. LF Date: Fri, 18 Jan 2008 13:14:58 -0500 Message-ID: <45AEC6EF95942140888406588E1A660203A0FC82@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <19f9b0170801180828s6b081380h1c0508a94e3c9cdd@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] re:LUF vs. LF Thread-Index: AchZ7z2ykXXyKdAtRq+ltceDao7cMwADnh/Q From: "Lee, Yiu" To: "Daryl Malas" , "Elwell, John" X-OriginalArrivalTime: 18 Jan 2008 18:15:25.0557 (UTC) FILETIME=[18F89A50:01C859FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I like them except I am confused by the last sentence of LRF. What does the "optically develops other SED required to route the request to that domain" really mean? Can you enlighten with an example?=20 -----Original Message----- From: Daryl Malas [mailto:dmalas@gmail.com]=20 Sent: Friday, January 18, 2008 11:28 AM To: Elwell, John Cc: speermint@ietf.org Subject: Re: [Speermint] re:LUF vs. LF Thanks, John. (John, please make sure I captured your last updated correctly.) Okay, here are the updated terms and definitions: Look-up Function: The Look-Up Function (LUF) provides a mechanism for determining for a given request the target domain to which the request should be routed. Location Routing Function: The Location Routing Function (LRF) determines for the target domain of a given request the location of the SF in that domain and optionally develops other SED required to route the request to that domain. Please provide feedback if anyone has concerns. Thanks...--Daryl On 1/18/08, Elwell, John wrote: > Daryl, > > See below. > > John > > > -----Original Message----- > > From: Daryl Malas [mailto:dmalas@gmail.com] > > Sent: 18 January 2008 15:56 > > To: Elwell, John > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] re:LUF vs. LF > > > > John, > > > > Thank you for suggesting some new language. Please review these=20 > > updated definitions, and provide feedback. I also suggested some=20 > > possible term changes to make sure there is no confusion with=20 > > 'Location Service' in 3261. > > > > LUF: > > > > The Look-Up Function (LUF) provides a mechanism for determining for=20 > > a given request the target domain to which the request should be routed. > [JRE] OK > > > > > Suggested term change from Location Function to: > > Location Determination Function > > Location Routing Function (I prefer this one.) > [JRE] OK > > > > > LRF: > > The Location Routing Function (LRF) determines for a given domain=20 > > the location of the SF in the target domain and optionally develops=20 > > other SED required to route the associated request to that domain. > [JRE] Slight word change (e.g., don't like switching from "a given=20 > domain" to "the target domain"): > "The Location Routing Function (LRF) determines for the target domain=20 > of a given request the location of the SF in that domain and=20 > optionally develops other SED required to route the request to that domain." > > With these changes I think the definitions are simple, relate to each=20 > other well, and clearly differentiate the two functions. > > > > > Thanks...--Daryl > > > > On 1/18/08, Elwell, John wrote: > > > Daryl, > > > > > > Trying to keep it simple, how about the following? > > > > > > LuF: A function that determines for a given request the > > domain to which > > > the request should be routed. > > > LF: A function that determines for a given domain the > > location of a SIP > > > server in that domain and optionally other information > > needed to route a > > > request to that domain. > > > > > > I have tried to keep this to a minimum, but if it is heading in=20 > > > the right direction we can add to it if necessary. However, I > > am in favour > > > of concise definitions. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Daryl Malas [mailto:dmalas@gmail.com] > > > > Sent: 18 January 2008 15:16 > > > > To: Elwell, John > > > > Cc: speermint@ietf.org > > > > Subject: Re: [Speermint] re:LUF vs. LF > > > > > > > > John, > > > > > > > > I can easily remove UA's and simplify it to domains. > > Since, you are > > > > still confused by the definition, can you please propose some=20 > > > > new wording for these two terms? > > > > > > > > IMO, this draft is being held up by these two terms. > > > > > > > > Thanks... > > > > > > > > Daryl > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jan 18 18:49:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG0xF-00073N-TI; Fri, 18 Jan 2008 18:48:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG0xF-00073I-6n for speermint@ietf.org; Fri, 18 Jan 2008 18:48:57 -0500 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JG0xD-0000oX-If for speermint@ietf.org; Fri, 18 Jan 2008 18:48:57 -0500 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1JG0x8-0005o4-00; Sat, 19 Jan 2008 00:48:50 +0100 Date: Sat, 19 Jan 2008 00:48:50 +0100 From: Otmar Lendl To: Daryl Malas Subject: Re: [Speermint] Categorization of Federations Message-ID: <20080118234850.GA22301@nic.at> Mail-Followup-To: Otmar Lendl , Daryl Malas , "Uzelac, Adam" , speermint@ietf.org References: <19f9b0170801171424p1fb69e97t38af2692ac91a406@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19f9b0170801171424p1fb69e97t38af2692ac91a406@mail.gmail.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: speermint@ietf.org, "Uzelac, Adam" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl, Adam, On 2008/01/17 23:01, Daryl Malas wrote: > Adam, > > The definition of a Federation is directly polarized to the concept of > On-demand, please see below: I think it's orthogonal. There are federations where the member know each other in advance and can set up the peering well before the first call comes in, and I can imagine federations where members discover on demand that a specific call can be passed towards a fellow federation peer. Here is an example for the latter: Let's say PBX vendor X sells nice SIP enabled PBXs which can be configured to do ENUM queries towards some ENUM tree. Furthermore, X acts as X.509 certification authority (incl. revocation management) for the SIP TLS certs of its customers' installation. A simple federation could be the set of all PBX installations from vendor X which do ENUM lookups into a common tree and which accept incoming SIP calls if the TLS handshake shows the both side posses a valid cert as signed by the vendor X CA. (who guarantees that these are serious, non-spammy, well connected, corporate customers) Whenever a new PBX with these features is installed, then all the others need not do anything. No new configurations are needed there. The peering with this new federation member is completely ad-hoc with the first call. (For all I know, the phonegnome system is close to such a setup.) > I can add some verbiage to Section 5 to indicate Federations may only > peer in a static manner if it will clear up confusion. I don't agree. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jan 18 19:22:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG1U9-0000CI-9x; Fri, 18 Jan 2008 19:22:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG1U8-0000CD-IZ for speermint@ietf.org; Fri, 18 Jan 2008 19:22:56 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JG1U6-0001O1-Ag for speermint@ietf.org; Fri, 18 Jan 2008 19:22:56 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id m0J0MlxD010219; Fri, 18 Jan 2008 17:22:48 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 18 Jan 2008 17:22:48 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Categorization of Federations Date: Fri, 18 Jan 2008 17:22:48 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA4917B0C0C@srvxchg3.cablelabs.com> In-Reply-To: <20080118234850.GA22301@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Categorization of Federations Thread-Index: AchaLMKy/VGq4NdKR1upOZ2E5Eqg8gAA9Ikw References: <19f9b0170801171424p1fb69e97t38af2692ac91a406@mail.gmail.com> <20080118234850.GA22301@nic.at> From: "Daryl Malas" To: "Otmar Lendl" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: speermint@ietf.org, "Uzelac, Adam" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar, I think the LUF/LRF and components of the SED can be dynamic, but the peering relationships in a federation are still static. --Daryl -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Friday, January 18, 2008 4:49 PM To: Daryl Malas Cc: speermint@ietf.org; Uzelac, Adam Subject: Re: [Speermint] Categorization of Federations Daryl, Adam, On 2008/01/17 23:01, Daryl Malas wrote: > Adam, >=20 > The definition of a Federation is directly polarized to the concept of > On-demand, please see below: I think it's orthogonal. There are federations where the member know each other in advance and can set up the peering well before the first call comes in, and I can imagine federations where members discover on demand that a specific call can be passed towards a fellow federation peer. Here is an example for the latter:=20 Let's say PBX vendor X sells nice SIP enabled PBXs which can be configured to do ENUM queries towards some ENUM tree. Furthermore, X acts as X.509 certification authority (incl. revocation management) for the SIP TLS certs of its customers' installation. A simple federation could be the set of all PBX installations from vendor X which do ENUM lookups into a common tree and which accept incoming SIP calls if the TLS handshake shows the both side posses a valid cert as signed by the vendor X CA. (who guarantees that these are serious, non-spammy, well connected, corporate customers) Whenever a new PBX with these features is installed, then all the others need not do anything. No new configurations are needed there. The peering with this new federation member is completely ad-hoc with the first call. (For all I know, the phonegnome system is close to such a setup.) > I can add some verbiage to Section 5 to indicate Federations may only=20 > peer in a static manner if it will clear up confusion. I don't agree. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat Jan 19 08:39:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGDvD-0006Sm-F4; Sat, 19 Jan 2008 08:39:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGDvB-0006Sc-Eu for speermint@ietf.org; Sat, 19 Jan 2008 08:39:41 -0500 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGDv9-0007dW-Ks for speermint@ietf.org; Sat, 19 Jan 2008 08:39:41 -0500 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1JGDv6-0005wv-00; Sat, 19 Jan 2008 14:39:36 +0100 Date: Sat, 19 Jan 2008 14:39:36 +0100 From: Otmar Lendl To: Daryl Malas Subject: Re: [Speermint] Categorization of Federations Message-ID: <20080119133936.GA22698@nic.at> Mail-Followup-To: Otmar Lendl , Daryl Malas , speermint@ietf.org, "Uzelac, Adam" References: <20080118234850.GA22301@nic.at> <160DE07A1C4F8E4AA2715DEC577DA4917B0C0C@srvxchg3.cablelabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA4917B0C0C@srvxchg3.cablelabs.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: speermint@ietf.org, "Uzelac, Adam" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl, On 2008/01/19 01:01, Daryl Malas wrote: > Otmar, > > I think the LUF/LRF and components of the SED can be dynamic, but the > peering relationships in a federation are still static. The current definition of static peering is: | 4.2.5. Static Peering | | SSPs are said to peer statically when pre-association between | providers is required for the initiation of any real-time | transactions (like a SIP message). I don't see how this applies to the given example. The peering partners don't know about each other until the first call between them. There is no pre-association. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jan 21 10:23:15 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGyUT-0001nH-MJ; Mon, 21 Jan 2008 10:23:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGyUR-0001hJ-NL for speermint@ietf.org; Mon, 21 Jan 2008 10:23:11 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGyUR-0000lE-3l for speermint@ietf.org; Mon, 21 Jan 2008 10:23:11 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id m0LFN6P9001871; Mon, 21 Jan 2008 08:23:06 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 21 Jan 2008 08:23:05 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Categorization of Federations Date: Mon, 21 Jan 2008 08:23:06 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA4917B0C0F@srvxchg3.cablelabs.com> In-Reply-To: <20080119133936.GA22698@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Categorization of Federations Thread-Index: AchaoLx6Cflss0dMTTeTPFAnIHbCLwBoKB/Q References: <20080118234850.GA22301@nic.at> <160DE07A1C4F8E4AA2715DEC577DA4917B0C0C@srvxchg3.cablelabs.com> <20080119133936.GA22698@nic.at> From: "Daryl Malas" To: "Otmar Lendl" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: speermint@ietf.org, "Uzelac, Adam" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar, I was more looking at this: 5. Federations A federation is a group of SSPs which agree to receive calls from each other via SIP, and who agree on a set of administrative rules for such calls (settlement, abuse-handling, ...) and the specific rules for the technical details of the peering. To me, this indicates pre-association. --Daryl -----Original Message----- From: Otmar Lendl [mailto:lendl@labs.nic.at] On Behalf Of Otmar Lendl Sent: Saturday, January 19, 2008 6:40 AM To: Daryl Malas Cc: speermint@ietf.org; Uzelac, Adam Subject: Re: [Speermint] Categorization of Federations Daryl, On 2008/01/19 01:01, Daryl Malas wrote: > Otmar, >=20 > I think the LUF/LRF and components of the SED can be dynamic, but the=20 > peering relationships in a federation are still static. The current definition of static peering is: | 4.2.5. Static Peering |=20 | SSPs are said to peer statically when pre-association between | providers is required for the initiation of any real-time | transactions (like a SIP message). I don't see how this applies to the given example. The peering partners don't know about each other until the first call between them. There is no pre-association. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jan 21 11:28:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGzVC-00043H-29; Mon, 21 Jan 2008 11:28:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGzVA-00043B-A8 for speermint@ietf.org; Mon, 21 Jan 2008 11:28:00 -0500 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGzV8-0002YI-3L for speermint@ietf.org; Mon, 21 Jan 2008 11:28:00 -0500 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1JGzV5-0006WR-00; Mon, 21 Jan 2008 17:27:55 +0100 Date: Mon, 21 Jan 2008 17:27:55 +0100 From: Otmar Lendl To: Daryl Malas Subject: Re: [Speermint] Categorization of Federations Message-ID: <20080121162754.GA25059@nic.at> Mail-Followup-To: Otmar Lendl , Daryl Malas , speermint@ietf.org, "Uzelac, Adam" References: <20080118234850.GA22301@nic.at> <160DE07A1C4F8E4AA2715DEC577DA4917B0C0C@srvxchg3.cablelabs.com> <20080119133936.GA22698@nic.at> <160DE07A1C4F8E4AA2715DEC577DA4917B0C0F@srvxchg3.cablelabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA4917B0C0F@srvxchg3.cablelabs.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: speermint@ietf.org, "Uzelac, Adam" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2008/01/21 16:01, Daryl Malas wrote: > Otmar, > > I was more looking at this: > > 5. Federations > A federation is a group of SSPs which agree to receive calls from each > other via SIP, and who agree on a set of administrative rules for such > calls (settlement, abuse-handling, ...) and the specific rules for the > technical details of the peering. > > To me, this indicates pre-association. "pre-association" in the sense of the active participation in such a setup, yes. But not necessarily pre-association with every peering partner. In the example I gave all setup/pre-association happens between the enterprise installing such a PBX and the vendor (e.g. configuring the ENUM setup, applying for the X.509 cert, signing terms-of-use statements regarding that service, retrieving revocation lists, complaints on incoming SPIT, ...). Which point of the federation definition isn't fulfilled by this example? Maybe the crucial point is that I contend that it's not necessary for the group of SSPs to sign mutual agreements, but instead that it can be sufficient that each members signs the group's charta. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jan 22 09:37:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHKG3-0005nV-9c; Tue, 22 Jan 2008 09:37:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHKG1-0005nL-5h for speermint@ietf.org; Tue, 22 Jan 2008 09:37:45 -0500 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHKG0-0003ln-Jg for speermint@ietf.org; Tue, 22 Jan 2008 09:37:45 -0500 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 47C8B9842; Tue, 22 Jan 2008 09:37:44 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jan 2008 09:37:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Categorization of Federations Date: Tue, 22 Jan 2008 09:37:42 -0500 Message-ID: In-Reply-To: <20080118234850.GA22301@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Categorization of Federations Thread-Index: AchaLLnuXAi6fCTKRRy+LGiVttZOwAC10muA References: <19f9b0170801171424p1fb69e97t38af2692ac91a406@mail.gmail.com> <20080118234850.GA22301@nic.at> From: "Uzelac, Adam" To: "Otmar Lendl" , "Daryl Malas" X-OriginalArrivalTime: 22 Jan 2008 14:37:44.0348 (UTC) FILETIME=[598945C0:01C85D04] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org A concern I have with regards to this discussion isn't so much the technical merits, but more the fact that the use-case draft is chartered to capture current practices in the industry. With that in mind, most of the Federation deployments that I am aware of falls inline with Daryl's train of thought - a Federation is On-demand/static. -AU=20 > -----Original Message----- > From: Otmar Lendl [mailto:lendl@labs.nic.at] On Behalf Of Otmar Lendl > Sent: Friday, January 18, 2008 6:49 PM > To: Daryl Malas > Cc: Uzelac, Adam; speermint@ietf.org > Subject: Re: [Speermint] Categorization of Federations >=20 >=20 > Daryl, Adam, >=20 > On 2008/01/17 23:01, Daryl Malas wrote: > > Adam, > >=20 > > The definition of a Federation is directly polarized to the=20 > concept of=20 > > On-demand, please see below: >=20 > I think it's orthogonal. >=20 > There are federations where the member know each other in=20 > advance and can set up the peering well before the first call=20 > comes in, and I can imagine federations where members=20 > discover on demand that a specific call can be passed towards=20 > a fellow federation peer. >=20 > Here is an example for the latter:=20 >=20 > Let's say PBX vendor X sells nice SIP enabled PBXs which can=20 > be configured to do ENUM queries towards some ENUM tree.=20 > Furthermore, X acts as X.509 certification authority (incl.=20 > revocation management) for the SIP TLS certs of its=20 > customers' installation. >=20 > A simple federation could be the set of all PBX installations=20 > from vendor X which do ENUM lookups into a common tree and=20 > which accept incoming SIP calls if the TLS handshake shows=20 > the both side posses a valid cert as signed by the vendor X=20 > CA. (who guarantees that these are serious, non-spammy, well=20 > connected, corporate customers) >=20 > Whenever a new PBX with these features is installed, then all=20 > the others need not do anything. No new configurations are=20 > needed there. > The peering with this new federation member is completely=20 > ad-hoc with the first call. >=20 > (For all I know, the phonegnome system is close to such a setup.) >=20 > > I can add some verbiage to Section 5 to indicate=20 > Federations may only=20 > > peer in a static manner if it will clear up confusion. >=20 > I don't agree. >=20 > /ol > -- > // Otmar Lendl , T: +43 1 5056416 - 33, F: -=20 > 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft=20 > m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jan 22 10:50:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHLOE-0003nS-ID; Tue, 22 Jan 2008 10:50:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHLOD-0003nM-8X for speermint@ietf.org; Tue, 22 Jan 2008 10:50:17 -0500 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHLOC-0008CK-Nz for speermint@ietf.org; Tue, 22 Jan 2008 10:50:17 -0500 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 617F29407; Tue, 22 Jan 2008 10:50:16 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jan 2008 10:50:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Categorization of Federations Date: Tue, 22 Jan 2008 10:50:13 -0500 Message-ID: In-Reply-To: <19f9b0170801220734l12639498pf951178574c15447@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Categorization of Federations Thread-Index: AchdDEO3By9G7VcbROK5TeAjQK+rwgAAiJkg References: <19f9b0170801171424p1fb69e97t38af2692ac91a406@mail.gmail.com> <20080118234850.GA22301@nic.at> <19f9b0170801220734l12639498pf951178574c15447@mail.gmail.com> From: "Uzelac, Adam" To: "Daryl Malas" X-OriginalArrivalTime: 22 Jan 2008 15:50:15.0225 (UTC) FILETIME=[7ADC6A90:01C85D0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Sorry - Daryl is correct. Static/direct. =20 > -----Original Message----- > From: Daryl Malas [mailto:dmalas@gmail.com]=20 > Sent: Tuesday, January 22, 2008 10:34 AM > To: Uzelac, Adam > Cc: Otmar Lendl; speermint@ietf.org > Subject: Re: [Speermint] Categorization of Federations >=20 > Adam, >=20 > I think you meant to say "a Federation peers statically", not=20 > on-demand. Is this correct? >=20 > --Daryl >=20 > On 1/22/08, Uzelac, Adam wrote: > > A concern I have with regards to this discussion isn't so much the=20 > > technical merits, but more the fact that the use-case draft is=20 > > chartered to capture current practices in the industry. =20 > With that in=20 > > mind, most of the Federation deployments that I am aware of falls=20 > > inline with Daryl's train of thought - a Federation is=20 > On-demand/static. > > > > -AU > > > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@labs.nic.at] On Behalf Of Otmar=20 > > > Lendl > > > Sent: Friday, January 18, 2008 6:49 PM > > > To: Daryl Malas > > > Cc: Uzelac, Adam; speermint@ietf.org > > > Subject: Re: [Speermint] Categorization of Federations > > > > > > > > > Daryl, Adam, > > > > > > On 2008/01/17 23:01, Daryl Malas wrote: > > > > Adam, > > > > > > > > The definition of a Federation is directly polarized to the > > > concept of > > > > On-demand, please see below: > > > > > > I think it's orthogonal. > > > > > > There are federations where the member know each other in advance=20 > > > and can set up the peering well before the first call=20 > comes in, and=20 > > > I can imagine federations where members discover on demand that a=20 > > > specific call can be passed towards a fellow federation peer. > > > > > > Here is an example for the latter: > > > > > > Let's say PBX vendor X sells nice SIP enabled PBXs which can be=20 > > > configured to do ENUM queries towards some ENUM tree. > > > Furthermore, X acts as X.509 certification authority (incl. > > > revocation management) for the SIP TLS certs of its customers'=20 > > > installation. > > > > > > A simple federation could be the set of all PBX=20 > installations from=20 > > > vendor X which do ENUM lookups into a common tree and=20 > which accept=20 > > > incoming SIP calls if the TLS handshake shows the both=20 > side posses a=20 > > > valid cert as signed by the vendor X CA. (who guarantees=20 > that these=20 > > > are serious, non-spammy, well connected, corporate customers) > > > > > > Whenever a new PBX with these features is installed, then all the=20 > > > others need not do anything. No new configurations are=20 > needed there. > > > The peering with this new federation member is completely ad-hoc=20 > > > with the first call. > > > > > > (For all I know, the phonegnome system is close to such a setup.) > > > > > > > I can add some verbiage to Section 5 to indicate > > > Federations may only > > > > peer in a static manner if it will clear up confusion. > > > > > > I don't agree. > > > > > > /ol > > > -- > > > // Otmar Lendl , T: +43 1 5056416 - 33, F: - > > > 933 // nic.at Internet Verwaltungs- und=20 > Betriebsgesellschaft m.b.H=20 > > > // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg > > > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jan 22 10:59:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHLX9-0000Fk-RW; Tue, 22 Jan 2008 10:59:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHLX8-0000Fe-G6 for speermint@ietf.org; Tue, 22 Jan 2008 10:59:30 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHLX6-0007UX-Q7 for speermint@ietf.org; Tue, 22 Jan 2008 10:59:30 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id m0MFxMJM001845; Tue, 22 Jan 2008 08:59:22 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 22 Jan 2008 08:59:22 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Categorization of Federations Date: Tue, 22 Jan 2008 08:59:22 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA4917B0C23@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Categorization of Federations Thread-Index: AchdDEO3By9G7VcbROK5TeAjQK+rwgAAiJkgAABClWA= References: <19f9b0170801171424p1fb69e97t38af2692ac91a406@mail.gmail.com><20080118234850.GA22301@nic.at><19f9b0170801220734l12639498pf951178574c15447@mail.gmail.com> From: "Daryl Malas" To: "Uzelac, Adam" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Adam, I do not agree with one thing. I think federated peers must peer statically, but it can occur direct or indirectly. --Daryl -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 Sent: Tuesday, January 22, 2008 8:50 AM To: Daryl Malas Cc: speermint@ietf.org; Otmar Lendl Subject: RE: [Speermint] Categorization of Federations Sorry - Daryl is correct. Static/direct. =20 > -----Original Message----- > From: Daryl Malas [mailto:dmalas@gmail.com] > Sent: Tuesday, January 22, 2008 10:34 AM > To: Uzelac, Adam > Cc: Otmar Lendl; speermint@ietf.org > Subject: Re: [Speermint] Categorization of Federations >=20 > Adam, >=20 > I think you meant to say "a Federation peers statically", not=20 > on-demand. Is this correct? >=20 > --Daryl >=20 > On 1/22/08, Uzelac, Adam wrote: > > A concern I have with regards to this discussion isn't so much the=20 > > technical merits, but more the fact that the use-case draft is=20 > > chartered to capture current practices in the industry. > With that in > > mind, most of the Federation deployments that I am aware of falls=20 > > inline with Daryl's train of thought - a Federation is > On-demand/static. > > > > -AU > > > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@labs.nic.at] On Behalf Of Otmar=20 > > > Lendl > > > Sent: Friday, January 18, 2008 6:49 PM > > > To: Daryl Malas > > > Cc: Uzelac, Adam; speermint@ietf.org > > > Subject: Re: [Speermint] Categorization of Federations > > > > > > > > > Daryl, Adam, > > > > > > On 2008/01/17 23:01, Daryl Malas wrote: > > > > Adam, > > > > > > > > The definition of a Federation is directly polarized to the > > > concept of > > > > On-demand, please see below: > > > > > > I think it's orthogonal. > > > > > > There are federations where the member know each other in advance=20 > > > and can set up the peering well before the first call > comes in, and > > > I can imagine federations where members discover on demand that a=20 > > > specific call can be passed towards a fellow federation peer. > > > > > > Here is an example for the latter: > > > > > > Let's say PBX vendor X sells nice SIP enabled PBXs which can be=20 > > > configured to do ENUM queries towards some ENUM tree. > > > Furthermore, X acts as X.509 certification authority (incl. > > > revocation management) for the SIP TLS certs of its customers'=20 > > > installation. > > > > > > A simple federation could be the set of all PBX > installations from > > > vendor X which do ENUM lookups into a common tree and > which accept > > > incoming SIP calls if the TLS handshake shows the both > side posses a > > > valid cert as signed by the vendor X CA. (who guarantees > that these > > > are serious, non-spammy, well connected, corporate customers) > > > > > > Whenever a new PBX with these features is installed, then all the=20 > > > others need not do anything. No new configurations are > needed there. > > > The peering with this new federation member is completely ad-hoc=20 > > > with the first call. > > > > > > (For all I know, the phonegnome system is close to such a setup.) > > > > > > > I can add some verbiage to Section 5 to indicate > > > Federations may only > > > > peer in a static manner if it will clear up confusion. > > > > > > I don't agree. > > > > > > /ol > > > -- > > > // Otmar Lendl , T: +43 1 5056416 - 33, F: - > > > 933 // nic.at Internet Verwaltungs- und > Betriebsgesellschaft m.b.H > > > // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg > > > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jan 22 11:32:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHM31-0000mz-UX; Tue, 22 Jan 2008 11:32:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHM30-0000mt-Lm for speermint@ietf.org; Tue, 22 Jan 2008 11:32:26 -0500 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHM2y-0008Kg-OP for speermint@ietf.org; Tue, 22 Jan 2008 11:32:26 -0500 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1JHM2l-0006nn-00; Tue, 22 Jan 2008 17:32:11 +0100 Date: Tue, 22 Jan 2008 17:32:11 +0100 From: Otmar Lendl To: Daryl Malas , "Uzelac, Adam" , speermint@ietf.org Subject: Re: [Speermint] Categorization of Federations Message-ID: <20080122163211.GB26106@nic.at> Mail-Followup-To: Otmar Lendl , Daryl Malas , "Uzelac, Adam" , speermint@ietf.org References: <19f9b0170801171424p1fb69e97t38af2692ac91a406@mail.gmail.com> <20080118234850.GA22301@nic.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080118234850.GA22301@nic.at> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2008/01/19 00:01, Otmar Lendl wrote: > On 2008/01/17 23:01, Daryl Malas wrote: > > > The definition of a Federation is directly polarized to the concept of > > On-demand, please see below: > > I think it's orthogonal. > > There are federations where the member know each other in advance > and can set up the peering well before the first call comes in, > and I can imagine federations where members discover on demand that > a specific call can be passed towards a fellow federation peer. Daryl and I had a chat yesterday evening trying to find out where exactly our disagreement is, and it seems to be that we categorize the same setup differently. e.g. "on-demand": | 4.2.4. On-demand Peering | | SSPs are said to peer on-demand when they are able to exchange | traffic without any pre-association prior to the origination of a | real-time transaction (like a SIP message) between the domains. Any | information that needs to be exchanged between domains in support | of peering can be learned through a dynamic protocol mechanism. On- | demand peering can occur as direct, indirect, or assisted. The example I wrote can be interpreted in two ways: a) it is "static", as members of the federation manually associate towards the federation before a call can be passed. The federation rules are not learned through a dynamic protocol mechanism. Thus there is "some pre-association". b) it is "on-demand", as a call towards a specific federation member does not need any further pre-association beyond the generic "joining the federation" operation. In other words, association towards the federation is static, towards individual peers can be on-demand. Do we now call this peering "static" or "on-demand"? This is where we seem to disagree (Daryl, please correct me if I got that wrong). Let me propose a litmus question to sort this out: A federation implements internally on-demand peerings if old federation members do not have to change their configuration whenever a new SSP joins this federation. Does this make sense? /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jan 23 13:09:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHk2F-0008Fo-FF; Wed, 23 Jan 2008 13:09:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHk2E-00088v-5C for speermint@ietf.org; Wed, 23 Jan 2008 13:09:14 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHk2D-0000Bq-NT for speermint@ietf.org; Wed, 23 Jan 2008 13:09:14 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id m0NI9Cr9003241 for ; Wed, 23 Jan 2008 11:09:13 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 23 Jan 2008 11:09:12 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Speermint] Common Dynamic Policies Date: Wed, 23 Jan 2008 11:09:12 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA4917B0C2A@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Common Dynamic Policies Thread-Index: Achd6wzxYEHldYrLSlG/MzDakSDIjQ== From: "Daryl Malas" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I am just about to publish rev -15 of the terminology draft, and I noticed something I would like to suggest. I recommend we add transport protocols (e.g. TCP, UDP, etc.) to Section 5, sub-point "Common dynamic policies". Comments? Thanks... Daryl --------------------- Daryl Malas CableLabs d.malas@cablelabs.com tel:+1-303-661-3302 Yahoo/Google IM: dmalas AIM/Skype IM: dwmalas _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jan 23 13:35:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHkRf-0008KN-WD; Wed, 23 Jan 2008 13:35:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHkRe-0008KI-TE for speermint@ietf.org; Wed, 23 Jan 2008 13:35:30 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHkRe-00026J-DW for speermint@ietf.org; Wed, 23 Jan 2008 13:35:30 -0500 Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.41458595; Wed, 23 Jan 2008 13:35:05 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 13:35:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Categorization of Federations Date: Wed, 23 Jan 2008 13:34:40 -0500 Message-ID: <45AEC6EF95942140888406588E1A660203A10233@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <20080122163211.GB26106@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Categorization of Federations Thread-Index: AchdFHn5qqygUAHISLC9e/KYSnnHjgA2LGGg From: "Lee, Yiu" To: "Otmar Lendl" , "Daryl Malas" , "Uzelac, Adam" , X-OriginalArrivalTime: 23 Jan 2008 18:35:05.0960 (UTC) FILETIME=[AC9C8E80:01C85DEE] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org But how does the on-demand peering happens internally in federation? If a SSP joins the federation and wants to have direct connection to another member SSP, today BCP is to have pre-association with the member peer. I think this is categorized to static direct peering, right?=20 This is awesome if a SSP can setup an on-demand direct peering to members in federation, but I don't see how easily to setup a protected channel on demand without using some methods like what you suggested to learn the certificate from the federation facilitator. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Tuesday, January 22, 2008 11:32 AM To: Daryl Malas; Uzelac, Adam; speermint@ietf.org Subject: Re: [Speermint] Categorization of Federations On 2008/01/19 00:01, Otmar Lendl wrote: > On 2008/01/17 23:01, Daryl Malas wrote: > > > The definition of a Federation is directly polarized to the concept=20 > > of On-demand, please see below: >=20 > I think it's orthogonal. >=20 > There are federations where the member know each other in advance and=20 > can set up the peering well before the first call comes in, and I can=20 > imagine federations where members discover on demand that a specific=20 > call can be passed towards a fellow federation peer. Daryl and I had a chat yesterday evening trying to find out where exactly our disagreement is, and it seems to be that we categorize the same setup differently. e.g. "on-demand": | 4.2.4. On-demand Peering |=20 | SSPs are said to peer on-demand when they are able to exchange | traffic without any pre-association prior to the origination of a | real-time transaction (like a SIP message) between the domains. Any | information that needs to be exchanged between domains in support | of peering can be learned through a dynamic protocol mechanism. On- | demand peering can occur as direct, indirect, or assisted. The example I wrote can be interpreted in two ways: a) it is "static", as members of the federation manually associate towards the federation before a call can be passed. The federation rules are not learned through a dynamic protocol mechanism. Thus there is "some pre-association". b) it is "on-demand", as a call towards a specific federation member does not need any further pre-association beyond the generic "joining the federation" operation. In other words, association towards the federation is static, towards individual peers can be on-demand. Do we now call this peering "static" or "on-demand"? This is where we seem to disagree (Daryl, please correct me if I got that wrong). Let me propose a litmus question to sort this out: A federation implements internally on-demand peerings if old federation members do not have to change their configuration whenever a new SSP joins this federation. Does this make sense? /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jan 23 13:43:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHkYv-00070F-Sz; Wed, 23 Jan 2008 13:43:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHkYv-000707-ED for speermint@ietf.org; Wed, 23 Jan 2008 13:43:01 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHkYu-0002JE-K2 for speermint@ietf.org; Wed, 23 Jan 2008 13:43:01 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id m0NIgkYp003414; Wed, 23 Jan 2008 11:42:47 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 23 Jan 2008 11:42:46 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Categorization of Federations Date: Wed, 23 Jan 2008 11:42:46 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA4917B0C2D@srvxchg3.cablelabs.com> In-Reply-To: <45AEC6EF95942140888406588E1A660203A10233@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Categorization of Federations Thread-Index: AchdFHn5qqygUAHISLC9e/KYSnnHjgA2LGGgAACJbrA= References: <20080122163211.GB26106@nic.at> <45AEC6EF95942140888406588E1A660203A10233@PACDCEXCMB04.cable.comcast.com> From: "Daryl Malas" To: "Lee, Yiu" , "Otmar Lendl" , "Uzelac, Adam" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Yiu, I agree with you regarding today's BCP. In response to Otmar and my disagreement. I would assert if a new member joins a federation and is not compatible with the "direct/static" set of guidelines, the Federation would be required to updated the minimum set of rules require to peer within the federation. This still requires/describes pre-association, which violates the "on-demand" premise. Also, why would I join a federation if I did not know how or if I could peer to any of the federated peers? --Daryl -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 Sent: Wednesday, January 23, 2008 11:35 AM To: Otmar Lendl; Daryl Malas; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Categorization of Federations But how does the on-demand peering happens internally in federation? If a SSP joins the federation and wants to have direct connection to another member SSP, today BCP is to have pre-association with the member peer. I think this is categorized to static direct peering, right?=20 This is awesome if a SSP can setup an on-demand direct peering to members in federation, but I don't see how easily to setup a protected channel on demand without using some methods like what you suggested to learn the certificate from the federation facilitator. -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Tuesday, January 22, 2008 11:32 AM To: Daryl Malas; Uzelac, Adam; speermint@ietf.org Subject: Re: [Speermint] Categorization of Federations On 2008/01/19 00:01, Otmar Lendl wrote: > On 2008/01/17 23:01, Daryl Malas wrote: > > > The definition of a Federation is directly polarized to the concept=20 > > of On-demand, please see below: >=20 > I think it's orthogonal. >=20 > There are federations where the member know each other in advance and=20 > can set up the peering well before the first call comes in, and I can=20 > imagine federations where members discover on demand that a specific=20 > call can be passed towards a fellow federation peer. Daryl and I had a chat yesterday evening trying to find out where exactly our disagreement is, and it seems to be that we categorize the same setup differently. e.g. "on-demand": | 4.2.4. On-demand Peering |=20 | SSPs are said to peer on-demand when they are able to exchange | traffic without any pre-association prior to the origination of a | real-time transaction (like a SIP message) between the domains. Any | information that needs to be exchanged between domains in support | of peering can be learned through a dynamic protocol mechanism. On- | demand peering can occur as direct, indirect, or assisted. The example I wrote can be interpreted in two ways: a) it is "static", as members of the federation manually associate towards the federation before a call can be passed. The federation rules are not learned through a dynamic protocol mechanism. Thus there is "some pre-association". b) it is "on-demand", as a call towards a specific federation member does not need any further pre-association beyond the generic "joining the federation" operation. In other words, association towards the federation is static, towards individual peers can be on-demand. Do we now call this peering "static" or "on-demand"? This is where we seem to disagree (Daryl, please correct me if I got that wrong). Let me propose a litmus question to sort this out: A federation implements internally on-demand peerings if old federation members do not have to change their configuration whenever a new SSP joins this federation. Does this make sense? /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jan 23 16:19:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHn07-00035B-46; Wed, 23 Jan 2008 16:19:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHn05-00032L-Ak for speermint@ietf.org; Wed, 23 Jan 2008 16:19:13 -0500 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHn02-0007Ve-In for speermint@ietf.org; Wed, 23 Jan 2008 16:19:13 -0500 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1JHn00-000793-00; Wed, 23 Jan 2008 22:19:08 +0100 Date: Wed, 23 Jan 2008 22:19:08 +0100 From: Otmar Lendl To: "Lee, Yiu" Subject: Re: [Speermint] Categorization of Federations Message-ID: <20080123211907.GA27439@nic.at> Mail-Followup-To: Otmar Lendl , "Lee, Yiu" , speermint@ietf.org References: <20080122163211.GB26106@nic.at> <45AEC6EF95942140888406588E1A660203A10233@PACDCEXCMB04.cable.comcast.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45AEC6EF95942140888406588E1A660203A10233@PACDCEXCMB04.cable.comcast.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2008/01/23 19:01, "Lee, Yiu" wrote: > But how does the on-demand peering happens internally in federation? If > a SSP joins the federation and wants to have direct connection to > another member SSP, today BCP is to have pre-association with the member > peer. I think this is categorized to static direct peering, right? I'm not _quite_ sure whether I really know what you mean exactly by "pre-association". Can you give details on what happens at that stage? Otherwise, yes: if SSPs need to do something extra to enable peerings to a specific federation peer, than I agree that we should call it "static" and "direct" peering. > This is awesome if a SSP can setup an on-demand direct peering to > members in federation, but I don't see how easily to setup a protected > channel on demand without using some methods like what you suggested to > learn the certificate from the federation facilitator. In my examples is it not necessary that federation facilitator distributes the key of each members to all members. It just needs to sign the key of each individual member. You can then build such a federation quite trivially with OpenSER, see http://www.openser.org/docs/tls-1.3.x.html by setting tls_ca_list="/mycerts/certs/fed-ca-cert.pem" tls_verify_client=1 tls_require_client_certificate=1 This tells OpenSer only to allow TLS connects from clients whose key was signed by the federation's CA. This is very basic X.509 stuff. A full description on how to implement such federations using OpenSer (and my domain-policy drafts as federation discovery) can be found at http://www.enum.at/typo3conf/ext/nf_downloads/pi1/passdownload.php?downloaddata=46 Have a look. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 24 13:43:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI73J-0001hO-O8; Thu, 24 Jan 2008 13:43:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI73I-0001hE-Dq for speermint@ietf.org; Thu, 24 Jan 2008 13:43:52 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI73G-0005db-U2 for speermint@ietf.org; Thu, 24 Jan 2008 13:43:52 -0500 Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.2/8.14.2/Debian-2) with ESMTP id m0OIgi7Y028079; Thu, 24 Jan 2008 10:42:44 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.2/8.14.2/Submit) id m0OIghhd028078; Thu, 24 Jan 2008 10:42:43 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 24 Jan 2008 10:42:43 -0800 From: David Meyer To: speermint@ietf.org Message-ID: <20080124184243.GB27931@1-4-5.net> MIME-Version: 1.0 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: "Electric light still struck like arrows // Fired but for the ones // Condemned to drift or else be kept from drifting" -- Bob Dylan, "Chimes of Freedom" User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Jason_Livingood@cable.comcast.com, jon.peterson@neustar.biz Subject: [Speermint] speermint chair changes X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1078765418==" Errors-To: speermint-bounces@ietf.org --===============1078765418== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eJnRUKwClWJh1Khz" Content-Disposition: inline --eJnRUKwClWJh1Khz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks, I wanted to let you know that I'll be standing down as co-chair of SPEERMINT. Daryl Malas has graciously aggreed to take over as co-chair (with Jason). As always, I'm looking forward to all of the great things I know will be accomplished in SPEERMINT. I also wanted to thank you all for your hard work over the past year or so, and for the opportunity to get to know and work with many of you. It has been a great experience.=20 Thanks again, Dave --eJnRUKwClWJh1Khz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHmNwjORgD1qCZ2KcRAt1UAJ0UimIE6DqIVw50yMPcMAe4wIkHdQCdFGnE VjcaVEZrrOlQbLEJx8qKHEU= =ghuI -----END PGP SIGNATURE----- --eJnRUKwClWJh1Khz-- --===============1078765418== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1078765418==-- From speermint-bounces@ietf.org Thu Jan 24 15:10:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8PL-0003wN-4G; Thu, 24 Jan 2008 15:10:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8PJ-0003te-Tj for speermint@ietf.org; Thu, 24 Jan 2008 15:10:41 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI8PJ-0007xH-Ko for speermint@ietf.org; Thu, 24 Jan 2008 15:10:41 -0500 Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.41515043; Thu, 24 Jan 2008 15:10:20 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 15:10:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Jan 2008 15:10:19 -0500 Message-ID: <45AEC6EF95942140888406588E1A660203A5A756@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <20080124184243.GB27931@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: speermint chair changes Thread-Index: AcheuPZQ2o1ZguRdQtCL/idEHG2qmAAC7jCQ References: <20080124184243.GB27931@1-4-5.net> From: "Livingood, Jason" To: "David Meyer" , X-OriginalArrivalTime: 24 Jan 2008 20:10:20.0901 (UTC) FILETIME=[25651950:01C85EC5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: jon.peterson@neustar.biz Subject: [Speermint] RE: speermint chair changes X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Thanks for your service, Dave! You handled all of the BoFs and standing up the WG and getting us to where we are today, which is a very long way from our first BoF. We really appreciate your hard work! And welcome, Daryl! Jason=20 > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net]=20 > Sent: Thursday, January 24, 2008 1:43 PM > To: speermint@ietf.org > Cc: Livingood, Jason; jon.peterson@neustar.biz;=20 > fluffy@cisco.com; d.malas@cablelabs.com > Subject: speermint chair changes >=20 >=20 > Folks, >=20 > I wanted to let you know that I'll be standing down as > co-chair of SPEERMINT. Daryl Malas has graciously aggreed > to take over as co-chair (with Jason). As always, I'm > looking forward to all of the great things I know will be > accomplished in SPEERMINT. >=20 > I also wanted to thank you all for your hard work over > the past year or so, and for the opportunity to get to > know and work with many of you. It has been a great > experience.=20 >=20 > Thanks again, >=20 > Dave >=20 >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 24 16:00:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI9Bo-0008Te-EM; Thu, 24 Jan 2008 16:00:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI9Bn-0008TZ-38 for speermint@ietf.org; Thu, 24 Jan 2008 16:00:47 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI9Bm-0000aw-MB for speermint@ietf.org; Thu, 24 Jan 2008 16:00:47 -0500 Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.2/8.14.2/Debian-2) with ESMTP id m0OL0dhk004499; Thu, 24 Jan 2008 13:00:39 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.2/8.14.2/Submit) id m0OL0dZn004498; Thu, 24 Jan 2008 13:00:39 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 24 Jan 2008 13:00:39 -0800 From: David Meyer To: "Livingood, Jason" Message-ID: <20080124210039.GA4356@1-4-5.net> References: <20080124184243.GB27931@1-4-5.net> <45AEC6EF95942140888406588E1A660203A5A756@PACDCEXCMB04.cable.comcast.com> MIME-Version: 1.0 In-Reply-To: <45AEC6EF95942140888406588E1A660203A5A756@PACDCEXCMB04.cable.comcast.com> 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: "Electric light still struck like arrows // Fired but for the ones // Condemned to drift or else be kept from drifting" -- Bob Dylan, "Chimes of Freedom" User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: speermint@ietf.org, jon.peterson@neustar.biz Subject: [Speermint] Re: speermint chair changes X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0948810456==" Errors-To: speermint-bounces@ietf.org --===============0948810456== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Thanks for your service, Dave! You handled all of the BoFs and standing > up the WG and getting us to where we are today, which is a very long way > from our first BoF. We really appreciate your hard work! Hey, my pleasure. I'm very lucky to have such great colleagues to work with. > And welcome, Daryl! Definitely. Dave --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHmPx3ORgD1qCZ2KcRArESAJ0anOTNTMzMts3S9dHxogz5euaINACfZKcE Ly9HxthXEmVl/NKUr8FlD94= =hIEb -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- --===============0948810456== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0948810456==-- From speermint-bounces@ietf.org Mon Jan 28 12:37:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJXv5-0001Uz-R7; Mon, 28 Jan 2008 12:37:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJXv4-0001UW-Jr for speermint@ietf.org; Mon, 28 Jan 2008 12:37:18 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJXv2-0006DJ-Ru for speermint@ietf.org; Mon, 28 Jan 2008 12:37:18 -0500 Received: from [10.10.0.113] ([::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Mon, 28 Jan 2008 18:37:14 +0100 id 0000C0E0.479E12CA.00006A7E Message-ID: <479E12BE.9000909@enum.at> Date: Mon, 28 Jan 2008 18:37:02 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: speermint@ietf.org, avshalom@il.ibm.com, aoki@aol.net, sriram.parameswar@microsoft.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Subject: [Speermint] (extremely) late comments on draft-ietf-speermint-consolidated-presence-im-usecases-03 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi, i found a couple of nits in the IM-usecases draft. I'm aware that i'm _really_ late, but since i think they improve the document, here you go: - Abstract: please remove "(SP)" from the abstract. Definition of acronyms must not happen in the abstract. - 1. (Introduction): Please explain the acronym "PSTN" acronym here - it's not on the well known list of abbreviations. - 1. (Introduction): the second "(RTC)" (5 lines from end of section) is not needed (is explained in first line already). Please remove it. - 2.1. It might be good to mention which user is associated with with peering network - otherwise that becomes a riddle :). So please add something like "Alice@example.com (with example.com hosted by Peer A)..." to the text. - 2.2. I think the "Ad-hock" group should be an "Ad-hoc" group. Also, in that paragraph, you say "A public group may be created by Alice..." while i think it should read "An ad-hoc group may be created by Alice..." - 2.6. "Fully standardized (became RFCs)" is weak language - as you know, not every RFC is a standard. Also, what is "fully standardized"? - 2.7. I think it should start with "A Federation" instead of "Federation". Also, "Peer Networks may connect each other via a peer-to-peer fashion" should probably read "Peer Networks may connect to each other in a peer-to-peer fashion". - 2.7. The text "the other Peering Network is who it claims to be" sounds unclear to me. You could replace that text by "that enables each Peering Network to clearly identify Peering partners, and set up secured trust relationships" - but that is just a personal suggestion. - 4. I'd replace "We are seeing today users are concerned with providing.." with "We are seeing today users are concerned about providing .." and "domain" with "domain name". - 4. The reference to section 2.3 would look better in parentheses "... (see Section 2.3)". - 4. Last sentence on page 6 - It would be good to change that to "This document discusses ause cases for peering between Peer Networks. It is out of scope of this document to provide for..." - 5. Acknowledgements: nit: My last name is misspelled :) - 6.1. Normative References: You don't use RFC 2119 language in the draft - please remove that reference, it's not neccessary. That's all, i hope it was helpful (though very late). thanks, Alex _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jan 29 10:19:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJsFM-0004q1-IE; Tue, 29 Jan 2008 10:19:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJsFL-0004m1-9E for speermint@ietf.org; Tue, 29 Jan 2008 10:19:35 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJsFK-0005TP-OP for speermint@ietf.org; Tue, 29 Jan 2008 10:19:35 -0500 Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m0TFJVPH016134; Tue, 29 Jan 2008 08:19:31 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 29 Jan 2008 08:19:32 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Categorization of Federations Date: Tue, 29 Jan 2008 08:19:31 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA4917B0C66@srvxchg3.cablelabs.com> In-Reply-To: <20080123211907.GA27439@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Categorization of Federations Thread-Index: AcheBaR0BBpUfstJSkyalwmA8PsCRAEhH8eQ References: <20080122163211.GB26106@nic.at><45AEC6EF95942140888406588E1A660203A10233@PACDCEXCMB04.cable.comcast.com> <20080123211907.GA27439@nic.at> From: "Daryl Malas" To: "Otmar Lendl" , "Lee, Yiu" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I would like to suggest some updated wording for "Static Peering" in the terminology draft to clear up some confusion. I tried to keep it simple, but would like to get your comments. 4.2.4. Static Peering SSPs are said to peer statically when pre-association between providers is required for the initiation of any real-time transactions (like a SIP message). Static peering can occur as direct or indirect. An example of static peering is a federation. Each of the peers within the federation must first agree on a common set of rules and guidelines for peering, thus pre-associating with each other prior to initiating session requests. Thanks...--Daryl=20 -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Wednesday, January 23, 2008 2:19 PM To: Lee, Yiu Cc: speermint@ietf.org Subject: Re: [Speermint] Categorization of Federations On 2008/01/23 19:01, "Lee, Yiu" wrote: > But how does the on-demand peering happens internally in federation?=20 > If a SSP joins the federation and wants to have direct connection to=20 > another member SSP, today BCP is to have pre-association with the=20 > member peer. I think this is categorized to static direct peering, right? I'm not _quite_ sure whether I really know what you mean exactly by "pre-association". Can you give details on what happens at that stage? Otherwise, yes: if SSPs need to do something extra to enable peerings to a specific federation peer, than I agree that we should call it "static" and "direct" peering. > This is awesome if a SSP can setup an on-demand direct peering to=20 > members in federation, but I don't see how easily to setup a protected > channel on demand without using some methods like what you suggested=20 > to learn the certificate from the federation facilitator. In my examples is it not necessary that federation facilitator distributes the key of each members to all members. It just needs to sign the key of each individual member. You can then build such a federation quite trivially with OpenSER, see http://www.openser.org/docs/tls-1.3.x.html by setting tls_ca_list=3D"/mycerts/certs/fed-ca-cert.pem" tls_verify_client=3D1 tls_require_client_certificate=3D1 This tells OpenSer only to allow TLS connects from clients whose key was signed by the federation's CA. This is very basic X.509 stuff. A full description on how to implement such federations using OpenSer (and my domain-policy drafts as federation discovery) can be found at http://www.enum.at/typo3conf/ext/nf_downloads/pi1/passdownload.php?downl oaddata=3D46 Have a look. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jan 29 16:10:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJxj3-0001ZB-9X; Tue, 29 Jan 2008 16:10:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJxiy-0001U8-Ma; Tue, 29 Jan 2008 16:10:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJxiy-00040u-Aw; Tue, 29 Jan 2008 16:10:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 455F12AC6D; Tue, 29 Jan 2008 21:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JJxiU-0005QF-1e; Tue, 29 Jan 2008 16:10: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: Tue, 29 Jan 2008 16:10:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: speermint@ietf.org Subject: [Speermint] I-D Action:draft-ietf-speermint-terminology-15.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Terminology Author(s) : D. Malas, D. Meyer Filename : draft-ietf-speermint-terminology-15.txt Pages : 12 Date : 2008-01-29 This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-15.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-speermint-terminology-15.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-speermint-terminology-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-29160420.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-terminology-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-terminology-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-29160420.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Tue Jan 29 16:28:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJy0T-0006c7-So; Tue, 29 Jan 2008 16:28:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJy0S-0006Zw-Ub for speermint@ietf.org; Tue, 29 Jan 2008 16:28:36 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJy0Q-0007Q2-Nq for speermint@ietf.org; Tue, 29 Jan 2008 16:28:36 -0500 Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.41692900; Tue, 29 Jan 2008 16:28:20 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 16:28:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Categorization of Federations Date: Tue, 29 Jan 2008 16:27:51 -0500 Message-ID: <45AEC6EF95942140888406588E1A660203B261B3@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA4917B0C66@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Categorization of Federations Thread-Index: AcheBaR0BBpUfstJSkyalwmA8PsCRAEhH8eQAAzIBbA= From: "Lee, Yiu" To: "Daryl Malas" , "Otmar Lendl" X-OriginalArrivalTime: 29 Jan 2008 21:28:20.0541 (UTC) FILETIME=[DEBE3ED0:01C862BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org As long as the rest of the team agrees that Federation is one kind of "Static Peering", I am ok for this description. =20 Thanks, Yiu -----Original Message----- From: Daryl Malas [mailto:D.Malas@cablelabs.com]=20 Sent: Tuesday, January 29, 2008 10:20 AM To: Otmar Lendl; Lee, Yiu Cc: speermint@ietf.org Subject: RE: [Speermint] Categorization of Federations I would like to suggest some updated wording for "Static Peering" in the terminology draft to clear up some confusion. I tried to keep it simple, but would like to get your comments. 4.2.4. Static Peering SSPs are said to peer statically when pre-association between providers is required for the initiation of any real-time transactions (like a SIP message). Static peering can occur as direct or indirect. An example of static peering is a federation. Each of the peers within the federation must first agree on a common set of rules and guidelines for peering, thus pre-associating with each other prior to initiating session requests. Thanks...--Daryl=20 -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Wednesday, January 23, 2008 2:19 PM To: Lee, Yiu Cc: speermint@ietf.org Subject: Re: [Speermint] Categorization of Federations On 2008/01/23 19:01, "Lee, Yiu" wrote: > But how does the on-demand peering happens internally in federation?=20 > If a SSP joins the federation and wants to have direct connection to=20 > another member SSP, today BCP is to have pre-association with the=20 > member peer. I think this is categorized to static direct peering, right? I'm not _quite_ sure whether I really know what you mean exactly by "pre-association". Can you give details on what happens at that stage? Otherwise, yes: if SSPs need to do something extra to enable peerings to a specific federation peer, than I agree that we should call it "static" and "direct" peering. > This is awesome if a SSP can setup an on-demand direct peering to=20 > members in federation, but I don't see how easily to setup a protected > channel on demand without using some methods like what you suggested=20 > to learn the certificate from the federation facilitator. In my examples is it not necessary that federation facilitator distributes the key of each members to all members. It just needs to sign the key of each individual member. You can then build such a federation quite trivially with OpenSER, see http://www.openser.org/docs/tls-1.3.x.html by setting tls_ca_list=3D"/mycerts/certs/fed-ca-cert.pem" tls_verify_client=3D1 tls_require_client_certificate=3D1 This tells OpenSer only to allow TLS connects from clients whose key was signed by the federation's CA. This is very basic X.509 stuff. A full description on how to implement such federations using OpenSer (and my domain-policy drafts as federation discovery) can be found at http://www.enum.at/typo3conf/ext/nf_downloads/pi1/passdownload.php?downl oaddata=3D46 Have a look. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jan 29 16:30:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJy24-0007tB-Tq; Tue, 29 Jan 2008 16:30:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJy23-0007su-Ly for speermint@ietf.org; Tue, 29 Jan 2008 16:30:15 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJy22-0005Vh-U0 for speermint@ietf.org; Tue, 29 Jan 2008 16:30:15 -0500 Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m0TLUC0L027492; Tue, 29 Jan 2008 14:30:12 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 29 Jan 2008 14:30:13 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Categorization of Federations Date: Tue, 29 Jan 2008 14:30:13 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA4917B0C6B@srvxchg3.cablelabs.com> In-Reply-To: <45AEC6EF95942140888406588E1A660203B261B3@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Categorization of Federations Thread-Index: AcheBaR0BBpUfstJSkyalwmA8PsCRAEhH8eQAAzIBbAAAC2MoA== References: <160DE07A1C4F8E4AA2715DEC577DA4917B0C66@srvxchg3.cablelabs.com> <45AEC6EF95942140888406588E1A660203B261B3@PACDCEXCMB04.cable.comcast.com> From: "Daryl Malas" To: "Lee, Yiu" , "Otmar Lendl" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I am not sure I understand what you mean. Can you please explain? The definition still indicates static peering can be both direct and indirect. Thanks...--Daryl=20 -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com]=20 Sent: Tuesday, January 29, 2008 2:28 PM To: Daryl Malas; Otmar Lendl Cc: speermint@ietf.org Subject: RE: [Speermint] Categorization of Federations As long as the rest of the team agrees that Federation is one kind of "Static Peering", I am ok for this description. =20 Thanks, Yiu -----Original Message----- From: Daryl Malas [mailto:D.Malas@cablelabs.com] Sent: Tuesday, January 29, 2008 10:20 AM To: Otmar Lendl; Lee, Yiu Cc: speermint@ietf.org Subject: RE: [Speermint] Categorization of Federations I would like to suggest some updated wording for "Static Peering" in the terminology draft to clear up some confusion. I tried to keep it simple, but would like to get your comments. 4.2.4. Static Peering SSPs are said to peer statically when pre-association between providers is required for the initiation of any real-time transactions (like a SIP message). Static peering can occur as direct or indirect. An example of static peering is a federation. Each of the peers within the federation must first agree on a common set of rules and guidelines for peering, thus pre-associating with each other prior to initiating session requests. Thanks...--Daryl=20 -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Wednesday, January 23, 2008 2:19 PM To: Lee, Yiu Cc: speermint@ietf.org Subject: Re: [Speermint] Categorization of Federations On 2008/01/23 19:01, "Lee, Yiu" wrote: > But how does the on-demand peering happens internally in federation?=20 > If a SSP joins the federation and wants to have direct connection to=20 > another member SSP, today BCP is to have pre-association with the=20 > member peer. I think this is categorized to static direct peering, right? I'm not _quite_ sure whether I really know what you mean exactly by "pre-association". Can you give details on what happens at that stage? Otherwise, yes: if SSPs need to do something extra to enable peerings to a specific federation peer, than I agree that we should call it "static" and "direct" peering. > This is awesome if a SSP can setup an on-demand direct peering to=20 > members in federation, but I don't see how easily to setup a protected > channel on demand without using some methods like what you suggested=20 > to learn the certificate from the federation facilitator. In my examples is it not necessary that federation facilitator distributes the key of each members to all members. It just needs to sign the key of each individual member. You can then build such a federation quite trivially with OpenSER, see http://www.openser.org/docs/tls-1.3.x.html by setting tls_ca_list=3D"/mycerts/certs/fed-ca-cert.pem" tls_verify_client=3D1 tls_require_client_certificate=3D1 This tells OpenSer only to allow TLS connects from clients whose key was signed by the federation's CA. This is very basic X.509 stuff. A full description on how to implement such federations using OpenSer (and my domain-policy drafts as federation discovery) can be found at http://www.enum.at/typo3conf/ext/nf_downloads/pi1/passdownload.php?downl oaddata=3D46 Have a look. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jan 29 16:35:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJy78-0004EB-Um; Tue, 29 Jan 2008 16:35:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJy77-0004Cc-R4 for speermint@ietf.org; Tue, 29 Jan 2008 16:35:29 -0500 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJy76-0007pS-1D for speermint@ietf.org; Tue, 29 Jan 2008 16:35:29 -0500 Received: from ([10.195.246.152]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.51357105; Tue, 29 Jan 2008 16:35:02 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 16:35:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Categorization of Federations Date: Tue, 29 Jan 2008 16:34:33 -0500 Message-ID: <45AEC6EF95942140888406588E1A660203B261B7@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA4917B0C6B@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Categorization of Federations Thread-Index: AcheBaR0BBpUfstJSkyalwmA8PsCRAEhH8eQAAzIBbAAAC2MoAAAGz+g From: "Lee, Yiu" To: "Daryl Malas" , "Otmar Lendl" X-OriginalArrivalTime: 29 Jan 2008 21:35:02.0651 (UTC) FILETIME=[CE6B5CB0:01C862BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Yes. I know it can be Direct and Indirect. Adam and I agree with you that Federation is Static Peering. I just wonder is there any people thinking that Federation can be built on "On-demand" peering. That's it. Thanks, Yiu -----Original Message----- From: Daryl Malas [mailto:D.Malas@cablelabs.com]=20 Sent: Tuesday, January 29, 2008 4:30 PM To: Lee, Yiu; Otmar Lendl Cc: speermint@ietf.org Subject: RE: [Speermint] Categorization of Federations I am not sure I understand what you mean. Can you please explain? The definition still indicates static peering can be both direct and indirect. Thanks...--Daryl=20 -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com] Sent: Tuesday, January 29, 2008 2:28 PM To: Daryl Malas; Otmar Lendl Cc: speermint@ietf.org Subject: RE: [Speermint] Categorization of Federations As long as the rest of the team agrees that Federation is one kind of "Static Peering", I am ok for this description. =20 Thanks, Yiu -----Original Message----- From: Daryl Malas [mailto:D.Malas@cablelabs.com] Sent: Tuesday, January 29, 2008 10:20 AM To: Otmar Lendl; Lee, Yiu Cc: speermint@ietf.org Subject: RE: [Speermint] Categorization of Federations I would like to suggest some updated wording for "Static Peering" in the terminology draft to clear up some confusion. I tried to keep it simple, but would like to get your comments. 4.2.4. Static Peering SSPs are said to peer statically when pre-association between providers is required for the initiation of any real-time transactions (like a SIP message). Static peering can occur as direct or indirect. An example of static peering is a federation. Each of the peers within the federation must first agree on a common set of rules and guidelines for peering, thus pre-associating with each other prior to initiating session requests. Thanks...--Daryl=20 -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Wednesday, January 23, 2008 2:19 PM To: Lee, Yiu Cc: speermint@ietf.org Subject: Re: [Speermint] Categorization of Federations On 2008/01/23 19:01, "Lee, Yiu" wrote: > But how does the on-demand peering happens internally in federation?=20 > If a SSP joins the federation and wants to have direct connection to=20 > another member SSP, today BCP is to have pre-association with the=20 > member peer. I think this is categorized to static direct peering, right? I'm not _quite_ sure whether I really know what you mean exactly by "pre-association". Can you give details on what happens at that stage? Otherwise, yes: if SSPs need to do something extra to enable peerings to a specific federation peer, than I agree that we should call it "static" and "direct" peering. > This is awesome if a SSP can setup an on-demand direct peering to=20 > members in federation, but I don't see how easily to setup a protected > channel on demand without using some methods like what you suggested=20 > to learn the certificate from the federation facilitator. In my examples is it not necessary that federation facilitator distributes the key of each members to all members. It just needs to sign the key of each individual member. You can then build such a federation quite trivially with OpenSER, see http://www.openser.org/docs/tls-1.3.x.html by setting tls_ca_list=3D"/mycerts/certs/fed-ca-cert.pem" tls_verify_client=3D1 tls_require_client_certificate=3D1 This tells OpenSer only to allow TLS connects from clients whose key was signed by the federation's CA. This is very basic X.509 stuff. A full description on how to implement such federations using OpenSer (and my domain-policy drafts as federation discovery) can be found at http://www.enum.at/typo3conf/ext/nf_downloads/pi1/passdownload.php?downl oaddata=3D46 Have a look. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jan 29 16:41:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJyCm-0004bK-Du; Tue, 29 Jan 2008 16:41:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJyCl-0004Yi-Ct for speermint@ietf.org; Tue, 29 Jan 2008 16:41:19 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJyCk-0007yV-QN for speermint@ietf.org; Tue, 29 Jan 2008 16:41:19 -0500 Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m0TLfIMU032623 for ; Tue, 29 Jan 2008 14:41:18 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 29 Jan 2008 14:41:17 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Speermint] RE: I-D Action:draft-ietf-speermint-terminology-15.txt Date: Tue, 29 Jan 2008 14:41:17 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA4917B0C6D@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: I-D Action:draft-ietf-speermint-terminology-15.txt Thread-Index: Achiu2zGjCE7c4pdRx+jVFTZe7oYfAAA6VJw References: From: "Daryl Malas" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org This version of the draft includes updates to the following sections: Section 2. Context Section 4.2.3 Assisted Peering (REMOVED) Section 4.3.1 Location Routing Function Section 4.3.2 Location Routing Function (Previously Look-Up Function) Section 5 - Minor add to "Common dynamic policies" Section 9 & 10 --Daryl -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, January 29, 2008 2:10 PM To: i-d-announce@ietf.org Cc: speermint@ietf.org Subject: [Speermint] I-D Action:draft-ietf-speermint-terminology-15.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Terminology Author(s) : D. Malas, D. Meyer Filename : draft-ietf-speermint-terminology-15.txt Pages : 12 Date : 2008-01-29 This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-15. 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-speermint-terminology-15.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-speermint-terminology-15.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. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jan 30 02:46:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK7eg-00084Q-AT; Wed, 30 Jan 2008 02:46:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK7ef-0007yC-5x for speermint@ietf.org; Wed, 30 Jan 2008 02:46:45 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JK7ee-0002Kr-BR for speermint@ietf.org; Wed, 30 Jan 2008 02:46:45 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JVG00H3S5LTB0@siemenscomms.co.uk> for speermint@ietf.org; Wed, 30 Jan 2008 07:46:41 +0000 (GMT) Date: Wed, 30 Jan 2008 07:46:40 +0000 From: "Elwell, John" Subject: RE: [Speermint] RE: I-D Action:draft-ietf-speermint-terminology-15.txt In-reply-to: <160DE07A1C4F8E4AA2715DEC577DA4917B0C6D@srvxchg3.cablelabs.com> To: Daryl Malas , speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D05CF164@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Speermint] RE: I-D Action:draft-ietf-speermint-terminology-15.txt Thread-Index: Achiu2zGjCE7c4pdRx+jVFTZe7oYfAAA6VJwABS+aJA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <160DE07A1C4F8E4AA2715DEC577DA4917B0C6D@srvxchg3.cablelabs.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl, Thanks, it's getting there. A few more things I noticed: 1. The document uses the words "application" and "session" in a number of places, and I feel there may be some inconsistency. For example: "A SIP Service Provider (or SSP) is an entity that provides=20 application services utilizing SIP signaling to its customers." Should it really be "application services", or should it be "session services". Consider a service provider that provides no more than SIP proxy functionality. It can hardly be said to provide application services to its users, so according to the definition it is not an SSP. There is just one other instance of "application". I wonder if the two instances should be changed to "session". 2. "In some cases, some entity (usually a 3rd party or federation)=20 provides peering assistance to the originating SSP by providing this=20 function. The assisting entity may provide information relating to=20 direct (Section 4.2.1) or indirect (Section 4.2.2) peering as=20 necessary." Two comments. First, should "peering assistance" be changed to "assistance". Second, this paragraph occurs within 4.3.2 on LRF. Should a similar statement be added to 4.3.1 on LuF? 3. "In this case it is generally required that a=20 trust relationship is established between the originating SSP and the transit network on one side; and, the transit network representing=20 the termination network on the other side." Two comments: First, in order to complement the first part, should the latter part be rewritten as "; and the transit network and the terminating SSP on the other side."? Second, on the use of the term "transit network". Is this intentional, or would it be better to talk about "transit SSP". In this context a transit network must provide functionality at the session layer (otherwise it would not be considered as indirect peering), so doesn't this make it an SSP? John > -----Original Message----- > From: Daryl Malas [mailto:D.Malas@cablelabs.com]=20 > Sent: 29 January 2008 21:41 > To: speermint@ietf.org > Subject: [Speermint] RE: I-D=20 > Action:draft-ietf-speermint-terminology-15.txt >=20 > This version of the draft includes updates to the following sections: >=20 > Section 2. Context > Section 4.2.3 Assisted Peering (REMOVED) > Section 4.3.1 Location Routing Function > Section 4.3.2 Location Routing Function (Previously Look-Up Function) > Section 5 - Minor add to "Common dynamic policies" > Section 9 & 10 >=20 > --Daryl >=20 >=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Tuesday, January 29, 2008 2:10 PM > To: i-d-announce@ietf.org > Cc: speermint@ietf.org > Subject: [Speermint] I-D=20 > Action:draft-ietf-speermint-terminology-15.txt=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session PEERing for Multimedia > INTerconnect Working Group of the IETF. >=20 >=20 > Title : SPEERMINT Terminology > Author(s) : D. Malas, D. Meyer > Filename : draft-ietf-speermint-terminology-15.txt > Pages : 12 > Date : 2008-01-29 >=20 > This document defines the terminology that is to be used in describing > Session PEERing for Multimedia INTerconnect (SPEERMINT). >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-speermint-termi > nology-15. > txt >=20 > 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. >=20 > 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-speermint-terminology-15.txt". >=20 > 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 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-speermint-terminology-15.txt". >=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 31 03:28:57 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKUn0-0008JB-9O; Thu, 31 Jan 2008 03:28:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKUmy-0008Io-CW for speermint@ietf.org; Thu, 31 Jan 2008 03:28:52 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JKUmx-0005pV-U2 for speermint@ietf.org; Thu, 31 Jan 2008 03:28:52 -0500 Received: (qmail invoked by alias); 31 Jan 2008 08:28:50 -0000 Received: from proxy3-nsn.nsn-inter.net (EHLO [217.115.75.231]) [217.115.75.231] by mail.gmx.net (mp044) with SMTP; 31 Jan 2008 09:28:50 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/oxxsuCefotyWAlVcNLyYD3xsfZ8S2DDpYfydTxu dtmH48XNfgrt44 Message-ID: <47A186C1.7080004@gmx.net> Date: Thu, 31 Jan 2008 10:28:49 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: speermint@ietf.org, ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Speermint] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi all, I wanted to ask you for your opinion since the following issue has been brought forward to me many times already. One deployment mode for the emergency services architecture is to route calls through the user's VoIP provider (VSP) and then towards the PSAP. Since the VSP is typically not in the visited network there is obviously the problem that the emergency SIP call (not the RTP, which would travel directly -- hopefully) needs to be handled properly when it leaves the VSP, potentially traverses some other peering networks, and then finally hits the PSAP. Some folks, particularly those with an IMS background, argue that "everything" should be done locally at the visited network rather than routing the call through the user's VSP where things could potentially go wrong along the path between the PSAP and the VSP. Thoughts about this aspect? Ciao Hannes _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 31 07:52:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKYu7-0003bH-AZ; Thu, 31 Jan 2008 07:52:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKYu6-0003ah-Cb for speermint@ietf.org; Thu, 31 Jan 2008 07:52:30 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JKYu5-0000jI-ML for speermint@ietf.org; Thu, 31 Jan 2008 07:52:30 -0500 Received: (qmail invoked by alias); 31 Jan 2008 12:52:27 -0000 Received: from proxy3-nsn.nsn-inter.net (EHLO [217.115.75.231]) [217.115.75.231] by mail.gmx.net (mp032) with SMTP; 31 Jan 2008 13:52:27 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ZnF0EJjKZkA7zvgquyV4ZEMd+PbA9e8OpfifHHk IcE50btI99vj8d Message-ID: <47A1C47B.7040800@gmx.net> Date: Thu, 31 Jan 2008 14:52:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Dawson, Martin" References: <47A186C1.7080004@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: speermint@ietf.org, ECRIT Subject: [Speermint] Re: [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi Martin, thanks for the quick feedback. Dawson, Martin wrote: > Good question! And one I tried to have discussed late last year. > > Really. I must have missed it. > I don't see any benefit in involving the VSP - for the caller, the VSP, > or the emergency service. > > It's been said that the emergency service wants the subscriber details > from the VSP. A caller can have subscriptions to lots of Internet > services that also don't need to be involved in the call. Should we also > make emergency calling dependent on them? > The idea was that the emergency call works in the same fashion as any other call. Normal calls just go via your VSP. The fact that you could attach identity information is quite useful as well (for security reasons). > I don't think it has to be the same as IMS. IMS requires a co-operative > E-CSCF that is actually part of the access network. With LoST and a > suitable emergency proxy, there doesn't have to be any dependency on the > access network to also provide call processing. > What do you mean by "suitable emergency proxy"? Who would operate it? > Not involving the VSP in the call does not mean that the caller cannot > provide callback details (in principle, they could provide multiple > callback options). I'd also be interested in a discussion around > providing an automatic presence subscription from the emergency network > itself - with a temporary callback number. As long as the emergency > calling device is attached to the Internet, it should be able to stay > registered with that temporary subscription and also do regular location > updates to it. > I agree that there are different ways todo the call back. > Many of the most convoluted issues that have arisen in this forum have > been around the challenges that having the VSP involved in call routing > introduces (the need for forest guides etc). Since direct-calling is a > valid option, I know I'd prefer an emergency calling client that always > worked that way. > You aren't worried about the lack of identity information. Right? Ciao Hannes > Cheers, > Martin > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, 31 January 2008 7:29 PM > To: speermint@ietf.org; ECRIT > Subject: [Ecrit] Emergency Calls & VoIP Peering > > Hi all, > > I wanted to ask you for your opinion since the following issue has been > brought forward to me many times already. > > One deployment mode for the emergency services architecture is to route > calls through the user's VoIP provider (VSP) and then towards the PSAP. > Since the VSP is typically not in the visited network there is obviously > > the problem that the emergency SIP call (not the RTP, which would travel > > directly -- hopefully) needs to be handled properly when it leaves the > VSP, potentially traverses some other peering networks, and then finally > > hits the PSAP. > > Some folks, particularly those with an IMS background, argue that > "everything" should be done locally at the visited network rather than > routing the call through the user's VSP where things could potentially > go wrong along the path between the PSAP and the VSP. > > Thoughts about this aspect? > > Ciao > Hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 31 11:55:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKchS-0006dA-U1; Thu, 31 Jan 2008 11:55:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKchR-0006V2-9T; Thu, 31 Jan 2008 11:55:41 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKchQ-0000g6-Nz; Thu, 31 Jan 2008 11:55:41 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JKchK-0006L5-FD; Thu, 31 Jan 2008 10:55:34 -0600 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Hannes Tschofenig'" , , "'ECRIT'" References: <47A186C1.7080004@gmx.net> Date: Thu, 31 Jan 2008 11:55:36 -0500 Message-ID: <005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAjcGcA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Subject: [Speermint] RE: [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org First my response to the original question: IMS is special because the visited network is in the call path. When the visited network has active elements in the call path, it makes sense to have the visited network handle emergency calls. Note that there are lots and lots of complications with this. Take for example, call back. What you want is to have both a Contact URI that will route back to the device that placed the call, and you need a real AoR you can use to reach the caller later on. The visited network would have to provide both. When the visited network is not in the call path, you have to use the VSP. Then my response to Martin: > It's been said that the emergency service wants the subscriber details > from the VSP. A caller can have subscriptions to lots of Internet > services that also don't need to be involved in the call. Should we also > make emergency calling dependent on them? No. However, involving the actual carrier that provides the service that is placing the call is essential. Bypassing the carrier that provides the service that places the call is pretty tough, except in unusual circumstances. IMS is an example of an unusual circumstance because they put the visited network in the call path. Very few other systems do that. I'm very conscious of what we must ask the access network to provide. This has lots of implications on engineering as well as cost and liability. Unless the device itself can locate itself without assistance of the access network, we ask the access network to provide location (or at least location assistance). We ask them to provide access to a LoST server. I want to stop there. That's all they have to do. > > I don't think it has to be the same as IMS. IMS requires a co-operative > E-CSCF that is actually part of the access network. With LoST and a > suitable emergency proxy, there doesn't have to be any dependency on the > access network to also provide call processing. IMS is different as discussed above. > > Not involving the VSP in the call does not mean that the caller cannot > provide callback details (in principle, they could provide multiple > callback options). I'd also be interested in a discussion around > providing an automatic presence subscription from the emergency network > itself - with a temporary callback number. As long as the emergency > calling device is attached to the Internet, it should be able to stay > registered with that temporary subscription and also do regular location > updates to it. I think the notion that we can define the characteristics of an emergency proxy that works for all devices is not feasible. Let me cite a few examples: Emergency call from AOL/MSN/Yahoo. We would have to require the device to implement SIP/SIMPLE. Emergency call from OnStar. Who is the emergency proxy provider? Emergency call from "Help I've fallen and I can't get up" buttons with two way audio. They would have to meet all of the phonebcp requirements. Call backs are an issue. You can get a contact URI, but you can't get an AoR you have any trust in for any call. But the biggest problem is that I think any attempt to give the access network the obligation and the liability to totally handle emergency calls will not fly. > > Many of the most convoluted issues that have arisen in this forum have > been around the challenges that having the VSP involved in call routing > introduces (the need for forest guides etc). Since direct-calling is a > valid option, I know I'd prefer an emergency calling client that always > worked that way. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 31 12:10:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKcva-0000o2-3C; Thu, 31 Jan 2008 12:10:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKcvZ-0000nb-0f; Thu, 31 Jan 2008 12:10:17 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKcvX-000273-Io; Thu, 31 Jan 2008 12:10:16 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JKcvR-0007qv-6T; Thu, 31 Jan 2008 11:10:09 -0600 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Dawson, Martin'" , "'Hannes Tschofenig'" , , "'ECRIT'" References: <47A186C1.7080004@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA0741EDAA@crexc41p> Date: Thu, 31 Jan 2008 12:10:11 -0500 Message-ID: <006601c8642c$25402ac0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0741EDAA@crexc41p> Thread-Index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAmQvbAAAGCaEA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [Speermint] RE: [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I made the same assumption, which I know to be wrong. Thank you for correcting us. Is "3GPP Access Network" the right terminology for the kind of network where the visited network provides the E-CSCF? Brian > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Thursday, January 31, 2008 12:05 PM > To: Dawson, Martin; Hannes Tschofenig; speermint@ietf.org; ECRIT > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > snip... > > IMS requires a co-operative > > E-CSCF that is actually part of the access network. > > This is not true. Please don't confuse "IMS" with "3GPP Access Network" > and early 3GPP IMS definitions. They aren't the same. It's absolutely > possible to have an IMS core that exists only on the Internet, and that > makes no assumptions about access networks. > Barbara > > ***** > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other > use of, or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. If > you received this in error, please contact the sender and delete the > material from all computers. GA622 > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 31 14:03:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKehO-0003F0-5M; Thu, 31 Jan 2008 14:03:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKehN-0003EG-Jm; Thu, 31 Jan 2008 14:03:45 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKehM-0005mp-Sv; Thu, 31 Jan 2008 14:03:45 -0500 X-IronPort-AV: E=Sophos;i="4.25,286,1199682000"; d="scan'208";a="85147931" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Jan 2008 14:03:44 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0VJ3iJ2019467; Thu, 31 Jan 2008 14:03:44 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0VJ3N80002709; Thu, 31 Jan 2008 19:03:32 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 14:03:16 -0500 Received: from [161.44.174.133] ([161.44.174.133]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 14:03:16 -0500 Message-ID: <47A21B7B.2060903@cisco.com> Date: Thu, 31 Jan 2008 14:03:23 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Speermint] RE: [Ecrit] Emergency Calls & VoIP Peering References: <47A186C1.7080004@gmx.net> <005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> In-Reply-To: <005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2008 19:03:16.0309 (UTC) FILETIME=[EF715850:01C8643B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4546; t=1201806224; x=1202670224; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Speermint]=20RE=3A=20[Ecrit]=20Emergen cy=20Calls=20&=20VoIP=20Peering |Sender:=20 |To:=20Brian=20Rosen=20; bh=F0TexCkVvK0wWspPUxQUPj8dkGIvCBHPVm7qxs3SQxc=; b=MKlRQ7yq0gT/HzQ4fXx466ht8yTHL6d6zywK34rG8Dp/8oVvHax8mIdOXO Mn2Pnxi/9B9KlcW+kk8NwwokJlqJ9xRnG66qmAY9epKHtyFRLQ/sxKHEDYde I01tPVRmK4; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: "'Dawson, Martin'" , 'ECRIT' , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian Rosen wrote: > First my response to the original question: > > IMS is special because the visited network is in the call path. When the > visited network has active elements in the call path, it makes sense to have > the visited network handle emergency calls. I think that is acceptable *if* the access network has a well defined, unambiguous way to discern whether a call is an emergency call or not. If the R-URI is then there is no problem at all. If the R-URI is then again there is no problem. But if the R-URI is then it is very problematic if a visited network in the US decides this is an emergency call because of the "911". OTOH the owner of the domain *can* decide this is an emergency call based on its understanding of its numbering plan. Paul > Note that there are lots and > lots of complications with this. Take for example, call back. What you > want is to have both a Contact URI that will route back to the device that > placed the call, and you need a real AoR you can use to reach the caller > later on. The visited network would have to provide both. > > When the visited network is not in the call path, you have to use the VSP. > > > Then my response to Martin: >> It's been said that the emergency service wants the subscriber details >> from the VSP. A caller can have subscriptions to lots of Internet >> services that also don't need to be involved in the call. Should we also >> make emergency calling dependent on them? > No. However, involving the actual carrier that provides the service that is > placing the call is essential. Bypassing the carrier that provides the > service that places the call is pretty tough, except in unusual > circumstances. IMS is an example of an unusual circumstance because they > put the visited network in the call path. Very few other systems do that. > > I'm very conscious of what we must ask the access network to provide. This > has lots of implications on engineering as well as cost and liability. > Unless the device itself can locate itself without assistance of the access > network, we ask the access network to provide location (or at least location > assistance). We ask them to provide access to a LoST server. I want to > stop there. That's all they have to do. > >> I don't think it has to be the same as IMS. IMS requires a co-operative >> E-CSCF that is actually part of the access network. With LoST and a >> suitable emergency proxy, there doesn't have to be any dependency on the >> access network to also provide call processing. > IMS is different as discussed above. > >> Not involving the VSP in the call does not mean that the caller cannot >> provide callback details (in principle, they could provide multiple >> callback options). I'd also be interested in a discussion around >> providing an automatic presence subscription from the emergency network >> itself - with a temporary callback number. As long as the emergency >> calling device is attached to the Internet, it should be able to stay >> registered with that temporary subscription and also do regular location >> updates to it. > I think the notion that we can define the characteristics of an emergency > proxy that works for all devices is not feasible. Let me cite a few > examples: > > Emergency call from AOL/MSN/Yahoo. We would have to require the device to > implement SIP/SIMPLE. > > Emergency call from OnStar. Who is the emergency proxy provider? > > Emergency call from "Help I've fallen and I can't get up" buttons with two > way audio. They would have to meet all of the phonebcp requirements. > > Call backs are an issue. You can get a contact URI, but you can't get an > AoR you have any trust in for any call. > > But the biggest problem is that I think any attempt to give the access > network the obligation and the liability to totally handle emergency calls > will not fly. > > >> Many of the most convoluted issues that have arisen in this forum have >> been around the challenges that having the VSP involved in call routing >> introduces (the need for forest guides etc). Since direct-calling is a >> valid option, I know I'd prefer an emergency calling client that always >> worked that way. > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 31 14:23:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKf0q-0004F8-48; Thu, 31 Jan 2008 14:23:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKf0p-0004Ea-7h; Thu, 31 Jan 2008 14:23:51 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKf0o-0005cM-Rs; Thu, 31 Jan 2008 14:23:51 -0500 X-IronPort-AV: E=Sophos;i="4.25,286,1199682000"; d="scan'208";a="85150807" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Jan 2008 14:23:51 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0VJNoSF032021; Thu, 31 Jan 2008 14:23:50 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0VJNl7s011468; Thu, 31 Jan 2008 19:23:50 GMT 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.1830); Thu, 31 Jan 2008 14:22:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Emergency Calls & VoIP Peering Date: Thu, 31 Jan 2008 14:23:05 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E304471B4F@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <47A186C1.7080004@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Emergency Calls & VoIP Peering Thread-Index: Achj419/w1RU7q+QTFC8ooXkXIowAwAWvy6g References: <47A186C1.7080004@gmx.net> From: "Michael Hammer (mhammer)" To: "Hannes Tschofenig" , , "ECRIT" X-OriginalArrivalTime: 31 Jan 2008 19:22:30.0171 (UTC) FILETIME=[9F32B6B0:01C8643E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1583; t=1201807430; x=1202671430; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20(mhammer)=22=20 |Subject:=20RE=3A=20[Speermint]=20Emergency=20Calls=20&=20V oIP=20Peering |Sender:=20 |To:=20=22Hannes=20Tschofenig=22=20,=20,=0A=20=20=20=20=20=20=20=20=22EC RIT=22=20; bh=9F79Wbk3MFWuifH3snb3068LWytCiAE4Oz3iXDFVMz8=; b=UngzMAZe8yGsY5gqrLXoKhHjPnjd+PtJ4sFLXz1FrBbK8pleyEnDmAEUYS ersWwyggXy9tLbnkHfKN8klyVFQWQfsB/9uolZQ/p0Xkqam3vDK5hb54aRqG jC9vLg1JC9; Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hannes, There are network situations where the only VSPs involved are the Home VSP and the PSAP. Local VSP may be incompatible. So, the case you cite must be covered. Mike > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, January 31, 2008 3:29 AM > To: speermint@ietf.org; ECRIT > Subject: [Speermint] Emergency Calls & VoIP Peering >=20 > Hi all, >=20 > I wanted to ask you for your opinion since the following=20 > issue has been brought forward to me many times already. >=20 > One deployment mode for the emergency services architecture=20 > is to route calls through the user's VoIP provider (VSP) and=20 > then towards the PSAP.=20 > Since the VSP is typically not in the visited network there=20 > is obviously the problem that the emergency SIP call (not the=20 > RTP, which would travel directly -- hopefully) needs to be=20 > handled properly when it leaves the VSP, potentially=20 > traverses some other peering networks, and then finally hits the PSAP. >=20 > Some folks, particularly those with an IMS background, argue=20 > that "everything" should be done locally at the visited=20 > network rather than routing the call through the user's VSP=20 > where things could potentially go wrong along the path=20 > between the PSAP and the VSP. >=20 > Thoughts about this aspect? >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 31 17:07:00 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D13E28C206; Thu, 31 Jan 2008 17:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS2s4CuyKb3O; Thu, 31 Jan 2008 17:06:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C82A128C20A; Thu, 31 Jan 2008 17:05:44 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 627E328C208; Thu, 31 Jan 2008 17:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DgNP59UBluv; Thu, 31 Jan 2008 17:05:42 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 9CB8528C213; Thu, 31 Jan 2008 17:04:45 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JKg1C-0000Ji-Ow; Thu, 31 Jan 2008 14:28:19 -0600 From: "Brian Rosen" To: "'Paul Kyzivat'" References: <47A186C1.7080004@gmx.net> <005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <47A21B7B.2060903@cisco.com> Date: Thu, 31 Jan 2008 15:28:24 -0500 Message-ID: <00c801c86447$d613da20$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47A21B7B.2060903@cisco.com> Thread-Index: AchkO/4oTX33jnGsSqW0LskPiFL4FwACqEfw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: "'Dawson, Martin'" , 'ECRIT' , speermint@ietf.org Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Not really true. In your last example, suppose 9-1-1 was directory assistance in the U.K. (it's not). If a call with sip:911@acme.co.uk is placed from a U.S. location, then usually it's an emergency call. The local (visited) dial string MUST be honored. The home dial string MAY be honored. It is indeed problematic for the UK proxy to do dial plan interpretation because it doesn't have location unless the phone already knows it's an emergency call, but never-the-less, 9-1-1 when dialed in the U.S. is always an emergency call, regardless of the domain. As a practical matter, some enterprise dial plans change this. You sometimes have to dial 9-9-1-1, and that's an emergency call. I don't think Martin's ASP proxy could handle that. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, January 31, 2008 2:03 PM > To: Brian Rosen > Cc: 'Dawson, Martin'; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' > Subject: Re: [Speermint] RE: [Ecrit] Emergency Calls & VoIP Peering > > > > Brian Rosen wrote: > > First my response to the original question: > > > > IMS is special because the visited network is in the call path. When > the > > visited network has active elements in the call path, it makes sense to > have > > the visited network handle emergency calls. > > I think that is acceptable *if* the access network has a well defined, > unambiguous way to discern whether a call is an emergency call or not. > > If the R-URI is then there is no problem at all. If the > R-URI is then again there is no problem. But > if the R-URI is then it is very problematic if a > visited network in the US decides this is an emergency call because of > the "911". OTOH the owner of the domain *can* decide this is an > emergency call based on its understanding of its numbering plan. > > Paul > > > Note that there are lots and > > lots of complications with this. Take for example, call back. What you > > want is to have both a Contact URI that will route back to the device > that > > placed the call, and you need a real AoR you can use to reach the caller > > later on. The visited network would have to provide both. > > > > When the visited network is not in the call path, you have to use the > VSP. > > > > > > Then my response to Martin: > >> It's been said that the emergency service wants the subscriber details > >> from the VSP. A caller can have subscriptions to lots of Internet > >> services that also don't need to be involved in the call. Should we > also > >> make emergency calling dependent on them? > > No. However, involving the actual carrier that provides the service > that is > > placing the call is essential. Bypassing the carrier that provides the > > service that places the call is pretty tough, except in unusual > > circumstances. IMS is an example of an unusual circumstance because > they > > put the visited network in the call path. Very few other systems do > that. > > > > I'm very conscious of what we must ask the access network to provide. > This > > has lots of implications on engineering as well as cost and liability. > > Unless the device itself can locate itself without assistance of the > access > > network, we ask the access network to provide location (or at least > location > > assistance). We ask them to provide access to a LoST server. I want to > > stop there. That's all they have to do. > > > >> I don't think it has to be the same as IMS. IMS requires a co-operative > >> E-CSCF that is actually part of the access network. With LoST and a > >> suitable emergency proxy, there doesn't have to be any dependency on > the > >> access network to also provide call processing. > > IMS is different as discussed above. > > > >> Not involving the VSP in the call does not mean that the caller cannot > >> provide callback details (in principle, they could provide multiple > >> callback options). I'd also be interested in a discussion around > >> providing an automatic presence subscription from the emergency network > >> itself - with a temporary callback number. As long as the emergency > >> calling device is attached to the Internet, it should be able to stay > >> registered with that temporary subscription and also do regular > location > >> updates to it. > > I think the notion that we can define the characteristics of an > emergency > > proxy that works for all devices is not feasible. Let me cite a few > > examples: > > > > Emergency call from AOL/MSN/Yahoo. We would have to require the device > to > > implement SIP/SIMPLE. > > > > Emergency call from OnStar. Who is the emergency proxy provider? > > > > Emergency call from "Help I've fallen and I can't get up" buttons with > two > > way audio. They would have to meet all of the phonebcp requirements. > > > > Call backs are an issue. You can get a contact URI, but you can't get > an > > AoR you have any trust in for any call. > > > > But the biggest problem is that I think any attempt to give the access > > network the obligation and the liability to totally handle emergency > calls > > will not fly. > > > > > >> Many of the most convoluted issues that have arisen in this forum have > >> been around the challenges that having the VSP involved in call routing > >> introduces (the need for forest guides etc). Since direct-calling is a > >> valid option, I know I'd prefer an emergency calling client that always > >> worked that way. > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 31 18:35:59 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D610B28C251; Thu, 31 Jan 2008 18:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9aXlhAug8zl; Thu, 31 Jan 2008 18:35:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE49828C1DD; Thu, 31 Jan 2008 18:35:55 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BADE328C1DD; Thu, 31 Jan 2008 18:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP+wSQBisL-7; Thu, 31 Jan 2008 18:35:52 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9AEA528C109; Thu, 31 Jan 2008 18:35:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,287,1199682000"; d="scan'208";a="85182765" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Jan 2008 21:37:26 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m112bPUm028961; Thu, 31 Jan 2008 21:37:25 -0500 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 m112bH7C026538; Fri, 1 Feb 2008 02:37:23 GMT 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.1830); Thu, 31 Jan 2008 21:37:17 -0500 Received: from [10.82.232.145] ([10.82.232.145]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 21:37:17 -0500 Message-ID: <47A285E3.8000003@cisco.com> Date: Thu, 31 Jan 2008 21:37:23 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Brian Rosen References: <47A186C1.7080004@gmx.net> <005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <47A21B7B.2060903@cisco.com> <00c801c86447$d613da20$640fa8c0@cis.neustar.com> In-Reply-To: <00c801c86447$d613da20$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 01 Feb 2008 02:37:17.0347 (UTC) FILETIME=[5C5DDF30:01C8647B] Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "'Dawson, Martin'" , 'ECRIT' , speermint@ietf.org Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Brian Rosen wrote: > Not really true. > > In your last example, suppose 9-1-1 was directory assistance in the U.K. > (it's not). I know its not. That was the point. > If a call with sip:911@acme.co.uk is placed from a U.S. > location, then usually it's an emergency call. > > The local (visited) dial string MUST be honored. The home dial string MAY > be honored. One problem is that the visited proxy doesn't know this is a dial string at all. It is a URL. That URL *might* embed a dialstring, and it might not. Even if it is a dial string, it might be a call to the phone in office 11 on the 9th floor of Acme's office building. Acme is responsible for the phone, not some US provider. Whether it wants to honor emergency numbers in other countries is its business. > It is indeed problematic for the UK proxy to do dial plan interpretation > because it doesn't have location unless the phone already knows it's an > emergency call, but never-the-less, 9-1-1 when dialed in the U.S. is always > an emergency call, regardless of the domain. What you are asserting is not just about *dial strings*. What you are saying is that any arbitrary string of digits that some locale wants to consider an emergency number cannot be the user part of any URI that might every be used from that locale. For instance this means that UAs must be very careful about what they encode in the user part of a contact URI, because that might at some point be the R-URI in a new call. That is absurd. The fundamental rule in sip has always been that you must make any interpretation of the user part of a sip URI unless you are responsible for the domain of that URI. (Or at least are cognizant of the conventions used by that domain for the user part.) Paul > As a practical matter, some enterprise dial plans change this. You > sometimes have to dial 9-9-1-1, and that's an emergency call. I don't think > Martin's ASP proxy could handle that. > > Brian > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, January 31, 2008 2:03 PM >> To: Brian Rosen >> Cc: 'Dawson, Martin'; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' >> Subject: Re: [Speermint] RE: [Ecrit] Emergency Calls & VoIP Peering >> >> >> >> Brian Rosen wrote: >>> First my response to the original question: >>> >>> IMS is special because the visited network is in the call path. When >> the >>> visited network has active elements in the call path, it makes sense to >> have >>> the visited network handle emergency calls. >> I think that is acceptable *if* the access network has a well defined, >> unambiguous way to discern whether a call is an emergency call or not. >> >> If the R-URI is then there is no problem at all. If the >> R-URI is then again there is no problem. But >> if the R-URI is then it is very problematic if a >> visited network in the US decides this is an emergency call because of >> the "911". OTOH the owner of the domain *can* decide this is an >> emergency call based on its understanding of its numbering plan. >> >> Paul >> >>> Note that there are lots and >>> lots of complications with this. Take for example, call back. What you >>> want is to have both a Contact URI that will route back to the device >> that >>> placed the call, and you need a real AoR you can use to reach the caller >>> later on. The visited network would have to provide both. >>> >>> When the visited network is not in the call path, you have to use the >> VSP. >>> >>> Then my response to Martin: >>>> It's been said that the emergency service wants the subscriber details >>>> from the VSP. A caller can have subscriptions to lots of Internet >>>> services that also don't need to be involved in the call. Should we >> also >>>> make emergency calling dependent on them? >>> No. However, involving the actual carrier that provides the service >> that is >>> placing the call is essential. Bypassing the carrier that provides the >>> service that places the call is pretty tough, except in unusual >>> circumstances. IMS is an example of an unusual circumstance because >> they >>> put the visited network in the call path. Very few other systems do >> that. >>> I'm very conscious of what we must ask the access network to provide. >> This >>> has lots of implications on engineering as well as cost and liability. >>> Unless the device itself can locate itself without assistance of the >> access >>> network, we ask the access network to provide location (or at least >> location >>> assistance). We ask them to provide access to a LoST server. I want to >>> stop there. That's all they have to do. >>> >>>> I don't think it has to be the same as IMS. IMS requires a co-operative >>>> E-CSCF that is actually part of the access network. With LoST and a >>>> suitable emergency proxy, there doesn't have to be any dependency on >> the >>>> access network to also provide call processing. >>> IMS is different as discussed above. >>> >>>> Not involving the VSP in the call does not mean that the caller cannot >>>> provide callback details (in principle, they could provide multiple >>>> callback options). I'd also be interested in a discussion around >>>> providing an automatic presence subscription from the emergency network >>>> itself - with a temporary callback number. As long as the emergency >>>> calling device is attached to the Internet, it should be able to stay >>>> registered with that temporary subscription and also do regular >> location >>>> updates to it. >>> I think the notion that we can define the characteristics of an >> emergency >>> proxy that works for all devices is not feasible. Let me cite a few >>> examples: >>> >>> Emergency call from AOL/MSN/Yahoo. We would have to require the device >> to >>> implement SIP/SIMPLE. >>> >>> Emergency call from OnStar. Who is the emergency proxy provider? >>> >>> Emergency call from "Help I've fallen and I can't get up" buttons with >> two >>> way audio. They would have to meet all of the phonebcp requirements. >>> >>> Call backs are an issue. You can get a contact URI, but you can't get >> an >>> AoR you have any trust in for any call. >>> >>> But the biggest problem is that I think any attempt to give the access >>> network the obligation and the liability to totally handle emergency >> calls >>> will not fly. >>> >>> >>>> Many of the most convoluted issues that have arisen in this forum have >>>> been around the challenges that having the VSP involved in call routing >>>> introduces (the need for forest guides etc). Since direct-calling is a >>>> valid option, I know I'd prefer an emergency calling client that always >>>> worked that way. >>> >>> >>> _______________________________________________ >>> Speermint mailing list >>> Speermint@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speermint >>> > > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint