From speermint-bounces@ietf.org Sat Jul 01 23:58:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwt6k-0007H6-Qa; Sat, 01 Jul 2006 23:58:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwt6j-0007H1-Hm for speermint@ietf.org; Sat, 01 Jul 2006 23:58:53 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fwt6i-0004xN-8O for speermint@ietf.org; Sat, 01 Jul 2006 23:58:53 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 01 Jul 2006 20:58:52 -0700 X-IronPort-AV: i="4.06,198,1149490800"; d="scan'208"; a="1834430414:sNHT32822480" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k623wpIr022608; Sat, 1 Jul 2006 20:58:51 -0700 Received: from [192.168.1.2] (sjc-vpn7-312.cisco.com [10.21.145.56]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k623wpIs003265; Sat, 1 Jul 2006 20:58:51 -0700 (PDT) In-Reply-To: <1151688969.10104.30.camel@montag.eng.level3.com> References: <00ae01c69ae3$70cc78e0$4d201f0a@cis.neustar.com> <732EB664-954E-410E-A7BD-9F53D350F119@hxr.us> <953beacc0606291705j603aa36fwb08b9f0687fb7150@mail.gmail.com> <6A4304EA-845D-4120-B0F4-FDC390334328@hxr.us> <953beacc0606300840h741d071cle64c12045a7de878@mail.gmail.com> <1151688969.10104.30.camel@montag.eng.level3.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <56265364-1A20-4BCA-8DCB-937546B60CFA@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) Date: Sat, 1 Jul 2006 20:58:49 -0700 To: Daryl Malas X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1179; t=1151812731; x=1152676731; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20TLS=20for=20peering=20(was=20RE=3A=20Comments=20(RE=3A[speermint ]requirementsdraft=20submitted)); X=v=3Dcisco.com=3B=20h=3DfVqRNEE8MQ2BOUdFDYiZtzHn+x0=3D; b=qqMkFk+qA9cfnIHFzfgTRXNY/QtNqXt8JkTRTHadnCYKIkDfKlgcLLYxxtiUYCV9tICL2swB t6nsI/71ddMG+CH2MIf5xjjY4V/BEticuxAeZazyRv9uYu424ir1+rPB; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "Khan, Sohel Q \[CTO\]" , 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 Jun 30, 2006, at 10:36 AM, Daryl Malas wrote: > --Should TCP/TLS be a MUST requirement for peering authentication, or > can it be a SHOULD requirement (made up of multiple potential methods) > for peering? > > If this is the right question being argued, what is the problem in > compromising on allowing it to be an acceptable alternative for > securing > a peering relationship? I think this is sort of the wrong question. TLS is a solution to a problem. The questions is, what are the problems. Then we can discuss what possible techniques that might be used to solve the problem. When SP A sends a call to SP B, (and I'm talking at the SIP level here not the IP level), do you have a requirements for B to know the call came from A? possibly for billing related reasons? Let's say SP A peers with both SP B and SP C. When A decides to route a call to B, do you have requirements to guarantee that C can not intercept the request and end up taking the call even though it was meant to go to B? I suspect you will end up with your security threats deriving the need for the two peers to be able to authenticate each other. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Jul 02 04:23:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwxEt-0003ev-KA; Sun, 02 Jul 2006 04:23:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwxEr-0003Uq-OK for speermint@ietf.org; Sun, 02 Jul 2006 04:23:33 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwxEq-0000da-FU for speermint@ietf.org; Sun, 02 Jul 2006 04:23:33 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k628NUE5027785; Sun, 2 Jul 2006 03:23:30 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 2 Jul 2006 09:23:29 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0134D246E@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Cullen Jennings'" , "'speermint@ietf.org'" Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Sun, 2 Jul 2006 09:23:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Oh no they do not - starting with just about every mobile phone you pick up. and therein lies your problem. Use of G.711 over the air interface has sufficient cost to either preclude or prevent its use. regards Keith > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 30 June 2006 17:16 > To: speermint@ietf.org > Subject: Re: [Speermint] I-D > ACTION:draft-ietf-speermint-requirements-00.t xt > > > > On Jun 28, 2006, at 3:46 AM, Livingood, Jason wrote: > > > So in the case of voice, the question at hand is - is there a lowest > > common denominator voice codec which should be required to > do peering? > > Don't know what you should do but ... pretty much every voice device > does G.711 so the "cost" of mandating at least that is pretty low. > > _______________________________________________ > 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 Sun Jul 02 11:55:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx4IU-0007eo-WE; Sun, 02 Jul 2006 11:55:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx4IT-0007ej-Rz for speermint@ietf.org; Sun, 02 Jul 2006 11:55:45 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx4IS-000629-IJ for speermint@ietf.org; Sun, 02 Jul 2006 11:55:45 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 02 Jul 2006 08:55:44 -0700 X-IronPort-AV: i="4.06,199,1149490800"; d="scan'208"; a="1834513148:sNHT30380632" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k62FthKp001348; Sun, 2 Jul 2006 08:55:43 -0700 Received: from [192.168.1.2] (sjc-vpn6-311.cisco.com [10.21.121.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k62FthcL006491; Sun, 2 Jul 2006 08:55:43 -0700 (PDT) In-Reply-To: <475FF955A05DD411980D00508B6D5FB0134D246E@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0134D246E@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Sun, 2 Jul 2006 08:55:41 -0700 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1224; t=1151855743; x=1152719743; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Speermint]=20I-D=20ACTION=3Adraft-ietf-speermint-requirements-0 0.t=20xt; X=v=3Dcisco.com=3B=20h=3DSJbnIMQh2jAOLYgUowSzWKqpWRw=3D; b=VvZ6A0kurC7HHskXIrB17HEhZGuVWlhS9z9Fj6TY9LUqTsvKxg92nPAeACvss1WTn465VZ1k RaavJCF7iQOlOEClvCpTf7Q5Lk5VwWcDgGKg2It1dMNMuTHnEx5jgSdo; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 About 1 second after I hit the send button on my original message, I realized what a stupid thing I was saying. Completely agree with Keith. On Jul 2, 2006, at 1:23 AM, Drage, Keith (Keith) wrote: > Oh no they do not - starting with just about every mobile phone you > pick up. > > and therein lies your problem. Use of G.711 over the air interface > has sufficient cost to either preclude or prevent its use. > > regards > > Keith > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: 30 June 2006 17:16 >> To: speermint@ietf.org >> Subject: Re: [Speermint] I-D >> ACTION:draft-ietf-speermint-requirements-00.t xt >> >> >> >> On Jun 28, 2006, at 3:46 AM, Livingood, Jason wrote: >> >>> So in the case of voice, the question at hand is - is there a lowest >>> common denominator voice codec which should be required to >> do peering? >> >> Don't know what you should do but ... pretty much every voice device >> does G.711 so the "cost" of mandating at least that is pretty low. >> >> _______________________________________________ >> 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 Jul 04 09:46:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxlEW-0003il-JR; Tue, 04 Jul 2006 09:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxlEU-0003if-TL for speermint@ietf.org; Tue, 04 Jul 2006 09:46:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxlEU-0004Di-C3 for speermint@ietf.org; Tue, 04 Jul 2006 09:46:30 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 04 Jul 2006 09:46:30 -0400 X-IronPort-AV: i="4.06,204,1149480000"; d="scan'208"; a="91618706:sNHT36037888" 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 k64DkTno013672; Tue, 4 Jul 2006 09:46:29 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jul 2006 09:46:29 -0400 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: TLS for peering (was RE:Comments(RE:[speermint]requirementsdraftsubmitted)) Date: Tue, 4 Jul 2006 09:46:29 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301A5ACE0@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE:Comments(RE:[speermint]requirementsdraftsubmitted)) Thread-Index: Acab3FUhf9K5J3CpRG6tu8cqs2JyFAAAe4hAAAEKwwAAHFNmkA== From: "Michael Hammer \(mhammer\)" To: "Reinaldo Penno" , , "Benjamin Black" , "Rohan Mahy" X-OriginalArrivalTime: 04 Jul 2006 13:46:29.0490 (UTC) FILETIME=[408EED20:01C69F70] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: "Khan, Sohel Q \[CTO\]" , 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 TLS must be supported. No question. The question is when and where it is used. There are times when IPSEC might provide a better solution. I don't want to argue the details as that is a network design issue that can be very situation specific. This is an academic argument in many ways. Mike > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 > Sent: Thursday, June 29, 2006 9:14 PM > To: richard@shockey.us; Benjamin Black; Rohan Mahy > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Uzelac, Adam > Subject: RE: TLS for peering (was=20 > RE:Comments(RE:[speermint]requirementsdraftsubmitted)) >=20 > IMO TLS must be supported but we should spell out the alternatives. >=20 > > -----Original Message----- > > From: Richard Shockey [mailto:richard@shockey.us] > > Sent: Thursday, June 29, 2006 6:02 PM > > To: 'Benjamin Black'; 'Rohan Mahy' > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org; 'Uzelac, Adam' > > Subject: RE: TLS for peering (was RE: > > Comments(RE:[speermint]requirementsdraftsubmitted)) > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Benjamin Black [mailto:ben@layer8.net] > > > Sent: Thursday, June 29, 2006 8:30 PM > > > To: Rohan Mahy > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Uzelac, Adam > > > Subject: Re: TLS for peering (was RE: > > > Comments(RE:[speermint]requirementsdraft submitted)) > > > > > > rohan, > > > > > > i don't think it is sufficient to simply make tls a requirement. > > > what is the problem you are trying to solve using tls? > >=20 > > Face the music you will support TLS whether you like it or=20 > not. This > is > > SIP > > 101. It will not be a requirement that you use it but I can tell you > I'd > > never give my voice traffic to any service provider that did not > accept a > > TLS connection at their point of interconnection. > >=20 > > Hello here... SIP signaling security, preventing MIM attacks, trust=20 > > relationships between domain bountries do you want a longer list of > why > > you > > need SIP security? > >=20 > > This whole thread is highlighting the central problem this=20 > list seems > to > > have has which is unwillingness to confront the central issues of > security > > and trust relationships between service providers and what protocols > are > > REQUIRED to create those trust relationships. > >=20 > > OK if you are a GSM network you figured this out already ..create a=20 > > totally private internet with completely private points of=20 > > interconnection and within a the great wall of GSM you have=20 > security. > >=20 > > It works ..is that the model you want? > >=20 > > Brother Rohan is spot on here. CPU cycles are cheep considering what > the > > requirements for security here are. > >=20 > > I just don't get it why does everyone so dislikes TLS..its simple > proven > > to > > scale and it works. > >=20 > > Frankly I think the chairs need to step in here and drive a little=20 > > consensus that without a robust security/trust model=20 > defined ASAP for=20 > > speermint > all > > other discussions are futile and a waste of time. > >=20 > >=20 > >=20 > >=20 > > given that, > > > what are the specific features/options of tls that=20 > minimally solve=20 > > > that problem? for example, eNULL encryption may not be=20 > appropriate,=20 > > > but is available if the entirety of the specification is "must use > tls". > > > > > > all this talk of what the performance impact of tls may or may not > be > > > presumes specifics of requirements, design, and=20 > implementation that > i > > > have not seen clearly articulated in this thread. > > > > > > > > > thanks, > > > ben > > > > > > On Jun 29, 2006, at 5:05 PM, Rohan Mahy wrote: > > > > > > > Andy, > > > > > > > > What you've described are a bunch of hacks that service=20 > providers > use > > > > because they don't peer over the Internet or because they can't > rely > > > > on the other guy to support TLS. The combination of hacks is > much, > > > > much more expensive in terms of both capital equipment and=20 > > > > operationally than just using TLS. > > > > > > > > A $2000 rack mount server can encrypt and decrypt a phenominal > volume > > > > of TLS traffic. Hardware crypto accellerators are=20 > available that=20 > > > > increase this volume and decrease initial TLS handshake=20 > latencies > by > > > > another couple of orders of magnitude. > > > > > > > > I'm willing to bet a few beers that the amount of data that is=20 > > > > encrypted using TLS exceeds the total volume of PSTN signaling > traffic > > > > on a daily basis. > > > > > > > > To those who have a problem with TLS, I ask them to=20 > provide some=20 > > > > quantitative data or real requirements rather than rhetoric and > FUD. > > > > > > > > thanks, > > > > -rohan > > > > > > > > > > > > > > > > > > > > > > > > On 6/28/06, Andrew Newton wrote: > > > >> > > > >> On Jun 28, 2006, at 2:48 PM, Richard Shockey wrote: > > > >> > how do you propose to establish a trust relationship between > SIP > > > >> > domain > > > >> > boundaries without TLS? > > > >> > > > >> There are other methods: security lower in the stack, private=20 > > > >> connections, address ACLs... the things that providers use > today. > > > >> > > > >> > If you cannot establish a trust relationship between > > > >> interconnecting > > > >> > partners then what is the purpose of this whole exercise? > > > >> > > > >> To answer the second part of that sentence: I don't know; I've > been > > > >> asking that question for quite some time. > > > >> > > > >> -andy > >=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 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 04 09:46:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxlEe-0003mH-Pw; Tue, 04 Jul 2006 09:46:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxlEd-0003mC-Li for speermint@ietf.org; Tue, 04 Jul 2006 09:46:39 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxlEc-0004J6-Cd for speermint@ietf.org; Tue, 04 Jul 2006 09:46:39 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 04 Jul 2006 06:46:38 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,204,1149490800"; d="scan'208"; a="31080440:sNHT22786348" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k64DkbYL010080; Tue, 4 Jul 2006 09:46:37 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jul 2006 09:46:37 -0400 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: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Date: Tue, 4 Jul 2006 09:46:37 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301A5ACE2@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Thread-Index: Acab2PAcmrPPE3ikQA+JwtuudbF0SgAeOayw From: "Michael Hammer \(mhammer\)" To: "Rohan Mahy" , "Andrew Newton" X-OriginalArrivalTime: 04 Jul 2006 13:46:37.0475 (UTC) FILETIME=[45515730:01C69F70] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "Khan, Sohel Q \[CTO\]" , 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 Rohan, With your $2000 server, can it support 300,000 simultaneous connections held for 3 minutes or more, dropping and adding 300 connections per second? And what is the percentage CPU and core memory used to do that? If the TLS would be handled completely on the I/O card, that would be great. Mike > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 > Sent: Thursday, June 29, 2006 8:05 PM > To: Andrew Newton > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Uzelac, Adam > Subject: Re: TLS for peering (was RE:=20 > Comments(RE:[speermint]requirementsdraft submitted)) >=20 > Andy, >=20 > What you've described are a bunch of hacks that service=20 > providers use because they don't peer over the Internet or=20 > because they can't rely on the other guy to support TLS. The=20 > combination of hacks is much, much more expensive in terms of=20 > both capital equipment and operationally than just using TLS. >=20 > A $2000 rack mount server can encrypt and decrypt a=20 > phenominal volume of TLS traffic. Hardware crypto=20 > accellerators are available that increase this volume and=20 > decrease initial TLS handshake latencies by another couple of=20 > orders of magnitude. >=20 > I'm willing to bet a few beers that the amount of data that=20 > is encrypted using TLS exceeds the total volume of PSTN=20 > signaling traffic on a daily basis. >=20 > To those who have a problem with TLS, I ask them to provide=20 > some quantitative data or real requirements rather than=20 > rhetoric and FUD. >=20 > thanks, > -rohan >=20 >=20 >=20 >=20 >=20 > On 6/28/06, Andrew Newton wrote: > > > > On Jun 28, 2006, at 2:48 PM, Richard Shockey wrote: > > > how do you propose to establish a trust relationship between SIP=20 > > > domain boundaries without TLS? > > > > There are other methods: security lower in the stack, private=20 > > connections, address ACLs... the things that providers use today. > > > > > If you cannot establish a trust relationship between=20 > interconnecting=20 > > > partners then what is the purpose of this whole exercise? > > > > To answer the second part of that sentence: I don't know; I've been=20 > > asking that question for quite some time. > > > > -andy > > > > _______________________________________________ > > 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 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 04 09:47:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxlFg-0003us-If; Tue, 04 Jul 2006 09:47:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxlFf-0003uk-E2 for speermint@ietf.org; Tue, 04 Jul 2006 09:47:43 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxlFd-0004Yu-Vy for speermint@ietf.org; Tue, 04 Jul 2006 09:47:43 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 7F80C1A3B5; Tue, 4 Jul 2006 15:47:39 +0200 (CEST) Date: Tue, 4 Jul 2006 15:47:39 +0200 From: Otmar Lendl To: speermint@ietf.org, yiu_lee@cable.comcast.com Message-ID: <20060704134739.GG19113@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org, yiu_lee@cable.comcast.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Subject: [Speermint] Some comments on draft-lee-speermint-use-case-cable-00 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've just read draft-lee-speermint-use-case-cable-00, and I'd like to offer some comments to the list. First of all, thanks for this informative document. Such clear reports on the current state of affairs are very helpful to focus our discussion. One thing is unclear to me: Your basic call setup contains 1. Perform an ENUM query on the called party in the SIP request URI. 2. If the ENUM server fails to return the response, SM-o forwards the call to PSTN. 3. ENUM server returns a NAPTR record. SM-o parses the regular expression and formulates the sip uri of Bob which is . 4. SM-o finds out that it does not own "mso-t.com". SM-o has local policies to send the request to PP-o. 5. SM-o sends a DNS query to locate PP-os IP address. 6. DNS returns PP-os IP address to SM-o. SM-o sends the SIP INVITE to PP-o. SM-o MAY choose to record-route to stay on the signaling path. 7. PP-o receives the SIP INVITE. It examines the request URI and sends a query to DNS server to get the IP address of Bobs domain "mos-t.com". This seems to indicate that whenever ENUM returns a foreign URI, the call will be sent via SIP to the responsible PP-t. In section 6 you elaborate: In the call flow shown in Figure 2, when PP-o receives the SIP INVITE request from SM-o, PP-o queries DNS to resolve the IP address of the domain "mso-t.com". PP-o MAY choose not to query DNS server to resolve "mso-t.com". By examining the domain part of Bob's sip uri, SM-o knows that "msoB.com" is one of its trusted peer. In many cases, PP-o's configuration will have static configuration pointing to a static IP address associated to PP-t. There is number of reasons to have this setup. Most common reason is security such that PP-o only peers to the pre-configured IP address. In this setup, PP-o MAY skip querying DNS to resolve the domain name of the remote target. That said, it does not stop PP-o to use DNS to resolve the domain name. thus there might be some static configuration regarding the address of PP-t in the originating network and thus information about peering partners. Questions: * Do you expect the ENUM to return only answers to queries if the destination MSO is one of the configured peers of the originting MSO? * Or is there a way in which the PP-o can tell its SM-o that "sorry, we don't peer with that destination domain, you need to fall-back to PSTN"? In 8.3 you write: This MAY not scale well when an operator tries to peer with few hundred peers. This happens for cable operators provide peering service to large numbers of enterprise customers. Peering security is a working item for the working group. So you expect that a MSO will not only peer with other MSOs and other VoIP operators, but also with enterprises? Is that a case of real peering (in the sense of a connection between equals) or is that more a customer/provider relationship (PBX to upstream VoIP-operator)? ----- Your "Furture Works" section hits the nail on the head. Those are exactly the areas where the current ad-hoc schemes fail. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 04 11:50:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxnAG-0000aE-8x; Tue, 04 Jul 2006 11:50:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxnAF-0000ZY-Ec for speermint@ietf.org; Tue, 04 Jul 2006 11:50:15 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxn2n-0005v7-2x for speermint@ietf.org; Tue, 04 Jul 2006 11:42:33 -0400 Received: by py-out-1112.google.com with SMTP id t32so1889131pyc for ; Tue, 04 Jul 2006 08:42:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=P6QhuOcpApS+/AT2zIGGXZKMIzhX7sx1C6erRCBLokGufv4murBfBdSjUqWaGuzcGusgGRhnntD3+SZILSjoNz8BDhWQ6QWGiFzUt9J0yen1zn2tchfyX6oGW4lQJGsRuDDm0n/hrJ8qN46K6rBy60umpnAkAie22jIF8dg8cWk= Received: by 10.35.99.14 with SMTP id b14mr4127747pym; Tue, 04 Jul 2006 08:42:32 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Tue, 4 Jul 2006 08:42:32 -0700 (PDT) Message-ID: <953beacc0607040842v6650a0afuf7cf276e67514ee8@mail.gmail.com> Date: Tue, 4 Jul 2006 08:42:32 -0700 From: "Rohan Mahy" To: "Michael Hammer (mhammer)" Subject: Re: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301A5ACE2@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <072C5B76F7CEAB488172C6F64B30B5E301A5ACE2@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: "Khan, Sohel Q \[CTO\]" , 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 Hi Michael, Don't confuse the number of calls or signaling transactions with the number of TLS connections. You only need as many TLS connections as other carriers you are willing to peer with. Lets say I am willing to peer with a community of 10,000 other carriers. Of these, lets say that in an average hour I might get or make a call with 1000 of them and that 100 of these will see more or less continuous use throughout the day. The connections to these 100 will be up all the time. The other 900 that I happen to peer with one hour will be different from the other 900 that I peer with the next hour. Now looking at Eric's performance data, a cheap server should have no trouble handling the setups for all 900 new connections for the hour in less than one second. That seems like a comfortable margin to me. Hardware accelerators can increase that number 10-fold for less than $5000. Even if the number of carriers I am willing to peer with increases 100-fold to 1 million (one carrier for approximately every 7000 people), I can still talk with all of them over the course of a day very inexpensively. thanks, -rohan On 7/4/06, Michael Hammer (mhammer) wrote: > Rohan, > > With your $2000 server, can it support 300,000 simultaneous connections > held for 3 minutes or more, dropping and adding 300 connections per > second? And what is the percentage CPU and core memory used to do that? > > If the TLS would be handled completely on the I/O card, that would be > great. > > Mike > > > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan.mahy@gmail.com] > > Sent: Thursday, June 29, 2006 8:05 PM > > To: Andrew Newton > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Uzelac, Adam > > Subject: Re: TLS for peering (was RE: > > Comments(RE:[speermint]requirementsdraft submitted)) > > > > Andy, > > > > What you've described are a bunch of hacks that service > > providers use because they don't peer over the Internet or > > because they can't rely on the other guy to support TLS. The > > combination of hacks is much, much more expensive in terms of > > both capital equipment and operationally than just using TLS. > > > > A $2000 rack mount server can encrypt and decrypt a > > phenominal volume of TLS traffic. Hardware crypto > > accellerators are available that increase this volume and > > decrease initial TLS handshake latencies by another couple of > > orders of magnitude. > > > > I'm willing to bet a few beers that the amount of data that > > is encrypted using TLS exceeds the total volume of PSTN > > signaling traffic on a daily basis. > > > > To those who have a problem with TLS, I ask them to provide > > some quantitative data or real requirements rather than > > rhetoric and FUD. > > > > thanks, > > -rohan > > > > > > > > > > > > On 6/28/06, Andrew Newton wrote: > > > > > > On Jun 28, 2006, at 2:48 PM, Richard Shockey wrote: > > > > how do you propose to establish a trust relationship between SIP > > > > domain boundaries without TLS? > > > > > > There are other methods: security lower in the stack, private > > > connections, address ACLs... the things that providers use today. > > > > > > > If you cannot establish a trust relationship between > > interconnecting > > > > partners then what is the purpose of this whole exercise? > > > > > > To answer the second part of that sentence: I don't know; I've been > > > asking that question for quite some time. > > > > > > -andy > > > > > > _______________________________________________ > > > 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 Tue Jul 04 14:02:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxpE3-0005Tr-FZ; Tue, 04 Jul 2006 14:02:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxpE2-0005Tm-SE for speermint@ietf.org; Tue, 04 Jul 2006 14:02:18 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxpE2-0001uZ-HR for speermint@ietf.org; Tue, 04 Jul 2006 14:02:18 -0400 Received: by py-out-1112.google.com with SMTP id t32so1928725pyc for ; Tue, 04 Jul 2006 11:02:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OvSvKYp95jRCB2Pyno8g3/dbI8KoVmqFtALk0bEFC1HVeHD/Sq8LwxkHbEC6KOiKkj2mK4rGWhBLwHnbUprtWKehDkCLM4RYODLx5TZuynDalOWpucL/dDZbo0YB02sTGbIktFXnqCj7sRzBKvQj6taT6cTTOhqdQww/IC9Ol40= Received: by 10.35.60.16 with SMTP id n16mr2419928pyk; Tue, 04 Jul 2006 11:02:18 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Tue, 4 Jul 2006 11:02:18 -0700 (PDT) Message-ID: <953beacc0607041102s2241c143j6a1c2c3acefa3746@mail.gmail.com> Date: Tue, 4 Jul 2006 11:02:18 -0700 From: "Rohan Mahy" To: "Andrew Newton" Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) In-Reply-To: <6A4304EA-845D-4120-B0F4-FDC390334328@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <00ae01c69ae3$70cc78e0$4d201f0a@cis.neustar.com> <732EB664-954E-410E-A7BD-9F53D350F119@hxr.us> <953beacc0606291705j603aa36fwb08b9f0687fb7150@mail.gmail.com> <6A4304EA-845D-4120-B0F4-FDC390334328@hxr.us> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: "Khan, Sohel Q \[CTO\]" , 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 Hi Andy, I'm back from vacation with answers to your questions (inline). On 6/30/06, Andrew Newton wrote: > Rohan, > > I am not a liberty to give specific numbers, but I can assure you > that your assumptions are wrong. We have a lot of very expensive > equipment that would fall over if it did all signaling over TLS or > even just TCP. And we have done the tests and measurements, and a > $2000 rack mount server cannot handle the load. I want to make sure that we are talking about dozens or hundreds of simultaneous connections for peering, and not the load necessary to handle all your user agents registering as described in draft-ietf-sip-outbound. > And since you are asking for "real requirements", I'd like to know > what your "real requirements" are for specifying TLS for signaling. > Specifically, I'd like to know the following: > > 1) Why is it you are advocating security of the signaling but not the > media? What requirement determines that signaling is important to > secure but media is not important to secure? I would love to have secure media, but the issues here are priority and scope. In the PSTN, neither media nor signaling is encrypted. However trusted signaling begins at the Central Office and is exchanged among switches over trunks with generally much better physical security than "last-mile" access links. I can easily tap the phone of almost anyone in my town from a nearby pole or manhole. Its been like this for decades and except for celebrities or individuals specifically targeted for attack, this lack of media security has been a non-issue for the most part in the PSTN. If we take this running network as any indication of priority, signaling protection is more important than media protection. The attacks that are possible against protected signaling and unprotected media (media hijacking, media recording) are a strict subset of those possible against unprotected signaling (identity spoofing, toll-fraud, etc..). The attacks on unprotected signaling involve significant financial motivations, while there is very poor positive financial motivation for attacks on the media alone. Second, the scope of this group is to define a practical peering convention that can be used over the public Internet. The group is not scoped with defining or limiting every aspect of behavior within the two administrative domains that are peering. Just like I feel it is inappropriate to mandate a specific codec, I feel it is unreasonable for this group to mandate that all endpoints that may ever be involved in a peered session need to support media encryption. Third, as demonstrated in the raiarea meeting in Dallas, there still is no consensus around a single secure media transport and keying mechanism. Finally, I assert that TLS for signaling is easy and inexpensive compared to the alternatives, and that the cost is wholly at the point of interconnection between the peers. > 2) Why do you believe TLS offers better authentication than any other > method, especially given that there is no global trust anchor? TLS is the only documented mechanism that provides the UAC or SIP proxy with a way to verify the identity of the next (SIP) hop. Regarding the trust anchor issue, the TLS client and server can use local authorization policy to decide if the root of a particular cert chain is acceptable. This is no different from the authorization policy you need for IPsec. > 3) What requirement makes TLS more secure than a dedicated link? If I have multiple dedicated links to different providers, my SIP proxy can only tell if traffic is coming from "inside" my walled garden or outside. I am completely vulnerable to one provider claiming to be another, unless I manually configure source IP addresses for all my peers. Practical deployment experience has shown this to be a gigantic administrative PITA and to frequently be misconfigured to provide an avenue of attack. TLS can distinguish between provider A and provider B whether you are using a dedicated link or the big-I Internet. Also, I believe that it is the charter of this group to describe a mechanism that works over the Internet. > 4) What requirement makes TLS more secure than IPSec? IPsec is typically implemented as virtual private links with private addressing. This has exactly the same problems of administrative drudgery and the danger of misconfiguration as the dedicated link case. > 5) Given that providers interconnect today without TLS, what > requirement is not met by the current interconnection methods that > TLS will provide? Providers do not have *widespread* interconnection and do the little interconnect they do in a non-interoperable, frequently undocumented, and ad-hoc fashion. The requirement is widespread interoperable peering and is the reason this group exists. > Don't get me wrong. I think all vendors should support TLS, and I > think providers and carriers should be able to have it at their > disposal when doing interconnection, but it is only one of many options. At issue here in speermint is what mechanism is used between two peers that are compliant to the speermint peering convention. If you want to setup a private club to do private peering, you can do that however you'd like. thanks, -rohan _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jul 05 11:16:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy96g-0000lY-Dg; Wed, 05 Jul 2006 11:16:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy96f-0000lT-IS for speermint@ietf.org; Wed, 05 Jul 2006 11:16:01 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy96d-0003Hj-57 for speermint@ietf.org; Wed, 05 Jul 2006 11:16:01 -0400 Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.21965396; Wed, 05 Jul 2006 11:15:28 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 11:15:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Jul 2006 11:15:24 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96D34561@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comments on draft-lee-speermint-use-case-cable-00 Thread-Index: AcafcHm9u5stI/V4QkOhuNb56dxmHgA0U8fQ From: "Lee, Yiu" To: "Otmar Lendl" , X-OriginalArrivalTime: 05 Jul 2006 15:15:28.0043 (UTC) FILETIME=[D8FF37B0:01C6A045] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: Subject: [Speermint] RE: Some comments on draft-lee-speermint-use-case-cable-00 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 Lendl, Thanks very much for taking time to review this draft. Please see inline for my attempt to answer your questions:=20 -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Tuesday, July 04, 2006 9:48 AM To: speermint@ietf.org; Lee, Yiu Subject: Some comments on draft-lee-speermint-use-case-cable-00 I've just read draft-lee-speermint-use-case-cable-00, and I'd like to offer some comments to the list. First of all, thanks for this informative document. Such clear reports on the current state of affairs are very helpful to focus our discussion. One thing is unclear to me: Your basic call setup contains 1. Perform an ENUM query on the called party in the SIP request URI.=20 =20 2. If the ENUM server fails to return the response, SM-o forwards the call to PSTN.=20 =20 3. ENUM server returns a NAPTR record. SM-o parses the regular=20 expression and formulates the sip uri of Bob which is .=20 =20 4. SM-o finds out that it does not own "mso-t.com". SM-o has local=20 policies to send the request to PP-o.=20 =20 5. SM-o sends a DNS query to locate PP-os IP address.=20 =20 6. DNS returns PP-os IP address to SM-o. SM-o sends the SIP INVITE=20 to PP-o. SM-o MAY choose to record-route to stay on the signaling=20 path.=20 =20 7. PP-o receives the SIP INVITE. It examines the request URI and=20 sends a query to DNS server to get the IP address of Bobs domain=20 "mos-t.com".=20 This seems to indicate that whenever ENUM returns a foreign URI, the call will be sent via SIP to the responsible PP-t. [YL] Yes, this is right In section 6 you elaborate: In the call flow shown in Figure 2, when PP-o receives the SIP INVITE request from SM-o, PP-o queries DNS to resolve the IP address of the=20 domain "mso-t.com". PP-o MAY choose not to query DNS server to=20 resolve "mso-t.com". By examining the domain part of Bob's sip uri,=20 SM-o knows that "msoB.com" is one of its trusted peer. In many cases, PP-o's configuration will have static configuration pointing to a=20 static IP address associated to PP-t. There is number of reasons to=20 have this setup. Most common reason is security such that PP-o only=20 peers to the pre-configured IP address. In this setup, PP-o MAY skip=20 querying DNS to resolve the domain name of the remote target. That=20 said, it does not stop PP-o to use DNS to resolve the domain name.=20 thus there might be some static configuration regarding the address of PP-t in the originating network and thus information about peering partners.=20 [YL] In our peering trial with CableLabs, we do not rely on DNS lookup. We always pre-configure the IP address of the target peering device. Questions: * Do you expect the ENUM to return only answers to queries if the destination MSO is one of the configured peers of the originting MSO? * Or is there a way in which the PP-o can tell its SM-o that "sorry, we don't peer with that destination domain, you need to fall-back to PSTN"? [YL] Excellent question. In our trial enum server, it only contains entries for MSO peering points. However, PP-o may not peer with all the MSOs in day one, so we need to have a way to fall back to PSTN. The way we handle it today is to ask the PP-o to send back a "404 Not Found" to SM-o if it doesn't have a pre-configured session to the target domain. When SM-o receives a 404 from PP-o, SM-o will have a local policy to fall-back to PSTN. We are also working on a design to ask PP-o to do a np dip for all unknown call and route the call back to SM-o.=20 In 8.3 you write: This MAY not scale well=20 when an operator tries to peer with few hundred peers. This happens=20 for cable operators provide peering service to large numbers of=20 enterprise customers. Peering security is a working item for the=20 working group.=20 So you expect that a MSO will not only peer with other MSOs and other VoIP operators, but also with enterprises? Is that a case of real peering (in the sense of a connection between equals) or is that more a customer/provider relationship (PBX to upstream VoIP-operator)? [YL] Some MSOs have enterprise voice customers. Currently, they sell TDM trunks to them. In future, I think it makes sense for those MSOs to offer SIP trunk services to the enterprise customers. For those MSOs, they will have two types of peering partners: (1) service provider peering and (2) enterprise customer peering.=20 ----- Your "Furture Works" section hits the nail on the head. Those are exactly the areas where the current ad-hoc schemes fail. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jul 05 21:58:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyJ7w-0005aI-Qn; Wed, 05 Jul 2006 21:58:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyJ7v-0005a0-R8 for speermint@ietf.org; Wed, 05 Jul 2006 21:57:59 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyJ7v-0002Qo-9T for speermint@ietf.org; Wed, 05 Jul 2006 21:57:59 -0400 Received: from [10.0.1.103] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 05 Jul 2006 21:53:11 -0400 id 015880BD.44AC6D07.00006894 In-Reply-To: <953beacc0607041102s2241c143j6a1c2c3acefa3746@mail.gmail.com> References: <00ae01c69ae3$70cc78e0$4d201f0a@cis.neustar.com> <732EB664-954E-410E-A7BD-9F53D350F119@hxr.us> <953beacc0606291705j603aa36fwb08b9f0687fb7150@mail.gmail.com> <6A4304EA-845D-4120-B0F4-FDC390334328@hxr.us> <953beacc0607041102s2241c143j6a1c2c3acefa3746@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DD9B5C3-1C80-45DD-9443-5D2CAFC22AC8@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) Date: Wed, 5 Jul 2006 21:52:51 -0400 To: Rohan Mahy X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: "Khan, Sohel Q \[CTO\]" , 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 Jul 4, 2006, at 2:02 PM, Rohan Mahy wrote: > I want to make sure that we are talking about dozens or hundreds of > simultaneous connections for peering, and not the load necessary to > handle all your user agents registering as described in > draft-ietf-sip-outbound. I'm aware of the difference. It still won't work. >> 1) Why is it you are advocating security of the signaling but not the >> media? What requirement determines that signaling is important to >> secure but media is not important to secure? > > I would love to have secure media, but the issues here are priority > and scope. > > In the PSTN, neither media nor signaling is encrypted. However > trusted signaling begins at the Central Office and is exchanged among > switches over trunks with generally much better physical security than > "last-mile" access links. I can easily tap the phone of almost anyone > in my town from a nearby pole or manhole. Its been like this for > decades and except for celebrities or individuals specifically > targeted for attack, this lack of media security has been a non-issue > for the most part in the PSTN. If we take this running network as any > indication of priority, signaling protection is more important than > media protection. > > The attacks that are possible against protected signaling and > unprotected media (media hijacking, media recording) are a strict > subset of those possible against unprotected signaling (identity > spoofing, toll-fraud, etc..). The attacks on unprotected signaling > involve significant financial motivations, while there is very poor > positive financial motivation for attacks on the media alone. Let me summarize the point you just made: "It isn't secure on the PSTN, therefore we needn't do it either." That's hardly a requirement developed against the analysis of a threat. I believe that most people would want both the signaling and media secured (if they knew the difference between the two), but if they had to have one they would opt for secure media. And if you are worried about toll fraud, the "last mile" access link should be a significant worry. There is no point in burdening the peering points with over-the-top security when the system can be easily gamed at the end points. > Second, the scope of this group is to define a practical peering > convention that can be used over the public Internet. The group is > not scoped with defining or limiting every aspect of behavior within > the two administrative domains that are peering. Just like I feel it > is inappropriate to mandate a specific codec, I feel it is > unreasonable for this group to mandate that all endpoints that may > ever be involved in a peered session need to support media encryption. I guess this a matter of perspectives. You see secure media as "limiting" and specifying codecs as "limiting" (something that most voip peering exchanges do), but you don't consider mandating TLS as limiting, though A LOT of equipment out there doesn't support it. > Third, as demonstrated in the raiarea meeting in Dallas, there still > is no consensus around a single secure media transport and keying > mechanism. But like a lot of things about setting a voip interconnection, such as settlements, there are ways to do it. > Finally, I assert that TLS for signaling is easy and inexpensive > compared to the alternatives, and that the cost is wholly at the point > of interconnection between the peers. Where is the citation for this? Also, I'd like to understand how you have done the cost benefit analysis for all cases? If there are two ITSPs with POPs in the same co-lo facility, running an ethernet cable is certainly easier and less expensive than upgrading equipment to support TLS. >> 2) Why do you believe TLS offers better authentication than any other >> method, especially given that there is no global trust anchor? > > TLS is the only documented mechanism that provides the UAC or SIP > proxy with a way to verify the identity of the next (SIP) hop. Aren't you describing a property that is more an artifact of a chain of trust and not specifically TLS? > Regarding the trust anchor issue, the TLS client and server can use > local authorization policy to decide if the root of a particular cert > chain is acceptable. This is no different from the authorization > policy you need for IPsec. So it is no better? >> 3) What requirement makes TLS more secure than a dedicated link? > > If I have multiple dedicated links to different providers, my SIP > proxy can only tell if traffic is coming from "inside" my walled > garden or outside. I am completely vulnerable to one provider claiming > to be another, unless I manually configure source IP addresses for all > my peers. Practical deployment experience has shown this to be a > gigantic administrative PITA and to frequently be misconfigured to > provide an avenue of attack. > > TLS can distinguish between provider A and provider B whether you are > using a dedicated link or the big-I Internet. Also, I believe that it > is the charter of this group to describe a mechanism that works over > the Internet. I disagree. Not all networks are setup in the manner you just described. >> 4) What requirement makes TLS more secure than IPSec? > > IPsec is typically implemented as virtual private links with private > addressing. This has exactly the same problems of administrative > drudgery and the danger of misconfiguration as the dedicated link > case. Again, you seem to be assuming a network topology where there is a single proxy. Additionally, it isn't that hard to administer. >> 5) Given that providers interconnect today without TLS, what >> requirement is not met by the current interconnection methods that >> TLS will provide? > > Providers do not have *widespread* interconnection and do the little > interconnect they do in a non-interoperable, frequently undocumented, > and ad-hoc fashion. The requirement is widespread interoperable > peering and is the reason this group exists. We just added one today. The process is not as ad-hoc as you might think, once the contract is signed. >> Don't get me wrong. I think all vendors should support TLS, and I >> think providers and carriers should be able to have it at their >> disposal when doing interconnection, but it is only one of many >> options. > > At issue here in speermint is what mechanism is used between two peers > that are compliant to the speermint peering convention. If you want > to setup a private club to do private peering, you can do that however > you'd like. So this is "public" peering where we are worried about toll fraud (as you described above)? Exactly what problem do you think you are solving? TLS will not solve the problem that settlement terms must be agreed upon and a contract must be signed before an interconnection can be made. If you are talking about public peering as we see with SMTP and Internet email, then what problem is TLS solving? And why hasn't TLS solved the problems with see with Internet email, where most MTA implementations do support TLS? In another message in this thread, you mentioned that the use of TLS is to be persistent connections with peers. For public peering, especially in the style of Internet email, just how many persistent connections are we talking about? What is your definition of public peering and what properties does it have and not have that differentiate it from the private peering you feel is out of scope of this working group? -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 06 13:05:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXIa-00021Y-HW; Thu, 06 Jul 2006 13:05:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXIZ-00021T-AK for speermint@ietf.org; Thu, 06 Jul 2006 13:05:55 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyXIY-0005Rg-RJ for speermint@ietf.org; Thu, 06 Jul 2006 13:05:55 -0400 Received: by py-out-1112.google.com with SMTP id s49so237676pyc for ; Thu, 06 Jul 2006 10:05:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Vu6DusmG1n5BmJAc+0Gd3rkfxGbuS3h7JGM5l2Xhe2K9XCit953mmjc5XRcLWAJXp8gisb2yOBKgLK6fmTKMNWnic4o2LA/7haRGMgxSblLx3wE1bs/MGeVcK4c9YKLBa3zHxc7iZYYf10hIUfgmWaoAtFVIgZcGuc8eYnPY8+o= Received: by 10.35.134.12 with SMTP id l12mr1121523pyn; Thu, 06 Jul 2006 10:05:52 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Thu, 6 Jul 2006 10:05:52 -0700 (PDT) Message-ID: <953beacc0607061005s32fdc490x786c2b0153a80a8e@mail.gmail.com> Date: Thu, 6 Jul 2006 10:05:52 -0700 From: "Rohan Mahy" To: "Andrew Newton" Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) In-Reply-To: <8DD9B5C3-1C80-45DD-9443-5D2CAFC22AC8@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <00ae01c69ae3$70cc78e0$4d201f0a@cis.neustar.com> <732EB664-954E-410E-A7BD-9F53D350F119@hxr.us> <953beacc0606291705j603aa36fwb08b9f0687fb7150@mail.gmail.com> <6A4304EA-845D-4120-B0F4-FDC390334328@hxr.us> <953beacc0607041102s2241c143j6a1c2c3acefa3746@mail.gmail.com> <8DD9B5C3-1C80-45DD-9443-5D2CAFC22AC8@hxr.us> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: "Khan, Sohel Q \[CTO\]" , 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 7/5/06, Andrew Newton wrote: > > On Jul 4, 2006, at 2:02 PM, Rohan Mahy wrote: > > I want to make sure that we are talking about dozens or hundreds of > > simultaneous connections for peering, and not the load necessary to > > handle all your user agents registering as described in > > draft-ietf-sip-outbound. > > I'm aware of the difference. It still won't work. That's quite an assertion for me to just believe without any data. What would you consider to be a valid test to demonstrate that it works or doesn't work? > >> 1) Why is it you are advocating security of the signaling but not the > >> media? What requirement determines that signaling is important to > >> secure but media is not important to secure? > > > > I would love to have secure media, but the issues here are priority > > and scope. > > > > In the PSTN, neither media nor signaling is encrypted. However > > trusted signaling begins at the Central Office and is exchanged among > > switches over trunks with generally much better physical security than > > "last-mile" access links. I can easily tap the phone of almost anyone > > in my town from a nearby pole or manhole. Its been like this for > > decades and except for celebrities or individuals specifically > > targeted for attack, this lack of media security has been a non-issue > > for the most part in the PSTN. If we take this running network as any > > indication of priority, signaling protection is more important than > > media protection. > > > > The attacks that are possible against protected signaling and > > unprotected media (media hijacking, media recording) are a strict > > subset of those possible against unprotected signaling (identity > > spoofing, toll-fraud, etc..). The attacks on unprotected signaling > > involve significant financial motivations, while there is very poor > > positive financial motivation for attacks on the media alone. > > Let me summarize the point you just made: "It isn't secure on the > PSTN, therefore we needn't do it either." That's hardly a > requirement developed against the analysis of a threat. That's hardly an accurate summary of my previous two sentences. Reread my last sentence: >> The attacks on unprotected signaling >> involve significant financial motivations, while there is very poor >> positive financial motivation for attacks on the media alone The fact that the PSTN does not secure media is merely a reaction to that reality. > I believe that most people would want both the signaling and media > secured (if they knew the difference between the two), but if they > had to have one they would opt for secure media. I disagree, but its really irrelevant since secure media depends on the existence of secure signaling. > And if you are worried about toll fraud, the "last mile" access link > should be a significant worry. There is no point in burdening the > peering points with over-the-top security when the system can be > easily gamed at the end points. the "last mile" is completely out of scope of speermint. Each provider can decide how they are going to offer services and secure that service. We can't do anything about that here. > > Second, the scope of this group is to define a practical peering > > convention that can be used over the public Internet. The group is > > not scoped with defining or limiting every aspect of behavior within > > the two administrative domains that are peering. Just like I feel it > > is inappropriate to mandate a specific codec, I feel it is > > unreasonable for this group to mandate that all endpoints that may > > ever be involved in a peered session need to support media encryption. > > I guess this a matter of perspectives. You see secure media as > "limiting" and specifying codecs as "limiting" (something that most > voip peering exchanges do), but you don't consider mandating TLS as > limiting, though A LOT of equipment out there doesn't support it. A LOT of equipment out there DOES support TLS (more than half the implementations at SIPit). Since this equipment only needs to be added at the point of interconnection, it does not require the carrier to re-architect their entire network as changing codecs or adding secure media might. > > Third, as demonstrated in the raiarea meeting in Dallas, there still > > is no consensus around a single secure media transport and keying > > mechanism. > > But like a lot of things about setting a voip interconnection, such > as settlements, there are ways to do it. Andy, I am disturbed by your comment. You are a WG chair. You know the necessity of consensus. "A way" to do it is not sufficient. Are you interested in making a positive contribution to speermint to meet its chartered goals and milestones within the scope established by the charter? > > Finally, I assert that TLS for signaling is easy and inexpensive > > compared to the alternatives, and that the cost is wholly at the point > > of interconnection between the peers. > > Where is the citation for this? Also, I'd like to understand how you > have done the cost benefit analysis for all cases? If there are two > ITSPs with POPs in the same co-lo facility, running an ethernet cable > is certainly easier and less expensive than upgrading equipment to > support TLS. What if the ITSPs are NOT in the same co-lo? We are looking for a general solution here. I believe supporting and running TLS will be cheaper than using IPsec VPNs (including administrative overhead) and cheaper in most cases than sending calls over the PSTN. If you come to a private agreement to exchange traffic over an ethernet cable, I'm not going to stop you, but you probably don't need speermint to do that. > >> 2) Why do you believe TLS offers better authentication than any other > >> method, especially given that there is no global trust anchor? > > > > TLS is the only documented mechanism that provides the UAC or SIP > > proxy with a way to verify the identity of the next (SIP) hop. > > Aren't you describing a property that is more an artifact of a chain > of trust and not specifically TLS? No. > > Regarding the trust anchor issue, the TLS client and server can use > > local authorization policy to decide if the root of a particular cert > > chain is acceptable. This is no different from the authorization > > policy you need for IPsec. > > So it is no better? No, for TLS the policy is configured with the application where it is useful, only in one place. When you use IPsec you need to configure your authorization policy in your VPN boxes AND a bunch of IP addresses in several places. > >> 3) What requirement makes TLS more secure than a dedicated link? > > > > If I have multiple dedicated links to different providers, my SIP > > proxy can only tell if traffic is coming from "inside" my walled > > garden or outside. I am completely vulnerable to one provider claiming > > to be another, unless I manually configure source IP addresses for all > > my peers. Practical deployment experience has shown this to be a > > gigantic administrative PITA and to frequently be misconfigured to > > provide an avenue of attack. > > > > TLS can distinguish between provider A and provider B whether you are > > using a dedicated link or the big-I Internet. Also, I believe that it > > is the charter of this group to describe a mechanism that works over > > the Internet. > > I disagree. Not all networks are setup in the manner you just > described. Please elaborate. > >> 4) What requirement makes TLS more secure than IPSec? > > > > IPsec is typically implemented as virtual private links with private > > addressing. This has exactly the same problems of administrative > > drudgery and the danger of misconfiguration as the dedicated link > > case. > > Again, you seem to be assuming a network topology where there is a > single proxy. Additionally, it isn't that hard to administer. Your problem with TLS performance seems to be with the total number of connections, although you are objecting with pretty vacuous comments. I am willing to bet that 1000 TLS connections is easier to configure that either 1000 proxies or 1000 source address filters plus the requisite IPsec SAs. > >> 5) Given that providers interconnect today without TLS, what > >> requirement is not met by the current interconnection methods that > >> TLS will provide? > > > > Providers do not have *widespread* interconnection and do the little > > interconnect they do in a non-interoperable, frequently undocumented, > > and ad-hoc fashion. The requirement is widespread interoperable > > peering and is the reason this group exists. > > We just added one today. The process is not as ad-hoc as you might > think, once the contract is signed. Congratulations. How long would it take you personally to setup 1000 of them? > >> Don't get me wrong. I think all vendors should support TLS, and I > >> think providers and carriers should be able to have it at their > >> disposal when doing interconnection, but it is only one of many > >> options. > > > > At issue here in speermint is what mechanism is used between two peers > > that are compliant to the speermint peering convention. If you want > > to setup a private club to do private peering, you can do that however > > you'd like. > > So this is "public" peering where we are worried about toll fraud (as > you described above)? Exactly what problem do you think you are > solving? TLS will not solve the problem that settlement terms must > be agreed upon and a contract must be signed before an > interconnection can be made. Several others on this thread have mentioned belonging to one or more clubs, federations, or clearing houses where you sign an agreement only with the "hubs". > If you are talking about public peering > as we see with SMTP and Internet email, then what problem is TLS > solving? TLS offers next and previous hop authentication with which you can make an authorization decision. This property is useful whether you are doing settlement-based peering, no-cost peering by prior arrangement, peering through members of a closed community or club, or fully open public peering. > And why hasn't TLS solved the problems with see with > Internet email, where most MTA implementations do support TLS? Because there is no strong binding to sender identity and because hop-by-hop authentication is not used universally, it is very difficult to have effective whitelists. The dkim WG is trying to provide one very useful tool to provide this property among consenting MTAs. > In another message in this thread, you mentioned that the use of TLS > is to be persistent connections with peers. For public peering, > especially in the style of Internet email, just how many persistent > connections are we talking about? I gave an example in an earlier thread of 10,000 carrier I am willling to peer with and 1000 simultaneous connections. > What is your definition of public peering and what properties does it > have and not have that differentiate it from the private peering you > feel is out of scope of this working group? To be clear, I feel the authorization decision about whether to peer or not is local policy. This means you can peer using settlement-based peering, no-cost peering by prior arrangement, peering through members of a closed community or club, or fully open public peering. What is not in scope is peering designed specifically for a piece of wire or some other kind of private network. The IETF designs protocols for the Internet. These protocols are often useful on private networks as well, but we design for the Internet first. thanks, -rohan _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 06 14:43:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyYon-0000L2-MF; Thu, 06 Jul 2006 14:43:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyYom-0000Kx-Tj for speermint@ietf.org; Thu, 06 Jul 2006 14:43:16 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyYol-0003dl-KY for speermint@ietf.org; Thu, 06 Jul 2006 14:43:16 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 06 Jul 2006 14:43:31 -0400 id 0158802A.44AD59D4.00002710 Message-ID: <44AD59BB.1080104@hxr.us> Date: Thu, 06 Jul 2006 14:43:07 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) References: <00ae01c69ae3$70cc78e0$4d201f0a@cis.neustar.com> <732EB664-954E-410E-A7BD-9F53D350F119@hxr.us> <953beacc0606291705j603aa36fwb08b9f0687fb7150@mail.gmail.com> <6A4304EA-845D-4120-B0F4-FDC390334328@hxr.us> <953beacc0607041102s2241c143j6a1c2c3acefa3746@mail.gmail.com> <8DD9B5C3-1C80-45DD-9443-5D2CAFC22AC8@hxr.us> <953beacc0607061005s32fdc490x786c2b0153a80a8e@mail.gmail.com> In-Reply-To: <953beacc0607061005s32fdc490x786c2b0153a80a8e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Rohan Mahy wrote: >> > At issue here in speermint is what mechanism is used between two peers >> > that are compliant to the speermint peering convention. If you want >> > to setup a private club to do private peering, you can do that however >> > you'd like. >> >> So this is "public" peering where we are worried about toll fraud (as >> you described above)? Exactly what problem do you think you are >> solving? TLS will not solve the problem that settlement terms must >> be agreed upon and a contract must be signed before an >> interconnection can be made. > > Several others on this thread have mentioned belonging to one or more > clubs, federations, or clearing houses where you sign an agreement > only with the "hubs". So a commercial peering exchange meets your definition of public peering? I'm quite familiar with a number of them. Of the ones for which I am familiar, most define the list of codecs that must be supported, many require peering at layer 2, some utilize tunneling for security, and none use TLS. So from my perspective, you are advocating the opposite of what is happening in the industry. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 06 15:06:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZBe-0000Gx-PG; Thu, 06 Jul 2006 15:06:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZBd-0000Go-JP for speermint@ietf.org; Thu, 06 Jul 2006 15:06:53 -0400 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZBb-00058f-5p for speermint@ietf.org; Thu, 06 Jul 2006 15:06:53 -0400 Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J1Z00LALX3EQ6@firewall.mci.com> for speermint@ietf.org; Thu, 06 Jul 2006 19:06:50 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([127.0.0.1]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0J1Z00KFXX3E3G@pmismtp04.mcilink.com> for speermint@ietf.org; Thu, 06 Jul 2006 19:06:50 +0000 (GMT) Received: from XS107V7775199 ([166.50.70.191]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0J1Z00IM4X3DHY@pmismtp04.mcilink.com> for speermint@ietf.org; Thu, 06 Jul 2006 19:06:50 +0000 (GMT) Date: Thu, 06 Jul 2006 14:06:49 -0500 From: Tim Dwight Subject: RE: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) In-reply-to: <44AD59BB.1080104@hxr.us> To: 'Andrew Newton' , 'Rohan Mahy' Message-id: <003501c6a12f$55f4f6d0$bf4632a6@mcilink.com> Organization: MCI MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Thread-index: AcahLB/A895nk55RQ6yvwKoG4nY2sAAAE1ag X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: timothy.dwight@verizon.com 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 to butt in but can you (or others ) address the issue of federation members signing agreements "with the hub" (but not with each other) vs the hub enabling connectivity between "federation members" and leaving it to them to sign commercial agreements and take whatever related measures are necessary to exchange L5 traffic? In your experience how is this usually handled? I've heard it described both ways. Tim > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, July 06, 2006 1:43 PM > To: Rohan Mahy > Cc: speermint@ietf.org > Subject: Re: TLS for peering (was RE: Comments > (RE:[speermint]requirementsdraft submitted)) > > Rohan Mahy wrote: > >> > At issue here in speermint is what mechanism is used between two > >> > peers that are compliant to the speermint peering > convention. If > >> > you want to setup a private club to do private peering, > you can do > >> > that however you'd like. > >> > >> So this is "public" peering where we are worried about > toll fraud (as > >> you described above)? Exactly what problem do you think you are > >> solving? TLS will not solve the problem that settlement > terms must > >> be agreed upon and a contract must be signed before an > >> interconnection can be made. > > > > Several others on this thread have mentioned belonging to > one or more > > clubs, federations, or clearing houses where you sign an agreement > > only with the "hubs". > > So a commercial peering exchange meets your definition of > public peering? > > I'm quite familiar with a number of them. Of the ones for > which I am familiar, most define the list of codecs that must > be supported, many require peering at layer 2, some utilize > tunneling for security, and none use TLS. So from my > perspective, you are advocating the opposite of what is > happening in the industry. > > -andy > > > _______________________________________________ > 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 Jul 06 15:25:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZTO-00081r-Os; Thu, 06 Jul 2006 15:25:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZTM-00081m-Ld for speermint@ietf.org; Thu, 06 Jul 2006 15:25:12 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZTK-0007gg-Ls for speermint@ietf.org; Thu, 06 Jul 2006 15:25:12 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 06 Jul 2006 15:25:26 -0400 id 01588032.44AD63A7.00002ECF Message-ID: <44AD638E.3020404@hxr.us> Date: Thu, 06 Jul 2006 15:25:02 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: timothy.dwight@verizon.com Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) References: <003501c6a12f$55f4f6d0$bf4632a6@mcilink.com> In-Reply-To: <003501c6a12f$55f4f6d0$bf4632a6@mcilink.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Tim Dwight wrote: > Sorry to butt in but can you (or others ) address the issue of federation > members signing agreements "with the hub" (but not with each other) vs the > hub enabling connectivity between "federation members" and leaving it to > them to sign commercial agreements and take whatever related measures are > necessary to exchange L5 traffic? In your experience how is this usually > handled? I've heard it described both ways. All of the commercial entities for which I am familiar require signing an agreement with the "hub" and not with the other peers. In fact, some of them attempt to obfuscate the identity of the peers from each other. The e.164 DUNDI context is an example of the latter (it isn't commercial, btw). You sign an agreement with one of the peers and you are in the club. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 06 15:38:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZgM-0006MF-AM; Thu, 06 Jul 2006 15:38:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZgL-0006JU-CB for speermint@ietf.org; Thu, 06 Jul 2006 15:38:37 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZgI-0000d1-W5 for speermint@ietf.org; Thu, 06 Jul 2006 15:38:37 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k66Jcrsu025609; Thu, 6 Jul 2006 12:38:53 -0700 From: "Richard Shockey" To: "'Andrew Newton'" , Subject: RE: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted)) Date: Thu, 6 Jul 2006 15:38:41 -0400 Message-ID: <004201c6a133$c99ef640$2e201f0a@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.2869 In-Reply-To: <44AD638E.3020404@hxr.us> Thread-Index: AcahMfkFFZB/JB91TXi8XgZawYJwlwAANzYg X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us 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 However the vast majority of agreements both in teleco interconnection and IP data peering are bi-lateral though the may use neutral points to L2 interconnect. Hub and spoke agreement as Andy points out are designed to advantage the hub at the expense of its spokes. > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, July 06, 2006 3:25 PM > To: timothy.dwight@verizon.com > Cc: speermint@ietf.org > Subject: Re: TLS for peering (was RE: Comments > (RE:[speermint]requirementsdraftsubmitted)) > > Tim Dwight wrote: > > Sorry to butt in but can you (or others ) address the issue of > federation > > members signing agreements "with the hub" (but not with each other) vs > the > > hub enabling connectivity between "federation members" and leaving it to > > them to sign commercial agreements and take whatever related measures > are > > necessary to exchange L5 traffic? In your experience how is this > usually > > handled? I've heard it described both ways. > > All of the commercial entities for which I am familiar require signing > an agreement with the "hub" and not with the other peers. In fact, some > of them attempt to obfuscate the identity of the peers from each other. > > The e.164 DUNDI context is an example of the latter (it isn't > commercial, btw). You sign an agreement with one of the peers and you > are in the club. > > -andy > > > _______________________________________________ > 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 Jul 06 15:55:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZwM-00010d-AI; Thu, 06 Jul 2006 15:55:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZwL-00010Y-H4 for speermint@ietf.org; Thu, 06 Jul 2006 15:55:09 -0400 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZwJ-0005sj-4a for speermint@ietf.org; Thu, 06 Jul 2006 15:55:09 -0400 Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J1Z009DOZBUE6@firewall.mci.com> for speermint@ietf.org; Thu, 06 Jul 2006 19:55:07 +0000 (GMT) Received: from pmismtp06.wcomnet.com ([127.0.0.1]) by pmismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0J1Z00BL9ZBU11@pmismtp06.mcilink.com> for speermint@ietf.org; Thu, 06 Jul 2006 19:55:06 +0000 (GMT) Received: from XS107V7775199 ([166.50.70.191]) by pmismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0J1Z00AMYZBS61@pmismtp06.mcilink.com> for speermint@ietf.org; Thu, 06 Jul 2006 19:55:06 +0000 (GMT) Date: Thu, 06 Jul 2006 14:55:04 -0500 From: Tim Dwight Subject: RE: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted)) In-reply-to: <004201c6a133$c99ef640$2e201f0a@cis.neustar.com> To: richard@shockey.us, 'Andrew Newton' Message-id: <004701c6a136$1429fdc0$bf4632a6@mcilink.com> Organization: MCI MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Thread-index: AcahMfkFFZB/JB91TXi8XgZawYJwlwAANzYgAAB293A= X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: timothy.dwight@verizon.com 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 Richard said: > However the vast majority of agreements both in teleco > interconnection and IP data peering are bi-lateral though the > may use neutral points to L2 interconnect. Yes, that's my experience as well. This notion of federations is relatively new, and I wondered whether it followed the same model. Andy's input suggests that it does not. I wonder, though, if you stretch the bounds a bit, whether this would change. In its support of VoIP/MMS/etc., peering, the GSM Association is (from what I understand) similar; do its members only peer / sign agreements with, some "hub" entity representing the GSMA, or do they peer / sign bilateral agreements with, each other? > Hub and spoke agreement as Andy points out are designed to advantage the hub at the expense of its spokes. Whether or not that is the design intent, I agree it would seem to be the effect. Tim > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Thursday, July 06, 2006 3:25 PM > > To: timothy.dwight@verizon.com > > Cc: speermint@ietf.org > > Subject: Re: TLS for peering (was RE: Comments > > (RE:[speermint]requirementsdraftsubmitted)) > > > > Tim Dwight wrote: > > > Sorry to butt in but can you (or others ) address the issue of federation > > > members signing agreements "with the hub" (but not with each other) > > > vs the hub enabling connectivity between "federation members" and leaving > > > it to them to sign commercial agreements and take whatever related > > > measures are necessary to exchange L5 traffic? In your experience how is this > > > usually handled? I've heard it described both ways. > > > > All of the commercial entities for which I am familiar require signing > > an agreement with the "hub" and not with the other peers. In fact, > > some of them attempt to obfuscate the identity of the peers from each other. > > > > The e.164 DUNDI context is an example of the latter (it isn't commercial, btw). > > You sign an agreement with one of the peers and you > > are in the club. > > > > -andy > > > > > > _______________________________________________ > > 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 Jul 06 15:57:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZyu-0001Fx-Tp; Thu, 06 Jul 2006 15:57:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZyu-0001Fs-IQ for speermint@ietf.org; Thu, 06 Jul 2006 15:57:48 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZyt-0007fu-6x for speermint@ietf.org; Thu, 06 Jul 2006 15:57:48 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 06 Jul 2006 15:58:03 -0400 id 01588032.44AD6B4B.000035B4 Message-ID: <44AD6B32.1090208@hxr.us> Date: Thu, 06 Jul 2006 15:57:38 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: richard@shockey.us Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted)) References: <004201c6a133$c99ef640$2e201f0a@cis.neustar.com> In-Reply-To: <004201c6a133$c99ef640$2e201f0a@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Richard Shockey wrote: > > However the vast majority of agreements both in teleco interconnection and > IP data peering are bi-lateral though the may use neutral points to L2 > interconnect. I agree that the majority of interconnections are bi-lateral as you have described. However, most of these are also agreements for voip transit and not peering. For hub and spoke model (federations, exchanges, or whatever you want to call them), the agreements are generally about peering and not transit. Neither are an absolute because there is some mixing and matching going on. > Hub and spoke agreement as Andy points out are designed to advantage the hub > at the expense of its spokes. That's an interesting characterization, but please do not attribute it to me. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 06 16:16:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyaGl-00036Y-BZ; Thu, 06 Jul 2006 16:16:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyaGk-00036T-Ip for speermint@ietf.org; Thu, 06 Jul 2006 16:16:14 -0400 Received: from mta8.srv.hcvlny.cv.net ([167.206.4.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyaGi-0007Nj-AV for speermint@ietf.org; Thu, 06 Jul 2006 16:16:14 -0400 Received: from palindrome (ool-43535e2d.dyn.optonline.net [67.83.94.45]) by mta8.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0J2000AIT09NCBU0@mta8.srv.hcvlny.cv.net> for speermint@ietf.org; Thu, 06 Jul 2006 16:15:28 -0400 (EDT) Date: Thu, 06 Jul 2006 16:15:55 -0400 From: Peter Thermos Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) In-reply-to: <953beacc0607061005s32fdc490x786c2b0153a80a8e@mail.gmail.com> To: 'Rohan Mahy' , 'Andrew Newton' Message-id: <001d01c6a138$fca462f0$0601a8c0@palindrome> Organization: Palindrome Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcahHnfweqU9ji5lQP2IKk6FU8GvKwAE2HyA X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org, "'Uzelac, Adam'" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pthermos@palindrometechnologies.com 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 See inline comments, -----Original Message----- From: Rohan Mahy [mailto:rohan.mahy@gmail.com] Sent: Thursday, July 06, 2006 1:06 PM To: Andrew Newton Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Uzelac, Adam Subject: Re: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) > > > > In the PSTN, neither media nor signaling is encrypted. However > > trusted signaling begins at the Central Office and is exchanged > > among switches over trunks with generally much better physical > > security than "last-mile" access links. I can easily tap the phone > > of almost anyone in my town from a nearby pole or manhole. Its been > > like this for decades and except for celebrities or individuals > > specifically targeted for attack, this lack of media security has > > been a non-issue for the most part in the PSTN. If we take this > > running network as any indication of priority, signaling protection > > is more important than media protection. > > > > The attacks that are possible against protected signaling and > > unprotected media (media hijacking, media recording) are a strict > > subset of those possible against unprotected signaling (identity > > spoofing, toll-fraud, etc..). The attacks on unprotected signaling > > involve significant financial motivations, while there is very poor > > positive financial motivation for attacks on the media alone. It depends the environment you are referring to. There are scenarios for which an attacker can eavesdrop in to media streams without having the need to manipulate the signaling by affecting the underlying layers of the protocol stack (e.g. ARP spoofing). > > Let me summarize the point you just made: "It isn't secure on the > PSTN, therefore we needn't do it either." That's hardly a requirement > developed against the analysis of a threat. The fundamental difference in realizing attacks in PSTN and IP is *ACCESSIBILITY*. How many residential connections do we know that can generate Q.931 messages to affect the PSTN? Unless you own a DMS switch and paying 100k/month for PSTN access you won't be able to do much. At the same time how feasible is for an attacker to generate traffic against an SBC or other network elements that support a VoIP infrastructure? > That's hardly an accurate summary of my previous two sentences. > Reread my last sentence: >> The attacks on unprotected signaling >> involve significant financial motivations, while there is very poor >> positive financial motivation for attacks on the media alone Not sure how we define financial motivation. In some cases financial gain is not the objective. >> I believe that most people would want both the signaling and media >> secured (if they knew the difference between the two), but if they had >> to have one they would opt for secure media. >I disagree, but its really irrelevant since secure media depends on the existence of secure signaling. It depends what is the motivation of the attacker. But I'm not sure if the group wants to address media protection from a peering perspective. Signaling protection can be mandated between intermediate hops but media protection should be left up to the end points. The peering nodes should hand off the RTP stream as is. Peter _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 06 16:19:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyaK4-0006Bb-MC; Thu, 06 Jul 2006 16:19:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyaK3-000681-I3 for speermint@ietf.org; Thu, 06 Jul 2006 16:19:39 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyaK2-0007S1-6G for speermint@ietf.org; Thu, 06 Jul 2006 16:19:39 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k66KJv1n001389; Thu, 6 Jul 2006 13:19:57 -0700 From: "Richard Shockey" To: "'Andrew Newton'" Subject: RE: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted)) Date: Thu, 6 Jul 2006 16:19:24 -0400 Message-ID: <008201c6a139$79d4b9f0$2e201f0a@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.2869 In-Reply-To: <44AD6B32.1090208@hxr.us> Thread-Index: AcahNoSBAC04q0aiSTyqS4oIT0hQuQAAjE0A X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us 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 > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, July 06, 2006 3:58 PM > To: richard@shockey.us > Cc: timothy.dwight@verizon.com; speermint@ietf.org > Subject: Re: TLS for peering (was RE: Comments > (RE:[speermint]requirementsdraftsubmitted)) > > Richard Shockey wrote: > > > > However the vast majority of agreements both in teleco interconnection > and > > IP data peering are bi-lateral though the may use neutral points to L2 > > interconnect. > > I agree that the majority of interconnections are bi-lateral as you have > described. However, most of these are also agreements for voip transit > and not peering. For hub and spoke model (federations, exchanges, or > whatever you want to call them), the agreements are generally about > peering and not transit. Neither are an absolute because there is some > mixing and matching going on. > > > Hub and spoke agreement as Andy points out are designed to advantage the > hub > > at the expense of its spokes. > > That's an interesting characterization, but please do not attribute it > to me. > I only meant that in your context where the hub attempts to "obfuscate the identity of the peers from each other." IMHO this is one of the silliest ideas federations can engage in. It provides no real advantage to the peers except that they are kept in the dark like mushrooms. The counter argument that peers must be keep from each other so they wont poach on each others territory is simply not proven by fact. Anyone can find out who is the underlying carrier for a particular TN. That is why every country has SIPD databases. IMHO if VOIP service providers had any smarts they would give their customers SIP URI's and creatively promotes their use. Nothing will create customer "stickieness" more that SIP URI adoption. > -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 06 16:31:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyaVb-0006nd-GS; Thu, 06 Jul 2006 16:31:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyaVa-0006nY-2r for speermint@ietf.org; Thu, 06 Jul 2006 16:31:34 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyaVY-0007ee-Ly for speermint@ietf.org; Thu, 06 Jul 2006 16:31:34 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k66KVUKN002080; Thu, 6 Jul 2006 13:31:30 -0700 Received: from OVE1WNEXCB02.vcorp.ad.vrsn.com ([10.60.13.34]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 13:31:29 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Date: Thu, 6 Jul 2006 15:31:28 -0500 Message-ID: <122A5731B827474C99ED552C6BFE23ED30CFDE@OVE1WNEXCB02.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Thread-Index: AcahMfkFFZB/JB91TXi8XgZawYJwlwAANzYgAAB293AAAVijYA== From: "McCandless, Kevin" To: , , "Andrew Newton" X-OriginalArrivalTime: 06 Jul 2006 20:31:29.0644 (UTC) FILETIME=[2967AAC0:01C6A13B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 Richard said: > However the vast majority of agreements both in teleco=20 > interconnection and IP data peering are bi-lateral though the=20 > may use neutral points to L2 interconnect.=20 Yes, that's my experience as well. This notion of federations is relatively new, and I wondered whether it followed the same model. Andy's input suggests that it does not. =20 I wonder, though, if you stretch the bounds a bit, whether this would change. In its support of VoIP/MMS/etc., peering, the GSM Association is (from what I understand) similar; do its members only peer / sign agreements with, some "hub" entity representing the GSMA, or do they peer / sign bilateral agreements with, each other? What happens is a new member signs an agreement with a hub. The new member now submits IR21 orders to gain signaling access to other members within the hub. The member must also complete GSM association forms such as AA14 and these are sent to the member network that the new member wants to signal with. Such things as financial clearing and rates are agreed upon before any active signaling takes place. > Hub and spoke agreement as Andy points out are designed to advantage the hub at the expense of its spokes. The spokes could not afford to interconnect with everyone that they want to signal with. That is one of the benefits the hub brings to the table. Whether or not that is the design intent, I agree it would seem to be the effect. Tim >=20 > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Thursday, July 06, 2006 3:25 PM > > To: timothy.dwight@verizon.com > > Cc: speermint@ietf.org > > Subject: Re: TLS for peering (was RE: Comments > > (RE:[speermint]requirementsdraftsubmitted)) > >=20 > > Tim Dwight wrote: > > > Sorry to butt in but can you (or others ) address the issue of federation > > > members signing agreements "with the hub" (but not with each other)=20 > > > vs the hub enabling connectivity between "federation members" and leaving=20 > > > it to them to sign commercial agreements and take whatever related > > > measures are necessary to exchange L5 traffic? In your experience how is this > > > usually handled? I've heard it described both ways. > >=20 > > All of the commercial entities for which I am familiar require signing=20 > > an agreement with the "hub" and not with the other peers. In fact,=20 > > some of them attempt to obfuscate the identity of the peers from each other. > >=20 > > The e.164 DUNDI context is an example of the latter (it isn't commercial, btw). > > You sign an agreement with one of the peers and you=20 > > are in the club. > >=20 > > -andy > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=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 Thu Jul 06 16:52:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyapR-0003uu-SL; Thu, 06 Jul 2006 16:52:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyapR-0003up-4o for speermint@ietf.org; Thu, 06 Jul 2006 16:52:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyaOJ-0007We-8l for speermint@ietf.org; Thu, 06 Jul 2006 16:24:03 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyaDU-0003cL-3s for speermint@ietf.org; Thu, 06 Jul 2006 16:12:55 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k66KCtXx032709; Thu, 6 Jul 2006 13:12:56 -0700 From: "Richard Shockey" To: , "'Andrew Newton'" Subject: RE: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted)) Date: Thu, 6 Jul 2006 16:12:24 -0400 Message-ID: <008101c6a138$7f1d1250$2e201f0a@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.2869 In-Reply-To: <004701c6a136$1429fdc0$bf4632a6@mcilink.com> Thread-Index: AcahMfkFFZB/JB91TXi8XgZawYJwlwAANzYgAAB293AAAIe0EA== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: -0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us 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 > -----Original Message----- > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > Sent: Thursday, July 06, 2006 3:55 PM > To: richard@shockey.us; 'Andrew Newton' > Cc: speermint@ietf.org > Subject: RE: TLS for peering (was RE: Comments > (RE:[speermint]requirementsdraftsubmitted)) > > Richard said: > > > However the vast majority of agreements both in teleco > > interconnection and IP data peering are bi-lateral though the > > may use neutral points to L2 interconnect. > > > Yes, that's my experience as well. This notion of federations is > relatively > new, and I wondered whether it followed the same model. Andy's input > suggests that it does not. Every "federation model" that attempts to interject itself into the private arrangements between two capitalistic service providers has generally proven to be a failure or at best a modest little business. The classic federation hubs simple act as aggregators for smaller players that don't have the clout to engage in bi-lateral agreements. That does not mean you don't need trusted neutral 3rd parties in interconnection cases. First you need to L2 connect in places like Equinix or Telehouse, AM-SIX, LINX etc etc. Second you typically choose a settlement partner to sort through your CDR's, lastly you need some one to maintain your trusted routing, number translation data between partners and make sure its corrected for LNP conditions . I could name some companies here.... :-) > > I wonder, though, if you stretch the bounds a bit, whether this would > change. In its support of VoIP/MMS/etc., peering, the GSM Association is > (from what I understand) similar; do its members only peer / sign > agreements with, some "hub" entity representing the GSMA, or do they peer > / > sign bilateral agreements with, each other? They first sign bilateral agreements and from what I remember the 600 GSM-A members have some 28,000 bilateral agreements among themselves though they do use shared interconnection facilities ..the GRX as points like AM-SIX. > > > > Hub and spoke agreement as Andy points out are designed to advantage the > hub at the expense of its spokes. > > > Whether or not that is the design intent, I agree it would seem to be the > effect. OH it's the specific design intent.... much like mushroom feeding. > > > Tim > > > > > > > -----Original Message----- > > > From: Andrew Newton [mailto:andy@hxr.us] > > > Sent: Thursday, July 06, 2006 3:25 PM > > > To: timothy.dwight@verizon.com > > > Cc: speermint@ietf.org > > > Subject: Re: TLS for peering (was RE: Comments > > > (RE:[speermint]requirementsdraftsubmitted)) > > > > > > Tim Dwight wrote: > > > > Sorry to butt in but can you (or others ) address the issue of > federation > > > > members signing agreements "with the hub" (but not with each other) > > > > vs the hub enabling connectivity between "federation members" and > leaving > > > > it to them to sign commercial agreements and take whatever related > > > > measures are necessary to exchange L5 traffic? In your experience > how > is this > > > > usually handled? I've heard it described both ways. > > > > > > All of the commercial entities for which I am familiar require signing > > > an agreement with the "hub" and not with the other peers. In fact, > > > some of them attempt to obfuscate the identity of the peers from each > other. > > > > > > The e.164 DUNDI context is an example of the latter (it isn't > commercial, btw). > > > You sign an agreement with one of the peers and you > > > are in the club. > > > > > > -andy > > > > > > > > > _______________________________________________ > > > 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 Jul 06 17:06:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyb2u-0005Mt-Sc; Thu, 06 Jul 2006 17:06:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyb2t-0005Mo-RG for speermint@ietf.org; Thu, 06 Jul 2006 17:05:59 -0400 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyb2r-0002OI-DH for speermint@ietf.org; Thu, 06 Jul 2006 17:05:59 -0400 Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J20007572LORQ@firewall.mci.com> for speermint@ietf.org; Thu, 06 Jul 2006 21:05:56 +0000 (GMT) Received: from pmismtp05.wcomnet.com ([127.0.0.1]) by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0J200082M2EI47@pmismtp05.mcilink.com> for speermint@ietf.org; Thu, 06 Jul 2006 21:01:30 +0000 (GMT) Received: from XS107V7775199 ([166.50.70.191]) by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0J20006IG2EIYN@pmismtp05.mcilink.com> for speermint@ietf.org; Thu, 06 Jul 2006 21:01:30 +0000 (GMT) Date: Thu, 06 Jul 2006 16:01:30 -0500 From: Tim Dwight Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) In-reply-to: <122A5731B827474C99ED552C6BFE23ED30CFDE@OVE1WNEXCB02.vcorp.ad.vrsn.com> To: "'McCandless, Kevin'" , richard@shockey.us, 'Andrew Newton' Message-id: <004801c6a13f$5aead9b0$bf4632a6@mcilink.com> Organization: MCI MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Thread-index: AcahMfkFFZB/JB91TXi8XgZawYJwlwAANzYgAAB293AAAVijYAAAjT1A X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: timothy.dwight@verizon.com 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 > Richard said: > > > However the vast majority of agreements both in teleco interconnection > > and IP data peering are bi-lateral though the may use neutral points > > to L2 interconnect. > > > Yes, that's my experience as well. This notion of federations is relatively > new, and I wondered whether it followed the same model. Andy's input > suggests that it does not. > > I wonder, though, if you stretch the bounds a bit, whether this would > change. In its support of VoIP/MMS/etc., peering, the GSM Association is > (from what I understand) similar; do its members only peer / sign > agreements with, some "hub" entity representing the GSMA, or do they peer / > sign bilateral agreements with, each other? > > What happens is a new member signs an agreement with a hub. The new > member now submits IR21 orders to gain signaling access to other members > within the hub. The member must also complete GSM association forms > such as AA14 and these are sent to the member network that the new > member wants to signal with. Such things as financial clearing and > rates are agreed upon before any active signaling takes place. Thanks Kevin, this is helpful. So, in addition to providing L2/L3 connectivity, the GSMA or some agent acting on its behalf facilitates (by providing the blank forms and forwarding them after they've been filled out by the new member, to the appropriate members) a set of bilateral agreements? Is that an accurate summary? Sounds like, at scale, we morph into a model very reminiscent of the PSTN (and L3 peering on the Internet). In your view is GSMA an anomaly, or does it illustrate the state to which peering federations naturally evolve? tim _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 06 17:31:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FybRb-0004W4-M0; Thu, 06 Jul 2006 17:31:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FybRZ-0004Vy-RX for speermint@ietf.org; Thu, 06 Jul 2006 17:31:30 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FybRY-0004bQ-Fq for speermint@ietf.org; Thu, 06 Jul 2006 17:31:29 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k66LVQfl008179; Thu, 6 Jul 2006 14:31:26 -0700 Received: from OVE1WNEXCB02.vcorp.ad.vrsn.com ([10.60.13.34]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 14:31:26 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Date: Thu, 6 Jul 2006 16:31:25 -0500 Message-ID: <122A5731B827474C99ED552C6BFE23ED30CFE1@OVE1WNEXCB02.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Thread-Index: AcahMfkFFZB/JB91TXi8XgZawYJwlwAANzYgAAB293AAAVijYAAAjT1AAAG5SCA= From: "McCandless, Kevin" To: , , "Andrew Newton" X-OriginalArrivalTime: 06 Jul 2006 21:31:26.0037 (UTC) FILETIME=[8905B050:01C6A143] X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 > Richard said: >=20 > > However the vast majority of agreements both in teleco interconnection=20 > > and IP data peering are bi-lateral though the may use neutral points > > to L2 interconnect. >=20 >=20 > Yes, that's my experience as well. This notion of federations is relatively > new, and I wondered whether it followed the same model. Andy's input > suggests that it does not. =20 >=20 > I wonder, though, if you stretch the bounds a bit, whether this would > change. In its support of VoIP/MMS/etc., peering, the GSM Association is > (from what I understand) similar; do its members only peer / sign > agreements with, some "hub" entity representing the GSMA, or do they peer / > sign bilateral agreements with, each other? >=20 > What happens is a new member signs an agreement with a hub. The new > member now submits IR21 orders to gain signaling access to other members > within the hub. The member must also complete GSM association forms > such as AA14 and these are sent to the member network that the new > member wants to signal with. Such things as financial clearing and > rates are agreed upon before any active signaling takes place. Thanks Kevin, this is helpful. So, in addition to providing L2/L3 connectivity, the GSMA or some agent acting on its behalf facilitates (by providing the blank forms and forwarding them after they've been filled out by the new member, to the appropriate members) a set of bilateral agreements? Is that an accurate summary? Correct Sounds like, at scale, we morph into a model very reminiscent of the PSTN (and L3 peering on the Internet). In your view is GSMA an anomaly, or does it illustrate the state to which peering federations naturally evolve? GSM association is a good example. How federation evolve from here remains to be seen. But I do have to agree with Andy that bilateral agreements will define a new member into a federation and that will include financial and technical expectations. =20 tim _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 06 18:01:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FybuL-0001Na-Gi; Thu, 06 Jul 2006 18:01:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FybuK-0001NL-4F for speermint@ietf.org; Thu, 06 Jul 2006 18:01:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyado-0008PY-MS for speermint@ietf.org; Thu, 06 Jul 2006 16:40:04 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyaQB-0003vW-El for speermint@ietf.org; Thu, 06 Jul 2006 16:26:01 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k66KPtOq002512; Thu, 6 Jul 2006 13:25:56 -0700 From: "Richard Shockey" To: , "'Rohan Mahy'" , "'Andrew Newton'" Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Date: Thu, 6 Jul 2006 16:25:22 -0400 Message-ID: <008601c6a13a$4f0af0d0$2e201f0a@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.2869 In-Reply-To: <001d01c6a138$fca462f0$0601a8c0@palindrome> Thread-Index: AcahHnfweqU9ji5lQP2IKk6FU8GvKwAE2HyAAAHqgHA= X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: -1.3 (-) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org, "'Uzelac, Adam'" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us 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 > -----Original Message----- > From: Peter Thermos [mailto:pthermos@palindrometechnologies.com] > Sent: Thursday, July 06, 2006 4:16 PM > To: 'Rohan Mahy'; 'Andrew Newton' > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org; 'Uzelac, Adam' > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraftsubmitted)) > > > > > > > > In the PSTN, neither media nor signaling is encrypted. However > > > trusted signaling begins at the Central Office and is exchanged > > > among switches over trunks with generally much better physical > > > security than "last-mile" access links. I can easily tap the phone > > > of almost anyone in my town from a nearby pole or manhole. Its been > > > like this for decades and except for celebrities or individuals > > > specifically targeted for attack, this lack of media security has > > > been a non-issue for the most part in the PSTN. If we take this > > > running network as any indication of priority, signaling protection > > > is more important than media protection. > > > > > > The attacks that are possible against protected signaling and > > > unprotected media (media hijacking, media recording) are a strict > > > subset of those possible against unprotected signaling (identity > > > spoofing, toll-fraud, etc..). The attacks on unprotected signaling > > > involve significant financial motivations, while there is very poor > > > positive financial motivation for attacks on the media alone. > > It depends the environment you are referring to. > There are scenarios for which an attacker can eavesdrop in to media > streams without having the need to manipulate the signaling by affecting > the underlying layers of the protocol stack (e.g. ARP spoofing). IF you never saw the signaling how are you going to find the media much less attack it, unless you are on the pole somewhere. > > > > > Let me summarize the point you just made: "It isn't secure on the > > PSTN, therefore we needn't do it either." That's hardly a requirement > > developed against the analysis of a threat. > > The fundamental difference in realizing attacks in PSTN and IP is > *ACCESSIBILITY*. > > How many residential connections do we know that can generate Q.931 > messages > to affect the PSTN? I know a lot that spoof the ANI signaling quite well. > Unless you own a DMS switch and paying 100k/month for PSTN access you > won't > be able to do much. I'm not sure of that. I can do a hell of a DoS attack with pair of wire clippers. > > At the same time how feasible is for an attacker to generate traffic > against > an SBC or other > network elements that support a VoIP infrastructure? If you don't know where it is how do you attack it. Which is BTW why the GSM model works well. > > > _______________________________________________ > 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 Jul 07 03:39:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fykw1-00013E-GJ; Fri, 07 Jul 2006 03:39:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fykw0-000131-9z for speermint@ietf.org; Fri, 07 Jul 2006 03:39:32 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyjIy-0002Lb-OV for speermint@ietf.org; Fri, 07 Jul 2006 01:55:09 -0400 Received: from mta9.srv.hcvlny.cv.net ([167.206.4.204]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fyiqn-00038w-Aw for speermint@ietf.org; Fri, 07 Jul 2006 01:26:04 -0400 Received: from palindrome (ool-43535e2d.dyn.optonline.net [67.83.94.45]) by mta9.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0J2000E9CPQS6G10@mta9.srv.hcvlny.cv.net> for speermint@ietf.org; Fri, 07 Jul 2006 01:25:44 -0400 (EDT) Date: Fri, 07 Jul 2006 01:25:52 -0400 From: Peter Thermos Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) In-reply-to: <008601c6a13a$4f0af0d0$2e201f0a@cis.neustar.com> To: richard@shockey.us, 'Rohan Mahy' , 'Andrew Newton' Message-id: <002901c6a185$d0981d30$0202fea9@palindrome> Organization: Palindrome Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcahHnfweqU9ji5lQP2IKk6FU8GvKwAE2HyAAAHqgHAAANs9YA== X-Spam-Score: -2.6 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org, "'Uzelac, Adam'" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pthermos@palindrometechnologies.com 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 > > -----Original Message----- > > From: Peter Thermos [mailto:pthermos@palindrometechnologies.com] > > Sent: Thursday, July 06, 2006 4:16 PM > > To: 'Rohan Mahy'; 'Andrew Newton' > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org; 'Uzelac, Adam' > > Subject: RE: TLS for peering (was RE: > > Comments(RE:[speermint]requirementsdraftsubmitted)) > > > > It depends the environment you are referring to. > > There are scenarios for which an attacker can eavesdrop in to media > > streams without having the need to manipulate the signaling by > > affecting the underlying layers of the protocol stack (e.g. > ARP spoofing). > > > IF you never saw the signaling how are you going to find the > media much less attack it, unless you are on the pole somewhere. Although there is a difference between "seeing the the signaling" the initial statement was "without having the need to manipulate the signaling" which is different. It is also feasible to identify whether two endpoints communicate using SIP through various methods (e.g. portscanning, sniffing traffic). In addition an attacker can collect RTP traffic if they have access to a segment of the network. But this is an end point concern. Not a concern of a peering realm where traffic has propagated from the end points already towards the core of the network. I believe Rohan's point is focusing on the peering relationship rather on the attacks that may occur on the endpoints as it was mentioned by another colleague. > > > > Let me summarize the point you just made: "It isn't secure on the > > > PSTN, therefore we needn't do it either." That's hardly a > > > requirement developed against the analysis of a threat. > > > > The fundamental difference in realizing attacks in PSTN and IP is > > *ACCESSIBILITY*. > > > > How many residential connections do we know that can generate Q.931 > > messages to affect the PSTN? > > I know a lot that spoof the ANI signaling quite well. Although I'm not sure this is the right place to start enumerating proper PSTN and VoIP security practices but normally, the ANI is set by the originating central office, based on the number of the calling line. Unless, you route through a VoIP provider or through a PBX using primary rate ISDN where the Caller ID is determined by the originating PBX. This is not the same as generating traffic from the traditional sense of network attack to compomise network elements or disrupt services. > > I'm not sure of that. I can do a hell of a DoS attack with > pair of wire > clippers. Unless the other end of the clippers is connected to something more capable than a dialpad, I'm not clear as to what you are alluding to. > > At the same time how feasible is for an attacker to generate traffic > > against > > an SBC or other > > network elements that support a VoIP infrastructure? > > > If you don't know where it is how do you attack it. Which is > BTW why the GSM > model works well. > I'm not sure what exactly you are refering to but typically SBC's and in some implementations Proxies are reachable from the Internet and thus discovery is as simple as a portscan. Unless these network elements operate within anIP-VPN where they are not accessible from the Internet. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 07 09:47:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyqg8-0000wQ-LM; Fri, 07 Jul 2006 09:47:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyqg5-0000wL-W4 for speermint@ietf.org; Fri, 07 Jul 2006 09:47:29 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyqg4-0003Aw-PE for speermint@ietf.org; Fri, 07 Jul 2006 09:47:29 -0400 Received: from ([10.20.62.12]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.22036357; Fri, 07 Jul 2006 09:46:03 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 09:46:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jul 2006 09:46:17 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF335@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [wg-business] Montreal Meeting Notice (possible change) Thread-Index: Acahy7ibZI4ei/23TJSmmE839wJz/g== X-Priority: 1 Priority: Urgent Importance: high From: "Livingood, Jason" To: X-OriginalArrivalTime: 07 Jul 2006 13:46:17.0904 (UTC) FILETIME=[B8E44B00:01C6A1CB] X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Speermint] [wg-business] Montreal Meeting Notice (possible change) 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 Due to a scheduling conflict which has just arisen with SIP at our scheduled time, it is highly likely that the time/date for our session at Montreal will change. As soon as we have more information, we will post it here. Regards Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 07 10:38:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrTP-00015J-P2; Fri, 07 Jul 2006 10:38:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrTO-00015A-Qi for speermint@ietf.org; Fri, 07 Jul 2006 10:38:26 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyrTN-00088W-Kn for speermint@ietf.org; Fri, 07 Jul 2006 10:38:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TLS for peering (was RE:Comments(RE:[speermint]requirementsdraftsubmitted)) Date: Fri, 7 Jul 2006 10:38:07 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF33B@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE:Comments(RE:[speermint]requirementsdraftsubmitted)) Thread-Index: AcahHnfweqU9ji5lQP2IKk6FU8GvKwAE2HyAAAHqgHAAJkfT8A== From: "Livingood, Jason" To: , , "Rohan Mahy" , "Andrew Newton" X-OriginalArrivalTime: 07 Jul 2006 14:38:08.0591 (UTC) FILETIME=[F70175F0:01C6A1D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: "Khan, Sohel Q \[CTO\]" , 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 > > Unless you own a DMS switch and paying 100k/month for PSTN=20 > access you=20 > > won't be able to do much. >=20 >=20 > I'm not sure of that. I can do a hell of a DoS attack with=20 > pair of wire > clippers. Yeah, but you know kids these days just don't like to play outside like they used to. Why not sit at home playing Xbox 360 on one screen and DoSing on the other, all while eating a nice snack in the comfort of central air conditioning. ;-) Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 07 10:39:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrUG-0001lr-4s; Fri, 07 Jul 2006 10:39:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrUE-0001lm-JE for speermint@ietf.org; Fri, 07 Jul 2006 10:39:18 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyrUD-0008Db-Cm for speermint@ietf.org; Fri, 07 Jul 2006 10:39:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Date: Fri, 7 Jul 2006 10:38:59 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF33C@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Thread-Index: AcahNoSBAC04q0aiSTyqS4oIT0hQuQAAjE0AACY5LeA= From: "Livingood, Jason" To: , "Andrew Newton" X-OriginalArrivalTime: 07 Jul 2006 14:38:59.0783 (UTC) FILETIME=[1584BD70:01C6A1D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 only meant that in your context where the hub attempts to=20 > "obfuscate the identity of the peers from each other." =20 >=20 > IMHO this is one of the silliest ideas federations can engage=20 > in. It provides no real advantage to the peers except that=20 > they are kept in the dark like mushrooms. >=20 > The counter argument that peers must be keep from each other=20 > so they wont poach on each others territory is simply not=20 > proven by fact. Anyone can find out who is the underlying=20 > carrier for a particular TN. That is why every country has=20 > SIPD databases. And I can tell you from speaking with several operators about this that many of them in fact want to know who the other carrier is. This is sometimes for business reasons, such as developing a billing/comp agreement. This is other times in a desire to reduce fraud and be able to traceback and/or troubleshoot sessions. I am not taking into account legal agreements, which is surely out of scope. Mainly I wanted to point out that some of these operators very much desire to know who they connect to and aren't looking to hide their numbers. All that being said, some operator use cases have been described where an operator just wants a relationship with an aggregrator/federation/hub and to have them mind all the session terminations (as Kevin McCandless briefly described). In this case they may not necessarily care who the session terminates with. That's another flavor with different business requirements. =20 So perhaps this points out that there may be a place for both models... Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 07 10:42:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrXK-0004p9-V1; Fri, 07 Jul 2006 10:42:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrXK-0004p4-7s for speermint@ietf.org; Fri, 07 Jul 2006 10:42:30 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyrXI-0008JJ-0z for speermint@ietf.org; Fri, 07 Jul 2006 10:42:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jul 2006 10:42:06 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF33D@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (attack vector draft request) Thread-Index: Acagn6v1qmQNVATGTluGAxwSiJXSUwBL91Bg From: "Livingood, Jason" To: "Andrew Newton" , "Rohan Mahy" X-OriginalArrivalTime: 07 Jul 2006 14:42:07.0138 (UTC) FILETIME=[8530D820:01C6A1D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org, "Uzelac, Adam" Subject: [Speermint] RE: TLS for peering (attack vector draft request) 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 > Let me summarize the point you just made: "It isn't secure on=20 > the PSTN, therefore we needn't do it either." That's hardly=20 > a requirement developed against the analysis of a threat. >=20 > I believe that most people would want both the signaling and=20 > media secured (if they knew the difference between the two),=20 > but if they had to have one they would opt for secure media. >=20 > And if you are worried about toll fraud, the "last mile"=20 > access link should be a significant worry. There is no point=20 > in burdening the peering points with over-the-top security=20 > when the system can be easily gamed at the end points. I'd like to suggest that someone or some group of people start work on a draft that documents possible VoIP peering attack vectors so we know all of the possible angles of attack to consider. That could help inform some of the discussion here. Don't say we didn't ask for one... :-) FWIW, I continue to believe that some of the attack/abuse-prevention techniques and learnings from messaging could be applied here in some sense. So if anyone from MAAWG (Messaging Anti-Abuse Working Group) or something like that wants to help out, please do so.=20 Regards Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 07 10:43:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrYb-0005Lc-AL; Fri, 07 Jul 2006 10:43:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrYa-0005IW-HP for speermint@ietf.org; Fri, 07 Jul 2006 10:43:48 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyrYY-0008Lo-8U for speermint@ietf.org; Fri, 07 Jul 2006 10:43:48 -0400 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.22039395; Fri, 07 Jul 2006 10:43:27 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 10:43:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Date: Fri, 7 Jul 2006 10:43:27 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF33E@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Thread-Index: AcahHnfweqU9ji5lQP2IKk6FU8GvKwAE2HyAACeaaOA= From: "Livingood, Jason" To: , "Rohan Mahy" , "Andrew Newton" X-OriginalArrivalTime: 07 Jul 2006 14:43:27.0417 (UTC) FILETIME=[B50A7290:01C6A1D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Khan, Sohel Q \[CTO\]" , 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 > > Let me summarize the point you just made: "It isn't secure on the=20 > > PSTN, therefore we needn't do it either." That's hardly a=20 > requirement=20 > > developed against the analysis of a threat. >=20 > The fundamental difference in realizing attacks in PSTN and IP is > *ACCESSIBILITY*. >=20 > How many residential connections do we know that can generate=20 > Q.931 messages > to affect the PSTN? > Unless you own a DMS switch and paying 100k/month for PSTN=20 > access you won't > be able to do much. >=20 > At the same time how feasible is for an attacker to generate=20 > traffic against > an SBC or other=20 > network elements that support a VoIP infrastructure? This is a good point. The ease and low cost of generating attacks or other 'bad' traffic is trivially low on the net and the information on how to do so is quickly and widely distributed. > It depends what is the motivation of the attacker.=20 > But I'm not sure if the group wants to address media protection from a > peering perspective. Signaling protection can be mandated between > intermediate hops but media protection should be left up to=20 > the end points. > The peering nodes should hand off the RTP stream as is. A good suggestion you have raised for consideration -> let the end point / UAs worry about the RTP stream. Certainly there are PSTN end user devices that will be paired at both ends to provide media security and there'd be nothing to discourage UAs (perhaps most easily realized in software-based clients) from employing end-to-end media encryption. But I suspect we'll see a variety of options here. We seem to have general consensus that, at the very least, signaling traffic should or must in some manner be secured/encrypted. There may be some confusion about the difference between mandatory-to-implement and mandatory-to-use. TLS is already mandatory-to-implement in the SIP standard (for proxies, which is what matters in a speermint context).=20 We will need to focus on the issue of the circumstances under which using TLS is meaningful and appropriate. Saying that TLS is mandatory-to-use could be problematic as there could be situations where other methods may be more appropriate and some of that has been touched upon in this long and continuing thread. ;-) Jason=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 07 10:55:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrkD-0002Fe-4J; Fri, 07 Jul 2006 10:55:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrkC-0002F9-2f for speermint@ietf.org; Fri, 07 Jul 2006 10:55:48 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyrkA-0002Dm-TA for speermint@ietf.org; Fri, 07 Jul 2006 10:55:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Fri, 7 Jul 2006 10:55:20 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF344@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Thread-Index: Acad8BX8/MNQnIVWRyKvflpuL+N3cwD5SWkQ From: "Livingood, Jason" To: "Cullen Jennings" , "Drage, Keith \(Keith\)" X-OriginalArrivalTime: 07 Jul 2006 14:55:21.0267 (UTC) FILETIME=[5E875030:01C6A1D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 > About 1 second after I hit the send button on my original=20 > message, I realized what a stupid thing I was saying.=20 > Completely agree with Keith. >=20 >=20 > On Jul 2, 2006, at 1:23 AM, Drage, Keith (Keith) wrote: >=20 > > Oh no they do not - starting with just about every mobile phone you=20 > > pick up. > > > > and therein lies your problem. Use of G.711 over the air=20 > interface has=20 > > sufficient cost to either preclude or prevent its use. So, in the mobile space, what is the lowest common denominator codec? (Perhaps we can arrive at a couple of options and figure things out from there.) Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 07 11:19:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fys7L-00031r-MT; Fri, 07 Jul 2006 11:19:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fys7K-00031m-Lm for speermint@ietf.org; Fri, 07 Jul 2006 11:19:42 -0400 Received: from [205.151.208.34] (helo=fw.tr.xittelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fys7J-00057z-Et for speermint@ietf.org; Fri, 07 Jul 2006 11:19:42 -0400 Received: from [192.168.2.139] (helo=gestionfm) by fw.tr.xittelecom.com with esmtp (Exim 3.36 #1 (Debian)) id 1FysA7-0006jP-00; Fri, 07 Jul 2006 11:22:35 -0400 From: "Francois D. Menard" To: "'Livingood, Jason'" , Subject: RE: [Speermint] [wg-business] Montreal Meeting Notice (possible change) Date: Fri, 7 Jul 2006 11:19:42 -0400 Message-ID: <036501c6a1d8$c58603a0$8b02a8c0@gestionfm> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acahy7ibZI4ei/23TJSmmE839wJz/gADQfTg In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF335@PACDCEXCMB03.cable.comcast.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Any bar bof scheduled? F.=20 -- Fran=E7ois D. M=E9nard Charg=E9 de projet Xit t=E9l=E9com inc. 1350 rue Royale #800 Trois-Rivi=E8res, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 =20 -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: 7 juillet 2006 09:46 To: speermint@ietf.org Subject: [Speermint] [wg-business] Montreal Meeting Notice (possible = change) Importance: High Due to a scheduling conflict which has just arisen with SIP at our = scheduled time, it is highly likely that the time/date for our session at Montreal will change. As soon as we have more information, we will post it here. Regards Jason _______________________________________________ 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 Jul 07 11:23:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FysB2-0004R7-BL; Fri, 07 Jul 2006 11:23:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FysB0-0004R2-KQ for speermint@ietf.org; Fri, 07 Jul 2006 11:23:30 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FysAz-0005Q0-DK for speermint@ietf.org; Fri, 07 Jul 2006 11:23:30 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Fri, 07 Jul 2006 11:23:43 -0400 id 015880C7.44AE7C7F.00001E5A Message-ID: <44AE7C66.6090709@hxr.us> Date: Fri, 07 Jul 2006 11:23:18 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Livingood, Jason" References: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF33D@PACDCEXCMB03.cable.comcast.com> In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF33D@PACDCEXCMB03.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: speermint@ietf.org Subject: [Speermint] wide open peering [was Re: TLS for peering (attack vector draft request)] 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 Livingood, Jason wrote: > FWIW, I continue to believe that some of the attack/abuse-prevention > techniques and learnings from messaging could be applied here in some > sense. So if anyone from MAAWG (Messaging Anti-Abuse Working Group) or > something like that wants to help out, please do so. Having been a participant of MAAWG, co-chair of MARID, and otherwise wasting too much time in the anti-spam arena, the one big takeaway I got from all of it was Dave Crocker's saying: "If anybody tells you they have the answer to spam, they are lying." If you want to prevent abuse, you need reputation systems. They come in many forms from private address ACLs to DNS blacklists to managed services (which for this context, is known as a peering federation or exchange). And as you can imagine, one size does not fit all. This is why I keep asking the question about the scope of the work for this working group: are we addressing the problems of wide open peering, or are we addressing the problems of more restrictive peering arrangements? The two do not have the same problems and requirements. If this group is to address wide open peering, then the right answer might be to produce something on which reputation services could hang their hat... and hope and pray that some entity out there gets recognized as a trusted reputation player. If this group is to address peering arrangements where some form of reputation system is already in use, I see little value in demanding they switch it to certificate-based TLS... if for no other reason than it is much, much harder to develop a reasonable reputation service than the bits on the wire to enable them. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 07 12:17:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyt1a-0005em-Tl; Fri, 07 Jul 2006 12:17:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyt1a-0005e7-3r for speermint@ietf.org; Fri, 07 Jul 2006 12:17:50 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyt1X-00037D-RK for speermint@ietf.org; Fri, 07 Jul 2006 12:17:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: UPD ? Date: Fri, 7 Jul 2006 12:17:21 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96D34F79@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: UPD ? Thread-Index: AcacZQ0AZWTS+yshQ5G9/il5y8rbdwFd7AiQ From: "Lee, Yiu" To: "Andrew Newton" , "Cullen Jennings" X-OriginalArrivalTime: 07 Jul 2006 16:17:23.0078 (UTC) FILETIME=[D4281260:01C6A1E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: "Leung, Alex" , "Khan, Sohel Q \[\[CTO\]\]" , speermint@ietf.org, "Livingood, Jason" , Adam Uzelac 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 Andy, I work in operator, so I can share some of our experience in regard to TCP/UDP for SIP. You are right that persistence TCP connection affects load balancing and fault tolerance schemes, Cullen is also right that IP fragmentation causes many problems especially our firewalls in production. We can't avoid the fact that SIP messages are getting bigger and bigger. So our current way to solve the problem is to have UDP connection between user-endpoint to our edge SIP proxy (P-CSCF/CMS) and have TCP connection between proxies. Since PacketCable eMTA connects to the cable plan directly, so we do not expect any firewall between the eMTA and our edge SIP proxy. However, the IP fragmentation will become problem when we introduce PC based soft client to the market for PacketCable Release 2.0. Using TCP connection between proxies is a natural decision. Normally connections between these proxies are long-lived. Also, we don't expect to have many of those connections between proxies. Since we have firewall between the edge proxy and other internal proxies or application servers, TCP can help us to simplify the firewall rules. Cullen's SIP outbound draft is a potential solution for handling persistent TCP connection between user endpoint and edge proxy. But this is a more expensive solution compared to using simple UDP connection. Another way may help is to use compression to the SDP before sending. This may help to reduce the total message size. However, if one day the SIP header size alone is larger than 1300 bytes, then we may have to work on TCP connection. Yiu -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Friday, June 30, 2006 12:48 PM To: Cullen Jennings Cc: Khan, Sohel Q [[CTO]]; speermint@ietf.org; Adam Uzelac Subject: [Speermint] Re: UPD ? On Jun 30, 2006, at 12:00 PM, Cullen Jennings wrote: > My real concern is IETF is acting as if we will move to TCP,=20 > deployments are acting as if this is not possible. This mismatch seems > like a growing problem for us and I am concerned about it. I think=20 > that this speermint WG has operators that are connected with the real=20 > issues so this seems as good a place as any to discuss this. For us the UDP vs. TCP issue is much more important on the registrar part of the network thanks to the ever cursed NAT. But even with peering, UDP is better performance wise. Persistent TCP connections also tend to cause problems with load balancing and fault tolerance schemes, which is a big issue. I do agree that TCP is important and strategies will need to be developed to better handle it. -andy _______________________________________________ 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 Jul 07 12:42:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FytPu-0007Ix-CR; Fri, 07 Jul 2006 12:42:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FytPs-0007Is-Mb for speermint@ietf.org; Fri, 07 Jul 2006 12:42:56 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FytPr-0005T0-B0 for speermint@ietf.org; Fri, 07 Jul 2006 12:42:56 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k67GgnI6007324; Fri, 7 Jul 2006 09:42:49 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k67Ggn3l007323; Fri, 7 Jul 2006 09:42:49 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 7 Jul 2006 09:42:49 -0700 From: David Meyer To: "Livingood, Jason" Subject: Re: [Speermint] RE: TLS for peering (attack vector draft request) Message-ID: <20060707164249.GA7314@1-4-5.net> References: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF33D@PACDCEXCMB03.cable.comcast.com> Mime-Version: 1.0 In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF33D@PACDCEXCMB03.cable.comcast.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "Khan, Sohel Q \[CTO\]" , 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: , Content-Type: multipart/mixed; boundary="===============0620434301==" Errors-To: speermint-bounces@ietf.org --===============0620434301== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 07, 2006 at 10:42:06AM -0400, Livingood, Jason wrote: > > Let me summarize the point you just made: "It isn't secure on=20 > > the PSTN, therefore we needn't do it either." That's hardly=20 > > a requirement developed against the analysis of a threat. > >=20 > > I believe that most people would want both the signaling and=20 > > media secured (if they knew the difference between the two),=20 > > but if they had to have one they would opt for secure media. > >=20 > > And if you are worried about toll fraud, the "last mile"=20 > > access link should be a significant worry. There is no point=20 > > in burdening the peering points with over-the-top security=20 > > when the system can be easily gamed at the end points. >=20 > I'd like to suggest that someone or some group of people start work on a > draft that documents possible VoIP peering attack vectors so we know all > of the possible angles of attack to consider. That could help inform > some of the discussion here. Don't say we didn't ask for one... :-) >=20 > FWIW, I continue to believe that some of the attack/abuse-prevention > techniques and learnings from messaging could be applied here in some > sense. So if anyone from MAAWG (Messaging Anti-Abuse Working Group) or > something like that wants to help out, please do so.=20 Excellent suggestion. Have folks looked at any of the BGP attack tree documents? It'd be nice (tm) to have something like that for our case(s). --dmm --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEro8JORgD1qCZ2KcRAgpXAJ9C11ssxoVpmXaJp/VmFIn3FTJGIwCgitDL U4++w/8ROu7fnuYRtqH0np8= =O/Nd -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- --===============0620434301== 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 --===============0620434301==-- From speermint-bounces@ietf.org Fri Jul 07 12:56:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FytdD-0003Hn-Eo; Fri, 07 Jul 2006 12:56:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FytdC-0003E6-AB for speermint@ietf.org; Fri, 07 Jul 2006 12:56:42 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FytdA-0006y6-19 for speermint@ietf.org; Fri, 07 Jul 2006 12:56:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] wide open peering [was Re: TLS for peering (attackvector draft request)] Date: Fri, 7 Jul 2006 12:56:10 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF346@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] wide open peering [was Re: TLS for peering (attackvector draft request)] Thread-Index: Acah2WJqk/yOw7M+QieYG/3Wpky+sAADJeag From: "Livingood, Jason" To: "Andrew Newton" X-OriginalArrivalTime: 07 Jul 2006 16:56:11.0144 (UTC) FILETIME=[3FCAC080:01C6A1E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 > This is why I keep asking the question about the scope of the=20 > work for this working group: are we addressing the problems=20 > of wide open peering, or are we addressing the problems of=20 > more restrictive peering arrangements? The two do not have=20 > the same problems and requirements. And I think we keep answering those questions. Short-term is limited / restrictive arrangements. Long-term, the goal, is more widespread and open. Short-term is how you get to the long-term state, the world probably isn't going to make the leap in one step. Jason =20 > If this group is to address wide open peering, then the right=20 > answer might be to produce something on which reputation=20 > services could hang their hat... and hope and pray that some=20 > entity out there gets recognized as a trusted reputation player. >=20 > If this group is to address peering arrangements where some=20 > form of reputation system is already in use, I see little=20 > value in demanding they switch it to certificate-based TLS...=20 > if for no other reason than it is much, much harder to=20 > develop a reasonable reputation service than the bits on the=20 > wire to enable them. >=20 > -andy >=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 Fri Jul 07 16:41:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyx8y-0002ud-Ap; Fri, 07 Jul 2006 16:41:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyx8w-0002uT-SQ for speermint@ietf.org; Fri, 07 Jul 2006 16:41:42 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyx8v-0003oc-L6 for speermint@ietf.org; Fri, 07 Jul 2006 16:41:42 -0400 Received: by py-out-1112.google.com with SMTP id s49so280547pyc for ; Fri, 07 Jul 2006 13:41:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NzCuGMHlfVv4whqO+Y62PdxF4aJMBaEOky63Ff5xbOd+u+huk53tZWbkiOS6cqK2z7cU/vpbKusUR61WgzPyUsXWUdbJD2+N4RAuwOMU+fNEr3ulA3uHOamFQWfWCKMdIrfIxl2HcmnJEyYioYdxdn32wnK6K7QM3x/PEJy6NQg= Received: by 10.35.132.13 with SMTP id j13mr659338pyn; Fri, 07 Jul 2006 13:41:41 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Fri, 7 Jul 2006 13:41:40 -0700 (PDT) Message-ID: <953beacc0607071341x201ce67aue7debb606b7653ed@mail.gmail.com> Date: Fri, 7 Jul 2006 13:41:40 -0700 From: "Rohan Mahy" To: "Andrew Newton" Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) In-Reply-To: <44AD59BB.1080104@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <00ae01c69ae3$70cc78e0$4d201f0a@cis.neustar.com> <732EB664-954E-410E-A7BD-9F53D350F119@hxr.us> <953beacc0606291705j603aa36fwb08b9f0687fb7150@mail.gmail.com> <6A4304EA-845D-4120-B0F4-FDC390334328@hxr.us> <953beacc0607041102s2241c143j6a1c2c3acefa3746@mail.gmail.com> <8DD9B5C3-1C80-45DD-9443-5D2CAFC22AC8@hxr.us> <953beacc0607061005s32fdc490x786c2b0153a80a8e@mail.gmail.com> <44AD59BB.1080104@hxr.us> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Hi Andy, On 7/6/06, Andrew Newton wrote: > Rohan Mahy wrote: > >> > At issue here in speermint is what mechanism is used between two peers > >> > that are compliant to the speermint peering convention. If you want > >> > to setup a private club to do private peering, you can do that however > >> > you'd like. > >> > >> So this is "public" peering where we are worried about toll fraud (as > >> you described above)? Exactly what problem do you think you are > >> solving? TLS will not solve the problem that settlement terms must > >> be agreed upon and a contract must be signed before an > >> interconnection can be made. > > > > Several others on this thread have mentioned belonging to one or more > > clubs, federations, or clearing houses where you sign an agreement > > only with the "hubs". > > So a commercial peering exchange meets your definition of public peering? I did not introduce the term public peering in this thread. You did. I documented a strawman model that I feel is technically compatible with a broad spectrum of peering models from fee-based bilateral settlement to wide open peering. > I'm quite familiar with a number of them. Of the ones for which I am > familiar, most define the list of codecs that must be supported, many > require peering at layer 2, some utilize tunneling for security, and > none use TLS. So from my perspective, you are advocating the opposite > of what is happening in the industry. If the industry was successfully solving the peering problem, there would have been no groundswell of demand to form this WG. Indeed, the majority of calls between two IP providers still goes over the PSTN. If there was a predominant approach that was working I suspect someone would have written a whitepaper or draft documenting the approach. This has also not happened. Finally, our role in this WG is necessarily more limited in scope than any one commercial peering exchange. This group needs to offer a technical solution to a broader range of "users" than a single type of commercial peering exchange. thanks, -rohan _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 07 17:40:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyy4D-0005UF-Dk; Fri, 07 Jul 2006 17:40:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyy4C-0005St-39 for speermint@ietf.org; Fri, 07 Jul 2006 17:40:52 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyy47-0001Bs-Rw for speermint@ietf.org; Fri, 07 Jul 2006 17:40:52 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k67Lekuv002665; Fri, 7 Jul 2006 16:40:46 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ94Y7W>; Fri, 7 Jul 2006 22:40:46 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290973@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Livingood, Jason'" Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Fri, 7 Jul 2006 22:40:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 If you go here, you will find the 3GPP specification for codec usage in IMS. http://www.3gpp.org/ftp/Specs/html-info/26235.htm Suggest use the latest version of the latest release unless you have reasons otherwise. Any of the other 3GPP references from within this document can be found by starting at http://www.3gpp.org/ftp/Specs/html-info/status-report.htm but you should get the information you need from clause 6.1 of the main document. Afraid I am not close enough to 3GPP2 to give you their references until I catch up with some of my colleagues next week. regards Keith > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: 07 July 2006 15:55 > To: Cullen Jennings; Drage, Keith (Keith) > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D > ACTION:draft-ietf-speermint-requirements-00.t xt > > > > About 1 second after I hit the send button on my original > > message, I realized what a stupid thing I was saying. > > Completely agree with Keith. > > > > > > On Jul 2, 2006, at 1:23 AM, Drage, Keith (Keith) wrote: > > > > > Oh no they do not - starting with just about every mobile > phone you > > > pick up. > > > > > > and therein lies your problem. Use of G.711 over the air > > interface has > > > sufficient cost to either preclude or prevent its use. > > So, in the mobile space, what is the lowest common denominator codec? > (Perhaps we can arrive at a couple of options and figure > things out from > there.) > > Jason > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 07 18:41:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyz12-00028N-FP; Fri, 07 Jul 2006 18:41:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyz11-00028I-2O for speermint@ietf.org; Fri, 07 Jul 2006 18:41:39 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyz0z-0001eR-Pp for speermint@ietf.org; Fri, 07 Jul 2006 18:41:39 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 07 Jul 2006 15:41:36 -0700 X-IronPort-AV: i="4.06,219,1149490800"; d="scan'208"; a="566071017:sNHT30767080" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] RE: TLS for peering (attack vector draft request) Date: Fri, 7 Jul 2006 18:41:34 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804DA9503@proton.jnpr.net> In-Reply-To: <20060707164249.GA7314@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: TLS for peering (attack vector draft request) Thread-Index: Acah5IprC1yU1tnTRMuIQGM6hYw6gQAMchqg From: "Reinaldo Penno" To: "David Meyer" , "Livingood, Jason" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "Khan, Sohel Q \[CTO\]" , 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 I agree. This long security discussion will greatly benefit from a security draft in Speermint as suggested by the chairs.=20 > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net] > Sent: Friday, July 07, 2006 9:43 AM > To: Livingood, Jason > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Uzelac, Adam > Subject: Re: [Speermint] RE: TLS for peering (attack vector draft request) >=20 > On Fri, Jul 07, 2006 at 10:42:06AM -0400, Livingood, Jason wrote: > > > Let me summarize the point you just made: "It isn't secure on > > > the PSTN, therefore we needn't do it either." That's hardly > > > a requirement developed against the analysis of a threat. > > > > > > I believe that most people would want both the signaling and > > > media secured (if they knew the difference between the two), > > > but if they had to have one they would opt for secure media. > > > > > > And if you are worried about toll fraud, the "last mile" > > > access link should be a significant worry. There is no point > > > in burdening the peering points with over-the-top security > > > when the system can be easily gamed at the end points. > > > > I'd like to suggest that someone or some group of people start work on a > > draft that documents possible VoIP peering attack vectors so we know all > > of the possible angles of attack to consider. That could help inform > > some of the discussion here. Don't say we didn't ask for one... :-) > > > > FWIW, I continue to believe that some of the attack/abuse-prevention > > techniques and learnings from messaging could be applied here in some > > sense. So if anyone from MAAWG (Messaging Anti-Abuse Working Group) or > > something like that wants to help out, please do so. >=20 > Excellent suggestion. Have folks looked at any of the BGP > attack tree documents? It'd be nice (tm) to have > something like that for our case(s). >=20 > --dmm _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat Jul 08 11:42:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzEwe-0005pI-Kw; Sat, 08 Jul 2006 11:42:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzEwd-0005pD-MD for speermint@ietf.org; Sat, 08 Jul 2006 11:42:11 -0400 Received: from outbound-res.frontbridge.com ([63.161.60.49] helo=outbound1-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzEwc-00067K-Du for speermint@ietf.org; Sat, 08 Jul 2006 11:42:11 -0400 Received: from outbound1-res.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-res-R.bigfish.com (Postfix) with ESMTP id 5171C7DD697; Sat, 8 Jul 2006 15:42:10 +0000 (UTC) Received: from mail13-res-R.bigfish.com (unknown [172.18.16.1]) by outbound1-res.bigfish.com (Postfix) with ESMTP id 49A6A7DD684; Sat, 8 Jul 2006 15:42:10 +0000 (UTC) Received: from mail13-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail13-res-R.bigfish.com (Postfix) with ESMTP id 3E40D5C66A2; Sat, 8 Jul 2006 15:42:10 +0000 (UTC) X-BigFish: V Received: by mail13-res (MessageSwitch) id 1152373330209552_6842; Sat, 8 Jul 2006 15:42:10 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail13-res.bigfish.com (Postfix) with ESMTP id 1F7615C614D; Sat, 8 Jul 2006 15:42:10 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k68Fg9Ag006222; Sat, 8 Jul 2006 10:42:09 -0500 (CDT) Received: from pdawg05a.ad.sprint.com (PDAWG05A.corp.sprint.com [10.122.2.38]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k68Fg9d03296; Sat, 8 Jul 2006 10:42:09 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by pdawg05a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Jul 2006 10:42:08 -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] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Sat, 8 Jul 2006 10:42:08 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A13014782BB@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Thread-Index: Acad8BX8/MNQnIVWRyKvflpuL+N3cwD5SWkQADPikhA= From: "Khan, Sohel Q [CTO]" To: "Livingood, Jason" , "Cullen Jennings" , "Drage, Keith \(Keith\)" X-OriginalArrivalTime: 08 Jul 2006 15:42:08.0418 (UTC) FILETIME=[12225020:01C6A2A5] X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 My suggestion is Enhanced Variable Rate Codec (EVRC). =20 -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Friday, July 07, 2006 9:55 AM To: Cullen Jennings; Drage, Keith (Keith) Cc: speermint@ietf.org Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt ... So, in the mobile space, what is the lowest common denominator codec? (Perhaps we can arrive at a couple of options and figure things out from there.) Jason _______________________________________________ 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 Jul 08 12:12:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzFQ4-0001P9-W5; Sat, 08 Jul 2006 12:12:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzFQ3-0001P4-H5 for speermint@ietf.org; Sat, 08 Jul 2006 12:12:35 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound2-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzFQ2-0002Um-4q for speermint@ietf.org; Sat, 08 Jul 2006 12:12:35 -0400 Received: from outbound2-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-cpk-R.bigfish.com (Postfix) with ESMTP id 88BC4CA0650; Sat, 8 Jul 2006 16:12:33 +0000 (UTC) Received: from mail59-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound2-cpk.bigfish.com (Postfix) with ESMTP id 81582CA064F; Sat, 8 Jul 2006 16:12:33 +0000 (UTC) Received: from mail59-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail59-cpk-R.bigfish.com (Postfix) with ESMTP id 67968463F5A; Sat, 8 Jul 2006 16:12:33 +0000 (UTC) X-BigFish: V Received: by mail59-cpk (MessageSwitch) id 1152375153380651_22906; Sat, 8 Jul 2006 16:12:33 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail59-cpk.bigfish.com (Postfix) with ESMTP id 2D070463ABC; Sat, 8 Jul 2006 16:12:33 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k68GB1vP017094; Sat, 8 Jul 2006 11:11:16 -0500 (CDT) Received: from plswg02a.ad.sprint.com (PLSWG02A.corp.sprint.com [10.214.11.48]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k68GAxB15504; Sat, 8 Jul 2006 11:10:59 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg02a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Jul 2006 11:10:59 -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: TLS for peering (was RE:Comments(RE:[speermint]requirementsdraftsubmitted)) Date: Sat, 8 Jul 2006 11:10:58 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A13014782C3@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE:Comments(RE:[speermint]requirementsdraftsubmitted)) Thread-Index: AcahHnfweqU9ji5lQP2IKk6FU8GvKwAE2HyAAAHqgHAAJkfT8AA1XX5g From: "Khan, Sohel Q [CTO]" To: "Livingood, Jason" , , , "Rohan Mahy" , "Andrew Newton" X-OriginalArrivalTime: 08 Jul 2006 16:10:59.0405 (UTC) FILETIME=[19E1F7D0:01C6A2A9] X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 =20 This is not a joke but a story: once upon a time there were two VoIP networks X and Y. The X and Y implemented all kind of security mechanism at the end points/access interfaces so that "DoS Kids" cannot attack those networks. VoIP X and Y peer with each other. One sunny day, one of the SIP proxies in VoIP network X "gone crazy" and started to send thousands of SIP INVITE to the peering proxy of network Y. The network Y got crippled not by the new "DoS Kids" in town, but his friendly and trusted neighbor's grown up proxy! Sohel Khan =20 -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Friday, July 07, 2006 9:38 AM To: richard@shockey.us; pthermos@palindrometechnologies.com; Rohan Mahy; Andrew Newton Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Uzelac, Adam Subject: RE: TLS for peering (was RE:Comments(RE:[speermint]requirementsdraftsubmitted)) > > Unless you own a DMS switch and paying 100k/month for PSTN > access you > > won't be able to do much. >=20 >=20 > I'm not sure of that. I can do a hell of a DoS attack with pair of=20 > wire clippers. Yeah, but you know kids these days just don't like to play outside like they used to. Why not sit at home playing Xbox 360 on one screen and DoSing on the other, all while eating a nice snack in the comfort of central air conditioning. ;-) Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat Jul 08 12:32:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzFj6-0008Cy-L0; Sat, 08 Jul 2006 12:32:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzFj5-0008Ct-HM for speermint@ietf.org; Sat, 08 Jul 2006 12:32:15 -0400 Received: from outbound-res.frontbridge.com ([63.161.60.49] helo=outbound2-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzFj4-0003Gy-9I for speermint@ietf.org; Sat, 08 Jul 2006 12:32:15 -0400 Received: from outbound2-res.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-res-R.bigfish.com (Postfix) with ESMTP id 912BD800D1F; Sat, 8 Jul 2006 16:31:38 +0000 (UTC) Received: from mail2-res-R.bigfish.com (unknown [172.18.16.1]) by outbound2-res.bigfish.com (Postfix) with ESMTP id 88BA9800D1D; Sat, 8 Jul 2006 16:31:38 +0000 (UTC) Received: from mail2-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail2-res-R.bigfish.com (Postfix) with ESMTP id 72FCF5F7D31; Sat, 8 Jul 2006 16:31:38 +0000 (UTC) X-BigFish: V Received: by mail2-res (MessageSwitch) id 1152376298383572_12533; Sat, 8 Jul 2006 16:31:38 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail2-res.bigfish.com (Postfix) with ESMTP id 3FADF5FD2B9; Sat, 8 Jul 2006 16:31:33 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k68GUbHe001950; Sat, 8 Jul 2006 11:30:57 -0500 (CDT) Received: from pdawg06a.ad.sprint.com (PDAWG06A.corp.sprint.com [10.122.2.33]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k68GUbB19492; Sat, 8 Jul 2006 11:30:37 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by pdawg06a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Jul 2006 11:30:36 -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: TLS for peering (was RE:Comments(RE:[speermint]requirementsdraftsubmitted)) Date: Sat, 8 Jul 2006 11:30:31 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A13014782D0@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE:Comments(RE:[speermint]requirementsdraftsubmitted)) Thread-Index: AcahMfkFFZB/JB91TXi8XgZawYJwlwAANzYgAAB293AAAVijYAAAjT1AAAG5SCAAWg870A== From: "Khan, Sohel Q [CTO]" To: "McCandless, Kevin" , , , "Andrew Newton" X-OriginalArrivalTime: 08 Jul 2006 16:30:36.0985 (UTC) FILETIME=[D7C66A90:01C6A2AB] X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 =20 -----Original Message----- From: McCandless, Kevin [mailto:KMcCandless@verisign.com]=20 Sent: Thursday, July 06, 2006 4:31 PM To: timothy.dwight@verizon.com; richard@shockey.us; Andrew Newton Cc: speermint@ietf.org Subject: RE: TLS for peering (was RE:Comments(RE:[speermint]requirementsdraftsubmitted)) GSM association is a good example. How federation evolve from here remains to be seen. But I do have to agree with Andy that bilateral agreements will define a new member into a federation and that will include financial and technical expectations. =20 We would want to keep financial agreement issues outside SPEERMINT. Operation Function (OF) may perform parameter and data exchange of the billing, charging, accounting. _______________________________________________ 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 Sun Jul 09 17:53:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzhDD-0004J5-VL; Sun, 09 Jul 2006 17:53:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzhDD-0004J0-Ig for speermint@ietf.org; Sun, 09 Jul 2006 17:53:11 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzhDC-00077j-Ct for speermint@ietf.org; Sun, 09 Jul 2006 17:53:11 -0400 Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.22082141; Sun, 09 Jul 2006 17:52:46 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Jul 2006 17:52:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 9 Jul 2006 17:52:45 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF361@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEW Montreal Session Time/Date Thread-Index: AcajogMls+qDTjioTm+tBHxv+Aktxg== From: "Livingood, Jason" To: X-OriginalArrivalTime: 09 Jul 2006 21:52:46.0374 (UTC) FILETIME=[0366DC60:01C6A3A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Speermint] NEW Montreal Session Time/Date 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="===============0044891991==" Errors-To: speermint-bounces@ietf.org --===============0044891991== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBvbiBhIGJsYWNrYmVycnkgc28gbm90IHN1cmUgaWYgRGF2ZSBwb3N0ZWQgdGhpcyB5ZXQg b3Igbm90LiBJZiBub3QsIHdlIGhhdmUgYmVlbiByZXNjaGVkdWxlZCB0byBhIGRpZmZlcmVudCBk YXkgYW5kIG91ciBzZXNzaW9uIGxlbmd0aCBoYXMgYmVlbiByZWR1Y2VkLiANCg0KTkVXIElORk86 DQpUdWVzZGF5LCBBZnRlcm5vb24gU2Vzc2lvbiBJSUkgMTc0MC0xODQwDQpSb29tIE5hbWU6IFJv b20gNTE4QUINCg0KV2Ugd2lsbCB3b3JrIHRvIGdldCBhIHJldmlzZWQgYWdlbmRhIG91dCBNb25k YXkuIFdlIGFwb2xvZ2l6ZSBmb3IgdGhpcywgaXQgd2FzIG91dCBvZiBvdXIgY29udHJvbC4gQXMg YSByZXN1bHQgb2Ygc2hvcnRlbmluZyBvdXIgc2Vzc2lvbiB3ZSB3aWxsIGhhdmUgdG8gZHJvcCBz ZXZlcmFsIHByZXNlbnRlcnMuIEhvd2V2ZXIsIGl0IGlzIG5vdyBjbGVhciB3ZSB3aWxsIGxpa2Vs eSBuZWVkIHRvIGRpc2N1c3MgYW4gaW50ZXJpbSBtZWV0aW5nIGZvciB0aGUgV0cgaW4gU2VwdGVt YmVyLiANCg0KVGhhbmtzDQpKYXNvbg0KVGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMg dG8gaXQgbWF5IGNvbnRhaW4gcHJvcHJpZXRhcnkgYW5kIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlv biBleGNsdXNpdmVseSBmb3IgaW50ZW5kZWQgcmVjaXBpZW50cy4gUGxlYXNlIGRvIG5vdCBmb3J3 YXJkIG9yIGRpc3RyaWJ1dGUgdG8gYW55b25lIGVsc2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwg Y29waWVzIG9mIHRoaXMgZS1tYWlsIGZyb20geW91ciBzeXN0ZW0uICANCg== --===============0044891991== 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 --===============0044891991==-- From speermint-bounces@ietf.org Sun Jul 09 18:54:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FziAv-0008EU-9n; Sun, 09 Jul 2006 18:54:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FziAu-0008EK-6A for Speermint@ietf.org; Sun, 09 Jul 2006 18:54:52 -0400 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 1FziAr-0002h1-Uu for Speermint@ietf.org; Sun, 09 Jul 2006 18:54:52 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 957F53944; Sun, 9 Jul 2006 18:54:49 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Jul 2006 18:54:49 -0400 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] NEW Montreal Session Time/Date Date: Sun, 9 Jul 2006 18:54:46 -0400 Message-ID: In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF361@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NEW Montreal Session Time/Date Thread-Index: AcajogMls+qDTjioTm+tBHxv+AktxgACFK6g From: "Uzelac, Adam" To: "Livingood, Jason" , X-OriginalArrivalTime: 09 Jul 2006 22:54:49.0447 (UTC) FILETIME=[AE86B770:01C6A3AA] X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Jason, >From the IETF Announcement List was the following - I point out only because the times you indicate are slightly different - specifically the end time. "SPEERMINT has been changed from Monday, July 10 at 1300-1500 to Tuesday, July 11 at 1740-1950 in Room 518AB." =20 Adam -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Sunday, July 09, 2006 5:53 PM To: Speermint@ietf.org Subject: [Speermint] NEW Montreal Session Time/Date I am on a blackberry so not sure if Dave posted this yet or not. If not, we have been rescheduled to a different day and our session length has been reduced.=20 NEW INFO: Tuesday, Afternoon Session III 1740-1840 Room Name: Room 518AB We will work to get a revised agenda out Monday. We apologize for this, it was out of our control. As a result of shortening our session we will have to drop several presenters. However, it is now clear we will likely need to discuss an interim meeting for the WG in September.=20 Thanks Jason This message and any attachments to it may contain proprietary and confidential information exclusively for intended recipients. Please do not forward or distribute to anyone else. If you are not the intended recipient, please contact the sender and delete all copies of this e-mail from your system. =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Jul 09 21:41:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzkll-0006mp-A9; Sun, 09 Jul 2006 21:41:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzklk-0006mk-3F for speermint@ietf.org; Sun, 09 Jul 2006 21:41:04 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzkli-0007vk-Qz for speermint@ietf.org; Sun, 09 Jul 2006 21:41:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] NEW Montreal Session Time/Date Date: Sun, 9 Jul 2006 21:40:12 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF364@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NEW Montreal Session Time/Date Thread-Index: AcajogMls+qDTjioTm+tBHxv+AktxgACFK6gAAWpw0A= From: "Livingood, Jason" To: "Uzelac, Adam" , X-OriginalArrivalTime: 10 Jul 2006 01:40:50.0271 (UTC) FILETIME=[DFA3D6F0:01C6A3C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 I have just noticed this as well and have emailed the agenda folks for clarification. What I forwarded was an automated message from the IETF meeting scheduling tool, so perhaps we've just been given 2, 1-hr sessions (appears likely). If this is the case, it would be good as it means we needn't reduce the agenda. Sorry for the continued confusion... Jason > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 > Sent: Sunday, July 09, 2006 6:55 PM > To: Livingood, Jason; Speermint@ietf.org > Subject: RE: [Speermint] NEW Montreal Session Time/Date >=20 > Jason, >=20 > From the IETF Announcement List was the following - I point=20 > out only because the times you indicate are slightly=20 > different - specifically the end time. >=20 > "SPEERMINT has been changed from Monday, July 10 at 1300-1500=20 > to Tuesday, July 11 at 1740-1950 in Room 518AB." > =20 > Adam >=20 >=20 > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Sunday, July 09, 2006 5:53 PM > To: Speermint@ietf.org > Subject: [Speermint] NEW Montreal Session Time/Date >=20 > I am on a blackberry so not sure if Dave posted this yet or=20 > not. If not, we have been rescheduled to a different day and=20 > our session length has been reduced.=20 >=20 > NEW INFO: > Tuesday, Afternoon Session III 1740-1840 Room Name: Room 518AB >=20 > We will work to get a revised agenda out Monday. We apologize=20 > for this, it was out of our control. As a result of=20 > shortening our session we will have to drop several=20 > presenters. However, it is now clear we will likely need to=20 > discuss an interim meeting for the WG in September.=20 >=20 > Thanks > Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Jul 09 22:39:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzlgb-0004YO-Cg; Sun, 09 Jul 2006 22:39:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzlga-0004YI-5V for Speermint@ietf.org; Sun, 09 Jul 2006 22:39:48 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FzlgX-0005qU-Ll for Speermint@ietf.org; Sun, 09 Jul 2006 22:39:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] NEW Montreal Session Time/Date Date: Mon, 10 Jul 2006 04:42:55 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B09@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NEW Montreal Session Time/Date Thread-Index: AcajogMls+qDTjioTm+tBHxv+AktxgACFK6gAAWpw0AAAmPXrQ== References: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF364@PACDCEXCMB03.cable.comcast.com> From: "Stastny Richard" To: "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 The new date clashes with ECRIT =20 Who had this nice idea? =20 Richard ________________________________ Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Gesendet: Mo 10.07.2006 03:40 An: Uzelac, Adam; Speermint@ietf.org Betreff: RE: [Speermint] NEW Montreal Session Time/Date I have just noticed this as well and have emailed the agenda folks for clarification. What I forwarded was an automated message from the IETF meeting scheduling tool, so perhaps we've just been given 2, 1-hr sessions (appears likely). If this is the case, it would be good as it means we needn't reduce the agenda. Sorry for the continued confusion... Jason > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Sunday, July 09, 2006 6:55 PM > To: Livingood, Jason; Speermint@ietf.org > Subject: RE: [Speermint] NEW Montreal Session Time/Date > > Jason, > > From the IETF Announcement List was the following - I point > out only because the times you indicate are slightly > different - specifically the end time. > > "SPEERMINT has been changed from Monday, July 10 at 1300-1500 > to Tuesday, July 11 at 1740-1950 in Room 518AB." >=20 > Adam > > > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Sunday, July 09, 2006 5:53 PM > To: Speermint@ietf.org > Subject: [Speermint] NEW Montreal Session Time/Date > > I am on a blackberry so not sure if Dave posted this yet or > not. If not, we have been rescheduled to a different day and > our session length has been reduced. > > NEW INFO: > Tuesday, Afternoon Session III 1740-1840 Room Name: Room 518AB > > We will work to get a revised agenda out Monday. We apologize > for this, it was out of our control. As a result of > shortening our session we will have to drop several > presenters. However, it is now clear we will likely need to > discuss an interim meeting for the WG in September. > > Thanks > Jason _______________________________________________ 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 Mon Jul 10 08:04:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzuV9-0002nf-Tu; Mon, 10 Jul 2006 08:04:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzuV8-0002gz-R5 for Speermint@ietf.org; Mon, 10 Jul 2006 08:04:34 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzuV7-00017q-FS for Speermint@ietf.org; Mon, 10 Jul 2006 08:04:34 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k6AC4WnN019704; Mon, 10 Jul 2006 05:04:32 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k6AC4RTb019703; Mon, 10 Jul 2006 05:04:27 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 10 Jul 2006 05:04:27 -0700 From: David Meyer To: Stastny Richard Subject: Re: [Speermint] NEW Montreal Session Time/Date Message-ID: <20060710120427.GA19687@1-4-5.net> References: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF364@PACDCEXCMB03.cable.comcast.com> <32755D354E6B65498C3BD9FD496C7D462C4B09@oefeg-s04.oefeg.loc> Mime-Version: 1.0 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B09@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Speermint@ietf.org, "Livingood, Jason" 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="===============0468581489==" Errors-To: speermint-bounces@ietf.org --===============0468581489== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 10, 2006 at 04:42:55AM +0200, Stastny Richard wrote: > The new date clashes with ECRIT > =20 > Who had this nice idea? lesser of n evils, I'm afraid. --dmm --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEskJLORgD1qCZ2KcRAvs8AJ9417y8vXQSezwKZokozH+iu6OxSACdGdAp NZQzlhycooQoSblhQKOBH0E= =LeuN -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- --===============0468581489== 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 --===============0468581489==-- From speermint-bounces@ietf.org Mon Jul 10 08:17:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzuhw-0003P4-IS; Mon, 10 Jul 2006 08:17:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzuhv-0003Oz-Eg for speermint@ietf.org; Mon, 10 Jul 2006 08:17:47 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzuhu-0001aH-6i for speermint@ietf.org; Mon, 10 Jul 2006 08:17:47 -0400 Received: from ([10.20.9.172]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.22087747; Mon, 10 Jul 2006 08:17:27 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 08:17:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] NEW Montreal Session Time/Date Date: Mon, 10 Jul 2006 08:16:38 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF374@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NEW Montreal Session Time/Date Thread-Index: AcajogMls+qDTjioTm+tBHxv+AktxgACFK6gAAWpw0AAFmeowA== From: "Livingood, Jason" To: "Uzelac, Adam" , X-OriginalArrivalTime: 10 Jul 2006 12:17:26.0947 (UTC) FILETIME=[CEA20F30:01C6A41A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 1740 - 1950 is confirmed, so we won't have to reduce the agenda. Jason=20 > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Sunday, July 09, 2006 9:40 PM > To: Uzelac, Adam; Speermint@ietf.org > Subject: RE: [Speermint] NEW Montreal Session Time/Date >=20 > I have just noticed this as well and have emailed the agenda=20 > folks for clarification. What I forwarded was an automated=20 > message from the IETF meeting scheduling tool, so perhaps=20 > we've just been given 2, 1-hr sessions (appears likely). If=20 > this is the case, it would be good as it means we needn't=20 > reduce the agenda. >=20 > Sorry for the continued confusion... >=20 > Jason >=20 > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Sunday, July 09, 2006 6:55 PM > > To: Livingood, Jason; Speermint@ietf.org > > Subject: RE: [Speermint] NEW Montreal Session Time/Date > >=20 > > Jason, > >=20 > > From the IETF Announcement List was the following - I point=20 > out only=20 > > because the times you indicate are slightly different -=20 > specifically=20 > > the end time. > >=20 > > "SPEERMINT has been changed from Monday, July 10 at 1300-1500 to=20 > > Tuesday, July 11 at 1740-1950 in Room 518AB." > > =20 > > Adam > >=20 > >=20 > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Sunday, July 09, 2006 5:53 PM > > To: Speermint@ietf.org > > Subject: [Speermint] NEW Montreal Session Time/Date > >=20 > > I am on a blackberry so not sure if Dave posted this yet or not. If=20 > > not, we have been rescheduled to a different day and our session=20 > > length has been reduced. > >=20 > > NEW INFO: > > Tuesday, Afternoon Session III 1740-1840 Room Name: Room 518AB > >=20 > > We will work to get a revised agenda out Monday. We apologize for=20 > > this, it was out of our control. As a result of shortening=20 > our session=20 > > we will have to drop several presenters. However, it is now=20 > clear we=20 > > will likely need to discuss an interim meeting for the WG in=20 > > September. > >=20 > > Thanks > > Jason >=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 Mon Jul 10 08:29:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzutF-0008To-0V; Mon, 10 Jul 2006 08:29:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzutD-0008Tb-6k for speermint@ietf.org; Mon, 10 Jul 2006 08:29:27 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzutC-0001vJ-0M for speermint@ietf.org; Mon, 10 Jul 2006 08:29:27 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k6ACTHO0019428; Mon, 10 Jul 2006 07:29:17 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ9VYJP>; Mon, 10 Jul 2006 13:29:16 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB01369D7BF@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: dmm@1-4-5.net Date: Mon, 10 Jul 2006 13:29:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: speermint@ietf.org Subject: [Speermint] Minor comments on draft-meyer-speermint-reqs-and-terminology-00.t xt 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 doing a quick read of this document, I noted a couple of things. 1) Usage of term "E.164 number". Recommendation E.164 defines the term "public telecommunication number". In most of the cases it does not look like this needs to be categorised as an "international public telecommunication number", but at least to do ENUM lookup I understood it needed to be. 2) In the references, you are referencing the 1991 version of E.164. Current in force version is February 1995, but in general this seems to be a prime case for an undated reference (i.e. latest version applies). 3) Introduction, 3rd para has a residual reference to "VOIPEER", as does section 2, 1st para, and figure 1, and the para immediately following it, and section 4.4, section 5.4. Not sure whether section 7 should change or not. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 10 08:41:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzv4o-0004du-BT; Mon, 10 Jul 2006 08:41:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzv4n-0004ce-KS for speermint@ietf.org; Mon, 10 Jul 2006 08:41:25 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzv4m-0002dz-8p for speermint@ietf.org; Mon, 10 Jul 2006 08:41:25 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k6ACfNYH021118; Mon, 10 Jul 2006 05:41:23 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k6ACfJh1021117; Mon, 10 Jul 2006 05:41:19 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 10 Jul 2006 05:41:19 -0700 From: David Meyer To: "Drage, Keith (Keith)" Message-ID: <20060710124119.GA21096@1-4-5.net> References: <475FF955A05DD411980D00508B6D5FB01369D7BF@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 In-Reply-To: <475FF955A05DD411980D00508B6D5FB01369D7BF@en0033exch001u.uk.lucent.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: speermint@ietf.org Subject: [Speermint] Re: Minor comments on draft-meyer-speermint-reqs-and-terminology-00.t xt 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="===============1878476444==" Errors-To: speermint-bounces@ietf.org --===============1878476444== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Keith, First, thanks for reviewing. However, the WG decided (wisely, IMO) to split the terminology and requirements into (at least) two documents. The current terminology document is draft-ietf-speermint-terminology-00.txt. I'll do the merge of your comments against that document for the next rev. Thnx, --dmm =09 On Mon, Jul 10, 2006 at 01:29:14PM +0100, Drage, Keith (Keith) wrote: > In doing a quick read of this document, I noted a couple of things. >=20 > 1) Usage of term "E.164 number". Recommendation E.164 defines the term "p= ublic telecommunication number". In most of the cases it does not look like= this needs to be categorised as an "international public telecommunication= number", but at least to do ENUM lookup I understood it needed to be. >=20 > 2) In the references, you are referencing the 1991 version of E.164. Curr= ent in force version is February 1995, but in general this seems to be a pr= ime case for an undated reference (i.e. latest version applies). >=20 > 3) Introduction, 3rd para has a residual reference to "VOIPEER", as does = section 2, 1st para, and figure 1, and the para immediately following it, a= nd section 4.4, section 5.4. Not sure whether section 7 should change or no= t. >=20 > regards >=20 > Keith >=20 > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 --zhXaljGHf11kAtnf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEskrvORgD1qCZ2KcRAnfwAKCDVAGCulnYQ01QFpCp/X8GjG9oRQCeK8bx XODYMhoDiV9CrXTuCaFuk4U= =mAzb -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- --===============1878476444== 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 --===============1878476444==-- From speermint-bounces@ietf.org Mon Jul 10 16:38:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02Wp-0003X4-Sm; Mon, 10 Jul 2006 16:38:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02Wo-0003Wl-TR for speermint@ietf.org; Mon, 10 Jul 2006 16:38:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzvkj-00041p-88 for speermint@ietf.org; Mon, 10 Jul 2006 09:24:45 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fzvd9-0000XW-DT for speermint@ietf.org; Mon, 10 Jul 2006 09:16:57 -0400 Received: from ([10.20.62.12]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.22089703; Mon, 10 Jul 2006 09:16:35 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 09:16:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Minor comments ondraft-meyer-speermint-reqs-and-terminology-00.t xt Date: Mon, 10 Jul 2006 09:15:00 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF377@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Minor comments ondraft-meyer-speermint-reqs-and-terminology-00.t xt Thread-Index: AcakHIs0Aux7r2w3SkKcQG7FQ2Ka7QABh5ZQ From: "Livingood, Jason" To: "Drage, Keith \(Keith\)" , X-OriginalArrivalTime: 10 Jul 2006 13:16:34.0969 (UTC) FILETIME=[116B4090:01C6A423] X-Spam-Score: -2.6 (--) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 That draft has been superceded by this one (and the old one is dead): http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-00. txt We split the requirements out of the draft you referenced and moved it to a new doc: http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-00 .txt Please review these docs and advise if your comments have been addressed or still remain. Jason=20 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 > Sent: Monday, July 10, 2006 8:29 AM > To: dmm@1-4-5.net > Cc: speermint@ietf.org > Subject: [Speermint] Minor comments=20 > ondraft-meyer-speermint-reqs-and-terminology-00.t xt >=20 > In doing a quick read of this document, I noted a couple of things. >=20 > 1) Usage of term "E.164 number". Recommendation E.164=20 > defines the term "public telecommunication number". In most=20 > of the cases it does not look like this needs to be=20 > categorised as an "international public telecommunication=20 > number", but at least to do ENUM lookup I understood it needed to be. >=20 > 2) In the references, you are referencing the 1991 version=20 > of E.164. Current in force version is February 1995, but in=20 > general this seems to be a prime case for an undated=20 > reference (i.e. latest version applies). >=20 > 3) Introduction, 3rd para has a residual reference to=20 > "VOIPEER", as does section 2, 1st para, and figure 1, and the=20 > para immediately following it, and section 4.4, section 5.4.=20 > Not sure whether section 7 should change or not. >=20 > regards >=20 > Keith >=20 > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 >=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 Tue Jul 11 09:47:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0IZp-0003q5-NY; Tue, 11 Jul 2006 09:47:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0IZo-0003q0-1L for speermint@ietf.org; Tue, 11 Jul 2006 09:47:00 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0IZm-0008Gq-H6 for speermint@ietf.org; Tue, 11 Jul 2006 09:47:00 -0400 Received: from ([10.20.62.12]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.22236551; Tue, 11 Jul 2006 09:44:20 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Jul 2006 09:46:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Jul 2006 09:46:01 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF3B8@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [wg-business] Possible Interim Meeting in September? Thread-Index: Acak7z1zjZP3NKfcThuBTi04JLYoqQ== From: "Livingood, Jason" To: X-OriginalArrivalTime: 11 Jul 2006 13:46:02.0009 (UTC) FILETIME=[5911E890:01C6A4F0] X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [Speermint] [wg-business] Possible Interim Meeting in September? 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="===============2072779220==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============2072779220== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A4F0.5880DE80" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A4F0.5880DE80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There has been some discussion about holding an interim meeting before the next IETF. We'll work on a proposed agenda later, but the general idea was to accelerate some of our technical discussions and deliverables work in a smaller, highly-focused, f2f environment. We're thinking that August should be avoided due to vacations in Europe, as well as the first week or so of September due to returning from said vacations. =20 So, I'd like to suggest the possibility of September 18 - 20 (meeting would likely be two days). The location would likely be in the US (the next interim would presumably move to Europe or Canada to accomodate all participants).=20 =20 Is anyone aware of potential meeting conflicts with these dates? If so, what are they?=20 =20 Thanks Jason ------_=_NextPart_001_01C6A4F0.5880DE80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There = has been some=20 discussion about holding an interim meeting before the next IETF.  = We'll=20 work on a proposed agenda later, but the general idea was to accelerate = some of=20 our technical discussions and deliverables work in a smaller, = highly-focused,=20 f2f environment.  We're thinking that August should be avoided due = to=20 vacations in Europe, as well as the first week or so of September due to = returning from said vacations.
 
So, = I'd like to=20 suggest the possibility of September 18 - 20 (meeting would likely be = two=20 days).  The location would likely be in the US (the next interim = would=20 presumably move to Europe or Canada to accomodate all=20 participants). 
 
Is = anyone aware of=20 potential meeting conflicts with these dates?  If so, what are=20 they? 
 
Thanks
Jason
------_=_NextPart_001_01C6A4F0.5880DE80-- --===============2072779220== 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 --===============2072779220==-- From speermint-bounces@ietf.org Wed Jul 12 12:41:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hls-0003xh-76; Wed, 12 Jul 2006 12:41:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hlq-0003xc-HH for speermint@ietf.org; Wed, 12 Jul 2006 12:41:06 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0hlp-0005TT-3f for speermint@ietf.org; Wed, 12 Jul 2006 12:41:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jul 2006 18:40:10 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B15@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Terminology draft - RFC3263 out of scope? Thread-Index: Acak7z1zjZP3NKfcThuBTi04JLYoqQA32r8N References: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF3B8@PACDCEXCMB03.cable.comcast.com> From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Speermint] Terminology draft - RFC3263 out of scope? 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 draft-ietf-speermint-terminology-00 in section 2 Speermint context, = the last sentence on page 3 states the following: =20 "Finally, note that the subsequent lookup steps described in RFC 3263 [RFC3263] used to find the next- hop SIP server from this URI are outside the scope of SPEERMINT." =20 OTOH, in the milestones list presented yesterday it is stated: =20 "Jan 2007 Submit I-D on the use of DNS SRV and NAPTR records as = specified by RFC 3263." =20 So we are doing an I-D explaing out of scope issues? IMO the sentence has to be deleted. =20 This also raises some issues with Figure 1: =20 Figure 1 on top of page 4 defines the upper boundary of the speermint scope against ENUM, but not the lower boundary According to the above sentence it must be just below SIP URI and above Service location lookup =20 IMHO the boundary is sharp below session establishment (keeping in mind that you need out-of-scope actions like A and AAAA IP Address and Mac-address first before you establish a session) =20 There is also an issue with=20 <--- Service location (lookup of SRV in DNS) =20 we either take this a e.g Service Location or we elaborate more =20 Federation detection and policy lookup Service Location (NAPTR and SRV) etc =20 And one other nit: =20 in section 3.4 Network insead of: "For purposes of this document and the SPEERMINT and ENUM Working Groups, a network is defined to be the set of SIP servers and end- users (customers) that are controlled by a single administrative domain. The network may also contain end-users who are located on the PSTN." it should be made more clearly: =20 For purposes of this document and the SPEERMINT and ENUM Working Groups, a network is defined to be the set of SIP servers and end- users (customers) that are controlled by a single administrative domain and can be reached via IP-peering. The network may also = contain end-users=20 who are located on the PSTN, as long as they are also reachable via = IP-peering. =20 =20 regards =20 Richard =20 =20 =20 =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jul 12 12:59:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0i3m-00063Y-1T; Wed, 12 Jul 2006 12:59:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0i3l-00063T-Ag for speermint@ietf.org; Wed, 12 Jul 2006 12:59:37 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0i3i-0006MT-T1 for speermint@ietf.org; Wed, 12 Jul 2006 12:59:37 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k6CGxY4i009295; Wed, 12 Jul 2006 09:59:34 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k6CGxYkp009294; Wed, 12 Jul 2006 09:59:34 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 12 Jul 2006 09:59:34 -0700 From: David Meyer To: Stastny Richard Subject: Re: [Speermint] Terminology draft - RFC3263 out of scope? Message-ID: <20060712165934.GA9273@1-4-5.net> References: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF3B8@PACDCEXCMB03.cable.comcast.com> <32755D354E6B65498C3BD9FD496C7D462C4B15@oefeg-s04.oefeg.loc> Mime-Version: 1.0 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B15@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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: , Content-Type: multipart/mixed; boundary="===============0680775719==" Errors-To: speermint-bounces@ietf.org --===============0680775719== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Richard, Thanks for the comments. I'll include in the next update. --dm On Wed, Jul 12, 2006 at 06:40:10PM +0200, Stastny Richard wrote: > In draft-ietf-speermint-terminology-00 in section 2 Speermint context, th= e last sentence > on page 3 states the following: > =20 > "Finally, note that the subsequent > lookup steps described in RFC 3263 [RFC3263] used to find the next- > hop SIP server from this URI are outside the scope of SPEERMINT." > =20 > OTOH, in the milestones list presented yesterday it is stated: > =20 > "Jan 2007 Submit I-D on the use of DNS SRV and NAPTR records as specified > by RFC 3263." > =20 > So we are doing an I-D explaing out of scope issues? >=20 > IMO the sentence has to be deleted. > =20 > This also raises some issues with Figure 1: > =20 > Figure 1 on top of page 4 defines the upper boundary of the speermint > scope against ENUM, but not the lower boundary >=20 > According to the above sentence it must be just below SIP URI > and above Service location lookup > =20 > IMHO the boundary is sharp below session establishment > (keeping in mind that you need out-of-scope actions like A and AAAA > IP Address and Mac-address first before you establish a session) > =20 > There is also an issue with=20 > <--- Service location (lookup of SRV in DNS) > =20 > we either take this a e.g Service Location > or > we elaborate more > =20 > Federation detection and policy lookup > Service Location (NAPTR and SRV) > etc > =20 > And one other nit: > =20 > in section 3.4 Network >=20 > insead of: > "For purposes of this document and the SPEERMINT and ENUM Working > Groups, a network is defined to be the set of SIP servers and end- > users (customers) that are controlled by a single administrative > domain. The network may also contain end-users who are located on > the PSTN." >=20 > it should be made more clearly: > =20 > For purposes of this document and the SPEERMINT and ENUM Working > Groups, a network is defined to be the set of SIP servers and end- > users (customers) that are controlled by a single administrative > domain and can be reached via IP-peering. The network may also contai= n end-users=20 > who are located on the PSTN, as long as they are also reachable via IP-= peering. > =20 > =20 > regards > =20 > Richard > =20 > =20 > =20 > =20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEtSp2ORgD1qCZ2KcRAqylAJ0Y6r4k47QvaSykBLuMeS2Yr0ESGgCgkwe9 jPCZ6828IgZNImi5TdY/fJk= =wctq -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- --===============0680775719== 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 --===============0680775719==-- From speermint-bounces@ietf.org Wed Jul 12 14:45:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jhv-0001yc-Sa; Wed, 12 Jul 2006 14:45:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jhu-0001yS-3c for Speermint@ietf.org; Wed, 12 Jul 2006 14:45:10 -0400 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 1G0jhr-0003b5-SN for Speermint@ietf.org; Wed, 12 Jul 2006 14:45:10 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id A87814122 for ; Wed, 12 Jul 2006 14:44:24 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 14:44:23 -0400 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: Wed, 12 Jul 2006 14:44:21 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3g== From: "Uzelac, Adam" To: X-OriginalArrivalTime: 12 Jul 2006 18:44:23.0494 (UTC) FILETIME=[31997E60:01C6A5E3] X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Speermint] TLS, etc - Local-policy versus WG mandate 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 Pertaining to the "To TLS or not TLS" discussion in the WG sessions, time didn't permit a proper tomato tossing session at the WG session - but one comment was made about mandating such things as TLS, etc - to which a rebuttal was made that the type of authentication and authorization used and implemented is an issue of local policy and therefore shouldn't be mandated. =20 For fear of starting a "great taste" versus "less filling" argument - Let me start this way....I agree with what appeared to be consensus in the WG session that there needs to be first a Discovery procedure, then an Authentication procedure, and finally connecting the call. The methods upon which each step along the way is done should not to so narrow as to exclude popular and in some cases widely adopted methods. Speermint should provide the BCP - but does that really need to exclude other plausible and practical models? It's important to note that I believe TLS is the most appropriate, practical and logical approach. I also believe the there are valid reasons for other approaches to authenticate. The same holds true for methods of discovery.=20 So the question for the group and possibly some guidance from the chairs here?!?!? - Should an undertaking to determine what should be determined via local policy versus mandated via 'MUSTs' be done? Is this a section for the requirements doc? I would like to thank Rohan for bringing this issue to the forefront in a lightning-rod manner!! ;) Regards, Adam _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jul 12 15:17:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kDQ-0006VH-75; Wed, 12 Jul 2006 15:17:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kDO-0006UT-Sy for Speermint@ietf.org; Wed, 12 Jul 2006 15:17:42 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0kDN-0004SV-EY for Speermint@ietf.org; Wed, 12 Jul 2006 15:17:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] TLS, etc - Local-policy versus WG mandate Date: Wed, 12 Jul 2006 21:12:26 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B17@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAA+xor References: From: "Stastny Richard" To: "Uzelac, Adam" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 >Speermint should provide the BCP - but does that really need to exclude >other plausible and practical models?=20 =20 BCP means best current practice - so if we say TLS IS the best current = practice does this prevent somebody not to use TLS? =20 OTOH, only one one method can be best - at least for now (current) =20 Richard ________________________________ Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Gesendet: Mi 12.07.2006 20:44 An: Speermint@ietf.org Betreff: [Speermint] TLS, etc - Local-policy versus WG mandate Pertaining to the "To TLS or not TLS" discussion in the WG sessions, time didn't permit a proper tomato tossing session at the WG session - but one comment was made about mandating such things as TLS, etc - to which a rebuttal was made that the type of authentication and authorization used and implemented is an issue of local policy and therefore shouldn't be mandated.=20 For fear of starting a "great taste" versus "less filling" argument - Let me start this way....I agree with what appeared to be consensus in the WG session that there needs to be first a Discovery procedure, then an Authentication procedure, and finally connecting the call. The methods upon which each step along the way is done should not to so narrow as to exclude popular and in some cases widely adopted methods. Speermint should provide the BCP - but does that really need to exclude other plausible and practical models? It's important to note that I believe TLS is the most appropriate, practical and logical approach. I also believe the there are valid reasons for other approaches to authenticate. The same holds true for methods of discovery. So the question for the group and possibly some guidance from the chairs here?!?!? - Should an undertaking to determine what should be determined via local policy versus mandated via 'MUSTs' be done? Is this a section for the requirements doc? I would like to thank Rohan for bringing this issue to the forefront in a lightning-rod manner!! ;) Regards, Adam _______________________________________________ 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 Jul 12 15:22:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kI6-0007Bc-6e; Wed, 12 Jul 2006 15:22:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kI4-0007BL-Jj for Speermint@ietf.org; Wed, 12 Jul 2006 15:22:32 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0kI3-0008Ts-9n for Speermint@ietf.org; Wed, 12 Jul 2006 15:22:32 -0400 Received: from [132.219.28.188] (helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G0kHu-0002Be-Ve; Wed, 12 Jul 2006 14:22:23 -0500 From: "Brian Rosen" To: "'Uzelac, Adam'" , Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate Date: Wed, 12 Jul 2006 15:22:27 -0400 Message-ID: <007801c6a5e8$84865670$bc1cdb84@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAAdEHg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Due to the last minute schedule change, I was unable to attend the meeting, but perhaps we now have enough consensus to write down the answer. I think we use the methods we have used in most of the sippish specs: It's mandatory to IMPLEMENT TLS between peers (presumably peer proxies). It's mandatory to DEPLOY some kind of mutual authentication, which does not have to be TLS. I suspect that we want to actually say that the federation establishes a particular authentication standard that all members use. Brian -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Sent: Wednesday, July 12, 2006 2:44 PM To: Speermint@ietf.org Subject: [Speermint] TLS, etc - Local-policy versus WG mandate Pertaining to the "To TLS or not TLS" discussion in the WG sessions, time didn't permit a proper tomato tossing session at the WG session - but one comment was made about mandating such things as TLS, etc - to which a rebuttal was made that the type of authentication and authorization used and implemented is an issue of local policy and therefore shouldn't be mandated. For fear of starting a "great taste" versus "less filling" argument - Let me start this way....I agree with what appeared to be consensus in the WG session that there needs to be first a Discovery procedure, then an Authentication procedure, and finally connecting the call. The methods upon which each step along the way is done should not to so narrow as to exclude popular and in some cases widely adopted methods. Speermint should provide the BCP - but does that really need to exclude other plausible and practical models? It's important to note that I believe TLS is the most appropriate, practical and logical approach. I also believe the there are valid reasons for other approaches to authenticate. The same holds true for methods of discovery. So the question for the group and possibly some guidance from the chairs here?!?!? - Should an undertaking to determine what should be determined via local policy versus mandated via 'MUSTs' be done? Is this a section for the requirements doc? I would like to thank Rohan for bringing this issue to the forefront in a lightning-rod manner!! ;) Regards, Adam _______________________________________________ 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 Jul 12 16:42:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0lX1-0005P5-QB; Wed, 12 Jul 2006 16:42:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0lX0-0005OO-Sk for Speermint@ietf.org; Wed, 12 Jul 2006 16:42:02 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0lWy-0006MQ-A2 for Speermint@ietf.org; Wed, 12 Jul 2006 16:42:02 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 12 Jul 2006 16:41:59 -0400 X-IronPort-AV: i="4.06,236,1149480000"; d="scan'208"; a="92554160:sNHT26584614" 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.20060308/8.12.11) with ESMTP id k6CKg0IB017720; Wed, 12 Jul 2006 16:42:00 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6CKfxdU027719; Wed, 12 Jul 2006 16:41:59 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jul 2006 16:41:59 -0400 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] TLS, etc - Local-policy versus WG mandate Date: Wed, 12 Jul 2006 16:41:58 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301B360FA@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAAdEHgAAOBPbA= From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Uzelac, Adam" , X-OriginalArrivalTime: 12 Jul 2006 20:41:59.0754 (UTC) FILETIME=[9F7552A0:01C6A5F3] DKIM-Signature: a=rsa-sha1; q=dns; l=3608; t=1152736920; x=1153600920; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20TLS, =20etc=20-=20Local-policy=20versus=20WG=20mand ate |To:=22Brian=20Rosen=22=20, =0A=20=20=20=20=20=20=20=20=22 Uzelac, =20Adam=22=20, =20; X=v=3Dcisco.com=3B=20h=3D2VnnJdMEaY5C8ig4LBewTc6BmaE=3D; b=ZbxDdKYFOC+lFMDc5stkhWfy2/dvV+tuQlbXeE/9cOya7d71F6AjESx8fT5Z/EpkZO56+irE 6PZuLy8jeRyzAawDGeSdF3Y51fF/TVbW6PfrYcaagCsdZfKOyNURirFb; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 Please refresh my memory. =20 Was there going to be a separate document that addresses security on the peering interface? Or, is this to be a security section in each of the documents that peel the onion, starting with discovery, with perhaps the policy discovery layer of the onion saying that federations should establish security policy and here are the minimum requirements that such policies hopefully support, with other layers saying signaling/media follow the security policy, whatever that is? Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, July 12, 2006 3:22 PM > To: 'Uzelac, Adam'; Speermint@ietf.org > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 > Due to the last minute schedule change, I was unable to=20 > attend the meeting, but perhaps we now have enough consensus=20 > to write down the answer. >=20 > I think we use the methods we have used in most of the sippish specs: >=20 > It's mandatory to IMPLEMENT TLS between peers (presumably=20 > peer proxies). > It's mandatory to DEPLOY some kind of mutual authentication,=20 > which does not have to be TLS. =20 >=20 > I suspect that we want to actually say that the federation=20 > establishes a particular authentication standard that all members use. >=20 > Brian >=20 >=20 >=20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, July 12, 2006 2:44 PM > To: Speermint@ietf.org > Subject: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 > Pertaining to the "To TLS or not TLS" discussion in the WG=20 > sessions, time didn't permit a proper tomato tossing session=20 > at the WG session - but one comment was made about mandating=20 > such things as TLS, etc - to which a rebuttal was made that=20 > the type of authentication and authorization used and=20 > implemented is an issue of local policy and therefore=20 > shouldn't be mandated. =20 >=20 > For fear of starting a "great taste" versus "less filling"=20 > argument - Let me start this way....I agree with what=20 > appeared to be consensus in the WG session that there needs=20 > to be first a Discovery procedure, then an Authentication=20 > procedure, and finally connecting the call. The methods upon=20 > which each step along the way is done should not to so narrow=20 > as to exclude popular and in some cases widely adopted methods. > Speermint should provide the BCP - but does that really need=20 > to exclude other plausible and practical models? It's=20 > important to note that I believe TLS is the most appropriate,=20 > practical and logical approach. I also believe the there are=20 > valid reasons for other approaches to authenticate. The same=20 > holds true for methods of discovery.=20 >=20 > So the question for the group and possibly some guidance from=20 > the chairs here?!?!? - Should an undertaking to determine=20 > what should be determined via local policy versus mandated=20 > via 'MUSTs' be done? Is this a section for the requirements doc? >=20 > I would like to thank Rohan for bringing this issue to the=20 > forefront in a lightning-rod manner!! ;) >=20 > Regards, >=20 > Adam >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=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 Wed Jul 12 16:53:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0liD-0008Jd-Li; Wed, 12 Jul 2006 16:53:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0liD-0008JY-6s for Speermint@ietf.org; Wed, 12 Jul 2006 16:53:37 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0liB-0000jV-RM for Speermint@ietf.org; Wed, 12 Jul 2006 16:53:37 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 12 Jul 2006 13:53:35 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="562142283:sNHT33149244" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate Date: Wed, 12 Jul 2006 16:53:31 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804DA9AAD@proton.jnpr.net> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301B360FA@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAAdEHgAAOBPbAAAHj2wA== From: "Reinaldo Penno" To: "Michael Hammer \(mhammer\)" , "Brian Rosen" , "Uzelac, Adam" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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 I still fell that would be (very) helpful independent of TLS vs. IPSec vs. Access Lists, etc, etc. Many WGs have something like it. We need a draft with the threats/attacks and possibly how the (3?) proposed security methods deal with them. Regards, Reinaldo=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, July 12, 2006 1:42 PM > To: Brian Rosen; Uzelac, Adam; Speermint@ietf.org > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 > Please refresh my memory. >=20 > Was there going to be a separate document that addresses security on the > peering interface? >=20 > Or, is this to be a security section in each of the documents that peel > the onion, starting with discovery, with perhaps the policy discovery > layer of the onion saying that federations should establish security > policy and here are the minimum requirements that such policies > hopefully support, with other layers saying signaling/media follow the > security policy, whatever that is? >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, July 12, 2006 3:22 PM > > To: 'Uzelac, Adam'; Speermint@ietf.org > > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate > > > > Due to the last minute schedule change, I was unable to > > attend the meeting, but perhaps we now have enough consensus > > to write down the answer. > > > > I think we use the methods we have used in most of the sippish specs: > > > > It's mandatory to IMPLEMENT TLS between peers (presumably > > peer proxies). > > It's mandatory to DEPLOY some kind of mutual authentication, > > which does not have to be TLS. > > > > I suspect that we want to actually say that the federation > > establishes a particular authentication standard that all members use. > > > > Brian > > > > > > > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Wednesday, July 12, 2006 2:44 PM > > To: Speermint@ietf.org > > Subject: [Speermint] TLS, etc - Local-policy versus WG mandate > > > > Pertaining to the "To TLS or not TLS" discussion in the WG > > sessions, time didn't permit a proper tomato tossing session > > at the WG session - but one comment was made about mandating > > such things as TLS, etc - to which a rebuttal was made that > > the type of authentication and authorization used and > > implemented is an issue of local policy and therefore > > shouldn't be mandated. > > > > For fear of starting a "great taste" versus "less filling" > > argument - Let me start this way....I agree with what > > appeared to be consensus in the WG session that there needs > > to be first a Discovery procedure, then an Authentication > > procedure, and finally connecting the call. The methods upon > > which each step along the way is done should not to so narrow > > as to exclude popular and in some cases widely adopted methods. > > Speermint should provide the BCP - but does that really need > > to exclude other plausible and practical models? It's > > important to note that I believe TLS is the most appropriate, > > practical and logical approach. I also believe the there are > > valid reasons for other approaches to authenticate. The same > > holds true for methods of discovery. > > > > So the question for the group and possibly some guidance from > > the chairs here?!?!? - Should an undertaking to determine > > what should be determined via local policy versus mandated > > via 'MUSTs' be done? Is this a section for the requirements doc? > > > > I would like to thank Rohan for bringing this issue to the > > forefront in a lightning-rod manner!! ;) > > > > Regards, > > > > Adam > > > > _______________________________________________ > > 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 > > >=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 Wed Jul 12 16:56:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ll0-0000Jd-1K; Wed, 12 Jul 2006 16:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0lkz-0000JN-6u for Speermint@ietf.org; Wed, 12 Jul 2006 16:56:29 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0lkx-0001L0-VV for Speermint@ietf.org; Wed, 12 Jul 2006 16:56:29 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 12 Jul 2006 13:56:27 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="562143006:sNHT26617924" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jul 2006 16:56:19 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804DA9AB0@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Policy and others Thread-Index: Acal9Z/JDlVxzBSMSV2f9cyOAiKgHA== From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Speermint] Policy and others 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 think that Dave Schwartz idea of a framework policy should not be dismissed so categorically. Although I agree that this is not the high priority right now, I think this topic should get its day under the sun and be presented at some point. I would suggest Dave put a uses cases/policy framework draft to that we can provide feedback on it.=20 Regards, Reinaldo _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jul 12 17:26:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0mEQ-00045o-Vy; Wed, 12 Jul 2006 17:26:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0mEP-00044P-Ca for speermint@ietf.org; Wed, 12 Jul 2006 17:26:53 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0mEO-0005Az-5w for speermint@ietf.org; Wed, 12 Jul 2006 17:26:53 -0400 Received: from ([10.20.9.174]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.22194806; Wed, 12 Jul 2006 17:26:36 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 17:26:36 -0400 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] TLS, etc - Local-policy versus WG mandate Date: Wed, 12 Jul 2006 17:26:35 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF3EC@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAAdEHgAAOBPbAAAHj2wAABKcDg From: "Livingood, Jason" To: "Reinaldo Penno" , "Michael Hammer \(mhammer\)" , "Brian Rosen" , "Uzelac, Adam" , X-OriginalArrivalTime: 12 Jul 2006 21:26:36.0316 (UTC) FILETIME=[DAD045C0:01C6A5F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 > Many WGs have something like it. We need a draft with the=20 > threats/attacks and possibly how the (3?) proposed security=20 > methods deal with them. Yes, so first step is to define the possible threats/attacks as noted in the meeting. We had a volunteer afterwards who we're going to chat with to see if they can make a contribution on this. Then we can figure out, for each of the supposed threats/attacks, what the proposed methods are. So it's a two step process, which may take a bit more time but I think we'll end up with a better long-term result. So, we'll get the ball rolling on the first step soon... Thanks Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jul 12 19:48:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0oRK-0003VZ-Es; Wed, 12 Jul 2006 19:48:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0oRI-0003VN-QS for speermint@ietf.org; Wed, 12 Jul 2006 19:48:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0mWD-0006K3-Dl for speermint@ietf.org; Wed, 12 Jul 2006 17:45:17 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0mHP-0005q3-Bm for speermint@ietf.org; Wed, 12 Jul 2006 17:30:00 -0400 Received: from ([10.20.62.13]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.22301285; Wed, 12 Jul 2006 17:29:33 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 17:29:33 -0400 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] TLS, etc - Local-policy versus WG mandate Date: Wed, 12 Jul 2006 17:29:32 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF3EE@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAAdEHgAAVCxAA= From: "Livingood, Jason" To: "Brian Rosen" , "Uzelac, Adam" , X-OriginalArrivalTime: 12 Jul 2006 21:29:33.0638 (UTC) FILETIME=[44817660:01C6A5FA] X-Spam-Score: -2.6 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > I think we use the methods we have used in most of the sippish specs: >=20 > It's mandatory to IMPLEMENT TLS between peers (presumably=20 > peer proxies). > It's mandatory to DEPLOY some kind of mutual authentication,=20 > which does not have to be TLS. =20 Yes, I think that is a fair statement and one we noted in the session (sorry we missed having you there!). =20 Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jul 12 19:49:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0oRz-0003cY-5u; Wed, 12 Jul 2006 19:49:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0oRy-0003cA-7f for Speermint@ietf.org; Wed, 12 Jul 2006 19:49:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0mWd-0006Ky-Fm for Speermint@ietf.org; Wed, 12 Jul 2006 17:45:43 -0400 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 1G0lsl-0005Gd-Jt for Speermint@ietf.org; Wed, 12 Jul 2006 17:04:33 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 28FBB3FAA; Wed, 12 Jul 2006 17:04:25 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 17:04:24 -0400 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] TLS, etc - Local-policy versus WG mandate Date: Wed, 12 Jul 2006 17:04:23 -0400 Message-ID: In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301B360FA@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAAdEHgAAOBPbAAAIj2cA== From: "Uzelac, Adam" To: "Michael Hammer (mhammer)" , "Brian Rosen" , X-OriginalArrivalTime: 12 Jul 2006 21:04:24.0973 (UTC) FILETIME=[C14573D0:01C6A5F6] X-Spam-Score: -2.6 (--) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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 Mike, I am not sure about an agreed upon way to address security concerns, but there was a request from the WG chairs that a document specifying threats be compiled. Dan York from Mitel offered to participate leveraging his work from www.voipsa.org. Adam -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Wednesday, July 12, 2006 4:42 PM To: Brian Rosen; Uzelac, Adam; Speermint@ietf.org Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate Please refresh my memory. =20 Was there going to be a separate document that addresses security on the peering interface? Or, is this to be a security section in each of the documents that peel the onion, starting with discovery, with perhaps the policy discovery layer of the onion saying that federations should establish security policy and here are the minimum requirements that such policies hopefully support, with other layers saying signaling/media follow the security policy, whatever that is? Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, July 12, 2006 3:22 PM > To: 'Uzelac, Adam'; Speermint@ietf.org > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 > Due to the last minute schedule change, I was unable to attend the=20 > meeting, but perhaps we now have enough consensus to write down the=20 > answer. >=20 > I think we use the methods we have used in most of the sippish specs: >=20 > It's mandatory to IMPLEMENT TLS between peers (presumably peer=20 > proxies). > It's mandatory to DEPLOY some kind of mutual authentication, which=20 > does not have to be TLS. >=20 > I suspect that we want to actually say that the federation establishes > a particular authentication standard that all members use. >=20 > Brian >=20 >=20 >=20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, July 12, 2006 2:44 PM > To: Speermint@ietf.org > Subject: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 > Pertaining to the "To TLS or not TLS" discussion in the WG sessions,=20 > time didn't permit a proper tomato tossing session at the WG session - > but one comment was made about mandating such things as TLS, etc - to=20 > which a rebuttal was made that the type of authentication and=20 > authorization used and implemented is an issue of local policy and=20 > therefore shouldn't be mandated. >=20 > For fear of starting a "great taste" versus "less filling"=20 > argument - Let me start this way....I agree with what appeared to be=20 > consensus in the WG session that there needs to be first a Discovery=20 > procedure, then an Authentication procedure, and finally connecting=20 > the call. The methods upon which each step along the way is done=20 > should not to so narrow as to exclude popular and in some cases widely > adopted methods. > Speermint should provide the BCP - but does that really need to=20 > exclude other plausible and practical models? It's important to note=20 > that I believe TLS is the most appropriate, practical and logical=20 > approach. I also believe the there are valid reasons for other=20 > approaches to authenticate. The same holds true for methods of=20 > discovery. >=20 > So the question for the group and possibly some guidance from the=20 > chairs here?!?!? - Should an undertaking to determine what should be=20 > determined via local policy versus mandated via 'MUSTs' be done? Is=20 > this a section for the requirements doc? >=20 > I would like to thank Rohan for bringing this issue to the forefront=20 > in a lightning-rod manner!! ;) >=20 > Regards, >=20 > Adam >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=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 Wed Jul 12 20:52:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0pRm-0007uP-EP; Wed, 12 Jul 2006 20:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0pRl-0007py-8v for speermint@ietf.org; Wed, 12 Jul 2006 20:52:53 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0nlp-0003N3-FX for speermint@ietf.org; Wed, 12 Jul 2006 19:05:29 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1G0ngF-0008QX-SO for speermint@ietf.org; Wed, 12 Jul 2006 18:59:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jul 2006 00:55:26 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B19@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5 References: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF3B8@PACDCEXCMB03.cable.comcast.com> <32755D354E6B65498C3BD9FD496C7D462C4B15@oefeg-s04.oefeg.loc> <20060712165934.GA9273@1-4-5.net> From: "Stastny Richard" To: "David Meyer" X-Spam-Score: -2.6 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: speermint@ietf.org Subject: [Speermint] Terminology draft - 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 Proposed wording for Peering =20 4.2. Layer 5 Peering or Session Peering Layer 5 peering or Session Peering refers to interconnection of=20 two (VoIP) service providers for the purposes of routing real-time (or quasi-real time) secure call signaling between their respective=20 customers using SIP methods. Such interconnection may be direct or=20 indirect.=20 Media streams associated with this signaling (if any) are not=20 constrained to follow the same set of paths. 4.3. Direct Peering Direct Peering covers all cases where the two SPs interconnect = without using an intervening L5 network. Both SP must have a trust = relationship established (e.g. know they belong to the same federation (see = below)) before opening up a secure communication path on L5. 4.4 Indirect or Transit Peering Indirect or transit peering is the establishment of a secure = signalling path via one (or more) referral or transit network(s). In this case = it is required that a trust relationship is established between the = originating SP and the transit network on one side and the transit network and = the=20 termination network on the other side before opening up a secure=20 communication path on L5. =20 In addition, I suggest to delete the old section 4.4. on private peering because it is confusing and and out of scope anyway =20 =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jul 12 21:03:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0pbk-00070i-0c; Wed, 12 Jul 2006 21:03:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0pbi-00070d-EW for Speermint@ietf.org; Wed, 12 Jul 2006 21:03:10 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0pbh-00078K-80 for Speermint@ietf.org; Wed, 12 Jul 2006 21:03:10 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 12 Jul 2006 21:03:23 -0400 id 015880D8.44B59BDB.00001D2D In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9F5B9930-2868-41EA-A99D-A22CD1E2A65C@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Speermint] TLS, etc - Local-policy versus WG mandate Date: Wed, 12 Jul 2006 21:03:06 -0400 To: "Uzelac, Adam" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Jul 12, 2006, at 2:44 PM, Uzelac, Adam wrote: > For fear of starting a "great taste" versus "less filling" argument - > Let me start this way....I agree with what appeared to be consensus in > the WG session that there needs to be first a Discovery procedure, > then > an Authentication procedure, and finally connecting the call. For those of us who were not able to attend the entire meeting, can somebody provide the description of the function of this discovery mechanism and a use case? -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jul 12 22:32:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0r0S-0006WX-Ar; Wed, 12 Jul 2006 22:32:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0r0R-0006WS-KV for speermint@ietf.org; Wed, 12 Jul 2006 22:32:47 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0r0Q-0004l4-BB for speermint@ietf.org; Wed, 12 Jul 2006 22:32:47 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 12 Jul 2006 19:32:45 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="562211566:sNHT30149820" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Terminology draft - Peering Date: Wed, 12 Jul 2006 22:32:40 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804DA9AEC@proton.jnpr.net> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B19@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMA= From: "Reinaldo Penno" To: "Stastny Richard" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Hello Richard, > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, July 12, 2006 3:55 PM > To: David Meyer > Cc: speermint@ietf.org > Subject: [Speermint] Terminology draft - Peering >=20 > Proposed wording for Peering >=20 > 4.2. Layer 5 Peering or Session Peering > Layer 5 peering or Session Peering refers to interconnection of > two (VoIP) service providers for the purposes of routing real-time > (or quasi-real time) secure call signaling between their respective > customers using SIP methods. Such interconnection may be direct or > indirect. > Media streams associated with this signaling (if any) are not > constrained to follow the same set of paths. > 4.3. Direct Peering > Direct Peering covers all cases where the two SPs=20 [[Reinaldo]]=20 SPs or VSPs? interconnect without > using an intervening L5 network. Both SP must have a trust relationship > established (e.g. know they belong to the same federation (see below) > before opening up a secure communication path on L5. > 4.4 Indirect or Transit Peering > Indirect or transit peering is the establishment of a secure signalling > path via one (or more) referral or transit network(s). In this case it > is > required that a trust relationship is established between the > originating > SP and the transit network on one side and the transit network and the > termination network on the other side before opening up a secure > communication path on L5. [[Reinaldo]]=20 Is this transit network just providing IP transit or it is actually a Layer 5 transit network? I think the requirements are different in the two scenarios. >=20 > In addition, > I suggest to delete the old section 4.4. on private peering because > it is confusing and and out of scope anyway >=20 >=20 >=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 Thu Jul 13 00:20:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0sgV-0002uT-Qj; Thu, 13 Jul 2006 00:20:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0sgU-0002uO-P8 for speermint@ietf.org; Thu, 13 Jul 2006 00:20:18 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0sgT-0004Ay-Ap for speermint@ietf.org; Thu, 13 Jul 2006 00:20:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 06:17:49 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B1B@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3A== References: <9BD5D7887235424FA97DFC223CAE3C2804DA9AEC@proton.jnpr.net> From: "Stastny Richard" To: "Reinaldo Penno" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 >[[Reinaldo]] >SPs or VSPs? Both=20 >Is this transit network just providing IP transit or it is actually a >Layer 5 transit network? I think the requirements are different in the >two scenarios. L5 =20 Richard ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Do 13.07.2006 04:32 An: Stastny Richard; David Meyer Cc: speermint@ietf.org Betreff: RE: [Speermint] Terminology draft - Peering Hello Richard, > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, July 12, 2006 3:55 PM > To: David Meyer > Cc: speermint@ietf.org > Subject: [Speermint] Terminology draft - Peering > > Proposed wording for Peering > > 4.2. Layer 5 Peering or Session Peering > Layer 5 peering or Session Peering refers to interconnection of > two (VoIP) service providers for the purposes of routing real-time > (or quasi-real time) secure call signaling between their respective > customers using SIP methods. Such interconnection may be direct or > indirect. > Media streams associated with this signaling (if any) are not > constrained to follow the same set of paths. > 4.3. Direct Peering > Direct Peering covers all cases where the two SPs [[Reinaldo]] SPs or VSPs? interconnect without > using an intervening L5 network. Both SP must have a trust relationship > established (e.g. know they belong to the same federation (see below) > before opening up a secure communication path on L5. > 4.4 Indirect or Transit Peering > Indirect or transit peering is the establishment of a secure signalling > path via one (or more) referral or transit network(s). In this case it > is > required that a trust relationship is established between the > originating > SP and the transit network on one side and the transit network and the > termination network on the other side before opening up a secure > communication path on L5. [[Reinaldo]] Is this transit network just providing IP transit or it is actually a Layer 5 transit network? I think the requirements are different in the two scenarios. > > In addition, > I suggest to delete the old section 4.4. on private peering because > it is confusing and and out of scope anyway > > > > _______________________________________________ > 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 Jul 13 00:27:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0snB-0003IX-97; Thu, 13 Jul 2006 00:27:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0sn9-0003IP-Iu for Speermint@ietf.org; Thu, 13 Jul 2006 00:27:11 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0sn8-0004LE-6K for Speermint@ietf.org; Thu, 13 Jul 2006 00:27:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] TLS, etc - Local-policy versus WG mandate Date: Thu, 13 Jul 2006 06:21:36 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B1C@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: AcamGACYF6Du3gBIQUu+YQR+gmxN/wAG9PY2 References: <9F5B9930-2868-41EA-A99D-A22CD1E2A65C@hxr.us> From: "Stastny Richard" To: "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 >For those of us who were not able to attend the entire meeting, can=20 >somebody provide the description of the function of this discovery=20 >mechanism and a use case? The the both lendl I-Ds and the presentation from Michael Haberler The basic idea is that you check first if you are able to establish a = secure path to the destination network at all by checking the policy, then you = establish a secure path (e.g by TLS) and then you send the invite. =20 The reason is to avoid being rejected=20 =20 Richard ________________________________ Von: Andrew Newton [mailto:andy@hxr.us] Gesendet: Do 13.07.2006 03:03 An: Uzelac, Adam Cc: Speermint@ietf.org Betreff: Re: [Speermint] TLS, etc - Local-policy versus WG mandate On Jul 12, 2006, at 2:44 PM, Uzelac, Adam wrote: > For fear of starting a "great taste" versus "less filling" argument - > Let me start this way....I agree with what appeared to be consensus in > the WG session that there needs to be first a Discovery procedure,=20 > then > an Authentication procedure, and finally connecting the call. For those of us who were not able to attend the entire meeting, can=20 somebody provide the description of the function of this discovery=20 mechanism and a use case? -andy _______________________________________________ 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 Jul 13 07:56:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0znu-0005IZ-Aa; Thu, 13 Jul 2006 07:56:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0znt-0005IT-Ei for speermint@ietf.org; Thu, 13 Jul 2006 07:56:25 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0znr-0008SL-Uj for speermint@ietf.org; Thu, 13 Jul 2006 07:56:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 13:51:45 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B1D@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5ABqXLJAAAIWIQw== References: <072C5B76F7CEAB488172C6F64B30B5E301B361CB@xmb-rtp-20b.amer.cisco.com> From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 > Media streams associated with this signaling (if any) are not > constrained to follow the same set of paths. I think this is an unnecessary and potentially damaging constraint. It implies that the media path goes through the same TLS connections and boxes as the signaling at worst. It may also preclude any optimization of the media path in cases where the calling and called parties are roaming far from their home networks, but sitting on the same cell site. I would much prefer that signaling and media paths be loosely coupled. [Richard] =20 I fully agree with you and that was exactly what I ( and Dave) meant. I = did not change this sentence, it is from the original text. I do not see what the = problem is here. =20 If you have a better or cleare wording, please propose another wording =20 Richard ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Do 13.07.2006 13:42 An: Stastny Richard; David Meyer Cc: speermint@ietf.org Betreff: RE: [Speermint] Terminology draft - Peering Inline... > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, July 12, 2006 6:55 PM > To: David Meyer > Cc: speermint@ietf.org > Subject: [Speermint] Terminology draft - Peering > > Proposed wording for Peering >=20 > 4.2. Layer 5 Peering or Session Peering > Layer 5 peering or Session Peering refers to interconnection of > two (VoIP) service providers for the purposes of routing real-time > (or quasi-real time) secure call signaling between their > respective > customers using SIP methods. Such interconnection may be > direct or > indirect. > Media streams associated with this signaling (if any) are not > constrained to follow the same set of paths. I think this is an unnecessary and potentially damaging constraint. It implies that the media path goes through the same TLS connections and boxes as the signaling at worst. It may also preclude any optimization of the media path in cases where the calling and called parties are roaming far from their home networks, but sitting on the same cell site. I would much prefer that signaling and media paths be loosely coupled. If you feel this is somehow justified, please elaborate on what you mean by path. Mike > 4.3. Direct Peering > Direct Peering covers all cases where the two SPs > interconnect without > using an intervening L5 network. Both SP must have a trust > relationship > established (e.g. know they belong to the same federation > (see below)) > before opening up a secure communication path on L5. > 4.4 Indirect or Transit Peering > Indirect or transit peering is the establishment of a > secure signalling > path via one (or more) referral or transit network(s). In > this case it is > required that a trust relationship is established between > the originating > SP and the transit network on one side and the transit > network and the > termination network on the other side before opening up a secure > communication path on L5. >=20 > In addition, > I suggest to delete the old section 4.4. on private peering > because it is confusing and and out of scope anyway >=20 >=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 Thu Jul 13 08:06:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0zxi-00068F-Cf; Thu, 13 Jul 2006 08:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0zxh-00068A-IC for speermint@ietf.org; Thu, 13 Jul 2006 08:06:33 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0zxf-0000Zf-2s for speermint@ietf.org; Thu, 13 Jul 2006 08:06:33 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 13 Jul 2006 05:06:31 -0700 X-IronPort-AV: i="4.06,237,1149490800"; d="scan'208"; a="1838127549:sNHT28188716" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DC6UdO011561; Thu, 13 Jul 2006 05:06:30 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6DC6T79026561; Thu, 13 Jul 2006 05:06:30 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 08:06:29 -0400 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] Terminology draft - Peering Date: Thu, 13 Jul 2006 08:06:28 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301B361D5@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5ABqXLJAAAIWIQwAAedaw From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "David Meyer" X-OriginalArrivalTime: 13 Jul 2006 12:06:29.0736 (UTC) FILETIME=[C624DE80:01C6A674] DKIM-Signature: a=rsa-sha1; q=dns; l=4140; t=1152792390; x=1153656390; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Terminology=20draft=20-=20Peering; X=v=3Dcisco.com=3B=20h=3DV9VbvCv1Id03VA1hCr6LfMekZYU=3D; b=CAagpGibQOQfEmqBvjEpFfzaY3DmIEANzBPpYS+WA4LMlzzQ7/KSHHydo1o7AkXWJH7ofmDp r+mi0iIZvmJFfibnYvOJ+DpJb2mObz4iZf+misMrPTei8xuC4MN8k2fm; Authentication-Results: sj-dkim-6.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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 My apologies. I lost the *not* in the sentence. Nevermind :) Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Thursday, July 13, 2006 7:52 AM > To: Michael Hammer (mhammer); David Meyer > Cc: speermint@ietf.org > Subject: Re: [Speermint] Terminology draft - Peering >=20 > > Media streams associated with this signaling (if any) are not > > constrained to follow the same set of paths. >=20 > I think this is an unnecessary and potentially damaging=20 > constraint. It implies that the media path goes through the=20 > same TLS connections and boxes as the signaling at worst. It=20 > may also preclude any optimization of the media path in cases=20 > where the calling and called parties are roaming far from=20 > their home networks, but sitting on the same cell site. > I would much prefer that signaling and media paths be loosely coupled. >=20 > [Richard] > =20 > I fully agree with you and that was exactly what I ( and=20 > Dave) meant. I did not change this sentence, it is from the=20 > original text. I do not see what the problem is here. > =20 > If you have a better or cleare wording, please propose another wording > =20 > Richard >=20 > ________________________________ >=20 > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Gesendet: Do 13.07.2006 13:42 > An: Stastny Richard; David Meyer > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Terminology draft - Peering >=20 >=20 >=20 > Inline... >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, July 12, 2006 6:55 PM > > To: David Meyer > > Cc: speermint@ietf.org > > Subject: [Speermint] Terminology draft - Peering > > > > Proposed wording for Peering > >=20 > > 4.2. Layer 5 Peering or Session Peering > > Layer 5 peering or Session Peering refers to interconnection of > > two (VoIP) service providers for the purposes of routing=20 > real-time > > (or quasi-real time) secure call signaling between their=20 > respective > > customers using SIP methods. Such interconnection may=20 > be direct or > > indirect. > > Media streams associated with this signaling (if any) are not > > constrained to follow the same set of paths. >=20 > I think this is an unnecessary and potentially damaging=20 > constraint. It implies that the media path goes through the=20 > same TLS connections and boxes as the signaling at worst. It=20 > may also preclude any optimization of the media path in cases=20 > where the calling and called parties are roaming far from=20 > their home networks, but sitting on the same cell site. > I would much prefer that signaling and media paths be loosely coupled. >=20 > If you feel this is somehow justified, please elaborate on=20 > what you mean by path. >=20 > Mike >=20 >=20 >=20 > > 4.3. Direct Peering > > Direct Peering covers all cases where the two SPs interconnect=20 > > without > > using an intervening L5 network. Both SP must have a trust=20 > > relationship > > established (e.g. know they belong to the same federation (see=20 > > below)) > > before opening up a secure communication path on L5. > > 4.4 Indirect or Transit Peering > > Indirect or transit peering is the establishment of a secure=20 > > signalling > > path via one (or more) referral or transit network(s).=20 > In this case=20 > > it is > > required that a trust relationship is established between the=20 > > originating > > SP and the transit network on one side and the transit=20 > network and=20 > > the > > termination network on the other side before opening up a secure > > communication path on L5. > >=20 > > In addition, > > I suggest to delete the old section 4.4. on private peering=20 > because it=20 > > is confusing and and out of scope anyway > >=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 Jul 13 09:44:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11U9-0006qj-BX; Thu, 13 Jul 2006 09:44:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11U7-0006qe-Pt for Speermint@ietf.org; Thu, 13 Jul 2006 09:44:07 -0400 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G11U6-0004Tw-EO for Speermint@ietf.org; Thu, 13 Jul 2006 09:44:07 -0400 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] Policy and others Date: Thu, 13 Jul 2006 16:44:03 +0300 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A60655F55341@isr-jlm-mail.Kayote.com> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804DA9AB0@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policy and others Thread-Index: Acal9Z/JDlVxzBSMSV2f9cyOAiKgHAAjHBYw From: "David Schwartz" To: "Reinaldo Penno" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 These are two separate documents. I am in the process of putting together an individual submission describing use cases. Once this is done it will be abundantly clear why a discussion of policy is way overdue. Cheers, David -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Wednesday, July 12, 2006 11:56 PM To: Speermint@ietf.org Subject: [Speermint] Policy and others I think that Dave Schwartz idea of a framework policy should not be dismissed so categorically. Although I agree that this is not the high priority right now, I think this topic should get its day under the sun and be presented at some point. I would suggest Dave put a uses cases/policy framework draft to that we can provide feedback on it.=20 Regards, Reinaldo _______________________________________________ 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 Jul 13 09:49:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11ZA-0003P3-8f; Thu, 13 Jul 2006 09:49:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11Z9-0003Ot-29 for speermint@ietf.org; Thu, 13 Jul 2006 09:49:19 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G11Z7-0004m2-NW for speermint@ietf.org; Thu, 13 Jul 2006 09:49:19 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 13 Jul 2006 06:49:17 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="562347842:sNHT31949476" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 09:49:15 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804DA9B28@proton.jnpr.net> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B1B@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+Q From: "Reinaldo Penno" To: "Stastny Richard" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 thought at some point we kind of agreed to get rid of the transit term, wasn't it? Anyway, in the following case VSPA <-----> VSP B <-----> VSP C Is VSP B providing layer 5 "transit" or we can just say it peers with A and B?=20 VSP A might not even know that is talking with VSP C through VSP B. For all purposes, VSP B is VSP C... Thanks, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, July 12, 2006 9:18 PM > To: Reinaldo Penno; David Meyer > Cc: speermint@ietf.org > Subject: Re: [Speermint] Terminology draft - Peering >=20 > >[[Reinaldo]] >=20 > >SPs or VSPs? >=20 > Both >=20 > >Is this transit network just providing IP transit or it is actually a > >Layer 5 transit network? I think the requirements are different in the > >two scenarios. >=20 > L5 >=20 > Richard >=20 >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 13.07.2006 04:32 > An: Stastny Richard; David Meyer > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Terminology draft - Peering >=20 >=20 >=20 > Hello Richard, >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, July 12, 2006 3:55 PM > > To: David Meyer > > Cc: speermint@ietf.org > > Subject: [Speermint] Terminology draft - Peering > > > > Proposed wording for Peering > > > > 4.2. Layer 5 Peering or Session Peering > > Layer 5 peering or Session Peering refers to interconnection of > > two (VoIP) service providers for the purposes of routing real-time > > (or quasi-real time) secure call signaling between their respective > > customers using SIP methods. Such interconnection may be direct or > > indirect. > > Media streams associated with this signaling (if any) are not > > constrained to follow the same set of paths. > > 4.3. Direct Peering > > Direct Peering covers all cases where the two SPs > [[Reinaldo]] >=20 > SPs or VSPs? >=20 > interconnect without > > using an intervening L5 network. Both SP must have a trust > relationship > > established (e.g. know they belong to the same federation (see > below) > > before opening up a secure communication path on L5. > > 4.4 Indirect or Transit Peering > > Indirect or transit peering is the establishment of a secure > signalling > > path via one (or more) referral or transit network(s). In this case > it > > is > > required that a trust relationship is established between the > > originating > > SP and the transit network on one side and the transit network and > the > > termination network on the other side before opening up a secure > > communication path on L5. > [[Reinaldo]] >=20 > Is this transit network just providing IP transit or it is actually a > Layer 5 transit network? I think the requirements are different in the > two scenarios. >=20 > > > > In addition, > > I suggest to delete the old section 4.4. on private peering because > > it is confusing and and out of scope anyway > > > > > > > > _______________________________________________ > > 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 Jul 13 10:05:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11of-00068T-Vs; Thu, 13 Jul 2006 10:05:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11of-00068M-0t for Speermint@ietf.org; Thu, 13 Jul 2006 10:05:21 -0400 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G11od-0005SS-In for Speermint@ietf.org; Thu, 13 Jul 2006 10:05:21 -0400 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] TLS, etc - Local-policy versus WG mandate Date: Thu, 13 Jul 2006 17:05:20 +0300 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A60655F5534F@isr-jlm-mail.Kayote.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAoCKnQ From: "David Schwartz" To: "Uzelac, Adam" , X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 So here are my two cents (just repeating what I said at the session) My claim which was not directly rebuffed is why authentication is any different than any other policy issue. As far as I can tell there are 2 not 3 issues that need to be resolved for peering to occur. 1. Where is the other side 2. Can we communicate If we focus on the second issue it includes things like =20 * Will the other side even accept a call from me * Assuming other side will accept my calls * Which authentication mechanism do I use for this communication- if any * what are the ground rules for communication (e.g. specific codecs) * etc. I think of federations as shared namespace NOT policy. Federations are comprised of one namespace and multiple policy federations describing the relationships between the members. This is why for the life of me I cannot understand why it is not ok with me to peer with A via TLS and with B with IPSec and with 3 with no authentication at all. Authentication is just a policy decision and should NOT be mandated. I know everybody will yell at this but to me making ANY security mechanism mandatory is tantamount to making a minimal codec set mandatory and we know how this list reacted when that was proposed.=20 If any member is dumb enough not to implement TLS or IPSec or some other security mechanism he will soon find that no one will accept traffic from him and implement it then. We do not have to mandate not being STUPID.=20 Cheers, David -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 Sent: Wednesday, July 12, 2006 9:44 PM To: Speermint@ietf.org Subject: [Speermint] TLS, etc - Local-policy versus WG mandate Pertaining to the "To TLS or not TLS" discussion in the WG sessions, time didn't permit a proper tomato tossing session at the WG session - but one comment was made about mandating such things as TLS, etc - to which a rebuttal was made that the type of authentication and authorization used and implemented is an issue of local policy and therefore shouldn't be mandated. =20 For fear of starting a "great taste" versus "less filling" argument - Let me start this way....I agree with what appeared to be consensus in the WG session that there needs to be first a Discovery procedure, then an Authentication procedure, and finally connecting the call. The methods upon which each step along the way is done should not to so narrow as to exclude popular and in some cases widely adopted methods. Speermint should provide the BCP - but does that really need to exclude other plausible and practical models? It's important to note that I believe TLS is the most appropriate, practical and logical approach. I also believe the there are valid reasons for other approaches to authenticate. The same holds true for methods of discovery.=20 So the question for the group and possibly some guidance from the chairs here?!?!? - Should an undertaking to determine what should be determined via local policy versus mandated via 'MUSTs' be done? Is this a section for the requirements doc? I would like to thank Rohan for bringing this issue to the forefront in a lightning-rod manner!! ;) Regards, Adam _______________________________________________ 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 Jul 13 10:06:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11pc-0006Fj-1S; Thu, 13 Jul 2006 10:06:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11pb-0006Fe-E7 for speermint@ietf.org; Thu, 13 Jul 2006 10:06:19 -0400 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 1G11pZ-0005UL-3g for speermint@ietf.org; Thu, 13 Jul 2006 10:06:19 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id BA6B43FDF; Thu, 13 Jul 2006 10:06:16 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 10:06:16 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 10:06:16 -0400 Message-ID: In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804DA9B28@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering thread-index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAABajaA= From: "Uzelac, Adam" To: "Reinaldo Penno" , "Stastny Richard" , "David Meyer" X-OriginalArrivalTime: 13 Jul 2006 14:06:16.0600 (UTC) FILETIME=[81D94980:01C6A685] X-Spam-Score: 0.1 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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 couple thoughts. The concept of the "transit L5 network" has to be acknowledged if you subscribe to the notion that the a complete mesh of bi-lateral interconnections of VoIP networks is unrealistic. I understand the point in the example below that VSP-A might not even know that it's communicating with VSP-C via VSP-B, but that doesn't mean that it's not happening?!?! =20 Also, David Schwartz also presented a plausible (IMO) use case that pointed out intentionally introducing a L5 intermediary (transit) for trust purposes. The point I am trying to make is this - it's gonna be there, why not acknowledge it?!?! Regards, Adam -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Thursday, July 13, 2006 9:49 AM To: Stastny Richard; David Meyer Cc: speermint@ietf.org Subject: RE: [Speermint] Terminology draft - Peering I thought at some point we kind of agreed to get rid of the transit term, wasn't it? Anyway, in the following case VSPA <-----> VSP B <-----> VSP C Is VSP B providing layer 5 "transit" or we can just say it peers with A and B?=20 VSP A might not even know that is talking with VSP C through VSP B. For all purposes, VSP B is VSP C... Thanks, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, July 12, 2006 9:18 PM > To: Reinaldo Penno; David Meyer > Cc: speermint@ietf.org > Subject: Re: [Speermint] Terminology draft - Peering >=20 > >[[Reinaldo]] >=20 > >SPs or VSPs? >=20 > Both >=20 > >Is this transit network just providing IP transit or it is actually a > >Layer 5 transit network? I think the requirements are different in the > >two scenarios. >=20 > L5 >=20 > Richard >=20 >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 13.07.2006 04:32 > An: Stastny Richard; David Meyer > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Terminology draft - Peering >=20 >=20 >=20 > Hello Richard, >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, July 12, 2006 3:55 PM > > To: David Meyer > > Cc: speermint@ietf.org > > Subject: [Speermint] Terminology draft - Peering > > > > Proposed wording for Peering > > > > 4.2. Layer 5 Peering or Session Peering > > Layer 5 peering or Session Peering refers to interconnection of > > two (VoIP) service providers for the purposes of routing real-time > > (or quasi-real time) secure call signaling between their respective > > customers using SIP methods. Such interconnection may be direct or > > indirect. > > Media streams associated with this signaling (if any) are not > > constrained to follow the same set of paths. > > 4.3. Direct Peering > > Direct Peering covers all cases where the two SPs > [[Reinaldo]] >=20 > SPs or VSPs? >=20 > interconnect without > > using an intervening L5 network. Both SP must have a trust > relationship > > established (e.g. know they belong to the same federation (see > below) > > before opening up a secure communication path on L5. > > 4.4 Indirect or Transit Peering > > Indirect or transit peering is the establishment of a secure > signalling > > path via one (or more) referral or transit network(s). In this case > it > > is > > required that a trust relationship is established between the=20 > > originating > > SP and the transit network on one side and the transit network and > the > > termination network on the other side before opening up a secure > > communication path on L5. > [[Reinaldo]] >=20 > Is this transit network just providing IP transit or it is actually a=20 > Layer 5 transit network? I think the requirements are different in the > two scenarios. >=20 > > > > In addition, > > I suggest to delete the old section 4.4. on private peering because=20 > > it is confusing and and out of scope anyway > > > > > > > > _______________________________________________ > > 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 Thu Jul 13 10:24:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G127F-0001rR-V0; Thu, 13 Jul 2006 10:24:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G127E-0001rM-01 for speermint@ietf.org; Thu, 13 Jul 2006 10:24:32 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G127C-0006Fn-JA for speermint@ietf.org; Thu, 13 Jul 2006 10:24:31 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-7.tower-120.messagelabs.com!1152800591!10919557!25 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 24709 invoked from network); 13 Jul 2006 14:24:28 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-7.tower-120.messagelabs.com with SMTP; 13 Jul 2006 14:24:28 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 449579B800376534; Thu, 13 Jul 2006 10:24:26 -0400 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] Terminology draft - Peering Date: Thu, 13 Jul 2006 10:24:24 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0D34B689@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804DA9B28@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAAFhUiA= From: "Pfautz, Penn L, GBLAM" To: "Reinaldo Penno" , "Stastny Richard" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 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 Then the question to ask is whether the two sub cases are functionally different: A. VSPA knows the ultimate destination is VSPC but is routing through VSPB at L5 B. As far as VSPA knows VSPC is the terminating VSP -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Thursday, July 13, 2006 9:49 AM To: Stastny Richard; David Meyer Cc: speermint@ietf.org Subject: RE: [Speermint] Terminology draft - Peering I thought at some point we kind of agreed to get rid of the transit term, wasn't it? Anyway, in the following case VSPA <-----> VSP B <-----> VSP C Is VSP B providing layer 5 "transit" or we can just say it peers with A and B?=20 VSP A might not even know that is talking with VSP C through VSP B. For all purposes, VSP B is VSP C... Thanks, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, July 12, 2006 9:18 PM > To: Reinaldo Penno; David Meyer > Cc: speermint@ietf.org > Subject: Re: [Speermint] Terminology draft - Peering >=20 > >[[Reinaldo]] >=20 > >SPs or VSPs? >=20 > Both >=20 > >Is this transit network just providing IP transit or it is actually a > >Layer 5 transit network? I think the requirements are different in the > >two scenarios. >=20 > L5 >=20 > Richard >=20 >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 13.07.2006 04:32 > An: Stastny Richard; David Meyer > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Terminology draft - Peering >=20 >=20 >=20 > Hello Richard, >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, July 12, 2006 3:55 PM > > To: David Meyer > > Cc: speermint@ietf.org > > Subject: [Speermint] Terminology draft - Peering > > > > Proposed wording for Peering > > > > 4.2. Layer 5 Peering or Session Peering > > Layer 5 peering or Session Peering refers to interconnection of > > two (VoIP) service providers for the purposes of routing real-time > > (or quasi-real time) secure call signaling between their respective > > customers using SIP methods. Such interconnection may be direct or > > indirect. > > Media streams associated with this signaling (if any) are not > > constrained to follow the same set of paths. > > 4.3. Direct Peering > > Direct Peering covers all cases where the two SPs > [[Reinaldo]] >=20 > SPs or VSPs? >=20 > interconnect without > > using an intervening L5 network. Both SP must have a trust > relationship > > established (e.g. know they belong to the same federation (see > below) > > before opening up a secure communication path on L5. > > 4.4 Indirect or Transit Peering > > Indirect or transit peering is the establishment of a secure > signalling > > path via one (or more) referral or transit network(s). In this case > it > > is > > required that a trust relationship is established between the > > originating > > SP and the transit network on one side and the transit network and > the > > termination network on the other side before opening up a secure > > communication path on L5. > [[Reinaldo]] >=20 > Is this transit network just providing IP transit or it is actually a > Layer 5 transit network? I think the requirements are different in the > two scenarios. >=20 > > > > In addition, > > I suggest to delete the old section 4.4. on private peering because > > it is confusing and and out of scope anyway > > > > > > > > _______________________________________________ > > 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 Thu Jul 13 10:27:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12A0-0002nr-L8; Thu, 13 Jul 2006 10:27:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G129z-0002nm-S1 for speermint@ietf.org; Thu, 13 Jul 2006 10:27:23 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G129z-0006Qi-Ci for speermint@ietf.org; Thu, 13 Jul 2006 10:27:23 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 13 Jul 2006 07:27:22 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="562357510:sNHT34996270" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 10:27:21 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804DA9B43@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAABajaAAAQXXEA== From: "Reinaldo Penno" To: "Uzelac, Adam" , "Stastny Richard" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f 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 It is going to be there, the issue is how to phrase it in the terminology draft.=20 As to your point below, VSP A might actually care. If VSP B is not actually VSP C, he might want to see some trust transitivity from C to B to him (A). If he does _not_ care (OR cannot perceive) and VSP B appears for all purposes as VSP C, we fall back into the "direct peering" scenario where maybe no security/trust is needed? Is it clear now? Thanks, Reinaldo > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Thursday, July 13, 2006 7:06 AM > To: Reinaldo Penno; Stastny Richard; David Meyer > Cc: speermint@ietf.org > Subject: RE: [Speermint] Terminology draft - Peering >=20 > A couple thoughts. >=20 > The concept of the "transit L5 network" has to be acknowledged if you > subscribe to the notion that the a complete mesh of bi-lateral > interconnections of VoIP networks is unrealistic. I understand the > point in the example below that VSP-A might not even know that it's > communicating with VSP-C via VSP-B, but that doesn't mean that it's not > happening?!?! >=20 > Also, David Schwartz also presented a plausible (IMO) use case that > pointed out intentionally introducing a L5 intermediary (transit) for > trust purposes. The point I am trying to make is this - it's gonna be > there, why not acknowledge it?!?! >=20 > Regards, >=20 > Adam >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, July 13, 2006 9:49 AM > To: Stastny Richard; David Meyer > Cc: speermint@ietf.org > Subject: RE: [Speermint] Terminology draft - Peering >=20 > I thought at some point we kind of agreed to get rid of the transit > term, wasn't it? >=20 > Anyway, in the following case >=20 > VSPA <-----> VSP B <-----> VSP C >=20 > Is VSP B providing layer 5 "transit" or we can just say it peers with A > and B? >=20 > VSP A might not even know that is talking with VSP C through VSP B. For > all purposes, VSP B is VSP C... >=20 > Thanks, >=20 > Reinaldo >=20 >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, July 12, 2006 9:18 PM > > To: Reinaldo Penno; David Meyer > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Terminology draft - Peering > > > > >[[Reinaldo]] > > > > >SPs or VSPs? > > > > Both > > > > >Is this transit network just providing IP transit or it is actually a >=20 > > >Layer 5 transit network? I think the requirements are different in > the > > >two scenarios. > > > > L5 > > > > Richard > > > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Do 13.07.2006 04:32 > > An: Stastny Richard; David Meyer > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > Hello Richard, > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, July 12, 2006 3:55 PM > > > To: David Meyer > > > Cc: speermint@ietf.org > > > Subject: [Speermint] Terminology draft - Peering > > > > > > Proposed wording for Peering > > > > > > 4.2. Layer 5 Peering or Session Peering > > > Layer 5 peering or Session Peering refers to interconnection of > > > two (VoIP) service providers for the purposes of routing > real-time > > > (or quasi-real time) secure call signaling between their > respective > > > customers using SIP methods. Such interconnection may be direct > or > > > indirect. > > > Media streams associated with this signaling (if any) are not > > > constrained to follow the same set of paths. > > > 4.3. Direct Peering > > > Direct Peering covers all cases where the two SPs > > [[Reinaldo]] > > > > SPs or VSPs? > > > > interconnect without > > > using an intervening L5 network. Both SP must have a trust > > relationship > > > established (e.g. know they belong to the same federation (see > > below) > > > before opening up a secure communication path on L5. > > > 4.4 Indirect or Transit Peering > > > Indirect or transit peering is the establishment of a secure > > signalling > > > path via one (or more) referral or transit network(s). In this > case > > it > > > is > > > required that a trust relationship is established between the > > > originating > > > SP and the transit network on one side and the transit network > and > > the > > > termination network on the other side before opening up a secure > > > communication path on L5. > > [[Reinaldo]] > > > > Is this transit network just providing IP transit or it is actually a > > Layer 5 transit network? I think the requirements are different in the >=20 > > two scenarios. > > > > > > > > In addition, > > > I suggest to delete the old section 4.4. on private peering because > > > it is confusing and and out of scope anyway > > > > > > > > > > > > _______________________________________________ > > > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 13 11:09:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12oX-0004L4-IE; Thu, 13 Jul 2006 11:09:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12oV-0004Jj-2B for speermint@ietf.org; Thu, 13 Jul 2006 11:09:15 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G12nG-0008Sj-LL for speermint@ietf.org; Thu, 13 Jul 2006 11:07:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 17:05:59 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B21@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAABajaAAAQXXEAABjOCF References: <9BD5D7887235424FA97DFC223CAE3C2804DA9B43@proton.jnpr.net> From: "Stastny Richard" To: "Reinaldo Penno" , "Uzelac, Adam" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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 If VSP B is giving A all what he needs, does he need to care how=20 VSP B and C are doing this? =20 Richard ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Do 13.07.2006 16:27 An: Uzelac, Adam; Stastny Richard; David Meyer Cc: speermint@ietf.org Betreff: RE: [Speermint] Terminology draft - Peering It is going to be there, the issue is how to phrase it in the terminology draft. As to your point below, VSP A might actually care. If VSP B is not actually VSP C, he might want to see some trust transitivity from C to B to him (A). If he does _not_ care (OR cannot perceive) and VSP B appears for all purposes as VSP C, we fall back into the "direct peering" scenario where maybe no security/trust is needed? Is it clear now? Thanks, Reinaldo > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Thursday, July 13, 2006 7:06 AM > To: Reinaldo Penno; Stastny Richard; David Meyer > Cc: speermint@ietf.org > Subject: RE: [Speermint] Terminology draft - Peering > > A couple thoughts. > > The concept of the "transit L5 network" has to be acknowledged if you > subscribe to the notion that the a complete mesh of bi-lateral > interconnections of VoIP networks is unrealistic. I understand the > point in the example below that VSP-A might not even know that it's > communicating with VSP-C via VSP-B, but that doesn't mean that it's not > happening?!?! > > Also, David Schwartz also presented a plausible (IMO) use case that > pointed out intentionally introducing a L5 intermediary (transit) for > trust purposes. The point I am trying to make is this - it's gonna be > there, why not acknowledge it?!?! > > Regards, > > Adam > > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, July 13, 2006 9:49 AM > To: Stastny Richard; David Meyer > Cc: speermint@ietf.org > Subject: RE: [Speermint] Terminology draft - Peering > > I thought at some point we kind of agreed to get rid of the transit > term, wasn't it? > > Anyway, in the following case > > VSPA <-----> VSP B <-----> VSP C > > Is VSP B providing layer 5 "transit" or we can just say it peers with A > and B? > > VSP A might not even know that is talking with VSP C through VSP B. For > all purposes, VSP B is VSP C... > > Thanks, > > Reinaldo > > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, July 12, 2006 9:18 PM > > To: Reinaldo Penno; David Meyer > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Terminology draft - Peering > > > > >[[Reinaldo]] > > > > >SPs or VSPs? > > > > Both > > > > >Is this transit network just providing IP transit or it is actually a > > > >Layer 5 transit network? I think the requirements are different in > the > > >two scenarios. > > > > L5 > > > > Richard > > > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Do 13.07.2006 04:32 > > An: Stastny Richard; David Meyer > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > Hello Richard, > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, July 12, 2006 3:55 PM > > > To: David Meyer > > > Cc: speermint@ietf.org > > > Subject: [Speermint] Terminology draft - Peering > > > > > > Proposed wording for Peering > > > > > > 4.2. Layer 5 Peering or Session Peering > > > Layer 5 peering or Session Peering refers to interconnection of > > > two (VoIP) service providers for the purposes of routing > real-time > > > (or quasi-real time) secure call signaling between their > respective > > > customers using SIP methods. Such interconnection may be direct > or > > > indirect. > > > Media streams associated with this signaling (if any) are not > > > constrained to follow the same set of paths. > > > 4.3. Direct Peering > > > Direct Peering covers all cases where the two SPs > > [[Reinaldo]] > > > > SPs or VSPs? > > > > interconnect without > > > using an intervening L5 network. Both SP must have a trust > > relationship > > > established (e.g. know they belong to the same federation (see > > below) > > > before opening up a secure communication path on L5. > > > 4.4 Indirect or Transit Peering > > > Indirect or transit peering is the establishment of a secure > > signalling > > > path via one (or more) referral or transit network(s). In this > case > > it > > > is > > > required that a trust relationship is established between the > > > originating > > > SP and the transit network on one side and the transit network > and > > the > > > termination network on the other side before opening up a secure > > > communication path on L5. > > [[Reinaldo]] > > > > Is this transit network just providing IP transit or it is actually a > > Layer 5 transit network? I think the requirements are different in the > > > two scenarios. > > > > > > > > In addition, > > > I suggest to delete the old section 4.4. on private peering because > > > it is confusing and and out of scope anyway > > > > > > > > > > > > _______________________________________________ > > > 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 Thu Jul 13 11:09:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12od-0004Uf-Ed; Thu, 13 Jul 2006 11:09:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12oY-0004Lc-QG for speermint@ietf.org; Thu, 13 Jul 2006 11:09:18 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G12l5-0008P2-1l for speermint@ietf.org; Thu, 13 Jul 2006 11:05:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 17:01:47 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B20@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAALHsGk= References: <9BD5D7887235424FA97DFC223CAE3C2804DA9B28@proton.jnpr.net> From: "Stastny Richard" To: "Reinaldo Penno" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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 >VSPA <-----> VSP B <-----> VSP C >Is VSP B providing layer 5 "transit" or we can just say it peers with A and B? >VSP A might not even know that is talking with VSP C through VSP B. For >all purposes, VSP B is VSP C... =20 VSP A must know that the call terminates at VSP C, because he basically = has an AoR for VSP C. =20 He looks up VSP C and sees he cannot peer with VSP C directly, but gets the pointer to VSP B (somehow) =20 Now he peers with VSP B and VSP B peers with VSP C =20 Richard ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Do 13.07.2006 15:49 An: Stastny Richard; David Meyer Cc: speermint@ietf.org Betreff: RE: [Speermint] Terminology draft - Peering I thought at some point we kind of agreed to get rid of the transit term, wasn't it? Anyway, in the following case VSPA <-----> VSP B <-----> VSP C Is VSP B providing layer 5 "transit" or we can just say it peers with A and B? VSP A might not even know that is talking with VSP C through VSP B. For all purposes, VSP B is VSP C... Thanks, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, July 12, 2006 9:18 PM > To: Reinaldo Penno; David Meyer > Cc: speermint@ietf.org > Subject: Re: [Speermint] Terminology draft - Peering > > >[[Reinaldo]] > > >SPs or VSPs? > > Both > > >Is this transit network just providing IP transit or it is actually a > >Layer 5 transit network? I think the requirements are different in the > >two scenarios. > > L5 > > Richard > > > ________________________________ > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 13.07.2006 04:32 > An: Stastny Richard; David Meyer > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Terminology draft - Peering > > > > Hello Richard, > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, July 12, 2006 3:55 PM > > To: David Meyer > > Cc: speermint@ietf.org > > Subject: [Speermint] Terminology draft - Peering > > > > Proposed wording for Peering > > > > 4.2. Layer 5 Peering or Session Peering > > Layer 5 peering or Session Peering refers to interconnection of > > two (VoIP) service providers for the purposes of routing real-time > > (or quasi-real time) secure call signaling between their respective > > customers using SIP methods. Such interconnection may be direct or > > indirect. > > Media streams associated with this signaling (if any) are not > > constrained to follow the same set of paths. > > 4.3. Direct Peering > > Direct Peering covers all cases where the two SPs > [[Reinaldo]] > > SPs or VSPs? > > interconnect without > > using an intervening L5 network. Both SP must have a trust > relationship > > established (e.g. know they belong to the same federation (see > below) > > before opening up a secure communication path on L5. > > 4.4 Indirect or Transit Peering > > Indirect or transit peering is the establishment of a secure > signalling > > path via one (or more) referral or transit network(s). In this case > it > > is > > required that a trust relationship is established between the > > originating > > SP and the transit network on one side and the transit network and > the > > termination network on the other side before opening up a secure > > communication path on L5. > [[Reinaldo]] > > Is this transit network just providing IP transit or it is actually a > Layer 5 transit network? I think the requirements are different in the > two scenarios. > > > > > In addition, > > I suggest to delete the old section 4.4. on private peering because > > it is confusing and and out of scope anyway > > > > > > > > _______________________________________________ > > 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 Jul 13 11:09:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12oh-0004mC-UL; Thu, 13 Jul 2006 11:09:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12ob-0004Qk-TO for Speermint@ietf.org; Thu, 13 Jul 2006 11:09:21 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G12hB-0008BD-GU for Speermint@ietf.org; Thu, 13 Jul 2006 11:01:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] TLS, etc - Local-policy versus WG mandate Date: Thu, 13 Jul 2006 16:57:44 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B1F@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAoCKnQAAJXv/w= References: <1DDB0D3CC4E7F14FAE946361C0A60655F5534F@isr-jlm-mail.Kayote.com> From: "Stastny Richard" To: "David Schwartz" , "Uzelac, Adam" , 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 >I think of federations as shared namespace NOT policy. Federations are >comprised of one namespace and multiple policy federations describing >the relationships between the members. =20 Just a question: if you do not have a common policy in the federation, why do you need it at all? =20 Richard ________________________________ Von: David Schwartz [mailto:David.Schwartz@Kayote.com] Gesendet: Do 13.07.2006 16:05 An: Uzelac, Adam; Speermint@ietf.org Betreff: RE: [Speermint] TLS, etc - Local-policy versus WG mandate So here are my two cents (just repeating what I said at the session) My claim which was not directly rebuffed is why authentication is any different than any other policy issue. As far as I can tell there are 2 not 3 issues that need to be resolved for peering to occur. 1. Where is the other side 2. Can we communicate If we focus on the second issue it includes things like * Will the other side even accept a call from me * Assuming other side will accept my calls * Which authentication mechanism do I use for this communication- if any * what are the ground rules for communication (e.g. specific codecs) * etc. I think of federations as shared namespace NOT policy. Federations are comprised of one namespace and multiple policy federations describing the relationships between the members. This is why for the life of me I cannot understand why it is not ok with me to peer with A via TLS and with B with IPSec and with 3 with no authentication at all. Authentication is just a policy decision and should NOT be mandated. I know everybody will yell at this but to me making ANY security mechanism mandatory is tantamount to making a minimal codec set mandatory and we know how this list reacted when that was proposed. If any member is dumb enough not to implement TLS or IPSec or some other security mechanism he will soon find that no one will accept traffic from him and implement it then. We do not have to mandate not being STUPID. Cheers, David -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Sent: Wednesday, July 12, 2006 9:44 PM To: Speermint@ietf.org Subject: [Speermint] TLS, etc - Local-policy versus WG mandate Pertaining to the "To TLS or not TLS" discussion in the WG sessions, time didn't permit a proper tomato tossing session at the WG session - but one comment was made about mandating such things as TLS, etc - to which a rebuttal was made that the type of authentication and authorization used and implemented is an issue of local policy and therefore shouldn't be mandated.=20 For fear of starting a "great taste" versus "less filling" argument - Let me start this way....I agree with what appeared to be consensus in the WG session that there needs to be first a Discovery procedure, then an Authentication procedure, and finally connecting the call. The methods upon which each step along the way is done should not to so narrow as to exclude popular and in some cases widely adopted methods. Speermint should provide the BCP - but does that really need to exclude other plausible and practical models? It's important to note that I believe TLS is the most appropriate, practical and logical approach. I also believe the there are valid reasons for other approaches to authenticate. The same holds true for methods of discovery. So the question for the group and possibly some guidance from the chairs here?!?!? - Should an undertaking to determine what should be determined via local policy versus mandated via 'MUSTs' be done? Is this a section for the requirements doc? I would like to thank Rohan for bringing this issue to the forefront in a lightning-rod manner!! ;) Regards, Adam _______________________________________________ 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 Thu Jul 13 11:09:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12ox-0005KD-I1; Thu, 13 Jul 2006 11:09:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12ow-0005Go-A3 for Speermint@ietf.org; Thu, 13 Jul 2006 11:09:42 -0400 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12ot-0000O1-Pd for Speermint@ietf.org; Thu, 13 Jul 2006 11:09:42 -0400 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] TLS, etc - Local-policy versus WG mandate Date: Thu, 13 Jul 2006 18:09:39 +0300 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A60655F55376@isr-jlm-mail.Kayote.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B1F@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAoCKnQAAJXv/wAAC/mYA== From: "David Schwartz" To: "Stastny Richard" , "Uzelac, Adam" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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 There is value in knowing the affiliation of an entity. I can use this information to find possible commonalities to possibly enable communication. For example, it could be that the reason we so not share a policy group is due to the fact that he supports only 711 and I support only 723. Once his affiliation was known I could search for a different entity in the same namespace who may be able to connect us (e.g. he shares policy with both of us since he can transcode 711 to 723). David -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, July 13, 2006 5:58 PM To: David Schwartz; Uzelac, Adam; Speermint@ietf.org Subject: Re: [Speermint] TLS, etc - Local-policy versus WG mandate >I think of federations as shared namespace NOT policy. Federations are >comprised of one namespace and multiple policy federations describing >the relationships between the members. =20 Just a question: if you do not have a common policy in the federation, why do you need it at all? =20 Richard ________________________________ Von: David Schwartz [mailto:David.Schwartz@Kayote.com] Gesendet: Do 13.07.2006 16:05 An: Uzelac, Adam; Speermint@ietf.org Betreff: RE: [Speermint] TLS, etc - Local-policy versus WG mandate So here are my two cents (just repeating what I said at the session) My claim which was not directly rebuffed is why authentication is any different than any other policy issue. As far as I can tell there are 2 not 3 issues that need to be resolved for peering to occur. 1. Where is the other side 2. Can we communicate If we focus on the second issue it includes things like * Will the other side even accept a call from me * Assuming other side will accept my calls * Which authentication mechanism do I use for this communication- if any * what are the ground rules for communication (e.g. specific codecs) * etc. I think of federations as shared namespace NOT policy. Federations are comprised of one namespace and multiple policy federations describing the relationships between the members. This is why for the life of me I cannot understand why it is not ok with me to peer with A via TLS and with B with IPSec and with 3 with no authentication at all. Authentication is just a policy decision and should NOT be mandated. I know everybody will yell at this but to me making ANY security mechanism mandatory is tantamount to making a minimal codec set mandatory and we know how this list reacted when that was proposed. If any member is dumb enough not to implement TLS or IPSec or some other security mechanism he will soon find that no one will accept traffic from him and implement it then. We do not have to mandate not being STUPID. Cheers, David -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Sent: Wednesday, July 12, 2006 9:44 PM To: Speermint@ietf.org Subject: [Speermint] TLS, etc - Local-policy versus WG mandate Pertaining to the "To TLS or not TLS" discussion in the WG sessions, time didn't permit a proper tomato tossing session at the WG session - but one comment was made about mandating such things as TLS, etc - to which a rebuttal was made that the type of authentication and authorization used and implemented is an issue of local policy and therefore shouldn't be mandated.=20 For fear of starting a "great taste" versus "less filling" argument - Let me start this way....I agree with what appeared to be consensus in the WG session that there needs to be first a Discovery procedure, then an Authentication procedure, and finally connecting the call. The methods upon which each step along the way is done should not to so narrow as to exclude popular and in some cases widely adopted methods. Speermint should provide the BCP - but does that really need to exclude other plausible and practical models? It's important to note that I believe TLS is the most appropriate, practical and logical approach. I also believe the there are valid reasons for other approaches to authenticate. The same holds true for methods of discovery. So the question for the group and possibly some guidance from the chairs here?!?!? - Should an undertaking to determine what should be determined via local policy versus mandated via 'MUSTs' be done? Is this a section for the requirements doc? I would like to thank Rohan for bringing this issue to the forefront in a lightning-rod manner!! ;) Regards, Adam _______________________________________________ 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 Thu Jul 13 11:17:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12wd-0007e7-Mg; Thu, 13 Jul 2006 11:17:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12wd-0007e2-5i for speermint@ietf.org; Thu, 13 Jul 2006 11:17:39 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12wa-0000ng-JT for speermint@ietf.org; Thu, 13 Jul 2006 11:17:39 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 13 Jul 2006 08:17:35 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="562370450:sNHT36434708" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 11:17:28 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804DA9B6B@proton.jnpr.net> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B21@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAABajaAAAQXXEAABjOCFAABM34A= From: "Reinaldo Penno" To: "Stastny Richard" , "Uzelac, Adam" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 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 Sure, isn't that the same thing in real life? If I'm paying you for a service, do I care if you are doing it in a legitimate way or not? If to perform this service you are involving somebody else, should I care if that somebody else is legitimate and not some front end money laundry shops? Thanks, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, July 13, 2006 8:06 AM > To: Reinaldo Penno; Uzelac, Adam; David Meyer > Cc: speermint@ietf.org > Subject: Re: [Speermint] Terminology draft - Peering >=20 > If VSP B is giving A all what he needs, does he need to care how > VSP B and C are doing this? >=20 > Richard >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 13.07.2006 16:27 > An: Uzelac, Adam; Stastny Richard; David Meyer > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Terminology draft - Peering >=20 >=20 >=20 > It is going to be there, the issue is how to phrase it in the > terminology draft. >=20 > As to your point below, VSP A might actually care. If VSP B is not > actually VSP C, he might want to see some trust transitivity from C to B > to him (A). If he does _not_ care (OR cannot perceive) and VSP B appears > for all purposes as VSP C, we fall back into the "direct peering" > scenario where maybe no security/trust is needed? Is it clear now? >=20 > Thanks, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Thursday, July 13, 2006 7:06 AM > > To: Reinaldo Penno; Stastny Richard; David Meyer > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Terminology draft - Peering > > > > A couple thoughts. > > > > The concept of the "transit L5 network" has to be acknowledged if you > > subscribe to the notion that the a complete mesh of bi-lateral > > interconnections of VoIP networks is unrealistic. I understand the > > point in the example below that VSP-A might not even know that it's > > communicating with VSP-C via VSP-B, but that doesn't mean that it's > not > > happening?!?! > > > > Also, David Schwartz also presented a plausible (IMO) use case that > > pointed out intentionally introducing a L5 intermediary (transit) for > > trust purposes. The point I am trying to make is this - it's gonna be > > there, why not acknowledge it?!?! > > > > Regards, > > > > Adam > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, July 13, 2006 9:49 AM > > To: Stastny Richard; David Meyer > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Terminology draft - Peering > > > > I thought at some point we kind of agreed to get rid of the transit > > term, wasn't it? > > > > Anyway, in the following case > > > > VSPA <-----> VSP B <-----> VSP C > > > > Is VSP B providing layer 5 "transit" or we can just say it peers with > A > > and B? > > > > VSP A might not even know that is talking with VSP C through VSP B. > For > > all purposes, VSP B is VSP C... > > > > Thanks, > > > > Reinaldo > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, July 12, 2006 9:18 PM > > > To: Reinaldo Penno; David Meyer > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Terminology draft - Peering > > > > > > >[[Reinaldo]] > > > > > > >SPs or VSPs? > > > > > > Both > > > > > > >Is this transit network just providing IP transit or it is actually > a > > > > > >Layer 5 transit network? I think the requirements are different in > > the > > > >two scenarios. > > > > > > L5 > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Do 13.07.2006 04:32 > > > An: Stastny Richard; David Meyer > > > Cc: speermint@ietf.org > > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > > > > > Hello Richard, > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Wednesday, July 12, 2006 3:55 PM > > > > To: David Meyer > > > > Cc: speermint@ietf.org > > > > Subject: [Speermint] Terminology draft - Peering > > > > > > > > Proposed wording for Peering > > > > > > > > 4.2. Layer 5 Peering or Session Peering > > > > Layer 5 peering or Session Peering refers to interconnection of > > > > two (VoIP) service providers for the purposes of routing > > real-time > > > > (or quasi-real time) secure call signaling between their > > respective > > > > customers using SIP methods. Such interconnection may be > direct > > or > > > > indirect. > > > > Media streams associated with this signaling (if any) are not > > > > constrained to follow the same set of paths. > > > > 4.3. Direct Peering > > > > Direct Peering covers all cases where the two SPs > > > [[Reinaldo]] > > > > > > SPs or VSPs? > > > > > > interconnect without > > > > using an intervening L5 network. Both SP must have a trust > > > relationship > > > > established (e.g. know they belong to the same federation (see > > > below) > > > > before opening up a secure communication path on L5. > > > > 4.4 Indirect or Transit Peering > > > > Indirect or transit peering is the establishment of a secure > > > signalling > > > > path via one (or more) referral or transit network(s). In this > > case > > > it > > > > is > > > > required that a trust relationship is established between the > > > > originating > > > > SP and the transit network on one side and the transit network > > and > > > the > > > > termination network on the other side before opening up a > secure > > > > communication path on L5. > > > [[Reinaldo]] > > > > > > Is this transit network just providing IP transit or it is actually > a > > > Layer 5 transit network? I think the requirements are different in > the > > > > > two scenarios. > > > > > > > > > > > In addition, > > > > I suggest to delete the old section 4.4. on private peering > because > > > > it is confusing and and out of scope anyway > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 Thu Jul 13 11:18:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12xP-0007mz-8q; Thu, 13 Jul 2006 11:18:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12xN-0007me-NG for speermint@ietf.org; Thu, 13 Jul 2006 11:18:25 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G12xK-0000pB-Rz for speermint@ietf.org; Thu, 13 Jul 2006 11:18:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 17:14:52 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B23@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAAFhUiAAAHOAoAABZ/Xe References: <1DDB0D3CC4E7F14FAE946361C0A60655F5536F@isr-jlm-mail.Kayote.com> From: "Stastny Richard" To: "David Schwartz" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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 do not really understand you anonynizing concept in Speermint =20 I may look up an E.164 number and interconnect without knowing with whom But in speermint VSP A alway gets an AoR indicating a domain name od VSP = C How can you now anonymize it? =20 Richard ________________________________ Von: David Schwartz [mailto:David.Schwartz@Kayote.com] Gesendet: Do 13.07.2006 17:01 An: Pfautz, Penn L, GBLAM; Reinaldo Penno; Stastny Richard; David Meyer Cc: speermint@ietf.org Betreff: RE: [Speermint] Terminology draft - Peering Hi Penn. My point was that there are two cases I can think of. 1. 1@A --- B --- 2@C=20 In this case when user 1 wants to call user 2. If this is a = federation where B is anonymizing all data than A would ask B and B = would return 2@B implying that communication with 2 needs to go via B = and 1 can have no visibility into who "owns" 2. My only point is that in = this case B is not a transit network, rather he is a "super" entity that = for all practical purposes "owns" 2 vis-=E0-vis 1. 2. 1@A ---B --- 2@C In this case 1 has visibility to the fact that 2 is "owned" by C. = The case I am trying to cover here is where 2 wants 1 to signal C via B. = This may be due to security or interoperability reasons. This is the = case that was referred to as "hosted policy". Point is there is thus no need for transit definition. Cheers, David -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Thursday, July 13, 2006 5:24 PM To: Reinaldo Penno; Stastny Richard; David Meyer Cc: speermint@ietf.org Subject: RE: [Speermint] Terminology draft - Peering Then the question to ask is whether the two sub cases are functionally different: A. VSPA knows the ultimate destination is VSPC but is routing through VSPB at L5 B. As far as VSPA knows VSPC is the terminating VSP -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Thursday, July 13, 2006 9:49 AM To: Stastny Richard; David Meyer Cc: speermint@ietf.org Subject: RE: [Speermint] Terminology draft - Peering I thought at some point we kind of agreed to get rid of the transit term, wasn't it? Anyway, in the following case VSPA <-----> VSP B <-----> VSP C Is VSP B providing layer 5 "transit" or we can just say it peers with A and B? VSP A might not even know that is talking with VSP C through VSP B. For all purposes, VSP B is VSP C... Thanks, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, July 12, 2006 9:18 PM > To: Reinaldo Penno; David Meyer > Cc: speermint@ietf.org > Subject: Re: [Speermint] Terminology draft - Peering > > >[[Reinaldo]] > > >SPs or VSPs? > > Both > > >Is this transit network just providing IP transit or it is actually a > >Layer 5 transit network? I think the requirements are different in the > >two scenarios. > > L5 > > Richard > > > ________________________________ > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 13.07.2006 04:32 > An: Stastny Richard; David Meyer > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Terminology draft - Peering > > > > Hello Richard, > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, July 12, 2006 3:55 PM > > To: David Meyer > > Cc: speermint@ietf.org > > Subject: [Speermint] Terminology draft - Peering > > > > Proposed wording for Peering > > > > 4.2. Layer 5 Peering or Session Peering > > Layer 5 peering or Session Peering refers to interconnection of > > two (VoIP) service providers for the purposes of routing real-time > > (or quasi-real time) secure call signaling between their respective > > customers using SIP methods. Such interconnection may be direct or > > indirect. > > Media streams associated with this signaling (if any) are not > > constrained to follow the same set of paths. > > 4.3. Direct Peering > > Direct Peering covers all cases where the two SPs > [[Reinaldo]] > > SPs or VSPs? > > interconnect without > > using an intervening L5 network. Both SP must have a trust > relationship > > established (e.g. know they belong to the same federation (see > below) > > before opening up a secure communication path on L5. > > 4.4 Indirect or Transit Peering > > Indirect or transit peering is the establishment of a secure > signalling > > path via one (or more) referral or transit network(s). In this case > it > > is > > required that a trust relationship is established between the > > originating > > SP and the transit network on one side and the transit network and > the > > termination network on the other side before opening up a secure > > communication path on L5. > [[Reinaldo]] > > Is this transit network just providing IP transit or it is actually a > Layer 5 transit network? I think the requirements are different in the > two scenarios. > > > > > In addition, > > I suggest to delete the old section 4.4. on private peering because > > it is confusing and and out of scope anyway > > > > > > > > _______________________________________________ > > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 13 11:19:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12ya-00088A-OR; Thu, 13 Jul 2006 11:19:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12yZ-000880-H2 for speermint@ietf.org; Thu, 13 Jul 2006 11:19:39 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12yZ-0000vc-1T for speermint@ietf.org; Thu, 13 Jul 2006 11:19:39 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 13 Jul 2006 08:19:38 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="562370965:sNHT36975816" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 11:19:31 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804DA9B6C@proton.jnpr.net> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B20@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAALHsGkAADlMwA== From: "Reinaldo Penno" To: "Stastny Richard" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 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 Richard, I think you are assuming the domain part of AORs maps to the VSP that actually host his VoIP service and this relationship is not well defined. I can be in VSP A and make a DNS query for alice@some-company.com and get as a result a proxy server at VSP B. Now, some-company.com is actually served by VSP C, but the DNS returns VSP B because that's where you need to send your signaling to get to some-company.com In this case, VSP A has no way of knowing that some-company.com is actually "hosted" (for a lack of a better term) in VSP C.=20 A VSP can serve many domains. Just because the VSP is called vspb.com does not mean it cannot serve, e.g., supervoip.com, voip'r'us.com, voipathome.com, etc, etc Thanks, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, July 13, 2006 8:02 AM > To: Reinaldo Penno; David Meyer > Cc: speermint@ietf.org > Subject: Re: [Speermint] Terminology draft - Peering >=20 > >VSPA <-----> VSP B <-----> VSP C >=20 > >Is VSP B providing layer 5 "transit" or we can just say it peers with A > and B? >=20 > >VSP A might not even know that is talking with VSP C through VSP B. For > >all purposes, VSP B is VSP C... >=20 > VSP A must know that the call terminates at VSP C, because he basically > has > an AoR for VSP C. >=20 > He looks up VSP C and sees he cannot peer with VSP C directly, but gets > the pointer to VSP B (somehow) >=20 > Now he peers with VSP B and VSP B peers with VSP C >=20 > Richard >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 13.07.2006 15:49 > An: Stastny Richard; David Meyer > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Terminology draft - Peering >=20 >=20 >=20 > I thought at some point we kind of agreed to get rid of the transit > term, wasn't it? >=20 > Anyway, in the following case >=20 > VSPA <-----> VSP B <-----> VSP C >=20 > Is VSP B providing layer 5 "transit" or we can just say it peers with A > and B? >=20 > VSP A might not even know that is talking with VSP C through VSP B. For > all purposes, VSP B is VSP C... >=20 > Thanks, >=20 > Reinaldo >=20 >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, July 12, 2006 9:18 PM > > To: Reinaldo Penno; David Meyer > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Terminology draft - Peering > > > > >[[Reinaldo]] > > > > >SPs or VSPs? > > > > Both > > > > >Is this transit network just providing IP transit or it is actually a > > >Layer 5 transit network? I think the requirements are different in > the > > >two scenarios. > > > > L5 > > > > Richard > > > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Do 13.07.2006 04:32 > > An: Stastny Richard; David Meyer > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > Hello Richard, > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, July 12, 2006 3:55 PM > > > To: David Meyer > > > Cc: speermint@ietf.org > > > Subject: [Speermint] Terminology draft - Peering > > > > > > Proposed wording for Peering > > > > > > 4.2. Layer 5 Peering or Session Peering > > > Layer 5 peering or Session Peering refers to interconnection of > > > two (VoIP) service providers for the purposes of routing > real-time > > > (or quasi-real time) secure call signaling between their > respective > > > customers using SIP methods. Such interconnection may be direct > or > > > indirect. > > > Media streams associated with this signaling (if any) are not > > > constrained to follow the same set of paths. > > > 4.3. Direct Peering > > > Direct Peering covers all cases where the two SPs > > [[Reinaldo]] > > > > SPs or VSPs? > > > > interconnect without > > > using an intervening L5 network. Both SP must have a trust > > relationship > > > established (e.g. know they belong to the same federation (see > > below) > > > before opening up a secure communication path on L5. > > > 4.4 Indirect or Transit Peering > > > Indirect or transit peering is the establishment of a secure > > signalling > > > path via one (or more) referral or transit network(s). In this > case > > it > > > is > > > required that a trust relationship is established between the > > > originating > > > SP and the transit network on one side and the transit network > and > > the > > > termination network on the other side before opening up a secure > > > communication path on L5. > > [[Reinaldo]] > > > > Is this transit network just providing IP transit or it is actually a > > Layer 5 transit network? I think the requirements are different in the > > two scenarios. > > > > > > > > In addition, > > > I suggest to delete the old section 4.4. on private peering because > > > it is confusing and and out of scope anyway > > > > > > > > > > > > _______________________________________________ > > > 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 Jul 13 11:23:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12ol-0004tw-5E; Thu, 13 Jul 2006 11:09:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12oc-0004Qk-1C for speermint@ietf.org; Thu, 13 Jul 2006 11:09:22 -0400 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12h0-0008B4-21 for speermint@ietf.org; Thu, 13 Jul 2006 11:01:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 18:01:28 +0300 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A60655F5536F@isr-jlm-mail.Kayote.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0D34B689@ACCLUST02EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAAFhUiAAAHOAoA== From: "David Schwartz" To: "Pfautz, Penn L, GBLAM" , "Reinaldo Penno" , "Stastny Richard" , "David Meyer" X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 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 Hi Penn. My point was that there are two cases I can think of. 1. 1@A --- B --- 2@C =20 In this case when user 1 wants to call user 2. If this is a = federation where B is anonymizing all data than A would ask B and B = would return 2@B implying that communication with 2 needs to go via B = and 1 can have no visibility into who "owns" 2. My only point is that in = this case B is not a transit network, rather he is a "super" entity that = for all practical purposes "owns" 2 vis-=E0-vis 1. 2. 1@A ---B --- 2@C In this case 1 has visibility to the fact that 2 is "owned" by C. = The case I am trying to cover here is where 2 wants 1 to signal C via B. = This may be due to security or interoperability reasons. This is the = case that was referred to as "hosted policy". Point is there is thus no need for transit definition. Cheers, David -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com]=20 Sent: Thursday, July 13, 2006 5:24 PM To: Reinaldo Penno; Stastny Richard; David Meyer Cc: speermint@ietf.org Subject: RE: [Speermint] Terminology draft - Peering Then the question to ask is whether the two sub cases are functionally different: A. VSPA knows the ultimate destination is VSPC but is routing through VSPB at L5 B. As far as VSPA knows VSPC is the terminating VSP -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Thursday, July 13, 2006 9:49 AM To: Stastny Richard; David Meyer Cc: speermint@ietf.org Subject: RE: [Speermint] Terminology draft - Peering I thought at some point we kind of agreed to get rid of the transit term, wasn't it? Anyway, in the following case VSPA <-----> VSP B <-----> VSP C Is VSP B providing layer 5 "transit" or we can just say it peers with A and B?=20 VSP A might not even know that is talking with VSP C through VSP B. For all purposes, VSP B is VSP C... Thanks, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, July 12, 2006 9:18 PM > To: Reinaldo Penno; David Meyer > Cc: speermint@ietf.org > Subject: Re: [Speermint] Terminology draft - Peering >=20 > >[[Reinaldo]] >=20 > >SPs or VSPs? >=20 > Both >=20 > >Is this transit network just providing IP transit or it is actually a > >Layer 5 transit network? I think the requirements are different in the > >two scenarios. >=20 > L5 >=20 > Richard >=20 >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 13.07.2006 04:32 > An: Stastny Richard; David Meyer > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Terminology draft - Peering >=20 >=20 >=20 > Hello Richard, >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, July 12, 2006 3:55 PM > > To: David Meyer > > Cc: speermint@ietf.org > > Subject: [Speermint] Terminology draft - Peering > > > > Proposed wording for Peering > > > > 4.2. Layer 5 Peering or Session Peering > > Layer 5 peering or Session Peering refers to interconnection of > > two (VoIP) service providers for the purposes of routing real-time > > (or quasi-real time) secure call signaling between their respective > > customers using SIP methods. Such interconnection may be direct or > > indirect. > > Media streams associated with this signaling (if any) are not > > constrained to follow the same set of paths. > > 4.3. Direct Peering > > Direct Peering covers all cases where the two SPs > [[Reinaldo]] >=20 > SPs or VSPs? >=20 > interconnect without > > using an intervening L5 network. Both SP must have a trust > relationship > > established (e.g. know they belong to the same federation (see > below) > > before opening up a secure communication path on L5. > > 4.4 Indirect or Transit Peering > > Indirect or transit peering is the establishment of a secure > signalling > > path via one (or more) referral or transit network(s). In this case > it > > is > > required that a trust relationship is established between the > > originating > > SP and the transit network on one side and the transit network and > the > > termination network on the other side before opening up a secure > > communication path on L5. > [[Reinaldo]] >=20 > Is this transit network just providing IP transit or it is actually a > Layer 5 transit network? I think the requirements are different in the > two scenarios. >=20 > > > > In addition, > > I suggest to delete the old section 4.4. on private peering because > > it is confusing and and out of scope anyway > > > > > > > > _______________________________________________ > > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 13 11:38:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13Go-0004La-Du; Thu, 13 Jul 2006 11:38:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13Gm-0004LV-Tm for speermint@ietf.org; Thu, 13 Jul 2006 11:38:28 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G13Gj-00036U-N1 for speermint@ietf.org; Thu, 13 Jul 2006 11:38:28 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 13 Jul 2006 11:38:39 -0400 id 01588101.44B668FF.000044FC Message-ID: <44B668EA.7010500@hxr.us> Date: Thu, 13 Jul 2006 11:38:18 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Speermint] Terminology draft - Peering References: <9BD5D7887235424FA97DFC223CAE3C2804DA9B43@proton.jnpr.net> <32755D354E6B65498C3BD9FD496C7D462C4B21@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B21@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 Stastny Richard wrote: > If VSP B is giving A all what he needs, does he need to care how > VSP B and C are doing this? Yes. We do care if any transcoding occurs and we do care if the termination is on the PSTN. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 13 11:42:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13Kv-0004ZH-6O; Thu, 13 Jul 2006 11:42:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13Kt-0004ZC-Fp for speermint@ietf.org; Thu, 13 Jul 2006 11:42:43 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G13Ks-0003J8-5Y for speermint@ietf.org; Thu, 13 Jul 2006 11:42:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 17:39:56 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B25@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: AcamkkOerj0xRO52TdWw7iPWThYB1AAAFPGN References: <9BD5D7887235424FA97DFC223CAE3C2804DA9B43@proton.jnpr.net> <32755D354E6B65498C3BD9FD496C7D462C4B21@oefeg-s04.oefeg.loc> <44B668EA.7010500@hxr.us> From: "Stastny Richard" To: "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 You are still in the signalling path =20 Regarding transcoding, we are talking here only about L5 =20 Richard ________________________________ Von: Andrew Newton [mailto:andy@hxr.us] Gesendet: Do 13.07.2006 17:38 An: Stastny Richard Cc: Reinaldo Penno; Uzelac, Adam; David Meyer; speermint@ietf.org Betreff: Re: [Speermint] Terminology draft - Peering Stastny Richard wrote: > If VSP B is giving A all what he needs, does he need to care how > VSP B and C are doing this? Yes. We do care if any transcoding occurs and we do care if the termination is on the PSTN. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 13 11:47:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13P3-0004k4-CV; Thu, 13 Jul 2006 11:47:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13P1-0004j8-R0 for speermint@ietf.org; Thu, 13 Jul 2006 11:46:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G13P1-0003RL-OC for speermint@ietf.org; Thu, 13 Jul 2006 11:46:59 -0400 Received: from borg.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G13Oz-0001S3-3d for speermint@ietf.org; Thu, 13 Jul 2006 11:46:59 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 13 Jul 2006 08:46:56 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="567596907:sNHT37802756" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 11:46:54 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804DA9B88@proton.jnpr.net> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B24@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAALHsGkAADlMwAAAfQkiAACHSfA= From: "Reinaldo Penno" To: "Stastny Richard" , "David Meyer" X-Spam-Score: -1.3 (-) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 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 So, what I'm trying to say is that the domain part of the AOR does not tell you which VSP actually hosts it. You can have vanity domains, company domains, etc, etc. Just like you can have a domain at your home but use your providers SMTP to relay email to you. Okay, let's put some call flows around it putting the federation thing aside for a moment. So, adapted from RFC 3263...example.com is actually at vspc.com As an example, consider a client that wishes to resolve sip:user@example.com. The client performs a NAPTR query for that domain, and the following NAPTR records are returned: ; order pref flags service regexp replacement IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.vspb.com. IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.vspb.com IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.vspb.com. This indicates that the server supports TLS over TCP, TCP, and UDP, in that order of preference. Since the client supports TCP and UDP, TCP will be used, targeted to a host determined by an SRV lookup of _sip._tcp.vspb.com. That lookup would return: ;; Priority Weight Port Target IN SRV 0 1 5060 server1.vspb.com IN SRV 0 2 5060 server2.vspb.com When the INVITE gets to server1.vspb.com it would eventually send to server1.vspc.com because that's the proxy/VSP that provides VoIP services to example.com. I might begetting this wrong, is there something wrong with this example? Thanks, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, July 13, 2006 8:28 AM > To: Reinaldo Penno; David Meyer > Cc: speermint@ietf.org > Subject: Re: [Speermint] Terminology draft - Peering >=20 > I think we are getting ahead of ourselves here >=20 > I always have to start with the AoR and look up the domain there >=20 > Here I may find a NAPTR indicating the federation (and eventually a > policy) > and I alsi find there the 3263 NAPTR and SRV, pointing to the servers > where > I should send the invites to >=20 > If there is an indirect peering, I may be diverted to (the domain of) VSP > B, > where I also may finally look up the 3263 SRV to find the ingress points > to send the invite too. How VSP B is no going further to reach B is none > of my business >=20 > Richard >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 13.07.2006 17:19 > An: Stastny Richard; David Meyer > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Terminology draft - Peering >=20 >=20 >=20 > Richard, >=20 > I think you are assuming the domain part of AORs maps to the VSP that > actually host his VoIP service and this relationship is not well > defined. >=20 > I can be in VSP A and make a DNS query for alice@some-company.com and > get as a result a proxy server at VSP B. Now, some-company.com is > actually served by VSP C, but the DNS returns VSP B because that's where > you need to send your signaling to get to some-company.com >=20 > In this case, VSP A has no way of knowing that some-company.com is > actually "hosted" (for a lack of a better term) in VSP C. >=20 > A VSP can serve many domains. Just because the VSP is called vspb.com > does not mean it cannot serve, e.g., supervoip.com, voip'r'us.com, > voipathome.com, etc, etc >=20 > Thanks, >=20 > Reinaldo >=20 >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, July 13, 2006 8:02 AM > > To: Reinaldo Penno; David Meyer > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Terminology draft - Peering > > > > >VSPA <-----> VSP B <-----> VSP C > > > > >Is VSP B providing layer 5 "transit" or we can just say it peers with > A > > and B? > > > > >VSP A might not even know that is talking with VSP C through VSP B. > For > > >all purposes, VSP B is VSP C... > > > > VSP A must know that the call terminates at VSP C, because he > basically > > has > > an AoR for VSP C. > > > > He looks up VSP C and sees he cannot peer with VSP C directly, but > gets > > the pointer to VSP B (somehow) > > > > Now he peers with VSP B and VSP B peers with VSP C > > > > Richard > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Do 13.07.2006 15:49 > > An: Stastny Richard; David Meyer > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > I thought at some point we kind of agreed to get rid of the transit > > term, wasn't it? > > > > Anyway, in the following case > > > > VSPA <-----> VSP B <-----> VSP C > > > > Is VSP B providing layer 5 "transit" or we can just say it peers with > A > > and B? > > > > VSP A might not even know that is talking with VSP C through VSP B. > For > > all purposes, VSP B is VSP C... > > > > Thanks, > > > > Reinaldo > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, July 12, 2006 9:18 PM > > > To: Reinaldo Penno; David Meyer > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Terminology draft - Peering > > > > > > >[[Reinaldo]] > > > > > > >SPs or VSPs? > > > > > > Both > > > > > > >Is this transit network just providing IP transit or it is actually > a > > > >Layer 5 transit network? I think the requirements are different in > > the > > > >two scenarios. > > > > > > L5 > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Do 13.07.2006 04:32 > > > An: Stastny Richard; David Meyer > > > Cc: speermint@ietf.org > > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > > > > > Hello Richard, > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Wednesday, July 12, 2006 3:55 PM > > > > To: David Meyer > > > > Cc: speermint@ietf.org > > > > Subject: [Speermint] Terminology draft - Peering > > > > > > > > Proposed wording for Peering > > > > > > > > 4.2. Layer 5 Peering or Session Peering > > > > Layer 5 peering or Session Peering refers to interconnection of > > > > two (VoIP) service providers for the purposes of routing > > real-time > > > > (or quasi-real time) secure call signaling between their > > respective > > > > customers using SIP methods. Such interconnection may be > direct > > or > > > > indirect. > > > > Media streams associated with this signaling (if any) are not > > > > constrained to follow the same set of paths. > > > > 4.3. Direct Peering > > > > Direct Peering covers all cases where the two SPs > > > [[Reinaldo]] > > > > > > SPs or VSPs? > > > > > > interconnect without > > > > using an intervening L5 network. Both SP must have a trust > > > relationship > > > > established (e.g. know they belong to the same federation (see > > > below) > > > > before opening up a secure communication path on L5. > > > > 4.4 Indirect or Transit Peering > > > > Indirect or transit peering is the establishment of a secure > > > signalling > > > > path via one (or more) referral or transit network(s). In this > > case > > > it > > > > is > > > > required that a trust relationship is established between the > > > > originating > > > > SP and the transit network on one side and the transit network > > and > > > the > > > > termination network on the other side before opening up a > secure > > > > communication path on L5. > > > [[Reinaldo]] > > > > > > Is this transit network just providing IP transit or it is actually > a > > > Layer 5 transit network? I think the requirements are different in > the > > > two scenarios. > > > > > > > > > > > In addition, > > > > I suggest to delete the old section 4.4. on private peering > because > > > > it is confusing and and out of scope anyway > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 Jul 13 11:50:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13SZ-0005FL-Sl; Thu, 13 Jul 2006 11:50:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13SY-0005F3-HA for speermint@ietf.org; Thu, 13 Jul 2006 11:50:38 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G13SX-0003al-SK for speermint@ietf.org; Thu, 13 Jul 2006 11:50:38 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 13 Jul 2006 08:50:37 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="567597929:sNHT39766564" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 11:50:30 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804DA9B8D@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAALHsGkAADlMwAAAfQkiAACHSfAAAG7sYA== From: "Reinaldo Penno" To: "Stastny Richard" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d 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 think RFC3263 states it better than me " It is not necessary for the domain suffixes in the NAPTR replacement field to match the domain of the original query (i.e., example.com above). " thanks, reinaldo > -----Original Message----- > From: Reinaldo Penno > Sent: Thursday, July 13, 2006 8:47 AM > To: 'Stastny Richard'; David Meyer > Cc: speermint@ietf.org > Subject: RE: [Speermint] Terminology draft - Peering >=20 > So, what I'm trying to say is that the domain part of the AOR does not > tell you which VSP actually hosts it. You can have vanity domains, company > domains, etc, etc. Just like you can have a domain at your home but use > your providers SMTP to relay email to you. >=20 > Okay, let's put some call flows around it putting the federation thing > aside for a moment. So, adapted from RFC 3263...example.com is actually at > vspc.com >=20 > As an example, consider a client that wishes to resolve > sip:user@example.com. The client performs a NAPTR query for that > domain, and the following NAPTR records are returned: >=20 > ; order pref flags service regexp replacement > IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.vspb.com. > IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.vspb.com > IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.vspb.com. >=20 > This indicates that the server supports TLS over TCP, TCP, and UDP, > in that order of preference. Since the client supports TCP and UDP, > TCP will be used, targeted to a host determined by an SRV lookup of > _sip._tcp.vspb.com. That lookup would return: >=20 > ;; Priority Weight Port Target > IN SRV 0 1 5060 server1.vspb.com > IN SRV 0 2 5060 server2.vspb.com >=20 >=20 > When the INVITE gets to server1.vspb.com it would eventually send to > server1.vspc.com because that's the proxy/VSP that provides VoIP services > to example.com. I might begetting this wrong, is there something wrong > with this example? >=20 > Thanks, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, July 13, 2006 8:28 AM > > To: Reinaldo Penno; David Meyer > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Terminology draft - Peering > > > > I think we are getting ahead of ourselves here > > > > I always have to start with the AoR and look up the domain there > > > > Here I may find a NAPTR indicating the federation (and eventually a > > policy) > > and I alsi find there the 3263 NAPTR and SRV, pointing to the servers > > where > > I should send the invites to > > > > If there is an indirect peering, I may be diverted to (the domain of) > VSP > > B, > > where I also may finally look up the 3263 SRV to find the ingress points > > to send the invite too. How VSP B is no going further to reach B is none > > of my business > > > > Richard > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Do 13.07.2006 17:19 > > An: Stastny Richard; David Meyer > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > Richard, > > > > I think you are assuming the domain part of AORs maps to the VSP that > > actually host his VoIP service and this relationship is not well > > defined. > > > > I can be in VSP A and make a DNS query for alice@some-company.com and > > get as a result a proxy server at VSP B. Now, some-company.com is > > actually served by VSP C, but the DNS returns VSP B because that's where > > you need to send your signaling to get to some-company.com > > > > In this case, VSP A has no way of knowing that some-company.com is > > actually "hosted" (for a lack of a better term) in VSP C. > > > > A VSP can serve many domains. Just because the VSP is called vspb.com > > does not mean it cannot serve, e.g., supervoip.com, voip'r'us.com, > > voipathome.com, etc, etc > > > > Thanks, > > > > Reinaldo > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, July 13, 2006 8:02 AM > > > To: Reinaldo Penno; David Meyer > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Terminology draft - Peering > > > > > > >VSPA <-----> VSP B <-----> VSP C > > > > > > >Is VSP B providing layer 5 "transit" or we can just say it peers with > > A > > > and B? > > > > > > >VSP A might not even know that is talking with VSP C through VSP B. > > For > > > >all purposes, VSP B is VSP C... > > > > > > VSP A must know that the call terminates at VSP C, because he > > basically > > > has > > > an AoR for VSP C. > > > > > > He looks up VSP C and sees he cannot peer with VSP C directly, but > > gets > > > the pointer to VSP B (somehow) > > > > > > Now he peers with VSP B and VSP B peers with VSP C > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Do 13.07.2006 15:49 > > > An: Stastny Richard; David Meyer > > > Cc: speermint@ietf.org > > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > > > > > I thought at some point we kind of agreed to get rid of the transit > > > term, wasn't it? > > > > > > Anyway, in the following case > > > > > > VSPA <-----> VSP B <-----> VSP C > > > > > > Is VSP B providing layer 5 "transit" or we can just say it peers with > > A > > > and B? > > > > > > VSP A might not even know that is talking with VSP C through VSP B. > > For > > > all purposes, VSP B is VSP C... > > > > > > Thanks, > > > > > > Reinaldo > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Wednesday, July 12, 2006 9:18 PM > > > > To: Reinaldo Penno; David Meyer > > > > Cc: speermint@ietf.org > > > > Subject: Re: [Speermint] Terminology draft - Peering > > > > > > > > >[[Reinaldo]] > > > > > > > > >SPs or VSPs? > > > > > > > > Both > > > > > > > > >Is this transit network just providing IP transit or it is actually > > a > > > > >Layer 5 transit network? I think the requirements are different in > > > the > > > > >two scenarios. > > > > > > > > L5 > > > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Gesendet: Do 13.07.2006 04:32 > > > > An: Stastny Richard; David Meyer > > > > Cc: speermint@ietf.org > > > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > > > > > > > > > Hello Richard, > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, July 12, 2006 3:55 PM > > > > > To: David Meyer > > > > > Cc: speermint@ietf.org > > > > > Subject: [Speermint] Terminology draft - Peering > > > > > > > > > > Proposed wording for Peering > > > > > > > > > > 4.2. Layer 5 Peering or Session Peering > > > > > Layer 5 peering or Session Peering refers to interconnection of > > > > > two (VoIP) service providers for the purposes of routing > > > real-time > > > > > (or quasi-real time) secure call signaling between their > > > respective > > > > > customers using SIP methods. Such interconnection may be > > direct > > > or > > > > > indirect. > > > > > Media streams associated with this signaling (if any) are not > > > > > constrained to follow the same set of paths. > > > > > 4.3. Direct Peering > > > > > Direct Peering covers all cases where the two SPs > > > > [[Reinaldo]] > > > > > > > > SPs or VSPs? > > > > > > > > interconnect without > > > > > using an intervening L5 network. Both SP must have a trust > > > > relationship > > > > > established (e.g. know they belong to the same federation (see > > > > below) > > > > > before opening up a secure communication path on L5. > > > > > 4.4 Indirect or Transit Peering > > > > > Indirect or transit peering is the establishment of a secure > > > > signalling > > > > > path via one (or more) referral or transit network(s). In this > > > case > > > > it > > > > > is > > > > > required that a trust relationship is established between the > > > > > originating > > > > > SP and the transit network on one side and the transit network > > > and > > > > the > > > > > termination network on the other side before opening up a > > secure > > > > > communication path on L5. > > > > [[Reinaldo]] > > > > > > > > Is this transit network just providing IP transit or it is actually > > a > > > > Layer 5 transit network? I think the requirements are different in > > the > > > > two scenarios. > > > > > > > > > > > > > > In addition, > > > > > I suggest to delete the old section 4.4. on private peering > > because > > > > > it is confusing and and out of scope anyway > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 Jul 13 12:01:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13cb-0006hq-5p; Thu, 13 Jul 2006 12:01:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13cZ-0006hJ-GQ for Speermint@ietf.org; Thu, 13 Jul 2006 12:00:59 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G13cY-0004Cy-UX for Speermint@ietf.org; Thu, 13 Jul 2006 12:00:59 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 13 Jul 2006 09:00:57 -0700 X-IronPort-AV: i="4.06,238,1149490800"; d="scan'208"; a="1838204422:sNHT3513867654" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DG0uU2028500; Thu, 13 Jul 2006 09:00:56 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6DG0u79000205; Thu, 13 Jul 2006 09:00:56 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 12:00:56 -0400 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] TLS, etc - Local-policy versus WG mandate Date: Thu, 13 Jul 2006 12:00:55 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301B362E7@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAoCKnQAARKCvA= From: "Michael Hammer \(mhammer\)" To: "David Schwartz" , "Uzelac, Adam" , X-OriginalArrivalTime: 13 Jul 2006 16:00:56.0347 (UTC) FILETIME=[867F5EB0:01C6A695] DKIM-Signature: a=rsa-sha1; q=dns; l=4931; t=1152806457; x=1153670457; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20TLS, =20etc=20-=20Local-policy=20versus=20WG=20mand ate; X=v=3Dcisco.com=3B=20h=3D2VnnJdMEaY5C8ig4LBewTc6BmaE=3D; b=fWjIFWqJLgtcBTieWJh+z4mtFVfwfQu0TtXNVhBNK9JczTLdhroVAHgBTH7S+mdiFxqVS33e cuHtDKLTPIYTurIJ2+eDKbJCDsnQJCOGIf0ui4L7O1wZJ00LygHt/iA/; Authentication-Results: sj-dkim-7.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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 Inline...=20 > -----Original Message----- > From: David Schwartz [mailto:David.Schwartz@Kayote.com]=20 > Sent: Thursday, July 13, 2006 10:05 AM > To: Uzelac, Adam; Speermint@ietf.org > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 > So here are my two cents (just repeating what I said at the session) >=20 > My claim which was not directly rebuffed is why=20 > authentication is any different than any other policy issue.=20 > As far as I can tell there are 2 not 3 issues that need to be=20 > resolved for peering to occur. >=20 > 1. Where is the other side > 2. Can we communicate >=20 > If we focus on the second issue it includes things like > =20 > * Will the other side even accept a call from me > * Assuming other side will accept my calls > * Which authentication mechanism do I use for this=20 > communication- if > any > * what are the ground rules for communication (e.g. specific codecs) > * etc. >=20 > I think of federations as shared namespace NOT policy.=20 I disagree. My view of federation is having a shared policy, ie. rules of engagement some of the most important ones center around security and trust, and independent of namespaces. The policy is about having a common denominator, such that you are guaranteed that you share at least one code, share at least one security mechanism, in order to assure that the communication will go through. > Federations are comprised of one namespace and multiple=20 > policy federations describing the relationships between the=20 > members. This is why for the life of me I cannot understand=20 > why it is not ok with me to peer with A via TLS and with B=20 > with IPSec and with 3 with no authentication at all. > Authentication is just a policy decision and should NOT be mandated. If more than one mechanism is agreed to be supported, there is not reason that you couldn't do that. =20 > I know everybody will yell at this but to me making ANY=20 > security mechanism mandatory is tantamount to making a=20 > minimal codec set mandatory and we know how this list reacted=20 > when that was proposed.=20 Mandatory to support, not necessarily use. > If any member is dumb enough not to implement TLS or IPSec or=20 > some other security mechanism he will soon find that no one=20 > will accept traffic from him and implement it then. Even if A did only TLS and B did only IPSEC, what would be the point of them being in a federation together? > We do not have to mandate not being STUPID.=20 But, we do need to mandate certain things so that we don't do something stupid. :) Mike >=20 > Cheers, >=20 > David >=20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, July 12, 2006 9:44 PM > To: Speermint@ietf.org > Subject: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 > Pertaining to the "To TLS or not TLS" discussion in the WG=20 > sessions, time didn't permit a proper tomato tossing session=20 > at the WG session - but one comment was made about mandating=20 > such things as TLS, etc - to which a rebuttal was made that=20 > the type of authentication and authorization used and=20 > implemented is an issue of local policy and therefore=20 > shouldn't be mandated. =20 >=20 > For fear of starting a "great taste" versus "less filling"=20 > argument - Let me start this way....I agree with what=20 > appeared to be consensus in the WG session that there needs=20 > to be first a Discovery procedure, then an Authentication=20 > procedure, and finally connecting the call. The methods upon=20 > which each step along the way is done should not to so narrow=20 > as to exclude popular and in some cases widely adopted methods. > Speermint should provide the BCP - but does that really need=20 > to exclude other plausible and practical models? It's=20 > important to note that I believe TLS is the most appropriate,=20 > practical and logical approach. I also believe the there are=20 > valid reasons for other approaches to authenticate. The same=20 > holds true for methods of discovery.=20 >=20 > So the question for the group and possibly some guidance from=20 > the chairs here?!?!? - Should an undertaking to determine=20 > what should be determined via local policy versus mandated=20 > via 'MUSTs' be done? Is this a section for the requirements doc? >=20 > I would like to thank Rohan for bringing this issue to the=20 > forefront in a lightning-rod manner!! ;) >=20 > Regards, >=20 > Adam >=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 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 13 12:08:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13jx-00079P-E7; Thu, 13 Jul 2006 12:08:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13ji-00078T-5Z for Speermint@ietf.org; Thu, 13 Jul 2006 12:08:23 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G13jh-0004UF-NN for Speermint@ietf.org; Thu, 13 Jul 2006 12:08:22 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 13 Jul 2006 09:08:20 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="567602900:sNHT34515848" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate Date: Thu, 13 Jul 2006 12:08:16 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804DA9BA0@proton.jnpr.net> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301B362E7@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAoCKnQAARKCvAAAG3Z4A== From: "Reinaldo Penno" To: "Michael Hammer \(mhammer\)" , "David Schwartz" , "Uzelac, Adam" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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 inline > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, July 13, 2006 9:01 AM > To: David Schwartz; Uzelac, Adam; Speermint@ietf.org > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 > Inline... >=20 > > -----Original Message----- > > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > Sent: Thursday, July 13, 2006 10:05 AM > > To: Uzelac, Adam; Speermint@ietf.org > > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate > > > > So here are my two cents (just repeating what I said at the session) > > > > My claim which was not directly rebuffed is why > > authentication is any different than any other policy issue. > > As far as I can tell there are 2 not 3 issues that need to be > > resolved for peering to occur. > > > > 1. Where is the other side > > 2. Can we communicate > > > > If we focus on the second issue it includes things like > > > > * Will the other side even accept a call from me > > * Assuming other side will accept my calls > > * Which authentication mechanism do I use for this > > communication- if > > any > > * what are the ground rules for communication (e.g. specific codecs) > > * etc. > > > > I think of federations as shared namespace NOT policy. >=20 > I disagree. My view of federation is having a shared policy, ie. rules > of engagement some of the most important ones center around security and > trust, and independent of namespaces. >=20 > The policy is about having a common denominator, such that you are > guaranteed that you share at least one code, share at least one security > mechanism, in order to assure that the communication will go through. >=20 >=20 > > Federations are comprised of one namespace and multiple > > policy federations describing the relationships between the > > members. This is why for the life of me I cannot understand > > why it is not ok with me to peer with A via TLS and with B > > with IPSec and with 3 with no authentication at all. > > Authentication is just a policy decision and should NOT be mandated. >=20 > If more than one mechanism is agreed to be supported, there is not > reason that you couldn't do that. >=20 >=20 > > I know everybody will yell at this but to me making ANY > > security mechanism mandatory is tantamount to making a > > minimal codec set mandatory and we know how this list reacted > > when that was proposed. >=20 > Mandatory to support, not necessarily use. >=20 >=20 > > If any member is dumb enough not to implement TLS or IPSec or > > some other security mechanism he will soon find that no one > > will accept traffic from him and implement it then. >=20 > Even if A did only TLS and B did only IPSEC, what would be the point of > them being in a federation together? >=20 >=20 [[Reinaldo]]=20 For this very reason you stated. A can be reached by TLS directly or through B for those that implement IPSec.=20 In other words, a federation does not need only to provide a common denominator but can also provide more choices as the sum of the parts. Wouldn't that be valuable? > > We do not have to mandate not being STUPID. >=20 > But, we do need to mandate certain things so that we don't do something > stupid. :) >=20 > Mike >=20 >=20 > > > > Cheers, > > > > David > > > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Wednesday, July 12, 2006 9:44 PM > > To: Speermint@ietf.org > > Subject: [Speermint] TLS, etc - Local-policy versus WG mandate > > > > Pertaining to the "To TLS or not TLS" discussion in the WG > > sessions, time didn't permit a proper tomato tossing session > > at the WG session - but one comment was made about mandating > > such things as TLS, etc - to which a rebuttal was made that > > the type of authentication and authorization used and > > implemented is an issue of local policy and therefore > > shouldn't be mandated. > > > > For fear of starting a "great taste" versus "less filling" > > argument - Let me start this way....I agree with what > > appeared to be consensus in the WG session that there needs > > to be first a Discovery procedure, then an Authentication > > procedure, and finally connecting the call. The methods upon > > which each step along the way is done should not to so narrow > > as to exclude popular and in some cases widely adopted methods. > > Speermint should provide the BCP - but does that really need > > to exclude other plausible and practical models? It's > > important to note that I believe TLS is the most appropriate, > > practical and logical approach. I also believe the there are > > valid reasons for other approaches to authenticate. The same > > holds true for methods of discovery. > > > > So the question for the group and possibly some guidance from > > the chairs here?!?!? - Should an undertaking to determine > > what should be determined via local policy versus mandated > > via 'MUSTs' be done? Is this a section for the requirements doc? > > > > I would like to thank Rohan for bringing this issue to the > > forefront in a lightning-rod manner!! ;) > > > > Regards, > > > > Adam > > > > _______________________________________________ > > 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 > > >=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 Thu Jul 13 12:23:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13yg-0001cU-PA; Thu, 13 Jul 2006 12:23:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13yf-0001cO-PW for Speermint@ietf.org; Thu, 13 Jul 2006 12:23:49 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G13yf-0005AG-3s for Speermint@ietf.org; Thu, 13 Jul 2006 12:23:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] TLS, etc - Local-policy versus WG mandate Date: Thu, 13 Jul 2006 18:21:17 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B27@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAoCKnQAARKCvAAAG3Z4AAAiuCB References: <9BD5D7887235424FA97DFC223CAE3C2804DA9BA0@proton.jnpr.net> From: "Stastny Richard" To: "Reinaldo Penno" , "David Schwartz" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c 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 >In other words, a federation does not need only to provide a common >denominator but can also provide more choices as the sum of the parts. >Wouldn't that be valuable? maybe, but we also should obey KISS Richard ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Do 13.07.2006 18:08 An: Michael Hammer (mhammer); David Schwartz; Uzelac, Adam; = Speermint@ietf.org Betreff: RE: [Speermint] TLS, etc - Local-policy versus WG mandate inline > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, July 13, 2006 9:01 AM > To: David Schwartz; Uzelac, Adam; Speermint@ietf.org > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate > > Inline... > > > -----Original Message----- > > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > Sent: Thursday, July 13, 2006 10:05 AM > > To: Uzelac, Adam; Speermint@ietf.org > > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate > > > > So here are my two cents (just repeating what I said at the session) > > > > My claim which was not directly rebuffed is why > > authentication is any different than any other policy issue. > > As far as I can tell there are 2 not 3 issues that need to be > > resolved for peering to occur. > > > > 1. Where is the other side > > 2. Can we communicate > > > > If we focus on the second issue it includes things like > > > > * Will the other side even accept a call from me > > * Assuming other side will accept my calls > > * Which authentication mechanism do I use for this > > communication- if > > any > > * what are the ground rules for communication (e.g. specific codecs) > > * etc. > > > > I think of federations as shared namespace NOT policy. > > I disagree. My view of federation is having a shared policy, ie. rules > of engagement some of the most important ones center around security and > trust, and independent of namespaces. > > The policy is about having a common denominator, such that you are > guaranteed that you share at least one code, share at least one security > mechanism, in order to assure that the communication will go through. > > > > Federations are comprised of one namespace and multiple > > policy federations describing the relationships between the > > members. This is why for the life of me I cannot understand > > why it is not ok with me to peer with A via TLS and with B > > with IPSec and with 3 with no authentication at all. > > Authentication is just a policy decision and should NOT be mandated. > > If more than one mechanism is agreed to be supported, there is not > reason that you couldn't do that. > > > > I know everybody will yell at this but to me making ANY > > security mechanism mandatory is tantamount to making a > > minimal codec set mandatory and we know how this list reacted > > when that was proposed. > > Mandatory to support, not necessarily use. > > > > If any member is dumb enough not to implement TLS or IPSec or > > some other security mechanism he will soon find that no one > > will accept traffic from him and implement it then. > > Even if A did only TLS and B did only IPSEC, what would be the point of > them being in a federation together? > > [[Reinaldo]] For this very reason you stated. A can be reached by TLS directly or through B for those that implement IPSec. In other words, a federation does not need only to provide a common denominator but can also provide more choices as the sum of the parts. Wouldn't that be valuable? > > We do not have to mandate not being STUPID. > > But, we do need to mandate certain things so that we don't do something > stupid. :) > > Mike > > > > > > Cheers, > > > > David > > > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Wednesday, July 12, 2006 9:44 PM > > To: Speermint@ietf.org > > Subject: [Speermint] TLS, etc - Local-policy versus WG mandate > > > > Pertaining to the "To TLS or not TLS" discussion in the WG > > sessions, time didn't permit a proper tomato tossing session > > at the WG session - but one comment was made about mandating > > such things as TLS, etc - to which a rebuttal was made that > > the type of authentication and authorization used and > > implemented is an issue of local policy and therefore > > shouldn't be mandated. > > > > For fear of starting a "great taste" versus "less filling" > > argument - Let me start this way....I agree with what > > appeared to be consensus in the WG session that there needs > > to be first a Discovery procedure, then an Authentication > > procedure, and finally connecting the call. The methods upon > > which each step along the way is done should not to so narrow > > as to exclude popular and in some cases widely adopted methods. > > Speermint should provide the BCP - but does that really need > > to exclude other plausible and practical models? It's > > important to note that I believe TLS is the most appropriate, > > practical and logical approach. I also believe the there are > > valid reasons for other approaches to authenticate. The same > > holds true for methods of discovery. > > > > So the question for the group and possibly some guidance from > > the chairs here?!?!? - Should an undertaking to determine > > what should be determined via local policy versus mandated > > via 'MUSTs' be done? Is this a section for the requirements doc? > > > > I would like to thank Rohan for bringing this issue to the > > forefront in a lightning-rod manner!! ;) > > > > Regards, > > > > Adam > > > > _______________________________________________ > > 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 _______________________________________________ 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 Jul 13 12:28:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G142u-0001yO-Sn; Thu, 13 Jul 2006 12:28:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13EX-0002q8-F2 for speermint@ietf.org; Thu, 13 Jul 2006 11:36:09 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G1371-0001b4-RP for speermint@ietf.org; Thu, 13 Jul 2006 11:28:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 17:27:30 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B24@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAALHsGkAADlMwAAAfQki References: <9BD5D7887235424FA97DFC223CAE3C2804DA9B6C@proton.jnpr.net> From: "Stastny Richard" To: "Reinaldo Penno" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b 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 think we are getting ahead of ourselves here =20 I always have to start with the AoR and look up the domain there =20 Here I may find a NAPTR indicating the federation (and eventually a = policy) and I alsi find there the 3263 NAPTR and SRV, pointing to the servers = where I should send the invites to =20 If there is an indirect peering, I may be diverted to (the domain of) = VSP B, where I also may finally look up the 3263 SRV to find the ingress points to send the invite too. How VSP B is no going further to reach B is none = of my business =20 Richard ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Do 13.07.2006 17:19 An: Stastny Richard; David Meyer Cc: speermint@ietf.org Betreff: RE: [Speermint] Terminology draft - Peering Richard, I think you are assuming the domain part of AORs maps to the VSP that actually host his VoIP service and this relationship is not well defined. I can be in VSP A and make a DNS query for alice@some-company.com and get as a result a proxy server at VSP B. Now, some-company.com is actually served by VSP C, but the DNS returns VSP B because that's where you need to send your signaling to get to some-company.com In this case, VSP A has no way of knowing that some-company.com is actually "hosted" (for a lack of a better term) in VSP C. A VSP can serve many domains. Just because the VSP is called vspb.com does not mean it cannot serve, e.g., supervoip.com, voip'r'us.com, voipathome.com, etc, etc Thanks, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, July 13, 2006 8:02 AM > To: Reinaldo Penno; David Meyer > Cc: speermint@ietf.org > Subject: Re: [Speermint] Terminology draft - Peering > > >VSPA <-----> VSP B <-----> VSP C > > >Is VSP B providing layer 5 "transit" or we can just say it peers with A > and B? > > >VSP A might not even know that is talking with VSP C through VSP B. For > >all purposes, VSP B is VSP C... > > VSP A must know that the call terminates at VSP C, because he basically > has > an AoR for VSP C. > > He looks up VSP C and sees he cannot peer with VSP C directly, but gets > the pointer to VSP B (somehow) > > Now he peers with VSP B and VSP B peers with VSP C > > Richard > > ________________________________ > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 13.07.2006 15:49 > An: Stastny Richard; David Meyer > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Terminology draft - Peering > > > > I thought at some point we kind of agreed to get rid of the transit > term, wasn't it? > > Anyway, in the following case > > VSPA <-----> VSP B <-----> VSP C > > Is VSP B providing layer 5 "transit" or we can just say it peers with A > and B? > > VSP A might not even know that is talking with VSP C through VSP B. For > all purposes, VSP B is VSP C... > > Thanks, > > Reinaldo > > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, July 12, 2006 9:18 PM > > To: Reinaldo Penno; David Meyer > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Terminology draft - Peering > > > > >[[Reinaldo]] > > > > >SPs or VSPs? > > > > Both > > > > >Is this transit network just providing IP transit or it is actually a > > >Layer 5 transit network? I think the requirements are different in > the > > >two scenarios. > > > > L5 > > > > Richard > > > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Do 13.07.2006 04:32 > > An: Stastny Richard; David Meyer > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > Hello Richard, > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, July 12, 2006 3:55 PM > > > To: David Meyer > > > Cc: speermint@ietf.org > > > Subject: [Speermint] Terminology draft - Peering > > > > > > Proposed wording for Peering > > > > > > 4.2. Layer 5 Peering or Session Peering > > > Layer 5 peering or Session Peering refers to interconnection of > > > two (VoIP) service providers for the purposes of routing > real-time > > > (or quasi-real time) secure call signaling between their > respective > > > customers using SIP methods. Such interconnection may be direct > or > > > indirect. > > > Media streams associated with this signaling (if any) are not > > > constrained to follow the same set of paths. > > > 4.3. Direct Peering > > > Direct Peering covers all cases where the two SPs > > [[Reinaldo]] > > > > SPs or VSPs? > > > > interconnect without > > > using an intervening L5 network. Both SP must have a trust > > relationship > > > established (e.g. know they belong to the same federation (see > > below) > > > before opening up a secure communication path on L5. > > > 4.4 Indirect or Transit Peering > > > Indirect or transit peering is the establishment of a secure > > signalling > > > path via one (or more) referral or transit network(s). In this > case > > it > > > is > > > required that a trust relationship is established between the > > > originating > > > SP and the transit network on one side and the transit network > and > > the > > > termination network on the other side before opening up a secure > > > communication path on L5. > > [[Reinaldo]] > > > > Is this transit network just providing IP transit or it is actually a > > Layer 5 transit network? I think the requirements are different in the > > two scenarios. > > > > > > > > In addition, > > > I suggest to delete the old section 4.4. on private peering because > > > it is confusing and and out of scope anyway > > > > > > > > > > > > _______________________________________________ > > > 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 Jul 13 12:38:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14Cd-0002x6-BZ; Thu, 13 Jul 2006 12:38:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14Cc-0002x0-6R for speermint@ietf.org; Thu, 13 Jul 2006 12:38:14 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G14Ca-0005rF-Hl for speermint@ietf.org; Thu, 13 Jul 2006 12:38:14 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 13 Jul 2006 09:38:12 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="567611455:sNHT40495872" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 12:38:09 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804DA9BBF@proton.jnpr.net> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B26@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAALHsGkAADlMwAAAfQkiAACHSfAAAVhLCQAAsQbQ From: "Reinaldo Penno" To: "Stastny Richard" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf 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 There are many operational reasons... When VSP C is provisioning its customers, it points to VSP B because B can actually check certificate revocation, or can prevent some SIP DDoS attacks, or in some parts of the country C has no presence, so it uses VSP B to route it back to him, etc, etc Regards, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, July 13, 2006 9:16 AM > To: Reinaldo Penno; David Meyer > Cc: speermint@ietf.org > Subject: Re: [Speermint] Terminology draft - Peering >=20 > >When the INVITE gets to server1.vspb.com it would eventually send to > >server1.vspc.com because that's the proxy/VSP that provides VoIP > >services to example.com. I might begetting this wrong, is there > >something wrong with this example? >=20 > Simply: why is example.com entering > server1.vspb.com into the NAPTRs and > not server1.vspc.com? >=20 > How is vspb.com coming into play at all? >=20 > If you do this, everything is ok >=20 > Richard >=20 >=20 >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 13.07.2006 17:46 > An: Stastny Richard; David Meyer > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Terminology draft - Peering >=20 >=20 >=20 > So, what I'm trying to say is that the domain part of the AOR does not > tell you which VSP actually hosts it. You can have vanity domains, > company domains, etc, etc. Just like you can have a domain at your home > but use your providers SMTP to relay email to you. >=20 > Okay, let's put some call flows around it putting the federation thing > aside for a moment. So, adapted from RFC 3263...example.com is actually > at vspc.com >=20 > As an example, consider a client that wishes to resolve > sip:user@example.com. The client performs a NAPTR query for that > domain, and the following NAPTR records are returned: >=20 > ; order pref flags service regexp replacement > IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.vspb.com. > IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.vspb.com > IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.vspb.com. >=20 > This indicates that the server supports TLS over TCP, TCP, and UDP, > in that order of preference. Since the client supports TCP and UDP, > TCP will be used, targeted to a host determined by an SRV lookup of > _sip._tcp.vspb.com. That lookup would return: >=20 > ;; Priority Weight Port Target > IN SRV 0 1 5060 server1.vspb.com > IN SRV 0 2 5060 server2.vspb.com >=20 >=20 > When the INVITE gets to server1.vspb.com it would eventually send to > server1.vspc.com because that's the proxy/VSP that provides VoIP > services to example.com. I might begetting this wrong, is there > something wrong with this example? >=20 > Thanks, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, July 13, 2006 8:28 AM > > To: Reinaldo Penno; David Meyer > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Terminology draft - Peering > > > > I think we are getting ahead of ourselves here > > > > I always have to start with the AoR and look up the domain there > > > > Here I may find a NAPTR indicating the federation (and eventually a > > policy) > > and I alsi find there the 3263 NAPTR and SRV, pointing to the servers > > where > > I should send the invites to > > > > If there is an indirect peering, I may be diverted to (the domain of) > VSP > > B, > > where I also may finally look up the 3263 SRV to find the ingress > points > > to send the invite too. How VSP B is no going further to reach B is > none > > of my business > > > > Richard > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Do 13.07.2006 17:19 > > An: Stastny Richard; David Meyer > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > Richard, > > > > I think you are assuming the domain part of AORs maps to the VSP that > > actually host his VoIP service and this relationship is not well > > defined. > > > > I can be in VSP A and make a DNS query for alice@some-company.com and > > get as a result a proxy server at VSP B. Now, some-company.com is > > actually served by VSP C, but the DNS returns VSP B because that's > where > > you need to send your signaling to get to some-company.com > > > > In this case, VSP A has no way of knowing that some-company.com is > > actually "hosted" (for a lack of a better term) in VSP C. > > > > A VSP can serve many domains. Just because the VSP is called vspb.com > > does not mean it cannot serve, e.g., supervoip.com, voip'r'us.com, > > voipathome.com, etc, etc > > > > Thanks, > > > > Reinaldo > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, July 13, 2006 8:02 AM > > > To: Reinaldo Penno; David Meyer > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Terminology draft - Peering > > > > > > >VSPA <-----> VSP B <-----> VSP C > > > > > > >Is VSP B providing layer 5 "transit" or we can just say it peers > with > > A > > > and B? > > > > > > >VSP A might not even know that is talking with VSP C through VSP B. > > For > > > >all purposes, VSP B is VSP C... > > > > > > VSP A must know that the call terminates at VSP C, because he > > basically > > > has > > > an AoR for VSP C. > > > > > > He looks up VSP C and sees he cannot peer with VSP C directly, but > > gets > > > the pointer to VSP B (somehow) > > > > > > Now he peers with VSP B and VSP B peers with VSP C > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Do 13.07.2006 15:49 > > > An: Stastny Richard; David Meyer > > > Cc: speermint@ietf.org > > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > > > > > I thought at some point we kind of agreed to get rid of the transit > > > term, wasn't it? > > > > > > Anyway, in the following case > > > > > > VSPA <-----> VSP B <-----> VSP C > > > > > > Is VSP B providing layer 5 "transit" or we can just say it peers > with > > A > > > and B? > > > > > > VSP A might not even know that is talking with VSP C through VSP B. > > For > > > all purposes, VSP B is VSP C... > > > > > > Thanks, > > > > > > Reinaldo > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Wednesday, July 12, 2006 9:18 PM > > > > To: Reinaldo Penno; David Meyer > > > > Cc: speermint@ietf.org > > > > Subject: Re: [Speermint] Terminology draft - Peering > > > > > > > > >[[Reinaldo]] > > > > > > > > >SPs or VSPs? > > > > > > > > Both > > > > > > > > >Is this transit network just providing IP transit or it is > actually > > a > > > > >Layer 5 transit network? I think the requirements are different > in > > > the > > > > >two scenarios. > > > > > > > > L5 > > > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Gesendet: Do 13.07.2006 04:32 > > > > An: Stastny Richard; David Meyer > > > > Cc: speermint@ietf.org > > > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > > > > > > > > > Hello Richard, > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, July 12, 2006 3:55 PM > > > > > To: David Meyer > > > > > Cc: speermint@ietf.org > > > > > Subject: [Speermint] Terminology draft - Peering > > > > > > > > > > Proposed wording for Peering > > > > > > > > > > 4.2. Layer 5 Peering or Session Peering > > > > > Layer 5 peering or Session Peering refers to interconnection > of > > > > > two (VoIP) service providers for the purposes of routing > > > real-time > > > > > (or quasi-real time) secure call signaling between their > > > respective > > > > > customers using SIP methods. Such interconnection may be > > direct > > > or > > > > > indirect. > > > > > Media streams associated with this signaling (if any) are not > > > > > constrained to follow the same set of paths. > > > > > 4.3. Direct Peering > > > > > Direct Peering covers all cases where the two SPs > > > > [[Reinaldo]] > > > > > > > > SPs or VSPs? > > > > > > > > interconnect without > > > > > using an intervening L5 network. Both SP must have a trust > > > > relationship > > > > > established (e.g. know they belong to the same federation > (see > > > > below) > > > > > before opening up a secure communication path on L5. > > > > > 4.4 Indirect or Transit Peering > > > > > Indirect or transit peering is the establishment of a secure > > > > signalling > > > > > path via one (or more) referral or transit network(s). In > this > > > case > > > > it > > > > > is > > > > > required that a trust relationship is established between the > > > > > originating > > > > > SP and the transit network on one side and the transit > network > > > and > > > > the > > > > > termination network on the other side before opening up a > > secure > > > > > communication path on L5. > > > > [[Reinaldo]] > > > > > > > > Is this transit network just providing IP transit or it is > actually > > a > > > > Layer 5 transit network? I think the requirements are different in > > the > > > > two scenarios. > > > > > > > > > > > > > > In addition, > > > > > I suggest to delete the old section 4.4. on private peering > > because > > > > > it is confusing and and out of scope anyway > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 Jul 13 13:11:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14im-0006SW-M4; Thu, 13 Jul 2006 13:11:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14il-0006SR-Bg for Speermint@ietf.org; Thu, 13 Jul 2006 13:11:27 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G14ii-0007pp-SH for Speermint@ietf.org; Thu, 13 Jul 2006 13:11:27 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2006 13:11:25 -0400 X-IronPort-AV: i="4.06,238,1149480000"; d="scan'208"; a="92672330:sNHT30163608" 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.20060308/8.12.11) with ESMTP id k6DHBOYi019444; Thu, 13 Jul 2006 13:11:24 -0400 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 k6DHBNdW028941; Thu, 13 Jul 2006 13:11:24 -0400 (EDT) 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, 13 Jul 2006 13:11:23 -0400 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] TLS, etc - Local-policy versus WG mandate Date: Thu, 13 Jul 2006 13:11:22 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301B36328@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAoCKnQAARKCvAAAG3Z4AAAiuCBAAG44SA= From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Reinaldo Penno" , "David Schwartz" , X-OriginalArrivalTime: 13 Jul 2006 17:11:23.0773 (UTC) FILETIME=[5E3D62D0:01C6A69F] DKIM-Signature: a=rsa-sha1; q=dns; l=7549; t=1152810684; x=1153674684; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20TLS, =20etc=20-=20Local-policy=20versus=20WG=20mand ate |To:=22Stastny=20Richard=22=20, =0A=20=20=20=20=20= 20=20=20=22Reinaldo=20Penno=22=20, =0A=20=20=20=20=20=20 =20=20=22David=20Schwartz=22=20, =20; X=v=3Dcisco.com=3B=20h=3D2VnnJdMEaY5C8ig4LBewTc6BmaE=3D; b=FFM/pa5Y6mitwSOzQ73+veoV9uAHHKUzNiuAwuo0GAzdT91AEIzRkV7uDekCslQ0ZPVOLL3z VfpXsTQWmCzGdu+frWRyErTUFYRMNMvrNdkoBdUjIL+TAx5jZOwIxO1F; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 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 Agree. It's a balancing act. Having a default is only there to assure that disjoint sets don't occur. Mike =20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Thursday, July 13, 2006 12:21 PM > To: Reinaldo Penno; David Schwartz; Speermint@ietf.org > Subject: Re: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 > >In other words, a federation does not need only to provide a common=20 > >denominator but can also provide more choices as the sum of=20 > the parts. >=20 > >Wouldn't that be valuable? >=20 > maybe, but we also should obey KISS >=20 > Richard >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 13.07.2006 18:08 > An: Michael Hammer (mhammer); David Schwartz; Uzelac, Adam;=20 > Speermint@ietf.org > Betreff: RE: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 >=20 >=20 > inline >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Thursday, July 13, 2006 9:01 AM > > To: David Schwartz; Uzelac, Adam; Speermint@ietf.org > > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate > > > > Inline... > > > > > -----Original Message----- > > > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > > Sent: Thursday, July 13, 2006 10:05 AM > > > To: Uzelac, Adam; Speermint@ietf.org > > > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate > > > > > > So here are my two cents (just repeating what I said at=20 > the session) > > > > > > My claim which was not directly rebuffed is why authentication is=20 > > > any different than any other policy issue. > > > As far as I can tell there are 2 not 3 issues that need to be=20 > > > resolved for peering to occur. > > > > > > 1. Where is the other side > > > 2. Can we communicate > > > > > > If we focus on the second issue it includes things like > > > > > > * Will the other side even accept a call from me > > > * Assuming other side will accept my calls > > > * Which authentication mechanism do I use for this > > > communication- if > > > any > > > * what are the ground rules for communication (e.g.=20 > specific codecs) > > > * etc. > > > > > > I think of federations as shared namespace NOT policy. > > > > I disagree. My view of federation is having a shared policy, ie. > rules > > of engagement some of the most important ones center around security > and > > trust, and independent of namespaces. > > > > The policy is about having a common denominator, such that you are=20 > > guaranteed that you share at least one code, share at least one > security > > mechanism, in order to assure that the communication will=20 > go through. > > > > > > > Federations are comprised of one namespace and multiple policy=20 > > > federations describing the relationships between the=20 > members. This=20 > > > is why for the life of me I cannot understand why it is=20 > not ok with=20 > > > me to peer with A via TLS and with B with IPSec and with=20 > 3 with no=20 > > > authentication at all. > > > Authentication is just a policy decision and should NOT=20 > be mandated. > > > > If more than one mechanism is agreed to be supported, there is not=20 > > reason that you couldn't do that. > > > > > > > I know everybody will yell at this but to me making ANY security=20 > > > mechanism mandatory is tantamount to making a minimal codec set=20 > > > mandatory and we know how this list reacted when that was=20 > proposed. > > > > Mandatory to support, not necessarily use. > > > > > > > If any member is dumb enough not to implement TLS or=20 > IPSec or some=20 > > > other security mechanism he will soon find that no one=20 > will accept=20 > > > traffic from him and implement it then. > > > > Even if A did only TLS and B did only IPSEC, what would be the point > of > > them being in a federation together? > > > > > [[Reinaldo]] >=20 > For this very reason you stated. A can be reached by TLS=20 > directly or through B for those that implement IPSec. >=20 > In other words, a federation does not need only to provide a=20 > common denominator but can also provide more choices as the=20 > sum of the parts. >=20 > Wouldn't that be valuable? >=20 > > > We do not have to mandate not being STUPID. > > > > But, we do need to mandate certain things so that we don't do > something > > stupid. :) > > > > Mike > > > > > > > > > > Cheers, > > > > > > David > > > > > > -----Original Message----- > > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > > Sent: Wednesday, July 12, 2006 9:44 PM > > > To: Speermint@ietf.org > > > Subject: [Speermint] TLS, etc - Local-policy versus WG mandate > > > > > > Pertaining to the "To TLS or not TLS" discussion in the=20 > WG sessions,=20 > > > time didn't permit a proper tomato tossing session at the=20 > WG session=20 > > > - but one comment was made about mandating such things as=20 > TLS, etc -=20 > > > to which a rebuttal was made that the type of authentication and=20 > > > authorization used and implemented is an issue of local=20 > policy and=20 > > > therefore shouldn't be mandated. > > > > > > For fear of starting a "great taste" versus "less filling" > > > argument - Let me start this way....I agree with what=20 > appeared to be=20 > > > consensus in the WG session that there needs to be first=20 > a Discovery=20 > > > procedure, then an Authentication procedure, and finally=20 > connecting=20 > > > the call. The methods upon which each step along the way is done=20 > > > should not to so narrow as to exclude popular and in some cases=20 > > > widely adopted methods. > > > Speermint should provide the BCP - but does that really need to=20 > > > exclude other plausible and practical models? It's important to=20 > > > note that I believe TLS is the most appropriate, practical and=20 > > > logical approach. I also believe the there are valid reasons for=20 > > > other approaches to authenticate. The same holds true=20 > for methods=20 > > > of discovery. > > > > > > So the question for the group and possibly some guidance from the=20 > > > chairs here?!?!? - Should an undertaking to determine=20 > what should be=20 > > > determined via local policy versus mandated via 'MUSTs'=20 > be done? Is=20 > > > this a section for the requirements doc? > > > > > > I would like to thank Rohan for bringing this issue to=20 > the forefront=20 > > > in a lightning-rod manner!! ;) > > > > > > Regards, > > > > > > Adam > > > > > > _______________________________________________ > > > 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 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=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 Jul 13 13:20:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14rg-00071f-4x; Thu, 13 Jul 2006 13:20:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14re-00071X-K0 for speermint@ietf.org; Thu, 13 Jul 2006 13:20:38 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G14ra-0008Ei-KB for speermint@ietf.org; Thu, 13 Jul 2006 13:20:38 -0400 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.22220533; Thu, 13 Jul 2006 13:20:01 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 13:20:00 -0400 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] Terminology draft - Peering Date: Thu, 13 Jul 2006 13:20:00 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96F55C31@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAHlEU0A== From: "Livingood, Jason" To: "Reinaldo Penno" , "Stastny Richard" , "David Meyer" X-OriginalArrivalTime: 13 Jul 2006 17:20:01.0088 (UTC) FILETIME=[92956400:01C6A6A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 =20 > > 4.3. Direct Peering > > Direct Peering covers all cases where the two SPs > [[Reinaldo]]=20 >=20 > SPs or VSPs? I think we ought to just say "domains" and not go down this road again on ITSP vs VSP vs SP vs Carrier vs whatever. ;-) Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 13 13:20:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14rl-00075J-Vr; Thu, 13 Jul 2006 13:20:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14rj-000757-UF for speermint@ietf.org; Thu, 13 Jul 2006 13:20:43 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G14rh-0008Ei-Qv for speermint@ietf.org; Thu, 13 Jul 2006 13:20:43 -0400 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.22220534; Thu, 13 Jul 2006 13:20:02 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 13:20:01 -0400 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] Terminology draft - Peering Date: Thu, 13 Jul 2006 13:20:00 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96F55C32@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAALHsGkAADlMwAAD+mIA From: "Livingood, Jason" To: "Reinaldo Penno" , "Stastny Richard" , "David Meyer" X-OriginalArrivalTime: 13 Jul 2006 17:20:01.0401 (UTC) FILETIME=[92C52690:01C6A6A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 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 Sounds like this could certainly be the case of enterprise domains, if there was some kind of federation aggregating them up and perhaps providing network services. Is that a fair example? Jason=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 > Sent: Thursday, July 13, 2006 11:20 AM > To: Stastny Richard; David Meyer > Cc: speermint@ietf.org > Subject: RE: [Speermint] Terminology draft - Peering >=20 > Richard, >=20 > I think you are assuming the domain part of AORs maps to the=20 > VSP that actually host his VoIP service and this relationship=20 > is not well defined. >=20 > I can be in VSP A and make a DNS query for=20 > alice@some-company.com and get as a result a proxy server at=20 > VSP B. Now, some-company.com is actually served by VSP C, but=20 > the DNS returns VSP B because that's where you need to send=20 > your signaling to get to some-company.com >=20 > In this case, VSP A has no way of knowing that=20 > some-company.com is actually "hosted" (for a lack of a better=20 > term) in VSP C.=20 >=20 > A VSP can serve many domains. Just because the VSP is called=20 > vspb.com does not mean it cannot serve, e.g., supervoip.com,=20 > voip'r'us.com, voipathome.com, etc, etc >=20 > Thanks, >=20 > Reinaldo >=20 >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, July 13, 2006 8:02 AM > > To: Reinaldo Penno; David Meyer > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Terminology draft - Peering > >=20 > > >VSPA <-----> VSP B <-----> VSP C > >=20 > > >Is VSP B providing layer 5 "transit" or we can just say it=20 > peers with > A > > and B? > >=20 > > >VSP A might not even know that is talking with VSP C through VSP B. > For > > >all purposes, VSP B is VSP C... > >=20 > > VSP A must know that the call terminates at VSP C, because he > basically > > has > > an AoR for VSP C. > >=20 > > He looks up VSP C and sees he cannot peer with VSP C directly, but > gets > > the pointer to VSP B (somehow) > >=20 > > Now he peers with VSP B and VSP B peers with VSP C > >=20 > > Richard > >=20 > > ________________________________ > >=20 > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Do 13.07.2006 15:49 > > An: Stastny Richard; David Meyer > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Terminology draft - Peering > >=20 > >=20 > >=20 > > I thought at some point we kind of agreed to get rid of the transit=20 > > term, wasn't it? > >=20 > > Anyway, in the following case > >=20 > > VSPA <-----> VSP B <-----> VSP C > >=20 > > Is VSP B providing layer 5 "transit" or we can just say it=20 > peers with > A > > and B? > >=20 > > VSP A might not even know that is talking with VSP C through VSP B. > For > > all purposes, VSP B is VSP C... > >=20 > > Thanks, > >=20 > > Reinaldo > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, July 12, 2006 9:18 PM > > > To: Reinaldo Penno; David Meyer > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Terminology draft - Peering > > > > > > >[[Reinaldo]] > > > > > > >SPs or VSPs? > > > > > > Both > > > > > > >Is this transit network just providing IP transit or it=20 > is actually > a > > > >Layer 5 transit network? I think the requirements are=20 > different in > > the > > > >two scenarios. > > > > > > L5 > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Do 13.07.2006 04:32 > > > An: Stastny Richard; David Meyer > > > Cc: speermint@ietf.org > > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > > > > > Hello Richard, > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Wednesday, July 12, 2006 3:55 PM > > > > To: David Meyer > > > > Cc: speermint@ietf.org > > > > Subject: [Speermint] Terminology draft - Peering > > > > > > > > Proposed wording for Peering > > > > > > > > 4.2. Layer 5 Peering or Session Peering > > > > Layer 5 peering or Session Peering refers to=20 > interconnection of > > > > two (VoIP) service providers for the purposes of routing > > real-time > > > > (or quasi-real time) secure call signaling between their > > respective > > > > customers using SIP methods. Such interconnection may be > direct > > or > > > > indirect. > > > > Media streams associated with this signaling (if any) are not > > > > constrained to follow the same set of paths. > > > > 4.3. Direct Peering > > > > Direct Peering covers all cases where the two SPs > > > [[Reinaldo]] > > > > > > SPs or VSPs? > > > > > > interconnect without > > > > using an intervening L5 network. Both SP must have a trust > > > relationship > > > > established (e.g. know they belong to the same=20 > federation (see > > > below) > > > > before opening up a secure communication path on L5. > > > > 4.4 Indirect or Transit Peering > > > > Indirect or transit peering is the establishment of a secure > > > signalling > > > > path via one (or more) referral or transit=20 > network(s). In this > > case > > > it > > > > is > > > > required that a trust relationship is established=20 > between the=20 > > > > originating > > > > SP and the transit network on one side and the=20 > transit network > > and > > > the > > > > termination network on the other side before opening up a > secure > > > > communication path on L5. > > > [[Reinaldo]] > > > > > > Is this transit network just providing IP transit or it=20 > is actually > a > > > Layer 5 transit network? I think the requirements are different in > the > > > two scenarios. > > > > > > > > > > > In addition, > > > > I suggest to delete the old section 4.4. on private peering > because > > > > it is confusing and and out of scope anyway > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 13 13:41:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15CH-0005nP-NS; Thu, 13 Jul 2006 13:41:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15CH-0005nK-18 for speermint@ietf.org; Thu, 13 Jul 2006 13:41:57 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G15CF-0000wh-PP for speermint@ietf.org; Thu, 13 Jul 2006 13:41:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 19:41:01 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B28@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAALHsGkAADlMwAAAfQkiAACHSfAAAVhLCQAAsQbQAAIYJ4g= References: <9BD5D7887235424FA97DFC223CAE3C2804DA9BBF@proton.jnpr.net> From: "Stastny Richard" To: "Reinaldo Penno" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d 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 do not think there is any difference =20 example.com (it belongs to a federation vspb.com is also a part of) =20 the direct peering takes place between vspa.com and vspb.com =20 if vspb.com is proxying the request then to vspc.com, this does not = matter anymore. This is similar if you send a call to an I-CSCF or SBC and this = element is =20 proxying the call further to an S-CSCSF. =20 So this is still direct peering between A and B =20 Richard ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Do 13.07.2006 18:38 An: Stastny Richard; David Meyer Cc: speermint@ietf.org Betreff: RE: [Speermint] Terminology draft - Peering There are many operational reasons... When VSP C is provisioning its customers, it points to VSP B because B can actually check certificate revocation, or can prevent some SIP DDoS attacks, or in some parts of the country C has no presence, so it uses VSP B to route it back to him, etc, etc Regards, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, July 13, 2006 9:16 AM > To: Reinaldo Penno; David Meyer > Cc: speermint@ietf.org > Subject: Re: [Speermint] Terminology draft - Peering > > >When the INVITE gets to server1.vspb.com it would eventually send to > >server1.vspc.com because that's the proxy/VSP that provides VoIP > >services to example.com. I might begetting this wrong, is there > >something wrong with this example? > > Simply: why is example.com entering > server1.vspb.com into the NAPTRs and > not server1.vspc.com? > > How is vspb.com coming into play at all? > > If you do this, everything is ok > > Richard > > > > ________________________________ > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 13.07.2006 17:46 > An: Stastny Richard; David Meyer > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Terminology draft - Peering > > > > So, what I'm trying to say is that the domain part of the AOR does not > tell you which VSP actually hosts it. You can have vanity domains, > company domains, etc, etc. Just like you can have a domain at your home > but use your providers SMTP to relay email to you. > > Okay, let's put some call flows around it putting the federation thing > aside for a moment. So, adapted from RFC 3263...example.com is actually > at vspc.com > > As an example, consider a client that wishes to resolve > sip:user@example.com. The client performs a NAPTR query for that > domain, and the following NAPTR records are returned: > > ; order pref flags service regexp replacement > IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.vspb.com. > IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.vspb.com > IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.vspb.com. > > This indicates that the server supports TLS over TCP, TCP, and UDP, > in that order of preference. Since the client supports TCP and UDP, > TCP will be used, targeted to a host determined by an SRV lookup of > _sip._tcp.vspb.com. That lookup would return: > > ;; Priority Weight Port Target > IN SRV 0 1 5060 server1.vspb.com > IN SRV 0 2 5060 server2.vspb.com > > > When the INVITE gets to server1.vspb.com it would eventually send to > server1.vspc.com because that's the proxy/VSP that provides VoIP > services to example.com. I might begetting this wrong, is there > something wrong with this example? > > Thanks, > > Reinaldo > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, July 13, 2006 8:28 AM > > To: Reinaldo Penno; David Meyer > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Terminology draft - Peering > > > > I think we are getting ahead of ourselves here > > > > I always have to start with the AoR and look up the domain there > > > > Here I may find a NAPTR indicating the federation (and eventually a > > policy) > > and I alsi find there the 3263 NAPTR and SRV, pointing to the servers > > where > > I should send the invites to > > > > If there is an indirect peering, I may be diverted to (the domain of) > VSP > > B, > > where I also may finally look up the 3263 SRV to find the ingress > points > > to send the invite too. How VSP B is no going further to reach B is > none > > of my business > > > > Richard > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Do 13.07.2006 17:19 > > An: Stastny Richard; David Meyer > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > Richard, > > > > I think you are assuming the domain part of AORs maps to the VSP that > > actually host his VoIP service and this relationship is not well > > defined. > > > > I can be in VSP A and make a DNS query for alice@some-company.com and > > get as a result a proxy server at VSP B. Now, some-company.com is > > actually served by VSP C, but the DNS returns VSP B because that's > where > > you need to send your signaling to get to some-company.com > > > > In this case, VSP A has no way of knowing that some-company.com is > > actually "hosted" (for a lack of a better term) in VSP C. > > > > A VSP can serve many domains. Just because the VSP is called vspb.com > > does not mean it cannot serve, e.g., supervoip.com, voip'r'us.com, > > voipathome.com, etc, etc > > > > Thanks, > > > > Reinaldo > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, July 13, 2006 8:02 AM > > > To: Reinaldo Penno; David Meyer > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Terminology draft - Peering > > > > > > >VSPA <-----> VSP B <-----> VSP C > > > > > > >Is VSP B providing layer 5 "transit" or we can just say it peers > with > > A > > > and B? > > > > > > >VSP A might not even know that is talking with VSP C through VSP B. > > For > > > >all purposes, VSP B is VSP C... > > > > > > VSP A must know that the call terminates at VSP C, because he > > basically > > > has > > > an AoR for VSP C. > > > > > > He looks up VSP C and sees he cannot peer with VSP C directly, but > > gets > > > the pointer to VSP B (somehow) > > > > > > Now he peers with VSP B and VSP B peers with VSP C > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Do 13.07.2006 15:49 > > > An: Stastny Richard; David Meyer > > > Cc: speermint@ietf.org > > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > > > > > I thought at some point we kind of agreed to get rid of the transit > > > term, wasn't it? > > > > > > Anyway, in the following case > > > > > > VSPA <-----> VSP B <-----> VSP C > > > > > > Is VSP B providing layer 5 "transit" or we can just say it peers > with > > A > > > and B? > > > > > > VSP A might not even know that is talking with VSP C through VSP B. > > For > > > all purposes, VSP B is VSP C... > > > > > > Thanks, > > > > > > Reinaldo > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Wednesday, July 12, 2006 9:18 PM > > > > To: Reinaldo Penno; David Meyer > > > > Cc: speermint@ietf.org > > > > Subject: Re: [Speermint] Terminology draft - Peering > > > > > > > > >[[Reinaldo]] > > > > > > > > >SPs or VSPs? > > > > > > > > Both > > > > > > > > >Is this transit network just providing IP transit or it is > actually > > a > > > > >Layer 5 transit network? I think the requirements are different > in > > > the > > > > >two scenarios. > > > > > > > > L5 > > > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Gesendet: Do 13.07.2006 04:32 > > > > An: Stastny Richard; David Meyer > > > > Cc: speermint@ietf.org > > > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > > > > > > > > > Hello Richard, > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, July 12, 2006 3:55 PM > > > > > To: David Meyer > > > > > Cc: speermint@ietf.org > > > > > Subject: [Speermint] Terminology draft - Peering > > > > > > > > > > Proposed wording for Peering > > > > > > > > > > 4.2. Layer 5 Peering or Session Peering > > > > > Layer 5 peering or Session Peering refers to interconnection > of > > > > > two (VoIP) service providers for the purposes of routing > > > real-time > > > > > (or quasi-real time) secure call signaling between their > > > respective > > > > > customers using SIP methods. Such interconnection may be > > direct > > > or > > > > > indirect. > > > > > Media streams associated with this signaling (if any) are not > > > > > constrained to follow the same set of paths. > > > > > 4.3. Direct Peering > > > > > Direct Peering covers all cases where the two SPs > > > > [[Reinaldo]] > > > > > > > > SPs or VSPs? > > > > > > > > interconnect without > > > > > using an intervening L5 network. Both SP must have a trust > > > > relationship > > > > > established (e.g. know they belong to the same federation > (see > > > > below) > > > > > before opening up a secure communication path on L5. > > > > > 4.4 Indirect or Transit Peering > > > > > Indirect or transit peering is the establishment of a secure > > > > signalling > > > > > path via one (or more) referral or transit network(s). In > this > > > case > > > > it > > > > > is > > > > > required that a trust relationship is established between the > > > > > originating > > > > > SP and the transit network on one side and the transit > network > > > and > > > > the > > > > > termination network on the other side before opening up a > > secure > > > > > communication path on L5. > > > > [[Reinaldo]] > > > > > > > > Is this transit network just providing IP transit or it is > actually > > a > > > > Layer 5 transit network? I think the requirements are different in > > the > > > > two scenarios. > > > > > > > > > > > > > > In addition, > > > > > I suggest to delete the old section 4.4. on private peering > > because > > > > > it is confusing and and out of scope anyway > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 Jul 13 14:29:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15w9-0006x9-St; Thu, 13 Jul 2006 14:29:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15w8-0006wt-Nf for speermint@ietf.org; Thu, 13 Jul 2006 14:29:20 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15w7-0004yk-5t for speermint@ietf.org; Thu, 13 Jul 2006 14:29:20 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 13 Jul 2006 11:29:18 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="562418636:sNHT36780768" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 14:29:15 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804DA9C14@proton.jnpr.net> In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D96F55C32@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAALHsGkAADlMwAAD+mIAAAMKD3A= From: "Reinaldo Penno" To: "Livingood, Jason" , "Stastny Richard" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 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. > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Thursday, July 13, 2006 10:20 AM > To: Reinaldo Penno; Stastny Richard; David Meyer > Cc: speermint@ietf.org > Subject: RE: [Speermint] Terminology draft - Peering >=20 > Sounds like this could certainly be the case of enterprise domains, if > there was some kind of federation aggregating them up and perhaps > providing network services. Is that a fair example? >=20 > Jason >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, July 13, 2006 11:20 AM > > To: Stastny Richard; David Meyer > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Terminology draft - Peering > > > > Richard, > > > > I think you are assuming the domain part of AORs maps to the > > VSP that actually host his VoIP service and this relationship > > is not well defined. > > > > I can be in VSP A and make a DNS query for > > alice@some-company.com and get as a result a proxy server at > > VSP B. Now, some-company.com is actually served by VSP C, but > > the DNS returns VSP B because that's where you need to send > > your signaling to get to some-company.com > > > > In this case, VSP A has no way of knowing that > > some-company.com is actually "hosted" (for a lack of a better > > term) in VSP C. > > > > A VSP can serve many domains. Just because the VSP is called > > vspb.com does not mean it cannot serve, e.g., supervoip.com, > > voip'r'us.com, voipathome.com, etc, etc > > > > Thanks, > > > > Reinaldo > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, July 13, 2006 8:02 AM > > > To: Reinaldo Penno; David Meyer > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Terminology draft - Peering > > > > > > >VSPA <-----> VSP B <-----> VSP C > > > > > > >Is VSP B providing layer 5 "transit" or we can just say it > > peers with > > A > > > and B? > > > > > > >VSP A might not even know that is talking with VSP C through VSP B. > > For > > > >all purposes, VSP B is VSP C... > > > > > > VSP A must know that the call terminates at VSP C, because he > > basically > > > has > > > an AoR for VSP C. > > > > > > He looks up VSP C and sees he cannot peer with VSP C directly, but > > gets > > > the pointer to VSP B (somehow) > > > > > > Now he peers with VSP B and VSP B peers with VSP C > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Do 13.07.2006 15:49 > > > An: Stastny Richard; David Meyer > > > Cc: speermint@ietf.org > > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > > > > > I thought at some point we kind of agreed to get rid of the transit > > > term, wasn't it? > > > > > > Anyway, in the following case > > > > > > VSPA <-----> VSP B <-----> VSP C > > > > > > Is VSP B providing layer 5 "transit" or we can just say it > > peers with > > A > > > and B? > > > > > > VSP A might not even know that is talking with VSP C through VSP B. > > For > > > all purposes, VSP B is VSP C... > > > > > > Thanks, > > > > > > Reinaldo > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Wednesday, July 12, 2006 9:18 PM > > > > To: Reinaldo Penno; David Meyer > > > > Cc: speermint@ietf.org > > > > Subject: Re: [Speermint] Terminology draft - Peering > > > > > > > > >[[Reinaldo]] > > > > > > > > >SPs or VSPs? > > > > > > > > Both > > > > > > > > >Is this transit network just providing IP transit or it > > is actually > > a > > > > >Layer 5 transit network? I think the requirements are > > different in > > > the > > > > >two scenarios. > > > > > > > > L5 > > > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Gesendet: Do 13.07.2006 04:32 > > > > An: Stastny Richard; David Meyer > > > > Cc: speermint@ietf.org > > > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > > > > > > > > > Hello Richard, > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, July 12, 2006 3:55 PM > > > > > To: David Meyer > > > > > Cc: speermint@ietf.org > > > > > Subject: [Speermint] Terminology draft - Peering > > > > > > > > > > Proposed wording for Peering > > > > > > > > > > 4.2. Layer 5 Peering or Session Peering > > > > > Layer 5 peering or Session Peering refers to > > interconnection of > > > > > two (VoIP) service providers for the purposes of routing > > > real-time > > > > > (or quasi-real time) secure call signaling between their > > > respective > > > > > customers using SIP methods. Such interconnection may be > > direct > > > or > > > > > indirect. > > > > > Media streams associated with this signaling (if any) are not > > > > > constrained to follow the same set of paths. > > > > > 4.3. Direct Peering > > > > > Direct Peering covers all cases where the two SPs > > > > [[Reinaldo]] > > > > > > > > SPs or VSPs? > > > > > > > > interconnect without > > > > > using an intervening L5 network. Both SP must have a trust > > > > relationship > > > > > established (e.g. know they belong to the same > > federation (see > > > > below) > > > > > before opening up a secure communication path on L5. > > > > > 4.4 Indirect or Transit Peering > > > > > Indirect or transit peering is the establishment of a secure > > > > signalling > > > > > path via one (or more) referral or transit > > network(s). In this > > > case > > > > it > > > > > is > > > > > required that a trust relationship is established > > between the > > > > > originating > > > > > SP and the transit network on one side and the > > transit network > > > and > > > > the > > > > > termination network on the other side before opening up a > > secure > > > > > communication path on L5. > > > > [[Reinaldo]] > > > > > > > > Is this transit network just providing IP transit or it > > is actually > > a > > > > Layer 5 transit network? I think the requirements are different in > > the > > > > two scenarios. > > > > > > > > > > > > > > In addition, > > > > > I suggest to delete the old section 4.4. on private peering > > because > > > > > it is confusing and and out of scope anyway > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 Thu Jul 13 17:31:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18mI-0000tA-8L; Thu, 13 Jul 2006 17:31:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18mG-0000sq-Jh for speermint@ietf.org; Thu, 13 Jul 2006 17:31:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0zc3-00087A-UM for speermint@ietf.org; Thu, 13 Jul 2006 07:44:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0zaS-00055b-GN for speermint@ietf.org; Thu, 13 Jul 2006 07:42:34 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Jul 2006 04:42:29 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,237,1149490800"; d="scan'208"; a="32089863:sNHT23927584" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DBgTcN028236; Thu, 13 Jul 2006 07:42:29 -0400 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 k6DBgSdU004711; Thu, 13 Jul 2006 07:42:29 -0400 (EDT) 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, 13 Jul 2006 07:42:28 -0400 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] Terminology draft - Peering Date: Thu, 13 Jul 2006 07:42:27 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301B361CB@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5ABqXLJA= From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "David Meyer" X-OriginalArrivalTime: 13 Jul 2006 11:42:28.0353 (UTC) FILETIME=[6B034710:01C6A671] DKIM-Signature: a=rsa-sha1; q=dns; l=2462; t=1152790949; x=1153654949; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Terminology=20draft=20-=20Peering |To:=22Stastny=20Richard=22=20, =0A=20=20=20=20=20= 20=20=20=22David=20Meyer=22=20; X=v=3Dcisco.com=3B=20h=3DV9VbvCv1Id03VA1hCr6LfMekZYU=3D; b=cALR1avNXD4bQDDdv7cwqeHe5+gpXL4f1/QztKzqS4Aku8V37oQWuuaW7wapl38l+DvFtCub /3JPtunrotlkf8qULsFoIHZcMca+EckhA0Ppazya2sxzDIpU4cOQj5Fq; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Inline...=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Wednesday, July 12, 2006 6:55 PM > To: David Meyer > Cc: speermint@ietf.org > Subject: [Speermint] Terminology draft - Peering >=20 > Proposed wording for Peering > =20 > 4.2. Layer 5 Peering or Session Peering > Layer 5 peering or Session Peering refers to interconnection of=20 > two (VoIP) service providers for the purposes of routing real-time > (or quasi-real time) secure call signaling between their=20 > respective=20 > customers using SIP methods. Such interconnection may be=20 > direct or=20 > indirect.=20 > Media streams associated with this signaling (if any) are not=20 > constrained to follow the same set of paths. I think this is an unnecessary and potentially damaging constraint. It implies that the media path goes through the same TLS connections and boxes as the signaling at worst. It may also preclude any optimization of the media path in cases where the calling and called parties are roaming far from their home networks, but sitting on the same cell site. I would much prefer that signaling and media paths be loosely coupled. If you feel this is somehow justified, please elaborate on what you mean by path. Mike > 4.3. Direct Peering > Direct Peering covers all cases where the two SPs=20 > interconnect without > using an intervening L5 network. Both SP must have a trust=20 > relationship > established (e.g. know they belong to the same federation=20 > (see below)) > before opening up a secure communication path on L5. > 4.4 Indirect or Transit Peering > Indirect or transit peering is the establishment of a=20 > secure signalling > path via one (or more) referral or transit network(s). In=20 > this case it is > required that a trust relationship is established between=20 > the originating > SP and the transit network on one side and the transit=20 > network and the=20 > termination network on the other side before opening up a secure=20 > communication path on L5. > =20 > In addition, > I suggest to delete the old section 4.4. on private peering=20 > because it is confusing and and out of scope anyway > =20 > =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 Jul 13 17:45:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18zU-00024i-L1; Thu, 13 Jul 2006 17:45:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18zS-00022F-K4 for Speermint@ietf.org; Thu, 13 Jul 2006 17:44:58 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0zrw-0000H5-Iu for Speermint@ietf.org; Thu, 13 Jul 2006 08:00:36 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0zdZ-0005RY-NY for Speermint@ietf.org; Thu, 13 Jul 2006 07:45:47 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2006 07:45:45 -0400 X-IronPort-AV: i="4.06,237,1149480000"; d="scan'208"; a="92629835:sNHT28501768" 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.20060308/8.12.11) with ESMTP id k6DBjjs8028857; Thu, 13 Jul 2006 07:45:45 -0400 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 k6DBji7t001558; Thu, 13 Jul 2006 07:45:44 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 07:45:44 -0400 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] TLS, etc - Local-policy versus WG mandate Date: Thu, 13 Jul 2006 07:45:43 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301B361CD@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAAdEHgAAOBPbAAAIj2cAAfJLNA From: "Michael Hammer \(mhammer\)" To: "Uzelac, Adam" , "Brian Rosen" , X-OriginalArrivalTime: 13 Jul 2006 11:45:44.0756 (UTC) FILETIME=[E013FF40:01C6A671] DKIM-Signature: a=rsa-sha1; q=dns; l=4779; t=1152791145; x=1153655145; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20TLS, =20etc=20-=20Local-policy=20versus=20WG=20mand ate |To:=22Uzelac, =20Adam=22=20, =0A=20=20=20=20= 20=20=20=20=22Brian=20Rosen=22=20, =20; X=v=3Dcisco.com=3B=20h=3D2VnnJdMEaY5C8ig4LBewTc6BmaE=3D; b=qJCdGteD3PrqjY0OUMNGw5fstss2gSKW7XZ32RfwA30wTjPqO9xO6cC52oszZkfqQF/T8XbH UEasrSG1IOft6TUn5uxTBxPyM96c/NYjXUNUFYbpKkXTXoL6uozuxGza; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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 That is a good first step, thanks. Mike =20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 > Sent: Wednesday, July 12, 2006 5:04 PM > To: Michael Hammer (mhammer); Brian Rosen; Speermint@ietf.org > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 > Mike, >=20 > I am not sure about an agreed upon way to address security=20 > concerns, but there was a request from the WG chairs that a=20 > document specifying threats be compiled. Dan York from Mitel=20 > offered to participate leveraging his work from www.voipsa.org. >=20 > Adam >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, July 12, 2006 4:42 PM > To: Brian Rosen; Uzelac, Adam; Speermint@ietf.org > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 > Please refresh my memory. =20 >=20 > Was there going to be a separate document that addresses=20 > security on the peering interface? >=20 > Or, is this to be a security section in each of the documents=20 > that peel the onion, starting with discovery, with perhaps=20 > the policy discovery layer of the onion saying that=20 > federations should establish security policy and here are the=20 > minimum requirements that such policies hopefully support,=20 > with other layers saying signaling/media follow the security=20 > policy, whatever that is? >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, July 12, 2006 3:22 PM > > To: 'Uzelac, Adam'; Speermint@ietf.org > > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate > >=20 > > Due to the last minute schedule change, I was unable to attend the=20 > > meeting, but perhaps we now have enough consensus to write down the=20 > > answer. > >=20 > > I think we use the methods we have used in most of the=20 > sippish specs: > >=20 > > It's mandatory to IMPLEMENT TLS between peers (presumably peer=20 > > proxies). > > It's mandatory to DEPLOY some kind of mutual authentication, which=20 > > does not have to be TLS. > >=20 > > I suspect that we want to actually say that the federation=20 > establishes >=20 > > a particular authentication standard that all members use. > >=20 > > Brian > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Wednesday, July 12, 2006 2:44 PM > > To: Speermint@ietf.org > > Subject: [Speermint] TLS, etc - Local-policy versus WG mandate > >=20 > > Pertaining to the "To TLS or not TLS" discussion in the WG=20 > sessions,=20 > > time didn't permit a proper tomato tossing session at the=20 > WG session - >=20 > > but one comment was made about mandating such things as=20 > TLS, etc - to=20 > > which a rebuttal was made that the type of authentication and=20 > > authorization used and implemented is an issue of local policy and=20 > > therefore shouldn't be mandated. > >=20 > > For fear of starting a "great taste" versus "less filling"=20 > > argument - Let me start this way....I agree with what=20 > appeared to be=20 > > consensus in the WG session that there needs to be first a=20 > Discovery=20 > > procedure, then an Authentication procedure, and finally connecting=20 > > the call. The methods upon which each step along the way is done=20 > > should not to so narrow as to exclude popular and in some=20 > cases widely >=20 > > adopted methods. > > Speermint should provide the BCP - but does that really need to=20 > > exclude other plausible and practical models? It's=20 > important to note=20 > > that I believe TLS is the most appropriate, practical and logical=20 > > approach. I also believe the there are valid reasons for other=20 > > approaches to authenticate. The same holds true for methods of=20 > > discovery. > >=20 > > So the question for the group and possibly some guidance from the=20 > > chairs here?!?!? - Should an undertaking to determine what=20 > should be=20 > > determined via local policy versus mandated via 'MUSTs' be=20 > done? Is=20 > > this a section for the requirements doc? > >=20 > > I would like to thank Rohan for bringing this issue to the=20 > forefront=20 > > in a lightning-rod manner!! ;) > >=20 > > Regards, > >=20 > > Adam > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 13 19:58:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1B4b-0002SA-VA; Thu, 13 Jul 2006 19:58:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1B4a-0002Rr-K1 for Speermint@ietf.org; Thu, 13 Jul 2006 19:58:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G139T-0001ww-Vp for Speermint@ietf.org; Thu, 13 Jul 2006 11:30:56 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1G12uI-0000lm-QQ for Speermint@ietf.org; Thu, 13 Jul 2006 11:15:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] TLS, etc - Local-policy versus WG mandate Date: Thu, 13 Jul 2006 17:11:51 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B22@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAoCKnQAAJXv/wAAC/mYAAATmNp References: <1DDB0D3CC4E7F14FAE946361C0A60655F55376@isr-jlm-mail.Kayote.com> From: "Stastny Richard" To: "David Schwartz" , "Uzelac, Adam" , X-Spam-Score: -2.6 (--) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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 I think there is a confusion about the word namespace and also about E.164 federations and Speermint federations What do you mean with namespace? =20 Richard ________________________________ Von: David Schwartz [mailto:David.Schwartz@Kayote.com] Gesendet: Do 13.07.2006 17:09 An: Stastny Richard; Uzelac, Adam; Speermint@ietf.org Betreff: RE: [Speermint] TLS, etc - Local-policy versus WG mandate There is value in knowing the affiliation of an entity. I can use this information to find possible commonalities to possibly enable communication. For example, it could be that the reason we so not share a policy group is due to the fact that he supports only 711 and I support only 723. Once his affiliation was known I could search for a different entity in the same namespace who may be able to connect us (e.g. he shares policy with both of us since he can transcode 711 to 723). David -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, July 13, 2006 5:58 PM To: David Schwartz; Uzelac, Adam; Speermint@ietf.org Subject: Re: [Speermint] TLS, etc - Local-policy versus WG mandate >I think of federations as shared namespace NOT policy. Federations are >comprised of one namespace and multiple policy federations describing >the relationships between the members. Just a question: if you do not have a common policy in the federation, why do you need it at all? Richard ________________________________ Von: David Schwartz [mailto:David.Schwartz@Kayote.com] Gesendet: Do 13.07.2006 16:05 An: Uzelac, Adam; Speermint@ietf.org Betreff: RE: [Speermint] TLS, etc - Local-policy versus WG mandate So here are my two cents (just repeating what I said at the session) My claim which was not directly rebuffed is why authentication is any different than any other policy issue. As far as I can tell there are 2 not 3 issues that need to be resolved for peering to occur. 1. Where is the other side 2. Can we communicate If we focus on the second issue it includes things like * Will the other side even accept a call from me * Assuming other side will accept my calls * Which authentication mechanism do I use for this communication- if any * what are the ground rules for communication (e.g. specific codecs) * etc. I think of federations as shared namespace NOT policy. Federations are comprised of one namespace and multiple policy federations describing the relationships between the members. This is why for the life of me I cannot understand why it is not ok with me to peer with A via TLS and with B with IPSec and with 3 with no authentication at all. Authentication is just a policy decision and should NOT be mandated. I know everybody will yell at this but to me making ANY security mechanism mandatory is tantamount to making a minimal codec set mandatory and we know how this list reacted when that was proposed. If any member is dumb enough not to implement TLS or IPSec or some other security mechanism he will soon find that no one will accept traffic from him and implement it then. We do not have to mandate not being STUPID. Cheers, David -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Sent: Wednesday, July 12, 2006 9:44 PM To: Speermint@ietf.org Subject: [Speermint] TLS, etc - Local-policy versus WG mandate Pertaining to the "To TLS or not TLS" discussion in the WG sessions, time didn't permit a proper tomato tossing session at the WG session - but one comment was made about mandating such things as TLS, etc - to which a rebuttal was made that the type of authentication and authorization used and implemented is an issue of local policy and therefore shouldn't be mandated. For fear of starting a "great taste" versus "less filling" argument - Let me start this way....I agree with what appeared to be consensus in the WG session that there needs to be first a Discovery procedure, then an Authentication procedure, and finally connecting the call. The methods upon which each step along the way is done should not to so narrow as to exclude popular and in some cases widely adopted methods. Speermint should provide the BCP - but does that really need to exclude other plausible and practical models? It's important to note that I believe TLS is the most appropriate, practical and logical approach. I also believe the there are valid reasons for other approaches to authenticate. The same holds true for methods of discovery. So the question for the group and possibly some guidance from the chairs here?!?!? - Should an undertaking to determine what should be determined via local policy versus mandated via 'MUSTs' be done? Is this a section for the requirements doc? I would like to thank Rohan for bringing this issue to the forefront in a lightning-rod manner!! ;) Regards, Adam _______________________________________________ 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 Thu Jul 13 23:51:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Ehl-0001pA-KE; Thu, 13 Jul 2006 23:51:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Ehl-0001oo-0C for speermint@ietf.org; Thu, 13 Jul 2006 23:51:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1495-0005fu-6O for speermint@ietf.org; Thu, 13 Jul 2006 12:34:35 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1G13u7-0001yJ-Le for speermint@ietf.org; Thu, 13 Jul 2006 12:19:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Terminology draft - Peering Date: Thu, 13 Jul 2006 18:15:49 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B26@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5AAd1XMAAA8zp3AATtb+QAALHsGkAADlMwAAAfQkiAACHSfAAAVhLCQ== References: <9BD5D7887235424FA97DFC223CAE3C2804DA9B88@proton.jnpr.net> From: "Stastny Richard" To: "Reinaldo Penno" , "David Meyer" X-Spam-Score: -2.6 (--) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e 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 >When the INVITE gets to server1.vspb.com it would eventually send to >server1.vspc.com because that's the proxy/VSP that provides VoIP >services to example.com. I might begetting this wrong, is there >something wrong with this example? Simply: why is example.com entering=20 server1.vspb.com into the NAPTRs and not server1.vspc.com? How is vspb.com coming into play at all? If you do this, everything is ok Richard ________________________________ Von: Reinaldo Penno [mailto:rpenno@juniper.net] Gesendet: Do 13.07.2006 17:46 An: Stastny Richard; David Meyer Cc: speermint@ietf.org Betreff: RE: [Speermint] Terminology draft - Peering So, what I'm trying to say is that the domain part of the AOR does not tell you which VSP actually hosts it. You can have vanity domains, company domains, etc, etc. Just like you can have a domain at your home but use your providers SMTP to relay email to you. Okay, let's put some call flows around it putting the federation thing aside for a moment. So, adapted from RFC 3263...example.com is actually at vspc.com As an example, consider a client that wishes to resolve sip:user@example.com. The client performs a NAPTR query for that domain, and the following NAPTR records are returned: ; order pref flags service regexp replacement IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.vspb.com. IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.vspb.com IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.vspb.com. This indicates that the server supports TLS over TCP, TCP, and UDP, in that order of preference. Since the client supports TCP and UDP, TCP will be used, targeted to a host determined by an SRV lookup of _sip._tcp.vspb.com. That lookup would return: ;; Priority Weight Port Target IN SRV 0 1 5060 server1.vspb.com IN SRV 0 2 5060 server2.vspb.com When the INVITE gets to server1.vspb.com it would eventually send to server1.vspc.com because that's the proxy/VSP that provides VoIP services to example.com. I might begetting this wrong, is there something wrong with this example? Thanks, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, July 13, 2006 8:28 AM > To: Reinaldo Penno; David Meyer > Cc: speermint@ietf.org > Subject: Re: [Speermint] Terminology draft - Peering > > I think we are getting ahead of ourselves here > > I always have to start with the AoR and look up the domain there > > Here I may find a NAPTR indicating the federation (and eventually a > policy) > and I alsi find there the 3263 NAPTR and SRV, pointing to the servers > where > I should send the invites to > > If there is an indirect peering, I may be diverted to (the domain of) VSP > B, > where I also may finally look up the 3263 SRV to find the ingress points > to send the invite too. How VSP B is no going further to reach B is none > of my business > > Richard > > ________________________________ > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Do 13.07.2006 17:19 > An: Stastny Richard; David Meyer > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Terminology draft - Peering > > > > Richard, > > I think you are assuming the domain part of AORs maps to the VSP that > actually host his VoIP service and this relationship is not well > defined. > > I can be in VSP A and make a DNS query for alice@some-company.com and > get as a result a proxy server at VSP B. Now, some-company.com is > actually served by VSP C, but the DNS returns VSP B because that's where > you need to send your signaling to get to some-company.com > > In this case, VSP A has no way of knowing that some-company.com is > actually "hosted" (for a lack of a better term) in VSP C. > > A VSP can serve many domains. Just because the VSP is called vspb.com > does not mean it cannot serve, e.g., supervoip.com, voip'r'us.com, > voipathome.com, etc, etc > > Thanks, > > Reinaldo > > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, July 13, 2006 8:02 AM > > To: Reinaldo Penno; David Meyer > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Terminology draft - Peering > > > > >VSPA <-----> VSP B <-----> VSP C > > > > >Is VSP B providing layer 5 "transit" or we can just say it peers with > A > > and B? > > > > >VSP A might not even know that is talking with VSP C through VSP B. > For > > >all purposes, VSP B is VSP C... > > > > VSP A must know that the call terminates at VSP C, because he > basically > > has > > an AoR for VSP C. > > > > He looks up VSP C and sees he cannot peer with VSP C directly, but > gets > > the pointer to VSP B (somehow) > > > > Now he peers with VSP B and VSP B peers with VSP C > > > > Richard > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Do 13.07.2006 15:49 > > An: Stastny Richard; David Meyer > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > I thought at some point we kind of agreed to get rid of the transit > > term, wasn't it? > > > > Anyway, in the following case > > > > VSPA <-----> VSP B <-----> VSP C > > > > Is VSP B providing layer 5 "transit" or we can just say it peers with > A > > and B? > > > > VSP A might not even know that is talking with VSP C through VSP B. > For > > all purposes, VSP B is VSP C... > > > > Thanks, > > > > Reinaldo > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, July 12, 2006 9:18 PM > > > To: Reinaldo Penno; David Meyer > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Terminology draft - Peering > > > > > > >[[Reinaldo]] > > > > > > >SPs or VSPs? > > > > > > Both > > > > > > >Is this transit network just providing IP transit or it is actually > a > > > >Layer 5 transit network? I think the requirements are different in > > the > > > >two scenarios. > > > > > > L5 > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Gesendet: Do 13.07.2006 04:32 > > > An: Stastny Richard; David Meyer > > > Cc: speermint@ietf.org > > > Betreff: RE: [Speermint] Terminology draft - Peering > > > > > > > > > > > > Hello Richard, > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Wednesday, July 12, 2006 3:55 PM > > > > To: David Meyer > > > > Cc: speermint@ietf.org > > > > Subject: [Speermint] Terminology draft - Peering > > > > > > > > Proposed wording for Peering > > > > > > > > 4.2. Layer 5 Peering or Session Peering > > > > Layer 5 peering or Session Peering refers to interconnection of > > > > two (VoIP) service providers for the purposes of routing > > real-time > > > > (or quasi-real time) secure call signaling between their > > respective > > > > customers using SIP methods. Such interconnection may be > direct > > or > > > > indirect. > > > > Media streams associated with this signaling (if any) are not > > > > constrained to follow the same set of paths. > > > > 4.3. Direct Peering > > > > Direct Peering covers all cases where the two SPs > > > [[Reinaldo]] > > > > > > SPs or VSPs? > > > > > > interconnect without > > > > using an intervening L5 network. Both SP must have a trust > > > relationship > > > > established (e.g. know they belong to the same federation (see > > > below) > > > > before opening up a secure communication path on L5. > > > > 4.4 Indirect or Transit Peering > > > > Indirect or transit peering is the establishment of a secure > > > signalling > > > > path via one (or more) referral or transit network(s). In this > > case > > > it > > > > is > > > > required that a trust relationship is established between the > > > > originating > > > > SP and the transit network on one side and the transit network > > and > > > the > > > > termination network on the other side before opening up a > secure > > > > communication path on L5. > > > [[Reinaldo]] > > > > > > Is this transit network just providing IP transit or it is actually > a > > > Layer 5 transit network? I think the requirements are different in > the > > > two scenarios. > > > > > > > > > > > In addition, > > > > I suggest to delete the old section 4.4. on private peering > because > > > > it is confusing and and out of scope anyway > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 Jul 14 10:18:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OV0-0008VT-Qn; Fri, 14 Jul 2006 10:18:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OUz-0008Uo-04 for speermint@ietf.org; Fri, 14 Jul 2006 10:18:33 -0400 Received: from mercury.sunrocket.com ([208.50.38.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1OSI-0004vT-02 for speermint@ietf.org; Fri, 14 Jul 2006 10:15:47 -0400 Received: (qmail 11149 invoked from network); 14 Jul 2006 14:03:34 -0000 Received: from unknown (HELO [172.16.9.168]) (gkulshreshtha@[172.16.9.168]) (envelope-sender ) by mercury.sunrocket.com (qmail-ldap-1.03) with SMTP for ; 14 Jul 2006 14:03:34 -0000 Message-ID: <44B7A432.5060802@sunrocket.com> Date: Fri, 14 Jul 2006 10:03:30 -0400 From: Gaurav Kulshreshtha Organization: SunRocket Inc. User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Speermint] Terminology draft - Peering References: <9BD5D7887235424FA97DFC223CAE3C2804DA9B43@proton.jnpr.net> <32755D354E6B65498C3BD9FD496C7D462C4B21@oefeg-s04.oefeg.loc> <44B668EA.7010500@hxr.us> <32755D354E6B65498C3BD9FD496C7D462C4B25@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B25@oefeg-s04.oefeg.loc> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gaurav@sunrocket.com 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 Richard, Agree we are talking in this thread about L5 but I would argue that in our interconnect discussions we have to keep an eye towards delay elements along the media path e.g. If transcoders at VSP D <--> VSP C introduce 70 ms delay and then VSP C <->VSP B introduce another 30 ms delay. We are left with only 50 ms of transit delay time for rest of the voice path according to ITU specs on Telephony. Gaurav Stastny Richard wrote: > You are still in the signalling path > > Regarding transcoding, we are talking here only about L5 > > Richard > > ________________________________ > > Von: Andrew Newton [mailto:andy@hxr.us] > Gesendet: Do 13.07.2006 17:38 > An: Stastny Richard > Cc: Reinaldo Penno; Uzelac, Adam; David Meyer; speermint@ietf.org > Betreff: Re: [Speermint] Terminology draft - Peering > > > > Stastny Richard wrote: > >> If VSP B is giving A all what he needs, does he need to care how >> VSP B and C are doing this? >> > > Yes. We do care if any transcoding occurs and we do care if the > termination is on the PSTN. > > -andy > > > > > _______________________________________________ > 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 Jul 14 11:42:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Pod-0002Gq-Dk; Fri, 14 Jul 2006 11:42:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Poc-0002Ec-03 for speermint@ietf.org; Fri, 14 Jul 2006 11:42:54 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1PVR-0006co-EC for speermint@ietf.org; Fri, 14 Jul 2006 11:23:05 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1G1Os6-0007M5-Bq for speermint@ietf.org; Fri, 14 Jul 2006 10:42:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Terminology draft - Peering Date: Fri, 14 Jul 2006 16:41:21 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B2B@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: AcanT970MTAfqoo8SMmKoEMPlRL/lwAAlsqo References: <9BD5D7887235424FA97DFC223CAE3C2804DA9B43@proton.jnpr.net> <32755D354E6B65498C3BD9FD496C7D462C4B21@oefeg-s04.oefeg.loc> <44B668EA.7010500@hxr.us> <32755D354E6B65498C3BD9FD496C7D462C4B25@oefeg-s04.oefeg.loc> <44B7A432.5060802@sunrocket.com> From: "Stastny Richard" To: X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 So basically satellite telephony is illegal ;-) =20 Serious: =20 There is two (3) problems with this: =20 1. We are talking here about the determination if you can peer or not i.e. selecting the VSP which may either host the subscriber or have a path to the VSP who is. The question is if you are allowed to = establish=20 a secure communication path to start signalling and negotiation without being rejected in the first place. I cannot imagine you put all = information you negotiate with SIP methods in advance in the DNS as policy elements =20 2. Keeping in mind the end-to-end principle, I have no idea how any VSP in the path may know about the media delays involved on the media path. This is only valid for the case where the media path follows the signalling path and here it is difficult. =20 3. I also cannot imaging that a network provider is announcing publicy=20 his worst case delay ;-) =20 Richard ________________________________ Von: Gaurav Kulshreshtha [mailto:gaurav@sunrocket.com] Gesendet: Fr 14.07.2006 16:03 An: Stastny Richard Cc: Andrew Newton; speermint@ietf.org Betreff: Re: [Speermint] Terminology draft - Peering Richard, Agree we are talking in this thread about L5 but I would argue that in our interconnect discussions we have to keep an eye towards delay elements along the media path e.g. If transcoders at VSP D <--> VSP C introduce 70 ms delay and then VSP C <->VSP B introduce another 30 ms delay. We are left with only 50 ms of transit delay time for rest of the voice path according to ITU specs on Telephony. Gaurav Stastny Richard wrote: > You are still in the signalling path >=20 > Regarding transcoding, we are talking here only about L5 >=20 > Richard > > ________________________________ > > Von: Andrew Newton [mailto:andy@hxr.us] > Gesendet: Do 13.07.2006 17:38 > An: Stastny Richard > Cc: Reinaldo Penno; Uzelac, Adam; David Meyer; speermint@ietf.org > Betreff: Re: [Speermint] Terminology draft - Peering > > > > Stastny Richard wrote: > =20 >> If VSP B is giving A all what he needs, does he need to care how >> VSP B and C are doing this? >> =20 > > Yes. We do care if any transcoding occurs and we do care if the > termination is on the PSTN. > > -andy > > > > > _______________________________________________ > 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 Jul 14 12:09:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1QE2-0006XT-60; Fri, 14 Jul 2006 12:09:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1QE0-0006Wz-Mm for speermint@ietf.org; Fri, 14 Jul 2006 12:09:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1PV0-0006Z2-3N for speermint@ietf.org; Fri, 14 Jul 2006 11:22:38 -0400 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 1G1PBf-0007pw-No for speermint@ietf.org; Fri, 14 Jul 2006 11:02:41 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 20A9D3D1F; Fri, 14 Jul 2006 11:02:29 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 11:02:28 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Speermint] Terminology draft - Peering Date: Fri, 14 Jul 2006 11:02:26 -0400 Message-ID: In-Reply-To: <44B7A432.5060802@sunrocket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering thread-index: AcanUG49bRKZLPQPSl2qCE8aotNYiwAAE1rg From: "Uzelac, Adam" To: , "Stastny Richard" X-OriginalArrivalTime: 14 Jul 2006 15:02:28.0817 (UTC) FILETIME=[86428410:01C6A756] X-Spam-Score: -2.6 (--) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 Gaurav, I agree with Richard that the focus should be on L5. (call signaling as I read it - at least at this time) As I have noted on this list before, I believe that transcoding is evil, and questionable if required in certain use-cases. Ultimately/ideally, bearer-path should be point-to-point and capabilities negotiated by those endpoints directly. I know all too well there are situations that transcoding is required, and it's important that both parties know it's occurring. Unfortunately this notification doesn't always happen. =20 On a bit of a side-note, currently it is unclear the extent to which bearer/media should be addressed within the SPEERMINT scope. I plan on supplying Jean-Francois feedback on that section [3.3] of the requirements draft - and I encourage others to do the same to fully vet out the requirements. -AU -----Original Message----- From: Gaurav Kulshreshtha [mailto:gaurav@sunrocket.com]=20 Sent: Friday, July 14, 2006 10:04 AM To: Stastny Richard Cc: speermint@ietf.org Subject: Re: [Speermint] Terminology draft - Peering Richard, Agree we are talking in this thread about L5 but I would argue that in our interconnect discussions we have to keep an eye towards delay elements along the media path e.g. If transcoders at VSP D <--> VSP C introduce 70 ms delay and then VSP C <->VSP B introduce another 30 ms delay. We are left with only 50 ms of transit delay time for rest of the voice path according to ITU specs on Telephony. Gaurav Stastny Richard wrote: > You are still in the signalling path > =20 > Regarding transcoding, we are talking here only about L5 > =20 > Richard > > ________________________________ > > Von: Andrew Newton [mailto:andy@hxr.us] > Gesendet: Do 13.07.2006 17:38 > An: Stastny Richard > Cc: Reinaldo Penno; Uzelac, Adam; David Meyer; speermint@ietf.org > Betreff: Re: [Speermint] Terminology draft - Peering > > > > Stastny Richard wrote: > =20 >> If VSP B is giving A all what he needs, does he need to care how VSP=20 >> B and C are doing this? >> =20 > > Yes. We do care if any transcoding occurs and we do care if the=20 > termination is on the PSTN. > > -andy > > > > > _______________________________________________ > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 14 15:34:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1TR4-0004ug-2W; Fri, 14 Jul 2006 15:34:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1TR3-0004ub-7G for speermint@ietf.org; Fri, 14 Jul 2006 15:34:49 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1TQz-0006kr-Sf for speermint@ietf.org; Fri, 14 Jul 2006 15:34:49 -0400 Received: from ([10.20.62.13]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.22268243; Fri, 14 Jul 2006 15:34:21 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 15:34:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 14 Jul 2006 15:34:19 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96F561CA@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Session Peering Use Case for Cable Thread-Index: AcanfIAA1osWbOydRhS4X5SDuBjDvA== From: "Lee, Yiu" To: X-OriginalArrivalTime: 14 Jul 2006 19:34:21.0607 (UTC) FILETIME=[8170BB70:01C6A77C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Speermint] Session Peering Use Case for Cable 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="===============0282342794==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0282342794== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A77C.8176FF76" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A77C.8176FF76 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is the link for the draft presented in IETF66: http://www.ietf.org/internet-drafts/draft-lee-speermint-use-case-cable-0 0.txt. This is an informational draft to share our BCP in voip peering. Regards, Yiu ------_=_NextPart_001_01C6A77C.8176FF76 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Session Peering Use Case for Cable

This is the link for the draft = presented in IETF66: http://www.ietf.org/internet-drafts/draft-lee-speermint-us= e-case-cable-00.txt.

This is an informational draft to share = our BCP in voip peering.

Regards,
Yiu

------_=_NextPart_001_01C6A77C.8176FF76-- --===============0282342794== 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 --===============0282342794==-- From speermint-bounces@ietf.org Fri Jul 14 16:48:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Ua9-0002Ke-Ku; Fri, 14 Jul 2006 16:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Ua7-0002Jh-SQ for speermint@ietf.org; Fri, 14 Jul 2006 16:48:16 -0400 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 1G1Ua6-0004zn-I3 for speermint@ietf.org; Fri, 14 Jul 2006 16:48:15 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 31D353CA1; Fri, 14 Jul 2006 16:48:10 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 16:48:10 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 14 Jul 2006 16:48:28 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Requirements Draft thread-index: Acanhtvm2DFlhufSTpeu6CtjXizetQ== From: "Uzelac, Adam" To: "Jean-Francois Mule" X-OriginalArrivalTime: 14 Jul 2006 20:48:10.0031 (UTC) FILETIME=[D0FC9BF0:01C6A786] X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: speermint@ietf.org Subject: [Speermint] Comments on Requirements Draft 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 Jean-Francois, Here's some feedback on the Requirements document - though this is a good start, as you pointed out in your presentation at the WG session, there's work that needs to be done to hone in on the requirements. You asked the WG in your presentation slot if the requirements should stay as one document or split into different documents. I can't recall what was ultimately decided or if this wasn't addressed at all. I believe it important that we only have one document. =20 I will start with 'General Requirements' for now. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2.1. Unified solution for session peering policies -=20 We might consider replacing the word "Unified" with "Flexible". The text in this section points out that polices SHOULD be extensible and flexible, but I am not sure that means Unified. Also, in the quick references to the different models ("closed, open, etc) the context and definition of policies changes wildly. 2.2. Domain Based I think we should rename this section as well to Domain-based Context. The point, as I read it, is that the domain is the first and most basic construct in forming peering. Ultimately it's the interconnection of 2 or more domains that defines peering. Call routing is to or from the domain. The text states, "...call routing should rely on URIs." Beyond this point though, there is some "squirreliness" when stating that "We assume that all SIP URIs with the same domain-part share the same set of peering polices". I think that's an assumption that we can not safely, nor logically make. I suggest that we point out that a intra-domain is out of scope, and inter-domain is what we are trying to define. 2.3. No blocked calls As I understand the intention of this requirement, it's basically about reachability - meaning - Do I know that something is out there willing to peer with me before I attempt to connect? The text reads... An originating service provider must be able to determine whether a SIP URI is open for direct interconnection without actually sending a SIP INVITE. This is important as unsuccessful call attempts are highly undesirable since they can introduce high delays due to timeouts and can act as an unintended denial of service attack. (e.g., by repeated TLS handshakes). I propose that change the section heading to "Universal Reachability". I was going to suggest "Global", but I don't want to offend our little green martian friends. ;)=20 2.5. Independence of lower layers *NIT* - "...on what technologies are used route the call.." Need to add a "to" in between "used" and "route". A couple thoughts - I agree with the intent of the section but think that it's mis-labeled. The section heading should be something like "Access and Security Agnostic" or something like that. We shouldn't the lower layer (Ethernet or POS), and there are references to upper layers as well (TLS). =20 2.6. Administrative and technical policies This section I think it's going to be very difficult to build consensus on within the WG. Mostly due to our having to find some common ground on what should be WG mandate versus Local Policy. I believe that we should have a requirement on core set of policies to consider exchanging, but after the suggestion to exchange information, SPEERMINT scope ends. 2.7. Minimal additional cost on call initiation I think that this should be changed to "Minimal transaction cost". The text pertains to discovery of peering next-hop, connection to next-hop and potentially bearer (if determined within scope). 2.8. Look beyond SIP I am struggling with this one a bit. I believe this should removed altogether. If we should consider a requirement beyond SIP, then we should re-charter as "PEERMINT" ;) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D That's all I have for now. Adam _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 14 17:28:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1VDJ-0003p0-4u; Fri, 14 Jul 2006 17:28:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1VDI-0003ov-7i for speermint@ietf.org; Fri, 14 Jul 2006 17:28:44 -0400 Received: from mercury.sunrocket.com ([208.50.38.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1VDG-0001Ri-VU for speermint@ietf.org; Fri, 14 Jul 2006 17:28:44 -0400 Received: (qmail 22717 invoked from network); 14 Jul 2006 21:28:43 -0000 Received: from unknown (HELO [172.16.9.168]) (gkulshreshtha@[172.16.9.168]) (envelope-sender ) by mercury.sunrocket.com (qmail-ldap-1.03) with SMTP for ; 14 Jul 2006 21:28:43 -0000 Message-ID: <44B80C86.8040400@sunrocket.com> Date: Fri, 14 Jul 2006 17:28:38 -0400 From: Gaurav Kulshreshtha Organization: SunRocket Inc. User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Uzelac, Adam" Subject: Re: [Speermint] Terminology draft - Peering References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Stastny Richard , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gaurav@sunrocket.com 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 Uzelac, Adam wrote: > Gaurav, > > I agree with Richard that the focus should be on L5. (call signaling as > I read it - at least at this time) As I have noted on this list before, > I believe that transcoding is evil, and questionable if required in > certain use-cases. My point is that we should end up with really quality links after all the L5 mechanism are done. At the end of the day its the media we are trying to transport and this media has certain requirements on end-to-end delay. > Ultimately/ideally, bearer-path should be > point-to-point and capabilities negotiated by those endpoints directly. > Ideally is the operative word. This is more than likely not going to be the case depending upon business model of the peering federation administrator. > I know all too well there are situations that transcoding is required, > and it's important that both parties know it's occurring. Unfortunately > this notification doesn't always happen. > > On a bit of a side-note, currently it is unclear the extent to which > bearer/media should be addressed within the SPEERMINT scope. I plan on > supplying Jean-Francois feedback on that section [3.3] of the > requirements draft - and I encourage others to do the same to fully vet > out the requirements. > Will do. > -AU > > -----Original Message----- > From: Gaurav Kulshreshtha [mailto:gaurav@sunrocket.com] > Sent: Friday, July 14, 2006 10:04 AM > To: Stastny Richard > Cc: speermint@ietf.org > Subject: Re: [Speermint] Terminology draft - Peering > > Richard, > Agree we are talking in this thread about L5 but I would argue that in > our interconnect discussions we have to keep an eye towards delay > elements along the media path e.g. If transcoders at VSP D <--> VSP C > introduce 70 ms delay and then VSP C <->VSP B introduce another 30 ms > delay. We are left with only 50 ms of transit delay time for rest of the > voice path according to ITU specs on Telephony. > > Gaurav > > Stastny Richard wrote: > >> You are still in the signalling path >> >> Regarding transcoding, we are talking here only about L5 >> >> Richard >> >> ________________________________ >> >> Von: Andrew Newton [mailto:andy@hxr.us] >> Gesendet: Do 13.07.2006 17:38 >> An: Stastny Richard >> Cc: Reinaldo Penno; Uzelac, Adam; David Meyer; speermint@ietf.org >> Betreff: Re: [Speermint] Terminology draft - Peering >> >> >> >> Stastny Richard wrote: >> >> >>> If VSP B is giving A all what he needs, does he need to care how VSP >>> B and C are doing this? >>> >>> >> Yes. We do care if any transcoding occurs and we do care if the >> termination is on the PSTN. >> >> -andy >> >> >> >> >> _______________________________________________ >> 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 Fri Jul 14 17:35:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1VJR-00043H-V1; Fri, 14 Jul 2006 17:35:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1VJQ-00043C-Gj for speermint@ietf.org; Fri, 14 Jul 2006 17:35:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1VJQ-0001cS-EH for speermint@ietf.org; Fri, 14 Jul 2006 17:35:04 -0400 Received: from mercury.sunrocket.com ([208.50.38.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1VJO-0005Wc-7y for speermint@ietf.org; Fri, 14 Jul 2006 17:35:04 -0400 Received: (qmail 24082 invoked from network); 14 Jul 2006 21:35:02 -0000 Received: from unknown (HELO [172.16.9.168]) (gkulshreshtha@[172.16.9.168]) (envelope-sender ) by mercury.sunrocket.com (qmail-ldap-1.03) with SMTP for ; 14 Jul 2006 21:35:02 -0000 Message-ID: <44B80E01.6020704@sunrocket.com> Date: Fri, 14 Jul 2006 17:34:57 -0400 From: Gaurav Kulshreshtha Organization: SunRocket Inc. User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Speermint] Terminology draft - Peering References: <9BD5D7887235424FA97DFC223CAE3C2804DA9B43@proton.jnpr.net> <32755D354E6B65498C3BD9FD496C7D462C4B21@oefeg-s04.oefeg.loc> <44B668EA.7010500@hxr.us> <32755D354E6B65498C3BD9FD496C7D462C4B25@oefeg-s04.oefeg.loc> <44B7A432.5060802@sunrocket.com> <32755D354E6B65498C3BD9FD496C7D462C4B2B@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B2B@oefeg-s04.oefeg.loc> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gaurav@sunrocket.com 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 Stastny Richard wrote: > So basically satellite telephony is illegal ;-) > No illegal but definitely a pain in neck. If you have ever used it for personal communication. > > Serious: > > There is two (3) problems with this: > > 1. We are talking here about the determination if you can peer or not > i.e. selecting the VSP which may either host the subscriber or have > a path to the VSP who is. The question is if you are allowed to establish > a secure communication path to start signalling and negotiation without > being rejected in the first place. I cannot imagine you put all information > you negotiate with SIP methods in advance in the DNS as policy elements > > > 2. Keeping in mind the end-to-end principle, I have no idea how any > VSP in the path may know about the media delays involved on the > media path. This is only valid for the case where the media path follows > the signalling path and here it is difficult. > In this light I think the work initiated in the draft-malas-performance-metrics-03.txt is of significance to this group.__ > > 3. I also cannot imaging that a network provider is announcing publicy > his worst case delay ;-) > It won't even if they have the best of the intentions. > > Richard > > ________________________________ > > Von: Gaurav Kulshreshtha [mailto:gaurav@sunrocket.com] > Gesendet: Fr 14.07.2006 16:03 > An: Stastny Richard > Cc: Andrew Newton; speermint@ietf.org > Betreff: Re: [Speermint] Terminology draft - Peering > > > > Richard, > Agree we are talking in this thread about L5 but I would argue that in > our interconnect discussions we have to keep an eye towards delay > elements along the media path e.g. If transcoders at VSP D <--> VSP C > introduce 70 ms delay and then VSP C <->VSP B introduce another 30 ms > delay. We are left with only 50 ms of transit delay time for rest of the > voice path according to ITU specs on Telephony. > > Gaurav > > Stastny Richard wrote: > >> You are still in the signalling path >> >> Regarding transcoding, we are talking here only about L5 >> >> Richard >> >> ________________________________ >> >> Von: Andrew Newton [mailto:andy@hxr.us] >> Gesendet: Do 13.07.2006 17:38 >> An: Stastny Richard >> Cc: Reinaldo Penno; Uzelac, Adam; David Meyer; speermint@ietf.org >> Betreff: Re: [Speermint] Terminology draft - Peering >> >> >> >> Stastny Richard wrote: >> >> >>> If VSP B is giving A all what he needs, does he need to care how >>> VSP B and C are doing this? >>> >>> >> Yes. We do care if any transcoding occurs and we do care if the >> termination is on the PSTN. >> >> -andy >> >> >> >> >> _______________________________________________ >> 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 Jul 14 17:39:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1VNc-0004FT-Pw; Fri, 14 Jul 2006 17:39:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1VNb-0004F6-Dr for speermint@ietf.org; Fri, 14 Jul 2006 17:39:23 -0400 Received: from mercury.sunrocket.com ([208.50.38.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1VNa-0001xL-8c for speermint@ietf.org; Fri, 14 Jul 2006 17:39:23 -0400 Received: (qmail 24797 invoked from network); 14 Jul 2006 21:39:26 -0000 Received: from unknown (HELO [172.16.9.168]) (gkulshreshtha@[172.16.9.168]) (envelope-sender ) by mercury.sunrocket.com (qmail-ldap-1.03) with SMTP for ; 14 Jul 2006 21:39:26 -0000 Message-ID: <44B80F09.2040109@sunrocket.com> Date: Fri, 14 Jul 2006 17:39:21 -0400 From: Gaurav Kulshreshtha Organization: SunRocket Inc. User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: speermint@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Speermint] VSP in SPEERMINT Terminology draft X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gaurav@sunrocket.com 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 All, I have a _tiny_ problem with using the term VSP (Voice Service Provider) in the context of SPEERMINT Terminology draft. The work group name has the term Multimedia interconnect and not Voice internconnect. Thanks Gaurav _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 17 06:05:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Pz2-0000ER-G8; Mon, 17 Jul 2006 06:05:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Pz1-0000EM-F0 for Speermint@ietf.org; Mon, 17 Jul 2006 06:05:47 -0400 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2Pz0-00067B-3O for Speermint@ietf.org; Mon, 17 Jul 2006 06:05:47 -0400 Content-class: urn:content-classes:message Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jul 2006 13:05:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A60655F557A1@isr-jlm-mail.Kayote.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301B362E7@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAoCKnQAARKCvAAu3Z64A== From: "David Schwartz" To: "Michael Hammer \(mhammer\)" , "Uzelac, Adam" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 I seem to be getting a lot of heat for suggesting the independence of namespace resolution and policy (including security). What I keep hearing is that there needs to be a minimal set of requirements (a.k.a. Prime Directives :-) ) for communication (hence the security requirements) for "what is the point of knowing where the other party is it cannot be reached". By extension this model MUST assume that communication in a federation MUST be symmetric. Both parties MUST be able to initiate communication to each other. If not, than the one who cannot initiate, in essence "knows" where the other party is but cannot communicate, hence violating one of the prime directives of federations. This is downright silly. As you will see in the "use case" I am in the process of writing there are complete valid models of federations where this is not the case. Take for example the case of a "closed" club where all members want to RECEIVE traffic only from members of this closed club. One or more of these members may want to additionally SEND traffic to a wider audience while still receiving traffic from only the closed club (why this would happen is discussed in my use case draft). The closed members would need to know where the "open" members are to initiate this communication. By sharing namespace this can be accomplished since all numbers (closed and open) can be known to all members (closed and open) and yet calls originating in closed network would be allowed out based on receiving member policy and calls originating in open network would not be allowed into closed club, again, based on receiving party policy. While you may argue that this is a case of peering between two federations the underlying model still mandates asymmetric signaling capabilities and hence my preference for a federation definition comprised only of a single shared namespace with provisions for sharing/informing/negotiating policy. Cheers, David _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 17 09:50:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2TUk-0006YW-A7; Mon, 17 Jul 2006 09:50:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2TUj-0006YQ-F1 for speermint@ietf.org; Mon, 17 Jul 2006 09:50:45 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2TUi-0000IX-7b for speermint@ietf.org; Mon, 17 Jul 2006 09:50:45 -0400 Received: from ([10.20.62.13]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.22309890; Mon, 17 Jul 2006 09:50:29 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 09:50:29 -0400 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] [wg-business] Possible Interim Meeting in September? Date: Mon, 17 Jul 2006 09:50:29 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF406@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business] Possible Interim Meeting in September? Thread-Index: Acak7z1zjZP3NKfcThuBTi04JLYoqQEuH2lQ From: "Livingood, Jason" To: X-OriginalArrivalTime: 17 Jul 2006 13:50:29.0178 (UTC) FILETIME=[F6CB29A0:01C6A9A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Final request for conflict advice on September 18 - 20, as a range of dates for a possible 2-day interim WG meeting.=20 We'll work up a proposed agenda soon for your review & comment. Thanks Jason=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Tuesday, July 11, 2006 9:46 AM To: speermint@ietf.org Subject: [Speermint] [wg-business] Possible Interim Meeting in September? =09 =09 There has been some discussion about holding an interim meeting before the next IETF. We'll work on a proposed agenda later, but the general idea was to accelerate some of our technical discussions and deliverables work in a smaller, highly-focused, f2f environment. We're thinking that August should be avoided due to vacations in Europe, as well as the first week or so of September due to returning from said vacations. =20 So, I'd like to suggest the possibility of September 18 - 20 (meeting would likely be two days). The location would likely be in the US (the next interim would presumably move to Europe or Canada to accomodate all participants).=20 =20 Is anyone aware of potential meeting conflicts with these dates? If so, what are they?=20 =20 Thanks Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 17 10:40:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2UHK-0002yE-2u; Mon, 17 Jul 2006 10:40:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2UHI-0002y9-OF for speermint@ietf.org; Mon, 17 Jul 2006 10:40:56 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2UHI-0002VK-4K for speermint@ietf.org; Mon, 17 Jul 2006 10:40:56 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 17 Jul 2006 07:40:55 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6HEetbx016481; Mon, 17 Jul 2006 07:40:55 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6HEekin028035; Mon, 17 Jul 2006 07:40:55 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 10:40:25 -0400 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] Comments on Requirements Draft Date: Mon, 17 Jul 2006 10:40:25 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301B368E9@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Comments on Requirements Draft Thread-Index: Acanhtvm2DFlhufSTpeu6CtjXizetQCJNogQ From: "Michael Hammer \(mhammer\)" To: "Uzelac, Adam" , "Jean-Francois Mule" X-OriginalArrivalTime: 17 Jul 2006 14:40:25.0995 (UTC) FILETIME=[F10925B0:01C6A9AE] DKIM-Signature: a=rsa-sha1; q=dns; l=6054; t=1153147255; x=1154011255; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Comments=20on=20Requirements=20Draft; X=v=3Dcisco.com=3B=20h=3D0vEV2Pnq6ElFr23DgdlhzUyl6Gc=3D; b=bMUfMPIE4D/8vxWZWZvNbGbaq5xQtVp/puxShYGy7gNSOfe9HMfM+d5ISK3WKHqY0rDEKq10 OgXRWkWaaY7VHDBCRwNdoBZ5u+fka+JRjnfMD0qtSoQAyCwpwcc5UoRM; Authentication-Results: sj-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 couple nuances inline...=20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 > Sent: Friday, July 14, 2006 4:48 PM > To: Jean-Francois Mule > Cc: speermint@ietf.org > Subject: [Speermint] Comments on Requirements Draft >=20 > Jean-Francois, >=20 > Here's some feedback on the Requirements document - though=20 > this is a good start, as you pointed out in your presentation=20 > at the WG session, there's work that needs to be done to hone=20 > in on the requirements. You asked the WG in your=20 > presentation slot if the requirements should stay as one=20 > document or split into different documents. I can't recall=20 > what was ultimately decided or if this wasn't addressed at=20 > all. I believe it important that we only have one document. =20 >=20 > I will start with 'General Requirements' for now. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 2.1. Unified solution for session peering policies -=20 >=20 > We might consider replacing the word "Unified" with=20 > "Flexible". The text in this section points out that polices=20 > SHOULD be extensible and flexible, but I am not sure that=20 > means Unified. Also, in the quick references to the=20 > different models ("closed, open, etc) the context and=20 > definition of policies changes wildly. >=20 > 2.2. Domain Based >=20 > I think we should rename this section as well to Domain-based Context. > The point, as I read it, is that the domain is the first and=20 > most basic construct in forming peering. Ultimately it's the=20 > interconnection of 2 or more domains that defines peering. =20 > Call routing is to or from the domain. The text states,=20 > "...call routing should rely on URIs." Beyond this point=20 > though, there is some "squirreliness" when stating that "We=20 > assume that all SIP URIs with the same domain-part share the=20 > same set of peering polices". I think that's an assumption=20 > that we can not safely, nor logically make. I suggest that=20 > we point out that a intra-domain is out of scope, and=20 > inter-domain is what we are trying to define. Are we really trying to say that if one contacts a policy server serving that domain name, we can get access to a *set* of peering policies? Not all policies in the set may be applicable, depending on who is asking and which element in the domain is targeted. There may be some ambiguity between mappings of domain elements to ingress proxies operated and associated with certain policies. =20 > 2.3. No blocked calls >=20 > As I understand the intention of this requirement, it's=20 > basically about reachability - meaning - Do I know that=20 > something is out there willing to peer with me before I=20 > attempt to connect? The text reads... >=20 > An originating service provider must be able to determine whether a > SIP URI is open for direct interconnection without=20 > actually sending a > SIP INVITE. This is important as unsuccessful call attempts are > highly undesirable since they can introduce high delays due to > timeouts and can act as an unintended denial of service attack. > (e.g., by repeated TLS handshakes). >=20 > I propose that change the section heading to "Universal Reachability". > I was going to suggest "Global", but I don't want to offend=20 > our little green martian friends. ;)=20 I think there could be blocked calls for those that do not adhere to the policies governing the peering. Would this better be phrased as: High Probability of Call Completion for Policy-Conforming Peers We could also throw in that conformance is enhanced because the policy is easily discoverable, but that is getting a bit wordy. =20 > 2.5. Independence of lower layers >=20 > *NIT* - "...on what technologies are used route the call.." =20 > Need to add a "to" in between "used" and "route". > A couple thoughts - I agree with the intent of the section=20 > but think that it's mis-labeled. The section heading should=20 > be something like "Access and Security Agnostic" or something=20 > like that. We shouldn't the lower layer (Ethernet or POS),=20 > and there are references to upper layers as well (TLS). =20 Agree. There is a dependence in some respects. =20 Could you say: Accommodate flexible use of diverse supporting lower layers? =20 > 2.6. Administrative and technical policies >=20 > This section I think it's going to be very difficult to build=20 > consensus on within the WG. Mostly due to our having to find=20 > some common ground on what should be WG mandate versus Local=20 > Policy. I believe that we should have a requirement on core=20 > set of policies to consider exchanging, but after the=20 > suggestion to exchange information, SPEERMINT scope ends. It may be best to have some meta-categories of things that a well-formed policy should cover. Example: Policies should address authentication, Policies should address minimal signaling mechanisms, Policies should address minimal codec sets, ... whatever. In effect it is all local policy, but what is needed to be covered to be complete and sufficient. Mike > 2.7. Minimal additional cost on call initiation >=20 > I think that this should be changed to "Minimal transaction=20 > cost". The text pertains to discovery of peering next-hop,=20 > connection to next-hop and potentially bearer (if determined=20 > within scope). >=20 > 2.8. Look beyond SIP >=20 > I am struggling with this one a bit. I believe this should=20 > removed altogether. If we should consider a requirement=20 > beyond SIP, then we should re-charter as "PEERMINT" ;) >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > That's all I have for now. >=20 > Adam >=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 Mon Jul 17 10:56:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2UWD-0007zv-Md; Mon, 17 Jul 2006 10:56:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2UWC-0007zq-Ju for Speermint@ietf.org; Mon, 17 Jul 2006 10:56:20 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2UWB-0003ub-AZ for Speermint@ietf.org; Mon, 17 Jul 2006 10:56:20 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Jul 2006 07:56:19 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,251,1149490800"; d="scan'208"; a="32412973:sNHT23932316" 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.20060308/8.12.11) with ESMTP id k6HEuInr006755; Mon, 17 Jul 2006 10:56:18 -0400 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 k6HEuIdU012281; Mon, 17 Jul 2006 10:56:18 -0400 (EDT) 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); Mon, 17 Jul 2006 10:56:18 -0400 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] TLS, etc - Local-policy versus WG mandate Date: Mon, 17 Jul 2006 10:56:17 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301B36901@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAoCKnQAARKCvAAu3Z64AALaSLw From: "Michael Hammer \(mhammer\)" To: "David Schwartz" , "Uzelac, Adam" , X-OriginalArrivalTime: 17 Jul 2006 14:56:18.0093 (UTC) FILETIME=[2887C5D0:01C6A9B1] DKIM-Signature: a=rsa-sha1; q=dns; l=3185; t=1153148178; x=1154012178; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20TLS, =20etc=20-=20Local-policy=20versus=20WG=20mand ate |To:=22David=20Schwartz=22=20, =0A=20=20=20=20=20= 20=20=20=22Uzelac, =20Adam=22=20, =20; X=v=3Dcisco.com=3B=20h=3D2VnnJdMEaY5C8ig4LBewTc6BmaE=3D; b=MXBNJpQTNY8OEar/ecI37ylHoW2GvdiqFdECHBAgTximx+/V03iJRDPKrCKXeU0kHQVzHNDb Qvdgan5J876f5s/ZP8FRpzRI32o17JWiH+Fn05FdOUEuP1WGu0yiYOcq; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 David, I am not sure I understand your use case yet, but would like to ask if this intertwining the policy layer and the signaling layer. In other words, whether one party can communicate and whether they may communicate are two different things. There are many PSTN services, such as the Closed User Group (CUG) feature that can be handled at the signaling layer independent of the fact that one could make the call and it would go through absent the application of this feature. Overlaying these two means that one could be using all the right technical mechanisms and "can" call, but the service feature causes the call to be rejected. You seem to be reinventing the CUG feature via the federation policy. Mike =20 > -----Original Message----- > From: David Schwartz [mailto:David.Schwartz@Kayote.com]=20 > Sent: Monday, July 17, 2006 6:06 AM > To: Michael Hammer (mhammer); Uzelac, Adam; Speermint@ietf.org > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 > I seem to be getting a lot of heat for suggesting the=20 > independence of namespace resolution and policy (including=20 > security). What I keep hearing is that there needs to be a=20 > minimal set of requirements (a.k.a. > Prime Directives :-) ) for communication (hence the security > requirements) for "what is the point of knowing where the=20 > other party is it cannot be reached". >=20 > By extension this model MUST assume that communication in a=20 > federation MUST be symmetric. Both parties MUST be able to=20 > initiate communication to each other. If not, than the one=20 > who cannot initiate, in essence "knows" where the other party=20 > is but cannot communicate, hence violating one of the prime=20 > directives of federations. >=20 > This is downright silly. As you will see in the "use case" I=20 > am in the process of writing there are complete valid models=20 > of federations where this is not the case. Take for example=20 > the case of a "closed" club where all members want to RECEIVE=20 > traffic only from members of this closed club. One or more of=20 > these members may want to additionally SEND traffic to a=20 > wider audience while still receiving traffic from only the=20 > closed club (why this would happen is discussed in my use=20 > case draft). The closed members would need to know where the=20 > "open" members are to initiate this communication. By sharing=20 > namespace this can be accomplished since all numbers (closed=20 > and open) can be known to all members (closed and open) and=20 > yet calls originating in closed network would be allowed out=20 > based on receiving member policy and calls originating in=20 > open network would not be allowed into closed club, again,=20 > based on receiving party policy. >=20 > While you may argue that this is a case of peering between=20 > two federations the underlying model still mandates=20 > asymmetric signaling capabilities and hence my preference for=20 > a federation definition comprised only of a single shared=20 > namespace with provisions for sharing/informing/negotiating policy. >=20 > Cheers, >=20 > David >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 17 11:47:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2VJX-0003NV-Qu; Mon, 17 Jul 2006 11:47:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2VJW-0003NQ-40 for speermint@ietf.org; Mon, 17 Jul 2006 11:47:18 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2VJU-0000f8-UM for speermint@ietf.org; Mon, 17 Jul 2006 11:47:18 -0400 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.22316848; Mon, 17 Jul 2006 11:46:53 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 11:46:51 -0400 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] Terminology draft - Peering Date: Mon, 17 Jul 2006 11:46:51 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96F565B5@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acal1HBRnGBFB0KdStOodqMopGCNkwAMdPP5ABqXLJAAzjXQwA== From: "Livingood, Jason" To: "Michael Hammer \(mhammer\)" , "Stastny Richard" , "David Meyer" X-OriginalArrivalTime: 17 Jul 2006 15:46:51.0660 (UTC) FILETIME=[38AD5CC0:01C6A9B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Richard said: =20 > > Media streams associated with this signaling (if any) are not=20 > > constrained to follow the same set of paths. Michael said: =20 > I think this is an unnecessary and potentially damaging=20 > constraint. It implies that the media path goes through the=20 > same TLS connections and boxes as the signaling at worst. It=20 > may also preclude any optimization of the media path in cases=20 > where the calling and called parties are roaming far from=20 > their home networks, but sitting on the same cell site. > I would much prefer that signaling and media paths be loosely coupled. Jason (me) said: I'm confused - seems like you are both saying the same thing, that media and signaling need not follow the same path through the network. Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 17 11:47:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2VJi-0003R2-1z; Mon, 17 Jul 2006 11:47:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2VJg-0003Qx-78 for speermint@ietf.org; Mon, 17 Jul 2006 11:47:28 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2VJe-0000fH-VI for speermint@ietf.org; Mon, 17 Jul 2006 11:47:28 -0400 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.22316855; Mon, 17 Jul 2006 11:46:57 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 11:46:57 -0400 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] Terminology draft - Peering Date: Mon, 17 Jul 2006 11:46:56 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96F565B6@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: AcanUG49bRKZLPQPSl2qCE8aotNYiwAAE1rgAJYj7/A= From: "Livingood, Jason" To: "Uzelac, Adam" , , "Stastny Richard" X-OriginalArrivalTime: 17 Jul 2006 15:46:57.0129 (UTC) FILETIME=[3BEFDD90:01C6A9B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 a bit of a side-note, currently it is unclear the extent=20 > to which bearer/media should be addressed within the=20 > SPEERMINT scope. I plan on supplying Jean-Francois feedback=20 > on that section [3.3] of the requirements draft - and I=20 > encourage others to do the same to fully vet out the requirements. Please do comment. We should explictly address the questions around media and signaling paths/flows, and this is a subject that comes up often here. We should strive to resolve this question soon. It seems like we have a few options: A - Signaling and Media MUST follow the same path. B - Signaling and Media MAY or MAY NOT follow the same path. (I am sure there's some nuance in here.) C - Signaling and Media SHOULD NOT follow the same path. Option B seems like it may be the optimal compromise that allows for maximum flexibility. Any other options possible? Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 17 11:56:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2VSE-0004W2-5s; Mon, 17 Jul 2006 11:56:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2VSC-0004Vj-7k for speermint@ietf.org; Mon, 17 Jul 2006 11:56:16 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2VS9-0002GL-Rz for speermint@ietf.org; Mon, 17 Jul 2006 11:56:16 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 17 Jul 2006 11:56:14 -0400 X-IronPort-AV: i="4.06,251,1149480000"; d="scan'208"; a="92962708:sNHT25773060" 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.20060308/8.12.11) with ESMTP id k6HFuDj1003175; Mon, 17 Jul 2006 11:56:13 -0400 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 k6HFtrde019365; Mon, 17 Jul 2006 11:56:13 -0400 (EDT) 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); Mon, 17 Jul 2006 11:56:06 -0400 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] Terminology draft - Peering Date: Mon, 17 Jul 2006 11:56:05 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301B36959@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: AcanUG49bRKZLPQPSl2qCE8aotNYiwAAE1rgAJYj7/AAA9mRQA== From: "Michael Hammer \(mhammer\)" To: "Livingood, Jason" , "Uzelac, Adam" , , "Stastny Richard" X-OriginalArrivalTime: 17 Jul 2006 15:56:06.0204 (UTC) FILETIME=[83360FC0:01C6A9B9] DKIM-Signature: a=rsa-sha1; q=dns; l=1965; t=1153151773; x=1154015773; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Terminology=20draft=20-=20Peering |To:=22Livingood, =20Jason=22=20, =0A=20=20 =20=20=20=20=20=20=22Uzelac, =20Adam=22=20, = 0A=20=20=20=20=20=20=20=20, =20=22Stastny=20Richard=22 =20; X=v=3Dcisco.com=3B=20h=3DV9VbvCv1Id03VA1hCr6LfMekZYU=3D; b=KJ7yqYVQH6H02lx4bdWYgiHDJUE9CN6a3uvp1e1fdDeUfVhRuf8VtGUYVa9R2yY1pZkKdUZV HMPS+ghN8fke5xHUngfZuEert62TxvL08PtZTkANkinLZvelcQhSk0eO; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Jason, Could we say it as follows: Signaling will determine: a) whether the media must follow the same path as signaling,=20 b) whether it must follow a different path than signaling, or=20 c) whether may follow a direct path not controlled by signaling. In the above, a) may point to a composed SBC, b) may point to the media part of a decomposed SBC, and c) may let IP routing mechanisms direct the media across any edge router toward the destination. Make sense? Mike > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Monday, July 17, 2006 11:47 AM > To: Uzelac, Adam; gaurav@sunrocket.com; Stastny Richard > Cc: speermint@ietf.org > Subject: RE: [Speermint] Terminology draft - Peering >=20 > > On a bit of a side-note, currently it is unclear the extent=20 > to which=20 > > bearer/media should be addressed within the SPEERMINT=20 > scope. I plan=20 > > on supplying Jean-Francois feedback on that section [3.3] of the=20 > > requirements draft - and I encourage others to do the same to fully=20 > > vet out the requirements. >=20 > Please do comment. We should explictly address the questions=20 > around media and signaling paths/flows, and this is a subject=20 > that comes up often here. We should strive to resolve this=20 > question soon. >=20 > It seems like we have a few options: >=20 > A - Signaling and Media MUST follow the same path. >=20 > B - Signaling and Media MAY or MAY NOT follow the same path. =20 > (I am sure there's some nuance in here.) >=20 > C - Signaling and Media SHOULD NOT follow the same path. >=20 > Option B seems like it may be the optimal compromise that=20 > allows for maximum flexibility. Any other options possible? >=20 >=20 > Jason >=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 Mon Jul 17 12:46:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2WEM-0007ur-6q; Mon, 17 Jul 2006 12:46:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2WEK-0007m2-CJ for speermint@ietf.org; Mon, 17 Jul 2006 12:46:00 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound2-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2WCz-00041M-4I for speermint@ietf.org; Mon, 17 Jul 2006 12:44:38 -0400 Received: from outbound2-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-cpk-R.bigfish.com (Postfix) with ESMTP id 47F47DCC06D; Mon, 17 Jul 2006 16:44:36 +0000 (UTC) Received: from mail39-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound2-cpk.bigfish.com (Postfix) with ESMTP id 3FE3ADCC02E; Mon, 17 Jul 2006 16:44:36 +0000 (UTC) Received: from mail39-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail39-cpk-R.bigfish.com (Postfix) with ESMTP id 262724EB3D9; Mon, 17 Jul 2006 16:44:36 +0000 (UTC) X-BigFish: V Received: by mail39-cpk (MessageSwitch) id 1153154676102033_13562; Mon, 17 Jul 2006 16:44:36 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail39-cpk.bigfish.com (Postfix) with ESMTP id E0D1E4EB416; Mon, 17 Jul 2006 16:44:35 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k6HGiTAg019478; Mon, 17 Jul 2006 11:44:29 -0500 (CDT) Received: from plswg03a.ad.sprint.com (PLSWG03A.corp.sprint.com [10.214.11.49]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k6HGiTB07130; Mon, 17 Jul 2006 11:44:29 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg03a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 11:44:29 -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] Terminology draft - Peering Date: Mon, 17 Jul 2006 11:44:27 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A1301A17684@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: AcanUG49bRKZLPQPSl2qCE8aotNYiwAAE1rgAJYj7/AABbgHoA== From: "Khan, Sohel Q [CTO]" To: "Livingood, Jason" , "Uzelac, Adam" , , "Stastny Richard" X-OriginalArrivalTime: 17 Jul 2006 16:44:29.0889 (UTC) FILETIME=[45F13B10:01C6A9C0] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 We will need all three options depending on the peering situation.=20 -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Monday, July 17, 2006 10:47 AM To: Uzelac, Adam; gaurav@sunrocket.com; Stastny Richard Cc: speermint@ietf.org Subject: RE: [Speermint] Terminology draft - Peering > On a bit of a side-note, currently it is unclear the extent to which=20 > bearer/media should be addressed within the SPEERMINT scope. I plan=20 > on supplying Jean-Francois feedback on that section [3.3] of the=20 > requirements draft - and I encourage others to do the same to fully=20 > vet out the requirements. Please do comment. We should explictly address the questions around media and signaling paths/flows, and this is a subject that comes up often here. We should strive to resolve this question soon. It seems like we have a few options: A - Signaling and Media MUST follow the same path. B - Signaling and Media MAY or MAY NOT follow the same path. (I am sure there's some nuance in here.) C - Signaling and Media SHOULD NOT follow the same path. Option B seems like it may be the optimal compromise that allows for maximum flexibility. Any other options possible? Jason _______________________________________________ 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 Mon Jul 17 13:26:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Wro-0006ej-3C; Mon, 17 Jul 2006 13:26:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Wrm-0006ee-MU for Speermint@ietf.org; Mon, 17 Jul 2006 13:26:46 -0400 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2Wrk-0002Eq-5Z for Speermint@ietf.org; Mon, 17 Jul 2006 13:26:46 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 17 Jul 2006 20:26:40 +0300 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A60655F558D9@isr-jlm-mail.Kayote.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301B36901@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAoCKnQAARKCvAAu3Z64AALaSLwAAUNjnA= From: "David Schwartz" To: "Michael Hammer \(mhammer\)" , "Uzelac, Adam" , X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 Hi Mike The opposite is true. I contend that the CAN is limited to NO SECURITY basic SIP signaling capability. This is my objection to the inclusion of things like TLS in a BASE spec. The MAY is exactly the point I am focusing on only I am calling the mechanism to determine the MAY -- "policy". The MAY includes security, tome of day and just about any other rule that may prevent one party from reaching another even though on the base signaling level this is possible. Cheers, David -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Monday, July 17, 2006 5:56 PM To: David Schwartz; Uzelac, Adam; Speermint@ietf.org Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate David, I am not sure I understand your use case yet, but would like to ask if this intertwining the policy layer and the signaling layer. In other words, whether one party can communicate and whether they may communicate are two different things. There are many PSTN services, such as the Closed User Group (CUG) feature that can be handled at the signaling layer independent of the fact that one could make the call and it would go through absent the application of this feature. Overlaying these two means that one could be using all the right technical mechanisms and "can" call, but the service feature causes the call to be rejected. You seem to be reinventing the CUG feature via the federation policy. Mike =20 > -----Original Message----- > From: David Schwartz [mailto:David.Schwartz@Kayote.com]=20 > Sent: Monday, July 17, 2006 6:06 AM > To: Michael Hammer (mhammer); Uzelac, Adam; Speermint@ietf.org > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 > I seem to be getting a lot of heat for suggesting the=20 > independence of namespace resolution and policy (including=20 > security). What I keep hearing is that there needs to be a=20 > minimal set of requirements (a.k.a. > Prime Directives :-) ) for communication (hence the security > requirements) for "what is the point of knowing where the=20 > other party is it cannot be reached". >=20 > By extension this model MUST assume that communication in a=20 > federation MUST be symmetric. Both parties MUST be able to=20 > initiate communication to each other. If not, than the one=20 > who cannot initiate, in essence "knows" where the other party=20 > is but cannot communicate, hence violating one of the prime=20 > directives of federations. >=20 > This is downright silly. As you will see in the "use case" I=20 > am in the process of writing there are complete valid models=20 > of federations where this is not the case. Take for example=20 > the case of a "closed" club where all members want to RECEIVE=20 > traffic only from members of this closed club. One or more of=20 > these members may want to additionally SEND traffic to a=20 > wider audience while still receiving traffic from only the=20 > closed club (why this would happen is discussed in my use=20 > case draft). The closed members would need to know where the=20 > "open" members are to initiate this communication. By sharing=20 > namespace this can be accomplished since all numbers (closed=20 > and open) can be known to all members (closed and open) and=20 > yet calls originating in closed network would be allowed out=20 > based on receiving member policy and calls originating in=20 > open network would not be allowed into closed club, again,=20 > based on receiving party policy. >=20 > While you may argue that this is a case of peering between=20 > two federations the underlying model still mandates=20 > asymmetric signaling capabilities and hence my preference for=20 > a federation definition comprised only of a single shared=20 > namespace with provisions for sharing/informing/negotiating policy. >=20 > Cheers, >=20 > David >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 17 14:03:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2XRP-0003U4-0d; Mon, 17 Jul 2006 14:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2XRN-0003SU-8C for Speermint@ietf.org; Mon, 17 Jul 2006 14:03:33 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2XRL-0004Zc-Ru for Speermint@ietf.org; Mon, 17 Jul 2006 14:03:33 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Jul 2006 11:03:26 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,251,1149490800"; d="scan'208"; a="32437746:sNHT25274228" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6HI3QHY017155; Mon, 17 Jul 2006 14:03:26 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6HI3QdU028063; Mon, 17 Jul 2006 14:03:26 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 14:03:26 -0400 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] TLS, etc - Local-policy versus WG mandate Date: Mon, 17 Jul 2006 14:03:24 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301B36A16@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acal4zCTQpb1BcQ5TieLxawM8IAl3gAoCKnQAARKCvAAu3Z64AALaSLwAAUNjnAAATrTgA== From: "Michael Hammer \(mhammer\)" To: "David Schwartz" , "Uzelac, Adam" , X-OriginalArrivalTime: 17 Jul 2006 18:03:26.0135 (UTC) FILETIME=[4CF70470:01C6A9CB] DKIM-Signature: a=rsa-sha1; q=dns; l=5115; t=1153159406; x=1154023406; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20TLS, =20etc=20-=20Local-policy=20versus=20WG=20mand ate |To:=22David=20Schwartz=22=20, =0A=20=20=20=20=20= 20=20=20=22Uzelac, =20Adam=22=20, =20; X=v=3Dcisco.com=3B=20h=3D2VnnJdMEaY5C8ig4LBewTc6BmaE=3D; b=m33GKHJVsVv88ohsJjvkBQJU6ouZ+xBwElvYUjwq+Jc36ljyimWSnd+kDkwmpII/+tvcXOWd G/JRqHI/n6SH5WTRT/jNOwFxY5PRXuUrZUMqdGiupj6WHJ8C3inZC4Zu; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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 David, We may be talking past each other based on when and how we envision various policies being applied. I could see some policies being applied before the first INVITE gets sent and some after. =20 Guess I'll have to wait for your use case to better understand where you are coming from. =20 Hopefully, it covers the nature of the data session and whether you expect re-INVITEs, REFERs, UPDATEs, BYEs and such to occur in only one direction, or whether you are referring to uni-directional media. I could read all sorts of things into the words and be quite wrong about what you intend. Mike > -----Original Message----- > From: David Schwartz [mailto:David.Schwartz@Kayote.com]=20 > Sent: Monday, July 17, 2006 1:27 PM > To: Michael Hammer (mhammer); Uzelac, Adam; Speermint@ietf.org > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 > Hi Mike >=20 > The opposite is true. I contend that the CAN is limited to NO=20 > SECURITY basic SIP signaling capability. This is my objection=20 > to the inclusion of things like TLS in a BASE spec. The MAY=20 > is exactly the point I am focusing on only I am calling the=20 > mechanism to determine the MAY -- "policy". The MAY includes=20 > security, tome of day and just about any other rule that may=20 > prevent one party from reaching another even though on the=20 > base signaling level this is possible. >=20 > Cheers, >=20 > David >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, July 17, 2006 5:56 PM > To: David Schwartz; Uzelac, Adam; Speermint@ietf.org > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 > David, >=20 > I am not sure I understand your use case yet, but would like=20 > to ask if this intertwining the policy layer and the=20 > signaling layer. In other words, whether one party can=20 > communicate and whether they may communicate are two=20 > different things. There are many PSTN services, such as the=20 > Closed User Group (CUG) feature that can be handled at the=20 > signaling layer independent of the fact that one could make=20 > the call and it would go through absent the application of=20 > this feature. Overlaying these two means that one could be=20 > using all the right technical mechanisms and "can" call, but=20 > the service feature causes the call to be rejected. >=20 > You seem to be reinventing the CUG feature via the federation policy. >=20 > Mike > =20 >=20 > > -----Original Message----- > > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > Sent: Monday, July 17, 2006 6:06 AM > > To: Michael Hammer (mhammer); Uzelac, Adam; Speermint@ietf.org > > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate > >=20 > > I seem to be getting a lot of heat for suggesting the=20 > independence of=20 > > namespace resolution and policy (including security). What I keep=20 > > hearing is that there needs to be a minimal set of requirements=20 > > (a.k.a. > > Prime Directives :-) ) for communication (hence the security > > requirements) for "what is the point of knowing where the=20 > other party=20 > > is it cannot be reached". > >=20 > > By extension this model MUST assume that communication in a=20 > federation=20 > > MUST be symmetric. Both parties MUST be able to initiate=20 > communication=20 > > to each other. If not, than the one who cannot initiate, in essence=20 > > "knows" where the other party is but cannot communicate, hence=20 > > violating one of the prime directives of federations. > >=20 > > This is downright silly. As you will see in the "use case"=20 > I am in the=20 > > process of writing there are complete valid models of federations=20 > > where this is not the case. Take for example the case of a "closed"=20 > > club where all members want to RECEIVE traffic only from members of=20 > > this closed club. One or more of these members may want to=20 > > additionally SEND traffic to a wider audience while still receiving=20 > > traffic from only the closed club (why this would happen is=20 > discussed=20 > > in my use case draft). The closed members would need to=20 > know where the=20 > > "open" members are to initiate this communication. By sharing=20 > > namespace this can be accomplished since all numbers=20 > (closed and open)=20 > > can be known to all members (closed and open) and yet calls=20 > > originating in closed network would be allowed out based on=20 > receiving=20 > > member policy and calls originating in open network would not be=20 > > allowed into closed club, again, based on receiving party policy. > >=20 > > While you may argue that this is a case of peering between two=20 > > federations the underlying model still mandates asymmetric=20 > signaling=20 > > capabilities and hence my preference for a federation definition=20 > > comprised only of a single shared namespace with provisions for=20 > > sharing/informing/negotiating policy. > >=20 > > Cheers, > >=20 > > David > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 17 19:28:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2cVW-0001sb-CH; Mon, 17 Jul 2006 19:28:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2cVU-0001sW-BJ for Speermint@ietf.org; Mon, 17 Jul 2006 19:28:08 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2cVS-00054Q-VU for Speermint@ietf.org; Mon, 17 Jul 2006 19:28:08 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k6HNS5aK000272; Mon, 17 Jul 2006 23:28:05 GMT Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate From: Daryl Malas To: David Schwartz In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A60655F557A1@isr-jlm-mail.Kayote.com> References: <1DDB0D3CC4E7F14FAE946361C0A60655F557A1@isr-jlm-mail.Kayote.com> Content-Type: text/plain Date: Mon, 17 Jul 2006 17:28:35 -0600 Message-Id: <1153178916.19821.16.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: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Comments in-line... On Mon, 2006-07-17 at 13:05 +0300, David Schwartz wrote: > I seem to be getting a lot of heat for suggesting the independence of > namespace resolution and policy (including security). What I keep > hearing is that there needs to be a minimal set of requirements (a.k.a. > Prime Directives :-) ) for communication (hence the security > requirements) for "what is the point of knowing where the other party is > it cannot be reached". > I'm not sure I'm following you here...We have already defined these independently in the peering architecture draft. These have been defined as the Location Function and Operation Function (providing policy). > By extension this model MUST assume that communication in a federation > MUST be symmetric. Both parties MUST be able to initiate communication > to each other. If not, than the one who cannot initiate, in essence > "knows" where the other party is but cannot communicate, hence violating > one of the prime directives of federations. This is not necessarily true. Although, it may take place in this manner, policy and routing can take place at varying levels. It may take place within the peers network, the federation, or some undefined hierarchical level. In other words, if a LF within the peers network identifies the routing of a specific call goes beyond the federation, then it will send it to that signaling function beyond the federation. Why would it depend on the federation to deal with all of its routing...this architecture does not assume the peer (operator, vsp, etc.) relinquishes all policy and routing functions. This architecture provides only routing and policy information for the federation and perhaps peering between the federations. If the peer sends all calls (essentially relinquishing its own policy and routing) to the federation LF and OF, then it very well may end up with many 404's, 401's, 503's, etc...failed call attempts. > > This is downright silly. As you will see in the "use case" I am in the > process of writing there are complete valid models of federations where > this is not the case. Take for example the case of a "closed" club where > all members want to RECEIVE traffic only from members of this closed > club. One or more of these members may want to additionally SEND traffic > to a wider audience while still receiving traffic from only the closed > club (why this would happen is discussed in my use case draft). The > closed members would need to know where the "open" members are to > initiate this communication. By sharing namespace this can be > accomplished since all numbers (closed and open) can be known to all > members (closed and open) and yet calls originating in closed network > would be allowed out based on receiving member policy and calls > originating in open network would not be allowed into closed club, > again, based on receiving party policy. > This describes the ability for a peer to be a member of multiple federations, right?! In this case, you would likely access varying LF's, SF's, and OF's, relative to the varying federations to communicate as has been defined. We have not ever said an operator may only be a member of one federation. > While you may argue that this is a case of peering between two > federations the underlying model still mandates asymmetric signaling > capabilities and hence my preference for a federation definition > comprised only of a single shared namespace with provisions for > sharing/informing/negotiating policy. > My primary rebuttal is this can be solved in many ways...should we define all of these, which would simply take away an operator's own routing creativity and flexibility? ...or, should we define principle functions, which may be implemented to enable peering in manners that enable greater creativity and flexibility in peering? My two cents...thanks! > Cheers, > > David > > _______________________________________________ > 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 Mon Jul 17 19:31:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2cYQ-0001zn-JC; Mon, 17 Jul 2006 19:31:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2cYP-0001zi-14 for speermint@ietf.org; Mon, 17 Jul 2006 19:31:09 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2cYN-0005aW-NG for speermint@ietf.org; Mon, 17 Jul 2006 19:31:09 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k6HNUvaK000957; Mon, 17 Jul 2006 23:30:57 GMT Subject: RE: [Speermint] Terminology draft - Peering From: Daryl Malas To: "Michael Hammer (mhammer)" In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301B36959@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E301B36959@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain Date: Mon, 17 Jul 2006 17:31:29 -0600 Message-Id: <1153179089.19821.20.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: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: speermint@ietf.org, Stastny Richard , "Uzelac, Adam" , "Livingood, Jason" 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 Mike, I agree, the following three options will occur. We MUST allow for all of these methods (a,b, and c). --Daryl On Mon, 2006-07-17 at 11:56 -0400, Michael Hammer (mhammer) wrote: > Jason, > > Could we say it as follows: > > Signaling will determine: > a) whether the media must follow the same path as signaling, > b) whether it must follow a different path than signaling, or > c) whether may follow a direct path not controlled by signaling. > > In the above, a) may point to a composed SBC, b) may point to the media > part of a decomposed SBC, and c) may let IP routing mechanisms direct > the media across any edge router toward the destination. > > Make sense? > > Mike > > > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Monday, July 17, 2006 11:47 AM > > To: Uzelac, Adam; gaurav@sunrocket.com; Stastny Richard > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Terminology draft - Peering > > > > > On a bit of a side-note, currently it is unclear the extent > > to which > > > bearer/media should be addressed within the SPEERMINT > > scope. I plan > > > on supplying Jean-Francois feedback on that section [3.3] of the > > > requirements draft - and I encourage others to do the same to fully > > > vet out the requirements. > > > > Please do comment. We should explictly address the questions > > around media and signaling paths/flows, and this is a subject > > that comes up often here. We should strive to resolve this > > question soon. > > > > It seems like we have a few options: > > > > A - Signaling and Media MUST follow the same path. > > > > B - Signaling and Media MAY or MAY NOT follow the same path. > > (I am sure there's some nuance in here.) > > > > C - Signaling and Media SHOULD NOT follow the same path. > > > > Option B seems like it may be the optimal compromise that > > allows for maximum flexibility. Any other options possible? > > > > > > Jason > > > > _______________________________________________ > > 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 Tue Jul 18 14:18:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2u8s-00057M-DI; Tue, 18 Jul 2006 14:17:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2u8q-00057H-TC for speermint@ietf.org; Tue, 18 Jul 2006 14:17:56 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2u8p-0003Ed-Hd for speermint@ietf.org; Tue, 18 Jul 2006 14:17:56 -0400 Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.22471891; Tue, 18 Jul 2006 14:17:31 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 14:17:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6AA96.6E3721A8" Date: Tue, 18 Jul 2006 14:17:29 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF436@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [wg-business] speermint Interim #1: Sept 18 - 19, Philadelphia (Plus TWO Requests) Thread-Index: Acaqlm4bKkTqwW+2Q0eBZNsw4q8PPA== X-Priority: 1 Priority: Urgent Importance: high From: "Livingood, Jason" To: X-OriginalArrivalTime: 18 Jul 2006 18:17:30.0548 (UTC) FILETIME=[6EAFF740:01C6AA96] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Subject: [Speermint] [wg-business] speermint Interim #1: Sept 18 - 19, Philadelphia (Plus TWO Requests) 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C6AA96.6E3721A8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Okay -- so our discussions regarding an interim meeting are progressing. The tentative dates are Monday and Tuesday, September 18 and 19, 2006. This is the week after VON in Boston. The interim meeting would tentatively be held in Philadelphia, which is not terribly far from Boston. =20 Discounted hotel room rates, with complimentary Internet access, would be made available. Attendees would only incur costs of travel to the meeting, plus lunch and dinner each day; there would be no fee to attend the meeting itself. The conference room will have whiteboards / drawing boards, an LCD projector, and Internet access. REQUEST #1: I have attached a proposed agenda and am requesting comments on this from the WG. =20 That agenda also contains the following meeting objective: To have detailed debate and discussion of open issues for current WG drafts and move ahead work items more quickly than we can by having a 2 hour meeting every 4 months at the main IETF meetings. Also, kick-off new WG items in detail and make rapid progress towards achieving WG milestones. REQUEST #2: I would also like to request a show of hands so we know how big a conference room to book. Please email me PRIVATELY at jason_livingood@cable.comcast.com if you would attend this meeting. Thanks! Jason ------_=_NextPart_001_01C6AA96.6E3721A8 Content-Type: text/plain; name="speermint_agenda_interim_1 - v2.txt" Content-Transfer-Encoding: base64 Content-Description: speermint_agenda_interim_1 - v2.txt Content-Disposition: attachment; filename="speermint_agenda_interim_1 - v2.txt" U2Vzc2lvbiBQRUVSaW5nIGZvciBNdWx0aW1lZGlhIElOVGVyY29ubmVjdCAoc3BlZXJtaW50KQ0K DQpTUEVFUk1JTlQgSW50ZXJpbSBNZWV0aW5nICMxDQoNCkRhdGVzOiBTZXB0ZW1iZXIgMTggLSAx OSwgMjAwNg0KDQpMb2NhdGlvbjogUGhpbGFkZWxwaGlhLCBQQSwgVVNBIChDZW50ZXIgQ2l0eSAv IERvd250b3duKQ0KDQpIb3RlbCAvIENvbmZlcmVuY2UgTG9jYXRpb246IEluIG5lZ290aWF0aW9u IG5vdywgYW5kIHRvIGJlIGFubm91bmNlZCBiZWZvcmUgdGhlIGVuZCBvZiBKdWx5IDIwMDYuDQoN Ck9iamVjdGl2ZTogIFRvIGhhdmUgZGV0YWlsZWQgZGViYXRlIGFuZCBkaXNjdXNzaW9uIG9mIG9w ZW4gaXNzdWVzIGZvciBjdXJyZW50IFdHIGRyYWZ0cyBhbmQgbW92ZSBhaGVhZCB3b3JrIA0KaXRl bXMgbW9yZSBxdWlja2x5IHRoYW4gd2UgY2FuIGJ5IGhhdmluZyBhIDIgaG91ciBtZWV0aW5nIGV2 ZXJ5IDQgbW9udGhzIGF0IHRoZSBtYWluIElFVEYgbWVldGluZ3MuICBBbHNvLCANCmtpY2stb2Zm IG5ldyBXRyBpdGVtcyBpbiBkZXRhaWwgYW5kIG1ha2UgcmFwaWQgcHJvZ3Jlc3MgdG93YXJkcyBh Y2hpZXZpbmcgV0cgbWlsZXN0b25lcy4gDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCkNIQUlSUzoJICAgIERh dmlkIE1leWVyICAgICAgCTxkbW1AMS00LTUubmV0Pg0KCSAgICBKYXNvbiBMaXZpbmdvb2QgIAk8 amFzb25fbGl2aW5nb29kQGNhYmxlLmNvbWNhc3QuY29tPg0KDQpTRUNSRVRBUlk6ICBBbGV4YW5k ZXIgTWF5cmhvZmVyIDxhbGV4YW5kZXIubWF5cmhvZmVyQG5pYy5hdD4NCg0KVEVOVEFUSVZFIC8g UFJPUE9TRUQgQUdFTkRBDQoNCkRheSAxCTA4MTUgLSAxODAwDQoNCiAgIDAgLSAgUmVnaXN0cmF0 aW9uICYgQ29udGluZW50YWwgQnJlYWtmYXN0CQkJCTQ1IG1pbnV0ZXMJLy8gCTA4MTUgLSAwOTAw DQoNCjxPVkVSVklFVz4NCg0KICAgMSAtIFJldmlldyBvZiBBZ2VuZGEsIE1lZXRpbmcgTG9naXN0 aWNzLCBhbmQgV2VsY29tZQkJCTMwIG1pbnV0ZXMJLy8JMDkwMCAtIDA5MzANCgkgSmFzb24gTGl2 aW5nb29kDQoNCjxQUk9HUkVTUyBPRkZJQ0lBTCBXRyBEUkFGVFM+DQoNCiAgIDIgLSAgRGlzY3Vz cyBhbmQgQ2xvc2UgT3V0IFJlbWFpbmluZyBJc3N1ZXMgKFBhcnQgMSkJCQk2MCBtaW51dGVzCS8v CTA5MzAgLSAxMDMwDQoJU1BFRVJNSU5UIFRlcm1pbm9sb2d5IERyYWZ0DQoJZHJhZnQtaWV0Zi1z cGVlcm1pbnQtdGVybWlub2xvZ3ktWFgNCgkgIERhdmUgTWV5ZXINCg0KICAgMyAtICBCUkVBSwkJ CQkJCQkJMTUgbWludXRlcyAJLy8JMTAzMCAtIDEwNDUNCg0KICAgNCAtICBEaXNjdXNzIE9wZW4g SXNzdWVzIGFuZCBRdWVzdGlvbnMgUG9zZWQgQnkgRWRpdG9yIChQYXJ0IDEpCTYwIG1pbnV0ZXMJ Ly8JMTA0NSAtIDExNDUNCiAgICAJTWluaW11bSBTZXQgb2YgUmVxdWlyZW1lbnRzIGZvciBTSVAt QmFzZWQgVm9JUCBJbnRlcmNvbm5lY3Rpb24NCglkcmFmdC1pZXRmLXNwZWVybWludC1yZXF1aXJl bWVudHMtWFgNCgkgIEplYW4tRnJhbmNvaXMgTXVsZQ0KDQogICA1IC0gIExVTkNICQkJCQkJCQk5 MCBtaW51dGVzCS8vCTExNDUgLSAxMzE1DQoJT24gWW91ciBPd24sIEluIExvY2FsIEFyZWENCg0K ICAgNiAtICBEaXNjdXNzIE9wZW4gSXNzdWVzIGFuZCBRdWVzdGlvbnMgUG9zZWQgQnkgRWRpdG9y IChQYXJ0IDIpCTYwIG1pbnV0ZXMJLy8JMTMxNSAtIDE0MTUNCiAgICAJTWluaW11bSBTZXQgb2Yg UmVxdWlyZW1lbnRzIGZvciBTSVAtQmFzZWQgVm9JUCBJbnRlcmNvbm5lY3Rpb24NCglkcmFmdC1p ZXRmLXNwZWVybWludC1yZXF1aXJlbWVudHMtWFgNCgkgIEplYW4tRnJhbmNvaXMgTXVsZQ0KDQog ICA3IC0gIFJldmlldyBhbmQgRGlzY3VzcyBOZXcgV0cgRHJhZnQgKFBhcnQgMSkNCglNZXNzYWdl IEZsb3dzIEFzc29jaWF0ZWQgd2l0aCBTUEVFUk1JTlQgUm91dGluZyBBcmNoaXRlY3R1cmUJMzAg bWludXRlcwkvLwkxNDE1IC0gMTQ0NQ0KICAgIAlkcmFmdC1pZXRmLW1lc3NhZ2UtZmxvd3MtWFgg DQoJICBSZWluYWxkbyBQZW5ubw0KDQogICA4IC0gIEJSRUFLCQkJCQkJCQkxNSBtaW51dGVzIAkv LwkxNDQ1IC0gMTUwMA0KDQogICA5IC0gIFJldmlldyBhbmQgRGlzY3VzcyBOZXcgV0cgRHJhZnQg KFBhcnQgMikNCglNZXNzYWdlIEZsb3dzIEFzc29jaWF0ZWQgd2l0aCBTUEVFUk1JTlQgUm91dGlu ZyBBcmNoaXRlY3R1cmUJMzAgbWludXRlcwkvLwkxNTAwIC0gMTUzMA0KICAgIAlkcmFmdC1pZXRm LW1lc3NhZ2UtZmxvd3MtWFggDQoJICBSZWluYWxkbyBQZW5ubw0KDQo8SU5GT1JNQVRJVkUgLyBF WFBFUlQgQlJJRUZJTkdTPg0KDQogICAxMCAtIFBvdGVudGlhbCBWb0lQIFNlY3VyaXR5IEF0dGFj ayBWZWN0b3JzICgqKlRCRCoqKQkJOTAgbWludXRlcyAJLy8JMTUzMCAtIDE3NDUNCglJbnRlbmRl ZCB0byBJbmZvcm0gU2VjdXJpdHkgJiBUcnVzdCBSZXF1aXJlbWVudHMsIEVkdWNhdGUgV0cNCgkq IFZPSVAgU0VDVVJJVFkgQVNTTi4/DQoJKiBSRVBVVEFUSU9OIC8gREtJTSAvIEVNQUlMIEFOVEkt QUJVU0UgVE9PTCBUUkFOU0ZFUlJBQklMSVRZPw0KCSogRkJJIC8gSU5GUkFHQVJEIE9SIE9USEVS IEVYUEVSVCBCUklFRklOR1M/Pw0KDQoNCiAgIDExIC0gQ2xvc2UgTWVldGluZyBEYXkgCQkJCQkJ MTUgbWludXRlcwkvLwkxNzQ1IC0gMTgwMA0KCT8gRGlubmVyIC8gU29jaWFsIExvZ2lzdGljcw0K CVJldmlldyBEYXkgMiBBZ2VuZGENCgkgIEphc29uIExpdmluZ29vZA0KDQo8QUZURVIgSE9VUlM+ DQoJDQoJPyBEaW5uZXIgYXMgYSBncm91cD8gIFdlJ2QgbmVlZCBhIHNwb25zb3IuDQoJPyBPciwg cHJvdmlkZSBsaXN0IG9mIHJlc3RhdXJhbnRzIGFuZCBsZXQgcGVvcGxlIGRpbmUgb3V0IGluIHRo ZWlyIG93biBncm91cHM/DQoNCg0KRGF5IDIgCTA4MzAgLSAxNTAwDQoNCiAgIDEgLSAgQ29udGlu ZW50YWwgQnJlYWtmYXN0CQkJCQkJMzAgbWludXRlcyAJLy8JMDgzMCAtIDA5MDANCg0KICAgMiAt ICBGZWRlcmF0aW9ucyBEaXNjdXNzaW9uCQkJCQkJNjAgbWludXRlcwkvLwkwOTAwIC0gMTAwMA0K CSAgTWljaGFlbCBIYWJlcmxlcg0KDQogICAzIC0gIEFyY2hpdGVjdHVyZSBEcmFmdHMgUmV2aWV3 LCBEZWJhdGUsIERpc2N1c3Npb24gKFBhcnQgMSkJCTMwIG1pbnV0ZXMJLy8JMTAwMCAtIDEwMzAN CgkgIFRCRA0KDQogICA0IC0gIEJSRUFLCQkJCQkJCQkxNSBtaW51dGVzCS8vCTEwMzAgLSAxMDQ1 DQoNCiAgIDUgLSAgQXJjaGl0ZWN0dXJlIERyYWZ0cyBSZXZpZXcsIERlYmF0ZSwgRGlzY3Vzc2lv biAoUGFydCAyKQkJNjAgbWludXRlcwkvLwkxMDQ1IC0gMTE0NQ0KCSAgVEJEDQoNCjxGSU5BTCBS RVZJRVcgJiBDT05TRU5TVVM+DQoNCiAgIDYgLSAgRmluYWwgUmV2aWV3IG9mIElzc3VlcyAmIENv bnNlbnN1cyBBZ3JlZW1lbnQJCQkxNSBtaW51dGVzCS8vCTExNDUtIDEyMDANCglTUEVFUk1JTlQg VGVybWlub2xvZ3kgRHJhZnQNCglkcmFmdC1pZXRmLXNwZWVybWludC10ZXJtaW5vbG9neS1YWA0K CSAgRGF2ZSBNZXllcg0KDQogICA3IC0gIExVTkNICQkJCQkJCQk5MCBtaW51dGVzCS8vCTEyMDAg LSAxMzMwDQoJT24gWW91ciBPd24sIEluIExvY2FsIEFyZWENCg0KDQogICA4IC0gIEZpbmFsIFJl dmlldyBvZiBJc3N1ZXMgJiBDb25zZW5zdXMgQWdyZWVtZW50CQkJMzAgbWludXRlcwkvLwkxMzMw IC0gMTQwMA0KICAgIAlNaW5pbXVtIFNldCBvZiBSZXF1aXJlbWVudHMgZm9yIFNJUC1CYXNlZCBW b0lQIEludGVyY29ubmVjdGlvbg0KCWRyYWZ0LWlldGYtc3BlZXJtaW50LXJlcXVpcmVtZW50cy1Y WA0KCSAgSmVhbi1GcmFuY29pcyBNdWxlDQoNCiAgIDkgLSAgRmluYWwgUmV2aWV3IG9mIElzc3Vl cyAmIENvbnNlbnN1cyBBZ3JlZW1lbnQNCglNZXNzYWdlIEZsb3dzIEFzc29jaWF0ZWQgd2l0aCBT UEVFUk1JTlQgUm91dGluZyBBcmNoaXRlY3R1cmUJMzAgbWludXRlcwkvLwkxNDAwIC0gMTQzMA0K ICAgIAlkcmFmdC1pZXRmLW1lc3NhZ2UtZmxvd3MtWFggDQoJICBSZWluYWxkbyBQZW5ubw0KDQog ICAxMCAtIE1lZXRpbmcgQ2xvc2VzCQkJCQkJCTMwIG1pbnV0ZXMJLy8JMTQzMCAtIDE1MDANCiAg CVJldmlldyBvZiBBY3Rpb24gSXRlbXMgYW5kIFBsYW5uaW5nIGZvciBOZXh0IElFVEYgTWVldGlu ZwkNCg0KDQo8TWVldGluZyBMb2NhdGlvbiBMb2dpc3RpY3M+DQoJSG90ZWw6IFRCRCBpbiBDZW50 ZXIgQ2l0eSBQaGlsYWRlbHBoaWENCglBaXJwb3J0OiBQSEwsIFBoaWxhZGVscGhpYSBJbnRlcm5h dGlvbmFsIEFpcnBvcnQNCglUcmFuc3BvcnRhdGlvbiBmcm9tIFBITCB0byBDZW50ZXIgQ2l0eTog UjEgQWlycG9ydCBFeHByZXNzIFRyYWluICh+JDUgYW5kIDIwIG1pbnMpIG9yIFRheGkgKH4kMjUp DQoJVHJhaW4gU3RhdGlvbjogQW10cmFrJ3MgMzAgU3RyZWV0IFN0YXRpb24gKDUgLSAxMCBtaW5z IHRheGkgdG8gbWVldGluZyBsb2NhdGlvbikNCglXZWJzaXRlOiBodHRwOi8vd3d3LmdvcGhpbGEu Y29tDQoJT3RoZXIgSG90ZWwgT3B0aW9uczogVEJEDQoNCjwvRU5EIE9GIEFHRU5EQT4= ------_=_NextPart_001_01C6AA96.6E3721A8 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_001_01C6AA96.6E3721A8-- From speermint-bounces@ietf.org Tue Jul 18 18:15:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2xr5-0001Bo-QI; Tue, 18 Jul 2006 18:15:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2xr5-0001Bj-4p for speermint@ietf.org; Tue, 18 Jul 2006 18:15:51 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2xr2-0005gf-OG for speermint@ietf.org; Tue, 18 Jul 2006 18:15:51 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k6IMFR3x021932; Tue, 18 Jul 2006 15:15:27 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k6IMFRsE021931; Tue, 18 Jul 2006 15:15:27 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 18 Jul 2006 15:15:27 -0700 From: David Meyer To: speermint@ietf.org Message-ID: <20060718221527.GA21857@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Jason_Livingood@cable.comcast.com Subject: [Speermint] draft-ietf-speermint-terminology-01.txt posted 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="===============0953836493==" Errors-To: speermint-bounces@ietf.org --===============0953836493== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I *think* I have everyone's recent comments in -01. If you'd like an early view (before it hits the id repository), please see http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-01.txt Let me know if I've addressed your concerns; we need to make sure we have solid consensus before last calling this one. BTW, anyone noticed the mess in http://xml.resource.org/public/rfc/bibxml3=20 in particulre, the inconsistent file names... thnx, --dmm --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEvV1/ORgD1qCZ2KcRAvXTAJ46Y5eVXWnxrEadhDKia2WdwW9awQCeOze8 pV1HCAIn4kCnw4L+i2exqLQ= =xDrD -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- --===============0953836493== 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 --===============0953836493==-- From speermint-bounces@ietf.org Tue Jul 18 20:40:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G307U-0000lh-7q; Tue, 18 Jul 2006 20:40:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G307S-0000lc-UO for speermint@ietf.org; Tue, 18 Jul 2006 20:40:54 -0400 Received: from mail.xconnect.net ([213.187.46.35] helo=xconnect.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G307Q-0004pR-GT for speermint@ietf.org; Tue, 18 Jul 2006 20:40:54 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] draft-ietf-speermint-terminology-01.txt posted X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 19 Jul 2006 01:40:45 +0100 Message-ID: <062B8EE81F2EC945A577C3EFAE1DD68E1A2F5E@mail.xconnect.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] draft-ietf-speermint-terminology-01.txt posted Thread-Index: Acaqt75Y7PlTc5bMSj+o9mwHkxQbpwADyvMA From: "Eli Katz" To: "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Jason_Livingood@cable.comcast.com 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 David, Thanx for putting together the -01 update. Some brief comments/clarification on the -01 txt; specifically section 6 (/4.4) 1. A SP can be a member of=20 - no-federations (e.g bilateral relations only),=20 - 1 federation=20 - or multiple federations=20 In all cases, this does not preclude a SP having a combination of bi-lateral(s), as well as federation(s) (multi-lateral) interconnections. 2. A Federation, can include some OR all of the following, in relation to its SP members=20 - a) common policy=20 - ad-hoc only with policy in public DNS [ e.g lendl-domain-policy-ddds draft ] OR - or policy managed by federation entity [ note "policy", can cover some/all of the areas below ] - b) federated enum directory root or services; and/or address resolution mechanism (e.g srv) - c) session signalling via Federation policy / services - d) media streams via federation policy / services (e.g media flows thru federation, and/or transcoding etc) - e) federation security policy / services=20 (e.g Identity/Trust/Certificates/SPIT/Authentication/Security mgmt) - f) interconnection policies (e.g individual peering policies, who I will accept traffic from within Federation) - g) L2 / L3 policy / service, =20 - h) billing / commercial / contractual policy / service 3. Announcement of Federation membership by Terminating SP - in I-ENUM AND/OR - within private ENUM Federation discovery mechanism AND/OR - Public DNS based on Service Provider domain Eli=20 -----Original Message----- From: David Meyer [mailto:dmm@1-4-5.net]=20 Sent: 18 July 2006 23:15 To: speermint@ietf.org Cc: Jason_Livingood@cable.comcast.com Subject: [Speermint] draft-ietf-speermint-terminology-01.txt posted I *think* I have everyone's recent comments in -01. If you'd like an early view (before it hits the id repository), please see =09 http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-01.txt Let me know if I've addressed your concerns; we need to make sure we have solid consensus before last calling this one. BTW, anyone noticed the mess in http://xml.resource.org/public/rfc/bibxml3=20 in particulre, the inconsistent file names... thnx, --dmm ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jul 19 00:35:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G33mL-0005td-2T; Wed, 19 Jul 2006 00:35:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G33mJ-0005tX-EY for speermint@ietf.org; Wed, 19 Jul 2006 00:35:19 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G33mH-0007kO-0d for speermint@ietf.org; Wed, 19 Jul 2006 00:35:19 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k6J4Yq5s029111; Tue, 18 Jul 2006 21:34:52 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k6J4YmgC029110; Tue, 18 Jul 2006 21:34:48 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 18 Jul 2006 21:34:48 -0700 From: David Meyer To: Eli Katz Subject: Re: [Speermint] draft-ietf-speermint-terminology-01.txt posted Message-ID: <20060719043448.GA29094@1-4-5.net> References: <062B8EE81F2EC945A577C3EFAE1DD68E1A2F5E@mail.xconnect.net> Mime-Version: 1.0 In-Reply-To: <062B8EE81F2EC945A577C3EFAE1DD68E1A2F5E@mail.xconnect.net> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: speermint@ietf.org, Jason_Livingood@cable.comcast.com 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="===============1461433707==" Errors-To: speermint-bounces@ietf.org --===============1461433707== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Eli, Thanks for the detailed comments. Will put them into -02.=20 --dmm On Wed, Jul 19, 2006 at 01:40:45AM +0100, Eli Katz wrote: > David, >=20 > Thanx for putting together the -01 update. >=20 > Some brief comments/clarification on the -01 txt; specifically section 6 > (/4.4) >=20 > 1. A SP can be a member of=20 > - no-federations (e.g bilateral relations only),=20 > - 1 federation=20 > - or multiple federations=20 >=20 > In all cases, this does not preclude a SP having a combination of > bi-lateral(s), as well as federation(s) (multi-lateral) > interconnections. >=20 > 2. A Federation, can include some OR all of the following, in relation > to its SP members=20 > - a) common policy=20 > - ad-hoc only with policy in public DNS [ e.g > lendl-domain-policy-ddds draft ] OR > - or policy managed by federation entity > [ note "policy", can cover some/all of the areas below ] > - b) federated enum directory root or services; and/or address > resolution mechanism (e.g srv) > - c) session signalling via Federation policy / services > - d) media streams via federation policy / services > (e.g media flows thru federation, and/or transcoding > etc) > - e) federation security policy / services=20 > (e.g > Identity/Trust/Certificates/SPIT/Authentication/Security mgmt) > - f) interconnection policies > (e.g individual peering policies, who I will accept > traffic from within Federation) > - g) L2 / L3 policy / service, =20 > - h) billing / commercial / contractual policy / service >=20 > 3. Announcement of Federation membership by Terminating SP > - in I-ENUM AND/OR > - within private ENUM Federation discovery mechanism AND/OR > - Public DNS based on Service Provider domain >=20 >=20 > Eli=20 >=20 > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net]=20 > Sent: 18 July 2006 23:15 > To: speermint@ietf.org > Cc: Jason_Livingood@cable.comcast.com > Subject: [Speermint] draft-ietf-speermint-terminology-01.txt posted >=20 >=20 > I *think* I have everyone's recent comments in -01. If > you'd like an early view (before it hits the id > repository), please see >=20 > =09 > http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-01.txt >=20 > Let me know if I've addressed your concerns; we need to > make sure we have solid consensus before last calling > this one. >=20 > BTW, anyone noticed the mess in >=20 > http://xml.resource.org/public/rfc/bibxml3=20 >=20 > in particulre, the inconsistent file names... >=20 > thnx, >=20 > --dmm >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEvbZoORgD1qCZ2KcRAgLhAJ9fPInGoljmSM16tyRbPhVbMr3SHACgiSQ+ 3stub84gJOu+ICj9fu23C0I= =cUab -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- --===============1461433707== 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 --===============1461433707==-- From speermint-bounces@ietf.org Wed Jul 19 11:14:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Dkk-00023s-48; Wed, 19 Jul 2006 11:14:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Dkj-00023j-8G for speermint@ietf.org; Wed, 19 Jul 2006 11:14:21 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Dkh-0001hj-SH for speermint@ietf.org; Wed, 19 Jul 2006 11:14:21 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k6JFEJvj004922 for ; Wed, 19 Jul 2006 08:14:19 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k6JFEJmd004921 for speermint@ietf.org; Wed, 19 Jul 2006 08:14:19 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 19 Jul 2006 08:14:19 -0700 From: David Meyer To: speermint@ietf.org Message-ID: <20060719151419.GA2976@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Speermint] make that...draft-ietf-speermint-terminology-02.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: , Content-Type: multipart/mixed; boundary="===============1899181685==" Errors-To: speermint-bounces@ietf.org --===============1899181685== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-02.txt includes recent comments from Eli and Patrik. I'm going to hold off on sending this to internet-drafts until I get comments on this one. thnx, --dmm --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEvkxLORgD1qCZ2KcRAmbhAJ9ItGEOH+Kr7WKTf4tBXzsh6pmRggCdHdz2 4QuhSSOrqtoZWLugFTW2fuU= =B0Hi -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd-- --===============1899181685== 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 --===============1899181685==-- From speermint-bounces@ietf.org Wed Jul 19 17:08:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3JHe-0003vQ-3R; Wed, 19 Jul 2006 17:08:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3JHd-0003ul-LU; Wed, 19 Jul 2006 17:08:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3IQk-00007f-Mc; Wed, 19 Jul 2006 16:14:02 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3I3Y-0001ux-Fy; Wed, 19 Jul 2006 15:50:09 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6JJo29R016813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jul 2006 19:50:04 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G3I3W-0006Gr-0g; Wed, 19 Jul 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 19 Jul 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-01.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. Meyer, et al. Filename : draft-ietf-speermint-terminology-01.txt Pages : 12 Date : 2006-7-19 This document defines the terminology that is to be used by the Session PEERing for Multimedia INTerconnect Working Group (SPEERMINT). It has as its primary objective to focus the working group during its discussions, and when writing requirements, gap analysis and other solutions oriented documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-terminology-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-terminology-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-19145435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-terminology-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-terminology-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-19145435.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 Thu Jul 20 12:28:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bOP-0006xM-HK; Thu, 20 Jul 2006 12:28:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bOO-0006xH-Sa for speermint@ietf.org; Thu, 20 Jul 2006 12:28:52 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3bOM-0002FM-DP for speermint@ietf.org; Thu, 20 Jul 2006 12:28:52 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 3902E210082; Thu, 20 Jul 2006 18:28:49 +0200 (CEST) Message-ID: <44BFAF47.7080408@pernau.at> Date: Thu, 20 Jul 2006 18:28:55 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jean-Francois Mule Subject: Re: [Speermint] use of RFC 3263 for locating peer's SIP server References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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 btw: openser fully supports RFC3263: NAPTR+SRV (although failover to multiple announced SRV entries in yet not supported) regards klaus Jean-Francois Mule wrote: > Hi Rohan, > > Thank you for your input. > > You wrote: > [snip] >> Note >> that most of these proxies will be consulting ENUM records and will >> need to implement NAPTR anyway for ENUM. I don't think RFC3263 is too >> much to ask for. > > I did not think full support for 3263 was too much to ask for "on the > paper". But my question was geared towards best current practices, > existing implementations (3263 has been lacking for transport protocol > selection) and initial operators deployments (not showing up in > numbers). > > So far, zero positive response for full support from service providers > based on the question, one operator nack for 3263 NAPTR. > > Jean-Francois. > > > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan.mahy@gmail.com] >> Sent: Monday, June 19, 2006 3:05 PM >> To: Jean-Francois Mule >> Cc: speermint@ietf.org >> Subject: Re: [Speermint] use of RFC 3263 for locating peer's SIP >> server >> >> Hi Jean-Francois, >> >> To use full NAPTR and SRV lookups in a peering context, we are only >> really worried about a pair of SIP proxies (one for the initiating >> peer and another for the receiving peer) implementing NAPTR. Note >> that most of these proxies will be consulting ENUM records and will >> need to implement NAPTR anyway for ENUM. I don't think RFC3263 is too >> much to ask for. >> >> thanks, >> -rohan >> >> On 6/19/06, Jean-Francois Mule wrote: >>> Hi, >>> >>> We have discussed the use of the DNS procedures specified in >> RFC3263 >>> in speermint to resolve a SIP URI into a reachable host (IP address >> and >>> port), and transport protocol. >>> >>> To document the best current practices, could you contact me if >> you >>> have any implementation or operational experience in field use of >> 3263 >>> mechanisms (full 3263 or partial NAPTR/SRV)? >>> - based on Robert Sparks' presentation in IETF#65 SIPPING on >> the >>> status of the implementation in sip interoperability testing events: >>> 40% of implementers showing up in SIPit do NAPTR, >>> 50% do SRV. >>> >>> - when implemented on the products, how many folks use those >>> options? any feedback on the field use of 3263 for NAPTR lookup for >> SIP >>> transport protocol selection? >>> a) The RFC indicates that if the URI contains the transport > protocol, >>> then it should be used (no lookup): is this common? Should it be? >>> b) In a few publicly-available product administration guides I have >>> looked at, NAPTR lookup for transport selection can be turned on/off >>> when it exists as anyone would expect. Do service providers use it? >> If >>> no, what are the issues? >>> ==> I'm told that some service providers mandate one transport >> protocol >>> (say TCP) for SIP termination and therefore, the transport protocol >> to >>> reach a peering partner is often statically configured along with >> the >>> sip route. Is this common? >>> ===> some folks believe it is costly to do on a per query basis. Is >> this >>> a matter of recommending proper DNS caching and long enough TTL >> values >>> for those things? >>> >>> - what about SRV? Same questions. >>> >>> If I get enough feedback, my goal is to provide a brief summary on >> the >>> above to the list, and possibly, draft one or two slides outline any >>> issues at IETF#66. >>> >>> Thanks, >>> Jean-Francois. >>> >>> >>> >>> _______________________________________________ >>> 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 Thu Jul 20 16:18:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3eya-00080Y-7R; Thu, 20 Jul 2006 16:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ewW-0006Kq-DB for speermint@ietf.org; Thu, 20 Jul 2006 16:16:20 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3erw-0004H8-G3 for speermint@ietf.org; Thu, 20 Jul 2006 16:11:41 -0400 Received: from ([10.20.9.172]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.22558230; Thu, 20 Jul 2006 16:11:05 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 16:11:05 -0400 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] [wg-business] speermint Interim #1: Sept 18 - 19, Philadelphia (Plus TWO Requests) Date: Thu, 20 Jul 2006 16:11:04 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD1A6059@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business] speermint Interim #1: Sept 18 - 19, Philadelphia (Plus TWO Requests) Thread-Index: Acaqlm4bKkTqwW+2Q0eBZNsw4q8PPABoYjKA From: "Livingood, Jason" To: X-OriginalArrivalTime: 20 Jul 2006 20:11:05.0630 (UTC) FILETIME=[A19E73E0:01C6AC38] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 Okay, I have 18 attendees so far and a few people not yet confirmed. I suspect the # of attendees will come closer to 25 but I'm just guessing unless people do not RSVP. :-) Below is the current list of attendees. If you are not listed here and *do* plan to attend, please let me know ASAP. I would like to finalize the hotel & conference facility selection late Monday or early Tuesday of next week, so I can sign the facility agreement and send out the hotel info to folks.=20 (BTW, we will provide visa letters for those from overseas that need them.) Thanks Jason 1 Tom Creighton 2 Michael Haberler 3 Hadrien Kaplan 4 Sohel Khan 5 Guarav Khandpur 6 Yiu Lee 7 Alex Leung 8 Gene Lew 9 Jason Livingood 10 Daryl Malas 11 Dave Meyer 12 Andy Newton 13 Reinaldo Penno 14 Brian Rosen 15 David Schwartz 16 Richard Stastny 17 Hannes Tschofenig 18 Adam Uzelac =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Tuesday, July 18, 2006 2:17 PM > To: speermint@ietf.org > Subject: [Speermint] [wg-business] speermint Interim #1: Sept=20 > 18 - 19,Philadelphia (Plus TWO Requests) > Importance: High >=20 > Okay -- so our discussions regarding an interim meeting are=20 > progressing. > The tentative dates are Monday and Tuesday, September 18 and 19, 2006. > This is the week after VON in Boston. The interim meeting=20 > would tentatively be held in Philadelphia, which is not=20 > terribly far from Boston. =20 >=20 > Discounted hotel room rates, with complimentary Internet=20 > access, would be made available. Attendees would only incur=20 > costs of travel to the meeting, plus lunch and dinner each=20 > day; there would be no fee to attend the meeting itself. The=20 > conference room will have whiteboards / drawing boards, an=20 > LCD projector, and Internet access. >=20 > REQUEST #1: I have attached a proposed agenda and am=20 > requesting comments on this from the WG. =20 >=20 > That agenda also contains the following meeting objective: =20 > To have detailed debate and discussion of open issues for=20 > current WG drafts and move ahead work items more quickly than=20 > we can by having a 2 hour meeting every 4 months at the main=20 > IETF meetings. Also, kick-off new WG items in detail and=20 > make rapid progress towards achieving WG milestones. >=20 >=20 > REQUEST #2: I would also like to request a show of hands so=20 > we know how big a conference room to book. Please email me=20 > PRIVATELY at jason_livingood@cable.comcast.com if you would=20 > attend this meeting. >=20 > Thanks! > Jason >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 21 04:42:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3qZo-00055k-Kj; Fri, 21 Jul 2006 04:41:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3qZk-000544-4U for speermint@ietf.org; Fri, 21 Jul 2006 04:41:36 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3qQe-0002UB-Fr for speermint@ietf.org; Fri, 21 Jul 2006 04:32:14 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id B502D2100FA; Fri, 21 Jul 2006 10:32:11 +0200 (CEST) Message-ID: <44C0910B.1010107@pernau.at> Date: Fri, 21 Jul 2006 10:32:11 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Speermint] Just submitted draft-mahy-speermint-direct-peering-00 References: <953beacc0606190159h5e6c40b5u4b51251eaab3f7b@mail.gmail.com> In-Reply-To: <953beacc0606190159h5e6c40b5u4b51251eaab3f7b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Hi Rohan! Sorry for jumping in late - I had long holidays. I have a few concerns about the TLS stuff: > 4.1.6 Setup TLS connection > > Once a transport, port, and address are found, the initiating peer > will open or find a reusable TLS connection to the peer. The > initiating provider MUST verify the server certificate which SHOULD > be rooted in a well-known certificate authority. The initiating How should the validation be done? You describe how the client validation works, but not the server validation. > provider MUST be prepared to provide a TLS client certificate upon > request during the TLS handshake. The client certificate MUST > contain a DNS or URI choice type in the subjectAltName which > corresponds to the domain asserted in the host production of the From > header URI. The certificate SHOULD be valid and rooted in a well- This will break the SMTP-style forwarding. Simple scenario: sip:alice@aaa call bob@bbb which is a forward to bob@ccc Thus, when ccc's proxy receive the INVITE, the headers are From: sip:alice@aaa To: bob@bbb Thus, when ccc validates the certificate from bbb it won't match the domain in the from header. Further, how will the validation works for in-dialog requests, for which a new TLS connection is required? The request URI will not contain the domain of the next hop. Thus, should certificate validation for in-dialog requests be done against the topmost Route header? regards klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 21 08:03:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3tjQ-0005JL-LD; Fri, 21 Jul 2006 08:03:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3tjP-0005J8-TN for speermint@ietf.org; Fri, 21 Jul 2006 08:03:47 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3taW-0004vY-Am for speermint@ietf.org; Fri, 21 Jul 2006 07:54:36 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 36EC0210075 for ; Fri, 21 Jul 2006 13:54:35 +0200 (CEST) Message-ID: <44C0C07A.6050604@pernau.at> Date: Fri, 21 Jul 2006 13:54:34 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: speermint@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Subject: [Speermint] comments on Peering Architecture Draft 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 Sohel! Sorry for reviewing the draft that late, but I was on holidays. > 2. Network Context > > Figure 1 shows an example network context. Two or more providers on > either the public Internet or private Layer 3 networks may form a SIP > (Layer 5) federation. The public or private peering location server > function enables discovery of federations and all provider peering > points. Subsequent exchanges with those provider peering points will > enable discover of policy and additional signaling and media peering You use the term federation 2 times although it is described later. I would put the terminology first. I'm not happy with the term "peering location server". It sounds like a dedicated server for location lookup, maybe a dedicated protocol? I would use the term "peering location service" instead, as it is more general. E.g. when using ENUM we have DNS servers, and the "peering location service" consists of the ENUM client together with the name servers. Thus, also figure 1 would have to be updated. You further say that during exchanges with the PEERING POINTS the policy will discovered. That is not always the case. The policy can be discoverd in several ways, e.g. in DNS like in Otmar's draft, or with a dedicated protocol with dedicated policy servers (!=peering points) or through local configuration. > [...] > > o Service Provider to Service Provider across a private internet > > Note also that the nature of the Service Provider is intentionally > ambiguous, so it encompasses both VoIP SP and other Application SP. IMO we should talk about VOIP and Multimedia Service PRoviders. If the service provider may have also other services (layer 3, web services, email ...), those Application's are out of scope. Thus they should not be referenced and we should speak clearly about the VoIP&Multimedia parts of the service provider's services. > Next Hop: > > A next hop may be a direct peer or a transit peer. So, what is a peer? I would describe the next hop as the host, to which the SIP signaling will be sent. The host which has the IP address which was resolved with the procedures in RFC3263. > 3. Reference Peering Architecture [...] > A real-time application (Voice and Multimedia) IP Service provider > interconnects with other real-time application (Voice and Multimedia) > IP Service providers through a set of peering interface functions > which are discussed next. What about the enterprises? Maybe we should add a paragraph which describes that all the functionalities are identical for enterprises and service providers, thus using only the term "service provider" for simplicity. > 4. Peering Interface Functions [...] > > o Signaling Function (SF): Purpose is to enable the discovery of > endpoints and assist in discovery and exchange of parameters to be > used with the MF peering point. (Section 4.3) What do you mean by discovery of endpoints? RFC3263 (then I would agree) or discovering the URI which will be used as entry point into RFC3263? In either cases it should be more clearly. As we have stated we will use SIP for signaling, why not say clearly that the SF is the session signaling with SIP? > > o Media Function (MF): Purpose is to enable the interconnection of > media paths between endpoints. (Section 4.4) > > o QoS Function (QF): Purpose is to negotiate and reserve bandwidth > resources, as well as police and provide measurements for media > paths. (Section 4.5) > > o Application Function (AF): TBD (Section 4.5) Is there really an AF? If there is an application, IMO it is the service, which uses the previously defined planes, so its not a plane itself. > SIP security, privacy and encryption: The SF may support Security > functions to provide authentication, privacy (encryption) and message > integrity functions. These functions may be provided by using IPSec > or TLS. or S/MIME or DTLS or whatever will come - no restrictions. --> "These functions may be provided by using for example IPSec or TLS." > 5. Call Control and Media Control Deployment Options > > The peering functions can either be deployed along the following two > dimensions depending upon how the SF and the MF along with IP > functions are implemented: > > Composed or Decomposed: Addresses the question whether the media > paths must flow through the same physical and geographic nodes as the > call signaling, What about dedicated host for SIP and RTP (like provider A in figure 3) - its not a single physical device, but a single logical unit (IMO still composed). IMO Decomposed is where the SF has no interaction with the MF - e.g. RTP is directly between the SIP phones. > Centralized or Distributed: Addresses the question whether the > logical and physical peering points are in one geographical location > or distributed to multiple physical locations on the service provider > network. What is if a provider has several ingress points on the same geographical location? IMO this is still distributed. May it can be formulated: central: a single peering point visible to other peers(it may be a load balancer or anycast IP address which distributes the traffic to proxies (the proxies are invisible to the outside)) decentral: multiple peering points visible to the other peers (e.g. multiple SRV records, or multiple A records ...) > In a composed model, SF, and MF functions are implemented in one > entity. What is an entity - maybe we can say "...in a single logical border element...". In your figure, where > > > Provider A Provider B > ---------- . . ---------- > / \ . . / \ > | | . _ . | | > | +----+ . / \_ . +----+ | > | | SF |<-----/ \------| SF | | > | e.g. +-+--+ . /Transit\ . | | | > | MGCP-> | | . / IP \ . | | | > | +-+--+ . \ Provider| . | | | > | | MF |<~~~~\(Option)|~~~~| MF | | > | +----+ . \ / . +----+ | > | | . \__ _/ . | | > \_________ / . . \________ _/ > ---------- ---------- > > --- Signal (SIP) > ~~~ Bearer (RTP/IP) > ... Scope of peering > > Figure 3: Decomposed v. Composed Peering > > > > khan Expires December 17, 2006 [Page 9] > > Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006 > > > The advantage of composed peering architecture is that one-device > solves all peering issues. Disadvantage examples of this architecture > are single point failure, bottle neck, and complex scalability. > > In a decomposed model, SF and MF are implemented in separate > entities. Signaling functions are implemented in a proxy and media > functions are implemented in another device. The scaling of > signaling versus scaling of media may differ between applications. > Decomposing allows each to follow a separate migration path. As said above, I would not differ between a single or multiple physical devices, but a single or multiple logical devices. > This model allows the implementation of M:N model where one SF is > associated with multiple peering routers and one peering router is What is a "peering router" L5? L3? Do we need that device? > associated with multiple peering proxies. Generally, a vertical > protocol such as MGCP associates the relationship between a peering > proxy and a peering router. This architecture reduces the potential > of single point failure. This architecture, allows separation of the > policy decision point and the policy enforcement point. An example of > disadvantages is the scaling complexity because of the M:N > relationship and latency due to the vertical control messages between > entities. Maybe some of this concerns were already discussed on the list - but I still have 200 mails left to read and did not wanted to wait that long before writing down my comments. ;-) regards klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 21 09:44:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vIm-0005bX-3E; Fri, 21 Jul 2006 09:44:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vIl-0005b6-Cq for speermint@ietf.org; Fri, 21 Jul 2006 09:44:23 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3u4F-0008TP-Se for speermint@ietf.org; Fri, 21 Jul 2006 08:25:20 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 79C512100FD; Fri, 21 Jul 2006 14:25:18 +0200 (CEST) Message-ID: <44C0C7AE.9050309@pernau.at> Date: Fri, 21 Jul 2006 14:25:18 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt References: <13b401c69a32$44ae3e30$b801a8c0@cis.neustar.com> In-Reply-To: <13b401c69a32$44ae3e30$b801a8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: speermint@ietf.org, "'Livingood, Jason'" 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: > Consider an all-IMS, all-GSM federation. Do they have to have G.711? > > Consider an all-video conference federation. Do they have to have G.711? > > Consider an all-IM federation. Do they have to have G.711? IMO we should specify G711 as mandatory codec for voice peering. Thus, the all-IM and all-video federations are still standard conform. Regarding IMS: Is really everything in IMS/3GPP 100%IETF compatible? Any federation can overrule the standard. For example the federation "high secure" can have a policy: Peering according to SPEERMINT RFCxxxx+RFCxxx witht he exception that it requires signaling over TLS+IPSEC over private Layer2 network. The "low-bandwidth" federation specifies speermint RFCxxxx + G.729. Every service provider can choose to participate in this federation or not. Thus, if the IMS federation mandates SPEERMINT RFCxxxx with the exception of AMR instead of G.711 IMO this is fine. But if any of the IMS providers want to peer with the "low-bandwidth" federation it has to support G.711 and G.729 as well. I'm sure there will be also federation which do not use the SPEERMINT documents at all. regards klaus > > > Brian > > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Tuesday, June 27, 2006 4:30 PM > To: Drage, Keith (Keith); Livingood, Jason; Rohan Mahy; Michael Hammer > (mhammer) > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t > xt > > So is this kind of scenario in scope of speermint? > Take: > - on one side, a 3GPP IMS network with the typical UE that does > not support G.711 on the terminal, and, > - on the other, a VSP like free world dialup or alike that allow > any sip UA with any kind of codec. > > Do we want to have some minimal requirements to ensure that negotiation > just does not fail? I could care less where this transcoding function > is implemented. > > Jean-Francois > >> -----Original Message----- >> From: Drage, Keith (Keith) [mailto:drage@lucent.com] >> Sent: Tuesday, June 27, 2006 11:31 AM >> To: Livingood, Jason; Rohan Mahy; Michael Hammer (mhammer) >> Cc: speermint@ietf.org >> Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements- >> 00.t xt >> >> But this still does not answer my original question. >> >> How can you mandate a codec for what is essentially a network operator >> when that operator does not own the terminals (which contain the vast >> majority of the codecs). Are you making a requirement for transcoding >> support in the absence of whatever codec set is defined, or is it just >> an empty letter? >> >> regards >> >> Keith >> >>> -----Original Message----- >>> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] >>> Sent: 27 June 2006 16:24 >>> To: Rohan Mahy; Michael Hammer (mhammer) >>> Cc: speermint@ietf.org >>> Subject: RE: [Speermint] I-D >>> ACTION:draft-ietf-speermint-requirements-00.t xt >>> >>> >>> My initial thought is that you are accurate saying that >>> federations are >>> NOT REQUIRED for speermint. Federations MAY or MAY NOT be >>> used, as you >>> noted, and to that extent will be considered in some fashion here. >>> >>> As for codecs, I think we'll have to see based on further WG >>> discussion. >>> I would surely agree that codec negotiation / selection is *well* >>> handled in the underlying SIP protocol itself. However, we may well >>> find a need to specify (or not) a lowest common denominator codec >> but >>> we'll have to see how our requirements work progress. >>> >>> Jason >>> >>>> -----Original Message----- >>>> From: Rohan Mahy [mailto:rohan.mahy@gmail.com] >>>> Sent: Sunday, June 25, 2006 2:41 PM >>>> To: Michael Hammer (mhammer) >>>> Cc: speermint@ietf.org >>>> Subject: Re: [Speermint] I-D >>>> ACTION:draft-ietf-speermint-requirements-00.t xt >>>> >>>> Mike, >>>> >>>> There is no requirement for a federation to exist in >>>> speermint. It might or it might not, but the IETF won't be >>>> very effective trying to put requirements on something which >>>> is effectively a business arrangement. We can define a set >>>> of protocols however, which needs to be useful in the big-I >>>> Internet and hopefully for folks building federations and >>>> other clubs as well. >>>> >>>> Everyone, >>>> >>>> I think codec selection should be out of scope. Mandating >>>> G.711 will have no positive effect now. Everyone supports it >>>> today in some way or another, but it could be detrimental in >>>> the future. The point of the SDP negotiation is to allow RTP >>>> *endpoints* to select the best codec in common under the >>>> circumstances. I don't think we can do any better than that >>>> in a requirements document, especially since we are >>>> describing an interface between SIP intermediaries that I >>>> hope will not even be a participant in the RTP media most >>> of the time. >>>> thanks, >>>> -rohan >>>> >>>> >>>> >>>> On 6/23/06, Michael Hammer (mhammer) wrote: >>>>> Shouldn't the requirement be that the policy of a >>> federation should >>>>> address the default codecs used by a federation to interconnect? >>>>> >>>>> Mike >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Drage, Keith (Keith) [mailto:drage@lucent.com] >>>>>> Sent: Friday, June 23, 2006 10:22 AM >>>>>> To: speermint@ietf.org >>>>>> Subject: RE: [Speermint] I-D >>>>>> ACTION:draft-ietf-speermint-requirements-00.t xt >>>>>> >>>>>> Section 3.5 indicates: >>>>>> >>>>>> The minimum requirements to allow a successful VoIP >>>> interconnection >>>>>> include: >>>>>> >>>>>> o the mandatory support of RTP *and* RTCP as defined in >>>>>> [RFC3550], >>>>>> >>>>>> o the support of compatible codecs between >>>> communication peers, >>>>>> the >>>>>> G.711 MUST be supported, the IETF iLBC [RFC3951] >>>> codec and its >>>>>> RTP >>>>>> payload format [RFC3952] SHOULD be supported. >>>>>> >>>>>> o the support of the VoIP metric block as defined in >>>> RTP Control >>>>>> Protocol Extended Reports [RFC3611] MAY be supported. >>>>>> >>>>>> What exactly does this mean to the two bodies that are >>> making the >>>>>> peering arrangement. Is this a requirement to control >>> the codecs >>>>>> used by the UAs attached to the peering organisations >> equipment >>>>>> before peering can occur, or a requirement to support >>>> transcoding if >>>>>> these requirements are not met by the population of >>> attached UAs. >>>>>> Additional nit comment. RFC 2327 is obsolete and sdp-new is >>>>>> imminently about to be published and I assume we are going to >>>>>> reference that document (it will be RFC 4566). >>>>>> >>>>>> regards >>>>>> >>>>>> Keith >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Internet-Drafts@ietf.org >>> [mailto:Internet-Drafts@ietf.org] >>>>>>> Sent: 21 June 2006 23:50 >>>>>>> To: i-d-announce@ietf.org >>>>>>> Cc: speermint@ietf.org >>>>>>> Subject: [Speermint] I-D >>>>>>> ACTION:draft-ietf-speermint-requirements-00.txt >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 Requirements for SIP-based >>>>>>> VoIP Interconnection >>>>>>> Author(s) : J. Mule >>>>>>> Filename : draft-ietf-speermint-requirements- >> 00.txt >>>>>>> Pages : 10 >>>>>>> Date : 2006-6-21 >>>>>>> >>>>>>> This document describes general requirements for Session >>>>>>> PEERing for >>>>>>> Multimedia INTerconnect and defines the minimum set of >>>>>> requirements >>>>>>> applicable to SIP session peering for VoIP interconnects. >>>>>>> >>>>>>> In its current form, the document is a first draft >>>> based on the >>>>>>> SPEERMINT mailing list's discussions on >>>> requirements. The main >>>>>>> objectives are to generate consensus on what categories >> of >>>>>>> requirements should be covered, and to start more >>>> discussions >>>>>>> on the >>>>>>> technical protocol requirements that apply to VoIP >>>> interconnects. >>>>>>> >>>>>>> A URL for this Internet-Draft is: >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-speermint- >> requi >>>>>> rements-00.txt >>>>>> >>>>>> To remove yourself from the I-D Announcement list, send a >>>> message to >>>>>> i-d-announce-request@ietf.org with the word unsubscribe >>>> in the body >>>>>> of the message. >>>>>> You can also visit >>>>>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>>>>> to change your subscription settings. >>>>>> >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP. >>>> Login with the >>>>>> username "anonymous" and a password of your e-mail >>> address. After >>>>>> logging in, type "cd internet-drafts" and then >>>>>> "get draft-ietf-speermint-requirements-00.txt". >>>>>> >>>>>> A list of Internet-Drafts directories can be found in >>>>>> http://www.ietf.org/shadow.html or >>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>>> >>>>>> Internet-Drafts can also be obtained by e-mail. >>>>>> >>>>>> Send a message to: >>>>>> mailserv@ietf.org. >>>>>> In the body type: >>>>>> "FILE >>>>>> /internet-drafts/draft-ietf-speermint-requirements-00.txt". >>>>>> >>>>>> NOTE: The mail server at ietf.org can return the document in >>>>>> MIME-encoded form by using the "mpack" utility. >>> To use this >>>>>> feature, insert the command "ENCODING mime" before >>>> the "FILE" >>>>>> command. To decode the response(s), you will need >>>> "munpack" or >>>>>> a MIME-compliant mail reader. Different >>>> MIME-compliant mail >>>>>> readers >>>>>> exhibit different behavior, especially when dealing with >>>>>> "multipart" MIME messages (i.e. documents which >>>> have been split >>>>>> up into multiple messages), so check your local >>>> documentation on >>>>>> how to manipulate these messages. >>>>>> >>>>>> >>>>>> Below is the data which will enable a MIME compliant >>> mail reader >>>>>> implementation to automatically retrieve the ASCII >>> version of the >>>>>> Internet-Draft. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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 Jul 21 09:45:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vJl-00065e-19; Fri, 21 Jul 2006 09:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vJk-0005zB-MO for speermint@ietf.org; Fri, 21 Jul 2006 09:45:24 -0400 Received: from exprod6og51.obsmtp.com ([64.18.1.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3v6W-0005Qi-6Z for speermint@ietf.org; Fri, 21 Jul 2006 09:31:46 -0400 Received: from source ([192.150.20.142]) by exprod6ob51.postini.com ([64.18.5.12]) with SMTP; Fri, 21 Jul 2006 06:31:41 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k6LDVquv026970; Fri, 21 Jul 2006 06:31:52 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k6LDVSR4000307; Fri, 21 Jul 2006 06:31:38 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 06:31:31 -0700 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: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted)) Date: Fri, 21 Jul 2006 06:31:25 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D2206C442@namail5.corp.adobe.com> In-Reply-To: <44C0CC9F.70705@pernau.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted)) Thread-Index: Acasw7OLGrLf9vhOQfmXEmLO3Zfd8AAAqW4g From: "Henry Sinnreich" To: "Klaus Darilion" , X-OriginalArrivalTime: 21 Jul 2006 13:31:31.0522 (UTC) FILETIME=[FA59A220:01C6ACC9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 I agree with Klaus and would like to add that the IETF success recipe MUST (!) be maintained: Have running code and deployment experience first before promoting anything to RFC status, even to informational RFC status. Only deployment is the link between a standards proposal and its confirmation in the market, since we cannot capture or even articulate the business models that drive a specific proposal. One wonders how many RFCs listed at http://rfc3261.net/ are based on running code, more than one implementation and experience from deployment.=20 Thanks, Henry -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 Sent: Friday, July 21, 2006 7:46 AM To: speermint@ietf.org Subject: RE: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted)) Hi! Lots of people in this group discuss the pro and cons of TLS. I wonder:=20 who of you has already used SIP and TLS. Who has configured it's SIP=20 proxy or client with certificates? I have doubts that there were SIP+TLS implementations when RFC3261 was=20 written - the whole TLS part in 3261 is incomplete and raises more=20 questions than it solves. There are several call scenarios (e.g. a=20 simple forward) in which certificate validation will fail. Don't get me wrong - I'm a TLS fan! Thus I know there might be several=20 problems with TLS which we should think about before defining TLS as MUST. I would really like that people use TLS for their SIP phones and proxies BEFORE defining if TLS is MUST or SHOULD. regards Klaus _______________________________________________ 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 Jul 21 10:19:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vrB-0006Wo-Ow; Fri, 21 Jul 2006 10:19:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vrA-0006UJ-BU for speermint@ietf.org; Fri, 21 Jul 2006 10:19:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3unh-0008AA-N7 for speermint@ietf.org; Fri, 21 Jul 2006 09:12:17 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3uYA-0006gY-5j for speermint@ietf.org; Fri, 21 Jul 2006 08:56:16 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 79D4F210075; Fri, 21 Jul 2006 14:56:08 +0200 (CEST) Message-ID: <44C0CEE7.1030201@pernau.at> Date: Fri, 21 Jul 2006 14:56:07 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) References: <00ae01c69ae3$70cc78e0$4d201f0a@cis.neustar.com> <732EB664-954E-410E-A7BD-9F53D350F119@hxr.us> <953beacc0606291705j603aa36fwb08b9f0687fb7150@mail.gmail.com> In-Reply-To: <953beacc0606291705j603aa36fwb08b9f0687fb7150@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "Khan, Sohel Q \[CTO\]" , 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 Hi Rohan! Do you have quantitative data about SIP proxies which use TLS? Call setup delay due to TLS handshake? call throughput decrease due to TLS encoding/decoding compared to UDP/TCP? regards klaus Rohan Mahy wrote: > Andy, > > What you've described are a bunch of hacks that service providers use > because they don't peer over the Internet or because they can't rely > on the other guy to support TLS. The combination of hacks is much, > much more expensive in terms of both capital equipment and > operationally than just using TLS. > > A $2000 rack mount server can encrypt and decrypt a phenominal volume > of TLS traffic. Hardware crypto accellerators are available that > increase this volume and decrease initial TLS handshake latencies by > another couple of orders of magnitude. > > I'm willing to bet a few beers that the amount of data that is > encrypted using TLS exceeds the total volume of PSTN signaling traffic > on a daily basis. > > To those who have a problem with TLS, I ask them to provide some > quantitative data or real requirements rather than rhetoric and FUD. > > thanks, > -rohan > > > > > > On 6/28/06, Andrew Newton wrote: >> >> On Jun 28, 2006, at 2:48 PM, Richard Shockey wrote: >> > how do you propose to establish a trust relationship between SIP >> > domain >> > boundaries without TLS? >> >> There are other methods: security lower in the stack, private >> connections, address ACLs... the things that providers use today. >> >> > If you cannot establish a trust relationship between interconnecting >> > partners then what is the purpose of this whole exercise? >> >> To answer the second part of that sentence: I don't know; I've been >> asking that question for quite some time. >> >> -andy >> >> _______________________________________________ >> 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 Fri Jul 21 10:20:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vrI-0006dX-3e; Fri, 21 Jul 2006 10:20:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vrG-0006cL-W7 for speermint@ietf.org; Fri, 21 Jul 2006 10:20:03 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3vYU-0003LA-G2 for speermint@ietf.org; Fri, 21 Jul 2006 10:00:39 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k6LE0VrY028786; Fri, 21 Jul 2006 07:00:31 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k6LE0VEQ028785; Fri, 21 Jul 2006 07:00:31 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 21 Jul 2006 07:00:31 -0700 From: David Meyer To: Henry Sinnreich Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted)) Message-ID: <20060721140031.GA28756@1-4-5.net> References: <44C0CC9F.70705@pernau.at> <24CCCC428EFEA2469BF046DB3C7A8D2206C442@namail5.corp.adobe.com> Mime-Version: 1.0 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D2206C442@namail5.corp.adobe.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Content-Type: multipart/mixed; boundary="===============0992673491==" Errors-To: speermint-bounces@ietf.org --===============0992673491== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jul 21, 2006 at 06:31:25AM -0700, Henry Sinnreich wrote: > I agree with Klaus and would like to add that the IETF success recipe > MUST (!) be maintained: Have running code and deployment experience > first before promoting anything to RFC status, even to informational RFC > status. Did you notice that routing area isn't going to be requiring interoperable implementations (read: running code) for DS status anymore (or so I understand)? --dmm --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEwN3/ORgD1qCZ2KcRAseqAJ9OOTf+kPDMFK/yFBEILqep4HpChgCglIGU qvHTXF5bne0MQgrugZPBAHo= =31PH -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- --===============0992673491== 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 --===============0992673491==-- From speermint-bounces@ietf.org Fri Jul 21 14:01:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3zJM-00010U-ED; Fri, 21 Jul 2006 14:01:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3zJL-0000vJ-9i for speermint@ietf.org; Fri, 21 Jul 2006 14:01:15 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3zJJ-0006Wn-UX for speermint@ietf.org; Fri, 21 Jul 2006 14:01:15 -0400 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.03) id A66A02FC; Fri, 21 Jul 2006 14:01:14 -0400 From: "Hadriel Kaplan" To: "'Brian Rosen'" , Subject: RE: TLS for peering (was RE:Comments (RE:[speermint]requirementsdraftsubmitted)) Date: Fri, 21 Jul 2006 14:01:07 -0400 Message-ID: <050901c6acef$a480e630$6601a8c0@acmepacket.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.2869 Thread-Index: Acasw7FPWFCwkTpDQvCI918gkVyWHwAGtvcAAAPR14A= In-Reply-To: <055501c6acdf$e73284d0$640fa8c0@cis.neustar.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 The part of that which confuses me is what does a MUST IMPLEMENT but not must deploy mean in a BCP from Speermint? Typically IETF RFCs are written from the perspective of manufacturers of equipment. (ok, that's a gross generalization, but you know what I mean) So for them a MUST IMPLEMENT means something which must be supported, but can be disabled through configuration or some such. But IMO, Speermint BCPs are really written for the operators - so what does MUST IMPLEMENT but not must deploy mean for them? Isn't it meaningless? -hadriel > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, July 21, 2006 12:08 PM > To: 'Klaus Darilion'; speermint@ietf.org > Subject: RE: TLS for peering (was RE:Comments > (RE:[speermint]requirementsdraftsubmitted)) > > Having lived with protocols that offered options like IPsec and VPNs and > other mechanisms, I think that despite the fact that you can, in theory, > create a satisfactory security arrangement, it is exceedingly hard to make > it actually work except for cases where there is an entity that completely > controls all aspects of the peering. That just isn't the case for what I > think we are trying to specify here (such cases don't need IETF > standardization). Thus, I personally think mandating TLS is a good thing, > achievable, and reasonable. That's a MUST IMPLEMENT, not a must deploy; > it's really hard to control actual deployments, and I don't think we try > hard to do so. > > Brian > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 21 15:08:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G40M9-0005pB-B8; Fri, 21 Jul 2006 15:08:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G40M3-0005d7-NB for speermint@ietf.org; Fri, 21 Jul 2006 15:08:07 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G40HC-0004mH-5f for speermint@ietf.org; Fri, 21 Jul 2006 15:03:11 -0400 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] Terminology draft - Peering Date: Fri, 21 Jul 2006 15:02:28 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD0DD6@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology draft - Peering Thread-Index: Acap+ST5mGbbIw9bQFG9j4ptCr8NEAC/jv1w From: "Livingood, Jason" To: "Daryl Malas" , "Michael Hammer \(mhammer\)" X-OriginalArrivalTime: 21 Jul 2006 19:02:29.0340 (UTC) FILETIME=[368831C0:01C6ACF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: speermint@ietf.org, Stastny Richard , "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 All of this makes sense to me for now... Jason=20 > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net]=20 > Sent: Monday, July 17, 2006 7:31 PM > To: Michael Hammer (mhammer) > Cc: Livingood, Jason; Uzelac, Adam; gaurav@sunrocket.com;=20 > Stastny Richard; speermint@ietf.org > Subject: RE: [Speermint] Terminology draft - Peering >=20 > Mike, I agree, the following three options will occur. We=20 > MUST allow for all of these methods (a,b, and c). --Daryl >=20 > On Mon, 2006-07-17 at 11:56 -0400, Michael Hammer (mhammer) wrote: > > Jason, > >=20 > > Could we say it as follows: > >=20 > > Signaling will determine: > > a) whether the media must follow the same path as signaling, > > b) whether it must follow a different path than signaling, or > > c) whether may follow a direct path not controlled by signaling. > >=20 > > In the above, a) may point to a composed SBC, b) may point to the=20 > > media part of a decomposed SBC, and c) may let IP routing=20 > mechanisms=20 > > direct the media across any edge router toward the destination. > >=20 > > Make sense? > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Sent: Monday, July 17, 2006 11:47 AM > > > To: Uzelac, Adam; gaurav@sunrocket.com; Stastny Richard > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Terminology draft - Peering > > >=20 > > > > On a bit of a side-note, currently it is unclear the extent > > > to which > > > > bearer/media should be addressed within the SPEERMINT > > > scope. I plan > > > > on supplying Jean-Francois feedback on that section=20 > [3.3] of the=20 > > > > requirements draft - and I encourage others to do the same to=20 > > > > fully vet out the requirements. > > >=20 > > > Please do comment. We should explictly address the=20 > questions around=20 > > > media and signaling paths/flows, and this is a subject=20 > that comes up=20 > > > often here. We should strive to resolve this question soon. > > >=20 > > > It seems like we have a few options: > > >=20 > > > A - Signaling and Media MUST follow the same path. > > >=20 > > > B - Signaling and Media MAY or MAY NOT follow the same path. =20 > > > (I am sure there's some nuance in here.) > > >=20 > > > C - Signaling and Media SHOULD NOT follow the same path. > > >=20 > > > Option B seems like it may be the optimal compromise that=20 > allows for=20 > > > maximum flexibility. Any other options possible? > > >=20 > > >=20 > > > Jason > > >=20 > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 21 15:25:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G40cv-0002F9-NG; Fri, 21 Jul 2006 15:25:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G40cu-0002Bv-4G for speermint@ietf.org; Fri, 21 Jul 2006 15:25:32 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G40ON-0006a2-F2 for speermint@ietf.org; Fri, 21 Jul 2006 15:10:32 -0400 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: TLS for peering (wasRE:Comments (RE:[speermint]requirementsdraftsubmitted)) Date: Fri, 21 Jul 2006 15:10:06 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD1A6080@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (wasRE:Comments (RE:[speermint]requirementsdraftsubmitted)) Thread-Index: Acasw7FPWFCwkTpDQvCI918gkVyWHwAGtvcAAAPR14AAAqfNsA== From: "Livingood, Jason" To: "Hadriel Kaplan" , "Brian Rosen" , X-OriginalArrivalTime: 21 Jul 2006 19:10:06.0947 (UTC) FILETIME=[47497B30:01C6ACF9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 No, I think it means it is optional and may be useful in some applications and not in others. On one "side" of my network I may peer in a particular way with another cable co. and NOT activate some option. While on the other side of the network I connect to some federation and WILL activate the option. It was mandatory to implement so it's in the s/w or h/w I use in my network, and depending upon the use cases I can choose to activate it or not. Jason=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Friday, July 21, 2006 2:01 PM > To: 'Brian Rosen'; speermint@ietf.org > Subject: RE: TLS for peering (wasRE:Comments=20 > (RE:[speermint]requirementsdraftsubmitted)) >=20 > The part of that which confuses me is what does a MUST=20 > IMPLEMENT but not must deploy mean in a BCP from Speermint? =20 > Typically IETF RFCs are written from the perspective of=20 > manufacturers of equipment. (ok, that's a gross=20 > generalization, but you know what I mean) So for them a MUST=20 > IMPLEMENT means something which must be supported, but can be=20 > disabled through configuration or some such. =20 >=20 > But IMO, Speermint BCPs are really written for the operators=20 > - so what does MUST IMPLEMENT but not must deploy mean for=20 > them? Isn't it meaningless? >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, July 21, 2006 12:08 PM > > To: 'Klaus Darilion'; speermint@ietf.org > > Subject: RE: TLS for peering (was RE:Comments > > (RE:[speermint]requirementsdraftsubmitted)) > >=20 > > Having lived with protocols that offered options like IPsec=20 > and VPNs=20 > > and other mechanisms, I think that despite the fact that=20 > you can, in=20 > > theory, create a satisfactory security arrangement, it is=20 > exceedingly=20 > > hard to make it actually work except for cases where there is an=20 > > entity that completely controls all aspects of the peering.=20 > That just=20 > > isn't the case for what I think we are trying to specify here (such=20 > > cases don't need IETF standardization). Thus, I personally think=20 > > mandating TLS is a good thing, achievable, and reasonable. =20 > That's a=20 > > MUST IMPLEMENT, not a must deploy; it's really hard to=20 > control actual=20 > > deployments, and I don't think we try hard to do so. > >=20 > > Brian > >=20 >=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 Sun Jul 23 19:48:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4ngk-0002QB-CJ; Sun, 23 Jul 2006 19:48:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4ngj-0002NT-L6 for speermint@ietf.org; Sun, 23 Jul 2006 19:48:45 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4ngj-0007rE-5k for speermint@ietf.org; Sun, 23 Jul 2006 19:48:45 -0400 Received: from pb94.dyndns.org (localhost [127.0.0.1]) by pb94.dyndns.org (Postfix) with ESMTP id DFD0021001C; Mon, 24 Jul 2006 01:48:43 +0200 (CEST) Received: from 212.17.67.197 (SquirrelMail authenticated user klaus.mailinglists@pernau.at) by pb94.dyndns.org with HTTP; Mon, 24 Jul 2006 01:48:43 +0200 (CEST) Message-ID: <63843.212.17.67.197.1153698523.squirrel@pb94.dyndns.org> In-Reply-To: <055501c6acdf$e73284d0$640fa8c0@cis.neustar.com> References: <44C0CC9F.70705@pernau.at> <055501c6acdf$e73284d0$640fa8c0@cis.neustar.com> Date: Mon, 24 Jul 2006 01:48:43 +0200 (CEST) Subject: RE: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted)) From: "Klaus Darilion" To: "Brian Rosen" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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 Hi Brian! On Fri, July 21, 2006 18:08, Brian Rosen said: > I believe it is the case that the link from one peer to another, which = is > generally between two proxies, can very reasonably be protected with TL= S, > with many current implementations, and with reasonable assumptions abou= t > PKI. Specifically, if one of the parts of a federation was an agreemen= t > on > a CA, then each peer can have a certificate that other peers can verify= . > I > believe all operations, including forwarding, if they work at all acros= s > the > peering system would work if it was TLS protected. Using TLS for encryption and TLS certificate validation works - but the L= 5 validation (validate the certificate domain names against the domains in the SIP headers) does not work without mandating a B2BUA. TLS/SSL was invented for a very simple client-server system - HTTP. Let's compare HTTP with SIP: HTTP: 1 request - 1 (or more) responses. L5 validation: verify domain in browser's location bar against the domain in the server certificate - this is straight forward SIP: Multiple - bidirectional requests L5 validation: There are several headers which are used for routing and thus can be used for validation: requestURI, From, To, Via, Route, Contact. We can have in-dialog requests which are initiated in reverse direction o= f the original dialog setup. And each of this domain resolves to several domains (due to NAPTR, SRV, A resolution). This alone should have people think a little more before defining TLS for SIP. I am a fan of forwarding - and probably every transit service provider too. As transit will happen I will use the transit scenario (simple forwarding without a B2BUA) to show that L5 validation is broken - and I would be very very happy if someone can show that I'm wrong. A want to call B. There is no direct peering agreement. Thus A sends the call to it's transit provider T. (only the signaling between the proxies is shown) A->T INVITE sip:B@B From: sip:A@A To: sip:B@B Contact: user@phone Record-Route: sip:A Cert validation according to RFC3261 section 26.3.2.2: T will show a TLS certificate for T (not for B) - thus, when A validates T's certificate, the validation will fail. IMO this can be fixed by addin= g a Route: header with sip:T, but this is nowhere mentioned in RFC 3261. T->B INVITE sip:B@B From: sip:A@A To: sip:B@B Contact: user@phone Record-Route: sip:T Record-Route: sip:A Cert validation according to RFC3261 section 26.3.2.2: B should validate the domain in the From header (A) aginst the domain in the client's certificate (T) --> it will fail. Now let's assume the previous validation have succeeded and B sends a BYE request to A, and the TLS connection was dropped and must be re-established: B->T BYE name@1.2.3.4 From: sip:B@B To: sip:A@A Route: sip:T Route: sip:A How should T's certificate be validated? Probably against the domain in the topmost Route header - but again: This is nowhere specified. T->A BYE name@1.2.3.4 From: sip:B@B To: sip:A@A Route: sip:A Again, probably T should use the domain in the Route header for certificate validation. But A can't validate the certificate's domain (T) against the From header (B) - it will fail. Similar problem arise in a forwarding scenario - A-->B which forwards it'= s call to C. The suggested L5 validation will fail (except B uses a B2BUA, and IMO a B2BUA should not be mandatory). > This does not assume sips works (whatever that means), and does not ass= ume > endpoints implement TLS, or either the originating or terminating domai= ns > deploy TLS anywhere else. > > It does provide a reasonable degree of protection across the peering > point, > which I think is a good thing. Yes, TLS provides protection, but we should not specify a broken L5 certificate validation. > Having lived with protocols that offered options like IPsec and VPNs an= d > other mechanisms, I think that despite the fact that you can, in theory= , > create a satisfactory security arrangement, it is exceedingly hard to m= ake > it actually work except for cases where there is an entity that complet= ely > controls all aspects of the peering. That just isn't the case for what= I > think we are trying to specify here (such cases don't need IETF > standardization). Thus, I personally think mandating TLS is a good thi= ng, > achievable, and reasonable. That's a MUST IMPLEMENT, not a must deploy= ; Yes, I agree. I want TLS in the specs too - but we have to specify the validation more precisely and it has to work in other scenarios than a basic call too. Otherwise people wont use it. regards Klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Jul 23 19:56:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4nnj-0005fU-Ew; Sun, 23 Jul 2006 19:55:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4nni-0005fO-67 for speermint@ietf.org; Sun, 23 Jul 2006 19:55:58 -0400 Received: from [204.209.140.176] (helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4nnf-0003Ce-QF for speermint@ietf.org; Sun, 23 Jul 2006 19:55:58 -0400 Received: from [192.168.1.103] (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified)) by wodka.aus-biz.com (Postfix) with ESMTP id 8D5A6483D for ; Sun, 23 Jul 2006 19:55:19 -0400 (EDT) Message-ID: <44C40C85.9040705@e164.org> Date: Sun, 23 Jul 2006 19:55:49 -0400 From: Duane User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: speermint@ietf.org Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted)) References: <44C0CC9F.70705@pernau.at> <055501c6acdf$e73284d0$640fa8c0@cis.neustar.com> <63843.212.17.67.197.1153698523.squirrel@pb94.dyndns.org> In-Reply-To: <63843.212.17.67.197.1153698523.squirrel@pb94.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Klaus Darilion wrote: > TLS/SSL was invented for a very simple client-server system - HTTP. Let's > compare HTTP with SIP: I fail to see the difference, HTTPS requests can go via intermediate servers as well (aka proxy servers like squid for example)... -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 24 01:51:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4tLG-0004sS-CH; Mon, 24 Jul 2006 01:50:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4tLF-0004sN-DK for speermint@ietf.org; Mon, 24 Jul 2006 01:50:57 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4tLD-0003iC-44 for speermint@ietf.org; Mon, 24 Jul 2006 01:50:57 -0400 Received: from pb94.dyndns.org (localhost [127.0.0.1]) by pb94.dyndns.org (Postfix) with ESMTP id 5ACBF2100CF; Mon, 24 Jul 2006 07:50:54 +0200 (CEST) Received: from 212.17.67.197 (SquirrelMail authenticated user klaus.mailinglists@pernau.at) by pb94.dyndns.org with HTTP; Mon, 24 Jul 2006 07:50:54 +0200 (CEST) Message-ID: <64523.212.17.67.197.1153720254.squirrel@pb94.dyndns.org> In-Reply-To: <44C40C85.9040705@e164.org> References: <44C0CC9F.70705@pernau.at> <055501c6acdf$e73284d0$640fa8c0@cis.neustar.com> <63843.212.17.67.197.1153698523.squirrel@pb94.dyndns.org> <44C40C85.9040705@e164.org> Date: Mon, 24 Jul 2006 07:50:54 +0200 (CEST) Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted)) From: "Klaus Darilion" To: "Duane" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Mon, July 24, 2006 1:55, Duane said: > Klaus Darilion wrote: > >> TLS/SSL was invented for a very simple client-server system - HTTP. >> Let's >> compare HTTP with SIP: > > I fail to see the difference, HTTPS requests can go via intermediate > servers as well (aka proxy servers like squid for example)... Hi! You do not see the difference? - Have you ever seen a web server connecting to your web browser? - HTTP is stateless - there are no in-dialog requests (that's why we have HTTP cookies). - Regarding TLS: When using HTTPS, the TLS tunnel is end2end, the proxy can't see the payload. SIP uses TLS on a hop-by-hop basis. Do you need more differences? regards Klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 24 02:52:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4uIu-0007e5-HL; Mon, 24 Jul 2006 02:52:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4uIt-0007do-7E for speermint@ietf.org; Mon, 24 Jul 2006 02:52:35 -0400 Received: from [204.209.140.176] (helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4uIr-0007Qj-Uk for speermint@ietf.org; Mon, 24 Jul 2006 02:52:35 -0400 Received: from [192.168.1.103] (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified)) by wodka.aus-biz.com (Postfix) with ESMTP id 0EE9A48ED; Mon, 24 Jul 2006 02:51:56 -0400 (EDT) Message-ID: <44C46E2D.1080305@e164.org> Date: Mon, 24 Jul 2006 02:52:29 -0400 From: Duane User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: Klaus Darilion Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted)) References: <44C0CC9F.70705@pernau.at> <055501c6acdf$e73284d0$640fa8c0@cis.neustar.com> <63843.212.17.67.197.1153698523.squirrel@pb94.dyndns.org> <44C40C85.9040705@e164.org> <64523.212.17.67.197.1153720254.squirrel@pb94.dyndns.org> In-Reply-To: <64523.212.17.67.197.1153720254.squirrel@pb94.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Klaus Darilion wrote: > Do you need more differences? RTP can be pass through (ie untouched like https and proxy) or can bypass proxies and be point to point as well... -- Best regards, Duane _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 24 04:10:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4vW6-0001An-Ao; Mon, 24 Jul 2006 04:10:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4vW5-0001Ai-QR for speermint@ietf.org; Mon, 24 Jul 2006 04:10:17 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4vW4-00006C-Hd for speermint@ietf.org; Mon, 24 Jul 2006 04:10:17 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id A3B962100DC; Mon, 24 Jul 2006 10:10:13 +0200 (CEST) Message-ID: <44C48068.7000903@pernau.at> Date: Mon, 24 Jul 2006 10:10:16 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Duane Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted)) References: <44C0CC9F.70705@pernau.at> <055501c6acdf$e73284d0$640fa8c0@cis.neustar.com> <63843.212.17.67.197.1153698523.squirrel@pb94.dyndns.org> <44C40C85.9040705@e164.org> <64523.212.17.67.197.1153720254.squirrel@pb94.dyndns.org> <44C46E2D.1080305@e164.org> In-Reply-To: <44C46E2D.1080305@e164.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Duane wrote: > Klaus Darilion wrote: > >> Do you need more differences? > > RTP can be pass through (ie untouched like https and proxy) or can > bypass proxies and be point to point as well... I thought we were taking about SIP. RTP has nothing to do with the L5 certificate validation in SIP. Regarding RTP: I can be direct or via an RTP proxy. If you use SRTP it can also be direct or via an RTP proxy, and depending on the method used to deliver the SRTP key, the RTP proxy might be able to look into the payload (e.g. if the key is in plaintext in the SDP). But again - RTP/SRTP has nothing in common with the TLS problems in SIP. regards klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 24 06:14:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4xRl-0004dL-Kd; Mon, 24 Jul 2006 06:13:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4xRi-0004dC-OM for speermint@ietf.org; Mon, 24 Jul 2006 06:13:54 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4xRh-0007PD-43 for speermint@ietf.org; Mon, 24 Jul 2006 06:13:54 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k6OADpAx025180; Mon, 24 Jul 2006 05:13:51 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 Jul 2006 05:13:50 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 Jul 2006 12:13:48 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Mon, 24 Jul 2006 12:13:45 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918013B011@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Thread-Index: AcaswMIBXGoKxNnzRXee5gSEEec6VQCSEfng From: "Drage, Keith \(Keith\)" To: "Klaus Darilion" X-OriginalArrivalTime: 24 Jul 2006 10:13:48.0558 (UTC) FILETIME=[DAB63AE0:01C6AF09] X-Spam-Score: 0.0 (/) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 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 The issue here is not whether IMS wants to do their own thing.=20 The issue is that putting G.711 over any radio interface in a cellular environment borders on commercial insanity for either the customer, the operator, or both.=20 Therefore you should not be specifying G.711 as the default unless you are also going to specify that transcoding (in the intervening sustem) must take place to G.711 when the terminal does not support or use such a codec, AND that some form of transcoder free operation should also be supported across the peering interface. (Side note: I suspect if one started totally figures for the number of end systems that support G.711, and those that support AMR, you might well be surprised at the result). Regards Keith > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 > Sent: 21 July 2006 13:25 > To: Brian Rosen > Cc: 'Jean-Francois Mule'; Drage, Keith (Keith); 'Livingood,=20 > Jason'; 'Rohan Mahy'; 'Michael Hammer (mhammer)'; speermint@ietf.org > Subject: Re: [Speermint] I-D=20 > ACTION:draft-ietf-speermint-requirements-00.t xt >=20 > Brian Rosen wrote: > > Consider an all-IMS, all-GSM federation. Do they have to=20 > have G.711? > >=20 > > Consider an all-video conference federation. Do they have=20 > to have G.711? > >=20 > > Consider an all-IM federation. Do they have to have G.711? >=20 > IMO we should specify G711 as mandatory codec for voice=20 > peering. Thus, the all-IM and all-video federations are still=20 > standard conform. >=20 > Regarding IMS: Is really everything in IMS/3GPP 100%IETF=20 > compatible? Any federation can overrule the standard. >=20 > For example the federation "high secure" can have a policy:=20 > Peering according to SPEERMINT RFCxxxx+RFCxxx witht he=20 > exception that it requires signaling over TLS+IPSEC over=20 > private Layer2 network. >=20 > The "low-bandwidth" federation specifies speermint RFCxxxx + G.729.=20 > Every service provider can choose to participate in this=20 > federation or not. >=20 > Thus, if the IMS federation mandates SPEERMINT RFCxxxx with=20 > the exception of AMR instead of G.711 IMO this is fine. But=20 > if any of the IMS providers want to peer with the=20 > "low-bandwidth" federation it has to support G.711 and G.729 as well. >=20 > I'm sure there will be also federation which do not use the=20 > SPEERMINT documents at all. >=20 > regards > klaus >=20 > >=20 > >=20 > > Brian > >=20 > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > Sent: Tuesday, June 27, 2006 4:30 PM > > To: Drage, Keith (Keith); Livingood, Jason; Rohan Mahy;=20 > Michael Hammer > > (mhammer) > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] I-D=20 > > ACTION:draft-ietf-speermint-requirements-00.t > > xt > >=20 > > So is this kind of scenario in scope of speermint? > > Take: > > - on one side, a 3GPP IMS network with the typical UE=20 > that does not=20 > > support G.711 on the terminal, and, > > - on the other, a VSP like free world dialup or alike=20 > that allow any=20 > > sip UA with any kind of codec. > >=20 > > Do we want to have some minimal requirements to ensure that=20 > > negotiation just does not fail? I could care less where this=20 > > transcoding function is implemented. > >=20 > > Jean-Francois > >=20 > >> -----Original Message----- > >> From: Drage, Keith (Keith) [mailto:drage@lucent.com] > >> Sent: Tuesday, June 27, 2006 11:31 AM > >> To: Livingood, Jason; Rohan Mahy; Michael Hammer (mhammer) > >> Cc: speermint@ietf.org > >> Subject: RE: [Speermint] I-D=20 > >> ACTION:draft-ietf-speermint-requirements- > >> 00.t xt > >> > >> But this still does not answer my original question. > >> > >> How can you mandate a codec for what is essentially a network=20 > >> operator when that operator does not own the terminals=20 > (which contain=20 > >> the vast majority of the codecs). Are you making a requirement for=20 > >> transcoding support in the absence of whatever codec set=20 > is defined,=20 > >> or is it just an empty letter? > >> > >> regards > >> > >> Keith > >> > >>> -----Original Message----- > >>> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > >>> Sent: 27 June 2006 16:24 > >>> To: Rohan Mahy; Michael Hammer (mhammer) > >>> Cc: speermint@ietf.org > >>> Subject: RE: [Speermint] I-D > >>> ACTION:draft-ietf-speermint-requirements-00.t xt > >>> > >>> > >>> My initial thought is that you are accurate saying that=20 > federations=20 > >>> are NOT REQUIRED for speermint. Federations MAY or MAY=20 > NOT be used,=20 > >>> as you noted, and to that extent will be considered in=20 > some fashion=20 > >>> here. > >>> > >>> As for codecs, I think we'll have to see based on further WG=20 > >>> discussion. > >>> I would surely agree that codec negotiation / selection is *well*=20 > >>> handled in the underlying SIP protocol itself. However,=20 > we may well=20 > >>> find a need to specify (or not) a lowest common denominator codec > >> but > >>> we'll have to see how our requirements work progress. > >>> > >>> Jason > >>> > >>>> -----Original Message----- > >>>> From: Rohan Mahy [mailto:rohan.mahy@gmail.com] > >>>> Sent: Sunday, June 25, 2006 2:41 PM > >>>> To: Michael Hammer (mhammer) > >>>> Cc: speermint@ietf.org > >>>> Subject: Re: [Speermint] I-D > >>>> ACTION:draft-ietf-speermint-requirements-00.t xt > >>>> > >>>> Mike, > >>>> > >>>> There is no requirement for a federation to exist in=20 > speermint. It=20 > >>>> might or it might not, but the IETF won't be very=20 > effective trying=20 > >>>> to put requirements on something which is effectively a business=20 > >>>> arrangement. We can define a set of protocols however,=20 > which needs=20 > >>>> to be useful in the big-I Internet and hopefully for=20 > folks building=20 > >>>> federations and other clubs as well. > >>>> > >>>> Everyone, > >>>> > >>>> I think codec selection should be out of scope. Mandating > >>>> G.711 will have no positive effect now. Everyone=20 > supports it today=20 > >>>> in some way or another, but it could be detrimental in=20 > the future. =20 > >>>> The point of the SDP negotiation is to allow RTP > >>>> *endpoints* to select the best codec in common under the=20 > >>>> circumstances. I don't think we can do any better than=20 > that in a=20 > >>>> requirements document, especially since we are describing an=20 > >>>> interface between SIP intermediaries that I hope will=20 > not even be a=20 > >>>> participant in the RTP media most > >>> of the time. > >>>> thanks, > >>>> -rohan > >>>> > >>>> > >>>> > >>>> On 6/23/06, Michael Hammer (mhammer) wrote: > >>>>> Shouldn't the requirement be that the policy of a > >>> federation should > >>>>> address the default codecs used by a federation to interconnect? > >>>>> > >>>>> Mike > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Drage, Keith (Keith) [mailto:drage@lucent.com] > >>>>>> Sent: Friday, June 23, 2006 10:22 AM > >>>>>> To: speermint@ietf.org > >>>>>> Subject: RE: [Speermint] I-D > >>>>>> ACTION:draft-ietf-speermint-requirements-00.t xt > >>>>>> > >>>>>> Section 3.5 indicates: > >>>>>> > >>>>>> The minimum requirements to allow a successful VoIP > >>>> interconnection > >>>>>> include: > >>>>>> > >>>>>> o the mandatory support of RTP *and* RTCP as defined in=20 > >>>>>> [RFC3550], > >>>>>> > >>>>>> o the support of compatible codecs between > >>>> communication peers, > >>>>>> the > >>>>>> G.711 MUST be supported, the IETF iLBC [RFC3951] > >>>> codec and its > >>>>>> RTP > >>>>>> payload format [RFC3952] SHOULD be supported. > >>>>>> > >>>>>> o the support of the VoIP metric block as defined in > >>>> RTP Control > >>>>>> Protocol Extended Reports [RFC3611] MAY be supported. > >>>>>> > >>>>>> What exactly does this mean to the two bodies that are > >>> making the > >>>>>> peering arrangement. Is this a requirement to control > >>> the codecs > >>>>>> used by the UAs attached to the peering organisations > >> equipment > >>>>>> before peering can occur, or a requirement to support > >>>> transcoding if > >>>>>> these requirements are not met by the population of > >>> attached UAs. > >>>>>> Additional nit comment. RFC 2327 is obsolete and sdp-new is=20 > >>>>>> imminently about to be published and I assume we are going to=20 > >>>>>> reference that document (it will be RFC 4566). > >>>>>> > >>>>>> regards > >>>>>> > >>>>>> Keith > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Internet-Drafts@ietf.org > >>> [mailto:Internet-Drafts@ietf.org] > >>>>>>> Sent: 21 June 2006 23:50 > >>>>>>> To: i-d-announce@ietf.org > >>>>>>> Cc: speermint@ietf.org > >>>>>>> Subject: [Speermint] I-D > >>>>>>> ACTION:draft-ietf-speermint-requirements-00.txt > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 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 Requirements for SIP-based > >>>>>>> VoIP Interconnection > >>>>>>> Author(s) : J. Mule > >>>>>>> Filename : draft-ietf-speermint-requirements- > >> 00.txt > >>>>>>> Pages : 10 > >>>>>>> Date : 2006-6-21 > >>>>>>> > >>>>>>> This document describes general requirements for Session=20 > >>>>>>> PEERing for > >>>>>>> Multimedia INTerconnect and defines the minimum set of > >>>>>> requirements > >>>>>>> applicable to SIP session peering for VoIP interconnects. > >>>>>>> > >>>>>>> In its current form, the document is a first draft > >>>> based on the > >>>>>>> SPEERMINT mailing list's discussions on > >>>> requirements. The main > >>>>>>> objectives are to generate consensus on what categories > >> of > >>>>>>> requirements should be covered, and to start more > >>>> discussions > >>>>>>> on the > >>>>>>> technical protocol requirements that apply to VoIP > >>>> interconnects. > >>>>>>> > >>>>>>> A URL for this Internet-Draft is: > >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-speermint- > >> requi > >>>>>> rements-00.txt > >>>>>> > >>>>>> To remove yourself from the I-D Announcement list, send a > >>>> message to > >>>>>> i-d-announce-request@ietf.org with the word unsubscribe > >>>> in the body > >>>>>> of the message. > >>>>>> You can also visit > >>>>>> https://www1.ietf.org/mailman/listinfo/I-D-announce > >>>>>> to change your subscription settings. > >>>>>> > >>>>>> > >>>>>> Internet-Drafts are also available by anonymous FTP. > >>>> Login with the > >>>>>> username "anonymous" and a password of your e-mail > >>> address. After > >>>>>> logging in, type "cd internet-drafts" and then > >>>>>> "get draft-ietf-speermint-requirements-00.txt". > >>>>>> > >>>>>> A list of Internet-Drafts directories can be found in=20 > >>>>>> http://www.ietf.org/shadow.html or=20 > >>>>>> 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-requirements-00.txt". > >>>>>> > >>>>>> NOTE: The mail server at ietf.org can return the document in > >>>>>> MIME-encoded form by using the "mpack" utility. > >>> To use this > >>>>>> feature, insert the command "ENCODING mime" before > >>>> the "FILE" > >>>>>> command. To decode the response(s), you will need > >>>> "munpack" or > >>>>>> a MIME-compliant mail reader. Different > >>>> MIME-compliant mail > >>>>>> readers > >>>>>> exhibit different behavior, especially when dealing with > >>>>>> "multipart" MIME messages (i.e. documents which > >>>> have been split > >>>>>> up into multiple messages), so check your local > >>>> documentation on > >>>>>> how to manipulate these messages. > >>>>>> > >>>>>> > >>>>>> Below is the data which will enable a MIME compliant > >>> mail reader > >>>>>> implementation to automatically retrieve the ASCII > >>> version of the > >>>>>> Internet-Draft. > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >>>> > >>> _______________________________________________ > >>> 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 > >=20 > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 24 09:00:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G502y-0007LN-Jm; Mon, 24 Jul 2006 09:00:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G502x-0007LI-T2 for speermint@ietf.org; Mon, 24 Jul 2006 09:00:31 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G502x-0002t7-2r for speermint@ietf.org; Mon, 24 Jul 2006 09:00:31 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 12D2F210092; Mon, 24 Jul 2006 15:00:30 +0200 (CEST) Message-ID: <44C4C471.1010503@pernau.at> Date: Mon, 24 Jul 2006 15:00:33 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt References: <5D1A7985295922448D5550C94DE2918013B011@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918013B011@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 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 Drage, Keith (Keith) wrote: > The issue here is not whether IMS wants to do their own thing. > > The issue is that putting G.711 over any radio interface in a cellular > environment borders on commercial insanity for either the customer, the > operator, or both. When you specify G.711 as mandatory that does not imply that it must be used - you may also use better codecs. The funny thing is, that if we do not specify them, there is no guarantee for a working interconnect. E.g. Provider A is a mobile operator and willing to interconnect via SIP. Provider B is a fixed line operator willing to interconnect via SIP. They both spend $$$ to by a SIP environment which supports peering according to the specifications made by the SPEERMINT group. And finally they can't interconnect as A uses AMR and B uses G.711. regards Klaus > > Therefore you should not be specifying G.711 as the default unless you > are also going to specify that transcoding (in the intervening sustem) > must take place to G.711 when the terminal does not support or use such > a codec, AND that some form of transcoder free operation should also be > supported across the peering interface. > > (Side note: I suspect if one started totally figures for the number of > end systems that support G.711, and those that support AMR, you might > well be surprised at the result). > > Regards > > Keith > >> -----Original Message----- >> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >> Sent: 21 July 2006 13:25 >> To: Brian Rosen >> Cc: 'Jean-Francois Mule'; Drage, Keith (Keith); 'Livingood, >> Jason'; 'Rohan Mahy'; 'Michael Hammer (mhammer)'; speermint@ietf.org >> Subject: Re: [Speermint] I-D >> ACTION:draft-ietf-speermint-requirements-00.t xt >> >> Brian Rosen wrote: >>> Consider an all-IMS, all-GSM federation. Do they have to >> have G.711? >>> Consider an all-video conference federation. Do they have >> to have G.711? >>> Consider an all-IM federation. Do they have to have G.711? >> IMO we should specify G711 as mandatory codec for voice >> peering. Thus, the all-IM and all-video federations are still >> standard conform. >> >> Regarding IMS: Is really everything in IMS/3GPP 100%IETF >> compatible? Any federation can overrule the standard. >> >> For example the federation "high secure" can have a policy: >> Peering according to SPEERMINT RFCxxxx+RFCxxx witht he >> exception that it requires signaling over TLS+IPSEC over >> private Layer2 network. >> >> The "low-bandwidth" federation specifies speermint RFCxxxx + G.729. >> Every service provider can choose to participate in this >> federation or not. >> >> Thus, if the IMS federation mandates SPEERMINT RFCxxxx with >> the exception of AMR instead of G.711 IMO this is fine. But >> if any of the IMS providers want to peer with the >> "low-bandwidth" federation it has to support G.711 and G.729 as well. >> >> I'm sure there will be also federation which do not use the >> SPEERMINT documents at all. >> >> regards >> klaus >> >>> >>> Brian >>> >>> -----Original Message----- >>> From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] >>> Sent: Tuesday, June 27, 2006 4:30 PM >>> To: Drage, Keith (Keith); Livingood, Jason; Rohan Mahy; >> Michael Hammer >>> (mhammer) >>> Cc: speermint@ietf.org >>> Subject: RE: [Speermint] I-D >>> ACTION:draft-ietf-speermint-requirements-00.t >>> xt >>> >>> So is this kind of scenario in scope of speermint? >>> Take: >>> - on one side, a 3GPP IMS network with the typical UE >> that does not >>> support G.711 on the terminal, and, >>> - on the other, a VSP like free world dialup or alike >> that allow any >>> sip UA with any kind of codec. >>> >>> Do we want to have some minimal requirements to ensure that >>> negotiation just does not fail? I could care less where this >>> transcoding function is implemented. >>> >>> Jean-Francois >>> >>>> -----Original Message----- >>>> From: Drage, Keith (Keith) [mailto:drage@lucent.com] >>>> Sent: Tuesday, June 27, 2006 11:31 AM >>>> To: Livingood, Jason; Rohan Mahy; Michael Hammer (mhammer) >>>> Cc: speermint@ietf.org >>>> Subject: RE: [Speermint] I-D >>>> ACTION:draft-ietf-speermint-requirements- >>>> 00.t xt >>>> >>>> But this still does not answer my original question. >>>> >>>> How can you mandate a codec for what is essentially a network >>>> operator when that operator does not own the terminals >> (which contain >>>> the vast majority of the codecs). Are you making a requirement for >>>> transcoding support in the absence of whatever codec set >> is defined, >>>> or is it just an empty letter? >>>> >>>> regards >>>> >>>> Keith >>>> >>>>> -----Original Message----- >>>>> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] >>>>> Sent: 27 June 2006 16:24 >>>>> To: Rohan Mahy; Michael Hammer (mhammer) >>>>> Cc: speermint@ietf.org >>>>> Subject: RE: [Speermint] I-D >>>>> ACTION:draft-ietf-speermint-requirements-00.t xt >>>>> >>>>> >>>>> My initial thought is that you are accurate saying that >> federations >>>>> are NOT REQUIRED for speermint. Federations MAY or MAY >> NOT be used, >>>>> as you noted, and to that extent will be considered in >> some fashion >>>>> here. >>>>> >>>>> As for codecs, I think we'll have to see based on further WG >>>>> discussion. >>>>> I would surely agree that codec negotiation / selection is *well* >>>>> handled in the underlying SIP protocol itself. However, >> we may well >>>>> find a need to specify (or not) a lowest common denominator codec >>>> but >>>>> we'll have to see how our requirements work progress. >>>>> >>>>> Jason >>>>> >>>>>> -----Original Message----- >>>>>> From: Rohan Mahy [mailto:rohan.mahy@gmail.com] >>>>>> Sent: Sunday, June 25, 2006 2:41 PM >>>>>> To: Michael Hammer (mhammer) >>>>>> Cc: speermint@ietf.org >>>>>> Subject: Re: [Speermint] I-D >>>>>> ACTION:draft-ietf-speermint-requirements-00.t xt >>>>>> >>>>>> Mike, >>>>>> >>>>>> There is no requirement for a federation to exist in >> speermint. It >>>>>> might or it might not, but the IETF won't be very >> effective trying >>>>>> to put requirements on something which is effectively a business >>>>>> arrangement. We can define a set of protocols however, >> which needs >>>>>> to be useful in the big-I Internet and hopefully for >> folks building >>>>>> federations and other clubs as well. >>>>>> >>>>>> Everyone, >>>>>> >>>>>> I think codec selection should be out of scope. Mandating >>>>>> G.711 will have no positive effect now. Everyone >> supports it today >>>>>> in some way or another, but it could be detrimental in >> the future. >>>>>> The point of the SDP negotiation is to allow RTP >>>>>> *endpoints* to select the best codec in common under the >>>>>> circumstances. I don't think we can do any better than >> that in a >>>>>> requirements document, especially since we are describing an >>>>>> interface between SIP intermediaries that I hope will >> not even be a >>>>>> participant in the RTP media most >>>>> of the time. >>>>>> thanks, >>>>>> -rohan >>>>>> >>>>>> >>>>>> >>>>>> On 6/23/06, Michael Hammer (mhammer) wrote: >>>>>>> Shouldn't the requirement be that the policy of a >>>>> federation should >>>>>>> address the default codecs used by a federation to interconnect? >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Drage, Keith (Keith) [mailto:drage@lucent.com] >>>>>>>> Sent: Friday, June 23, 2006 10:22 AM >>>>>>>> To: speermint@ietf.org >>>>>>>> Subject: RE: [Speermint] I-D >>>>>>>> ACTION:draft-ietf-speermint-requirements-00.t xt >>>>>>>> >>>>>>>> Section 3.5 indicates: >>>>>>>> >>>>>>>> The minimum requirements to allow a successful VoIP >>>>>> interconnection >>>>>>>> include: >>>>>>>> >>>>>>>> o the mandatory support of RTP *and* RTCP as defined in >>>>>>>> [RFC3550], >>>>>>>> >>>>>>>> o the support of compatible codecs between >>>>>> communication peers, >>>>>>>> the >>>>>>>> G.711 MUST be supported, the IETF iLBC [RFC3951] >>>>>> codec and its >>>>>>>> RTP >>>>>>>> payload format [RFC3952] SHOULD be supported. >>>>>>>> >>>>>>>> o the support of the VoIP metric block as defined in >>>>>> RTP Control >>>>>>>> Protocol Extended Reports [RFC3611] MAY be supported. >>>>>>>> >>>>>>>> What exactly does this mean to the two bodies that are >>>>> making the >>>>>>>> peering arrangement. Is this a requirement to control >>>>> the codecs >>>>>>>> used by the UAs attached to the peering organisations >>>> equipment >>>>>>>> before peering can occur, or a requirement to support >>>>>> transcoding if >>>>>>>> these requirements are not met by the population of >>>>> attached UAs. >>>>>>>> Additional nit comment. RFC 2327 is obsolete and sdp-new is >>>>>>>> imminently about to be published and I assume we are going to >>>>>>>> reference that document (it will be RFC 4566). >>>>>>>> >>>>>>>> regards >>>>>>>> >>>>>>>> Keith >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Internet-Drafts@ietf.org >>>>> [mailto:Internet-Drafts@ietf.org] >>>>>>>>> Sent: 21 June 2006 23:50 >>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>> Cc: speermint@ietf.org >>>>>>>>> Subject: [Speermint] I-D >>>>>>>>> ACTION:draft-ietf-speermint-requirements-00.txt >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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 Requirements for SIP-based >>>>>>>>> VoIP Interconnection >>>>>>>>> Author(s) : J. Mule >>>>>>>>> Filename : draft-ietf-speermint-requirements- >>>> 00.txt >>>>>>>>> Pages : 10 >>>>>>>>> Date : 2006-6-21 >>>>>>>>> >>>>>>>>> This document describes general requirements for Session >>>>>>>>> PEERing for >>>>>>>>> Multimedia INTerconnect and defines the minimum set of >>>>>>>> requirements >>>>>>>>> applicable to SIP session peering for VoIP interconnects. >>>>>>>>> >>>>>>>>> In its current form, the document is a first draft >>>>>> based on the >>>>>>>>> SPEERMINT mailing list's discussions on >>>>>> requirements. The main >>>>>>>>> objectives are to generate consensus on what categories >>>> of >>>>>>>>> requirements should be covered, and to start more >>>>>> discussions >>>>>>>>> on the >>>>>>>>> technical protocol requirements that apply to VoIP >>>>>> interconnects. >>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-speermint- >>>> requi >>>>>>>> rements-00.txt >>>>>>>> >>>>>>>> To remove yourself from the I-D Announcement list, send a >>>>>> message to >>>>>>>> i-d-announce-request@ietf.org with the word unsubscribe >>>>>> in the body >>>>>>>> of the message. >>>>>>>> You can also visit >>>>>>>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>>>>>>> to change your subscription settings. >>>>>>>> >>>>>>>> >>>>>>>> Internet-Drafts are also available by anonymous FTP. >>>>>> Login with the >>>>>>>> username "anonymous" and a password of your e-mail >>>>> address. After >>>>>>>> logging in, type "cd internet-drafts" and then >>>>>>>> "get draft-ietf-speermint-requirements-00.txt". >>>>>>>> >>>>>>>> A list of Internet-Drafts directories can be found in >>>>>>>> http://www.ietf.org/shadow.html or >>>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>> >>>>>>>> >>>>>>>> Internet-Drafts can also be obtained by e-mail. >>>>>>>> >>>>>>>> Send a message to: >>>>>>>> mailserv@ietf.org. >>>>>>>> In the body type: >>>>>>>> "FILE >>>>>>>> /internet-drafts/draft-ietf-speermint-requirements-00.txt". >>>>>>>> >>>>>>>> NOTE: The mail server at ietf.org can return the document in >>>>>>>> MIME-encoded form by using the "mpack" utility. >>>>> To use this >>>>>>>> feature, insert the command "ENCODING mime" before >>>>>> the "FILE" >>>>>>>> command. To decode the response(s), you will need >>>>>> "munpack" or >>>>>>>> a MIME-compliant mail reader. Different >>>>>> MIME-compliant mail >>>>>>>> readers >>>>>>>> exhibit different behavior, especially when dealing with >>>>>>>> "multipart" MIME messages (i.e. documents which >>>>>> have been split >>>>>>>> up into multiple messages), so check your local >>>>>> documentation on >>>>>>>> how to manipulate these messages. >>>>>>>> >>>>>>>> >>>>>>>> Below is the data which will enable a MIME compliant >>>>> mail reader >>>>>>>> implementation to automatically retrieve the ASCII >>>>> version of the >>>>>>>> Internet-Draft. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> _______________________________________________ >>> 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 Mon Jul 24 09:39:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G50eR-0007Rt-Ui; Mon, 24 Jul 2006 09:39:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G50eR-0007Ro-0P for speermint@ietf.org; Mon, 24 Jul 2006 09:39:15 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G50eP-0008Si-R1 for speermint@ietf.org; Mon, 24 Jul 2006 09:39:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Mon, 24 Jul 2006 15:35:39 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B37@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Thread-Index: AcavIQnls6Sd0Pl5SeOi3dxSww52RgABQOrT References: <5D1A7985295922448D5550C94DE2918013B011@DEEXC1U01.de.lucent.com> <44C4C471.1010503@pernau.at> From: "Stastny Richard" To: "Klaus Darilion" , "Drage, Keith \(Keith\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 562cdc9baa87554b29d950396a30cf75 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 >And finally they can't interconnect as A >uses AMR and B uses G.711. They can, if one provides transcoding =20 If we say G.711 is mandatory, it is provider A who has to provide the = transcoding Richard ________________________________ Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Gesendet: Mo 24.07.2006 15:00 An: Drage, Keith (Keith) Cc: speermint@ietf.org Betreff: Re: [Speermint] I-D = ACTION:draft-ietf-speermint-requirements-00.t xt Drage, Keith (Keith) wrote: > The issue here is not whether IMS wants to do their own thing. > > The issue is that putting G.711 over any radio interface in a cellular > environment borders on commercial insanity for either the customer, = the > operator, or both. When you specify G.711 as mandatory that does not imply that it must be used - you may also use better codecs. The funny thing is, that if we do not specify them, there is no guarantee for a working interconnect. E.g. Provider A is a mobile operator and willing to interconnect via SIP. Provider B is a fixed line operator willing to interconnect via SIP. They both spend $$$ to by a SIP environment which supports peering according to the specifications made by the SPEERMINT group. And finally they can't interconnect as A uses AMR and B uses G.711. regards Klaus > > Therefore you should not be specifying G.711 as the default unless you > are also going to specify that transcoding (in the intervening sustem) > must take place to G.711 when the terminal does not support or use = such > a codec, AND that some form of transcoder free operation should also = be > supported across the peering interface. > > (Side note: I suspect if one started totally figures for the number of > end systems that support G.711, and those that support AMR, you might > well be surprised at the result). > > Regards > > Keith > >> -----Original Message----- >> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >> Sent: 21 July 2006 13:25 >> To: Brian Rosen >> Cc: 'Jean-Francois Mule'; Drage, Keith (Keith); 'Livingood, >> Jason'; 'Rohan Mahy'; 'Michael Hammer (mhammer)'; speermint@ietf.org >> Subject: Re: [Speermint] I-D >> ACTION:draft-ietf-speermint-requirements-00.t xt >> >> Brian Rosen wrote: >>> Consider an all-IMS, all-GSM federation. Do they have to >> have G.711? >>> Consider an all-video conference federation. Do they have >> to have G.711? >>> Consider an all-IM federation. Do they have to have G.711? >> IMO we should specify G711 as mandatory codec for voice >> peering. Thus, the all-IM and all-video federations are still >> standard conform. >> >> Regarding IMS: Is really everything in IMS/3GPP 100%IETF >> compatible? Any federation can overrule the standard. >> >> For example the federation "high secure" can have a policy: >> Peering according to SPEERMINT RFCxxxx+RFCxxx witht he >> exception that it requires signaling over TLS+IPSEC over >> private Layer2 network. >> >> The "low-bandwidth" federation specifies speermint RFCxxxx + G.729. >> Every service provider can choose to participate in this >> federation or not. >> >> Thus, if the IMS federation mandates SPEERMINT RFCxxxx with >> the exception of AMR instead of G.711 IMO this is fine. But >> if any of the IMS providers want to peer with the >> "low-bandwidth" federation it has to support G.711 and G.729 as well. >> >> I'm sure there will be also federation which do not use the >> SPEERMINT documents at all. >> >> regards >> klaus >> >>> >>> Brian >>> >>> -----Original Message----- >>> From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] >>> Sent: Tuesday, June 27, 2006 4:30 PM >>> To: Drage, Keith (Keith); Livingood, Jason; Rohan Mahy; >> Michael Hammer >>> (mhammer) >>> Cc: speermint@ietf.org >>> Subject: RE: [Speermint] I-D >>> ACTION:draft-ietf-speermint-requirements-00.t >>> xt >>> >>> So is this kind of scenario in scope of speermint? >>> Take: >>> - on one side, a 3GPP IMS network with the typical UE >> that does not >>> support G.711 on the terminal, and, >>> - on the other, a VSP like free world dialup or alike >> that allow any >>> sip UA with any kind of codec. >>> >>> Do we want to have some minimal requirements to ensure that >>> negotiation just does not fail? I could care less where this >>> transcoding function is implemented. >>> >>> Jean-Francois >>> >>>> -----Original Message----- >>>> From: Drage, Keith (Keith) [mailto:drage@lucent.com] >>>> Sent: Tuesday, June 27, 2006 11:31 AM >>>> To: Livingood, Jason; Rohan Mahy; Michael Hammer (mhammer) >>>> Cc: speermint@ietf.org >>>> Subject: RE: [Speermint] I-D >>>> ACTION:draft-ietf-speermint-requirements- >>>> 00.t xt >>>> >>>> But this still does not answer my original question. >>>> >>>> How can you mandate a codec for what is essentially a network >>>> operator when that operator does not own the terminals >> (which contain >>>> the vast majority of the codecs). Are you making a requirement for >>>> transcoding support in the absence of whatever codec set >> is defined, >>>> or is it just an empty letter? >>>> >>>> regards >>>> >>>> Keith >>>> >>>>> -----Original Message----- >>>>> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] >>>>> Sent: 27 June 2006 16:24 >>>>> To: Rohan Mahy; Michael Hammer (mhammer) >>>>> Cc: speermint@ietf.org >>>>> Subject: RE: [Speermint] I-D >>>>> ACTION:draft-ietf-speermint-requirements-00.t xt >>>>> >>>>> >>>>> My initial thought is that you are accurate saying that >> federations >>>>> are NOT REQUIRED for speermint. Federations MAY or MAY >> NOT be used, >>>>> as you noted, and to that extent will be considered in >> some fashion >>>>> here. >>>>> >>>>> As for codecs, I think we'll have to see based on further WG >>>>> discussion. >>>>> I would surely agree that codec negotiation / selection is *well* >>>>> handled in the underlying SIP protocol itself. However, >> we may well >>>>> find a need to specify (or not) a lowest common denominator codec >>>> but >>>>> we'll have to see how our requirements work progress. >>>>> >>>>> Jason >>>>> >>>>>> -----Original Message----- >>>>>> From: Rohan Mahy [mailto:rohan.mahy@gmail.com] >>>>>> Sent: Sunday, June 25, 2006 2:41 PM >>>>>> To: Michael Hammer (mhammer) >>>>>> Cc: speermint@ietf.org >>>>>> Subject: Re: [Speermint] I-D >>>>>> ACTION:draft-ietf-speermint-requirements-00.t xt >>>>>> >>>>>> Mike, >>>>>> >>>>>> There is no requirement for a federation to exist in >> speermint. It >>>>>> might or it might not, but the IETF won't be very >> effective trying >>>>>> to put requirements on something which is effectively a business >>>>>> arrangement. We can define a set of protocols however, >> which needs >>>>>> to be useful in the big-I Internet and hopefully for >> folks building >>>>>> federations and other clubs as well. >>>>>> >>>>>> Everyone, >>>>>> >>>>>> I think codec selection should be out of scope. Mandating >>>>>> G.711 will have no positive effect now. Everyone >> supports it today >>>>>> in some way or another, but it could be detrimental in >> the future.=20 >>>>>> The point of the SDP negotiation is to allow RTP >>>>>> *endpoints* to select the best codec in common under the >>>>>> circumstances. I don't think we can do any better than >> that in a >>>>>> requirements document, especially since we are describing an >>>>>> interface between SIP intermediaries that I hope will >> not even be a >>>>>> participant in the RTP media most >>>>> of the time. >>>>>> thanks, >>>>>> -rohan >>>>>> >>>>>> >>>>>> >>>>>> On 6/23/06, Michael Hammer (mhammer) wrote: >>>>>>> Shouldn't the requirement be that the policy of a >>>>> federation should >>>>>>> address the default codecs used by a federation to interconnect? >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Drage, Keith (Keith) [mailto:drage@lucent.com] >>>>>>>> Sent: Friday, June 23, 2006 10:22 AM >>>>>>>> To: speermint@ietf.org >>>>>>>> Subject: RE: [Speermint] I-D >>>>>>>> ACTION:draft-ietf-speermint-requirements-00.t xt >>>>>>>> >>>>>>>> Section 3.5 indicates: >>>>>>>> >>>>>>>> The minimum requirements to allow a successful VoIP >>>>>> interconnection >>>>>>>> include: >>>>>>>> >>>>>>>> o the mandatory support of RTP *and* RTCP as defined in >>>>>>>> [RFC3550], >>>>>>>> >>>>>>>> o the support of compatible codecs between >>>>>> communication peers, >>>>>>>> the >>>>>>>> G.711 MUST be supported, the IETF iLBC [RFC3951] >>>>>> codec and its >>>>>>>> RTP >>>>>>>> payload format [RFC3952] SHOULD be supported. >>>>>>>> >>>>>>>> o the support of the VoIP metric block as defined in >>>>>> RTP Control >>>>>>>> Protocol Extended Reports [RFC3611] MAY be supported. >>>>>>>> >>>>>>>> What exactly does this mean to the two bodies that are >>>>> making the >>>>>>>> peering arrangement. Is this a requirement to control >>>>> the codecs >>>>>>>> used by the UAs attached to the peering organisations >>>> equipment >>>>>>>> before peering can occur, or a requirement to support >>>>>> transcoding if >>>>>>>> these requirements are not met by the population of >>>>> attached UAs. >>>>>>>> Additional nit comment. RFC 2327 is obsolete and sdp-new is >>>>>>>> imminently about to be published and I assume we are going to >>>>>>>> reference that document (it will be RFC 4566). >>>>>>>> >>>>>>>> regards >>>>>>>> >>>>>>>> Keith >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Internet-Drafts@ietf.org >>>>> [mailto:Internet-Drafts@ietf.org] >>>>>>>>> Sent: 21 June 2006 23:50 >>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>> Cc: speermint@ietf.org >>>>>>>>> Subject: [Speermint] I-D >>>>>>>>> ACTION:draft-ietf-speermint-requirements-00.txt >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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 Requirements for SIP-based >>>>>>>>> VoIP Interconnection >>>>>>>>> Author(s) : J. Mule >>>>>>>>> Filename : draft-ietf-speermint-requirements- >>>> 00.txt >>>>>>>>> Pages : 10 >>>>>>>>> Date : 2006-6-21 >>>>>>>>> >>>>>>>>> This document describes general requirements for Session >>>>>>>>> PEERing for >>>>>>>>> Multimedia INTerconnect and defines the minimum set of >>>>>>>> requirements >>>>>>>>> applicable to SIP session peering for VoIP interconnects. >>>>>>>>> >>>>>>>>> In its current form, the document is a first draft >>>>>> based on the >>>>>>>>> SPEERMINT mailing list's discussions on >>>>>> requirements. The main >>>>>>>>> objectives are to generate consensus on what categories >>>> of >>>>>>>>> requirements should be covered, and to start more >>>>>> discussions >>>>>>>>> on the >>>>>>>>> technical protocol requirements that apply to VoIP >>>>>> interconnects. >>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-speermint- >>>> requi >>>>>>>> rements-00.txt >>>>>>>> >>>>>>>> To remove yourself from the I-D Announcement list, send a >>>>>> message to >>>>>>>> i-d-announce-request@ietf.org with the word unsubscribe >>>>>> in the body >>>>>>>> of the message. >>>>>>>> You can also visit >>>>>>>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>>>>>>> to change your subscription settings. >>>>>>>> >>>>>>>> >>>>>>>> Internet-Drafts are also available by anonymous FTP. >>>>>> Login with the >>>>>>>> username "anonymous" and a password of your e-mail >>>>> address. After >>>>>>>> logging in, type "cd internet-drafts" and then >>>>>>>> "get draft-ietf-speermint-requirements-00.txt". >>>>>>>> >>>>>>>> A list of Internet-Drafts directories can be found in >>>>>>>> http://www.ietf.org/shadow.html or >>>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>> >>>>>>>> >>>>>>>> Internet-Drafts can also be obtained by e-mail. >>>>>>>> >>>>>>>> Send a message to: >>>>>>>> mailserv@ietf.org. >>>>>>>> In the body type: >>>>>>>> "FILE >>>>>>>> /internet-drafts/draft-ietf-speermint-requirements-00.txt". >>>>>>>> >>>>>>>> NOTE: The mail server at ietf.org can return the document in >>>>>>>> MIME-encoded form by using the "mpack" utility. >>>>> To use this >>>>>>>> feature, insert the command "ENCODING mime" before >>>>>> the "FILE" >>>>>>>> command. To decode the response(s), you will need >>>>>> "munpack" or >>>>>>>> a MIME-compliant mail reader. Different >>>>>> MIME-compliant mail >>>>>>>> readers >>>>>>>> exhibit different behavior, especially when dealing with >>>>>>>> "multipart" MIME messages (i.e. documents which >>>>>> have been split >>>>>>>> up into multiple messages), so check your local >>>>>> documentation on >>>>>>>> how to manipulate these messages. >>>>>>>> >>>>>>>> >>>>>>>> Below is the data which will enable a MIME compliant >>>>> mail reader >>>>>>>> implementation to automatically retrieve the ASCII >>>>> version of the >>>>>>>> Internet-Draft. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> _______________________________________________ >>> 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 Mon Jul 24 09:47:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G50mi-0003em-SR; Mon, 24 Jul 2006 09:47:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G50mg-0003ee-Un for speermint@ietf.org; Mon, 24 Jul 2006 09:47:46 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G50md-0001HA-KN for speermint@ietf.org; Mon, 24 Jul 2006 09:47:46 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k6ODlfrH001904; Mon, 24 Jul 2006 07:47:42 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Mon, 24 Jul 2006 07:47:41 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Thread-Index: AcaswMIBXGoKxNnzRXee5gSEEec6VQCSEfngAAdb8uA= From: "Jean-Francois Mule" To: "Drage, Keith (Keith)" , "Klaus Darilion" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Keith,=20 See inline.=20 Jean-Francois. You wrote: > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Monday, July 24, 2006 4:14 AM > To: Klaus Darilion > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements- > 00.t xt >=20 > The issue here is not whether IMS wants to do their own thing. >=20 > The issue is that putting G.711 over any radio interface in a cellular > environment borders on commercial insanity for either the customer, > the > operator, or both. >=20 > Therefore you should not be specifying G.711 as the default unless you > are also going to specify that transcoding (in the intervening sustem) > must take place to G.711 when the terminal does not support or use > such > a codec, AND that some form of transcoder free operation should also ^^^^^^^^^^^^^^^^^^^^^ !!!!!!!!!!!!!!! ^^^^^^^^^ !!!!!! ^^^^ > be > supported across the peering interface. This is where you loose me. Are you suggesting putting a requirement (albeit at a should level) on transcoder free operation for all VoIP networks, yet not specify one or more *common* codecs?=20 If so, are you suggesting to recommend transcoder free operations without specifying any common denominator between L5 peers (user groups, VSP, enterprises)? > (Side note: I suspect if one started totally figures for the number of > end systems that support G.711, and those that support AMR, you might > well be surprised at the result). Side side note: I think we should define "end systems" as in *IP* end systems (with RTP data pumps bolted to the codec DSP) in this speermint context. Does the result survive? >=20 > Regards >=20 > Keith _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 24 10:12:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G51AZ-00040P-Hn; Mon, 24 Jul 2006 10:12:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G51AX-00040K-Ms for speermint@ietf.org; Mon, 24 Jul 2006 10:12:25 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G51AX-0004Dz-9v for speermint@ietf.org; Mon, 24 Jul 2006 10:12:25 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G51AQ-0004rT-RT; Mon, 24 Jul 2006 09:12:19 -0500 From: "Brian Rosen" To: "'Klaus Darilion'" Subject: RE: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted)) Date: Mon, 24 Jul 2006 10:12:21 -0400 Message-ID: <088001c6af2b$2f6d61f0$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 thread-index: AcausoXeKVtQn2bYT8+ufq5C7ARWzAAdWLHQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <63843.212.17.67.197.1153698523.squirrel@pb94.dyndns.org> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.6 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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 think you are misinterpreting 3261. Section 26.3.2.2 is illustrating a simple SIP trapezoid call where the call goes from atlanta.com to biloxi.com. If there is another intermediary, biloxi.com would not be checking the From to see that it matched the domain of the T proxy handling the call. We all agree that TLS is underspecified in 3261. There is some effort to address this shortcoming underway. If the path is A -> T -> B, then the mutual TLS cert validation is A <-> T and T <-> B. In a peering system, the peers authenticate each other within the peering regime. If T accepts a call from A destined for B, then it authenticates A as a peer which it accepts transit calls for B, and it authenticates B as a peer with whom it can send calls destined for B. Brian > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Sunday, July 23, 2006 7:49 PM > To: Brian Rosen > Cc: speermint@ietf.org > Subject: RE: TLS for peering (was RE: Comments > (RE:[speermint]requirementsdraftsubmitted)) > > Hi Brian! > > On Fri, July 21, 2006 18:08, Brian Rosen said: > > I believe it is the case that the link from one peer to another, which > is > > generally between two proxies, can very reasonably be protected with > TLS, > > with many current implementations, and with reasonable assumptions about > > PKI. Specifically, if one of the parts of a federation was an agreement > > on > > a CA, then each peer can have a certificate that other peers can verify. > > I > > believe all operations, including forwarding, if they work at all across > > the > > peering system would work if it was TLS protected. > > Using TLS for encryption and TLS certificate validation works - but the L5 > validation (validate the certificate domain names against the domains in > the SIP headers) does not work without mandating a B2BUA. > > TLS/SSL was invented for a very simple client-server system - HTTP. Let's > compare HTTP with SIP: > > HTTP: > 1 request - 1 (or more) responses. > L5 validation: verify domain in browser's location bar against the domain > in the server certificate - this is straight forward > > SIP: > Multiple - bidirectional requests > L5 validation: There are several headers which are used for routing and > thus can be used for validation: requestURI, From, To, Via, Route, > Contact. > We can have in-dialog requests which are initiated in reverse direction of > the original dialog setup. And each of this domain resolves to several > domains (due to NAPTR, SRV, A resolution). This alone should have people > think a little more before defining TLS for SIP. > > I am a fan of forwarding - and probably every transit service provider > too. As transit will happen I will use the transit scenario (simple > forwarding without a B2BUA) to show that L5 validation is broken - and I > would be very very happy if someone can show that I'm wrong. > > A want to call B. There is no direct peering agreement. Thus A sends the > call to it's transit provider T. (only the signaling between the proxies > is shown) > > A->T > INVITE sip:B@B > From: sip:A@A > To: sip:B@B > Contact: user@phone > Record-Route: sip:A > > Cert validation according to RFC3261 section 26.3.2.2: > T will show a TLS certificate for T (not for B) - thus, when A validates > T's certificate, the validation will fail. IMO this can be fixed by adding > a Route: header with sip:T, but this is nowhere mentioned in RFC 3261. > > T->B > INVITE sip:B@B > From: sip:A@A > To: sip:B@B > Contact: user@phone > Record-Route: sip:T > Record-Route: sip:A > > Cert validation according to RFC3261 section 26.3.2.2: > B should validate the domain in the From header (A) aginst the domain in > the client's certificate (T) --> it will fail. > > Now let's assume the previous validation have succeeded and B sends a BYE > request to A, and the TLS connection was dropped and must be > re-established: > > B->T > BYE name@1.2.3.4 > From: sip:B@B > To: sip:A@A > Route: sip:T > Route: sip:A > > How should T's certificate be validated? Probably against the domain in > the topmost Route header - but again: This is nowhere specified. > > T->A > BYE name@1.2.3.4 > From: sip:B@B > To: sip:A@A > Route: sip:A > > Again, probably T should use the domain in the Route header for > certificate validation. But A can't validate the certificate's domain (T) > against the From header (B) - it will fail. > > Similar problem arise in a forwarding scenario - A-->B which forwards it's > call to C. The suggested L5 validation will fail (except B uses a B2BUA, > and IMO a B2BUA should not be mandatory). > > > This does not assume sips works (whatever that means), and does not > assume > > endpoints implement TLS, or either the originating or terminating > domains > > deploy TLS anywhere else. > > > > It does provide a reasonable degree of protection across the peering > > point, > > which I think is a good thing. > > Yes, TLS provides protection, but we should not specify a broken L5 > certificate validation. > > > Having lived with protocols that offered options like IPsec and VPNs and > > other mechanisms, I think that despite the fact that you can, in theory, > > create a satisfactory security arrangement, it is exceedingly hard to > make > > it actually work except for cases where there is an entity that > completely > > controls all aspects of the peering. That just isn't the case for what > I > > think we are trying to specify here (such cases don't need IETF > > standardization). Thus, I personally think mandating TLS is a good > thing, > > achievable, and reasonable. That's a MUST IMPLEMENT, not a must deploy; > > Yes, I agree. I want TLS in the specs too - but we have to specify the > validation more precisely and it has to work in other scenarios than a > basic call too. Otherwise people wont use it. > > regards > Klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 24 10:28:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G51Q7-0003J1-8h; Mon, 24 Jul 2006 10:28:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G51Q6-0003HM-3X for speermint@ietf.org; Mon, 24 Jul 2006 10:28:30 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G51Q4-000605-Ou for speermint@ietf.org; Mon, 24 Jul 2006 10:28:30 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k6OESMVF028545; Mon, 24 Jul 2006 09:28:22 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 Jul 2006 09:28:22 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 Jul 2006 16:28:03 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Mon, 24 Jul 2006 16:28:03 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918013B225@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Thread-Index: AcaswMIBXGoKxNnzRXee5gSEEec6VQCSEfngAAdb8uAAAZKu8A== From: "Drage, Keith \(Keith\)" To: "Jean-Francois Mule" , "Klaus Darilion" X-OriginalArrivalTime: 24 Jul 2006 14:28:03.0718 (UTC) FILETIME=[5F7EEA60:01C6AF2D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 Inline as well. Keith=20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: 24 July 2006 14:48 > To: Drage, Keith (Keith); Klaus Darilion > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D=20 > ACTION:draft-ietf-speermint-requirements-00.t xt >=20 > Keith,=20 >=20 > See inline.=20 >=20 > Jean-Francois. >=20 > You wrote: > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Monday, July 24, 2006 4:14 AM > > To: Klaus Darilion > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] I-D=20 > ACTION:draft-ietf-speermint-requirements- > > 00.t xt > >=20 > > The issue here is not whether IMS wants to do their own thing. > >=20 > > The issue is that putting G.711 over any radio interface in=20 > a cellular=20 > > environment borders on commercial insanity for either the customer,=20 > > the operator, or both. > >=20 > > Therefore you should not be specifying G.711 as the default=20 > unless you=20 > > are also going to specify that transcoding (in the=20 > intervening sustem)=20 > > must take place to G.711 when the terminal does not support or use=20 > > such a codec, AND that some form of transcoder free=20 > operation should=20 > > also > ^^^^^^^^^^^^^^^^^^^^^ !!!!!!!!!!!!!!! ^^^^^^^^^ !!!!!! ^^^^ > > be > > supported across the peering interface. >=20 > This is where you loose me. > Are you suggesting putting a requirement (albeit at a should=20 > level) on transcoder free operation for all VoIP networks,=20 > yet not specify one or more *common* codecs?=20 > If so, are you suggesting to recommend transcoder free=20 > operations without specifying any common denominator between=20 > L5 peers (user groups, VSP, enterprises)? >=20 As soon as you put a transcoder in the path, then the offer/answer no longer works end-to-end. End-to-end offer answer will ensure that if the UAC and the UAS support a common codec they will use it. With the transcoder in the way, we do not want to end up with something that goes from codec A to codec B (as the default, or some other codec) back to codec A. Therefore I believe if you allow transcoding, you also have to require that we prevent such scenarios. > > Regards > >=20 > > Keith >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 24 11:06:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G520q-0003Pq-P0; Mon, 24 Jul 2006 11:06:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G520p-0003Pk-Ee for speermint@ietf.org; Mon, 24 Jul 2006 11:06:27 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G520n-0004Sf-KG for speermint@ietf.org; Mon, 24 Jul 2006 11:06:26 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id CC45A210092; Mon, 24 Jul 2006 17:06:24 +0200 (CEST) Message-ID: <44C4E1F4.7050706@pernau.at> Date: Mon, 24 Jul 2006 17:06:28 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt References: <5D1A7985295922448D5550C94DE2918013B011@DEEXC1U01.de.lucent.com> <44C4C471.1010503@pernau.at> <32755D354E6B65498C3BD9FD496C7D462C4B37@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B37@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Stastny Richard wrote: >> And finally they can't interconnect as A >> uses AMR and B uses G.711. > > They can, if one provides transcoding > > If we say G.711 is mandatory, it is provider A who has to provide the transcoding Thus, we have to mandate a minimum set of codecs. regards klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 24 13:23:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G549R-0001Ph-33; Mon, 24 Jul 2006 13:23:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G549P-0001Pc-U4 for speermint@ietf.org; Mon, 24 Jul 2006 13:23:27 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G549O-0005JR-KV for speermint@ietf.org; Mon, 24 Jul 2006 13:23:27 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 24 Jul 2006 10:23:26 -0700 X-IronPort-AV: i="4.07,176,1151910000"; d="scan'208"; a="570674010:sNHT29502016" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Mon, 24 Jul 2006 13:23:29 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804F94931@proton.jnpr.net> In-Reply-To: <44C4E1F4.7050706@pernau.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Thread-Index: AcavMtjSUN/IyMAXSMSP8ooNPOAI4QAEXLCA From: "Reinaldo Penno" To: "Klaus Darilion" , "Stastny Richard" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 tend to agree. One thing is to specify a behavior over a peering interface that affects only the peering devices. Another is to specify a behavior that affects possibly millions of phones (or alternatively a requirement to install many of transcoders). I cannot imagine Sprint changing all its phones to support G.711 or Comcast changing all of its phones to support some wireless codec because Speermint mandates it.=20 That leaves only three alternatives: 1) Do not specify anything in the RFCs and the peers work in out whether through some transcoding devices, or some common coder when possible. 2) Specify a minimum set (Can it be done and make everybody happy?) 3) Let offer/answer decide. I believe this might fall back into 1) since I do not believe carriers will just "wing it" when it comes to peering.=20 Regards, Reinaldo > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Monday, July 24, 2006 8:06 AM > To: Stastny Richard > Cc: speermint@ietf.org > Subject: Re: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t > xt >=20 > Stastny Richard wrote: > >> And finally they can't interconnect as A > >> uses AMR and B uses G.711. > > > > They can, if one provides transcoding > > > > If we say G.711 is mandatory, it is provider A who has to provide the > transcoding >=20 >=20 > Thus, we have to mandate a minimum set of codecs. >=20 > regards > klaus >=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 Mon Jul 24 13:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54ie-0001T4-Mu; Mon, 24 Jul 2006 13:59:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54id-0001Sg-I0 for speermint@ietf.org; Mon, 24 Jul 2006 13:59:51 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G54ib-0001Me-8B for speermint@ietf.org; Mon, 24 Jul 2006 13:59:51 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 5A3CD2100DF for ; Mon, 24 Jul 2006 19:59:48 +0200 (CEST) Message-ID: <44C50A97.3080402@pernau.at> Date: Mon, 24 Jul 2006 19:59:51 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: speermint@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Speermint] TLs performance 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 made some tests with sipp+openser: scenario: UAC <-TLS-> openser <-TLS-> UAS (all of them got its own 2xP3 1,26GHz machine, linked with 100MBit). Simple forwarding configuration (like a loadbalancer), no DNS lookups or DB queries. UDP: ~620 cps TLS: ~680 cps (single TLS connection) cps=calls per second = INVITE-180-200-OK-ACK-BYE-200 I think TLS performs better as because of UDP retransmissions, which "kills" the proxy if it becomes slow. More data when I have it. regards klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 24 14:07:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54qK-0004UJ-Eb; Mon, 24 Jul 2006 14:07:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54qI-0004UE-Sx for speermint@ietf.org; Mon, 24 Jul 2006 14:07:46 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G54qH-0002Ce-IT for speermint@ietf.org; Mon, 24 Jul 2006 14:07:46 -0400 Received: from PMelampy2 [10.0.200.104] by acmepacket.com with ESMTP (SMTPD-9.03) id AC7101EC; Mon, 24 Jul 2006 14:07:45 -0400 From: "Patrick Melampy" To: "'Drage, Keith \(Keith\)'" , "'Jean-Francois Mule'" , "'Klaus Darilion'" Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Mon, 24 Jul 2006 14:07:39 -0400 Message-ID: <003e01c6af4c$0cc46290$68c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaswMIBXGoKxNnzRXee5gSEEec6VQCSEfngAAdb8uAAAZKu8AAHt8wg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <5D1A7985295922448D5550C94DE2918013B225@DEEXC1U01.de.lucent.com> X-Spam-Score: 0.1 (/) 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 Keith, It is possible to "modify" the offer to permit otherwise impossible communication. So a middle box of some kind, could insert an additional capability into an offer. It is of course the hope that this additional capability will not be selected. If it is, then the network element that inserted the capability, must provide the transcoding capability on the fly transparently. The signaling (offer/answer) is still end-to-end. But midpoints can modify the offer if so desired to enable the communication to occur. This is by far preferred over other techniques that would "normalize" all RTP to a single common form (G.711). -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Monday, July 24, 2006 10:28 AM To: Jean-Francois Mule; Klaus Darilion Cc: speermint@ietf.org Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Inline as well. Keith > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: 24 July 2006 14:48 > To: Drage, Keith (Keith); Klaus Darilion > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D > ACTION:draft-ietf-speermint-requirements-00.t xt > > Keith, > > See inline. > > Jean-Francois. > > You wrote: > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Monday, July 24, 2006 4:14 AM > > To: Klaus Darilion > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] I-D > ACTION:draft-ietf-speermint-requirements- > > 00.t xt > > > > The issue here is not whether IMS wants to do their own thing. > > > > The issue is that putting G.711 over any radio interface in > a cellular > > environment borders on commercial insanity for either the customer, > > the operator, or both. > > > > Therefore you should not be specifying G.711 as the default > unless you > > are also going to specify that transcoding (in the > intervening sustem) > > must take place to G.711 when the terminal does not support or use > > such a codec, AND that some form of transcoder free > operation should > > also > ^^^^^^^^^^^^^^^^^^^^^ !!!!!!!!!!!!!!! ^^^^^^^^^ !!!!!! ^^^^ > > be > > supported across the peering interface. > > This is where you loose me. > Are you suggesting putting a requirement (albeit at a should > level) on transcoder free operation for all VoIP networks, > yet not specify one or more *common* codecs? > If so, are you suggesting to recommend transcoder free > operations without specifying any common denominator between > L5 peers (user groups, VSP, enterprises)? > As soon as you put a transcoder in the path, then the offer/answer no longer works end-to-end. End-to-end offer answer will ensure that if the UAC and the UAS support a common codec they will use it. With the transcoder in the way, we do not want to end up with something that goes from codec A to codec B (as the default, or some other codec) back to codec A. Therefore I believe if you allow transcoding, you also have to require that we prevent such scenarios. > > Regards > > > > Keith > > _______________________________________________ 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 Mon Jul 24 14:53:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G55Y6-0000SZ-8c; Mon, 24 Jul 2006 14:53:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G55Y5-0000ST-BE for speermint@ietf.org; Mon, 24 Jul 2006 14:53:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G52av-0006Ms-Du for speermint@ietf.org; Mon, 24 Jul 2006 11:43:45 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G52LZ-0001w6-VP for speermint@ietf.org; Mon, 24 Jul 2006 11:27:54 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id A0FB5210092; Mon, 24 Jul 2006 17:27:48 +0200 (CEST) Message-ID: <44C4E6F7.3050507@pernau.at> Date: Mon, 24 Jul 2006 17:27:51 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Brian Rosen Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted)) References: <088001c6af2b$2f6d61f0$640fa8c0@cis.neustar.com> In-Reply-To: <088001c6af2b$2f6d61f0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.0 (--) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 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 Brian Rosen wrote: > I think you are misinterpreting 3261. Section 26.3.2.2 is illustrating a > simple SIP trapezoid call where the call goes from atlanta.com to > biloxi.com. If there is another intermediary, biloxi.com would not be > checking the From to see that it matched the domain of the T proxy handling How will biloxi's proxy know if the request comes directly from atlanta or via an intermediary? You suggest that in this case the From: validation is not used. Then we should remove the From: validation completely and validate only the Identity signature. The only thing I want to say is that Rohan's suggested From: validation .... The client certificate MUST contain a DNS or URI choice type in the subjectAltName which corresponds to the domain asserted in the host production of the From header URI.... can't be mandated. > the call. We all agree that TLS is underspecified in 3261. There is some > effort to address this shortcoming underway. > > If the path is A -> T -> B, then the mutual TLS cert validation is A <-> T > and T <-> B. In a peering system, the peers authenticate each other within Yes. > the peering regime. If T accepts a call from A destined for B, then it > authenticates A as a peer which it accepts transit calls for B, and it > authenticates B as a peer with whom it can send calls destined for B. Yes - but the L5 domain validation can't be used. Maybe I express myself a little bit unclear. Thus, I describe it more detailed. When using SSL/TLS to secure a transport connection, there are several validation steps. Some of the are done in the SSL stack, some of the are done in the application. I'm speaking of experience in using openssl and openser. During the TLS handshake, the peers verify the certificate presented by the other peer. The TLS stacks of the certificate is signed by a (to the stack) well known CA and it is valid (not expired). Let's call this L4 certificate validation. Once the TLS connection is setup, the application can further validate the certificate, e.g. if the domain presented in the certificate equals the domain in the request URI. Let's call this L5 certificate validation. To authenticate a peer, L5 is NOT necessary. For example, T and B are in the same federation. (B trusts T, T trusts B, and both of them trusts the federation's CA) If B receives a call from T, which is originally from an other service provider (which T trusts), the domain in the From header is not important, as the authentication is based on the certificate. And B and T can bill each other because they were both authenticated (although there was no L5 validation). Conclusion: IMO TLS should be MUST, but the L5 domain validation (as suggested in RFC3261 and Rohan's draft) must be removed as it does not work in many scenarios and further is not needed. Nevertheless, in scenarios where it is useful it should be used. But a MUST is wrong. regards Klaus > > Brian > >> -----Original Message----- >> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >> Sent: Sunday, July 23, 2006 7:49 PM >> To: Brian Rosen >> Cc: speermint@ietf.org >> Subject: RE: TLS for peering (was RE: Comments >> (RE:[speermint]requirementsdraftsubmitted)) >> >> Hi Brian! >> >> On Fri, July 21, 2006 18:08, Brian Rosen said: >>> I believe it is the case that the link from one peer to another, which >> is >>> generally between two proxies, can very reasonably be protected with >> TLS, >>> with many current implementations, and with reasonable assumptions about >>> PKI. Specifically, if one of the parts of a federation was an agreement >>> on >>> a CA, then each peer can have a certificate that other peers can verify. >>> I >>> believe all operations, including forwarding, if they work at all across >>> the >>> peering system would work if it was TLS protected. >> Using TLS for encryption and TLS certificate validation works - but the L5 >> validation (validate the certificate domain names against the domains in >> the SIP headers) does not work without mandating a B2BUA. >> >> TLS/SSL was invented for a very simple client-server system - HTTP. Let's >> compare HTTP with SIP: >> >> HTTP: >> 1 request - 1 (or more) responses. >> L5 validation: verify domain in browser's location bar against the domain >> in the server certificate - this is straight forward >> >> SIP: >> Multiple - bidirectional requests >> L5 validation: There are several headers which are used for routing and >> thus can be used for validation: requestURI, From, To, Via, Route, >> Contact. >> We can have in-dialog requests which are initiated in reverse direction of >> the original dialog setup. And each of this domain resolves to several >> domains (due to NAPTR, SRV, A resolution). This alone should have people >> think a little more before defining TLS for SIP. >> >> I am a fan of forwarding - and probably every transit service provider >> too. As transit will happen I will use the transit scenario (simple >> forwarding without a B2BUA) to show that L5 validation is broken - and I >> would be very very happy if someone can show that I'm wrong. >> >> A want to call B. There is no direct peering agreement. Thus A sends the >> call to it's transit provider T. (only the signaling between the proxies >> is shown) >> >> A->T >> INVITE sip:B@B >> From: sip:A@A >> To: sip:B@B >> Contact: user@phone >> Record-Route: sip:A >> >> Cert validation according to RFC3261 section 26.3.2.2: >> T will show a TLS certificate for T (not for B) - thus, when A validates >> T's certificate, the validation will fail. IMO this can be fixed by adding >> a Route: header with sip:T, but this is nowhere mentioned in RFC 3261. >> >> T->B >> INVITE sip:B@B >> From: sip:A@A >> To: sip:B@B >> Contact: user@phone >> Record-Route: sip:T >> Record-Route: sip:A >> >> Cert validation according to RFC3261 section 26.3.2.2: >> B should validate the domain in the From header (A) aginst the domain in >> the client's certificate (T) --> it will fail. >> >> Now let's assume the previous validation have succeeded and B sends a BYE >> request to A, and the TLS connection was dropped and must be >> re-established: >> >> B->T >> BYE name@1.2.3.4 >> From: sip:B@B >> To: sip:A@A >> Route: sip:T >> Route: sip:A >> >> How should T's certificate be validated? Probably against the domain in >> the topmost Route header - but again: This is nowhere specified. >> >> T->A >> BYE name@1.2.3.4 >> From: sip:B@B >> To: sip:A@A >> Route: sip:A >> >> Again, probably T should use the domain in the Route header for >> certificate validation. But A can't validate the certificate's domain (T) >> against the From header (B) - it will fail. >> >> Similar problem arise in a forwarding scenario - A-->B which forwards it's >> call to C. The suggested L5 validation will fail (except B uses a B2BUA, >> and IMO a B2BUA should not be mandatory). >> >>> This does not assume sips works (whatever that means), and does not >> assume >>> endpoints implement TLS, or either the originating or terminating >> domains >>> deploy TLS anywhere else. >>> >>> It does provide a reasonable degree of protection across the peering >>> point, >>> which I think is a good thing. >> Yes, TLS provides protection, but we should not specify a broken L5 >> certificate validation. >> >>> Having lived with protocols that offered options like IPsec and VPNs and >>> other mechanisms, I think that despite the fact that you can, in theory, >>> create a satisfactory security arrangement, it is exceedingly hard to >> make >>> it actually work except for cases where there is an entity that >> completely >>> controls all aspects of the peering. That just isn't the case for what >> I >>> think we are trying to specify here (such cases don't need IETF >>> standardization). Thus, I personally think mandating TLS is a good >> thing, >>> achievable, and reasonable. That's a MUST IMPLEMENT, not a must deploy; >> Yes, I agree. I want TLS in the specs too - but we have to specify the >> validation more precisely and it has to work in other scenarios than a >> basic call too. Otherwise people wont use it. >> >> regards >> Klaus > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 24 15:20:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G55yX-0005PF-Pp; Mon, 24 Jul 2006 15:20:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G55yV-0005Gf-Nv for speermint@ietf.org; Mon, 24 Jul 2006 15:20:19 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G55yT-0002NM-F1 for speermint@ietf.org; Mon, 24 Jul 2006 15:20:19 -0400 Received: from ([10.20.62.13]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.22660968; Mon, 24 Jul 2006 15:19:59 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 15:19:59 -0400 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] [wg-business] speermint Interim #1: Sept 18 - 19, Philadelphia (Plus TWO Requests) Date: Mon, 24 Jul 2006 15:19:57 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD1A608F@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business] speermint Interim #1: Sept 18 - 19, Philadelphia (Plus TWO Requests) Thread-Index: Acaqlm4bKkTqwW+2Q0eBZNsw4q8PPAEvLCTA From: "Livingood, Jason" To: X-OriginalArrivalTime: 24 Jul 2006 19:19:59.0059 (UTC) FILETIME=[2773DA30:01C6AF56] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 We secured the meeting location today. We selected a corporate meeting center, rather than a hotel conference room as their technology services were far superior and the prices for such services were more reasonable. The location has a GigE connection (fractionally provisioned) to the Internet that can be turned up for more bandwidth as needed. We'll have wired Ethernet for each attendee as well as WiFi to use as needed. We'll have an LCD projector and whiteboards, plus a PolyCom phone system to dial up a conference bridge for remote attendees. We will announce the hotel options / discounts within the next day or so, as well as other travel / logistical details. Meeting Location: =20 The Hub - CityView Location, in the Keystone Room United Plaza Building=20 30 South 17th Street 14th Floor Philadelphia, PA 19103 Directions: http://www.thehub.com/maps.php=20 Map: http://maps.google.com/maps?f=3Dq&hl=3Den&q=3D30+S+17th+St,+19103&ie=3DUT= F8&ll=3D3 9.951448,-75.168028&spn=3D0.007238,0.021286&om=3D1=20 Regards Jason PS - Current attendee list is as follows: Chris Celiberti Tom Creighton Geoff Devine Martin Dolly Michael Haberler Avshalom Houri Hadrien Kaplan Sohel Khan Guarav Khandpur Yiu Lee Alex Leung Gene Lew Jason Livingood Daryl Malas Jim McEachern Patrick Melampy Dave Meyer Andy Newton Bob Penfield Reinaldo Penno Penn Pfautz Brian Rosen David Schwartz Richard Stastny Hannes Tschofenig Adam Uzelac > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Tuesday, July 18, 2006 2:17 PM > To: speermint@ietf.org > Subject: [Speermint] [wg-business] speermint Interim #1: Sept=20 > 18 - 19,Philadelphia (Plus TWO Requests) > Importance: High >=20 > Okay -- so our discussions regarding an interim meeting are=20 > progressing. > The tentative dates are Monday and Tuesday, September 18 and 19, 2006. > This is the week after VON in Boston. The interim meeting=20 > would tentatively be held in Philadelphia, which is not=20 > terribly far from Boston. =20 >=20 > Discounted hotel room rates, with complimentary Internet=20 > access, would be made available. Attendees would only incur=20 > costs of travel to the meeting, plus lunch and dinner each=20 > day; there would be no fee to attend the meeting itself. The=20 > conference room will have whiteboards / drawing boards, an=20 > LCD projector, and Internet access. >=20 > REQUEST #1: I have attached a proposed agenda and am=20 > requesting comments on this from the WG. =20 >=20 > That agenda also contains the following meeting objective: =20 > To have detailed debate and discussion of open issues for=20 > current WG drafts and move ahead work items more quickly than=20 > we can by having a 2 hour meeting every 4 months at the main=20 > IETF meetings. Also, kick-off new WG items in detail and=20 > make rapid progress towards achieving WG milestones. >=20 >=20 > REQUEST #2: I would also like to request a show of hands so=20 > we know how big a conference room to book. Please email me=20 > PRIVATELY at jason_livingood@cable.comcast.com if you would=20 > attend this meeting. >=20 > Thanks! > Jason >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 24 16:19:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G56tX-0001Hr-17; Mon, 24 Jul 2006 16:19:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G56tV-0001Hl-Ia for speermint@ietf.org; Mon, 24 Jul 2006 16:19:13 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G56tT-0007de-1a for speermint@ietf.org; Mon, 24 Jul 2006 16:19:13 -0400 Received: from pb94.dyndns.org (localhost [127.0.0.1]) by pb94.dyndns.org (Postfix) with ESMTP id D8E82210028; Mon, 24 Jul 2006 22:19:09 +0200 (CEST) Received: from 212.17.67.197 (SquirrelMail authenticated user klaus.mailinglists@pernau.at) by pb94.dyndns.org with HTTP; Mon, 24 Jul 2006 22:19:09 +0200 (CEST) Message-ID: <61838.212.17.67.197.1153772349.squirrel@pb94.dyndns.org> In-Reply-To: <003e01c6af4c$0cc46290$68c8000a@acmepacket.com> References: <5D1A7985295922448D5550C94DE2918013B225@DEEXC1U01.de.lucent.com> <003e01c6af4c$0cc46290$68c8000a@acmepacket.com> Date: Mon, 24 Jul 2006 22:19:09 +0200 (CEST) Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt From: "Klaus Darilion" To: "Patrick Melampy" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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 Mon, July 24, 2006 20:07, Patrick Melampy said: > Keith, > > It is possible to "modify" the offer to permit otherwise impossible > communication. So a middle box of some kind, could insert an additional > capability into an offer. It is of course the hope that this additional > capability will not be selected. If it is, then the network element tha= t > inserted the capability, must provide the transcoding capability on the > fly > transparently. Yes, this is possible, but with the drawback, that either: - you have to enforce that the media is sent to an RTP proxy (and perform= s transcoding if necessary) as the SDP in the offer contains the socket where to send the RTP stream - or you have to generate re-INVITEs to change the media sockets to the transcoder when transcoding is needed (requires a B2BUA). This is complicated. > The signaling (offer/answer) is still end-to-end. But midpoints can mod= ify > the offer if so desired to enable the communication to occur. > > This is by far preferred over other techniques that would "normalize" a= ll > RTP to a single common form (G.711). The normalization is only needed if the terminals do not support G.711. I= f the terminal is a SIP phone, usually G.711 is supported. If the terminal is a PSTN phone, usualy G.711 is used. If the terminal is a mobile phone (usually GSM or AMR), and it want's to peer with non mobile providers, it either: - ensures that the other peer supports AMR/GSM too - or it transcodes. Every mobile operator has transcoders for PSTN interconnect. regards klaus > > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Monday, July 24, 2006 10:28 AM > To: Jean-Francois Mule; Klaus Darilion > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-0= 0.t > xt > > Inline as well. > > Keith > >> -----Original Message----- >> From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] >> Sent: 24 July 2006 14:48 >> To: Drage, Keith (Keith); Klaus Darilion >> Cc: speermint@ietf.org >> Subject: RE: [Speermint] I-D >> ACTION:draft-ietf-speermint-requirements-00.t xt >> >> Keith, >> >> See inline. >> >> Jean-Francois. >> >> You wrote: >> > -----Original Message----- >> > From: Drage, Keith (Keith) [mailto:drage@lucent.com] >> > Sent: Monday, July 24, 2006 4:14 AM >> > To: Klaus Darilion >> > Cc: speermint@ietf.org >> > Subject: RE: [Speermint] I-D >> ACTION:draft-ietf-speermint-requirements- >> > 00.t xt >> > >> > The issue here is not whether IMS wants to do their own thing. >> > >> > The issue is that putting G.711 over any radio interface in >> a cellular >> > environment borders on commercial insanity for either the customer, >> > the operator, or both. >> > >> > Therefore you should not be specifying G.711 as the default >> unless you >> > are also going to specify that transcoding (in the >> intervening sustem) >> > must take place to G.711 when the terminal does not support or use >> > such a codec, AND that some form of transcoder free >> operation should >> > also >> ^^^^^^^^^^^^^^^^^^^^^ !!!!!!!!!!!!!!! ^^^^^^^^^ !!!!!! ^^^^ >> > be >> > supported across the peering interface. >> >> This is where you loose me. >> Are you suggesting putting a requirement (albeit at a should >> level) on transcoder free operation for all VoIP networks, >> yet not specify one or more *common* codecs? >> If so, are you suggesting to recommend transcoder free >> operations without specifying any common denominator between >> L5 peers (user groups, VSP, enterprises)? >> > As soon as you put a transcoder in the path, then the offer/answer no > longer works end-to-end. End-to-end offer answer will ensure that if th= e > UAC and the UAS support a common codec they will use it. With the > transcoder in the way, we do not want to end up with something that goe= s > from codec A to codec B (as the default, or some other codec) back to > codec A. Therefore I believe if you allow transcoding, you also have to > require that we prevent such scenarios. > > > >> > Regards >> > >> > Keith >> >> > > _______________________________________________ > 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 Mon Jul 24 17:25:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G57vJ-0003gM-NX; Mon, 24 Jul 2006 17:25:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G57vH-0003gF-So for speermint@ietf.org; Mon, 24 Jul 2006 17:25:07 -0400 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G57vG-0000x5-FB for speermint@ietf.org; Mon, 24 Jul 2006 17:25:07 -0400 Received: from source ([192.150.11.134]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Mon, 24 Jul 2006 14:24:24 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k6OJrGBl004383; Mon, 24 Jul 2006 12:53:16 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k6OJskR8018216; Mon, 24 Jul 2006 12:54:59 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 12:54:50 -0700 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] TLs performance Date: Mon, 24 Jul 2006 12:54:50 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D2206C463@namail5.corp.adobe.com> In-Reply-To: <44C50A97.3080402@pernau.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLs performance Thread-Index: AcavSv8M5NbfXwDJT6atWyXDCiHPBgADuDqw From: "Henry Sinnreich" To: "Klaus Darilion" , X-OriginalArrivalTime: 24 Jul 2006 19:54:50.0819 (UTC) FILETIME=[063D1930:01C6AF5B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Hi Klaus, This is a good beginning, but you may want to include the 2-3 DNS lookups from the originating UAC and the additional 3-4 DNS lookups for ENUM, NAPTR, etc. Can you add such a test? Thanks, Henry -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 Sent: Monday, July 24, 2006 1:00 PM To: speermint@ietf.org Subject: [Speermint] TLs performance Hi! I made some tests with sipp+openser: scenario: UAC <-TLS-> openser <-TLS-> UAS (all of them got its own 2xP3 1,26GHz=20 machine, linked with 100MBit). Simple forwarding configuration (like a=20 loadbalancer), no DNS lookups or DB queries. UDP: ~620 cps TLS: ~680 cps (single TLS connection) cps=3Dcalls per second =3D INVITE-180-200-OK-ACK-BYE-200 I think TLS performs better as because of UDP retransmissions, which=20 "kills" the proxy if it becomes slow. More data when I have it. regards klaus _______________________________________________ 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 Mon Jul 24 18:05:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G58Y6-0006UW-DJ; Mon, 24 Jul 2006 18:05:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G58Y4-0006U5-Rd for speermint@ietf.org; Mon, 24 Jul 2006 18:05:12 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G58Y2-0005rw-ET for speermint@ietf.org; Mon, 24 Jul 2006 18:05:12 -0400 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] [wg-business] speermint Interim #1: Sept 18 - 19, Philadelphia (Plus TWO Requests) Date: Mon, 24 Jul 2006 18:04:58 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD1A609F@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business] speermint Interim #1: Sept 18 - 19, Philadelphia (Plus TWO Requests) Thread-Index: Acaqlm4bKkTqwW+2Q0eBZNsw4q8PPAEvLCTAAAZkVQA= From: "Livingood, Jason" To: X-OriginalArrivalTime: 24 Jul 2006 22:04:58.0300 (UTC) FILETIME=[33DC27C0:01C6AF6D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c 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 We have finalized the hotel and have arranged a special rate at the Sofitel Philadelphia. * You must contact the hotel *directly* to use these special rates. * You must inform the hotel that you are coming to a Comcast-sponsored meeting and are requesting the Comcast rate. -> Special Room Rate =3D US$175 -> Special Suite Rate =3D US$215 * Please contact Mrs. Aida Sparta if you have ANY difficulty making reservations or need related assistance. She's at Aida_Sparta@cable.comcast.com or +1-215-981-7500. Sofitel Philadelphia 120 South 17th Street http://www.sofitel.com/sofitel/fichehotel/gb/sof/2741/fiche_hotel.shtml Phone 1-215-569-8300=20 The hotel is a very short 1 block walk from the meeting location. Regards, Jason > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Monday, July 24, 2006 3:20 PM > To: speermint@ietf.org > Subject: RE: [Speermint] [wg-business] speermint Interim #1:=20 > Sept 18 - 19,Philadelphia (Plus TWO Requests) >=20 > We secured the meeting location today. We selected a=20 > corporate meeting center, rather than a hotel conference room=20 > as their technology services were far superior and the prices=20 > for such services were more reasonable. > The location has a GigE connection (fractionally provisioned)=20 > to the Internet that can be turned up for more bandwidth as=20 > needed. We'll have wired Ethernet for each attendee as well=20 > as WiFi to use as needed. > We'll have an LCD projector and whiteboards, plus a PolyCom=20 > phone system to dial up a conference bridge for remote attendees. >=20 > We will announce the hotel options / discounts within the=20 > next day or so, as well as other travel / logistical details. >=20 > Meeting Location: =20 > The Hub - CityView Location, in the Keystone Room United=20 > Plaza Building 30 South 17th Street 14th Floor Philadelphia, PA 19103 >=20 > Directions: http://www.thehub.com/maps.php=20 >=20 > Map: > http://maps.google.com/maps?f=3Dq&hl=3Den&q=3D30+S+17th+St,+19103&ie > =3DUTF8&ll=3D3 > 9.951448,-75.168028&spn=3D0.007238,0.021286&om=3D1=20 >=20 > Regards > Jason >=20 > PS - Current attendee list is as follows: > Chris Celiberti > Tom Creighton > Geoff Devine > Martin Dolly > Michael Haberler > Avshalom Houri > Hadrien Kaplan > Sohel Khan > Guarav Khandpur > Yiu Lee > Alex Leung > Gene Lew > Jason Livingood > Daryl Malas > Jim McEachern > Patrick Melampy > Dave Meyer > Andy Newton > Bob Penfield > Reinaldo Penno > Penn Pfautz > Brian Rosen > David Schwartz > Richard Stastny > Hannes Tschofenig > Adam Uzelac >=20 > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Tuesday, July 18, 2006 2:17 PM > > To: speermint@ietf.org > > Subject: [Speermint] [wg-business] speermint Interim #1: Sept > > 18 - 19,Philadelphia (Plus TWO Requests) > > Importance: High > >=20 > > Okay -- so our discussions regarding an interim meeting are=20 > > progressing. > > The tentative dates are Monday and Tuesday, September 18=20 > and 19, 2006. > > This is the week after VON in Boston. The interim meeting would=20 > > tentatively be held in Philadelphia, which is not terribly far from=20 > > Boston. > >=20 > > Discounted hotel room rates, with complimentary Internet=20 > access, would=20 > > be made available. Attendees would only incur costs of=20 > travel to the=20 > > meeting, plus lunch and dinner each day; there would be no fee to=20 > > attend the meeting itself. The conference room will have=20 > whiteboards=20 > > / drawing boards, an LCD projector, and Internet access. > >=20 > > REQUEST #1: I have attached a proposed agenda and am requesting=20 > > comments on this from the WG. > >=20 > > That agenda also contains the following meeting objective: =20 > > To have detailed debate and discussion of open issues for=20 > current WG=20 > > drafts and move ahead work items more quickly than we can=20 > by having a=20 > > 2 hour meeting every 4 months at the main IETF meetings. Also,=20 > > kick-off new WG items in detail and make rapid progress towards=20 > > achieving WG milestones. > >=20 > >=20 > > REQUEST #2: I would also like to request a show of hands so we know=20 > > how big a conference room to book. Please email me PRIVATELY at=20 > > jason_livingood@cable.comcast.com if you would attend this meeting. > >=20 > > Thanks! > > Jason > >=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 Mon Jul 24 18:49:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G59Et-00023C-91; Mon, 24 Jul 2006 18:49:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G59Es-000232-7F for speermint@ietf.org; Mon, 24 Jul 2006 18:49:26 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G59Eq-0002g1-QL for speermint@ietf.org; Mon, 24 Jul 2006 18:49:26 -0400 Received: from ([10.52.116.10]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.22563582; Mon, 24 Jul 2006 18:48:53 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 18:48:53 -0400 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] [wg-business] speermint Interim #1: Sept 18 - 19, Philadelphia (Plus TWO Requests) Date: Mon, 24 Jul 2006 18:48:53 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD1A60A6@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business] speermint Interim #1: Sept 18 - 19, Philadelphia (Plus TWO Requests) Thread-Index: Acaqlm4bKkTqwW+2Q0eBZNsw4q8PPAEvLCTAAAZkVQAAAZITsA== From: "Livingood, Jason" To: X-OriginalArrivalTime: 24 Jul 2006 22:48:53.0590 (UTC) FILETIME=[569D7F60:01C6AF73] X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff 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 an FYI, here are some hotel alternatives as I've been told that if you arrive on Sunday the Sofitel may only have suites remaining (at $215/night, still not terrible by big city standards). For those of you who know Philadelphia, these are east of City Hall and our meeting is just west of City Hall. =20 =20 Courtyard by Marriott 21 N. Juniper Street at City Hall http://marriott.com/property/propertyPage/phldc Phone 1-215-496-3200 Regular room =3D $109 per night*=20 Loews Hotel 1200 Market Street http://www.loewshotels.com/hotels/philadelphia/default.asp Phone 1-215-627-1200 Regular room =3D $109 per night* =20 =20 Jason * As with the other rates you must also mention you are coming for a special Comcast-sponsored meeting and would like the Comcast rate. You may have to give them my name & phone for verification (or Aida Sparta's). Please advise if you have any difficulties. > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Monday, July 24, 2006 6:05 PM > To: speermint@ietf.org > Subject: RE: [Speermint] [wg-business] speermint Interim #1:=20 > Sept 18 - 19,Philadelphia (Plus TWO Requests) >=20 > We have finalized the hotel and have arranged a special rate=20 > at the Sofitel Philadelphia. >=20 > * You must contact the hotel *directly* to use these special rates. > * You must inform the hotel that you are coming to a=20 > Comcast-sponsored meeting and are requesting the Comcast rate. > -> Special Room Rate =3D US$175 > -> Special Suite Rate =3D US$215 > * Please contact Mrs. Aida Sparta if you have ANY difficulty=20 > making reservations or need related assistance. She's at=20 > Aida_Sparta@cable.comcast.com or +1-215-981-7500. >=20 > Sofitel Philadelphia > 120 South 17th Street > http://www.sofitel.com/sofitel/fichehotel/gb/sof/2741/fiche_ho > tel.shtml > Phone 1-215-569-8300=20 >=20 > The hotel is a very short 1 block walk from the meeting location. >=20 > Regards, > Jason >=20 > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Monday, July 24, 2006 3:20 PM > > To: speermint@ietf.org > > Subject: RE: [Speermint] [wg-business] speermint Interim #1:=20 > > Sept 18 - 19,Philadelphia (Plus TWO Requests) > >=20 > > We secured the meeting location today. We selected a corporate=20 > > meeting center, rather than a hotel conference room as their=20 > > technology services were far superior and the prices for=20 > such services=20 > > were more reasonable. > > The location has a GigE connection (fractionally=20 > provisioned) to the=20 > > Internet that can be turned up for more bandwidth as needed. We'll=20 > > have wired Ethernet for each attendee as well as WiFi to use as=20 > > needed. > > We'll have an LCD projector and whiteboards, plus a PolyCom phone=20 > > system to dial up a conference bridge for remote attendees. > >=20 > > We will announce the hotel options / discounts within the=20 > next day or=20 > > so, as well as other travel / logistical details. > >=20 > > Meeting Location: =20 > > The Hub - CityView Location, in the Keystone Room United Plaza=20 > > Building 30 South 17th Street 14th Floor Philadelphia, PA 19103 > >=20 > > Directions: http://www.thehub.com/maps.php > >=20 > > Map: > > http://maps.google.com/maps?f=3Dq&hl=3Den&q=3D30+S+17th+St,+19103&ie > > =3DUTF8&ll=3D3 > > 9.951448,-75.168028&spn=3D0.007238,0.021286&om=3D1 > >=20 > > Regards > > Jason > >=20 > > PS - Current attendee list is as follows: > > Chris Celiberti > > Tom Creighton > > Geoff Devine > > Martin Dolly > > Michael Haberler > > Avshalom Houri > > Hadrien Kaplan > > Sohel Khan > > Guarav Khandpur > > Yiu Lee > > Alex Leung > > Gene Lew > > Jason Livingood > > Daryl Malas > > Jim McEachern > > Patrick Melampy > > Dave Meyer > > Andy Newton > > Bob Penfield > > Reinaldo Penno > > Penn Pfautz > > Brian Rosen > > David Schwartz > > Richard Stastny > > Hannes Tschofenig > > Adam Uzelac > >=20 > > > -----Original Message----- > > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Sent: Tuesday, July 18, 2006 2:17 PM > > > To: speermint@ietf.org > > > Subject: [Speermint] [wg-business] speermint Interim #1: Sept > > > 18 - 19,Philadelphia (Plus TWO Requests) > > > Importance: High > > >=20 > > > Okay -- so our discussions regarding an interim meeting are=20 > > > progressing. > > > The tentative dates are Monday and Tuesday, September 18 > > and 19, 2006. > > > This is the week after VON in Boston. The interim meeting would=20 > > > tentatively be held in Philadelphia, which is not=20 > terribly far from=20 > > > Boston. > > >=20 > > > Discounted hotel room rates, with complimentary Internet > > access, would > > > be made available. Attendees would only incur costs of > > travel to the > > > meeting, plus lunch and dinner each day; there would be no fee to=20 > > > attend the meeting itself. The conference room will have > > whiteboards > > > / drawing boards, an LCD projector, and Internet access. > > >=20 > > > REQUEST #1: I have attached a proposed agenda and am requesting=20 > > > comments on this from the WG. > > >=20 > > > That agenda also contains the following meeting objective: =20 > > > To have detailed debate and discussion of open issues for > > current WG > > > drafts and move ahead work items more quickly than we can > > by having a > > > 2 hour meeting every 4 months at the main IETF meetings. Also,=20 > > > kick-off new WG items in detail and make rapid progress towards=20 > > > achieving WG milestones. > > >=20 > > >=20 > > > REQUEST #2: I would also like to request a show of hands=20 > so we know=20 > > > how big a conference room to book. Please email me PRIVATELY at=20 > > > jason_livingood@cable.comcast.com if you would attend=20 > this meeting. > > >=20 > > > Thanks! > > > Jason > > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=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 Tue Jul 25 05:08:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Itc-0001Il-KP; Tue, 25 Jul 2006 05:08:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Itb-0001If-DG for speermint@ietf.org; Tue, 25 Jul 2006 05:08:07 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ItY-0007E1-VH for speermint@ietf.org; Tue, 25 Jul 2006 05:08:07 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k6P97uCH017433; Tue, 25 Jul 2006 04:07:56 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Jul 2006 04:07:55 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Jul 2006 11:07:52 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Tue, 25 Jul 2006 11:07:52 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918013B431@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Thread-Index: AcaswMIBXGoKxNnzRXee5gSEEec6VQCSEfngAAdb8uAAAZKu8AAHt8wgAB1oQYA= From: "Drage, Keith \(Keith\)" To: "Patrick Melampy" , "Jean-Francois Mule" , "Klaus Darilion" X-OriginalArrivalTime: 25 Jul 2006 09:07:52.0958 (UTC) FILETIME=[CF6751E0:01C6AFC9] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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 The architecture you describe is a B2BUA with media. While you may try and design this as transparently as possible, it still exists from the start of the dialog, unless you REFER it in, and is end to middlebox, middlebox to end. A SIP proxy cannot suddenly decide mid dialog to become a B2BUA. The SIP/SIPPING working groups do have a number of RFCs and drafts relating to transcoding, and how they are provided. Regards Keith=20 > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com]=20 > Sent: 24 July 2006 19:08 > To: Drage, Keith (Keith); 'Jean-Francois Mule'; 'Klaus Darilion' > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D=20 > ACTION:draft-ietf-speermint-requirements-00.t xt >=20 > Keith, >=20 > It is possible to "modify" the offer to permit otherwise=20 > impossible communication. So a middle box of some kind, could=20 > insert an additional capability into an offer. It is of=20 > course the hope that this additional capability will not be=20 > selected. If it is, then the network element that inserted=20 > the capability, must provide the transcoding capability on=20 > the fly transparently. >=20 > The signaling (offer/answer) is still end-to-end. But=20 > midpoints can modify the offer if so desired to enable the=20 > communication to occur. >=20 > This is by far preferred over other techniques that would=20 > "normalize" all RTP to a single common form (G.711). >=20 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Monday, July 24, 2006 10:28 AM > To: Jean-Francois Mule; Klaus Darilion > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D=20 > ACTION:draft-ietf-speermint-requirements-00.t > xt >=20 > Inline as well. >=20 > Keith=20 >=20 > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > Sent: 24 July 2006 14:48 > > To: Drage, Keith (Keith); Klaus Darilion > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] I-D > > ACTION:draft-ietf-speermint-requirements-00.t xt > >=20 > > Keith, > >=20 > > See inline.=20 > >=20 > > Jean-Francois. > >=20 > > You wrote: > > > -----Original Message----- > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > Sent: Monday, July 24, 2006 4:14 AM > > > To: Klaus Darilion > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] I-D > > ACTION:draft-ietf-speermint-requirements- > > > 00.t xt > > >=20 > > > The issue here is not whether IMS wants to do their own thing. > > >=20 > > > The issue is that putting G.711 over any radio interface in > > a cellular > > > environment borders on commercial insanity for either the=20 > customer,=20 > > > the operator, or both. > > >=20 > > > Therefore you should not be specifying G.711 as the default > > unless you > > > are also going to specify that transcoding (in the > > intervening sustem) > > > must take place to G.711 when the terminal does not=20 > support or use=20 > > > such a codec, AND that some form of transcoder free > > operation should > > > also > > ^^^^^^^^^^^^^^^^^^^^^ !!!!!!!!!!!!!!! ^^^^^^^^^=20 > !!!!!! ^^^^ > > > be > > > supported across the peering interface. > >=20 > > This is where you loose me. > > Are you suggesting putting a requirement (albeit at a should > > level) on transcoder free operation for all VoIP networks, yet not=20 > > specify one or more *common* codecs? > > If so, are you suggesting to recommend transcoder free operations=20 > > without specifying any common denominator between > > L5 peers (user groups, VSP, enterprises)? > >=20 > As soon as you put a transcoder in the path, then the=20 > offer/answer no longer works end-to-end. End-to-end offer=20 > answer will ensure that if the UAC and the UAS support a=20 > common codec they will use it. With the transcoder in the=20 > way, we do not want to end up with something that goes from=20 > codec A to codec B (as the default, or some other codec) back=20 > to codec A. Therefore I believe if you allow transcoding, you=20 > also have to require that we prevent such scenarios. >=20 > >=20 > > > Regards > > >=20 > > > Keith > >=20 > >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 25 13:28:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Qht-0000ut-48; Tue, 25 Jul 2006 13:28:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Qhr-0000uo-FV for speermint@ietf.org; Tue, 25 Jul 2006 13:28:31 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Qhr-0002WZ-1Q for speermint@ietf.org; Tue, 25 Jul 2006 13:28:31 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k6PHSTnX010783 for ; Tue, 25 Jul 2006 12:28:29 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Jul 2006 12:28:29 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Jul 2006 19:28:27 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Tue, 25 Jul 2006 19:28:26 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918013B742@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Thread-Index: AcaswMIBXGoKxNnzRXee5gSEEec6VQCSEfngAAdb8uAAAZKu8AAHt8wgAB1oQYAAC5dlQAAIAGNQ From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 25 Jul 2006 17:28:27.0833 (UTC) FILETIME=[BD958A90:01C6B00F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 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 Published or WG work in progress http://www.ietf.org/rfc/rfc4117.txt http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-framework- 04.txt http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-conf-03.tx t Author draft not yet discussed as follows: http://www.ietf.org/internet-drafts/draft-kang-sipping-transc-scenario-0 1.txt=20 Regards Keith=20 > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: 25 July 2006 14:40 > To: Drage, Keith (Keith) > Subject: RE: [Speermint] I-D=20 > ACTION:draft-ietf-speermint-requirements-00.t xt >=20 > Can you email the list some of the pertinent RFCs or I-Ds=20 > related to transcoding? That way folks can read them and get=20 > familiar with them. >=20 > Thx > Jason=20 >=20 > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Tuesday, July 25, 2006 5:08 AM > > To: Patrick Melampy; Jean-Francois Mule; Klaus Darilion > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] I-D > > ACTION:draft-ietf-speermint-requirements-00.t xt > >=20 > > The architecture you describe is a B2BUA with media. While=20 > you may try=20 > > and design this as transparently as possible, it still=20 > exists from the=20 > > start of the dialog, unless you REFER it in, and is end to=20 > middlebox,=20 > > middlebox to end. A SIP proxy cannot suddenly decide mid dialog to=20 > > become a B2BUA. > >=20 > > The SIP/SIPPING working groups do have a number of RFCs and drafts=20 > > relating to transcoding, and how they are provided. > >=20 > > Regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > Sent: 24 July 2006 19:08 > > > To: Drage, Keith (Keith); 'Jean-Francois Mule'; 'Klaus Darilion' > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] I-D > > > ACTION:draft-ietf-speermint-requirements-00.t xt > > >=20 > > > Keith, > > >=20 > > > It is possible to "modify" the offer to permit otherwise=20 > impossible=20 > > > communication. So a middle box of some kind, could insert an=20 > > > additional capability into an offer. It is of course the=20 > hope that=20 > > > this additional capability will not be selected. If it=20 > is, then the=20 > > > network element that inserted the capability, must provide the=20 > > > transcoding capability on the fly transparently. > > >=20 > > > The signaling (offer/answer) is still end-to-end. But=20 > midpoints can=20 > > > modify the offer if so desired to enable the=20 > communication to occur. > > >=20 > > > This is by far preferred over other techniques that would > > "normalize"=20 > > > all RTP to a single common form (G.711). > > >=20 > > > -----Original Message----- > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > Sent: Monday, July 24, 2006 10:28 AM > > > To: Jean-Francois Mule; Klaus Darilion > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] I-D > > > ACTION:draft-ietf-speermint-requirements-00.t > > > xt > > >=20 > > > Inline as well. > > >=20 > > > Keith > > >=20 > > > > -----Original Message----- > > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > > Sent: 24 July 2006 14:48 > > > > To: Drage, Keith (Keith); Klaus Darilion > > > > Cc: speermint@ietf.org > > > > Subject: RE: [Speermint] I-D > > > > ACTION:draft-ietf-speermint-requirements-00.t xt > > > >=20 > > > > Keith, > > > >=20 > > > > See inline.=20 > > > >=20 > > > > Jean-Francois. > > > >=20 > > > > You wrote: > > > > > -----Original Message----- > > > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > > > Sent: Monday, July 24, 2006 4:14 AM > > > > > To: Klaus Darilion > > > > > Cc: speermint@ietf.org > > > > > Subject: RE: [Speermint] I-D > > > > ACTION:draft-ietf-speermint-requirements- > > > > > 00.t xt > > > > >=20 > > > > > The issue here is not whether IMS wants to do their own thing. > > > > >=20 > > > > > The issue is that putting G.711 over any radio interface in > > > > a cellular > > > > > environment borders on commercial insanity for either the > > > customer, > > > > > the operator, or both. > > > > >=20 > > > > > Therefore you should not be specifying G.711 as the default > > > > unless you > > > > > are also going to specify that transcoding (in the > > > > intervening sustem) > > > > > must take place to G.711 when the terminal does not > > > support or use > > > > > such a codec, AND that some form of transcoder free > > > > operation should > > > > > also > > > > ^^^^^^^^^^^^^^^^^^^^^ !!!!!!!!!!!!!!! ^^^^^^^^^ > > > !!!!!! ^^^^ > > > > > be > > > > > supported across the peering interface. > > > >=20 > > > > This is where you loose me. > > > > Are you suggesting putting a requirement (albeit at a should > > > > level) on transcoder free operation for all VoIP > > networks, yet not > > > > specify one or more *common* codecs? > > > > If so, are you suggesting to recommend transcoder free=20 > operations=20 > > > > without specifying any common denominator between > > > > L5 peers (user groups, VSP, enterprises)? > > > >=20 > > > As soon as you put a transcoder in the path, then the > > offer/answer no > > > longer works end-to-end. End-to-end offer answer will > > ensure that if > > > the UAC and the UAS support a common codec they will use > > it. With the > > > transcoder in the way, we do not want to end up with=20 > something that=20 > > > goes from codec A to codec B (as the default, or some=20 > other codec)=20 > > > back to codec A. Therefore I believe if you allow=20 > transcoding, you=20 > > > also have to require that we prevent such scenarios. > > >=20 > > > > > >=20 > > > > > Regards > > > > >=20 > > > > > Keith > > > >=20 > > > >=20 > > >=20 > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 25 15:07:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5SFi-0002dJ-JP; Tue, 25 Jul 2006 15:07:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5SFh-0002d3-Sl for Speermint@ietf.org; Tue, 25 Jul 2006 15:07:33 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound1-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5SFf-0008Rp-Gj for Speermint@ietf.org; Tue, 25 Jul 2006 15:07:33 -0400 Received: from outbound1-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-cpk-R.bigfish.com (Postfix) with ESMTP id 3E28710147AF; Tue, 25 Jul 2006 19:07:31 +0000 (UTC) Received: from mail48-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound1-cpk.bigfish.com (Postfix) with ESMTP id 34E3E1014715; Tue, 25 Jul 2006 19:07:31 +0000 (UTC) Received: from mail48-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail48-cpk-R.bigfish.com (Postfix) with ESMTP id 1F8704D3716; Tue, 25 Jul 2006 19:07:31 +0000 (UTC) X-BigFish: V Received: by mail48-cpk (MessageSwitch) id 115385445190813_22156; Tue, 25 Jul 2006 19:07:31 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail48-cpk.bigfish.com (Postfix) with ESMTP id D40CB4D3F12; Tue, 25 Jul 2006 19:07:30 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k6PJ6jl8006635; Tue, 25 Jul 2006 14:07:10 -0500 (CDT) Received: from pdawg06a.ad.sprint.com (PDAWG06A.corp.sprint.com [10.122.2.33]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k6PJ6F309278; Tue, 25 Jul 2006 14:06:17 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by pdawg06a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 14:02:51 -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] TLS, etc - Local-policy versus WG mandate Date: Tue, 25 Jul 2006 14:02:47 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A1301F35382@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acap+LDZIaXVgT3VRzS1gdJH/8Qt8AGI+V2g From: "Khan, Sohel Q [CTO]" To: "Daryl Malas" , "David Schwartz" X-OriginalArrivalTime: 25 Jul 2006 19:02:51.0703 (UTC) FILETIME=[ED838470:01C6B01C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 =20 Daryl Malas [mailto:daryl@level3.net] wrote: >My primary rebuttal is this can be solved in many ways...should we define all of these, which=20 >would simply take away an operator's own routing creativity and flexibility? ...or, should we=20 >define principle functions, which may be implemented to enable peering in manners that enable=20 >greater creativity and flexibility in peering? We should define principle functions that would allow creativity and flexiblity in peering. Sohel Khan, Ph.D. Technology Strategist Sprint-Nextel 913-794-1470 (office) 913-486-3145 (cell) _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 25 15:30:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ScB-0005eE-3L; Tue, 25 Jul 2006 15:30:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Sc9-0005e8-Ao for Speermint@ietf.org; Tue, 25 Jul 2006 15:30:45 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Sc7-0001BR-09 for Speermint@ietf.org; Tue, 25 Jul 2006 15:30:45 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G5Sbu-0004vu-St; Tue, 25 Jul 2006 14:30:31 -0500 From: "Brian Rosen" To: "'Khan, Sohel Q [CTO]'" , "'Daryl Malas'" , "'David Schwartz'" Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate Date: Tue, 25 Jul 2006 15:30:34 -0400 Message-ID: <016f01c6b020$ce80fe00$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.2869 Thread-Index: Acap+LDZIaXVgT3VRzS1gdJH/8Qt8AGI+V2gAADOY0A= In-Reply-To: <858217C310A3D94182FA8AAE42860A1301F35382@PLSWB08C.ad.sprint.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 I'm sorry, but standards are nearly the exact opposite of "creativity and flexibility". We create standards to be interoperable. They severely restrict what you can do so that there are no surprises, your implementation matches the other guy's. If you want creativity and flexibility, be my guest - start a peering service, define your interfaces any way you want and see who comes. Use all the creativity and flexibility you can. If you want interoperable implementations, then we specify, with very little flexibility, and almost no creativity, what to do. Options in protocols are BAD. The best protocols have only one way to do something, and everyone implements it the same way. The worst protocols have elaborate negotiation mechanisms so that everyone's favorite choices have standards coverage. Bah on your creativity and flexibility :) Brian > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Tuesday, July 25, 2006 3:03 PM > To: Daryl Malas; David Schwartz > Cc: Speermint@ietf.org; Uzelac, Adam > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate > > > > Daryl Malas [mailto:daryl@level3.net] wrote: > > >My primary rebuttal is this can be solved in many ways...should we > define all of these, which > >would simply take away an operator's own routing creativity and > flexibility? ...or, should we > >define principle functions, which may be implemented to enable peering > in manners that enable > >greater creativity and flexibility in peering? > > We should define principle functions that would allow creativity and > flexiblity in peering. > > Sohel Khan, Ph.D. > Technology Strategist > Sprint-Nextel > 913-794-1470 (office) > 913-486-3145 (cell) > > > > _______________________________________________ > 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 Jul 25 16:07:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5TBS-0003C8-Ar; Tue, 25 Jul 2006 16:07:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5TBR-0003Bg-11 for speermint@ietf.org; Tue, 25 Jul 2006 16:07:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Sf2-00024J-Px for speermint@ietf.org; Tue, 25 Jul 2006 15:33:44 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound1-cpk-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5SXH-00042B-Uw for speermint@ietf.org; Tue, 25 Jul 2006 15:25:47 -0400 Received: from outbound1-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-cpk-R.bigfish.com (Postfix) with ESMTP id 58D95101550C; Tue, 25 Jul 2006 19:25:43 +0000 (UTC) Received: from mail28-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound1-cpk.bigfish.com (Postfix) with ESMTP id 4EA1F1014E2A; Tue, 25 Jul 2006 19:25:43 +0000 (UTC) Received: from mail108-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail28-cpk-R.bigfish.com (Postfix) with ESMTP id 393EF4D48E1; Tue, 25 Jul 2006 19:25:43 +0000 (UTC) X-BigFish: V Received: by mail108-cpk (MessageSwitch) id 1153855543144610_13834; Tue, 25 Jul 2006 19:25:43 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail28-cpk.bigfish.com (Postfix) with ESMTP id 010434D44BC; Tue, 25 Jul 2006 19:25:42 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k6PJPfAg028972; Tue, 25 Jul 2006 14:25:42 -0500 (CDT) Received: from plswg02a.ad.sprint.com (PLSWG02A.corp.sprint.com [10.214.11.48]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k6PJLf308869; Tue, 25 Jul 2006 14:21:41 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg02a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 14:21:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] comments on Peering Architecture Draft Date: Tue, 25 Jul 2006 14:21:07 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A1301F35437@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] comments on Peering Architecture Draft Thread-Index: AcasvcSO4H0l6+pOQOqVHU6qhK+iRgDYIgaQ From: "Khan, Sohel Q [CTO]" To: "Klaus Darilion" , X-OriginalArrivalTime: 25 Jul 2006 19:21:16.0916 (UTC) FILETIME=[8045A340:01C6B01F] X-Spam-Score: -2.6 (--) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 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 Klaus, Thank you for the input. We updated the SPEERMINT Architecture draft significanlty and addressed many of your concerns.=20 We will make it publicly avaiable this Friday. Sohel=20 -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 Sent: Friday, July 21, 2006 6:55 AM To: speermint@ietf.org Subject: [Speermint] comments on Peering Architecture Draft Hi Sohel! Sorry for reviewing the draft that late, but I was on holidays. > 2. Network Context >=20 > Figure 1 shows an example network context. Two or more providers on=20 > either the public Internet or private Layer 3 networks may form a SIP > (Layer 5) federation. The public or private peering location server =20 > function enables discovery of federations and all provider peering=20 > points. Subsequent exchanges with those provider peering points will > enable discover of policy and additional signaling and media peering You use the term federation 2 times although it is described later. I would put the terminology first. I'm not happy with the term "peering location server". It sounds like a dedicated server for location lookup, maybe a dedicated protocol? I would use the term "peering location service" instead, as it is more general. E.g. when using ENUM we have DNS servers, and the "peering location service" consists of the ENUM client together with the name servers. Thus, also figure 1 would have to be updated. You further say that during exchanges with the PEERING POINTS the policy will discovered. That is not always the case. The policy can be discoverd in several ways, e.g. in DNS like in Otmar's draft, or with a dedicated protocol with dedicated policy servers (!=3Dpeering points) or through local configuration. > [...] >=20 > o Service Provider to Service Provider across a private internet >=20 > Note also that the nature of the Service Provider is intentionally=20 > ambiguous, so it encompasses both VoIP SP and other Application SP. IMO we should talk about VOIP and Multimedia Service PRoviders. If the service provider may have also other services (layer 3, web services, email ...), those Application's are out of scope. Thus they should not be referenced and we should speak clearly about the VoIP&Multimedia parts of the service provider's services. > Next Hop: >=20 > A next hop may be a direct peer or a transit peer. So, what is a peer? I would describe the next hop as the host, to which the SIP signaling will be sent. The host which has the IP address which was resolved with the procedures in RFC3263. > 3. Reference Peering Architecture [...] > A real-time application (Voice and Multimedia) IP Service provider=20 > interconnects with other real-time application (Voice and Multimedia)=20 > IP Service providers through a set of peering interface functions=20 > which are discussed next.=20 What about the enterprises? Maybe we should add a paragraph which describes that all the functionalities are identical for enterprises and service providers, thus using only the term "service provider" for simplicity. > 4. Peering Interface Functions [...] >=20 > o Signaling Function (SF): Purpose is to enable the discovery of=20 > endpoints and assist in discovery and exchange of parameters to be=20 > used with the MF peering point. (Section 4.3) What do you mean by discovery of endpoints? RFC3263 (then I would agree) or discovering the URI which will be used as entry point into RFC3263?=20 In either cases it should be more clearly. As we have stated we will use SIP for signaling, why not say clearly that the SF is the session signaling with SIP? >=20 > o Media Function (MF): Purpose is to enable the interconnection of=20 > media paths between endpoints. (Section 4.4) >=20 > o QoS Function (QF): Purpose is to negotiate and reserve bandwidth=20 > resources, as well as police and provide measurements for media=20 > paths. (Section 4.5) >=20 > o Application Function (AF): TBD (Section 4.5) Is there really an AF? If there is an application, IMO it is the service, which uses the previously defined planes, so its not a plane itself. > SIP security, privacy and encryption: The SF may support Security=20 > functions to provide authentication, privacy (encryption) and message=20 > integrity functions. These functions may be provided by using IPSec > or TLS. =20 or S/MIME or DTLS or whatever will come - no restrictions. --> "These functions may be provided by using for example IPSec or TLS." > 5. Call Control and Media Control Deployment Options >=20 > The peering functions can either be deployed along the following two=20 > dimensions depending upon how the SF and the MF along with IP=20 > functions are implemented:=20 >=20 > Composed or Decomposed: Addresses the question whether the media=20 > paths must flow through the same physical and geographic nodes as the=20 > call signaling, What about dedicated host for SIP and RTP (like provider A in figure 3) - its not a single physical device, but a single logical unit (IMO still composed). IMO Decomposed is where the SF has no interaction with the MF - e.g. RTP is directly between the SIP phones. > Centralized or Distributed: Addresses the question whether the=20 > logical and physical peering points are in one geographical location=20 > or distributed to multiple physical locations on the service provider=20 > network.=20 What is if a provider has several ingress points on the same geographical location? IMO this is still distributed. May it can be formulated: central: a single peering point visible to other peers(it may be a load balancer or anycast IP address which distributes the traffic to proxies (the proxies are invisible to the outside)) decentral: multiple peering points visible to the other peers (e.g.=20 multiple SRV records, or multiple A records ...) > In a composed model, SF, and MF functions are implemented in one=20 > entity.=20 What is an entity - maybe we can say "...in a single logical border element...". In your figure, where >=20 > =20 > Provider A Provider B=20 > ---------- . . ---------- > / \ . . / \=20 > | | . _ . | |=20 > | +----+ . / \_ . +----+ |=20 > | | SF |<-----/ \------| SF | |=20 > | e.g. +-+--+ . /Transit\ . | | |=20 > | MGCP-> | | . / IP \ . | | |=20 > | +-+--+ . \ Provider| . | | |=20 > | | MF |<~~~~\(Option)|~~~~| MF | |=20 > | +----+ . \ / . +----+ |=20 > | | . \__ _/ . | |=20 > \_________ / . . \________ _/=20 > ---------- ----------=20 > =20 > --- Signal (SIP) =20 > ~~~ Bearer (RTP/IP)=20 > ... Scope of peering > =20 > Figure 3: Decomposed v. Composed Peering >=20 > =20 > =20 > khan Expires December 17, 2006 [Page 9]=20 > =0C > Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006=20 > =20 >=20 > The advantage of composed peering architecture is that one-device=20 > solves all peering issues. Disadvantage examples of this architecture=20 > are single point failure, bottle neck, and complex scalability.=20 >=20 > In a decomposed model, SF and MF are implemented in separate=20 > entities. Signaling functions are implemented in a proxy and media=20 > functions are implemented in another device. The scaling of=20 > signaling versus scaling of media may differ between applications. > Decomposing allows each to follow a separate migration path. As said above, I would not differ between a single or multiple physical devices, but a single or multiple logical devices. > This model allows the implementation of M:N model where one SF is=20 > associated with multiple peering routers and one peering router is What is a "peering router" L5? L3? Do we need that device? > associated with multiple peering proxies. Generally, a vertical=20 > protocol such as MGCP associates the relationship between a peering > proxy and a peering router. This architecture reduces the potential > of single point failure. This architecture, allows separation of the=20 > policy decision point and the policy enforcement point. An example of=20 > disadvantages is the scaling complexity because of the M:N=20 > relationship and latency due to the vertical control messages between=20 > entities. =20 Maybe some of this concerns were already discussed on the list - but I still have 200 mails left to read and did not wanted to wait that long before writing down my comments. ;-) regards klaus _______________________________________________ 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 Jul 25 16:37:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5TeM-0005ok-Iu; Tue, 25 Jul 2006 16:37:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5TeK-0005lz-KZ for speermint@ietf.org; Tue, 25 Jul 2006 16:37:04 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5TeG-0000l6-Vb for speermint@ietf.org; Tue, 25 Jul 2006 16:37:04 -0400 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: Tue, 25 Jul 2006 16:36:30 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD1A60F0@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of draft-penno-message-flows-02 Thread-Index: AcawKgKKPs7uRv4pQVmG7yUXk3PHQw== From: "Livingood, Jason" To: X-OriginalArrivalTime: 25 Jul 2006 20:36:31.0271 (UTC) FILETIME=[03098B70:01C6B02A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Speermint] Status of draft-penno-message-flows-02 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 During the IETF 66 meeting in Montreal, Reinaldo Penno presented the lastest draft that he and his co-authors produced, entitled "draft-penno-message-flows-02." As we have a December, 2006, milestone on this (Dec 2006 Submit I-D defining the message flows associated with the SPEERMINT routing architecture) we asked the WG if this should be made an official WG draft. I do not believe we had any hums/hands against doing so, but we wanted to check one final time on the list. If anyone objects to making this a WG draft, please speak up before Tuesday, August 1st (a week from today). Otherwise, a week from today, the WG will ask Reinaldo and his co-authors use draft-penno-message-flows-02, incorporating in feedback received in Montreal, to begin work on what would then be called "draft-ietf-speermint-message-flows-00." We will then ask that the authors submit this new -00 draft at least 2 weeks prior to speermint Interim Meeting #1 so that participants and WG list members can review it. Thank you, Jason & Dave=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 25 18:43:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5VcP-0004n5-4T; Tue, 25 Jul 2006 18:43:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5VcN-0004j9-7U for Speermint@ietf.org; Tue, 25 Jul 2006 18:43:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5TBc-0004Jm-59 for Speermint@ietf.org; Tue, 25 Jul 2006 16:07:24 -0400 Received: from outbound-ash.frontbridge.com ([206.16.192.249] helo=outbound2-ash-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5Sz8-0004uw-B7 for Speermint@ietf.org; Tue, 25 Jul 2006 15:54:32 -0400 Received: from outbound2-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-ash-R.bigfish.com (Postfix) with ESMTP id 12EDCBBF9C2; Tue, 25 Jul 2006 19:53:21 +0000 (UTC) Received: from mail55-ash-R.bigfish.com (unknown [172.18.2.3]) by outbound2-ash.bigfish.com (Postfix) with ESMTP id 0A6D3BBF241; Tue, 25 Jul 2006 19:53:21 +0000 (UTC) Received: from mail55-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail55-ash-R.bigfish.com (Postfix) with ESMTP id F3CCD63423B; Tue, 25 Jul 2006 19:53:20 +0000 (UTC) X-BigFish: V Received: by mail55-ash (MessageSwitch) id 1153857200947675_30484; Tue, 25 Jul 2006 19:53:20 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail55-ash.bigfish.com (Postfix) with ESMTP id CA41163423B; Tue, 25 Jul 2006 19:53:20 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k6PJrJAg012851; Tue, 25 Jul 2006 14:53:19 -0500 (CDT) Received: from pdawg04a.ad.sprint.com (PDAWG04A.corp.sprint.com [10.122.2.37]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k6PJrHn09847; Tue, 25 Jul 2006 14:53:17 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by pdawg04a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 14:53:11 -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] TLS, etc - Local-policy versus WG mandate Date: Tue, 25 Jul 2006 14:53:03 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A1301FB728E@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS, etc - Local-policy versus WG mandate Thread-Index: Acap+LDZIaXVgT3VRzS1gdJH/8Qt8AGI+V2gAADOY0AAAQGpUA== From: "Khan, Sohel Q [CTO]" To: "Brian Rosen" , "Daryl Malas" , "David Schwartz" X-OriginalArrivalTime: 25 Jul 2006 19:53:11.0152 (UTC) FILETIME=[F53EDF00:01C6B023] X-Spam-Score: -2.6 (--) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Okay, we will make it creatively interoperable and flexible.=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, July 25, 2006 2:31 PM To: Khan, Sohel Q [CTO]; 'Daryl Malas'; 'David Schwartz' Cc: Speermint@ietf.org; 'Uzelac, Adam' Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate I'm sorry, but standards are nearly the exact opposite of "creativity and flexibility". We create standards to be interoperable. They severely restrict what you can do so that there are no surprises, your implementation matches the other guy's. If you want creativity and flexibility, be my guest - start a peering service, define your interfaces any way you want and see who comes. Use all the creativity and flexibility you can. If you want interoperable implementations, then we specify, with very little flexibility, and almost no creativity, what to do. Options in protocols are BAD. The best protocols have only one way to do something, and everyone implements it the same way. The worst protocols have elaborate negotiation mechanisms so that everyone's favorite choices have standards coverage. Bah on your creativity and flexibility :) Brian > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Tuesday, July 25, 2006 3:03 PM > To: Daryl Malas; David Schwartz > Cc: Speermint@ietf.org; Uzelac, Adam > Subject: RE: [Speermint] TLS, etc - Local-policy versus WG mandate >=20 >=20 >=20 > Daryl Malas [mailto:daryl@level3.net] wrote: >=20 > >My primary rebuttal is this can be solved in many ways...should we > define all of these, which > >would simply take away an operator's own routing creativity and > flexibility? ...or, should we > >define principle functions, which may be implemented to enable=20 > >peering > in manners that enable > >greater creativity and flexibility in peering? >=20 > We should define principle functions that would allow creativity and=20 > flexiblity in peering. >=20 > Sohel Khan, Ph.D. > Technology Strategist > Sprint-Nextel > 913-794-1470 (office) > 913-486-3145 (cell) >=20 >=20 >=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 Wed Jul 26 10:00:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jwG-0005co-4b; Wed, 26 Jul 2006 10:00:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jwE-0005cj-Tm for speermint@ietf.org; Wed, 26 Jul 2006 10:00:38 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5jwD-0001Ba-E3 for speermint@ietf.org; Wed, 26 Jul 2006 10:00:38 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k6QE0aFA001649; Wed, 26 Jul 2006 09:00:36 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 Jul 2006 09:00:36 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 Jul 2006 16:00:34 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Speermint] Status of draft-penno-message-flows-02 Date: Wed, 26 Jul 2006 16:00:48 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180194B16@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Status of draft-penno-message-flows-02 Thread-Index: AcawKgKKPs7uRv4pQVmG7yUXk3PHQwAjyI7Q From: "Drage, Keith \(Keith\)" To: "Livingood, Jason" , X-OriginalArrivalTime: 26 Jul 2006 14:00:34.0581 (UTC) FILETIME=[DD5C1450:01C6B0BB] 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 I did a quick look and had the following comments: 1) The proposed deliverable is meant to be informational. Do we need the RFC 2119 reference and associated boiler plate text. 2) General: Use of 100 (Trying) responses. The way this is shown this seems to be generated as an immediate response. This is meant to be generated to prevent timeout in the sender, and I would expect things like DHCP lookup, and registration within the location server, to occur quicker than this, thus either obviating the need to send 100 (Trying), or sending it after the lookup has occurred. 3) Media flow at end of section 2: What is the "BYE" doing in this flow? 4) Section 3.1.2: I assume this needs a new event package that would need to be done by the SIPPING group (RFC 3427). Have you built this into your timescales of December 2006). 5) Section 3.1.3: The purpose of REGISTER is to create an AoR. Do I understand that you are creating an AoR if Alice in proxy 2, and an AoR of Bob with proxy 1. That is how I currently read the text. If so, doesn't that obviate the need to send the subsequent session request to proxy 2? Not sure what SIP changes would be needed here, but I would work on the assumption that there would be some and these need to go to the SIP group. Timescales again. 6) For both section 3.1.2 and section 3.1.3, are you providing one or multiple security mechanisms. If multiple mechanisns, what are you doing to negotiate which one gets used (the strongest), and how are you avoiding bid-down attacks. 7) In some cases it would be useful to identify the dialogs/transactions involved, especially where there are multiple different ids. Are these flows going to evolve into detailed flows? If so RFC 4485 indicates that they should contain real examples, with correct certificates and so on? In regard as to whether it goes forward or not, I would not like it to go to IESG review with inclusion of SIP extensions that have not yet been chartered and are not well under way. I have no problem with it forming the basis of a charter item. Regards Keith > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: 25 July 2006 21:37 > To: speermint@ietf.org > Subject: [Speermint] Status of draft-penno-message-flows-02 >=20 > During the IETF 66 meeting in Montreal, Reinaldo Penno=20 > presented the lastest draft that he and his co-authors=20 > produced, entitled "draft-penno-message-flows-02." As we=20 > have a December, 2006, milestone on this (Dec 2006 Submit I-D=20 > defining the message flows associated with the SPEERMINT=20 > routing architecture) we asked the WG if this should be made=20 > an official WG draft. I do not believe we had any hums/hands=20 > against doing so, but we wanted to check one final time on=20 > the list. If anyone objects to making this a WG draft,=20 > please speak up before Tuesday, August 1st (a week from today). >=20 > Otherwise, a week from today, the WG will ask Reinaldo and=20 > his co-authors use draft-penno-message-flows-02,=20 > incorporating in feedback received in Montreal, to begin work=20 > on what would then be called=20 > "draft-ietf-speermint-message-flows-00." We will then ask=20 > that the authors submit this new -00 draft at least 2 weeks=20 > prior to speermint Interim Meeting #1 so that participants=20 > and WG list members can review it. >=20 > Thank you, > Jason & Dave=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 Wed Jul 26 16:41:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5qCF-0000Df-5r; Wed, 26 Jul 2006 16:41:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5qCE-0000Da-QQ for speermint@ietf.org; Wed, 26 Jul 2006 16:41:34 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5qC9-00014O-Hv for speermint@ietf.org; Wed, 26 Jul 2006 16:41:34 -0400 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: TLS for peering (was RE:Comments (RE:[speermint]requirementsdraftsubmitted)) Date: Wed, 26 Jul 2006 16:41:07 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD3BA2CC@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE:Comments (RE:[speermint]requirementsdraftsubmitted)) Thread-Index: AcavUoaoKx5fgnULSIuP9ZA80GGS8ABFuTgg From: "Lee, Yiu" To: "Klaus Darilion" , "Brian Rosen" X-OriginalArrivalTime: 26 Jul 2006 20:41:08.0552 (UTC) FILETIME=[D2B90480:01C6B0F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd 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 Hi, We agree that it is difficult to enforce hop-by-hop TLS session for SIPS in federation. I think we can't mandate SIPS, but we can require a TLS session between A and T and a TLS session between T and B. So we can relax the requirement of SIPS but still provide some security to transport SIP messages. Thanks, Yiu=20 -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 Sent: Monday, July 24, 2006 11:28 AM To: Brian Rosen Cc: speermint@ietf.org Subject: Re: TLS for peering (was RE:Comments (RE:[speermint]requirementsdraftsubmitted)) Brian Rosen wrote: > I think you are misinterpreting 3261. Section 26.3.2.2 is=20 > illustrating a simple SIP trapezoid call where the call goes from=20 > atlanta.com to biloxi.com. If there is another intermediary,=20 > biloxi.com would not be checking the From to see that it matched the=20 > domain of the T proxy handling How will biloxi's proxy know if the request comes directly from atlanta or via an intermediary? You suggest that in this case the From:=20 validation is not used. Then we should remove the From: validation completely and validate only the Identity signature. The only thing I want to say is that Rohan's suggested From: validation .... The client certificate MUST contain a DNS or URI choice type in the subjectAltName which corresponds to the domain asserted in the host production of the From header URI.... can't be mandated. > the call. We all agree that TLS is underspecified in 3261. There is=20 > some effort to address this shortcoming underway. >=20 > If the path is A -> T -> B, then the mutual TLS cert validation is A=20 > <-> T and T <-> B. In a peering system, the peers authenticate each=20 > other within Yes. > the peering regime. If T accepts a call from A destined for B, then=20 > it authenticates A as a peer which it accepts transit calls for B, and > it authenticates B as a peer with whom it can send calls destined for B. Yes - but the L5 domain validation can't be used. Maybe I express myself a little bit unclear. Thus, I describe it more detailed. When using SSL/TLS to secure a transport connection, there are several validation steps. Some of the are done in the SSL stack, some of the are done in the application. I'm speaking of experience in using openssl and openser. During the TLS handshake, the peers verify the certificate presented by the other peer. The TLS stacks of the certificate is signed by a (to the stack) well known CA and it is valid (not expired). Let's call this L4 certificate validation. Once the TLS connection is setup, the application can further validate the certificate, e.g. if the domain presented in the certificate equals the domain in the request URI. Let's call this L5 certificate validation. To authenticate a peer, L5 is NOT necessary. For example, T and B are in the same federation. (B trusts T, T trusts B, and both of them trusts the federation's CA) If B receives a call from T, which is originally from an other service provider (which T trusts), the domain in the From header is not important, as the authentication is based on the certificate. And B and T can bill each other because they were both authenticated (although there was no L5 validation). Conclusion: IMO TLS should be MUST, but the L5 domain validation (as suggested in RFC3261 and Rohan's draft) must be removed as it does not work in many scenarios and further is not needed. Nevertheless, in scenarios where it is useful it should be used. But a MUST is wrong. regards Klaus >=20 > Brian >=20 >> -----Original Message----- >> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >> Sent: Sunday, July 23, 2006 7:49 PM >> To: Brian Rosen >> Cc: speermint@ietf.org >> Subject: RE: TLS for peering (was RE: Comments >> (RE:[speermint]requirementsdraftsubmitted)) >> >> Hi Brian! >> >> On Fri, July 21, 2006 18:08, Brian Rosen said: >>> I believe it is the case that the link from one peer to another,=20 >>> which >> is >>> generally between two proxies, can very reasonably be protected with >> TLS, >>> with many current implementations, and with reasonable assumptions=20 >>> about PKI. Specifically, if one of the parts of a federation was an >>> agreement on a CA, then each peer can have a certificate that other=20 >>> peers can verify. >>> I >>> believe all operations, including forwarding, if they work at all=20 >>> across the peering system would work if it was TLS protected. >> Using TLS for encryption and TLS certificate validation works - but=20 >> the L5 validation (validate the certificate domain names against the=20 >> domains in the SIP headers) does not work without mandating a B2BUA. >> >> TLS/SSL was invented for a very simple client-server system - HTTP.=20 >> Let's compare HTTP with SIP: >> >> HTTP: >> 1 request - 1 (or more) responses. >> L5 validation: verify domain in browser's location bar against the=20 >> domain in the server certificate - this is straight forward >> >> SIP: >> Multiple - bidirectional requests >> L5 validation: There are several headers which are used for routing=20 >> and thus can be used for validation: requestURI, From, To, Via,=20 >> Route, Contact. >> We can have in-dialog requests which are initiated in reverse=20 >> direction of the original dialog setup. And each of this domain=20 >> resolves to several domains (due to NAPTR, SRV, A resolution). This=20 >> alone should have people think a little more before defining TLS for SIP. >> >> I am a fan of forwarding - and probably every transit service=20 >> provider too. As transit will happen I will use the transit scenario=20 >> (simple forwarding without a B2BUA) to show that L5 validation is=20 >> broken - and I would be very very happy if someone can show that I'm wrong. >> >> A want to call B. There is no direct peering agreement. Thus A sends=20 >> the call to it's transit provider T. (only the signaling between the=20 >> proxies is shown) >> >> A->T >> INVITE sip:B@B >> From: sip:A@A >> To: sip:B@B >> Contact: user@phone >> Record-Route: sip:A >> >> Cert validation according to RFC3261 section 26.3.2.2: >> T will show a TLS certificate for T (not for B) - thus, when A=20 >> validates T's certificate, the validation will fail. IMO this can be=20 >> fixed by adding a Route: header with sip:T, but this is nowhere mentioned in RFC 3261. >> >> T->B >> INVITE sip:B@B >> From: sip:A@A >> To: sip:B@B >> Contact: user@phone >> Record-Route: sip:T >> Record-Route: sip:A >> >> Cert validation according to RFC3261 section 26.3.2.2: >> B should validate the domain in the From header (A) aginst the domain >> in the client's certificate (T) --> it will fail. >> >> Now let's assume the previous validation have succeeded and B sends a >> BYE request to A, and the TLS connection was dropped and must be >> re-established: >> >> B->T >> BYE name@1.2.3.4 >> From: sip:B@B >> To: sip:A@A >> Route: sip:T >> Route: sip:A >> >> How should T's certificate be validated? Probably against the domain=20 >> in the topmost Route header - but again: This is nowhere specified. >> >> T->A >> BYE name@1.2.3.4 >> From: sip:B@B >> To: sip:A@A >> Route: sip:A >> >> Again, probably T should use the domain in the Route header for=20 >> certificate validation. But A can't validate the certificate's domain >> (T) against the From header (B) - it will fail. >> >> Similar problem arise in a forwarding scenario - A-->B which forwards >> it's call to C. The suggested L5 validation will fail (except B uses=20 >> a B2BUA, and IMO a B2BUA should not be mandatory). >> >>> This does not assume sips works (whatever that means), and does not >> assume >>> endpoints implement TLS, or either the originating or terminating >> domains >>> deploy TLS anywhere else. >>> >>> It does provide a reasonable degree of protection across the peering >>> point, which I think is a good thing. >> Yes, TLS provides protection, but we should not specify a broken L5=20 >> certificate validation. >> >>> Having lived with protocols that offered options like IPsec and VPNs >>> and other mechanisms, I think that despite the fact that you can, in >>> theory, create a satisfactory security arrangement, it is=20 >>> exceedingly hard to >> make >>> it actually work except for cases where there is an entity that >> completely >>> controls all aspects of the peering. That just isn't the case for=20 >>> what >> I >>> think we are trying to specify here (such cases don't need IETF=20 >>> standardization). Thus, I personally think mandating TLS is a good >> thing, >>> achievable, and reasonable. That's a MUST IMPLEMENT, not a must=20 >>> deploy; >> Yes, I agree. I want TLS in the specs too - but we have to specify=20 >> the validation more precisely and it has to work in other scenarios=20 >> than a basic call too. Otherwise people wont use it. >> >> regards >> Klaus >=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 Wed Jul 26 20:41:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5twA-0003mt-5l; Wed, 26 Jul 2006 20:41:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5tw8-0003eK-Ld for speermint@ietf.org; Wed, 26 Jul 2006 20:41:12 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5tw8-0007qK-9M for speermint@ietf.org; Wed, 26 Jul 2006 20:41:12 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 26 Jul 2006 17:41:13 -0700 X-IronPort-AV: i="4.07,185,1151910000"; d="scan'208"; a="566059720:sNHT32822226" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Status of draft-penno-message-flows-02 Date: Wed, 26 Jul 2006 20:41:16 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804F94D82@proton.jnpr.net> In-Reply-To: <5D1A7985295922448D5550C94DE29180194B16@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Status of draft-penno-message-flows-02 Thread-Index: AcawKgKKPs7uRv4pQVmG7yUXk3PHQwAjyI7QABb4UmA= From: "Reinaldo Penno" To: "Drage, Keith \(Keith\)" , "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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 Hello Keith, Thanks for the comments, they are welcome. I will address them in the next revision. I'm planning to issue a draft regarding an event package for policy exchange in the context of Speermint for some time now. Most of the work is already done but my day job is kept me from publishing it before the meeting. Thanks, Reinaldo > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Wednesday, July 26, 2006 7:01 AM > To: Livingood, Jason; speermint@ietf.org > Subject: RE: [Speermint] Status of draft-penno-message-flows-02 >=20 > I did a quick look and had the following comments: >=20 > 1) The proposed deliverable is meant to be informational. Do we > need the RFC 2119 reference and associated boiler plate text. >=20 > 2) General: Use of 100 (Trying) responses. The way this is shown > this seems to be generated as an immediate response. This is meant to be > generated to prevent timeout in the sender, and I would expect things > like DHCP lookup, and registration within the location server, to occur > quicker than this, thus either obviating the need to send 100 (Trying), > or sending it after the lookup has occurred. >=20 > 3) Media flow at end of section 2: What is the "BYE" doing in this > flow? >=20 > 4) Section 3.1.2: I assume this needs a new event package that > would need to be done by the SIPPING group (RFC 3427). Have you built > this into your timescales of December 2006). >=20 > 5) Section 3.1.3: The purpose of REGISTER is to create an AoR. Do I > understand that you are creating an AoR if Alice in proxy 2, and an AoR > of Bob with proxy 1. That is how I currently read the text. If so, > doesn't that obviate the need to send the subsequent session request to > proxy 2? Not sure what SIP changes would be needed here, but I would > work on the assumption that there would be some and these need to go to > the SIP group. Timescales again. >=20 > 6) For both section 3.1.2 and section 3.1.3, are you providing one > or multiple security mechanisms. If multiple mechanisns, what are you > doing to negotiate which one gets used (the strongest), and how are you > avoiding bid-down attacks. >=20 > 7) In some cases it would be useful to identify the > dialogs/transactions involved, especially where there are multiple > different ids. Are these flows going to evolve into detailed flows? If > so RFC 4485 indicates that they should contain real examples, with > correct certificates and so on? >=20 > In regard as to whether it goes forward or not, I would not like it to > go to IESG review with inclusion of SIP extensions that have not yet > been chartered and are not well under way. I have no problem with it > forming the basis of a charter item. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: 25 July 2006 21:37 > > To: speermint@ietf.org > > Subject: [Speermint] Status of draft-penno-message-flows-02 > > > > During the IETF 66 meeting in Montreal, Reinaldo Penno > > presented the lastest draft that he and his co-authors > > produced, entitled "draft-penno-message-flows-02." As we > > have a December, 2006, milestone on this (Dec 2006 Submit I-D > > defining the message flows associated with the SPEERMINT > > routing architecture) we asked the WG if this should be made > > an official WG draft. I do not believe we had any hums/hands > > against doing so, but we wanted to check one final time on > > the list. If anyone objects to making this a WG draft, > > please speak up before Tuesday, August 1st (a week from today). > > > > Otherwise, a week from today, the WG will ask Reinaldo and > > his co-authors use draft-penno-message-flows-02, > > incorporating in feedback received in Montreal, to begin work > > on what would then be called > > "draft-ietf-speermint-message-flows-00." We will then ask > > that the authors submit this new -00 draft at least 2 weeks > > prior to speermint Interim Meeting #1 so that participants > > and WG list members can review it. > > > > Thank you, > > Jason & Dave > > > > _______________________________________________ > > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 27 03:00:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5zqp-0003W1-8m; Thu, 27 Jul 2006 03:00:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5zqo-0003U5-5i for speermint@ietf.org; Thu, 27 Jul 2006 03:00:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5zqo-0003hy-3X for speermint@ietf.org; Thu, 27 Jul 2006 03:00:06 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5zll-0003Dc-7B for speermint@ietf.org; Thu, 27 Jul 2006 02:54:56 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id BF1F7210023; Thu, 27 Jul 2006 08:54:47 +0200 (CEST) Message-ID: <44C8633D.4090106@pernau.at> Date: Thu, 27 Jul 2006 08:54:53 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Lee, Yiu" Subject: Re: TLS for peering (was RE:Comments (RE:[speermint]requirementsdraftsubmitted)) References: <8587F175CDB3D741B58C79F67E8E09AD3BA2CC@PACDCEXCMB03.cable.comcast.com> In-Reply-To: <8587F175CDB3D741B58C79F67E8E09AD3BA2CC@PACDCEXCMB03.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b 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 Lee, Yiu wrote: > Hi, > > We agree that it is difficult to enforce hop-by-hop TLS session for SIPS > in federation. I think we can't mandate SIPS, but we can require a TLS > session between A and T and a TLS session between T and B. So we can > relax the requirement of SIPS but still provide some security to > transport SIP messages. H! Looks like I'm still not clear enough - it was not talking about SIPS. Only SIP which uses TLS between providers. IMO, TLS as transport is a MUST, but the L5 certificate domain validation must not be a MUST. regards klaus > > Thanks, > Yiu > > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Monday, July 24, 2006 11:28 AM > To: Brian Rosen > Cc: speermint@ietf.org > Subject: Re: TLS for peering (was RE:Comments > (RE:[speermint]requirementsdraftsubmitted)) > > Brian Rosen wrote: >> I think you are misinterpreting 3261. Section 26.3.2.2 is >> illustrating a simple SIP trapezoid call where the call goes from >> atlanta.com to biloxi.com. If there is another intermediary, >> biloxi.com would not be checking the From to see that it matched the >> domain of the T proxy handling > > How will biloxi's proxy know if the request comes directly from atlanta > or via an intermediary? You suggest that in this case the From: > validation is not used. Then we should remove the From: validation > completely and validate only the Identity signature. > > The only thing I want to say is that Rohan's suggested From: validation > > .... The client certificate MUST > contain a DNS or URI choice type in the subjectAltName which > corresponds to the domain asserted in the host production of the > From > header URI.... > > can't be mandated. > >> the call. We all agree that TLS is underspecified in 3261. There is >> some effort to address this shortcoming underway. >> >> If the path is A -> T -> B, then the mutual TLS cert validation is A >> <-> T and T <-> B. In a peering system, the peers authenticate each >> other within > > Yes. > >> the peering regime. If T accepts a call from A destined for B, then >> it authenticates A as a peer which it accepts transit calls for B, and > >> it authenticates B as a peer with whom it can send calls destined for > B. > > Yes - but the L5 domain validation can't be used. > > Maybe I express myself a little bit unclear. Thus, I describe it more > detailed. > > When using SSL/TLS to secure a transport connection, there are several > validation steps. Some of the are done in the SSL stack, some of the are > done in the application. I'm speaking of experience in using openssl and > openser. > > During the TLS handshake, the peers verify the certificate presented by > the other peer. The TLS stacks of the certificate is signed by a (to the > stack) well known CA and it is valid (not expired). Let's call this L4 > certificate validation. > > Once the TLS connection is setup, the application can further validate > the certificate, e.g. if the domain presented in the certificate equals > the domain in the request URI. Let's call this L5 certificate > validation. > > To authenticate a peer, L5 is NOT necessary. For example, T and B are in > the same federation. (B trusts T, T trusts B, and both of them trusts > the federation's CA) > > If B receives a call from T, which is originally from an other service > provider (which T trusts), the domain in the From header is not > important, as the authentication is based on the certificate. And B and > T can bill each other because they were both authenticated (although > there was no L5 validation). > > Conclusion: > IMO TLS should be MUST, but the L5 domain validation (as suggested in > RFC3261 and Rohan's draft) must be removed as it does not work in many > scenarios and further is not needed. Nevertheless, in scenarios where it > is useful it should be used. But a MUST is wrong. > > regards > Klaus > > > >> Brian >> >>> -----Original Message----- >>> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >>> Sent: Sunday, July 23, 2006 7:49 PM >>> To: Brian Rosen >>> Cc: speermint@ietf.org >>> Subject: RE: TLS for peering (was RE: Comments >>> (RE:[speermint]requirementsdraftsubmitted)) >>> >>> Hi Brian! >>> >>> On Fri, July 21, 2006 18:08, Brian Rosen said: >>>> I believe it is the case that the link from one peer to another, >>>> which >>> is >>>> generally between two proxies, can very reasonably be protected with >>> TLS, >>>> with many current implementations, and with reasonable assumptions >>>> about PKI. Specifically, if one of the parts of a federation was an > >>>> agreement on a CA, then each peer can have a certificate that other >>>> peers can verify. >>>> I >>>> believe all operations, including forwarding, if they work at all >>>> across the peering system would work if it was TLS protected. >>> Using TLS for encryption and TLS certificate validation works - but >>> the L5 validation (validate the certificate domain names against the >>> domains in the SIP headers) does not work without mandating a B2BUA. >>> >>> TLS/SSL was invented for a very simple client-server system - HTTP. >>> Let's compare HTTP with SIP: >>> >>> HTTP: >>> 1 request - 1 (or more) responses. >>> L5 validation: verify domain in browser's location bar against the >>> domain in the server certificate - this is straight forward >>> >>> SIP: >>> Multiple - bidirectional requests >>> L5 validation: There are several headers which are used for routing >>> and thus can be used for validation: requestURI, From, To, Via, >>> Route, Contact. >>> We can have in-dialog requests which are initiated in reverse >>> direction of the original dialog setup. And each of this domain >>> resolves to several domains (due to NAPTR, SRV, A resolution). This >>> alone should have people think a little more before defining TLS for > SIP. >>> I am a fan of forwarding - and probably every transit service >>> provider too. As transit will happen I will use the transit scenario >>> (simple forwarding without a B2BUA) to show that L5 validation is >>> broken - and I would be very very happy if someone can show that I'm > wrong. >>> A want to call B. There is no direct peering agreement. Thus A sends >>> the call to it's transit provider T. (only the signaling between the >>> proxies is shown) >>> >>> A->T >>> INVITE sip:B@B >>> From: sip:A@A >>> To: sip:B@B >>> Contact: user@phone >>> Record-Route: sip:A >>> >>> Cert validation according to RFC3261 section 26.3.2.2: >>> T will show a TLS certificate for T (not for B) - thus, when A >>> validates T's certificate, the validation will fail. IMO this can be >>> fixed by adding a Route: header with sip:T, but this is nowhere > mentioned in RFC 3261. >>> T->B >>> INVITE sip:B@B >>> From: sip:A@A >>> To: sip:B@B >>> Contact: user@phone >>> Record-Route: sip:T >>> Record-Route: sip:A >>> >>> Cert validation according to RFC3261 section 26.3.2.2: >>> B should validate the domain in the From header (A) aginst the domain > >>> in the client's certificate (T) --> it will fail. >>> >>> Now let's assume the previous validation have succeeded and B sends a > >>> BYE request to A, and the TLS connection was dropped and must be >>> re-established: >>> >>> B->T >>> BYE name@1.2.3.4 >>> From: sip:B@B >>> To: sip:A@A >>> Route: sip:T >>> Route: sip:A >>> >>> How should T's certificate be validated? Probably against the domain >>> in the topmost Route header - but again: This is nowhere specified. >>> >>> T->A >>> BYE name@1.2.3.4 >>> From: sip:B@B >>> To: sip:A@A >>> Route: sip:A >>> >>> Again, probably T should use the domain in the Route header for >>> certificate validation. But A can't validate the certificate's domain > >>> (T) against the From header (B) - it will fail. >>> >>> Similar problem arise in a forwarding scenario - A-->B which forwards > >>> it's call to C. The suggested L5 validation will fail (except B uses >>> a B2BUA, and IMO a B2BUA should not be mandatory). >>> >>>> This does not assume sips works (whatever that means), and does not >>> assume >>>> endpoints implement TLS, or either the originating or terminating >>> domains >>>> deploy TLS anywhere else. >>>> >>>> It does provide a reasonable degree of protection across the peering > >>>> point, which I think is a good thing. >>> Yes, TLS provides protection, but we should not specify a broken L5 >>> certificate validation. >>> >>>> Having lived with protocols that offered options like IPsec and VPNs > >>>> and other mechanisms, I think that despite the fact that you can, in > >>>> theory, create a satisfactory security arrangement, it is >>>> exceedingly hard to >>> make >>>> it actually work except for cases where there is an entity that >>> completely >>>> controls all aspects of the peering. That just isn't the case for >>>> what >>> I >>>> think we are trying to specify here (such cases don't need IETF >>>> standardization). Thus, I personally think mandating TLS is a good >>> thing, >>>> achievable, and reasonable. That's a MUST IMPLEMENT, not a must >>>> deploy; >>> Yes, I agree. I want TLS in the specs too - but we have to specify >>> the validation more precisely and it has to work in other scenarios >>> than a basic call too. Otherwise people wont use it. >>> >>> regards >>> Klaus > > > _______________________________________________ > 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 Jul 27 09:38:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6643-0007V6-PO; Thu, 27 Jul 2006 09:38:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6641-0007Uz-Tj for speermint@ietf.org; Thu, 27 Jul 2006 09:38:09 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6641-0000wE-D3 for speermint@ietf.org; Thu, 27 Jul 2006 09:38:09 -0400 Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.22759181; Thu, 27 Jul 2006 09:37:51 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 09:37:51 -0400 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: TLS for peering (was RE:Comments (RE:[speermint]requirementsdraftsubmitted)) Date: Thu, 27 Jul 2006 09:37:50 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD3BA453@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE:Comments (RE:[speermint]requirementsdraftsubmitted)) Thread-Index: AcaxSaFmZ4KB0KxNTRChTprKjQ3uUAAN+Xqw From: "Lee, Yiu" To: "Klaus Darilion" X-OriginalArrivalTime: 27 Jul 2006 13:37:51.0128 (UTC) FILETIME=[DB176980:01C6B181] X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 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 Hi Klaus, Sorry for mis-understanding your previous post. I agree that using the domain for the end-to-end certification is broken in federation. Thanks for the clarification. -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 Sent: Thursday, July 27, 2006 2:55 AM To: Lee, Yiu Cc: Brian Rosen; speermint@ietf.org Subject: Re: TLS for peering (was RE:Comments (RE:[speermint]requirementsdraftsubmitted)) Lee, Yiu wrote: > Hi, >=20 > We agree that it is difficult to enforce hop-by-hop TLS session for=20 > SIPS in federation. I think we can't mandate SIPS, but we can require=20 > a TLS session between A and T and a TLS session between T and B. So we > can relax the requirement of SIPS but still provide some security to=20 > transport SIP messages. H! Looks like I'm still not clear enough - it was not talking about SIPS.=20 Only SIP which uses TLS between providers. IMO, TLS as transport is a MUST, but the L5 certificate domain validation must not be a MUST. regards klaus >=20 > Thanks, > Yiu >=20 > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Monday, July 24, 2006 11:28 AM > To: Brian Rosen > Cc: speermint@ietf.org > Subject: Re: TLS for peering (was RE:Comments > (RE:[speermint]requirementsdraftsubmitted)) >=20 > Brian Rosen wrote: >> I think you are misinterpreting 3261. Section 26.3.2.2 is=20 >> illustrating a simple SIP trapezoid call where the call goes from=20 >> atlanta.com to biloxi.com. If there is another intermediary,=20 >> biloxi.com would not be checking the From to see that it matched the=20 >> domain of the T proxy handling >=20 > How will biloxi's proxy know if the request comes directly from=20 > atlanta or via an intermediary? You suggest that in this case the From: > validation is not used. Then we should remove the From: validation=20 > completely and validate only the Identity signature. >=20 > The only thing I want to say is that Rohan's suggested From:=20 > validation >=20 > .... The client certificate MUST > contain a DNS or URI choice type in the subjectAltName which > corresponds to the domain asserted in the host production of the=20 > From > header URI.... >=20 > can't be mandated. >=20 >> the call. We all agree that TLS is underspecified in 3261. There is >> some effort to address this shortcoming underway. >> >> If the path is A -> T -> B, then the mutual TLS cert validation is A=20 >> <-> T and T <-> B. In a peering system, the peers authenticate each=20 >> other within >=20 > Yes. >=20 >> the peering regime. If T accepts a call from A destined for B, then=20 >> it authenticates A as a peer which it accepts transit calls for B,=20 >> and >=20 >> it authenticates B as a peer with whom it can send calls destined for > B. >=20 > Yes - but the L5 domain validation can't be used. >=20 > Maybe I express myself a little bit unclear. Thus, I describe it more=20 > detailed. >=20 > When using SSL/TLS to secure a transport connection, there are several > validation steps. Some of the are done in the SSL stack, some of the=20 > are done in the application. I'm speaking of experience in using=20 > openssl and openser. >=20 > During the TLS handshake, the peers verify the certificate presented=20 > by the other peer. The TLS stacks of the certificate is signed by a=20 > (to the > stack) well known CA and it is valid (not expired). Let's call this L4 > certificate validation. >=20 > Once the TLS connection is setup, the application can further validate > the certificate, e.g. if the domain presented in the certificate=20 > equals the domain in the request URI. Let's call this L5 certificate=20 > validation. >=20 > To authenticate a peer, L5 is NOT necessary. For example, T and B are=20 > in the same federation. (B trusts T, T trusts B, and both of them=20 > trusts the federation's CA) >=20 > If B receives a call from T, which is originally from an other service > provider (which T trusts), the domain in the From header is not=20 > important, as the authentication is based on the certificate. And B=20 > and T can bill each other because they were both authenticated=20 > (although there was no L5 validation). >=20 > Conclusion: > IMO TLS should be MUST, but the L5 domain validation (as suggested in > RFC3261 and Rohan's draft) must be removed as it does not work in many > scenarios and further is not needed. Nevertheless, in scenarios where=20 > it is useful it should be used. But a MUST is wrong. >=20 > regards > Klaus >=20 >=20 >=20 >> Brian >> >>> -----Original Message----- >>> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >>> Sent: Sunday, July 23, 2006 7:49 PM >>> To: Brian Rosen >>> Cc: speermint@ietf.org >>> Subject: RE: TLS for peering (was RE: Comments >>> (RE:[speermint]requirementsdraftsubmitted)) >>> >>> Hi Brian! >>> >>> On Fri, July 21, 2006 18:08, Brian Rosen said: >>>> I believe it is the case that the link from one peer to another,=20 >>>> which >>> is >>>> generally between two proxies, can very reasonably be protected=20 >>>> with >>> TLS, >>>> with many current implementations, and with reasonable assumptions=20 >>>> about PKI. Specifically, if one of the parts of a federation was=20 >>>> an >=20 >>>> agreement on a CA, then each peer can have a certificate that other >>>> peers can verify. >>>> I >>>> believe all operations, including forwarding, if they work at all=20 >>>> across the peering system would work if it was TLS protected. >>> Using TLS for encryption and TLS certificate validation works - but=20 >>> the L5 validation (validate the certificate domain names against the >>> domains in the SIP headers) does not work without mandating a B2BUA. >>> >>> TLS/SSL was invented for a very simple client-server system - HTTP.=20 >>> Let's compare HTTP with SIP: >>> >>> HTTP: >>> 1 request - 1 (or more) responses. >>> L5 validation: verify domain in browser's location bar against the=20 >>> domain in the server certificate - this is straight forward >>> >>> SIP: >>> Multiple - bidirectional requests >>> L5 validation: There are several headers which are used for routing=20 >>> and thus can be used for validation: requestURI, From, To, Via,=20 >>> Route, Contact. >>> We can have in-dialog requests which are initiated in reverse=20 >>> direction of the original dialog setup. And each of this domain=20 >>> resolves to several domains (due to NAPTR, SRV, A resolution). This=20 >>> alone should have people think a little more before defining TLS for > SIP. >>> I am a fan of forwarding - and probably every transit service=20 >>> provider too. As transit will happen I will use the transit scenario >>> (simple forwarding without a B2BUA) to show that L5 validation is=20 >>> broken - and I would be very very happy if someone can show that I'm > wrong. >>> A want to call B. There is no direct peering agreement. Thus A sends >>> the call to it's transit provider T. (only the signaling between the >>> proxies is shown) >>> >>> A->T >>> INVITE sip:B@B >>> From: sip:A@A >>> To: sip:B@B >>> Contact: user@phone >>> Record-Route: sip:A >>> >>> Cert validation according to RFC3261 section 26.3.2.2: >>> T will show a TLS certificate for T (not for B) - thus, when A=20 >>> validates T's certificate, the validation will fail. IMO this can be >>> fixed by adding a Route: header with sip:T, but this is nowhere > mentioned in RFC 3261. >>> T->B >>> INVITE sip:B@B >>> From: sip:A@A >>> To: sip:B@B >>> Contact: user@phone >>> Record-Route: sip:T >>> Record-Route: sip:A >>> >>> Cert validation according to RFC3261 section 26.3.2.2: >>> B should validate the domain in the From header (A) aginst the=20 >>> domain >=20 >>> in the client's certificate (T) --> it will fail. >>> >>> Now let's assume the previous validation have succeeded and B sends=20 >>> a >=20 >>> BYE request to A, and the TLS connection was dropped and must be >>> re-established: >>> >>> B->T >>> BYE name@1.2.3.4 >>> From: sip:B@B >>> To: sip:A@A >>> Route: sip:T >>> Route: sip:A >>> >>> How should T's certificate be validated? Probably against the domain >>> in the topmost Route header - but again: This is nowhere specified. >>> >>> T->A >>> BYE name@1.2.3.4 >>> From: sip:B@B >>> To: sip:A@A >>> Route: sip:A >>> >>> Again, probably T should use the domain in the Route header for=20 >>> certificate validation. But A can't validate the certificate's=20 >>> domain >=20 >>> (T) against the From header (B) - it will fail. >>> >>> Similar problem arise in a forwarding scenario - A-->B which=20 >>> forwards >=20 >>> it's call to C. The suggested L5 validation will fail (except B uses >>> a B2BUA, and IMO a B2BUA should not be mandatory). >>> >>>> This does not assume sips works (whatever that means), and does not >>> assume >>>> endpoints implement TLS, or either the originating or terminating >>> domains >>>> deploy TLS anywhere else. >>>> >>>> It does provide a reasonable degree of protection across the=20 >>>> peering >=20 >>>> point, which I think is a good thing. >>> Yes, TLS provides protection, but we should not specify a broken L5=20 >>> certificate validation. >>> >>>> Having lived with protocols that offered options like IPsec and=20 >>>> VPNs >=20 >>>> and other mechanisms, I think that despite the fact that you can,=20 >>>> in >=20 >>>> theory, create a satisfactory security arrangement, it is=20 >>>> exceedingly hard to >>> make >>>> it actually work except for cases where there is an entity that >>> completely >>>> controls all aspects of the peering. That just isn't the case for=20 >>>> what >>> I >>>> think we are trying to specify here (such cases don't need IETF=20 >>>> standardization). Thus, I personally think mandating TLS is a good >>> thing, >>>> achievable, and reasonable. That's a MUST IMPLEMENT, not a must=20 >>>> deploy; >>> Yes, I agree. I want TLS in the specs too - but we have to specify=20 >>> the validation more precisely and it has to work in other scenarios=20 >>> than a basic call too. Otherwise people wont use it. >>> >>> regards >>> Klaus >=20 >=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 Thu Jul 27 11:29:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67nP-0007wB-RY; Thu, 27 Jul 2006 11:29:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67nO-0007tX-Ic for speermint@ietf.org; Thu, 27 Jul 2006 11:29:06 -0400 Received: from outbound-red.frontbridge.com ([216.148.222.49] helo=outbound1-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G67nN-0004H3-6u for speermint@ietf.org; Thu, 27 Jul 2006 11:29:06 -0400 Received: from outbound1-red.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-red-R.bigfish.com (Postfix) with ESMTP id E73A6EAE308; Thu, 27 Jul 2006 15:29:04 +0000 (UTC) Received: from mail14-red-R.bigfish.com (unknown [172.18.12.3]) by outbound1-red.bigfish.com (Postfix) with ESMTP id DDC81EAE2C5; Thu, 27 Jul 2006 15:29:04 +0000 (UTC) Received: from mail14-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail14-red-R.bigfish.com (Postfix) with ESMTP id CD4243153EA; Thu, 27 Jul 2006 15:29:04 +0000 (UTC) X-BigFish: V Received: by mail14-red (MessageSwitch) id 1154014144753970_14751; Thu, 27 Jul 2006 15:29:04 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail14-red.bigfish.com (Postfix) with ESMTP id 97A3F314DFD; Thu, 27 Jul 2006 15:29:04 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k6RFT3Ag004549; Thu, 27 Jul 2006 10:29:03 -0500 (CDT) Received: from plswg02a.ad.sprint.com (PLSWG02A.corp.sprint.com [10.214.11.48]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k6RFS9X18008; Thu, 27 Jul 2006 10:28:09 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg02a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 10:28:08 -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, 27 Jul 2006 10:28:03 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A13020F10E4@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft-ietf-speermint-requirements-00.txt Thread-Index: AcaEEdBAV/nhiie0SOG4l7wbr22a4gADATtAAAGGBKAAApa2AAtYWN6w From: "Khan, Sohel Q [CTO]" To: "Jean-Francois Mule" , X-OriginalArrivalTime: 27 Jul 2006 15:28:08.0338 (UTC) FILETIME=[43418720:01C6B191] X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Speermint] Draft-ietf-speermint-requirements-00.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 =20 These issues were discussed before; however, I am trying to reopen the discussion. Section 3.3: On Codec requirements:=20 A minimum set of Codecs needs to be supported that includes EvRC. On Editor's note: Fax, DTMF signaling, TTY/TDD, instant messaging, and presence need to be supported. Thank you. Sohel Khan, Ph.D. Technology Strategist Sprint-Nextel 913-794-1470 (office) 913-486-3145 (cell) _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 27 14:01:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AAc-0003DV-23; Thu, 27 Jul 2006 14:01:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AAb-0003DQ-1f for speermint@ietf.org; Thu, 27 Jul 2006 14:01:13 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6AAZ-0005tJ-Ki for speermint@ietf.org; Thu, 27 Jul 2006 14:01:13 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Thu, 27 Jul 2006 11:01:01 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k6RHxCBl026038; Thu, 27 Jul 2006 10:59:13 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k6RI0RRS007360; Thu, 27 Jul 2006 11:00:43 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 11:00:42 -0700 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, 27 Jul 2006 11:00:36 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D2206C4A3@namail5.corp.adobe.com> In-Reply-To: <858217C310A3D94182FA8AAE42860A13020F10E4@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Voice codecs Thread-Index: AcaEEdBAV/nhiie0SOG4l7wbr22a4gADATtAAAGGBKAAApa2AAtYWN6wAAWfC6A= From: "Henry Sinnreich" To: "Khan, Sohel Q [CTO]" , "Jean-Francois Mule" , X-OriginalArrivalTime: 27 Jul 2006 18:00:42.0493 (UTC) FILETIME=[938EBAD0:01C6B1A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Greg Herlein , Ed Okerson Subject: [Speermint] Voice codecs 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 Sohel, > A minimum set of Codecs needs to be supported that includes EvRC. How does the EvRC codec compare to the 'Internet Codecs' iLBC and SPEEX? - Open source code? - Licensing fees? - Audio bandwidth? - Audio quality package? - APIs and codec abstraction for developers? - Independent lab quality assessments, etc.? More generic:=20 How do all such closed, licensed, _narrowband voice only_ codecs benefit global Internet communications and why should the IETF care? Have you heard of broadband? :-)=20 (Note: I am a happy EVDO Sprint user).=20 Thanks, Henry -----Original Message----- From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com]=20 Sent: Thursday, July 27, 2006 10:28 AM To: Jean-Francois Mule; speermint@ietf.org Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt =20 These issues were discussed before; however, I am trying to reopen the discussion. Section 3.3: On Codec requirements:=20 A minimum set of Codecs needs to be supported that includes EvRC. On Editor's note: Fax, DTMF signaling, TTY/TDD, instant messaging, and presence need to be supported. Thank you. Sohel Khan, Ph.D. Technology Strategist Sprint-Nextel 913-794-1470 (office) 913-486-3145 (cell) _______________________________________________ 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 Jul 27 14:04:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ADp-00012o-Vt; Thu, 27 Jul 2006 14:04:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ADo-0000xD-EP for speermint@ietf.org; Thu, 27 Jul 2006 14:04:32 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6ADn-0006hQ-1n for speermint@ietf.org; Thu, 27 Jul 2006 14:04:32 -0400 Received: from source ([192.150.11.134]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Thu, 27 Jul 2006 11:04:24 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k6RI2cBl026766; Thu, 27 Jul 2006 11:02:38 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k6RI4LR0008015; Thu, 27 Jul 2006 11:04:22 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 11:04:20 -0700 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, 27 Jul 2006 11:04:11 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D2206C4A4@namail5.corp.adobe.com> In-Reply-To: <858217C310A3D94182FA8AAE42860A13020F10E4@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Voice codecs - more (should the IETF market any?) Thread-Index: AcaEEdBAV/nhiie0SOG4l7wbr22a4gADATtAAAGGBKAAApa2AAtYWN6wAAWfC6A= From: "Henry Sinnreich" To: "Khan, Sohel Q [CTO]" , "Jean-Francois Mule" , X-OriginalArrivalTime: 27 Jul 2006 18:04:20.0812 (UTC) FILETIME=[15AF90C0:01C6B1A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Greg Herlein , Ed Okerson Subject: [Speermint] Voice codecs - more (should the IETF market any?) 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 Sohel, > A minimum set of Codecs needs to be supported that includes EvRC. Why should the IETF market any specific commercial codec? How does the EvRC codec compare to the 'Internet Codecs' iLBC and SPEEX? - Open source code? - Licensing fees? - Audio bandwidth? - Audio quality package? - APIs and codec abstraction for developers? - Independent lab quality assessments, etc.? More generic:=20 How do all such closed, licensed, _narrowband voice only_ codecs benefit global Internet communications and why should the IETF care? Have you heard of broadband? :-)=20 (Note: I am a happy EVDO Sprint user).=20 Thanks, Henry -----Original Message----- From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com]=20 Sent: Thursday, July 27, 2006 10:28 AM To: Jean-Francois Mule; speermint@ietf.org Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt =20 These issues were discussed before; however, I am trying to reopen the discussion. Section 3.3: On Codec requirements:=20 A minimum set of Codecs needs to be supported that includes EvRC. On Editor's note: Fax, DTMF signaling, TTY/TDD, instant messaging, and presence need to be supported. Thank you. Sohel Khan, Ph.D. Technology Strategist Sprint-Nextel 913-794-1470 (office) 913-486-3145 (cell) _______________________________________________ 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 Jul 27 14:41:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AnH-00079z-OI; Thu, 27 Jul 2006 14:41:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AnF-00079O-T4 for speermint@ietf.org; Thu, 27 Jul 2006 14:41:09 -0400 Received: from ns.xittelecom.com ([205.151.16.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6AnE-0002Vl-KC for speermint@ietf.org; Thu, 27 Jul 2006 14:41:09 -0400 Received: from fmenard (helo=localhost) by ns.xittelecom.com with local-esmtp (Exim 3.36 #1 (Debian)) id 1G6An0-0001jU-00; Thu, 27 Jul 2006 13:40:54 -0500 Date: Thu, 27 Jul 2006 13:40:54 -0500 (EST) From: Francois Menard X-X-Sender: fmenard@localhost To: Henry Sinnreich Subject: Re: [Speermint] Voice codecs In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D2206C4A3@namail5.corp.adobe.com> Message-ID: References: <24CCCC428EFEA2469BF046DB3C7A8D2206C4A3@namail5.corp.adobe.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org, Greg Herlein , Ed Okerson 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 come from Sherbrooke and you know I vote hands down for Speex Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet than people are willing to give him credit for. F. -- Francois D. Menard Project Manager/Charge de projet Xit telecom inc. 1350 Royale # 800 Trois-Rivieres, QC, G9A 4J4 Tel: +1 819 374 2556 x 268 Cell: +1 819 692 1383 fmenard@xittelecom.com On Thu, 27 Jul 2006, Henry Sinnreich wrote: > Sohel, > >> A minimum set of Codecs needs to be supported that includes EvRC. > > How does the EvRC codec compare to the 'Internet Codecs' iLBC and SPEEX? > > - Open source code? > - Licensing fees? > - Audio bandwidth? > - Audio quality package? > - APIs and codec abstraction for developers? > - Independent lab quality assessments, etc.? > > More generic: > > How do all such closed, licensed, _narrowband voice only_ codecs benefit > global Internet communications and why should the IETF care? > > Have you heard of broadband? :-) > (Note: I am a happy EVDO Sprint user). > > Thanks, Henry > > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Thursday, July 27, 2006 10:28 AM > To: Jean-Francois Mule; speermint@ietf.org > Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt > > > These issues were discussed before; however, I am trying to reopen the > discussion. > > Section 3.3: > > On Codec requirements: > A minimum set of Codecs needs to be supported that includes EvRC. > > On Editor's note: > Fax, DTMF signaling, TTY/TDD, instant messaging, and presence need to be > supported. > > > Thank you. > > Sohel Khan, Ph.D. > Technology Strategist > Sprint-Nextel > 913-794-1470 (office) > 913-486-3145 (cell) > > > > > > > _______________________________________________ > 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 Thu Jul 27 14:53:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AzF-0007md-UF; Thu, 27 Jul 2006 14:53:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AzE-0007ln-7i for speermint@ietf.org; Thu, 27 Jul 2006 14:53:32 -0400 Received: from outbound-ash.frontbridge.com ([206.16.192.249] helo=outbound1-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Az8-0003Xw-Hl for speermint@ietf.org; Thu, 27 Jul 2006 14:53:32 -0400 Received: from outbound1-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-ash-R.bigfish.com (Postfix) with ESMTP id E19F9FD412E; Thu, 27 Jul 2006 18:50:48 +0000 (UTC) Received: from mail78-ash-R.bigfish.com (unknown [172.18.2.3]) by outbound1-ash.bigfish.com (Postfix) with ESMTP id D7FF7FD412A; Thu, 27 Jul 2006 18:50:48 +0000 (UTC) Received: from mail78-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail78-ash-R.bigfish.com (Postfix) with ESMTP id CD94F56C527; Thu, 27 Jul 2006 18:50:48 +0000 (UTC) X-BigFish: V Received: by mail78-ash (MessageSwitch) id 1154026248432860_32593; Thu, 27 Jul 2006 18:50:48 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail78-ash.bigfish.com (Postfix) with ESMTP id 92CEF56C2B6; Thu, 27 Jul 2006 18:50:11 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k6RIo7pu024536; Thu, 27 Jul 2006 13:50:07 -0500 (CDT) Received: from pdawg06a.ad.sprint.com (PDAWG06A.corp.sprint.com [10.122.2.33]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k6RIkKX28767; Thu, 27 Jul 2006 13:46:20 -0500 (CDT) Received: from PDAWB14C.ad.sprint.com ([144.226.76.137]) by pdawg06a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 13:46:18 -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] Voice codecs Date: Thu, 27 Jul 2006 13:46:16 -0500 Message-ID: <1A8DCAFC5DC73B4D94081BDCF028A20306059522@PDAWB14C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: AcaxrEJCSQnXXLB/RoGRW9fZYY4yJQAABBhQ From: "Lipford, Mark A [CTO]" To: "Francois Menard" , "Henry Sinnreich" X-OriginalArrivalTime: 27 Jul 2006 18:46:18.0034 (UTC) FILETIME=[F2112920:01C6B1AC] X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org, Greg Herlein , Ed Okerson 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 is in response to the question to Sohel regarding Broadband. Yes, we are very involved in broadband, and believe wireless broadband will become extremely active in the next few years, but the reality is that in the 3G work both EVRC and AMR are both widely deployed and with IMS deployments starting to "spring up" around the global it is probably important to also consider these needs. Can we support some mechanism for support codec negotiations with a default "fall back" to G.711 or some other well known default? I do believe that we need to also consider the narrowband deployments. Thanks -----Original Message----- From: Francois Menard [mailto:fmenard@xittelecom.com]=20 Sent: Thursday, July 27, 2006 1:41 PM To: Henry Sinnreich Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Ed Okerson Subject: Re: [Speermint] Voice codecs I come from Sherbrooke and you know I vote hands down for Speex Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet than=20 people are willing to give him credit for. F. -- Francois D. Menard Project Manager/Charge de projet Xit telecom inc. 1350 Royale # 800 Trois-Rivieres, QC, G9A 4J4 Tel: +1 819 374 2556 x 268 Cell: +1 819 692 1383 fmenard@xittelecom.com On Thu, 27 Jul 2006, Henry Sinnreich wrote: > Sohel, > >> A minimum set of Codecs needs to be supported that includes EvRC. > > How does the EvRC codec compare to the 'Internet Codecs' iLBC and SPEEX? > > - Open source code? > - Licensing fees? > - Audio bandwidth? > - Audio quality package? > - APIs and codec abstraction for developers? > - Independent lab quality assessments, etc.? > > More generic: > > How do all such closed, licensed, _narrowband voice only_ codecs benefit > global Internet communications and why should the IETF care? > > Have you heard of broadband? :-) > (Note: I am a happy EVDO Sprint user). > > Thanks, Henry > > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Thursday, July 27, 2006 10:28 AM > To: Jean-Francois Mule; speermint@ietf.org > Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt > > > These issues were discussed before; however, I am trying to reopen the > discussion. > > Section 3.3: > > On Codec requirements: > A minimum set of Codecs needs to be supported that includes EvRC. > > On Editor's note: > Fax, DTMF signaling, TTY/TDD, instant messaging, and presence need to be > supported. > > > Thank you. > > Sohel Khan, Ph.D. > Technology Strategist > Sprint-Nextel > 913-794-1470 (office) > 913-486-3145 (cell) > > > > > > > _______________________________________________ > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 27 16:01:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6C3G-000768-Aa; Thu, 27 Jul 2006 16:01:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6C3F-00070g-KH for speermint@ietf.org; Thu, 27 Jul 2006 16:01:45 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6C3D-0003Re-3z for speermint@ietf.org; Thu, 27 Jul 2006 16:01:45 -0400 Received: from source ([192.150.11.134]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Thu, 27 Jul 2006 13:01:30 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k6RJxVBl015503; Thu, 27 Jul 2006 12:59:36 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k6RK1AQw021089; Thu, 27 Jul 2006 13:01:11 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 13:01:10 -0700 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] Voice codecs Date: Thu, 27 Jul 2006 13:00:43 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D2206C4A7@namail5.corp.adobe.com> In-Reply-To: <1A8DCAFC5DC73B4D94081BDCF028A20306059522@PDAWB14C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: AcaxrEJCSQnXXLB/RoGRW9fZYY4yJQAABBhQAAJtjKA= From: "Henry Sinnreich" To: "Lipford, Mark A [CTO]" X-OriginalArrivalTime: 27 Jul 2006 20:01:10.0052 (UTC) FILETIME=[6784B640:01C6B1B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org, Greg Herlein , Ed Okerson 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 Mark Lipford writes: > Can we support some mechanism for support codec negotiations with=20 > a default "fall back" to G.711 Technically, the uncompressed G.711 (1960's PCM) is definitely the worst choice for a default: - Narrow band telephony at 3.1 kHz audio bandwidth (why do we have BB?) - Highest bandwidth consumed: Almost 90 kb/s with RTP/UDP/IP overhead - There are better mechanisms for Fax. Why do you avoid SPEEX and iLBC (RFC 3951 and RFC 3952) and what are your selection criteria? Can you explain? Thanks, Henry -----Original Message----- From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com]=20 Sent: Thursday, July 27, 2006 1:46 PM To: Francois Menard; Henry Sinnreich Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Ed Okerson Subject: RE: [Speermint] Voice codecs This is in response to the question to Sohel regarding Broadband. Yes, we are very involved in broadband, and believe wireless broadband will become extremely active in the next few years, but the reality is that in the 3G work both EVRC and AMR are both widely deployed and with IMS deployments starting to "spring up" around the global it is probably important to also consider these needs. Can we support some mechanism for support codec negotiations with a default "fall back" to G.711 or some other well known default? I do believe that we need to also consider the narrowband deployments. Thanks -----Original Message----- From: Francois Menard [mailto:fmenard@xittelecom.com]=20 Sent: Thursday, July 27, 2006 1:41 PM To: Henry Sinnreich Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Ed Okerson Subject: Re: [Speermint] Voice codecs I come from Sherbrooke and you know I vote hands down for Speex Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet than=20 people are willing to give him credit for. F. -- Francois D. Menard Project Manager/Charge de projet Xit telecom inc. 1350 Royale # 800 Trois-Rivieres, QC, G9A 4J4 Tel: +1 819 374 2556 x 268 Cell: +1 819 692 1383 fmenard@xittelecom.com On Thu, 27 Jul 2006, Henry Sinnreich wrote: > Sohel, > >> A minimum set of Codecs needs to be supported that includes EvRC. > > How does the EvRC codec compare to the 'Internet Codecs' iLBC and SPEEX? > > - Open source code? > - Licensing fees? > - Audio bandwidth? > - Audio quality package? > - APIs and codec abstraction for developers? > - Independent lab quality assessments, etc.? > > More generic: > > How do all such closed, licensed, _narrowband voice only_ codecs benefit > global Internet communications and why should the IETF care? > > Have you heard of broadband? :-) > (Note: I am a happy EVDO Sprint user). > > Thanks, Henry > > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Thursday, July 27, 2006 10:28 AM > To: Jean-Francois Mule; speermint@ietf.org > Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt > > > These issues were discussed before; however, I am trying to reopen the > discussion. > > Section 3.3: > > On Codec requirements: > A minimum set of Codecs needs to be supported that includes EvRC. > > On Editor's note: > Fax, DTMF signaling, TTY/TDD, instant messaging, and presence need to be > supported. > > > Thank you. > > Sohel Khan, Ph.D. > Technology Strategist > Sprint-Nextel > 913-794-1470 (office) > 913-486-3145 (cell) > > > > > > > _______________________________________________ > 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 _______________________________________________ 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 Jul 27 16:28:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CT4-0005Je-Qo; Thu, 27 Jul 2006 16:28:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CT3-0005JW-JI for speermint@ietf.org; Thu, 27 Jul 2006 16:28:25 -0400 Received: from outbound-red.frontbridge.com ([216.148.222.49] helo=outbound1-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6CSy-0001xO-HV for speermint@ietf.org; Thu, 27 Jul 2006 16:28:25 -0400 Received: from outbound1-red.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-red-R.bigfish.com (Postfix) with ESMTP id 1CA91EB41DC; Thu, 27 Jul 2006 20:27:12 +0000 (UTC) Received: from mail34-red-R.bigfish.com (unknown [172.18.12.3]) by outbound1-red.bigfish.com (Postfix) with ESMTP id 11D21EB41DA; Thu, 27 Jul 2006 20:27:12 +0000 (UTC) Received: from mail34-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail34-red-R.bigfish.com (Postfix) with ESMTP id 0591551D8C6; Thu, 27 Jul 2006 20:27:12 +0000 (UTC) X-BigFish: V Received: by mail34-red (MessageSwitch) id 1154032031944904_29237; Thu, 27 Jul 2006 20:27:11 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail34-red.bigfish.com (Postfix) with ESMTP id C35D851D8C6; Thu, 27 Jul 2006 20:27:11 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k6RKRBAg004093; Thu, 27 Jul 2006 15:27:11 -0500 (CDT) Received: from plswg02a.ad.sprint.com (PLSWG02A.corp.sprint.com [10.214.11.48]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k6RKRAX21421; Thu, 27 Jul 2006 15:27:10 -0500 (CDT) Received: from PDAWB14C.ad.sprint.com ([144.226.76.137]) by plswg02a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 15:27:10 -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] Voice codecs Date: Thu, 27 Jul 2006 15:27:09 -0500 Message-ID: <1A8DCAFC5DC73B4D94081BDCF028A20306059536@PDAWB14C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: AcaxrEJCSQnXXLB/RoGRW9fZYY4yJQAABBhQAAJtjKAAARvgMA== From: "Lipford, Mark A [CTO]" To: "Henry Sinnreich" X-OriginalArrivalTime: 27 Jul 2006 20:27:10.0182 (UTC) FILETIME=[096DA860:01C6B1BB] X-Spam-Score: 0.1 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org, Greg Herlein , Ed Okerson 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 See inline -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Thursday, July 27, 2006 3:01 PM To: Lipford, Mark A [CTO] Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois Menard; Ed Okerson Subject: RE: [Speermint] Voice codecs Mark Lipford writes: > Can we support some mechanism for support codec negotiations with=20 > a default "fall back" to G.711 Technically, the uncompressed G.711 (1960's PCM) is definitely the worst choice for a default: - Narrow band telephony at 3.1 kHz audio bandwidth (why do we have BB?) - Highest bandwidth consumed: Almost 90 kb/s with RTP/UDP/IP overhead - There are better mechanisms for Fax. Why do you avoid SPEEX and iLBC (RFC 3951 and RFC 3952) and what are your selection criteria? Can you explain? [Lipford, Mark A [NTK]] I am OK with SPEEX and iLBC as defaults, I used G.711 due to 19 years in Telco :-) The main point I was wanting to try and gain some agreement around is that narrowband (i.e. 3GPP and 3GPP2 3G networks) is/are deploying IMS networks and using EVRC and AMR. The I-D I am looking at is about Requirements for VoIP interconnection. If this is the case it appears that support for these codecs seems to make some sense. Again, as far as SEEX and iLBC are concerned that's OK, I'm just an old telco guy. Thanks, Henry -----Original Message----- From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com]=20 Sent: Thursday, July 27, 2006 1:46 PM To: Francois Menard; Henry Sinnreich Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Ed Okerson Subject: RE: [Speermint] Voice codecs This is in response to the question to Sohel regarding Broadband. Yes, we are very involved in broadband, and believe wireless broadband will become extremely active in the next few years, but the reality is that in the 3G work both EVRC and AMR are both widely deployed and with IMS deployments starting to "spring up" around the global it is probably important to also consider these needs. Can we support some mechanism for support codec negotiations with a default "fall back" to G.711 or some other well known default? I do believe that we need to also consider the narrowband deployments. Thanks -----Original Message----- From: Francois Menard [mailto:fmenard@xittelecom.com]=20 Sent: Thursday, July 27, 2006 1:41 PM To: Henry Sinnreich Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Ed Okerson Subject: Re: [Speermint] Voice codecs I come from Sherbrooke and you know I vote hands down for Speex Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet than=20 people are willing to give him credit for. F. -- Francois D. Menard Project Manager/Charge de projet Xit telecom inc. 1350 Royale # 800 Trois-Rivieres, QC, G9A 4J4 Tel: +1 819 374 2556 x 268 Cell: +1 819 692 1383 fmenard@xittelecom.com On Thu, 27 Jul 2006, Henry Sinnreich wrote: > Sohel, > >> A minimum set of Codecs needs to be supported that includes EvRC. > > How does the EvRC codec compare to the 'Internet Codecs' iLBC and SPEEX? > > - Open source code? > - Licensing fees? > - Audio bandwidth? > - Audio quality package? > - APIs and codec abstraction for developers? > - Independent lab quality assessments, etc.? > > More generic: > > How do all such closed, licensed, _narrowband voice only_ codecs benefit > global Internet communications and why should the IETF care? > > Have you heard of broadband? :-) > (Note: I am a happy EVDO Sprint user). > > Thanks, Henry > > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Thursday, July 27, 2006 10:28 AM > To: Jean-Francois Mule; speermint@ietf.org > Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt > > > These issues were discussed before; however, I am trying to reopen the > discussion. > > Section 3.3: > > On Codec requirements: > A minimum set of Codecs needs to be supported that includes EvRC. > > On Editor's note: > Fax, DTMF signaling, TTY/TDD, instant messaging, and presence need to be > supported. > > > Thank you. > > Sohel Khan, Ph.D. > Technology Strategist > Sprint-Nextel > 913-794-1470 (office) > 913-486-3145 (cell) > > > > > > > _______________________________________________ > 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 _______________________________________________ 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 Jul 27 16:59:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CxS-00080z-CF; Thu, 27 Jul 2006 16:59:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CxR-00080u-B2 for speermint@ietf.org; Thu, 27 Jul 2006 16:59:49 -0400 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6CxO-0003Fw-NL for speermint@ietf.org; Thu, 27 Jul 2006 16:59:49 -0400 Received: from source ([192.150.11.134]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Thu, 27 Jul 2006 13:59:41 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k6RKvoBl024367; Thu, 27 Jul 2006 13:57:50 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k6RKxPR4027155; Thu, 27 Jul 2006 13:59:34 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 13:59:27 -0700 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] Voice codecs Date: Thu, 27 Jul 2006 13:59:07 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D2206C4AB@namail5.corp.adobe.com> In-Reply-To: <1A8DCAFC5DC73B4D94081BDCF028A20306059536@PDAWB14C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: AcaxrEJCSQnXXLB/RoGRW9fZYY4yJQAABBhQAAJtjKAAARvgMAABEkLA From: "Henry Sinnreich" To: "Lipford, Mark A [CTO]" X-OriginalArrivalTime: 27 Jul 2006 20:59:27.0273 (UTC) FILETIME=[8C064990:01C6B1BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: "Khan, Sohel Q \[CTO\]" , speermint@ietf.org, Greg Herlein , Ed Okerson 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 Mark Lipford writes: > I am OK with SPEEX and iLBC as defaults Thanks and I am very happy we can come closer to an agreement on this! Are there any other opinions on using SPEEX and iLBC (RFC 3951 and RFC 3952) as defaults for IP-IP broadband? Thanks again, Henry -----Original Message----- From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com]=20 Sent: Thursday, July 27, 2006 3:27 PM To: Henry Sinnreich Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois Menard; Ed Okerson Subject: RE: [Speermint] Voice codecs See inline -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Thursday, July 27, 2006 3:01 PM To: Lipford, Mark A [CTO] Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois Menard; Ed Okerson Subject: RE: [Speermint] Voice codecs Mark Lipford writes: > Can we support some mechanism for support codec negotiations with=20 > a default "fall back" to G.711 Technically, the uncompressed G.711 (1960's PCM) is definitely the worst choice for a default: - Narrow band telephony at 3.1 kHz audio bandwidth (why do we have BB?) - Highest bandwidth consumed: Almost 90 kb/s with RTP/UDP/IP overhead - There are better mechanisms for Fax. Why do you avoid SPEEX and iLBC (RFC 3951 and RFC 3952) and what are your selection criteria? Can you explain? [Lipford, Mark A [NTK]] I am OK with SPEEX and iLBC as defaults, I used G.711 due to 19 years in Telco :-) The main point I was wanting to try and gain some agreement around is that narrowband (i.e. 3GPP and 3GPP2 3G networks) is/are deploying IMS networks and using EVRC and AMR. The I-D I am looking at is about Requirements for VoIP interconnection. If this is the case it appears that support for these codecs seems to make some sense. Again, as far as SEEX and iLBC are concerned that's OK, I'm just an old telco guy. Thanks, Henry -----Original Message----- From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com]=20 Sent: Thursday, July 27, 2006 1:46 PM To: Francois Menard; Henry Sinnreich Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Ed Okerson Subject: RE: [Speermint] Voice codecs This is in response to the question to Sohel regarding Broadband. Yes, we are very involved in broadband, and believe wireless broadband will become extremely active in the next few years, but the reality is that in the 3G work both EVRC and AMR are both widely deployed and with IMS deployments starting to "spring up" around the global it is probably important to also consider these needs. Can we support some mechanism for support codec negotiations with a default "fall back" to G.711 or some other well known default? I do believe that we need to also consider the narrowband deployments. Thanks -----Original Message----- From: Francois Menard [mailto:fmenard@xittelecom.com]=20 Sent: Thursday, July 27, 2006 1:41 PM To: Henry Sinnreich Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Ed Okerson Subject: Re: [Speermint] Voice codecs I come from Sherbrooke and you know I vote hands down for Speex Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet than=20 people are willing to give him credit for. F. -- Francois D. Menard Project Manager/Charge de projet Xit telecom inc. 1350 Royale # 800 Trois-Rivieres, QC, G9A 4J4 Tel: +1 819 374 2556 x 268 Cell: +1 819 692 1383 fmenard@xittelecom.com On Thu, 27 Jul 2006, Henry Sinnreich wrote: > Sohel, > >> A minimum set of Codecs needs to be supported that includes EvRC. > > How does the EvRC codec compare to the 'Internet Codecs' iLBC and SPEEX? > > - Open source code? > - Licensing fees? > - Audio bandwidth? > - Audio quality package? > - APIs and codec abstraction for developers? > - Independent lab quality assessments, etc.? > > More generic: > > How do all such closed, licensed, _narrowband voice only_ codecs benefit > global Internet communications and why should the IETF care? > > Have you heard of broadband? :-) > (Note: I am a happy EVDO Sprint user). > > Thanks, Henry > > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Thursday, July 27, 2006 10:28 AM > To: Jean-Francois Mule; speermint@ietf.org > Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt > > > These issues were discussed before; however, I am trying to reopen the > discussion. > > Section 3.3: > > On Codec requirements: > A minimum set of Codecs needs to be supported that includes EvRC. > > On Editor's note: > Fax, DTMF signaling, TTY/TDD, instant messaging, and presence need to be > supported. > > > Thank you. > > Sohel Khan, Ph.D. > Technology Strategist > Sprint-Nextel > 913-794-1470 (office) > 913-486-3145 (cell) > > > > > > > _______________________________________________ > 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 _______________________________________________ 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 Jul 27 18:58:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Ent-0007sZ-7g; Thu, 27 Jul 2006 18:58:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Ens-0007sH-5Z for speermint@ietf.org; Thu, 27 Jul 2006 18:58:04 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Enr-0002us-L1 for speermint@ietf.org; Thu, 27 Jul 2006 18:58:04 -0400 Received: from pb94.dyndns.org (localhost [127.0.0.1]) by pb94.dyndns.org (Postfix) with ESMTP id 96E6C21006E; Fri, 28 Jul 2006 00:58:02 +0200 (CEST) Received: from 212.17.67.197 (SquirrelMail authenticated user klaus.mailinglists@pernau.at) by pb94.dyndns.org with HTTP; Fri, 28 Jul 2006 00:58:02 +0200 (CEST) Message-ID: <61946.212.17.67.197.1154041082.squirrel@pb94.dyndns.org> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D2206C4AB@namail5.corp.adobe.com> References: <1A8DCAFC5DC73B4D94081BDCF028A20306059536@PDAWB14C.ad.sprint.com> <24CCCC428EFEA2469BF046DB3C7A8D2206C4AB@namail5.corp.adobe.com> Date: Fri, 28 Jul 2006 00:58:02 +0200 (CEST) Subject: RE: [Speermint] Voice codecs From: "Klaus Darilion" To: "Henry Sinnreich" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: speermint@ietf.org, Greg Herlein , Ed Okerson , "Lipford, Mark A \[CTO\]" 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 Thu, July 27, 2006 22:59, Henry Sinnreich said: > Mark Lipford writes: > >> I am OK with SPEEX and iLBC as defaults > > Thanks and I am very happy we can come closer to an agreement on this! > > Are there any other opinions on using SPEEX and iLBC (RFC 3951 and RFC > 3952) as defaults for IP-IP broadband? Yes. Please count the number of terminal adaptor and SIP hardphones that support SPEEX and iLBC versus G.711. regards klaus > > Thanks again, Henry > > -----Original Message----- > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > Sent: Thursday, July 27, 2006 3:27 PM > To: Henry Sinnreich > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois > Menard; Ed Okerson > Subject: RE: [Speermint] Voice codecs > > See inline > > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Thursday, July 27, 2006 3:01 PM > To: Lipford, Mark A [CTO] > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois > Menard; Ed Okerson > Subject: RE: [Speermint] Voice codecs > > Mark Lipford writes: > >> Can we support some mechanism for support codec negotiations with >> a default "fall back" to G.711 > > Technically, the uncompressed G.711 (1960's PCM) is definitely the wors= t > choice for a default: > > - Narrow band telephony at 3.1 kHz audio bandwidth (why do we have BB?) > - Highest bandwidth consumed: Almost 90 kb/s with RTP/UDP/IP overhead > - There are better mechanisms for Fax. > > Why do you avoid SPEEX and iLBC (RFC 3951 and RFC 3952) and what are > your selection criteria? Can you explain? > [Lipford, Mark A [NTK]] I am OK with SPEEX and iLBC as defaults, I used > G.711 due to 19 years in Telco :-) The main point I was wanting to try > and gain some agreement around is that narrowband (i.e. 3GPP and 3GPP2 > 3G networks) is/are deploying IMS networks and using EVRC and AMR. The > I-D I am looking at is about Requirements for VoIP interconnection. If > this is the case it appears that support for these codecs seems to make > some sense. Again, as far as SEEX and iLBC are concerned that's OK, I'= m > just an old telco guy. > > > > Thanks, Henry > > -----Original Message----- > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > Sent: Thursday, July 27, 2006 1:46 PM > To: Francois Menard; Henry Sinnreich > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Ed Okerson > Subject: RE: [Speermint] Voice codecs > > This is in response to the question to Sohel regarding Broadband. > > Yes, we are very involved in broadband, and believe wireless broadband > will become extremely active in the next few years, but the reality is > that in the 3G work both EVRC and AMR are both widely deployed and with > IMS deployments starting to "spring up" around the global it is probabl= y > important to also consider these needs. > > Can we support some mechanism for support codec negotiations with a > default "fall back" to G.711 or some other well known default? > > I do believe that we need to also consider the narrowband deployments. > > Thanks > > -----Original Message----- > From: Francois Menard [mailto:fmenard@xittelecom.com] > Sent: Thursday, July 27, 2006 1:41 PM > To: Henry Sinnreich > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Ed Okerson > Subject: Re: [Speermint] Voice codecs > > > I come from Sherbrooke and you know I vote hands down for Speex > > Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet than > people are willing to give him credit for. > > F. > > -- > Francois D. Menard > Project Manager/Charge de projet > Xit telecom inc. > 1350 Royale # 800 > Trois-Rivieres, QC, G9A 4J4 > Tel: +1 819 374 2556 x 268 > Cell: +1 819 692 1383 > fmenard@xittelecom.com > > > On Thu, 27 Jul 2006, Henry Sinnreich wrote: > >> Sohel, >> >>> A minimum set of Codecs needs to be supported that includes EvRC. >> >> How does the EvRC codec compare to the 'Internet Codecs' iLBC and > SPEEX? >> >> - Open source code? >> - Licensing fees? >> - Audio bandwidth? >> - Audio quality package? >> - APIs and codec abstraction for developers? >> - Independent lab quality assessments, etc.? >> >> More generic: >> >> How do all such closed, licensed, _narrowband voice only_ codecs > benefit >> global Internet communications and why should the IETF care? >> >> Have you heard of broadband? :-) >> (Note: I am a happy EVDO Sprint user). >> >> Thanks, Henry >> >> -----Original Message----- >> From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] >> Sent: Thursday, July 27, 2006 10:28 AM >> To: Jean-Francois Mule; speermint@ietf.org >> Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt >> >> >> These issues were discussed before; however, I am trying to reopen the >> discussion. >> >> Section 3.3: >> >> On Codec requirements: >> A minimum set of Codecs needs to be supported that includes EvRC. >> >> On Editor's note: >> Fax, DTMF signaling, TTY/TDD, instant messaging, and presence need to > be >> supported. >> >> >> Thank you. >> >> Sohel Khan, Ph.D. >> Technology Strategist >> Sprint-Nextel >> 913-794-1470 (office) >> 913-486-3145 (cell) >> >> >> >> >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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 Fri Jul 28 08:46:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Rjs-0002JP-Fq; Fri, 28 Jul 2006 08:46:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Rjq-0002JI-Js for speermint@ietf.org; Fri, 28 Jul 2006 08:46:46 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Rjq-00041w-5N for speermint@ietf.org; Fri, 28 Jul 2006 08:46:46 -0400 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] Voice codecs Date: Fri, 28 Jul 2006 08:46:09 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD1A6171@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/Vw From: "Livingood, Jason" To: "Klaus Darilion" , "Henry Sinnreich" X-OriginalArrivalTime: 28 Jul 2006 12:46:20.0407 (UTC) FILETIME=[D34A9070:01C6B243] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: speermint@ietf.org, Greg Herlein , Ed Okerson , "Lipford, Mark A \[CTO\]" 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 We ought to at least recognize that in the VoIP server & equipment market G.711 is probably the one with widest deployment (someone will now surely cite Skype downloads as a datapoint, I am very familiar with it and wish someone from eBay/Skype was participating here). In wireless, it appears AMR is biggest (due to use by GSM), with EVRC in second place. This group is not going to be able to push implementation of one codec or another (nor should we), whether we like the business model or social model represented by that codec or not. We do want to figure out how to get the most people VoIP peering the fastest, and that may (or may not) necessitate some lowest common denominator codecs. That is far from a foregone conclusion and is a subject that will have to be worked out by the WG over time. This of course would not preclude use of other codecs and then endpoints could use SIP to (normally) negotiate a different / preferred codec that may be newer, lower bandwidth, higher fidelity, less expensive to license, etc. This may also be a moot point in the near future. A recent conversation with an endpoint maker gave me the impression that it will be pretty easy to have all of the codecs we have mentioned here in a very low cost endpoint in the near future. Any hardware makers wish to comment on the futures / possibilities? So keep up the discussion...=20 Jason=20 > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 > Sent: Thursday, July 27, 2006 6:58 PM > To: Henry Sinnreich > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford,Mark A [CTO] > Subject: RE: [Speermint] Voice codecs >=20 > On Thu, July 27, 2006 22:59, Henry Sinnreich said: > > Mark Lipford writes: > > > >> I am OK with SPEEX and iLBC as defaults > > > > Thanks and I am very happy we can come closer to an=20 > agreement on this! > > > > Are there any other opinions on using SPEEX and iLBC (RFC=20 > 3951 and RFC > > 3952) as defaults for IP-IP broadband? >=20 > Yes. Please count the number of terminal adaptor and SIP=20 > hardphones that support SPEEX and iLBC versus G.711. >=20 > regards > klaus >=20 >=20 > > > > Thanks again, Henry > > > > -----Original Message----- > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > Sent: Thursday, July 27, 2006 3:27 PM > > To: Henry Sinnreich > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois=20 > > Menard; Ed Okerson > > Subject: RE: [Speermint] Voice codecs > > > > See inline > > > > -----Original Message----- > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > Sent: Thursday, July 27, 2006 3:01 PM > > To: Lipford, Mark A [CTO] > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois=20 > > Menard; Ed Okerson > > Subject: RE: [Speermint] Voice codecs > > > > Mark Lipford writes: > > > >> Can we support some mechanism for support codec=20 > negotiations with a=20 > >> default "fall back" to G.711 > > > > Technically, the uncompressed G.711 (1960's PCM) is definitely the=20 > > worst choice for a default: > > > > - Narrow band telephony at 3.1 kHz audio bandwidth (why do we have=20 > > BB?) > > - Highest bandwidth consumed: Almost 90 kb/s with=20 > RTP/UDP/IP overhead > > - There are better mechanisms for Fax. > > > > Why do you avoid SPEEX and iLBC (RFC 3951 and RFC 3952) and=20 > what are=20 > > your selection criteria? Can you explain? > > [Lipford, Mark A [NTK]] I am OK with SPEEX and iLBC as defaults, I=20 > > used > > G.711 due to 19 years in Telco :-) The main point I was wanting to=20 > > try and gain some agreement around is that narrowband (i.e.=20 > 3GPP and=20 > > 3GPP2 3G networks) is/are deploying IMS networks and using EVRC and=20 > > AMR. The I-D I am looking at is about Requirements for VoIP=20 > > interconnection. If this is the case it appears that support for=20 > > these codecs seems to make some sense. Again, as far as=20 > SEEX and iLBC=20 > > are concerned that's OK, I'm just an old telco guy. > > > > > > > > Thanks, Henry > > > > -----Original Message----- > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > Sent: Thursday, July 27, 2006 1:46 PM > > To: Francois Menard; Henry Sinnreich > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein;=20 > Ed Okerson > > Subject: RE: [Speermint] Voice codecs > > > > This is in response to the question to Sohel regarding Broadband. > > > > Yes, we are very involved in broadband, and believe=20 > wireless broadband=20 > > will become extremely active in the next few years, but the=20 > reality is=20 > > that in the 3G work both EVRC and AMR are both widely deployed and=20 > > with IMS deployments starting to "spring up" around the=20 > global it is=20 > > probably important to also consider these needs. > > > > Can we support some mechanism for support codec negotiations with a=20 > > default "fall back" to G.711 or some other well known default? > > > > I do believe that we need to also consider the narrowband=20 > deployments. > > > > Thanks > > > > -----Original Message----- > > From: Francois Menard [mailto:fmenard@xittelecom.com] > > Sent: Thursday, July 27, 2006 1:41 PM > > To: Henry Sinnreich > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein;=20 > Ed Okerson > > Subject: Re: [Speermint] Voice codecs > > > > > > I come from Sherbrooke and you know I vote hands down for Speex > > > > Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet=20 > > than people are willing to give him credit for. > > > > F. > > > > -- > > Francois D. Menard > > Project Manager/Charge de projet > > Xit telecom inc. > > 1350 Royale # 800 > > Trois-Rivieres, QC, G9A 4J4 > > Tel: +1 819 374 2556 x 268 > > Cell: +1 819 692 1383 > > fmenard@xittelecom.com > > > > > > On Thu, 27 Jul 2006, Henry Sinnreich wrote: > > > >> Sohel, > >> > >>> A minimum set of Codecs needs to be supported that includes EvRC. > >> > >> How does the EvRC codec compare to the 'Internet Codecs' iLBC and > > SPEEX? > >> > >> - Open source code? > >> - Licensing fees? > >> - Audio bandwidth? > >> - Audio quality package? > >> - APIs and codec abstraction for developers? > >> - Independent lab quality assessments, etc.? > >> > >> More generic: > >> > >> How do all such closed, licensed, _narrowband voice only_ codecs > > benefit > >> global Internet communications and why should the IETF care? > >> > >> Have you heard of broadband? :-) > >> (Note: I am a happy EVDO Sprint user). > >> > >> Thanks, Henry > >> > >> -----Original Message----- > >> From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > >> Sent: Thursday, July 27, 2006 10:28 AM > >> To: Jean-Francois Mule; speermint@ietf.org > >> Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt > >> > >> > >> These issues were discussed before; however, I am trying to reopen=20 > >> the discussion. > >> > >> Section 3.3: > >> > >> On Codec requirements: > >> A minimum set of Codecs needs to be supported that includes EvRC. > >> > >> On Editor's note: > >> Fax, DTMF signaling, TTY/TDD, instant messaging, and=20 > presence need to > > be > >> supported. > >> > >> > >> Thank you. > >> > >> Sohel Khan, Ph.D. > >> Technology Strategist > >> Sprint-Nextel > >> 913-794-1470 (office) > >> 913-486-3145 (cell) > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > > > > > _______________________________________________ > > 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 > > >=20 >=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 Fri Jul 28 09:33:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6SSb-0002lU-AZ; Fri, 28 Jul 2006 09:33:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6SSa-0002lP-6S for speermint@ietf.org; Fri, 28 Jul 2006 09:33:00 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6SSZ-0003xr-Lo for speermint@ietf.org; Fri, 28 Jul 2006 09:33:00 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G6SS9-0003hG-9c; Fri, 28 Jul 2006 08:32:33 -0500 From: "Brian Rosen" To: "'Livingood, Jason'" , "'Klaus Darilion'" , "'Henry Sinnreich'" Subject: RE: [Speermint] Voice codecs Date: Fri, 28 Jul 2006 09:32:43 -0400 Message-ID: <01f501c6b24a$4ffea3d0$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.2869 Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/A= In-Reply-To: <8587F175CDB3D741B58C79F67E8E09AD1A6171@PACDCEXCMB03.cable.comcast.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Cc: speermint@ietf.org, 'Greg Herlein' , 'Ed Okerson' , "'Lipford, Mark A \[CTO\]'" 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'm a big believer in reality. I really like SPEEX and iLBC for the reasons Henry cites, but the reality is that they are not widely implemented, and us writing them into a "must implement" spec in SPEERMINT isn't going to help deployment, it will just be another one of those "ignore here" things we sometimes do in the IETF when religion gets in front of reality. Perhaps what we say is this: A Federation specifies AT LEAST ONE mandatory codec for every media stream type (voice, video, text, ...). Each participant must be able to send or receive media in that codec, either by direct endpoint support or origination side transcoding. Brian > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Friday, July 28, 2006 8:46 AM > To: Klaus Darilion; Henry Sinnreich > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford,Mark A [CTO] > Subject: RE: [Speermint] Voice codecs > > We ought to at least recognize that in the VoIP server & equipment > market G.711 is probably the one with widest deployment (someone will > now surely cite Skype downloads as a datapoint, I am very familiar with > it and wish someone from eBay/Skype was participating here). In > wireless, it appears AMR is biggest (due to use by GSM), with EVRC in > second place. This group is not going to be able to push implementation > of one codec or another (nor should we), whether we like the business > model or social model represented by that codec or not. We do want to > figure out how to get the most people VoIP peering the fastest, and that > may (or may not) necessitate some lowest common denominator codecs. > That is far from a foregone conclusion and is a subject that will have > to be worked out by the WG over time. > > This of course would not preclude use of other codecs and then endpoints > could use SIP to (normally) negotiate a different / preferred codec that > may be newer, lower bandwidth, higher fidelity, less expensive to > license, etc. > > This may also be a moot point in the near future. A recent conversation > with an endpoint maker gave me the impression that it will be pretty > easy to have all of the codecs we have mentioned here in a very low cost > endpoint in the near future. Any hardware makers wish to comment on the > futures / possibilities? > > So keep up the discussion... > > Jason > > > -----Original Message----- > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > Sent: Thursday, July 27, 2006 6:58 PM > > To: Henry Sinnreich > > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford,Mark A [CTO] > > Subject: RE: [Speermint] Voice codecs > > > > On Thu, July 27, 2006 22:59, Henry Sinnreich said: > > > Mark Lipford writes: > > > > > >> I am OK with SPEEX and iLBC as defaults > > > > > > Thanks and I am very happy we can come closer to an > > agreement on this! > > > > > > Are there any other opinions on using SPEEX and iLBC (RFC > > 3951 and RFC > > > 3952) as defaults for IP-IP broadband? > > > > Yes. Please count the number of terminal adaptor and SIP > > hardphones that support SPEEX and iLBC versus G.711. > > > > regards > > klaus > > > > > > > > > > Thanks again, Henry > > > > > > -----Original Message----- > > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > > Sent: Thursday, July 27, 2006 3:27 PM > > > To: Henry Sinnreich > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois > > > Menard; Ed Okerson > > > Subject: RE: [Speermint] Voice codecs > > > > > > See inline > > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > Sent: Thursday, July 27, 2006 3:01 PM > > > To: Lipford, Mark A [CTO] > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois > > > Menard; Ed Okerson > > > Subject: RE: [Speermint] Voice codecs > > > > > > Mark Lipford writes: > > > > > >> Can we support some mechanism for support codec > > negotiations with a > > >> default "fall back" to G.711 > > > > > > Technically, the uncompressed G.711 (1960's PCM) is definitely the > > > worst choice for a default: > > > > > > - Narrow band telephony at 3.1 kHz audio bandwidth (why do we have > > > BB?) > > > - Highest bandwidth consumed: Almost 90 kb/s with > > RTP/UDP/IP overhead > > > - There are better mechanisms for Fax. > > > > > > Why do you avoid SPEEX and iLBC (RFC 3951 and RFC 3952) and > > what are > > > your selection criteria? Can you explain? > > > [Lipford, Mark A [NTK]] I am OK with SPEEX and iLBC as defaults, I > > > used > > > G.711 due to 19 years in Telco :-) The main point I was wanting to > > > try and gain some agreement around is that narrowband (i.e. > > 3GPP and > > > 3GPP2 3G networks) is/are deploying IMS networks and using EVRC and > > > AMR. The I-D I am looking at is about Requirements for VoIP > > > interconnection. If this is the case it appears that support for > > > these codecs seems to make some sense. Again, as far as > > SEEX and iLBC > > > are concerned that's OK, I'm just an old telco guy. > > > > > > > > > > > > Thanks, Henry > > > > > > -----Original Message----- > > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > > Sent: Thursday, July 27, 2006 1:46 PM > > > To: Francois Menard; Henry Sinnreich > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > > Ed Okerson > > > Subject: RE: [Speermint] Voice codecs > > > > > > This is in response to the question to Sohel regarding Broadband. > > > > > > Yes, we are very involved in broadband, and believe > > wireless broadband > > > will become extremely active in the next few years, but the > > reality is > > > that in the 3G work both EVRC and AMR are both widely deployed and > > > with IMS deployments starting to "spring up" around the > > global it is > > > probably important to also consider these needs. > > > > > > Can we support some mechanism for support codec negotiations with a > > > default "fall back" to G.711 or some other well known default? > > > > > > I do believe that we need to also consider the narrowband > > deployments. > > > > > > Thanks > > > > > > -----Original Message----- > > > From: Francois Menard [mailto:fmenard@xittelecom.com] > > > Sent: Thursday, July 27, 2006 1:41 PM > > > To: Henry Sinnreich > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > > Ed Okerson > > > Subject: Re: [Speermint] Voice codecs > > > > > > > > > I come from Sherbrooke and you know I vote hands down for Speex > > > > > > Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet > > > than people are willing to give him credit for. > > > > > > F. > > > > > > -- > > > Francois D. Menard > > > Project Manager/Charge de projet > > > Xit telecom inc. > > > 1350 Royale # 800 > > > Trois-Rivieres, QC, G9A 4J4 > > > Tel: +1 819 374 2556 x 268 > > > Cell: +1 819 692 1383 > > > fmenard@xittelecom.com > > > > > > > > > On Thu, 27 Jul 2006, Henry Sinnreich wrote: > > > > > >> Sohel, > > >> > > >>> A minimum set of Codecs needs to be supported that includes EvRC. > > >> > > >> How does the EvRC codec compare to the 'Internet Codecs' iLBC and > > > SPEEX? > > >> > > >> - Open source code? > > >> - Licensing fees? > > >> - Audio bandwidth? > > >> - Audio quality package? > > >> - APIs and codec abstraction for developers? > > >> - Independent lab quality assessments, etc.? > > >> > > >> More generic: > > >> > > >> How do all such closed, licensed, _narrowband voice only_ codecs > > > benefit > > >> global Internet communications and why should the IETF care? > > >> > > >> Have you heard of broadband? :-) > > >> (Note: I am a happy EVDO Sprint user). > > >> > > >> Thanks, Henry > > >> > > >> -----Original Message----- > > >> From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > >> Sent: Thursday, July 27, 2006 10:28 AM > > >> To: Jean-Francois Mule; speermint@ietf.org > > >> Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt > > >> > > >> > > >> These issues were discussed before; however, I am trying to reopen > > >> the discussion. > > >> > > >> Section 3.3: > > >> > > >> On Codec requirements: > > >> A minimum set of Codecs needs to be supported that includes EvRC. > > >> > > >> On Editor's note: > > >> Fax, DTMF signaling, TTY/TDD, instant messaging, and > > presence need to > > > be > > >> supported. > > >> > > >> > > >> Thank you. > > >> > > >> Sohel Khan, Ph.D. > > >> Technology Strategist > > >> Sprint-Nextel > > >> 913-794-1470 (office) > > >> 913-486-3145 (cell) > > >> > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > 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 Jul 28 09:59:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6SsN-0000Io-Qr; Fri, 28 Jul 2006 09:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6SsN-0000Ij-Bp for speermint@ietf.org; Fri, 28 Jul 2006 09:59:39 -0400 Received: from outbound-ash.frontbridge.com ([206.16.192.249] helo=outbound1-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6SsK-0000us-VE for speermint@ietf.org; Fri, 28 Jul 2006 09:59:39 -0400 Received: from outbound1-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-ash-R.bigfish.com (Postfix) with ESMTP id D3357FE1E0A; Fri, 28 Jul 2006 13:59:21 +0000 (UTC) Received: from mail64-ash-R.bigfish.com (unknown [172.18.2.3]) by outbound1-ash.bigfish.com (Postfix) with ESMTP id CA497FE5DA0; Fri, 28 Jul 2006 13:59:21 +0000 (UTC) Received: from mail64-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail64-ash-R.bigfish.com (Postfix) with ESMTP id BEF3F5C6FBF; Fri, 28 Jul 2006 13:59:21 +0000 (UTC) X-BigFish: V Received: by mail64-ash (MessageSwitch) id 1154095161697087_11603; Fri, 28 Jul 2006 13:59:21 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail64-ash.bigfish.com (Postfix) with ESMTP id 945905C4AC6; Fri, 28 Jul 2006 13:59:21 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k6SDxLPA025632; Fri, 28 Jul 2006 08:59:21 -0500 (CDT) Received: from plswg01a.ad.sprint.com (PLSWG01A.corp.sprint.com [10.214.11.47]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k6SDxKX20455; Fri, 28 Jul 2006 08:59:20 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg01a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 08:59: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] Voice codecs Date: Fri, 28 Jul 2006 08:58:43 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A1302158209@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: AcaxrEJCSQnXXLB/RoGRW9fZYY4yJQAABBhQAAJtjKAAARvgMAAkyz/Q From: "Khan, Sohel Q [CTO]" To: "Lipford, Mark A [CTO]" , "Henry Sinnreich" X-OriginalArrivalTime: 28 Jul 2006 13:59:15.0874 (UTC) FILETIME=[0345D820:01C6B24E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: speermint@ietf.org, Greg Herlein , Ed Okerson 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 To ensure that Mark's argument is Cleary heard... Mark wrote the followings: "[Lipford, Mark A [NTK]] I am OK with SPEEX and iLBC as defaults, I used G.711 due to 19 years in Telco :-) The main point I was wanting to try and gain some agreement around is that narrowband (i.e. 3GPP and 3GPP2 3G networks) is/are deploying IMS networks and using EVRC and AMR. The I-D I am looking at is about Requirements for VoIP interconnection. If this is the case it appears that support for these codecs seems to make some sense. Again, as far as SEEX and iLBC are concerned that's OK, I'm just an old telco guy." Thanks, Sohel Khan -----Original Message----- From: Lipford, Mark A [CTO]=20 Sent: Thursday, July 27, 2006 3:27 PM To: 'Henry Sinnreich' Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois Menard; Ed Okerson Subject: RE: [Speermint] Voice codecs See inline -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Thursday, July 27, 2006 3:01 PM To: Lipford, Mark A [CTO] Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois Menard; Ed Okerson Subject: RE: [Speermint] Voice codecs Mark Lipford writes: > Can we support some mechanism for support codec negotiations with a=20 > default "fall back" to G.711 Technically, the uncompressed G.711 (1960's PCM) is definitely the worst choice for a default: - Narrow band telephony at 3.1 kHz audio bandwidth (why do we have BB?) - Highest bandwidth consumed: Almost 90 kb/s with RTP/UDP/IP overhead - There are better mechanisms for Fax. Why do you avoid SPEEX and iLBC (RFC 3951 and RFC 3952) and what are your selection criteria? Can you explain? [Lipford, Mark A [NTK]] I am OK with SPEEX and iLBC as defaults, I used G.711 due to 19 years in Telco :-) The main point I was wanting to try and gain some agreement around is that narrowband (i.e. 3GPP and 3GPP2 3G networks) is/are deploying IMS networks and using EVRC and AMR. The I-D I am looking at is about Requirements for VoIP interconnection. If this is the case it appears that support for these codecs seems to make some sense. Again, as far as SEEX and iLBC are concerned that's OK, I'm just an old telco guy. Thanks, Henry -----Original Message----- From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] Sent: Thursday, July 27, 2006 1:46 PM To: Francois Menard; Henry Sinnreich Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Ed Okerson Subject: RE: [Speermint] Voice codecs This is in response to the question to Sohel regarding Broadband. Yes, we are very involved in broadband, and believe wireless broadband will become extremely active in the next few years, but the reality is that in the 3G work both EVRC and AMR are both widely deployed and with IMS deployments starting to "spring up" around the global it is probably important to also consider these needs. Can we support some mechanism for support codec negotiations with a default "fall back" to G.711 or some other well known default? I do believe that we need to also consider the narrowband deployments. Thanks -----Original Message----- From: Francois Menard [mailto:fmenard@xittelecom.com] Sent: Thursday, July 27, 2006 1:41 PM To: Henry Sinnreich Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Ed Okerson Subject: Re: [Speermint] Voice codecs I come from Sherbrooke and you know I vote hands down for Speex Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet than=20 people are willing to give him credit for. F. -- Francois D. Menard Project Manager/Charge de projet Xit telecom inc. 1350 Royale # 800 Trois-Rivieres, QC, G9A 4J4 Tel: +1 819 374 2556 x 268 Cell: +1 819 692 1383 fmenard@xittelecom.com On Thu, 27 Jul 2006, Henry Sinnreich wrote: > Sohel, > >> A minimum set of Codecs needs to be supported that includes EvRC. > > How does the EvRC codec compare to the 'Internet Codecs' iLBC and SPEEX? > > - Open source code? > - Licensing fees? > - Audio bandwidth? > - Audio quality package? > - APIs and codec abstraction for developers? > - Independent lab quality assessments, etc.? > > More generic: > > How do all such closed, licensed, _narrowband voice only_ codecs benefit > global Internet communications and why should the IETF care? > > Have you heard of broadband? :-) > (Note: I am a happy EVDO Sprint user). > > Thanks, Henry > > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Thursday, July 27, 2006 10:28 AM > To: Jean-Francois Mule; speermint@ietf.org > Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt > > > These issues were discussed before; however, I am trying to reopen the > discussion. > > Section 3.3: > > On Codec requirements: > A minimum set of Codecs needs to be supported that includes EvRC. > > On Editor's note: > Fax, DTMF signaling, TTY/TDD, instant messaging, and presence need to be > supported. > > > Thank you. > > Sohel Khan, Ph.D. > Technology Strategist > Sprint-Nextel > 913-794-1470 (office) > 913-486-3145 (cell) > > > > > > > _______________________________________________ > 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 _______________________________________________ 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 Jul 28 10:04:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Sx1-0007pA-OH; Fri, 28 Jul 2006 10:04:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Sx0-0007hc-RW for speermint@ietf.org; Fri, 28 Jul 2006 10:04:26 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Sx0-0001gC-AC for speermint@ietf.org; Fri, 28 Jul 2006 10:04:26 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 10:04:23 -0400 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] Voice codecs Date: Fri, 28 Jul 2006 10:04:22 -0400 Message-ID: <402F25FC1EB2BD44831F8A4A4F6DF94205456D@MAIL02.cedarpointcom.com> In-Reply-To: <01f501c6b24a$4ffea3d0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4A== From: "Geoff Devine" To: "Brian Rosen" , "Livingood, Jason" , "Klaus Darilion" , "Henry Sinnreich" X-OriginalArrivalTime: 28 Jul 2006 14:04:23.0979 (UTC) FILETIME=[BAEAEFB0:01C6B24E] X-Spam-Score: 0.0 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: speermint@ietf.org, Greg Herlein , Ed Okerson , "Lipford, Mark A \[CTO\]" 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 agree with Brian that mandating iLBC makes no sense. Unlike Brian, I don't particularly "like" iLBC. Have any of you actually done a CODEC bake-off with iLBC in the mix? I find the audio quality unacceptable compared to a premium compression codec like G.729e. You can hear iLBC distort speech (women, in particular) and it falls over completely reproducing music-on-hold. It's also my opinion that iLBC steps on quite a bit of patented IPR. There is a significant risk of lawsuits if a carrier deploys it. There are always going to be cases where transcoding is necessary. For example, the dual-mode cell phones we have in our lab tend to only speak the native compression codec in their ASIC. They don't have the CPU horsepower locally to convert it to G.711. When you are running voice over scarce and expensive licensed spectrum, an operator is likely to insist on always running a compression codec native to that network technology. Any viable peering architecture is going to have to take transcoding into account. Hopefully, most peering arrangements won't need to make much use of it. Geoff Geoff Devine Chief Architect Cedar Point Communications -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, July 28, 2006 9:33 AM To: 'Livingood, Jason'; 'Klaus Darilion'; 'Henry Sinnreich' Cc: speermint@ietf.org; 'Greg Herlein'; 'Ed Okerson'; 'Lipford,Mark A [CTO]' Subject: RE: [Speermint] Voice codecs I'm a big believer in reality. I really like SPEEX and iLBC for the reasons Henry cites, but the reality is that they are not widely implemented, and us writing them into a "must implement" spec in SPEERMINT isn't going to help deployment, it will just be another one of those "ignore here" things we sometimes do in the IETF when religion gets in front of reality. Perhaps what we say is this: A Federation specifies AT LEAST ONE mandatory codec for every media stream type (voice, video, text, ...). Each participant must be able to send or receive media in that codec, either by direct endpoint support or origination side transcoding. =20 Brian > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Friday, July 28, 2006 8:46 AM > To: Klaus Darilion; Henry Sinnreich > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford,Mark A [CTO] > Subject: RE: [Speermint] Voice codecs >=20 > We ought to at least recognize that in the VoIP server & equipment > market G.711 is probably the one with widest deployment (someone will > now surely cite Skype downloads as a datapoint, I am very familiar with > it and wish someone from eBay/Skype was participating here). In > wireless, it appears AMR is biggest (due to use by GSM), with EVRC in > second place. This group is not going to be able to push implementation > of one codec or another (nor should we), whether we like the business > model or social model represented by that codec or not. We do want to > figure out how to get the most people VoIP peering the fastest, and that > may (or may not) necessitate some lowest common denominator codecs. > That is far from a foregone conclusion and is a subject that will have > to be worked out by the WG over time. >=20 > This of course would not preclude use of other codecs and then endpoints > could use SIP to (normally) negotiate a different / preferred codec that > may be newer, lower bandwidth, higher fidelity, less expensive to > license, etc. >=20 > This may also be a moot point in the near future. A recent conversation > with an endpoint maker gave me the impression that it will be pretty > easy to have all of the codecs we have mentioned here in a very low cost > endpoint in the near future. Any hardware makers wish to comment on the > futures / possibilities? >=20 > So keep up the discussion... >=20 > Jason >=20 > > -----Original Message----- > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > Sent: Thursday, July 27, 2006 6:58 PM > > To: Henry Sinnreich > > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford,Mark A [CTO] > > Subject: RE: [Speermint] Voice codecs > > > > On Thu, July 27, 2006 22:59, Henry Sinnreich said: > > > Mark Lipford writes: > > > > > >> I am OK with SPEEX and iLBC as defaults > > > > > > Thanks and I am very happy we can come closer to an > > agreement on this! > > > > > > Are there any other opinions on using SPEEX and iLBC (RFC > > 3951 and RFC > > > 3952) as defaults for IP-IP broadband? > > > > Yes. Please count the number of terminal adaptor and SIP > > hardphones that support SPEEX and iLBC versus G.711. > > > > regards > > klaus > > > > > > > > > > Thanks again, Henry > > > > > > -----Original Message----- > > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > > Sent: Thursday, July 27, 2006 3:27 PM > > > To: Henry Sinnreich > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois > > > Menard; Ed Okerson > > > Subject: RE: [Speermint] Voice codecs > > > > > > See inline > > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > Sent: Thursday, July 27, 2006 3:01 PM > > > To: Lipford, Mark A [CTO] > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois > > > Menard; Ed Okerson > > > Subject: RE: [Speermint] Voice codecs > > > > > > Mark Lipford writes: > > > > > >> Can we support some mechanism for support codec > > negotiations with a > > >> default "fall back" to G.711 > > > > > > Technically, the uncompressed G.711 (1960's PCM) is definitely the > > > worst choice for a default: > > > > > > - Narrow band telephony at 3.1 kHz audio bandwidth (why do we have > > > BB?) > > > - Highest bandwidth consumed: Almost 90 kb/s with > > RTP/UDP/IP overhead > > > - There are better mechanisms for Fax. > > > > > > Why do you avoid SPEEX and iLBC (RFC 3951 and RFC 3952) and > > what are > > > your selection criteria? Can you explain? > > > [Lipford, Mark A [NTK]] I am OK with SPEEX and iLBC as defaults, I > > > used > > > G.711 due to 19 years in Telco :-) The main point I was wanting to > > > try and gain some agreement around is that narrowband (i.e. > > 3GPP and > > > 3GPP2 3G networks) is/are deploying IMS networks and using EVRC and > > > AMR. The I-D I am looking at is about Requirements for VoIP > > > interconnection. If this is the case it appears that support for > > > these codecs seems to make some sense. Again, as far as > > SEEX and iLBC > > > are concerned that's OK, I'm just an old telco guy. > > > > > > > > > > > > Thanks, Henry > > > > > > -----Original Message----- > > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > > Sent: Thursday, July 27, 2006 1:46 PM > > > To: Francois Menard; Henry Sinnreich > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > > Ed Okerson > > > Subject: RE: [Speermint] Voice codecs > > > > > > This is in response to the question to Sohel regarding Broadband. > > > > > > Yes, we are very involved in broadband, and believe > > wireless broadband > > > will become extremely active in the next few years, but the > > reality is > > > that in the 3G work both EVRC and AMR are both widely deployed and > > > with IMS deployments starting to "spring up" around the > > global it is > > > probably important to also consider these needs. > > > > > > Can we support some mechanism for support codec negotiations with a > > > default "fall back" to G.711 or some other well known default? > > > > > > I do believe that we need to also consider the narrowband > > deployments. > > > > > > Thanks > > > > > > -----Original Message----- > > > From: Francois Menard [mailto:fmenard@xittelecom.com] > > > Sent: Thursday, July 27, 2006 1:41 PM > > > To: Henry Sinnreich > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > > Ed Okerson > > > Subject: Re: [Speermint] Voice codecs > > > > > > > > > I come from Sherbrooke and you know I vote hands down for Speex > > > > > > Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet > > > than people are willing to give him credit for. > > > > > > F. > > > > > > -- > > > Francois D. Menard > > > Project Manager/Charge de projet > > > Xit telecom inc. > > > 1350 Royale # 800 > > > Trois-Rivieres, QC, G9A 4J4 > > > Tel: +1 819 374 2556 x 268 > > > Cell: +1 819 692 1383 > > > fmenard@xittelecom.com > > > > > > > > > On Thu, 27 Jul 2006, Henry Sinnreich wrote: > > > > > >> Sohel, > > >> > > >>> A minimum set of Codecs needs to be supported that includes EvRC. > > >> > > >> How does the EvRC codec compare to the 'Internet Codecs' iLBC and > > > SPEEX? > > >> > > >> - Open source code? > > >> - Licensing fees? > > >> - Audio bandwidth? > > >> - Audio quality package? > > >> - APIs and codec abstraction for developers? > > >> - Independent lab quality assessments, etc.? > > >> > > >> More generic: > > >> > > >> How do all such closed, licensed, _narrowband voice only_ codecs > > > benefit > > >> global Internet communications and why should the IETF care? > > >> > > >> Have you heard of broadband? :-) > > >> (Note: I am a happy EVDO Sprint user). > > >> > > >> Thanks, Henry > > >> > > >> -----Original Message----- > > >> From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > >> Sent: Thursday, July 27, 2006 10:28 AM > > >> To: Jean-Francois Mule; speermint@ietf.org > > >> Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt > > >> > > >> > > >> These issues were discussed before; however, I am trying to reopen > > >> the discussion. > > >> > > >> Section 3.3: > > >> > > >> On Codec requirements: > > >> A minimum set of Codecs needs to be supported that includes EvRC. > > >> > > >> On Editor's note: > > >> Fax, DTMF signaling, TTY/TDD, instant messaging, and > > presence need to > > > be > > >> supported. > > >> > > >> > > >> Thank you. > > >> > > >> Sohel Khan, Ph.D. > > >> Technology Strategist > > >> Sprint-Nextel > > >> 913-794-1470 (office) > > >> 913-486-3145 (cell) > > >> > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > > > > > > _______________________________________________ > > > 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 > > >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 28 10:13:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6T5R-00051c-4N; Fri, 28 Jul 2006 10:13:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6T5P-000500-VP for speermint@ietf.org; Fri, 28 Jul 2006 10:13:07 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6T5O-0002HB-AB for speermint@ietf.org; Fri, 28 Jul 2006 10:13:07 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G6T4x-0005f5-63; Fri, 28 Jul 2006 09:12:40 -0500 From: "Brian Rosen" To: "'Geoff Devine'" , "'Livingood, Jason'" , "'Klaus Darilion'" , "'Henry Sinnreich'" Subject: RE: [Speermint] Voice codecs Date: Fri, 28 Jul 2006 10:12:49 -0400 Message-ID: <020301c6b24f$ea474e60$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.2869 Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXg In-Reply-To: <402F25FC1EB2BD44831F8A4A4F6DF94205456D@MAIL02.cedarpointcom.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 Cc: speermint@ietf.org, 'Greg Herlein' , 'Ed Okerson' , "'Lipford, Mark A \[CTO\]'" 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 don't think arguing about iLBC will get us very far, so I'm not going to respond to that part of your message. I did say something in my message which may have escaped some notice. I said "origination side". One of the things you have to get right on any kind of part like transcoding is what assumptions are made. You can assume the origination side does it, the destination side does it or the peering fabric itself does it. I think it's essential to choose one, or we won't have interoperability. More than one is always possible, but at least one is required. I think origination side is best: it means that across the peering fabric, there is at least one common codec. Brian > -----Original Message----- > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > Sent: Friday, July 28, 2006 10:04 AM > To: Brian Rosen; Livingood, Jason; Klaus Darilion; Henry Sinnreich > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford,Mark A [CTO] > Subject: RE: [Speermint] Voice codecs > > I agree with Brian that mandating iLBC makes no sense. Unlike Brian, I > don't particularly "like" iLBC. Have any of you actually done a CODEC > bake-off with iLBC in the mix? I find the audio quality unacceptable > compared to a premium compression codec like G.729e. You can hear iLBC > distort speech (women, in particular) and it falls over completely > reproducing music-on-hold. It's also my opinion that iLBC steps on > quite a bit of patented IPR. There is a significant risk of lawsuits if > a carrier deploys it. > > There are always going to be cases where transcoding is necessary. For > example, the dual-mode cell phones we have in our lab tend to only speak > the native compression codec in their ASIC. They don't have the CPU > horsepower locally to convert it to G.711. When you are running voice > over scarce and expensive licensed spectrum, an operator is likely to > insist on always running a compression codec native to that network > technology. > > Any viable peering architecture is going to have to take transcoding > into account. Hopefully, most peering arrangements won't need to make > much use of it. > > Geoff > > Geoff Devine > Chief Architect > Cedar Point Communications > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, July 28, 2006 9:33 AM > To: 'Livingood, Jason'; 'Klaus Darilion'; 'Henry Sinnreich' > Cc: speermint@ietf.org; 'Greg Herlein'; 'Ed Okerson'; 'Lipford,Mark A > [CTO]' > Subject: RE: [Speermint] Voice codecs > > I'm a big believer in reality. > > I really like SPEEX and iLBC for the reasons Henry cites, but the > reality is > that they are not widely implemented, and us writing them into a "must > implement" spec in SPEERMINT isn't going to help deployment, it will > just be > another one of those "ignore here" things we sometimes do in the IETF > when > religion gets in front of reality. > > Perhaps what we say is this: > > A Federation specifies AT LEAST ONE mandatory codec for every media > stream > type (voice, video, text, ...). Each participant must be able to send > or > receive media in that codec, either by direct endpoint support or > origination side transcoding. > > Brian > > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Friday, July 28, 2006 8:46 AM > > To: Klaus Darilion; Henry Sinnreich > > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford,Mark A [CTO] > > Subject: RE: [Speermint] Voice codecs > > > > We ought to at least recognize that in the VoIP server & equipment > > market G.711 is probably the one with widest deployment (someone will > > now surely cite Skype downloads as a datapoint, I am very familiar > with > > it and wish someone from eBay/Skype was participating here). In > > wireless, it appears AMR is biggest (due to use by GSM), with EVRC in > > second place. This group is not going to be able to push > implementation > > of one codec or another (nor should we), whether we like the business > > model or social model represented by that codec or not. We do want to > > figure out how to get the most people VoIP peering the fastest, and > that > > may (or may not) necessitate some lowest common denominator codecs. > > That is far from a foregone conclusion and is a subject that will have > > to be worked out by the WG over time. > > > > This of course would not preclude use of other codecs and then > endpoints > > could use SIP to (normally) negotiate a different / preferred codec > that > > may be newer, lower bandwidth, higher fidelity, less expensive to > > license, etc. > > > > This may also be a moot point in the near future. A recent > conversation > > with an endpoint maker gave me the impression that it will be pretty > > easy to have all of the codecs we have mentioned here in a very low > cost > > endpoint in the near future. Any hardware makers wish to comment on > the > > futures / possibilities? > > > > So keep up the discussion... > > > > Jason > > > > > -----Original Message----- > > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > > Sent: Thursday, July 27, 2006 6:58 PM > > > To: Henry Sinnreich > > > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford,Mark A > [CTO] > > > Subject: RE: [Speermint] Voice codecs > > > > > > On Thu, July 27, 2006 22:59, Henry Sinnreich said: > > > > Mark Lipford writes: > > > > > > > >> I am OK with SPEEX and iLBC as defaults > > > > > > > > Thanks and I am very happy we can come closer to an > > > agreement on this! > > > > > > > > Are there any other opinions on using SPEEX and iLBC (RFC > > > 3951 and RFC > > > > 3952) as defaults for IP-IP broadband? > > > > > > Yes. Please count the number of terminal adaptor and SIP > > > hardphones that support SPEEX and iLBC versus G.711. > > > > > > regards > > > klaus > > > > > > > > > > > > > > Thanks again, Henry > > > > > > > > -----Original Message----- > > > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > > > Sent: Thursday, July 27, 2006 3:27 PM > > > > To: Henry Sinnreich > > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > Francois > > > > Menard; Ed Okerson > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > See inline > > > > > > > > -----Original Message----- > > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > > Sent: Thursday, July 27, 2006 3:01 PM > > > > To: Lipford, Mark A [CTO] > > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > Francois > > > > Menard; Ed Okerson > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > Mark Lipford writes: > > > > > > > >> Can we support some mechanism for support codec > > > negotiations with a > > > >> default "fall back" to G.711 > > > > > > > > Technically, the uncompressed G.711 (1960's PCM) is definitely the > > > > worst choice for a default: > > > > > > > > - Narrow band telephony at 3.1 kHz audio bandwidth (why do we have > > > > BB?) > > > > - Highest bandwidth consumed: Almost 90 kb/s with > > > RTP/UDP/IP overhead > > > > - There are better mechanisms for Fax. > > > > > > > > Why do you avoid SPEEX and iLBC (RFC 3951 and RFC 3952) and > > > what are > > > > your selection criteria? Can you explain? > > > > [Lipford, Mark A [NTK]] I am OK with SPEEX and iLBC as defaults, I > > > > used > > > > G.711 due to 19 years in Telco :-) The main point I was wanting > to > > > > try and gain some agreement around is that narrowband (i.e. > > > 3GPP and > > > > 3GPP2 3G networks) is/are deploying IMS networks and using EVRC > and > > > > AMR. The I-D I am looking at is about Requirements for VoIP > > > > interconnection. If this is the case it appears that support for > > > > these codecs seems to make some sense. Again, as far as > > > SEEX and iLBC > > > > are concerned that's OK, I'm just an old telco guy. > > > > > > > > > > > > > > > > Thanks, Henry > > > > > > > > -----Original Message----- > > > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > > > Sent: Thursday, July 27, 2006 1:46 PM > > > > To: Francois Menard; Henry Sinnreich > > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > > > Ed Okerson > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > This is in response to the question to Sohel regarding Broadband. > > > > > > > > Yes, we are very involved in broadband, and believe > > > wireless broadband > > > > will become extremely active in the next few years, but the > > > reality is > > > > that in the 3G work both EVRC and AMR are both widely deployed and > > > > with IMS deployments starting to "spring up" around the > > > global it is > > > > probably important to also consider these needs. > > > > > > > > Can we support some mechanism for support codec negotiations with > a > > > > default "fall back" to G.711 or some other well known default? > > > > > > > > I do believe that we need to also consider the narrowband > > > deployments. > > > > > > > > Thanks > > > > > > > > -----Original Message----- > > > > From: Francois Menard [mailto:fmenard@xittelecom.com] > > > > Sent: Thursday, July 27, 2006 1:41 PM > > > > To: Henry Sinnreich > > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > > > Ed Okerson > > > > Subject: Re: [Speermint] Voice codecs > > > > > > > > > > > > I come from Sherbrooke and you know I vote hands down for Speex > > > > > > > > Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet > > > > than people are willing to give him credit for. > > > > > > > > F. > > > > > > > > -- > > > > Francois D. Menard > > > > Project Manager/Charge de projet > > > > Xit telecom inc. > > > > 1350 Royale # 800 > > > > Trois-Rivieres, QC, G9A 4J4 > > > > Tel: +1 819 374 2556 x 268 > > > > Cell: +1 819 692 1383 > > > > fmenard@xittelecom.com > > > > > > > > > > > > On Thu, 27 Jul 2006, Henry Sinnreich wrote: > > > > > > > >> Sohel, > > > >> > > > >>> A minimum set of Codecs needs to be supported that includes > EvRC. > > > >> > > > >> How does the EvRC codec compare to the 'Internet Codecs' iLBC and > > > > SPEEX? > > > >> > > > >> - Open source code? > > > >> - Licensing fees? > > > >> - Audio bandwidth? > > > >> - Audio quality package? > > > >> - APIs and codec abstraction for developers? > > > >> - Independent lab quality assessments, etc.? > > > >> > > > >> More generic: > > > >> > > > >> How do all such closed, licensed, _narrowband voice only_ codecs > > > > benefit > > > >> global Internet communications and why should the IETF care? > > > >> > > > >> Have you heard of broadband? :-) > > > >> (Note: I am a happy EVDO Sprint user). > > > >> > > > >> Thanks, Henry > > > >> > > > >> -----Original Message----- > > > >> From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > > >> Sent: Thursday, July 27, 2006 10:28 AM > > > >> To: Jean-Francois Mule; speermint@ietf.org > > > >> Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt > > > >> > > > >> > > > >> These issues were discussed before; however, I am trying to > reopen > > > >> the discussion. > > > >> > > > >> Section 3.3: > > > >> > > > >> On Codec requirements: > > > >> A minimum set of Codecs needs to be supported that includes EvRC. > > > >> > > > >> On Editor's note: > > > >> Fax, DTMF signaling, TTY/TDD, instant messaging, and > > > presence need to > > > > be > > > >> supported. > > > >> > > > >> > > > >> Thank you. > > > >> > > > >> Sohel Khan, Ph.D. > > > >> Technology Strategist > > > >> Sprint-Nextel > > > >> 913-794-1470 (office) > > > >> 913-486-3145 (cell) > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> 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 > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > _______________________________________________ > > 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 Fri Jul 28 10:31:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6TN2-0005rX-Fe; Fri, 28 Jul 2006 10:31:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6TN0-0005mk-Qv for speermint@ietf.org; Fri, 28 Jul 2006 10:31:18 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6TMy-0004tH-Gl for speermint@ietf.org; Fri, 28 Jul 2006 10:31:18 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 28 Jul 2006 10:30:16 -0400 X-IronPort-AV: i="4.07,191,1151899200"; d="scan'208"; a="94253340:sNHT26495638" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6SEUGgO001090; Fri, 28 Jul 2006 10:30:16 -0400 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 k6SEUEYh021827; Fri, 28 Jul 2006 10:30:15 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 10:30:14 -0400 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] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Fri, 28 Jul 2006 10:30:13 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301BF8732@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Thread-Index: AcavMtjSUN/IyMAXSMSP8ooNPOAI4QAEXLCAAMNvo2A= From: "Michael Hammer \(mhammer\)" To: "Reinaldo Penno" , "Klaus Darilion" , "Stastny Richard" X-OriginalArrivalTime: 28 Jul 2006 14:30:14.0914 (UTC) FILETIME=[5758D620:01C6B252] DKIM-Signature: a=rsa-sha1; q=dns; l=2404; t=1154097016; x=1154961016; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20I-D=20ACTION=3Adraft-ietf-speermint-requirements-0 0.t=20xt |To:=22Reinaldo=20Penno=22=20, =0A=20=20=20=20=20=20=20=2 0=22Klaus=20Darilion=22=20, =0A=20=20=20=20=20 =20=20=20=22Stastny=20Richard=22=20; X=v=3Dcisco.com=3B=20h=3DMvhhKRce1jKXaSAsB8wOllFLvvY=3D; b=VtlFAMtSq9mjdNwNO3ijU7N7cmLlcALP0hqlXvxb3iI/bMLEcUIOAqh4vP7duu1eebqIDdys ZGX7OVfwAj3SObHzASwF/h/qlRa4ujOK3ZoP9hbLrKC8eFZrK+WlfEtX; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 suspect a Federation of like-minded users will be used and setup/agree to a media policy that specifies that set of codecs that they know and love. Mike > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 > Sent: Monday, July 24, 2006 1:23 PM > To: Klaus Darilion; Stastny Richard > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D=20 > ACTION:draft-ietf-speermint-requirements-00.t xt >=20 > I tend to agree. One thing is to specify a behavior over a=20 > peering interface that affects only the peering devices.=20 > Another is to specify a behavior that affects possibly=20 > millions of phones (or alternatively a requirement to install=20 > many of transcoders). >=20 > I cannot imagine Sprint changing all its phones to support=20 > G.711 or Comcast changing all of its phones to support some=20 > wireless codec because Speermint mandates it.=20 >=20 > That leaves only three alternatives: >=20 > 1) Do not specify anything in the RFCs and the peers work in=20 > out whether through some transcoding devices, or some common=20 > coder when possible. >=20 > 2) Specify a minimum set (Can it be done and make everybody happy?) >=20 > 3) Let offer/answer decide. I believe this might fall back=20 > into 1) since I do not believe carriers will just "wing it"=20 > when it comes to peering.=20 >=20 > Regards, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > Sent: Monday, July 24, 2006 8:06 AM > > To: Stastny Richard > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] I-D > ACTION:draft-ietf-speermint-requirements-00.t > > xt > >=20 > > Stastny Richard wrote: > > >> And finally they can't interconnect as A uses AMR and B=20 > uses G.711. > > > > > > They can, if one provides transcoding > > > > > > If we say G.711 is mandatory, it is provider A who has to provide > the > > transcoding > >=20 > >=20 > > Thus, we have to mandate a minimum set of codecs. > >=20 > > regards > > klaus > >=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 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 28 10:32:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6TOA-0007Ij-Eu; Fri, 28 Jul 2006 10:32:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6TO9-0007D4-7h for speermint@ietf.org; Fri, 28 Jul 2006 10:32:29 -0400 Received: from outbound-ash.frontbridge.com ([206.16.192.249] helo=outbound2-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6TO8-0004wh-PG for speermint@ietf.org; Fri, 28 Jul 2006 10:32:29 -0400 Received: from outbound2-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-ash-R.bigfish.com (Postfix) with ESMTP id 9F3A4BE2558; Fri, 28 Jul 2006 14:32:28 +0000 (UTC) Received: from mail17-ash-R.bigfish.com (unknown [172.18.2.3]) by outbound2-ash.bigfish.com (Postfix) with ESMTP id 95600BE253F; Fri, 28 Jul 2006 14:32:28 +0000 (UTC) Received: from mail17-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail17-ash-R.bigfish.com (Postfix) with ESMTP id 89280425A84; Fri, 28 Jul 2006 14:32:28 +0000 (UTC) X-BigFish: V Received: by mail17-ash (MessageSwitch) id 1154097148376818_27956; Fri, 28 Jul 2006 14:32:28 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail17-ash.bigfish.com (Postfix) with ESMTP id 43C76422495; Fri, 28 Jul 2006 14:32:28 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k6SEWRY3029758; Fri, 28 Jul 2006 09:32:27 -0500 (CDT) Received: from plswg03a.ad.sprint.com (PLSWG03A.corp.sprint.com [10.214.11.49]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k6SEWPv03770; Fri, 28 Jul 2006 09:32:25 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg03a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 09:32:24 -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] Voice codecs Date: Fri, 28 Jul 2006 09:32:11 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A1302158330@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAPcYCA= From: "Khan, Sohel Q [CTO]" To: "Livingood, Jason" , "Klaus Darilion" , "Henry Sinnreich" X-OriginalArrivalTime: 28 Jul 2006 14:32:24.0909 (UTC) FILETIME=[A4D47FD0:01C6B252] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: speermint@ietf.org, Greg Herlein , Ed Okerson 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 concur with Jason that a set of lowest common denominator codecs needs to be recommended/supported to allow fastest VoIP peering to work.=20 Let us make this minimum set of list. For example, the minimum set of codec list =3D {G.711, EvRC, ...} Thank you. Sohel Khan=20 -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Friday, July 28, 2006 7:46 AM To: Klaus Darilion; Henry Sinnreich Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford, Mark A [CTO] Subject: RE: [Speermint] Voice codecs We ought to at least recognize that in the VoIP server & equipment market G.711 is probably the one with widest deployment (someone will now surely cite Skype downloads as a datapoint, I am very familiar with it and wish someone from eBay/Skype was participating here). In wireless, it appears AMR is biggest (due to use by GSM), with EVRC in second place. This group is not going to be able to push implementation of one codec or another (nor should we), whether we like the business model or social model represented by that codec or not. We do want to figure out how to get the most people VoIP peering the fastest, and that may (or may not) necessitate some lowest common denominator codecs. That is far from a foregone conclusion and is a subject that will have to be worked out by the WG over time. This of course would not preclude use of other codecs and then endpoints could use SIP to (normally) negotiate a different / preferred codec that may be newer, lower bandwidth, higher fidelity, less expensive to license, etc. This may also be a moot point in the near future. A recent conversation with an endpoint maker gave me the impression that it will be pretty easy to have all of the codecs we have mentioned here in a very low cost endpoint in the near future. Any hardware makers wish to comment on the futures / possibilities? So keep up the discussion...=20 Jason=20 > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Thursday, July 27, 2006 6:58 PM > To: Henry Sinnreich > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford,Mark A [CTO] > Subject: RE: [Speermint] Voice codecs >=20 > On Thu, July 27, 2006 22:59, Henry Sinnreich said: > > Mark Lipford writes: > > > >> I am OK with SPEEX and iLBC as defaults > > > > Thanks and I am very happy we can come closer to an > agreement on this! > > > > Are there any other opinions on using SPEEX and iLBC (RFC > 3951 and RFC > > 3952) as defaults for IP-IP broadband? >=20 > Yes. Please count the number of terminal adaptor and SIP hardphones=20 > that support SPEEX and iLBC versus G.711. >=20 > regards > klaus >=20 >=20 > > > > Thanks again, Henry > > > > -----Original Message----- > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > Sent: Thursday, July 27, 2006 3:27 PM > > To: Henry Sinnreich > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois=20 > > Menard; Ed Okerson > > Subject: RE: [Speermint] Voice codecs > > > > See inline > > > > -----Original Message----- > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > Sent: Thursday, July 27, 2006 3:01 PM > > To: Lipford, Mark A [CTO] > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois=20 > > Menard; Ed Okerson > > Subject: RE: [Speermint] Voice codecs > > > > Mark Lipford writes: > > > >> Can we support some mechanism for support codec > negotiations with a > >> default "fall back" to G.711 > > > > Technically, the uncompressed G.711 (1960's PCM) is definitely the=20 > > worst choice for a default: > > > > - Narrow band telephony at 3.1 kHz audio bandwidth (why do we have > > BB?) > > - Highest bandwidth consumed: Almost 90 kb/s with > RTP/UDP/IP overhead > > - There are better mechanisms for Fax. > > > > Why do you avoid SPEEX and iLBC (RFC 3951 and RFC 3952) and > what are > > your selection criteria? Can you explain? > > [Lipford, Mark A [NTK]] I am OK with SPEEX and iLBC as defaults, I=20 > > used > > G.711 due to 19 years in Telco :-) The main point I was wanting to=20 > > try and gain some agreement around is that narrowband (i.e. > 3GPP and > > 3GPP2 3G networks) is/are deploying IMS networks and using EVRC and=20 > > AMR. The I-D I am looking at is about Requirements for VoIP=20 > > interconnection. If this is the case it appears that support for=20 > > these codecs seems to make some sense. Again, as far as > SEEX and iLBC > > are concerned that's OK, I'm just an old telco guy. > > > > > > > > Thanks, Henry > > > > -----Original Message----- > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > Sent: Thursday, July 27, 2006 1:46 PM > > To: Francois Menard; Henry Sinnreich > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > Ed Okerson > > Subject: RE: [Speermint] Voice codecs > > > > This is in response to the question to Sohel regarding Broadband. > > > > Yes, we are very involved in broadband, and believe > wireless broadband > > will become extremely active in the next few years, but the > reality is > > that in the 3G work both EVRC and AMR are both widely deployed and=20 > > with IMS deployments starting to "spring up" around the > global it is > > probably important to also consider these needs. > > > > Can we support some mechanism for support codec negotiations with a=20 > > default "fall back" to G.711 or some other well known default? > > > > I do believe that we need to also consider the narrowband > deployments. > > > > Thanks > > > > -----Original Message----- > > From: Francois Menard [mailto:fmenard@xittelecom.com] > > Sent: Thursday, July 27, 2006 1:41 PM > > To: Henry Sinnreich > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > Ed Okerson > > Subject: Re: [Speermint] Voice codecs > > > > > > I come from Sherbrooke and you know I vote hands down for Speex > > > > Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet=20 > > than people are willing to give him credit for. > > > > F. > > > > -- > > Francois D. Menard > > Project Manager/Charge de projet > > Xit telecom inc. > > 1350 Royale # 800 > > Trois-Rivieres, QC, G9A 4J4 > > Tel: +1 819 374 2556 x 268 > > Cell: +1 819 692 1383 > > fmenard@xittelecom.com > > > > > > On Thu, 27 Jul 2006, Henry Sinnreich wrote: > > > >> Sohel, > >> > >>> A minimum set of Codecs needs to be supported that includes EvRC. > >> > >> How does the EvRC codec compare to the 'Internet Codecs' iLBC and > > SPEEX? > >> > >> - Open source code? > >> - Licensing fees? > >> - Audio bandwidth? > >> - Audio quality package? > >> - APIs and codec abstraction for developers? > >> - Independent lab quality assessments, etc.? > >> > >> More generic: > >> > >> How do all such closed, licensed, _narrowband voice only_ codecs > > benefit > >> global Internet communications and why should the IETF care? > >> > >> Have you heard of broadband? :-) > >> (Note: I am a happy EVDO Sprint user). > >> > >> Thanks, Henry > >> > >> -----Original Message----- > >> From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > >> Sent: Thursday, July 27, 2006 10:28 AM > >> To: Jean-Francois Mule; speermint@ietf.org > >> Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt > >> > >> > >> These issues were discussed before; however, I am trying to reopen=20 > >> the discussion. > >> > >> Section 3.3: > >> > >> On Codec requirements: > >> A minimum set of Codecs needs to be supported that includes EvRC. > >> > >> On Editor's note: > >> Fax, DTMF signaling, TTY/TDD, instant messaging, and > presence need to > > be > >> supported. > >> > >> > >> Thank you. > >> > >> Sohel Khan, Ph.D. > >> Technology Strategist > >> Sprint-Nextel > >> 913-794-1470 (office) > >> 913-486-3145 (cell) > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > > > > > _______________________________________________ > > 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 > > >=20 >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 28 10:45:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Tb1-0004MB-3T; Fri, 28 Jul 2006 10:45:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Taz-0004M5-Tz for speermint@ietf.org; Fri, 28 Jul 2006 10:45:45 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Tax-0007NZ-AE for speermint@ietf.org; Fri, 28 Jul 2006 10:45:45 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G6TaQ-0007x8-Tj; Fri, 28 Jul 2006 09:45:11 -0500 From: "Brian Rosen" To: "'Khan, Sohel Q [CTO]'" , "'Livingood, Jason'" , "'Klaus Darilion'" , "'Henry Sinnreich'" Subject: RE: [Speermint] Voice codecs Date: Fri, 28 Jul 2006 10:45:19 -0400 Message-ID: <020a01c6b254$75b6a960$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.2869 Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAPcYCAAAGicMA== In-Reply-To: <858217C310A3D94182FA8AAE42860A1302158330@PLSWB08C.ad.sprint.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Cc: speermint@ietf.org, 'Greg Herlein' , 'Ed Okerson' 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 Sohel I think this is a mistake. If I were, just to pick an example, the GSMA, and I "sponsored" a peering system, just for GSMA members, then I don't want EvRC or G.711 in my fabric. If I am organizing an IM Peering system, then I don't want ANY voice codec. If I am organizing a video conferencing peering system, I need something quite a bit different than what a VoIP peering system needs. SPEERMINT documents should work well for these federations. This is why I don't think we can specify an actual codec list. I'd LIKE to do it, because I'd like to be able to build one thing that works with all federations, but if GSMA is a federation and the IM guys make one, EvRC just doesn't fit, no way, no how. If there was a real minimum, it would have to be G.711 alone, no other codec, but the IM guys would really squeal. Brian > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Friday, July 28, 2006 10:32 AM > To: Livingood, Jason; Klaus Darilion; Henry Sinnreich > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson > Subject: RE: [Speermint] Voice codecs > > I concur with Jason that a set of lowest common denominator codecs needs > to be recommended/supported to allow fastest VoIP peering to work. > Let us make this minimum set of list. > For example, the minimum set of codec list = {G.711, EvRC, ...} > > Thank you. > > Sohel Khan > > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Friday, July 28, 2006 7:46 AM > To: Klaus Darilion; Henry Sinnreich > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford, Mark A [CTO] > Subject: RE: [Speermint] Voice codecs > > We ought to at least recognize that in the VoIP server & equipment > market G.711 is probably the one with widest deployment (someone will > now surely cite Skype downloads as a datapoint, I am very familiar with > it and wish someone from eBay/Skype was participating here). In > wireless, it appears AMR is biggest (due to use by GSM), with EVRC in > second place. This group is not going to be able to push implementation > of one codec or another (nor should we), whether we like the business > model or social model represented by that codec or not. We do want to > figure out how to get the most people VoIP peering the fastest, and that > may (or may not) necessitate some lowest common denominator codecs. > That is far from a foregone conclusion and is a subject that will have > to be worked out by the WG over time. > > This of course would not preclude use of other codecs and then endpoints > could use SIP to (normally) negotiate a different / preferred codec that > may be newer, lower bandwidth, higher fidelity, less expensive to > license, etc. > > This may also be a moot point in the near future. A recent conversation > with an endpoint maker gave me the impression that it will be pretty > easy to have all of the codecs we have mentioned here in a very low cost > endpoint in the near future. Any hardware makers wish to comment on the > futures / possibilities? > > So keep up the discussion... > > Jason > > > -----Original Message----- > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > Sent: Thursday, July 27, 2006 6:58 PM > > To: Henry Sinnreich > > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford,Mark A [CTO] > > Subject: RE: [Speermint] Voice codecs > > > > On Thu, July 27, 2006 22:59, Henry Sinnreich said: > > > Mark Lipford writes: > > > > > >> I am OK with SPEEX and iLBC as defaults > > > > > > Thanks and I am very happy we can come closer to an > > agreement on this! > > > > > > Are there any other opinions on using SPEEX and iLBC (RFC > > 3951 and RFC > > > 3952) as defaults for IP-IP broadband? > > > > Yes. Please count the number of terminal adaptor and SIP hardphones > > that support SPEEX and iLBC versus G.711. > > > > regards > > klaus > > > > > > > > > > Thanks again, Henry > > > > > > -----Original Message----- > > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > > Sent: Thursday, July 27, 2006 3:27 PM > > > To: Henry Sinnreich > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois > > > Menard; Ed Okerson > > > Subject: RE: [Speermint] Voice codecs > > > > > > See inline > > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > Sent: Thursday, July 27, 2006 3:01 PM > > > To: Lipford, Mark A [CTO] > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois > > > Menard; Ed Okerson > > > Subject: RE: [Speermint] Voice codecs > > > > > > Mark Lipford writes: > > > > > >> Can we support some mechanism for support codec > > negotiations with a > > >> default "fall back" to G.711 > > > > > > Technically, the uncompressed G.711 (1960's PCM) is definitely the > > > worst choice for a default: > > > > > > - Narrow band telephony at 3.1 kHz audio bandwidth (why do we have > > > BB?) > > > - Highest bandwidth consumed: Almost 90 kb/s with > > RTP/UDP/IP overhead > > > - There are better mechanisms for Fax. > > > > > > Why do you avoid SPEEX and iLBC (RFC 3951 and RFC 3952) and > > what are > > > your selection criteria? Can you explain? > > > [Lipford, Mark A [NTK]] I am OK with SPEEX and iLBC as defaults, I > > > used > > > G.711 due to 19 years in Telco :-) The main point I was wanting to > > > try and gain some agreement around is that narrowband (i.e. > > 3GPP and > > > 3GPP2 3G networks) is/are deploying IMS networks and using EVRC and > > > AMR. The I-D I am looking at is about Requirements for VoIP > > > interconnection. If this is the case it appears that support for > > > these codecs seems to make some sense. Again, as far as > > SEEX and iLBC > > > are concerned that's OK, I'm just an old telco guy. > > > > > > > > > > > > Thanks, Henry > > > > > > -----Original Message----- > > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > > Sent: Thursday, July 27, 2006 1:46 PM > > > To: Francois Menard; Henry Sinnreich > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > > Ed Okerson > > > Subject: RE: [Speermint] Voice codecs > > > > > > This is in response to the question to Sohel regarding Broadband. > > > > > > Yes, we are very involved in broadband, and believe > > wireless broadband > > > will become extremely active in the next few years, but the > > reality is > > > that in the 3G work both EVRC and AMR are both widely deployed and > > > with IMS deployments starting to "spring up" around the > > global it is > > > probably important to also consider these needs. > > > > > > Can we support some mechanism for support codec negotiations with a > > > default "fall back" to G.711 or some other well known default? > > > > > > I do believe that we need to also consider the narrowband > > deployments. > > > > > > Thanks > > > > > > -----Original Message----- > > > From: Francois Menard [mailto:fmenard@xittelecom.com] > > > Sent: Thursday, July 27, 2006 1:41 PM > > > To: Henry Sinnreich > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > > Ed Okerson > > > Subject: Re: [Speermint] Voice codecs > > > > > > > > > I come from Sherbrooke and you know I vote hands down for Speex > > > > > > Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet > > > than people are willing to give him credit for. > > > > > > F. > > > > > > -- > > > Francois D. Menard > > > Project Manager/Charge de projet > > > Xit telecom inc. > > > 1350 Royale # 800 > > > Trois-Rivieres, QC, G9A 4J4 > > > Tel: +1 819 374 2556 x 268 > > > Cell: +1 819 692 1383 > > > fmenard@xittelecom.com > > > > > > > > > On Thu, 27 Jul 2006, Henry Sinnreich wrote: > > > > > >> Sohel, > > >> > > >>> A minimum set of Codecs needs to be supported that includes EvRC. > > >> > > >> How does the EvRC codec compare to the 'Internet Codecs' iLBC and > > > SPEEX? > > >> > > >> - Open source code? > > >> - Licensing fees? > > >> - Audio bandwidth? > > >> - Audio quality package? > > >> - APIs and codec abstraction for developers? > > >> - Independent lab quality assessments, etc.? > > >> > > >> More generic: > > >> > > >> How do all such closed, licensed, _narrowband voice only_ codecs > > > benefit > > >> global Internet communications and why should the IETF care? > > >> > > >> Have you heard of broadband? :-) > > >> (Note: I am a happy EVDO Sprint user). > > >> > > >> Thanks, Henry > > >> > > >> -----Original Message----- > > >> From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > >> Sent: Thursday, July 27, 2006 10:28 AM > > >> To: Jean-Francois Mule; speermint@ietf.org > > >> Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt > > >> > > >> > > >> These issues were discussed before; however, I am trying to reopen > > >> the discussion. > > >> > > >> Section 3.3: > > >> > > >> On Codec requirements: > > >> A minimum set of Codecs needs to be supported that includes EvRC. > > >> > > >> On Editor's note: > > >> Fax, DTMF signaling, TTY/TDD, instant messaging, and > > presence need to > > > be > > >> supported. > > >> > > >> > > >> Thank you. > > >> > > >> Sohel Khan, Ph.D. > > >> Technology Strategist > > >> Sprint-Nextel > > >> 913-794-1470 (office) > > >> 913-486-3145 (cell) > > >> > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > 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 Fri Jul 28 10:47:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Tcu-0004av-7R; Fri, 28 Jul 2006 10:47:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Tcs-0004aq-Nl for speermint@ietf.org; Fri, 28 Jul 2006 10:47:42 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Tcr-0007kG-9G for speermint@ietf.org; Fri, 28 Jul 2006 10:47:42 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k6SElwBL006791 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 28 Jul 2006 07:48:00 -0700 From: "Richard Shockey" To: "'Michael Hammer \(mhammer\)'" , "'Reinaldo Penno'" , "'Klaus Darilion'" , "'Stastny Richard'" Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Fri, 28 Jul 2006 10:47:32 -0400 Message-ID: <00c101c6b254$c332a130$23f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301BF8732@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcavMtjSUN/IyMAXSMSP8ooNPOAI4QAEXLCAAMNvo2AAADVNcA== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us 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 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, July 28, 2006 10:30 AM > To: Reinaldo Penno; Klaus Darilion; Stastny Richard > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t > xt > > I suspect a Federation of like-minded users will be used and setup/agree > to a media policy that specifies that set of codecs that they know and > love. > > Mike I agree. This whole discussion of CODEC's is one reason we are all wandering in the weeds trying to define requirements. I don't believe that there should be any discussion of media policy at all or any type of policy. ITS OUT OF SCOPE!!! You are trying to boil the ocean here. Now it might make sense eventually to have a protocol mechanism to discover "what is the media policy" of a federation and define what constitutes the minimum set of media parameters the federation requires that makes sense. I'm wondering if folks could just try and divide up the problem ( do we know what the problem is) into manageable chunks. We were talking first about discovery, then security and authentication, Long history in IETF circles tells me that anything that looks or smells like a policy protocol or policy decision mechanism is a rat hole we don't want to go into at least not until we knock off the easy stuff which IMHO is discovery and security and authentication. Frankly I would start to carve up the requirements document into Phases or dare I say it Implementation Profiles. > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Monday, July 24, 2006 1:23 PM > > To: Klaus Darilion; Stastny Richard > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] I-D > > ACTION:draft-ietf-speermint-requirements-00.t xt > > > > I tend to agree. One thing is to specify a behavior over a > > peering interface that affects only the peering devices. > > Another is to specify a behavior that affects possibly > > millions of phones (or alternatively a requirement to install > > many of transcoders). > > > > I cannot imagine Sprint changing all its phones to support > > G.711 or Comcast changing all of its phones to support some > > wireless codec because Speermint mandates it. > > > > That leaves only three alternatives: > > > > 1) Do not specify anything in the RFCs and the peers work in > > out whether through some transcoding devices, or some common > > coder when possible. > > > > 2) Specify a minimum set (Can it be done and make everybody happy?) > > > > 3) Let offer/answer decide. I believe this might fall back > > into 1) since I do not believe carriers will just "wing it" > > when it comes to peering. > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > > Sent: Monday, July 24, 2006 8:06 AM > > > To: Stastny Richard > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] I-D > > ACTION:draft-ietf-speermint-requirements-00.t > > > xt > > > > > > Stastny Richard wrote: > > > >> And finally they can't interconnect as A uses AMR and B > > uses G.711. > > > > > > > > They can, if one provides transcoding > > > > > > > > If we say G.711 is mandatory, it is provider A who has to provide > > the > > > transcoding > > > > > > > > > Thus, we have to mandate a minimum set of codecs. > > > > > > regards > > > klaus > > > > > > _______________________________________________ > > > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 28 11:00:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Tpg-0004FX-Uy; Fri, 28 Jul 2006 11:00:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Tpf-0004FQ-Pz for speermint@ietf.org; Fri, 28 Jul 2006 11:00:55 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6Tpe-00015h-Pp for speermint@ietf.org; Fri, 28 Jul 2006 11:00:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Voice codecs Date: Fri, 28 Jul 2006 16:55:34 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B3E@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAPcYCAAAGicMAAAkPui References: <020a01c6b254$75b6a960$640fa8c0@cis.neustar.com> From: "Stastny Richard" To: "Brian Rosen" X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 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 In principle I like Brians idea that each federation defines its minimum = set of codecs they use =20 But keeping in mind the transit case, we may also need a minimum set = defined so we should look at large groups of potential "customers" od speermint and define "their" codec =20 which is as I got from this discussion: G.711, AMR and EvRC (sofar) =20 Richard ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Fr 28.07.2006 16:45 An: 'Khan, Sohel Q [CTO]'; 'Livingood, Jason'; 'Klaus Darilion'; 'Henry = Sinnreich' Cc: speermint@ietf.org; 'Greg Herlein'; 'Ed Okerson' Betreff: RE: [Speermint] Voice codecs Sohel I think this is a mistake.=20 If I were, just to pick an example, the GSMA, and I "sponsored" a = peering system, just for GSMA members, then I don't want EvRC or G.711 in my = fabric. If I am organizing an IM Peering system, then I don't want ANY voice = codec. If I am organizing a video conferencing peering system, I need something quite a bit different than what a VoIP peering system needs. SPEERMINT documents should work well for these federations. This is why = I don't think we can specify an actual codec list. I'd LIKE to do it, because I'd like to be able to build one thing that = works with all federations, but if GSMA is a federation and the IM guys make = one, EvRC just doesn't fit, no way, no how. If there was a real minimum, it would have to be G.711 alone, no other codec, but the IM guys would really squeal. Brian > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Friday, July 28, 2006 10:32 AM > To: Livingood, Jason; Klaus Darilion; Henry Sinnreich > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson > Subject: RE: [Speermint] Voice codecs > > I concur with Jason that a set of lowest common denominator codecs = needs > to be recommended/supported to allow fastest VoIP peering to work. > Let us make this minimum set of list. > For example, the minimum set of codec list =3D {G.711, EvRC, ...} > > Thank you. > > Sohel Khan > > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Friday, July 28, 2006 7:46 AM > To: Klaus Darilion; Henry Sinnreich > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford, Mark A = [CTO] > Subject: RE: [Speermint] Voice codecs > > We ought to at least recognize that in the VoIP server & equipment > market G.711 is probably the one with widest deployment (someone will > now surely cite Skype downloads as a datapoint, I am very familiar = with > it and wish someone from eBay/Skype was participating here). In > wireless, it appears AMR is biggest (due to use by GSM), with EVRC in > second place. This group is not going to be able to push = implementation > of one codec or another (nor should we), whether we like the business > model or social model represented by that codec or not. We do want to > figure out how to get the most people VoIP peering the fastest, and = that > may (or may not) necessitate some lowest common denominator codecs. > That is far from a foregone conclusion and is a subject that will have > to be worked out by the WG over time. > > This of course would not preclude use of other codecs and then = endpoints > could use SIP to (normally) negotiate a different / preferred codec = that > may be newer, lower bandwidth, higher fidelity, less expensive to > license, etc. > > This may also be a moot point in the near future. A recent = conversation > with an endpoint maker gave me the impression that it will be pretty > easy to have all of the codecs we have mentioned here in a very low = cost > endpoint in the near future. Any hardware makers wish to comment on = the > futures / possibilities? > > So keep up the discussion... > > Jason > > > -----Original Message----- > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > Sent: Thursday, July 27, 2006 6:58 PM > > To: Henry Sinnreich > > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford,Mark A = [CTO] > > Subject: RE: [Speermint] Voice codecs > > > > On Thu, July 27, 2006 22:59, Henry Sinnreich said: > > > Mark Lipford writes: > > > > > >> I am OK with SPEEX and iLBC as defaults > > > > > > Thanks and I am very happy we can come closer to an > > agreement on this! > > > > > > Are there any other opinions on using SPEEX and iLBC (RFC > > 3951 and RFC > > > 3952) as defaults for IP-IP broadband? > > > > Yes. Please count the number of terminal adaptor and SIP hardphones > > that support SPEEX and iLBC versus G.711. > > > > regards > > klaus > > > > > > > > > > Thanks again, Henry > > > > > > -----Original Message----- > > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > > Sent: Thursday, July 27, 2006 3:27 PM > > > To: Henry Sinnreich > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; = Francois > > > Menard; Ed Okerson > > > Subject: RE: [Speermint] Voice codecs > > > > > > See inline > > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > Sent: Thursday, July 27, 2006 3:01 PM > > > To: Lipford, Mark A [CTO] > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; = Francois > > > Menard; Ed Okerson > > > Subject: RE: [Speermint] Voice codecs > > > > > > Mark Lipford writes: > > > > > >> Can we support some mechanism for support codec > > negotiations with a > > >> default "fall back" to G.711 > > > > > > Technically, the uncompressed G.711 (1960's PCM) is definitely the > > > worst choice for a default: > > > > > > - Narrow band telephony at 3.1 kHz audio bandwidth (why do we have > > > BB?) > > > - Highest bandwidth consumed: Almost 90 kb/s with > > RTP/UDP/IP overhead > > > - There are better mechanisms for Fax. > > > > > > Why do you avoid SPEEX and iLBC (RFC 3951 and RFC 3952) and > > what are > > > your selection criteria? Can you explain? > > > [Lipford, Mark A [NTK]] I am OK with SPEEX and iLBC as defaults, I > > > used > > > G.711 due to 19 years in Telco :-) The main point I was wanting = to > > > try and gain some agreement around is that narrowband (i.e. > > 3GPP and > > > 3GPP2 3G networks) is/are deploying IMS networks and using EVRC = and > > > AMR. The I-D I am looking at is about Requirements for VoIP > > > interconnection. If this is the case it appears that support for > > > these codecs seems to make some sense. Again, as far as > > SEEX and iLBC > > > are concerned that's OK, I'm just an old telco guy. > > > > > > > > > > > > Thanks, Henry > > > > > > -----Original Message----- > > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > > Sent: Thursday, July 27, 2006 1:46 PM > > > To: Francois Menard; Henry Sinnreich > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > > Ed Okerson > > > Subject: RE: [Speermint] Voice codecs > > > > > > This is in response to the question to Sohel regarding Broadband. > > > > > > Yes, we are very involved in broadband, and believe > > wireless broadband > > > will become extremely active in the next few years, but the > > reality is > > > that in the 3G work both EVRC and AMR are both widely deployed and > > > with IMS deployments starting to "spring up" around the > > global it is > > > probably important to also consider these needs. > > > > > > Can we support some mechanism for support codec negotiations with = a > > > default "fall back" to G.711 or some other well known default? > > > > > > I do believe that we need to also consider the narrowband > > deployments. > > > > > > Thanks > > > > > > -----Original Message----- > > > From: Francois Menard [mailto:fmenard@xittelecom.com] > > > Sent: Thursday, July 27, 2006 1:41 PM > > > To: Henry Sinnreich > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > > Ed Okerson > > > Subject: Re: [Speermint] Voice codecs > > > > > > > > > I come from Sherbrooke and you know I vote hands down for Speex > > > > > > Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet > > > than people are willing to give him credit for. > > > > > > F. > > > > > > -- > > > Francois D. Menard > > > Project Manager/Charge de projet > > > Xit telecom inc. > > > 1350 Royale # 800 > > > Trois-Rivieres, QC, G9A 4J4 > > > Tel: +1 819 374 2556 x 268 > > > Cell: +1 819 692 1383 > > > fmenard@xittelecom.com > > > > > > > > > On Thu, 27 Jul 2006, Henry Sinnreich wrote: > > > > > >> Sohel, > > >> > > >>> A minimum set of Codecs needs to be supported that includes = EvRC. > > >> > > >> How does the EvRC codec compare to the 'Internet Codecs' iLBC and > > > SPEEX? > > >> > > >> - Open source code? > > >> - Licensing fees? > > >> - Audio bandwidth? > > >> - Audio quality package? > > >> - APIs and codec abstraction for developers? > > >> - Independent lab quality assessments, etc.? > > >> > > >> More generic: > > >> > > >> How do all such closed, licensed, _narrowband voice only_ codecs > > > benefit > > >> global Internet communications and why should the IETF care? > > >> > > >> Have you heard of broadband? :-) > > >> (Note: I am a happy EVDO Sprint user). > > >> > > >> Thanks, Henry > > >> > > >> -----Original Message----- > > >> From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > >> Sent: Thursday, July 27, 2006 10:28 AM > > >> To: Jean-Francois Mule; speermint@ietf.org > > >> Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt > > >> > > >> > > >> These issues were discussed before; however, I am trying to = reopen > > >> the discussion. > > >> > > >> Section 3.3: > > >> > > >> On Codec requirements: > > >> A minimum set of Codecs needs to be supported that includes EvRC. > > >> > > >> On Editor's note: > > >> Fax, DTMF signaling, TTY/TDD, instant messaging, and > > presence need to > > > be > > >> supported. > > >> > > >> > > >> Thank you. > > >> > > >> Sohel Khan, Ph.D. > > >> Technology Strategist > > >> Sprint-Nextel > > >> 913-794-1470 (office) > > >> 913-486-3145 (cell) > > >> > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 28 11:05:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6TuJ-0006Qq-6j; Fri, 28 Jul 2006 11:05:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6TuG-0006OD-Uk for speermint@ietf.org; Fri, 28 Jul 2006 11:05:40 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6TuF-0001Nv-TX for speermint@ietf.org; Fri, 28 Jul 2006 11:05:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Voice codecs Date: Fri, 28 Jul 2006 17:02:23 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B3F@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAPcYCAAAGicMAAAkPuiAAA88Bs= References: <020a01c6b254$75b6a960$640fa8c0@cis.neustar.com> <32755D354E6B65498C3BD9FD496C7D462C4B3E@oefeg-s04.oefeg.loc> From: "Stastny Richard" To: "Brian Rosen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9178bae9f85419fdc08e9f2c86e345d0 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 Another possibility would be to let each federation define their codecs and in the transit case the originating network is oblidged to do = transcoding (also as Brian suggests) =20 Richard ________________________________ Von: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Gesendet: Fr 28.07.2006 16:55 An: Brian Rosen Cc: speermint@ietf.org Betreff: Re: [Speermint] Voice codecs In principle I like Brians idea that each federation defines its minimum = set of codecs they use But keeping in mind the transit case, we may also need a minimum set = defined so we should look at large groups of potential "customers" od speermint and define "their" codec which is as I got from this discussion: G.711, AMR and EvRC (sofar) Richard ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Fr 28.07.2006 16:45 An: 'Khan, Sohel Q [CTO]'; 'Livingood, Jason'; 'Klaus Darilion'; 'Henry = Sinnreich' Cc: speermint@ietf.org; 'Greg Herlein'; 'Ed Okerson' Betreff: RE: [Speermint] Voice codecs Sohel I think this is a mistake. If I were, just to pick an example, the GSMA, and I "sponsored" a = peering system, just for GSMA members, then I don't want EvRC or G.711 in my = fabric. If I am organizing an IM Peering system, then I don't want ANY voice = codec. If I am organizing a video conferencing peering system, I need something quite a bit different than what a VoIP peering system needs. SPEERMINT documents should work well for these federations. This is why = I don't think we can specify an actual codec list. I'd LIKE to do it, because I'd like to be able to build one thing that = works with all federations, but if GSMA is a federation and the IM guys make = one, EvRC just doesn't fit, no way, no how. If there was a real minimum, it would have to be G.711 alone, no other codec, but the IM guys would really squeal. Brian > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Friday, July 28, 2006 10:32 AM > To: Livingood, Jason; Klaus Darilion; Henry Sinnreich > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson > Subject: RE: [Speermint] Voice codecs > > I concur with Jason that a set of lowest common denominator codecs = needs > to be recommended/supported to allow fastest VoIP peering to work. > Let us make this minimum set of list. > For example, the minimum set of codec list =3D {G.711, EvRC, ...} > > Thank you. > > Sohel Khan > > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Friday, July 28, 2006 7:46 AM > To: Klaus Darilion; Henry Sinnreich > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford, Mark A = [CTO] > Subject: RE: [Speermint] Voice codecs > > We ought to at least recognize that in the VoIP server & equipment > market G.711 is probably the one with widest deployment (someone will > now surely cite Skype downloads as a datapoint, I am very familiar = with > it and wish someone from eBay/Skype was participating here). In > wireless, it appears AMR is biggest (due to use by GSM), with EVRC in > second place. This group is not going to be able to push = implementation > of one codec or another (nor should we), whether we like the business > model or social model represented by that codec or not. We do want to > figure out how to get the most people VoIP peering the fastest, and = that > may (or may not) necessitate some lowest common denominator codecs. > That is far from a foregone conclusion and is a subject that will have > to be worked out by the WG over time. > > This of course would not preclude use of other codecs and then = endpoints > could use SIP to (normally) negotiate a different / preferred codec = that > may be newer, lower bandwidth, higher fidelity, less expensive to > license, etc. > > This may also be a moot point in the near future. A recent = conversation > with an endpoint maker gave me the impression that it will be pretty > easy to have all of the codecs we have mentioned here in a very low = cost > endpoint in the near future. Any hardware makers wish to comment on = the > futures / possibilities? > > So keep up the discussion... > > Jason > > > -----Original Message----- > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > Sent: Thursday, July 27, 2006 6:58 PM > > To: Henry Sinnreich > > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford,Mark A = [CTO] > > Subject: RE: [Speermint] Voice codecs > > > > On Thu, July 27, 2006 22:59, Henry Sinnreich said: > > > Mark Lipford writes: > > > > > >> I am OK with SPEEX and iLBC as defaults > > > > > > Thanks and I am very happy we can come closer to an > > agreement on this! > > > > > > Are there any other opinions on using SPEEX and iLBC (RFC > > 3951 and RFC > > > 3952) as defaults for IP-IP broadband? > > > > Yes. Please count the number of terminal adaptor and SIP hardphones > > that support SPEEX and iLBC versus G.711. > > > > regards > > klaus > > > > > > > > > > Thanks again, Henry > > > > > > -----Original Message----- > > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > > Sent: Thursday, July 27, 2006 3:27 PM > > > To: Henry Sinnreich > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; = Francois > > > Menard; Ed Okerson > > > Subject: RE: [Speermint] Voice codecs > > > > > > See inline > > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > Sent: Thursday, July 27, 2006 3:01 PM > > > To: Lipford, Mark A [CTO] > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; = Francois > > > Menard; Ed Okerson > > > Subject: RE: [Speermint] Voice codecs > > > > > > Mark Lipford writes: > > > > > >> Can we support some mechanism for support codec > > negotiations with a > > >> default "fall back" to G.711 > > > > > > Technically, the uncompressed G.711 (1960's PCM) is definitely the > > > worst choice for a default: > > > > > > - Narrow band telephony at 3.1 kHz audio bandwidth (why do we have > > > BB?) > > > - Highest bandwidth consumed: Almost 90 kb/s with > > RTP/UDP/IP overhead > > > - There are better mechanisms for Fax. > > > > > > Why do you avoid SPEEX and iLBC (RFC 3951 and RFC 3952) and > > what are > > > your selection criteria? Can you explain? > > > [Lipford, Mark A [NTK]] I am OK with SPEEX and iLBC as defaults, I > > > used > > > G.711 due to 19 years in Telco :-) The main point I was wanting = to > > > try and gain some agreement around is that narrowband (i.e. > > 3GPP and > > > 3GPP2 3G networks) is/are deploying IMS networks and using EVRC = and > > > AMR. The I-D I am looking at is about Requirements for VoIP > > > interconnection. If this is the case it appears that support for > > > these codecs seems to make some sense. Again, as far as > > SEEX and iLBC > > > are concerned that's OK, I'm just an old telco guy. > > > > > > > > > > > > Thanks, Henry > > > > > > -----Original Message----- > > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > > Sent: Thursday, July 27, 2006 1:46 PM > > > To: Francois Menard; Henry Sinnreich > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > > Ed Okerson > > > Subject: RE: [Speermint] Voice codecs > > > > > > This is in response to the question to Sohel regarding Broadband. > > > > > > Yes, we are very involved in broadband, and believe > > wireless broadband > > > will become extremely active in the next few years, but the > > reality is > > > that in the 3G work both EVRC and AMR are both widely deployed and > > > with IMS deployments starting to "spring up" around the > > global it is > > > probably important to also consider these needs. > > > > > > Can we support some mechanism for support codec negotiations with = a > > > default "fall back" to G.711 or some other well known default? > > > > > > I do believe that we need to also consider the narrowband > > deployments. > > > > > > Thanks > > > > > > -----Original Message----- > > > From: Francois Menard [mailto:fmenard@xittelecom.com] > > > Sent: Thursday, July 27, 2006 1:41 PM > > > To: Henry Sinnreich > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > > Ed Okerson > > > Subject: Re: [Speermint] Voice codecs > > > > > > > > > I come from Sherbrooke and you know I vote hands down for Speex > > > > > > Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet > > > than people are willing to give him credit for. > > > > > > F. > > > > > > -- > > > Francois D. Menard > > > Project Manager/Charge de projet > > > Xit telecom inc. > > > 1350 Royale # 800 > > > Trois-Rivieres, QC, G9A 4J4 > > > Tel: +1 819 374 2556 x 268 > > > Cell: +1 819 692 1383 > > > fmenard@xittelecom.com > > > > > > > > > On Thu, 27 Jul 2006, Henry Sinnreich wrote: > > > > > >> Sohel, > > >> > > >>> A minimum set of Codecs needs to be supported that includes = EvRC. > > >> > > >> How does the EvRC codec compare to the 'Internet Codecs' iLBC and > > > SPEEX? > > >> > > >> - Open source code? > > >> - Licensing fees? > > >> - Audio bandwidth? > > >> - Audio quality package? > > >> - APIs and codec abstraction for developers? > > >> - Independent lab quality assessments, etc.? > > >> > > >> More generic: > > >> > > >> How do all such closed, licensed, _narrowband voice only_ codecs > > > benefit > > >> global Internet communications and why should the IETF care? > > >> > > >> Have you heard of broadband? :-) > > >> (Note: I am a happy EVDO Sprint user). > > >> > > >> Thanks, Henry > > >> > > >> -----Original Message----- > > >> From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > >> Sent: Thursday, July 27, 2006 10:28 AM > > >> To: Jean-Francois Mule; speermint@ietf.org > > >> Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt > > >> > > >> > > >> These issues were discussed before; however, I am trying to = reopen > > >> the discussion. > > >> > > >> Section 3.3: > > >> > > >> On Codec requirements: > > >> A minimum set of Codecs needs to be supported that includes EvRC. > > >> > > >> On Editor's note: > > >> Fax, DTMF signaling, TTY/TDD, instant messaging, and > > presence need to > > > be > > >> supported. > > >> > > >> > > >> Thank you. > > >> > > >> Sohel Khan, Ph.D. > > >> Technology Strategist > > >> Sprint-Nextel > > >> 913-794-1470 (office) > > >> 913-486-3145 (cell) > > >> > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > 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 _______________________________________________ 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 Jul 28 11:10:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Tyg-0004lA-2W; Fri, 28 Jul 2006 11:10:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Tyf-0004l4-5L for speermint@ietf.org; Fri, 28 Jul 2006 11:10:13 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Tyc-0001yh-PM for speermint@ietf.org; Fri, 28 Jul 2006 11:10:13 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k6SFA9iI018441; Fri, 28 Jul 2006 08:10:09 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k6SFA9X3018440; Fri, 28 Jul 2006 08:10:09 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 28 Jul 2006 08:10:09 -0700 From: David Meyer To: Richard Shockey Subject: Re: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Message-ID: <20060728151009.GA18384@1-4-5.net> References: <072C5B76F7CEAB488172C6F64B30B5E301BF8732@xmb-rtp-20b.amer.cisco.com> <00c101c6b254$c332a130$23f0a544@cis.neustar.com> Mime-Version: 1.0 In-Reply-To: <00c101c6b254$c332a130$23f0a544@cis.neustar.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: 'Stastny Richard' , 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: , Content-Type: multipart/mixed; boundary="===============1604208477==" Errors-To: speermint-bounces@ietf.org --===============1604208477== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 28, 2006 at 10:47:32AM -0400, Richard Shockey wrote: >=20 >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Friday, July 28, 2006 10:30 AM > > To: Reinaldo Penno; Klaus Darilion; Stastny Richard > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-0= 0.t > > xt > >=20 > > I suspect a Federation of like-minded users will be used and setup/agree > > to a media policy that specifies that set of codecs that they know and > > love. > >=20 > > Mike >=20 >=20 > I agree. This whole discussion of CODEC's is one reason we are all wander= ing > in the weeds trying to define requirements. >=20 > I don't believe that there should be any discussion of media policy at all > or any type of policy. >=20 > ITS OUT OF SCOPE!!! You are trying to boil the ocean here. I believe this is correct as well. And has been pointed out to me (and others) on several occasions, the selection of a default codec is an absolutely unsolvable problem. It has an intractable set of IPR issues, and (learning from history) many other SDOs have stumbled all over this issue and in the process have failed to select a codec baseline. Let's not add SPEERMINT to that list. A lot of WG email list b/w has been spent on this, with little resolution (on the contrary, I would posit). Let's not fall down this (rat) hole again. --dmm --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEyijRORgD1qCZ2KcRAgTzAJ4o6LIWBOohk0qXM+yhIWr2+ytCpgCffdlA Mov8hVUu2+dEd5BYX92EErw= =CyH9 -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- --===============1604208477== 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 --===============1604208477==-- From speermint-bounces@ietf.org Fri Jul 28 11:49:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Uao-0002jI-RD; Fri, 28 Jul 2006 11:49:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Uan-0002jD-Hg for speermint@ietf.org; Fri, 28 Jul 2006 11:49:37 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Uam-0003gH-US for speermint@ietf.org; Fri, 28 Jul 2006 11:49:37 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k6SFnZaK005376; Fri, 28 Jul 2006 15:49:35 GMT Subject: Re: [Speermint] Voice codecs From: Daryl Malas To: Stastny Richard In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B3F@oefeg-s04.oefeg.loc> References: <020a01c6b254$75b6a960$640fa8c0@cis.neustar.com> <32755D354E6B65498C3BD9FD496C7D462C4B3E@oefeg-s04.oefeg.loc> <32755D354E6B65498C3BD9FD496C7D462C4B3F@oefeg-s04.oefeg.loc> Content-Type: text/plain Date: Fri, 28 Jul 2006 09:50:39 -0600 Message-Id: <1154101839.19821.132.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: 0.1 (/) X-Scan-Signature: 2fe944273194be3112d13b31c91e6941 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 generally agree with Richard and Brian's comments. I don't understand this conversation. Does RFC 3261 say all SIP UA's MUST support G.711 or any other codec? This doesn't make any sense to me. When I setup a peering relationship with someone, I'm going to say..."Hey, I use the "X" codec....I hope you do too, or we'll have to do some transcoding!" I might suggest another method too...as defined in RFC 3261, a peer could send an OPTIONS message to query for supported codecs, then determine which one it supports and then send the appropriate codec in the SDP. I think much of this will be sorted out in setting up the peering relationship....as far as "Transit" peers...uh...oh...here we go again. ;-) Transits will naturally occur as peers are members of more than one federation and opt to offer hosted signaling functions for agreed upon peers in other federations. Transcoding may have to occur here for any hosted media functions. I just think explaining how this might occur is a good step, but saying any codec is a MUST is a mistake. Daryl On Fri, 2006-07-28 at 17:02 +0200, Stastny Richard wrote: > Another possibility would be to let each federation define their codecs > and in the transit case the originating network is oblidged to do transcoding > (also as Brian suggests) > > Richard > > ________________________________ > > Von: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Gesendet: Fr 28.07.2006 16:55 > An: Brian Rosen > Cc: speermint@ietf.org > Betreff: Re: [Speermint] Voice codecs > > > > In principle I like Brians idea that each federation defines its minimum set of codecs they use > > But keeping in mind the transit case, we may also need a minimum set defined > so we should look at large groups of potential "customers" od speermint > and define "their" codec > > which is as I got from this discussion: G.711, AMR and EvRC (sofar) > > Richard > > ________________________________ > > Von: Brian Rosen [mailto:br@brianrosen.net] > Gesendet: Fr 28.07.2006 16:45 > An: 'Khan, Sohel Q [CTO]'; 'Livingood, Jason'; 'Klaus Darilion'; 'Henry Sinnreich' > Cc: speermint@ietf.org; 'Greg Herlein'; 'Ed Okerson' > Betreff: RE: [Speermint] Voice codecs > > > > Sohel > > I think this is a mistake. > > If I were, just to pick an example, the GSMA, and I "sponsored" a peering > system, just for GSMA members, then I don't want EvRC or G.711 in my fabric. > > If I am organizing an IM Peering system, then I don't want ANY voice codec. > > If I am organizing a video conferencing peering system, I need something > quite a bit different than what a VoIP peering system needs. > > SPEERMINT documents should work well for these federations. This is why I > don't think we can specify an actual codec list. > > I'd LIKE to do it, because I'd like to be able to build one thing that works > with all federations, but if GSMA is a federation and the IM guys make one, > EvRC just doesn't fit, no way, no how. > > If there was a real minimum, it would have to be G.711 alone, no other > codec, but the IM guys would really squeal. > > Brian > > > -----Original Message----- > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Sent: Friday, July 28, 2006 10:32 AM > > To: Livingood, Jason; Klaus Darilion; Henry Sinnreich > > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson > > Subject: RE: [Speermint] Voice codecs > > > > I concur with Jason that a set of lowest common denominator codecs needs > > to be recommended/supported to allow fastest VoIP peering to work. > > Let us make this minimum set of list. > > For example, the minimum set of codec list = {G.711, EvRC, ...} > > > > Thank you. > > > > Sohel Khan > > > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Friday, July 28, 2006 7:46 AM > > To: Klaus Darilion; Henry Sinnreich > > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford, Mark A [CTO] > > Subject: RE: [Speermint] Voice codecs > > > > We ought to at least recognize that in the VoIP server & equipment > > market G.711 is probably the one with widest deployment (someone will > > now surely cite Skype downloads as a datapoint, I am very familiar with > > it and wish someone from eBay/Skype was participating here). In > > wireless, it appears AMR is biggest (due to use by GSM), with EVRC in > > second place. This group is not going to be able to push implementation > > of one codec or another (nor should we), whether we like the business > > model or social model represented by that codec or not. We do want to > > figure out how to get the most people VoIP peering the fastest, and that > > may (or may not) necessitate some lowest common denominator codecs. > > That is far from a foregone conclusion and is a subject that will have > > to be worked out by the WG over time. > > > > This of course would not preclude use of other codecs and then endpoints > > could use SIP to (normally) negotiate a different / preferred codec that > > may be newer, lower bandwidth, higher fidelity, less expensive to > > license, etc. > > > > This may also be a moot point in the near future. A recent conversation > > with an endpoint maker gave me the impression that it will be pretty > > easy to have all of the codecs we have mentioned here in a very low cost > > endpoint in the near future. Any hardware makers wish to comment on the > > futures / possibilities? > > > > So keep up the discussion... > > > > Jason > > > > > -----Original Message----- > > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > > Sent: Thursday, July 27, 2006 6:58 PM > > > To: Henry Sinnreich > > > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford,Mark A [CTO] > > > Subject: RE: [Speermint] Voice codecs > > > > > > On Thu, July 27, 2006 22:59, Henry Sinnreich said: > > > > Mark Lipford writes: > > > > > > > >> I am OK with SPEEX and iLBC as defaults > > > > > > > > Thanks and I am very happy we can come closer to an > > > agreement on this! > > > > > > > > Are there any other opinions on using SPEEX and iLBC (RFC > > > 3951 and RFC > > > > 3952) as defaults for IP-IP broadband? > > > > > > Yes. Please count the number of terminal adaptor and SIP hardphones > > > that support SPEEX and iLBC versus G.711. > > > > > > regards > > > klaus > > > > > > > > > > > > > > Thanks again, Henry > > > > > > > > -----Original Message----- > > > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > > > Sent: Thursday, July 27, 2006 3:27 PM > > > > To: Henry Sinnreich > > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois > > > > Menard; Ed Okerson > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > See inline > > > > > > > > -----Original Message----- > > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > > Sent: Thursday, July 27, 2006 3:01 PM > > > > To: Lipford, Mark A [CTO] > > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois > > > > Menard; Ed Okerson > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > Mark Lipford writes: > > > > > > > >> Can we support some mechanism for support codec > > > negotiations with a > > > >> default "fall back" to G.711 > > > > > > > > Technically, the uncompressed G.711 (1960's PCM) is definitely the > > > > worst choice for a default: > > > > > > > > - Narrow band telephony at 3.1 kHz audio bandwidth (why do we have > > > > BB?) > > > > - Highest bandwidth consumed: Almost 90 kb/s with > > > RTP/UDP/IP overhead > > > > - There are better mechanisms for Fax. > > > > > > > > Why do you avoid SPEEX and iLBC (RFC 3951 and RFC 3952) and > > > what are > > > > your selection criteria? Can you explain? > > > > [Lipford, Mark A [NTK]] I am OK with SPEEX and iLBC as defaults, I > > > > used > > > > G.711 due to 19 years in Telco :-) The main point I was wanting to > > > > try and gain some agreement around is that narrowband (i.e. > > > 3GPP and > > > > 3GPP2 3G networks) is/are deploying IMS networks and using EVRC and > > > > AMR. The I-D I am looking at is about Requirements for VoIP > > > > interconnection. If this is the case it appears that support for > > > > these codecs seems to make some sense. Again, as far as > > > SEEX and iLBC > > > > are concerned that's OK, I'm just an old telco guy. > > > > > > > > > > > > > > > > Thanks, Henry > > > > > > > > -----Original Message----- > > > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > > > Sent: Thursday, July 27, 2006 1:46 PM > > > > To: Francois Menard; Henry Sinnreich > > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > > > Ed Okerson > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > This is in response to the question to Sohel regarding Broadband. > > > > > > > > Yes, we are very involved in broadband, and believe > > > wireless broadband > > > > will become extremely active in the next few years, but the > > > reality is > > > > that in the 3G work both EVRC and AMR are both widely deployed and > > > > with IMS deployments starting to "spring up" around the > > > global it is > > > > probably important to also consider these needs. > > > > > > > > Can we support some mechanism for support codec negotiations with a > > > > default "fall back" to G.711 or some other well known default? > > > > > > > > I do believe that we need to also consider the narrowband > > > deployments. > > > > > > > > Thanks > > > > > > > > -----Original Message----- > > > > From: Francois Menard [mailto:fmenard@xittelecom.com] > > > > Sent: Thursday, July 27, 2006 1:41 PM > > > > To: Henry Sinnreich > > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > > > Ed Okerson > > > > Subject: Re: [Speermint] Voice codecs > > > > > > > > > > > > I come from Sherbrooke and you know I vote hands down for Speex > > > > > > > > Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet > > > > than people are willing to give him credit for. > > > > > > > > F. > > > > > > > > -- > > > > Francois D. Menard > > > > Project Manager/Charge de projet > > > > Xit telecom inc. > > > > 1350 Royale # 800 > > > > Trois-Rivieres, QC, G9A 4J4 > > > > Tel: +1 819 374 2556 x 268 > > > > Cell: +1 819 692 1383 > > > > fmenard@xittelecom.com > > > > > > > > > > > > On Thu, 27 Jul 2006, Henry Sinnreich wrote: > > > > > > > >> Sohel, > > > >> > > > >>> A minimum set of Codecs needs to be supported that includes EvRC. > > > >> > > > >> How does the EvRC codec compare to the 'Internet Codecs' iLBC and > > > > SPEEX? > > > >> > > > >> - Open source code? > > > >> - Licensing fees? > > > >> - Audio bandwidth? > > > >> - Audio quality package? > > > >> - APIs and codec abstraction for developers? > > > >> - Independent lab quality assessments, etc.? > > > >> > > > >> More generic: > > > >> > > > >> How do all such closed, licensed, _narrowband voice only_ codecs > > > > benefit > > > >> global Internet communications and why should the IETF care? > > > >> > > > >> Have you heard of broadband? :-) > > > >> (Note: I am a happy EVDO Sprint user). > > > >> > > > >> Thanks, Henry > > > >> > > > >> -----Original Message----- > > > >> From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > > >> Sent: Thursday, July 27, 2006 10:28 AM > > > >> To: Jean-Francois Mule; speermint@ietf.org > > > >> Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt > > > >> > > > >> > > > >> These issues were discussed before; however, I am trying to reopen > > > >> the discussion. > > > >> > > > >> Section 3.3: > > > >> > > > >> On Codec requirements: > > > >> A minimum set of Codecs needs to be supported that includes EvRC. > > > >> > > > >> On Editor's note: > > > >> Fax, DTMF signaling, TTY/TDD, instant messaging, and > > > presence need to > > > > be > > > >> supported. > > > >> > > > >> > > > >> Thank you. > > > >> > > > >> Sohel Khan, Ph.D. > > > >> Technology Strategist > > > >> Sprint-Nextel > > > >> 913-794-1470 (office) > > > >> 913-486-3145 (cell) > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> 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 > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > _______________________________________________ > > 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 > > > > _______________________________________________ > 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 Fri Jul 28 12:22:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6V6j-0005BB-Eg; Fri, 28 Jul 2006 12:22:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6V6i-0005B3-Eo for speermint@ietf.org; Fri, 28 Jul 2006 12:22:36 -0400 Received: from outbound-red.frontbridge.com ([216.148.222.49] helo=outbound2-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6V6e-00060M-5V for speermint@ietf.org; Fri, 28 Jul 2006 12:22:36 -0400 Received: from outbound2-red.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-red-R.bigfish.com (Postfix) with ESMTP id 406F4FB9362; Fri, 28 Jul 2006 16:22:31 +0000 (UTC) Received: from mail41-red-R.bigfish.com (unknown [172.18.12.3]) by outbound2-red.bigfish.com (Postfix) with ESMTP id 3384AFB9411; Fri, 28 Jul 2006 16:22:31 +0000 (UTC) Received: from mail41-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail41-red-R.bigfish.com (Postfix) with ESMTP id 0DA7E6EFCF1; Fri, 28 Jul 2006 16:22:31 +0000 (UTC) X-BigFish: V Received: by mail41-red (MessageSwitch) id 1154103750728841_16266; Fri, 28 Jul 2006 16:22:30 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail41-red.bigfish.com (Postfix) with ESMTP id 805316D0B63; Fri, 28 Jul 2006 16:22:30 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k6SGMTqd026738; Fri, 28 Jul 2006 11:22:29 -0500 (CDT) Received: from pdawg05a.ad.sprint.com (PDAWG05A.corp.sprint.com [10.122.2.38]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k6SGMSX17011; Fri, 28 Jul 2006 11:22:28 -0500 (CDT) Received: from PDAWB14C.ad.sprint.com ([144.226.76.137]) by pdawg05a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 11:22:29 -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] Voice codecs Date: Fri, 28 Jul 2006 11:22:28 -0500 Message-ID: <1A8DCAFC5DC73B4D94081BDCF028A2030605955A@PDAWB14C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: AcayXXt2DzSppIKjSPuz0pnD2LN3qwAA/7/w From: "Lipford, Mark A [CTO]" To: "Daryl Malas" , "Stastny Richard" X-OriginalArrivalTime: 28 Jul 2006 16:22:29.0065 (UTC) FILETIME=[0536BB90:01C6B262] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7cb76adb986247703cbb5582da68b5fc 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, You mention using the OPTION message, I actually asked if this was a possibility in my original message, with the recommendation of defaulting to G.711 or some other codec. If I follow you line of thinking that that of others then let's simply require either using the OPTION message, to determine the codec, or some other method agreeable to the peering networks. My comment was based on the second bullet in 3.3 of the requirements draft (version 00) -----Original Message----- From: Daryl Malas [mailto:daryl@level3.net]=20 Sent: Friday, July 28, 2006 10:51 AM To: Stastny Richard Cc: speermint@ietf.org Subject: Re: [Speermint] Voice codecs I generally agree with Richard and Brian's comments. I don't understand this conversation. Does RFC 3261 say all SIP UA's MUST support G.711 or any other codec? This doesn't make any sense to me. When I setup a peering relationship with someone, I'm going to say..."Hey, I use the "X" codec....I hope you do too, or we'll have to do some transcoding!" I might suggest another method too...as defined in RFC 3261, a peer could send an OPTIONS message to query for supported codecs, then determine which one it supports and then send the appropriate codec in the SDP. I think much of this will be sorted out in setting up the peering relationship....as far as "Transit" peers...uh...oh...here we go again. ;-) Transits will naturally occur as peers are members of more than one federation and opt to offer hosted signaling functions for agreed upon peers in other federations. Transcoding may have to occur here for any hosted media functions. I just think explaining how this might occur is a good step, but saying any codec is a MUST is a mistake. Daryl On Fri, 2006-07-28 at 17:02 +0200, Stastny Richard wrote: > Another possibility would be to let each federation define their codecs > and in the transit case the originating network is oblidged to do transcoding > (also as Brian suggests) > =20 > Richard >=20 > ________________________________ >=20 > Von: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Gesendet: Fr 28.07.2006 16:55 > An: Brian Rosen > Cc: speermint@ietf.org > Betreff: Re: [Speermint] Voice codecs >=20 >=20 >=20 > In principle I like Brians idea that each federation defines its minimum set of codecs they use >=20 > But keeping in mind the transit case, we may also need a minimum set defined > so we should look at large groups of potential "customers" od speermint > and define "their" codec >=20 > which is as I got from this discussion: G.711, AMR and EvRC (sofar) >=20 > Richard >=20 > ________________________________ >=20 > Von: Brian Rosen [mailto:br@brianrosen.net] > Gesendet: Fr 28.07.2006 16:45 > An: 'Khan, Sohel Q [CTO]'; 'Livingood, Jason'; 'Klaus Darilion'; 'Henry Sinnreich' > Cc: speermint@ietf.org; 'Greg Herlein'; 'Ed Okerson' > Betreff: RE: [Speermint] Voice codecs >=20 >=20 >=20 > Sohel >=20 > I think this is a mistake. >=20 > If I were, just to pick an example, the GSMA, and I "sponsored" a peering > system, just for GSMA members, then I don't want EvRC or G.711 in my fabric. >=20 > If I am organizing an IM Peering system, then I don't want ANY voice codec. >=20 > If I am organizing a video conferencing peering system, I need something > quite a bit different than what a VoIP peering system needs. >=20 > SPEERMINT documents should work well for these federations. This is why I > don't think we can specify an actual codec list. >=20 > I'd LIKE to do it, because I'd like to be able to build one thing that works > with all federations, but if GSMA is a federation and the IM guys make one, > EvRC just doesn't fit, no way, no how. >=20 > If there was a real minimum, it would have to be G.711 alone, no other > codec, but the IM guys would really squeal. >=20 > Brian >=20 > > -----Original Message----- > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Sent: Friday, July 28, 2006 10:32 AM > > To: Livingood, Jason; Klaus Darilion; Henry Sinnreich > > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson > > Subject: RE: [Speermint] Voice codecs > > > > I concur with Jason that a set of lowest common denominator codecs needs > > to be recommended/supported to allow fastest VoIP peering to work. > > Let us make this minimum set of list. > > For example, the minimum set of codec list =3D {G.711, EvRC, ...} > > > > Thank you. > > > > Sohel Khan > > > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Friday, July 28, 2006 7:46 AM > > To: Klaus Darilion; Henry Sinnreich > > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford, Mark A [CTO] > > Subject: RE: [Speermint] Voice codecs > > > > We ought to at least recognize that in the VoIP server & equipment > > market G.711 is probably the one with widest deployment (someone will > > now surely cite Skype downloads as a datapoint, I am very familiar with > > it and wish someone from eBay/Skype was participating here). In > > wireless, it appears AMR is biggest (due to use by GSM), with EVRC in > > second place. This group is not going to be able to push implementation > > of one codec or another (nor should we), whether we like the business > > model or social model represented by that codec or not. We do want to > > figure out how to get the most people VoIP peering the fastest, and that > > may (or may not) necessitate some lowest common denominator codecs. > > That is far from a foregone conclusion and is a subject that will have > > to be worked out by the WG over time. > > > > This of course would not preclude use of other codecs and then endpoints > > could use SIP to (normally) negotiate a different / preferred codec that > > may be newer, lower bandwidth, higher fidelity, less expensive to > > license, etc. > > > > This may also be a moot point in the near future. A recent conversation > > with an endpoint maker gave me the impression that it will be pretty > > easy to have all of the codecs we have mentioned here in a very low cost > > endpoint in the near future. Any hardware makers wish to comment on the > > futures / possibilities? > > > > So keep up the discussion... > > > > Jason > > > > > -----Original Message----- > > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > > Sent: Thursday, July 27, 2006 6:58 PM > > > To: Henry Sinnreich > > > Cc: speermint@ietf.org; Greg Herlein; Ed Okerson; Lipford,Mark A [CTO] > > > Subject: RE: [Speermint] Voice codecs > > > > > > On Thu, July 27, 2006 22:59, Henry Sinnreich said: > > > > Mark Lipford writes: > > > > > > > >> I am OK with SPEEX and iLBC as defaults > > > > > > > > Thanks and I am very happy we can come closer to an > > > agreement on this! > > > > > > > > Are there any other opinions on using SPEEX and iLBC (RFC > > > 3951 and RFC > > > > 3952) as defaults for IP-IP broadband? > > > > > > Yes. Please count the number of terminal adaptor and SIP hardphones > > > that support SPEEX and iLBC versus G.711. > > > > > > regards > > > klaus > > > > > > > > > > > > > > Thanks again, Henry > > > > > > > > -----Original Message----- > > > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > > > Sent: Thursday, July 27, 2006 3:27 PM > > > > To: Henry Sinnreich > > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois > > > > Menard; Ed Okerson > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > See inline > > > > > > > > -----Original Message----- > > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > > Sent: Thursday, July 27, 2006 3:01 PM > > > > To: Lipford, Mark A [CTO] > > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; Francois > > > > Menard; Ed Okerson > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > Mark Lipford writes: > > > > > > > >> Can we support some mechanism for support codec > > > negotiations with a > > > >> default "fall back" to G.711 > > > > > > > > Technically, the uncompressed G.711 (1960's PCM) is definitely the > > > > worst choice for a default: > > > > > > > > - Narrow band telephony at 3.1 kHz audio bandwidth (why do we have > > > > BB?) > > > > - Highest bandwidth consumed: Almost 90 kb/s with > > > RTP/UDP/IP overhead > > > > - There are better mechanisms for Fax. > > > > > > > > Why do you avoid SPEEX and iLBC (RFC 3951 and RFC 3952) and > > > what are > > > > your selection criteria? Can you explain? > > > > [Lipford, Mark A [NTK]] I am OK with SPEEX and iLBC as defaults, I > > > > used > > > > G.711 due to 19 years in Telco :-) The main point I was wanting to > > > > try and gain some agreement around is that narrowband (i.e. > > > 3GPP and > > > > 3GPP2 3G networks) is/are deploying IMS networks and using EVRC and > > > > AMR. The I-D I am looking at is about Requirements for VoIP > > > > interconnection. If this is the case it appears that support for > > > > these codecs seems to make some sense. Again, as far as > > > SEEX and iLBC > > > > are concerned that's OK, I'm just an old telco guy. > > > > > > > > > > > > > > > > Thanks, Henry > > > > > > > > -----Original Message----- > > > > From: Lipford, Mark A [CTO] [mailto:Mark.A.Lipford@sprint.com] > > > > Sent: Thursday, July 27, 2006 1:46 PM > > > > To: Francois Menard; Henry Sinnreich > > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > > > Ed Okerson > > > > Subject: RE: [Speermint] Voice codecs > > > > > > > > This is in response to the question to Sohel regarding Broadband. > > > > > > > > Yes, we are very involved in broadband, and believe > > > wireless broadband > > > > will become extremely active in the next few years, but the > > > reality is > > > > that in the 3G work both EVRC and AMR are both widely deployed and > > > > with IMS deployments starting to "spring up" around the > > > global it is > > > > probably important to also consider these needs. > > > > > > > > Can we support some mechanism for support codec negotiations with a > > > > default "fall back" to G.711 or some other well known default? > > > > > > > > I do believe that we need to also consider the narrowband > > > deployments. > > > > > > > > Thanks > > > > > > > > -----Original Message----- > > > > From: Francois Menard [mailto:fmenard@xittelecom.com] > > > > Sent: Thursday, July 27, 2006 1:41 PM > > > > To: Henry Sinnreich > > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org; Greg Herlein; > > > Ed Okerson > > > > Subject: Re: [Speermint] Voice codecs > > > > > > > > > > > > I come from Sherbrooke and you know I vote hands down for Speex > > > > > > > > Jean-Marc Valin prof @ U Sherbrooke has done more for the Internet > > > > than people are willing to give him credit for. > > > > > > > > F. > > > > > > > > -- > > > > Francois D. Menard > > > > Project Manager/Charge de projet > > > > Xit telecom inc. > > > > 1350 Royale # 800 > > > > Trois-Rivieres, QC, G9A 4J4 > > > > Tel: +1 819 374 2556 x 268 > > > > Cell: +1 819 692 1383 > > > > fmenard@xittelecom.com > > > > > > > > > > > > On Thu, 27 Jul 2006, Henry Sinnreich wrote: > > > > > > > >> Sohel, > > > >> > > > >>> A minimum set of Codecs needs to be supported that includes EvRC. > > > >> > > > >> How does the EvRC codec compare to the 'Internet Codecs' iLBC and > > > > SPEEX? > > > >> > > > >> - Open source code? > > > >> - Licensing fees? > > > >> - Audio bandwidth? > > > >> - Audio quality package? > > > >> - APIs and codec abstraction for developers? > > > >> - Independent lab quality assessments, etc.? > > > >> > > > >> More generic: > > > >> > > > >> How do all such closed, licensed, _narrowband voice only_ codecs > > > > benefit > > > >> global Internet communications and why should the IETF care? > > > >> > > > >> Have you heard of broadband? :-) > > > >> (Note: I am a happy EVDO Sprint user). > > > >> > > > >> Thanks, Henry > > > >> > > > >> -----Original Message----- > > > >> From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > > >> Sent: Thursday, July 27, 2006 10:28 AM > > > >> To: Jean-Francois Mule; speermint@ietf.org > > > >> Subject: [Speermint] Draft-ietf-speermint-requirements-00.txt > > > >> > > > >> > > > >> These issues were discussed before; however, I am trying to reopen > > > >> the discussion. > > > >> > > > >> Section 3.3: > > > >> > > > >> On Codec requirements: > > > >> A minimum set of Codecs needs to be supported that includes EvRC. > > > >> > > > >> On Editor's note: > > > >> Fax, DTMF signaling, TTY/TDD, instant messaging, and > > > presence need to > > > > be > > > >> supported. > > > >> > > > >> > > > >> Thank you. > > > >> > > > >> Sohel Khan, Ph.D. > > > >> Technology Strategist > > > >> Sprint-Nextel > > > >> 913-794-1470 (office) > > > >> 913-486-3145 (cell) > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> 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 > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > _______________________________________________ > > 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 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 28 12:29:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6VDL-000645-Lp; Fri, 28 Jul 2006 12:29:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6VDL-00063g-9v for speermint@ietf.org; Fri, 28 Jul 2006 12:29:27 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6VDK-0007r4-36 for speermint@ietf.org; Fri, 28 Jul 2006 12:29:27 -0400 Received: from lion.cs.columbia.edu (IDENT:XUpCj6T4zU6UflSS/h/FgfgyWmq8ED+s@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6SGTKf7000244 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 28 Jul 2006 12:29:20 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k6SGTJrh030863 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 28 Jul 2006 12:29:19 -0400 Message-ID: <44CA3B5A.6000904@cs.columbia.edu> Date: Fri, 28 Jul 2006 12:29:14 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Lipford, Mark A [CTO]" Subject: Re: [Speermint] Voice codecs References: <1A8DCAFC5DC73B4D94081BDCF028A2030605955A@PDAWB14C.ad.sprint.com> In-Reply-To: <1A8DCAFC5DC73B4D94081BDCF028A2030605955A@PDAWB14C.ad.sprint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.28.90932 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0, __cbl.abuseat.org_TIMEOUT ' X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Stastny Richard , 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'm confused by this whole discussion. Is the assumption that a carrier restricts what kind of devices, codecs and software any customer is allowed to use? Are we going back to the pre-Carterphone days? Lipford, Mark A [CTO] wrote: > Daryl, > > You mention using the OPTION message, I actually asked if this was a > possibility in my original message, with the recommendation of > defaulting to G.711 or some other codec. If I follow you line of > thinking that that of others then let's simply require either using the > OPTION message, to determine the codec, or some other method agreeable > to the peering networks. > > My comment was based on the second bullet in 3.3 of the requirements > draft (version 00) > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 28 12:38:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6VLr-0008Oy-Ki; Fri, 28 Jul 2006 12:38:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6VLq-0008Os-7X for speermint@ietf.org; Fri, 28 Jul 2006 12:38:14 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6VLp-00013l-QE for speermint@ietf.org; Fri, 28 Jul 2006 12:38:14 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k6SGcCaK000346; Fri, 28 Jul 2006 16:38:12 GMT Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt From: Daryl Malas To: richard@shockey.us In-Reply-To: <00c101c6b254$c332a130$23f0a544@cis.neustar.com> References: <00c101c6b254$c332a130$23f0a544@cis.neustar.com> Content-Type: text/plain Date: Fri, 28 Jul 2006 10:39:14 -0600 Message-Id: <1154104754.19821.135.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: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: 'Stastny Richard' , 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 Comments in-line... On Fri, 2006-07-28 at 10:47 -0400, Richard Shockey wrote: > > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Friday, July 28, 2006 10:30 AM > > To: Reinaldo Penno; Klaus Darilion; Stastny Richard > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t > > xt > > > > I suspect a Federation of like-minded users will be used and setup/agree > > to a media policy that specifies that set of codecs that they know and > > love. > > YES!! Agreed! Agreed! > > > Mike > > > I agree. This whole discussion of CODEC's is one reason we are all wandering > in the weeds trying to define requirements. > > I don't believe that there should be any discussion of media policy at all > or any type of policy. > > ITS OUT OF SCOPE!!! You are trying to boil the ocean here. YES!! Agreed! Agreed! > > Now it might make sense eventually to have a protocol mechanism to discover > "what is the media policy" of a federation and define what constitutes the > minimum set of media parameters the federation requires that makes sense. > > I'm wondering if folks could just try and divide up the problem ( do we know > what the problem is) into manageable chunks. > > We were talking first about discovery, then security and authentication, > > Long history in IETF circles tells me that anything that looks or smells > like a policy protocol or policy decision mechanism is a rat hole we don't > want to go into at least not until we knock off the easy stuff which IMHO is > discovery and security and authentication. > > Frankly I would start to carve up the requirements document into Phases or > dare I say it Implementation Profiles. > > > > > > > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: Monday, July 24, 2006 1:23 PM > > > To: Klaus Darilion; Stastny Richard > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] I-D > > > ACTION:draft-ietf-speermint-requirements-00.t xt > > > > > > I tend to agree. One thing is to specify a behavior over a > > > peering interface that affects only the peering devices. > > > Another is to specify a behavior that affects possibly > > > millions of phones (or alternatively a requirement to install > > > many of transcoders). > > > > > > I cannot imagine Sprint changing all its phones to support > > > G.711 or Comcast changing all of its phones to support some > > > wireless codec because Speermint mandates it. > > > > > > That leaves only three alternatives: > > > > > > 1) Do not specify anything in the RFCs and the peers work in > > > out whether through some transcoding devices, or some common > > > coder when possible. > > > > > > 2) Specify a minimum set (Can it be done and make everybody happy?) > > > > > > 3) Let offer/answer decide. I believe this might fall back > > > into 1) since I do not believe carriers will just "wing it" > > > when it comes to peering. > > > > > > Regards, > > > > > > Reinaldo > > > > > > > -----Original Message----- > > > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > > > Sent: Monday, July 24, 2006 8:06 AM > > > > To: Stastny Richard > > > > Cc: speermint@ietf.org > > > > Subject: Re: [Speermint] I-D > > > ACTION:draft-ietf-speermint-requirements-00.t > > > > xt > > > > > > > > Stastny Richard wrote: > > > > >> And finally they can't interconnect as A uses AMR and B > > > uses G.711. > > > > > > > > > > They can, if one provides transcoding > > > > > > > > > > If we say G.711 is mandatory, it is provider A who has to provide > > > the > > > > transcoding > > > > > > > > > > > > Thus, we have to mandate a minimum set of codecs. > > > > > > > > regards > > > > klaus > > > > > > > > _______________________________________________ > > > > 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 > > > _______________________________________________ > 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 Jul 28 12:38:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6VMV-0000Xp-D5; Fri, 28 Jul 2006 12:38:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6VMT-0000Xk-Go for speermint@ietf.org; Fri, 28 Jul 2006 12:38:53 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6VMS-00018o-5s for speermint@ietf.org; Fri, 28 Jul 2006 12:38:53 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 28 Jul 2006 09:38:53 -0700 X-IronPort-AV: i="4.07,192,1151910000"; d="scan'208"; a="572019042:sNHT32300384" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Fri, 28 Jul 2006 12:38:58 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804F94FEE@proton.jnpr.net> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301BF8732@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Thread-Index: AcavMtjSUN/IyMAXSMSP8ooNPOAI4QAEXLCAAMNvo2AABG+jMA== From: "Reinaldo Penno" To: "Michael Hammer \(mhammer\)" , "Klaus Darilion" , "Stastny Richard" 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 Exactly. And just like Daryl said, carriers/SP/VSPs will just work out their differences whether because they discover somehow they support a common denominator codec or through the use of transcoding. In the case of a federation maybe it is enough that, for example, only one member supports AMR to G.711 conversion. This member will take care of inter-federation calls that need that. That's why some emails/threads ago I said the sum of the capabilities of each member of the federation is important, besides having a common denominator. > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, July 28, 2006 7:30 AM > To: Reinaldo Penno; Klaus Darilion; Stastny Richard > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t > xt >=20 > I suspect a Federation of like-minded users will be used and setup/agree > to a media policy that specifies that set of codecs that they know and > love. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Monday, July 24, 2006 1:23 PM > > To: Klaus Darilion; Stastny Richard > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] I-D > > ACTION:draft-ietf-speermint-requirements-00.t xt > > > > I tend to agree. One thing is to specify a behavior over a > > peering interface that affects only the peering devices. > > Another is to specify a behavior that affects possibly > > millions of phones (or alternatively a requirement to install > > many of transcoders). > > > > I cannot imagine Sprint changing all its phones to support > > G.711 or Comcast changing all of its phones to support some > > wireless codec because Speermint mandates it. > > > > That leaves only three alternatives: > > > > 1) Do not specify anything in the RFCs and the peers work in > > out whether through some transcoding devices, or some common > > coder when possible. > > > > 2) Specify a minimum set (Can it be done and make everybody happy?) > > > > 3) Let offer/answer decide. I believe this might fall back > > into 1) since I do not believe carriers will just "wing it" > > when it comes to peering. > > > > Regards, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > > Sent: Monday, July 24, 2006 8:06 AM > > > To: Stastny Richard > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] I-D > > ACTION:draft-ietf-speermint-requirements-00.t > > > xt > > > > > > Stastny Richard wrote: > > > >> And finally they can't interconnect as A uses AMR and B > > uses G.711. > > > > > > > > They can, if one provides transcoding > > > > > > > > If we say G.711 is mandatory, it is provider A who has to provide > > the > > > transcoding > > > > > > > > > Thus, we have to mandate a minimum set of codecs. > > > > > > regards > > > klaus > > > > > > _______________________________________________ > > > 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 Fri Jul 28 12:51:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6VYj-00064A-0J; Fri, 28 Jul 2006 12:51:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6VYh-00062p-Ij for speermint@ietf.org; Fri, 28 Jul 2006 12:51:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6VYh-0003X0-Gt for speermint@ietf.org; Fri, 28 Jul 2006 12:51:31 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1G6VY4-0000WL-OW for speermint@ietf.org; Fri, 28 Jul 2006 12:50:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Voice codecs Date: Fri, 28 Jul 2006 18:47:39 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B41@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: AcayYuEdjn+q+8P6SFGfzL2uyZ5D3AAAqgsL References: <1A8DCAFC5DC73B4D94081BDCF028A2030605955A@PDAWB14C.ad.sprint.com> <44CA3B5A.6000904@cs.columbia.edu> From: "Stastny Richard" To: "Henning Schulzrinne" X-Spam-Score: -2.6 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 No, but as practice shows, 99% of customers on fixed networks have no = idea what a codec is and use the device they get from the provider. In the mobile world = currently you have no choice at all =20 Richard ________________________________ Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Gesendet: Fr 28.07.2006 18:29 An: Lipford, Mark A [CTO] Cc: Stastny Richard; speermint@ietf.org Betreff: Re: [Speermint] Voice codecs I'm confused by this whole discussion. Is the assumption that a carrier restricts what kind of devices, codecs and software any customer is allowed to use? Are we going back to the pre-Carterphone days? Lipford, Mark A [CTO] wrote: > Daryl, > > You mention using the OPTION message, I actually asked if this was a > possibility in my original message, with the recommendation of > defaulting to G.711 or some other codec. If I follow you line of > thinking that that of others then let's simply require either using = the > OPTION message, to determine the codec, or some other method agreeable > to the peering networks. > > My comment was based on the second bullet in 3.3 of the requirements > draft (version 00) > _______________________________________________ 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 Mon Jul 31 08:18:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Wik-0002Zl-GH; Mon, 31 Jul 2006 08:18:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Wii-0002YU-SH for speermint@ietf.org; Mon, 31 Jul 2006 08:18:04 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Wii-0008Ew-BS for speermint@ietf.org; Mon, 31 Jul 2006 08:18:04 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 0EE9C1A36C; Mon, 31 Jul 2006 14:18:01 +0200 (CEST) Date: Mon, 31 Jul 2006 14:18:01 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Comments on Requirements Draft Message-ID: <20060731121801.GH19113@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 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 Some additional comments from me. On 2006/07/14 22:07, "Uzelac, Adam" wrote: > > I will start with 'General Requirements' for now. > > ====================== > > 2.1. Unified solution for session peering policies - > > We might consider replacing the word "Unified" with "Flexible". The > text in this section points out that polices SHOULD be extensible and > flexible, but I am not sure that means Unified. Also, in the quick > references to the different models ("closed, open, etc) the context and > definition of policies changes wildly. Well, the actual policies might vary a lot, but the language in which these policies are expressed in needs to be the same. Thus we need a *one* policy language (I think that's how "uniform" entered this paragraph) which is flexible enough to such that all peering models can be expressed by it. So perhaps it should be 2.1. Unified session peering policies description language > > 2.2. Domain Based > > I think we should rename this section as well to Domain-based Context. > The point, as I read it, is that the domain is the first and most basic > construct in forming peering. Ultimately it's the interconnection of 2 > or more domains that defines peering. Call routing is to or from the > domain. The text states, "...call routing should rely on URIs." Beyond > this point though, there is some "squirreliness" when stating that "We > assume that all SIP URIs with the same domain-part share the same set of > peering polices". I think that's an assumption that we can not safely, > nor logically make. I suggest that we point out that a intra-domain is > out of scope, and inter-domain is what we are trying to define. There are two aspects to the Domain question: a) Domains as in "not numbers". While SIP URIs may have been derived from E.164 numbers, the peering/routing decisions must not be based on telephone numbers. The scheme has to work if the end-user dialed a SIP URI directly. b) Is there a need to treat sip:user-A@foreign.com in any form differently than sip:user-B@foreign.com? The SIP RFCs say "no". All routing decisions are keyed by the domain only. The user-part is only interpreted by SIP servers serving the domain. Thus anybody else uses just the domain to derive the next hop. I think that's a very safe assumption. The only thing which can mess with that assumption would be the SIP aequivalent to number portability. I really doubt we want to support that. > 2.3. No blocked calls > > As I understand the intention of this requirement, it's basically about > reachability - meaning - Do I know that something is out there willing > to peer with me before I attempt to connect? The text reads... > > An originating service provider must be able to determine whether a > SIP URI is open for direct interconnection without actually sending a > SIP INVITE. This is important as unsuccessful call attempts are > highly undesirable since they can introduce high delays due to > timeouts and can act as an unintended denial of service attack. > (e.g., by repeated TLS handshakes). > > I propose that change the section heading to "Universal Reachability". I don't think "Universal Reachability" fits. That would indicate that any SIP URI is reachable. This isn't what the original text says. This requirement just states that trial-and-error on the SIP layer is a bad idea. An originating network should find out if there is a peering possibility before sending any SIP requests to a -- potentially firewalled -- destination network. > 2.5. Independence of lower layers > > *NIT* - "...on what technologies are used route the call.." Need to add > a "to" in between "used" and "route". > A couple thoughts - I agree with the intent of the section but think > that it's mis-labeled. The section heading should be something like > "Access and Security Agnostic" or something like that. We shouldn't the > lower layer (Ethernet or POS), and there are references to upper layers > as well (TLS). "Access Agnostic" sounds fine. Security is part of the game here and I would not rule that out. But we shouldn't talk about how to connect MPLS networks to ensure QoS or other Layer2/3 issues. > 2.6. Administrative and technical policies > > This section I think it's going to be very difficult to build consensus > on within the WG. Mostly due to our having to find some common ground > on what should be WG mandate versus Local Policy. I believe that we > should have a requirement on core set of policies to consider > exchanging, but after the suggestion to exchange information, SPEERMINT > scope ends. I see Speermint as the framework under which federations can define their own rules. As such, the framework needs to support (= provide means of expressing them) all possible administrative and technical policies. Speermint will fail if it tries to force all federations to operate under the same rules. But Speermint should try to get all federations to use the same language to define their rules. > 2.7. Minimal additional cost on call initiation > > I think that this should be changed to "Minimal transaction cost". The > text pertains to discovery of peering next-hop, connection to next-hop > and potentially bearer (if determined within scope). Fine. > 2.8. Look beyond SIP > > I am struggling with this one a bit. I believe this should removed > altogether. If we should consider a requirement beyond SIP, then we > should re-charter as "PEERMINT" ;) This is optional. A lot of the problems we try to solve in Speermint are bound to pop up in other contexts as well. If it's easy to fomulate our solution in a way that make it adaptable for other uses as well, then why should try to do so. Maybe XMPP will need similar mechanisms. SMTP? Who knows. That's why I split up my drafts into the generic one and the SIP specific one. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 31 09:49:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Y9O-0001H6-86; Mon, 31 Jul 2006 09:49:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Y9O-0001H1-0B for speermint@ietf.org; Mon, 31 Jul 2006 09:49:42 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Y9M-0004MF-NR for speermint@ietf.org; Mon, 31 Jul 2006 09:49:41 -0400 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] Voice codecs Date: Mon, 31 Jul 2006 09:47:11 -0400 Message-ID: <8587F175CDB3D741B58C79F67E8E09AD1A6191@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmA= From: "Livingood, Jason" To: "Brian Rosen" , X-OriginalArrivalTime: 31 Jul 2006 13:47:12.0988 (UTC) FILETIME=[D3A371C0:01C6B4A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Ed Okerson , "Lipford, Mark A \[CTO\]" 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 wrote: > I did say something in my message which may have escaped some=20 > notice. I said "origination side". One of the things you=20 > have to get right on any kind of part like transcoding is=20 > what assumptions are made. You can assume the origination=20 > side does it, the destination side does it or the peering=20 > fabric itself does it. I think it's essential to choose one,=20 > or we won't have interoperability. More than one is always=20 > possible, but at least one is required. I think origination=20 > side is best: it means that across the peering fabric, there=20 > is at least one common codec. So, it is looking convincingly now that WG consensus is against a lowest common denominator codec. ;-)=20 But Brian raises an interesting question here. Somewhere in our drafts (several of them) we *may* need to consider optional inclusion of a transcoding function and describe how it might be implemented. When we take up that discussion, I think Brian poses an interesting question. =20 If I consider it from the perspective of some operator that is using all the major codecs in my endpoints, and someone connects with some obscure codec then I can see an arguement for having the originator perform any transcoding. (And if that is indeed the case, it may even be like lots of other stuff an originating network may or may not do that we don't care about and call out of scope.) Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 31 14:27:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7cUV-0005Tu-Jw; Mon, 31 Jul 2006 14:27:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7cUU-0005Tp-J0 for speermint@ietf.org; Mon, 31 Jul 2006 14:27:46 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7cUS-00047y-A9 for speermint@ietf.org; Mon, 31 Jul 2006 14:27:46 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 14:27:42 -0400 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] Voice codecs Date: Mon, 31 Jul 2006 14:27:41 -0400 Message-ID: <402F25FC1EB2BD44831F8A4A4F6DF9420548CA@MAIL02.cedarpointcom.com> In-Reply-To: <8587F175CDB3D741B58C79F67E8E09AD1A6191@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmAACa16AA== From: "Geoff Devine" To: "Livingood, Jason" , "Brian Rosen" , X-OriginalArrivalTime: 31 Jul 2006 18:27:42.0811 (UTC) FILETIME=[02FEA2B0:01C6B4CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Ed Okerson , "Lipford, Mark A \[CTO\]" 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 your codec architecture example, you say that the originator may have some strange and wonderful codec that is not supported by the peer network. I'd point out that the other 50% of the time, that endpoint is the terminator in the call, not the originator. I would think that transcoding would be something that is negotiated as part of the peering business arrangement. In terms of $ per port, transcoding is a relatively costly operation and somebody is going to have to purchase and operate the transcoding equipment. =20 Transcoding, like echo cancellation, is something you want to avoid doing extra times since it degrades voice quality. A path that goes, say, from AMR to G.711 to iLBC is going to have a lower MOS score than a path that goes AMR to iLBC. Ideally, you don't want to transcode at all since that gives you the least impairment and the least delay. Geoff -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Monday, July 31, 2006 9:47 AM To: Brian Rosen; speermint@ietf.org Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Geoff Devine; Klaus Darilion; Henry Sinnreich Subject: RE: [Speermint] Voice codecs Brian wrote: > I did say something in my message which may have escaped some=20 > notice. I said "origination side". One of the things you=20 > have to get right on any kind of part like transcoding is=20 > what assumptions are made. You can assume the origination=20 > side does it, the destination side does it or the peering=20 > fabric itself does it. I think it's essential to choose one,=20 > or we won't have interoperability. More than one is always=20 > possible, but at least one is required. I think origination=20 > side is best: it means that across the peering fabric, there=20 > is at least one common codec. So, it is looking convincingly now that WG consensus is against a lowest common denominator codec. ;-)=20 But Brian raises an interesting question here. Somewhere in our drafts (several of them) we *may* need to consider optional inclusion of a transcoding function and describe how it might be implemented. When we take up that discussion, I think Brian poses an interesting question. =20 If I consider it from the perspective of some operator that is using all the major codecs in my endpoints, and someone connects with some obscure codec then I can see an arguement for having the originator perform any transcoding. (And if that is indeed the case, it may even be like lots of other stuff an originating network may or may not do that we don't care about and call out of scope.) Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 31 14:39:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7cfq-0006b5-I0; Mon, 31 Jul 2006 14:39:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7cfo-0006Uf-Pt for speermint@ietf.org; Mon, 31 Jul 2006 14:39:28 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7cfn-00054L-FQ for speermint@ietf.org; Mon, 31 Jul 2006 14:39:28 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G7cfV-0003r4-0v; Mon, 31 Jul 2006 13:39:09 -0500 From: "Brian Rosen" To: "'Geoff Devine'" , "'Livingood, Jason'" , Subject: RE: [Speermint] Voice codecs Date: Mon, 31 Jul 2006 14:39:10 -0400 Message-ID: <044c01c6b4d0$9fd065f0$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 In-Reply-To: <402F25FC1EB2BD44831F8A4A4F6DF9420548CA@MAIL02.cedarpointcom.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmAACa16AAAAir3Q X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: 'Ed Okerson' , "'Lipford, Mark A \[CTO\]'" 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 Okay, makes sense. So, maybe it's more like, the federation agrees on minimal codec support, and participants must be prepared to transcode to that minimal set if their endpoints need it. I don't think you can mandate anything that guarantees only one transcode. However desirable it may be. Brian > -----Original Message----- > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > Sent: Monday, July 31, 2006 2:28 PM > To: Livingood, Jason; Brian Rosen; speermint@ietf.org > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Klaus Darilion; Henry > Sinnreich > Subject: RE: [Speermint] Voice codecs > > In your codec architecture example, you say that the originator may have > some strange and wonderful codec that is not supported by the peer > network. I'd point out that the other 50% of the time, that endpoint is > the terminator in the call, not the originator. I would think that > transcoding would be something that is negotiated as part of the peering > business arrangement. In terms of $ per port, transcoding is a > relatively costly operation and somebody is going to have to purchase > and operate the transcoding equipment. > > Transcoding, like echo cancellation, is something you want to avoid > doing extra times since it degrades voice quality. A path that goes, > say, from AMR to G.711 to iLBC is going to have a lower MOS score than a > path that goes AMR to iLBC. Ideally, you don't want to transcode at all > since that gives you the least impairment and the least delay. > > Geoff > > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, July 31, 2006 9:47 AM > To: Brian Rosen; speermint@ietf.org > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Geoff Devine; Klaus > Darilion; Henry Sinnreich > Subject: RE: [Speermint] Voice codecs > > Brian wrote: > > > I did say something in my message which may have escaped some > > notice. I said "origination side". One of the things you > > have to get right on any kind of part like transcoding is > > what assumptions are made. You can assume the origination > > side does it, the destination side does it or the peering > > fabric itself does it. I think it's essential to choose one, > > or we won't have interoperability. More than one is always > > possible, but at least one is required. I think origination > > side is best: it means that across the peering fabric, there > > is at least one common codec. > > So, it is looking convincingly now that WG consensus is against a lowest > common denominator codec. ;-) > > But Brian raises an interesting question here. Somewhere in our drafts > (several of them) we *may* need to consider optional inclusion of a > transcoding function and describe how it might be implemented. When we > take up that discussion, I think Brian poses an interesting question. > > If I consider it from the perspective of some operator that is using all > the major codecs in my endpoints, and someone connects with some obscure > codec then I can see an arguement for having the originator perform any > transcoding. (And if that is indeed the case, it may even be like lots > of other stuff an originating network may or may not do that we don't > care about and call out of scope.) > > Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 31 14:52:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7csJ-0000pA-3V; Mon, 31 Jul 2006 14:52:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7csH-0000p5-RA for speermint@ietf.org; Mon, 31 Jul 2006 14:52:21 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7csG-0007OE-HD for speermint@ietf.org; Mon, 31 Jul 2006 14:52:21 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 14:52:19 -0400 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] Voice codecs Date: Mon, 31 Jul 2006 14:52:18 -0400 Message-ID: <402F25FC1EB2BD44831F8A4A4F6DF9420548E4@MAIL02.cedarpointcom.com> In-Reply-To: <044c01c6b4d0$9fd065f0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Voice codecs Thread-Index: Acax0Dk1kQEj0bcCQYaGVby0idKMhwAck/VwAAG6x/AAAF3s4AABGMXgAJXsKmAACa16AAAAir3QAABaGpA= From: "Geoff Devine" To: "Brian Rosen" , "Livingood, Jason" , X-OriginalArrivalTime: 31 Jul 2006 18:52:19.0177 (UTC) FILETIME=[72FA3590:01C6B4D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: Ed Okerson , "Lipford, Mark A \[CTO\]" 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 That sounds good to me. =20 I'd point out that different federations are likely to have different ideas about what makes up the "minimal codec". In broadband-oriented federations, that would likely be G.711. In cellular-centric federations that are converging to IP transport, it's more likely to be their native client compression codec. If eBay created one based on Skype, it could very well be iLBC. I think we all agree that transcoding is something we want to avoid but we need to come up with an architecture that takes it into account.=20 Geoff -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Monday, July 31, 2006 2:39 PM To: Geoff Devine; 'Livingood, Jason'; speermint@ietf.org Cc: 'Greg Herlein'; 'Ed Okerson'; 'Lipford,Mark A [CTO]'; 'Klaus Darilion'; 'Henry Sinnreich' Subject: RE: [Speermint] Voice codecs Okay, makes sense. So, maybe it's more like, the federation agrees on minimal codec support, and participants must be prepared to transcode to that minimal set if their endpoints need it. I don't think you can mandate anything that guarantees only one transcode. However desirable it may be. Brian > -----Original Message----- > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > Sent: Monday, July 31, 2006 2:28 PM > To: Livingood, Jason; Brian Rosen; speermint@ietf.org > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Klaus Darilion; Henry > Sinnreich > Subject: RE: [Speermint] Voice codecs >=20 > In your codec architecture example, you say that the originator may have > some strange and wonderful codec that is not supported by the peer > network. I'd point out that the other 50% of the time, that endpoint is > the terminator in the call, not the originator. I would think that > transcoding would be something that is negotiated as part of the peering > business arrangement. In terms of $ per port, transcoding is a > relatively costly operation and somebody is going to have to purchase > and operate the transcoding equipment. >=20 > Transcoding, like echo cancellation, is something you want to avoid > doing extra times since it degrades voice quality. A path that goes, > say, from AMR to G.711 to iLBC is going to have a lower MOS score than a > path that goes AMR to iLBC. Ideally, you don't want to transcode at all > since that gives you the least impairment and the least delay. >=20 > Geoff >=20 > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, July 31, 2006 9:47 AM > To: Brian Rosen; speermint@ietf.org > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Geoff Devine; Klaus > Darilion; Henry Sinnreich > Subject: RE: [Speermint] Voice codecs >=20 > Brian wrote: >=20 > > I did say something in my message which may have escaped some > > notice. I said "origination side". One of the things you > > have to get right on any kind of part like transcoding is > > what assumptions are made. You can assume the origination > > side does it, the destination side does it or the peering > > fabric itself does it. I think it's essential to choose one, > > or we won't have interoperability. More than one is always > > possible, but at least one is required. I think origination > > side is best: it means that across the peering fabric, there > > is at least one common codec. >=20 > So, it is looking convincingly now that WG consensus is against a lowest > common denominator codec. ;-) >=20 > But Brian raises an interesting question here. Somewhere in our drafts > (several of them) we *may* need to consider optional inclusion of a > transcoding function and describe how it might be implemented. When we > take up that discussion, I think Brian poses an interesting question. >=20 > If I consider it from the perspective of some operator that is using all > the major codecs in my endpoints, and someone connects with some obscure > codec then I can see an arguement for having the originator perform any > transcoding. (And if that is indeed the case, it may even be like lots > of other stuff an originating network may or may not do that we don't > care about and call out of scope.) >=20 > Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 31 17:04:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7evr-0008I2-L2; Mon, 31 Jul 2006 17:04:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7evp-0008FD-QL for speermint@ietf.org; Mon, 31 Jul 2006 17:04:09 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7evn-0003OR-Bh for speermint@ietf.org; Mon, 31 Jul 2006 17:04:09 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k6VL41aK010373; Mon, 31 Jul 2006 21:04:01 GMT Subject: RE: [Speermint] Voice codecs From: Daryl Malas To: Geoff Devine In-Reply-To: <402F25FC1EB2BD44831F8A4A4F6DF9420548E4@MAIL02.cedarpointcom.com> References: <402F25FC1EB2BD44831F8A4A4F6DF9420548E4@MAIL02.cedarpointcom.com> Content-Type: text/plain Date: Mon, 31 Jul 2006 15:05:17 -0600 Message-Id: <1154379918.19821.153.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: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: speermint@ietf.org, "Livingood, Jason" , Ed Okerson , "Lipford, Mark A \[CTO\]" 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 agree with Geoff's statement below. On Mon, 2006-07-31 at 14:52 -0400, Geoff Devine wrote: > That sounds good to me. > > I'd point out that different federations are likely to have different > ideas about what makes up the "minimal codec". In broadband-oriented > federations, that would likely be G.711. In cellular-centric > federations that are converging to IP transport, it's more likely to be > their native client compression codec. If eBay created one based on > Skype, it could very well be iLBC. > > I think we all agree that transcoding is something we want to avoid but > we need to come up with an architecture that takes it into account. > > Geoff > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, July 31, 2006 2:39 PM > To: Geoff Devine; 'Livingood, Jason'; speermint@ietf.org > Cc: 'Greg Herlein'; 'Ed Okerson'; 'Lipford,Mark A [CTO]'; 'Klaus > Darilion'; 'Henry Sinnreich' > Subject: RE: [Speermint] Voice codecs > > Okay, makes sense. So, maybe it's more like, the federation agrees on > minimal codec support, and participants must be prepared to transcode to > that minimal set if their endpoints need it. > > I don't think you can mandate anything that guarantees only one > transcode. > However desirable it may be. > > Brian > > > -----Original Message----- > > From: Geoff Devine [mailto:gdevine@cedarpointcom.com] > > Sent: Monday, July 31, 2006 2:28 PM > > To: Livingood, Jason; Brian Rosen; speermint@ietf.org > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Klaus Darilion; > Henry > > Sinnreich > > Subject: RE: [Speermint] Voice codecs > > > > In your codec architecture example, you say that the originator may > have > > some strange and wonderful codec that is not supported by the peer > > network. I'd point out that the other 50% of the time, that endpoint > is > > the terminator in the call, not the originator. I would think that > > transcoding would be something that is negotiated as part of the > peering > > business arrangement. In terms of $ per port, transcoding is a > > relatively costly operation and somebody is going to have to purchase > > and operate the transcoding equipment. > > > > Transcoding, like echo cancellation, is something you want to avoid > > doing extra times since it degrades voice quality. A path that goes, > > say, from AMR to G.711 to iLBC is going to have a lower MOS score than > a > > path that goes AMR to iLBC. Ideally, you don't want to transcode at > all > > since that gives you the least impairment and the least delay. > > > > Geoff > > > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Monday, July 31, 2006 9:47 AM > > To: Brian Rosen; speermint@ietf.org > > Cc: Greg Herlein; Ed Okerson; Lipford,Mark A [CTO]; Geoff Devine; > Klaus > > Darilion; Henry Sinnreich > > Subject: RE: [Speermint] Voice codecs > > > > Brian wrote: > > > > > I did say something in my message which may have escaped some > > > notice. I said "origination side". One of the things you > > > have to get right on any kind of part like transcoding is > > > what assumptions are made. You can assume the origination > > > side does it, the destination side does it or the peering > > > fabric itself does it. I think it's essential to choose one, > > > or we won't have interoperability. More than one is always > > > possible, but at least one is required. I think origination > > > side is best: it means that across the peering fabric, there > > > is at least one common codec. > > > > So, it is looking convincingly now that WG consensus is against a > lowest > > common denominator codec. ;-) > > > > But Brian raises an interesting question here. Somewhere in our > drafts > > (several of them) we *may* need to consider optional inclusion of a > > transcoding function and describe how it might be implemented. When > we > > take up that discussion, I think Brian poses an interesting question. > > > > If I consider it from the perspective of some operator that is using > all > > the major codecs in my endpoints, and someone connects with some > obscure > > codec then I can see an arguement for having the originator perform > any > > transcoding. (And if that is indeed the case, it may even be like > lots > > of other stuff an originating network may or may not do that we don't > > care about and call out of scope.) > > > > Jason > > > _______________________________________________ > 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