From speermint-bounces@ietf.org Thu Jun 01 09:04:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flmr3-0001Rx-KE; Thu, 01 Jun 2006 09:04:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flmqe-0000pX-RX; Thu, 01 Jun 2006 09:04:24 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlmoQ-0007XG-QH; Thu, 01 Jun 2006 09:02:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jun 2006 15:06:07 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4FF8@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDA== From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: enum@ietf.org Subject: [Speermint] How to correctly set up the request URI? 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 Folks, Question for clarification: In the discussions here on how to populate sip URI in Infrastructure=20 ENUM to derive the Call Routing data for SPEERMINT two lines of thought exist: The Enumservice SIP in Infrastructure ENUM should contain=20 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net 2. the ingress point into the provider network: e.g. sip:+4319793321@sbc4711.provB.net The originating UAC has in this case set the To: field to=20 tel:+4319793321 and the Request-URI to e.g.=20 sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query at the proxy of provider A The question is how the proxy of provider A is now setting up the request URI in cases mentioned above? Does the UAS from provider B accept calls to sbc7411.provB.net, or must the request URI set to the proper AoR as described in 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. I would also like to draw the attention to section 3 of RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. Regards -sta _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 01 10:36:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FloI1-00009y-NY; Thu, 01 Jun 2006 10:36:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FloI0-00009q-N1; Thu, 01 Jun 2006 10:36:44 -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 1FloHz-00013C-F5; Thu, 01 Jun 2006 10:36:44 -0400 Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.20722102; Thu, 01 Jun 2006 10:36:21 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 10:36:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jun 2006 10:36:19 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96624E68@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OA From: "Creighton, Tom" To: "Stastny Richard" , X-OriginalArrivalTime: 01 Jun 2006 14:36:20.0474 (UTC) FILETIME=[BFB11DA0:01C68588] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: enum@ietf.org Subject: [Speermint] RE: [Enum] How to correctly set up the request URI? 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: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 09:06 > To: speermint@ietf.org > Cc: enum@ietf.org > Subject: [Enum] How to correctly set up the request URI? >=20 > Folks, >=20 > Question for clarification: >=20 > In the discussions here on how to populate sip URI in Infrastructure > ENUM to derive the Call Routing data for SPEERMINT two > lines of thought exist: >=20 > The Enumservice SIP in Infrastructure ENUM should contain > 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net > 2. the ingress point into the provider network: > e.g. sip:+4319793321@sbc4711.provB.net >=20 > The originating UAC has in this case set the To: field to > tel:+4319793321 and the Request-URI to e.g. > sip:+4319793321provA.net;user=3Dphone. This caused the > ENUM query at the proxy of provider A >=20 > The question is how the proxy of provider A is now > setting up the request URI in cases mentioned above? >=20 > Does the UAS from provider B accept calls to sbc7411.provB.net, > or must the request URI set to the proper AoR as described in > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. [Tom Creighton wrote:]=20 >From section 8.2.2.1 of RFC3261: "If the Request-URI does not identify an address that the UAS is willing to accept requests for, it SHOULD reject the request with a 404 (Not Found) response." As long as the UAS from provider B is "willing" to accept the request, either should work. Since provider B is populating Infrastructure ENUM, one would hope that they would coordinate this data with the configuration of their proxies. Besides, how do you actually know that sbc4441.provB.net is actually a hostname and isn't a subdomain? In either case, after the provider A proxy performs an ENUM query and rewrites the request URI, it should behave as a UAC and follow the procedures outlined in Section 4 of RFC3263 to determine the IP address, port, and transport protocol for the provider B UAS. >=20 > I would also like to draw the attention to section 3 of > RFC3761 (SIP Enumservice) explaining the usage of AoR in > ENUM. >=20 > Regards >=20 > -sta >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 01 11:07:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flom3-0003k5-4G; Thu, 01 Jun 2006 11:07:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flom1-0003he-LU for speermint@ietf.org; Thu, 01 Jun 2006 11:07:45 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flom0-0004pR-8T for speermint@ietf.org; Thu, 01 Jun 2006 11:07:45 -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 k51F84cA023225; Thu, 1 Jun 2006 08:08:04 -0700 From: "Richard Shockey" To: "'Stastny Richard'" , "'Andrew Newton'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Thu, 1 Jun 2006 11:07:32 -0400 Message-ID: <002c01c6858d$1c4bf220$40211f0a@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: AcaD/W9wzhdOOV+xRZWp3yzFsp5u8wAALw+xAGOuKiA= In-reply-to: <32755D354E6B65498C3BD9FD496C7D462C4A92@oefeg-s04.oefeg.loc> 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: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Yes .. private ENUM would be in scope for the ENUM WG and in fact it already is since the PSTN data draft that has now finished IETF last call specifically deals with domains outside the scope of e164.apra visible on invisible to the DNS > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, May 30, 2006 11:32 AM > To: Andrew Newton > Cc: speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > Andy wrote > > >Stastny Richard wrote: > >> > >> IMHO SPEERMINT does not deal with E.164 numbers at all in routing, it > is out of scope > > >Would the "private" ENUM tree run by a peering point and specifying its > >location (i.e. DNS suffix) be in scope? > > IMHO yes, because any ENUM is dealing with E.164 numbers > > -sta > > > > > > > _______________________________________________ > 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 Jun 01 11:25:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flp33-0000QK-Tw; Thu, 01 Jun 2006 11:25:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flp31-0000Os-9c for speermint@ietf.org; Thu, 01 Jun 2006 11:25:19 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flp30-0006dy-16 for speermint@ietf.org; Thu, 01 Jun 2006 11:25:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jun 2006 11:25:04 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96581DE9@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [wg-business] Montreal Meeting & Other Next Steps, Incl. Agenda for IETF 66 Thread-Index: AcaFj47qs7ihVGRfTiGTzF5jJBTcMg== From: "Livingood, Jason" To: X-OriginalArrivalTime: 01 Jun 2006 15:25:05.0613 (UTC) FILETIME=[8F35E7D0:01C6858F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Alexander Mayrhofer Subject: [Speermint] [wg-business] Montreal Meeting & Other Next Steps, Incl. Agenda for IETF 66 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 WG Update As we look ahead to Montreal, Dave and I wanted to share with the WG what our current objectives look like and what the draft agenda for Montreal is. *Please send us your feedback and suggest additional agenda items as appropriate.* For reference, see the WG charter at http://www.ietf.org/html.charters/speermint-charter.html Proposed WG agenda for Montreal: 0 - Agenda Bashing 1 - Terminology I-D review. 2 - Requirements I-D review. (+ Possible selected Use Case I-D reviews.) 3 - Architecture I-D review. 4 - Review Next Steps >From Goals & Milestones: (My additional comments preceded by "JL-->".) ------------------------ 1 - Jul 2006 Submit SPEERMINT terminology I-D JL --> This draft is still in-process. We expect to present a reasonably stable draft in Montreal and move to WGLC shortly afterwards. *Please review this document again and submit your comments.* =20 http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-00. txt 2 - Sep 2006 Submit I-D defining the SPEERMINT routing architecture JL --> Plan TBD. (We expect to discuss our approach with key contributors in Montreal.) 3 - Dec 2006 Submit I-D defining the message flows associated with the SPEERMINT routing architecture JL --> Plan TBD. It is likely that this document will mature out of one or more of the use case I-Ds we hope to solicit (*see 2nd comment in #5 below*). 4 - Jan 2007 Submit I-D on the use of DNS SRV and NAPTR records as specified by RFC 3263 JL --> Plan TBD. Same parenthetical note as in #3 above. 5 - Mar 2007 Submit I-D on the minimum set of requirements for SIP-based VoIP interconnection JL --> This document will be of major importance to the WG. Jean-Francois Mule will be editing this WG document for us and leading the effort. We hope to see a basic -00 draft for Montreal, perhaps at least carrying over the requirements that were split out of Dave's earlier Requirements & Terminology draft. JL --> Also *VERY* important to filling out the requirements draft (and the architecture draft for that matter) are use cases. The goal is to solicit use case I-Ds. These should be informational, as personal I-Ds for the WG from people from different geographies, and with different technologies. Those use cases will need to comply with the high-level requirements of course. However, in order to fully document all requirements, these application-specific or industry-specific use cases will be needed. We expect these will necessarily be concerned with and constrained to a specific industry, market geography, or deployment technology, so that they need not be all-encompassing or overly complex. We would expect some of these uses cases to indicate a need for additions to the requirements draft (based on WG consensus). And these use cases will also share a large set of common requirements which we can confirm as especially high priority, for example.=20 *Please email Dave and I if you may be interested in submitting use cases.* Thanks!! Dave & Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 01 11:26:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flp3y-0000gY-Sp; Thu, 01 Jun 2006 11:26:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flp3x-0000gF-Mp; Thu, 01 Jun 2006 11:26:17 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Flp3w-0006i2-6L; Thu, 01 Jun 2006 11:26: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: Thu, 1 Jun 2006 17:30:19 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4FF9@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARA= From: "Stastny Richard" To: "Creighton, Tom" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: enum@ietf.org Subject: [Speermint] RE: [Enum] How to correctly set up the request URI? 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 Thank you, Tom just a minor additional question: > In either case, after the provider A proxy performs an ENUM query and > rewrites the request URI, it should behave as a UAC and follow the > procedures outlined in Section 4 of RFC3263 to determine the IP address, > port, and transport protocol for the provider B UAS. If I have to do this according to RFC3263 anyway, why put the sbc4711.provB.net into ENUM in the first place? -sta > -----Original Message----- > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Sent: Thursday, June 01, 2006 4:36 PM > To: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Enum] How to correctly set up the request URI? >=20 >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 09:06 > > To: speermint@ietf.org > > Cc: enum@ietf.org > > Subject: [Enum] How to correctly set up the request URI? > > > > Folks, > > > > Question for clarification: > > > > In the discussions here on how to populate sip URI in Infrastructure > > ENUM to derive the Call Routing data for SPEERMINT two > > lines of thought exist: > > > > The Enumservice SIP in Infrastructure ENUM should contain > > 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net > > 2. the ingress point into the provider network: > > e.g. sip:+4319793321@sbc4711.provB.net > > > > The originating UAC has in this case set the To: field to > > tel:+4319793321 and the Request-URI to e.g. > > sip:+4319793321provA.net;user=3Dphone. This caused the > > ENUM query at the proxy of provider A > > > > The question is how the proxy of provider A is now > > setting up the request URI in cases mentioned above? > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > > or must the request URI set to the proper AoR as described in > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. >=20 > [Tom Creighton wrote:] > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > identify an address that the UAS is willing to accept requests for, it > SHOULD reject the request with a 404 (Not Found) response." >=20 > As long as the UAS from provider B is "willing" to accept the request, > either should work. Since provider B is populating Infrastructure ENUM, > one would hope that they would coordinate this data with the > configuration of their proxies. >=20 > Besides, how do you actually know that sbc4441.provB.net is actually a > hostname and isn't a subdomain? >=20 > In either case, after the provider A proxy performs an ENUM query and > rewrites the request URI, it should behave as a UAC and follow the > procedures outlined in Section 4 of RFC3263 to determine the IP address, > port, and transport protocol for the provider B UAS. >=20 > > > > I would also like to draw the attention to section 3 of > > RFC3761 (SIP Enumservice) explaining the usage of AoR in > > ENUM. > > > > Regards > > > > -sta > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 01 11:58:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpYg-0001na-9A; Thu, 01 Jun 2006 11:58:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpYf-0001mR-2g; Thu, 01 Jun 2006 11:58:01 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpYe-00013z-OR; Thu, 01 Jun 2006 11:58:01 -0400 Received: from ([10.20.9.172]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.20617794; Thu, 01 Jun 2006 11:57:35 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 11:57:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jun 2006 11:57:34 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96624F21@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4A== From: "Creighton, Tom" To: "Stastny Richard" , X-OriginalArrivalTime: 01 Jun 2006 15:57:35.0373 (UTC) FILETIME=[195BABD0:01C68594] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: enum@ietf.org Subject: [Speermint] RE: [Enum] How to correctly set up the request URI? 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 Maybe the service provider has some sort of segregated network (physically or logically) and wants/needs to associate each its subscribers with a particular network segment. If the provider went with the flat model of provB.net, each of its proxies would have to accept requests destined to all of its customers and would then have to route the request to the appropriate region or division of its network. If the provider went with the hierarchical approach of sbc4711.provB.net, all of the requests would already be routed to the appropriate ingress point. This could very well save a service provider a lot of money in route proxy equipment although might cost more on the provisioning side. That is my guess. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 11:30 > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Enum] How to correctly set up the request URI? >=20 > Thank you, Tom >=20 > just a minor additional question: >=20 > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. >=20 > If I have to do this according to RFC3263 anyway, why put > the sbc4711.provB.net into ENUM in the first place? >=20 > -sta >=20 >=20 > > -----Original Message----- > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Sent: Thursday, June 01, 2006 4:36 PM > > To: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 09:06 > > > To: speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > Folks, > > > > > > Question for clarification: > > > > > > In the discussions here on how to populate sip URI in Infrastructure > > > ENUM to derive the Call Routing data for SPEERMINT two > > > lines of thought exist: > > > > > > The Enumservice SIP in Infrastructure ENUM should contain > > > 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net > > > 2. the ingress point into the provider network: > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > The originating UAC has in this case set the To: field to > > > tel:+4319793321 and the Request-URI to e.g. > > > sip:+4319793321provA.net;user=3Dphone. This caused the > > > ENUM query at the proxy of provider A > > > > > > The question is how the proxy of provider A is now > > > setting up the request URI in cases mentioned above? > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > > > or must the request URI set to the proper AoR as described in > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > [Tom Creighton wrote:] > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > identify an address that the UAS is willing to accept requests for, it > > SHOULD reject the request with a 404 (Not Found) response." > > > > As long as the UAS from provider B is "willing" to accept the request, > > either should work. Since provider B is populating Infrastructure > ENUM, > > one would hope that they would coordinate this data with the > > configuration of their proxies. > > > > Besides, how do you actually know that sbc4441.provB.net is actually a > > hostname and isn't a subdomain? > > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > > > > > > > I would also like to draw the attention to section 3 of > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in > > > ENUM. > > > > > > Regards > > > > > > -sta > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 01 12:01:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flpbr-0005D6-0W; Thu, 01 Jun 2006 12:01:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flpbq-0005Cz-6V for speermint@ietf.org; Thu, 01 Jun 2006 12:01:18 -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 1Flpbo-0001Hd-WC for speermint@ietf.org; Thu, 01 Jun 2006 12:01:18 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 01 Jun 2006 12:01:46 -0400 id 01588016.447F0F6A.00000831 Message-ID: <447F0F41.2060209@hxr.us> Date: Thu, 01 Jun 2006 12:01:05 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: richard@shockey.us Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture References: <002c01c6858d$1c4bf220$40211f0a@cis.neustar.com> In-Reply-To: <002c01c6858d$1c4bf220$40211f0a@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: 8abaac9e10c826e8252866cbe6766464 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 So, the discovery of an ENUM service for an opportunistic peering exchange would be worked out in the ENUM working group, but all other aspects of an opportunistic peering exchange are to be worked out here. Seems kinda weird. -andy Richard Shockey wrote: > Yes .. private ENUM would be in scope for the ENUM WG and in fact it already > is since the PSTN data draft that has now finished IETF last call > specifically deals with domains outside the scope of e164.apra visible on > invisible to the DNS > > >> -----Original Message----- >> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >> Sent: Tuesday, May 30, 2006 11:32 AM >> To: Andrew Newton >> Cc: speermint@ietf.org >> Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >> >> Andy wrote >> >>> Stastny Richard wrote: >>>> IMHO SPEERMINT does not deal with E.164 numbers at all in routing, it >> is out of scope >> >>> Would the "private" ENUM tree run by a peering point and specifying its >>> location (i.e. DNS suffix) be in scope? >> IMHO yes, because any ENUM is dealing with E.164 numbers _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 01 13:11:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flqhm-0007aI-PN; Thu, 01 Jun 2006 13:11:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flqhm-0007aA-5n; Thu, 01 Jun 2006 13:11:30 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Flqhl-0002Ma-GQ; Thu, 01 Jun 2006 13:11:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jun 2006 19:12:44 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A9D@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVby From: "Stastny Richard" To: "Creighton, Tom" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: enum@ietf.org Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? 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 see, =20 but how do you solve this problem if the users can also be reached by = AoRs direct? =20 -sta ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 17:57 An: Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Enum] How to correctly set up the request URI? Maybe the service provider has some sort of segregated network (physically or logically) and wants/needs to associate each its subscribers with a particular network segment. If the provider went with the flat model of provB.net, each of its proxies would have to accept requests destined to all of its customers and would then have to route the request to the appropriate region or division of its network. If the provider went with the hierarchical approach of sbc4711.provB.net, all of the requests would already be routed to the appropriate ingress point. This could very well save a service provider a lot of money in route proxy equipment although might cost more on the provisioning side. That is my guess. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 11:30 > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Enum] How to correctly set up the request URI? > > Thank you, Tom > > just a minor additional question: > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > If I have to do this according to RFC3263 anyway, why put > the sbc4711.provB.net into ENUM in the first place? > > -sta > > > > -----Original Message----- > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Sent: Thursday, June 01, 2006 4:36 PM > > To: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 09:06 > > > To: speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > Folks, > > > > > > Question for clarification: > > > > > > In the discussions here on how to populate sip URI in Infrastructure > > > ENUM to derive the Call Routing data for SPEERMINT two > > > lines of thought exist: > > > > > > The Enumservice SIP in Infrastructure ENUM should contain > > > 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net > > > 2. the ingress point into the provider network: > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > The originating UAC has in this case set the To: field to > > > tel:+4319793321 and the Request-URI to e.g. > > > sip:+4319793321provA.net;user=3Dphone. This caused the > > > ENUM query at the proxy of provider A > > > > > > The question is how the proxy of provider A is now > > > setting up the request URI in cases mentioned above? > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > > > or must the request URI set to the proper AoR as described in > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > [Tom Creighton wrote:] > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > identify an address that the UAS is willing to accept requests for, it > > SHOULD reject the request with a 404 (Not Found) response." > > > > As long as the UAS from provider B is "willing" to accept the request, > > either should work. Since provider B is populating Infrastructure > ENUM, > > one would hope that they would coordinate this data with the > > configuration of their proxies. > > > > Besides, how do you actually know that sbc4441.provB.net is actually a > > hostname and isn't a subdomain? > > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > > > > > > > I would also like to draw the attention to section 3 of > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in > > > ENUM. > > > > > > Regards > > > > > > -sta > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 01 13:32:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flr1d-0005yI-3g; Thu, 01 Jun 2006 13:32:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flr1b-0005yC-VG for speermint@ietf.org; Thu, 01 Jun 2006 13:31:59 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flr1a-0003az-Js for speermint@ietf.org; Thu, 01 Jun 2006 13:31:59 -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 k51HWJeA012954; Thu, 1 Jun 2006 10:32:19 -0700 From: "Richard Shockey" To: "'Andrew Newton'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Thu, 1 Jun 2006 13:31:47 -0400 Message-ID: <005c01c685a1$42dbd590$40211f0a@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: AcaFlLCI1XromQMSRkuTFWDtFpn5PAADFILA In-reply-to: <447F0F41.2060209@hxr.us> 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: 4adaf050708fb13be3316a9eee889caa Cc: 'Stastny Richard' , 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 No .. its not weird .. all you have to do is define the enumservice registration E2U+"foo" with "foo" defined in Speermint > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, June 01, 2006 12:01 PM > To: richard@shockey.us > Cc: 'Stastny Richard'; speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > So, the discovery of an ENUM service for an opportunistic peering > exchange would be worked out in the ENUM working group, but all other > aspects of an opportunistic peering exchange are to be worked out here. > Seems kinda weird. > > -andy > > Richard Shockey wrote: > > Yes .. private ENUM would be in scope for the ENUM WG and in fact it > already > > is since the PSTN data draft that has now finished IETF last call > > specifically deals with domains outside the scope of e164.apra visible > on > > invisible to the DNS > > > > > >> -----Original Message----- > >> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > >> Sent: Tuesday, May 30, 2006 11:32 AM > >> To: Andrew Newton > >> Cc: speermint@ietf.org > >> Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > >> > >> Andy wrote > >> > >>> Stastny Richard wrote: > >>>> IMHO SPEERMINT does not deal with E.164 numbers at all in routing, it > >> is out of scope > >> > >>> Would the "private" ENUM tree run by a peering point and specifying > its > >>> location (i.e. DNS suffix) be in scope? > >> IMHO yes, because any ENUM is dealing with E.164 numbers _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 01 13:34:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flr4Q-0001NA-GD; Thu, 01 Jun 2006 13:34:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flr4O-0001Io-Tm; Thu, 01 Jun 2006 13:34:52 -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 1Flr4M-0003md-H2; Thu, 01 Jun 2006 13:34:52 -0400 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.20731536; Thu, 01 Jun 2006 13:34:29 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 13:34:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 13:34:24 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96624FDD@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobA= From: "Lee, Yiu" To: "Stastny Richard" , "Creighton, Tom" , X-OriginalArrivalTime: 01 Jun 2006 17:34:29.0430 (UTC) FILETIME=[A2CE5D60:01C685A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: enum@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 this case, I guess when the originating proxy resolves the domain part of the AOR (sip:+4319793321@provB.net), it will return the IP address of the root domain "provB.net" which may be a redirect proxy. So "provB.net" has two choices: (1) It accesses its local routing table and sends a 305 to the originating proxy with "sbc4711.provB.net" in the contact header. (2) It replaces the domain part in the r-uri to more specific like "proxy.austria.provB.net" and forward the message to the next-hop. Either case, the assumption is provB.net will have a way to find out where the home proxy of user +4319793321. This is only my guess. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, June 01, 2006 1:13 PM To: Creighton, Tom; speermint@ietf.org Cc: enum@ietf.org Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? I see, =20 but how do you solve this problem if the users can also be reached by AoRs direct? =20 -sta ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 17:57 An: Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Enum] How to correctly set up the request URI? Maybe the service provider has some sort of segregated network (physically or logically) and wants/needs to associate each its subscribers with a particular network segment. If the provider went with the flat model of provB.net, each of its proxies would have to accept requests destined to all of its customers and would then have to route the request to the appropriate region or division of its network. If the provider went with the hierarchical approach of sbc4711.provB.net, all of the requests would already be routed to the appropriate ingress point. This could very well save a service provider a lot of money in route proxy equipment although might cost more on the provisioning side. That is my guess. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 11:30 > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Enum] How to correctly set up the request URI? > > Thank you, Tom > > just a minor additional question: > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the=20 > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > If I have to do this according to RFC3263 anyway, why put the=20 > sbc4711.provB.net into ENUM in the first place? > > -sta > > > > -----Original Message----- > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Sent: Thursday, June 01, 2006 4:36 PM > > To: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 09:06 > > > To: speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > Folks, > > > > > > Question for clarification: > > > > > > In the discussions here on how to populate sip URI in Infrastructure > > > ENUM to derive the Call Routing data for SPEERMINT two lines of=20 > > > thought exist: > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the=20 > > > address-of-record of the user: e.g. sip:+4319793321@provB.net > > > 2. the ingress point into the provider network: > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > The originating UAC has in this case set the To: field to > > > tel:+4319793321 and the Request-URI to e.g. > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query = at > > > the proxy of provider A > > > > > > The question is how the proxy of provider A is now setting up the=20 > > > request URI in cases mentioned above? > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > must the request URI set to the proper AoR as described in > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > [Tom Creighton wrote:] > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > identify an address that the UAS is willing to accept requests for, it > > SHOULD reject the request with a 404 (Not Found) response." > > > > As long as the UAS from provider B is "willing" to accept the request, > > either should work. Since provider B is populating Infrastructure > ENUM, > > one would hope that they would coordinate this data with the=20 > > configuration of their proxies. > > > > Besides, how do you actually know that sbc4441.provB.net is actually a > > hostname and isn't a subdomain? > > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the=20 > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > > > > > > > I would also like to draw the attention to section 3 of > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > Regards > > > > > > -sta > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ 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 Jun 01 13:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlrFB-0007dN-Ro; Thu, 01 Jun 2006 13:46:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlrFA-0007dA-Of; Thu, 01 Jun 2006 13:46:00 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlrFA-0004lF-Cx; Thu, 01 Jun 2006 13:46:00 -0400 Received: from ([10.20.62.13]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.20623581; Thu, 01 Jun 2006 13:45:42 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 13:45: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] Re: [Enum] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 13:45:40 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96624FF0@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMA== From: "Creighton, Tom" To: "Lee, Yiu" , "Stastny Richard" , X-OriginalArrivalTime: 01 Jun 2006 17:45:42.0210 (UTC) FILETIME=[33D07220:01C685A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: enum@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 Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop.=20 > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: >=20 > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. >=20 > (2) It replaces the domain part in the r-uri to more specific like > "proxy.austria.provB.net" and forward the message to the next-hop. >=20 > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. >=20 > This is only my guess. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? >=20 > I see, >=20 > but how do you solve this problem if the users can also be reached by AoRs > direct? >=20 > -sta >=20 > ________________________________ >=20 > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? >=20 >=20 >=20 > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. >=20 > That is my guess. >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum >=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 Jun 01 14:04:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlrWW-0000IC-2U; Thu, 01 Jun 2006 14:03:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlrWV-0000I4-2W; Thu, 01 Jun 2006 14:03:55 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlrWU-0006Dt-9F; Thu, 01 Jun 2006 14:03: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] Re: [Enum] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 20:06:48 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AA1@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTD From: "Stastny Richard" To: "Creighton, Tom" , "Lee, Yiu" , X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: enum@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 the IMS I-CSCF - HSS - S-CSCF way? =20 Richard ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 19:45 An: Lee, Yiu; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop. > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: > > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. > > (2) It replaces the domain part in the r-uri to more specific like > "proxy.austria.provB.net" and forward the message to the next-hop. > > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. > > This is only my guess. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? > > I see, > > but how do you solve this problem if the users can also be reached by AoRs > direct? > > -sta > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. > > That is my guess. > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > 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 Jun 01 14:07:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flra4-0001aH-Jj; Thu, 01 Jun 2006 14:07:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flra3-0001aC-P6 for speermint@ietf.org; Thu, 01 Jun 2006 14:07:35 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Flra2-0006R9-AF for speermint@ietf.org; Thu, 01 Jun 2006 14:07:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Thu, 1 Jun 2006 20:08:42 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AA2@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaFlLCI1XromQMSRkuTFWDtFpn5PAADFILAAAFaD2U= From: "Stastny Richard" To: , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Maybe it is me, but I am not quite able to follow this discussion: I am a bit confused Question for clarification =20 What is discovered in which ENUM? the E.164 to URI mapping club or the SIP peering club? =20 -sta ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Do 01.06.2006 19:31 An: 'Andrew Newton' Cc: Stastny Richard; speermint@ietf.org Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture No .. its not weird .. all you have to do is define the enumservice registration E2U+"foo" with "foo" defined in Speermint > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, June 01, 2006 12:01 PM > To: richard@shockey.us > Cc: 'Stastny Richard'; speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > So, the discovery of an ENUM service for an opportunistic peering > exchange would be worked out in the ENUM working group, but all other > aspects of an opportunistic peering exchange are to be worked out = here. > Seems kinda weird. > > -andy > > Richard Shockey wrote: > > Yes .. private ENUM would be in scope for the ENUM WG and in fact it > already > > is since the PSTN data draft that has now finished IETF last call > > specifically deals with domains outside the scope of e164.apra = visible > on > > invisible to the DNS > > > > > >> -----Original Message----- > >> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > >> Sent: Tuesday, May 30, 2006 11:32 AM > >> To: Andrew Newton > >> Cc: speermint@ietf.org > >> Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering = Architecture > >> > >> Andy wrote > >> > >>> Stastny Richard wrote: > >>>> IMHO SPEERMINT does not deal with E.164 numbers at all in = routing, it > >> is out of scope > >> > >>> Would the "private" ENUM tree run by a peering point and = specifying > its > >>> location (i.e. DNS suffix) be in scope? > >> IMHO yes, because any ENUM is dealing with E.164 numbers _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 01 14:10:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flrcm-0002lT-NI; Thu, 01 Jun 2006 14:10:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flrcm-0002iY-3b for speermint@ietf.org; Thu, 01 Jun 2006 14:10:24 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flrcl-0006ej-Mn for speermint@ietf.org; Thu, 01 Jun 2006 14:10:24 -0400 Received: from ([10.52.116.10]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.20625403; Thu, 01 Jun 2006 14:10:08 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 14:10:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 14:10:06 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96625033@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDA= From: "Lee, Yiu" To: "Stastny Richard" , "Creighton, Tom" , X-OriginalArrivalTime: 01 Jun 2006 18:10:08.0300 (UTC) FILETIME=[9DAC06C0:01C685A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 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 Yes. IMS is using Option 2. Option 1 is also possible if the operator decides to use just a redirect proxy.=20 -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, June 01, 2006 2:07 PM To: Creighton, Tom; Lee, Yiu; speermint@ietf.org Cc: enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? so basically the IMS I-CSCF - HSS - S-CSCF way? =20 Richard ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 19:45 An: Lee, Yiu; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop. > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: > > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. > > (2) It replaces the domain part in the r-uri to more specific like=20 > "proxy.austria.provB.net" and forward the message to the next-hop. > > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. > > This is only my guess. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? > > I see, > > but how do you solve this problem if the users can also be reached by AoRs > direct? > > -sta > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the=20 > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. > > That is my guess. > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the=20 > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the=20 > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > 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 Jun 01 14:17:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlrjU-0002wl-6H; Thu, 01 Jun 2006 14:17:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlrjT-0002wg-J3 for speermint@ietf.org; Thu, 01 Jun 2006 14:17:19 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlrjS-0007EE-Ps for speermint@ietf.org; Thu, 01 Jun 2006 14:17:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 20:17:50 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AA3@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItg== From: "Stastny Richard" To: "Lee, Yiu" , "Creighton, Tom" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd 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 Ok, so I am back to my original question: =20 if I implement both types of public user identities: E.164 numbers and SIP AoRs, why doing the mapping to different hosting proxies in two places (in this case ENUM and the HSS), if I can do it only in one place? -sta ________________________________ Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Gesendet: Do 01.06.2006 20:10 An: Stastny Richard; Creighton, Tom; speermint@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? Yes. IMS is using Option 2. Option 1 is also possible if the operator decides to use just a redirect proxy. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 2:07 PM To: Creighton, Tom; Lee, Yiu; speermint@ietf.org Cc: enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? so basically the IMS I-CSCF - HSS - S-CSCF way? Richard ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 19:45 An: Lee, Yiu; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop. > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: > > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. > > (2) It replaces the domain part in the r-uri to more specific like > "proxy.austria.provB.net" and forward the message to the next-hop. > > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. > > This is only my guess. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? > > I see, > > but how do you solve this problem if the users can also be reached by AoRs > direct? > > -sta > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. > > That is my guess. > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > 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 Jun 01 14:18:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flrkj-0003Rz-Eh; Thu, 01 Jun 2006 14:18:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flrkh-0003Rj-NW; Thu, 01 Jun 2006 14:18:35 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flrkf-0007GH-9p; Thu, 01 Jun 2006 14:18:35 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FlrkW-0006av-Mn; Thu, 01 Jun 2006 13:18:24 -0500 From: "Brian Rosen" To: "'Creighton, Tom'" , "'Stastny Richard'" , Date: Thu, 1 Jun 2006 14:18:27 -0400 Message-ID: <08be01c685a7$c990f1f0$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: <4884CD6C1DF0A8429DD8DAD942BF9D96624F21@PACDCEXCMB03.cable.comcast.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AAFSVvw 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: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: enum@ietf.org Subject: [Speermint] RE: [Enum] How to correctly set up the request URI? 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 this is not correct. If the AoR is provB.net, then Provider B has technology to route incoming calls addressed to provB.net to the sbc4711.provB.net, and it will use its existing mechanism to do so. The same AoR would be used for on-net as well as off-net routing and the same routing path would be used. The same routing proxies would be used. Capacity issues shouldn't be an issue with this technology. Brian -----Original Message----- From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Sent: Thursday, June 01, 2006 11:58 AM To: Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Subject: RE: [Enum] How to correctly set up the request URI? Maybe the service provider has some sort of segregated network (physically or logically) and wants/needs to associate each its subscribers with a particular network segment. If the provider went with the flat model of provB.net, each of its proxies would have to accept requests destined to all of its customers and would then have to route the request to the appropriate region or division of its network. If the provider went with the hierarchical approach of sbc4711.provB.net, all of the requests would already be routed to the appropriate ingress point. This could very well save a service provider a lot of money in route proxy equipment although might cost more on the provisioning side. That is my guess. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 11:30 > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Enum] How to correctly set up the request URI? > > Thank you, Tom > > just a minor additional question: > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > If I have to do this according to RFC3263 anyway, why put > the sbc4711.provB.net into ENUM in the first place? > > -sta > > > > -----Original Message----- > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Sent: Thursday, June 01, 2006 4:36 PM > > To: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 09:06 > > > To: speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > Folks, > > > > > > Question for clarification: > > > > > > In the discussions here on how to populate sip URI in Infrastructure > > > ENUM to derive the Call Routing data for SPEERMINT two > > > lines of thought exist: > > > > > > The Enumservice SIP in Infrastructure ENUM should contain > > > 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net > > > 2. the ingress point into the provider network: > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > The originating UAC has in this case set the To: field to > > > tel:+4319793321 and the Request-URI to e.g. > > > sip:+4319793321provA.net;user=phone. This caused the > > > ENUM query at the proxy of provider A > > > > > > The question is how the proxy of provider A is now > > > setting up the request URI in cases mentioned above? > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > > > or must the request URI set to the proper AoR as described in > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > [Tom Creighton wrote:] > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > identify an address that the UAS is willing to accept requests for, it > > SHOULD reject the request with a 404 (Not Found) response." > > > > As long as the UAS from provider B is "willing" to accept the request, > > either should work. Since provider B is populating Infrastructure > ENUM, > > one would hope that they would coordinate this data with the > > configuration of their proxies. > > > > Besides, how do you actually know that sbc4441.provB.net is actually a > > hostname and isn't a subdomain? > > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > > > > > > > I would also like to draw the attention to section 3 of > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in > > > ENUM. > > > > > > Regards > > > > > > -sta > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 01 14:22:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlroT-0004BO-Go; Thu, 01 Jun 2006 14:22:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlroR-0004BJ-Rt for speermint@ietf.org; Thu, 01 Jun 2006 14:22:27 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlroR-0007UH-Eo for speermint@ietf.org; Thu, 01 Jun 2006 14:22: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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 14:22:10 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96625047@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowA From: "Lee, Yiu" To: "Stastny Richard" , "Creighton, Tom" , X-OriginalArrivalTime: 01 Jun 2006 18:22:12.0802 (UTC) FILETIME=[4D824220:01C685A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 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 Actually, I think it is sufficient for the Enum to return the user AOR because the routing decision should happen in the provB.net network. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, June 01, 2006 2:18 PM To: Lee, Yiu; Creighton, Tom; speermint@ietf.org Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Ok, so I am back to my original question: =20 if I implement both types of public user identities: E.164 numbers and SIP AoRs, why doing the mapping to different hosting proxies in two places (in this case ENUM and the HSS), if I can do it only in one place? -sta ________________________________ Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Gesendet: Do 01.06.2006 20:10 An: Stastny Richard; Creighton, Tom; speermint@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Yes. IMS is using Option 2. Option 1 is also possible if the operator decides to use just a redirect proxy. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 2:07 PM To: Creighton, Tom; Lee, Yiu; speermint@ietf.org Cc: enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? so basically the IMS I-CSCF - HSS - S-CSCF way? Richard ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 19:45 An: Lee, Yiu; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop. > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: > > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. > > (2) It replaces the domain part in the r-uri to more specific like=20 > "proxy.austria.provB.net" and forward the message to the next-hop. > > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. > > This is only my guess. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? > > I see, > > but how do you solve this problem if the users can also be reached by AoRs > direct? > > -sta > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the=20 > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. > > That is my guess. > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the=20 > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the=20 > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > 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 Jun 01 14:41:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fls73-0001sF-Dv; Thu, 01 Jun 2006 14:41:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fls72-0001s7-1W; Thu, 01 Jun 2006 14:41:40 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fls70-0002Ck-Bk; Thu, 01 Jun 2006 14:41: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] Re: [Enum] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 20:43:15 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AA4@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAAw2+HA== From: "Stastny Richard" To: "Lee, Yiu" , "Creighton, Tom" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: enum@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 Just out of curiosity: =20 (2) It replaces the domain part in the r-uri to more specific like "proxy.austria.provB.net" and forward the message to the next-hop. Do I have to replace the request URI with "proxy.austria.provB.net, or could I just leave it to "provB.net", assuming that = "proxy.austria.provB.net accepts "provB.net"? =20 -sta ________________________________ Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Gesendet: Do 01.06.2006 19:34 An: Stastny Richard; Creighton, Tom; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? In this case, I guess when the originating proxy resolves the domain part of the AOR (sip:+4319793321@provB.net), it will return the IP address of the root domain "provB.net" which may be a redirect proxy. So "provB.net" has two choices: (1) It accesses its local routing table and sends a 305 to the originating proxy with "sbc4711.provB.net" in the contact header. (2) It replaces the domain part in the r-uri to more specific like "proxy.austria.provB.net" and forward the message to the next-hop. Either case, the assumption is provB.net will have a way to find out where the home proxy of user +4319793321. This is only my guess. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 1:13 PM To: Creighton, Tom; speermint@ietf.org Cc: enum@ietf.org Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? I see, but how do you solve this problem if the users can also be reached by AoRs direct? -sta ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 17:57 An: Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Enum] How to correctly set up the request URI? Maybe the service provider has some sort of segregated network (physically or logically) and wants/needs to associate each its subscribers with a particular network segment. If the provider went with the flat model of provB.net, each of its proxies would have to accept requests destined to all of its customers and would then have to route the request to the appropriate region or division of its network. If the provider went with the hierarchical approach of sbc4711.provB.net, all of the requests would already be routed to the appropriate ingress point. This could very well save a service provider a lot of money in route proxy equipment although might cost more on the provisioning side. That is my guess. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 11:30 > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Enum] How to correctly set up the request URI? > > Thank you, Tom > > just a minor additional question: > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > If I have to do this according to RFC3263 anyway, why put the > sbc4711.provB.net into ENUM in the first place? > > -sta > > > > -----Original Message----- > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Sent: Thursday, June 01, 2006 4:36 PM > > To: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 09:06 > > > To: speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > Folks, > > > > > > Question for clarification: > > > > > > In the discussions here on how to populate sip URI in Infrastructure > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > thought exist: > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > address-of-record of the user: e.g. sip:+4319793321@provB.net > > > 2. the ingress point into the provider network: > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > The originating UAC has in this case set the To: field to > > > tel:+4319793321 and the Request-URI to e.g. > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query = at > > > the proxy of provider A > > > > > > The question is how the proxy of provider A is now setting up the > > > request URI in cases mentioned above? > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > must the request URI set to the proper AoR as described in > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > [Tom Creighton wrote:] > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > identify an address that the UAS is willing to accept requests for, it > > SHOULD reject the request with a 404 (Not Found) response." > > > > As long as the UAS from provider B is "willing" to accept the request, > > either should work. Since provider B is populating Infrastructure > ENUM, > > one would hope that they would coordinate this data with the > > configuration of their proxies. > > > > Besides, how do you actually know that sbc4441.provB.net is actually a > > hostname and isn't a subdomain? > > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > > > > > > > I would also like to draw the attention to section 3 of > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > Regards > > > > > > -sta > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ 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 Jun 01 14:50:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsFd-0007jP-45; Thu, 01 Jun 2006 14:50:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsFb-0007jH-UG; Thu, 01 Jun 2006 14:50:31 -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 1FlsFb-0003UF-5f; Thu, 01 Jun 2006 14:50:31 -0400 Received: from ([10.20.62.13]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.20735439; Thu, 01 Jun 2006 14:50:04 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 14:50: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] Re: [Enum] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 14:50:03 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96625085@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAO9LA= From: "Creighton, Tom" To: "Stastny Richard" , "Lee, Yiu" , X-OriginalArrivalTime: 01 Jun 2006 18:50:04.0398 (UTC) FILETIME=[31DB90E0:01C685AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Cc: enum@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 Provider B could be using an internal ENUM database, an HSS-like database, an LDAP database, or even static route table. I was merely using this as an example and certainly did not mean to imply or suggest that provider B was or had to follow any particular religion. ;-) Another way to look at it would be the case of a city government in the U.S. that acted as its own PSTN provider and wanted to use its .us TLD to provision its records into Infrastructure ENUM. For example: 1. The originating UAC has the To: field set to tel:+12155551234 and the Request-URI to sip:+12155551234@provA.net;user=3Dphone. 2. The provider A proxy performs a query to Infrastructure ENUM. 3. Infrastructure ENUM returns the following AoR: sip:+12155551234@langhorne.pa.us In this fictitious example, the entity that manages pa.us sub-delegated langhorne.pa.us to the Township of Langhorne which gives them full administrative and technical control of their domain. They in turn provision RFC3263 compliant NAPTR and SRV records that point to their SIP proxy. =20 I am just trying to point out that it is impossible to determine the difference between a hostname and a domain name if a provider's ingress sip proxy is configured to accept what is provisioned on the right side of the @ in Infrastructure ENUM. Tom > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 14:07 > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > so basically the IMS I-CSCF - HSS - S-CSCF way? >=20 > Richard >=20 > ________________________________ >=20 > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 19:45 > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > Agreed, in this case the proxy associated with provB.net would be an > intermediate device that would have to perform some sort of internal > lookup in order to route the request to the next hop. >=20 > > -----Original Message----- > > From: Lee, Yiu > > Sent: Thursday, June 01, 2006 13:34 > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > In this case, I guess when the originating proxy resolves the domain > part > > of the AOR (sip:+4319793321@provB.net), it will return the IP address > of > > the root domain "provB.net" which may be a redirect proxy. So > "provB.net" > > has two choices: > > > > (1) It accesses its local routing table and sends a 305 to the > originating > > proxy with "sbc4711.provB.net" in the contact header. > > > > (2) It replaces the domain part in the r-uri to more specific like > > "proxy.austria.provB.net" and forward the message to the next-hop. > > > > Either case, the assumption is provB.net will have a way to find out > where > > the home proxy of user +4319793321. > > > > This is only my guess. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 1:13 PM > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > I see, > > > > but how do you solve this problem if the users can also be reached by > AoRs > > direct? > > > > -sta > > > > ________________________________ > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Gesendet: Do 01.06.2006 17:57 > > An: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > Maybe the service provider has some sort of segregated network > (physically > > or logically) and wants/needs to associate each its subscribers with a > > particular network segment. If the provider went with the flat model > of > > provB.net, each of its proxies would have to accept requests destined > to > > all of its customers and would then have to route the request to the > > appropriate region or division of its network. > > If the provider went with the hierarchical approach of > sbc4711.provB.net, > > all of the requests would already be routed to the appropriate ingress > > point. This could very well save a service provider a lot of money in > > route proxy equipment although might cost more on the provisioning > side. > > > > That is my guess. > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 11:30 > > > To: Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > Thank you, Tom > > > > > > just a minor additional question: > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > sbc4711.provB.net into ENUM in the first place? > > > > > > -sta > > > > > > > > > > -----Original Message----- > > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > To: Stastny Richard; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > To: speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > Folks, > > > > > > > > > > Question for clarification: > > > > > > > > > > In the discussions here on how to populate sip URI in > > Infrastructure > > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > > thought exist: > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > > address-of-record of the user: e.g. > > sip:+4319793321@provB.net > > > > > 2. the ingress point into the provider network: > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query > at > > > > > the proxy of provider A > > > > > > > > > > The question is how the proxy of provider A is now setting up > the > > > > > request URI in cases mentioned above? > > > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > or > > > > > must the request URI set to the proper AoR as described in > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > > > [Tom Creighton wrote:] > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > > identify an address that the UAS is willing to accept requests > for, > > it > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > As long as the UAS from provider B is "willing" to accept the > > request, > > > > either should work. Since provider B is populating Infrastructure > > > ENUM, > > > > one would hope that they would coordinate this data with the > > > > configuration of their proxies. > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > actually > > a > > > > hostname and isn't a subdomain? > > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > > > Regards > > > > > > > > > > -sta > > > > > > > > > > > > > > > _______________________________________________ > > > > > enum mailing list > > > > > enum@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > _______________________________________________ > > 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 Jun 01 15:19:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlshD-0002Gb-Jh; Thu, 01 Jun 2006 15:19:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlshC-0002GV-5g for speermint@ietf.org; Thu, 01 Jun 2006 15:19:02 -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 1FlshB-0006p3-Or for speermint@ietf.org; Thu, 01 Jun 2006 15:19:02 -0400 Received: from ([10.20.9.174]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.20736786; Thu, 01 Jun 2006 15:18:38 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 15:18:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 15:18:35 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D966250C5@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAAw2+HAAAxUgw From: "Lee, Yiu" To: "Stastny Richard" , "Creighton, Tom" , X-OriginalArrivalTime: 01 Jun 2006 19:18:38.0412 (UTC) FILETIME=[2F7D58C0:01C685B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 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, you don't have to. All I try to say is provB is responsible to route the call to the user. If they decide to modify the r-uri to help the downstream proxies, they can. If they decide to put the route set in the header, they also can. This is local routing decision to provB. The bottom line is the request will arrive in the user home proxy to replace the user aor to the registered contact address to reach the user's device. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, June 01, 2006 2:43 PM To: Lee, Yiu; Creighton, Tom; speermint@ietf.org Cc: enum@ietf.org Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Just out of curiosity: =20 (2) It replaces the domain part in the r-uri to more specific like "proxy.austria.provB.net" and forward the message to the next-hop. Do I have to replace the request URI with "proxy.austria.provB.net, or could I just leave it to "provB.net", assuming that "proxy.austria.provB.net accepts "provB.net"? =20 -sta ________________________________ Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Gesendet: Do 01.06.2006 19:34 An: Stastny Richard; Creighton, Tom; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? In this case, I guess when the originating proxy resolves the domain part of the AOR (sip:+4319793321@provB.net), it will return the IP address of the root domain "provB.net" which may be a redirect proxy. So "provB.net" has two choices: (1) It accesses its local routing table and sends a 305 to the originating proxy with "sbc4711.provB.net" in the contact header. (2) It replaces the domain part in the r-uri to more specific like "proxy.austria.provB.net" and forward the message to the next-hop. Either case, the assumption is provB.net will have a way to find out where the home proxy of user +4319793321. This is only my guess. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 1:13 PM To: Creighton, Tom; speermint@ietf.org Cc: enum@ietf.org Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? I see, but how do you solve this problem if the users can also be reached by AoRs direct? -sta ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 17:57 An: Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Enum] How to correctly set up the request URI? Maybe the service provider has some sort of segregated network (physically or logically) and wants/needs to associate each its subscribers with a particular network segment. If the provider went with the flat model of provB.net, each of its proxies would have to accept requests destined to all of its customers and would then have to route the request to the appropriate region or division of its network. If the provider went with the hierarchical approach of sbc4711.provB.net, all of the requests would already be routed to the appropriate ingress point. This could very well save a service provider a lot of money in route proxy equipment although might cost more on the provisioning side. That is my guess. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 11:30 > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Enum] How to correctly set up the request URI? > > Thank you, Tom > > just a minor additional question: > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the=20 > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > If I have to do this according to RFC3263 anyway, why put the=20 > sbc4711.provB.net into ENUM in the first place? > > -sta > > > > -----Original Message----- > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Sent: Thursday, June 01, 2006 4:36 PM > > To: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 09:06 > > > To: speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > Folks, > > > > > > Question for clarification: > > > > > > In the discussions here on how to populate sip URI in Infrastructure > > > ENUM to derive the Call Routing data for SPEERMINT two lines of=20 > > > thought exist: > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the=20 > > > address-of-record of the user: e.g. sip:+4319793321@provB.net > > > 2. the ingress point into the provider network: > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > The originating UAC has in this case set the To: field to > > > tel:+4319793321 and the Request-URI to e.g. > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query = at > > > the proxy of provider A > > > > > > The question is how the proxy of provider A is now setting up the=20 > > > request URI in cases mentioned above? > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > must the request URI set to the proper AoR as described in > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > [Tom Creighton wrote:] > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > identify an address that the UAS is willing to accept requests for, it > > SHOULD reject the request with a 404 (Not Found) response." > > > > As long as the UAS from provider B is "willing" to accept the request, > > either should work. Since provider B is populating Infrastructure > ENUM, > > one would hope that they would coordinate this data with the=20 > > configuration of their proxies. > > > > Besides, how do you actually know that sbc4441.provB.net is actually a > > hostname and isn't a subdomain? > > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the=20 > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > > > > > > > I would also like to draw the attention to section 3 of > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > Regards > > > > > > -sta > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ 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 Jun 01 15:43:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flt4m-0004Zo-Tv; Thu, 01 Jun 2006 15:43:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flt4l-0004Zh-3v for speermint@ietf.org; Thu, 01 Jun 2006 15:43:23 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flt4j-00085t-TQ for speermint@ietf.org; Thu, 01 Jun 2006 15:43:23 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 01 Jun 2006 15:43:51 -0400 id 01588108.447F4377.00002D61 Message-ID: <447F4352.1090202@hxr.us> Date: Thu, 01 Jun 2006 15:43:14 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture References: <32755D354E6B65498C3BD9FD496C7D462C4AA2@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4AA2@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: de4f315c9369b71d7dd5909b42224370 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: > Maybe it is me, but I am not quite able to follow this discussion: > I am a bit confused > > Question for clarification > > What is discovered in which ENUM? > the E.164 to URI mapping club or the SIP peering club? I don't know of a single VoIP peering exchange that uses the e164.arpa. ENUM tree. They might exist, but I've not seen them. If ever there were to be opportunistic peering exchanges, there would need to be discovery of the ENUM tree for that peering exchange so that peers within the exchange can use the E.164 number namespace. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 01 15:54:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FltFW-0007jY-1k; Thu, 01 Jun 2006 15:54:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FltFU-0007jT-6q for speermint@ietf.org; Thu, 01 Jun 2006 15:54:28 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FltFS-0001SN-R6 for speermint@ietf.org; Thu, 01 Jun 2006 15:54:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Thu, 1 Jun 2006 21:55:46 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AA5@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaFtDges3jtL4xaQo+NsrspvL0VDgAASc3o From: "Stastny Richard" To: "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 have an I-D for the ENUM WG in the pipe which may solve your problem, I will submit it after the weekend =20 I am not quite sure what you mean with "opportunistic" peering exchanges =20 -sta =20 =20 ________________________________ Von: Andrew Newton [mailto:andy@hxr.us] Gesendet: Do 01.06.2006 21:43 An: Stastny Richard Cc: richard@shockey.us; speermint@ietf.org Betreff: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Stastny Richard wrote: > Maybe it is me, but I am not quite able to follow this discussion: > I am a bit confused > > Question for clarification >=20 > What is discovered in which ENUM? > the E.164 to URI mapping club or the SIP peering club? I don't know of a single VoIP peering exchange that uses the e164.arpa. ENUM tree. They might exist, but I've not seen them. If ever there were to be opportunistic peering exchanges, there would need to be discovery of the ENUM tree for that peering exchange so that peers within the exchange can use the E.164 number namespace. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 01 18:00:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlvDW-0004D7-Ra; Thu, 01 Jun 2006 18:00:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlvDV-0004Ck-Ds for speermint@ietf.org; Thu, 01 Jun 2006 18:00:33 -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 1FlvDU-00013P-86 for speermint@ietf.org; Thu, 01 Jun 2006 18:00:33 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 01 Jun 2006 18:01:01 -0400 id 01588016.447F639D.0000485D Message-ID: <447F6378.9030901@hxr.us> Date: Thu, 01 Jun 2006 18:00:24 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture References: <32755D354E6B65498C3BD9FD496C7D462C4AA5@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4AA5@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: 7bac9cb154eb5790ae3b2913587a40de 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: > > I am not quite sure what you mean with "opportunistic" > peering exchanges I was using the term to mean a peering exchange (or federation or whatever you want to call them) that can be joined dynamically. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 01 18:10:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlvNV-00050V-1N; Thu, 01 Jun 2006 18:10:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlvNU-0004zR-2O for speermint@ietf.org; Thu, 01 Jun 2006 18:10:52 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlvNS-0002mx-NN for speermint@ietf.org; Thu, 01 Jun 2006 18:10:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Fri, 2 Jun 2006 00:14:56 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AA6@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaFx2HT0pL9HKwBQe+x2bdE2VvI9wAAJBvG From: "Stastny Richard" To: "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 was using the term to mean a peering exchange (or federation or >whatever you want to call them) that can be joined dynamically. On what terms? I still do nor understand. Joining a federation always involves some legal negotiotions. =20 In addition, a "federation" to do ENUM (i.e. E.164 to URI mapping =3D finding out the Carrier-of-Record) and The "federation" to peer VoIP traffic may be identical, but need not to be. As I already pointed out on this list, it is still the choice of the originating service provider to select the peering fabric =20 -sta ________________________________ Von: Andrew Newton [mailto:andy@hxr.us] Gesendet: Fr 02.06.2006 00:00 An: Stastny Richard Cc: richard@shockey.us; speermint@ietf.org Betreff: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Stastny Richard wrote: >=20 > I am not quite sure what you mean with "opportunistic" > peering exchanges I was using the term to mean a peering exchange (or federation or whatever you want to call them) that can be joined dynamically. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 01 20:24:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlxSf-0001Ew-Nr; Thu, 01 Jun 2006 20:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlxSe-0001Er-FQ for speermint@ietf.org; Thu, 01 Jun 2006 20:24:20 -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 1FlxSd-000876-7Q for speermint@ietf.org; Thu, 01 Jun 2006 20:24:20 -0400 Received: from [10.0.1.103] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 01 Jun 2006 20:24:48 -0400 id 01588112.447F8550.00005F27 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4AA6@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4AA6@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <566D4F6D-5DEF-4C61-B090-AB824860C9F2@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Thu, 1 Jun 2006 20:24:11 -0400 To: "Stastny Richard" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) 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 On Jun 1, 2006, at 6:14 PM, Stastny Richard wrote: >> I was using the term to mean a peering exchange (or federation or >> whatever you want to call them) that can be joined dynamically. > > > On what terms? I still do nor understand. Joining a federation > always involves some legal negotiotions. Well, they require an agreement. The legality of that agreement is another matter. If the execution of that agreement requires signed contracts, etc... all the configuration information for joining that federation does not need to be in machine readable form. Indeed, much of it will not be given until an NDA is signed or a service contract is signed, so it won't even be available on the web. If, however, there is intention to have the policies on which the peering federation agreement operates to be machine readable, such as in the DDDS application proposed by Otmar, then this seems to imply that joining the federation is more opportunistic in nature. > In addition, a "federation" to do ENUM (i.e. E.164 to URI mapping = > finding out the Carrier-of-Record) and The "federation" to peer VoIP > traffic may be identical, but need not to be. I guess that is one way to look at it. I've always thought that an ENUM service was just a feature or service of a particular federation. After all, many of the commercial ones today have mechanisms other than ENUM to convert E.164 numbers to URIs. And it is possible that a federation may have multiple namespace management services as E.164 is but just one type of namespace. A federation may decide to offer namespace management for ICQ numbers -- in addition to E.164. > As I already pointed out on this list, it is still the choice of the > originating service provider to select the peering fabric Yes. And to do it today requires no new protocols or work. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 02 05:44:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm6Ct-0006ko-Ax; Fri, 02 Jun 2006 05:44:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm6Cr-0006kj-P3 for speermint@ietf.org; Fri, 02 Jun 2006 05:44:37 -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 1Fm6Cq-0007o1-AQ for speermint@ietf.org; Fri, 02 Jun 2006 05:44:37 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 699A51A37D; Fri, 2 Jun 2006 11:44:34 +0200 (CEST) Date: Fri, 2 Jun 2006 11:44:34 +0200 From: Otmar Lendl To: Andrew Newton Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060602094434.GS1811@nic.at> Mail-Followup-To: Otmar Lendl , Andrew Newton , Stastny Richard , speermint@ietf.org References: <32755D354E6B65498C3BD9FD496C7D462C4AA6@oefeg-s04.oefeg.loc> <566D4F6D-5DEF-4C61-B090-AB824860C9F2@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <566D4F6D-5DEF-4C61-B090-AB824860C9F2@hxr.us> User-Agent: Mutt/1.5.6+20040907i 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 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 2006/06/02 02:06, Andrew Newton wrote: > On Jun 1, 2006, at 6:14 PM, Stastny Richard wrote: > >>I was using the term to mean a peering exchange (or federation or > >>whatever you want to call them) that can be joined dynamically. > > > > > >On what terms? I still do nor understand. Joining a federation > >always involves some legal negotiotions. > > Well, they require an agreement. The legality of that agreement is > another matter. > > If the execution of that agreement requires signed contracts, etc... > all the configuration information for joining that federation does > not need to be in machine readable form. Indeed, much of it will not > be given until an NDA is signed or a service contract is signed, so > it won't even be available on the web. > > If, however, there is intention to have the policies on which the > peering federation agreement operates to be machine readable, such as > in the DDDS application proposed by Otmar, then this seems to imply > that joining the federation is more opportunistic in nature. My DDDS proposal allows both: draft-lendl-speermint-federations-00 is targetted at the former type of federation (we call it "named federation"). All the DNS contains is the federation ID. Nothing else is required. From this the draft (highlighted with !!): -=-=-=- 3. Federations The proposed method is based upon the concept of a "Federation". A federation in this context is defined as follows: A Federation is a group of VoIP service providers which * agree to receive calls from each other via SIP, * agree on a set of administrative rules for such calls (settlement, abuse-handling, ...), and * agree on specific rules for the technical details of the interconnection. !! This document does not define what these rules can be and how they !! are communicated to all members of a federation. There is no !! requirement to make those rules public. Federations shall use URIs as their identifiers. It is RECOMMENDED that federations use URLs as identifiers which point to documents describing the federation. -=-=-=- The draft describing the overall algorithm (draft-lendl-domain-policy-ddds-00) contains an "Examples" section which uses "ad-hoc" federations based on references to standards. That section contains the following warning: -=-=-=- 5. Examples In order to give meaningful examples, we need to define a few types of rules. The definitions here are purely meant to illustrate the possibilities. They MUST NOT be considered as valid examples of real entries. ... o The policy-type "std" shall indicate that the URI indicates a standard the sender has to fulfill. -=-=-=- I haven't written an I-D defining the exact semantics of these ad-hoc federations. Our assumption is that named federation (which can hide their internals from the public) are well suited for peerings between service providers. For the Austrian I-ENUM trial, we're going to start with named federations only. Ad-hoc federations are IMHO more suitable for enterprise environments. Questions to the group: * Is there interest in an I-D which defines the semantic of policy rules which can be used to form ad-hoc federations? * Is there interest in another presentation regarding my domain policy DDDS proposal at the upcoming IETF meeting? /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 Fri Jun 02 15:25:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFGa-00022f-Ne; Fri, 02 Jun 2006 15:25:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFGZ-00022H-II; Fri, 02 Jun 2006 15:25:03 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmFBV-0000Ki-GJ; Fri, 02 Jun 2006 15:19:51 -0400 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.20674403; Fri, 02 Jun 2006 15:19:23 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:19:22 -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, 2 Jun 2006 15:19:21 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96705418@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAA1DG0w From: "Creighton, Tom" To: "Stastny Richard" , X-OriginalArrivalTime: 02 Jun 2006 19:19:22.0599 (UTC) FILETIME=[743D7F70:01C68679] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: enum@ietf.org Subject: [Speermint] RE: [Enum] How to correctly set up the request URI? 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: All examples aside, I attempted to craft some words that would not set any limitations on what can or cannot be used in the host portion of a SIP URI while maintaining a consistent method for resolving whatever is used in the host portion of a SIP URI. When a SIP URI is used in Infrastructure ENUM, the procedures outlined in RFC3263 MUST be followed for locating a UAS that will accept a request for the given URI. For providers assuming the role of a UAS, this means that they MUST provision RFC3263 compliant NAPTR records and SRV records that correspond to the host portion of the SIP URI provisioned in Infrastructure ENUM. For providers assuming the role of a UAC, when a query to Infrastructure ENUM returns a SIP URI, they MUST follow the procedures outlined in Section 4 of RFC3263 to determine the IP address, port, and transport protocol of a UAS that will accept a request for the given URI. Please let me know what you think. Regards, Tom > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 09:06 > To: speermint@ietf.org > Cc: enum@ietf.org > Subject: [Enum] How to correctly set up the request URI? >=20 > Folks, >=20 > Question for clarification: >=20 > In the discussions here on how to populate sip URI in Infrastructure > ENUM to derive the Call Routing data for SPEERMINT two > lines of thought exist: >=20 > The Enumservice SIP in Infrastructure ENUM should contain > 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net > 2. the ingress point into the provider network: > e.g. sip:+4319793321@sbc4711.provB.net >=20 > The originating UAC has in this case set the To: field to > tel:+4319793321 and the Request-URI to e.g. > sip:+4319793321provA.net;user=3Dphone. This caused the > ENUM query at the proxy of provider A >=20 > The question is how the proxy of provider A is now > setting up the request URI in cases mentioned above? >=20 > Does the UAS from provider B accept calls to sbc7411.provB.net, > or must the request URI set to the proper AoR as described in > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. >=20 > I would also like to draw the attention to section 3 of > RFC3761 (SIP Enumservice) explaining the usage of AoR in > ENUM. >=20 > Regards >=20 > -sta >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 02 15:25:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFH2-0002Yg-Dl; Fri, 02 Jun 2006 15:25:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFH0-0002Vl-7d; Fri, 02 Jun 2006 15:25:30 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmF3v-00082y-5T; Fri, 02 Jun 2006 15:11:59 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k52JBrJ28731; Fri, 2 Jun 2006 15:11:54 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 15:11:42 -0400 Message-ID: In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D96625047@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmA= From: "James McEachern" To: "Lee, Yiu" , "Stastny Richard" , "Creighton, Tom" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb 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 the past it has been suggested that if Infrastructure ENUM is openly = accessible, then for data privacy reasons it would not be acceptable to = list the user AOR. Do we still believe this is the case, or do we now = think providing the user AOR would be acceptable? James -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 Sent: Thursday, June 01, 2006 2:22 PM To: Stastny Richard; Creighton, Tom; speermint@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? Actually, I think it is sufficient for the Enum to return the user AOR because the routing decision should happen in the provB.net network. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, June 01, 2006 2:18 PM To: Lee, Yiu; Creighton, Tom; speermint@ietf.org Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Ok, so I am back to my original question: =20 if I implement both types of public user identities: E.164 numbers and SIP AoRs, why doing the mapping to different hosting proxies in two places (in this case ENUM and the HSS), if I can do it only in one place? -sta ________________________________ Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Gesendet: Do 01.06.2006 20:10 An: Stastny Richard; Creighton, Tom; speermint@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Yes. IMS is using Option 2. Option 1 is also possible if the operator decides to use just a redirect proxy. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 2:07 PM To: Creighton, Tom; Lee, Yiu; speermint@ietf.org Cc: enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? so basically the IMS I-CSCF - HSS - S-CSCF way? Richard ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 19:45 An: Lee, Yiu; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop. > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: > > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. > > (2) It replaces the domain part in the r-uri to more specific like=20 > "proxy.austria.provB.net" and forward the message to the next-hop. > > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. > > This is only my guess. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? > > I see, > > but how do you solve this problem if the users can also be reached by AoRs > direct? > > -sta > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the=20 > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. > > That is my guess. > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the=20 > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the=20 > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > 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 Jun 02 15:37:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFSD-00085b-7e; Fri, 02 Jun 2006 15:37:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFSC-000828-EC; Fri, 02 Jun 2006 15:37:04 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmFSA-0002x6-Tr; Fri, 02 Jun 2006 15:37: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Jun 2006 21:41:07 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AA7@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAA1DG0wAArcX1A= From: "Stastny Richard" To: "Creighton, Tom" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: enum@ietf.org Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? 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 Tom, =20 being in favor of the usage of an AoR in Infrastructure ENUM, I have no problems with your proposed words. There are only two issues: =20 1. There will be some people objecting, I assume. 2. Where should this words go? -in the ENUM requirements or in the SPEERMINT requirements? =20 could the esteemed chairs of the two WGs please give their advice? =20 -sta ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Fr 02.06.2006 21:19 An: Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Enum] How to correctly set up the request URI? Richard: All examples aside, I attempted to craft some words that would not set any limitations on what can or cannot be used in the host portion of a SIP URI while maintaining a consistent method for resolving whatever is used in the host portion of a SIP URI. When a SIP URI is used in Infrastructure ENUM, the procedures outlined in RFC3263 MUST be followed for locating a UAS that will accept a request for the given URI. For providers assuming the role of a UAS, this means that they MUST provision RFC3263 compliant NAPTR records and SRV records that correspond to the host portion of the SIP URI provisioned in Infrastructure ENUM. For providers assuming the role of a UAC, when a query to Infrastructure ENUM returns a SIP URI, they MUST follow the procedures outlined in Section 4 of RFC3263 to determine the IP address, port, and transport protocol of a UAS that will accept a request for the given URI. Please let me know what you think. Regards, Tom > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 09:06 > To: speermint@ietf.org > Cc: enum@ietf.org > Subject: [Enum] How to correctly set up the request URI? > > Folks, > > Question for clarification: > > In the discussions here on how to populate sip URI in Infrastructure > ENUM to derive the Call Routing data for SPEERMINT two > lines of thought exist: > > The Enumservice SIP in Infrastructure ENUM should contain > 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net > 2. the ingress point into the provider network: > e.g. sip:+4319793321@sbc4711.provB.net > > The originating UAC has in this case set the To: field to > tel:+4319793321 and the Request-URI to e.g. > sip:+4319793321provA.net;user=3Dphone. This caused the > ENUM query at the proxy of provider A > > The question is how the proxy of provider A is now > setting up the request URI in cases mentioned above? > > Does the UAS from provider B accept calls to sbc7411.provB.net, > or must the request URI set to the proper AoR as described in > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > I would also like to draw the attention to section 3 of > RFC3761 (SIP Enumservice) explaining the usage of AoR in > ENUM. > > Regards > > -sta > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 02 15:46:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFb3-0000FQ-4X; Fri, 02 Jun 2006 15:46:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFb1-0000FI-ML; Fri, 02 Jun 2006 15:46:11 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmFb0-0003xd-OD; Fri, 02 Jun 2006 15:46: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] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 21:50:17 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AA8@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAATCo4AAAf0N2 From: "Stastny Richard" To: "Pfautz, Penn L, GBLAM" , "James McEachern" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c 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 Penn, =20 I just wanted to give a similar reply: the user part of the SIP URI should either be the E.164 phone number and = an identifier not allowing to derive any information about the identity of = the user e.g. an internal number or so. =20 Regarding this issue, we need to add a security section to draft-ietf-enum-infrastructure anyway, so this issue should be covered there. =20 -sta ________________________________ Von: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Gesendet: Fr 02.06.2006 21:30 An: James McEachern; Lee, Yiu; Stastny Richard; Creighton, Tom; = speermint@ietf.org; enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? James I think what this means is that a provider should not provision an AoR that would a) provide personally identifiable information beyond the called phone number or b) allow direct access to the user's CPE. Or are you referring to a user supplied SIP URI? Penn -----Original Message----- From: James McEachern [mailto:jmce@nortel.com] Sent: Friday, June 02, 2006 3:12 PM To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? In the past it has been suggested that if Infrastructure ENUM is openly accessible, then for data privacy reasons it would not be acceptable to list the user AOR. Do we still believe this is the case, or do we now think providing the user AOR would be acceptable? James -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Sent: Thursday, June 01, 2006 2:22 PM To: Stastny Richard; Creighton, Tom; speermint@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Actually, I think it is sufficient for the Enum to return the user AOR because the routing decision should happen in the provB.net network. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 2:18 PM To: Lee, Yiu; Creighton, Tom; speermint@ietf.org Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Ok, so I am back to my original question: if I implement both types of public user identities: E.164 numbers and SIP AoRs, why doing the mapping to different hosting proxies in two places (in this case ENUM and the HSS), if I can do it only in one place? -sta ________________________________ Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Gesendet: Do 01.06.2006 20:10 An: Stastny Richard; Creighton, Tom; speermint@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Yes. IMS is using Option 2. Option 1 is also possible if the operator decides to use just a redirect proxy. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 2:07 PM To: Creighton, Tom; Lee, Yiu; speermint@ietf.org Cc: enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? so basically the IMS I-CSCF - HSS - S-CSCF way? Richard ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 19:45 An: Lee, Yiu; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop. > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: > > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. > > (2) It replaces the domain part in the r-uri to more specific like > "proxy.austria.provB.net" and forward the message to the next-hop. > > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. > > This is only my guess. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? > > I see, > > but how do you solve this problem if the users can also be reached by AoRs > direct? > > -sta > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. > > That is my guess. > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 02 15:49:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFeC-0000g9-1S; Fri, 02 Jun 2006 15:49:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFeA-0000fx-O1; Fri, 02 Jun 2006 15:49:26 -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 1FmFe9-0004Ef-7m; Fri, 02 Jun 2006 15:49:26 -0400 Received: from ([10.52.116.10]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.20781747; Fri, 02 Jun 2006 15:49:00 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:49:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 15:48:59 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96705448@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0A== From: "Creighton, Tom" To: "James McEachern" , "Lee, Yiu" , "Stastny Richard" , , X-OriginalArrivalTime: 02 Jun 2006 19:49:00.0462 (UTC) FILETIME=[97EDDCE0:01C6867D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d 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 we have two separate issues: 1. An issue of misunderstanding of the term AoR. Section 6 of RFC3261 defines an Address-of-Record as: "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user." Based on that definition and the examples provided by Richard, a user's privacy would not be compromised because it doesn't directly reach or identify the customer. 2. There is confusion around what is or is not acceptable in the host portion of a SIP URI. As long as RFC3263 is followed, it shouldn't matter what is placed in the host portion of the SIP URI as long as it doesn't compromise a user's privacy. So in the examples Richard provided earlier, either are acceptable and would resolve in an identical manner. Tom > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, June 02, 2006 15:12 > To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; > enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > In the past it has been suggested that if Infrastructure ENUM is openly > accessible, then for data privacy reasons it would not be acceptable to > list the user AOR. Do we still believe this is the case, or do we now > think providing the user AOR would be acceptable? >=20 > James >=20 > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Sent: Thursday, June 01, 2006 2:22 PM > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Actually, I think it is sufficient for the Enum to return the user AOR > because the routing decision should happen in the provB.net network. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:18 PM > To: Lee, Yiu; Creighton, Tom; speermint@ietf.org > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Ok, so I am back to my original question: >=20 > if I implement both types of public user identities: > E.164 numbers and SIP AoRs, why doing the mapping to different hosting > proxies in two places (in this case ENUM and the HSS), if I can do it > only in one place? >=20 > -sta >=20 >=20 >=20 > ________________________________ >=20 > Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Gesendet: Do 01.06.2006 20:10 > An: Stastny Richard; Creighton, Tom; speermint@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > Yes. IMS is using Option 2. Option 1 is also possible if the operator > decides to use just a redirect proxy. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:07 PM > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > so basically the IMS I-CSCF - HSS - S-CSCF way? >=20 > Richard >=20 > ________________________________ >=20 > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 19:45 > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > Agreed, in this case the proxy associated with provB.net would be an > intermediate device that would have to perform some sort of internal > lookup in order to route the request to the next hop. >=20 > > -----Original Message----- > > From: Lee, Yiu > > Sent: Thursday, June 01, 2006 13:34 > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > In this case, I guess when the originating proxy resolves the domain > part > > of the AOR (sip:+4319793321@provB.net), it will return the IP address > of > > the root domain "provB.net" which may be a redirect proxy. So > "provB.net" > > has two choices: > > > > (1) It accesses its local routing table and sends a 305 to the > originating > > proxy with "sbc4711.provB.net" in the contact header. > > > > (2) It replaces the domain part in the r-uri to more specific like > > "proxy.austria.provB.net" and forward the message to the next-hop. > > > > Either case, the assumption is provB.net will have a way to find out > where > > the home proxy of user +4319793321. > > > > This is only my guess. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 1:13 PM > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > I see, > > > > but how do you solve this problem if the users can also be reached by > AoRs > > direct? > > > > -sta > > > > ________________________________ > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Gesendet: Do 01.06.2006 17:57 > > An: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > Maybe the service provider has some sort of segregated network > (physically > > or logically) and wants/needs to associate each its subscribers with a >=20 > > particular network segment. If the provider went with the flat model > of > > provB.net, each of its proxies would have to accept requests destined > to > > all of its customers and would then have to route the request to the > > appropriate region or division of its network. > > If the provider went with the hierarchical approach of > sbc4711.provB.net, > > all of the requests would already be routed to the appropriate ingress >=20 > > point. This could very well save a service provider a lot of money in >=20 > > route proxy equipment although might cost more on the provisioning > side. > > > > That is my guess. > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 11:30 > > > To: Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > Thank you, Tom > > > > > > just a minor additional question: > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the >=20 > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > sbc4711.provB.net into ENUM in the first place? > > > > > > -sta > > > > > > > > > > -----Original Message----- > > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > To: Stastny Richard; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > To: speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > Folks, > > > > > > > > > > Question for clarification: > > > > > > > > > > In the discussions here on how to populate sip URI in > > Infrastructure > > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of >=20 > > > > > thought exist: > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the >=20 > > > > > address-of-record of the user: e.g. > > sip:+4319793321@provB.net > > > > > 2. the ingress point into the provider network: > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query > at > > > > > the proxy of provider A > > > > > > > > > > The question is how the proxy of provider A is now setting up > the > > > > > request URI in cases mentioned above? > > > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > or > > > > > must the request URI set to the proper AoR as described in > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > > > [Tom Creighton wrote:] > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > > identify an address that the UAS is willing to accept requests > for, > > it > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > As long as the UAS from provider B is "willing" to accept the > > request, > > > > either should work. Since provider B is populating Infrastructure > > > ENUM, > > > > one would hope that they would coordinate this data with the > > > > configuration of their proxies. > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > actually > > a > > > > hostname and isn't a subdomain? > > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the >=20 > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > > > Regards > > > > > > > > > > -sta > > > > > > > > > > > > > > > _______________________________________________ > > > > > enum mailing list > > > > > enum@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > _______________________________________________ > > 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 >=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 Fri Jun 02 15:59:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFnT-0002O3-MR; Fri, 02 Jun 2006 15:59:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFnS-0002Nv-F3; Fri, 02 Jun 2006 15:59:02 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmFnQ-0005ld-Nk; Fri, 02 Jun 2006 15:59:02 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1149276628!9622849!4 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30182 invoked from network); 2 Jun 2006 19:30:56 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-6.tower-120.messagelabs.com with SMTP; 2 Jun 2006 19:30:56 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 44708FE9001BEB82; Fri, 2 Jun 2006 15:30: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] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 15:30:48 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0CEFF776@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAATCo4A== From: "Pfautz, Penn L, GBLAM" To: "James McEachern" , "Lee, Yiu" , "Stastny Richard" , "Creighton, Tom" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d 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 James I think what this means is that a provider should not provision an AoR that would a) provide personally identifiable information beyond the called phone number or b) allow direct access to the user's CPE. Or are you referring to a user supplied SIP URI? Penn=20 -----Original Message----- From: James McEachern [mailto:jmce@nortel.com]=20 Sent: Friday, June 02, 2006 3:12 PM To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? In the past it has been suggested that if Infrastructure ENUM is openly accessible, then for data privacy reasons it would not be acceptable to list the user AOR. Do we still believe this is the case, or do we now think providing the user AOR would be acceptable? James -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 Sent: Thursday, June 01, 2006 2:22 PM To: Stastny Richard; Creighton, Tom; speermint@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Actually, I think it is sufficient for the Enum to return the user AOR because the routing decision should happen in the provB.net network. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, June 01, 2006 2:18 PM To: Lee, Yiu; Creighton, Tom; speermint@ietf.org Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Ok, so I am back to my original question: =20 if I implement both types of public user identities: E.164 numbers and SIP AoRs, why doing the mapping to different hosting proxies in two places (in this case ENUM and the HSS), if I can do it only in one place? -sta ________________________________ Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Gesendet: Do 01.06.2006 20:10 An: Stastny Richard; Creighton, Tom; speermint@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Yes. IMS is using Option 2. Option 1 is also possible if the operator decides to use just a redirect proxy. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 2:07 PM To: Creighton, Tom; Lee, Yiu; speermint@ietf.org Cc: enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? so basically the IMS I-CSCF - HSS - S-CSCF way? Richard ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 19:45 An: Lee, Yiu; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop. > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: > > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. > > (2) It replaces the domain part in the r-uri to more specific like=20 > "proxy.austria.provB.net" and forward the message to the next-hop. > > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. > > This is only my guess. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? > > I see, > > but how do you solve this problem if the users can also be reached by AoRs > direct? > > -sta > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the=20 > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. > > That is my guess. > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the=20 > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the=20 > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 02 15:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFoI-0002eW-GG; Fri, 02 Jun 2006 15:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFoI-0002eO-1Z; Fri, 02 Jun 2006 15:59:54 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmFoG-0005xD-N5; Fri, 02 Jun 2006 15:59:54 -0400 Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.20676753; Fri, 02 Jun 2006 15:59:35 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:59:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Jun 2006 15:59:34 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D9670545E@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAA1DG0wAArcX1AAAHkt4A== From: "Creighton, Tom" To: "Stastny Richard" , X-OriginalArrivalTime: 02 Jun 2006 19:59:35.0450 (UTC) FILETIME=[126957A0:01C6867F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: enum@ietf.org Subject: [Speermint] RE: [Enum] How to correctly set up the request URI? 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 below. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, June 02, 2006 15:41 > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: Re: [Enum] How to correctly set up the request URI? >=20 > Tom, >=20 > being in favor of the usage of an AoR in Infrastructure ENUM, I have no > problems with your proposed words. There are only two issues: >=20 > 1. There will be some people objecting, I assume. [Tom Creighton wrote:]=20 I welcome any comments or recommendations that anyone has to help move beyond this discussion. =20 > 2. Where should this words go? > -in the ENUM requirements or in the SPEERMINT requirements? [Tom Creighton wrote:]=20 My initial reaction would be to keep it in SPEERMINT as this is a peering architecture issue and not a specific ENUM protocol issue, but as you said, advice from the 4 chairs would be appreciated. >=20 > could the esteemed chairs of the two WGs please give their advice? >=20 > -sta >=20 > ________________________________ >=20 > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Fr 02.06.2006 21:19 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? >=20 >=20 >=20 > Richard: >=20 > All examples aside, I attempted to craft some words that would not set > any limitations on what can or cannot be used in the host portion of a > SIP URI while maintaining a consistent method for resolving whatever is > used in the host portion of a SIP URI. >=20 > When a SIP URI is used in Infrastructure ENUM, the procedures outlined > in RFC3263 MUST be followed for locating a UAS that will accept a > request for the given URI. For providers assuming the role of a UAS, > this means that they MUST provision RFC3263 compliant NAPTR records and > SRV records that correspond to the host portion of the SIP URI > provisioned in Infrastructure ENUM. For providers assuming the role of > a UAC, when a query to Infrastructure ENUM returns a SIP URI, they MUST > follow the procedures outlined in Section 4 of RFC3263 to determine the > IP address, port, and transport protocol of a UAS that will accept a > request for the given URI. >=20 > Please let me know what you think. >=20 > Regards, >=20 > Tom >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 09:06 > > To: speermint@ietf.org > > Cc: enum@ietf.org > > Subject: [Enum] How to correctly set up the request URI? > > > > Folks, > > > > Question for clarification: > > > > In the discussions here on how to populate sip URI in Infrastructure > > ENUM to derive the Call Routing data for SPEERMINT two > > lines of thought exist: > > > > The Enumservice SIP in Infrastructure ENUM should contain > > 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net > > 2. the ingress point into the provider network: > > e.g. sip:+4319793321@sbc4711.provB.net > > > > The originating UAC has in this case set the To: field to > > tel:+4319793321 and the Request-URI to e.g. > > sip:+4319793321provA.net;user=3Dphone. This caused the > > ENUM query at the proxy of provider A > > > > The question is how the proxy of provider A is now > > setting up the request URI in cases mentioned above? > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > > or must the request URI set to the proper AoR as described in > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > I would also like to draw the attention to section 3 of > > RFC3761 (SIP Enumservice) explaining the usage of AoR in > > ENUM. > > > > Regards > > > > -sta > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 02 16:40:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGRE-0000TB-Lj; Fri, 02 Jun 2006 16:40:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGRC-0000R1-Ic; Fri, 02 Jun 2006 16:40:06 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGRC-0002fc-2D; Fri, 02 Jun 2006 16:40:06 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k52KYpx21698; Fri, 2 Jun 2006 16:34:52 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 16:39:55 -0400 Message-ID: In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0CEFF776@ACCLUST02EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAATCo4AACUnHw From: "James McEachern" To: "Pfautz, Penn L, GBLAM" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f 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 Penn, I'm thinking of either user supplied SIP URIs, or carrier supplied SIP = URIs other than those that are simply based on the E.164 number. (e.g. sip:+4319793321provA.net;user=3Dphone) I am assuming that these = are possible, and that therefore we must provide a solution that deals = with them. James -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com]=20 Sent: Friday, June 02, 2006 3:31 PM To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; = Creighton, Tom; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? James I think what this means is that a provider should not provision an AoR that would a) provide personally identifiable information beyond the called phone number or b) allow direct access to the user's CPE. Or are you referring to a user supplied SIP URI? Penn=20 -----Original Message----- From: James McEachern [mailto:jmce@nortel.com]=20 Sent: Friday, June 02, 2006 3:12 PM To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? In the past it has been suggested that if Infrastructure ENUM is openly accessible, then for data privacy reasons it would not be acceptable to list the user AOR. Do we still believe this is the case, or do we now think providing the user AOR would be acceptable? James -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 Sent: Thursday, June 01, 2006 2:22 PM To: Stastny Richard; Creighton, Tom; speermint@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Actually, I think it is sufficient for the Enum to return the user AOR because the routing decision should happen in the provB.net network. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, June 01, 2006 2:18 PM To: Lee, Yiu; Creighton, Tom; speermint@ietf.org Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Ok, so I am back to my original question: =20 if I implement both types of public user identities: E.164 numbers and SIP AoRs, why doing the mapping to different hosting proxies in two places (in this case ENUM and the HSS), if I can do it only in one place? -sta ________________________________ Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Gesendet: Do 01.06.2006 20:10 An: Stastny Richard; Creighton, Tom; speermint@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Yes. IMS is using Option 2. Option 1 is also possible if the operator decides to use just a redirect proxy. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 2:07 PM To: Creighton, Tom; Lee, Yiu; speermint@ietf.org Cc: enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? so basically the IMS I-CSCF - HSS - S-CSCF way? Richard ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 19:45 An: Lee, Yiu; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop. > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: > > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. > > (2) It replaces the domain part in the r-uri to more specific like=20 > "proxy.austria.provB.net" and forward the message to the next-hop. > > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. > > This is only my guess. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? > > I see, > > but how do you solve this problem if the users can also be reached by AoRs > direct? > > -sta > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the=20 > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. > > That is my guess. > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the=20 > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the=20 > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 02 16:50:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGap-0004AB-5g; Fri, 02 Jun 2006 16:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGan-00049o-4x; Fri, 02 Jun 2006 16:50:01 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmGam-0004oP-Kv; Fri, 02 Jun 2006 16:50:01 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-11.tower-121.messagelabs.com!1149281314!7603740!27 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 20250 invoked from network); 2 Jun 2006 20:49:59 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-11.tower-121.messagelabs.com with SMTP; 2 Jun 2006 20:49:59 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 44708FE9001C275B; Fri, 2 Jun 2006 16:49: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] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 16:49:58 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0CEFF8CE@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAATCo4AACUnHwAABdhAA= From: "Pfautz, Penn L, GBLAM" To: "James McEachern" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 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 If a carrier agrees to provision a user-supplied URI and the user chooses to use one including PII after proper caution, that's their lookout.=20 I see no privacy issue with a carrier URI like the one you show below as long as it points to a carrier network element rather than directly to say, the user's terminal adapter. If the pointer is direct to CPE I'd have some concerns, which is not to say a provider can be forbidden (except by regulators) to do so. -----Original Message----- From: James McEachern [mailto:jmce@nortel.com]=20 Sent: Friday, June 02, 2006 4:40 PM To: Pfautz, Penn L, GBLAM; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Penn, I'm thinking of either user supplied SIP URIs, or carrier supplied SIP URIs other than those that are simply based on the E.164 number. (e.g. sip:+4319793321provA.net;user=3Dphone) I am assuming that these = are possible, and that therefore we must provide a solution that deals with them. James -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com]=20 Sent: Friday, June 02, 2006 3:31 PM To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? James I think what this means is that a provider should not provision an AoR that would a) provide personally identifiable information beyond the called phone number or b) allow direct access to the user's CPE. Or are you referring to a user supplied SIP URI? Penn=20 -----Original Message----- From: James McEachern [mailto:jmce@nortel.com]=20 Sent: Friday, June 02, 2006 3:12 PM To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? In the past it has been suggested that if Infrastructure ENUM is openly accessible, then for data privacy reasons it would not be acceptable to list the user AOR. Do we still believe this is the case, or do we now think providing the user AOR would be acceptable? James -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 Sent: Thursday, June 01, 2006 2:22 PM To: Stastny Richard; Creighton, Tom; speermint@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Actually, I think it is sufficient for the Enum to return the user AOR because the routing decision should happen in the provB.net network. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, June 01, 2006 2:18 PM To: Lee, Yiu; Creighton, Tom; speermint@ietf.org Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Ok, so I am back to my original question: =20 if I implement both types of public user identities: E.164 numbers and SIP AoRs, why doing the mapping to different hosting proxies in two places (in this case ENUM and the HSS), if I can do it only in one place? -sta ________________________________ Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Gesendet: Do 01.06.2006 20:10 An: Stastny Richard; Creighton, Tom; speermint@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Yes. IMS is using Option 2. Option 1 is also possible if the operator decides to use just a redirect proxy. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 2:07 PM To: Creighton, Tom; Lee, Yiu; speermint@ietf.org Cc: enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? so basically the IMS I-CSCF - HSS - S-CSCF way? Richard ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 19:45 An: Lee, Yiu; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop. > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: > > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. > > (2) It replaces the domain part in the r-uri to more specific like=20 > "proxy.austria.provB.net" and forward the message to the next-hop. > > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. > > This is only my guess. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? > > I see, > > but how do you solve this problem if the users can also be reached by AoRs > direct? > > -sta > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the=20 > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. > > That is my guess. > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the=20 > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the=20 > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 02 16:52:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGcj-0006w5-BI; Fri, 02 Jun 2006 16:52:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGch-0006vb-QH; Fri, 02 Jun 2006 16:51:59 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGch-00053m-8D; Fri, 02 Jun 2006 16:51:59 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k52KpsJ11846; Fri, 2 Jun 2006 16:51:54 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 16:51:34 -0400 Message-ID: In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D96705448@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVA From: "James McEachern" To: "Creighton, Tom" , "Lee, Yiu" , "Stastny Richard" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: e06437eb72f6703f11713d345be8298a 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 Ok, I think I see now. Presumably I can have a SIP URI that clearly = identifies me, but this is not the AOR that would be populated in = Infrastructure ENUM. That AOR would either be based on my E.164 number, = or on some other random string created by the carrier. Have I got it = right? James -----Original Message----- From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com]=20 Sent: Friday, June 02, 2006 3:49 PM To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; = speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? I think we have two separate issues: 1. An issue of misunderstanding of the term AoR. Section 6 of RFC3261 defines an Address-of-Record as: "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user." Based on that definition and the examples provided by Richard, a user's privacy would not be compromised because it doesn't directly reach or identify the customer. 2. There is confusion around what is or is not acceptable in the host portion of a SIP URI. As long as RFC3263 is followed, it shouldn't matter what is placed in the host portion of the SIP URI as long as it doesn't compromise a user's privacy. So in the examples Richard provided earlier, either are acceptable and would resolve in an identical manner. Tom > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, June 02, 2006 15:12 > To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; > enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > In the past it has been suggested that if Infrastructure ENUM is openly > accessible, then for data privacy reasons it would not be acceptable to > list the user AOR. Do we still believe this is the case, or do we now > think providing the user AOR would be acceptable? >=20 > James >=20 > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Sent: Thursday, June 01, 2006 2:22 PM > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Actually, I think it is sufficient for the Enum to return the user AOR > because the routing decision should happen in the provB.net network. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:18 PM > To: Lee, Yiu; Creighton, Tom; speermint@ietf.org > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Ok, so I am back to my original question: >=20 > if I implement both types of public user identities: > E.164 numbers and SIP AoRs, why doing the mapping to different hosting > proxies in two places (in this case ENUM and the HSS), if I can do it > only in one place? >=20 > -sta >=20 >=20 >=20 > ________________________________ >=20 > Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Gesendet: Do 01.06.2006 20:10 > An: Stastny Richard; Creighton, Tom; speermint@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > Yes. IMS is using Option 2. Option 1 is also possible if the operator > decides to use just a redirect proxy. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:07 PM > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > so basically the IMS I-CSCF - HSS - S-CSCF way? >=20 > Richard >=20 > ________________________________ >=20 > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 19:45 > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > Agreed, in this case the proxy associated with provB.net would be an > intermediate device that would have to perform some sort of internal > lookup in order to route the request to the next hop. >=20 > > -----Original Message----- > > From: Lee, Yiu > > Sent: Thursday, June 01, 2006 13:34 > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > In this case, I guess when the originating proxy resolves the domain > part > > of the AOR (sip:+4319793321@provB.net), it will return the IP address > of > > the root domain "provB.net" which may be a redirect proxy. So > "provB.net" > > has two choices: > > > > (1) It accesses its local routing table and sends a 305 to the > originating > > proxy with "sbc4711.provB.net" in the contact header. > > > > (2) It replaces the domain part in the r-uri to more specific like > > "proxy.austria.provB.net" and forward the message to the next-hop. > > > > Either case, the assumption is provB.net will have a way to find out > where > > the home proxy of user +4319793321. > > > > This is only my guess. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 1:13 PM > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > I see, > > > > but how do you solve this problem if the users can also be reached by > AoRs > > direct? > > > > -sta > > > > ________________________________ > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Gesendet: Do 01.06.2006 17:57 > > An: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > Maybe the service provider has some sort of segregated network > (physically > > or logically) and wants/needs to associate each its subscribers with a >=20 > > particular network segment. If the provider went with the flat model > of > > provB.net, each of its proxies would have to accept requests destined > to > > all of its customers and would then have to route the request to the > > appropriate region or division of its network. > > If the provider went with the hierarchical approach of > sbc4711.provB.net, > > all of the requests would already be routed to the appropriate ingress >=20 > > point. This could very well save a service provider a lot of money in >=20 > > route proxy equipment although might cost more on the provisioning > side. > > > > That is my guess. > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 11:30 > > > To: Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > Thank you, Tom > > > > > > just a minor additional question: > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the >=20 > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > sbc4711.provB.net into ENUM in the first place? > > > > > > -sta > > > > > > > > > > -----Original Message----- > > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > To: Stastny Richard; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > To: speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > Folks, > > > > > > > > > > Question for clarification: > > > > > > > > > > In the discussions here on how to populate sip URI in > > Infrastructure > > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of >=20 > > > > > thought exist: > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the >=20 > > > > > address-of-record of the user: e.g. > > sip:+4319793321@provB.net > > > > > 2. the ingress point into the provider network: > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query > at > > > > > the proxy of provider A > > > > > > > > > > The question is how the proxy of provider A is now setting up > the > > > > > request URI in cases mentioned above? > > > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > or > > > > > must the request URI set to the proper AoR as described in > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > > > [Tom Creighton wrote:] > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > > identify an address that the UAS is willing to accept requests > for, > > it > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > As long as the UAS from provider B is "willing" to accept the > > request, > > > > either should work. Since provider B is populating Infrastructure > > > ENUM, > > > > one would hope that they would coordinate this data with the > > > > configuration of their proxies. > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > actually > > a > > > > hostname and isn't a subdomain? > > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the >=20 > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > > > Regards > > > > > > > > > > -sta > > > > > > > > > > > > > > > _______________________________________________ > > > > > enum mailing list > > > > > enum@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > _______________________________________________ > > 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 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 02 16:55:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGgE-0002CX-8E; Fri, 02 Jun 2006 16:55:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGgD-0002CP-01; Fri, 02 Jun 2006 16:55:37 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmGgC-0005NZ-Fh; Fri, 02 Jun 2006 16:55:36 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1149281735!7046634!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30236 invoked from network); 2 Jun 2006 20:55:35 -0000 Received: from unknown (HELO ACCLUST02EVS1.ugd.att.com) (134.24.146.4) by server-14.tower-121.messagelabs.com with SMTP; 2 Jun 2006 20:55:35 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 16:55:34 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0CEFF8DE@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAABBo3A= From: "Pfautz, Penn L, GBLAM" To: "James McEachern" , "Creighton, Tom" , "Lee, Yiu" , "Stastny Richard" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e 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 Yes. Again, there might be exceptions, for example a business might want a URI with their name to be used and some SPs might agree to that, but generally the point of infrastructure ENUM is to be invisible to the user=20 -----Original Message----- From: James McEachern [mailto:jmce@nortel.com]=20 Sent: Friday, June 02, 2006 4:52 PM To: Creighton, Tom; Lee, Yiu; Stastny Richard; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Ok, I think I see now. Presumably I can have a SIP URI that clearly identifies me, but this is not the AOR that would be populated in Infrastructure ENUM. That AOR would either be based on my E.164 number, or on some other random string created by the carrier. Have I got it right? James -----Original Message----- From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com]=20 Sent: Friday, June 02, 2006 3:49 PM To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? I think we have two separate issues: 1. An issue of misunderstanding of the term AoR. Section 6 of RFC3261 defines an Address-of-Record as: "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user." Based on that definition and the examples provided by Richard, a user's privacy would not be compromised because it doesn't directly reach or identify the customer. 2. There is confusion around what is or is not acceptable in the host portion of a SIP URI. As long as RFC3263 is followed, it shouldn't matter what is placed in the host portion of the SIP URI as long as it doesn't compromise a user's privacy. So in the examples Richard provided earlier, either are acceptable and would resolve in an identical manner. Tom > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, June 02, 2006 15:12 > To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; > enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > In the past it has been suggested that if Infrastructure ENUM is openly > accessible, then for data privacy reasons it would not be acceptable to > list the user AOR. Do we still believe this is the case, or do we now > think providing the user AOR would be acceptable? >=20 > James >=20 > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Sent: Thursday, June 01, 2006 2:22 PM > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Actually, I think it is sufficient for the Enum to return the user AOR > because the routing decision should happen in the provB.net network. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:18 PM > To: Lee, Yiu; Creighton, Tom; speermint@ietf.org > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Ok, so I am back to my original question: >=20 > if I implement both types of public user identities: > E.164 numbers and SIP AoRs, why doing the mapping to different hosting > proxies in two places (in this case ENUM and the HSS), if I can do it > only in one place? >=20 > -sta >=20 >=20 >=20 > ________________________________ >=20 > Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Gesendet: Do 01.06.2006 20:10 > An: Stastny Richard; Creighton, Tom; speermint@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > Yes. IMS is using Option 2. Option 1 is also possible if the operator > decides to use just a redirect proxy. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:07 PM > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > so basically the IMS I-CSCF - HSS - S-CSCF way? >=20 > Richard >=20 > ________________________________ >=20 > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 19:45 > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > Agreed, in this case the proxy associated with provB.net would be an > intermediate device that would have to perform some sort of internal > lookup in order to route the request to the next hop. >=20 > > -----Original Message----- > > From: Lee, Yiu > > Sent: Thursday, June 01, 2006 13:34 > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > In this case, I guess when the originating proxy resolves the domain > part > > of the AOR (sip:+4319793321@provB.net), it will return the IP address > of > > the root domain "provB.net" which may be a redirect proxy. So > "provB.net" > > has two choices: > > > > (1) It accesses its local routing table and sends a 305 to the > originating > > proxy with "sbc4711.provB.net" in the contact header. > > > > (2) It replaces the domain part in the r-uri to more specific like > > "proxy.austria.provB.net" and forward the message to the next-hop. > > > > Either case, the assumption is provB.net will have a way to find out > where > > the home proxy of user +4319793321. > > > > This is only my guess. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 1:13 PM > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > I see, > > > > but how do you solve this problem if the users can also be reached by > AoRs > > direct? > > > > -sta > > > > ________________________________ > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Gesendet: Do 01.06.2006 17:57 > > An: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > Maybe the service provider has some sort of segregated network > (physically > > or logically) and wants/needs to associate each its subscribers with a >=20 > > particular network segment. If the provider went with the flat model > of > > provB.net, each of its proxies would have to accept requests destined > to > > all of its customers and would then have to route the request to the > > appropriate region or division of its network. > > If the provider went with the hierarchical approach of > sbc4711.provB.net, > > all of the requests would already be routed to the appropriate ingress >=20 > > point. This could very well save a service provider a lot of money in >=20 > > route proxy equipment although might cost more on the provisioning > side. > > > > That is my guess. > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 11:30 > > > To: Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > Thank you, Tom > > > > > > just a minor additional question: > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the >=20 > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > sbc4711.provB.net into ENUM in the first place? > > > > > > -sta > > > > > > > > > > -----Original Message----- > > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > To: Stastny Richard; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > To: speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > Folks, > > > > > > > > > > Question for clarification: > > > > > > > > > > In the discussions here on how to populate sip URI in > > Infrastructure > > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of >=20 > > > > > thought exist: > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the >=20 > > > > > address-of-record of the user: e.g. > > sip:+4319793321@provB.net > > > > > 2. the ingress point into the provider network: > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query > at > > > > > the proxy of provider A > > > > > > > > > > The question is how the proxy of provider A is now setting up > the > > > > > request URI in cases mentioned above? > > > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > or > > > > > must the request URI set to the proper AoR as described in > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > > > [Tom Creighton wrote:] > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > > identify an address that the UAS is willing to accept requests > for, > > it > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > As long as the UAS from provider B is "willing" to accept the > > request, > > > > either should work. Since provider B is populating Infrastructure > > > ENUM, > > > > one would hope that they would coordinate this data with the > > > > configuration of their proxies. > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > actually > > a > > > > hostname and isn't a subdomain? > > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the >=20 > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > > > Regards > > > > > > > > > > -sta > > > > > > > > > > > > > > > _______________________________________________ > > > > > enum mailing list > > > > > enum@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > _______________________________________________ > > 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 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 02 16:58:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGj2-0004ll-Iy; Fri, 02 Jun 2006 16:58:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGj1-0004lc-0u; Fri, 02 Jun 2006 16:58:31 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGj0-0005lH-Fg; Fri, 02 Jun 2006 16:58:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 16:58:19 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D967054B5@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAAA6/FA= From: "Creighton, Tom" To: "James McEachern" , "Lee, Yiu" , "Stastny Richard" , , X-OriginalArrivalTime: 02 Jun 2006 20:58:19.0961 (UTC) FILETIME=[472F0A90:01C68687] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 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 correct. The SIP URI that clearly identifies you, as you described, would only be used within your provider's network. > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, June 02, 2006 16:52 > To: Creighton, Tom; Lee, Yiu; Stastny Richard; speermint@ietf.org; > enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Ok, I think I see now. Presumably I can have a SIP URI that clearly > identifies me, but this is not the AOR that would be populated in > Infrastructure ENUM. That AOR would either be based on my E.164 number, > or on some other random string created by the carrier. Have I got it > right? >=20 > James >=20 > -----Original Message----- > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Sent: Friday, June 02, 2006 3:49 PM > To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; > speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > I think we have two separate issues: >=20 > 1. An issue of misunderstanding of the term AoR. Section 6 of RFC3261 > defines an Address-of-Record as: >=20 > "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI > that points to a domain with a location service that can map > the URI to another URI where the user might be available. > Typically, the location service is populated through > registrations. An AOR is frequently thought of as the "public > address" of the user." >=20 > Based on that definition and the examples provided by Richard, a user's > privacy would not be compromised because it doesn't directly reach or > identify the customer. >=20 > 2. There is confusion around what is or is not acceptable in the host > portion of a SIP URI. As long as RFC3263 is followed, it shouldn't > matter what is placed in the host portion of the SIP URI as long as it > doesn't compromise a user's privacy. So in the examples Richard > provided earlier, either are acceptable and would resolve in an > identical manner. >=20 > Tom >=20 > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Friday, June 02, 2006 15:12 > > To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; > > enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > In the past it has been suggested that if Infrastructure ENUM is > openly > > accessible, then for data privacy reasons it would not be acceptable > to > > list the user AOR. Do we still believe this is the case, or do we now > > think providing the user AOR would be acceptable? > > > > James > > > > -----Original Message----- > > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > Sent: Thursday, June 01, 2006 2:22 PM > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > Actually, I think it is sufficient for the Enum to return the user AOR > > because the routing decision should happen in the provB.net network. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 2:18 PM > > To: Lee, Yiu; Creighton, Tom; speermint@ietf.org > > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > Ok, so I am back to my original question: > > > > if I implement both types of public user identities: > > E.164 numbers and SIP AoRs, why doing the mapping to different hosting > > proxies in two places (in this case ENUM and the HSS), if I can do it > > only in one place? > > > > -sta > > > > > > > > ________________________________ > > > > Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > Gesendet: Do 01.06.2006 20:10 > > An: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > > > > > Yes. IMS is using Option 2. Option 1 is also possible if the operator > > decides to use just a redirect proxy. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 2:07 PM > > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > so basically the IMS I-CSCF - HSS - S-CSCF way? > > > > Richard > > > > ________________________________ > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Gesendet: Do 01.06.2006 19:45 > > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > > > > > Agreed, in this case the proxy associated with provB.net would be an > > intermediate device that would have to perform some sort of internal > > lookup in order to route the request to the next hop. > > > > > -----Original Message----- > > > From: Lee, Yiu > > > Sent: Thursday, June 01, 2006 13:34 > > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > In this case, I guess when the originating proxy resolves the domain > > part > > > of the AOR (sip:+4319793321@provB.net), it will return the IP > address > > of > > > the root domain "provB.net" which may be a redirect proxy. So > > "provB.net" > > > has two choices: > > > > > > (1) It accesses its local routing table and sends a 305 to the > > originating > > > proxy with "sbc4711.provB.net" in the contact header. > > > > > > (2) It replaces the domain part in the r-uri to more specific like > > > "proxy.austria.provB.net" and forward the message to the next-hop. > > > > > > Either case, the assumption is provB.net will have a way to find out > > where > > > the home proxy of user +4319793321. > > > > > > This is only my guess. > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 1:13 PM > > > To: Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: [Speermint] Re: [Enum] How to correctly set up the request > > URI? > > > > > > I see, > > > > > > but how do you solve this problem if the users can also be reached > by > > AoRs > > > direct? > > > > > > -sta > > > > > > ________________________________ > > > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Gesendet: Do 01.06.2006 17:57 > > > An: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > Maybe the service provider has some sort of segregated network > > (physically > > > or logically) and wants/needs to associate each its subscribers with > a > > > > > particular network segment. If the provider went with the flat > model > > of > > > provB.net, each of its proxies would have to accept requests > destined > > to > > > all of its customers and would then have to route the request to the > > > appropriate region or division of its network. > > > If the provider went with the hierarchical approach of > > sbc4711.provB.net, > > > all of the requests would already be routed to the appropriate > ingress > > > > > point. This could very well save a service provider a lot of money > in > > > > > route proxy equipment although might cost more on the provisioning > > side. > > > > > > That is my guess. > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 11:30 > > > > To: Creighton, Tom; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > Thank you, Tom > > > > > > > > just a minor additional question: > > > > > > > > > In either case, after the provider A proxy performs an ENUM > query > > > and > > > > > rewrites the request URI, it should behave as a UAC and follow > the > > > > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > > address, > > > > > port, and transport protocol for the provider B UAS. > > > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > > sbc4711.provB.net into ENUM in the first place? > > > > > > > > -sta > > > > > > > > > > > > > -----Original Message----- > > > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > > To: Stastny Richard; speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > > To: speermint@ietf.org > > > > > > Cc: enum@ietf.org > > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > Folks, > > > > > > > > > > > > Question for clarification: > > > > > > > > > > > > In the discussions here on how to populate sip URI in > > > Infrastructure > > > > > > ENUM to derive the Call Routing data for SPEERMINT two lines > of > > > > > > > > thought exist: > > > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. > the > > > > > > > > address-of-record of the user: e.g. > > > sip:+4319793321@provB.net > > > > > > 2. the ingress point into the provider network: > > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM > query > > at > > > > > > the proxy of provider A > > > > > > > > > > > > The question is how the proxy of provider A is now setting up > > the > > > > > > request URI in cases mentioned above? > > > > > > > > > > > > Does the UAS from provider B accept calls to > sbc7411.provB.net, > > or > > > > > > must the request URI set to the proper AoR as described in > > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in > ENUM. > > > > > > > > > > [Tom Creighton wrote:] > > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > > > identify an address that the UAS is willing to accept requests > > for, > > > it > > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > > > As long as the UAS from provider B is "willing" to accept the > > > request, > > > > > either should work. Since provider B is populating > Infrastructure > > > > ENUM, > > > > > one would hope that they would coordinate this data with the > > > > > configuration of their proxies. > > > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > > actually > > > a > > > > > hostname and isn't a subdomain? > > > > > > > > > > In either case, after the provider A proxy performs an ENUM > query > > > and > > > > > rewrites the request URI, it should behave as a UAC and follow > the > > > > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > > address, > > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > > > > > Regards > > > > > > > > > > > > -sta > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > enum mailing list > > > > > > enum@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 02 16:59:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGjn-0005Tf-BQ; Fri, 02 Jun 2006 16:59:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGjm-0005TJ-7U; Fri, 02 Jun 2006 16:59:18 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGjk-0005sb-R6; Fri, 02 Jun 2006 16:59:18 -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 k52KxZJN030896; Fri, 2 Jun 2006 13:59:35 -0700 From: "Richard Shockey" To: "'Creighton, Tom'" , "'Stastny Richard'" , Date: Fri, 2 Jun 2006 16:59:09 -0400 Message-ID: <018201c68687$652ea320$40211f0a@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: AcaFfCUKMx50zyJCT9mhJO88vu1YDAA1DG0wAArcX1AAAHkt4AACXAnA In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D9670545E@PACDCEXCMB03.cable.comcast.com> 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: enum@ietf.org Subject: [Speermint] RE: [Enum] How to correctly set up the request URI? 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 This discussion is best kept in SPEERMINT. IMHO. s/ your bewildered ENUM WG co-chair > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Friday, June 02, 2006 15:41 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: Re: [Enum] How to correctly set up the request URI? > > > > Tom, > > > > being in favor of the usage of an AoR in Infrastructure ENUM, I have > no > > problems with your proposed words. There are only two issues: > > > > 1. There will be some people objecting, I assume. > > [Tom Creighton wrote:] > > I welcome any comments or recommendations that anyone has to help move > beyond this discussion. > > > 2. Where should this words go? > > -in the ENUM requirements or in the SPEERMINT requirements? > > [Tom Creighton wrote:] > > My initial reaction would be to keep it in SPEERMINT as this is a > peering architecture issue and not a specific ENUM protocol issue, but > as you said, advice from the 4 chairs would be appreciated. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 02 16:59:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGjp-0005Vs-1Y; Fri, 02 Jun 2006 16:59:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGjn-0005TW-8L; Fri, 02 Jun 2006 16:59:19 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmGjm-0005sc-6M; Fri, 02 Jun 2006 16:59:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 23:03:24 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AA9@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAABmHa4= From: "Stastny Richard" To: "James McEachern" , "Creighton, Tom" , "Lee, Yiu" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 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 Exactly, =20 A service provider will never populate Infrastructure ENUM with a user = provided URI, (even if the user may have one), it will always be the alias used by the service provider. =20 We should not mix this up with the discussion in SPEERMINT on user = provided AoR such as sip:user@company.com. This will always be an alias in = addition to the AoR used by the provider. =20 Of couse the user may use this AoR in User ENUM. =20 -sta ________________________________ Von: James McEachern [mailto:jmce@nortel.com] Gesendet: Fr 02.06.2006 22:51 An: Creighton, Tom; Lee, Yiu; Stastny Richard; speermint@ietf.org; = enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? Ok, I think I see now. Presumably I can have a SIP URI that clearly = identifies me, but this is not the AOR that would be populated in = Infrastructure ENUM. That AOR would either be based on my E.164 number, = or on some other random string created by the carrier. Have I got it = right? James -----Original Message----- From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Sent: Friday, June 02, 2006 3:49 PM To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; = speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? I think we have two separate issues: 1. An issue of misunderstanding of the term AoR. Section 6 of RFC3261 defines an Address-of-Record as: "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user." Based on that definition and the examples provided by Richard, a user's privacy would not be compromised because it doesn't directly reach or identify the customer. 2. There is confusion around what is or is not acceptable in the host portion of a SIP URI. As long as RFC3263 is followed, it shouldn't matter what is placed in the host portion of the SIP URI as long as it doesn't compromise a user's privacy. So in the examples Richard provided earlier, either are acceptable and would resolve in an identical manner. Tom > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, June 02, 2006 15:12 > To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; > enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In the past it has been suggested that if Infrastructure ENUM is openly > accessible, then for data privacy reasons it would not be acceptable to > list the user AOR. Do we still believe this is the case, or do we now > think providing the user AOR would be acceptable? > > James > > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Sent: Thursday, June 01, 2006 2:22 PM > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > Actually, I think it is sufficient for the Enum to return the user AOR > because the routing decision should happen in the provB.net network. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:18 PM > To: Lee, Yiu; Creighton, Tom; speermint@ietf.org > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > Ok, so I am back to my original question: > > if I implement both types of public user identities: > E.164 numbers and SIP AoRs, why doing the mapping to different hosting > proxies in two places (in this case ENUM and the HSS), if I can do it > only in one place? > > -sta > > > > ________________________________ > > Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Gesendet: Do 01.06.2006 20:10 > An: Stastny Richard; Creighton, Tom; speermint@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > Yes. IMS is using Option 2. Option 1 is also possible if the operator > decides to use just a redirect proxy. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:07 PM > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > so basically the IMS I-CSCF - HSS - S-CSCF way? > > Richard > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 19:45 > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > Agreed, in this case the proxy associated with provB.net would be an > intermediate device that would have to perform some sort of internal > lookup in order to route the request to the next hop. > > > -----Original Message----- > > From: Lee, Yiu > > Sent: Thursday, June 01, 2006 13:34 > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > In this case, I guess when the originating proxy resolves the domain > part > > of the AOR (sip:+4319793321@provB.net), it will return the IP address > of > > the root domain "provB.net" which may be a redirect proxy. So > "provB.net" > > has two choices: > > > > (1) It accesses its local routing table and sends a 305 to the > originating > > proxy with "sbc4711.provB.net" in the contact header. > > > > (2) It replaces the domain part in the r-uri to more specific like > > "proxy.austria.provB.net" and forward the message to the next-hop. > > > > Either case, the assumption is provB.net will have a way to find out > where > > the home proxy of user +4319793321. > > > > This is only my guess. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 1:13 PM > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > I see, > > > > but how do you solve this problem if the users can also be reached by > AoRs > > direct? > > > > -sta > > > > ________________________________ > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Gesendet: Do 01.06.2006 17:57 > > An: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > Maybe the service provider has some sort of segregated network > (physically > > or logically) and wants/needs to associate each its subscribers with a > > > particular network segment. If the provider went with the flat model > of > > provB.net, each of its proxies would have to accept requests destined > to > > all of its customers and would then have to route the request to the > > appropriate region or division of its network. > > If the provider went with the hierarchical approach of > sbc4711.provB.net, > > all of the requests would already be routed to the appropriate ingress > > > point. This could very well save a service provider a lot of money in > > > route proxy equipment although might cost more on the provisioning > side. > > > > That is my guess. > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 11:30 > > > To: Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > Thank you, Tom > > > > > > just a minor additional question: > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the > > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > sbc4711.provB.net into ENUM in the first place? > > > > > > -sta > > > > > > > > > > -----Original Message----- > > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > To: Stastny Richard; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > To: speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > Folks, > > > > > > > > > > Question for clarification: > > > > > > > > > > In the discussions here on how to populate sip URI in > > Infrastructure > > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > > > thought exist: > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > > > address-of-record of the user: e.g. > > sip:+4319793321@provB.net > > > > > 2. the ingress point into the provider network: > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query > at > > > > > the proxy of provider A > > > > > > > > > > The question is how the proxy of provider A is now setting up > the > > > > > request URI in cases mentioned above? > > > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > or > > > > > must the request URI set to the proper AoR as described in > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > > > [Tom Creighton wrote:] > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > > identify an address that the UAS is willing to accept requests > for, > > it > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > As long as the UAS from provider B is "willing" to accept the > > request, > > > > either should work. Since provider B is populating Infrastructure > > > ENUM, > > > > one would hope that they would coordinate this data with the > > > > configuration of their proxies. > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > actually > > a > > > > hostname and isn't a subdomain? > > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the > > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > > > Regards > > > > > > > > > > -sta > > > > > > > > > > > > > > > _______________________________________________ > > > > > enum mailing list > > > > > enum@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > _______________________________________________ > > 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 02 17:33:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHGT-0005ty-IR; Fri, 02 Jun 2006 17:33:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHGS-0005tn-GP; Fri, 02 Jun 2006 17:33:04 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmHGR-0000H8-2I; Fri, 02 Jun 2006 17:33: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 23:37:09 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AAB@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaGigRqepu1NVO+QBGwtTETRZuWxgAAalQs From: "Stastny Richard" To: "Tony Rutkowski" , "Pfautz, Penn L, GBLAM" , "James McEachern" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Tony, =20 I do not fully understand what the CALEA issue has to do with the = question which URI is put in ENUM. This may be a signalling requirement in SPEERMINT =20 I have complete different concerns regarding CALEA, in principle I do=20 not understand why the service providers are bothered with this at all, because the NSA is getting all data from Penn anyway ;-) =20 http://news.com.com/AT38T+leaks+sensitive+info+in+NSA+suit/2100-1028_3-60= 77353.html?tag=3Dnefd.lede =20 http://www.wired.com/news/technology/0,70944-0.html =20 -sta ________________________________ Von: Tony Rutkowski [mailto:trutkowski@verisign.com] Gesendet: Fr 02.06.2006 23:13 An: Pfautz, Penn L, GBLAM; James McEachern; speermint@ietf.org; = enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? Hi Penn, >I see no privacy issue with a carrier URI like the one you show below = as >long as it points to a carrier network element rather than directly to >say, the user's terminal adapter. If the pointer is direct to CPE I'd >have some concerns, which is not to say a provider can be forbidden >(except by regulators) to do so. The concerns primarily relate to network integrity as well as support of law enforcement (CALEA/LI requirements) in determining authoritative bindings of user/provider information to identifiers. In Europe and many countries, this binding information is also subject to data retention directives. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 02 17:49:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHWJ-0007ku-Vp; Fri, 02 Jun 2006 17:49:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHWI-0007fW-GH; Fri, 02 Jun 2006 17:49:26 -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 1FmGzR-0007Ap-Ih; Fri, 02 Jun 2006 17:15:29 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FmGor-00040o-Ep; Fri, 02 Jun 2006 17:04: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Jun 2006 23:05:53 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AAA@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAA1DG0wAArcX1AAAHkt4AACXAnAAABOEK8= From: "Stastny Richard" To: , "Creighton, Tom" , X-Spam-Score: -2.5 (--) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: enum@ietf.org Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? 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 also my preference, but it is basically what SPEERMINT expects to be the CRD output from Infrastructure ENUM (so it could also be a BCP what to put into Infrastucture ENUM ;-) =20 -sta ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Fr 02.06.2006 22:59 An: 'Creighton, Tom'; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Enum] How to correctly set up the request URI? This discussion is best kept in SPEERMINT. IMHO. s/ your bewildered ENUM WG co-chair > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Friday, June 02, 2006 15:41 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: Re: [Enum] How to correctly set up the request URI? > > > > Tom, > > > > being in favor of the usage of an AoR in Infrastructure ENUM, I have > no > > problems with your proposed words. There are only two issues: > > > > 1. There will be some people objecting, I assume. > > [Tom Creighton wrote:] > > I welcome any comments or recommendations that anyone has to help move > beyond this discussion. > > > 2. Where should this words go? > > -in the ENUM requirements or in the SPEERMINT requirements? > > [Tom Creighton wrote:] > > My initial reaction would be to keep it in SPEERMINT as this is a > peering architecture issue and not a specific ENUM protocol issue, but > as you said, advice from the 4 chairs would be appreciated. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 02 18:17:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHx0-00018H-OM; Fri, 02 Jun 2006 18:17:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHwz-000189-U7; Fri, 02 Jun 2006 18:17:01 -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 1FmHwz-00043c-5s; Fri, 02 Jun 2006 18:17:01 -0400 Received: from outbound2-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-cpk-R.bigfish.com (Postfix) with ESMTP id 9BC9A9471EA; Fri, 2 Jun 2006 22:17:00 +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 92E599471E9; Fri, 2 Jun 2006 22:17:00 +0000 (UTC) Received: from mail39-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail39-cpk-R.bigfish.com (Postfix) with ESMTP id 2A72E46A01C; Fri, 2 Jun 2006 22:17:00 +0000 (UTC) X-BigFish: V Received: by mail39-cpk (MessageSwitch) id 114928662084264_22403; Fri, 2 Jun 2006 22:17:00 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail39-cpk.bigfish.com (Postfix) with ESMTP id E3DCA469EA7; Fri, 2 Jun 2006 22:16:59 +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 k52MGE5p029369; Fri, 2 Jun 2006 17:16:29 -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 k52MGDI23959; Fri, 2 Jun 2006 17:16:13 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by pdawg06a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 17:15:25 -0500 Received: from 10.122.2.34 ([10.122.2.34]) by PLSWB08C.ad.sprint.com ([208.10.70.245]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Jun 2006 22:15:24 +0000 MIME-Version: 1.0 From: "Khan, Sohel Q [CTO]" Message-ID: <40b401c68692$0b63f43f$22027a0a@ad.sprint.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 17:17:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAAMaWkA= Importance: normal X-Priority: 3 To: "James McEachern" , "Creighton, Tom" , "Lee, Yiu" , "Stastny Richard" , , X-OriginalArrivalTime: 02 Jun 2006 22:15:25.0476 (UTC) FILETIME=[0C349E40:01C68692] X-Spam-Score: 3.1 (+++) X-Scan-Signature: 3dc828214e948ff35b815af10e94a823 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 do not know whether I am writing in the right place. Please understand = that users are =20 Mobile to roam among providers and also prefer to maintain same identity = when they switch providers. Sohel=20 -----Original Message----- From: "James McEachern" To: "Creighton, Tom" ; "Lee, Yiu" = ; "Stastny Richard" = ; "speermint@ietf.org" ; = "enum@ietf.org" Sent: 6/2/06 3:51 PM Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? Ok, I think I see now. Presumably I can have a SIP URI that clearly = identifies me, but this is not the AOR that would be populated in = Infrastructure ENUM. That AOR would either be based on my E.164 number, = or on some other random string created by the carrier. Have I got it = right? James -----Original Message----- From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com]=20 Sent: Friday, June 02, 2006 3:49 PM To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; = speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? I think we have two separate issues: 1. An issue of misunderstanding of the term AoR. Section 6 of RFC3261 defines an Address-of-Record as: "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user." Based on that definition and the examples provided by Richard, a user's privacy would not be compromised because it doesn't directly reach or identify the customer. 2. There is confusion around what is or is not acceptable in the host portion of a SIP URI. As long as RFC3263 is followed, it shouldn't matter what is placed in the host portion of the SIP URI as long as it doesn't compromise a user's privacy. So in the examples Richard provided earlier, either are acceptable and would resolve in an identical manner. Tom > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, June 02, 2006 15:12 > To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; > enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > In the past it has been suggested that if Infrastructure ENUM is openly > accessible, then for data privacy reasons it would not be acceptable to > list the user AOR. Do we still believe this is the case, or do we now > think providing the user AOR would be acceptable? >=20 > James >=20 > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Sent: Thursday, June 01, 2006 2:22 PM > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Actually, I think it is sufficient for the Enum to return the user AOR > because the routing decision should happen in the provB.net network. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:18 PM > To: Lee, Yiu; Creighton, Tom; speermint@ietf.org > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Ok, so I am back to my original question: >=20 > if I implement both types of public user identities: > E.164 numbers and SIP AoRs, why doing the mapping to different hosting > proxies in two places (in this case ENUM and the HSS), if I can do it > only in one place? >=20 > -sta >=20 >=20 >=20 > ________________________________ >=20 > Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Gesendet: Do 01.06.2006 20:10 > An: Stastny Richard; Creighton, Tom; speermint@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > Yes. IMS is using Option 2. Option 1 is also possible if the operator > decides to use just a redirect proxy. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:07 PM > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > so basically the IMS I-CSCF - HSS - S-CSCF way? >=20 > Richard >=20 > ________________________________ >=20 > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 19:45 > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > Agreed, in this case the proxy associated with provB.net would be an > intermediate device that would have to perform some sort of internal > lookup in order to route the request to the next hop. >=20 > > -----Original Message----- > > From: Lee, Yiu > > Sent: Thursday, June 01, 2006 13:34 > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > In this case, I guess when the originating proxy resolves the domain > part > > of the AOR (sip:+4319793321@provB.net), it will return the IP address > of > > the root domain "provB.net" which may be a redirect proxy. So > "provB.net" > > has two choices: > > > > (1) It accesses its local routing table and sends a 305 to the > originating > > proxy with "sbc4711.provB.net" in the contact header. > > > > (2) It replaces the domain part in the r-uri to more specific like > > "proxy.austria.provB.net" and forward the message to the next-hop. > > > > Either case, the assumption is provB.net will have a way to find out > where > > the home proxy of user +4319793321. > > > > This is only my guess. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 1:13 PM > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > I see, > > > > but how do you solve this problem if the users can also be reached by > AoRs > > direct? > > > > -sta > > > > ________________________________ > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Gesendet: Do 01.06.2006 17:57 > > An: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > Maybe the service provider has some sort of segregated network > (physically > > or logically) and wants/needs to associate each its subscribers with a >=20 > > particular network segment. If the provider went with the flat model > of > > provB.net, each of its proxies would have to accept requests destined > to > > all of its customers and would then have to route the request to the > > appropriate region or division of its network. > > If the provider went with the hierarchical approach of > sbc4711.provB.net, > > all of the requests would already be routed to the appropriate ingress >=20 > > point. This could very well save a service provider a lot of money in >=20 > > route proxy equipment although might cost more on the provisioning > side. > > > > That is my guess. > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 11:30 > > > To: Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > Thank you, Tom > > > > > > just a minor additional question: > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the >=20 > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > sbc4711.provB.net into ENUM in the first place? > > > > > > -sta > > > > > > > > > > -----Original Message----- > > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > To: Stastny Richard; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > To: speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > Folks, > > > > > > > > > > Question for clarification: > > > > > > > > > > In the discussions here on how to populate sip URI in > > Infrastructure > > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of >=20 > > > > > thought exist: > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the >=20 > > > > > address-of-record of the user: e.g. > > sip:+4319793321@provB.net > > > > > 2. the ingress point into the provider network: > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query > at > > > > > the proxy of provider A > > > > > > > > > > The question is how the proxy of provider A is now setting up > the > > > > > request URI in cases mentioned above? > > > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > or > > > > > must the request URI set to the proper AoR as described in > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > > > [Tom Creighton wrote:] > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > > identify an address that the UAS is willing to accept requests > for, > > it > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > As long as the UAS from provider B is "willing" to accept the > > request, > > > > either should work. Since provider B is populating Infrastructure > > > ENUM, > > > > one would hope that they would coordinate this data with the > > > > configuration of their proxies. > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > actually > > a > > > > hostname and isn't a subdomain? > > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the >=20 > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > > > Regards > > > > > > > > > > -sta > > > > > > > > > > > > > > > _______________________________________________ > > > > > enum mailing list > > > > > enum@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > _______________________________________________ > > 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 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ 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 Jun 02 23:52:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmNBv-0004tW-UL; Fri, 02 Jun 2006 23:52:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmNBu-0004tR-UR for speermint@ietf.org; Fri, 02 Jun 2006 23:52:46 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmNBu-0005Jb-Bs for speermint@ietf.org; Fri, 02 Jun 2006 23:52:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 23:52:16 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D967054FE@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAAMaWkAACok3IA== From: "Creighton, Tom" To: "Khan, Sohel Q [CTO]" , X-OriginalArrivalTime: 03 Jun 2006 03:52:17.0544 (UTC) FILETIME=[1B897080:01C686C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 916029c14bdb340aa234d3ec4cd24f52 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 Sohel: I don't believe that mobility has any bearing on this particular discussion. We are concentrating on the first part of the AoR definition (referenced below) where a SIP or SIPS URI is populated in Infrastructure ENUM and points to a domain (service provider) with a location service. In my mind, that provider-owned location service is where the presence/mobility data would be consulted, thus allowing the subscriber to maintain their identity regardless of where they roamed. =20 Tom > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Friday, June 02, 2006 18:18 > To: James McEachern; Creighton, Tom; Lee, Yiu; Stastny Richard; > speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > I do not know whether I am writing in the right place. Please understand > that users are > Mobile to roam among providers and also prefer to maintain same identity > when they switch providers. >=20 > Sohel >=20 > -----Original Message----- > From: "James McEachern" > To: "Creighton, Tom" ; "Lee, Yiu" > ; "Stastny Richard" ; > "speermint@ietf.org" ; "enum@ietf.org" > Sent: 6/2/06 3:51 PM > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Ok, I think I see now. Presumably I can have a SIP URI that clearly > identifies me, but this is not the AOR that would be populated in > Infrastructure ENUM. That AOR would either be based on my E.164 number, > or on some other random string created by the carrier. Have I got it > right? >=20 > James >=20 > -----Original Message----- > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Sent: Friday, June 02, 2006 3:49 PM > To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; > speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > I think we have two separate issues: >=20 > 1. An issue of misunderstanding of the term AoR. Section 6 of RFC3261 > defines an Address-of-Record as: >=20 > "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI > that points to a domain with a location service that can map > the URI to another URI where the user might be available. > Typically, the location service is populated through > registrations. An AOR is frequently thought of as the "public > address" of the user." >=20 > Based on that definition and the examples provided by Richard, a user's > privacy would not be compromised because it doesn't directly reach or > identify the customer. >=20 > 2. There is confusion around what is or is not acceptable in the host > portion of a SIP URI. As long as RFC3263 is followed, it shouldn't > matter what is placed in the host portion of the SIP URI as long as it > doesn't compromise a user's privacy. So in the examples Richard > provided earlier, either are acceptable and would resolve in an > identical manner. >=20 > Tom >=20 > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Friday, June 02, 2006 15:12 > > To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; > > enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > In the past it has been suggested that if Infrastructure ENUM is > openly > > accessible, then for data privacy reasons it would not be acceptable > to > > list the user AOR. Do we still believe this is the case, or do we now > > think providing the user AOR would be acceptable? > > > > James > > > > -----Original Message----- > > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > Sent: Thursday, June 01, 2006 2:22 PM > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > Actually, I think it is sufficient for the Enum to return the user AOR > > because the routing decision should happen in the provB.net network. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 2:18 PM > > To: Lee, Yiu; Creighton, Tom; speermint@ietf.org > > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > Ok, so I am back to my original question: > > > > if I implement both types of public user identities: > > E.164 numbers and SIP AoRs, why doing the mapping to different hosting > > proxies in two places (in this case ENUM and the HSS), if I can do it > > only in one place? > > > > -sta > > > > > > > > ________________________________ > > > > Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > Gesendet: Do 01.06.2006 20:10 > > An: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > > > > > Yes. IMS is using Option 2. Option 1 is also possible if the operator > > decides to use just a redirect proxy. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 2:07 PM > > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > so basically the IMS I-CSCF - HSS - S-CSCF way? > > > > Richard > > > > ________________________________ > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Gesendet: Do 01.06.2006 19:45 > > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > > > > > Agreed, in this case the proxy associated with provB.net would be an > > intermediate device that would have to perform some sort of internal > > lookup in order to route the request to the next hop. > > > > > -----Original Message----- > > > From: Lee, Yiu > > > Sent: Thursday, June 01, 2006 13:34 > > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > In this case, I guess when the originating proxy resolves the domain > > part > > > of the AOR (sip:+4319793321@provB.net), it will return the IP > address > > of > > > the root domain "provB.net" which may be a redirect proxy. So > > "provB.net" > > > has two choices: > > > > > > (1) It accesses its local routing table and sends a 305 to the > > originating > > > proxy with "sbc4711.provB.net" in the contact header. > > > > > > (2) It replaces the domain part in the r-uri to more specific like > > > "proxy.austria.provB.net" and forward the message to the next-hop. > > > > > > Either case, the assumption is provB.net will have a way to find out > > where > > > the home proxy of user +4319793321. > > > > > > This is only my guess. > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 1:13 PM > > > To: Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: [Speermint] Re: [Enum] How to correctly set up the request > > URI? > > > > > > I see, > > > > > > but how do you solve this problem if the users can also be reached > by > > AoRs > > > direct? > > > > > > -sta > > > > > > ________________________________ > > > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Gesendet: Do 01.06.2006 17:57 > > > An: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > Maybe the service provider has some sort of segregated network > > (physically > > > or logically) and wants/needs to associate each its subscribers with > a > > > > > particular network segment. If the provider went with the flat > model > > of > > > provB.net, each of its proxies would have to accept requests > destined > > to > > > all of its customers and would then have to route the request to the > > > appropriate region or division of its network. > > > If the provider went with the hierarchical approach of > > sbc4711.provB.net, > > > all of the requests would already be routed to the appropriate > ingress > > > > > point. This could very well save a service provider a lot of money > in > > > > > route proxy equipment although might cost more on the provisioning > > side. > > > > > > That is my guess. > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 11:30 > > > > To: Creighton, Tom; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > Thank you, Tom > > > > > > > > just a minor additional question: > > > > > > > > > In either case, after the provider A proxy performs an ENUM > query > > > and > > > > > rewrites the request URI, it should behave as a UAC and follow > the > > > > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > > address, > > > > > port, and transport protocol for the provider B UAS. > > > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > > sbc4711.provB.net into ENUM in the first place? > > > > > > > > -sta > > > > > > > > > > > > > -----Original Message----- > > > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > > To: Stastny Richard; speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > > To: speermint@ietf.org > > > > > > Cc: enum@ietf.org > > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > Folks, > > > > > > > > > > > > Question for clarification: > > > > > > > > > > > > In the discussions here on how to populate sip URI in > > > Infrastructure > > > > > > ENUM to derive the Call Routing data for SPEERMINT two lines > of > > > > > > > > thought exist: > > > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. > the > > > > > > > > address-of-record of the user: e.g. > > > sip:+4319793321@provB.net > > > > > > 2. the ingress point into the provider network: > > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM > query > > at > > > > > > the proxy of provider A > > > > > > > > > > > > The question is how the proxy of provider A is now setting up > > the > > > > > > request URI in cases mentioned above? > > > > > > > > > > > > Does the UAS from provider B accept calls to > sbc7411.provB.net, > > or > > > > > > must the request URI set to the proper AoR as described in > > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in > ENUM. > > > > > > > > > > [Tom Creighton wrote:] > > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > > > identify an address that the UAS is willing to accept requests > > for, > > > it > > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > > > As long as the UAS from provider B is "willing" to accept the > > > request, > > > > > either should work. Since provider B is populating > Infrastructure > > > > ENUM, > > > > > one would hope that they would coordinate this data with the > > > > > configuration of their proxies. > > > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > > actually > > > a > > > > > hostname and isn't a subdomain? > > > > > > > > > > In either case, after the provider A proxy performs an ENUM > query > > > and > > > > > rewrites the request URI, it should behave as a UAC and follow > the > > > > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > > address, > > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > > > > > Regards > > > > > > > > > > > > -sta > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > enum mailing list > > > > > > enum@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=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 Sat Jun 03 09:11:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmVux-0000gy-EP; Sat, 03 Jun 2006 09:11:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmVuv-0000gl-Fc; Sat, 03 Jun 2006 09:11:49 -0400 Received: from omzesmtp02.mci.com ([199.249.17.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmVur-0000Ab-8M; Sat, 03 Jun 2006 09:11:49 -0400 Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J0A00H4XCNKKZ@firewall.mci.com>; Sat, 03 Jun 2006 13:11:44 +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 <0J0A00JECCNKSR@pmismtp04.mcilink.com>; Sat, 03 Jun 2006 13:11:44 +0000 (GMT) Received: from XS107V7775199 ([131.146.26.60]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0J0A00I6PCN56D@pmismtp04.mcilink.com>; Sat, 03 Jun 2006 13:11:44 +0000 (GMT) Date: Sat, 03 Jun 2006 08:11:24 -0500 From: Tim Dwight Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? In-reply-to: <4884CD6C1DF0A8429DD8DAD942BF9D967054B5@PACDCEXCMB03.cable.comcast.com> To: "'Creighton, Tom'" , 'James McEachern' , "'Lee, Yiu'" , 'Stastny Richard' , speermint@ietf.org, enum@ietf.org Message-id: <001c01c6870f$3e70b1f0$3c1a9283@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: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAAA6/FAAIbZ38A== X-Spam-Score: 0.1 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 Cc: 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 What good does this globally-visible public-user-ID to private-user-ID visible only within the serving network scheme do, if the means of translating globally-visible public user ID to private user ID is publicly accessible (public DNS)? Or, are we assuming that it's not publicly accessible, e.g., that the serving network has a split DNS and these "final translations" are only visible within that network? tim > -----Original Message----- > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Sent: Friday, June 02, 2006 3:58 PM > To: James McEachern; Lee, Yiu; Stastny Richard; > speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up > the request URI? > > That is correct. The SIP URI that clearly identifies you, as > you described, would only be used within your provider's network. > > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Friday, June 02, 2006 16:52 > > To: Creighton, Tom; Lee, Yiu; Stastny Richard; speermint@ietf.org; > > enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > Ok, I think I see now. Presumably I can have a SIP URI > that clearly > > identifies me, but this is not the AOR that would be populated in > > Infrastructure ENUM. That AOR would either be based on my E.164 > number, > > or on some other random string created by the carrier. > Have I got it > > right? > > > > James > > > > -----Original Message----- > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Sent: Friday, June 02, 2006 3:49 PM > > To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; > > speermint@ietf.org; enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > I think we have two separate issues: > > > > 1. An issue of misunderstanding of the term AoR. Section 6 > of RFC3261 > > defines an Address-of-Record as: > > > > "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI > > that points to a domain with a location service > that can map > > the URI to another URI where the user might be available. > > Typically, the location service is populated through > > registrations. An AOR is frequently thought of as the > "public > > address" of the user." > > > > Based on that definition and the examples provided by Richard, a > user's > > privacy would not be compromised because it doesn't > directly reach or > > identify the customer. > > > > 2. There is confusion around what is or is not acceptable > in the host > > portion of a SIP URI. As long as RFC3263 is followed, it shouldn't > > matter what is placed in the host portion of the SIP URI as > long as it > > doesn't compromise a user's privacy. So in the examples Richard > > provided earlier, either are acceptable and would resolve in an > > identical manner. > > > > Tom > > > > > -----Original Message----- > > > From: James McEachern [mailto:jmce@nortel.com] > > > Sent: Friday, June 02, 2006 15:12 > > > To: Lee, Yiu; Stastny Richard; Creighton, Tom; > speermint@ietf.org; > > > enum@ietf.org > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > In the past it has been suggested that if Infrastructure ENUM is > > openly > > > accessible, then for data privacy reasons it would not be > acceptable > > to > > > list the user AOR. Do we still believe this is the case, or do we > now > > > think providing the user AOR would be acceptable? > > > > > > James > > > > > > -----Original Message----- > > > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > > Sent: Thursday, June 01, 2006 2:22 PM > > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > Actually, I think it is sufficient for the Enum to return the user > AOR > > > because the routing decision should happen in the > provB.net network. > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 2:18 PM > > > To: Lee, Yiu; Creighton, Tom; speermint@ietf.org > > > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > Ok, so I am back to my original question: > > > > > > if I implement both types of public user identities: > > > E.164 numbers and SIP AoRs, why doing the mapping to different > hosting > > > proxies in two places (in this case ENUM and the HSS), if I can do > it > > > only in one place? > > > > > > -sta > > > > > > > > > > > > ________________________________ > > > > > > Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > > Gesendet: Do 01.06.2006 20:10 > > > An: Stastny Richard; Creighton, Tom; speermint@ietf.org > > > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > > > > > > > Yes. IMS is using Option 2. Option 1 is also possible if the > operator > > > decides to use just a redirect proxy. > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 2:07 PM > > > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > so basically the IMS I-CSCF - HSS - S-CSCF way? > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Gesendet: Do 01.06.2006 19:45 > > > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > > > > > > > Agreed, in this case the proxy associated with provB.net > would be an > > > intermediate device that would have to perform some sort > of internal > > > lookup in order to route the request to the next hop. > > > > > > > -----Original Message----- > > > > From: Lee, Yiu > > > > Sent: Thursday, June 01, 2006 13:34 > > > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > > request > > > > URI? > > > > > > > > In this case, I guess when the originating proxy resolves the > domain > > > part > > > > of the AOR (sip:+4319793321@provB.net), it will return the IP > > address > > > of > > > > the root domain "provB.net" which may be a redirect proxy. So > > > "provB.net" > > > > has two choices: > > > > > > > > (1) It accesses its local routing table and sends a 305 to the > > > originating > > > > proxy with "sbc4711.provB.net" in the contact header. > > > > > > > > (2) It replaces the domain part in the r-uri to more > specific like > > > > "proxy.austria.provB.net" and forward the message to > the next-hop. > > > > > > > > Either case, the assumption is provB.net will have a way to find > out > > > where > > > > the home proxy of user +4319793321. > > > > > > > > This is only my guess. > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 1:13 PM > > > > To: Creighton, Tom; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Speermint] Re: [Enum] How to correctly set up the > request > > > URI? > > > > > > > > I see, > > > > > > > > but how do you solve this problem if the users can also > be reached > > by > > > AoRs > > > > direct? > > > > > > > > -sta > > > > > > > > ________________________________ > > > > > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > Gesendet: Do 01.06.2006 17:57 > > > > An: Stastny Richard; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > Maybe the service provider has some sort of segregated network > > > (physically > > > > or logically) and wants/needs to associate each its subscribers > with > > a > > > > > > > particular network segment. If the provider went with the flat > > model > > > of > > > > provB.net, each of its proxies would have to accept requests > > destined > > > to > > > > all of its customers and would then have to route the request to > the > > > > appropriate region or division of its network. > > > > If the provider went with the hierarchical approach of > > > sbc4711.provB.net, > > > > all of the requests would already be routed to the appropriate > > ingress > > > > > > > point. This could very well save a service provider a lot of > money > > in > > > > > > > route proxy equipment although might cost more on the > provisioning > > > side. > > > > > > > > That is my guess. > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, June 01, 2006 11:30 > > > > > To: Creighton, Tom; speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > Thank you, Tom > > > > > > > > > > just a minor additional question: > > > > > > > > > > > In either case, after the provider A proxy performs an ENUM > > query > > > > and > > > > > > rewrites the request URI, it should behave as a UAC > and follow > > the > > > > > > > > > procedures outlined in Section 4 of RFC3263 to determine the > IP > > > > > address, > > > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > > > sbc4711.provB.net into ENUM in the first place? > > > > > > > > > > -sta > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Creighton, Tom > [mailto:Tom_Creighton@cable.comcast.com] > > > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > > > To: Stastny Richard; speermint@ietf.org > > > > > > Cc: enum@ietf.org > > > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > > > To: speermint@ietf.org > > > > > > > Cc: enum@ietf.org > > > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > Folks, > > > > > > > > > > > > > > Question for clarification: > > > > > > > > > > > > > > In the discussions here on how to populate sip URI in > > > > Infrastructure > > > > > > > ENUM to derive the Call Routing data for SPEERMINT two > lines > > of > > > > > > > > > > thought exist: > > > > > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should > contain 1. > > the > > > > > > > > > > address-of-record of the user: e.g. > > > > sip:+4319793321@provB.net > > > > > > > 2. the ingress point into the provider network: > > > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > > > sip:+4319793321provA.net;user=phone. This caused the ENUM > > query > > > at > > > > > > > the proxy of provider A > > > > > > > > > > > > > > The question is how the proxy of provider A is now setting > up > > > the > > > > > > > request URI in cases mentioned above? > > > > > > > > > > > > > > Does the UAS from provider B accept calls to > > sbc7411.provB.net, > > > or > > > > > > > must the request URI set to the proper AoR as described in > > > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in > > ENUM. > > > > > > > > > > > > [Tom Creighton wrote:] > > > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does > not > > > > > > identify an address that the UAS is willing to > accept requests > > > for, > > > > it > > > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > > > > > As long as the UAS from provider B is "willing" to > accept the > > > > request, > > > > > > either should work. Since provider B is populating > > Infrastructure > > > > > ENUM, > > > > > > one would hope that they would coordinate this data > with the > > > > > > configuration of their proxies. > > > > > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > > > actually > > > > a > > > > > > hostname and isn't a subdomain? > > > > > > > > > > > > In either case, after the provider A proxy performs an ENUM > > query > > > > and > > > > > > rewrites the request URI, it should behave as a UAC > and follow > > the > > > > > > > > > procedures outlined in Section 4 of RFC3263 to determine the > IP > > > > > address, > > > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in > ENUM. > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > -sta > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > enum mailing list > > > > > > > enum@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > 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 Jun 03 10:16:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmWvr-00061e-6e; Sat, 03 Jun 2006 10:16:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmWvp-0005zz-Ov; Sat, 03 Jun 2006 10:16:49 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmWvo-0006cn-FK; Sat, 03 Jun 2006 10:16: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] Re: [Enum] How to correctly set up the request URI? Date: Sat, 3 Jun 2006 16:20:54 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AAC@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAAA6/FAAIbZ38AAB+7kx From: "Stastny Richard" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5df1f98f3253c63b673ea560243aa58f 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 this discussion is getting a bit confused in terminology My I try to get this back in track from my knowledge: =20 The terms Public User ID and Private User ID are from 3GPP = specifications A Public User ID is defined as an ID somebody may put on his business = card: Examples are: a) tel:+4319793321 (a E.164 number) b) sip:+4319793321@provider.com (an E.164 number and an = address-of-record) c) sip:richard.stastny@provider.com (also an AoR) d) sip:richard@stastny.com =20 All of these could be aliases linked to one Private User Identity The private user identity is defined in 3GPP as a realm, used for = registration e.g. in the format richard.stastny @ provider.com To be compatible with existing 2G systems, it could also be derived from the IMSI with a predefined algorithm. Private User Identities are our of scope in Speermint (I think) a) cannot be user fro routing between SIP based networks, so it must be = translated to a SIP AoR. This can be done with ENUM. As we also stated here, not to = disclose and privacy, it should be in format b) This mapping is publicly visible in Infrastructure ENUM But this does not preclude me to put sip:richard.stastny@provider.com or sip:richard@stastny.com on my business card, so it will be used outside the providers network. The routing of sip:richard.stastny@provider.com is straightforward, for the mapping of the stastny.com part sip:richard@stastny.com to provider.com an entry (e.g. a NAPTR as Otmar described) is necessary in the stastny.com domain to get the call proverly routed to my network. The mapping of the user part "richard" to "richard.stastny" or +4319793321 takes place in the providers network and is not visible outside I hope this helps to clarify -sta ________________________________ Von: Tim Dwight [mailto:timothy.dwight@verizon.com] Gesendet: Sa 03.06.2006 15:11 An: 'Creighton, Tom'; 'James McEachern'; 'Lee, Yiu'; Stastny Richard; = speermint@ietf.org; enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? What good does this globally-visible public-user-ID to private-user-ID visible only within the serving network scheme do, if the means of translating globally-visible public user ID to private user ID is = publicly accessible (public DNS)? Or, are we assuming that it's not publicly accessible, e.g., that the serving network has a split DNS and these = "final translations" are only visible within that network? tim > -----Original Message----- > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Sent: Friday, June 02, 2006 3:58 PM > To: James McEachern; Lee, Yiu; Stastny Richard; > speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up > the request URI? > > That is correct. The SIP URI that clearly identifies you, as > you described, would only be used within your provider's network. > > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Friday, June 02, 2006 16:52 > > To: Creighton, Tom; Lee, Yiu; Stastny Richard; speermint@ietf.org; > > enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > Ok, I think I see now. Presumably I can have a SIP URI > that clearly > > identifies me, but this is not the AOR that would be populated in > > Infrastructure ENUM. That AOR would either be based on my E.164 > number, > > or on some other random string created by the carrier.=20 > Have I got it > > right? > > > > James > > > > -----Original Message----- > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Sent: Friday, June 02, 2006 3:49 PM > > To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; > > speermint@ietf.org; enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > I think we have two separate issues: > > > > 1. An issue of misunderstanding of the term AoR. Section 6 > of RFC3261 > > defines an Address-of-Record as: > > > > "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI > > that points to a domain with a location service > that can map > > the URI to another URI where the user might be available. > > Typically, the location service is populated through > > registrations. An AOR is frequently thought of as the > "public > > address" of the user." > > > > Based on that definition and the examples provided by Richard, a > user's > > privacy would not be compromised because it doesn't > directly reach or > > identify the customer. > > > > 2. There is confusion around what is or is not acceptable > in the host > > portion of a SIP URI. As long as RFC3263 is followed, it shouldn't > > matter what is placed in the host portion of the SIP URI as > long as it > > doesn't compromise a user's privacy. So in the examples Richard > > provided earlier, either are acceptable and would resolve in an > > identical manner. > > > > Tom > > > > > -----Original Message----- > > > From: James McEachern [mailto:jmce@nortel.com] > > > Sent: Friday, June 02, 2006 15:12 > > > To: Lee, Yiu; Stastny Richard; Creighton, Tom; > speermint@ietf.org; > > > enum@ietf.org > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > In the past it has been suggested that if Infrastructure ENUM is > > openly > > > accessible, then for data privacy reasons it would not be > acceptable > > to > > > list the user AOR. Do we still believe this is the case, or do we > now > > > think providing the user AOR would be acceptable? > > > > > > James > > > > > > -----Original Message----- > > > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > > Sent: Thursday, June 01, 2006 2:22 PM > > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > Actually, I think it is sufficient for the Enum to return the user > AOR > > > because the routing decision should happen in the > provB.net network. > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 2:18 PM > > > To: Lee, Yiu; Creighton, Tom; speermint@ietf.org > > > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > Ok, so I am back to my original question: > > > > > > if I implement both types of public user identities: > > > E.164 numbers and SIP AoRs, why doing the mapping to different > hosting > > > proxies in two places (in this case ENUM and the HSS), if I can do > it > > > only in one place? > > > > > > -sta > > > > > > > > > > > > ________________________________ > > > > > > Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > > Gesendet: Do 01.06.2006 20:10 > > > An: Stastny Richard; Creighton, Tom; speermint@ietf.org > > > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > > > > > > > Yes. IMS is using Option 2. Option 1 is also possible if the > operator > > > decides to use just a redirect proxy. > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 2:07 PM > > > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > so basically the IMS I-CSCF - HSS - S-CSCF way? > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Gesendet: Do 01.06.2006 19:45 > > > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > > > > > > > Agreed, in this case the proxy associated with provB.net > would be an > > > intermediate device that would have to perform some sort > of internal > > > lookup in order to route the request to the next hop. > > > > > > > -----Original Message----- > > > > From: Lee, Yiu > > > > Sent: Thursday, June 01, 2006 13:34 > > > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > > request > > > > URI? > > > > > > > > In this case, I guess when the originating proxy resolves the > domain > > > part > > > > of the AOR (sip:+4319793321@provB.net), it will return the IP > > address > > > of > > > > the root domain "provB.net" which may be a redirect proxy. So > > > "provB.net" > > > > has two choices: > > > > > > > > (1) It accesses its local routing table and sends a 305 to the > > > originating > > > > proxy with "sbc4711.provB.net" in the contact header. > > > > > > > > (2) It replaces the domain part in the r-uri to more > specific like > > > > "proxy.austria.provB.net" and forward the message to > the next-hop. > > > > > > > > Either case, the assumption is provB.net will have a way to find > out > > > where > > > > the home proxy of user +4319793321. > > > > > > > > This is only my guess. > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 1:13 PM > > > > To: Creighton, Tom; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Speermint] Re: [Enum] How to correctly set up the > request > > > URI? > > > > > > > > I see, > > > > > > > > but how do you solve this problem if the users can also > be reached > > by > > > AoRs > > > > direct? > > > > > > > > -sta > > > > > > > > ________________________________ > > > > > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > Gesendet: Do 01.06.2006 17:57 > > > > An: Stastny Richard; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > Maybe the service provider has some sort of segregated network > > > (physically > > > > or logically) and wants/needs to associate each its subscribers > with > > a > > > > > > > particular network segment. If the provider went with the flat > > model > > > of > > > > provB.net, each of its proxies would have to accept requests > > destined > > > to > > > > all of its customers and would then have to route the request to > the > > > > appropriate region or division of its network. > > > > If the provider went with the hierarchical approach of > > > sbc4711.provB.net, > > > > all of the requests would already be routed to the appropriate > > ingress > > > > > > > point. This could very well save a service provider a lot of > money > > in > > > > > > > route proxy equipment although might cost more on the > provisioning > > > side. > > > > > > > > That is my guess. > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, June 01, 2006 11:30 > > > > > To: Creighton, Tom; speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > Thank you, Tom > > > > > > > > > > just a minor additional question: > > > > > > > > > > > In either case, after the provider A proxy performs an ENUM > > query > > > > and > > > > > > rewrites the request URI, it should behave as a UAC > and follow > > the > > > > > > > > > procedures outlined in Section 4 of RFC3263 to determine the > IP > > > > > address, > > > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > > > sbc4711.provB.net into ENUM in the first place? > > > > > > > > > > -sta > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Creighton, Tom > [mailto:Tom_Creighton@cable.comcast.com] > > > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > > > To: Stastny Richard; speermint@ietf.org > > > > > > Cc: enum@ietf.org > > > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > > > To: speermint@ietf.org > > > > > > > Cc: enum@ietf.org > > > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > Folks, > > > > > > > > > > > > > > Question for clarification: > > > > > > > > > > > > > > In the discussions here on how to populate sip URI in > > > > Infrastructure > > > > > > > ENUM to derive the Call Routing data for SPEERMINT two > lines > > of > > > > > > > > > > thought exist: > > > > > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should > contain 1. > > the > > > > > > > > > > address-of-record of the user: e.g. > > > > sip:+4319793321@provB.net > > > > > > > 2. the ingress point into the provider network: > > > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > > > sip:+4319793321provA.net;user=3Dphone. This caused the = ENUM > > query > > > at > > > > > > > the proxy of provider A > > > > > > > > > > > > > > The question is how the proxy of provider A is now setting > up > > > the > > > > > > > request URI in cases mentioned above? > > > > > > > > > > > > > > Does the UAS from provider B accept calls to > > sbc7411.provB.net, > > > or > > > > > > > must the request URI set to the proper AoR as described in > > > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in > > ENUM. > > > > > > > > > > > > [Tom Creighton wrote:] > > > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does > not > > > > > > identify an address that the UAS is willing to > accept requests > > > for, > > > > it > > > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > > > > > As long as the UAS from provider B is "willing" to > accept the > > > > request, > > > > > > either should work. Since provider B is populating > > Infrastructure > > > > > ENUM, > > > > > > one would hope that they would coordinate this data > with the > > > > > > configuration of their proxies. > > > > > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > > > actually > > > > a > > > > > > hostname and isn't a subdomain? > > > > > > > > > > > > In either case, after the provider A proxy performs an ENUM > > query > > > > and > > > > > > rewrites the request URI, it should behave as a UAC > and follow > > the > > > > > > > > > procedures outlined in Section 4 of RFC3263 to determine the > IP > > > > > address, > > > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in > ENUM. > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > -sta > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > enum mailing list > > > > > > > enum@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > 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 Jun 03 10:42:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmXKm-0005s5-ST; Sat, 03 Jun 2006 10:42:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmXKl-0005rx-7W; Sat, 03 Jun 2006 10:42:35 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmXKj-0008Sa-Qi; Sat, 03 Jun 2006 10:42:35 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k53Eguib004110; Sat, 3 Jun 2006 07:42:56 -0700 From: "Richard Shockey" To: "'Tony Rutkowski'" , "'Stastny Richard'" , "'Pfautz, Penn L, GBLAM'" , "'James McEachern'" , , Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Sat, 3 Jun 2006 10:42:25 -0400 Message-ID: <011001c6871b$ef013ba0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <7.0.1.0.2.20060602175232.033dc4e0@verisign.com> Thread-Index: AcaGkMhEXSK7WvlTRXSIW8VVxl/TawAigIiA 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: 082a9cbf4d599f360ac7f815372a6a15 Cc: 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 Well Tony we continue to agree on some things after all .. You point is well taken. ENUM IS more than a flexible routing table. Its value is in the ability to authenticate and maintain authoritative bindings for E164 to URI bindings. How those bindings are used may or may not involve the use of DNS technology. Consequently the critical issue is the TRUST created by and maintained by the authoritative Registry of those bindings and that Registry MAY and in all likelihood MUST maintain some mechanism for the maintenance of information about providers and users. Which is why we did the work on IRIS in the ENUM WG. BTW Which EU directive you mention IYHO will require the maintenance of a pin trap of ENUM queries? > -----Original Message----- > From: Tony Rutkowski [mailto:trutkowski@verisign.com] > Sent: Friday, June 02, 2006 6:06 PM > To: Stastny Richard; Pfautz, Penn L, GBLAM; James McEachern; > speermint@ietf.org; enum@ietf.org > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > Hi Richard, > > >I do not fully understand what the CALEA issue has to do with the > >question which > >URI is put in ENUM. > > ENUM is little more than a more flexible routing table > - a more dynamic LERG. Stable public infrastructures > - for network integrity, law enforcement support, and > a host of other requirements - require some ability > to authenticate changes and maintain authoritative > bindings to provider/user information. Austrian > police cannot do lawful interceptions if they can't > trust the E.164 to URI bindings and do queries to > get authoritative information about providers and > users. > > >I have complete different concerns regarding CALEA, in principle I do > >not understand why the service providers are bothered with this at all, > > European authorities will be much better supported > under the EU Data Retention Directive - which will > require capturing and timestamping every signalling > query. > > --tony > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat Jun 03 10:47:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmXPx-0006tn-WE; Sat, 03 Jun 2006 10:47:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmXPx-0006tf-0a; Sat, 03 Jun 2006 10:47:57 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmXPv-0000Da-Jn; Sat, 03 Jun 2006 10:47:56 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k53EmA45004889; Sat, 3 Jun 2006 07:48:11 -0700 From: "Richard Shockey" To: "'Pfautz, Penn L, GBLAM'" , "'James McEachern'" , "'Creighton, Tom'" , "'Lee, Yiu'" , "'Stastny Richard'" , , Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Sat, 3 Jun 2006 10:47:39 -0400 Message-ID: <011201c6871c$ab36fee0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0CEFF8DE@ACCLUST02EVS1.ugd.att.com> Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAABBo3AAJXTKwA== 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 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: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > Sent: Friday, June 02, 2006 4:56 PM > To: James McEachern; Creighton, Tom; Lee, Yiu; Stastny Richard; > speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > Yes. Again, there might be exceptions, for example a business might want > a URI with their name to be used and some SPs might agree to that, but > generally the point of infrastructure ENUM is to be invisible to the > user > Now the 64B question is the "infrastructure" URI invisible to the global DNS? > _______________________________________________ > 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 Jun 05 11:15:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnGnk-00074u-L3; Mon, 05 Jun 2006 11:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnGnj-00074m-Iw; Mon, 05 Jun 2006 11:15:31 -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 1FnGni-0000dr-7Y; Mon, 05 Jun 2006 11:15:31 -0400 Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.20825811; Mon, 05 Jun 2006 11:15:15 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 11:15:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Mon, 5 Jun 2006 11:15:14 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D9670574F@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAABBo3AAJXTKwABkv/xg From: "Creighton, Tom" To: , "Pfautz, Penn L, GBLAM" , "James McEachern" , "Lee, Yiu" , "Stastny Richard" , , X-OriginalArrivalTime: 05 Jun 2006 15:15:15.0436 (UTC) FILETIME=[D9170AC0:01C688B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Who has the authority to make that decision? Is it the ITU, IETF, a combination of the two, or each country that opts to participate in Infrastructure ENUM? I think that is the 64B question. > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Saturday, June 03, 2006 10:48 > To: 'Pfautz, Penn L, GBLAM'; 'James McEachern'; Creighton, Tom; Lee, Yiu; > 'Stastny Richard'; speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > > -----Original Message----- > > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > > Sent: Friday, June 02, 2006 4:56 PM > > To: James McEachern; Creighton, Tom; Lee, Yiu; Stastny Richard; > > speermint@ietf.org; enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > > URI? > > > > Yes. Again, there might be exceptions, for example a business might want > > a URI with their name to be used and some SPs might agree to that, but > > generally the point of infrastructure ENUM is to be invisible to the > > user > > >=20 >=20 > Now the 64B question is the "infrastructure" URI invisible to the global > DNS? >=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 Mon Jun 05 11:44:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHG2-00050A-CX; Mon, 05 Jun 2006 11:44:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHG1-0004zr-4h; Mon, 05 Jun 2006 11:44:45 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnHFz-0004q6-M2; Mon, 05 Jun 2006 11:44: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 Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Mon, 5 Jun 2006 17:48:50 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AB4@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAABBo3AAJXTKwABkv/xgAAHQbNg= From: "Stastny Richard" To: "Creighton, Tom" , , "Pfautz, Penn L, GBLAM" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 >> > Yes. Again, there might be exceptions, for example a business might = want >> > a URI with their name to be used and some SPs might agree to that, = but >> > generally the point of infrastructure ENUM is to be invisible to = the >> > user >> > >> Now the 64B question is the "infrastructure" URI invisible to the = global >> DNS? >Who has the authority to make that decision? Is it the ITU, IETF, a >combination of the two, or each country that opts to participate in >Infrastructure ENUM? I think that is the 64B question ? I am confused Could anybody please explain to me what you are talking about I cannot parse this thread What is the "point of Infrastructure ENUM"? What is an "Infrastructure URI" and why should it be invisible? And what has this to do with an enterprise specific URI? -sta ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Mo 05.06.2006 17:15 An: richard@shockey.us; Pfautz, Penn L, GBLAM; James McEachern; Lee, = Yiu; Stastny Richard; speermint@ietf.org; enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? Who has the authority to make that decision? Is it the ITU, IETF, a combination of the two, or each country that opts to participate in Infrastructure ENUM? I think that is the 64B question. > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Saturday, June 03, 2006 10:48 > To: 'Pfautz, Penn L, GBLAM'; 'James McEachern'; Creighton, Tom; Lee, Yiu; > 'Stastny Richard'; speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > > -----Original Message----- > > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > > Sent: Friday, June 02, 2006 4:56 PM > > To: James McEachern; Creighton, Tom; Lee, Yiu; Stastny Richard; > > speermint@ietf.org; enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > > URI? > > > > Yes. Again, there might be exceptions, for example a business might want > > a URI with their name to be used and some SPs might agree to that, but > > generally the point of infrastructure ENUM is to be invisible to the > > user > > > > > Now the 64B question is the "infrastructure" URI invisible to the global > DNS? > > > > _______________________________________________ > > 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 Jun 05 11:57:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHSF-0001NZ-9j; Mon, 05 Jun 2006 11:57:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHSE-0001NR-Am; Mon, 05 Jun 2006 11:57:22 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnHSC-0005hr-WF; Mon, 05 Jun 2006 11:57:22 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-15.tower-121.messagelabs.com!1149522994!6609210!29 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 6114 invoked from network); 5 Jun 2006 15:57:20 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-15.tower-121.messagelabs.com with SMTP; 5 Jun 2006 15:57:20 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 44708FE9001FAB5A; Mon, 5 Jun 2006 11:57: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] Re: [Enum] How to correctly set up the request URI? Date: Mon, 5 Jun 2006 11:57:18 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0CF41506@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4AB4@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAABBo3AAJXTKwABkv/xgAAHQbNgAACAcMA== From: "Pfautz, Penn L, GBLAM" To: "Stastny Richard" , "Creighton, Tom" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 My original statement about invisibility was that the end user doesn't need to specify/know the URI that the SP provides in infrastructure ENUM - or even that infrastructure ENUM even exists at all. The issue seems to have evolved to that of how much of the infrastructure ENUM tree and its products will be openly visible. This is a decision that many parties may have some level of input to. National regulators may well be able to veto public visibility if they so choose. Service providers may wish to control resolution to some degree although making the infrastructure ENUM Tier 1 inaccessible would not seem to be something the IETF would want to do other things being equal. Penn -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Monday, June 05, 2006 11:49 AM To: Creighton, Tom; richard@shockey.us; Pfautz, Penn L, GBLAM; speermint@ietf.org; enum@ietf.org Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? >> > Yes. Again, there might be exceptions, for example a business might want >> > a URI with their name to be used and some SPs might agree to that, but >> > generally the point of infrastructure ENUM is to be invisible to the >> > user >> > >> Now the 64B question is the "infrastructure" URI invisible to the global >> DNS? >Who has the authority to make that decision? Is it the ITU, IETF, a >combination of the two, or each country that opts to participate in >Infrastructure ENUM? I think that is the 64B question ? I am confused Could anybody please explain to me what you are talking about I cannot parse this thread What is the "point of Infrastructure ENUM"? What is an "Infrastructure URI" and why should it be invisible? And what has this to do with an enterprise specific URI? -sta ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Mo 05.06.2006 17:15 An: richard@shockey.us; Pfautz, Penn L, GBLAM; James McEachern; Lee, Yiu; Stastny Richard; speermint@ietf.org; enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Who has the authority to make that decision? Is it the ITU, IETF, a combination of the two, or each country that opts to participate in Infrastructure ENUM? I think that is the 64B question. > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Saturday, June 03, 2006 10:48 > To: 'Pfautz, Penn L, GBLAM'; 'James McEachern'; Creighton, Tom; Lee, Yiu; > 'Stastny Richard'; speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > > -----Original Message----- > > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > > Sent: Friday, June 02, 2006 4:56 PM > > To: James McEachern; Creighton, Tom; Lee, Yiu; Stastny Richard; > > speermint@ietf.org; enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > > URI? > > > > Yes. Again, there might be exceptions, for example a business might want > > a URI with their name to be used and some SPs might agree to that, but > > generally the point of infrastructure ENUM is to be invisible to the > > user > > > > > Now the 64B question is the "infrastructure" URI invisible to the global > DNS? > > > > _______________________________________________ > > 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 Jun 05 12:13:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHhd-0001DY-WA; Mon, 05 Jun 2006 12:13:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHhc-0001D8-4u; Mon, 05 Jun 2006 12:13:16 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnHhb-0007vA-Gd; Mon, 05 Jun 2006 12:13:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Mon, 5 Jun 2006 18:17:22 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AB5@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAABBo3AAJXTKwABkv/xgAAHQbNgAACAcMAAAxI86 From: "Stastny Richard" To: "Pfautz, Penn L, GBLAM" , "Creighton, Tom" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c 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 >My original statement about invisibility was that the end user doesn't >need to specify/know the URI that the SP provides in infrastructure = ENUM >- or even that infrastructure ENUM even exists at all. ok=20 >The issue seems to have evolved to that of how much of the >infrastructure ENUM tree and its products will be openly visible. This >is a decision that many parties may have some level of input to. >National regulators may well be able to veto public visibility if they >so choose.=20 I agree that national regulators may have some saying on what kind of URIs should be placed in Infastructure ENUM (e.g. none that jeopardizes the end-user privacy), but I do not see why the regulators do not want to have the Infrastructure ENUM data not public at all. =20 I already said that a security and privacy section is missing in draft-ietf-enum-infrastructure The Infrastructure ENUM data is basically providing a E.164 to SPID=20 mapping, and part of this is available on every regulators web-site (the block assignment). What is not is the numbers ported out of this blocks and this seems more to be a concern of the providers and not of the regulators. The problem here is that this information hiding is more to other providers and not to the public. But then a non public Infrastructure ENUM does not help either ;-) =20 -sta =20 >Service providers may wish to control resolution to some >degree although making the infrastructure ENUM Tier 1 inaccessible = would >not seem to be something the IETF would want to do other things being >equal. Penn -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Monday, June 05, 2006 11:49 AM To: Creighton, Tom; richard@shockey.us; Pfautz, Penn L, GBLAM; speermint@ietf.org; enum@ietf.org Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? >> > Yes. Again, there might be exceptions, for example a business might want >> > a URI with their name to be used and some SPs might agree to that, but >> > generally the point of infrastructure ENUM is to be invisible to the >> > user >> > >> Now the 64B question is the "infrastructure" URI invisible to the global >> DNS? >Who has the authority to make that decision? Is it the ITU, IETF, a >combination of the two, or each country that opts to participate in >Infrastructure ENUM? I think that is the 64B question ? I am confused Could anybody please explain to me what you are talking about I cannot parse this thread What is the "point of Infrastructure ENUM"? What is an "Infrastructure URI" and why should it be invisible? And what has this to do with an enterprise specific URI? -sta ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Mo 05.06.2006 17:15 An: richard@shockey.us; Pfautz, Penn L, GBLAM; James McEachern; Lee, Yiu; Stastny Richard; speermint@ietf.org; enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Who has the authority to make that decision? Is it the ITU, IETF, a combination of the two, or each country that opts to participate in Infrastructure ENUM? I think that is the 64B question. > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Saturday, June 03, 2006 10:48 > To: 'Pfautz, Penn L, GBLAM'; 'James McEachern'; Creighton, Tom; Lee, Yiu; > 'Stastny Richard'; speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > > -----Original Message----- > > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > > Sent: Friday, June 02, 2006 4:56 PM > > To: James McEachern; Creighton, Tom; Lee, Yiu; Stastny Richard; > > speermint@ietf.org; enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > > URI? > > > > Yes. Again, there might be exceptions, for example a business might want > > a URI with their name to be used and some SPs might agree to that, but > > generally the point of infrastructure ENUM is to be invisible to the > > user > > > > > Now the 64B question is the "infrastructure" URI invisible to the global > DNS? > > > > _______________________________________________ > > 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 Jun 06 10:51:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnctW-0007Ye-5c; Tue, 06 Jun 2006 10:50:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnctV-0007YZ-KB for speermint@ietf.org; Tue, 06 Jun 2006 10:50:57 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnctU-0007sU-Ti for speermint@ietf.org; Tue, 06 Jun 2006 10:50:57 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 06 Jun 2006 07:50:54 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208"; a="1820213175:sNHT3378535810" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k56EosgI013828; Tue, 6 Jun 2006 07:50:54 -0700 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 k56EorIs016742; Tue, 6 Jun 2006 10:50:54 -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, 6 Jun 2006 10:50: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] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 6 Jun 2006 10:50:52 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3018B70FB@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIB/RgscA== From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Reinaldo Penno" , "Otmar Lendl" X-OriginalArrivalTime: 06 Jun 2006 14:50:53.0320 (UTC) FILETIME=[9C039880:01C68978] DKIM-Signature: a=rsa-sha1; q=dns; l=11906; t=1149605454; x=1150469454; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Updated=20Draft=3A=20SPEERMINT=20Peering=20Archite cture; X=v=3Dcisco.com=3B=20h=3DLBvaC29k4XreapJV/To4qKVFzC8=3D; b=C/5uSWgnm+4Ztpa4iT/66q/tww7HVwM2RND/wt/gTh0xbDHzhfTuo05pWTtpTCChMmt2H1GI t3AJ5fkXoca44Y5SfN4z55paXcTPHO/PnVtVVHR3xUIvu0ZDI1QZPIXz; Authentication-Results: sj-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 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 All, I am back from vacation and find a very long and interesting thread. I was trying to hold off responding till I read all 130+ messages but am finding it difficult to remember and resist, so pardon me if I restate something here. First, the goal is to reach domains, so the routing to E.164 numbers should be out of scope -- no reinventing TRIP. We turn E.164 into sip addresses and then route on the domains. >From the domain we should be able to look up direct signaling points or indirectly policy points. In some cases, we may find federation information, then need to think about how to route to that federation. I think the discussion about number of domains and BGP-like stuff is barking up the wrong tree. Oh, BTW there are about 3000 carriers in the USA alone and roughly 8000 public enterprises (publicly traded stock) in the USA. But, I think that misses the point. I believe the reality will be that there will ultimately be two options: - from one SP (carrier/enterprise) to another there is direct peering, - from one SP to another there is no direct peering and a "Tier 1" SP will be used for transit. There will be some rather large SPs (think ATT, Sprint, name you favorite PTT) that will be all too willing to be the transit carrier and solve the bridging problem, and many enterprises or individuals will be all too willing to let them do that. The federations may thus be a means of aggregating the sip routing problem and making it scalable. The federation then becomes a default route for the Tier 2 SP. I suspect that the sequence will look something like: E.164 -> sip:E.164@termination-SP.com - at this point the originating SP can determine if it has a peering throug internal means, - if not: termination-SP.com -> terminating-federation.com - at this point the originating SP can determine if it belongs to that same federation, - if not, the end result will be: Request-URI: sip:E.164@termination-SP.com -- points to target SP Route: originating-federation.com -- points to near side if not common federation Route: terminating-federation.com -- points to far side federation originating-federation -> translates to my transit SP. I may have abused the federation concept a bit, given that there is both the qualitative aspect of having a common agreement on how to interconnect, and the routing aspect which anticipates that a federation may be formed around a large SP that has the IP network to connect to all the SPs that sign up for that "federation". I'll confess that there is some legacy precedent here. But, that may be the most viable short term evolution path. My thinking, if it is not obvious is that the optimal number of SPs is 2 (direct peering). Second best is 3 (one transit). =20 Maximum number is 4 (one originating and one terminating transit). =20 I believe that hopping across 10 SIP signaling networks would be a sure sign that our work here has failed, and that is what I fear the BGP discussion would lead us to. Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Saturday, May 27, 2006 7:26 AM > To: Reinaldo Penno; Otmar Lendl > Cc: speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > >I wonder how > >LNP is solved within wireless...A specific entry for each=20 > phone? That=20 > >would be crazy. >=20 > Ahem, ENUM? >=20 > I thought that is all what ENUM is about? >=20 > Richard >=20 >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Sa 27.05.2006 11:04 > An: Otmar Lendl; Patrick Melampy > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 >=20 > Hello, >=20 > I believe the crux of the problem was missed. >=20 > The issue is not really the number of domains. We have today=20 > some 400.000.000 million hosts on the Internet. BGP peers to=20 > do not exchange 400.000.000 million routes, they exchange in=20 > the low hundreds of thousands. >=20 > And why is that? (I guess you know where I'm getting at).=20 > That's because IP addresses lend themselves very well to=20 > hierarchical deployment, compression through prefix/CIDR=20 > usage and the like. DNS names are strings and hence difficult=20 > to come up with a similar scheme. >=20 >=20 > I believe that if domains need to be exchanged between peers: >=20 > 1 - Just a limited set would be exchanged and a "default=20 > layer 5 route" > (equivalent to a traditional default route) would be used. >=20 > 2 - Compression schemes like *.company.com, regular=20 > expressions or the like would need to be used. Having=20 > specific routes to AORs would be hairy (maybe for the=20 > eventual roaming or visiting user). I wonder how LNP is=20 > solved within wireless...A specific entry for each phone?=20 > That would be crazy. >=20 > 3 - Some new scheme that will make somebody rich....until then.. >=20 > I believe subscriptions would be used to exchange mostly=20 > "cost" and policy information and some domains. I use cost=20 > here in the layer 3 sense (number of calls, jitter,=20 > whatever). Cost would be an abstract value or a more specific=20 > one (up to the administrator). >=20 > Regards, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at] > > Sent: Saturday, May 27, 2006 1:29 AM > > To: Patrick Melampy > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering=20 > Architecture > > > > On 2006/05/26 18:05, Patrick Melampy=20 > wrote: > > > I suppose like in any distributed routing protocol, there are some > > chicken > > > an egg issues. But consider the following. > > > > > > PREREQUISITES: > > > 1.) You know the destination DOMAIN from either ENUM or=20 > other means. > > > > [...] > > > > > > This technique is very similar to TRIP, only its for=20 > DOMAINS and not > > partial > > > E.164 numbers. > > > > [...] > > > > > Obviously, the data set could get large, as the list of=20 > domains can > be > > > really big. There are some possibilities here... > > > > Let's do a quick estimate on the number of domains involved: > > > > Right now, operators usually give customers URIs of the form=20 > > @. As long as this is the state of affairs,=20 > > we're fine as the number of providers is quite finite (a few=20 > > thousands, perhaps). > > > > This is like the state of affairs with respect to email, anno 1990. > > Back then customers started to notice that if they use their own > domain > > for email, then they can switch providers without having to change=20 > > their email address. Thus a *lot* of people opted to use their own=20 > > domain for email. > > > > My guess is that the same will happen to SIP. Once customers print=20 > > their SIP uris on business cards, they will want to use their own=20 > > domains. If providers won't support that feature then I=20 > suspect that=20 > > the regulators will step in and mandate an URI portability solution=20 > > just as they did in the PSTN with respect to numbers from number > blocks. > > (This could get really nasty protocol-wise, so I guess=20 > using customer-=20 > > owned domains is the far better and likelier solution to the porting > > question.) > > > > So: Anything we come up with here in SPEERMINT needs to cope with a=20 > > scenario where the use of customer domains in SIP URIs is just as=20 > > widespread as it is for email. > > > > How many domains are used for email? That's hard to say. There are=20 > > about 60 million gTLD domains and probably more than 20 ccTLD ones. > > Assuming that only a tenth of that is used for email we're at > > 8 million domains. Given the exponential growth any system which=20 > > doesn't scale to at least 10 million domains will be=20 > obsolete before=20 > > the ink is dry on the RFC. > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > Let's say we need at least 100 bytes of state information=20 > per domain. > > That makes a full routing table 1 GB worth of data. That also means=20 > > that a new border element needs to exchange that amount of=20 > data with=20 > > its peers before it has learned the current state of the routing=20 > > table. > > > > That is some serious amount of data. > > > > > 1.) Have notification point to a published document, and the > document > > lists > > > all of the relevant reachability in real time. Thus any change to > the > > > document would generate a NOTIFICATION. > > > > + a download of up to 1 GB per peer. > > > > > 2.) User partial domains, broken up by the "dots". This may allow > some > > > wildcarding to reduce the number of domains. For=20 > instance, a carrier > > like > > > Verizon may have many 100's of domains attached to it, and version > is > > > willing to route and manage SIP traffic to any of them. The NOTIFY > could > > > contain something like: Verizon.com or *.verizon.com to indicate > that > > any > > > domain in Verizon is reachable. > > > > That's helpful if a provider uses subdomains for internal purposes,=20 > > but that won't help you with customer owned domains. > > > > > This technique may work -- and fit nicely into an=20 > existing protocol. > All > > we > > > would need to do is define the data models (XML?) and or documents > for > > > exchanging. > > > > I think this technique can work -- if you add an aggregation step=20 > > before the routing scheme. > > > > Take another look at BGP: there you have the concept of an=20 > Autonomous=20 > > System and not only that of prefixes. Maybe you need something=20 > > similar. > > > > One approach to cope with hosted SIP domains could be to use the=20 > > hostnames as found in SRV records. E.g. for settings like > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > run the routing algorithm on "sip.provider.com" instead of=20 > > "customer.domain". > > > > Another option is to store some AS-equivalent in the=20 > customer domain=20 > > and have the routing algorithm operate on that. In my domain-policy=20 > > framework this could be expressed e.g. like > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > stating that this domain can be reached using the Speermint routing=20 > > logic by using the learned route to RoutingID 1042. > > > > Or, even better, use non-terminals, and thus refer to the ingress=20 > > policy stored in the provider's domain: > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > (+ whatever other facts provider.com wants to announce about his > > reachability.) > > > > This combination of our ideas can indeed work and scale to an=20 > > unlimited number of customer-owned domains. > > > > /ol > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > _______________________________________________ > > 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 Wed Jun 07 10:35:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnz86-0002Ei-4g; Wed, 07 Jun 2006 10:35:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnz84-0002Ea-MF for speermint@ietf.org; Wed, 07 Jun 2006 10:35:28 -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 1Fnz84-0000Mn-2Z for speermint@ietf.org; Wed, 07 Jun 2006 10:35:28 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id AED3838F6; Wed, 7 Jun 2006 10:35: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, 7 Jun 2006 10:35: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] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 7 Jun 2006 10:35:23 -0400 Message-ID: In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3018B70FB@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIB/RgscAAw2qLA From: "Uzelac, Adam" To: "Michael Hammer (mhammer)" , "Stastny Richard" , "Reinaldo Penno" , "Otmar Lendl" X-OriginalArrivalTime: 07 Jun 2006 14:35:25.0487 (UTC) FILETIME=[9D6543F0:01C68A3F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b 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 Mike - I agree with what you are saying here, or more importantly how I am reading what you are saying. Some points below: -It's important to avoid the "hopping across 10 SIP signaling networks" scenario. AGREED. -I think it's important to state and acknowledge that we aren't going to ever see one big globally pertinent "CRD database" in the sky that is mutually owned and shared. Hence the value of "routing to a Federation" instead of the ultimate terminating network. Does it make any difference that access to the Federation is via a transitory relationship (your "tier 1" provider example)?!?! If both the originating and terminating networks were members of the same Federation, then a direct relationship can be established and or facilitated be the "authoritative" body of the Federation. -It's been identified on this list before that there is a finite limit to the number of "peering relationships" that an orig domain can maintain effective. With that in mind, there must be some summary mechanism. As you note, the ultimate goal is to reach domains. That reachability can either be direct, or through Federation alignment. The Federation concept alleviates the burden of both the central db in the sky, as well as of the orig domain to peer with everyone to facilitate a full mesh. =20 Otmar Lendl via draft-lendl-speermint-federations-00 suggests a method to disseminate Federation membership, but this is via DNS, and therefore out of scope for Speermint. At the end of the day, Speermint routes to either the terminating domain and/or the Federation where terminating domain is a member. =20 Adam -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Tuesday, June 06, 2006 10:51 AM To: Stastny Richard; Reinaldo Penno; Otmar Lendl Cc: speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture All, I am back from vacation and find a very long and interesting thread. I was trying to hold off responding till I read all 130+ messages but am finding it difficult to remember and resist, so pardon me if I restate something here. First, the goal is to reach domains, so the routing to E.164 numbers should be out of scope -- no reinventing TRIP. We turn E.164 into sip addresses and then route on the domains. >From the domain we should be able to look up direct signaling points or indirectly policy points. In some cases, we may find federation information, then need to think about how to route to that federation. I think the discussion about number of domains and BGP-like stuff is barking up the wrong tree. Oh, BTW there are about 3000 carriers in the USA alone and roughly 8000 public enterprises (publicly traded stock) in the USA. But, I think that misses the point. I believe the reality will be that there will ultimately be two options: - from one SP (carrier/enterprise) to another there is direct peering, - from one SP to another there is no direct peering and a "Tier 1" SP will be used for transit. There will be some rather large SPs (think ATT, Sprint, name you favorite PTT) that will be all too willing to be the transit carrier and solve the bridging problem, and many enterprises or individuals will be all too willing to let them do that. The federations may thus be a means of aggregating the sip routing problem and making it scalable. The federation then becomes a default route for the Tier 2 SP. I suspect that the sequence will look something like: E.164 -> sip:E.164@termination-SP.com - at this point the originating SP can determine if it has a peering throug internal means, - if not: termination-SP.com -> terminating-federation.com - at this point the originating SP can determine if it belongs to that same federation, - if not, the end result will be: Request-URI: sip:E.164@termination-SP.com -- points to target SP Route: originating-federation.com -- points to near side if not common federation Route: terminating-federation.com -- points to far side federation originating-federation -> translates to my transit SP. I may have abused the federation concept a bit, given that there is both the qualitative aspect of having a common agreement on how to interconnect, and the routing aspect which anticipates that a federation may be formed around a large SP that has the IP network to connect to all the SPs that sign up for that "federation". I'll confess that there is some legacy precedent here. But, that may be the most viable short term evolution path. My thinking, if it is not obvious is that the optimal number of SPs is 2 (direct peering). Second best is 3 (one transit). =20 Maximum number is 4 (one originating and one terminating transit). =20 I believe that hopping across 10 SIP signaling networks would be a sure sign that our work here has failed, and that is what I fear the BGP discussion would lead us to. Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Saturday, May 27, 2006 7:26 AM > To: Reinaldo Penno; Otmar Lendl > Cc: speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > >I wonder how > >LNP is solved within wireless...A specific entry for each > phone? That > >would be crazy. >=20 > Ahem, ENUM? >=20 > I thought that is all what ENUM is about? >=20 > Richard >=20 >=20 > ________________________________ >=20 > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Sa 27.05.2006 11:04 > An: Otmar Lendl; Patrick Melampy > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 >=20 >=20 > Hello, >=20 > I believe the crux of the problem was missed. >=20 > The issue is not really the number of domains. We have today some=20 > 400.000.000 million hosts on the Internet. BGP peers to do not=20 > exchange 400.000.000 million routes, they exchange in the low hundreds > of thousands. >=20 > And why is that? (I guess you know where I'm getting at).=20 > That's because IP addresses lend themselves very well to hierarchical=20 > deployment, compression through prefix/CIDR usage and the like. DNS=20 > names are strings and hence difficult to come up with a similar=20 > scheme. >=20 >=20 > I believe that if domains need to be exchanged between peers: >=20 > 1 - Just a limited set would be exchanged and a "default layer 5=20 > route" > (equivalent to a traditional default route) would be used. >=20 > 2 - Compression schemes like *.company.com, regular expressions or the > like would need to be used. Having specific routes to AORs would be=20 > hairy (maybe for the eventual roaming or visiting user). I wonder how=20 > LNP is solved within wireless...A specific entry for each phone? > That would be crazy. >=20 > 3 - Some new scheme that will make somebody rich....until then.. >=20 > I believe subscriptions would be used to exchange mostly "cost" and=20 > policy information and some domains. I use cost here in the layer 3=20 > sense (number of calls, jitter, whatever). Cost would be an abstract=20 > value or a more specific one (up to the administrator). >=20 > Regards, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at] > > Sent: Saturday, May 27, 2006 1:29 AM > > To: Patrick Melampy > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > On 2006/05/26 18:05, Patrick Melampy > wrote: > > > I suppose like in any distributed routing protocol, there are some > > chicken > > > an egg issues. But consider the following. > > > > > > PREREQUISITES: > > > 1.) You know the destination DOMAIN from either ENUM or > other means. > > > > [...] > > > > > > This technique is very similar to TRIP, only its for > DOMAINS and not > > partial > > > E.164 numbers. > > > > [...] > > > > > Obviously, the data set could get large, as the list of > domains can > be > > > really big. There are some possibilities here... > > > > Let's do a quick estimate on the number of domains involved: > > > > Right now, operators usually give customers URIs of the form=20 > > @. As long as this is the state of affairs,=20 > > we're fine as the number of providers is quite finite (a few=20 > > thousands, perhaps). > > > > This is like the state of affairs with respect to email, anno 1990. > > Back then customers started to notice that if they use their own > domain > > for email, then they can switch providers without having to change=20 > > their email address. Thus a *lot* of people opted to use their own=20 > > domain for email. > > > > My guess is that the same will happen to SIP. Once customers print=20 > > their SIP uris on business cards, they will want to use their own=20 > > domains. If providers won't support that feature then I > suspect that > > the regulators will step in and mandate an URI portability solution=20 > > just as they did in the PSTN with respect to numbers from number > blocks. > > (This could get really nasty protocol-wise, so I guess > using customer- > > owned domains is the far better and likelier solution to the porting > > question.) > > > > So: Anything we come up with here in SPEERMINT needs to cope with a=20 > > scenario where the use of customer domains in SIP URIs is just as=20 > > widespread as it is for email. > > > > How many domains are used for email? That's hard to say. There are=20 > > about 60 million gTLD domains and probably more than 20 ccTLD ones. > > Assuming that only a tenth of that is used for email we're at > > 8 million domains. Given the exponential growth any system which=20 > > doesn't scale to at least 10 million domains will be > obsolete before > > the ink is dry on the RFC. > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > Let's say we need at least 100 bytes of state information > per domain. > > That makes a full routing table 1 GB worth of data. That also means=20 > > that a new border element needs to exchange that amount of > data with > > its peers before it has learned the current state of the routing=20 > > table. > > > > That is some serious amount of data. > > > > > 1.) Have notification point to a published document, and the > document > > lists > > > all of the relevant reachability in real time. Thus any change to > the > > > document would generate a NOTIFICATION. > > > > + a download of up to 1 GB per peer. > > > > > 2.) User partial domains, broken up by the "dots". This may allow > some > > > wildcarding to reduce the number of domains. For > instance, a carrier > > like > > > Verizon may have many 100's of domains attached to it, and version > is > > > willing to route and manage SIP traffic to any of them. The NOTIFY > could > > > contain something like: Verizon.com or *.verizon.com to indicate > that > > any > > > domain in Verizon is reachable. > > > > That's helpful if a provider uses subdomains for internal purposes,=20 > > but that won't help you with customer owned domains. > > > > > This technique may work -- and fit nicely into an > existing protocol. > All > > we > > > would need to do is define the data models (XML?) and or documents > for > > > exchanging. > > > > I think this technique can work -- if you add an aggregation step=20 > > before the routing scheme. > > > > Take another look at BGP: there you have the concept of an > Autonomous > > System and not only that of prefixes. Maybe you need something=20 > > similar. > > > > One approach to cope with hosted SIP domains could be to use the=20 > > hostnames as found in SRV records. E.g. for settings like > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > run the routing algorithm on "sip.provider.com" instead of=20 > > "customer.domain". > > > > Another option is to store some AS-equivalent in the > customer domain > > and have the routing algorithm operate on that. In my domain-policy=20 > > framework this could be expressed e.g. like > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > stating that this domain can be reached using the Speermint routing=20 > > logic by using the learned route to RoutingID 1042. > > > > Or, even better, use non-terminals, and thus refer to the ingress=20 > > policy stored in the provider's domain: > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > (+ whatever other facts provider.com wants to announce about his > > reachability.) > > > > This combination of our ideas can indeed work and scale to an=20 > > unlimited number of customer-owned domains. > > > > /ol > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > _______________________________________________ > > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jun 07 12:23:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0oF-0004os-FP; Wed, 07 Jun 2006 12:23:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0oF-0004on-0v for speermint@ietf.org; Wed, 07 Jun 2006 12:23:07 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fo0oD-0005OY-SX for speermint@ietf.org; Wed, 07 Jun 2006 12:23:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 7 Jun 2006 18:23:38 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AC4@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIB/RgscAAw2qLAAAWjXmc= From: "Stastny Richard" To: "Uzelac, Adam" , "Otmar Lendl" X-Spam-Score: 0.0 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 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 it's important to state and acknowledge that we aren't going = to >ever see one big globally pertinent "CRD database" in the sky that is >mutually owned and shared. =20 =20 I always thought that is the DNS, and how to use it is defined in RFC = 3263. If you add draft-lendl-speermint-federations, you basically have it =20 BTE, the DNS is not out of scope ;-) =20 -sta ________________________________ Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Gesendet: Mi 07.06.2006 16:35 An: Michael Hammer (mhammer); Stastny Richard; Reinaldo Penno; Otmar = Lendl Cc: speermint@ietf.org Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Mike - I agree with what you are saying here, or more importantly how I am reading what you are saying. Some points below: -It's important to avoid the "hopping across 10 SIP signaling networks" scenario. AGREED. -I think it's important to state and acknowledge that we aren't going to ever see one big globally pertinent "CRD database" in the sky that is mutually owned and shared. Hence the value of "routing to a Federation" instead of the ultimate terminating network. Does it make any difference that access to the Federation is via a transitory relationship (your "tier 1" provider example)?!?! If both the originating and terminating networks were members of the same Federation, then a direct relationship can be established and or facilitated be the "authoritative" body of the Federation. -It's been identified on this list before that there is a finite limit to the number of "peering relationships" that an orig domain can maintain effective. With that in mind, there must be some summary mechanism. As you note, the ultimate goal is to reach domains. That reachability can either be direct, or through Federation alignment. The Federation concept alleviates the burden of both the central db in the sky, as well as of the orig domain to peer with everyone to facilitate a full mesh.=20 Otmar Lendl via draft-lendl-speermint-federations-00 suggests a method to disseminate Federation membership, but this is via DNS, and therefore out of scope for Speermint. At the end of the day, Speermint routes to either the terminating domain and/or the Federation where terminating domain is a member.=20 Adam -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Tuesday, June 06, 2006 10:51 AM To: Stastny Richard; Reinaldo Penno; Otmar Lendl Cc: speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture All, I am back from vacation and find a very long and interesting thread. I was trying to hold off responding till I read all 130+ messages but am finding it difficult to remember and resist, so pardon me if I restate something here. First, the goal is to reach domains, so the routing to E.164 numbers should be out of scope -- no reinventing TRIP. We turn E.164 into sip addresses and then route on the domains. >From the domain we should be able to look up direct signaling points or indirectly policy points. In some cases, we may find federation information, then need to think about how to route to that federation. I think the discussion about number of domains and BGP-like stuff is barking up the wrong tree. Oh, BTW there are about 3000 carriers in the USA alone and roughly 8000 public enterprises (publicly traded stock) in the USA. But, I think that misses the point. I believe the reality will be that there will ultimately be two options: - from one SP (carrier/enterprise) to another there is direct peering, - from one SP to another there is no direct peering and a "Tier 1" SP will be used for transit. There will be some rather large SPs (think ATT, Sprint, name you favorite PTT) that will be all too willing to be the transit carrier and solve the bridging problem, and many enterprises or individuals will be all too willing to let them do that. The federations may thus be a means of aggregating the sip routing problem and making it scalable. The federation then becomes a default route for the Tier 2 SP. I suspect that the sequence will look something like: E.164 -> sip:E.164@termination-SP.com - at this point the originating SP can determine if it has a peering throug internal means, - if not: termination-SP.com -> terminating-federation.com - at this point the originating SP can determine if it belongs to that same federation, - if not, the end result will be: Request-URI: sip:E.164@termination-SP.com -- points to target SP Route: originating-federation.com -- points to near side if not common federation Route: terminating-federation.com -- points to far side federation originating-federation -> translates to my transit SP. I may have abused the federation concept a bit, given that there is both the qualitative aspect of having a common agreement on how to interconnect, and the routing aspect which anticipates that a federation may be formed around a large SP that has the IP network to connect to all the SPs that sign up for that "federation". I'll confess that there is some legacy precedent here. But, that may be the most viable short term evolution path. My thinking, if it is not obvious is that the optimal number of SPs is 2 (direct peering). Second best is 3 (one transit).=20 Maximum number is 4 (one originating and one terminating transit).=20 I believe that hopping across 10 SIP signaling networks would be a sure sign that our work here has failed, and that is what I fear the BGP discussion would lead us to. Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Saturday, May 27, 2006 7:26 AM > To: Reinaldo Penno; Otmar Lendl > Cc: speermint@ietf.org > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > >I wonder how > >LNP is solved within wireless...A specific entry for each > phone? That > >would be crazy. > > Ahem, ENUM? > > I thought that is all what ENUM is about? > > Richard > > > ________________________________ > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > Gesendet: Sa 27.05.2006 11:04 > An: Otmar Lendl; Patrick Melampy > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > Hello, > > I believe the crux of the problem was missed. > > The issue is not really the number of domains. We have today some > 400.000.000 million hosts on the Internet. BGP peers to do not > exchange 400.000.000 million routes, they exchange in the low hundreds > of thousands. > > And why is that? (I guess you know where I'm getting at). > That's because IP addresses lend themselves very well to hierarchical > deployment, compression through prefix/CIDR usage and the like. DNS > names are strings and hence difficult to come up with a similar > scheme. > > > I believe that if domains need to be exchanged between peers: > > 1 - Just a limited set would be exchanged and a "default layer 5 > route" > (equivalent to a traditional default route) would be used. > > 2 - Compression schemes like *.company.com, regular expressions or the > like would need to be used. Having specific routes to AORs would be > hairy (maybe for the eventual roaming or visiting user). I wonder how > LNP is solved within wireless...A specific entry for each phone? > That would be crazy. > > 3 - Some new scheme that will make somebody rich....until then.. > > I believe subscriptions would be used to exchange mostly "cost" and > policy information and some domains. I use cost here in the layer 3 > sense (number of calls, jitter, whatever). Cost would be an abstract > value or a more specific one (up to the administrator). > > Regards, > > Reinaldo > > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at] > > Sent: Saturday, May 27, 2006 1:29 AM > > To: Patrick Melampy > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > Architecture > > > > On 2006/05/26 18:05, Patrick Melampy > wrote: > > > I suppose like in any distributed routing protocol, there are some > > chicken > > > an egg issues. But consider the following. > > > > > > PREREQUISITES: > > > 1.) You know the destination DOMAIN from either ENUM or > other means. > > > > [...] > > > > > > This technique is very similar to TRIP, only its for > DOMAINS and not > > partial > > > E.164 numbers. > > > > [...] > > > > > Obviously, the data set could get large, as the list of > domains can > be > > > really big. There are some possibilities here... > > > > Let's do a quick estimate on the number of domains involved: > > > > Right now, operators usually give customers URIs of the form > > @. As long as this is the state of affairs, > > we're fine as the number of providers is quite finite (a few > > thousands, perhaps). > > > > This is like the state of affairs with respect to email, anno 1990. > > Back then customers started to notice that if they use their own > domain > > for email, then they can switch providers without having to change > > their email address. Thus a *lot* of people opted to use their own > > domain for email. > > > > My guess is that the same will happen to SIP. Once customers print > > their SIP uris on business cards, they will want to use their own > > domains. If providers won't support that feature then I > suspect that > > the regulators will step in and mandate an URI portability solution > > just as they did in the PSTN with respect to numbers from number > blocks. > > (This could get really nasty protocol-wise, so I guess > using customer- > > owned domains is the far better and likelier solution to the porting > > question.) > > > > So: Anything we come up with here in SPEERMINT needs to cope with a > > scenario where the use of customer domains in SIP URIs is just as > > widespread as it is for email. > > > > How many domains are used for email? That's hard to say. There are > > about 60 million gTLD domains and probably more than 20 ccTLD ones. > > Assuming that only a tenth of that is used for email we're at > > 8 million domains. Given the exponential growth any system which > > doesn't scale to at least 10 million domains will be > obsolete before > > the ink is dry on the RFC. > > > > So what happens if we do some sort of BGP or TRIP with domains? > > > > Let's say we need at least 100 bytes of state information > per domain. > > That makes a full routing table 1 GB worth of data. That also means > > that a new border element needs to exchange that amount of > data with > > its peers before it has learned the current state of the routing > > table. > > > > That is some serious amount of data. > > > > > 1.) Have notification point to a published document, and the > document > > lists > > > all of the relevant reachability in real time. Thus any change to > the > > > document would generate a NOTIFICATION. > > > > + a download of up to 1 GB per peer. > > > > > 2.) User partial domains, broken up by the "dots". This may allow > some > > > wildcarding to reduce the number of domains. For > instance, a carrier > > like > > > Verizon may have many 100's of domains attached to it, and version > is > > > willing to route and manage SIP traffic to any of them. The NOTIFY > could > > > contain something like: Verizon.com or *.verizon.com to indicate > that > > any > > > domain in Verizon is reachable. > > > > That's helpful if a provider uses subdomains for internal purposes, > > but that won't help you with customer owned domains. > > > > > This technique may work -- and fit nicely into an > existing protocol. > All > > we > > > would need to do is define the data models (XML?) and or documents > for > > > exchanging. > > > > I think this technique can work -- if you add an aggregation step > > before the routing scheme. > > > > Take another look at BGP: there you have the concept of an > Autonomous > > System and not only that of prefixes. Maybe you need something > > similar. > > > > One approach to cope with hosted SIP domains could be to use the > > hostnames as found in SRV records. E.g. for settings like > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com > > > > run the routing algorithm on "sip.provider.com" instead of > > "customer.domain". > > > > Another option is to store some AS-equivalent in the > customer domain > > and have the routing algorithm operate on that. In my domain-policy > > framework this could be expressed e.g. like > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > stating that this domain can be reached using the Speermint routing > > logic by using the learned route to RoutingID 1042. > > > > Or, even better, use non-terminals, and thus refer to the ingress > > policy stored in the provider's domain: > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" > > "!.*!urn:ietf:speermint:RID:1042!" . > > > > (+ whatever other facts provider.com wants to announce about his > > reachability.) > > > > This combination of our ideas can indeed work and scale to an > > unlimited number of customer-owned domains. > > > > /ol > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > _______________________________________________ > > 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 Wed Jun 07 12:25:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0qg-0007RJ-Vq; Wed, 07 Jun 2006 12:25:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0qf-0007R8-6t for speermint@ietf.org; Wed, 07 Jun 2006 12:25:37 -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 1Fo0qd-0005VE-VU for speermint@ietf.org; Wed, 07 Jun 2006 12:25:37 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id A77E3412E; Wed, 7 Jun 2006 12:25:35 -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, 7 Jun 2006 12:25:35 -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] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 7 Jun 2006 12:25:33 -0400 Message-ID: In-Reply-To: <20060607161053.GA9035@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaKTP3Jm/zAPDBATguI39m9XC3YkQAALGMQ From: "Uzelac, Adam" To: "Otmar Lendl" X-OriginalArrivalTime: 07 Jun 2006 16:25:35.0647 (UTC) FILETIME=[015BA2F0:01C68A4F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 make the out of scope statement because I am of the mindset that the SPEERMINT scope kicks in after resolution of the AoR - to me this means that Speermint can assume knowledge of domain and federation from DNS, and then use that CRD appropriately. I might have this wrong though - but that was what I was thinking. -Adam=20 -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Wednesday, June 07, 2006 12:11 PM To: Uzelac, Adam Cc: Michael Hammer (mhammer); Stastny Richard; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture On 2006/06/07 16:06, "Uzelac, Adam" wrote: > > -It's been identified on this list before that there is a finite limit > to the number of "peering relationships" that an orig domain can=20 > maintain effective. With that in mind, there must be some summary=20 > mechanism. As you note, the ultimate goal is to reach domains. That=20 > reachability can either be direct, or through Federation alignment. =20 > The Federation concept alleviates the burden of both the central db in > the sky, as well as of the orig domain to peer with everyone to=20 > facilitate a full mesh. Correct. > Otmar Lendl via draft-lendl-speermint-federations-00 suggests a method > to disseminate Federation membership, but this is via DNS, and=20 > therefore out of scope for Speermint. ENUM is out of scope for speermint, as it deals with E.164 numbers. draft-lendl-speermint-federations-00 operates on the domain part of SIP URIs. I see no conflict with the SPEERMINT charter. Can you elaborate why you think that draft-lendl-speermint-federations-00 is out of scope? /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 Jun 07 12:50:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1Ek-0003AQ-Jo; Wed, 07 Jun 2006 12:50:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1Ej-00039o-0S for speermint@ietf.org; Wed, 07 Jun 2006 12:50:29 -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 1Fo0kS-0004zY-31 for speermint@ietf.org; Wed, 07 Jun 2006 12:19:12 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fo0cT-0001T6-Vg for speermint@ietf.org; Wed, 07 Jun 2006 12:10:59 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 61A841A372; Wed, 7 Jun 2006 18:10:53 +0200 (CEST) Date: Wed, 7 Jun 2006 18:10:53 +0200 From: Otmar Lendl To: "Uzelac, Adam" Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060607161053.GA9035@nic.at> Mail-Followup-To: Otmar Lendl , "Uzelac, Adam" , "Michael Hammer (mhammer)" , Stastny Richard , Reinaldo Penno , speermint@ietf.org References: <072C5B76F7CEAB488172C6F64B30B5E3018B70FB@xmb-rtp-20b.amer.cisco.com> 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: -2.6 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 On 2006/06/07 16:06, "Uzelac, Adam" wrote: > > -It's been identified on this list before that there is a finite limit > to the number of "peering relationships" that an orig domain can > maintain effective. With that in mind, there must be some summary > mechanism. As you note, the ultimate goal is to reach domains. That > reachability can either be direct, or through Federation alignment. The > Federation concept alleviates the burden of both the central db in the > sky, as well as of the orig domain to peer with everyone to facilitate a > full mesh. Correct. > Otmar Lendl via draft-lendl-speermint-federations-00 suggests a method > to disseminate Federation membership, but this is via DNS, and therefore > out of scope for Speermint. ENUM is out of scope for speermint, as it deals with E.164 numbers. draft-lendl-speermint-federations-00 operates on the domain part of SIP URIs. I see no conflict with the SPEERMINT charter. Can you elaborate why you think that draft-lendl-speermint-federations-00 is out of scope? /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 Jun 07 13:52:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2CD-0002Yb-IT; Wed, 07 Jun 2006 13:51:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2CD-0002YW-04 for speermint@ietf.org; Wed, 07 Jun 2006 13:51:57 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2CB-0001dT-QA for speermint@ietf.org; Wed, 07 Jun 2006 13:51:56 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Wed, 07 Jun 2006 13:52:23 -0400 id 0158C122.44871257.00005DF1 Message-ID: <44871232.2000002@hxr.us> Date: Wed, 07 Jun 2006 13:51:46 -0400 From: Andrew Newton 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: cf4fa59384e76e63313391b70cd0dd25 Subject: [Speermint] A question about federations X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Last week, Otmar asked the following questions to the working group: * Is there interest in an I-D which defines the semantic of policy rules which can be used to form ad-hoc federations? * Is there interest in another presentation regarding my domain policy DDDS proposal at the upcoming IETF meeting? He got a resounding zero responses (perhaps because the question was buried in a very long thread). I say "yes" to both questions. Mostly because I'm unsure what other problems this working group is suppose to solve. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jun 07 15:38:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3rL-0003Ut-Pb; Wed, 07 Jun 2006 15:38:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3rL-0003Uo-7G for speermint@ietf.org; Wed, 07 Jun 2006 15:38:31 -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 1Fo3rJ-0005mK-Ve for speermint@ietf.org; Wed, 07 Jun 2006 15:38:31 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 58DC035BD; Wed, 7 Jun 2006 15:38:29 -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, 7 Jun 2006 15:38: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] A question about federations Date: Wed, 7 Jun 2006 15:38:26 -0400 Message-ID: In-Reply-To: <44871232.2000002@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] A question about federations Thread-Index: AcaKWxnv8qhxocbaQwuxrbVf9p6kAgAANZSg From: "Uzelac, Adam" To: "Andrew Newton" , X-OriginalArrivalTime: 07 Jun 2006 19:38:29.0184 (UTC) FILETIME=[F3B93C00:01C68A69] X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Andrew, Question - are you saying that good points and questions getting buried in very long threads? Never seen that before in IETF mailing lists! ;) Great catch plucking these 2 questions out of that thread. I would like to understand better the "policy rules", and I think it would apply beyond ad hoc. I am not sure I completely understand the "ad hoc" aspect of the question, but it doesn't really matter. =20 As for the domain policy proposal presentation in Montreal, I believe that would also kick a most lively discussion about policy exchange via DNS or SIP. I personally see merit in both. =20 Adam -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Wednesday, June 07, 2006 1:52 PM To: speermint@ietf.org Subject: [Speermint] A question about federations Last week, Otmar asked the following questions to the working group: * Is there interest in an I-D which defines the semantic of policy rules which can be used to form ad-hoc federations? * Is there interest in another presentation regarding my domain policy DDDS proposal at the upcoming IETF meeting? He got a resounding zero responses (perhaps because the question was buried in a very long thread). I say "yes" to both questions. Mostly because I'm unsure what other problems this working group is suppose to solve. -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 Jun 08 14:06:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoOtf-0008Qp-O9; Thu, 08 Jun 2006 14:06:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoOte-0008Qa-Bq for speermint@ietf.org; Thu, 08 Jun 2006 14:06:18 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoOtd-0007Iw-2x for speermint@ietf.org; Thu, 08 Jun 2006 14:06:18 -0400 Received: from ([10.20.9.174]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.21021406; Thu, 08 Jun 2006 14:05:38 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 14: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Jun 2006 14:05:36 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96581F03@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 67 Location Announcement thread-index: AcaLE6X7tHmjE33wQQepV5hGj90nvQAEmsQg From: "Livingood, Jason" To: X-OriginalArrivalTime: 08 Jun 2006 18:05:40.0184 (UTC) FILETIME=[26C10580:01C68B26] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Speermint] FW: IETF 67 Location Announcement 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 fyi=20 -----Original Message----- From: IETF Administrative Director [mailto:iad@ietf.org]=20 Sent: Thursday, June 08, 2006 11:52 AM To: IETF Announcement list Subject: IETF 67 Location Announcement=20 The IETF is pleased to announce its selection of San Diego, California, USA and the Sheraton San Diego Hotel & Marina as the site of IETF 67 being held November 5 - 10, 2006. As we celebrate IETF's 20th year we return to the city where IETF 01 (with 21 attendees) was held, as well as IETFs' 9, 23, 49, and 60. The Sheraton has added another 18,000 sq ft of meeting space for us to use this year. Note Well: There are other conferences being held in San Diego so we encourage you to reserve your hotel rooms right away. We have arrangements on Harbor Island with: Sheraton San Diego Hotel & Marina for 770 rooms and 50 rooms at the Hilton San Diego Airport/Marina, both properties with free Internet in the rooms. More information can be found at: http://www.ietf.org/meetings/hotels_67.html Registration for San Diego will open July 12th. We are looking forward to San Diego in November, but until then we will see you in Montreal in 31 days! And speaking of Montreal, Early Bird registration with its $550 registration fee expires at 1600 GMT on 30 June! If you have not registered yet, delay no longer! http://www.ietf.org/meetings/IETF-66.html Ray Pelletier IETF Administrative Director _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 09 10:04:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FohbF-0000tB-Vh; Fri, 09 Jun 2006 10:04:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FohbF-0000t5-2T for speermint@ietf.org; Fri, 09 Jun 2006 10:04:33 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FohbB-0002yf-KS for speermint@ietf.org; Fri, 09 Jun 2006 10:04:33 -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 k59E4TRg026536 for ; Fri, 9 Jun 2006 07:04:29 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k59E4T0u026535 for speermint@ietf.org; Fri, 9 Jun 2006 07:04:29 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 9 Jun 2006 07:04:29 -0700 From: David Meyer To: speermint@ietf.org Message-ID: <20060609140429.GA26522@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: 92df29fa99cf13e554b84c8374345c17 Subject: [Speermint] FYI -- Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada 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="===============0746971360==" Errors-To: speermint-bounces@ietf.org --===============0746971360== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from ietf-secretariat@ietf.org ----- > From: ietf-secretariat@ietf.org > To: ietf-announce@ietf.org > Cc:=20 > Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting > in Montreal, Quebec, Canada=20 > Date: Fri, 09 Jun 2006 00:00:01 -0400 >=20 >=20 > There are two (2) Internet-Draft cutoff dates for the 66th=20 > IETF Meeting in Montreal, Quebec, Canada: >=20 > June 19th: Cutoff Date for Initial (i.e., version -00)=20 > Internet-Draft Submissions=20 >=20 > All initial Internet-Drafts (version -00) must be submitted by Monday,=20 > June 19th at 9:00 AM ET. As always, all initial submissions with a=20 > filename beginning with "draft-ietf" must be approved by the=20 > appropriate WG Chair before they can be processed or announced. The=20 > Secretariat would appreciate receiving WG Chair approval by Monday,=20 > June 12th at 9:00 AM ET. >=20 > June 26th: Cutoff Date for Revised (i.e., version -01 and higher)=20 > Internet-Draft Submissions=20 >=20 > All revised Internet-Drafts (version -01 and higher) must be submitted=20 > by Monday, June 26th at 9:00 AM ET. >=20 > Initial and revised Internet-Drafts received after their respective=20 > cutoff dates will not be made available in the Internet-Drafts=20 > directory or announced until on or after Monday, July 10th at 9:00=20 > AM ET, when Internet-Draft posting resumes. Please do not wait until=20 > the last minute to submit. >=20 > Thank you for your understanding and cooperation. If you have any=20 > questions or concerns, then please send a message to=20 > internet-drafts@ietf.org. >=20 > The IETF Secretariat >=20 > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 66th IETF Meeting can be found at http://www.ietf.org/meetings/cu= toff_dates_66.html. >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEiX/tORgD1qCZ2KcRAmPtAJ40aXedM9BdjlNF0nX39CyMZ4x5EgCeJxJF cEXZ/AEdMc7/7CBQYf09n90= =lK5n -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- --===============0746971360== 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 --===============0746971360==-- From speermint-bounces@ietf.org Mon Jun 12 13:39:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpqNi-0007sQ-0p; Mon, 12 Jun 2006 13:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpqNh-0007sF-2O for speermint@ietf.org; Mon, 12 Jun 2006 13:39:17 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpqNd-00005C-E7 for speermint@ietf.org; Mon, 12 Jun 2006 13:39:17 -0400 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.21233774; Mon, 12 Jun 2006 13:38:36 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jun 2006 13:38:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Jun 2006 13:38:35 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96581F50@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [wg-business] Speermint WG Meeting information for those of you travel planning thread-index: AcaNh/RLJjO3ibAGS/mJOc1dTSbtJQAvvHPA From: "Livingood, Jason" To: X-OriginalArrivalTime: 12 Jun 2006 17:38:35.0751 (UTC) FILETIME=[082B3770:01C68E47] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Speermint] [wg-business] Speermint WG Meeting information for those of you travel planning 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 TENTATIVE... -----Original Message----- From: IETF Secretariat=20 Subject: SPEERMINT - Requested session has been scheduled for IETF 66=20 The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. SPEERMINT Session 1 (2 hours) Monday, Afternoon Session I 1300-1500 Room Name: Room 520DEF ---------------------------------------------- _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jun 12 21:34:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpxnb-0000YP-PD; Mon, 12 Jun 2006 21:34:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpxnZ-0000YK-Pr for speermint@ietf.org; Mon, 12 Jun 2006 21:34:29 -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 1FpxnY-0008U6-Hi for speermint@ietf.org; Mon, 12 Jun 2006 21:34:29 -0400 Received: from PMelampy [68.189.242.21] by acmepacket.com with ESMTP (SMTPD-9.03) id A62004D0; Mon, 12 Jun 2006 21:34:24 -0400 From: "Patrick Melampy" To: "'Michael Hammer \(mhammer\)'" , "'Stastny Richard'" , "'Reinaldo Penno'" , "'Otmar Lendl'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Mon, 12 Jun 2006 21:34:27 -0400 Message-ID: <004601c68e89$82c3eda0$6501a8c0@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: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIB/RgscAFELq5A In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3018B70FB@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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'd like to comment as follows: You said: > I believe the reality will be that there will ultimately be two options: > - from one SP (carrier/enterprise) to another there is direct peering, > - from one SP to another there is no direct peering and a "Tier 1" SP > will be used for transit. Unless somebody representing a carrier makes this statement, it's safe to say we are just guessing. I find this statement your making to lack any backing. How many Autonomous Systems do your communications go through today? When you're at work? When you're at home? I'm guessing you have no idea. Why should this group ever designate a role for a Tier 1 SP as a required internetworking element? If you worked at a competitive Tier 2 you might take exception to your statement. > My thinking, if it is not obvious is that the optimal number of SPs is 2 > (direct peering). Optimal in whose frame of reference? The internet's? The caller? The callee? The carrier(s)? My guess is your thinking of the internet. > Second best is 3 (one transit). Why is one transit carrier better than 2 or 3? Is it cost? Quality? Where did this conclusion come from? Are there any IP based models where a single backbone carrier is considered optimal? Doesn't this limit competition and choice? Wouldn't it be anti-competitive, and thus not be net-neutral? >Maximum number is 4 (one originating and one terminating transit). Why is this the maxium? I hate to argue with your statements, but they should be better defended. There are a lot of managed networks that are both legislated and or pre-existing. The owners of long haul fiber networks want to use them for signaled media. My guess is we will not only have One Tier 1 to choose from, but the following: 1.) Each Enterprise will desire at least 2 interconnect carriers to ensure they have the lowest cost and best level of service with redundancy. 2.) Each Tier 1 Carrier will want to purchase termination services for its customers and have multiple paths to each major desination domain 3.) Many Tier 2 and Tier 3 carriers will exist by selecting specific target markets and verticals. 4.) Governments will continue to try to enforce regulations guaranteeing a competitive landscape for communication interconnects (requiring access for 2nd and 3rd carrier options. I could go on and on. I would suggest that we embrace the realities of our world as requirements for this standards group. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jun 13 10:38:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqA25-0002RT-D6; Tue, 13 Jun 2006 10:38:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqA24-0002RO-05 for speermint@ietf.org; Tue, 13 Jun 2006 10:38:16 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqA23-0000Pg-Eo for speermint@ietf.org; Tue, 13 Jun 2006 10:38:15 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 13 Jun 2006 07:38:14 -0700 X-IronPort-AV: i="4.06,128,1149490800"; d="scan'208"; a="293819532:sNHT2078159906" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5DEcDS8002231; Tue, 13 Jun 2006 07:38:13 -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 k5DEcAIu010000; Tue, 13 Jun 2006 07:38:12 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 10:38:10 -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] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 13 Jun 2006 10:38:09 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301917BBB@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIB/RgscAFELq5AABtVn4A= From: "Michael Hammer \(mhammer\)" To: "Patrick Melampy" , "Stastny Richard" , "Reinaldo Penno" , "Otmar Lendl" X-OriginalArrivalTime: 13 Jun 2006 14:38:10.0241 (UTC) FILETIME=[FE133B10:01C68EF6] DKIM-Signature: a=rsa-sha1; q=dns; l=6831; t=1150209493; x=1151073493; c=relaxed/simple; s=sjdkim8001; 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]=20Updated=20Draft=3A=20SPEERMINT=20Peering=20Archite cture; X=v=3Dcisco.com=3B=20h=3DJEBiKFA1nAWjuMdMPpxwPZYTZkA=3D; b=T+fRuOHbSZFvnJ8x9cV6TRbY8mfmT4IBZsKMmIIVFZRvhqg5MgppxKugLiXRqEWEQ0VUdhAV MWGhntfPXTWlGTFJvOwTK60Yuyn3Z/t3Ip3eo6fV44ZmalcQmSXrqmQm; Authentication-Results: sj-dkim-8.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) 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 Patrick, Let us take these one at a time. Inline.=20 > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com]=20 > Sent: Monday, June 12, 2006 9:34 PM > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Reinaldo=20 > Penno'; 'Otmar Lendl' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > I'd like to comment as follows: >=20 > You said: > > I believe the reality will be that there will ultimately=20 > be two options: > > - from one SP (carrier/enterprise) to another there is=20 > direct peering, > > - from one SP to another there is no direct peering and a=20 > "Tier 1"=20 > > SP will be used for transit. >=20 > Unless somebody representing a carrier makes this statement,=20 > it's safe to say we are just guessing. I find this statement=20 > your making to lack any backing. How many Autonomous Systems=20 > do your communications go through today? When you're at work?=20 > When you're at home? I'm guessing you have no idea. Why=20 > should this group ever designate a role for a Tier 1 SP as a=20 > required internetworking element? If you worked at a=20 > competitive Tier 2 you might take exception to your statement. The basis for this statement is an assumption that for security and economic reasons, you must have rules of engagement in order to connect to a peer. If there is a business arrangement, you can directly connect, if not then an intermediary is used. This is rather simple and straight forward. This does not preclude you creating a wide-open-to-the-Internet federation through which anyone can connect to you. I am simply stating there are two options: direct and indirect. Is there a third possibility? =20 > > My thinking, if it is not obvious is that the optimal=20 > number of SPs is=20 > > 2 (direct peering). >=20 > Optimal in whose frame of reference? The internet's? The=20 > caller? The callee? > The carrier(s)? My guess is your thinking of the internet.=20 The most optimal is directly from client to client, ie. true P2P. But, I am relaxing that here to the assumption that an end device may "outsource" some degree of features and functionality to a SP, be that enterprise PBX or carrier system. It is optimal because we are talking about two parties, the caller and called parties. For that you could have an origination system and a termination system. Anything beyond that is extraneous middlemen that add cost into the picture, but not much in the way of added value, and a lot of possibility for unintended consequences to screw up the signaling or media. Case in point: Every additional signaling point on the path will exacerbate call setup delay and increase the complexity of the interactions amongst all these components. Case in point: Every additional media anchor will add delay to the RTP stream, thus negatively affecting QoS. So, from the perspective of the caller and callee, the service experience will be better if SPs can minimize the number of extra moving parts in the system. And, from the perspective of the SP, the fewer middlemen in the picture, the fewer the profits to share amongst those middlemen. I am just applying Occam's Razor to get the minimalist set. =20 > > Second best is 3 (one transit). =20 > Why is one transit carrier better than 2 or 3? Is it cost?=20 > Quality? Where did this conclusion come from? Are there any=20 > IP based models where a single backbone carrier is considered=20 > optimal? Doesn't this limit competition and choice? Wouldn't=20 > it be anti-competitive, and thus not be net-neutral? I am suggesting that if both caller and callee have the good fortune to prefer the same transit carrier, then the savings from avoiding a second SP can be shared. This is what is experienced when a call stays within a single enterprise. This is what happens when you have a "friends and family" scenario. It is both a business advantage and a technical advantage to have only one SP's policies to care about. No interworking! =20 > >Maximum number is 4 (one originating and one terminating transit). >=20 > Why is this the maxium?=20 What would a third tranist carrier provide that could not be better provided if transit carrier 1 and 2 had a direct signaling agreement between them? How is sharing revenues amongst 3 carriers better than shared betweeen 2? > I hate to argue with your statements, but they should be=20 > better defended. Hopefully, I have done so. :) > There are a lot of managed networks that are both legislated=20 > and or pre-existing.=20 I don't want our creativity to be limited by arbitrary government fiat, nor by lack of imagination constrained to repeat simply what already exists. > The owners of long haul fiber networks=20 > want to use them for signaled media.=20 Nothing precludes this. This is a layer 3 issue. I am not saying that to connect one signaling point to another that there can not be a VPN over a third IP carrier. Don't confuse Layer 5 with Layer 3 issues. > My guess is we will not=20 > only have One Tier 1 to choose from, but the following: >=20 > 1.) Each Enterprise will desire at least 2 interconnect=20 > carriers to ensure they have the lowest cost and best level=20 > of service with redundancy. My statements don't preclude this. =20 > 2.) Each Tier 1 Carrier will want to purchase termination=20 > services for its customers and have multiple paths to each=20 > major desination domain Not precluded. =20 > 3.) Many Tier 2 and Tier 3 carriers will exist by selecting=20 > specific target markets and verticals. Define Tier 2 and 3. I think you have descended into Layer 3 here. =20 > 4.) Governments will continue to try to enforce regulations=20 > guaranteeing a competitive landscape for communication=20 > interconnects (requiring access for 2nd and 3rd carrier options. See previous. =20 > I could go on and on. I would suggest that we embrace the=20 > realities of our world as requirements for this standards group. Belive me, I am being very realistic. Allow room for arbitrage and it will occur. Economics will drive out an inefficiency in routing, so long as a better path exists. If you do go on and on, would you please also indicate what added value any such intermediaries provide? So far, you have only indicated that they have existed in the past. While their value may have been grounded in the regulatory and business climate of the past, past history that does not take into account new technical realities amounts to just rebuilding the PSTN because that's the way we did it with TDM. I don't find such arguments persuasive. Mike _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jun 13 17:09:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqG8N-0003Cb-3n; Tue, 13 Jun 2006 17:09:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqG8L-0003CW-Bu for speermint@ietf.org; Tue, 13 Jun 2006 17:09:09 -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 1FqG8J-0000YK-TV for speermint@ietf.org; Tue, 13 Jun 2006 17:09:09 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id D4E0E1A379; Tue, 13 Jun 2006 23:09:05 +0200 (CEST) Date: Tue, 13 Jun 2006 23:09:05 +0200 From: Otmar Lendl To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Message-ID: <20060613210905.GB9035@nic.at> Mail-Followup-To: Otmar Lendl , "Michael Hammer (mhammer)" , Patrick Melampy , Stastny Richard , Reinaldo Penno , speermint@ietf.org References: <072C5B76F7CEAB488172C6F64B30B5E301917BBB@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301917BBB@xmb-rtp-20b.amer.cisco.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 [inline] On 2006/06/13 16:06, "Michael Hammer (mhammer)" wrote: > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > > Unless somebody representing a carrier makes this statement, > > it's safe to say we are just guessing. I find this statement > > your making to lack any backing. How many Autonomous Systems > > do your communications go through today? When you're at work? > > When you're at home? I'm guessing you have no idea. Why > > should this group ever designate a role for a Tier 1 SP as a > > required internetworking element? If you worked at a > > competitive Tier 2 you might take exception to your statement. > > The basis for this statement is an assumption that for security and > economic reasons, you must have rules of engagement in order to connect > to a peer. If there is a business arrangement, you can directly > connect, if not then an intermediary is used. This is rather simple and > straight forward. This does not preclude you creating a > wide-open-to-the-Internet federation through which anyone can connect to > you. > > I am simply stating there are two options: direct and indirect. Is > there a third possibility? Well, call it a variant of "direct": The business arrangement may be via an intermediate, but the connection may be direct. (e.g. when a some sort of certification authority qualifies peers on behalf of some constituency.) [...] > It is optimal because we are talking about two parties, the caller and > called parties. For that you could have an origination system and a > termination system. Anything beyond that is extraneous middlemen that > add cost into the picture, but not much in the way of added value, and a > lot of possibility for unintended consequences to screw up the signaling > or media. [...] > > I could go on and on. I would suggest that we embrace the > > realities of our world as requirements for this standards group. > > Belive me, I am being very realistic. Allow room for arbitrage and it > will occur. Economics will drive out an inefficiency in routing, so > long as a better path exists. Agreed. How fast and widestread this happens depends a lot on the cost structure of layer 5 transits. If it is pure SIP signalling (e.g. in order to provide trust) without media, then this can be done with very little additional cost per call (and none per minute). Whether some local SP from Hawaii will bother to establish peerings with one from Finland will depend on calling patterns and the administrative overhead of establishing the peering. We just don't know yet what the cost factors will be in this business in a few years. I just doubt that we can accurately predict what business models will emerge and how many SIP proxies the average call will traverse. All we can do right now is to write standards which are not dependent on a specific assumption regarding the interconnection structure. Our RFCs need to cope with both a quite flat hierarchy (large number of peers per service provider) as well as 4-level 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 Tue Jun 13 21:49:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqKV6-0007hH-Rr; Tue, 13 Jun 2006 21:48:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqKV6-0007h8-3F for speermint@ietf.org; Tue, 13 Jun 2006 21:48:56 -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 1FqKV4-0005oE-L6 for speermint@ietf.org; Tue, 13 Jun 2006 21:48:56 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 331E23AAC; Tue, 13 Jun 2006 21:48:54 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 21:48:54 -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] Updated Draft: SPEERMINT Peering Architecture Date: Tue, 13 Jun 2006 21:48:51 -0400 Message-ID: In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301917BBB@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIB/RgscAFELq5AABtVn4AAF8v/4A== From: "Uzelac, Adam" To: "Michael Hammer (mhammer)" , "Patrick Melampy" , "Stastny Richard" , "Reinaldo Penno" , "Otmar Lendl" X-OriginalArrivalTime: 14 Jun 2006 01:48:54.0114 (UTC) FILETIME=[B14AEC20:01C68F54] X-Spam-Score: 0.1 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c 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 Piping in here to make a point or two - Two realistic requirements that oftentimes are overlooked in global peering bar-napkin discussions, and possibly assumed in the PSTN world, are trust and scale. I argue that the P2P world of direct interconnection/peering, though preferred for obvious technical reasons, can't be realized practically due to scale limitations and an inherent lack of trust. Therefore these 2 items should be kept in mind when scheming up a solution for global peering dominance. (/me puts pinky finger to mouth and mutters, "1 million dollars"! muhahaha) ;) =20 A service provide would be best served to provide its subscribers a way to contact anyone else. The burden to facilitate that session is on the SP. Will a SP in Topeka trust a SP in Oslo enough to establish a direct peering arrangement? Without that direct peer, how will the subscribers of the Topeka SP access the folks in Oslo? An intermediary most likely will be involved with the value being reachability and trust that should a call be sent to the transit provider, it will be completed as intended by the calling party. At the end of the day, it will be the one that will complete the call that gets the buck. Unfortunately it's the PSTN that facilitates that Topeka to Oslo call today more often than not. -Adam -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Tuesday, June 13, 2006 10:38 AM To: Patrick Melampy; Stastny Richard; Reinaldo Penno; Otmar Lendl Cc: speermint@ietf.org Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Patrick, Let us take these one at a time. Inline.=20 > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Sent: Monday, June 12, 2006 9:34 PM > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Reinaldo Penno';=20 > 'Otmar Lendl' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > I'd like to comment as follows: >=20 > You said: > > I believe the reality will be that there will ultimately > be two options: > > - from one SP (carrier/enterprise) to another there is > direct peering, > > - from one SP to another there is no direct peering and a > "Tier 1"=20 > > SP will be used for transit. >=20 > Unless somebody representing a carrier makes this statement, it's safe > to say we are just guessing. I find this statement your making to lack > any backing. How many Autonomous Systems do your communications go=20 > through today? When you're at work? > When you're at home? I'm guessing you have no idea. Why should this=20 > group ever designate a role for a Tier 1 SP as a required=20 > internetworking element? If you worked at a competitive Tier 2 you=20 > might take exception to your statement. The basis for this statement is an assumption that for security and economic reasons, you must have rules of engagement in order to connect to a peer. If there is a business arrangement, you can directly connect, if not then an intermediary is used. This is rather simple and straight forward. This does not preclude you creating a wide-open-to-the-Internet federation through which anyone can connect to you. I am simply stating there are two options: direct and indirect. Is there a third possibility? =20 > > My thinking, if it is not obvious is that the optimal > number of SPs is > > 2 (direct peering). >=20 > Optimal in whose frame of reference? The internet's? The caller? The=20 > callee? > The carrier(s)? My guess is your thinking of the internet.=20 The most optimal is directly from client to client, ie. true P2P. But, I am relaxing that here to the assumption that an end device may "outsource" some degree of features and functionality to a SP, be that enterprise PBX or carrier system. It is optimal because we are talking about two parties, the caller and called parties. For that you could have an origination system and a termination system. Anything beyond that is extraneous middlemen that add cost into the picture, but not much in the way of added value, and a lot of possibility for unintended consequences to screw up the signaling or media. Case in point: Every additional signaling point on the path will exacerbate call setup delay and increase the complexity of the interactions amongst all these components. Case in point: Every additional media anchor will add delay to the RTP stream, thus negatively affecting QoS. So, from the perspective of the caller and callee, the service experience will be better if SPs can minimize the number of extra moving parts in the system. And, from the perspective of the SP, the fewer middlemen in the picture, the fewer the profits to share amongst those middlemen. I am just applying Occam's Razor to get the minimalist set. =20 > > Second best is 3 (one transit). =20 > Why is one transit carrier better than 2 or 3? Is it cost?=20 > Quality? Where did this conclusion come from? Are there any IP based=20 > models where a single backbone carrier is considered optimal? Doesn't=20 > this limit competition and choice? Wouldn't it be anti-competitive,=20 > and thus not be net-neutral? I am suggesting that if both caller and callee have the good fortune to prefer the same transit carrier, then the savings from avoiding a second SP can be shared. This is what is experienced when a call stays within a single enterprise. This is what happens when you have a "friends and family" scenario. It is both a business advantage and a technical advantage to have only one SP's policies to care about. No interworking! =20 > >Maximum number is 4 (one originating and one terminating transit). >=20 > Why is this the maxium?=20 What would a third tranist carrier provide that could not be better provided if transit carrier 1 and 2 had a direct signaling agreement between them? How is sharing revenues amongst 3 carriers better than shared betweeen 2? > I hate to argue with your statements, but they should be better=20 > defended. Hopefully, I have done so. :) > There are a lot of managed networks that are both legislated and or=20 > pre-existing. I don't want our creativity to be limited by arbitrary government fiat, nor by lack of imagination constrained to repeat simply what already exists. > The owners of long haul fiber networks want to use them for signaled=20 > media. Nothing precludes this. This is a layer 3 issue. I am not saying that to connect one signaling point to another that there can not be a VPN over a third IP carrier. Don't confuse Layer 5 with Layer 3 issues. > My guess is we will not > only have One Tier 1 to choose from, but the following: >=20 > 1.) Each Enterprise will desire at least 2 interconnect carriers to=20 > ensure they have the lowest cost and best level of service with=20 > redundancy. My statements don't preclude this. =20 > 2.) Each Tier 1 Carrier will want to purchase termination services for > its customers and have multiple paths to each major desination domain Not precluded. =20 > 3.) Many Tier 2 and Tier 3 carriers will exist by selecting specific=20 > target markets and verticals. Define Tier 2 and 3. I think you have descended into Layer 3 here. =20 > 4.) Governments will continue to try to enforce regulations=20 > guaranteeing a competitive landscape for communication interconnects=20 > (requiring access for 2nd and 3rd carrier options. See previous. =20 > I could go on and on. I would suggest that we embrace the realities of > our world as requirements for this standards group. Belive me, I am being very realistic. Allow room for arbitrage and it will occur. Economics will drive out an inefficiency in routing, so long as a better path exists. If you do go on and on, would you please also indicate what added value any such intermediaries provide? So far, you have only indicated that they have existed in the past. While their value may have been grounded in the regulatory and business climate of the past, past history that does not take into account new technical realities amounts to just rebuilding the PSTN because that's the way we did it with TDM. I don't find such arguments persuasive. Mike _______________________________________________ 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 Jun 14 08:57:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqUva-0001U5-HL; Wed, 14 Jun 2006 08:56:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqUvY-0001OK-Ue for speermint@ietf.org; Wed, 14 Jun 2006 08:56:56 -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 1FqUut-0006xD-Rz for speermint@ietf.org; Wed, 14 Jun 2006 08:56:17 -0400 Received: from [10.0.1.103] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 14 Jun 2006 08:56:40 -0400 id 0158C0D2.44900788.000053D3 In-Reply-To: References: Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Wed, 14 Jun 2006 08:56:13 -0400 To: "Uzelac, Adam" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Otmar Lendl , 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="===============2109847734==" Errors-To: speermint-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============2109847734== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-21466-1150289801-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-21466-1150289801-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit I couldn't agree more. Comments inline: On Jun 13, 2006, at 9:48 PM, Uzelac, Adam wrote: > A service provide would be best served to provide its subscribers a > way > to contact anyone else. The burden to facilitate that session is > on the > SP. Will a SP in Topeka trust a SP in Oslo enough to establish a > direct > peering arrangement? Without that direct peer, how will the > subscribers > of the Topeka SP access the folks in Oslo? One model that has been discussed on this list is the email model, which is that ITSPs just run open networks. Given that I receive on the order of 900 spam emails a day, I do not think ITSPs will be opening up to this arrangement any time soon. > An intermediary most likely > will be involved with the value being reachability and trust that > should > a call be sent to the transit provider, it will be completed as > intended > by the calling party. There are entities that do this today, except they don't do transit (usually). They are known as VoIP peering exchanges. > At the end of the day, it will be the one that > will complete the call that gets the buck. And most don't have call termination charges. -andy --=_zeke.ecotroph.net-21466-1150289801-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.0
I couldn't agree more.=A0 Commen= ts inline:

On Jun 13, 2006, at 9:48 PM, Uzelac, Adam w= rote:

A service provide would be b= est served to provide its subscribers a way

to contact anyone else.=A0 The burden to facilitate that session is on the

SP.=A0 Will a SP in Topeka trust a SP in Oslo enough= to establish a direct

=A0 Wi= thout that direct peer, how will the subscribers

of the Topeka SP access the folks in Oslo?


One model that has been discussed on this list is the email model, whic= h is that ITSPs just run open networks.=A0 Given that I receive on the or= der of 900 spam emails a day, I do not think ITSPs will be opening up to = this arrangement any time soon.

= =A0 An intermediary most likely

will be involved with the value being reachability and = trust that should

a c= all be sent to the transit provider, it will be completed as intended

by the calling party.


There are entities that do this today, except they don't do transit= (usually).=A0 They are known as VoIP peering exchanges.

At the end o= f the day, it will be the one that

will complete the call that gets the buck.=A0


And= most don't have call termination charges.

-andy

--=_zeke.ecotroph.net-21466-1150289801-0001-2-- --===============2109847734== 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 --===============2109847734==-- From speermint-bounces@ietf.org Thu Jun 15 12:31:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqukL-0004go-6O; Thu, 15 Jun 2006 12:31:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqukK-0004gi-OP for speermint@ietf.org; Thu, 15 Jun 2006 12:31:04 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqukG-0007Mx-Jl for speermint@ietf.org; Thu, 15 Jun 2006 12:31:04 -0400 Received: from ([10.20.9.174]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.21362780; Thu, 15 Jun 2006 12:30:32 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 12:30:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Thu, 15 Jun 2006 12:30:31 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96581FE6@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture thread-index: AcaPLboXGAjzdOy9T/KTTgSnBTPO9wBawAiA From: "Livingood, Jason" To: "Otmar Lendl" X-OriginalArrivalTime: 15 Jun 2006 16:30:31.0897 (UTC) FILETIME=[053DCC90:01C69099] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 > Whether some local SP from Hawaii will bother to establish=20 > peerings with one from Finland will depend on calling=20 > patterns and the administrative overhead of establishing the peering. I'd certainly like to see that we get that admin overhead as low / minimal as possible. To use a buzzword, it should be as 'frictionless' as possible. ;-) Which is basically, easy, efficient, quick, etc. Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 15 12:32:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqum5-0006Ms-W1; Thu, 15 Jun 2006 12:32:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqum5-0006Mn-1r for speermint@ietf.org; Thu, 15 Jun 2006 12:32:53 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqum0-0007kQ-UQ for speermint@ietf.org; Thu, 15 Jun 2006 12:32:53 -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] Updated Draft: SPEERMINT Peering Architecture Date: Thu, 15 Jun 2006 12:32:12 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96581FE7@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture thread-index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIB/RgscAFELq5AABtVn4AAF8v/4ABRx6Pw From: "Livingood, Jason" To: "Uzelac, Adam" X-OriginalArrivalTime: 15 Jun 2006 16:32:12.0719 (UTC) FILETIME=[415603F0:01C69099] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 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 Very interesting response. I think you have highlighted again why the co-chairs feel that security and trust are major areas of concern and work for the group. Jason=20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 > Sent: Tuesday, June 13, 2006 9:49 PM > To: Michael Hammer (mhammer); Patrick Melampy; Stastny=20 > Richard; Reinaldo Penno; Otmar Lendl > Cc: speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Piping in here to make a point or two - Two realistic=20 > requirements that oftentimes are overlooked in global peering=20 > bar-napkin discussions, and possibly assumed in the PSTN=20 > world, are trust and scale. I argue that the P2P world of=20 > direct interconnection/peering, though preferred for obvious=20 > technical reasons, can't be realized practically due to scale=20 > limitations and an inherent lack of trust. Therefore these 2=20 > items should be kept in mind when scheming up a solution for=20 > global peering dominance. (/me puts pinky finger to mouth and=20 > mutters, "1 million dollars"! muhahaha) ;) =20 >=20 > A service provide would be best served to provide its=20 > subscribers a way to contact anyone else. The burden to=20 > facilitate that session is on the SP. Will a SP in Topeka=20 > trust a SP in Oslo enough to establish a direct peering=20 > arrangement? Without that direct peer, how will the=20 > subscribers of the Topeka SP access the folks in Oslo? An=20 > intermediary most likely will be involved with the value=20 > being reachability and trust that should a call be sent to=20 > the transit provider, it will be completed as intended by the=20 > calling party. At the end of the day, it will be the one that=20 > will complete the call that gets the buck. Unfortunately=20 > it's the PSTN that facilitates that Topeka to Oslo call today=20 > more often than not. >=20 > -Adam >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, June 13, 2006 10:38 AM > To: Patrick Melampy; Stastny Richard; Reinaldo Penno; Otmar Lendl > Cc: speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture >=20 > Patrick, >=20 > Let us take these one at a time. Inline.=20 >=20 > > -----Original Message----- > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Sent: Monday, June 12, 2006 9:34 PM > > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Reinaldo Penno';=20 > > 'Otmar Lendl' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering=20 > Architecture > >=20 > > I'd like to comment as follows: > >=20 > > You said: > > > I believe the reality will be that there will ultimately > > be two options: > > > - from one SP (carrier/enterprise) to another there is > > direct peering, > > > - from one SP to another there is no direct peering and a > > "Tier 1"=20 > > > SP will be used for transit. > >=20 > > Unless somebody representing a carrier makes this=20 > statement, it's safe >=20 > > to say we are just guessing. I find this statement your=20 > making to lack >=20 > > any backing. How many Autonomous Systems do your communications go=20 > > through today? When you're at work? > > When you're at home? I'm guessing you have no idea. Why should this=20 > > group ever designate a role for a Tier 1 SP as a required=20 > > internetworking element? If you worked at a competitive Tier 2 you=20 > > might take exception to your statement. >=20 > The basis for this statement is an assumption that for=20 > security and economic reasons, you must have rules of=20 > engagement in order to connect to a peer. If there is a=20 > business arrangement, you can directly connect, if not then=20 > an intermediary is used. This is rather simple and straight=20 > forward. This does not preclude you creating a=20 > wide-open-to-the-Internet federation through which anyone can=20 > connect to you. >=20 > I am simply stating there are two options: direct and=20 > indirect. Is there a third possibility? >=20 > =20 > > > My thinking, if it is not obvious is that the optimal > > number of SPs is > > > 2 (direct peering). > >=20 > > Optimal in whose frame of reference? The internet's? The=20 > caller? The=20 > > callee? > > The carrier(s)? My guess is your thinking of the internet.=20 >=20 > The most optimal is directly from client to client, ie. true=20 > P2P. But, I am relaxing that here to the assumption that an=20 > end device may "outsource" some degree of features and=20 > functionality to a SP, be that enterprise PBX or carrier system. >=20 > It is optimal because we are talking about two parties, the=20 > caller and called parties. For that you could have an=20 > origination system and a termination system. Anything beyond=20 > that is extraneous middlemen that add cost into the picture,=20 > but not much in the way of added value, and a lot of=20 > possibility for unintended consequences to screw up the=20 > signaling or media. >=20 > Case in point: Every additional signaling point on the path=20 > will exacerbate call setup delay and increase the complexity=20 > of the interactions amongst all these components. >=20 > Case in point: Every additional media anchor will add delay=20 > to the RTP stream, thus negatively affecting QoS. >=20 > So, from the perspective of the caller and callee, the=20 > service experience will be better if SPs can minimize the=20 > number of extra moving parts in the system. >=20 > And, from the perspective of the SP, the fewer middlemen in=20 > the picture, the fewer the profits to share amongst those middlemen. >=20 > I am just applying Occam's Razor to get the minimalist set. >=20 > =20 > > > Second best is 3 (one transit). =20 > > Why is one transit carrier better than 2 or 3? Is it cost?=20 > > Quality? Where did this conclusion come from? Are there any=20 > IP based=20 > > models where a single backbone carrier is considered=20 > optimal? Doesn't=20 > > this limit competition and choice? Wouldn't it be anti-competitive,=20 > > and thus not be net-neutral? >=20 > I am suggesting that if both caller and callee have the good=20 > fortune to prefer the same transit carrier, then the savings=20 > from avoiding a second SP can be shared. This is what is=20 > experienced when a call stays within a single enterprise. =20 > This is what happens when you have a "friends and family" scenario. >=20 > It is both a business advantage and a technical advantage to=20 > have only one SP's policies to care about. No interworking! >=20 > =20 > > >Maximum number is 4 (one originating and one terminating transit). > >=20 > > Why is this the maxium?=20 >=20 > What would a third tranist carrier provide that could not be=20 > better provided if transit carrier 1 and 2 had a direct=20 > signaling agreement between them? How is sharing revenues=20 > amongst 3 carriers better than shared betweeen 2? >=20 >=20 > > I hate to argue with your statements, but they should be better=20 > > defended. >=20 > Hopefully, I have done so. :) >=20 >=20 > > There are a lot of managed networks that are both legislated and or=20 > > pre-existing. >=20 > I don't want our creativity to be limited by arbitrary=20 > government fiat, nor by lack of imagination constrained to=20 > repeat simply what already exists. >=20 >=20 > > The owners of long haul fiber networks want to use them for=20 > signaled=20 > > media. >=20 > Nothing precludes this. This is a layer 3 issue. I am not=20 > saying that to connect one signaling point to another that=20 > there can not be a VPN over a third IP carrier. Don't=20 > confuse Layer 5 with Layer 3 issues. >=20 >=20 > > My guess is we will not > > only have One Tier 1 to choose from, but the following: > >=20 > > 1.) Each Enterprise will desire at least 2 interconnect carriers to=20 > > ensure they have the lowest cost and best level of service with=20 > > redundancy. >=20 > My statements don't preclude this. >=20 > =20 > > 2.) Each Tier 1 Carrier will want to purchase termination=20 > services for >=20 > > its customers and have multiple paths to each major=20 > desination domain >=20 > Not precluded. >=20 > =20 > > 3.) Many Tier 2 and Tier 3 carriers will exist by selecting=20 > specific=20 > > target markets and verticals. >=20 > Define Tier 2 and 3. I think you have descended into Layer 3 here. >=20 > =20 > > 4.) Governments will continue to try to enforce regulations=20 > > guaranteeing a competitive landscape for communication=20 > interconnects=20 > > (requiring access for 2nd and 3rd carrier options. >=20 > See previous. >=20 > =20 > > I could go on and on. I would suggest that we embrace the=20 > realities of >=20 > > our world as requirements for this standards group. >=20 > Belive me, I am being very realistic. Allow room for=20 > arbitrage and it will occur. Economics will drive out an=20 > inefficiency in routing, so long as a better path exists. >=20 > If you do go on and on, would you please also indicate what=20 > added value any such intermediaries provide? So far, you=20 > have only indicated that they have existed in the past. =20 > While their value may have been grounded in the regulatory=20 > and business climate of the past, past history that does not=20 > take into account new technical realities amounts to just=20 > rebuilding the PSTN because that's the way we did it with=20 > TDM. I don't find such arguments persuasive. >=20 > Mike >=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 Jun 15 18:34:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0Pf-0001pY-Q2; Thu, 15 Jun 2006 18:34:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0Pd-0001pT-Ry for speermint@ietf.org; Thu, 15 Jun 2006 18:34:05 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr0Pa-0004M0-HM for speermint@ietf.org; Thu, 15 Jun 2006 18:34:05 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5FMY1J7014857 for ; Thu, 15 Jun 2006 16:34:01 -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: [speermint] minimum set of requirements for SIP-based VoIP interconnection and emergency calling Date: Thu, 15 Jun 2006 16:34:01 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum set of requirements for SIP-based VoIP interconnection and emergency calling Thread-Index: AcaQy9UFQqph1OmmQkG3q7q/eD4eXw== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Should the special case of emergency calls be considered as part of the use cases for the 'minimum' set of requirements for SIP-based VoIP interconnection? If so, what should the minimum set of requirements be for SIP voice interconnects? Unless this is done somewhere else in the context of voice interconnects, I think it should be in scope given the definition of VSP in the speermint terminology draft and the real use cases of VSPs handing off 911 calls to other service provider or terminating calls to 911 psaps. That said, those requirements should probably be left at the SIP level and remain at a high-level given the work in sipping, ecrit and various national bodies.=20 E.g. - a VSP should be able to recognize the SOS URN or any other well known markers such as a local dialing string for emergency calls as an emergency session - a VSP should invoke special SIP routing procedures to hand the call off to the correct PSAP - put SIP Priority header - support SIP location conveyance I-D? - etc. Any thoughts and comments are appreciated. Jean-Francois. email: jfm@cablelabs.com=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 15 18:42:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0XN-0007SP-03; Thu, 15 Jun 2006 18:42:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0XL-0007MR-P0 for speermint@ietf.org; Thu, 15 Jun 2006 18:42:03 -0400 Received: from mail2.nextone.com ([209.125.86.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr0XK-0004hU-Gx for speermint@ietf.org; Thu, 15 Jun 2006 18:42:03 -0400 Received: from moe.nextone.local ([192.168.15.38]) by mail2.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 18:42:02 -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] minimum set of requirements for SIP-based VoIPinterconnection and emergency calling Date: Thu, 15 Jun 2006 18:41:57 -0400 Message-ID: <8812D8156467224C9E9739E513037EF1C91FCB@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum set of requirements for SIP-based VoIPinterconnection and emergency calling Thread-Index: AcaQy9UFQqph1OmmQkG3q7q/eD4eXwAAJE2A From: "Bob Natale" To: "Jean-Francois Mule" X-OriginalArrivalTime: 15 Jun 2006 22:42:02.0210 (UTC) FILETIME=[EB4DA420:01C690CC] 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 =20 Hi Jean-Francois, I agree with your general position on this and the first three of your five bullet-list items. (I don't know enough about the location conveyance I-D to have a position and I'll wait on the etc item :) We should probably do a close scrub of the latest ECRIT requirements doc to ensure coverage and adopt appropriate terminology where applicable. Cheers, BobN -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Thursday, June 15, 2006 6:34 PM To: speermint@ietf.org Subject: [speermint] minimum set of requirements for SIP-based VoIPinterconnection and emergency calling Should the special case of emergency calls be considered as part of the use cases for the 'minimum' set of requirements for SIP-based VoIP interconnection? If so, what should the minimum set of requirements be for SIP voice interconnects? Unless this is done somewhere else in the context of voice interconnects, I think it should be in scope given the definition of VSP in the speermint terminology draft and the real use cases of VSPs handing off 911 calls to other service provider or terminating calls to 911 psaps. That said, those requirements should probably be left at the SIP level and remain at a high-level given the work in sipping, ecrit and various national bodies.=20 E.g. - a VSP should be able to recognize the SOS URN or any other well known markers such as a local dialing string for emergency calls as an emergency session - a VSP should invoke special SIP routing procedures to hand the call off to the correct PSAP - put SIP Priority header - support SIP location conveyance I-D? - etc. Any thoughts and comments are appreciated. Jean-Francois. email: jfm@cablelabs.com=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 Jun 16 04:06:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr9Lw-0005Wz-Tm; Fri, 16 Jun 2006 04:06:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr9Lw-0005Wu-3M for speermint@ietf.org; Fri, 16 Jun 2006 04:06:52 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fr9Lt-0003DI-K2 for speermint@ietf.org; Fri, 16 Jun 2006 04:06:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [speermint] minimum set of requirements for SIP-basedVoIPinterconnection and emergency calling Date: Fri, 16 Jun 2006 10:07:39 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AE4@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum set of requirements for SIP-basedVoIPinterconnection and emergency calling Thread-Index: AcaQy9UFQqph1OmmQkG3q7q/eD4eXwAAJE2AABPiXXI= From: "Stastny Richard" To: "Bob Natale" , "Jean-Francois Mule" 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 Sorry, but I doubt that emergency services is within the scope of = speermint =20 For emergency services normally either the UA itself or the first hop = proxy is responsible, so it never reaches the peering point at all =20 -sta ________________________________ Von: Bob Natale [mailto:bnatale@nextone.com] Gesendet: Fr 16.06.2006 00:41 An: Jean-Francois Mule Cc: speermint@ietf.org Betreff: RE: [speermint] minimum set of requirements for = SIP-basedVoIPinterconnection and emergency calling Hi Jean-Francois, I agree with your general position on this and the first three of your five bullet-list items. (I don't know enough about the location conveyance I-D to have a position and I'll wait on the etc item :) We should probably do a close scrub of the latest ECRIT requirements doc to ensure coverage and adopt appropriate terminology where applicable. Cheers, BobN -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] Sent: Thursday, June 15, 2006 6:34 PM To: speermint@ietf.org Subject: [speermint] minimum set of requirements for SIP-based VoIPinterconnection and emergency calling Should the special case of emergency calls be considered as part of the use cases for the 'minimum' set of requirements for SIP-based VoIP interconnection? If so, what should the minimum set of requirements be for SIP voice interconnects? Unless this is done somewhere else in the context of voice interconnects, I think it should be in scope given the definition of VSP in the speermint terminology draft and the real use cases of VSPs handing off 911 calls to other service provider or terminating calls to 911 psaps. That said, those requirements should probably be left at the SIP level and remain at a high-level given the work in sipping, ecrit and various national bodies. E.g. - a VSP should be able to recognize the SOS URN or any other well known markers such as a local dialing string for emergency calls as an emergency session - a VSP should invoke special SIP routing procedures to hand the call off to the correct PSAP - put SIP Priority header - support SIP location conveyance I-D? - etc. Any thoughts and comments are appreciated. Jean-Francois. email: jfm@cablelabs.com _______________________________________________ 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 Jun 16 05:04:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAFj-0006JO-Ac; Fri, 16 Jun 2006 05:04:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAFh-0006JD-No for speermint@ietf.org; Fri, 16 Jun 2006 05:04:29 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrAFg-0005g2-Dq for speermint@ietf.org; Fri, 16 Jun 2006 05:04:29 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5G94RhH015779; Fri, 16 Jun 2006 03:04:27 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [speermint] minimum set of requirements for SIP-basedVoIPinterconnection and emergency calling Date: Fri, 16 Jun 2006 03:04:27 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum set of requirements for SIP-basedVoIPinterconnection and emergency calling Thread-Index: AcaQy9UFQqph1OmmQkG3q7q/eD4eXwAAJE2AABPiXXIAAT+JAA== From: "Jean-Francois Mule" To: "Stastny Richard" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: > Sorry, but I doubt that emergency services is within the scope of > speermint > > For emergency services normally either the UA itself or the first hop > proxy is responsible, > so it never reaches the peering point at all ^^^^^ There are examples of VSP providers that do offer sip-based VoIP = interconnect services today including 9-1-1. So your assertion that = emergency calls do not reach "peering points" between VSPs is simply not = true (based on current practices and this is by no means = cable-specific). > For emergency services normally either the UA itself or the first hop > proxy is responsible I presume you mean responsible for "invoking the special routing = procedures caused by an emergency dialed string or use of SOS URN". This is ok but it does not necessarily mean that, upon determination = that the call is an emergency call, the originating VSP does have to = handle the SIP call to the PSAP within its own domain.=20 Some VSPs do have gateways connected to the PSTN and the whole selective = routers thingy in the North American system for example to do this; some = don't and hand off the call to another VSP. The question of who does the = ECRIT mapping protocol resolution is also not relevant here. My first question was: - should there be any minimal set of requirements (and ones = applicable beyond national standards) for handling emergency calls that = should be captured in a speermint requirement doc for SIP-based VoIP = interconnect? Jean-Fran=E7ois _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 16 05:21:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAWK-0001gs-Da; Fri, 16 Jun 2006 05:21:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAWJ-0001gk-7i for speermint@ietf.org; Fri, 16 Jun 2006 05:21:39 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrAWH-0006V9-QW for speermint@ietf.org; Fri, 16 Jun 2006 05:21:39 -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] minimum set of requirements for SIP-basedVoIPinterconnection and emergency calling Date: Fri, 16 Jun 2006 11:22:55 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AE6@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum set of requirements for SIP-basedVoIPinterconnection and emergency calling Thread-Index: AcaQy9UFQqph1OmmQkG3q7q/eD4eXwAAJE2AABPiXXIAAT+JAAABYWt/ From: "Stastny Richard" To: "Jean-Francois Mule" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 >Some VSPs do have gateways connected to the PSTN and the whole = selective routers thingy in the North American system for >example to do = this; some don't and hand off the call to another VSP. The question of = who does the ECRIT mapping protocol >resolution is also not relevant = here. Ok, but you mention here two issues out of speermint scope: gateways to = the PSTN and=20 North American selective router stuff =20 -sta ________________________________ Von: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] Gesendet: Fr 16.06.2006 11:04 An: Stastny Richard Cc: speermint@ietf.org Betreff: RE: [speermint] minimum set of requirements for = SIP-basedVoIPinterconnection and emergency calling Stastny Richard wrote: > Sorry, but I doubt that emergency services is within the scope of > speermint > > For emergency services normally either the UA itself or the first hop > proxy is responsible, > so it never reaches the peering point at all ^^^^^ There are examples of VSP providers that do offer sip-based VoIP = interconnect services today including 9-1-1. So your assertion that = emergency calls do not reach "peering points" between VSPs is simply not = true (based on current practices and this is by no means = cable-specific). > For emergency services normally either the UA itself or the first hop > proxy is responsible I presume you mean responsible for "invoking the special routing = procedures caused by an emergency dialed string or use of SOS URN". This is ok but it does not necessarily mean that, upon determination = that the call is an emergency call, the originating VSP does have to = handle the SIP call to the PSAP within its own domain. Some VSPs do have gateways connected to the PSTN and the whole selective = routers thingy in the North American system for example to do this; some = don't and hand off the call to another VSP. The question of who does the = ECRIT mapping protocol resolution is also not relevant here. My first question was: - should there be any minimal set of requirements (and ones = applicable beyond national standards) for handling emergency calls that = should be captured in a speermint requirement doc for SIP-based VoIP = interconnect? Jean-Fran=E7ois _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 16 07:39:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrCfi-0003Dv-Cy; Fri, 16 Jun 2006 07:39:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrCfg-00038k-UN for speermint@ietf.org; Fri, 16 Jun 2006 07:39:28 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrCff-0005YG-La for speermint@ietf.org; Fri, 16 Jun 2006 07:39:28 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5GBdQ0O010220; Fri, 16 Jun 2006 05:39:26 -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] minimum set of requirements for SIP-basedVoIPinterconnection and emergency calling Date: Fri, 16 Jun 2006 05:39:26 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum set of requirements for SIP-basedVoIPinterconnection and emergency calling Thread-Index: AcaQy9UFQqph1OmmQkG3q7q/eD4eXwAAJE2AABPiXXIAAT+JAAABYWt/AASiPWA= From: "Jean-Francois Mule" To: "Stastny Richard" X-Approved: ondar 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 Stastny Richard wrote: > >Some VSPs do have gateways connected to the PSTN and the whole > selective routers thingy in the North American system for >example to > do this; some don't and hand off the call to another VSP. The question > of who does the ECRIT mapping protocol >resolution is also not > relevant here. >=20 > Ok, but you mention here two issues out of speermint scope: gateways > to the PSTN and > North American selective router stuff And that is clearly out of scope. Per my earlier email, the scope question was related to the other case where emergency calls are not handled within a single VSP domain (or for that matter, the case of an enterprise using a SIP interconnect service and handing off all calls to the VSP).=20 Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 16 07:49:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrCpk-0001YN-W4; Fri, 16 Jun 2006 07:49:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrCpj-0001YI-Cn for speermint@ietf.org; Fri, 16 Jun 2006 07:49:51 -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 1FrCpi-0006EQ-4g for speermint@ietf.org; Fri, 16 Jun 2006 07:49:51 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id D2FFF34EC; Fri, 16 Jun 2006 07:49:47 -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, 16 Jun 2006 07:49:47 -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] minimum set of requirements forSIP-basedVoIPinterconnection and emergency calling Date: Fri, 16 Jun 2006 07:49:45 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum set of requirements forSIP-basedVoIPinterconnection and emergency calling Thread-Index: AcaQy9UFQqph1OmmQkG3q7q/eD4eXwAAJE2AABPiXXIAAT+JAAABYWt/AASiPWAAADvScA== From: "Uzelac, Adam" To: "Jean-Francois Mule" , "Stastny Richard" X-OriginalArrivalTime: 16 Jun 2006 11:49:47.0704 (UTC) FILETIME=[F7BBAB80:01C6913A] 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 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, Is this to mean that you believe emergency calling should be addressed within the scope of general peering arrangements, or you would like to see emergency requirements addressed in a specific emergency-like peering arrangement (possibly other services as well)? I think I could see that and one would not exclude the other. -AU -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Friday, June 16, 2006 7:39 AM To: Stastny Richard Cc: speermint@ietf.org Subject: RE: [speermint] minimum set of requirements forSIP-basedVoIPinterconnection and emergency calling Stastny Richard wrote: > >Some VSPs do have gateways connected to the PSTN and the whole > selective routers thingy in the North American system for >example to=20 > do this; some don't and hand off the call to another VSP. The question > of who does the ECRIT mapping protocol >resolution is also not=20 > relevant here. >=20 > Ok, but you mention here two issues out of speermint scope: gateways=20 > to the PSTN and North American selective router stuff And that is clearly out of scope. Per my earlier email, the scope question was related to the other case where emergency calls are not handled within a single VSP domain (or for that matter, the case of an enterprise using a SIP interconnect service and handing off all calls to the VSP).=20 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 From speermint-bounces@ietf.org Fri Jun 16 07:57:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrCwk-0006mn-FC; Fri, 16 Jun 2006 07:57:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrCwj-0006mi-Bt for speermint@ietf.org; Fri, 16 Jun 2006 07:57:05 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrCwh-0006Ym-2y for speermint@ietf.org; Fri, 16 Jun 2006 07:57:05 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-6.tower-121.messagelabs.com!1150458986!8063599!10 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 17104 invoked from network); 16 Jun 2006 11:57:02 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-6.tower-121.messagelabs.com with SMTP; 16 Jun 2006 11:57:02 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 44708FE9003A5E6F; Fri, 16 Jun 2006 07:57:01 -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] minimum set of requirements forSIP-basedVoIPinterconnection and emergency calling X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 16 Jun 2006 07:57:00 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0D0736D2@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum set of requirements forSIP-basedVoIPinterconnection and emergency calling thread-index: AcaQy9UFQqph1OmmQkG3q7q/eD4eXwAAJE2AABPiXXIAAT+JAAABYWt/AASiPWAAAK1sUA== From: "Pfautz, Penn L, GBLAM" To: "Jean-Francois Mule" , "Stastny Richard" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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'd be better served NOT to take up the emergency use case for now, until the other groups (GEOPRIV and ECRIT) solidify their requirements.=20 Penn -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Friday, June 16, 2006 7:39 AM To: Stastny Richard Cc: speermint@ietf.org Subject: RE: [speermint] minimum set of requirements forSIP-basedVoIPinterconnection and emergency calling Stastny Richard wrote: > >Some VSPs do have gateways connected to the PSTN and the whole > selective routers thingy in the North American system for >example to > do this; some don't and hand off the call to another VSP. The question > of who does the ECRIT mapping protocol >resolution is also not > relevant here. >=20 > Ok, but you mention here two issues out of speermint scope: gateways > to the PSTN and > North American selective router stuff And that is clearly out of scope. Per my earlier email, the scope question was related to the other case where emergency calls are not handled within a single VSP domain (or for that matter, the case of an enterprise using a SIP interconnect service and handing off all calls to the VSP).=20 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 From speermint-bounces@ietf.org Fri Jun 16 08:09:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrD92-0006QG-Vw; Fri, 16 Jun 2006 08:09:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrD91-0006QA-DS for speermint@ietf.org; Fri, 16 Jun 2006 08:09:47 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrD8z-0007Jz-W2 for speermint@ietf.org; Fri, 16 Jun 2006 08:09:47 -0400 Received: (qmail invoked by alias); 16 Jun 2006 12:09:44 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp023) with SMTP; 16 Jun 2006 14:09:44 +0200 X-Authenticated: #29516787 Message-ID: <44929F87.6030305@gmx.net> Date: Fri, 16 Jun 2006 14:09:43 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pfautz, Penn L, GBLAM" Subject: Re: [speermint] minimum set of requirements forSIP-basedVoIPinterconnection and emergency calling References: <34DA635B184A644DA4588E260EC0A25A0D0736D2@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0D0736D2@ACCLUST02EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: speermint@ietf.org, Stastny Richard 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 requirements work in ECRIT is finished. Here is the most recent document: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-10.txt It might be good to clearly describe what you want to accomplish with emgerency services in the context of peering. Ciao Hannes Pfautz, Penn L, GBLAM wrote: > I think we'd be better served NOT to take up the emergency use case for > now, until the other groups (GEOPRIV and ECRIT) solidify their > requirements. > > Penn > > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Friday, June 16, 2006 7:39 AM > To: Stastny Richard > Cc: speermint@ietf.org > Subject: RE: [speermint] minimum set of requirements > forSIP-basedVoIPinterconnection and emergency calling > > Stastny Richard wrote: > >>>Some VSPs do have gateways connected to the PSTN and the whole >> >>selective routers thingy in the North American system for >example to >>do this; some don't and hand off the call to another VSP. The question >>of who does the ECRIT mapping protocol >resolution is also not >>relevant here. >> >>Ok, but you mention here two issues out of speermint scope: gateways >>to the PSTN and >>North American selective router stuff > > > And that is clearly out of scope. > Per my earlier email, the scope question was related to the other case > where emergency calls are not handled within a single VSP domain (or for > that matter, the case of an enterprise using a SIP interconnect service > and handing off all calls to the VSP). > > 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 Fri Jun 16 08:10:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrD9b-0006YB-Hw; Fri, 16 Jun 2006 08:10:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrD9a-0006XY-4z for speermint@ietf.org; Fri, 16 Jun 2006 08:10:22 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrD9Y-0007Um-Nu for speermint@ietf.org; Fri, 16 Jun 2006 08:10:22 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5GCAFvg015243; Fri, 16 Jun 2006 06:10:15 -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] minimum set of requirements forSIP-basedVoIPinterconnection and emergency calling Date: Fri, 16 Jun 2006 06:10:15 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum set of requirements forSIP-basedVoIPinterconnection and emergency calling Thread-Index: AcaQy9UFQqph1OmmQkG3q7q/eD4eXwAAJE2AABPiXXIAAT+JAAABYWt/AASiPWAAADvScAAAnfkQ From: "Jean-Francois Mule" To: "Uzelac, Adam" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Adam, I'm generally interested in what folks believe should be in-scope and out of scope for the wg deliverable identified as "the minimum set of requirements for SIP-based VoIP interconnection (BCP)", and especially re: emergency calling. If the goal is a BCP and if today, various providers do have SIP interconnect agreements that include emergency calling, I thought it may be in scope, at least from a SIP requirement point of view per my email yesterday. Jean-Francois > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Friday, June 16, 2006 5:50 AM > To: Jean-Francois Mule; Stastny Richard > Cc: speermint@ietf.org > Subject: RE: [speermint] minimum set of requirements forSIP- > basedVoIPinterconnection and emergency calling >=20 > Jean-Francois, >=20 > Is this to mean that you believe emergency calling should be addressed > within the scope of general peering arrangements, or you would like to > see emergency requirements addressed in a specific emergency-like > peering arrangement (possibly other services as well)? I think I > could > see that and one would not exclude the other. >=20 > -AU >=20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Friday, June 16, 2006 7:39 AM > To: Stastny Richard > Cc: speermint@ietf.org > Subject: RE: [speermint] minimum set of requirements > forSIP-basedVoIPinterconnection and emergency calling >=20 > Stastny Richard wrote: > > >Some VSPs do have gateways connected to the PSTN and the whole > > selective routers thingy in the North American system for >example > to > > do this; some don't and hand off the call to another VSP. The > question >=20 > > of who does the ECRIT mapping protocol >resolution is also not > > relevant here. > > > > Ok, but you mention here two issues out of speermint scope: gateways > > to the PSTN and North American selective router stuff >=20 > And that is clearly out of scope. > Per my earlier email, the scope question was related to the other case > where emergency calls are not handled within a single VSP domain (or > for > that matter, the case of an enterprise using a SIP interconnect > service > and handing off all calls to the VSP). >=20 > Jean-Francois. >=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 Fri Jun 16 09:35:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrETm-0003Tl-F0; Fri, 16 Jun 2006 09:35:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrETl-0003Tg-Nr for speermint@ietf.org; Fri, 16 Jun 2006 09:35:17 -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 1FrETk-0003sw-Hd for speermint@ietf.org; Fri, 16 Jun 2006 09:35:17 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Fri, 16 Jun 2006 09:35:40 -0400 id 0158801A.4492B3AC.00004E16 Message-ID: <4492B389.5030601@hxr.us> Date: Fri, 16 Jun 2006 09:35:05 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [speermint] minimum set of requirements for SIP-basedVoIPinterconnection and emergency calling References: <32755D354E6B65498C3BD9FD496C7D462C4AE4@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4AE4@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: de4f315c9369b71d7dd5909b42224370 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: > Sorry, but I doubt that emergency services is within the scope of speermint I can't speak to this statement because I'm completely confused about the purpose of the working being conducted in this working group. > For emergency services normally either the UA itself or the first hop proxy is responsible, > so it never reaches the peering point at all But can you explain to me how you reached this conclusion? Do you expect UAs to directly connect to PSAP SIP servers? Are you ruling out a peering point because the ECRIT process results in a SIP URI and not a telephone number, and therefore a peering point won't be consulted? I don't get it. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 16 09:38:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEXD-0006GM-JP; Fri, 16 Jun 2006 09:38:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEXC-0006GH-UI for speermint@ietf.org; Fri, 16 Jun 2006 09:38:50 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrEXC-0004Du-ER for speermint@ietf.org; Fri, 16 Jun 2006 09:38:50 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5GDcjGG004426; Fri, 16 Jun 2006 07:38:45 -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] minimum set of requirements forSIP-basedVoIPinterconnection and emergency calling Date: Fri, 16 Jun 2006 07:38:44 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum set of requirements forSIP-basedVoIPinterconnection and emergency calling Thread-Index: AcaRPcP38JvOP9K8SoS3IFLxR4eufAABiQ+Q From: "Jean-Francois Mule" To: "Hannes Tschofenig" , "Pfautz, Penn L, GBLAM" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 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 Penn and Hannes, Thanks for the input. Here is an attempt to clarify what could be in scope of speermint.=20 Hannes wrote: > It might be good to clearly describe what you want to accomplish with > emgerency services in the context of peering. The potential goal would be to write the minimum requirements a VSP should comply with when handing off an emergency call to another administrative domain over IP through a VoIP interconnect point (SIP call termination to another third-party provider which in turn does terminate the call to a PSAP). Folks assume the work in GEOPRIV and ECRIT takes care of the above. The requirement gap I can see so far is based on: a) the requirement work in ECRIT is for IP-enabled PSAPs (US/nena i3). The ECRIT requirement document states: | This document only focuses on end-to-end IP-based calls, i.e., where | the emergency call originates from an IP end system and terminates | into an IP-capable PSAP, conveyed entirely over an IP network. b) GEOPRIV, ECRIT and SIPPING are concerned with location determination, emergency context resolution, location-based routing of the SIP call to the PSAP URI, location conveyance in SIP. c) SPEERMINT is about "architectures to identify, signal, and route delay-sensitive (real-time) communication sessions."... "These sessions use the SIP signaling protocol to enable peering between two or more administrative domains over IP networks." So, for example, the speermint requirement doc could state things like: - any applicable ECRIT requirements for exchanging emergency sip calls between 2 or more domains, - any SIP requirements that should be taken into consideration. For e.g. if available, convey location using sipping location conveyance. But also special handling of things like p-asserted-id when handing off emergency calls (if privacy is on in the originating domain, some VSPs remove p-asserted-id when handing out the call to another provider). In the case of an emergency call, for psap callback, p-asserted-id must/should be left in... so that the terminating VSP that connects to the PSAPs can identify the ANI. These are first thoughts to provide more examples. We could just have a couple of sentences highlighting the key requirements and giving pointers to consider when the handoff of emergency calls is possible. Penn wrote: > > I think we'd be better served NOT to take up the emergency use case > for > > now, until the other groups (GEOPRIV and ECRIT) solidify their > > requirements. This is fine and I'm ok not taking if we think we should just not take this for *now* but as Hannes points out, and as I tried to highlight above, we should not assume there will be a lot more requirement work in other IETF groups around the SIP interconnects and there may be some gaps (hence the scope question). Jean-Francois > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, June 16, 2006 6:10 AM > To: Pfautz, Penn L, GBLAM > Cc: Jean-Francois Mule; Stastny Richard; speermint@ietf.org > Subject: Re: [speermint] minimum set of requirements forSIP- > basedVoIPinterconnection and emergency calling >=20 > The requirements work in ECRIT is finished. Here is the most recent > document: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements- > 10.txt >=20 > It might be good to clearly describe what you want to accomplish with > emgerency services in the context of peering. >=20 > Ciao > Hannes >=20 >=20 > Pfautz, Penn L, GBLAM wrote: > > I think we'd be better served NOT to take up the emergency use case > for > > now, until the other groups (GEOPRIV and ECRIT) solidify their > > requirements. > > > > Penn > > > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > Sent: Friday, June 16, 2006 7:39 AM > > To: Stastny Richard > > Cc: speermint@ietf.org > > Subject: RE: [speermint] minimum set of requirements > > forSIP-basedVoIPinterconnection and emergency calling > > > > Stastny Richard wrote: > > > >>>Some VSPs do have gateways connected to the PSTN and the whole > >> > >>selective routers thingy in the North American system for >example > to > >>do this; some don't and hand off the call to another VSP. The > question > >>of who does the ECRIT mapping protocol >resolution is also not > >>relevant here. > >> > >>Ok, but you mention here two issues out of speermint scope: gateways > >>to the PSTN and > >>North American selective router stuff > > > > > > And that is clearly out of scope. > > Per my earlier email, the scope question was related to the other > case > > where emergency calls are not handled within a single VSP domain (or > for > > that matter, the case of an enterprise using a SIP interconnect > service > > and handing off all calls to the VSP). > > > > 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 Fri Jun 16 11:06:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFu5-0004gX-RA; Fri, 16 Jun 2006 11:06:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFu3-0004gS-No for speermint@ietf.org; Fri, 16 Jun 2006 11:06:31 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFu2-0004Hf-Ah for speermint@ietf.org; Fri, 16 Jun 2006 11:06:31 -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 k5GF6SA6024122 for ; Fri, 16 Jun 2006 08:06:29 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k5GF6NUX024121 for speermint@ietf.org; Fri, 16 Jun 2006 08:06:23 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 16 Jun 2006 08:06:23 -0700 From: David Meyer To: speermint@ietf.org Message-ID: <20060616150623.GA24114@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: 92df29fa99cf13e554b84c8374345c17 Subject: [Speermint] FYI -- [ietf-secretariat@ietf.org: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada] 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="===============0616632529==" Errors-To: speermint-bounces@ietf.org --===============0616632529== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from ietf-secretariat@ietf.org ----- > From: ietf-secretariat@ietf.org > To: ietf-announce@ietf.org > Cc:=20 > Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting > in Montreal, Quebec, Canada=20 > Date: Fri, 16 Jun 2006 00:00:01 -0400 >=20 >=20 > There are two (2) Internet-Draft cutoff dates for the 66th=20 > IETF Meeting in Montreal, Quebec, Canada: >=20 > June 19th: Cutoff Date for Initial (i.e., version -00)=20 > Internet-Draft Submissions=20 >=20 > All initial Internet-Drafts (version -00) must be submitted by Monday,=20 > June 19th at 9:00 AM ET. As always, all initial submissions with a=20 > filename beginning with "draft-ietf" must be approved by the=20 > appropriate WG Chair before they can be processed or announced. The=20 > Secretariat would appreciate receiving WG Chair approval by Monday,=20 > June 12th at 9:00 AM ET. >=20 > June 26th: Cutoff Date for Revised (i.e., version -01 and higher)=20 > Internet-Draft Submissions=20 >=20 > All revised Internet-Drafts (version -01 and higher) must be submitted=20 > by Monday, June 26th at 9:00 AM ET. >=20 > Initial and revised Internet-Drafts received after their respective=20 > cutoff dates will not be made available in the Internet-Drafts=20 > directory or announced until on or after Monday, July 10th at 9:00=20 > AM ET, when Internet-Draft posting resumes. Please do not wait until=20 > the last minute to submit. >=20 > Thank you for your understanding and cooperation. If you have any=20 > questions or concerns, then please send a message to=20 > internet-drafts@ietf.org. >=20 > The IETF Secretariat >=20 > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 66th IETF Meeting can be found at http://www.ietf.org/meetings/cu= toff_dates_66.html. >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEksjvORgD1qCZ2KcRAkQ5AJ9AgMVy2n4P67APXe2keqnvMkzOWwCfbBNt eSiFHeEyRbBCzW4sgvqYGys= =L7LB -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- --===============0616632529== 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 --===============0616632529==-- From speermint-bounces@ietf.org Fri Jun 16 15:44:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKFQ-0003K0-CA; Fri, 16 Jun 2006 15:44:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKFP-0003Jm-7T for speermint@ietf.org; Fri, 16 Jun 2006 15:44:51 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrKFN-0000MB-Ia for speermint@ietf.org; Fri, 16 Jun 2006 15:44:51 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 16 Jun 2006 12:44:49 -0700 X-IronPort-AV: i="4.06,144,1149490800"; d="scan'208"; a="296080194:sNHT52388184" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5GJimZ5004907; Fri, 16 Jun 2006 12:44:48 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5GJilIs010970; Fri, 16 Jun 2006 12:44:48 -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.211); Fri, 16 Jun 2006 15:44: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] minimum set ofrequirements forSIP-basedVoIPinterconnection and emergency calling Date: Fri, 16 Jun 2006 15:44:45 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30197C0EE@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum set ofrequirements forSIP-basedVoIPinterconnection and emergency calling Thread-Index: AcaRPcP38JvOP9K8SoS3IFLxR4eufAABiQ+QAA44w/A= From: "Michael Hammer \(mhammer\)" To: "Jean-Francois Mule" , "Hannes Tschofenig" , "Pfautz, Penn L, GBLAM" X-OriginalArrivalTime: 16 Jun 2006 19:44:46.0632 (UTC) FILETIME=[526AFA80:01C6917D] DKIM-Signature: a=rsa-sha1; q=dns; l=6883; t=1150487088; x=1151351088; c=relaxed/simple; s=sjdkim5001; 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]=20minimum=20set=20ofrequirements=09forSIP-basedVoIPi nterconnection=20and=20emergency=20calling; X=v=3Dcisco.com=3B=20h=3DSO8Ti2IdwvsijfHiaV6fq7ziQrU=3D; b=VdiY72yy+sD0tuNGbiq/3wmwEhere/vKGsQrAp7heZICQuQVurWojOhWjyn/p2epvKXJerDR Lr7aDhE8rwyyfs9MRcPjPgYZHUnrcYtESi7v+f1NxVPdWVz2f9ifvZIc; Authentication-Results: sj-dkim-5.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 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 All, Let me ask the question a different way: Will all PSAPs belong to the same federation (a special PSAP federation that defines the rules for accessing PSAP domains), or will all PSAPs belong to various federations, where the rules for handling SIP messages and what is needed for SOS calls is defined by each federations? Put me in the column for holding off on special cases of calls being addressed until we have worked out the basic call case. By then, perhaps the ECRIT WG will have made further progress on the SOS call delivery mechanisms and associated protocol elements. Mike =20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Friday, June 16, 2006 9:39 AM > To: Hannes Tschofenig; Pfautz, Penn L, GBLAM > Cc: Stastny Richard; speermint@ietf.org > Subject: RE: [speermint] minimum set ofrequirements=20 > forSIP-basedVoIPinterconnection and emergency calling >=20 > Penn and Hannes, >=20 > Thanks for the input. Here is an attempt to clarify what=20 > could be in scope of speermint.=20 >=20 > Hannes wrote: > > It might be good to clearly describe what you want to=20 > accomplish with=20 > > emgerency services in the context of peering. >=20 > The potential goal would be to write the minimum requirements=20 > a VSP should comply with when handing off an emergency call=20 > to another administrative domain over IP through a VoIP=20 > interconnect point (SIP call termination to another=20 > third-party provider which in turn does terminate the call to a PSAP). >=20 > Folks assume the work in GEOPRIV and ECRIT takes care of the above. > The requirement gap I can see so far is based on: > a) the requirement work in ECRIT is for IP-enabled PSAPs (US/nena i3). > The ECRIT requirement document states: > | This document only focuses on end-to-end IP-based calls,=20 > i.e., where=20 > | the emergency call originates from an IP end system and terminates=20 > | into an IP-capable PSAP, conveyed entirely over an IP network. >=20 > b) GEOPRIV, ECRIT and SIPPING are concerned with location=20 > determination, emergency context resolution, location-based=20 > routing of the SIP call to the PSAP URI, location conveyance in SIP. >=20 > c) SPEERMINT is about "architectures to identify, signal, and=20 > route delay-sensitive (real-time) communication sessions."...=20 > "These sessions use the SIP signaling protocol to enable=20 > peering between two or more administrative domains over IP networks." >=20 > So, for example, the speermint requirement doc could state=20 > things like: > - any applicable ECRIT requirements for exchanging=20 > emergency sip calls between 2 or more domains, > - any SIP requirements that should be taken into consideration. > For e.g. if available, convey location using sipping location=20 > conveyance. But also special handling of things like=20 > p-asserted-id when handing off emergency calls (if privacy is=20 > on in the originating domain, some VSPs remove p-asserted-id=20 > when handing out the call to another provider). In the case=20 > of an emergency call, for psap callback, p-asserted-id=20 > must/should be left in... so that the terminating VSP that=20 > connects to the PSAPs can identify the ANI. >=20 > These are first thoughts to provide more examples. We could=20 > just have a couple of sentences highlighting the key=20 > requirements and giving pointers to consider when the handoff=20 > of emergency calls is possible. >=20 > Penn wrote: > > > I think we'd be better served NOT to take up the=20 > emergency use case > > for > > > now, until the other groups (GEOPRIV and ECRIT) solidify their=20 > > > requirements. > This is fine and I'm ok not taking if we think we should just=20 > not take this for *now* but as Hannes points out, and as I=20 > tried to highlight above, we should not assume there will be=20 > a lot more requirement work in other IETF groups around the=20 > SIP interconnects and there may be some gaps (hence the scope=20 > question). >=20 > Jean-Francois >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Friday, June 16, 2006 6:10 AM > > To: Pfautz, Penn L, GBLAM > > Cc: Jean-Francois Mule; Stastny Richard; speermint@ietf.org > > Subject: Re: [speermint] minimum set of requirements forSIP-=20 > > basedVoIPinterconnection and emergency calling > >=20 > > The requirements work in ECRIT is finished. Here is the most recent > > document: > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements- > > 10.txt > >=20 > > It might be good to clearly describe what you want to=20 > accomplish with=20 > > emgerency services in the context of peering. > >=20 > > Ciao > > Hannes > >=20 > >=20 > > Pfautz, Penn L, GBLAM wrote: > > > I think we'd be better served NOT to take up the=20 > emergency use case > > for > > > now, until the other groups (GEOPRIV and ECRIT) solidify their=20 > > > requirements. > > > > > > Penn > > > > > > -----Original Message----- > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > Sent: Friday, June 16, 2006 7:39 AM > > > To: Stastny Richard > > > Cc: speermint@ietf.org > > > Subject: RE: [speermint] minimum set of requirements=20 > > > forSIP-basedVoIPinterconnection and emergency calling > > > > > > Stastny Richard wrote: > > > > > >>>Some VSPs do have gateways connected to the PSTN and the whole > > >> > > >>selective routers thingy in the North American system for >example > > to > > >>do this; some don't and hand off the call to another VSP. The > > question > > >>of who does the ECRIT mapping protocol >resolution is also not=20 > > >>relevant here. > > >> > > >>Ok, but you mention here two issues out of speermint=20 > scope: gateways=20 > > >>to the PSTN and North American selective router stuff > > > > > > > > > And that is clearly out of scope. > > > Per my earlier email, the scope question was related to the other > > case > > > where emergency calls are not handled within a single VSP=20 > domain (or > > for > > > that matter, the case of an enterprise using a SIP interconnect > > service > > > and handing off all calls to the VSP). > > > > > > 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 > > > > > > >=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 Jun 16 16:08:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKcY-0003fj-0F; Fri, 16 Jun 2006 16:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKcX-0003fZ-2E for speermint@ietf.org; Fri, 16 Jun 2006 16:08:45 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrKcW-0003qJ-BK for speermint@ietf.org; Fri, 16 Jun 2006 16:08: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 Subject: Re: [speermint] minimum set ofrequirements forSIP-basedVoIPinterconnection and emergency calling Date: Fri, 16 Jun 2006 22:11:54 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AEA@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum set ofrequirements forSIP-basedVoIPinterconnection and emergency calling Thread-Index: AcaRPcP38JvOP9K8SoS3IFLxR4eufAABiQ+QAA44w/AAARRuNg== From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "Jean-Francois Mule" 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 could live with this proposal =20 -sta ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Fr 16.06.2006 21:44 An: Jean-Francois Mule; Hannes Tschofenig; Pfautz, Penn L, GBLAM Cc: Stastny Richard; speermint@ietf.org Betreff: RE: [speermint] minimum set ofrequirements = forSIP-basedVoIPinterconnection and emergency calling All, Let me ask the question a different way: Will all PSAPs belong to the same federation (a special PSAP federation that defines the rules for accessing PSAP domains), or will all PSAPs belong to various federations, where the rules for handling SIP messages and what is needed for SOS calls is defined by each federations? Put me in the column for holding off on special cases of calls being addressed until we have worked out the basic call case. By then, perhaps the ECRIT WG will have made further progress on the SOS call delivery mechanisms and associated protocol elements. Mike > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Friday, June 16, 2006 9:39 AM > To: Hannes Tschofenig; Pfautz, Penn L, GBLAM > Cc: Stastny Richard; speermint@ietf.org > Subject: RE: [speermint] minimum set ofrequirements > forSIP-basedVoIPinterconnection and emergency calling > > Penn and Hannes, > > Thanks for the input. Here is an attempt to clarify what > could be in scope of speermint. > > Hannes wrote: > > It might be good to clearly describe what you want to > accomplish with > > emgerency services in the context of peering. > > The potential goal would be to write the minimum requirements > a VSP should comply with when handing off an emergency call > to another administrative domain over IP through a VoIP > interconnect point (SIP call termination to another > third-party provider which in turn does terminate the call to a PSAP). > > Folks assume the work in GEOPRIV and ECRIT takes care of the above. > The requirement gap I can see so far is based on: > a) the requirement work in ECRIT is for IP-enabled PSAPs (US/nena i3). > The ECRIT requirement document states: > | This document only focuses on end-to-end IP-based calls, > i.e., where > | the emergency call originates from an IP end system and terminates > | into an IP-capable PSAP, conveyed entirely over an IP network. > > b) GEOPRIV, ECRIT and SIPPING are concerned with location > determination, emergency context resolution, location-based > routing of the SIP call to the PSAP URI, location conveyance in SIP. > > c) SPEERMINT is about "architectures to identify, signal, and > route delay-sensitive (real-time) communication sessions."... > "These sessions use the SIP signaling protocol to enable > peering between two or more administrative domains over IP networks." > > So, for example, the speermint requirement doc could state > things like: > - any applicable ECRIT requirements for exchanging > emergency sip calls between 2 or more domains, > - any SIP requirements that should be taken into consideration. > For e.g. if available, convey location using sipping location > conveyance. But also special handling of things like > p-asserted-id when handing off emergency calls (if privacy is > on in the originating domain, some VSPs remove p-asserted-id > when handing out the call to another provider). In the case > of an emergency call, for psap callback, p-asserted-id > must/should be left in... so that the terminating VSP that > connects to the PSAPs can identify the ANI. > > These are first thoughts to provide more examples. We could > just have a couple of sentences highlighting the key > requirements and giving pointers to consider when the handoff > of emergency calls is possible. > > Penn wrote: > > > I think we'd be better served NOT to take up the > emergency use case > > for > > > now, until the other groups (GEOPRIV and ECRIT) solidify their > > > requirements. > This is fine and I'm ok not taking if we think we should just > not take this for *now* but as Hannes points out, and as I > tried to highlight above, we should not assume there will be > a lot more requirement work in other IETF groups around the > SIP interconnects and there may be some gaps (hence the scope > question). > > Jean-Francois > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Friday, June 16, 2006 6:10 AM > > To: Pfautz, Penn L, GBLAM > > Cc: Jean-Francois Mule; Stastny Richard; speermint@ietf.org > > Subject: Re: [speermint] minimum set of requirements forSIP- > > basedVoIPinterconnection and emergency calling > > > > The requirements work in ECRIT is finished. Here is the most recent > > document: > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements- > > 10.txt > > > > It might be good to clearly describe what you want to > accomplish with > > emgerency services in the context of peering. > > > > Ciao > > Hannes > > > > > > Pfautz, Penn L, GBLAM wrote: > > > I think we'd be better served NOT to take up the > emergency use case > > for > > > now, until the other groups (GEOPRIV and ECRIT) solidify their > > > requirements. > > > > > > Penn > > > > > > -----Original Message----- > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > Sent: Friday, June 16, 2006 7:39 AM > > > To: Stastny Richard > > > Cc: speermint@ietf.org > > > Subject: RE: [speermint] minimum set of requirements > > > forSIP-basedVoIPinterconnection and emergency calling > > > > > > Stastny Richard wrote: > > > > > >>>Some VSPs do have gateways connected to the PSTN and the whole > > >> > > >>selective routers thingy in the North American system for >example > > to > > >>do this; some don't and hand off the call to another VSP. The > > question > > >>of who does the ECRIT mapping protocol >resolution is also not > > >>relevant here. > > >> > > >>Ok, but you mention here two issues out of speermint > scope: gateways > > >>to the PSTN and North American selective router stuff > > > > > > > > > And that is clearly out of scope. > > > Per my earlier email, the scope question was related to the other > > case > > > where emergency calls are not handled within a single VSP > domain (or > > for > > > that matter, the case of an enterprise using a SIP interconnect > > service > > > and handing off all calls to the VSP). > > > > > > 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 > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 16 16:17:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKki-0006qr-UB; Fri, 16 Jun 2006 16:17:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKkh-0006q4-2v for speermint@ietf.org; Fri, 16 Jun 2006 16:17:11 -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 1FrKkg-0004jO-LT for speermint@ietf.org; Fri, 16 Jun 2006 16:17:11 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 57AED3521; Fri, 16 Jun 2006 16:17: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, 16 Jun 2006 16:17:10 -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] minimum set ofrequirementsforSIP-basedVoIPinterconnection and emergency calling Date: Fri, 16 Jun 2006 16:17:08 -0400 Message-ID: In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4AEA@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum set ofrequirementsforSIP-basedVoIPinterconnection and emergency calling Thread-Index: AcaRPcP38JvOP9K8SoS3IFLxR4eufAABiQ+QAA44w/AAARRuNgAADalw From: "Uzelac, Adam" To: "Stastny Richard" , "Michael Hammer (mhammer)" , "Jean-Francois Mule" X-OriginalArrivalTime: 16 Jun 2006 20:17:10.0054 (UTC) FILETIME=[D8C9A460:01C69181] X-Spam-Score: 0.1 (/) 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 I agree that focus on initial call flows is wise for the time being, but what's the harm in citing the requirement with fairly high-level generic wording for now?!?! FWIW - I join Mike in the "holding-off-a-bit-until-we-sort-out-basic-functionality" column. Crawl-Walk-Run. -AU -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Friday, June 16, 2006 4:12 PM To: Michael Hammer (mhammer); Jean-Francois Mule Cc: speermint@ietf.org Subject: Re: [speermint] minimum set ofrequirementsforSIP-basedVoIPinterconnection and emergency calling I could live with this proposal =20 -sta ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Fr 16.06.2006 21:44 An: Jean-Francois Mule; Hannes Tschofenig; Pfautz, Penn L, GBLAM Cc: Stastny Richard; speermint@ietf.org Betreff: RE: [speermint] minimum set ofrequirements forSIP-basedVoIPinterconnection and emergency calling All, Let me ask the question a different way: Will all PSAPs belong to the same federation (a special PSAP federation that defines the rules for accessing PSAP domains), or will all PSAPs belong to various federations, where the rules for handling SIP messages and what is needed for SOS calls is defined by each federations? Put me in the column for holding off on special cases of calls being addressed until we have worked out the basic call case. By then, perhaps the ECRIT WG will have made further progress on the SOS call delivery mechanisms and associated protocol elements. Mike > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Friday, June 16, 2006 9:39 AM > To: Hannes Tschofenig; Pfautz, Penn L, GBLAM > Cc: Stastny Richard; speermint@ietf.org > Subject: RE: [speermint] minimum set ofrequirements=20 > forSIP-basedVoIPinterconnection and emergency calling > > Penn and Hannes, > > Thanks for the input. Here is an attempt to clarify what could be=20 > in scope of speermint. > > Hannes wrote: > > It might be good to clearly describe what you want to > accomplish with > > emgerency services in the context of peering. > > The potential goal would be to write the minimum requirements a VSP=20 > should comply with when handing off an emergency call to another=20 > administrative domain over IP through a VoIP interconnect point (SIP=20 > call termination to another third-party provider which in turn does=20 > terminate the call to a PSAP). > > Folks assume the work in GEOPRIV and ECRIT takes care of the above. > The requirement gap I can see so far is based on: > a) the requirement work in ECRIT is for IP-enabled PSAPs (US/nena i3). > The ECRIT requirement document states: > | This document only focuses on end-to-end IP-based calls, > i.e., where > | the emergency call originates from an IP end system and terminates=20 > | into an IP-capable PSAP, conveyed entirely over an IP network. > > b) GEOPRIV, ECRIT and SIPPING are concerned with location=20 > determination, emergency context resolution, location-based routing of > the SIP call to the PSAP URI, location conveyance in SIP. > > c) SPEERMINT is about "architectures to identify, signal, and route=20 > delay-sensitive (real-time) communication sessions."... > "These sessions use the SIP signaling protocol to enable peering=20 > between two or more administrative domains over IP networks." > > So, for example, the speermint requirement doc could state things=20 > like: > - any applicable ECRIT requirements for exchanging emergency sip > calls between 2 or more domains, > - any SIP requirements that should be taken into consideration. > For e.g. if available, convey location using sipping location=20 > conveyance. But also special handling of things like p-asserted-id=20 > when handing off emergency calls (if privacy is on in the originating=20 > domain, some VSPs remove p-asserted-id when handing out the call to=20 > another provider). In the case of an emergency call, for psap=20 > callback, p-asserted-id must/should be left in... so that the=20 > terminating VSP that connects to the PSAPs can identify the ANI. > > These are first thoughts to provide more examples. We could just have=20 > a couple of sentences highlighting the key requirements and giving=20 > pointers to consider when the handoff of emergency calls is possible. > > Penn wrote: > > > I think we'd be better served NOT to take up the > emergency use case > > for > > > now, until the other groups (GEOPRIV and ECRIT) solidify their=20 > > > requirements. > This is fine and I'm ok not taking if we think we should just not take > this for *now* but as Hannes points out, and as I tried to highlight=20 > above, we should not assume there will be a lot more requirement work=20 > in other IETF groups around the SIP interconnects and there may be=20 > some gaps (hence the scope question). > > Jean-Francois > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Friday, June 16, 2006 6:10 AM > > To: Pfautz, Penn L, GBLAM > > Cc: Jean-Francois Mule; Stastny Richard; speermint@ietf.org > > Subject: Re: [speermint] minimum set of requirements forSIP-=20 > > basedVoIPinterconnection and emergency calling > > > > The requirements work in ECRIT is finished. Here is the most recent > > document: > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements- > > 10.txt > > > > It might be good to clearly describe what you want to > accomplish with > > emgerency services in the context of peering. > > > > Ciao > > Hannes > > > > > > Pfautz, Penn L, GBLAM wrote: > > > I think we'd be better served NOT to take up the > emergency use case > > for > > > now, until the other groups (GEOPRIV and ECRIT) solidify their=20 > > > requirements. > > > > > > Penn > > > > > > -----Original Message----- > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > Sent: Friday, June 16, 2006 7:39 AM > > > To: Stastny Richard > > > Cc: speermint@ietf.org > > > Subject: RE: [speermint] minimum set of requirements=20 > > > forSIP-basedVoIPinterconnection and emergency calling > > > > > > Stastny Richard wrote: > > > > > >>>Some VSPs do have gateways connected to the PSTN and the whole > > >> > > >>selective routers thingy in the North American system for >example > > to > > >>do this; some don't and hand off the call to another VSP. The > > question > > >>of who does the ECRIT mapping protocol >resolution is also not=20 > > >>relevant here. > > >> > > >>Ok, but you mention here two issues out of speermint > scope: gateways > > >>to the PSTN and North American selective router stuff > > > > > > > > > And that is clearly out of scope. > > > Per my earlier email, the scope question was related to the other > > case > > > where emergency calls are not handled within a single VSP > domain (or > > for > > > that matter, the case of an enterprise using a SIP interconnect > > service > > > and handing off all calls to the VSP). > > > > > > 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 > _______________________________________________ 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 Jun 17 16:11:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frh9A-0005cw-FV; Sat, 17 Jun 2006 16:11:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frh98-0005Px-5b for speermint@ietf.org; Sat, 17 Jun 2006 16:11:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Frh96-00031V-Pa for speermint@ietf.org; Sat, 17 Jun 2006 16:11:54 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 17 Jun 2006 13:11:52 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,145,1149490800"; d="scan'208"; a="29773495:sNHT22236256" 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 k5HKBqno002475; Sat, 17 Jun 2006 16:11:52 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 17 Jun 2006 16:11:51 -0400 Received: from [10.86.242.233] ([10.86.242.233]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 17 Jun 2006 16:11:51 -0400 Message-ID: <44946206.3010600@cisco.com> Date: Sat, 17 Jun 2006 16:11:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Livingood, Jason" Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture References: <4884CD6C1DF0A8429DD8DAD942BF9D96581FE7@PACDCEXCMB03.cable.comcast.com> In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D96581FE7@PACDCEXCMB03.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jun 2006 20:11:51.0493 (UTC) FILETIME=[4552D750:01C6924A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 >> -----Original Message----- >> From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] >> A service provide would be best served to provide its >> subscribers a way to contact anyone else. The burden to >> facilitate that session is on the SP. Will a SP in Topeka >> trust a SP in Oslo enough to establish a direct peering >> arrangement? Without that direct peer, how will the >> subscribers of the Topeka SP access the folks in Oslo? An >> intermediary most likely will be involved with the value >> being reachability and trust that should a call be sent to >> the transit provider, it will be completed as intended by the >> calling party. At the end of the day, it will be the one that >> will complete the call that gets the buck. Unfortunately >> it's the PSTN that facilitates that Topeka to Oslo call today >> more often than not. Assuming the provider for the caller can determine the provider for the callee, then I fail to see how introducing an intermediary can improve trust. No matter how many intermediaries are involved, ultimately the callee's provider will be involved in the call. Establishing a direct peering relationship seems at least as good, if not better. Paul _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Jun 18 19:51:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs72y-0005TF-9k; Sun, 18 Jun 2006 19:51:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs72w-0005TA-Va for speermint@ietf.org; Sun, 18 Jun 2006 19:51:14 -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 1Fs72v-0002Yd-Im for speermint@ietf.org; Sun, 18 Jun 2006 19:51:14 -0400 Received: from PMelampy [68.189.242.21] by acmepacket.com with ESMTP (SMTPD-9.03) id A6EB043C; Sun, 18 Jun 2006 19:51:07 -0400 From: "Patrick Melampy" To: "'Paul Kyzivat'" , "'Livingood, Jason'" Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture Date: Sun, 18 Jun 2006 19:51:11 -0400 Message-ID: <004701c69332$13f1cf20$6801a8c0@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: AcaSSlZQLW6LYFYjRlelM8bWDOmxMwA5mY2g In-reply-to: <44946206.3010600@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Paul, It's clear that most of us Engineers (including me) don't understand what's required to establish a business relationship for telephonic communications. I'm guessing there are issues with taxation, regulation, service level agreements, minimum usage, billing issues, currency issues, credit, and more. Although I've never seen a peering agreement for voice traffic, I'm guessing they are comprehensive. I personally am aware of IP Peering relationships for voice that even have damage clauses for periods of service interruption. Maybe somebody who understands why these relationships are so difficult to establish and maintain could shed some light on this. If anybody could easily and quickly establish a new peering relationship, then your position is correct. Maybe you can help resolve all of the business issues to enable "easy and quick" peering with on contracts, no taxes or regulation, and no service level agreements. I do believe that Adam is correct that trust will depend on the signaling infrastructure being open only to those networks that are trust worthy -- with pre-established contractual guarantees. Any network that would break the SIPS chain of trust MUST be excluded, or we need to find a way to ensure that every party in the communication knows that the call is leaving the trusted world and entering into untrusted networks. As far as I know, there is no way currently to know that a SIP communication has followed a SIPS trusted set of proxies from end-to-end. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Saturday, June 17, 2006 4:12 PM To: Livingood, Jason Cc: speermint@ietf.org; Uzelac, Adam Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture >> -----Original Message----- >> From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] >> A service provide would be best served to provide its >> subscribers a way to contact anyone else. The burden to >> facilitate that session is on the SP. Will a SP in Topeka >> trust a SP in Oslo enough to establish a direct peering >> arrangement? Without that direct peer, how will the >> subscribers of the Topeka SP access the folks in Oslo? An >> intermediary most likely will be involved with the value >> being reachability and trust that should a call be sent to >> the transit provider, it will be completed as intended by the >> calling party. At the end of the day, it will be the one that >> will complete the call that gets the buck. Unfortunately >> it's the PSTN that facilitates that Topeka to Oslo call today >> more often than not. Assuming the provider for the caller can determine the provider for the callee, then I fail to see how introducing an intermediary can improve trust. No matter how many intermediaries are involved, ultimately the callee's provider will be involved in the call. Establishing a direct peering relationship seems at least as good, if not better. Paul _______________________________________________ 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 Jun 19 04:59:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsFbj-00031U-Jv; Mon, 19 Jun 2006 04:59:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsFbi-00031P-Hz for speermint@ietf.org; Mon, 19 Jun 2006 04:59:42 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsFbg-000145-Bg for speermint@ietf.org; Mon, 19 Jun 2006 04:59:42 -0400 Received: by py-out-1112.google.com with SMTP id e30so1220801pya for ; Mon, 19 Jun 2006 01:59:40 -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:mime-version:content-type:content-transfer-encoding:content-disposition; b=jeVUHaPFn0uYQN1VS05uYH9J6Y177x+y9BVIcYqdkd/8RarBOGPl1n9ASx9RKXgP1rKS0w6KcXo/ed+0Wdva8aYKdKJoCiYG3B2wlN4IaR9Dg4aLWI5iIZm0XKYcc+9Iz2b4ryNT42KO1xaqVd9XyRt+hSCQqXQru+YDkTvJxxU= Received: by 10.35.69.11 with SMTP id w11mr2528619pyk; Mon, 19 Jun 2006 01:59:40 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Mon, 19 Jun 2006 01:59:40 -0700 (PDT) Message-ID: <953beacc0606190159h5e6c40b5u4b51251eaab3f7b@mail.gmail.com> Date: Mon, 19 Jun 2006 01:59:40 -0700 From: "Rohan Mahy" To: speermint@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Speermint] Just submitted draft-mahy-speermint-direct-peering-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 Folks, I just submitted a draft with a minimalist approach to peering. I thought this might be a useful way to have a productive discussion on requirements. Until it appears in the archive, you can get it here: http://scm.sipfoundry.org/rep/ietf-drafts/rohan/direct-peering/draft-mahy-speermint-direct-peering-00.html http://scm.sipfoundry.org/rep/ietf-drafts/rohan/direct-peering/draft-mahy-speermint-direct-peering-00.txt thanks, -rohan _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jun 19 09:40:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsJzI-0003pV-1i; Mon, 19 Jun 2006 09:40:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsJzG-0003pQ-Uq for speermint@ietf.org; Mon, 19 Jun 2006 09:40:18 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsJzG-0002j0-FL for speermint@ietf.org; Mon, 19 Jun 2006 09:40:18 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FsJz8-00073P-Mp; Mon, 19 Jun 2006 08:40:11 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , "'Michael Hammer \(mhammer\)'" , "'Jean-Francois Mule'" Subject: RE: [speermint] minimum set ofrequirementsforSIP-basedVoIPinterconnection and emergency calling Date: Mon, 19 Jun 2006 09:40:11 -0400 Message-ID: <090301c693a5$e50fe970$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: <32755D354E6B65498C3BD9FD496C7D462C4AEA@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaRPcP38JvOP9K8SoS3IFLxR4eufAABiQ+QAA44w/AAARRuNgCI2DUw 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: 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 I can too. I do think it will be fairly common for an originating network to hand off an emergency call to another network. That network may be one operated by or for the PSAP, but it will operate much like any other SP. It probably will have at least two different mechanisms for interconnect: one very much a "peering" relationship, well within the scope of speermint, and the other pretty much an open Internet connection most times accepting any call sent to it. The security profiles of these two mechanisms will be different. However, it's not clear to me whether ecrit takes the speermint work and runs with that, speermint takes ecrit work and puts words in its document, or we leave it to the authorities and their own standards groups to do that work, as we are talking about precisely how a call is handed from an SP to a PSAP, and the PSAP side of that is governed by the emergency authorities. I think ecrit is definitely going to precisely specify the open Internet interconnect. It may be that this whole area collapses easily into the basic speermint model, except for the location header and any priority/QoS stuff that is peculiar to emergency calls. Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Friday, June 16, 2006 4:12 PM To: Michael Hammer (mhammer); Jean-Francois Mule Cc: speermint@ietf.org Subject: Re: [speermint] minimum set ofrequirementsforSIP-basedVoIPinterconnection and emergency calling I could live with this proposal -sta ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Fr 16.06.2006 21:44 An: Jean-Francois Mule; Hannes Tschofenig; Pfautz, Penn L, GBLAM Cc: Stastny Richard; speermint@ietf.org Betreff: RE: [speermint] minimum set ofrequirements forSIP-basedVoIPinterconnection and emergency calling All, Let me ask the question a different way: Will all PSAPs belong to the same federation (a special PSAP federation that defines the rules for accessing PSAP domains), or will all PSAPs belong to various federations, where the rules for handling SIP messages and what is needed for SOS calls is defined by each federations? Put me in the column for holding off on special cases of calls being addressed until we have worked out the basic call case. By then, perhaps the ECRIT WG will have made further progress on the SOS call delivery mechanisms and associated protocol elements. Mike > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Friday, June 16, 2006 9:39 AM > To: Hannes Tschofenig; Pfautz, Penn L, GBLAM > Cc: Stastny Richard; speermint@ietf.org > Subject: RE: [speermint] minimum set ofrequirements > forSIP-basedVoIPinterconnection and emergency calling > > Penn and Hannes, > > Thanks for the input. Here is an attempt to clarify what > could be in scope of speermint. > > Hannes wrote: > > It might be good to clearly describe what you want to > accomplish with > > emgerency services in the context of peering. > > The potential goal would be to write the minimum requirements > a VSP should comply with when handing off an emergency call > to another administrative domain over IP through a VoIP > interconnect point (SIP call termination to another > third-party provider which in turn does terminate the call to a PSAP). > > Folks assume the work in GEOPRIV and ECRIT takes care of the above. > The requirement gap I can see so far is based on: > a) the requirement work in ECRIT is for IP-enabled PSAPs (US/nena i3). > The ECRIT requirement document states: > | This document only focuses on end-to-end IP-based calls, > i.e., where > | the emergency call originates from an IP end system and terminates > | into an IP-capable PSAP, conveyed entirely over an IP network. > > b) GEOPRIV, ECRIT and SIPPING are concerned with location > determination, emergency context resolution, location-based > routing of the SIP call to the PSAP URI, location conveyance in SIP. > > c) SPEERMINT is about "architectures to identify, signal, and > route delay-sensitive (real-time) communication sessions."... > "These sessions use the SIP signaling protocol to enable > peering between two or more administrative domains over IP networks." > > So, for example, the speermint requirement doc could state > things like: > - any applicable ECRIT requirements for exchanging > emergency sip calls between 2 or more domains, > - any SIP requirements that should be taken into consideration. > For e.g. if available, convey location using sipping location > conveyance. But also special handling of things like > p-asserted-id when handing off emergency calls (if privacy is > on in the originating domain, some VSPs remove p-asserted-id > when handing out the call to another provider). In the case > of an emergency call, for psap callback, p-asserted-id > must/should be left in... so that the terminating VSP that > connects to the PSAPs can identify the ANI. > > These are first thoughts to provide more examples. We could > just have a couple of sentences highlighting the key > requirements and giving pointers to consider when the handoff > of emergency calls is possible. > > Penn wrote: > > > I think we'd be better served NOT to take up the > emergency use case > > for > > > now, until the other groups (GEOPRIV and ECRIT) solidify their > > > requirements. > This is fine and I'm ok not taking if we think we should just > not take this for *now* but as Hannes points out, and as I > tried to highlight above, we should not assume there will be > a lot more requirement work in other IETF groups around the > SIP interconnects and there may be some gaps (hence the scope > question). > > Jean-Francois > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Friday, June 16, 2006 6:10 AM > > To: Pfautz, Penn L, GBLAM > > Cc: Jean-Francois Mule; Stastny Richard; speermint@ietf.org > > Subject: Re: [speermint] minimum set of requirements forSIP- > > basedVoIPinterconnection and emergency calling > > > > The requirements work in ECRIT is finished. Here is the most recent > > document: > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements- > > 10.txt > > > > It might be good to clearly describe what you want to > accomplish with > > emgerency services in the context of peering. > > > > Ciao > > Hannes > > > > > > Pfautz, Penn L, GBLAM wrote: > > > I think we'd be better served NOT to take up the > emergency use case > > for > > > now, until the other groups (GEOPRIV and ECRIT) solidify their > > > requirements. > > > > > > Penn > > > > > > -----Original Message----- > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > Sent: Friday, June 16, 2006 7:39 AM > > > To: Stastny Richard > > > Cc: speermint@ietf.org > > > Subject: RE: [speermint] minimum set of requirements > > > forSIP-basedVoIPinterconnection and emergency calling > > > > > > Stastny Richard wrote: > > > > > >>>Some VSPs do have gateways connected to the PSTN and the whole > > >> > > >>selective routers thingy in the North American system for >example > > to > > >>do this; some don't and hand off the call to another VSP. The > > question > > >>of who does the ECRIT mapping protocol >resolution is also not > > >>relevant here. > > >> > > >>Ok, but you mention here two issues out of speermint > scope: gateways > > >>to the PSTN and North American selective router stuff > > > > > > > > > And that is clearly out of scope. > > > Per my earlier email, the scope question was related to the other > > case > > > where emergency calls are not handled within a single VSP > domain (or > > for > > > that matter, the case of an enterprise using a SIP interconnect > > service > > > and handing off all calls to the VSP). > > > > > > 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 > _______________________________________________ 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 Jun 19 10:10:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsKS9-0001Dr-Cr; Mon, 19 Jun 2006 10:10:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsKS8-0001D5-Qn for speermint@ietf.org; Mon, 19 Jun 2006 10:10:08 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsKIH-00084A-9P for speermint@ietf.org; Mon, 19 Jun 2006 09:59:57 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5JDxsW5027347; Mon, 19 Jun 2006 07:59:54 -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] minimum setofrequirementsforSIP-basedVoIPinterconnection and emergency calling Date: Mon, 19 Jun 2006 07:59:54 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum setofrequirementsforSIP-basedVoIPinterconnection and emergency calling Thread-Index: AcaRPcP38JvOP9K8SoS3IFLxR4eufAABiQ+QAA44w/AAARRuNgCI2DUwAADqgkA= From: "Jean-Francois Mule" To: "Brian Rosen" , "Stastny Richard" , "Michael Hammer (mhammer)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e 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 wrote: > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, June 19, 2006 7:40 AM > To: 'Stastny Richard'; 'Michael Hammer (mhammer)'; Jean-Francois Mule > Cc: speermint@ietf.org > Subject: RE: [speermint] minimum setofrequirementsforSIP- > basedVoIPinterconnection and emergency calling >=20 > I can too. >=20 > I do think it will be fairly common for an originating network to hand > off > an emergency call to another network. That network may be one > operated by > or for the PSAP, but it will operate much like any other SP. It > probably > will have at least two different mechanisms for interconnect: one very > much > a "peering" relationship, well within the scope of speermint, and the > other > pretty much an open Internet connection most times accepting any call > sent > to it. The security profiles of these two mechanisms will be > different. >=20 > However, it's not clear to me whether ecrit takes the speermint work > and > runs with that, speermint takes ecrit work and puts words in its > document, I thought that wg charters could tell you that. I provided my reading; I could care less about whether this is done in ECRIT or SPEERMINT but something should be done for session peering of emergency calls. > or we leave it to the authorities and their own standards groups to do > that > work, as we are talking about precisely how a call is handed from an > SP to a > PSAP, and the PSAP side of that is governed by the emergency > authorities. I > think ecrit is definitely going to precisely specify the open Internet > interconnect. It may be that this whole area collapses easily into > the > basic speermint model, except for the location header and any > priority/QoS > stuff that is peculiar to emergency calls. Ack. >=20 > Brian >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, June 16, 2006 4:12 PM > To: Michael Hammer (mhammer); Jean-Francois Mule > Cc: speermint@ietf.org > Subject: Re: [speermint] minimum set > ofrequirementsforSIP-basedVoIPinterconnection and emergency calling >=20 > I could live with this proposal >=20 > -sta >=20 > ________________________________ >=20 > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Gesendet: Fr 16.06.2006 21:44 > An: Jean-Francois Mule; Hannes Tschofenig; Pfautz, Penn L, GBLAM > Cc: Stastny Richard; speermint@ietf.org > Betreff: RE: [speermint] minimum set ofrequirements > forSIP-basedVoIPinterconnection and emergency calling >=20 >=20 >=20 > All, >=20 > Let me ask the question a different way: >=20 > Will all PSAPs belong to the same federation (a special PSAP > federation > that defines the rules for accessing PSAP domains), or >=20 > will all PSAPs belong to various federations, where the rules for > handling SIP messages and what is needed for SOS calls is defined by > each federations? >=20 > Put me in the column for holding off on special cases of calls being > addressed until we have worked out the basic call case. By then, > perhaps the ECRIT WG will have made further progress on the SOS call > elivery mechanisms and associated protocol elements. >=20 > Mike >=20 >=20 >=20 > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > Sent: Friday, June 16, 2006 9:39 AM > > To: Hannes Tschofenig; Pfautz, Penn L, GBLAM > > Cc: Stastny Richard; speermint@ietf.org > > Subject: RE: [speermint] minimum set ofrequirements > > forSIP-basedVoIPinterconnection and emergency calling > > > > Penn and Hannes, > > > > Thanks for the input. Here is an attempt to clarify what > > could be in scope of speermint. > > > > Hannes wrote: > > > It might be good to clearly describe what you want to > > accomplish with > > > emgerency services in the context of peering. > > > > The potential goal would be to write the minimum requirements > > a VSP should comply with when handing off an emergency call > > to another administrative domain over IP through a VoIP > > interconnect point (SIP call termination to another > > third-party provider which in turn does terminate the call to a > PSAP). > > > > Folks assume the work in GEOPRIV and ECRIT takes care of the > above. > > The requirement gap I can see so far is based on: > > a) the requirement work in ECRIT is for IP-enabled PSAPs (US/nena > i3). > > The ECRIT requirement document states: > > | This document only focuses on end-to-end IP-based calls, > > i.e., where > > | the emergency call originates from an IP end system and terminates > > | into an IP-capable PSAP, conveyed entirely over an IP network. > > > > b) GEOPRIV, ECRIT and SIPPING are concerned with location > > determination, emergency context resolution, location-based > > routing of the SIP call to the PSAP URI, location conveyance in SIP. > > > > c) SPEERMINT is about "architectures to identify, signal, and > > route delay-sensitive (real-time) communication sessions."... > > "These sessions use the SIP signaling protocol to enable > > peering between two or more administrative domains over IP > networks." > > > > So, for example, the speermint requirement doc could state > > things like: > > - any applicable ECRIT requirements for exchanging > > emergency sip calls between 2 or more domains, > > - any SIP requirements that should be taken into consideration. > > For e.g. if available, convey location using sipping location > > conveyance. But also special handling of things like > > p-asserted-id when handing off emergency calls (if privacy is > > on in the originating domain, some VSPs remove p-asserted-id > > when handing out the call to another provider). In the case > > of an emergency call, for psap callback, p-asserted-id > > must/should be left in... so that the terminating VSP that > > connects to the PSAPs can identify the ANI. > > > > These are first thoughts to provide more examples. We could > > just have a couple of sentences highlighting the key > > requirements and giving pointers to consider when the handoff > > of emergency calls is possible. > > > > Penn wrote: > > > > I think we'd be better served NOT to take up the > > emergency use case > > > for > > > > now, until the other groups (GEOPRIV and ECRIT) solidify their > > > > requirements. > > This is fine and I'm ok not taking if we think we should just > > not take this for *now* but as Hannes points out, and as I > > tried to highlight above, we should not assume there will be > > a lot more requirement work in other IETF groups around the > > SIP interconnects and there may be some gaps (hence the scope > > question). > > > > Jean-Francois > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Friday, June 16, 2006 6:10 AM > > > To: Pfautz, Penn L, GBLAM > > > Cc: Jean-Francois Mule; Stastny Richard; speermint@ietf.org > > > Subject: Re: [speermint] minimum set of requirements forSIP- > > > basedVoIPinterconnection and emergency calling > > > > > > The requirements work in ECRIT is finished. Here is the most > recent > > > document: > > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements- > > > 10.txt > > > > > > It might be good to clearly describe what you want to > > accomplish with > > > emgerency services in the context of peering. > > > > > > Ciao > > > Hannes > > > > > > > > > Pfautz, Penn L, GBLAM wrote: > > > > I think we'd be better served NOT to take up the > > emergency use case > > > for > > > > now, until the other groups (GEOPRIV and ECRIT) solidify their > > > > requirements. > > > > > > > > Penn > > > > > > > > -----Original Message----- > > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > > Sent: Friday, June 16, 2006 7:39 AM > > > > To: Stastny Richard > > > > Cc: speermint@ietf.org > > > > Subject: RE: [speermint] minimum set of requirements > > > > forSIP-basedVoIPinterconnection and emergency calling > > > > > > > > Stastny Richard wrote: > > > > > > > >>>Some VSPs do have gateways connected to the PSTN and the whole > > > >> > > > >>selective routers thingy in the North American system for > >example > > > to > > > >>do this; some don't and hand off the call to another VSP. The > > > question > > > >>of who does the ECRIT mapping protocol >resolution is also not > > > >>relevant here. > > > >> > > > >>Ok, but you mention here two issues out of speermint > > scope: gateways > > > >>to the PSTN and North American selective router stuff > > > > > > > > > > > > And that is clearly out of scope. > > > > Per my earlier email, the scope question was related to the > other > > > case > > > > where emergency calls are not handled within a single VSP > > domain (or > > > for > > > > that matter, the case of an enterprise using a SIP interconnect > > > service > > > > and handing off all calls to the VSP). > > > > > > > > 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 > > >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jun 19 10:10:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsKSc-0001Rq-Cm; Mon, 19 Jun 2006 10:10:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsKSa-0001RJ-Rc for speermint@ietf.org; Mon, 19 Jun 2006 10:10:36 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsKDA-00060v-Po for speermint@ietf.org; Mon, 19 Jun 2006 09:54:42 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5JDsWC0026075; Mon, 19 Jun 2006 07:54:33 -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] minimum set ofrequirements forSIP-basedVoIPinterconnection and emergency calling Date: Mon, 19 Jun 2006 07:54:32 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum set ofrequirements forSIP-basedVoIPinterconnection and emergency calling Thread-Index: AcaRPcP38JvOP9K8SoS3IFLxR4eufAABiQ+QAA44w/AAiTPb0A== From: "Jean-Francois Mule" To: "Michael Hammer (mhammer)" , "Hannes Tschofenig" , "Pfautz, Penn L, GBLAM" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Stastny Richard , speermint@ietf.org, "Tschofenig, Hannes" 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, Thanks for the input. Mike wrote: > All, >=20 > Let me ask the question a different way: >=20 > Will all PSAPs belong to the same federation (a special PSAP > federation > that defines the rules for accessing PSAP domains), or >=20 > will all PSAPs belong to various federations, where the rules for > handling SIP messages and what is needed for SOS calls is defined by > each federations? Each "PSAP federation" will likely define what is needed for SOS calls (likely at a regional or national level, take NENA for e.g.).=20 But wouldn't it be a plus for all the actors (those regional PSAP federations, multinational corporations connecting IP-PBX to SIP voice providers, VSPs crossing multiple of those regional boundaries using a common vendor solution) to point to a basic and minimum set of applicable requirements for exchanging emergency calling between those actors? We have most of the requirement pieces, we just need the mint glue and a document to stick them in. > Put me in the column for holding off on special cases of calls being > addressed until we have worked out the basic call case. =20 Ok, seems the right order anyway. > By then, > perhaps the ECRIT WG will have made further progress on the SOS call > delivery mechanisms and associated protocol elements. As Hannes reminded us, the requirement work in ECRIT is almost done. This is where folks think there is no gap and take a 'wait and see' position. Please re-read the ECRIT WG charter again.=20 I understand the following: - ECRIT will provide for how to identify a session initiation request it for an emergency call and ECRIT will describe how "route an emergency call based on location info", - once a SIP entity gets the PSAP URI back from the LoST mapping protocol for e.g., this is where the speermint scope starts. To draw a parallel, this is very similar to the relationship between ENUM and SPEERMINT when an e.164 is used (ref. SPEERMINT Context in the terminology draft): once call routing data is obtained from ENUM (e.164-->URI) and you have the SIP URI, session-level signaling and the associated requirements for SIP message exchange is in scope of speermint. What am I missing? Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jun 19 10:30:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsKlS-0000vy-0i; Mon, 19 Jun 2006 10:30:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsKlQ-0000rU-EU for speermint@ietf.org; Mon, 19 Jun 2006 10:30:04 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsKdF-0001hS-9i for speermint@ietf.org; Mon, 19 Jun 2006 10:21:37 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Jun 2006 10:21:38 -0400 X-IronPort-AV: i="4.06,152,1149480000"; d="scan'208"; a="90437877:sNHT36172224" 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 k5JELano002138; Mon, 19 Jun 2006 10:21:36 -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); Mon, 19 Jun 2006 10:21: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] minimum setofrequirementsforSIP-basedVoIPinterconnection and emergency calling Date: Mon, 19 Jun 2006 10:21:35 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30197C2F7@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum setofrequirementsforSIP-basedVoIPinterconnection and emergency calling Thread-Index: AcaRPcP38JvOP9K8SoS3IFLxR4eufAABiQ+QAA44w/AAARRuNgCI2DUwAADqgkAAAMYH0A== From: "Michael Hammer \(mhammer\)" To: "Jean-Francois Mule" , "Brian Rosen" , "Stastny Richard" X-OriginalArrivalTime: 19 Jun 2006 14:21:36.0036 (UTC) FILETIME=[ABF61640:01C693AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 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 need to look more closely at what this E-PSCF function is doing. It may for all I know be the ingress proxy for a PSAP domain. Or maybe the egress from an SP that needs to peer to a PSAP domain. At some point we need to meld the two WG efforts together. Mike > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Monday, June 19, 2006 10:00 AM > To: Brian Rosen; Stastny Richard; Michael Hammer (mhammer) > Cc: speermint@ietf.org > Subject: RE: [speermint] minimum=20 > setofrequirementsforSIP-basedVoIPinterconnection and emergency calling >=20 > Brian wrote: >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, June 19, 2006 7:40 AM > > To: 'Stastny Richard'; 'Michael Hammer (mhammer)';=20 > Jean-Francois Mule > > Cc: speermint@ietf.org > > Subject: RE: [speermint] minimum setofrequirementsforSIP-=20 > > basedVoIPinterconnection and emergency calling > >=20 > > I can too. > >=20 > > I do think it will be fairly common for an originating=20 > network to hand=20 > > off an emergency call to another network. That network may be one=20 > > operated by or for the PSAP, but it will operate much like=20 > any other=20 > > SP. It probably will have at least two different mechanisms for=20 > > interconnect: one very much a "peering" relationship, well=20 > within the=20 > > scope of speermint, and the other pretty much an open Internet=20 > > connection most times accepting any call sent to it. The security=20 > > profiles of these two mechanisms will be different. > >=20 > > However, it's not clear to me whether ecrit takes the=20 > speermint work=20 > > and runs with that, speermint takes ecrit work and puts=20 > words in its=20 > > document, >=20 > I thought that wg charters could tell you that. I provided my=20 > reading; I could care less about whether this is done in=20 > ECRIT or SPEERMINT but something should be done for session=20 > peering of emergency calls. >=20 > > or we leave it to the authorities and their own standards=20 > groups to do=20 > > that work, as we are talking about precisely how a call is=20 > handed from=20 > > an SP to a PSAP, and the PSAP side of that is governed by the=20 > > emergency authorities. I think ecrit is definitely going=20 > to precisely=20 > > specify the open Internet interconnect. It may be that this whole=20 > > area collapses easily into the basic speermint model,=20 > except for the=20 > > location header and any priority/QoS stuff that is peculiar to=20 > > emergency calls. >=20 > Ack. >=20 > >=20 > > Brian > >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Friday, June 16, 2006 4:12 PM > > To: Michael Hammer (mhammer); Jean-Francois Mule > > Cc: speermint@ietf.org > > Subject: Re: [speermint] minimum set > > ofrequirementsforSIP-basedVoIPinterconnection and emergency calling > >=20 > > I could live with this proposal > >=20 > > -sta > >=20 > > ________________________________ > >=20 > > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Gesendet: Fr 16.06.2006 21:44 > > An: Jean-Francois Mule; Hannes Tschofenig; Pfautz, Penn L, GBLAM > > Cc: Stastny Richard; speermint@ietf.org > > Betreff: RE: [speermint] minimum set ofrequirements=20 > > forSIP-basedVoIPinterconnection and emergency calling > >=20 > >=20 > >=20 > > All, > >=20 > > Let me ask the question a different way: > >=20 > > Will all PSAPs belong to the same federation (a special PSAP=20 > > federation that defines the rules for accessing PSAP domains), or > >=20 > > will all PSAPs belong to various federations, where the rules for=20 > > handling SIP messages and what is needed for SOS calls is=20 > defined by=20 > > each federations? > >=20 > > Put me in the column for holding off on special cases of=20 > calls being=20 > > addressed until we have worked out the basic call case. By then,=20 > > perhaps the ECRIT WG will have made further progress on the=20 > SOS call=20 > > elivery mechanisms and associated protocol elements. > >=20 > > Mike > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > Sent: Friday, June 16, 2006 9:39 AM > > > To: Hannes Tschofenig; Pfautz, Penn L, GBLAM > > > Cc: Stastny Richard; speermint@ietf.org > > > Subject: RE: [speermint] minimum set ofrequirements=20 > > > forSIP-basedVoIPinterconnection and emergency calling > > > > > > Penn and Hannes, > > > > > > Thanks for the input. Here is an attempt to clarify=20 > what could be=20 > > > in scope of speermint. > > > > > > Hannes wrote: > > > > It might be good to clearly describe what you want to > > > accomplish with > > > > emgerency services in the context of peering. > > > > > > The potential goal would be to write the minimum=20 > requirements a VSP=20 > > > should comply with when handing off an emergency call to another=20 > > > administrative domain over IP through a VoIP interconnect=20 > point (SIP=20 > > > call termination to another third-party provider which in=20 > turn does=20 > > > terminate the call to a > > PSAP). > > > > > > Folks assume the work in GEOPRIV and ECRIT takes care of the > > above. > > > The requirement gap I can see so far is based on: > > > a) the requirement work in ECRIT is for IP-enabled PSAPs (US/nena > > i3). > > > The ECRIT requirement document states: > > > | This document only focuses on end-to-end IP-based calls, > > > i.e., where > > > | the emergency call originates from an IP end system and=20 > terminates=20 > > > | into an IP-capable PSAP, conveyed entirely over an IP network. > > > > > > b) GEOPRIV, ECRIT and SIPPING are concerned with location=20 > > > determination, emergency context resolution,=20 > location-based routing=20 > > > of the SIP call to the PSAP URI, location conveyance in SIP. > > > > > > c) SPEERMINT is about "architectures to identify, signal,=20 > and route=20 > > > delay-sensitive (real-time) communication sessions."... > > > "These sessions use the SIP signaling protocol to enable peering=20 > > > between two or more administrative domains over IP > > networks." > > > > > > So, for example, the speermint requirement doc could state things=20 > > > like: > > > - any applicable ECRIT requirements for exchanging=20 > emergency=20 > > > sip calls between 2 or more domains, > > > - any SIP requirements that should be taken into > consideration. > > > For e.g. if available, convey location using sipping location=20 > > > conveyance. But also special handling of things like=20 > p-asserted-id=20 > > > when handing off emergency calls (if privacy is on in the=20 > > > originating domain, some VSPs remove p-asserted-id when=20 > handing out=20 > > > the call to another provider). In the case of an=20 > emergency call, for=20 > > > psap callback, p-asserted-id must/should be left in... so=20 > that the=20 > > > terminating VSP that connects to the PSAPs can identify the ANI. > > > > > > These are first thoughts to provide more examples. We could just=20 > > > have a couple of sentences highlighting the key requirements and=20 > > > giving pointers to consider when the handoff of emergency=20 > calls is=20 > > > possible. > > > > > > Penn wrote: > > > > > I think we'd be better served NOT to take up the > > > emergency use case > > > > for > > > > > now, until the other groups (GEOPRIV and ECRIT)=20 > solidify their=20 > > > > > requirements. > > > This is fine and I'm ok not taking if we think we should just not=20 > > > take this for *now* but as Hannes points out, and as I tried to=20 > > > highlight above, we should not assume there will be a lot more=20 > > > requirement work in other IETF groups around the SIP=20 > interconnects=20 > > > and there may be some gaps (hence the scope question). > > > > > > Jean-Francois > > > > > > > -----Original Message----- > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > Sent: Friday, June 16, 2006 6:10 AM > > > > To: Pfautz, Penn L, GBLAM > > > > Cc: Jean-Francois Mule; Stastny Richard; speermint@ietf.org > > > > Subject: Re: [speermint] minimum set of requirements forSIP-=20 > > > > basedVoIPinterconnection and emergency calling > > > > > > > > The requirements work in ECRIT is finished. Here is the most > > recent > > > > document: > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements- > > > > 10.txt > > > > > > > > It might be good to clearly describe what you want to > > > accomplish with > > > > emgerency services in the context of peering. > > > > > > > > Ciao > > > > Hannes > > > > > > > > > > > > Pfautz, Penn L, GBLAM wrote: > > > > > I think we'd be better served NOT to take up the > > > emergency use case > > > > for > > > > > now, until the other groups (GEOPRIV and ECRIT)=20 > solidify their=20 > > > > > requirements. > > > > > > > > > > Penn > > > > > > > > > > -----Original Message----- > > > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > > > Sent: Friday, June 16, 2006 7:39 AM > > > > > To: Stastny Richard > > > > > Cc: speermint@ietf.org > > > > > Subject: RE: [speermint] minimum set of requirements=20 > > > > > forSIP-basedVoIPinterconnection and emergency calling > > > > > > > > > > Stastny Richard wrote: > > > > > > > > > >>>Some VSPs do have gateways connected to the PSTN and=20 > the whole > > > > >> > > > > >>selective routers thingy in the North American system for > > >example > > > > to > > > > >>do this; some don't and hand off the call to another VSP. The > > > > question > > > > >>of who does the ECRIT mapping protocol >resolution is=20 > also not=20 > > > > >>relevant here. > > > > >> > > > > >>Ok, but you mention here two issues out of speermint > > > scope: gateways > > > > >>to the PSTN and North American selective router stuff > > > > > > > > > > > > > > > And that is clearly out of scope. > > > > > Per my earlier email, the scope question was related to the > > other > > > > case > > > > > where emergency calls are not handled within a single VSP > > > domain (or > > > > for > > > > > that matter, the case of an enterprise using a SIP=20 > interconnect > > > > service > > > > > and handing off all calls to the VSP). > > > > > > > > > > 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 > > > > >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jun 19 10:46:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsL0k-0008B8-6Y; Mon, 19 Jun 2006 10:45:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsL0j-0008B2-11 for speermint@ietf.org; Mon, 19 Jun 2006 10:45:53 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsL0i-0005Aj-EG for speermint@ietf.org; Mon, 19 Jun 2006 10:45:53 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FsL0Z-0003PN-JX; Mon, 19 Jun 2006 09:45:44 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Jean-Francois Mule'" , "'Stastny Richard'" Subject: RE: [speermint] minimum setofrequirementsforSIP-basedVoIPinterconnection and emergency calling Date: Mon, 19 Jun 2006 10:45:44 -0400 Message-ID: <092501c693af$0d8f41d0$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: <072C5B76F7CEAB488172C6F64B30B5E30197C2F7@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaRPcP38JvOP9K8SoS3IFLxR4eufAABiQ+QAA44w/AAARRuNgCI2DUwAADqgkAAAMYH0AAA2ueQ 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: 79bb66f827e54e9d5c5c7f1f9d645608 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 An "E-CSCF" is an IMS term for a proxy in the originating network that handles emergency calls. It would probably be the exit proxy for the originating domain. An "ESRP" is a term used in ecrit for any intermediary in the domain the PSAP is a part of (or a higher level domain when there is some hierarchy). An ESRP could be the entrance proxy for the PSAP domain. So the E-CSCF would 'peer' with the ESRP. Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Monday, June 19, 2006 10:22 AM To: Jean-Francois Mule; Brian Rosen; Stastny Richard Cc: speermint@ietf.org Subject: RE: [speermint] minimum setofrequirementsforSIP-basedVoIPinterconnection and emergency calling I need to look more closely at what this E-PSCF function is doing. It may for all I know be the ingress proxy for a PSAP domain. Or maybe the egress from an SP that needs to peer to a PSAP domain. At some point we need to meld the two WG efforts together. Mike > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Monday, June 19, 2006 10:00 AM > To: Brian Rosen; Stastny Richard; Michael Hammer (mhammer) > Cc: speermint@ietf.org > Subject: RE: [speermint] minimum > setofrequirementsforSIP-basedVoIPinterconnection and emergency calling > > Brian wrote: > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, June 19, 2006 7:40 AM > > To: 'Stastny Richard'; 'Michael Hammer (mhammer)'; > Jean-Francois Mule > > Cc: speermint@ietf.org > > Subject: RE: [speermint] minimum setofrequirementsforSIP- > > basedVoIPinterconnection and emergency calling > > > > I can too. > > > > I do think it will be fairly common for an originating > network to hand > > off an emergency call to another network. That network may be one > > operated by or for the PSAP, but it will operate much like > any other > > SP. It probably will have at least two different mechanisms for > > interconnect: one very much a "peering" relationship, well > within the > > scope of speermint, and the other pretty much an open Internet > > connection most times accepting any call sent to it. The security > > profiles of these two mechanisms will be different. > > > > However, it's not clear to me whether ecrit takes the > speermint work > > and runs with that, speermint takes ecrit work and puts > words in its > > document, > > I thought that wg charters could tell you that. I provided my > reading; I could care less about whether this is done in > ECRIT or SPEERMINT but something should be done for session > peering of emergency calls. > > > or we leave it to the authorities and their own standards > groups to do > > that work, as we are talking about precisely how a call is > handed from > > an SP to a PSAP, and the PSAP side of that is governed by the > > emergency authorities. I think ecrit is definitely going > to precisely > > specify the open Internet interconnect. It may be that this whole > > area collapses easily into the basic speermint model, > except for the > > location header and any priority/QoS stuff that is peculiar to > > emergency calls. > > Ack. > > > > > Brian > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Friday, June 16, 2006 4:12 PM > > To: Michael Hammer (mhammer); Jean-Francois Mule > > Cc: speermint@ietf.org > > Subject: Re: [speermint] minimum set > > ofrequirementsforSIP-basedVoIPinterconnection and emergency calling > > > > I could live with this proposal > > > > -sta > > > > ________________________________ > > > > Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Gesendet: Fr 16.06.2006 21:44 > > An: Jean-Francois Mule; Hannes Tschofenig; Pfautz, Penn L, GBLAM > > Cc: Stastny Richard; speermint@ietf.org > > Betreff: RE: [speermint] minimum set ofrequirements > > forSIP-basedVoIPinterconnection and emergency calling > > > > > > > > All, > > > > Let me ask the question a different way: > > > > Will all PSAPs belong to the same federation (a special PSAP > > federation that defines the rules for accessing PSAP domains), or > > > > will all PSAPs belong to various federations, where the rules for > > handling SIP messages and what is needed for SOS calls is > defined by > > each federations? > > > > Put me in the column for holding off on special cases of > calls being > > addressed until we have worked out the basic call case. By then, > > perhaps the ECRIT WG will have made further progress on the > SOS call > > elivery mechanisms and associated protocol elements. > > > > Mike > > > > > > > > > -----Original Message----- > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > Sent: Friday, June 16, 2006 9:39 AM > > > To: Hannes Tschofenig; Pfautz, Penn L, GBLAM > > > Cc: Stastny Richard; speermint@ietf.org > > > Subject: RE: [speermint] minimum set ofrequirements > > > forSIP-basedVoIPinterconnection and emergency calling > > > > > > Penn and Hannes, > > > > > > Thanks for the input. Here is an attempt to clarify > what could be > > > in scope of speermint. > > > > > > Hannes wrote: > > > > It might be good to clearly describe what you want to > > > accomplish with > > > > emgerency services in the context of peering. > > > > > > The potential goal would be to write the minimum > requirements a VSP > > > should comply with when handing off an emergency call to another > > > administrative domain over IP through a VoIP interconnect > point (SIP > > > call termination to another third-party provider which in > turn does > > > terminate the call to a > > PSAP). > > > > > > Folks assume the work in GEOPRIV and ECRIT takes care of the > > above. > > > The requirement gap I can see so far is based on: > > > a) the requirement work in ECRIT is for IP-enabled PSAPs (US/nena > > i3). > > > The ECRIT requirement document states: > > > | This document only focuses on end-to-end IP-based calls, > > > i.e., where > > > | the emergency call originates from an IP end system and > terminates > > > | into an IP-capable PSAP, conveyed entirely over an IP network. > > > > > > b) GEOPRIV, ECRIT and SIPPING are concerned with location > > > determination, emergency context resolution, > location-based routing > > > of the SIP call to the PSAP URI, location conveyance in SIP. > > > > > > c) SPEERMINT is about "architectures to identify, signal, > and route > > > delay-sensitive (real-time) communication sessions."... > > > "These sessions use the SIP signaling protocol to enable peering > > > between two or more administrative domains over IP > > networks." > > > > > > So, for example, the speermint requirement doc could state things > > > like: > > > - any applicable ECRIT requirements for exchanging > emergency > > > sip calls between 2 or more domains, > > > - any SIP requirements that should be taken into > consideration. > > > For e.g. if available, convey location using sipping location > > > conveyance. But also special handling of things like > p-asserted-id > > > when handing off emergency calls (if privacy is on in the > > > originating domain, some VSPs remove p-asserted-id when > handing out > > > the call to another provider). In the case of an > emergency call, for > > > psap callback, p-asserted-id must/should be left in... so > that the > > > terminating VSP that connects to the PSAPs can identify the ANI. > > > > > > These are first thoughts to provide more examples. We could just > > > have a couple of sentences highlighting the key requirements and > > > giving pointers to consider when the handoff of emergency > calls is > > > possible. > > > > > > Penn wrote: > > > > > I think we'd be better served NOT to take up the > > > emergency use case > > > > for > > > > > now, until the other groups (GEOPRIV and ECRIT) > solidify their > > > > > requirements. > > > This is fine and I'm ok not taking if we think we should just not > > > take this for *now* but as Hannes points out, and as I tried to > > > highlight above, we should not assume there will be a lot more > > > requirement work in other IETF groups around the SIP > interconnects > > > and there may be some gaps (hence the scope question). > > > > > > Jean-Francois > > > > > > > -----Original Message----- > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > Sent: Friday, June 16, 2006 6:10 AM > > > > To: Pfautz, Penn L, GBLAM > > > > Cc: Jean-Francois Mule; Stastny Richard; speermint@ietf.org > > > > Subject: Re: [speermint] minimum set of requirements forSIP- > > > > basedVoIPinterconnection and emergency calling > > > > > > > > The requirements work in ECRIT is finished. Here is the most > > recent > > > > document: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements- > > > > 10.txt > > > > > > > > It might be good to clearly describe what you want to > > > accomplish with > > > > emgerency services in the context of peering. > > > > > > > > Ciao > > > > Hannes > > > > > > > > > > > > Pfautz, Penn L, GBLAM wrote: > > > > > I think we'd be better served NOT to take up the > > > emergency use case > > > > for > > > > > now, until the other groups (GEOPRIV and ECRIT) > solidify their > > > > > requirements. > > > > > > > > > > Penn > > > > > > > > > > -----Original Message----- > > > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > > > Sent: Friday, June 16, 2006 7:39 AM > > > > > To: Stastny Richard > > > > > Cc: speermint@ietf.org > > > > > Subject: RE: [speermint] minimum set of requirements > > > > > forSIP-basedVoIPinterconnection and emergency calling > > > > > > > > > > Stastny Richard wrote: > > > > > > > > > >>>Some VSPs do have gateways connected to the PSTN and > the whole > > > > >> > > > > >>selective routers thingy in the North American system for > > >example > > > > to > > > > >>do this; some don't and hand off the call to another VSP. The > > > > question > > > > >>of who does the ECRIT mapping protocol >resolution is > also not > > > > >>relevant here. > > > > >> > > > > >>Ok, but you mention here two issues out of speermint > > > scope: gateways > > > > >>to the PSTN and North American selective router stuff > > > > > > > > > > > > > > > And that is clearly out of scope. > > > > > Per my earlier email, the scope question was related to the > > other > > > > case > > > > > where emergency calls are not handled within a single VSP > > > domain (or > > > > for > > > > > that matter, the case of an enterprise using a SIP > interconnect > > > > service > > > > > and handing off all calls to the VSP). > > > > > > > > > > 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 > > > > > > > > > > > _______________________________________________ > > 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 Jun 19 11:04:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsLIS-0000OF-72; Mon, 19 Jun 2006 11:04:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsLIQ-0000OA-SL for speermint@ietf.org; Mon, 19 Jun 2006 11:04:10 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsLIP-00079o-Hw for speermint@ietf.org; Mon, 19 Jun 2006 11:04:10 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5JF48QZ012277 for ; Mon, 19 Jun 2006 09:04:08 -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: [Speermint] use of RFC 3263 for locating peer's SIP server Date: Mon, 19 Jun 2006 09:04:08 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] use of RFC 3263 for locating peer's SIP server Thread-Index: AcaTfrxB+/I9bhT9TBS90Pk0Fl+WRAAIWhcA From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 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,=20 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? =3D=3D> 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? =3D=3D=3D> 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 From speermint-bounces@ietf.org Mon Jun 19 11:12:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsLQ3-0003pF-1D; Mon, 19 Jun 2006 11:12:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsLQ1-0003mv-14 for speermint@ietf.org; Mon, 19 Jun 2006 11:12:01 -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 1FsLQ0-0008JX-Hs for speermint@ietf.org; Mon, 19 Jun 2006 11:12:01 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id A48781A37F; Mon, 19 Jun 2006 17:11:58 +0200 (CEST) Date: Mon, 19 Jun 2006 17:11:58 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Just submitted draft-mahy-speermint-direct-peering-00 Message-ID: <20060619151158.GB19113@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <953beacc0606190159h5e6c40b5u4b51251eaab3f7b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <953beacc0606190159h5e6c40b5u4b51251eaab3f7b@mail.gmail.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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 2006/06/19 10:06, Rohan Mahy wrote: > Hi Folks, > > I just submitted a draft with a minimalist approach to peering. I > thought this might be a useful way to have a productive discussion on > requirements. Thanks for the contribution. It's always helpful to have something concrete to talk about. Some comments: > 3. Overview > > The approach described here assumes that the initiating peer first > discovers a SIP [2] target URI handled by the receiving peer, then > sends SIP requests directly to the receiving peer. Perhaps you should also notice here that such ad-hoc peering implies settlement-free peering. > Note that in a federation of domains, the initiating peer role can be > logically decomposed. Domain A1 can forward requests to domain A2, > so that A2 actually opens a TLS connection to the receiving peer. > Likewise, the receiving peer function can be similarly decomposed. > How functions are distributed between or among domains or nodes is > not subject to this specification as long as the requirements > described in this document are met. We have to be careful here to keep the terminology consistent between the various documents. I used "peering" for calls within a federation, you seem to use "peering" only for inter-federation connects. The latter are not covered by draft-lendl-speermint-federations-00. A common understanding of this aspect will be important. > 4. Procedures I like this section. It's very helpful for the discussion. > 4.1.2 User ENUM lookup > > If an external E.164 address is the target, the initiating peer > consults the public "User ENUM" rooted at e164.arpa, according to the > procedures described in RFC 3761. The peer MUST query for the "E2U+ > sip" enumservice as described in RFC 3674 [11], but MAY check for > other enumservices. The initiating peer MAY consult a cache or > alternate representation of the ENUM data rather than actual DNS > queries. Also, the peer MAY skip actual DNS queries if the > initiating peer is sure that the target address country code is not > represented in e164.arpa. If a sip: or sips: URI is chosen, the peer > skips to Section 4.1.5. IMHO the URIs as returned by User-ENUM do not require TLS (except when they are sips: ones) as described in 4.1.6. They could point to end-user controlled devices (an Asterisk installation, other VoIP-enabled PBX's or simple SIP services). I see no need to insist on anything more than pure RFC3263 for these cases. > 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. That is going to be contentious. What are the "well-known certificate authorities"? The ones which have their keys installed in MSIE and Firefox? Do you expect people to run white-lists based on the keys themselves or based on special-purpose CAs? Or blacklists to keep baddies out? If you allow the same CAs as used for TLS certs for websites then this is a huge community of potential peering partners. Not all of them are well-meaning and serious operators. Do you expect to use CRLs? What if the destination SIP server hosts multiple domains? Which cert is he supposed to present to an incoming SIP/TLS connection? (This is the same problem as hosting multiple https: servers on a single server. Do you need one IP address per domain?) > The initiating > 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- > known certificate authority. Same question again as above. What about TLS connection reuse? If both SIP servers serve URIs in multiple domains, can they reuse TLS connections which were established based on calls to a different domain (but hosted on the same server)? > Note that the client certificate MAY contain a list of entries in the > subjectAltName, only one of which has to match the domain in the From > header URI. What are the scalability limits to that? Any moderately sized ISP mail server hosts mails for thousands of domains. Can this TLS setup scale to similar levels of domain hosting? > 4.2 Receiving Peer > 4.2.4 Receive SIP requests > The receiving peer MAY reject incoming requests due to local policy. > When a request is rejected because the initiating peer is not > authorized to peer, the receiving peer SHOULD respond with a 403 > response with the reason phrase "Unsupported Peer". You have to distinguish rejects based on TLS negotiations and those on the SIP layer. What is the sending peer supposed to do in that case? Fall back to 4.1.4? Cache that result? If caching: per destination URI or per SIP proxy? For how long? How do you prevent unsuccessful TLS establishments to become a kind of DoS attack? Firewalling could be an option on the destination side, but dropped packets lead to timeouts on the sender side which lead to unpredictable call-establishment delays. -------- As I wrote above: this draft is a good starting point for discussions. /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 Jun 19 11:44:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsLvX-0001EU-5K; Mon, 19 Jun 2006 11:44:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsLvW-0001EP-E2 for speermint@ietf.org; Mon, 19 Jun 2006 11:44:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsLvV-0004da-1H for speermint@ietf.org; Mon, 19 Jun 2006 11:44:34 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Jun 2006 08:44:30 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,152,1149490800"; d="scan'208"; a="29926482:sNHT26836304" 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 k5JFiTYf028363; Mon, 19 Jun 2006 11:44:30 -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); Mon, 19 Jun 2006 11:44: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] Just submitted draft-mahy-speermint-direct-peering-00 Date: Mon, 19 Jun 2006 11:44:29 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30197C384@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Just submitted draft-mahy-speermint-direct-peering-00 Thread-Index: AcaTssTkyFIOg+f9RWyHsoCbptolrQAA976g From: "Michael Hammer \(mhammer\)" To: "Otmar Lendl" , X-OriginalArrivalTime: 19 Jun 2006 15:44:29.0831 (UTC) FILETIME=[4092F970:01C693B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 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 To add to the discussion. I think it might be useful that federations as part of their role in peering to establish certificate authorities. One aspect of the comments below that we have to keep very distinct is that of authentication from authorization. You could potentially know, because a certificate is valid, exactly who the offending SP is. Whether you then white list or black list is a separate authorization issue. In that case, if they subscribe to get your policy, you send them to the ingress proxy at: 0.0.0.0 :) Mike > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Monday, June 19, 2006 11:12 AM > To: speermint@ietf.org > Subject: Re: [Speermint] Just submitted=20 > draft-mahy-speermint-direct-peering-00 >=20 > On 2006/06/19 10:06, Rohan Mahy wrote: > > Hi Folks, > >=20 > > I just submitted a draft with a minimalist approach to peering. I=20 > > thought this might be a useful way to have a productive=20 > discussion on=20 > > requirements. >=20 > Thanks for the contribution. >=20 > It's always helpful to have something concrete to talk about. >=20 > Some comments: >=20 > > 3. Overview > >=20 > > The approach described here assumes that the initiating=20 > peer first > > discovers a SIP [2] target URI handled by the receiving=20 > peer, then > > sends SIP requests directly to the receiving peer. >=20 > Perhaps you should also notice here that such ad-hoc peering=20 > implies settlement-free peering. >=20 > > Note that in a federation of domains, the initiating=20 > peer role can be > > logically decomposed. Domain A1 can forward requests to=20 > domain A2, > > so that A2 actually opens a TLS connection to the receiving peer. > > Likewise, the receiving peer function can be similarly=20 > decomposed. > > How functions are distributed between or among domains=20 > or nodes is > > not subject to this specification as long as the requirements > > described in this document are met. >=20 > We have to be careful here to keep the terminology consistent=20 > between the various documents. >=20 > I used "peering" for calls within a federation, you seem to=20 > use "peering" only for inter-federation connects. The latter=20 > are not covered by draft-lendl-speermint-federations-00. >=20 > A common understanding of this aspect will be important. >=20 > > 4. Procedures >=20 > I like this section. It's very helpful for the discussion. >=20 > > 4.1.2 User ENUM lookup > >=20 > > If an external E.164 address is the target, the initiating peer > > consults the public "User ENUM" rooted at e164.arpa,=20 > according to the > > procedures described in RFC 3761. The peer MUST query=20 > for the "E2U+ > > sip" enumservice as described in RFC 3674 [11], but MAY check for > > other enumservices. The initiating peer MAY consult a cache or > > alternate representation of the ENUM data rather than actual DNS > > queries. Also, the peer MAY skip actual DNS queries if the > > initiating peer is sure that the target address country=20 > code is not > > represented in e164.arpa. If a sip: or sips: URI is=20 > chosen, the peer > > skips to Section 4.1.5. >=20 > IMHO the URIs as returned by User-ENUM do not require TLS=20 > (except when they are sips: ones) as described in 4.1.6. >=20 > They could point to end-user controlled devices (an Asterisk=20 > installation, other VoIP-enabled PBX's or simple SIP=20 > services). I see no need to insist on anything more than=20 > pure RFC3263 for these cases. >=20 > > 4.1.6 Setup TLS connection > >=20 > > Once a transport, port, and address are found, the=20 > initiating peer > > will open or find a reusable TLS connection to the peer. The > > initiating provider MUST verify the server certificate=20 > which SHOULD > > be rooted in a well-known certificate authority. =20 >=20 > That is going to be contentious. What are the "well-known=20 > certificate authorities"? The ones which have their keys=20 > installed in MSIE and Firefox? >=20 > Do you expect people to run white-lists based on the keys=20 > themselves or based on special-purpose CAs? >=20 > Or blacklists to keep baddies out? >=20 > If you allow the same CAs as used for TLS certs for websites=20 > then this is a huge community of potential peering partners.=20 > Not all of them are well-meaning and serious operators. >=20 > Do you expect to use CRLs? >=20 > What if the destination SIP server hosts multiple domains?=20 > Which cert is he supposed to present to an incoming SIP/TLS=20 > connection? >=20 > (This is the same problem as hosting multiple https: servers=20 > on a single server. Do you need one IP address per domain?) >=20 > > The initiating > > provider MUST be prepared to provide a TLS client=20 > 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=20 > production of the From > > header URI. The certificate SHOULD be valid and rooted=20 > in a well- > > known certificate authority. >=20 > Same question again as above. >=20 > What about TLS connection reuse? If both SIP servers serve=20 > URIs in multiple domains, can they reuse TLS connections=20 > which were established based on calls to a different domain=20 > (but hosted on the same server)? >=20 > > Note that the client certificate MAY contain a list of=20 > entries in the > > subjectAltName, only one of which has to match the=20 > domain in the From > > header URI. >=20 > What are the scalability limits to that? >=20 > Any moderately sized ISP mail server hosts mails for=20 > thousands of domains. Can this TLS setup scale to similar=20 > levels of domain hosting? >=20 > > 4.2 Receiving Peer > > 4.2.4 Receive SIP requests >=20 > > The receiving peer MAY reject incoming requests due to=20 > local policy. > > When a request is rejected because the initiating peer is not > > authorized to peer, the receiving peer SHOULD respond with a 403 > > response with the reason phrase "Unsupported Peer". >=20 > You have to distinguish rejects based on TLS negotiations and=20 > those on the SIP layer. >=20 > What is the sending peer supposed to do in that case? > Fall back to 4.1.4? Cache that result? If caching: per=20 > destination URI or per SIP proxy? For how long? >=20 > How do you prevent unsuccessful TLS establishments to become=20 > a kind of DoS attack? Firewalling could be an option on the=20 > destination side, but dropped packets lead to timeouts on the=20 > sender side which lead to unpredictable call-establishment delays. >=20 > -------- >=20 > As I wrote above: this draft is a good starting point for discussions. >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=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 Jun 19 13:45:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsNoU-00082i-0T; Mon, 19 Jun 2006 13:45:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsNoT-000814-4F for speermint@ietf.org; Mon, 19 Jun 2006 13:45:25 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsNoS-0003MO-L8 for speermint@ietf.org; Mon, 19 Jun 2006 13:45:25 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FsNoF-0008If-GW; Mon, 19 Jun 2006 12:45:12 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Otmar Lendl'" , Subject: RE: [Speermint] Just submitted draft-mahy-speermint-direct-peering-00 Date: Mon, 19 Jun 2006 13:45:13 -0400 Message-ID: <094901c693c8$20804fa0$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: <072C5B76F7CEAB488172C6F64B30B5E30197C384@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaTssTkyFIOg+f9RWyHsoCbptolrQAA976gAAP6hlA= 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: 0bb031f3a6fb29f760794ac9bf1997ae 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 Does this strike a chord with others? A federation is DEFINED, at least partially, by a CA handing out certs to club members useful to restrict calls to members of the club? I do think many federations will have more restrictive security policies than simply possession of a valid federation cert, but this idea could be one of those rare cases where a PKI can work. Remember: this is TLS. The NEXT HOP is the one that counts. So transit networks would work here. A transit network offering transit from A to B would have a cert in A and a cert in B. Originator X, in federation A, can check the transit network's A cert, and Y, the terminating network in B, can check the transit network's B cert. X -> ( A cloud ) -> Transit -> ( B cloud ) -> Y It's simple enough. If peering is by federation, it might work pretty well. Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Monday, June 19, 2006 11:44 AM To: Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Just submitted draft-mahy-speermint-direct-peering-00 To add to the discussion. I think it might be useful that federations as part of their role in peering to establish certificate authorities. One aspect of the comments below that we have to keep very distinct is that of authentication from authorization. You could potentially know, because a certificate is valid, exactly who the offending SP is. Whether you then white list or black list is a separate authorization issue. In that case, if they subscribe to get your policy, you send them to the ingress proxy at: 0.0.0.0 :) Mike > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Monday, June 19, 2006 11:12 AM > To: speermint@ietf.org > Subject: Re: [Speermint] Just submitted > draft-mahy-speermint-direct-peering-00 > > On 2006/06/19 10:06, Rohan Mahy wrote: > > Hi Folks, > > > > I just submitted a draft with a minimalist approach to peering. I > > thought this might be a useful way to have a productive > discussion on > > requirements. > > Thanks for the contribution. > > It's always helpful to have something concrete to talk about. > > Some comments: > > > 3. Overview > > > > The approach described here assumes that the initiating > peer first > > discovers a SIP [2] target URI handled by the receiving > peer, then > > sends SIP requests directly to the receiving peer. > > Perhaps you should also notice here that such ad-hoc peering > implies settlement-free peering. > > > Note that in a federation of domains, the initiating > peer role can be > > logically decomposed. Domain A1 can forward requests to > domain A2, > > so that A2 actually opens a TLS connection to the receiving peer. > > Likewise, the receiving peer function can be similarly > decomposed. > > How functions are distributed between or among domains > or nodes is > > not subject to this specification as long as the requirements > > described in this document are met. > > We have to be careful here to keep the terminology consistent > between the various documents. > > I used "peering" for calls within a federation, you seem to > use "peering" only for inter-federation connects. The latter > are not covered by draft-lendl-speermint-federations-00. > > A common understanding of this aspect will be important. > > > 4. Procedures > > I like this section. It's very helpful for the discussion. > > > 4.1.2 User ENUM lookup > > > > If an external E.164 address is the target, the initiating peer > > consults the public "User ENUM" rooted at e164.arpa, > according to the > > procedures described in RFC 3761. The peer MUST query > for the "E2U+ > > sip" enumservice as described in RFC 3674 [11], but MAY check for > > other enumservices. The initiating peer MAY consult a cache or > > alternate representation of the ENUM data rather than actual DNS > > queries. Also, the peer MAY skip actual DNS queries if the > > initiating peer is sure that the target address country > code is not > > represented in e164.arpa. If a sip: or sips: URI is > chosen, the peer > > skips to Section 4.1.5. > > IMHO the URIs as returned by User-ENUM do not require TLS > (except when they are sips: ones) as described in 4.1.6. > > They could point to end-user controlled devices (an Asterisk > installation, other VoIP-enabled PBX's or simple SIP > services). I see no need to insist on anything more than > pure RFC3263 for these cases. > > > 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. > > That is going to be contentious. What are the "well-known > certificate authorities"? The ones which have their keys > installed in MSIE and Firefox? > > Do you expect people to run white-lists based on the keys > themselves or based on special-purpose CAs? > > Or blacklists to keep baddies out? > > If you allow the same CAs as used for TLS certs for websites > then this is a huge community of potential peering partners. > Not all of them are well-meaning and serious operators. > > Do you expect to use CRLs? > > What if the destination SIP server hosts multiple domains? > Which cert is he supposed to present to an incoming SIP/TLS > connection? > > (This is the same problem as hosting multiple https: servers > on a single server. Do you need one IP address per domain?) > > > The initiating > > 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- > > known certificate authority. > > Same question again as above. > > What about TLS connection reuse? If both SIP servers serve > URIs in multiple domains, can they reuse TLS connections > which were established based on calls to a different domain > (but hosted on the same server)? > > > Note that the client certificate MAY contain a list of > entries in the > > subjectAltName, only one of which has to match the > domain in the From > > header URI. > > What are the scalability limits to that? > > Any moderately sized ISP mail server hosts mails for > thousands of domains. Can this TLS setup scale to similar > levels of domain hosting? > > > 4.2 Receiving Peer > > 4.2.4 Receive SIP requests > > > The receiving peer MAY reject incoming requests due to > local policy. > > When a request is rejected because the initiating peer is not > > authorized to peer, the receiving peer SHOULD respond with a 403 > > response with the reason phrase "Unsupported Peer". > > You have to distinguish rejects based on TLS negotiations and > those on the SIP layer. > > What is the sending peer supposed to do in that case? > Fall back to 4.1.4? Cache that result? If caching: per > destination URI or per SIP proxy? For how long? > > How do you prevent unsuccessful TLS establishments to become > a kind of DoS attack? Firewalling could be an option on the > destination side, but dropped packets lead to timeouts on the > sender side which lead to unpredictable call-establishment delays. > > -------- > > As I wrote above: this draft is a good starting point for discussions. > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > _______________________________________________ > 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 Jun 19 15:09:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsP8B-0004Rw-Jn; Mon, 19 Jun 2006 15:09:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsP8B-0004Rr-0a for speermint@ietf.org; Mon, 19 Jun 2006 15:09:51 -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 1FsP89-0004vF-Ml for speermint@ietf.org; Mon, 19 Jun 2006 15:09:50 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id C9EF81A37F; Mon, 19 Jun 2006 21:09:45 +0200 (CEST) Date: Mon, 19 Jun 2006 21:09:45 +0200 From: Otmar Lendl To: Brian Rosen Subject: Re: [Speermint] Just submitted draft-mahy-speermint-direct-peering-00 Message-ID: <20060619190945.GF2086@nic.at> Mail-Followup-To: Otmar Lendl , Brian Rosen , "'Michael Hammer (mhammer)'" , speermint@ietf.org References: <072C5B76F7CEAB488172C6F64B30B5E30197C384@xmb-rtp-20b.amer.cisco.com> <094901c693c8$20804fa0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <094901c693c8$20804fa0$640fa8c0@cis.neustar.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 2006/06/19 19:06, Brian Rosen wrote: > Does this strike a chord with others? http://www.ietf.org/internet-drafts/draft-lendl-speermint-federations-00.txt 3., first example. > A federation is DEFINED, at least partially, by a CA handing out certs to > club members useful to restrict calls to members of the club? > > I do think many federations will have more restrictive security policies > than simply possession of a valid federation cert, but this idea could be > one of those rare cases where a PKI can work. > > Remember: this is TLS. The NEXT HOP is the one that counts. So transit > networks would work here. A transit network offering transit from A to B > would have a cert in A and a cert in B. Originator X, in federation A, can > check the transit network's A cert, and Y, the terminating network in B, can > check the transit network's B cert. > > X -> ( A cloud ) -> Transit -> ( B cloud ) -> Y > > It's simple enough. If peering is by federation, it might work pretty well. Yes. My drafts aimed at getting the simple case within clouds/clubs (which are called federations in my drafts) nailed down and then build some sort of transit scheme on top of that. Some proposals on how to do this transit routing are floating around lunch conversations and private email and we hope to get some preliminary drafts ready for Montreal. Please note that TLS is just one scheme of building such clubs of SIP providers. You can do the same thing with IPsec, Firewalling or VPN setups. /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 Jun 19 15:44:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsPg2-0003dY-7Z; Mon, 19 Jun 2006 15:44:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsPg1-0003dT-6W for speermint@ietf.org; Mon, 19 Jun 2006 15:44:49 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsPfz-00087b-S7 for speermint@ietf.org; Mon, 19 Jun 2006 15:44:49 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Jun 2006 12:44:47 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,152,1149490800"; d="scan'208"; a="29975361:sNHT23913908" 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 k5JJihYP015913; Mon, 19 Jun 2006 15:44:47 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 15:44:44 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 15:44:44 -0400 Message-ID: <4496FEAB.5020002@cisco.com> Date: Mon, 19 Jun 2006 15:44:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Patrick Melampy Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture References: <004701c69332$13f1cf20$6801a8c0@acmepacket.com> In-Reply-To: <004701c69332$13f1cf20$6801a8c0@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2006 19:44:44.0611 (UTC) FILETIME=[D073D930:01C693D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: speermint@ietf.org, "'Livingood, Jason'" , "'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 Patrick, I can see that there may be many reasons why the calling SP does not have, and cannot establish a peering relationship with the called SP, and would indeed need to use an intermediary. But if SP-A lacks trust that SP-B will deliver the call to Bob, then adding an intermediary cannot fix that. Paul Patrick Melampy wrote: > Paul, > > It's clear that most of us Engineers (including me) don't understand what's > required to establish a business relationship for telephonic communications. > I'm guessing there are issues with taxation, regulation, service level > agreements, minimum usage, billing issues, currency issues, credit, and > more. Although I've never seen a peering agreement for voice traffic, I'm > guessing they are comprehensive. I personally am aware of IP Peering > relationships for voice that even have damage clauses for periods of service > interruption. > > Maybe somebody who understands why these relationships are so difficult to > establish and maintain could shed some light on this. If anybody could > easily and quickly establish a new peering relationship, then your position > is correct. Maybe you can help resolve all of the business issues to enable > "easy and quick" peering with on contracts, no taxes or regulation, and no > service level agreements. > > I do believe that Adam is correct that trust will depend on the signaling > infrastructure being open only to those networks that are trust worthy -- > with pre-established contractual guarantees. Any network that would break > the SIPS chain of trust MUST be excluded, or we need to find a way to ensure > that every party in the communication knows that the call is leaving the > trusted world and entering into untrusted networks. As far as I know, there > is no way currently to know that a SIP communication has followed a SIPS > trusted set of proxies from end-to-end. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Saturday, June 17, 2006 4:12 PM > To: Livingood, Jason > Cc: speermint@ietf.org; Uzelac, Adam > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > >>> -----Original Message----- >>> From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > >>> A service provide would be best served to provide its >>> subscribers a way to contact anyone else. The burden to >>> facilitate that session is on the SP. Will a SP in Topeka >>> trust a SP in Oslo enough to establish a direct peering >>> arrangement? Without that direct peer, how will the >>> subscribers of the Topeka SP access the folks in Oslo? An >>> intermediary most likely will be involved with the value >>> being reachability and trust that should a call be sent to >>> the transit provider, it will be completed as intended by the >>> calling party. At the end of the day, it will be the one that >>> will complete the call that gets the buck. Unfortunately >>> it's the PSTN that facilitates that Topeka to Oslo call today >>> more often than not. > > Assuming the provider for the caller can determine the provider for the > callee, then I fail to see how introducing an intermediary can improve > trust. No matter how many intermediaries are involved, ultimately the > callee's provider will be involved in the call. Establishing a direct > peering relationship seems at least as good, if not better. > > Paul > > _______________________________________________ > 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 Jun 19 17:01:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQrr-0004Dg-5f; Mon, 19 Jun 2006 17:01:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQrp-0004D4-Vb for speermint@ietf.org; Mon, 19 Jun 2006 17:01:05 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsQrp-0008PL-Ic for speermint@ietf.org; Mon, 19 Jun 2006 17:01:05 -0400 Received: by py-out-1112.google.com with SMTP id i75so1370473pye for ; Mon, 19 Jun 2006 14:01:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kFo0P9qdk7le6xelz1rQlqHPN4w6rYnqwr715cw+H/sLNlC/0q2M6Fgec1/NDoqqCkoVBySEuZ6yuTxtbGdPN6Z786aeNBkwgTHW5pK21qeCe2c6cNZ/4/5rWbnoiO1bL2Sb8uSxwkndWhf/Tpc4uWu+EL2ZjIack9Gs78AfbHQ= Received: by 10.35.50.9 with SMTP id c9mr8787572pyk; Mon, 19 Jun 2006 14:01:04 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Mon, 19 Jun 2006 14:01:04 -0700 (PDT) Message-ID: <953beacc0606191401x45b4f619sde213e665cdb2e4d@mail.gmail.com> Date: Mon, 19 Jun 2006 14:01:04 -0700 From: "Rohan Mahy" To: "Otmar Lendl" , speermint@ietf.org Subject: Re: [Speermint] Just submitted draft-mahy-speermint-direct-peering-00 In-Reply-To: <20060619151158.GB19113@nic.at> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <953beacc0606190159h5e6c40b5u4b51251eaab3f7b@mail.gmail.com> <20060619151158.GB19113@nic.at> X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 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 Otmar, Thanks for the review. My comments are inline. On 6/19/06, Otmar Lendl wrote: > On 2006/06/19 10:06, Rohan Mahy wrote: > > Hi Folks, > > > > I just submitted a draft with a minimalist approach to peering. I > > thought this might be a useful way to have a productive discussion on > > requirements. > > Thanks for the contribution. > > It's always helpful to have something concrete to talk about. > > Some comments: > > > 3. Overview > > > > The approach described here assumes that the initiating peer first > > discovers a SIP [2] target URI handled by the receiving peer, then > > sends SIP requests directly to the receiving peer. > > Perhaps you should also notice here that such ad-hoc peering implies > settlement-free peering. When the receiving peer is the carrier-of-record, settlement-free certainly makes a lot of sense. The approach does not prevent out-of-band settlement, which still makes sense if the receiving peer is providing PSTN termination. > > Note that in a federation of domains, the initiating peer role can be > > logically decomposed. Domain A1 can forward requests to domain A2, > > so that A2 actually opens a TLS connection to the receiving peer. > > Likewise, the receiving peer function can be similarly decomposed. > > How functions are distributed between or among domains or nodes is > > not subject to this specification as long as the requirements > > described in this document are met. > > We have to be careful here to keep the terminology consistent between > the various documents. > > I used "peering" for calls within a federation, you seem to use > "peering" only for inter-federation connects. The latter are not > covered by draft-lendl-speermint-federations-00. > > A common understanding of this aspect will be important. Agreed we should get a consensus on what to call inter-federation and intra-federation communications. > > 4. Procedures > > I like this section. It's very helpful for the discussion. > > > 4.1.2 User ENUM lookup > > > > If an external E.164 address is the target, the initiating peer > > consults the public "User ENUM" rooted at e164.arpa, according to the > > procedures described in RFC 3761. The peer MUST query for the "E2U+ > > sip" enumservice as described in RFC 3674 [11], but MAY check for > > other enumservices. The initiating peer MAY consult a cache or > > alternate representation of the ENUM data rather than actual DNS > > queries. Also, the peer MAY skip actual DNS queries if the > > initiating peer is sure that the target address country code is not > > represented in e164.arpa. If a sip: or sips: URI is chosen, the peer > > skips to Section 4.1.5. > > IMHO the URIs as returned by User-ENUM do not require TLS (except when > they are sips: ones) as described in 4.1.6. > > They could point to end-user controlled devices (an Asterisk > installation, other VoIP-enabled PBX's or simple SIP services). I see > no need to insist on anything more than pure RFC3263 for these cases. good point. I think this would be a good change. > > 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. > > That is going to be contentious. What are the "well-known certificate > authorities"? The ones which have their keys installed in MSIE and > Firefox? > > Do you expect people to run white-lists based on the keys themselves > or based on special-purpose CAs? > > Or blacklists to keep baddies out? > > If you allow the same CAs as used for TLS certs for websites then this > is a huge community of potential peering partners. Not all of them > are well-meaning and serious operators. I think well-known CAs (as used in web-browser for example) are appropriate for authentication. The reason I put a SHOULD above is to allow certs signed by a club, or even self-signed certs if both peers are OK with that. How the receiving peer decides to authorize the initiating peer is subject to local policy. Some peers could use an explicit whitelist mechanism (similar to traditional telephone network peering) and other peers could use a blacklist mechanism (similar to email networks with spam filtering). Either approach could use rating and/or accreditation services to assist in the authorization decision making. > Do you expect to use CRLs? I do not expect hosts to perform real-time CRL checks, but CRLs are still potentially useful input to an authorization decision. > What if the destination SIP server hosts multiple domains? Which > cert is he supposed to present to an incoming SIP/TLS connection? If the SIP server hosts multiple effectively equivalent domains (ex: mozilla.org, mozilla.com, getfirefox.com), it could present a single certificate with all of the domains in the subjectAltName (which is a really a list of names). For ordinary virtual hosting, the receiving peer needs to assign a separate port for each virtual host, just like we do with HTTPS virtual hosting, but because of SRV records, we can serve several hosts on a single IP address. Eventually we should migrate to using a TLS client extension (it already exists), so the TLS client can state in the client hello which domain its trying to contact. The TLS server then responds with the appropriate cert. > (This is the same problem as hosting multiple https: servers on > a single server. Do you need one IP address per domain?) > > > The initiating > > 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- > > known certificate authority. > > Same question again as above. > > What about TLS connection reuse? If both SIP servers serve URIs > in multiple domains, can they reuse TLS connections which were > established based on calls to a different domain (but hosted > on the same server)? As long as the certificate used to open the connection still covers the target domain. > > Note that the client certificate MAY contain a list of entries in the > > subjectAltName, only one of which has to match the domain in the From > > header URI. > > What are the scalability limits to that? Currently getting a CA to sign the resulting certificate is the hard part. ;-) > Any moderately sized ISP mail server hosts mails for thousands of > domains. Can this TLS setup scale to similar levels of domain hosting? If User ENUM does not need to use TLS, we only need to scale to the number of domains one receiving peer needs to handle for its carrier(s) of record. > > 4.2 Receiving Peer > > 4.2.4 Receive SIP requests > > > The receiving peer MAY reject incoming requests due to local policy. > > When a request is rejected because the initiating peer is not > > authorized to peer, the receiving peer SHOULD respond with a 403 > > response with the reason phrase "Unsupported Peer". > > You have to distinguish rejects based on TLS negotiations and those on > the SIP layer. good point. > What is the sending peer supposed to do in that case? > Fall back to 4.1.4? Cache that result? If caching: per destination > URI or per SIP proxy? For how long? I think the sending peer should continue trying other possibilities until it can't any more. I would like a message that conveys: you are not authorized to peer with this target domain name, so do not try again unless you have administrative information suggesting that situation has changed. This is different from the typical meaning of a 403 which means that the *request* is forbidden. > How do you prevent unsuccessful TLS establishments to become a kind of > DoS attack? Firewalling could be an option on the destination side, > but dropped packets lead to timeouts on the sender side which lead to > unpredictable call-establishment delays. there are already a variety of products that manage TLS establishment DoS attacks for web commerce. thanks, -rohan _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jun 19 17:05:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQvv-0007GQ-B1; Mon, 19 Jun 2006 17:05:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQvu-0007G6-KS for speermint@ietf.org; Mon, 19 Jun 2006 17:05:18 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsQvu-0000aH-8U for speermint@ietf.org; Mon, 19 Jun 2006 17:05:18 -0400 Received: by py-out-1112.google.com with SMTP id e30so1385116pya for ; Mon, 19 Jun 2006 14:05: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=GkaLjZfkPpKfal5neTQKBp7Gaa8Z+p200AJ5UkqnocZTXmF5yPrQWf/COh1c/rdmCGoqyjzKf6NsKsvgQnx4DU2/Wh19b7ZBL/QYb1Xdt+geDKboOOMyoINpwFRaNQ9jnNqCgrKfq+uLmm3HDXqyNHzq4BgXyV9XZhqUtUGBF54= Received: by 10.35.88.18 with SMTP id q18mr2138188pyl; Mon, 19 Jun 2006 14:05:18 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Mon, 19 Jun 2006 14:05:17 -0700 (PDT) Message-ID: <953beacc0606191405s52ef860fv8e0d143f36d9af9@mail.gmail.com> Date: Mon, 19 Jun 2006 14:05:17 -0700 From: "Rohan Mahy" To: "Jean-Francois Mule" Subject: Re: [Speermint] use of RFC 3263 for locating peer's SIP server In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: 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 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 From speermint-bounces@ietf.org Mon Jun 19 19:15:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsSyE-00034c-5s; Mon, 19 Jun 2006 19:15:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsSyD-00034I-Eu for speermint@ietf.org; Mon, 19 Jun 2006 19:15:49 -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 1FsSy9-0008TG-5A for speermint@ietf.org; Mon, 19 Jun 2006 19:15:49 -0400 Received: from ([10.20.9.172]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.21601810; Mon, 19 Jun 2006 19:15:16 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 19:15:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [speermint] minimum set of requirements forSIP-basedVoIPinterconnection and emergency calling Date: Mon, 19 Jun 2006 19:15:16 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96582021@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] minimum set of requirements forSIP-basedVoIPinterconnection and emergency calling thread-index: AcaQy9UFQqph1OmmQkG3q7q/eD4eXwAAJE2AABPiXXIAAT+JAAC09f7Q From: "Livingood, Jason" To: X-OriginalArrivalTime: 19 Jun 2006 23:15:16.0096 (UTC) FILETIME=[39678000:01C693F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Always interesting to see the WG pounce on a pretty innocent question. = ;-) To wit, should there be special emergency calling requirements for = interdomain calls? Nothing more and nothing less. One answer is NO, = all calls are treated the same. The other answer is YES, we believe = emergency calls should somehow be treated differently between two = domains OR at least have minimially different requirements. =20 I believe there is a line between ECRIT and SPEERMINT on this as with = ENUM and SPEERMINT. We just want to know if there may be any additional = requirements if we get a URI that clearly (in whatever manner) indicates = an emergency call. Not so controversial a question? ;-) So perhaps now, we'll leave it as a placeholder question and Dave and I = will chat up the ECRIT chairs in Montreal to get their thoughts. We're = clearly not at consensus yet I think. =20 Regards Jason =20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Friday, June 16, 2006 5:04 AM > To: Stastny Richard > Cc: speermint@ietf.org > Subject: RE: [speermint] minimum set of requirements=20 > forSIP-basedVoIPinterconnection and emergency calling >=20 > Stastny Richard wrote: > > Sorry, but I doubt that emergency services is within the scope of=20 > > speermint > > > > For emergency services normally either the UA itself or the=20 > first hop=20 > > proxy is responsible, so it never reaches the peering point at all > ^^^^^ > There are examples of VSP providers that do offer sip-based=20 > VoIP interconnect services today including 9-1-1. So your=20 > assertion that emergency calls do not reach "peering points"=20 > between VSPs is simply not true (based on current practices e > and this is by no means cable-specific). >=20 > > For emergency services normally either the UA itself or the=20 > first hop=20 > > proxy is responsible > I presume you mean responsible for "invoking the special=20 > routing procedures caused by an emergency dialed string or=20 > use of SOS URN". > This is ok but it does not necessarily mean that, upon=20 > determination that the call is an emergency call, the=20 > originating VSP does have to handle the SIP call to the PSAP=20 > within its own domain.=20 > Some VSPs do have gateways connected to the PSTN and the=20 > whole selective routers thingy in the North American system=20 > for example to do this; some don't and hand off the call to=20 > another VSP. The question of who does the ECRIT mapping=20 > protocol resolution is also not relevant here. >=20 > My first question was: > - should there be any minimal set of requirements (and=20 > ones applicable beyond national standards) for handling=20 > emergency calls that should be captured in a speermint=20 > requirement doc for SIP-based VoIP interconnect? >=20 > Jean-Fran=E7ois >=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 Jun 19 19:15:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsSyJ-000368-1t; Mon, 19 Jun 2006 19:15:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsSyH-00035t-78 for speermint@ietf.org; Mon, 19 Jun 2006 19:15:53 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsSyA-0008TJ-W7 for speermint@ietf.org; Mon, 19 Jun 2006 19:15:53 -0400 Received: from ([10.52.116.10]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.21504130; Mon, 19 Jun 2006 19:15:15 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 19:15:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Just submitted draft-mahy-speermint-direct-peering-00 Date: Mon, 19 Jun 2006 19:14:03 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96582020@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Just submitted draft-mahy-speermint-direct-peering-00 thread-index: AcaTss4Kk2o4EE6MSDG40vUNoGjuqgAQxpRw From: "Livingood, Jason" To: X-OriginalArrivalTime: 19 Jun 2006 23:15:15.0148 (UTC) FILETIME=[38D6D8C0:01C693F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > Some comments: >=20 > > 3. Overview > >=20 > > The approach described here assumes that the initiating=20 > peer first > > discovers a SIP [2] target URI handled by the receiving=20 > peer, then > > sends SIP requests directly to the receiving peer. >=20 > Perhaps you should also notice here that such ad-hoc peering=20 > implies settlement-free peering. I think it may be premature to speculate on settlement or cost models. Let's focus on the underlying stuff first. Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jun 20 05:55:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fscxd-0004ZG-0k; Tue, 20 Jun 2006 05:55:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fscxc-0004ZB-MG for speermint@ietf.org; Tue, 20 Jun 2006 05:55:52 -0400 Received: from lb01nat02.inode.at ([62.99.145.2] helo=mx.inode.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FscxZ-0007yK-RS for speermint@ietf.org; Tue, 20 Jun 2006 05:55:52 -0400 Received: from [89.144.245.137] (port=2915 helo=[89.144.245.137]) by smartmx-02.inode.at with esmtpsa (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.50) id 1FscxX-0006dw-DC; Tue, 20 Jun 2006 11:55:49 +0200 Received: from 127.0.0.1 (AVG SMTP 7.1.394 [268.9.1/369]); Tue, 20 Jun 2006 11:55:28 +0200 Message-ID: <4497C60F.7020900@inode.at> Date: Tue, 20 Jun 2006 11:55:27 +0200 From: Michael Haberler User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) To: Brian Rosen Subject: Re: [Speermint] Just submitted draft-mahy-speermint-direct-peering-00 References: <094901c693c8$20804fa0$640fa8c0@cis.neustar.com> In-Reply-To: <094901c693c8$20804fa0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: speermint@ietf.org, 'Otmar Lendl' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian Rosen schrieb: ... > I do think many federations will have more restrictive security policies > than simply possession of a valid federation cert, but this idea could be > one of those rare cases where a PKI can work. this is why we worked on OpenSer to add support for multiple TLS connection, per-connection certificates and enable choice of TLS pipe based on the target federation as delivered by the domain policy matching method as per Otmar's I-D for inquisitive minds: see http://www.openser.org/docs/tls.html for the multiple TLS connection/cert support see http://www.enum.at/index.php?id=dokumente (free signup required) for code and documentation on domain policy matching, and infrastructure ENUM resolver in OpenSer -Michael > It's simple enough. If peering is by federation, it might work pretty well. > > Brian > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, June 19, 2006 11:44 AM > To: Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] Just submitted > draft-mahy-speermint-direct-peering-00 > > To add to the discussion. > > I think it might be useful that federations as part of their role in > peering to establish certificate authorities. > > One aspect of the comments below that we have to keep very distinct is > that of authentication from authorization. You could potentially know, > because a certificate is valid, exactly who the offending SP is. > Whether you then white list or black list is a separate authorization > issue. In that case, if they subscribe to get your policy, you send > them to the ingress proxy at: 0.0.0.0 :) > > Mike > > > >> -----Original Message----- >> From: Otmar Lendl [mailto:lendl@nic.at] >> Sent: Monday, June 19, 2006 11:12 AM >> To: speermint@ietf.org >> Subject: Re: [Speermint] Just submitted >> draft-mahy-speermint-direct-peering-00 >> >> On 2006/06/19 10:06, Rohan Mahy wrote: >> >>> Hi Folks, >>> >>> I just submitted a draft with a minimalist approach to peering. I >>> thought this might be a useful way to have a productive >>> >> discussion on >> >>> requirements. >>> >> Thanks for the contribution. >> >> It's always helpful to have something concrete to talk about. >> >> Some comments: >> >> >>> 3. Overview >>> >>> The approach described here assumes that the initiating >>> >> peer first >> >>> discovers a SIP [2] target URI handled by the receiving >>> >> peer, then >> >>> sends SIP requests directly to the receiving peer. >>> >> Perhaps you should also notice here that such ad-hoc peering >> implies settlement-free peering. >> >> >>> Note that in a federation of domains, the initiating >>> >> peer role can be >> >>> logically decomposed. Domain A1 can forward requests to >>> >> domain A2, >> >>> so that A2 actually opens a TLS connection to the receiving peer. >>> Likewise, the receiving peer function can be similarly >>> >> decomposed. >> >>> How functions are distributed between or among domains >>> >> or nodes is >> >>> not subject to this specification as long as the requirements >>> described in this document are met. >>> >> We have to be careful here to keep the terminology consistent >> between the various documents. >> >> I used "peering" for calls within a federation, you seem to >> use "peering" only for inter-federation connects. The latter >> are not covered by draft-lendl-speermint-federations-00. >> >> A common understanding of this aspect will be important. >> >> >>> 4. Procedures >>> >> I like this section. It's very helpful for the discussion. >> >> >>> 4.1.2 User ENUM lookup >>> >>> If an external E.164 address is the target, the initiating peer >>> consults the public "User ENUM" rooted at e164.arpa, >>> >> according to the >> >>> procedures described in RFC 3761. The peer MUST query >>> >> for the "E2U+ >> >>> sip" enumservice as described in RFC 3674 [11], but MAY check for >>> other enumservices. The initiating peer MAY consult a cache or >>> alternate representation of the ENUM data rather than actual DNS >>> queries. Also, the peer MAY skip actual DNS queries if the >>> initiating peer is sure that the target address country >>> >> code is not >> >>> represented in e164.arpa. If a sip: or sips: URI is >>> >> chosen, the peer >> >>> skips to Section 4.1.5. >>> >> IMHO the URIs as returned by User-ENUM do not require TLS >> (except when they are sips: ones) as described in 4.1.6. >> >> They could point to end-user controlled devices (an Asterisk >> installation, other VoIP-enabled PBX's or simple SIP >> services). I see no need to insist on anything more than >> pure RFC3263 for these cases. >> >> >>> 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. >>> >> That is going to be contentious. What are the "well-known >> certificate authorities"? The ones which have their keys >> installed in MSIE and Firefox? >> >> Do you expect people to run white-lists based on the keys >> themselves or based on special-purpose CAs? >> >> Or blacklists to keep baddies out? >> >> If you allow the same CAs as used for TLS certs for websites >> then this is a huge community of potential peering partners. >> Not all of them are well-meaning and serious operators. >> >> Do you expect to use CRLs? >> >> What if the destination SIP server hosts multiple domains? >> Which cert is he supposed to present to an incoming SIP/TLS >> connection? >> >> (This is the same problem as hosting multiple https: servers >> on a single server. Do you need one IP address per domain?) >> >> >>> The initiating >>> 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- >> >>> known certificate authority. >>> >> Same question again as above. >> >> What about TLS connection reuse? If both SIP servers serve >> URIs in multiple domains, can they reuse TLS connections >> which were established based on calls to a different domain >> (but hosted on the same server)? >> >> >>> Note that the client certificate MAY contain a list of >>> >> entries in the >> >>> subjectAltName, only one of which has to match the >>> >> domain in the From >> >>> header URI. >>> >> What are the scalability limits to that? >> >> Any moderately sized ISP mail server hosts mails for >> thousands of domains. Can this TLS setup scale to similar >> levels of domain hosting? >> >> >>> 4.2 Receiving Peer >>> 4.2.4 Receive SIP requests >>> >>> The receiving peer MAY reject incoming requests due to >>> >> local policy. >> >>> When a request is rejected because the initiating peer is not >>> authorized to peer, the receiving peer SHOULD respond with a 403 >>> response with the reason phrase "Unsupported Peer". >>> >> You have to distinguish rejects based on TLS negotiations and >> those on the SIP layer. >> >> What is the sending peer supposed to do in that case? >> Fall back to 4.1.4? Cache that result? If caching: per >> destination URI or per SIP proxy? For how long? >> >> How do you prevent unsuccessful TLS establishments to become >> a kind of DoS attack? Firewalling could be an option on the >> destination side, but dropped packets lead to timeouts on the >> sender side which lead to unpredictable call-establishment delays. >> >> -------- >> >> As I wrote above: this draft is a good starting point for discussions. >> >> /ol >> -- >> < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >> >> _______________________________________________ >> 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 > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.1/369 - Release Date: 19.06.2006 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jun 21 12:19:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5QO-0004ML-Ne; Wed, 21 Jun 2006 12:19:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5QO-0004MG-3c for speermint@ietf.org; Wed, 21 Jun 2006 12:19:28 -0400 Received: from outbound-fra.frontbridge.com ([62.209.45.174] helo=outbound1-fra-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5QM-0004oF-MW for speermint@ietf.org; Wed, 21 Jun 2006 12:19:28 -0400 Received: from outbound1-fra.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-fra-R.bigfish.com (Postfix) with ESMTP id 0C38C883C97 for ; Wed, 21 Jun 2006 16:19:26 +0000 (UTC) Received: from mail15-fra-R.bigfish.com (unknown [172.18.18.1]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound1-fra.bigfish.com (Postfix) with ESMTP id F1093883CCA for ; Wed, 21 Jun 2006 16:19:25 +0000 (UTC) Received: from mail15-fra.bigfish.com (localhost.localdomain [127.0.0.1]) by mail15-fra-R.bigfish.com (Postfix) with ESMTP id D73E36085E0 for ; Wed, 21 Jun 2006 16:19:25 +0000 (UTC) X-BigFish: V Received: by mail15-fra (MessageSwitch) id 1150906765331845_15906; Wed, 21 Jun 2006 16:19:25 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail15-fra.bigfish.com (Postfix) with ESMTP id 1607D607BEC for ; Wed, 21 Jun 2006 16:19:24 +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 k5LGJ4RB000519 for ; Wed, 21 Jun 2006 11:19:19 -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 k5LGJ2b22418 for ; Wed, 21 Jun 2006 11:19:02 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by pdawg06a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 11:18: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 Date: Wed, 21 Jun 2006 11:18:29 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A13A0C42F@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Speermint Peering Architecture Draft Thread-Index: AcaTss4Kk2o4EE6MSDG40vUNoGjuqgAQxpRwAFYKMGA= From: "Khan, Sohel Q [CTO]" To: X-OriginalArrivalTime: 21 Jun 2006 16:18:59.0758 (UTC) FILETIME=[672C44E0:01C6954E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Speermint] Speermint 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 =20 The Version 3.0 of the Speermint Peering Architecture can be found at: http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-arch-03.txt Thank you. Sohel Khan _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jun 21 17:42:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtASV-0003HI-IP; Wed, 21 Jun 2006 17:41:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtASU-0003Gm-Cs for speermint@ietf.org; Wed, 21 Jun 2006 17:41: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 1FtADy-0007TN-UU for speermint@ietf.org; Wed, 21 Jun 2006 17:26:58 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtA0V-0006DM-7J for speermint@ietf.org; Wed, 21 Jun 2006 17:13:05 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.6/8.13.6) with ESMTP id k5LLD0Hv063896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Jun 2006 21:13:00 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k5LLFMeB100032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 21 Jun 2006 23:15:22 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k5LLD04v002541 for ; Wed, 21 Jun 2006 23:13:00 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5LLD0vB002538 for ; Wed, 21 Jun 2006 23:13:00 +0200 To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Thu, 22 Jun 2006 00:16:00 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.1HF123 | April 14, 2006) at 22/06/2006 00:15:21, Serialize complete at 22/06/2006 00:15:21 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: -2.3 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Speermint] Provisioning requirements 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 http://www.ietf.org/internet-drafts/draft-houri-speermint-rtc-provisioning-reqs-00.txt Real Time Communications (RTC) tools are becoming as prevalent and essential for users on the Internet as email. While RTC tools can, like email, be implemented directly by users in a point-to-point fashion, they are often provided for or on behalf of a community of users within an administrative domain. As the use of these tools grows, users increasingly have the need to communicate with users not only within their own community but with those in other communities as well. In practice, each community is controlled by some authority, and so there is a need to provide for easier establishment of connectivity between communities, and the management of the inter- community link. This document contains an initial list of requirements for provisioning and managing connectivity between communities. --Avshalom _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jun 21 22:27:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtEur-0005Bz-GV; Wed, 21 Jun 2006 22:27:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtEuo-0004zh-7b; Wed, 21 Jun 2006 22:27:30 -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 1FtBlR-0006N9-CW; Wed, 21 Jun 2006 19:05:37 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtBZX-0008MG-2L; Wed, 21 Jun 2006 18:53:20 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5LMo1mU026466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtBWL-0003DH-QT; Wed, 21 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 21 Jun 2006 18:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION: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 --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 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-requirements-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. --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-6-21160711.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-21160711.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 Jun 22 09:10:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOwY-0005Cu-Hs; Thu, 22 Jun 2006 09:09:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOwW-00057P-Qz for speermint@ietf.org; Thu, 22 Jun 2006 09:09:56 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtOwV-0002up-IS for speermint@ietf.org; Thu, 22 Jun 2006 09:09:56 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5MD9sXe011082 for ; Thu, 22 Jun 2006 07:09:54 -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: [speermint] requirements draft submitted Date: Thu, 22 Jun 2006 07:09:54 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] requirements draft submitted Thread-Index: AcaVe5BSv6x0w0C1TiKNz/WT3DVSKgAeqhrg From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 An initial draft of the speermint wg requirements is now available at: http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-00 .txt Jean-Francois. jfm@cablelabs.com _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 22 13:52:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTLf-0005MO-7Y; Thu, 22 Jun 2006 13:52:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTLd-0005M9-Gr for speermint@ietf.org; Thu, 22 Jun 2006 13:52:09 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtTLc-0003Zw-3q for speermint@ietf.org; Thu, 22 Jun 2006 13:52:09 -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 k5MHq7Uc029437 for ; Thu, 22 Jun 2006 10:52:07 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k5MHq7px029436 for speermint@ietf.org; Thu, 22 Jun 2006 10:52:07 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 22 Jun 2006 10:52:07 -0700 From: David Meyer To: speermint@ietf.org Message-ID: <20060622175207.GA29426@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: cab78e1e39c4b328567edb48482b6a69 Subject: [Speermint] FYI -- [chair@ietf.org: Montreal agenda still in flux] 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="===============1621851655==" Errors-To: speermint-bounces@ietf.org --===============1621851655== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from IETF Chair ----- > From: IETF Chair > To: IETF Announcement list > Cc:=20 > Subject: Montreal agenda still in flux=20 > Date: Thu, 22 Jun 2006 13:26:51 -0400 >=20 > Please be aware that there are still a few unresolved clashes, > and the Secretariat is working on this, so (as always) please do > not be surprised if there are some more agenda changes. Obviously=20 > we attempt to minimize late changes, but they are likely to=20 > continue for several more days. >=20 > For the latest agenda, please check this URL: >=20 > https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num= =3D66 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEmtjHORgD1qCZ2KcRAu89AJ973357Vh/qEWeePfQkp9z356O5rgCfauG6 rgbNwqp8o+yP/z8mDFHZ5Ic= =QQgo -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- --===============1621851655== 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 --===============1621851655==-- From speermint-bounces@ietf.org Thu Jun 22 14:24:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTr7-00063K-RH; Thu, 22 Jun 2006 14:24:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTr7-00063F-J8 for speermint@ietf.org; Thu, 22 Jun 2006 14:24:41 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtTr6-00064n-8J for speermint@ietf.org; Thu, 22 Jun 2006 14:24:41 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 22 Jun 2006 11:24:39 -0700 X-IronPort-AV: i="4.06,166,1149490800"; d="scan'208"; a="556965050:sNHT69275752" 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: Comments (RE: [speermint] requirements draft submitted) Date: Thu, 22 Jun 2006 14:24:37 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804B9DADD@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments (RE: [speermint] requirements draft submitted) Thread-Index: AcaVe5BSv6x0w0C1TiKNz/WT3DVSKgAeqhrgAAu/ePA= From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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 Francois, Comments on your draft "2.3. No blocked calls" I think the title of this subsection should be changed to something else since blocked calls (just like normal IP packets) can always happen due to call limits, QoS, white/black lists, etc, etc I think there is a distinction on what can be achieved in terms of static vs. dynamic data available. The data is DNS is static and does not reflect that state of the network. Actually since DNS is an out of band mechanism, it does not even guarantee that your layer 3 peering connections are up. "Per-service provider opt-in without consultation of a centralized 'peering registry', but rather by publishing local configuration choices only is highly desirable." Not sure I understand the connection between the first and second phrases. Did you mean "Instead of a per-service...., providers should publish"?=20 Or is the first option acceptable? Personally I think that tackling the (N^2) problem is very important but there will certainly be deployments where providers prefer a centralized registry (intra federation calls could be an example). "2.5. Independence of lower layers The system needs to be independent of details on what technologies are used route" Which "system" do you refer here? I think independence is very important but not sure it is totally achievable. I guess it depends how it is worded. For example, see my comments to the no blocked calls above. "2.7. Minimal additional cost on call initiation Since each call setup implies execution of any proposed algorithm, it should incur minimal overhead and delay, and employ caching wherever possible to avoid extra protocol round trips." We should mention that caching brings with it security problems. I can foresee similar attacks like "SIP/URI" cache poisoning, etc "2.8. Look beyond SIP" Good point. Although SMTP and SIP have different needs in terms of delay and security. "3.3. Media-related requirements" It seems to me media related requirements as you stated come into play _if_ somebody is using a media relay. Otherwise the decision is between the endpoints and we do not care/it is out of scope right? For example, " o the support of the VoIP metric block as defined in RTP Control Protocol Extended Reports [RFC3611] MAY be supported." Between which entities? I'm assuming you mean between media relays since if it is between the endpoints we really do not care/it is out of scope, right?=20 I think media requirements strictly related to speermint could be QoS across the fabric and discussed in the list and stated in the message flows draft and maybe some requirements in terms of control vs data routing. "3.4. Security requirements All SIP messages MUST be sent over TLS [RFC3546] to provide transport-layer security as defined in RFC 3261," Giving the fact that we can have security through physical segregation, intra-federation/provider calls, etc, the "MUST" here seems too generic. I think we should say something like "in the case of public on-demand peering SIP messages...." Good draft. Thanks, Reinaldo > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Thursday, June 22, 2006 6:10 AM > To: speermint@ietf.org > Subject: [speermint] requirements draft submitted >=20 >=20 > An initial draft of the speermint wg requirements is now available at: > http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-00 > .txt >=20 > Jean-Francois. > jfm@cablelabs.com >=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 Fri Jun 23 09:56:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftm8w-0006Yl-EX; Fri, 23 Jun 2006 09:56:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftm8v-0006QY-9h for speermint@ietf.org; Fri, 23 Jun 2006 09:56:17 -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 1Ftm8t-0007NJ-QM for speermint@ietf.org; Fri, 23 Jun 2006 09:56:17 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id BF07A1A384; Fri, 23 Jun 2006 15:56:13 +0200 (CEST) Date: Fri, 23 Jun 2006 15:56:13 +0200 From: Otmar Lendl To: Reinaldo Penno Subject: Re: Comments (RE: [speermint] requirements draft submitted) Message-ID: <20060623135613.GD19113@nic.at> Mail-Followup-To: Otmar Lendl , Reinaldo Penno , speermint@ietf.org References: <9BD5D7887235424FA97DFC223CAE3C2804B9DADD@proton.jnpr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804B9DADD@proton.jnpr.net> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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 2006/06/22 20:06, Reinaldo Penno wrote: > Hello Francois, > > Comments on your draft Some comments from me as well. > > "2.3. No blocked calls" > > I think the title of this subsection should be changed to something else > since blocked calls (just like normal IP packets) can always happen due > to call limits, QoS, white/black lists, etc, etc I agree with you on call limits and QoS as these are dynamic variables which are hard to avoid. On the other hand white/black lists are configuration issues and in that case I think we should try to avoid sending INVITES to someone who per configuration does not want to talk to us. > I think there is a distinction on what can be achieved in terms of > static vs. dynamic data available. The data is DNS is static and does > not reflect that state of the network. Actually since DNS is an out of > band mechanism, it does not even guarantee that your layer 3 peering > connections are up. Wait a second. We're talking about requirements here. The DNS may be part of the solution but need not be. The requirement just states that you should not blindly try to send SIP invites without having good reasons to think that the call will get through. If you do your peering using special layer 3 connections, then this requirement means that you should synchronize your SIP stack with your layer 3 state. I.e.: don't bother generating SIP packets if the IPSEC tunnels are down. Or if you do some sort of SUBSCRIBE/NOTIFY to establish peerings, then you shouldn't send INVITES unless the last notify you received gave you a green light. > "Per-service provider opt-in > without consultation of a centralized 'peering registry', but rather > by publishing local configuration choices only is highly desirable." > > Not sure I understand the connection between the first and second > phrases. Did you mean "Instead of a per-service...., providers should > publish"? Yes, that sentence is broken. What about: "A VSP opt-in by publishing local configuration choices is preferrable to a centralized 'peering registry'." > Or is the first option acceptable? Personally I think that tackling the > (N^2) problem is very important but there will certainly be deployments > where providers prefer a centralized registry (intra federation calls > could be an example). Agreed, within federations such registries could be fine. I doubt that such registries can scale to the inter-federation (that is: global reachability) case. Such a global registry might be possible on technical grounds, but in terms of politics and economics this is not feasible. Who would every VSP trust to run that global registry? > "2.5. Independence of lower layers > > The system needs to be independent of details on what technologies > are used route" > > Which "system" do you refer here? I think independence is very important > but not sure it is totally achievable. I guess it depends how it is > worded. For example, see my comments to the no blocked calls above. "system" here stands for the world-wide peer discovery system. The algorithm to find peers should be independent of how you talk to that peer. > "2.7. Minimal additional cost on call initiation > > Since each call setup implies execution of any proposed algorithm, it > should incur minimal overhead and delay, and employ caching wherever > possible to avoid extra protocol round trips." > > We should mention that caching brings with it security problems. I can > foresee similar attacks like "SIP/URI" cache poisoning, etc What about some generic security requirement? (independently of caching) > > "2.8. Look beyond SIP" > > Good point. Although SMTP and SIP have different needs in terms of delay > and security. Yes. If you look e.g. at MMS which are transmitted via SMTP you might find similar requirements in terms of security. [...] > > "3.4. Security requirements > > All SIP messages MUST be sent over TLS [RFC3546] to provide > transport-layer security as defined in RFC 3261," > > Giving the fact that we can have security through physical segregation, > intra-federation/provider calls, etc, the "MUST" here seems too generic. > > I think we should say something like "in the case of public on-demand > peering SIP messages...." > Agreed. IMHO the Speermint work falls into two separate areas: * Federation discovery & routing This needs to be a global standard. * Intra-federation peering rules In theory each federation could write its own rules. Speermint should provide a best practice document for that. > Good draft. yes. /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 Fri Jun 23 10:22:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtmXv-0006sJ-FC; Fri, 23 Jun 2006 10:22:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtmXs-0006rx-Q8 for speermint@ietf.org; Fri, 23 Jun 2006 10:22:05 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtmXr-0000lq-GX for speermint@ietf.org; Fri, 23 Jun 2006 10:22:04 -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 k5NEM1T7027680 for ; Fri, 23 Jun 2006 09:22:01 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 23 Jun 2006 15:22:00 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290933@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: speermint@ietf.org Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Fri, 23 Jun 2006 15:21:57 +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: 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 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 From speermint-bounces@ietf.org Fri Jun 23 10:38:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftmnd-0000QQ-No; Fri, 23 Jun 2006 10:38:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftmnc-0000QL-7B for speermint@ietf.org; Fri, 23 Jun 2006 10:38:20 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftmna-0003Tv-RK for speermint@ietf.org; Fri, 23 Jun 2006 10:38:20 -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 k5NEcIql017378 for ; Fri, 23 Jun 2006 07:38:18 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k5NEcIW9017377 for speermint@ietf.org; Fri, 23 Jun 2006 07:38:18 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 23 Jun 2006 07:38:18 -0700 From: David Meyer To: speermint@ietf.org Message-ID: <20060623143818.GA17359@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: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Speermint] FYI -- [ietf-secretariat@ietf.org: Revised Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada] 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="===============2094484360==" Errors-To: speermint-bounces@ietf.org --===============2094484360== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from ietf-secretariat@ietf.org ----- > From: ietf-secretariat@ietf.org > To: ietf-announce@ietf.org > Cc:=20 > Subject: Revised Internet-Drafts Submission Cutoff Dates for the 66th IET= F=20 > Meeting in Montreal, Quebec, Canada=20 > Date: Fri, 23 Jun 2006 00:00:01 -0400 >=20 >=20 > All revised Internet-Drafts (version -01 and higher) must be submitted=20 > by Monday, June 26th at 9:00 AM ET. >=20 > Revised Internet-Drafts received after the cutoff date will not be made > available in the Internet-Drafts directory or announced until on or=20 > after Monday, July 10th at 9:00 AM ET, when Internet-Draft posting=20 > resumes. Please do not wait until the last minute to submit. >=20 > Thank you for your understanding and cooperation. If you have any=20 > questions or concerns, then please send a message to=20 > internet-drafts@ietf.org. >=20 > The IETF Secretariat >=20 > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 66th IETF Meeting can be found at http://www.ietf.org/meetings/cu= toff_dates_66.html. >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEm/zaORgD1qCZ2KcRAr0DAJ9+nnw5wAM/YL4QHzhGxFW7soIE5gCeJCTm GMDEa246SoSYLWIg5mPcIyA= =kMbS -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- --===============2094484360== 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 --===============2094484360==-- From speermint-bounces@ietf.org Fri Jun 23 11:03:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtnBY-00018O-UF; Fri, 23 Jun 2006 11:03:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtnBX-00018J-Gk for speermint@ietf.org; Fri, 23 Jun 2006 11:03:03 -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 1FtnBV-000119-86 for speermint@ietf.org; Fri, 23 Jun 2006 11:03:03 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id F1A551A3BF; Fri, 23 Jun 2006 17:02:59 +0200 (CEST) Date: Fri, 23 Jun 2006 17:02:59 +0200 From: Otmar Lendl To: speermint@ietf.org Message-ID: <20060623150259.GE19113@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 1.1 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Speermint] Update to draft-lendl-speermint-federations X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org FYI, an updated version of draft-lendl-speermint-federations has been submitted to the RFC editors. This version adds a lot of explanatory text and examples. I am glad that Mike Hammer and Michael Haberler joined in as co-authors. Michael will do a presentation in Montreal. The new version can be found at http://www.enum.at/ietf/draft-lendl-speermint-federations-01.txt and http://www.enum.at/ietf/draft-lendl-speermint-federations-01.html Comments are welcome! /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 Fri Jun 23 17:32:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FttGK-0000eh-AE; Fri, 23 Jun 2006 17:32:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FttGJ-0000cm-73 for speermint@ietf.org; Fri, 23 Jun 2006 17:32:23 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftt7s-0008Aw-LO for speermint@ietf.org; Fri, 23 Jun 2006 17:23:42 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Jun 2006 14:23:40 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,170,1149490800"; d="scan'208"; a="30367434:sNHT24827692" 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 k5NLNdYL024460; Fri, 23 Jun 2006 17:23:39 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Jun 2006 17:23:39 -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, 23 Jun 2006 17:23:38 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3019E9E07@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: AcaW0HCasWeyhJ8uRYSVLbb9qPMhmgAOqmvQ From: "Michael Hammer \(mhammer\)" To: "Drage, Keith \(Keith\)" , X-OriginalArrivalTime: 23 Jun 2006 21:23:39.0505 (UTC) FILETIME=[4B93CE10:01C6970B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org 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]=20 > Sent: Friday, June 23, 2006 10:22 AM > To: speermint@ietf.org > Subject: RE: [Speermint] I-D=20 > ACTION:draft-ietf-speermint-requirements-00.t xt=20 >=20 > Section 3.5 indicates: >=20 > The minimum requirements to allow a successful VoIP interconnection > include: >=20 > o the mandatory support of RTP *and* RTCP as defined in [RFC3550], >=20 > o the support of compatible codecs between communication=20 > peers, the > G.711 MUST be supported, the IETF iLBC [RFC3951] codec=20 > and its RTP > payload format [RFC3952] SHOULD be supported. >=20 > o the support of the VoIP metric block as defined in RTP Control > Protocol Extended Reports [RFC3611] MAY be supported. >=20 > What exactly does this mean to the two bodies that are making=20 > the peering arrangement. Is this a requirement to control the=20 > codecs used by the UAs attached to the peering organisations=20 > equipment before peering can occur, or a requirement to=20 > support transcoding if these requirements are not met by the=20 > population of attached UAs. >=20 > 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). >=20 > regards >=20 > Keith >=20 > > -----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 > >=20 > >=20 > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > This draft is a work item of the Session PEERing for Multimedia=20 > > INTerconnect Working Group of the IETF. > >=20 > > Title : SPEERMINT Requirements for SIP-based=20 > > VoIP Interconnection > > Author(s) : J. Mule > > Filename : draft-ietf-speermint-requirements-00.txt > > Pages : 10 > > Date : 2006-6-21 > > =09 > > This document describes general requirements for Session PEERing=20 > > for > > Multimedia INTerconnect and defines the minimum set of=20 > requirements > > applicable to SIP session peering for VoIP interconnects. > >=20 > > 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=20 > > the > > technical protocol requirements that apply to VoIP interconnects. > >=20 > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-speermint-requi > rements-00.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-speermint-requirements-00.txt". >=20 > 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 >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-ietf-speermint-requirements-00.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=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 Jun 23 18:30:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtuAc-0002Fz-D8; Fri, 23 Jun 2006 18:30:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtuAb-0002Ft-UN for speermint@ietf.org; Fri, 23 Jun 2006 18:30:33 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FtuAa-0005gi-KD for speermint@ietf.org; Fri, 23 Jun 2006 18:30:33 -0400 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 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sat, 24 Jun 2006 00:34:40 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AEF@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: AcaW0HCasWeyhJ8uRYSVLbb9qPMhmgAOqmvQAAJT4mE= References: <072C5B76F7CEAB488172C6F64B30B5E3019E9E07@xmb-rtp-20b.amer.cisco.com> From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 >o Should the minimum set of requirements for VoIP interconnect > include any media-related requirements at all? > o The speerming charter defines "VoIP" as in voice calls. Does > voice communication mean audio only or more? audio, DTMF tones, > real-time fax, voiceband data? IMHO not: Speermint is dealing with the interworking between proxies media is basically an interworling between endpoints =20 In addition, as said in the second bullet, why just defining the = audio-codecs? =20 =20 regards -sta =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Jun 25 14:41:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuZXr-0008HW-Of; Sun, 25 Jun 2006 14:41:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuZXr-0008HE-8h for speermint@ietf.org; Sun, 25 Jun 2006 14:41:19 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuZXq-0005mH-TF for speermint@ietf.org; Sun, 25 Jun 2006 14:41:19 -0400 Received: by py-out-1112.google.com with SMTP id s49so1330760pyc for ; Sun, 25 Jun 2006 11:41: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=nePNDZ7BuZrynmA0Ngi4UzscCkQqw2wTRE6kkgVWaf+LeCrckJ5I+EZXqBx4CUdl0BS1RW30RvudCA+DNSmnoURbESXXvS0yAD9ZVOSIPQeQaYlJHWtpVN/b5hL9DxzMJC0Wf8GV4ig4alBcY8eAGZuAl0OidxlI/Qa7QL1M/z0= Received: by 10.35.88.18 with SMTP id q18mr4998458pyl; Sun, 25 Jun 2006 11:41:18 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Sun, 25 Jun 2006 11:41:18 -0700 (PDT) Message-ID: <953beacc0606251141j2d6b9602mee34bd2e761431f@mail.gmail.com> Date: Sun, 25 Jun 2006 11:41:18 -0700 From: "Rohan Mahy" To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3019E9E07@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: <072C5B76F7CEAB488172C6F64B30B5E3019E9E07@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 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 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 From speermint-bounces@ietf.org Mon Jun 26 14:19:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuvgb-0004EP-57; Mon, 26 Jun 2006 14:19:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuvga-0004EK-0j for speermint@ietf.org; Mon, 26 Jun 2006 14:19:48 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuvgY-0007eG-Jh for speermint@ietf.org; Mon, 26 Jun 2006 14:19:47 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 26 Jun 2006 14:19:47 -0400 X-IronPort-AV: i="4.06,177,1149480000"; d="scan'208"; a="91038025:sNHT34218364" 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 k5QIJiYR004448; Mon, 26 Jun 2006 14:19:46 -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); Mon, 26 Jun 2006 14:19: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] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Mon, 26 Jun 2006 14:19:44 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3019EA161@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: AcaYhvPCapz8npTfRYquUdaD03iAdgAxa98w From: "Michael Hammer \(mhammer\)" To: "Rohan Mahy" X-OriginalArrivalTime: 26 Jun 2006 18:19:46.0111 (UTC) FILETIME=[1A66BCF0:01C6994D] X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 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, Agree with your codec point. I was indirectly pushing that out as being just another policy element. You are missing what I am promoting. I want "federation" to be a protocol element, so you can map domains to federations. Being able to learn such associations in DNS will enable two parties to determine if they "speak" the same federation dialect, i.e. can route SIP directly or not. Mike=20 > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 > Sent: Sunday, June 25, 2006 2:41 PM > To: Michael Hammer (mhammer) > Cc: Drage, Keith (Keith); speermint@ietf.org > Subject: Re: [Speermint] I-D=20 > ACTION:draft-ietf-speermint-requirements-00.t xt >=20 > Mike, >=20 > There is no requirement for a federation to exist in=20 > speermint. It might or it might not, but the IETF won't be=20 > very effective trying to put requirements on something which=20 > is effectively a business arrangement. We can define a set=20 > of protocols however, which needs to be useful in the big-I=20 > Internet and hopefully for folks building federations and=20 > other clubs as well. >=20 > Everyone, >=20 > I think codec selection should be out of scope. Mandating=20 > G.711 will have no positive effect now. Everyone supports it=20 > today in some way or another, but it could be detrimental in=20 > the future. The point of the SDP negotiation is to allow RTP=20 > *endpoints* to select the best codec in common under the=20 > circumstances. I don't think we can do any better than that=20 > in a requirements document, especially since we are=20 > describing an interface between SIP intermediaries that I=20 > hope will not even be a participant in the RTP media most of the time. >=20 > thanks, > -rohan >=20 >=20 >=20 > On 6/23/06, Michael Hammer (mhammer) wrote: > > Shouldn't the requirement be that the policy of a federation should=20 > > 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=20 > interconnection > > > include: > > > > > > o the mandatory support of RTP *and* RTCP as defined in=20 > > > [RFC3550], > > > > > > o the support of compatible codecs between=20 > communication peers,=20 > > > the > > > G.711 MUST be supported, the IETF iLBC [RFC3951]=20 > codec and its=20 > > > RTP > > > payload format [RFC3952] SHOULD be supported. > > > > > > o the support of the VoIP metric block as defined in=20 > RTP Control > > > Protocol Extended Reports [RFC3611] MAY be supported. > > > > > > What exactly does this mean to the two bodies that are making the=20 > > > peering arrangement. Is this a requirement to control the codecs=20 > > > used by the UAs attached to the peering organisations equipment=20 > > > before peering can occur, or a requirement to support=20 > transcoding if=20 > > > 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=20 > Internet-Drafts=20 > > > > directories. > > > > This draft is a work item of the Session PEERing for Multimedia=20 > > > > 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=20 > based on the > > > > SPEERMINT mailing list's discussions on=20 > requirements. The main > > > > objectives are to generate consensus on what categories of > > > > requirements should be covered, and to start more=20 > discussions=20 > > > > on the > > > > technical protocol requirements that apply to VoIP=20 > 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=20 > message to=20 > > > i-d-announce-request@ietf.org with the word unsubscribe=20 > in the body=20 > > > of the message. > > > You can also visit=20 > > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > > > > > > > > Internet-Drafts are also available by anonymous FTP.=20 > Login with the=20 > > > username "anonymous" and a password of your e-mail address. After=20 > > > 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=20 > the "FILE" > > > command. To decode the response(s), you will need=20 > "munpack" or > > > a MIME-compliant mail reader. Different=20 > MIME-compliant mail=20 > > > readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which=20 > have been split > > > up into multiple messages), so check your local=20 > documentation on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail reader=20 > > > implementation to automatically retrieve the ASCII version of the=20 > > > 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 > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jun 26 15:07:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwQx-00081N-5Z; Mon, 26 Jun 2006 15:07:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwQw-00081I-9m for speermint@ietf.org; Mon, 26 Jun 2006 15:07:42 -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 1FuwQv-0002uZ-Sc for speermint@ietf.org; Mon, 26 Jun 2006 15:07:42 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 8E3CF40ED; Mon, 26 Jun 2006 15:07:41 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 15:07: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] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Mon, 26 Jun 2006 15:07:39 -0400 Message-ID: In-Reply-To: <953beacc0606251141j2d6b9602mee34bd2e761431f@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Thread-Index: AcaYhxiSKdGr7BVWSqSdtIdHlzxNNwAx5zgw From: "Uzelac, Adam" To: "Rohan Mahy" , "Michael Hammer (mhammer)" X-OriginalArrivalTime: 26 Jun 2006 19:07:41.0392 (UTC) FILETIME=[CC33CD00:01C69953] X-Spam-Score: 0.1 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 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 don't see why a Federation is deemed exclusively a business arrangement. A Federation should be an optional parameter in the protocol set that facilitates SIP peering. IMO, the main driver is scale. Achieving scale without some hierarchical tools and therefore summation options makes for problematic reachability propagation. Thinking of DNS - Hierarchy in the domain names is NOT the reason for DNS scalability - the namespace is essentially flat in practice. Federations presents an another option to the direct P2P model. The attempt is not to ingrain an archaic business model that forces transitory providers into the P2P world. Federations can help with reachability awareness through a further segregation of the data-set. If every single endpoint is the data-set, and we aspire to have everyone be able to directly communicate with everyone else (think pure P2P), then WHOA, what a database I would have to connect-to in the sky -OR- WHOA, what a database of reachabiliy I would have resident on my local proxy! =20 Adam Uzelac -----Original Message----- From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 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=20 > 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,=20 > > 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=20 > > peering arrangement. Is this a requirement to control the codecs=20 > > used by the UAs attached to the peering organisations equipment=20 > > 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=20 > > > 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=20 > > > 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=20 > > of the message. > > You can also visit=20 > > 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=20 > > username "anonymous" and a password of your e-mail address. After=20 > > 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=20 > > 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=20 > > implementation to automatically retrieve the ASCII version of the=20 > > 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 From speermint-bounces@ietf.org Tue Jun 27 04:15:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv8j7-00080h-Ap; Tue, 27 Jun 2006 04:15:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv8j5-0007wQ-J1 for speermint@ietf.org; Tue, 27 Jun 2006 04:15:15 -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 1Fv7Hn-0000fv-FI for speermint@ietf.org; Tue, 27 Jun 2006 02:42:59 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fv71v-0007Hj-No for speermint@ietf.org; Tue, 27 Jun 2006 02:26:37 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id DE1741A372; Tue, 27 Jun 2006 08:26:25 +0200 (CEST) Date: Tue, 27 Jun 2006 08:26:25 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Update to draft-lendl-speermint-federations Message-ID: <20060627062625.GF19113@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <20060623150259.GE19113@nic.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623150259.GE19113@nic.at> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: -1.9 (-) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 2006/06/23 17:06, Otmar Lendl wrote: > > FYI, > > an updated version of draft-lendl-speermint-federations has been > submitted to the RFC editors. This version adds a lot of explanatory > text and examples. I am glad that Mike Hammer and Michael Haberler > joined in as co-authors. Michael will do a presentation in Montreal. > > The new version can be found at This draft is now online at the official repository: http://www.ietf.org/internet-drafts/draft-lendl-speermint-federations-01.txt A new version of the basic (SIP-independent) algorithm is available, too: http://www.ietf.org/internet-drafts/draft-lendl-domain-policy-ddds-01.txt /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 Jun 27 04:28:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv8vU-0000Ha-At; Tue, 27 Jun 2006 04:28:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv8vU-0000HV-0x for speermint@ietf.org; Tue, 27 Jun 2006 04:28:04 -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 1Fv8vS-0006bh-Pe for speermint@ietf.org; Tue, 27 Jun 2006 04:28:04 -0400 Received: from ([10.20.9.172]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.21837017; Tue, 27 Jun 2006 04:27:45 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 04:27:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jun 2006 04:25:29 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D9658208F@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 66th IETF Final Agenda Thread-Index: AcaZi4cQxZ+mqozaTuqRo6rQAGFRdQAN5Lqg From: "Livingood, Jason" To: X-OriginalArrivalTime: 27 Jun 2006 08:27:33.0235 (UTC) FILETIME=[8991E430:01C699C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Speermint] FW: 66th IETF Final Agenda 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 FYI=20 The final agenda for the 66th IETF meeting can be found at http://www.ietf.org/meetings/IETF-66.html Not all requests for changes were able to be made due to additional conflicts. The WG will have a firm agenda completed in a couple of days. Regards Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jun 27 11:24:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFQG-0004q2-AV; Tue, 27 Jun 2006 11:24:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFQF-0004ou-E6 for speermint@ietf.org; Tue, 27 Jun 2006 11:24:15 -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 1FvFQD-0006YB-0A for speermint@ietf.org; Tue, 27 Jun 2006 11:24:15 -0400 Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.21847647; Tue, 27 Jun 2006 11:23:53 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 11:23:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Tue, 27 Jun 2006 11:23:36 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D965820C8@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: AcaYhyEmYDInj/70SbyVCu6kApTh9wBdcTNg From: "Livingood, Jason" To: "Rohan Mahy" , "Michael Hammer \(mhammer\)" X-OriginalArrivalTime: 27 Jun 2006 15:23:52.0999 (UTC) FILETIME=[B2AB6370:01C699FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 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 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]=20 > Sent: Sunday, June 25, 2006 2:41 PM > To: Michael Hammer (mhammer) > Cc: speermint@ietf.org > Subject: Re: [Speermint] I-D=20 > ACTION:draft-ietf-speermint-requirements-00.t xt >=20 > Mike, >=20 > There is no requirement for a federation to exist in=20 > speermint. It might or it might not, but the IETF won't be=20 > very effective trying to put requirements on something which=20 > is effectively a business arrangement. We can define a set=20 > of protocols however, which needs to be useful in the big-I=20 > Internet and hopefully for folks building federations and=20 > other clubs as well. >=20 > Everyone, >=20 > I think codec selection should be out of scope. Mandating=20 > G.711 will have no positive effect now. Everyone supports it=20 > today in some way or another, but it could be detrimental in=20 > the future. The point of the SDP negotiation is to allow RTP=20 > *endpoints* to select the best codec in common under the=20 > circumstances. I don't think we can do any better than that=20 > in a requirements document, especially since we are=20 > describing an interface between SIP intermediaries that I=20 > hope will not even be a participant in the RTP media most of the time. >=20 > thanks, > -rohan >=20 >=20 >=20 > On 6/23/06, Michael Hammer (mhammer) wrote: > > Shouldn't the requirement be that the policy of a federation should=20 > > 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=20 > interconnection > > > include: > > > > > > o the mandatory support of RTP *and* RTCP as defined in=20 > > > [RFC3550], > > > > > > o the support of compatible codecs between=20 > communication peers,=20 > > > the > > > G.711 MUST be supported, the IETF iLBC [RFC3951]=20 > codec and its=20 > > > RTP > > > payload format [RFC3952] SHOULD be supported. > > > > > > o the support of the VoIP metric block as defined in=20 > RTP Control > > > Protocol Extended Reports [RFC3611] MAY be supported. > > > > > > What exactly does this mean to the two bodies that are making the=20 > > > peering arrangement. Is this a requirement to control the codecs=20 > > > used by the UAs attached to the peering organisations equipment=20 > > > before peering can occur, or a requirement to support=20 > transcoding if=20 > > > 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=20 > Internet-Drafts=20 > > > > directories. > > > > This draft is a work item of the Session PEERing for Multimedia=20 > > > > 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=20 > based on the > > > > SPEERMINT mailing list's discussions on=20 > requirements. The main > > > > objectives are to generate consensus on what categories of > > > > requirements should be covered, and to start more=20 > discussions=20 > > > > on the > > > > technical protocol requirements that apply to VoIP=20 > 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=20 > message to=20 > > > i-d-announce-request@ietf.org with the word unsubscribe=20 > in the body=20 > > > of the message. > > > You can also visit=20 > > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > > > > > > > > Internet-Drafts are also available by anonymous FTP.=20 > Login with the=20 > > > username "anonymous" and a password of your e-mail address. After=20 > > > 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=20 > the "FILE" > > > command. To decode the response(s), you will need=20 > "munpack" or > > > a MIME-compliant mail reader. Different=20 > MIME-compliant mail=20 > > > readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which=20 > have been split > > > up into multiple messages), so check your local=20 > documentation on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail reader=20 > > > implementation to automatically retrieve the ASCII version of the=20 > > > 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 > > >=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 Jun 27 12:29:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGR8-0002kP-6i; Tue, 27 Jun 2006 12:29:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGR6-0002kK-O1 for speermint@ietf.org; Tue, 27 Jun 2006 12:29:12 -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 1FvGR6-0005ZU-Ce for speermint@ietf.org; Tue, 27 Jun 2006 12:29:12 -0400 Received: from ([10.20.62.12]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.21852147; Tue, 27 Jun 2006 12:29:02 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 12:27:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Jun 2006 12:27:12 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D965820E1@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft WG Agenda for Montreal Thread-Index: AcaaBosL5Y3o8JctSjGtpepEbrD9iw== From: "Livingood, Jason" To: X-OriginalArrivalTime: 27 Jun 2006 16:27:20.0213 (UTC) FILETIME=[8FF22450:01C69A06] X-Spam-Score: 0.1 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Subject: [Speermint] Draft WG Agenda for Montreal 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="===============1981833839==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1981833839== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69A06.9013245C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69A06.9013245C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have a tentative agenda posted now. It is still subject to change / somewhat in flux. We'll post to the list as it is updated. =20 http://www3.ietf.org/proceedings/06jul/agenda/speermint.txt =20 Session PEERing for Multimedia INTerconnect (speermint) MONDAY, JULY 10, 2006, 1300 - 1500 (Afternoon Session I)=20 Room Name: 520DEF =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: David Meyer Jason Livingood SECRETARY: Alexander Mayrhofer AGENDA o Welcome & Introduction to speermint / Administrivia 5 minutes Jason Livingood - Mailing list: speermint-request@ietf.org subscribe - Scribe (jabber) =20 - Blue Sheets - Review of Milestones o Agenda Bashing 5 minutes Dave Meyer o Review and Status of Open Work Items =20 Primary / Official WG Drafts ----------------------------- 1 - SPEERMINT Terminology Draft 15 minutes draft-ietf-speermint-terminology-00 Dave Meyer 2 - Minimum Set of Requirements for SIP-Based VoIP Interconnection 20 minutes draft-ietf-speermint-requirements-00 Jean-Francois Mule New or Updated Individual Drafts ---------------------------------- 3 - SPEERMINT Routing Architecture Draft 15 minutes draft-khan-ip-serv-peer-arch-03 Sohel Khan 4 - Message Flows Associated with SPEERMINT Routing Architecture 15 minutes draft-penno-message-flows-02=20 Reinaldo Penno 5 - Session Peering Use Case for Cable 10 minutes draft-lee-speermint-use-case-cable-00 Yiu Lee 6 - A Minimalist Approach to Direct Peering 10 minutes draft-mahy-speermint-direct-peering-00=20 Rohan Mahy 7 - Real-Time Communications Provisioning Requirements 10 minutes draft-houri-speermint-rtc-provisioning-reqs-00 Avshalom Houri 8 - A Federation based VoIP Peering Architecture 10 minutes draft-lendl-speermint-federations-01 Michael Haberler o Open Discussion 5 minutes =20 ------_=_NextPart_001_01C69A06.9013245C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We = have a tentative=20 agenda posted now.  It is still subject to change / somewhat in = flux. =20 We'll post to the list as it is updated.
 
http= ://www3.ietf.org/proceedings/06jul/agenda/speermint.txt=
 
Session PEERing for =
Multimedia INTerconnect (speermint)

MONDAY, JULY 10, 2006, 1300 - 1500 (Afternoon Session I)=20
Room Name: 520DEF
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CHAIRS:	    David Meyer      	<dmm@1-4-5.net>
	    Jason Livingood  	<jason_livingood@cable.comcast.com>

SECRETARY:  Alexander Mayrhofer <alexander.mayrhofer@nic.at>

AGENDA

 o Welcome & Introduction to speermint / Administrivia	  		5 minutes
     Jason Livingood

   - Mailing list: speermint-request@ietf.org
     subscribe

   - Scribe (jabber)
  =20
   - Blue Sheets

   - Review of Milestones

 o Agenda Bashing                                         		5 minutes
     Dave Meyer

 o Review and Status of Open Work Items                     =20

   Primary / Official WG Drafts
   -----------------------------
    1 - SPEERMINT Terminology Draft					15 minutes
	draft-ietf-speermint-terminology-00
	  Dave Meyer

    2 - Minimum Set of Requirements for SIP-Based VoIP Interconnection	=
20 minutes
    	draft-ietf-speermint-requirements-00
	  Jean-Francois Mule

    New or Updated Individual Drafts
   ----------------------------------

    3 - SPEERMINT Routing Architecture Draft				15 minutes
	draft-khan-ip-serv-peer-arch-03
     	  Sohel Khan

    4 - Message Flows Associated with SPEERMINT Routing Architecture	15 =
minutes
    	draft-penno-message-flows-02=20
	  Reinaldo Penno

    5 - Session Peering Use Case for Cable				10 minutes
	draft-lee-speermint-use-case-cable-00
	  Yiu Lee

    6 - A Minimalist Approach to Direct Peering				10 minutes
	draft-mahy-speermint-direct-peering-00=20
	  Rohan Mahy

    7 - Real-Time Communications Provisioning Requirements		10 minutes
	draft-houri-speermint-rtc-provisioning-reqs-00
	  Avshalom Houri

    8 - A Federation based VoIP Peering Architecture			10 minutes
	draft-lendl-speermint-federations-01
	  Michael Haberler


 o Open Discussion                                       		5 minutes
  =20
------_=_NextPart_001_01C69A06.9013245C-- --===============1981833839== 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 --===============1981833839==-- From speermint-bounces@ietf.org Tue Jun 27 13:31:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHOt-00067C-SL; Tue, 27 Jun 2006 13:30:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHOs-000672-RC for speermint@ietf.org; Tue, 27 Jun 2006 13:30:58 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvHOs-0003kE-Db for speermint@ietf.org; Tue, 27 Jun 2006 13:30:58 -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 k5RHUs4M013217; Tue, 27 Jun 2006 12:30:55 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jun 2006 18:30:54 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0134D1EA7@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Livingood, Jason" , Rohan Mahy , "Michael Hammer (mhammer)" Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Tue, 27 Jun 2006 18:30:52 +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: 2b2ad76aced9b1d558e34a970a85c027 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 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 From speermint-bounces@ietf.org Tue Jun 27 13:41:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHZE-0006bV-6z; Tue, 27 Jun 2006 13:41:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHZD-0006b7-4h for speermint@ietf.org; Tue, 27 Jun 2006 13:41:39 -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 1FvHZD-0004Z1-1K for speermint@ietf.org; Tue, 27 Jun 2006 13:41:39 -0400 Received: from borg.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvHZ9-0001xC-VS for speermint@ietf.org; Tue, 27 Jun 2006 13:41:38 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 27 Jun 2006 10:41:33 -0700 X-IronPort-AV: i="4.06,183,1149490800"; d="scan'208"; a="563261915:sNHT40818180" 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: Tue, 27 Jun 2006 13:41:31 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804B9DF9B@proton.jnpr.net> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0134D1EA7@en0033exch001u.uk.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: AcaaD4nuhvunL42RQ9+SkFUVGSp/wAAAFopQ From: "Reinaldo Penno" To: "Drage, Keith \(Keith\)" , "Livingood, Jason" , "Rohan Mahy" , "Michael Hammer \(mhammer\)" X-Spam-Score: -0.7 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 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, When I posted my comments I also thought that this part was weird. Maybe Francois had something else in mind. I see codecs coming into play in a media relay/transcoding scenario.=20 But even then, a media relay (or a pair of them) would negotiate the necessary codecs as transparently as possible.=20 And in the case of SUBSCRIBE/NOTIFY policies and media relays, the preferred codecs would be known in advance if transcoding was needed.=20 But I'm open to hear scenarios where mandating a codec would be necessary. Regards, REinaldo > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Tuesday, June 27, 2006 10: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 >=20 > But this still does not answer my original question. >=20 > 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? >=20 > regards >=20 > Keith >=20 > > -----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 > > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jun 27 15:02:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvIpV-0006FV-Fj; Tue, 27 Jun 2006 15:02:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvIpU-0006FQ-6y for speermint@ietf.org; Tue, 27 Jun 2006 15:02:32 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvIpT-0004k1-NA for speermint@ietf.org; Tue, 27 Jun 2006 15:02:32 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 27 Jun 2006 15:02:32 -0400 X-IronPort-AV: i="4.06,183,1149480000"; d="scan'208"; a="91130287:sNHT36208680" 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 k5RJ2VYL023614; Tue, 27 Jun 2006 15:02:31 -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, 27 Jun 2006 15:02:31 -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: Tue, 27 Jun 2006 15:02:30 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301A5A1D0@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: AcaYhyEmYDInj/70SbyVCu6kApTh9wBdcTNgAAe8REA= From: "Michael Hammer \(mhammer\)" To: "Livingood, Jason" , "Rohan Mahy" X-OriginalArrivalTime: 27 Jun 2006 19:02:31.0439 (UTC) FILETIME=[3DDE79F0:01C69A1C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 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 IFF you are not interested in global rechability of users, then yes small pockets of users can connect without federations, or whatever name you want to give it. However, if you want global scalability, something other than a full mesh is needed, and that implies some degree of hierarchy. Call that grouping mechanism what you want, it is needed. If the value of the PSTN is 4 billion squared, I would prefer the SIP NGN network of the future to be at least as valuable. Mike > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Tuesday, June 27, 2006 11:24 AM > To: Rohan Mahy; Michael Hammer (mhammer) > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D=20 > ACTION:draft-ietf-speermint-requirements-00.t xt >=20 > My initial thought is that you are accurate saying that=20 > federations are NOT REQUIRED for speermint. Federations MAY=20 > or MAY NOT be used, as you noted, and to that extent will be=20 > considered in some fashion here. >=20 > 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=20 > *well* handled in the underlying SIP protocol itself. =20 > However, we may well find a need to specify (or not) a lowest=20 > common denominator codec but we'll have to see how our=20 > requirements work progress. >=20 > Jason >=20 > > -----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 > >=20 > > Mike, > >=20 > > There is no requirement for a federation to exist in speermint. It=20 > > might or it might not, but the IETF won't be very effective=20 > trying to=20 > > put requirements on something which is effectively a business=20 > > arrangement. We can define a set of protocols however,=20 > which needs to=20 > > be useful in the big-I Internet and hopefully for folks building=20 > > federations and other clubs as well. > >=20 > > Everyone, > >=20 > > I think codec selection should be out of scope. Mandating > > G.711 will have no positive effect now. Everyone supports=20 > it today in=20 > > some way or another, but it could be detrimental in the=20 > future. The=20 > > 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 that in a=20 > > requirements document, especially since we are describing=20 > an interface=20 > > between SIP intermediaries that I hope will not even be a=20 > participant=20 > > in the RTP media most of the time. > >=20 > > thanks, > > -rohan > >=20 > >=20 > >=20 > > On 6/23/06, Michael Hammer (mhammer) wrote: > > > Shouldn't the requirement be that the policy of a=20 > federation should=20 > > > 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=20 > making the=20 > > > > peering arrangement. Is this a requirement to control=20 > the codecs=20 > > > > used by the UAs attached to the peering organisations equipment=20 > > > > before peering can occur, or a requirement to support > > transcoding if > > > > these requirements are not met by the population of=20 > 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=20 > [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=20 > Multimedia=20 > > > > > 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.=20 > > Login with the > > > > username "anonymous" and a password of your e-mail=20 > address. After=20 > > > > 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. =20 > 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=20 > mail reader=20 > > > > implementation to automatically retrieve the ASCII=20 > version of the=20 > > > > 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 > > > > >=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 Jun 27 15:11:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvIxm-0002k9-7H; Tue, 27 Jun 2006 15:11:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvIxl-0002fs-6h for speermint@ietf.org; Tue, 27 Jun 2006 15:11:05 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvIxj-00050S-Pl for speermint@ietf.org; Tue, 27 Jun 2006 15:11:05 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5RJB106004273; Tue, 27 Jun 2006 13:11:01 -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] use of RFC 3263 for locating peer's SIP server Date: Tue, 27 Jun 2006 13:11:01 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] use of RFC 3263 for locating peer's SIP server Thread-Index: AcaT5BNtFbBN5Z7bTHqlWP77qxDsXgGNsJBA From: "Jean-Francois Mule" To: "Rohan Mahy" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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, Thank you for your input.=20 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 >=20 > Hi Jean-Francois, >=20 > 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. >=20 > thanks, > -rohan >=20 > 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? > > =3D=3D> 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? > > =3D=3D=3D> 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 From speermint-bounces@ietf.org Tue Jun 27 16:05:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJoQ-0008SV-Ka; Tue, 27 Jun 2006 16:05:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJoL-0008Pi-M0 for speermint@ietf.org; Tue, 27 Jun 2006 16:05:26 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJoK-0004qv-8D for speermint@ietf.org; Tue, 27 Jun 2006 16:05:25 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5RK5NZN016205; Tue, 27 Jun 2006 14:05:23 -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: Comments (RE: [speermint] requirements draft submitted) Date: Tue, 27 Jun 2006 14:05:23 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments (RE: [speermint] requirements draft submitted) Thread-Index: AcaVe5BSv6x0w0C1TiKNz/WT3DVSKgAeqhrgAAu/ePAA/kaN0A== From: "Jean-Francois Mule" To: "Reinaldo Penno" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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 Reinaldo, You wrote: > Comments on your draft >=20 > "2.3. No blocked calls" >=20 > I think the title of this subsection should be changed to something > else > since blocked calls (just like normal IP packets) can always happen > due > to call limits, QoS, white/black lists, etc, etc I agree. How about URI reachability based on the current txt? > I think there is a distinction on what can be achieved in terms of > static vs. dynamic data available. The data is DNS is static and does > not reflect that state of the network. Not necessarily true.=20 While global DNS may have some lag, it is dynamic. It is part of common DNS operations to actually reduce TTL in some DNS records just before doing maintenance work on target servers to limit reachability issues due to DNS caching, then do the maintenance and crank the TTLs back up once the network is "more stable". > Actually since DNS is an out of > band mechanism, it does not even guarantee that your layer 3 peering > connections are up. >=20 > "Per-service provider opt-in > without consultation of a centralized 'peering registry', but > rather > by publishing local configuration choices only is highly > desirable." > Not sure I understand the connection between the first and second > phrases.=20 Me neither. > Did you mean "Instead of a per-service...., providers should > publish"? >=20 > Or is the first option acceptable? Personally I think that tackling > the > (N^2) problem is very important but there will certainly be > deployments > where providers prefer a centralized registry (intra federation calls > could be an example). This sentence in 2.4 is taken from the original draft and should be clarified. I understood it as follows: Publishing local configuration choices is highly desirable and preferable over per-service provider opt-in without consultation of a centralized 'peering registry'. But even then, it is not clear to me what is meant... more work & refinements are needed here. > "2.5. Independence of lower layers >=20 > The system needs to be independent of details on what technologies > are used route" >=20 > Which "system" do you refer here? I think independence is very > important > but not sure it is totally achievable. I guess it depends how it is > worded. For example, see my comments to the no blocked calls above. Agreed.=20 Proposed new text:=20 s/system/session peering=20 at least for now and until we have a function name from the archictecture doc? Session peering SHOULD be independent of lower layers and the technologies used to route the call... =20 > "2.7. Minimal additional cost on call initiation >=20 > Since each call setup implies execution of any proposed algorithm, > it > should incur minimal overhead and delay, and employ caching > wherever > possible to avoid extra protocol round trips." >=20 > We should mention that caching brings with it security problems. I can > foresee similar attacks like "SIP/URI" cache poisoning, etc -> security consideration section: add txt on the implications of caching? > "3.3. Media-related requirements" >=20 > It seems to me media related requirements as you stated come into play > _if_ somebody is using a media relay. Otherwise the decision is > between > the endpoints and we do not care/it is out of scope right? It seems to me that VoIP interconnect is ultimately about exchanging rtp packets (be it audio payloads or comfort noise). >=20 > For example, >=20 >=20 > " o the support of the VoIP metric block as defined in RTP Control > Protocol Extended Reports [RFC3611] MAY be supported." >=20 > Between which entities? I'm assuming you mean between media relays > since > if it is between the endpoints we really do not care/it is out of > scope, > right? This goes back to a problem in the current draft: requirements apply to several types of entities. =20 =20 > I think media requirements strictly related to speermint could be QoS > across the fabric and discussed in the list and stated in the message > flows draft and maybe some requirements in terms of control vs data > routing. >=20 > "3.4. Security requirements >=20 > All SIP messages MUST be sent over TLS [RFC3546] to provide > transport-layer security as defined in RFC 3261," >=20 > Giving the fact that we can have security through physical segregation, > intra-federation/provider calls, etc, the "MUST" here seems too > generic. I tend to differ on this: it is not because you have lower layer security (presumably hop by hop security associations) that you should relax the end-to-end transport security requirements.=20 Rohan's well written draft is also in favor of mandatory support of TLS, and so is the SIP Forum's IP PBX to VSP (here is a working link: http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_Inte rop-sibley-final.pdf). May be the requirement should be rewritten to put the MUST on SIP entities involved in L5 peering.=20 How do others feel on this? Thanks for your comments. Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jun 27 16:16:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJz9-0004GU-5E; Tue, 27 Jun 2006 16:16:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJz8-0004GD-E4 for speermint@ietf.org; Tue, 27 Jun 2006 16:16:34 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJz7-0005cJ-4c for speermint@ietf.org; Tue, 27 Jun 2006 16:16:34 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5RKGVYB018732; Tue, 27 Jun 2006 14:16:32 -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: Tue, 27 Jun 2006 14:16:31 -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: AcaW0G8O++QUBRdVR2ufhkaXbZArHADVagIw From: "Jean-Francois Mule" To: "Drage, Keith (Keith)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 wrote: > Section 3.5 indicates: >=20 > The minimum requirements to allow a successful VoIP interconnection > include: >=20 > o the mandatory support of RTP *and* RTCP as defined in [RFC3550], >=20 > 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. >=20 > o the support of the VoIP metric block as defined in RTP Control > Protocol Extended Reports [RFC3611] MAY be supported. >=20 > 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. Up for debate, but the later is more inline with a generic requirement draft.=20 > 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). Ok - will update the reference. Thank you, Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jun 27 16:24:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvK6g-00064l-Jy; Tue, 27 Jun 2006 16:24:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvK6f-000648-KT for speermint@ietf.org; Tue, 27 Jun 2006 16:24:21 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvK6e-0005y8-9s for speermint@ietf.org; Tue, 27 Jun 2006 16:24:21 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5RKOHWP020230; Tue, 27 Jun 2006 14:24:17 -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: Tue, 27 Jun 2006 14:24:17 -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: AcaYhxg8860WfgciSPW75MPhqRH6SABn9y9g From: "Jean-Francois Mule" To: "Rohan Mahy" , "Michael Hammer (mhammer)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 wrote: > 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. This ID is for a set of *minimum* requirements for VoIP interconnect. I have never walked in a meeting related to VoIP interop between 2 systems or operators without having cleared the voice codec part (or assumed G.711 is there). I also note that it is in scope of the SIP Forum's use case for IP-PBX to VSP VoIP interconnect. Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jun 27 16:30:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKCA-00005r-Bk; Tue, 27 Jun 2006 16:30:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKC9-0008W7-Im for speermint@ietf.org; Tue, 27 Jun 2006 16:30:01 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvKC9-0006Jq-0q for speermint@ietf.org; Tue, 27 Jun 2006 16:30:01 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5RKTvXW022109; Tue, 27 Jun 2006 14:29:57 -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: Tue, 27 Jun 2006 14:29:57 -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: AcaaD3+sv2ttrBgfQF6JYN+PD0v+sgAGHPAw From: "Jean-Francois Mule" To: "Drage, Keith (Keith)" , "Livingood, Jason" , "Rohan Mahy" , "Michael Hammer (mhammer)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e 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 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 >=20 > But this still does not answer my original question. >=20 > 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? >=20 > regards >=20 > Keith >=20 > > -----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 > > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jun 27 17:12:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKrA-0006IF-OT; Tue, 27 Jun 2006 17:12:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKr9-0006BZ-B7 for speermint@ietf.org; Tue, 27 Jun 2006 17:12:23 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvKr8-0004Zi-3m for speermint@ietf.org; Tue, 27 Jun 2006 17:12:23 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FvKqx-0002xQ-Hw; Tue, 27 Jun 2006 16:12:12 -0500 From: "Brian Rosen" To: "'Jean-Francois Mule'" , "'Reinaldo Penno'" Subject: RE: Comments (RE: [speermint] requirements draft submitted) Date: Tue, 27 Jun 2006 17:12:04 -0400 Message-ID: <137101c69a2e$593de700$b801a8c0@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: Thread-Index: AcaVe5BSv6x0w0C1TiKNz/WT3DVSKgAeqhrgAAu/ePAA/kaN0AADh0MA 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: 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 > > "3.4. Security requirements > > All SIP messages MUST be sent over TLS [RFC3546] to provide > transport-layer security as defined in RFC 3261," > > Giving the fact that we can have security through physical segregation, > intra-federation/provider calls, etc, the "MUST" here seems too > generic. I tend to differ on this: it is not because you have lower layer security (presumably hop by hop security associations) that you should relax the end-to-end transport security requirements. Rohan's well written draft is also in favor of mandatory support of TLS, and so is the SIP Forum's IP PBX to VSP (here is a working link: http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_Inte rop-sibley-final.pdf). May be the requirement should be rewritten to put the MUST on SIP entities involved in L5 peering. I'm in favor of requiring TLS. I'd say MUST in a heartbeat. Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jun 27 17:18:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKwy-0001bv-Fj; Tue, 27 Jun 2006 17:18:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKww-0001UP-VF for speermint@ietf.org; Tue, 27 Jun 2006 17:18:23 -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 1FvJwD-0005QL-FA for speermint@ietf.org; Tue, 27 Jun 2006 16:13:33 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvJwC-0005W4-51 for speermint@ietf.org; Tue, 27 Jun 2006 16:13:33 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5RKCgOv017599; Tue, 27 Jun 2006 14:12:43 -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: Comments (RE: [speermint] requirements draft submitted) Date: Tue, 27 Jun 2006 14:12:42 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments (RE: [speermint] requirements draft submitted) Thread-Index: AcaWzNkC0EkDJGhgQi+PNJ7qBdLhjgDWFfcw From: "Jean-Francois Mule" To: "Otmar Lendl" , "Reinaldo Penno" X-Approved: ondar X-Spam-Score: -1.9 (-) 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 Just to set the record straight on this I-D: > > Comments on your draft This I-D is a wg draft so it is your draft too. I consider my role as an editor on this one. Regarding section 2.4 requirements, Omar wrote: > What about: >=20 > "A VSP opt-in by publishing local configuration choices is preferrable > to a centralized 'peering registry'." That is better, I could go with that. > > "2.7. Minimal additional cost on call initiation > > > > Since each call setup implies execution of any proposed algorithm, > it > > should incur minimal overhead and delay, and employ caching > wherever > > possible to avoid extra protocol round trips." > > > > We should mention that caching brings with it security problems. I > can > > foresee similar attacks like "SIP/URI" cache poisoning, etc >=20 > What about some generic security requirement? (independently of > caching) Concrete proposal welcome for discussion as usual. > > "3.4. Security requirements > > > > All SIP messages MUST be sent over TLS [RFC3546] to provide > > transport-layer security as defined in RFC 3261," > > > > Giving the fact that we can have security through physical > segregation, > > intra-federation/provider calls, etc, the "MUST" here seems too > generic. > > > > I think we should say something like "in the case of public on- > demand > > peering SIP messages...." > > >=20 > Agreed. Noted. Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jun 27 17:40:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvLIL-00013h-VI; Tue, 27 Jun 2006 17:40:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvLIK-00011M-QY for speermint@ietf.org; Tue, 27 Jun 2006 17:40:28 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvLIK-0007ZY-8Z for speermint@ietf.org; Tue, 27 Jun 2006 17:40:28 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FvLI6-0004Yl-Si; Tue, 27 Jun 2006 16:40:15 -0500 From: "Brian Rosen" To: "'Jean-Francois Mule'" , "'Drage, Keith \(Keith\)'" , "'Livingood, Jason'" , "'Rohan Mahy'" , "'Michael Hammer \(mhammer\)'" Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Tue, 27 Jun 2006 17:40:07 -0400 Message-ID: <13b401c69a32$44ae3e30$b801a8c0@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: Thread-Index: AcaaD3+sv2ttrBgfQF6JYN+PD0v+sgAGHPAwAAKCnlA= 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: 918f4bd8440e8de4700bcf6d658bc801 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 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? 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 From speermint-bounces@ietf.org Tue Jun 27 20:27:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvNtZ-000734-Iw; Tue, 27 Jun 2006 20:27:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvNtX-00072z-MK for speermint@ietf.org; Tue, 27 Jun 2006 20:27:03 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvNtW-0001pg-DB for speermint@ietf.org; Tue, 27 Jun 2006 20:27:03 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 27 Jun 2006 17:27:01 -0700 X-IronPort-AV: i="4.06,184,1149490800"; d="scan'208"; a="558374052:sNHT29605270" 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: TLS for peering (was RE: Comments (RE: [speermint] requirements draft submitted)) Date: Tue, 27 Jun 2006 20:27:00 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804B9E046@proton.jnpr.net> In-Reply-To: <137101c69a2e$593de700$b801a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments (RE: [speermint] requirements draft submitted)) Thread-Index: AcaVe5BSv6x0w0C1TiKNz/WT3DVSKgAeqhrgAAu/ePAA/kaN0AADh0MAAAcTiaA= From: "Reinaldo Penno" To: "Brian Rosen" , "Jean-Francois Mule" 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 =20 TLS for _all_ scenarios? Even in private peerings, physically secure peerings, etc?=20 Isn't that the same as requiring IPsec for all layer 3 peering? But since Layer 5 peering might be more distributed, the number of TLS sessions would be huge. It would be good to hear the provider's opinion on this... Thanks, Reinaldo > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, June 27, 2006 2:12 PM > To: 'Jean-Francois Mule'; Reinaldo Penno > Cc: speermint@ietf.org > Subject: RE: Comments (RE: [speermint] requirements draft submitted) >=20 > > > > "3.4. Security requirements > > > > All SIP messages MUST be sent over TLS [RFC3546] to provide > > transport-layer security as defined in RFC 3261," > > > > Giving the fact that we can have security through physical > segregation, > > intra-federation/provider calls, etc, the "MUST" here seems too > > generic. >=20 > I tend to differ on this: it is not because you have lower layer > security (presumably hop by hop security associations) that you should > relax the end-to-end transport security requirements. > Rohan's well written draft is also in favor of mandatory support of TLS, > and so is the SIP Forum's IP PBX to VSP (here is a working link: > http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_Inte > rop-sibley-final.pdf). > May be the requirement should be rewritten to put the MUST on SIP > entities involved in L5 peering. >=20 > I'm in favor of requiring TLS. I'd say MUST in a heartbeat. >=20 > Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jun 27 20:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvOAS-0001mv-JL; Tue, 27 Jun 2006 20:44:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvOAR-0001mi-C7 for speermint@ietf.org; Tue, 27 Jun 2006 20:44:31 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvOAP-0003JA-Vz for speermint@ietf.org; Tue, 27 Jun 2006 20:44:31 -0400 Received: by ug-out-1314.google.com with SMTP id m3so66981uge for ; Tue, 27 Jun 2006 17:44:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=MDgJcMo3iGNGeC0rIDLHz2UnRRMtjJ6eHkGQE08Jp9RhEpwc+H8aOU7xeX9N98oLyQ0ybg+9595FczctbpngzYzxuteI9ezub3bJ0O4lp22OX+q2STpnztdbR1BT8LHJZID1XGrN6No0164BpzPlrPAv7fUGKY35jboj0nqQT1c= Received: by 10.78.167.12 with SMTP id p12mr33151hue; Tue, 27 Jun 2006 17:44:29 -0700 (PDT) Received: by 10.78.100.4 with HTTP; Tue, 27 Jun 2006 17:44:28 -0700 (PDT) Message-ID: <894e079b0606271744r1310c6c5k1e17a86c41c02b26@mail.gmail.com> Date: Tue, 27 Jun 2006 20:44:28 -0400 From: "Medhavi Bhatia" To: "Reinaldo Penno" Subject: Re: TLS for peering (was RE: Comments (RE: [speermint] requirements draft submitted)) In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804B9E046@proton.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <137101c69a2e$593de700$b801a8c0@cis.neustar.com> <9BD5D7887235424FA97DFC223CAE3C2804B9E046@proton.jnpr.net> X-Google-Sender-Auth: 60279c3926cc0804 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I am not a provider yet, but I think we dont need to mess with TLS/TCP. As I understand one of the goals is to prevent the calls from failing due to "peering only" reasons. This means that things like codecs which are not negotiated by the peers need to be mandated at a minimal level. TCP/TLS can be negotiated between the peers themselves so it is a non-issue. Also as I still understand doing a high volume calls with TLS is still expensive. Mandating TLS in cases where the caller or callee dont require it doesnt seem to add any value. -Medhavi. On 6/27/06, Reinaldo Penno wrote: > > TLS for _all_ scenarios? Even in private peerings, physically secure > peerings, etc? > > Isn't that the same as requiring IPsec for all layer 3 peering? But > since Layer 5 peering might be more distributed, the number of TLS > sessions would be huge. > > It would be good to hear the provider's opinion on this... > > Thanks, > > Reinaldo > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, June 27, 2006 2:12 PM > > To: 'Jean-Francois Mule'; Reinaldo Penno > > Cc: speermint@ietf.org > > Subject: RE: Comments (RE: [speermint] requirements draft submitted) > > > > > > > > "3.4. Security requirements > > > > > > All SIP messages MUST be sent over TLS [RFC3546] to provide > > > transport-layer security as defined in RFC 3261," > > > > > > Giving the fact that we can have security through physical > > segregation, > > > intra-federation/provider calls, etc, the "MUST" here seems too > > > generic. > > > > I tend to differ on this: it is not because you have lower layer > > security (presumably hop by hop security associations) that you should > > relax the end-to-end transport security requirements. > > Rohan's well written draft is also in favor of mandatory support of > TLS, > > and so is the SIP Forum's IP PBX to VSP (here is a working link: > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_Inte > > rop-sibley-final.pdf). > > May be the requirement should be rewritten to put the MUST on SIP > > entities involved in L5 peering. > > > > I'm in favor of requiring TLS. I'd say MUST in a heartbeat. > > > > Brian > > _______________________________________________ > 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 Jun 27 21:47:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvP9c-0001pu-EE; Tue, 27 Jun 2006 21:47:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvP9a-0001pm-Rk for speermint@ietf.org; Tue, 27 Jun 2006 21:47:42 -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 1FvP9Z-0001yO-GQ for speermint@ietf.org; Tue, 27 Jun 2006 21:47:42 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 219CC3873; Tue, 27 Jun 2006 21:47:41 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 21:47:40 -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, 27 Jun 2006 21:47:37 -0400 Message-ID: In-Reply-To: <894e079b0606271744r1310c6c5k1e17a86c41c02b26@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments (RE: [speermint] requirementsdraft submitted)) Thread-Index: AcaaTAvQibrYHlUOTIKmrbaCpV6BkgABbC1g From: "Uzelac, Adam" To: "Medhavi Bhatia" , "Reinaldo Penno" X-OriginalArrivalTime: 28 Jun 2006 01:47:40.0935 (UTC) FILETIME=[D7753170:01C69A54] X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 TLS is becoming more and more a subject when the topic of SIP interconnections arises for me professionally. This shows growing momentum indeed. With that said, I can not agree with TLS as a steadfast requirement. Economics and scale are my major concerns. TLS adds cost, server load, and there are fail-over issues to consider as well. For the person that designs an interconnect, I believe weighing the cost against the benefit of the different models a useful exercise. Mandating TLS, even if all parties involved in a peering arrangement feel somehow "safe and secure" due to underlying security mechanisms (L2/L3VPNs, etc), seems a little harsh. =20 Adam -----Original Message----- From: Medhavi Bhatia [mailto:mbhatia@3clogic.com]=20 Sent: Tuesday, June 27, 2006 8:44 PM To: Reinaldo Penno Cc: speermint@ietf.org Subject: Re: TLS for peering (was RE: Comments (RE: [speermint] requirementsdraft submitted)) I am not a provider yet, but I think we dont need to mess with TLS/TCP. As I understand one of the goals is to prevent the calls from failing due to "peering only" reasons. This means that things like codecs which are not negotiated by the peers need to be mandated at a minimal level. TCP/TLS can be negotiated between the peers themselves so it is a non-issue. Also as I still understand doing a high volume calls with TLS is still expensive. Mandating TLS in cases where the caller or callee dont require it doesnt seem to add any value. -Medhavi. On 6/27/06, Reinaldo Penno wrote: > > TLS for _all_ scenarios? Even in private peerings, physically secure=20 > peerings, etc? > > Isn't that the same as requiring IPsec for all layer 3 peering? But=20 > since Layer 5 peering might be more distributed, the number of TLS=20 > sessions would be huge. > > It would be good to hear the provider's opinion on this... > > Thanks, > > Reinaldo > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, June 27, 2006 2:12 PM > > To: 'Jean-Francois Mule'; Reinaldo Penno > > Cc: speermint@ietf.org > > Subject: RE: Comments (RE: [speermint] requirements draft submitted) > > > > > > > > "3.4. Security requirements > > > > > > All SIP messages MUST be sent over TLS [RFC3546] to provide > > > transport-layer security as defined in RFC 3261," > > > > > > Giving the fact that we can have security through physical > > segregation, > > > intra-federation/provider calls, etc, the "MUST" here seems too=20 > > > generic. > > > > I tend to differ on this: it is not because you have lower layer=20 > > security (presumably hop by hop security associations) that you=20 > > should relax the end-to-end transport security requirements. > > Rohan's well written draft is also in favor of mandatory support of > TLS, > > and so is the SIP Forum's IP PBX to VSP (here is a working link: > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_In > te > > rop-sibley-final.pdf). > > May be the requirement should be rewritten to put the MUST on SIP=20 > > entities involved in L5 peering. > > > > I'm in favor of requiring TLS. I'd say MUST in a heartbeat. > > > > Brian > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jun 28 06:46:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvXYs-0001Sp-Kp; Wed, 28 Jun 2006 06:46:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvXYr-0001Sf-0b for speermint@ietf.org; Wed, 28 Jun 2006 06:46:21 -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 1FvXYq-0001p8-H7 for speermint@ietf.org; Wed, 28 Jun 2006 06:46:20 -0400 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.21879257; Wed, 28 Jun 2006 06:46:00 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 06:45: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Wed, 28 Jun 2006 06:46:00 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D965820E9@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: AcaaD3+sv2ttrBgfQF6JYN+PD0v+sgAGHPAwAAKCnlAAFsqdUA== From: "Livingood, Jason" To: "Brian Rosen" , "Jean-Francois Mule" , "Drage, Keith \(Keith\)" , "Rohan Mahy" , "Michael Hammer \(mhammer\)" X-OriginalArrivalTime: 28 Jun 2006 10:45:59.0752 (UTC) FILETIME=[0B0D8C80:01C69AA0] X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 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 Let's drop the IM and video examples -- for now. Let's first focus on getting the basic one working that we're committed to: voice. =20 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? If not, is there much utility in peering if certain provider types cannot agree on a common codec? Jason > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, June 27, 2006 5:40 PM > To: 'Jean-Francois Mule'; 'Drage, Keith (Keith)'; Livingood,=20 > Jason; 'Rohan Mahy'; 'Michael Hammer (mhammer)' > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D=20 > ACTION:draft-ietf-speermint-requirements-00.t xt >=20 > Consider an all-IMS, all-GSM federation. Do they have to have G.711? >=20 > Consider an all-video conference federation. Do they have to=20 > have G.711? >=20 > Consider an all-IM federation. Do they have to have G.711? >=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; 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 support G.711 on the terminal, and, > - on the other, a VSP like free world dialup or alike=20 > that allow any 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 > >=20 > > But this still does not answer my original question. > >=20 > > How can you mandate a codec for what is essentially a=20 > network operator=20 > > when that operator does not own the terminals (which=20 > contain the vast=20 > > majority of the codecs). Are you making a requirement for=20 > transcoding=20 > > support in the absence of whatever codec set is defined, or=20 > is it just=20 > > an empty letter? > >=20 > > regards > >=20 > > Keith > >=20 > > > -----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. =20 > > > > It might or it might not, but the IETF won't be very effective=20 > > > > trying to put requirements on something which is effectively a=20 > > > > business arrangement. We can define a set of protocols=20 > however,=20 > > > > which needs to be useful in the big-I Internet and=20 > hopefully for=20 > > > > 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=20 > > > > today in some way or another, but it could be=20 > detrimental in the=20 > > > > future. 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=20 > > > > 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=20 > 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=20 > 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=20 > for Session=20 > > > > > > > PEERing for > > > > > > > Multimedia INTerconnect and defines the minimum set of > > > > > > requirements > > > > > > > applicable to SIP session peering for VoIP=20 > 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=20 > 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 > > > > >=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 Wed Jun 28 07:01:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvXna-000728-N1; Wed, 28 Jun 2006 07:01:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvXnZ-0006zA-3L for speermint@ietf.org; Wed, 28 Jun 2006 07:01:33 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FvXnX-0003fY-Ox for speermint@ietf.org; Wed, 28 Jun 2006 07:01:33 -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: Wed, 28 Jun 2006 13:05:38 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C504B@oefeg-s04.oefeg.loc> In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D965820E9@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: AcaaD3+sv2ttrBgfQF6JYN+PD0v+sgAGHPAwAAKCnlAAFsqdUAAE+sig From: "Stastny Richard" To: "Livingood, Jason" 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 Jason wrote: >=20 > 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? > If not, is there much utility in peering if certain provider types > cannot agree on a common codec? >=20 The codecs are a terminal or end-user device issue. Peering between service=20 providers have no influence on these. So if there is no match in available=20 codecs, the only way out is to insert a transcoding function on one or on both sides. Since I am not so in protocol details, so I have a question: is there a call flow available to do so? And if, the codec selected is part of the peering agreement itself. Which=20 codec is up to the parties. Richard >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jun 28 09:28:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fva5Q-0004of-PZ; Wed, 28 Jun 2006 09:28:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fva5P-0004oa-UT for speermint@ietf.org; Wed, 28 Jun 2006 09:28:07 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fva5O-0007iM-Nd for speermint@ietf.org; Wed, 28 Jun 2006 09:28:07 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Wed, 28 Jun 2006 09:27:53 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006062809275101944 ; Wed, 28 Jun 2006 09:27:52 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jun 2006 09:27:51 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230E2D@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Stastny Richard Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Wed, 28 Jun 2006 09:27:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Folks: The bottom line of the support of codec is this: Support of QOS for the VoIP application. For example, one can do transcoding, but will they meet QOS requirements? It is not simply the bandwidth. It is also about end-to-end delay, jitter, and packet loss at the VoIP presentation layer (beyond IP network layer). Best regards, Radhika R. Roy -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Stastny Richard Sent: Wednesday, June 28, 2006 7:06 AM To: Livingood, Jason Cc: speermint@ietf.org Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt 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? > If not, is there much utility in peering if certain provider types > cannot agree on a common codec? > The codecs are a terminal or end-user device issue. Peering between service providers have no influence on these. So if there is no match in available codecs, the only way out is to insert a transcoding function on one or on both sides. Since I am not so in protocol details, so I have a question: is there a call flow available to do so? And if, the codec selected is part of the peering agreement itself. Which codec is up to the parties. Richard > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jun 28 09:47:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvaOD-0001j3-F4; Wed, 28 Jun 2006 09:47:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvaOB-0001fC-1l for speermint@ietf.org; Wed, 28 Jun 2006 09:47:31 -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 1FvaO9-0000lH-MG for speermint@ietf.org; Wed, 28 Jun 2006 09:47:31 -0400 Received: from outbound1-res.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-res-R.bigfish.com (Postfix) with ESMTP id EBD1275242D; Wed, 28 Jun 2006 13:47:27 +0000 (UTC) Received: from mail50-res-R.bigfish.com (unknown [172.18.16.1]) by outbound1-res.bigfish.com (Postfix) with ESMTP id E2E9F752064; Wed, 28 Jun 2006 13:47:27 +0000 (UTC) Received: from mail50-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail50-res-R.bigfish.com (Postfix) with ESMTP id D7385771838; Wed, 28 Jun 2006 13:47:27 +0000 (UTC) X-BigFish: V Received: by mail50-res (MessageSwitch) id 1151502447817850_28448; Wed, 28 Jun 2006 13:47:27 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail50-res.bigfish.com (Postfix) with ESMTP id A90FB771997; Wed, 28 Jun 2006 13:47:27 +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 k5SDlLAg017153; Wed, 28 Jun 2006 08:47:21 -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 k5SDlLf16656; Wed, 28 Jun 2006 08:47:21 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg02a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 08:47:21 -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: Wed, 28 Jun 2006 08:47:19 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A13E99314@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: AcaaD3+sv2ttrBgfQF6JYN+PD0v+sgAGHPAwAAKCnlAAFsqdUAAE+sigAAX8OCA= From: "Khan, Sohel Q [CTO]" To: "Stastny Richard" , "Livingood, Jason" X-OriginalArrivalTime: 28 Jun 2006 13:47:21.0411 (UTC) FILETIME=[6106F130:01C69AB9] 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 Codec can be implemented in the peering interface. It can be internal to a provider network. =20 -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Wednesday, June 28, 2006 6:06 AM To: Livingood, Jason Cc: speermint@ietf.org Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Jason wrote: >=20 > So in the case of voice, the question at hand is - is there a lowest=20 > common denominator voice codec which should be required to do peering? > If not, is there much utility in peering if certain provider types=20 > cannot agree on a common codec? >=20 The codecs are a terminal or end-user device issue. Peering between service providers have no influence on these. So if there is no match in available codecs, the only way out is to insert a transcoding function on one or on both sides. Since I am not so in protocol details, so I have a question: is there a call flow available to do so? And if, the codec selected is part of the peering agreement itself. Which codec is up to the parties. Richard >=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 Jun 28 10:10:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvakl-00053D-ED; Wed, 28 Jun 2006 10:10:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvakk-0004uT-7O for speermint@ietf.org; Wed, 28 Jun 2006 10:10:50 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FvagY-00039x-64 for speermint@ietf.org; Wed, 28 Jun 2006 10:06:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Wed, 28 Jun 2006 16:10:37 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C504C@oefeg-s04.oefeg.loc> In-Reply-To: <858217C310A3D94182FA8AAE42860A13E99314@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: AcaaD3+sv2ttrBgfQF6JYN+PD0v+sgAGHPAwAAKCnlAAFsqdUAAE+sigAAX8OCAAAOE4QA== From: "Stastny Richard" To: "Khan, Sohel Q [CTO]" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 > Codec can be implemented in the peering interface. On L5? Richard > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Wednesday, June 28, 2006 3:47 PM > To: Stastny Richard; Livingood, Jason > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t > xt >=20 > Codec can be implemented in the peering interface. > It can be internal to a provider network. >=20 >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, June 28, 2006 6:06 AM > To: Livingood, Jason > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D > ACTION:draft-ietf-speermint-requirements-00.t xt >=20 > 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? > > If not, is there much utility in peering if certain provider types > > cannot agree on a common codec? > > > The codecs are a terminal or end-user device issue. Peering between > service providers have no influence on these. So if there is no match in > available codecs, the only way out is to insert a transcoding function > on one or on both sides. >=20 > Since I am not so in protocol details, so I have a question: is there a > call flow available to do so? >=20 > And if, the codec selected is part of the peering agreement itself. > Which > codec is up to the parties. >=20 > Richard > > >=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 Jun 28 10:44:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvbH3-0002M2-Fo; Wed, 28 Jun 2006 10:44:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvbH2-0002Lw-2C for speermint@ietf.org; Wed, 28 Jun 2006 10:44:12 -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 1FvbH1-0007YW-FA for speermint@ietf.org; Wed, 28 Jun 2006 10:44:12 -0400 Received: from PMelampy2 [10.0.200.91] by acmepacket.com with ESMTP (SMTPD-9.03) id A5B90664; Wed, 28 Jun 2006 10:44:09 -0400 From: "Patrick Melampy" To: "'Livingood, Jason'" Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Wed, 28 Jun 2006 10:44:10 -0400 Message-ID: <008601c69ac1$5146adf0$5bc8000a@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: AcaaD3+sv2ttrBgfQF6JYN+PD0v+sgAGHPAwAAKCnlAAFsqdUAAMwTNg In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D965820E9@PACDCEXCMB03.cable.comcast.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 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 there are 3 carriers...A, B, and C A may only support AMR (wireless network) B may support AMR and G.711 (wireless interconnect network) C may only support G.711 (terminating PSNT network) So now we have a problem... A-----B (negotiates to AMR) WORKS B-----C (negotiates to G.711) WORKS But A----via B-----C FAILS [has no agreeable CODEC's] Thus B finds that on a call by call basis, if they support A and C, they may not be able to provide universal connectivity from A to C and vica-versa. I don't see how this problem can be avoided when there are 3 or more carriers interconnected. I would suggest that this problem is outside the scope of spearmint, and just a general problem. I don't think we should require a codec (this doesn't always make sense), nor do I think we should require transcoding which is offensive in its own rite. I just think this is part of the internal problem B has with the services B wishes to offer. B may have to provide either segmented service offerings, and or transcoding internal to its network to support A and C peering relationships. Said another way, I do not believe incompatible CODEC's is a service provider peering issue, but rather a general technology issue that exists with or without service provider borders. -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Sent: Wednesday, June 28, 2006 6:46 AM To: Brian Rosen; Jean-Francois Mule; Drage, Keith (Keith); Rohan Mahy; Michael Hammer (mhammer) Cc: speermint@ietf.org Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Let's drop the IM and video examples -- for now. Let's first focus on getting the basic one working that we're committed to: voice. 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? If not, is there much utility in peering if certain provider types cannot agree on a common codec? Jason > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, June 27, 2006 5:40 PM > To: 'Jean-Francois Mule'; '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 > > 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? > > > 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 Wed Jun 28 11:15:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvblN-0006py-3t; Wed, 28 Jun 2006 11:15:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvblL-0006kv-EB for speermint@ietf.org; Wed, 28 Jun 2006 11:15:31 -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 1FvblJ-00022H-JD for speermint@ietf.org; Wed, 28 Jun 2006 11:15:31 -0400 Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.21889535; Wed, 28 Jun 2006 11:15:06 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 11:15:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Wed, 28 Jun 2006 11:14:33 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D9658211B@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: AcaaD3+sv2ttrBgfQF6JYN+PD0v+sgAGHPAwAAKCnlAAFsqdUAAMwTNgAAEhTVA= From: "Livingood, Jason" To: "Patrick Melampy" X-OriginalArrivalTime: 28 Jun 2006 15:15:05.0649 (UTC) FILETIME=[A2C1EA10:01C69AC5] X-Spam-Score: 0.0 (/) X-Scan-Signature: dadeebe491e67c033a493fd3c7d6792b 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 disagree with the fact that codec mismatches are a general technology issue. =20 However, I am not yet convinced (I'd like some operators to weigh in) that continuing to *discuss* whether or not there *may* be a need for a lowest common demoninator codec requirement is necessarily bad.=20 Yes, endpoints or other elements will negotiate codecs, and no we're not trying to tread into that area. But I do think it's rational to consider whether many peered domains may find it in their interest to have a common codec, or language, to fall back on failing other, perhaps more preferred or efficient codecs. Whether someone had to transcode in their network to meet such a requirement, were it even adopted, would be out of scope as much as how the internals of IMS, PacketCable, and washing machines are to us. ;-) Again, looking to have some operators weigh in with their thoughts. Jason > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com]=20 > Sent: Wednesday, June 28, 2006 10:44 AM > To: Livingood, Jason > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D=20 > ACTION:draft-ietf-speermint-requirements-00.t xt >=20 > If there are 3 carriers...A, B, and C >=20 > A may only support AMR (wireless network) B may support AMR=20 > and G.711 (wireless interconnect network) C may only support=20 > G.711 (terminating PSNT network) >=20 > So now we have a problem... >=20 > A-----B (negotiates to AMR) WORKS >=20 > B-----C (negotiates to G.711) WORKS >=20 > But A----via B-----C FAILS [has no agreeable CODEC's] >=20 > Thus B finds that on a call by call basis, if they support A=20 > and C, they may not be able to provide universal connectivity=20 > from A to C and vica-versa. >=20 > I don't see how this problem can be avoided when there are 3=20 > or more carriers interconnected. I would suggest that this=20 > problem is outside the scope of spearmint, and just a general problem. >=20 > I don't think we should require a codec (this doesn't always=20 > make sense), nor do I think we should require transcoding=20 > which is offensive in its own rite. I just think this is part=20 > of the internal problem B has with the services B wishes to=20 > offer. B may have to provide either segmented service=20 > offerings, and or transcoding internal to its network to=20 > support A and C peering relationships. >=20 > Said another way, I do not believe incompatible CODEC's is a=20 > service provider peering issue, but rather a general=20 > technology issue that exists with or without service provider borders. >=20 >=20 > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Wednesday, June 28, 2006 6:46 AM > To: Brian Rosen; Jean-Francois Mule; Drage, Keith (Keith);=20 > Rohan Mahy; Michael Hammer (mhammer) > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D=20 > ACTION:draft-ietf-speermint-requirements-00.t > xt >=20 > Let's drop the IM and video examples -- for now. Let's first=20 > focus on getting the basic one working that we're committed=20 > to: voice. =20 >=20 > So in the case of voice, the question at hand is - is there a=20 > lowest common denominator voice codec which should be=20 > required to do peering? > If not, is there much utility in peering if certain provider=20 > types cannot agree on a common codec? >=20 > Jason >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, June 27, 2006 5:40 PM > > To: 'Jean-Francois Mule'; 'Drage, Keith (Keith)'; Livingood, Jason;=20 > > 'Rohan Mahy'; 'Michael Hammer (mhammer)' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] I-D > > ACTION:draft-ietf-speermint-requirements-00.t xt > >=20 > > 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 to have=20 > > G.711? > >=20 > > Consider an all-IM federation. Do they have to have G.711? > >=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 > > 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 > > ACTION:draft-ietf-speermint-requirements- > > > 00.t xt > > >=20 > > > But this still does not answer my original question. > > >=20 > > > 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? > > >=20 > > > regards > > >=20 > > > Keith > > >=20 > > > > -----Original Message----- > > > > From: Livingood, Jason=20 > [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=20 > > > > discussion. > > > > I would surely agree that codec negotiation / selection=20 > is *well*=20 > > > > handled in the underlying SIP protocol itself. However, > > we may well > > > > find a need to specify (or not) a lowest common=20 > 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. =20 > > > > > It might or it might not, but the IETF won't be very=20 > effective=20 > > > > > trying to put requirements on something which is=20 > effectively a=20 > > > > > 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=20 > > > > > 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=20 > > > > > circumstances. I don't think we can do any better than > > that in a > > > > > requirements document, especially since we are describing an=20 > > > > > 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)=20 > 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=20 > > > > > > > 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=20 > 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=20 > 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=20 > sdp-new is=20 > > > > > > > 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=20 > 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=20 > 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=20 > 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: > > > > > > > >=20 > 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 > > > > > > >=20 > /internet-drafts/draft-ietf-speermint-requirements-00.txt". > > > > > > > > > > > > > > NOTE: The mail server at ietf.org can return the=20 > 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 > > > > > > >=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 >=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 Jun 28 11:28:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvbyD-0005jE-Ho; Wed, 28 Jun 2006 11:28:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvbyC-0005j9-QL for speermint@ietf.org; Wed, 28 Jun 2006 11:28:48 -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 1FvbyC-0003Yi-Cu for speermint@ietf.org; Wed, 28 Jun 2006 11:28:48 -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 k5SFSiaK016668; Wed, 28 Jun 2006 15:28:44 GMT Subject: RE: TLS for peering (was RE: Comments (RE: [speermint] requirementsdraft submitted)) From: Daryl Malas To: "Uzelac, Adam" In-Reply-To: References: Content-Type: text/plain Date: Wed, 28 Jun 2006 09:28:03 -0600 Message-Id: <1151508483.10104.3.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: 057ebe9b96adec30a7efb2aeda4c26a4 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 agree with Adam's assessment. Requiring TLS is simply not realistic at this point. I believe it has the potential of becoming a more common practice in the future, but not right now. --Daryl On Tue, 2006-06-27 at 21:47 -0400, Uzelac, Adam wrote: > TLS is becoming more and more a subject when the topic of SIP > interconnections arises for me professionally. This shows growing > momentum indeed. With that said, I can not agree with TLS as a > steadfast requirement. Economics and scale are my major concerns. TLS > adds cost, server load, and there are fail-over issues to consider as > well. For the person that designs an interconnect, I believe weighing > the cost against the benefit of the different models a useful exercise. > Mandating TLS, even if all parties involved in a peering arrangement > feel somehow "safe and secure" due to underlying security mechanisms > (L2/L3VPNs, etc), seems a little harsh. > > Adam > > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@3clogic.com] > Sent: Tuesday, June 27, 2006 8:44 PM > To: Reinaldo Penno > Cc: speermint@ietf.org > Subject: Re: TLS for peering (was RE: Comments (RE: [speermint] > requirementsdraft submitted)) > > I am not a provider yet, but I think we dont need to mess with TLS/TCP. > As I understand one of the goals is to prevent the calls from failing > due to "peering only" reasons. This means that things like codecs which > are not negotiated by the peers need to be mandated at a minimal level. > TCP/TLS can be negotiated between the peers themselves so it is a > non-issue. Also as I still understand doing a high volume calls with TLS > is still expensive. Mandating TLS in cases where the caller or callee > dont require it doesnt seem to add any value. > > -Medhavi. > > On 6/27/06, Reinaldo Penno wrote: > > > > TLS for _all_ scenarios? Even in private peerings, physically secure > > peerings, etc? > > > > Isn't that the same as requiring IPsec for all layer 3 peering? But > > since Layer 5 peering might be more distributed, the number of TLS > > sessions would be huge. > > > > It would be good to hear the provider's opinion on this... > > > > Thanks, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, June 27, 2006 2:12 PM > > > To: 'Jean-Francois Mule'; Reinaldo Penno > > > Cc: speermint@ietf.org > > > Subject: RE: Comments (RE: [speermint] requirements draft submitted) > > > > > > > > > > > "3.4. Security requirements > > > > > > > > All SIP messages MUST be sent over TLS [RFC3546] to provide > > > > transport-layer security as defined in RFC 3261," > > > > > > > > Giving the fact that we can have security through physical > > > segregation, > > > > intra-federation/provider calls, etc, the "MUST" here seems too > > > > generic. > > > > > > I tend to differ on this: it is not because you have lower layer > > > security (presumably hop by hop security associations) that you > > > should relax the end-to-end transport security requirements. > > > Rohan's well written draft is also in favor of mandatory support of > > TLS, > > > and so is the SIP Forum's IP PBX to VSP (here is a working link: > > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_In > > te > > > rop-sibley-final.pdf). > > > May be the requirement should be rewritten to put the MUST on SIP > > > entities involved in L5 peering. > > > > > > I'm in favor of requiring TLS. I'd say MUST in a heartbeat. > > > > > > Brian > > > > _______________________________________________ > > 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 Wed Jun 28 11:41:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvcAK-0000iU-MF; Wed, 28 Jun 2006 11:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvcAJ-0000cY-Ty for speermint@ietf.org; Wed, 28 Jun 2006 11:41:19 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvcAJ-0004qa-5T for speermint@ietf.org; Wed, 28 Jun 2006 11:41:19 -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 k5SFfFKY007966; Wed, 28 Jun 2006 09:41:15 -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: Wed, 28 Jun 2006 09:41:15 -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: AcaaD3+sv2ttrBgfQF6JYN+PD0v+sgAGHPAwAAKCnlAAFsqdUAAMwTNgAAHOsnA= From: "Jean-Francois Mule" To: "Patrick Melampy" , "Livingood, Jason" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 32604d42645517c44d778f1d111b40a6 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 Patrick, See inline: this is a typical case of using a list formed from a union of groups but the groups' intersection results in an empty list. Patrick wrote: > If there are 3 carriers...A, B, and C >=20 > A may only support AMR (wireless network) > B may support AMR and G.711 (wireless interconnect network) > C may only support G.711 (terminating PSNT network) >=20 > So now we have a problem... >=20 > A-----B (negotiates to AMR) WORKS ^^^^^^^^^^ If they "negotiate" codec, it means they do perform session peering (A,B). >=20 > B-----C (negotiates to G.711) WORKS Same here (B,C) > But A----via B-----C FAILS [has no agreeable CODEC's] ^^^ A and C do not perform session peering directly. This is transit case: why should we care about this case? If B agrees to transit calls from A to C (i.e. B can be a resolved target for users of C in A's land), then B should provide codec transcoding.=20 =20 > Thus B finds that on a call by call basis, if they support A and C, > they may > not be able to provide universal connectivity from A to C and vica- > versa. Blame B. > I don't see how this problem can be avoided when there are 3 or more > carriers interconnected.=20 The transit case is just a curved ball here, nothing new is added. A and C are not L5 peers, period. > I would suggest that this problem is outside > the > scope of spearmint, and just a general problem. >=20 > I don't think we should require a codec (this doesn't always make > sense), > nor do I think we should require transcoding which is offensive in its > own > rite.=20 The direct peers (A,B) and (B,C) do have a codec in common. > I just think this is part of the internal problem B has with the > services B wishes to offer. B may have to provide either segmented > service > offerings, and or transcoding internal to its network to support A and > C > peering relationships. >=20 > Said another way, I do not believe incompatible CODEC's is a service > provider peering issue, but rather a general technology issue that > exists > with or without service provider borders. I'd rather speak in terms of requirements rather than issues. Let's depart from the provocative requirements of mandating G.711 everywhere to refocus on more open questions: should any codec recommendations be made in the specific WG deliverable for "the minimum set of requirements for VoIP interconnects"? Jean-Francois. > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Wednesday, June 28, 2006 6:46 AM > To: Brian Rosen; Jean-Francois Mule; Drage, Keith (Keith); Rohan Mahy; > Michael Hammer (mhammer) > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements- > 00.t > xt >=20 > Let's drop the IM and video examples -- for now. Let's first focus on > getting the basic one working that we're committed to: voice. >=20 > 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? > If not, is there much utility in peering if certain provider types > cannot agree on a common codec? >=20 > Jason >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, June 27, 2006 5:40 PM > > To: 'Jean-Francois Mule'; '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 > > > > 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? > > > > > > 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 > > > > >=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 Wed Jun 28 12:09:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvcbd-00051T-E0; Wed, 28 Jun 2006 12:09:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvcbS-0004l6-8t for speermint@ietf.org; Wed, 28 Jun 2006 12:09:22 -0400 Received: from outbound-fra.frontbridge.com ([62.209.45.174] helo=outbound2-fra-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvcbQ-0007Fp-MD for speermint@ietf.org; Wed, 28 Jun 2006 12:09:22 -0400 Received: from outbound2-fra.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-fra-R.bigfish.com (Postfix) with ESMTP id 89E8A7DB1BB; Wed, 28 Jun 2006 16:08:17 +0000 (UTC) Received: from mail58-fra-R.bigfish.com (unknown [172.18.18.1]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound2-fra.bigfish.com (Postfix) with ESMTP id 862177DB1B9; Wed, 28 Jun 2006 16:08:17 +0000 (UTC) Received: from mail58-fra.bigfish.com (localhost.localdomain [127.0.0.1]) by mail58-fra-R.bigfish.com (Postfix) with ESMTP id 8013A469E26; Wed, 28 Jun 2006 16:08:17 +0000 (UTC) X-BigFish: V Received: by mail58-fra (MessageSwitch) id 1151510897427153_10908; Wed, 28 Jun 2006 16:08:17 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail58-fra.bigfish.com (Postfix) with ESMTP id 2C420469823; Wed, 28 Jun 2006 16:08:17 +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 k5SG7Vqm006679; Wed, 28 Jun 2006 11:07:56 -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 k5SG3j723913; Wed, 28 Jun 2006 11:03:45 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by pdawg05a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 11:03:45 -0500 Received: from 10.122.2.36 ([10.122.2.36]) by PLSWB08C.ad.sprint.com ([208.10.70.245]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Jun 2006 16:03:44 +0000 MIME-Version: 1.0 Message-ID: <92b001c69acc$6e73696d$24027a0a@ad.sprint.com> From: "Khan, Sohel Q [CTO]" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: TLS for peering (was RE: Comments (RE: [speermint]requirementsdraft submitted)) X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: TLS for peering (was RE: Comments (RE: [speermint]requirementsdraft submitted)) Thread-Index: AcaazG5zH3Hgwvv5RueVLqSQoPsWnA== Date: Wed, 28 Jun 2006 11:05:59 -0500 Importance: normal X-Priority: 3 To: "Daryl Malas" , "Uzelac, Adam" X-OriginalArrivalTime: 28 Jun 2006 16:03:45.0280 (UTC) FILETIME=[6EFE4000:01C69ACC] X-Spam-Score: 3.1 (+++) 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 So, what do u recommended ? Keep TLS optional? Any other method? Sohel=20 -----Original Message----- From: "Daryl Malas" To: "Uzelac, Adam" Cc: "speermint@ietf.org" Sent: 6/28/06 10:29 AM Subject: RE: TLS for peering (was RE: Comments (RE: = [speermint]requirementsdraft submitted)) I agree with Adam's assessment. Requiring TLS is simply not realistic at this point. I believe it has the potential of becoming a more common practice in the future, but not right now. --Daryl On Tue, 2006-06-27 at 21:47 -0400, Uzelac, Adam wrote: > TLS is becoming more and more a subject when the topic of SIP > interconnections arises for me professionally. This shows growing > momentum indeed. With that said, I can not agree with TLS as a > steadfast requirement. Economics and scale are my major concerns. = TLS > adds cost, server load, and there are fail-over issues to consider as > well. For the person that designs an interconnect, I believe weighing > the cost against the benefit of the different models a useful = exercise. > Mandating TLS, even if all parties involved in a peering arrangement > feel somehow "safe and secure" due to underlying security mechanisms > (L2/L3VPNs, etc), seems a little harsh. =20 >=20 > Adam >=20 > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@3clogic.com]=20 > Sent: Tuesday, June 27, 2006 8:44 PM > To: Reinaldo Penno > Cc: speermint@ietf.org > Subject: Re: TLS for peering (was RE: Comments (RE: [speermint] > requirementsdraft submitted)) >=20 > I am not a provider yet, but I think we dont need to mess with = TLS/TCP. > As I understand one of the goals is to prevent the calls from failing > due to "peering only" reasons. This means that things like codecs = which > are not negotiated by the peers need to be mandated at a minimal = level. > TCP/TLS can be negotiated between the peers themselves so it is a > non-issue. Also as I still understand doing a high volume calls with = TLS > is still expensive. Mandating TLS in cases where the caller or callee > dont require it doesnt seem to add any value. >=20 > -Medhavi. >=20 > On 6/27/06, Reinaldo Penno wrote: > > > > TLS for _all_ scenarios? Even in private peerings, physically secure = > > peerings, etc? > > > > Isn't that the same as requiring IPsec for all layer 3 peering? But=20 > > since Layer 5 peering might be more distributed, the number of TLS=20 > > sessions would be huge. > > > > It would be good to hear the provider's opinion on this... > > > > Thanks, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, June 27, 2006 2:12 PM > > > To: 'Jean-Francois Mule'; Reinaldo Penno > > > Cc: speermint@ietf.org > > > Subject: RE: Comments (RE: [speermint] requirements draft = submitted) > > > > > > > > > > > "3.4. Security requirements > > > > > > > > All SIP messages MUST be sent over TLS [RFC3546] to provide > > > > transport-layer security as defined in RFC 3261," > > > > > > > > Giving the fact that we can have security through physical > > > segregation, > > > > intra-federation/provider calls, etc, the "MUST" here seems too=20 > > > > generic. > > > > > > I tend to differ on this: it is not because you have lower layer=20 > > > security (presumably hop by hop security associations) that you=20 > > > should relax the end-to-end transport security requirements. > > > Rohan's well written draft is also in favor of mandatory support = of > > TLS, > > > and so is the SIP Forum's IP PBX to VSP (here is a working link: > > > > > = http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_In > > te > > > rop-sibley-final.pdf). > > > May be the requirement should be rewritten to put the MUST on SIP=20 > > > entities involved in L5 peering. > > > > > > I'm in favor of requiring TLS. I'd say MUST in a = heartbeat. > > > > > > Brian > > > > _______________________________________________ > > 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 _______________________________________________ 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 Jun 28 12:12:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvceV-0006Ag-5b; Wed, 28 Jun 2006 12:12:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvceT-00068u-UZ for speermint@ietf.org; Wed, 28 Jun 2006 12:12:29 -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 1FvceT-0007Va-8I for speermint@ietf.org; Wed, 28 Jun 2006 12:12:29 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id E1C103494; Wed, 28 Jun 2006 12:12:28 -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, 28 Jun 2006 12:12: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] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Wed, 28 Jun 2006 12:12:25 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Thread-Index: AcaaD3+sv2ttrBgfQF6JYN+PD0v+sgAGHPAwAAKCnlAAFsqdUAAMwTNgAAHOsnAAAIyZsA== From: "Uzelac, Adam" To: "Jean-Francois Mule" , "Patrick Melampy" , "Livingood, Jason" X-OriginalArrivalTime: 28 Jun 2006 16:12:28.0743 (UTC) FILETIME=[A7005D70:01C69ACD] X-Spam-Score: 0.1 (/) X-Scan-Signature: bfc9ec46aa2f66e5aee6a3bbffb0ebe9 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 here. I completely agree with Jean-Francois that we should focus on the open question: should any codec recommendations be made in the specific WG deliverable for "the minimum set of requirements for VoIP interconnects"? - Here are my thoughts. Transcoding sucks (ok - it's not-preferred I mean), but a current reality because, as an operator, we have the obligation to complete the call due to the expectations of the peering relationship. If the call is to/fro the PSTN, then G711 is most likely in the mix. If the call is going to an enterprise that has an affinity to G729, well then G729 it is for them. I would _love_ to do anything that eliminates all the bad things (like adding additional jitter and play-out buffers, adding superfluous elements into call flows, degrading call quality due to a poor-quality codec "hops" in the mix) that media transcoding introduces. But I think that by restricting the applicability by way of mandating codecs, etc is not the right thing to do AT THIS STAGE. I think we should take the tactic of suggesting an IETF codec (iLBC or SPEEX) and indicate that a common denominator is in everyone's best interest. (Well, everyone except the transcoding vendors! You know who you are!!) But leave it as a suggestion for now. Did I mention that I didn't like transcoding?!?! -AU -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Wednesday, June 28, 2006 11:41 AM To: Patrick Melampy; Livingood, Jason Cc: speermint@ietf.org Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Patrick, See inline: this is a typical case of using a list formed from a union of groups but the groups' intersection results in an empty list. Patrick wrote: > If there are 3 carriers...A, B, and C >=20 > A may only support AMR (wireless network) B may support AMR and G.711=20 > (wireless interconnect network) C may only support G.711 (terminating=20 > PSNT network) >=20 > So now we have a problem... >=20 > A-----B (negotiates to AMR) WORKS ^^^^^^^^^^ If they "negotiate" codec, it means they do perform session peering (A,B). >=20 > B-----C (negotiates to G.711) WORKS Same here (B,C) > But A----via B-----C FAILS [has no agreeable CODEC's] ^^^ A and C do not perform session peering directly. This is transit case: why should we care about this case? If B agrees to transit calls from A to C (i.e. B can be a resolved target for users of C in A's land), then B should provide codec transcoding.=20 =20 > Thus B finds that on a call by call basis, if they support A and C,=20 > they may not be able to provide universal connectivity from A to C and > vica- versa. Blame B. > I don't see how this problem can be avoided when there are 3 or more=20 > carriers interconnected. The transit case is just a curved ball here, nothing new is added. A and C are not L5 peers, period. > I would suggest that this problem is outside the scope of spearmint,=20 > and just a general problem. >=20 > I don't think we should require a codec (this doesn't always make=20 > sense), nor do I think we should require transcoding which is=20 > offensive in its own rite. The direct peers (A,B) and (B,C) do have a codec in common. > I just think this is part of the internal problem B has with the=20 > services B wishes to offer. B may have to provide either segmented=20 > service offerings, and or transcoding internal to its network to=20 > support A and C peering relationships. >=20 > Said another way, I do not believe incompatible CODEC's is a service=20 > provider peering issue, but rather a general technology issue that=20 > exists with or without service provider borders. I'd rather speak in terms of requirements rather than issues. Let's depart from the provocative requirements of mandating G.711 everywhere to refocus on more open questions: should any codec recommendations be made in the specific WG deliverable for "the minimum set of requirements for VoIP interconnects"? Jean-Francois. > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Wednesday, June 28, 2006 6:46 AM > To: Brian Rosen; Jean-Francois Mule; Drage, Keith (Keith); Rohan Mahy; > Michael Hammer (mhammer) > Cc: speermint@ietf.org > Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements- > 00.t > xt >=20 > Let's drop the IM and video examples -- for now. Let's first focus on > getting the basic one working that we're committed to: voice. >=20 > So in the case of voice, the question at hand is - is there a lowest=20 > common denominator voice codec which should be required to do peering? > If not, is there much utility in peering if certain provider types=20 > cannot agree on a common codec? >=20 > Jason >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, June 27, 2006 5:40 PM > > To: 'Jean-Francois Mule'; 'Drage, Keith (Keith)'; Livingood, Jason;=20 > > 'Rohan Mahy'; 'Michael Hammer (mhammer)' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] I-D > > ACTION:draft-ietf-speermint-requirements-00.t xt > > > > 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=20 > > G.711? > > > > Consider an all-IM federation. Do they have to have G.711? > > > > > > 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=20 > > 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=20 > > negotiation just does not fail? I could care less where this=20 > > 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=20 > > > > 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=20 > > > > > 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=20 > > > > > circumstances. I don't think we can do any better than > > that in a > > > > > requirements document, especially since we are describing an=20 > > > > > 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=20 > > > > > > > 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=20 > > > > > > > > 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=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 > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jun 28 14:29:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvenE-00048I-Nh; Wed, 28 Jun 2006 14:29:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvenD-000414-Ob for speermint@ietf.org; Wed, 28 Jun 2006 14:29:39 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvenC-0004H5-5y for speermint@ietf.org; Wed, 28 Jun 2006 14:29: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 k5SITXnY030305; Wed, 28 Jun 2006 11:29:33 -0700 From: "Richard Shockey" To: "'Khan, Sohel Q [CTO]'" , "'Daryl Malas'" , "'Uzelac, Adam'" Subject: RE: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) Date: Wed, 28 Jun 2006 14:28:56 -0400 Message-ID: <008801c69ae0$b804c530$4d201f0a@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: AcaazG5zH3Hgwvv5RueVLqSQoPsWnAAE6qyw In-Reply-To: <92b001c69acc$6e73696d$24027a0a@ad.sprint.com> 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: 3fbd9b434023f8abfcb1532abaec7a21 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 TLS is a core part of the SIP specification. Saying its not realistic is just plain bovine effluent. You are not going to interconnect at the most basic level unless there is a level of trust between the domains. So how do you plan on authenticating the domain? This was the absolute conclusion of the SIP Forum when we came up with the SIP Connect specification for PBX to SP interconnection. SP to SP interconnection is not that much different. http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_Interop- sibley-final.pdf > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Wednesday, June 28, 2006 12:06 PM > To: Daryl Malas; Uzelac, Adam > Cc: speermint@ietf.org > Subject: RE: TLS for peering (was RE: Comments > (RE:[speermint]requirementsdraft submitted)) > > So, what do u recommended ? > Keep TLS optional? > Any other method? > > Sohel > > > -----Original Message----- > From: "Daryl Malas" > To: "Uzelac, Adam" > Cc: "speermint@ietf.org" > Sent: 6/28/06 10:29 AM > Subject: RE: TLS for peering (was RE: Comments (RE: > [speermint]requirementsdraft submitted)) > > I agree with Adam's assessment. Requiring TLS is simply not realistic > at this point. I believe it has the potential of becoming a more common > practice in the future, but not right now. > > --Daryl > > On Tue, 2006-06-27 at 21:47 -0400, Uzelac, Adam wrote: > > TLS is becoming more and more a subject when the topic of SIP > > interconnections arises for me professionally. This shows growing > > momentum indeed. With that said, I can not agree with TLS as a > > steadfast requirement. Economics and scale are my major concerns. TLS > > adds cost, server load, and there are fail-over issues to consider as > > well. For the person that designs an interconnect, I believe weighing > > the cost against the benefit of the different models a useful exercise. > > Mandating TLS, even if all parties involved in a peering arrangement > > feel somehow "safe and secure" due to underlying security mechanisms > > (L2/L3VPNs, etc), seems a little harsh. > > > > Adam > > > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@3clogic.com] > > Sent: Tuesday, June 27, 2006 8:44 PM > > To: Reinaldo Penno > > Cc: speermint@ietf.org > > Subject: Re: TLS for peering (was RE: Comments (RE: [speermint] > > requirementsdraft submitted)) > > > > I am not a provider yet, but I think we dont need to mess with TLS/TCP. > > As I understand one of the goals is to prevent the calls from failing > > due to "peering only" reasons. This means that things like codecs which > > are not negotiated by the peers need to be mandated at a minimal level. > > TCP/TLS can be negotiated between the peers themselves so it is a > > non-issue. Also as I still understand doing a high volume calls with TLS > > is still expensive. Mandating TLS in cases where the caller or callee > > dont require it doesnt seem to add any value. > > > > -Medhavi. > > > > On 6/27/06, Reinaldo Penno wrote: > > > > > > TLS for _all_ scenarios? Even in private peerings, physically secure > > > peerings, etc? > > > > > > Isn't that the same as requiring IPsec for all layer 3 peering? But > > > since Layer 5 peering might be more distributed, the number of TLS > > > sessions would be huge. > > > > > > It would be good to hear the provider's opinion on this... > > > > > > Thanks, > > > > > > Reinaldo > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Tuesday, June 27, 2006 2:12 PM > > > > To: 'Jean-Francois Mule'; Reinaldo Penno > > > > Cc: speermint@ietf.org > > > > Subject: RE: Comments (RE: [speermint] requirements draft submitted) > > > > > > > > > > > > > > "3.4. Security requirements > > > > > > > > > > All SIP messages MUST be sent over TLS [RFC3546] to provide > > > > > transport-layer security as defined in RFC 3261," > > > > > > > > > > Giving the fact that we can have security through physical > > > > segregation, > > > > > intra-federation/provider calls, etc, the "MUST" here seems too > > > > > generic. > > > > > > > > I tend to differ on this: it is not because you have lower layer > > > > security (presumably hop by hop security associations) that you > > > > should relax the end-to-end transport security requirements. > > > > Rohan's well written draft is also in favor of mandatory support of > > > TLS, > > > > and so is the SIP Forum's IP PBX to VSP (here is a working link: > > > > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_In > > > te > > > > rop-sibley-final.pdf). > > > > May be the requirement should be rewritten to put the MUST on SIP > > > > entities involved in L5 peering. > > > > > > > > I'm in favor of requiring TLS. I'd say MUST in a heartbeat. > > > > > > > > Brian > > > > > > _______________________________________________ > > > 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 Wed Jun 28 14:43:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvf0K-0006mh-JN; Wed, 28 Jun 2006 14:43:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvf0J-0006mc-2X for speermint@ietf.org; Wed, 28 Jun 2006 14:43:11 -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 1Fvf0I-0006lI-GH for speermint@ietf.org; Wed, 28 Jun 2006 14:43:11 -0400 Received: from [192.168.0.5] ([::ffff:69.164.213.95]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 28 Jun 2006 14:43:28 -0400 id 015881AA.44A2CDD0.00000F93 In-Reply-To: <008801c69ae0$b804c530$4d201f0a@cis.neustar.com> References: <008801c69ae0$b804c530$4d201f0a@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <939B0075-C7D3-426C-BBAD-D8E0D47A8BB4@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) Date: Wed, 28 Jun 2006 14:43:08 -0400 To: richard@shockey.us X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: speermint@ietf.org, "'Khan, Sohel Q \[CTO\]'" , "'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 While we are at it, why don't we make signed DNS zones and DNSSEC TSIG mandatory too. That way we can have many things in an RFC that are flat out ignored. I agree with Adam and Daryl. -andy On Jun 28, 2006, at 2:28 PM, Richard Shockey wrote: > > > TLS is a core part of the SIP specification. Saying its not > realistic is > just plain bovine effluent. > > You are not going to interconnect at the most basic level unless > there is a > level of trust between the domains. So how do you plan on > authenticating the > domain? > > This was the absolute conclusion of the SIP Forum when we came up > with the > SIP Connect specification for PBX to SP interconnection. > > SP to SP interconnection is not that much different. > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg- > IP_PBX_SP_Interop- > sibley-final.pdf > > > >> -----Original Message----- >> From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] >> Sent: Wednesday, June 28, 2006 12:06 PM >> To: Daryl Malas; Uzelac, Adam >> Cc: speermint@ietf.org >> Subject: RE: TLS for peering (was RE: Comments >> (RE:[speermint]requirementsdraft submitted)) >> >> So, what do u recommended ? >> Keep TLS optional? >> Any other method? >> >> Sohel >> >> >> -----Original Message----- >> From: "Daryl Malas" >> To: "Uzelac, Adam" >> Cc: "speermint@ietf.org" >> Sent: 6/28/06 10:29 AM >> Subject: RE: TLS for peering (was RE: Comments (RE: >> [speermint]requirementsdraft submitted)) >> >> I agree with Adam's assessment. Requiring TLS is simply not >> realistic >> at this point. I believe it has the potential of becoming a more >> common >> practice in the future, but not right now. >> >> --Daryl >> >> On Tue, 2006-06-27 at 21:47 -0400, Uzelac, Adam wrote: >>> TLS is becoming more and more a subject when the topic of SIP >>> interconnections arises for me professionally. This shows growing >>> momentum indeed. With that said, I can not agree with TLS as a >>> steadfast requirement. Economics and scale are my major >>> concerns. TLS >>> adds cost, server load, and there are fail-over issues to >>> consider as >>> well. For the person that designs an interconnect, I believe >>> weighing >>> the cost against the benefit of the different models a useful >>> exercise. >>> Mandating TLS, even if all parties involved in a peering arrangement >>> feel somehow "safe and secure" due to underlying security mechanisms >>> (L2/L3VPNs, etc), seems a little harsh. >>> >>> Adam >>> >>> -----Original Message----- >>> From: Medhavi Bhatia [mailto:mbhatia@3clogic.com] >>> Sent: Tuesday, June 27, 2006 8:44 PM >>> To: Reinaldo Penno >>> Cc: speermint@ietf.org >>> Subject: Re: TLS for peering (was RE: Comments (RE: [speermint] >>> requirementsdraft submitted)) >>> >>> I am not a provider yet, but I think we dont need to mess with >>> TLS/TCP. >>> As I understand one of the goals is to prevent the calls from >>> failing >>> due to "peering only" reasons. This means that things like codecs >>> which >>> are not negotiated by the peers need to be mandated at a minimal >>> level. >>> TCP/TLS can be negotiated between the peers themselves so it is a >>> non-issue. Also as I still understand doing a high volume calls >>> with TLS >>> is still expensive. Mandating TLS in cases where the caller or >>> callee >>> dont require it doesnt seem to add any value. >>> >>> -Medhavi. >>> >>> On 6/27/06, Reinaldo Penno wrote: >>>> >>>> TLS for _all_ scenarios? Even in private peerings, physically >>>> secure >>>> peerings, etc? >>>> >>>> Isn't that the same as requiring IPsec for all layer 3 peering? But >>>> since Layer 5 peering might be more distributed, the number of TLS >>>> sessions would be huge. >>>> >>>> It would be good to hear the provider's opinion on this... >>>> >>>> Thanks, >>>> >>>> Reinaldo >>>> >>>>> -----Original Message----- >>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>> Sent: Tuesday, June 27, 2006 2:12 PM >>>>> To: 'Jean-Francois Mule'; Reinaldo Penno >>>>> Cc: speermint@ietf.org >>>>> Subject: RE: Comments (RE: [speermint] requirements draft >>>>> submitted) >>>>> >>>>>> >>>>>> "3.4. Security requirements >>>>>> >>>>>> All SIP messages MUST be sent over TLS [RFC3546] to provide >>>>>> transport-layer security as defined in RFC 3261," >>>>>> >>>>>> Giving the fact that we can have security through physical >>>>> segregation, >>>>>> intra-federation/provider calls, etc, the "MUST" here seems too >>>>>> generic. >>>>> >>>>> I tend to differ on this: it is not because you have lower layer >>>>> security (presumably hop by hop security associations) that you >>>>> should relax the end-to-end transport security requirements. >>>>> Rohan's well written draft is also in favor of mandatory >>>>> support of >>>> TLS, >>>>> and so is the SIP Forum's IP PBX to VSP (here is a working link: >>>>> >>>> http://data.memberclicks.com/bbattach/130808/sf-draft-twg- >>>> IP_PBX_SP_In >>>> te >>>>> rop-sibley-final.pdf). >>>>> May be the requirement should be rewritten to put the MUST on SIP >>>>> entities involved in L5 peering. >>>>> >>>>> I'm in favor of requiring TLS. I'd say MUST in a >>>>> heartbeat. >>>>> >>>>> Brian >>>> >>>> _______________________________________________ >>>> 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 Wed Jun 28 14:50:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvf7U-0005L1-Az; Wed, 28 Jun 2006 14:50:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvf7T-0005H2-Fo for speermint@ietf.org; Wed, 28 Jun 2006 14:50:35 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvf7R-0008Qp-Rx for speermint@ietf.org; Wed, 28 Jun 2006 14:50:35 -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 k5SImqs1005190; Wed, 28 Jun 2006 11:48:53 -0700 From: "Richard Shockey" To: "'Andrew Newton'" Subject: RE: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) Date: Wed, 28 Jun 2006 14:48:25 -0400 Message-ID: <00ae01c69ae3$70cc78e0$4d201f0a@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: Acaa4sXkAk+JF92vR1S6c4qXnbZwvAAADzvQ In-Reply-To: <939B0075-C7D3-426C-BBAD-D8E0D47A8BB4@hxr.us> 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: 7268a2980febc47a9fa732aba2b737ba Cc: speermint@ietf.org, "'Khan, Sohel Q \[CTO\]'" , "'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 Really Andy ... how do you propose to establish a trust relationship between SIP domain boundaries without TLS? If you cannot establish a trust relationship between interconnecting partners then what is the purpose of this whole exercise? > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Wednesday, June 28, 2006 2:43 PM > To: richard@shockey.us > Cc: 'Khan, Sohel Q [CTO]'; 'Daryl Malas'; 'Uzelac, Adam'; > speermint@ietf.org > Subject: Re: TLS for peering (was RE: Comments > (RE:[speermint]requirementsdraft submitted)) > > While we are at it, why don't we make signed DNS zones and DNSSEC > TSIG mandatory too. That way we can have many things in an RFC that > are flat out ignored. > > I agree with Adam and Daryl. > > -andy > > On Jun 28, 2006, at 2:28 PM, Richard Shockey wrote: > > > > > > > TLS is a core part of the SIP specification. Saying its not > > realistic is > > just plain bovine effluent. > > > > You are not going to interconnect at the most basic level unless > > there is a > > level of trust between the domains. So how do you plan on > > authenticating the > > domain? > > > > This was the absolute conclusion of the SIP Forum when we came up > > with the > > SIP Connect specification for PBX to SP interconnection. > > > > SP to SP interconnection is not that much different. > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg- > > IP_PBX_SP_Interop- > > sibley-final.pdf > > > > > > > >> -----Original Message----- > >> From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > >> Sent: Wednesday, June 28, 2006 12:06 PM > >> To: Daryl Malas; Uzelac, Adam > >> Cc: speermint@ietf.org > >> Subject: RE: TLS for peering (was RE: Comments > >> (RE:[speermint]requirementsdraft submitted)) > >> > >> So, what do u recommended ? > >> Keep TLS optional? > >> Any other method? > >> > >> Sohel > >> > >> > >> -----Original Message----- > >> From: "Daryl Malas" > >> To: "Uzelac, Adam" > >> Cc: "speermint@ietf.org" > >> Sent: 6/28/06 10:29 AM > >> Subject: RE: TLS for peering (was RE: Comments (RE: > >> [speermint]requirementsdraft submitted)) > >> > >> I agree with Adam's assessment. Requiring TLS is simply not > >> realistic > >> at this point. I believe it has the potential of becoming a more > >> common > >> practice in the future, but not right now. > >> > >> --Daryl > >> > >> On Tue, 2006-06-27 at 21:47 -0400, Uzelac, Adam wrote: > >>> TLS is becoming more and more a subject when the topic of SIP > >>> interconnections arises for me professionally. This shows growing > >>> momentum indeed. With that said, I can not agree with TLS as a > >>> steadfast requirement. Economics and scale are my major > >>> concerns. TLS > >>> adds cost, server load, and there are fail-over issues to > >>> consider as > >>> well. For the person that designs an interconnect, I believe > >>> weighing > >>> the cost against the benefit of the different models a useful > >>> exercise. > >>> Mandating TLS, even if all parties involved in a peering arrangement > >>> feel somehow "safe and secure" due to underlying security mechanisms > >>> (L2/L3VPNs, etc), seems a little harsh. > >>> > >>> Adam > >>> > >>> -----Original Message----- > >>> From: Medhavi Bhatia [mailto:mbhatia@3clogic.com] > >>> Sent: Tuesday, June 27, 2006 8:44 PM > >>> To: Reinaldo Penno > >>> Cc: speermint@ietf.org > >>> Subject: Re: TLS for peering (was RE: Comments (RE: [speermint] > >>> requirementsdraft submitted)) > >>> > >>> I am not a provider yet, but I think we dont need to mess with > >>> TLS/TCP. > >>> As I understand one of the goals is to prevent the calls from > >>> failing > >>> due to "peering only" reasons. This means that things like codecs > >>> which > >>> are not negotiated by the peers need to be mandated at a minimal > >>> level. > >>> TCP/TLS can be negotiated between the peers themselves so it is a > >>> non-issue. Also as I still understand doing a high volume calls > >>> with TLS > >>> is still expensive. Mandating TLS in cases where the caller or > >>> callee > >>> dont require it doesnt seem to add any value. > >>> > >>> -Medhavi. > >>> > >>> On 6/27/06, Reinaldo Penno wrote: > >>>> > >>>> TLS for _all_ scenarios? Even in private peerings, physically > >>>> secure > >>>> peerings, etc? > >>>> > >>>> Isn't that the same as requiring IPsec for all layer 3 peering? But > >>>> since Layer 5 peering might be more distributed, the number of TLS > >>>> sessions would be huge. > >>>> > >>>> It would be good to hear the provider's opinion on this... > >>>> > >>>> Thanks, > >>>> > >>>> Reinaldo > >>>> > >>>>> -----Original Message----- > >>>>> From: Brian Rosen [mailto:br@brianrosen.net] > >>>>> Sent: Tuesday, June 27, 2006 2:12 PM > >>>>> To: 'Jean-Francois Mule'; Reinaldo Penno > >>>>> Cc: speermint@ietf.org > >>>>> Subject: RE: Comments (RE: [speermint] requirements draft > >>>>> submitted) > >>>>> > >>>>>> > >>>>>> "3.4. Security requirements > >>>>>> > >>>>>> All SIP messages MUST be sent over TLS [RFC3546] to provide > >>>>>> transport-layer security as defined in RFC 3261," > >>>>>> > >>>>>> Giving the fact that we can have security through physical > >>>>> segregation, > >>>>>> intra-federation/provider calls, etc, the "MUST" here seems too > >>>>>> generic. > >>>>> > >>>>> I tend to differ on this: it is not because you have lower layer > >>>>> security (presumably hop by hop security associations) that you > >>>>> should relax the end-to-end transport security requirements. > >>>>> Rohan's well written draft is also in favor of mandatory > >>>>> support of > >>>> TLS, > >>>>> and so is the SIP Forum's IP PBX to VSP (here is a working link: > >>>>> > >>>> http://data.memberclicks.com/bbattach/130808/sf-draft-twg- > >>>> IP_PBX_SP_In > >>>> te > >>>>> rop-sibley-final.pdf). > >>>>> May be the requirement should be rewritten to put the MUST on SIP > >>>>> entities involved in L5 peering. > >>>>> > >>>>> I'm in favor of requiring TLS. I'd say MUST in a > >>>>> heartbeat. > >>>>> > >>>>> Brian > >>>> > >>>> _______________________________________________ > >>>> 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 Wed Jun 28 15:06:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvfMQ-0003uK-9f; Wed, 28 Jun 2006 15:06:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvfMP-0003uF-8V for speermint@ietf.org; Wed, 28 Jun 2006 15:06:01 -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 1FvfMO-0000ls-0b for speermint@ietf.org; Wed, 28 Jun 2006 15:06:01 -0400 Received: from [192.168.0.5] ([::ffff:69.164.213.95]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 28 Jun 2006 15:06:18 -0400 id 01588032.44A2D32B.00001521 In-Reply-To: <00ae01c69ae3$70cc78e0$4d201f0a@cis.neustar.com> References: <00ae01c69ae3$70cc78e0$4d201f0a@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <732EB664-954E-410E-A7BD-9F53D350F119@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) Date: Wed, 28 Jun 2006 15:05:58 -0400 To: richard@shockey.us X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: speermint@ietf.org, "'Khan, Sohel Q \[CTO\]'" , "'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 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 From speermint-bounces@ietf.org Wed Jun 28 15:08:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvfPF-0004ov-JJ; Wed, 28 Jun 2006 15:08:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvfPE-0004oq-Aw for speermint@ietf.org; Wed, 28 Jun 2006 15:08:56 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvfPC-0000q6-U1 for speermint@ietf.org; Wed, 28 Jun 2006 15:08:56 -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 k5SJ8qBj022520; Wed, 28 Jun 2006 14:08:52 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jun 2006 20:08:52 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290954@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Andrew Newton'" , richard@shockey.us Subject: RE: TLS for peering (was RE: Comments (RE:[speermint]requirements draft submitted)) Date: Wed, 28 Jun 2006 20:08:51 +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: e1924de3f9fb68e58c31920136007eb1 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 Given that writing a requirement in RFC 3261 (standards track) that all SIP implementations must support TLS has not resulted in its universal deployment and use, why should writing it into a SPEERMINT BCP result in any wider deployment and use (BCP is what the milestone in the charter currently indicates)? [And if there is a rational answer to the above question - it would be worth identifying if this means we should be taking that back into SIP rather than documenting it in SPEERMINT] I guess that this raises a more general issue. Is this BCP (and other SPEERMINT work) meant to be focussed on trying to change the world, or should it be focussed on solving immediate problems with getting SIP networks to connect. If the former, then by all means specify TLS. If the latter, then it should probably identify that security solutions are required, and then make sure that sufficient guidance is given on the mechanisms currently available, including TLS, but probably also addressing IPsec. regards Keith > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: 28 June 2006 19:43 > To: richard@shockey.us > Cc: speermint@ietf.org; 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam' > Subject: Re: TLS for peering (was RE: Comments > (RE:[speermint]requirementsdraft submitted)) > > > While we are at it, why don't we make signed DNS zones and DNSSEC > TSIG mandatory too. That way we can have many things in an RFC that > are flat out ignored. > > I agree with Adam and Daryl. > > -andy > > On Jun 28, 2006, at 2:28 PM, Richard Shockey wrote: > > > > > > > TLS is a core part of the SIP specification. Saying its not > > realistic is > > just plain bovine effluent. > > > > You are not going to interconnect at the most basic level unless > > there is a > > level of trust between the domains. So how do you plan on > > authenticating the > > domain? > > > > This was the absolute conclusion of the SIP Forum when we came up > > with the > > SIP Connect specification for PBX to SP interconnection. > > > > SP to SP interconnection is not that much different. > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg- > > IP_PBX_SP_Interop- > > sibley-final.pdf > > > > > > > >> -----Original Message----- > >> From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > >> Sent: Wednesday, June 28, 2006 12:06 PM > >> To: Daryl Malas; Uzelac, Adam > >> Cc: speermint@ietf.org > >> Subject: RE: TLS for peering (was RE: Comments > >> (RE:[speermint]requirementsdraft submitted)) > >> > >> So, what do u recommended ? > >> Keep TLS optional? > >> Any other method? > >> > >> Sohel > >> > >> > >> -----Original Message----- > >> From: "Daryl Malas" > >> To: "Uzelac, Adam" > >> Cc: "speermint@ietf.org" > >> Sent: 6/28/06 10:29 AM > >> Subject: RE: TLS for peering (was RE: Comments (RE: > >> [speermint]requirementsdraft submitted)) > >> > >> I agree with Adam's assessment. Requiring TLS is simply not > >> realistic > >> at this point. I believe it has the potential of becoming a more > >> common > >> practice in the future, but not right now. > >> > >> --Daryl > >> > >> On Tue, 2006-06-27 at 21:47 -0400, Uzelac, Adam wrote: > >>> TLS is becoming more and more a subject when the topic of SIP > >>> interconnections arises for me professionally. This shows growing > >>> momentum indeed. With that said, I can not agree with TLS as a > >>> steadfast requirement. Economics and scale are my major > >>> concerns. TLS > >>> adds cost, server load, and there are fail-over issues to > >>> consider as > >>> well. For the person that designs an interconnect, I believe > >>> weighing > >>> the cost against the benefit of the different models a useful > >>> exercise. > >>> Mandating TLS, even if all parties involved in a peering > arrangement > >>> feel somehow "safe and secure" due to underlying security > mechanisms > >>> (L2/L3VPNs, etc), seems a little harsh. > >>> > >>> Adam > >>> > >>> -----Original Message----- > >>> From: Medhavi Bhatia [mailto:mbhatia@3clogic.com] > >>> Sent: Tuesday, June 27, 2006 8:44 PM > >>> To: Reinaldo Penno > >>> Cc: speermint@ietf.org > >>> Subject: Re: TLS for peering (was RE: Comments (RE: [speermint] > >>> requirementsdraft submitted)) > >>> > >>> I am not a provider yet, but I think we dont need to mess with > >>> TLS/TCP. > >>> As I understand one of the goals is to prevent the calls from > >>> failing > >>> due to "peering only" reasons. This means that things > like codecs > >>> which > >>> are not negotiated by the peers need to be mandated at a minimal > >>> level. > >>> TCP/TLS can be negotiated between the peers themselves so it is a > >>> non-issue. Also as I still understand doing a high volume calls > >>> with TLS > >>> is still expensive. Mandating TLS in cases where the caller or > >>> callee > >>> dont require it doesnt seem to add any value. > >>> > >>> -Medhavi. > >>> > >>> On 6/27/06, Reinaldo Penno wrote: > >>>> > >>>> TLS for _all_ scenarios? Even in private peerings, physically > >>>> secure > >>>> peerings, etc? > >>>> > >>>> Isn't that the same as requiring IPsec for all layer 3 > peering? But > >>>> since Layer 5 peering might be more distributed, the > number of TLS > >>>> sessions would be huge. > >>>> > >>>> It would be good to hear the provider's opinion on this... > >>>> > >>>> Thanks, > >>>> > >>>> Reinaldo > >>>> > >>>>> -----Original Message----- > >>>>> From: Brian Rosen [mailto:br@brianrosen.net] > >>>>> Sent: Tuesday, June 27, 2006 2:12 PM > >>>>> To: 'Jean-Francois Mule'; Reinaldo Penno > >>>>> Cc: speermint@ietf.org > >>>>> Subject: RE: Comments (RE: [speermint] requirements draft > >>>>> submitted) > >>>>> > >>>>>> > >>>>>> "3.4. Security requirements > >>>>>> > >>>>>> All SIP messages MUST be sent over TLS [RFC3546] to provide > >>>>>> transport-layer security as defined in RFC 3261," > >>>>>> > >>>>>> Giving the fact that we can have security through physical > >>>>> segregation, > >>>>>> intra-federation/provider calls, etc, the "MUST" here seems too > >>>>>> generic. > >>>>> > >>>>> I tend to differ on this: it is not because you have lower layer > >>>>> security (presumably hop by hop security associations) that you > >>>>> should relax the end-to-end transport security requirements. > >>>>> Rohan's well written draft is also in favor of mandatory > >>>>> support of > >>>> TLS, > >>>>> and so is the SIP Forum's IP PBX to VSP (here is a working link: > >>>>> > >>>> http://data.memberclicks.com/bbattach/130808/sf-draft-twg- > >>>> IP_PBX_SP_In > >>>> te > >>>>> rop-sibley-final.pdf). > >>>>> May be the requirement should be rewritten to put the > MUST on SIP > >>>>> entities involved in L5 peering. > >>>>> > >>>>> I'm in favor of requiring TLS. I'd say MUST in a > >>>>> heartbeat. > >>>>> > >>>>> Brian > >>>> > >>>> _______________________________________________ > >>>> 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 Wed Jun 28 15:41:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvfuI-0007xy-Ty; Wed, 28 Jun 2006 15:41:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvfuH-0007vr-1D for speermint@ietf.org; Wed, 28 Jun 2006 15:41:01 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvfuF-0002g5-LZ for speermint@ietf.org; Wed, 28 Jun 2006 15:41: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 k5SJfGIl019431; Wed, 28 Jun 2006 12:41:16 -0700 From: "Richard Shockey" To: "'Andrew Newton'" Subject: RE: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) Date: Wed, 28 Jun 2006 15:40:56 -0400 Message-ID: <00ff01c69aea$c7214930$4d201f0a@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: Acaa5fZ5NGhsPsuiTz6yKQm/EKnphAAAhV8g In-Reply-To: <732EB664-954E-410E-A7BD-9F53D350F119@hxr.us> 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: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: speermint@ietf.org, "'Khan, Sohel Q \[CTO\]'" , "'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 Well the one thing we all seem to agree on is that without some trust relationship between interconnecting partners at their domain boundaries this whole exercise is a vast waste of time and electrons. Now then I think Keith has a point. "If the former, then by all means specify TLS. If the latter, then it should probably identify that security solutions are required, and then make sure that sufficient guidance is given on the mechanisms currently available, including TLS, but probably also addressing IPsec." Required ..I's say security solutions are mandated as in MUST. There _are_ certainly more than one mechanism, besides TLS that can be used to establish security & trust at the boundaries. So ..those techniques MUST be deliberately specified along with the risks associated with them. That said there are many of us that are getting very very tired of the constant whining about this or that aspect of 3261 that for one reason or another some developer or service provider doesn't like. Some of us just went through 6 months of this discussion to reach consensus on the SIPConnect with TLS support since it was the obvious choice. TLS support IS mandated in 3261 so IMHO get with the program. I've yet to see real concrete data on why its such a problem to implement or support in high volume SIP transaction systems. Lots of http based Ecommerce seems to rely on per transaction secure connections so I just don't get what the problem is here. > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Wednesday, June 28, 2006 3:06 PM > To: richard@shockey.us > Cc: 'Khan, Sohel Q [CTO]'; 'Daryl Malas'; 'Uzelac, Adam'; > speermint@ietf.org > Subject: Re: TLS for peering (was RE: Comments > (RE:[speermint]requirementsdraft submitted)) > > > 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 From speermint-bounces@ietf.org Wed Jun 28 16:08:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvgKS-0007wz-B5; Wed, 28 Jun 2006 16:08:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvgKR-0007wp-JT for speermint@ietf.org; Wed, 28 Jun 2006 16:08:03 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvgKQ-00064I-9w for speermint@ietf.org; Wed, 28 Jun 2006 16:08:03 -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 k5SK7uFp010296; Wed, 28 Jun 2006 15:07:57 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jun 2006 21:07:56 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C29095C@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'richard@shockey.us'" , "'Andrew Newton'" Subject: RE: TLS for peering (was RE: Comments (RE:[speermint]requirements draft submitted)) Date: Wed, 28 Jun 2006 21:07:55 +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: 32b73d73e8047ed17386f9799119ce43 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 was using REQUIRED as in the RFC 2119 sense - I just forgot to capitalise it. regards Keith > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: 28 June 2006 20:41 > To: 'Andrew Newton' > Cc: speermint@ietf.org; 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam' > Subject: RE: TLS for peering (was RE: Comments > (RE:[speermint]requirementsdraft submitted)) > > > > > Well the one thing we all seem to agree on is that without some trust > relationship between interconnecting partners at their domain > boundaries > this whole exercise is a vast waste of time and electrons. > > Now then I think Keith has a point. > > "If the former, then by all means specify TLS. If the latter, > then it should > probably identify that security solutions are required, and > then make sure > that sufficient guidance is given on the mechanisms currently > available, > including TLS, but probably also addressing IPsec." > > Required ..I's say security solutions are mandated as in MUST. > > There _are_ certainly more than one mechanism, besides TLS > that can be used > to establish security & trust at the boundaries. So ..those > techniques MUST > be deliberately specified along with the risks associated with them. > > That said there are many of us that are getting very very tired of the > constant whining about this or that aspect of 3261 that for > one reason or > another some developer or service provider doesn't like. Some > of us just > went through 6 months of this discussion to reach consensus on the > SIPConnect with TLS support since it was the obvious choice. > > TLS support IS mandated in 3261 so IMHO get with the program. > > I've yet to see real concrete data on why its such a problem > to implement or > support in high volume SIP transaction systems. Lots of http > based Ecommerce > seems to rely on per transaction secure connections so I just > don't get what > the problem is here. > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Wednesday, June 28, 2006 3:06 PM > > To: richard@shockey.us > > Cc: 'Khan, Sohel Q [CTO]'; 'Daryl Malas'; 'Uzelac, Adam'; > > speermint@ietf.org > > Subject: Re: TLS for peering (was RE: Comments > > (RE:[speermint]requirementsdraft submitted)) > > > > > > 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 From speermint-bounces@ietf.org Wed Jun 28 16:17:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvgTM-0003Sk-RH; Wed, 28 Jun 2006 16:17:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvgTL-0003SY-ND for speermint@ietf.org; Wed, 28 Jun 2006 16:17:15 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvgTJ-0007Bm-Bq for speermint@ietf.org; Wed, 28 Jun 2006 16:17:15 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 28 Jun 2006 13:17:12 -0700 X-IronPort-AV: i="4.06,189,1149490800"; d="scan'208"; a="563645195:sNHT32816272" 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]requirementsdraft submitted)) Date: Wed, 28 Jun 2006 16:17:10 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804B9E183@proton.jnpr.net> In-Reply-To: <00ff01c69aea$c7214930$4d201f0a@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Thread-Index: Acaa5fZ5NGhsPsuiTz6yKQm/EKnphAAAhV8gAAGawNA= From: "Reinaldo Penno" To: , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 Hello Richard, I guess you put the answer in the email itself. Adam and others talked about cost vs. benefit.=20 Speaking out of experience, these 'e-commerce' sites you mention have stacks and stacks of SSL accelerators and/or offpath SSL decryption engines. It definitely increases the equipment cost, management, real state and operation of the solution. Also, if you have looked long enough on RFCs, many, many things that are mandated never see the light of the day because they lack consensus, are complex, never factored service provider's opinion, etc, etc.=20 Layer 3 peering has been going on for decades without IPsec.=20 I believe we are not saying TLS is evil. We are saying 'MUST' is not the right word.=20 Regards, Reinaldo > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Wednesday, June 28, 2006 12:41 PM > To: 'Andrew Newton' > Cc: speermint@ietf.org; 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam' > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraft submitted)) >=20 >=20 >=20 > Well the one thing we all seem to agree on is that without some trust > relationship between interconnecting partners at their domain boundaries > this whole exercise is a vast waste of time and electrons. >=20 > Now then I think Keith has a point. >=20 > "If the former, then by all means specify TLS. If the latter, then it > should > probably identify that security solutions are required, and then make sure > that sufficient guidance is given on the mechanisms currently available, > including TLS, but probably also addressing IPsec." >=20 > Required ..I's say security solutions are mandated as in MUST. >=20 > There _are_ certainly more than one mechanism, besides TLS that can be > used > to establish security & trust at the boundaries. So ..those techniques > MUST > be deliberately specified along with the risks associated with them. >=20 > That said there are many of us that are getting very very tired of the > constant whining about this or that aspect of 3261 that for one reason or > another some developer or service provider doesn't like. Some of us just > went through 6 months of this discussion to reach consensus on the > SIPConnect with TLS support since it was the obvious choice. >=20 > TLS support IS mandated in 3261 so IMHO get with the program. >=20 > I've yet to see real concrete data on why its such a problem to implement > or > support in high volume SIP transaction systems. Lots of http based > Ecommerce > seems to rely on per transaction secure connections so I just don't get > what > the problem is here. >=20 > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Wednesday, June 28, 2006 3:06 PM > > To: richard@shockey.us > > Cc: 'Khan, Sohel Q [CTO]'; 'Daryl Malas'; 'Uzelac, Adam'; > > speermint@ietf.org > > Subject: Re: TLS for peering (was RE: Comments > > (RE:[speermint]requirementsdraft submitted)) > > > > > > 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 >=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 Jun 28 17:24:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvhWi-0002DM-SL; Wed, 28 Jun 2006 17:24:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvhWi-0002DH-74 for speermint@ietf.org; Wed, 28 Jun 2006 17:24:48 -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 1FvhWg-0007oD-PO for speermint@ietf.org; Wed, 28 Jun 2006 17:24:48 -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 k5SLOhaK017368; Wed, 28 Jun 2006 21:24:44 GMT Subject: RE: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) From: Daryl Malas To: richard@shockey.us In-Reply-To: <008801c69ae0$b804c530$4d201f0a@cis.neustar.com> References: <008801c69ae0$b804c530$4d201f0a@cis.neustar.com> Content-Type: text/plain Date: Wed, 28 Jun 2006 15:24:03 -0600 Message-Id: <1151529844.10104.14.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: 7e439b86d3292ef5adf93b694a43a576 Cc: speermint@ietf.org, "'Khan, Sohel Q \[CTO\]'" , "'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 simply said REQUIRING it would be unrealistic...I didn't say including it as an optional method is unrealistic. There are multiple ways to authenticate peers as described in Penno's message flows draft. On Wed, 2006-06-28 at 14:28 -0400, Richard Shockey wrote: > > TLS is a core part of the SIP specification. Saying its not realistic is > just plain bovine effluent. > > You are not going to interconnect at the most basic level unless there is a > level of trust between the domains. So how do you plan on authenticating the > domain? > > This was the absolute conclusion of the SIP Forum when we came up with the > SIP Connect specification for PBX to SP interconnection. > > SP to SP interconnection is not that much different. > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_Interop- > sibley-final.pdf > > > > > -----Original Message----- > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Sent: Wednesday, June 28, 2006 12:06 PM > > To: Daryl Malas; Uzelac, Adam > > Cc: speermint@ietf.org > > Subject: RE: TLS for peering (was RE: Comments > > (RE:[speermint]requirementsdraft submitted)) > > > > So, what do u recommended ? > > Keep TLS optional? > > Any other method? > > > > Sohel > > > > > > -----Original Message----- > > From: "Daryl Malas" > > To: "Uzelac, Adam" > > Cc: "speermint@ietf.org" > > Sent: 6/28/06 10:29 AM > > Subject: RE: TLS for peering (was RE: Comments (RE: > > [speermint]requirementsdraft submitted)) > > > > I agree with Adam's assessment. Requiring TLS is simply not realistic > > at this point. I believe it has the potential of becoming a more common > > practice in the future, but not right now. > > > > --Daryl > > > > On Tue, 2006-06-27 at 21:47 -0400, Uzelac, Adam wrote: > > > TLS is becoming more and more a subject when the topic of SIP > > > interconnections arises for me professionally. This shows growing > > > momentum indeed. With that said, I can not agree with TLS as a > > > steadfast requirement. Economics and scale are my major concerns. TLS > > > adds cost, server load, and there are fail-over issues to consider as > > > well. For the person that designs an interconnect, I believe weighing > > > the cost against the benefit of the different models a useful exercise. > > > Mandating TLS, even if all parties involved in a peering arrangement > > > feel somehow "safe and secure" due to underlying security mechanisms > > > (L2/L3VPNs, etc), seems a little harsh. > > > > > > Adam > > > > > > -----Original Message----- > > > From: Medhavi Bhatia [mailto:mbhatia@3clogic.com] > > > Sent: Tuesday, June 27, 2006 8:44 PM > > > To: Reinaldo Penno > > > Cc: speermint@ietf.org > > > Subject: Re: TLS for peering (was RE: Comments (RE: [speermint] > > > requirementsdraft submitted)) > > > > > > I am not a provider yet, but I think we dont need to mess with TLS/TCP. > > > As I understand one of the goals is to prevent the calls from failing > > > due to "peering only" reasons. This means that things like codecs which > > > are not negotiated by the peers need to be mandated at a minimal level. > > > TCP/TLS can be negotiated between the peers themselves so it is a > > > non-issue. Also as I still understand doing a high volume calls with TLS > > > is still expensive. Mandating TLS in cases where the caller or callee > > > dont require it doesnt seem to add any value. > > > > > > -Medhavi. > > > > > > On 6/27/06, Reinaldo Penno wrote: > > > > > > > > TLS for _all_ scenarios? Even in private peerings, physically secure > > > > peerings, etc? > > > > > > > > Isn't that the same as requiring IPsec for all layer 3 peering? But > > > > since Layer 5 peering might be more distributed, the number of TLS > > > > sessions would be huge. > > > > > > > > It would be good to hear the provider's opinion on this... > > > > > > > > Thanks, > > > > > > > > Reinaldo > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Tuesday, June 27, 2006 2:12 PM > > > > > To: 'Jean-Francois Mule'; Reinaldo Penno > > > > > Cc: speermint@ietf.org > > > > > Subject: RE: Comments (RE: [speermint] requirements draft submitted) > > > > > > > > > > > > > > > > > "3.4. Security requirements > > > > > > > > > > > > All SIP messages MUST be sent over TLS [RFC3546] to provide > > > > > > transport-layer security as defined in RFC 3261," > > > > > > > > > > > > Giving the fact that we can have security through physical > > > > > segregation, > > > > > > intra-federation/provider calls, etc, the "MUST" here seems too > > > > > > generic. > > > > > > > > > > I tend to differ on this: it is not because you have lower layer > > > > > security (presumably hop by hop security associations) that you > > > > > should relax the end-to-end transport security requirements. > > > > > Rohan's well written draft is also in favor of mandatory support of > > > > TLS, > > > > > and so is the SIP Forum's IP PBX to VSP (here is a working link: > > > > > > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_In > > > > te > > > > > rop-sibley-final.pdf). > > > > > May be the requirement should be rewritten to put the MUST on SIP > > > > > entities involved in L5 peering. > > > > > > > > > > I'm in favor of requiring TLS. I'd say MUST in a heartbeat. > > > > > > > > > > Brian > > > > > > > > _______________________________________________ > > > > 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 Wed Jun 28 17:38:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvhjc-0005VD-BX; Wed, 28 Jun 2006 17:38:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvhjb-0005Uw-C6 for speermint@ietf.org; Wed, 28 Jun 2006 17:38:07 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvhjZ-0001Mn-Pg for speermint@ietf.org; Wed, 28 Jun 2006 17:38:07 -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 k5SLa9xB017164; Wed, 28 Jun 2006 14:36:09 -0700 From: "Richard Shockey" To: "'Reinaldo Penno'" , "'Andrew Newton'" Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Date: Wed, 28 Jun 2006 17:35:31 -0400 Message-ID: <024e01c69afa$c89c3620$4d201f0a@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: Acaa5fZ5NGhsPsuiTz6yKQm/EKnphAAAhV8gAAGawNAAAgi1IA== In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804B9E183@proton.jnpr.net> 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: 225414c974e0d6437992164e91287a51 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: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Wednesday, June 28, 2006 4:17 PM > To: richard@shockey.us; Andrew Newton > Cc: speermint@ietf.org; Khan, Sohel Q [CTO]; Uzelac, Adam > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraft submitted)) > > Hello Richard, > > I guess you put the answer in the email itself. Adam and others talked > about cost vs. benefit. > > Speaking out of experience, these 'e-commerce' sites you mention have > stacks and stacks of SSL accelerators and/or offpath SSL decryption > engines. It definitely increases the equipment cost, management, real > state and operation of the solution. Like duh? So what? There is real money involved here. Are you saying in inter carrier SIP communications, transaction security, fraud avoidance and UA identity management/control across domain boundaries are not worth the security cost? Voice communications alone is a 300 Billion US business world wide? What's a few CPU cycles compared to that. > Also, if you have looked long enough on RFCs, many, many things that are > mandated never see the light of the day because they lack consensus, are > complex, never factored service provider's opinion, etc, etc. Been there done that. You could say that for about 60% of the Security Area RFC's, IPv6, DNSSEC, IDN, PKI, Public ENUM in e164.arpa, etal > > Layer 3 peering has been going on for decades without IPsec. Yes but that has been for best efforts IP traffic. The entire premise of speermint at its core is the supposition that though all bits are created equal on the Internet it seems that some SIP bits are more equal than others. If you don't believe that, this WG has no reason for existence. Since some traffic between SIP interconnection partners ( notice I never say peering ) may involve PSTN termination charges or use bandwidth in high volume priority access mode, there must be a reasonable level of trust between interconnecting partners. There has to be the capability of the terminating service provider trusting the first who the originating provider is and second trusting the calling party identity provided to them for billing purposes if nothing else. Therefore the security methodology mandated is critical. > > I believe we are not saying TLS is evil. We are saying 'MUST' is not the > right word. Well again 3261 said MUST for a very very good reason. I would still require MUST support TLS in any SPEERMENT standard or BCP. However I accept that other trust/security methodologies can work but they had better be well documented along with the possible security threats associated with each proposed method. > > Regards, > > Reinaldo > > > > -----Original Message----- > > From: Richard Shockey [mailto:richard@shockey.us] > > Sent: Wednesday, June 28, 2006 12:41 PM > > To: 'Andrew Newton' > > Cc: speermint@ietf.org; 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam' > > Subject: RE: TLS for peering (was RE: > > Comments(RE:[speermint]requirementsdraft submitted)) > > > > > > > > Well the one thing we all seem to agree on is that without some trust > > relationship between interconnecting partners at their domain > boundaries > > this whole exercise is a vast waste of time and electrons. > > > > Now then I think Keith has a point. > > > > "If the former, then by all means specify TLS. If the latter, then it > > should > > probably identify that security solutions are required, and then make > sure > > that sufficient guidance is given on the mechanisms currently > available, > > including TLS, but probably also addressing IPsec." > > > > Required ..I's say security solutions are mandated as in MUST. > > > > There _are_ certainly more than one mechanism, besides TLS that can be > > used > > to establish security & trust at the boundaries. So ..those techniques > > MUST > > be deliberately specified along with the risks associated with them. > > > > That said there are many of us that are getting very very tired of the > > constant whining about this or that aspect of 3261 that for one reason > or > > another some developer or service provider doesn't like. Some of us > just > > went through 6 months of this discussion to reach consensus on the > > SIPConnect with TLS support since it was the obvious choice. > > > > TLS support IS mandated in 3261 so IMHO get with the program. > > > > I've yet to see real concrete data on why its such a problem to > implement > > or > > support in high volume SIP transaction systems. Lots of http based > > Ecommerce > > seems to rely on per transaction secure connections so I just don't > get > > what > > the problem is here. > > > > > -----Original Message----- > > > From: Andrew Newton [mailto:andy@hxr.us] > > > Sent: Wednesday, June 28, 2006 3:06 PM > > > To: richard@shockey.us > > > Cc: 'Khan, Sohel Q [CTO]'; 'Daryl Malas'; 'Uzelac, Adam'; > > > speermint@ietf.org > > > Subject: Re: TLS for peering (was RE: Comments > > > (RE:[speermint]requirementsdraft submitted)) > > > > > > > > > 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 From speermint-bounces@ietf.org Wed Jun 28 18:02:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvi72-0000bR-T9; Wed, 28 Jun 2006 18:02:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvi71-0000Wc-D1 for speermint@ietf.org; Wed, 28 Jun 2006 18:02:19 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvi6V-0003Yn-Uh for speermint@ietf.org; Wed, 28 Jun 2006 18:01:48 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 28 Jun 2006 15:01:47 -0700 X-IronPort-AV: i="4.06,189,1149490800"; d="scan'208"; a="558663237:sNHT37575316" 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]requirementsdraft submitted)) Date: Wed, 28 Jun 2006 18:01:45 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804B9E1D5@proton.jnpr.net> In-Reply-To: <024e01c69afa$c89c3620$4d201f0a@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Thread-Index: Acaa5fZ5NGhsPsuiTz6yKQm/EKnphAAAhV8gAAGawNAAAgi1IAABbr3Q From: "Reinaldo Penno" To: , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 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 Richard, If you are so confident that TLS will become the standard for peering, there is nothing to fear, just say that it should be used in the absence of other methods.=20 If your prediction is correct, providers will actually require and use it, vendors will implement TLS, and it will become ubiquitous. =20 Shoving down the throats of people an operational requirement that will increase the cost of a deployment is not the way to go. IETF is about running code and consensus. More comments inline... > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Wednesday, June 28, 2006 2:36 PM > To: Reinaldo Penno; 'Andrew Newton' > Cc: speermint@ietf.org; 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam' > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraft submitted)) >=20 >=20 >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Wednesday, June 28, 2006 4:17 PM > > To: richard@shockey.us; Andrew Newton > > Cc: speermint@ietf.org; Khan, Sohel Q [CTO]; Uzelac, Adam > > Subject: RE: TLS for peering (was RE: > > Comments(RE:[speermint]requirementsdraft submitted)) > > > > Hello Richard, > > > > I guess you put the answer in the email itself. Adam and others talked > > about cost vs. benefit. > > > > Speaking out of experience, these 'e-commerce' sites you mention have > > stacks and stacks of SSL accelerators and/or offpath SSL decryption > > engines. It definitely increases the equipment cost, management, real > > state and operation of the solution. >=20 > Like duh? So what? >=20 [[Reinaldo]]=20 I'm sorry, but you first argument was quite simple and my answer was pointing out that e-commerce sites use special hardware.=20 > There is real money involved here. Are you saying in inter carrier SIP > communications, transaction security, fraud avoidance and UA identity > management/control across domain boundaries are not worth the security > cost? It is not for you and me to decide. We should provide the necessary alternatives and the market will lean one way or another.=20 >=20 > Voice communications alone is a 300 Billion US business world wide? What's > a > few CPU cycles compared to that. >=20 >=20 > > Also, if you have looked long enough on RFCs, many, many things that are > > mandated never see the light of the day because they lack consensus, are > > complex, never factored service provider's opinion, etc, etc. >=20 > Been there done that. You could say that for about 60% of the Security > Area > RFC's, IPv6, DNSSEC, IDN, PKI, Public ENUM in e164.arpa, etal >=20 > > > > Layer 3 peering has been going on for decades without IPsec. >=20 >=20 > Yes but that has been for best efforts IP traffic. >=20 > The entire premise of speermint at its core is the supposition that though > all bits are created equal on the Internet it seems that some SIP bits are > more equal than others. >=20 > If you don't believe that, this WG has no reason for existence. >=20 [[Reinaldo]]=20 That's a logical fallacy. In the end SIP is just a protocol like HTTP, DNS and others that run over IP. And what _actually_ needs strict QoS is _media_ and not SIP signaling.=20 Are you going to suggest secure RTP as well between every single call on the planet?=20 > Since some traffic between SIP interconnection partners ( notice I never > say > peering ) may involve PSTN termination charges or use bandwidth in high > volume priority access mode, there must be a reasonable level of trust > between interconnecting partners. There has to be the capability of the > terminating service provider trusting the first who the originating > provider > is and second trusting the calling party identity provided to them for > billing purposes if nothing else. Therefore the security methodology > mandated is critical. >=20 >=20 > > > > I believe we are not saying TLS is evil. We are saying 'MUST' is not the > > right word. >=20 > Well again 3261 said MUST for a very very good reason. I would still > require > MUST support TLS in any SPEERMENT standard or BCP. However I accept that > other trust/security methodologies can work but they had better be well > documented along with the possible security threats associated with each > proposed method. >=20 > > > > Regards, > > > > Reinaldo > > > > > > > -----Original Message----- > > > From: Richard Shockey [mailto:richard@shockey.us] > > > Sent: Wednesday, June 28, 2006 12:41 PM > > > To: 'Andrew Newton' > > > Cc: speermint@ietf.org; 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam' > > > Subject: RE: TLS for peering (was RE: > > > Comments(RE:[speermint]requirementsdraft submitted)) > > > > > > > > > > > > Well the one thing we all seem to agree on is that without some trust > > > relationship between interconnecting partners at their domain > > boundaries > > > this whole exercise is a vast waste of time and electrons. > > > > > > Now then I think Keith has a point. > > > > > > "If the former, then by all means specify TLS. If the latter, then it > > > should > > > probably identify that security solutions are required, and then make > > sure > > > that sufficient guidance is given on the mechanisms currently > > available, > > > including TLS, but probably also addressing IPsec." > > > > > > Required ..I's say security solutions are mandated as in MUST. > > > > > > There _are_ certainly more than one mechanism, besides TLS that can be > > > used > > > to establish security & trust at the boundaries. So ..those techniques > > > MUST > > > be deliberately specified along with the risks associated with them. > > > > > > That said there are many of us that are getting very very tired of the > > > constant whining about this or that aspect of 3261 that for one reason > > or > > > another some developer or service provider doesn't like. Some of us > > just > > > went through 6 months of this discussion to reach consensus on the > > > SIPConnect with TLS support since it was the obvious choice. > > > > > > TLS support IS mandated in 3261 so IMHO get with the program. > > > > > > I've yet to see real concrete data on why its such a problem to > > implement > > > or > > > support in high volume SIP transaction systems. Lots of http based > > > Ecommerce > > > seems to rely on per transaction secure connections so I just don't > > get > > > what > > > the problem is here. > > > > > > > -----Original Message----- > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > Sent: Wednesday, June 28, 2006 3:06 PM > > > > To: richard@shockey.us > > > > Cc: 'Khan, Sohel Q [CTO]'; 'Daryl Malas'; 'Uzelac, Adam'; > > > > speermint@ietf.org > > > > Subject: Re: TLS for peering (was RE: Comments > > > > (RE:[speermint]requirementsdraft submitted)) > > > > > > > > > > > > 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 From speermint-bounces@ietf.org Wed Jun 28 18:02:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvi73-0000co-6v; Wed, 28 Jun 2006 18:02:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvi71-0000Wc-Jc for speermint@ietf.org; Wed, 28 Jun 2006 18:02: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 1Fvi4w-0003XY-6T for speermint@ietf.org; Wed, 28 Jun 2006 18:00: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 DC41F3B62; Wed, 28 Jun 2006 18:00:09 -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, 28 Jun 2006 18:00:09 -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: Wed, 28 Jun 2006 18:00:02 -0400 Message-ID: In-Reply-To: <025801c69afc$ab7b04c0$4d201f0a@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Thread-Index: Acaa+VnBRcdEnLXWRMiY93iCtTwjCgAAXlTQAACsaSA= From: "Uzelac, Adam" To: , "Daryl Malas" X-OriginalArrivalTime: 28 Jun 2006 22:00:09.0826 (UTC) FILETIME=[392D0420:01C69AFE] X-Spam-Score: 0.1 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: "Khan, Sohel Q \[CTO\]" , 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 agree with Richard's wording below.=20 "...any proposed BCP in SPEERMINT for intercarrier interconnection using SIP MUST support a trust/security model....you MUST support TLS as one of the supported models." =20 I also believe that a trust/security model must be in place, and I have written as much in this forum. =20 Adam -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: Wednesday, June 28, 2006 5:49 PM To: 'Daryl Malas' Cc: 'Khan, Sohel Q [CTO]'; Uzelac, Adam; speermint@ietf.org Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Wednesday, June 28, 2006 5:24 PM > To: richard@shockey.us > Cc: 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam'; speermint@ietf.org > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraft submitted)) >=20 > ...I simply said REQUIRING it would be unrealistic...I didn't say=20 > including it as an optional method is unrealistic. There are multiple > ways to authenticate peers as described in Penno's message flows draft. Ah .. you are heading into a semantic trap here.=20 My position is any proposed BCP in SPEERMINT for intercarrier interconnection ( did I say peering here :-) using SIP MUST support a trust/security model. I'm not saying you should be REQUIRED to use TLS at all times but only that you MUST support TLS as one of the supported models. It is my opinion based on many years of personal experience in the IETF that you that you will not get anything through the IESG to an RFC unless something like the above position is incorporated into the drafts. >=20 > On Wed, 2006-06-28 at 14:28 -0400, Richard Shockey wrote: > > > > TLS is a core part of the SIP specification. Saying its not=20 > > realistic is just plain bovine effluent. > > > > You are not going to interconnect at the most basic level unless=20 > > there > is a > > level of trust between the domains. So how do you plan on=20 > > authenticating > the > > domain? > > > > This was the absolute conclusion of the SIP Forum when we came up=20 > > with > the > > SIP Connect specification for PBX to SP interconnection. > > > > SP to SP interconnection is not that much different. > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg- > IP_PBX_SP_Interop- > > sibley-final.pdf > > > > > > > > > -----Original Message----- > > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > > Sent: Wednesday, June 28, 2006 12:06 PM > > > To: Daryl Malas; Uzelac, Adam > > > Cc: speermint@ietf.org > > > Subject: RE: TLS for peering (was RE: Comments=20 > > > (RE:[speermint]requirementsdraft submitted)) > > > > > > So, what do u recommended ? > > > Keep TLS optional? > > > Any other method? > > > > > > Sohel > > > > > > > > > -----Original Message----- > > > From: "Daryl Malas" > > > To: "Uzelac, Adam" > > > Cc: "speermint@ietf.org" > > > Sent: 6/28/06 10:29 AM > > > Subject: RE: TLS for peering (was RE: Comments (RE: > > > [speermint]requirementsdraft submitted)) > > > > > > I agree with Adam's assessment. Requiring TLS is simply not=20 > > > realistic at this point. I believe it has the potential of=20 > > > becoming a more > common > > > practice in the future, but not right now. > > > > > > --Daryl > > > > > > On Tue, 2006-06-27 at 21:47 -0400, Uzelac, Adam wrote: > > > > TLS is becoming more and more a subject when the topic of SIP=20 > > > > interconnections arises for me professionally. This shows=20 > > > > growing momentum indeed. With that said, I can not agree with=20 > > > > TLS as a steadfast requirement. Economics and scale are my major concerns. > TLS > > > > adds cost, server load, and there are fail-over issues to=20 > > > > consider > as > > > > well. For the person that designs an interconnect, I believe > weighing > > > > the cost against the benefit of the different models a useful > exercise. > > > > Mandating TLS, even if all parties involved in a peering=20 > > > > arrangement feel somehow "safe and secure" due to underlying=20 > > > > security mechanisms (L2/L3VPNs, etc), seems a little harsh. > > > > > > > > Adam > > > > > > > > -----Original Message----- > > > > From: Medhavi Bhatia [mailto:mbhatia@3clogic.com] > > > > Sent: Tuesday, June 27, 2006 8:44 PM > > > > To: Reinaldo Penno > > > > Cc: speermint@ietf.org > > > > Subject: Re: TLS for peering (was RE: Comments (RE: [speermint]=20 > > > > requirementsdraft submitted)) > > > > > > > > I am not a provider yet, but I think we dont need to mess with > TLS/TCP. > > > > As I understand one of the goals is to prevent the calls from > failing > > > > due to "peering only" reasons. This means that things like=20 > > > > codecs > which > > > > are not negotiated by the peers need to be mandated at a minimal > level. > > > > TCP/TLS can be negotiated between the peers themselves so it is=20 > > > > a non-issue. Also as I still understand doing a high volume=20 > > > > calls with > TLS > > > > is still expensive. Mandating TLS in cases where the caller or > callee > > > > dont require it doesnt seem to add any value. > > > > > > > > -Medhavi. > > > > > > > > On 6/27/06, Reinaldo Penno wrote: > > > > > > > > > > TLS for _all_ scenarios? Even in private peerings, physically > secure > > > > > peerings, etc? > > > > > > > > > > Isn't that the same as requiring IPsec for all layer 3 peering? > But > > > > > since Layer 5 peering might be more distributed, the number of > > > > > TLS sessions would be huge. > > > > > > > > > > It would be good to hear the provider's opinion on this... > > > > > > > > > > Thanks, > > > > > > > > > > Reinaldo > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Tuesday, June 27, 2006 2:12 PM > > > > > > To: 'Jean-Francois Mule'; Reinaldo Penno > > > > > > Cc: speermint@ietf.org > > > > > > Subject: RE: Comments (RE: [speermint] requirements draft > submitted) > > > > > > > > > > > > > > > > > > > > "3.4. Security requirements > > > > > > > > > > > > > > All SIP messages MUST be sent over TLS [RFC3546] to provide > > > > > > > transport-layer security as defined in RFC 3261," > > > > > > > > > > > > > > Giving the fact that we can have security through physical > > > > > > segregation, > > > > > > > intra-federation/provider calls, etc, the "MUST" here=20 > > > > > > > seems > too > > > > > > > generic. > > > > > > > > > > > > I tend to differ on this: it is not because you have lower=20 > > > > > > layer security (presumably hop by hop security associations) > > > > > > that you should relax the end-to-end transport security requirements. > > > > > > Rohan's well written draft is also in favor of mandatory=20 > > > > > > support > of > > > > > TLS, > > > > > > and so is the SIP Forum's IP PBX to VSP (here is a working link: > > > > > > > > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg- > IP_PBX_SP_In > > > > > te > > > > > > rop-sibley-final.pdf). > > > > > > May be the requirement should be rewritten to put the MUST=20 > > > > > > on > SIP > > > > > > entities involved in L5 peering. > > > > > > > > > > > > I'm in favor of requiring TLS. I'd say MUST in a > heartbeat. > > > > > > > > > > > > Brian > > > > > > > > > > _______________________________________________ > > > > > 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 Wed Jun 28 18:02:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvi72-0000Zk-Hq; Wed, 28 Jun 2006 18:02:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvi71-0000Wc-Ah for speermint@ietf.org; Wed, 28 Jun 2006 18:02:19 -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 1Fvi6e-0003Z0-C5 for speermint@ietf.org; Wed, 28 Jun 2006 18:01:57 -0400 Received: from [10.1.126.102] ([::ffff:72.158.100.2]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 28 Jun 2006 18:02:10 -0400 id 015880BD.44A2FC63.00003775 In-Reply-To: <024e01c69afa$c89c3620$4d201f0a@cis.neustar.com> References: <024e01c69afa$c89c3620$4d201f0a@cis.neustar.com> Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Date: Wed, 28 Jun 2006 18:01:42 -0400 To: richard@shockey.us X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) 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: , Content-Type: multipart/mixed; boundary="===============1245679726==" Errors-To: speermint-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1245679726== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-14202-1151532136-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-14202-1151532136-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jun 28, 2006, at 5:35 PM, Richard Shockey wrote: > Like duh? So what? > > There is real money involved here. There's real money involved in many aspects of Internet operations. Life would certainly be better if the gTLD providers did the right thing by offering secure protocols too, but you don't see them stampeding to do so. The other thing I don't like about the magical TLS pixie dust is that it does not take into account the fact that there is no root trust anchor. Some CAs will sell anybody a cert for $25, some give them away for FREE. What's the point of all that additional TLS infrastructure if it can be easily circumvented by a trust path that leads back to a money order purchased at a gas station. -andy --=_zeke.ecotroph.net-14202-1151532136-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.0
On Jun 28, 2006, at 5:3= 5 PM, Richard Shockey wrote:

<= FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">Like = duh? So what?


There is real money involved here.=A0


There'= s real money involved in many aspects of Internet operations.=A0 Life wou= ld certainly be better if the gTLD providers did the right thing by offer= ing secure protocols too, but you don't see them stampeding to do so.

The other thing I= don't like about the magical TLS pixie dust is that it does not take int= o account the fact that there is no root trust anchor.=A0 Some CAs will s= ell anybody a cert for $25, some give them away for FREE.=A0 What's the p= oint of all that additional TLS infrastructure if it can be easily circum= vented by a trust path that leads back to a money order purchased at a ga= s station.

-an= dy
--=_zeke.ecotroph.net-14202-1151532136-0001-2-- --===============1245679726== 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 --===============1245679726==-- From speermint-bounces@ietf.org Wed Jun 28 18:02:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvi7T-0001kj-TD; Wed, 28 Jun 2006 18:02:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvi78-0000nx-DZ for speermint@ietf.org; Wed, 28 Jun 2006 18:02:26 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvhwG-0003I8-UR for speermint@ietf.org; Wed, 28 Jun 2006 17:51:14 -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 k5SLnWLL025511; Wed, 28 Jun 2006 14:49:32 -0700 From: "Richard Shockey" To: "'Daryl Malas'" Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Date: Wed, 28 Jun 2006 17:49:01 -0400 Message-ID: <025801c69afc$ab7b04c0$4d201f0a@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: Acaa+VnBRcdEnLXWRMiY93iCtTwjCgAAXlTQ In-Reply-To: <1151529844.10104.14.camel@montag.eng.level3.com> 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: d9238570526f12788af3d33c67f37625 Cc: speermint@ietf.org, "'Khan, Sohel Q \[CTO\]'" , "'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: Daryl Malas [mailto:daryl@level3.net] > Sent: Wednesday, June 28, 2006 5:24 PM > To: richard@shockey.us > Cc: 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam'; speermint@ietf.org > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraft submitted)) > > ...I simply said REQUIRING it would be unrealistic...I didn't say > including it as an optional method is unrealistic. There are multiple > ways to authenticate peers as described in Penno's message flows draft. Ah .. you are heading into a semantic trap here. My position is any proposed BCP in SPEERMINT for intercarrier interconnection ( did I say peering here :-) using SIP MUST support a trust/security model. I'm not saying you should be REQUIRED to use TLS at all times but only that you MUST support TLS as one of the supported models. It is my opinion based on many years of personal experience in the IETF that you that you will not get anything through the IESG to an RFC unless something like the above position is incorporated into the drafts. > > On Wed, 2006-06-28 at 14:28 -0400, Richard Shockey wrote: > > > > TLS is a core part of the SIP specification. Saying its not realistic is > > just plain bovine effluent. > > > > You are not going to interconnect at the most basic level unless there > is a > > level of trust between the domains. So how do you plan on authenticating > the > > domain? > > > > This was the absolute conclusion of the SIP Forum when we came up with > the > > SIP Connect specification for PBX to SP interconnection. > > > > SP to SP interconnection is not that much different. > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg- > IP_PBX_SP_Interop- > > sibley-final.pdf > > > > > > > > > -----Original Message----- > > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > > Sent: Wednesday, June 28, 2006 12:06 PM > > > To: Daryl Malas; Uzelac, Adam > > > Cc: speermint@ietf.org > > > Subject: RE: TLS for peering (was RE: Comments > > > (RE:[speermint]requirementsdraft submitted)) > > > > > > So, what do u recommended ? > > > Keep TLS optional? > > > Any other method? > > > > > > Sohel > > > > > > > > > -----Original Message----- > > > From: "Daryl Malas" > > > To: "Uzelac, Adam" > > > Cc: "speermint@ietf.org" > > > Sent: 6/28/06 10:29 AM > > > Subject: RE: TLS for peering (was RE: Comments (RE: > > > [speermint]requirementsdraft submitted)) > > > > > > I agree with Adam's assessment. Requiring TLS is simply not realistic > > > at this point. I believe it has the potential of becoming a more > common > > > practice in the future, but not right now. > > > > > > --Daryl > > > > > > On Tue, 2006-06-27 at 21:47 -0400, Uzelac, Adam wrote: > > > > TLS is becoming more and more a subject when the topic of SIP > > > > interconnections arises for me professionally. This shows growing > > > > momentum indeed. With that said, I can not agree with TLS as a > > > > steadfast requirement. Economics and scale are my major concerns. > TLS > > > > adds cost, server load, and there are fail-over issues to consider > as > > > > well. For the person that designs an interconnect, I believe > weighing > > > > the cost against the benefit of the different models a useful > exercise. > > > > Mandating TLS, even if all parties involved in a peering arrangement > > > > feel somehow "safe and secure" due to underlying security mechanisms > > > > (L2/L3VPNs, etc), seems a little harsh. > > > > > > > > Adam > > > > > > > > -----Original Message----- > > > > From: Medhavi Bhatia [mailto:mbhatia@3clogic.com] > > > > Sent: Tuesday, June 27, 2006 8:44 PM > > > > To: Reinaldo Penno > > > > Cc: speermint@ietf.org > > > > Subject: Re: TLS for peering (was RE: Comments (RE: [speermint] > > > > requirementsdraft submitted)) > > > > > > > > I am not a provider yet, but I think we dont need to mess with > TLS/TCP. > > > > As I understand one of the goals is to prevent the calls from > failing > > > > due to "peering only" reasons. This means that things like codecs > which > > > > are not negotiated by the peers need to be mandated at a minimal > level. > > > > TCP/TLS can be negotiated between the peers themselves so it is a > > > > non-issue. Also as I still understand doing a high volume calls with > TLS > > > > is still expensive. Mandating TLS in cases where the caller or > callee > > > > dont require it doesnt seem to add any value. > > > > > > > > -Medhavi. > > > > > > > > On 6/27/06, Reinaldo Penno wrote: > > > > > > > > > > TLS for _all_ scenarios? Even in private peerings, physically > secure > > > > > peerings, etc? > > > > > > > > > > Isn't that the same as requiring IPsec for all layer 3 peering? > But > > > > > since Layer 5 peering might be more distributed, the number of TLS > > > > > sessions would be huge. > > > > > > > > > > It would be good to hear the provider's opinion on this... > > > > > > > > > > Thanks, > > > > > > > > > > Reinaldo > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Tuesday, June 27, 2006 2:12 PM > > > > > > To: 'Jean-Francois Mule'; Reinaldo Penno > > > > > > Cc: speermint@ietf.org > > > > > > Subject: RE: Comments (RE: [speermint] requirements draft > submitted) > > > > > > > > > > > > > > > > > > > > "3.4. Security requirements > > > > > > > > > > > > > > All SIP messages MUST be sent over TLS [RFC3546] to provide > > > > > > > transport-layer security as defined in RFC 3261," > > > > > > > > > > > > > > Giving the fact that we can have security through physical > > > > > > segregation, > > > > > > > intra-federation/provider calls, etc, the "MUST" here seems > too > > > > > > > generic. > > > > > > > > > > > > I tend to differ on this: it is not because you have lower layer > > > > > > security (presumably hop by hop security associations) that you > > > > > > should relax the end-to-end transport security requirements. > > > > > > Rohan's well written draft is also in favor of mandatory support > of > > > > > TLS, > > > > > > and so is the SIP Forum's IP PBX to VSP (here is a working link: > > > > > > > > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg- > IP_PBX_SP_In > > > > > te > > > > > > rop-sibley-final.pdf). > > > > > > May be the requirement should be rewritten to put the MUST on > SIP > > > > > > entities involved in L5 peering. > > > > > > > > > > > > I'm in favor of requiring TLS. I'd say MUST in a > heartbeat. > > > > > > > > > > > > Brian > > > > > > > > > > _______________________________________________ > > > > > 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 Wed Jun 28 18:19:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FviNF-0001Y1-Q5; Wed, 28 Jun 2006 18:19:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FviNE-0001Xw-HV for speermint@ietf.org; Wed, 28 Jun 2006 18:19:04 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FviNE-0004Dn-3M for speermint@ietf.org; Wed, 28 Jun 2006 18:19:04 -0400 Received: from ([10.20.62.13]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.21813429; Wed, 28 Jun 2006 18:18:48 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 18:18: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: note: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Date: Wed, 28 Jun 2006 18:18:33 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96CAF2D3@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: note: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Thread-Index: Acaa+VnBRcdEnLXWRMiY93iCtTwjCgAAXlTQAAE/CXA= From: "Livingood, Jason" To: , "Daryl Malas" X-OriginalArrivalTime: 28 Jun 2006 22:18:48.0203 (UTC) FILETIME=[D3C7CDB0:01C69B00] X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 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 Thanks everyone for coming to the fair today. Please step away from your keyboards and go home for the evening and have a nice, cold beer. :-) I'm in Belgium at the moment, so there's no shortage of that. Let's resume again tomorrow and reduce the tone just a few notches please. There are valid points on **both** sides of the issue that can be discussed on the list and, perhaps best in person in Montreal. Both sides ought to duly consider the dispassionate arguements. We will need to keep in mind that for now, we are focusing on the bare minimum set of requirements to get VoIP peering working (as a first use case). There will surely be issues that come up, perhaps like this one, in a BCP or later/other document that says something like "oh, by the way, if you want to protect X/Y/Z or whatever, you really out to implement A/B/C." So I think there are ways to satisfy both sides of the issue here and this is not an all or nothing scenario. We can all be right and all feel the love. ;-) It'd be helpful to discuss this more but maybe for now we can table this for 24 hours or something like that. Jason > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us]=20 > Sent: Wednesday, June 28, 2006 5:49 PM > To: 'Daryl Malas' > Cc: speermint@ietf.org; 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam' > Subject: RE: TLS for peering (was RE:=20 > Comments(RE:[speermint]requirementsdraftsubmitted)) >=20 >=20 >=20 > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: Wednesday, June 28, 2006 5:24 PM > > To: richard@shockey.us > > Cc: 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam'; speermint@ietf.org > > Subject: RE: TLS for peering (was RE: > > Comments(RE:[speermint]requirementsdraft submitted)) > >=20 > > ...I simply said REQUIRING it would be unrealistic...I didn't say=20 > > including it as an optional method is unrealistic. There=20 > are multiple=20 > > ways to authenticate peers as described in Penno's message=20 > flows draft. >=20 >=20 > Ah .. you are heading into a semantic trap here.=20 >=20 > My position is any proposed BCP in SPEERMINT for intercarrier=20 > interconnection ( did I say peering here :-) using SIP MUST=20 > support a trust/security model. I'm not saying you should be=20 > REQUIRED to use TLS at all times but only that you MUST=20 > support TLS as one of the supported models. >=20 > It is my opinion based on many years of personal experience=20 > in the IETF that you that you will not get anything through=20 > the IESG to an RFC unless something like the above position=20 > is incorporated into the drafts. >=20 >=20 >=20 > >=20 > > On Wed, 2006-06-28 at 14:28 -0400, Richard Shockey wrote: > > > > > > TLS is a core part of the SIP specification. Saying its not=20 > > > realistic is just plain bovine effluent. > > > > > > You are not going to interconnect at the most basic level unless=20 > > > there > > is a > > > level of trust between the domains. So how do you plan on=20 > > > authenticating > > the > > > domain? > > > > > > This was the absolute conclusion of the SIP Forum when we came up=20 > > > with > > the > > > SIP Connect specification for PBX to SP interconnection. > > > > > > SP to SP interconnection is not that much different. > > > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg- > > IP_PBX_SP_Interop- > > > sibley-final.pdf > > > > > > > > > > > > > -----Original Message----- > > > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > > > Sent: Wednesday, June 28, 2006 12:06 PM > > > > To: Daryl Malas; Uzelac, Adam > > > > Cc: speermint@ietf.org > > > > Subject: RE: TLS for peering (was RE: Comments=20 > > > > (RE:[speermint]requirementsdraft submitted)) > > > > > > > > So, what do u recommended ? > > > > Keep TLS optional? > > > > Any other method? > > > > > > > > Sohel > > > > > > > > > > > > -----Original Message----- > > > > From: "Daryl Malas" > > > > To: "Uzelac, Adam" > > > > Cc: "speermint@ietf.org" > > > > Sent: 6/28/06 10:29 AM > > > > Subject: RE: TLS for peering (was RE: Comments (RE: > > > > [speermint]requirementsdraft submitted)) > > > > > > > > I agree with Adam's assessment. Requiring TLS is simply not=20 > > > > realistic at this point. I believe it has the potential of=20 > > > > becoming a more > > common > > > > practice in the future, but not right now. > > > > > > > > --Daryl > > > > > > > > On Tue, 2006-06-27 at 21:47 -0400, Uzelac, Adam wrote: > > > > > TLS is becoming more and more a subject when the topic of SIP=20 > > > > > interconnections arises for me professionally. This shows=20 > > > > > growing momentum indeed. With that said, I can not=20 > agree with=20 > > > > > TLS as a steadfast requirement. Economics and scale=20 > are my major concerns. > > TLS > > > > > adds cost, server load, and there are fail-over issues to=20 > > > > > consider > > as > > > > > well. For the person that designs an interconnect, I believe > > weighing > > > > > the cost against the benefit of the different models a useful > > exercise. > > > > > Mandating TLS, even if all parties involved in a peering=20 > > > > > arrangement feel somehow "safe and secure" due to underlying=20 > > > > > security mechanisms (L2/L3VPNs, etc), seems a little harsh. > > > > > > > > > > Adam > > > > > > > > > > -----Original Message----- > > > > > From: Medhavi Bhatia [mailto:mbhatia@3clogic.com] > > > > > Sent: Tuesday, June 27, 2006 8:44 PM > > > > > To: Reinaldo Penno > > > > > Cc: speermint@ietf.org > > > > > Subject: Re: TLS for peering (was RE: Comments (RE:=20 > [speermint]=20 > > > > > requirementsdraft submitted)) > > > > > > > > > > I am not a provider yet, but I think we dont need to mess with > > TLS/TCP. > > > > > As I understand one of the goals is to prevent the calls from > > failing > > > > > due to "peering only" reasons. This means that things like=20 > > > > > codecs > > which > > > > > are not negotiated by the peers need to be mandated=20 > at a minimal > > level. > > > > > TCP/TLS can be negotiated between the peers=20 > themselves so it is=20 > > > > > a non-issue. Also as I still understand doing a high volume=20 > > > > > calls with > > TLS > > > > > is still expensive. Mandating TLS in cases where the caller or > > callee > > > > > dont require it doesnt seem to add any value. > > > > > > > > > > -Medhavi. > > > > > > > > > > On 6/27/06, Reinaldo Penno wrote: > > > > > > > > > > > > TLS for _all_ scenarios? Even in private peerings,=20 > physically > > secure > > > > > > peerings, etc? > > > > > > > > > > > > Isn't that the same as requiring IPsec for all=20 > layer 3 peering? > > But > > > > > > since Layer 5 peering might be more distributed,=20 > the number of=20 > > > > > > TLS sessions would be huge. > > > > > > > > > > > > It would be good to hear the provider's opinion on this... > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Reinaldo > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > > Sent: Tuesday, June 27, 2006 2:12 PM > > > > > > > To: 'Jean-Francois Mule'; Reinaldo Penno > > > > > > > Cc: speermint@ietf.org > > > > > > > Subject: RE: Comments (RE: [speermint] requirements draft > > submitted) > > > > > > > > > > > > > > > > > > > > > > > "3.4. Security requirements > > > > > > > > > > > > > > > > All SIP messages MUST be sent over TLS=20 > [RFC3546] to provide > > > > > > > > transport-layer security as defined in RFC 3261," > > > > > > > > > > > > > > > > Giving the fact that we can have security=20 > through physical > > > > > > > segregation, > > > > > > > > intra-federation/provider calls, etc, the "MUST" here=20 > > > > > > > > seems > > too > > > > > > > > generic. > > > > > > > > > > > > > > I tend to differ on this: it is not because you=20 > have lower=20 > > > > > > > layer security (presumably hop by hop security=20 > associations)=20 > > > > > > > that you should relax the end-to-end transport=20 > security requirements. > > > > > > > Rohan's well written draft is also in favor of mandatory=20 > > > > > > > support > > of > > > > > > TLS, > > > > > > > and so is the SIP Forum's IP PBX to VSP (here is=20 > a working link: > > > > > > > > > > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg- > > IP_PBX_SP_In > > > > > > te > > > > > > > rop-sibley-final.pdf). > > > > > > > May be the requirement should be rewritten to put=20 > the MUST=20 > > > > > > > on > > SIP > > > > > > > entities involved in L5 peering. > > > > > > > > > > > > > > I'm in favor of requiring TLS. I'd say MUST in a > > heartbeat. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > _______________________________________________ > > > > > > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jun 28 18:20:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FviOq-0001o2-JR; Wed, 28 Jun 2006 18:20:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FviOp-0001nx-Hi for speermint@ietf.org; Wed, 28 Jun 2006 18:20:43 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FviOo-0004G7-U4 for speermint@ietf.org; Wed, 28 Jun 2006 18:20:43 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 28 Jun 2006 15:20:41 -0700 X-IronPort-AV: i="4.06,189,1149490800"; d="scan'208"; a="558667081:sNHT39585336" 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: Wed, 28 Jun 2006 18:20:40 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804B9E1D9@proton.jnpr.net> In-Reply-To: <025801c69afc$ab7b04c0$4d201f0a@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Thread-Index: Acaa+VnBRcdEnLXWRMiY93iCtTwjCgAAXlTQAAFXrpA= From: "Reinaldo Penno" To: , "Daryl Malas" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 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 The following security 'models' come to mind: 1 - TLS 2 - IPSec 3 - Physical security 4 - Access lists 5 - Registrations=20 6 - others?=20 TLS just like the other methods has pros and cons that should be weighted by the persons that will actually use it. I hope we can agree with that. Regards, Reinaldo > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Wednesday, June 28, 2006 2:49 PM > To: 'Daryl Malas' > Cc: speermint@ietf.org; 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam' > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraftsubmitted)) >=20 >=20 >=20 > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: Wednesday, June 28, 2006 5:24 PM > > To: richard@shockey.us > > Cc: 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam'; speermint@ietf.org > > Subject: RE: TLS for peering (was RE: > > Comments(RE:[speermint]requirementsdraft submitted)) > > > > ...I simply said REQUIRING it would be unrealistic...I didn't say > > including it as an optional method is unrealistic. There are multiple > > ways to authenticate peers as described in Penno's message flows draft. >=20 >=20 > Ah .. you are heading into a semantic trap here. >=20 > My position is any proposed BCP in SPEERMINT for intercarrier > interconnection ( did I say peering here :-) using SIP MUST support a > trust/security model. I'm not saying you should be REQUIRED to use TLS at > all times but only that you MUST support TLS as one of the supported > models. >=20 > It is my opinion based on many years of personal experience in the IETF > that > you that you will not get anything through the IESG to an RFC unless > something like the above position is incorporated into the drafts. >=20 >=20 >=20 > > > > On Wed, 2006-06-28 at 14:28 -0400, Richard Shockey wrote: > > > > > > TLS is a core part of the SIP specification. Saying its not realistic > is > > > just plain bovine effluent. > > > > > > You are not going to interconnect at the most basic level unless there > > is a > > > level of trust between the domains. So how do you plan on > authenticating > > the > > > domain? > > > > > > This was the absolute conclusion of the SIP Forum when we came up with > > the > > > SIP Connect specification for PBX to SP interconnection. > > > > > > SP to SP interconnection is not that much different. > > > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg- > > IP_PBX_SP_Interop- > > > sibley-final.pdf > > > > > > > > > > > > > -----Original Message----- > > > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > > > Sent: Wednesday, June 28, 2006 12:06 PM > > > > To: Daryl Malas; Uzelac, Adam > > > > Cc: speermint@ietf.org > > > > Subject: RE: TLS for peering (was RE: Comments > > > > (RE:[speermint]requirementsdraft submitted)) > > > > > > > > So, what do u recommended ? > > > > Keep TLS optional? > > > > Any other method? > > > > > > > > Sohel > > > > > > > > > > > > -----Original Message----- > > > > From: "Daryl Malas" > > > > To: "Uzelac, Adam" > > > > Cc: "speermint@ietf.org" > > > > Sent: 6/28/06 10:29 AM > > > > Subject: RE: TLS for peering (was RE: Comments (RE: > > > > [speermint]requirementsdraft submitted)) > > > > > > > > I agree with Adam's assessment. Requiring TLS is simply not > realistic > > > > at this point. I believe it has the potential of becoming a more > > common > > > > practice in the future, but not right now. > > > > > > > > --Daryl > > > > > > > > On Tue, 2006-06-27 at 21:47 -0400, Uzelac, Adam wrote: > > > > > TLS is becoming more and more a subject when the topic of SIP > > > > > interconnections arises for me professionally. This shows growing > > > > > momentum indeed. With that said, I can not agree with TLS as a > > > > > steadfast requirement. Economics and scale are my major concerns. > > TLS > > > > > adds cost, server load, and there are fail-over issues to consider > > as > > > > > well. For the person that designs an interconnect, I believe > > weighing > > > > > the cost against the benefit of the different models a useful > > exercise. > > > > > Mandating TLS, even if all parties involved in a peering > arrangement > > > > > feel somehow "safe and secure" due to underlying security > mechanisms > > > > > (L2/L3VPNs, etc), seems a little harsh. > > > > > > > > > > Adam > > > > > > > > > > -----Original Message----- > > > > > From: Medhavi Bhatia [mailto:mbhatia@3clogic.com] > > > > > Sent: Tuesday, June 27, 2006 8:44 PM > > > > > To: Reinaldo Penno > > > > > Cc: speermint@ietf.org > > > > > Subject: Re: TLS for peering (was RE: Comments (RE: [speermint] > > > > > requirementsdraft submitted)) > > > > > > > > > > I am not a provider yet, but I think we dont need to mess with > > TLS/TCP. > > > > > As I understand one of the goals is to prevent the calls from > > failing > > > > > due to "peering only" reasons. This means that things like codecs > > which > > > > > are not negotiated by the peers need to be mandated at a minimal > > level. > > > > > TCP/TLS can be negotiated between the peers themselves so it is a > > > > > non-issue. Also as I still understand doing a high volume calls > with > > TLS > > > > > is still expensive. Mandating TLS in cases where the caller or > > callee > > > > > dont require it doesnt seem to add any value. > > > > > > > > > > -Medhavi. > > > > > > > > > > On 6/27/06, Reinaldo Penno wrote: > > > > > > > > > > > > TLS for _all_ scenarios? Even in private peerings, physically > > secure > > > > > > peerings, etc? > > > > > > > > > > > > Isn't that the same as requiring IPsec for all layer 3 peering? > > But > > > > > > since Layer 5 peering might be more distributed, the number of > TLS > > > > > > sessions would be huge. > > > > > > > > > > > > It would be good to hear the provider's opinion on this... > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Reinaldo > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > > Sent: Tuesday, June 27, 2006 2:12 PM > > > > > > > To: 'Jean-Francois Mule'; Reinaldo Penno > > > > > > > Cc: speermint@ietf.org > > > > > > > Subject: RE: Comments (RE: [speermint] requirements draft > > submitted) > > > > > > > > > > > > > > > > > > > > > > > "3.4. Security requirements > > > > > > > > > > > > > > > > All SIP messages MUST be sent over TLS [RFC3546] to > provide > > > > > > > > transport-layer security as defined in RFC 3261," > > > > > > > > > > > > > > > > Giving the fact that we can have security through physical > > > > > > > segregation, > > > > > > > > intra-federation/provider calls, etc, the "MUST" here seems > > too > > > > > > > > generic. > > > > > > > > > > > > > > I tend to differ on this: it is not because you have lower > layer > > > > > > > security (presumably hop by hop security associations) that > you > > > > > > > should relax the end-to-end transport security requirements. > > > > > > > Rohan's well written draft is also in favor of mandatory > support > > of > > > > > > TLS, > > > > > > > and so is the SIP Forum's IP PBX to VSP (here is a working > link: > > > > > > > > > > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg- > > IP_PBX_SP_In > > > > > > te > > > > > > > rop-sibley-final.pdf). > > > > > > > May be the requirement should be rewritten to put the MUST on > > SIP > > > > > > > entities involved in L5 peering. > > > > > > > > > > > > > > I'm in favor of requiring TLS. I'd say MUST in a > > heartbeat. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > _______________________________________________ > > > > > > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jun 28 19:36:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvja0-0001J3-Oc; Wed, 28 Jun 2006 19:36:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvjZz-0001Fi-4z for speermint@ietf.org; Wed, 28 Jun 2006 19:36:19 -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 1FvjZy-0006Kr-Ll for speermint@ietf.org; Wed, 28 Jun 2006 19:36:19 -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 k5SNaFaK023561; Wed, 28 Jun 2006 23:36:16 GMT Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) From: Daryl Malas To: richard@shockey.us In-Reply-To: <025801c69afc$ab7b04c0$4d201f0a@cis.neustar.com> References: <025801c69afc$ab7b04c0$4d201f0a@cis.neustar.com> Content-Type: text/plain Date: Wed, 28 Jun 2006 17:35:36 -0600 Message-Id: <1151537736.10104.17.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: bacfc6c7290e34d410f9bc22b825ce96 Cc: speermint@ietf.org, "'Khan, Sohel Q \[CTO\]'" , "'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 100% agree with your statement below. Thanks for clarifying...I apparently stepped in the semantic trap...it's sticky I might add. ;-) Thanks...--Daryl On Wed, 2006-06-28 at 17:49 -0400, Richard Shockey wrote: > > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: Wednesday, June 28, 2006 5:24 PM > > To: richard@shockey.us > > Cc: 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam'; speermint@ietf.org > > Subject: RE: TLS for peering (was RE: > > Comments(RE:[speermint]requirementsdraft submitted)) > > > > ...I simply said REQUIRING it would be unrealistic...I didn't say > > including it as an optional method is unrealistic. There are multiple > > ways to authenticate peers as described in Penno's message flows draft. > > > Ah .. you are heading into a semantic trap here. > > My position is any proposed BCP in SPEERMINT for intercarrier > interconnection ( did I say peering here :-) using SIP MUST support a > trust/security model. I'm not saying you should be REQUIRED to use TLS at > all times but only that you MUST support TLS as one of the supported models. > > It is my opinion based on many years of personal experience in the IETF that > you that you will not get anything through the IESG to an RFC unless > something like the above position is incorporated into the drafts. > > > > > > > On Wed, 2006-06-28 at 14:28 -0400, Richard Shockey wrote: > > > > > > TLS is a core part of the SIP specification. Saying its not realistic is > > > just plain bovine effluent. > > > > > > You are not going to interconnect at the most basic level unless there > > is a > > > level of trust between the domains. So how do you plan on authenticating > > the > > > domain? > > > > > > This was the absolute conclusion of the SIP Forum when we came up with > > the > > > SIP Connect specification for PBX to SP interconnection. > > > > > > SP to SP interconnection is not that much different. > > > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg- > > IP_PBX_SP_Interop- > > > sibley-final.pdf > > > > > > > > > > > > > -----Original Message----- > > > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > > > Sent: Wednesday, June 28, 2006 12:06 PM > > > > To: Daryl Malas; Uzelac, Adam > > > > Cc: speermint@ietf.org > > > > Subject: RE: TLS for peering (was RE: Comments > > > > (RE:[speermint]requirementsdraft submitted)) > > > > > > > > So, what do u recommended ? > > > > Keep TLS optional? > > > > Any other method? > > > > > > > > Sohel > > > > > > > > > > > > -----Original Message----- > > > > From: "Daryl Malas" > > > > To: "Uzelac, Adam" > > > > Cc: "speermint@ietf.org" > > > > Sent: 6/28/06 10:29 AM > > > > Subject: RE: TLS for peering (was RE: Comments (RE: > > > > [speermint]requirementsdraft submitted)) > > > > > > > > I agree with Adam's assessment. Requiring TLS is simply not realistic > > > > at this point. I believe it has the potential of becoming a more > > common > > > > practice in the future, but not right now. > > > > > > > > --Daryl > > > > > > > > On Tue, 2006-06-27 at 21:47 -0400, Uzelac, Adam wrote: > > > > > TLS is becoming more and more a subject when the topic of SIP > > > > > interconnections arises for me professionally. This shows growing > > > > > momentum indeed. With that said, I can not agree with TLS as a > > > > > steadfast requirement. Economics and scale are my major concerns. > > TLS > > > > > adds cost, server load, and there are fail-over issues to consider > > as > > > > > well. For the person that designs an interconnect, I believe > > weighing > > > > > the cost against the benefit of the different models a useful > > exercise. > > > > > Mandating TLS, even if all parties involved in a peering arrangement > > > > > feel somehow "safe and secure" due to underlying security mechanisms > > > > > (L2/L3VPNs, etc), seems a little harsh. > > > > > > > > > > Adam > > > > > > > > > > -----Original Message----- > > > > > From: Medhavi Bhatia [mailto:mbhatia@3clogic.com] > > > > > Sent: Tuesday, June 27, 2006 8:44 PM > > > > > To: Reinaldo Penno > > > > > Cc: speermint@ietf.org > > > > > Subject: Re: TLS for peering (was RE: Comments (RE: [speermint] > > > > > requirementsdraft submitted)) > > > > > > > > > > I am not a provider yet, but I think we dont need to mess with > > TLS/TCP. > > > > > As I understand one of the goals is to prevent the calls from > > failing > > > > > due to "peering only" reasons. This means that things like codecs > > which > > > > > are not negotiated by the peers need to be mandated at a minimal > > level. > > > > > TCP/TLS can be negotiated between the peers themselves so it is a > > > > > non-issue. Also as I still understand doing a high volume calls with > > TLS > > > > > is still expensive. Mandating TLS in cases where the caller or > > callee > > > > > dont require it doesnt seem to add any value. > > > > > > > > > > -Medhavi. > > > > > > > > > > On 6/27/06, Reinaldo Penno wrote: > > > > > > > > > > > > TLS for _all_ scenarios? Even in private peerings, physically > > secure > > > > > > peerings, etc? > > > > > > > > > > > > Isn't that the same as requiring IPsec for all layer 3 peering? > > But > > > > > > since Layer 5 peering might be more distributed, the number of TLS > > > > > > sessions would be huge. > > > > > > > > > > > > It would be good to hear the provider's opinion on this... > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Reinaldo > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > > Sent: Tuesday, June 27, 2006 2:12 PM > > > > > > > To: 'Jean-Francois Mule'; Reinaldo Penno > > > > > > > Cc: speermint@ietf.org > > > > > > > Subject: RE: Comments (RE: [speermint] requirements draft > > submitted) > > > > > > > > > > > > > > > > > > > > > > > "3.4. Security requirements > > > > > > > > > > > > > > > > All SIP messages MUST be sent over TLS [RFC3546] to provide > > > > > > > > transport-layer security as defined in RFC 3261," > > > > > > > > > > > > > > > > Giving the fact that we can have security through physical > > > > > > > segregation, > > > > > > > > intra-federation/provider calls, etc, the "MUST" here seems > > too > > > > > > > > generic. > > > > > > > > > > > > > > I tend to differ on this: it is not because you have lower layer > > > > > > > security (presumably hop by hop security associations) that you > > > > > > > should relax the end-to-end transport security requirements. > > > > > > > Rohan's well written draft is also in favor of mandatory support > > of > > > > > > TLS, > > > > > > > and so is the SIP Forum's IP PBX to VSP (here is a working link: > > > > > > > > > > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg- > > IP_PBX_SP_In > > > > > > te > > > > > > > rop-sibley-final.pdf). > > > > > > > May be the requirement should be rewritten to put the MUST on > > SIP > > > > > > > entities involved in L5 peering. > > > > > > > > > > > > > > I'm in favor of requiring TLS. I'd say MUST in a > > heartbeat. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > _______________________________________________ > > > > > > 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 Wed Jun 28 21:29:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvlLV-0007vn-J8; Wed, 28 Jun 2006 21:29:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvlLT-0007vi-DY for speermint@ietf.org; Wed, 28 Jun 2006 21:29:27 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvlLS-0002qI-0J for speermint@ietf.org; Wed, 28 Jun 2006 21:29:27 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5T1Thd6018428; Wed, 28 Jun 2006 18:29:43 -0700 From: "Richard Shockey" To: "'Uzelac, Adam'" , "'Daryl Malas'" Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Date: Wed, 28 Jun 2006 21:29:14 -0400 Message-ID: <01d801c69b1b$6f20a330$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: Thread-Index: Acaa+VnBRcdEnLXWRMiY93iCtTwjCgAAXlTQAACsaSAAB28JEA== 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: "'Khan, Sohel Q \[CTO\]'" , 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: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, June 28, 2006 6:00 PM > To: richard@shockey.us; Daryl Malas > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraft submitted)) > > I agree with Richard's wording below. > > "...any proposed BCP in SPEERMINT for intercarrier interconnection using > SIP MUST support a trust/security model....you MUST support TLS as one > of the supported models." > > I also believe that a trust/security model must be in place, and I have > written as much in this forum. Thank you. This is my point exactly. > > > > > > > > _______________________________________________ > > > > 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 Jun 28 21:39:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvlVH-0000qI-5j; Wed, 28 Jun 2006 21:39:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvlVG-0000q1-9p for speermint@ietf.org; Wed, 28 Jun 2006 21:39:34 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvlVE-00041z-TQ for speermint@ietf.org; Wed, 28 Jun 2006 21:39:34 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5T1bn6R019660; Wed, 28 Jun 2006 18:37:49 -0700 From: "Richard Shockey" To: "'Reinaldo Penno'" , "'Andrew Newton'" Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Date: Wed, 28 Jun 2006 21:37:20 -0400 Message-ID: <01d901c69b1c$90c07780$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804B9E1D5@proton.jnpr.net> Thread-Index: Acaa5fZ5NGhsPsuiTz6yKQm/EKnphAAAhV8gAAGawNAAAgi1IAABbr3QAAfKqxA= 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: 0ddefe323dd869ab027dbfff7eff0465 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: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Wednesday, June 28, 2006 6:02 PM > To: richard@shockey.us; Andrew Newton > Cc: speermint@ietf.org; Khan, Sohel Q [CTO]; Uzelac, Adam > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraft submitted)) > > Richard, > > If you are so confident that TLS will become the standard for peering, > there is nothing to fear, just say that it should be used in the absence > of other methods. My point is that in SIP communications TLS IS a standard directly required in 3261. That cannot be avoided..if you say you support SIP by definition you MUST support TLS. > > If your prediction is correct, providers will actually require and use > it, vendors will implement TLS, and it will become ubiquitous. I did not say there were not other trust models only that you cannot side step the requirement to support TLS. > > Shoving down the throats of people an operational requirement that will > increase the cost of a deployment is not the way to go. IETF is about > running code and consensus. So you choose to pick and choose what points in the SIP standard you want? How do you propose to implement interoperability? You are the violation of consensus. Follow the standard as agreed to by the SIP WG and approved by the IETF otherwise you are in noncompliance. > > More comments inline... > > > > > > > > _______________________________________________ > > > > 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 Jun 28 21:51:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvlhD-0001dU-Ii; Wed, 28 Jun 2006 21:51:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvlhC-0001dP-3R for speermint@ietf.org; Wed, 28 Jun 2006 21:51:54 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvlhA-00065q-EC for speermint@ietf.org; Wed, 28 Jun 2006 21:51:54 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5T1q9UX027003; Wed, 28 Jun 2006 18:52:09 -0700 From: "Richard Shockey" To: "'Andrew Newton'" Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Date: Wed, 28 Jun 2006 21:51:40 -0400 Message-ID: <01de01c69b1e$91613970$23f0a544@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: Thread-Index: Acaa/om+aMlr5zSBSL6Cr6Q7llmYYAAHhScg 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: 94962611154c8404498b19f744990308 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: , Content-Type: multipart/mixed; boundary="===============0926903665==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0926903665== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DF_01C69AFD.0A4F9970" This is a multi-part message in MIME format. ------=_NextPart_000_01DF_01C69AFD.0A4F9970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit An excellent point Andy ..now we are making progress here. But is this a discussion over what is the root CA authority between service providers should it be? "To be a CA or not to be a CA that is the question" Bill Shakespeare That is a reasonable point of discussion on how or to whom anchors the trust between the domain boundaries. Which is my ultimate point. All other discussions are moot points unless the trust model is clear. My personal view is that so long as two consenting service providers can agree on the CA the boundary trust relationship can be established. Why should SIP interconnection be any different from traditional network interconnection which is a matrix of bi-lateral agreements? Look at the GSM? 600 members and 32000 bilateral agreements covering each and every detail including neutral settlement clearing houses. My point is that TLS MUST be supported and it is up to service providers to decide who they mutually agree to be their trusted CA. _____ From: Andrew Newton [mailto:andy@hxr.us] Sent: Wednesday, June 28, 2006 6:02 PM To: richard@shockey.us Cc: 'Reinaldo Penno'; speermint@ietf.org; 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam' Subject: Re: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) On Jun 28, 2006, at 5:35 PM, Richard Shockey wrote: Like duh? So what? There is real money involved here. There's real money involved in many aspects of Internet operations. Life would certainly be better if the gTLD providers did the right thing by offering secure protocols too, but you don't see them stampeding to do so. The other thing I don't like about the magical TLS pixie dust is that it does not take into account the fact that there is no root trust anchor. Some CAs will sell anybody a cert for $25, some give them away for FREE. What's the point of all that additional TLS infrastructure if it can be easily circumvented by a trust path that leads back to a money order purchased at a gas station. -andy ------=_NextPart_000_01DF_01C69AFD.0A4F9970 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

An excellent point Andy ..now we = are making progress here.

 

But is this a discussion over what = is the root CA authority between service providers should it = be?

 

“To be a CA or not to be a CA = that is the question”  Bill Shakespeare =

 

That is a reasonable point of = discussion on how or to whom anchors the trust between the domain boundaries. Which = is my ultimate point.

 

All other discussions are moot = points unless the trust model is clear.

 

My personal view is that so long as = two consenting service providers can agree on the CA the boundary trust relationship can be established.

 

Why should SIP interconnection be = any different from traditional network interconnection which is a matrix of bi-lateral agreements?  Look at the GSM? 600 members and 32000 = bilateral agreements covering each and every detail including neutral settlement = clearing houses.

 

My point is that TLS MUST be = supported and it is up to service providers to decide who they mutually agree to be = their trusted CA.

 

 

 

 

 

From: = Andrew Newton [mailto:andy@hxr.us]
Sent: Wednesday, June 28, = 2006 6:02 PM
To: richard@shockey.us
Cc: 'Reinaldo Penno'; speermint@ietf.org; 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam'
Subject: Re: TLS for = peering (was RE: Comments(RE:[speermint]requirementsdraft = submitted))

 

 

On Jun 28, 2006, at 5:35 PM, Richard Shockey = wrote:



Like duh? So = what?

 <= /font>

There is real money = involved here. =

 

There's real money involved in many aspects of Internet = operations. Life would certainly be better if the gTLD providers did the right thing = by offering secure protocols too, but you don't see them stampeding to do = so.

 

The other thing I don't like about the magical TLS pixie dust is = that it does not take into account the fact that there is no root trust = anchor. Some CAs will sell anybody a cert for $25, some give them away for FREE. = What's the point of all that additional TLS infrastructure if it can be easily circumvented by a trust path that leads back to a money order purchased = at a gas station.

 

-andy

------=_NextPart_000_01DF_01C69AFD.0A4F9970-- --===============0926903665== 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 --===============0926903665==-- From speermint-bounces@ietf.org Wed Jun 28 22:08:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvlxR-0006hy-HL; Wed, 28 Jun 2006 22:08:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvlxD-0006gG-Fn for speermint@ietf.org; Wed, 28 Jun 2006 22:08:27 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvlxB-0007g6-2v for speermint@ietf.org; Wed, 28 Jun 2006 22:08:27 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5T26dkK032440; Wed, 28 Jun 2006 19:06:39 -0700 From: "Richard Shockey" To: "'Reinaldo Penno'" , "'Daryl Malas'" Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Date: Wed, 28 Jun 2006 22:06:11 -0400 Message-ID: <01ec01c69b20$998f6c50$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804B9E1D9@proton.jnpr.net> Thread-Index: Acaa+VnBRcdEnLXWRMiY93iCtTwjCgAAXlTQAAFXrpAAB6qYcA== 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: 50a516d93fd399dc60588708fd9a3002 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: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Wednesday, June 28, 2006 6:21 PM > To: richard@shockey.us; Daryl Malas > Cc: speermint@ietf.org; Khan, Sohel Q [CTO]; Uzelac, Adam > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraftsubmitted)) > > The following security 'models' come to mind: > > 1 - TLS > 2 - IPSec > 3 - Physical security > 4 - Access lists > 5 - Registrations > 6 - others? > > TLS just like the other methods has pros and cons that should be > weighted by the persons that will actually use it. But it cannot be deprecated. It MUST be supported. Its part of the core SIP standard you cannot side step this issue. > > I hope we can agree with that. This is exactly where we begin to make progress. Define the reasonable security/trust models including TLS that we can find consensus on, the smaller the list the better. This is really the core problem in spearmint. What is the ultimate trust/security model that service providers can rely on to accept traffic across domain boundaries. Are you really BT or Sprint or FT or Cablevision etc. Or are you really IBM or Ford or Bombardier or Sony for that matter. Can I bill you for your traffic? How do I know you are who you say you are. > > > > _______________________________________________ > > 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 Jun 29 03:53:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvrLI-0000Wo-0m; Thu, 29 Jun 2006 03:53:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvrLH-0000Wj-IX for speermint@ietf.org; Thu, 29 Jun 2006 03:53:39 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FvrLD-0003DM-6J for speermint@ietf.org; Thu, 29 Jun 2006 03:53:39 -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: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Date: Thu, 29 Jun 2006 09:53:08 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AF7@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Thread-Index: Acaa+VnBRcdEnLXWRMiY93iCtTwjCgAAXlTQAACsaSAAB28JEAANc7zU References: <01d801c69b1b$6f20a330$23f0a544@cis.neustar.com> From: "Stastny Richard" To: 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: , Errors-To: speermint-bounces@ietf.org > I agree with Richard's wording below. > > "...any proposed BCP in SPEERMINT for intercarrier interconnection = using > SIP MUST support a trust/security model....you MUST support TLS as one > of the supported models." > > I also believe that a trust/security model must be in place, and I = have > written as much in this forum. Count me in too. =20 I also want to add Rich's statements: =20 >So you choose to pick and choose what points in the SIP standard you = want? >How do you propose to implement interoperability? You are the violation = of >consensus. Follow the standard as agreed to by the SIP WG and approved = by >the IETF otherwise you are in noncompliance. =20 and >My point is that TLS MUST be supported and it is up to service = providers to decide who they mutually agree to be >their trusted CA. =20 -sta _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 29 08:13:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvvOo-0000h0-Aj; Thu, 29 Jun 2006 08:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvvOm-0000go-1c for speermint@ietf.org; Thu, 29 Jun 2006 08:13:32 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvvOk-0005UT-PD for speermint@ietf.org; Thu, 29 Jun 2006 08:13:32 -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 k5TCDH31008188; Thu, 29 Jun 2006 07:13:26 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 29 Jun 2006 13:13:16 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C29096C@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'richard@shockey.us'" , "'Reinaldo Penno'" , "'Daryl Malas'" Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsd raftsubmitted)) Date: Thu, 29 Jun 2006 13:13:16 +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: 0fa76816851382eb71b0a882ccdc29ac 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 Just to be clear. RFC 3261 requires implementations to support TLS. To be conformant it must also response to a SIPS URI with the use of TLS, but presumably it can also reject a request for any reason it likes. That does not require it to use a SIPS URI on any outgoing request, and therefore use TLS on outgoing requests. Therefore substantially the RFC 3261 requirement is to support TLS, not to use it. You seem to be verging on implying that RFC 3261 says it must also be used. regards Keith > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: 29 June 2006 03:06 > To: 'Reinaldo Penno'; 'Daryl Malas' > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org; 'Uzelac, Adam' > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraftsubmitted)) > > > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Wednesday, June 28, 2006 6:21 PM > > To: richard@shockey.us; Daryl Malas > > Cc: speermint@ietf.org; Khan, Sohel Q [CTO]; Uzelac, Adam > > Subject: RE: TLS for peering (was RE: > > Comments(RE:[speermint]requirementsdraftsubmitted)) > > > > The following security 'models' come to mind: > > > > 1 - TLS > > 2 - IPSec > > 3 - Physical security > > 4 - Access lists > > 5 - Registrations > > 6 - others? > > > > TLS just like the other methods has pros and cons that should be > > weighted by the persons that will actually use it. > > But it cannot be deprecated. It MUST be supported. Its part > of the core SIP > standard you cannot side step this issue. > > > > > I hope we can agree with that. > > > This is exactly where we begin to make progress. Define the reasonable > security/trust models including TLS that we can find consensus on, the > smaller the list the better. > > This is really the core problem in spearmint. What is the ultimate > trust/security model that service providers can rely on to > accept traffic > across domain boundaries. > > Are you really BT or Sprint or FT or Cablevision etc. Or are > you really IBM > or Ford or Bombardier or Sony for that matter. Can I bill you for your > traffic? How do I know you are who you say you are. > > > > > > > > > _______________________________________________ > > > 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 Jun 29 10:10:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxDf-0003xw-73; Thu, 29 Jun 2006 10:10:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxDd-0003xe-PW for speermint@ietf.org; Thu, 29 Jun 2006 10:10:09 -0400 Received: from [67.32.112.39] (helo=wireless.ccld.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvxDb-0001ar-AW for speermint@ietf.org; Thu, 29 Jun 2006 10:10:09 -0400 Received: from [65.83.246.8] (helo=BROSENLT40xp) by wireless.ccld.net with esmtp (Exim 3.34 #1) id 1FvwHN-0000Zr-00; Thu, 29 Jun 2006 09:09:57 -0400 From: "Brian Rosen" To: "'Uzelac, Adam'" , "'Medhavi Bhatia'" , "'Reinaldo Penno'" Subject: RE: TLS for peering (was RE: Comments (RE: [speermint]requirementsdraft submitted)) Date: Thu, 29 Jun 2006 10:09:15 -0400 Message-ID: <01f501c69b85$b32cef60$08f65341@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: Thread-Index: AcaaTAvQibrYHlUOTIKmrbaCpV6BkgABbC1gACiw7SA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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 us a PEERING system with federations. The likelihood of a persistent TLS connection being maintained is high, and the cost of establishing a new one is relatively low, especially if, as on another thread, one of the things a federation means is a CA signing certs for use by the federation. The number of peers is going to be relatively low, improving the probability of the persistent TLS connection being available. Brian -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Sent: Tuesday, June 27, 2006 9:48 PM To: Medhavi Bhatia; Reinaldo Penno Cc: speermint@ietf.org Subject: RE: TLS for peering (was RE: Comments (RE: [speermint]requirementsdraft submitted)) TLS is becoming more and more a subject when the topic of SIP interconnections arises for me professionally. This shows growing momentum indeed. With that said, I can not agree with TLS as a steadfast requirement. Economics and scale are my major concerns. TLS adds cost, server load, and there are fail-over issues to consider as well. For the person that designs an interconnect, I believe weighing the cost against the benefit of the different models a useful exercise. Mandating TLS, even if all parties involved in a peering arrangement feel somehow "safe and secure" due to underlying security mechanisms (L2/L3VPNs, etc), seems a little harsh. Adam -----Original Message----- From: Medhavi Bhatia [mailto:mbhatia@3clogic.com] Sent: Tuesday, June 27, 2006 8:44 PM To: Reinaldo Penno Cc: speermint@ietf.org Subject: Re: TLS for peering (was RE: Comments (RE: [speermint] requirementsdraft submitted)) I am not a provider yet, but I think we dont need to mess with TLS/TCP. As I understand one of the goals is to prevent the calls from failing due to "peering only" reasons. This means that things like codecs which are not negotiated by the peers need to be mandated at a minimal level. TCP/TLS can be negotiated between the peers themselves so it is a non-issue. Also as I still understand doing a high volume calls with TLS is still expensive. Mandating TLS in cases where the caller or callee dont require it doesnt seem to add any value. -Medhavi. On 6/27/06, Reinaldo Penno wrote: > > TLS for _all_ scenarios? Even in private peerings, physically secure > peerings, etc? > > Isn't that the same as requiring IPsec for all layer 3 peering? But > since Layer 5 peering might be more distributed, the number of TLS > sessions would be huge. > > It would be good to hear the provider's opinion on this... > > Thanks, > > Reinaldo > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, June 27, 2006 2:12 PM > > To: 'Jean-Francois Mule'; Reinaldo Penno > > Cc: speermint@ietf.org > > Subject: RE: Comments (RE: [speermint] requirements draft submitted) > > > > > > > > "3.4. Security requirements > > > > > > All SIP messages MUST be sent over TLS [RFC3546] to provide > > > transport-layer security as defined in RFC 3261," > > > > > > Giving the fact that we can have security through physical > > segregation, > > > intra-federation/provider calls, etc, the "MUST" here seems too > > > generic. > > > > I tend to differ on this: it is not because you have lower layer > > security (presumably hop by hop security associations) that you > > should relax the end-to-end transport security requirements. > > Rohan's well written draft is also in favor of mandatory support of > TLS, > > and so is the SIP Forum's IP PBX to VSP (here is a working link: > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_In > te > > rop-sibley-final.pdf). > > May be the requirement should be rewritten to put the MUST on SIP > > entities involved in L5 peering. > > > > I'm in favor of requiring TLS. I'd say MUST in a heartbeat. > > > > Brian > > _______________________________________________ > 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 Jun 29 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 1FvxhQ-0001kb-Dp; Thu, 29 Jun 2006 10:40:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxhP-0001kP-97 for speermint@ietf.org; Thu, 29 Jun 2006 10:40:55 -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 1Fvx43-0001FH-1H for speermint@ietf.org; Thu, 29 Jun 2006 10:00:15 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fvwot-0004ZU-LM for speermint@ietf.org; Thu, 29 Jun 2006 09:44: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 k5TDipFE011071; Thu, 29 Jun 2006 06:44:52 -0700 From: "Richard Shockey" To: "'Drage, Keith \(Keith\)'" , "'Reinaldo Penno'" , "'Daryl Malas'" Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Date: Thu, 29 Jun 2006 09:44:08 -0400 Message-ID: <013e01c69b82$198b4850$4d201f0a@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: <475FF955A05DD411980D00508B6D5FB00C29096C@en0033exch001u.uk.lucent.com> Thread-Index: AcabdYWBnBYVQQYPQLiGniFUnuXJHAAC+qgg X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: -0.5 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Thursday, June 29, 2006 8:13 AM > To: 'richard@shockey.us'; 'Reinaldo Penno'; 'Daryl Malas' > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org; 'Uzelac, Adam' > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraftsubmitted)) > > Just to be clear. RFC 3261 requires implementations to support TLS. To be > conformant it must also response to a SIPS URI with the use of TLS, but > presumably it can also reject a request for any reason it likes. OF course. > > That does not require it to use a SIPS URI on any outgoing request, and > therefore use TLS on outgoing requests. > > Therefore substantially the RFC 3261 requirement is to support TLS, not to > use it. You seem to be verging on implying that RFC 3261 says it must also > be used. > > Apologies is I was not clear. You MUST support TLS as one of multiple security/trust options. > > > > _______________________________________________ > > 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 Jun 29 10:46:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxnG-0003tt-Ue; Thu, 29 Jun 2006 10:46:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxnF-0003to-MG for speermint@ietf.org; Thu, 29 Jun 2006 10:46:57 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvxnE-0004ZG-CL for speermint@ietf.org; Thu, 29 Jun 2006 10:46:57 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Jun 2006 10:46:56 -0400 X-IronPort-AV: i="4.06,192,1149480000"; d="scan'208,217"; a="91294865:sNHT52932040" 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 k5TEkrno018464; Thu, 29 Jun 2006 10:46:53 -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); Thu, 29 Jun 2006 10:46:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Date: Thu, 29 Jun 2006 10:46:52 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301A5A6FE@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: Acaa/pifKsls8bbdS5KkS4cLpL9RTQAi9r5Q From: "Michael Hammer \(mhammer\)" To: "Andrew Newton" , X-OriginalArrivalTime: 29 Jun 2006 14:46:53.0730 (UTC) FILETIME=[DCB55020:01C69B8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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="===============1581168816==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1581168816== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69B8A.DC81273B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69B8A.DC81273B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This whole discussion leads back to the observation that many of these type of agreements are aspects that ALL SPs may not come to agreement, but some subset might have agreement. =20 In other words, it is a "federation" policy issue. =20 Mike =20 ________________________________ From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Wednesday, June 28, 2006 6:02 PM To: richard@shockey.us Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org; 'Uzelac, Adam' Subject: Re: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) =09 =09 On Jun 28, 2006, at 5:35 PM, Richard Shockey wrote: Like duh? So what? =09 =09 There is real money involved here.=20 There's real money involved in many aspects of Internet operations. Life would certainly be better if the gTLD providers did the right thing by offering secure protocols too, but you don't see them stampeding to do so. The other thing I don't like about the magical TLS pixie dust is that it does not take into account the fact that there is no root trust anchor. Some CAs will sell anybody a cert for $25, some give them away for FREE. What's the point of all that additional TLS infrastructure if it can be easily circumvented by a trust path that leads back to a money order purchased at a gas station. -andy ------_=_NextPart_001_01C69B8A.DC81273B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This whole discussion leads back to the observation that = many of=20 these type of agreements are aspects that ALL SPs may not come to = agreement, but=20 some subset might have agreement.
 
In other words, it is a "federation" policy=20 issue.
 
Mike
 

From: Andrew Newton = [mailto:andy@hxr.us]=20
Sent: Wednesday, June 28, 2006 6:02 PM
To:=20 richard@shockey.us
Cc: 'Khan, Sohel Q [CTO]'; = speermint@ietf.org;=20 'Uzelac, Adam'
Subject: Re: TLS for peering (was RE:=20 = Comments(RE:[speermint]requirementsdraftsubmitted))


On Jun 28, 2006, at 5:35 PM, Richard Shockey wrote:

Like duh? So what?


There is real money involved here. 

=
There's real money involved in many aspects of Internet = operations. =20 Life would certainly be better if the gTLD providers did the right = thing by=20 offering secure protocols too, but you don't see them stampeding to do = so.

The other thing I don't like about the magical TLS pixie dust is = that it=20 does not take into account the fact that there is no root trust = anchor. =20 Some CAs will sell anybody a cert for $25, some give them away for = FREE. =20 What's the point of all that additional TLS infrastructure if it can = be easily=20 circumvented by a trust path that leads back to a money order = purchased at a=20 gas station.

-andy
------_=_NextPart_001_01C69B8A.DC81273B-- --===============1581168816== 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 --===============1581168816==-- From speermint-bounces@ietf.org Thu Jun 29 11:01:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvy1O-0006uo-2n; Thu, 29 Jun 2006 11:01:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvy1N-0006sX-Bo for speermint@ietf.org; Thu, 29 Jun 2006 11:01:33 -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 1Fvy1L-0006uO-2l for speermint@ietf.org; Thu, 29 Jun 2006 11:01:33 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 29 Jun 2006 11:01:49 -0400 id 01588110.44A3EB5D.0000049E Message-ID: <44A3EB3E.4090600@hxr.us> Date: Thu, 29 Jun 2006 11:01:18 -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]requirementsdraft submitted)) References: <01de01c69b1e$91613970$23f0a544@cis.neustar.com> In-Reply-To: <01de01c69b1e$91613970$23f0a544@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: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Richard Shockey wrote: > My point is that TLS MUST be supported and it is up to service providers to > decide who they mutually agree to be their trusted CA. So a mechanism MUST be supported even though the bits to get it to work will not be specified? Haven't you ever wondered why SMTPS has never succeeded in solving the spam problem? What's wrong with just saying that service providers MUST mutually agree upon security and authorization mechanisms? -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 29 12:26:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvzLK-0001h4-M7; Thu, 29 Jun 2006 12:26:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvzLJ-0001gy-4f for speermint@ietf.org; Thu, 29 Jun 2006 12:26:13 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvzLH-0005Fz-Qw for speermint@ietf.org; Thu, 29 Jun 2006 12:26:13 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 29 Jun 2006 09:26:10 -0700 X-IronPort-AV: i="4.06,192,1149490800"; d="scan'208"; a="558890799:sNHT31311650" 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]requirementsdraft submitted)) Date: Thu, 29 Jun 2006 12:26:08 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804B9E286@proton.jnpr.net> In-Reply-To: <01d901c69b1c$90c07780$23f0a544@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Thread-Index: Acaa5fZ5NGhsPsuiTz6yKQm/EKnphAAAhV8gAAGawNAAAgi1IAABbr3QAAfKqxAAHubfgA== From: "Reinaldo Penno" To: , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 Richard, Until very recently there was consensus around TLS: nobody implemented it. - "But hey, isn't it a MUST on the RFC?" one would ask. Yes, but there was no interoperability problem at all. People just did not use it. It took years for TLS to gain momentum and I can guarantee that it is _not_ because the RFC 3261says it MUST, but because users saw security advantages on it in certain deployments. All I'm saying is that we must provide alternatives so that small ISPs that do not have tons of money as you it, ISPs that do not care about TLS and others can interoperate.=20 Regards, Reinaldo > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Wednesday, June 28, 2006 6:37 PM > To: Reinaldo Penno; 'Andrew Newton' > Cc: speermint@ietf.org; 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam' > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraft submitted)) >=20 >=20 >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Wednesday, June 28, 2006 6:02 PM > > To: richard@shockey.us; Andrew Newton > > Cc: speermint@ietf.org; Khan, Sohel Q [CTO]; Uzelac, Adam > > Subject: RE: TLS for peering (was RE: > > Comments(RE:[speermint]requirementsdraft submitted)) > > > > Richard, > > > > If you are so confident that TLS will become the standard for peering, > > there is nothing to fear, just say that it should be used in the absence > > of other methods. >=20 >=20 > My point is that in SIP communications TLS IS a standard directly required > in 3261. That cannot be avoided..if you say you support SIP by definition > you MUST support TLS. >=20 > > > > If your prediction is correct, providers will actually require and use > > it, vendors will implement TLS, and it will become ubiquitous. >=20 > I did not say there were not other trust models only that you cannot side > step the requirement to support TLS. >=20 > > > > Shoving down the throats of people an operational requirement that will > > increase the cost of a deployment is not the way to go. IETF is about > > running code and consensus. >=20 > So you choose to pick and choose what points in the SIP standard you want? > How do you propose to implement interoperability? You are the violation of > consensus. Follow the standard as agreed to by the SIP WG and approved by > the IETF otherwise you are in noncompliance. >=20 >=20 >=20 > > > > More comments inline... >=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 Jun 29 12:34:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvzTg-0003SN-0U; Thu, 29 Jun 2006 12:34:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvzTe-0003SI-P9 for speermint@ietf.org; Thu, 29 Jun 2006 12:34:50 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvzTe-00063C-AY for speermint@ietf.org; Thu, 29 Jun 2006 12:34:50 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 29 Jun 2006 09:34:49 -0700 X-IronPort-AV: i="4.06,192,1149490800"; d="scan'208"; a="558893019:sNHT35075336" 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]requirementsdraft submitted)) Date: Thu, 29 Jun 2006 12:34:48 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804B9E287@proton.jnpr.net> In-Reply-To: <01f501c69b85$b32cef60$08f65341@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments (RE: [speermint]requirementsdraft submitted)) Thread-Index: AcaaTAvQibrYHlUOTIKmrbaCpV6BkgABbC1gACiw7SAAKRZacA== From: "Reinaldo Penno" To: "Brian Rosen" , "Uzelac, Adam" , "Medhavi Bhatia" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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 Hummm....I'm not sure about that. It depends on many factors. First and foremost it depends on which model you embrace: p2p/email or federations. In the email model the number of TLS connection will be considerable.=20 In the federations model it depends on the scale of the federations. I've been told that there are some 3000 carriers in the US and 8000 public traded companies alone This does not count the million of end users that might get their own domain and run a Sip Proxy.=20 Regards, Reinaldo > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, June 29, 2006 7:09 AM > To: 'Uzelac, Adam'; 'Medhavi Bhatia'; Reinaldo Penno > Cc: speermint@ietf.org > Subject: RE: TLS for peering (was RE: Comments (RE: > [speermint]requirementsdraft submitted)) >=20 > > This us a PEERING system with federations. The likelihood of a persistent > TLS connection being maintained is high, and the cost of establishing a > new > one is relatively low, especially if, as on another thread, one of the > things a federation means is a CA signing certs for use by the federation. > The number of peers is going to be relatively low, improving the > probability > of the persistent TLS connection being available. >=20 > Brian >=20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Tuesday, June 27, 2006 9:48 PM > To: Medhavi Bhatia; Reinaldo Penno > Cc: speermint@ietf.org > Subject: RE: TLS for peering (was RE: Comments (RE: > [speermint]requirementsdraft submitted)) >=20 > TLS is becoming more and more a subject when the topic of SIP > interconnections arises for me professionally. This shows growing > momentum indeed. With that said, I can not agree with TLS as a > steadfast requirement. Economics and scale are my major concerns. TLS > adds cost, server load, and there are fail-over issues to consider as > well. For the person that designs an interconnect, I believe weighing > the cost against the benefit of the different models a useful exercise. > Mandating TLS, even if all parties involved in a peering arrangement > feel somehow "safe and secure" due to underlying security mechanisms > (L2/L3VPNs, etc), seems a little harsh. >=20 > Adam >=20 > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@3clogic.com] > Sent: Tuesday, June 27, 2006 8:44 PM > To: Reinaldo Penno > Cc: speermint@ietf.org > Subject: Re: TLS for peering (was RE: Comments (RE: [speermint] > requirementsdraft submitted)) >=20 > I am not a provider yet, but I think we dont need to mess with TLS/TCP. > As I understand one of the goals is to prevent the calls from failing > due to "peering only" reasons. This means that things like codecs which > are not negotiated by the peers need to be mandated at a minimal level. > TCP/TLS can be negotiated between the peers themselves so it is a > non-issue. Also as I still understand doing a high volume calls with TLS > is still expensive. Mandating TLS in cases where the caller or callee > dont require it doesnt seem to add any value. >=20 > -Medhavi. >=20 > On 6/27/06, Reinaldo Penno wrote: > > > > TLS for _all_ scenarios? Even in private peerings, physically secure > > peerings, etc? > > > > Isn't that the same as requiring IPsec for all layer 3 peering? But > > since Layer 5 peering might be more distributed, the number of TLS > > sessions would be huge. > > > > It would be good to hear the provider's opinion on this... > > > > Thanks, > > > > Reinaldo > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, June 27, 2006 2:12 PM > > > To: 'Jean-Francois Mule'; Reinaldo Penno > > > Cc: speermint@ietf.org > > > Subject: RE: Comments (RE: [speermint] requirements draft submitted) > > > > > > > > > > > "3.4. Security requirements > > > > > > > > All SIP messages MUST be sent over TLS [RFC3546] to provide > > > > transport-layer security as defined in RFC 3261," > > > > > > > > Giving the fact that we can have security through physical > > > segregation, > > > > intra-federation/provider calls, etc, the "MUST" here seems too > > > > generic. > > > > > > I tend to differ on this: it is not because you have lower layer > > > security (presumably hop by hop security associations) that you > > > should relax the end-to-end transport security requirements. > > > Rohan's well written draft is also in favor of mandatory support of > > TLS, > > > and so is the SIP Forum's IP PBX to VSP (here is a working link: > > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_In > > te > > > rop-sibley-final.pdf). > > > May be the requirement should be rewritten to put the MUST on SIP > > > entities involved in L5 peering. > > > > > > I'm in favor of requiring TLS. I'd say MUST in a heartbeat. > > > > > > Brian > > > > _______________________________________________ > > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 29 12:38:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvzX1-00058j-Dm; Thu, 29 Jun 2006 12:38:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvzX0-00058e-Oa for speermint@ietf.org; Thu, 29 Jun 2006 12:38:18 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvzWz-0006cm-Ew for speermint@ietf.org; Thu, 29 Jun 2006 12:38:18 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 29 Jun 2006 09:38:16 -0700 X-IronPort-AV: i="4.06,192,1149490800"; d="scan'208"; a="558893741:sNHT30986092" 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: Thu, 29 Jun 2006 12:38:15 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804B9E289@proton.jnpr.net> In-Reply-To: <01ec01c69b20$998f6c50$23f0a544@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Thread-Index: Acaa+VnBRcdEnLXWRMiY93iCtTwjCgAAXlTQAAFXrpAAB6qYcAAe1NoA From: "Reinaldo Penno" To: , "Daryl Malas" X-Spam-Score: 0.0 (/) 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 No, it will not be deprecated. TLS must be supported as one of the options, but mandating its use is another issue. There are many ways to establish trust. > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Wednesday, June 28, 2006 7:06 PM > To: Reinaldo Penno; 'Daryl Malas' > Cc: speermint@ietf.org; 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam' > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraftsubmitted)) >=20 >=20 >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Wednesday, June 28, 2006 6:21 PM > > To: richard@shockey.us; Daryl Malas > > Cc: speermint@ietf.org; Khan, Sohel Q [CTO]; Uzelac, Adam > > Subject: RE: TLS for peering (was RE: > > Comments(RE:[speermint]requirementsdraftsubmitted)) > > > > The following security 'models' come to mind: > > > > 1 - TLS > > 2 - IPSec > > 3 - Physical security > > 4 - Access lists > > 5 - Registrations > > 6 - others? > > > > TLS just like the other methods has pros and cons that should be > > weighted by the persons that will actually use it. >=20 > But it cannot be deprecated. It MUST be supported. Its part of the core > SIP > standard you cannot side step this issue. >=20 > > > > I hope we can agree with that. >=20 >=20 > This is exactly where we begin to make progress. Define the reasonable > security/trust models including TLS that we can find consensus on, the > smaller the list the better. >=20 > This is really the core problem in spearmint. What is the ultimate > trust/security model that service providers can rely on to accept traffic > across domain boundaries. >=20 > Are you really BT or Sprint or FT or Cablevision etc. Or are you really > IBM > or Ford or Bombardier or Sony for that matter. Can I bill you for your > traffic? How do I know you are who you say you are. >=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 Jun 29 20:05:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw6Vi-0007nM-55; Thu, 29 Jun 2006 20:05:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw6Vg-0007nH-QH for speermint@ietf.org; Thu, 29 Jun 2006 20:05:24 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw6Vf-0006H3-IU for speermint@ietf.org; Thu, 29 Jun 2006 20:05:24 -0400 Received: by py-out-1112.google.com with SMTP id m51so500592pye for ; Thu, 29 Jun 2006 17:05:23 -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=f2UBIUs4BcWCvA5+rWyN4RUG7t/rbb9ez9Z9rbu53mWt9Y6MoJVEmnvaGYJbdEbofE/TfL676Ihp9yTMGjII4RuROQsOvHFu7lzAHEaF6pMp6IVE1RCJCzMyVpOA1vuaQ7KwKP6AmZ8iWGBuiO23RyD/3cFHUTV+OM6jbksWi+k= Received: by 10.35.101.9 with SMTP id d9mr60766pym; Thu, 29 Jun 2006 17:05:23 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Thu, 29 Jun 2006 17:05:23 -0700 (PDT) Message-ID: <953beacc0606291705j603aa36fwb08b9f0687fb7150@mail.gmail.com> Date: Thu, 29 Jun 2006 17:05:23 -0700 From: "Rohan Mahy" To: "Andrew Newton" Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) In-Reply-To: <732EB664-954E-410E-A7BD-9F53D350F119@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> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 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 From speermint-bounces@ietf.org Thu Jun 29 20:20:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw6kZ-0000ZN-7N; Thu, 29 Jun 2006 20:20:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw6kY-0000ZI-Ex for speermint@ietf.org; Thu, 29 Jun 2006 20:20:46 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw6kW-0007Ot-8P for speermint@ietf.org; Thu, 29 Jun 2006 20:20:46 -0400 Received: by py-out-1112.google.com with SMTP id m51so503742pye for ; Thu, 29 Jun 2006 17:20:43 -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=NZA3rlTVe1jOCoSSemFusFvbUQOY9DDZwyKNMVxfAZIhPo/6qK7yMD8z8dZm+In3WNFRGhYsd4p40tX1pbs7xIl/CtZgHtgSQGlbMwJiJy/T6A2Pz6WOqoTrNC2ke2jhXCDd13wPXefs5gB0ZMBL/TkULqgmWhFm9PaiHXYgCrI= Received: by 10.35.93.15 with SMTP id v15mr76137pyl; Thu, 29 Jun 2006 17:20:43 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Thu, 29 Jun 2006 17:20:43 -0700 (PDT) Message-ID: <953beacc0606291720pc45d3b0mb5e7da3078c3cf9d@mail.gmail.com> Date: Thu, 29 Jun 2006 17:20:43 -0700 From: "Rohan Mahy" To: "Reinaldo Penno" Subject: Re: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804B9E1D5@proton.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <024e01c69afa$c89c3620$4d201f0a@cis.neustar.com> <9BD5D7887235424FA97DFC223CAE3C2804B9E1D5@proton.jnpr.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: speermint@ietf.org, "Khan, Sohel Q \[CTO\]" , "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 6/28/06, Reinaldo Penno wrote: > Shoving down the throats of people an operational requirement that will > increase the cost of a deployment is not the way to go. IETF is about > running code and consensus. Can you prove to this group that TLS would cost more than using IPsec? than using a private walled garden network? Can you describe a model where this begins to look expensive compared to all the other various boxes SPs are installing. Where are your requirements? > Are you going to suggest secure RTP as well between every single call on > the planet? I certainly won't. The attack isn't as relevant as the attack on the signaling channel. thanks, -rohan _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 29 20:29:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw6t5-0002p5-Cw; Thu, 29 Jun 2006 20:29:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw6t4-0002oi-AQ for speermint@ietf.org; Thu, 29 Jun 2006 20:29:34 -0400 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fw6t1-0007b8-UB for speermint@ietf.org; Thu, 29 Jun 2006 20:29:34 -0400 Received: (qmail 26295 invoked from network); 30 Jun 2006 00:27:44 -0000 Received: from dsl254-017-242.sea1.dsl.speakeasy.net (HELO ?172.16.100.251?) (ben@216.254.17.242) by layer8.net with SMTP; 30 Jun 2006 00:27:44 -0000 In-Reply-To: <953beacc0606291705j603aa36fwb08b9f0687fb7150@mail.gmail.com> References: <00ae01c69ae3$70cc78e0$4d201f0a@cis.neustar.com> <732EB664-954E-410E-A7BD-9F53D350F119@hxr.us> <953beacc0606291705j603aa36fwb08b9f0687fb7150@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0BFA99D8-CD4E-4844-ADBF-0AC09DF3A07A@layer8.net> Content-Transfer-Encoding: 7bit From: Benjamin Black Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) Date: Thu, 29 Jun 2006 17:29:32 -0700 To: Rohan Mahy X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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, i don't think it is sufficient to simply make tls a requirement. what is the problem you are trying to solve using tls? given that, what are the specific features/options of tls that minimally solve that problem? for example, eNULL encryption may not be appropriate, 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 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 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 Thu Jun 29 20:40:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw73r-0001kf-MD; Thu, 29 Jun 2006 20:40:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw73q-0001kZ-1F for speermint@ietf.org; Thu, 29 Jun 2006 20:40:42 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw73n-0001Pt-ML for speermint@ietf.org; Thu, 29 Jun 2006 20:40:42 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 29 Jun 2006 17:40:38 -0700 X-IronPort-AV: i="4.06,193,1149490800"; d="scan'208"; a="558986745:sNHT31965292" 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]requirementsdraft submitted)) Date: Thu, 29 Jun 2006 20:40:36 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804B9E378@proton.jnpr.net> In-Reply-To: <953beacc0606291705j603aa36fwb08b9f0687fb7150@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Thread-Index: Acab2PFtF6l3pt2gRhS04KNSLblXoAAATLBw From: "Reinaldo Penno" To: "Rohan Mahy" , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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, I'm okay with TLS as long as there are alternatives, but you email seems contradictory. You complain of rhetoric, but (1) " much, much more expensive in terms of both capital equipment and operationally than just using TLS ",=20 (2) " A $2000 rack mount server can encrypt and decrypt a phenominal volume of TLS traffic",=20 (3) " by another couple of orders of magnitude",=20 Can you provide quantitative data instead of, you know...rhetoric? I'll be very interested on reading some serious data on (1) above and the number of TLS _connections per second_ on a $2000 rack server. As for the beers, are you saying the number of TLS _connections per second_ on the Internet today is greater than the number of calls in the PSTN? Worldwide? That would be an interesting bet. Have any numbers on that? Thanks, Reinaldo > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com] > Sent: Thursday, June 29, 2006 5: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)) >=20 > Andy, >=20 > 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. >=20 > 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. >=20 > 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. >=20 > To those who have a problem with TLS, I ask them to provide some > quantitative data or real requirements rather than 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 > > > 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 > > >=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 Jun 29 20:48:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw7BG-0007oU-CA; Thu, 29 Jun 2006 20:48:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw7BF-0007lG-Pp for speermint@ietf.org; Thu, 29 Jun 2006 20:48:21 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw7BE-0002wS-HI for speermint@ietf.org; Thu, 29 Jun 2006 20:48:21 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 29 Jun 2006 17:48:20 -0700 X-IronPort-AV: i="4.06,193,1149490800"; d="scan'208"; a="564012234:sNHT30074356" 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]requirementsdraft submitted)) Date: Thu, 29 Jun 2006 20:48:16 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804B9E379@proton.jnpr.net> In-Reply-To: <953beacc0606291720pc45d3b0mb5e7da3078c3cf9d@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Thread-Index: Acab2xA60lxC9srgQky2R8Sivd2S+QAAsEYw From: "Reinaldo Penno" To: "Rohan Mahy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: speermint@ietf.org, "Khan, Sohel Q \[CTO\]" , "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, There is no need to resort to these kinds of personal statements. The burden of the proof does not need to be on me.=20 As with any scientific discussion, I'm validating the other side. What I'm hearing is that people say TLS is faster, securer, cheaper...than _any_ alternative. What is wrong in trying to validate that? Or asking where is the data to prove that?=20 Thanks, Reinaldo=20 > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com] > Sent: Thursday, June 29, 2006 5:21 PM > To: Reinaldo Penno > Cc: richard@shockey.us; Andrew Newton; Khan, Sohel Q [CTO]; > speermint@ietf.org; Uzelac, Adam > Subject: Re: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraft submitted)) >=20 > On 6/28/06, Reinaldo Penno wrote: > > Shoving down the throats of people an operational requirement that will > > increase the cost of a deployment is not the way to go. IETF is about > > running code and consensus. >=20 > Can you prove to this group that TLS would cost more than using IPsec? > than using a private walled garden network? Can you describe a model > where this begins to look expensive compared to all the other various > boxes SPs are installing. Where are your requirements? >=20 > > Are you going to suggest secure RTP as well between every single call on > > the planet? >=20 > I certainly won't. The attack isn't as relevant as the attack on the > signaling channel. >=20 > thanks, > -rohan _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 29 21:02:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw7Oy-0000cf-IX; Thu, 29 Jun 2006 21:02:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw7Ox-0000ca-5k for speermint@ietf.org; Thu, 29 Jun 2006 21:02:31 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw7Ov-0003VP-OC for speermint@ietf.org; Thu, 29 Jun 2006 21:02:31 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5U12iiU010832; Thu, 29 Jun 2006 18:02:45 -0700 From: "Richard Shockey" To: "'Benjamin Black'" , "'Rohan Mahy'" Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Date: Thu, 29 Jun 2006 21:02:18 -0400 Message-ID: <013501c69be0$d67b6b30$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acab3FUhf9K5J3CpRG6tu8cqs2JyFAAAe4hA In-Reply-To: <0BFA99D8-CD4E-4844-ADBF-0AC09DF3A07A@layer8.net> 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: 6d95a152022472c7d6cdf886a0424dc6 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: 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? Face the music you will support TLS whether you like it or 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. Hello here... SIP signaling security, preventing MIM attacks, trust relationships between domain bountries do you want a longer list of why you need SIP security? This whole thread is highlighting the central problem this 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. OK if you are a GSM network you figured this out already ..create a totally private internet with completely private points of interconnection and within a the great wall of GSM you have security. It works ..is that the model you want? Brother Rohan is spot on here. CPU cycles are cheep considering what the requirements for security here are. I just don't get it why does everyone so dislikes TLS..its simple proven to scale and it works. Frankly I think the chairs need to step in here and drive a little consensus that without a robust security/trust model defined ASAP for speermint all other discussions are futile and a waste of time. given that, > what are the specific features/options of tls that minimally solve > that problem? for example, eNULL encryption may not be appropriate, > 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 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 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 From speermint-bounces@ietf.org Thu Jun 29 21:14:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw7aN-0003wr-I9; Thu, 29 Jun 2006 21:14:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw7aM-0003wm-MN for speermint@ietf.org; Thu, 29 Jun 2006 21:14:18 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw7aM-0003mO-7I for speermint@ietf.org; Thu, 29 Jun 2006 21:14:18 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 29 Jun 2006 18:14:17 -0700 X-IronPort-AV: i="4.06,193,1149490800"; d="scan'208"; a="564016496:sNHT35487740" 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: Thu, 29 Jun 2006 21:14:13 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804B9E380@proton.jnpr.net> In-Reply-To: <013501c69be0$d67b6b30$23f0a544@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraftsubmitted)) Thread-Index: Acab3FUhf9K5J3CpRG6tu8cqs2JyFAAAe4hAAAEKwwA= From: "Reinaldo Penno" To: , "Benjamin Black" , "Rohan Mahy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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 IMO TLS must be supported but we should spell out the alternatives. > -----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 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 > 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 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 > totally > private internet with completely private points of interconnection and > within a the great wall of GSM you have 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 > consensus > that without a robust security/trust model defined ASAP for 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 minimally solve > > that problem? for example, eNULL encryption may not be appropriate, > > 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 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 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 >=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 Jun 29 21:15:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw7bd-0005ct-5s; Thu, 29 Jun 2006 21:15:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw7bc-0005co-Al for speermint@ietf.org; Thu, 29 Jun 2006 21:15:36 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw7ba-0003nf-Vb for speermint@ietf.org; Thu, 29 Jun 2006 21:15:36 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5U1FeiE015593; Thu, 29 Jun 2006 18:15:40 -0700 From: "Richard Shockey" To: "'Rohan Mahy'" , "'Reinaldo Penno'" Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Date: Thu, 29 Jun 2006 21:15:16 -0400 Message-ID: <013901c69be2$a619ca20$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acab2xgI6bju94xCTK6sNAdcn5r3DwABjbKA In-Reply-To: <953beacc0606291720pc45d3b0mb5e7da3078c3cf9d@mail.gmail.com> 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: 769a46790fb42fbb0b0cc700c82f7081 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 Right on Brother Rohan .. protection of the 5060 signaling channel is much more important than the RTP media stream. > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com] > Sent: Thursday, June 29, 2006 8:21 PM > To: Reinaldo Penno > Cc: richard@shockey.us; Andrew Newton; Khan, Sohel Q [CTO]; > speermint@ietf.org; Uzelac, Adam > Subject: Re: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraft submitted)) > > On 6/28/06, Reinaldo Penno wrote: > > Shoving down the throats of people an operational requirement that will > > increase the cost of a deployment is not the way to go. IETF is about > > running code and consensus. > > Can you prove to this group that TLS would cost more than using IPsec? > than using a private walled garden network? Can you describe a model > where this begins to look expensive compared to all the other various > boxes SPs are installing. Where are your requirements? Well here is my requirement you cannot have interconnection between service providers without securing and authenticating the source of the SIP 5060 signaling data. We know TLS works. That is why it is in the SIP standard. That is why it MUST be supported. The burden of proof is now on you and others to describe what other security/trust models you want supported and the risks associated with them. And those methods should either match or exceed the capabilities of TLS. > > > Are you going to suggest secure RTP as well between every single call on > > the planet? > > I certainly won't. The attack isn't as relevant as the attack on the > signaling channel. > > thanks, > -rohan _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 29 21:39:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw7yn-0003YL-Qe; Thu, 29 Jun 2006 21:39:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw7yn-0003YG-2B for speermint@ietf.org; Thu, 29 Jun 2006 21:39:33 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw7yl-0005QG-Oo for speermint@ietf.org; Thu, 29 Jun 2006 21:39:33 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 29 Jun 2006 18:39:31 -0700 X-IronPort-AV: i="4.06,193,1149490800"; d="scan'208"; a="564020391:sNHT31690168" 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]requirementsdraft submitted)) Date: Thu, 29 Jun 2006 21:39:26 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804B9E387@proton.jnpr.net> In-Reply-To: <013901c69be2$a619ca20$23f0a544@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Thread-Index: Acab2xgI6bju94xCTK6sNAdcn5r3DwABjbKAAADawyA= From: "Reinaldo Penno" To: , "Rohan Mahy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 did not know there was some kind strange brotherhood going on here but... > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Thursday, June 29, 2006 6:15 PM > To: 'Rohan Mahy'; Reinaldo Penno > Cc: 'Andrew Newton'; 'Khan, Sohel Q [CTO]'; speermint@ietf.org; 'Uzelac, > Adam' > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraft submitted)) >=20 >=20 > Right on Brother Rohan .. protection of the 5060 signaling channel is much > more important than the RTP media stream. >=20 >=20 >=20 > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan.mahy@gmail.com] > > Sent: Thursday, June 29, 2006 8:21 PM > > To: Reinaldo Penno > > Cc: richard@shockey.us; Andrew Newton; Khan, Sohel Q [CTO]; > > speermint@ietf.org; Uzelac, Adam > > Subject: Re: TLS for peering (was RE: > > Comments(RE:[speermint]requirementsdraft submitted)) > > > > On 6/28/06, Reinaldo Penno wrote: > > > Shoving down the throats of people an operational requirement that > will > > > increase the cost of a deployment is not the way to go. IETF is about > > > running code and consensus. > > > > Can you prove to this group that TLS would cost more than using IPsec? > > than using a private walled garden network? Can you describe a model > > where this begins to look expensive compared to all the other various > > boxes SPs are installing. Where are your requirements? >=20 >=20 > Well here is my requirement you cannot have interconnection between > service > providers without securing and authenticating the source of the SIP 5060 > signaling data. [[Reinaldo]]=20 huh? There are plenty of VoIP peering today without TLS. They seem to be working. Are they not? The concept of securing and trust is the one that matters between service providers. If they think physical security is okay, then that is good enough for them.=20 >=20 > We know TLS works. That is why it is in the SIP standard. That is why it > MUST be supported. >=20 > The burden of proof is now on you and others to describe what other > security/trust models you want supported and the risks associated with > them. > And those methods should either match or exceed the capabilities of TLS. >=20 >=20 [[Reinaldo]]=20 Not really. They only need to be alternatives for people that when peer do not need TLS. There are many small enterprises; small carriers that do not want, cannot afford Tor do not have the expertise to deal with LS. This is true especially outside the US. There is life outside the rich and powerful providers. > > > > > Are you going to suggest secure RTP as well between every single call > on > > > the planet? > > > > I certainly won't. The attack isn't as relevant as the attack on the > > signaling channel. > > > > thanks, > > -rohan _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 29 21:52:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw8Bk-0004Pc-GI; Thu, 29 Jun 2006 21:52:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw8Bj-0004PX-8M for speermint@ietf.org; Thu, 29 Jun 2006 21:52:55 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw8Bh-0007E9-Sh for speermint@ietf.org; Thu, 29 Jun 2006 21:52:55 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5U1r5UJ000854; Thu, 29 Jun 2006 18:53:05 -0700 From: "Richard Shockey" To: "'Reinaldo Penno'" , "'Rohan Mahy'" Subject: RE: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Date: Thu, 29 Jun 2006 21:52:35 -0400 Message-ID: <014101c69be7$dc80b150$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acab2xgI6bju94xCTK6sNAdcn5r3DwABjbKAAADawyAAALqNMA== In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804B9E387@proton.jnpr.net> 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: d6b246023072368de71562c0ab503126 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: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, June 29, 2006 9:39 PM > To: richard@shockey.us; Rohan Mahy > Cc: Andrew Newton; Khan, Sohel Q [CTO]; speermint@ietf.org; Uzelac, Adam > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraft submitted)) > > I did not know there was some kind strange brotherhood going on here > but... You never heard of the SIP Mafia? _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 29 21:56:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw8F2-0004qQ-A3; Thu, 29 Jun 2006 21:56:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw8F1-0004qL-9a for speermint@ietf.org; Thu, 29 Jun 2006 21:56:19 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw8F0-0007zt-1O for speermint@ietf.org; Thu, 29 Jun 2006 21:56:19 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 29 Jun 2006 18:56:17 -0700 X-IronPort-AV: i="4.06,193,1149490800"; d="scan'208"; a="558997042:sNHT29578536" 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]requirementsdraft submitted)) Date: Thu, 29 Jun 2006 21:56:12 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804B9E38C@proton.jnpr.net> In-Reply-To: <014101c69be7$dc80b150$23f0a544@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Thread-Index: Acab2xgI6bju94xCTK6sNAdcn5r3DwABjbKAAADawyAAALqNMAAAGa3Q From: "Reinaldo Penno" To: , "Rohan Mahy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Sorry Don Shockley....I will have you TLS ready by next week...I promise (:-) > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Thursday, June 29, 2006 6:53 PM > To: Reinaldo Penno; 'Rohan Mahy' > Cc: 'Andrew Newton'; 'Khan, Sohel Q [CTO]'; speermint@ietf.org; 'Uzelac, > Adam' > Subject: RE: TLS for peering (was RE: > Comments(RE:[speermint]requirementsdraft submitted)) >=20 >=20 >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, June 29, 2006 9:39 PM > > To: richard@shockey.us; Rohan Mahy > > Cc: Andrew Newton; Khan, Sohel Q [CTO]; speermint@ietf.org; Uzelac, Adam > > Subject: RE: TLS for peering (was RE: > > Comments(RE:[speermint]requirementsdraft submitted)) > > > > I did not know there was some kind strange brotherhood going on here > > but... >=20 >=20 > You never heard of the SIP Mafia? >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 29 22:17:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw8Z8-0006mz-00; Thu, 29 Jun 2006 22:17:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw8Z5-0006mu-SL for speermint@ietf.org; Thu, 29 Jun 2006 22:17:03 -0400 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fw8Z4-0000ly-FK for speermint@ietf.org; Thu, 29 Jun 2006 22:17:03 -0400 Received: (qmail 30719 invoked from network); 30 Jun 2006 02:08:33 -0000 Received: from dsl254-017-242.sea1.dsl.speakeasy.net (HELO ?172.16.100.251?) (ben@216.254.17.242) by layer8.net with SMTP; 30 Jun 2006 02:08:33 -0000 In-Reply-To: <013501c69be0$d67b6b30$23f0a544@cis.neustar.com> References: <013501c69be0$d67b6b30$23f0a544@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <999F61EE-9579-43FB-9C42-7C9C0B428475@layer8.net> Content-Transfer-Encoding: 7bit From: Benjamin Black Subject: Re: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Date: Thu, 29 Jun 2006 19:10:16 -0700 To: X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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 richard, i agree 100%. this is really important. so important, in fact, that the requirements should be clearly stated so the problem is actually solved. tls _can_ be an extremely powerful tool, but simply requiring its use is insufficient to achieve the goals of this working group, imo. thanks, ben On Jun 29, 2006, at 6:02 PM, Richard Shockey wrote: > > >> -----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? > > Face the music you will support TLS whether you like it or 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. > > Hello here... SIP signaling security, preventing MIM attacks, trust > relationships between domain bountries do you want a longer list of > why you > need SIP security? > > This whole thread is highlighting the central problem this 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. > > OK if you are a GSM network you figured this out already ..create a > totally > private internet with completely private points of interconnection and > within a the great wall of GSM you have security. > > It works ..is that the model you want? > > Brother Rohan is spot on here. CPU cycles are cheep considering > what the > requirements for security here are. > > I just don't get it why does everyone so dislikes TLS..its simple > proven to > scale and it works. > > Frankly I think the chairs need to step in here and drive a little > consensus > that without a robust security/trust model defined ASAP for > speermint all > other discussions are futile and a waste of time. > > > > > given that, >> what are the specific features/options of tls that minimally solve >> that problem? for example, eNULL encryption may not be appropriate, >> 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 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 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 From speermint-bounces@ietf.org Fri Jun 30 10:02:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJZU-0008Iv-4e; Fri, 30 Jun 2006 10:02:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJZT-0008Iq-0M for speermint@ietf.org; Fri, 30 Jun 2006 10:02:11 -0400 Received: from services.erkkila.org ([24.97.94.217] helo=erkkila.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwJZR-0001L0-On for speermint@ietf.org; Fri, 30 Jun 2006 10:02:10 -0400 Received: from [10.1.1.226] (dhcp226.dhcp.erkkila.org [::ffff:10.1.1.226]) (AUTH: PLAIN pee@erkkila.org, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by erkkila.org with esmtp; Fri, 30 Jun 2006 13:57:01 +0000 id 0020345C.44A52DAD.0000733A Message-ID: <44A52DC4.1040105@erkkila.org> Date: Fri, 30 Jun 2006 13:57:24 +0000 From: Paul Erkkila User-Agent: Mail/News 1.5.0.5 (X11/20060628) MIME-Version: 1.0 To: richard@shockey.us Subject: Re: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) References: <013901c69be2$a619ca20$23f0a544@cis.neustar.com> In-Reply-To: <013901c69be2$a619ca20$23f0a544@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: 9466e0365fc95844abaf7c3f15a05c7d 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 From a customer point of view, I'm sure they would rather we kept our signaling protected, AND kept their calls private. Fraud charge handling and billing problems (sadly) are almost expected by customers these days, this is aggravation for sure; but not a customer loss for the most part. Having their intimate chats with kids/mom/dog (or other bits) recorded and punted around the internet is a lost customer, loss of face for the provider, and probably ends up with lawyers involved. So protecting signaling certainly helps protect the bearer(s), but I don't think I would put it MUCH higher then the data, maybe just a wee bit higher ;). Most customers pay for the service after all, not the implementation. As far as my input into the requirement for TLS as a method of establishing trust between peers, I agree with it as long as there are other allowable methods. -pee Richard Shockey wrote: > Right on Brother Rohan .. protection of the 5060 signaling channel is much > more important than the RTP media stream. > > > >> -----Original Message----- > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 30 10:03:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJb2-0008PP-KX; Fri, 30 Jun 2006 10:03:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJb1-0008PK-Td for speermint@ietf.org; Fri, 30 Jun 2006 10:03:47 -0400 Received: from services.erkkila.org ([24.97.94.217] helo=erkkila.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwJb0-0001Ms-M2 for speermint@ietf.org; Fri, 30 Jun 2006 10:03:47 -0400 Received: from [10.1.1.226] (dhcp226.dhcp.erkkila.org [::ffff:10.1.1.226]) (AUTH: PLAIN pee@erkkila.org, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by erkkila.org with esmtp; Fri, 30 Jun 2006 14:03:42 +0000 id 0020345C.44A52F3E.0000744D Message-ID: <44A52F56.2010203@erkkila.org> Date: Fri, 30 Jun 2006 14:04:06 +0000 From: Paul Erkkila User-Agent: Mail/News 1.5.0.5 (X11/20060628) 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: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Mahy wrote: > To those who have a problem with TLS, I ask them to provide some > quantitative data or real requirements rather than rhetoric and FUD. > Here's a single point of data for you. Number of devices in our voip network that handle TLS connections with their current hardware and software configurations: => 0. I'm not defending anyone so don't bother with the "pick a different vendor(s)" replies =). There has been limited demand for TCP/TLS to the equipment vendors, so consequently there has been limited development into supporting it (everyone is *working on it*). It could be a reasonable BCP from this group helps accelerate that process. -pee > thanks, > -rohan > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 30 10:14:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJlh-0001ZL-SE; Fri, 30 Jun 2006 10:14:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJlg-0001ZG-B7 for speermint@ietf.org; Fri, 30 Jun 2006 10:14:48 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwJle-0001ac-Uw for speermint@ietf.org; Fri, 30 Jun 2006 10:14:48 -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 k5UEF2ns032429; Fri, 30 Jun 2006 07:15:03 -0700 From: "Richard Shockey" To: "'Rohan Mahy'" , "'Andrew Newton'" Subject: RE: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) Date: Fri, 30 Jun 2006 10:14:34 -0400 Message-ID: <00f401c69c4f$83b25610$4d201f0a@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: Acab2PMTCIPN8sImTxyo/hi6uxDcSgAdKLCA In-Reply-To: <953beacc0606291705j603aa36fwb08b9f0687fb7150@mail.gmail.com> 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: 0ddefe323dd869ab027dbfff7eff0465 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 > 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. A pretty good bet if I do say so. Its tough to break out per transactions but the underlying supposition is that there is a heck of a lot of TLS going on. Well the numbers are huge no matter how you count them. Basic stats are that on the basis of 162M US access lines in 2004 generated 422.4 Billion access minutes of which 81 B of those were toll calls. Due to LNP and other network issues everyone of those requires a form of SS7 dip. ( FCC ) Ecommerce stats are now Total Worldwide eCommerce Revenues, 2004 (B2B & B2C) Region Total North America $3.5 trillion Asia Pacific $1.6 trillion Western Europe $1.5 trillion Latin America $81.8 billion Rest of World $68.6 billion Source: Forrester Research Payment Types In The US, 2005 - 2010 Volume ($ trillion) 2005 2010 Paper $3.4 (50%) $3.6 (36%) Cards $2.7 (39%) $4.3 (49%) Electronic $0.7 (11%) $1.3 (15%) Total $6.8 (100%) $8.7 (100%) Source: The Nilson Report > > 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 > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 30 10:37:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwK7T-0006h1-Df; Fri, 30 Jun 2006 10:37:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwK7S-0006gr-SB for speermint@ietf.org; Fri, 30 Jun 2006 10:37:18 -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 1FwK7S-0002Kh-Qf for speermint@ietf.org; Fri, 30 Jun 2006 10:37:18 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FwK1H-0006aL-1T for speermint@ietf.org; Fri, 30 Jun 2006 10:30:56 -0400 Received: from [10.0.1.105] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 30 Jun 2006 10:31:03 -0400 id 01588118.44A535A7.00000AC4 In-Reply-To: <953beacc0606291705j603aa36fwb08b9f0687fb7150@mail.gmail.com> References: <00ae01c69ae3$70cc78e0$4d201f0a@cis.neustar.com> <732EB664-954E-410E-A7BD-9F53D350F119@hxr.us> <953beacc0606291705j603aa36fwb08b9f0687fb7150@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6A4304EA-845D-4120-B0F4-FDC390334328@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) Date: Fri, 30 Jun 2006 10:30:42 -0400 To: Rohan Mahy X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.6 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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, 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. 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? 2) Why do you believe TLS offers better authentication than any other method, especially given that there is no global trust anchor? 3) What requirement makes TLS more secure than a dedicated link? 4) What requirement makes TLS more secure than IPSec? 5) Given that providers interconnect today without TLS, what requirement is not met by the current interconnection methods that TLS will provide? 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. -andy On Jun 29, 2006, at 8:05 PM, 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 From speermint-bounces@ietf.org Fri Jun 30 10:47:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKHb-0007tH-Vz; Fri, 30 Jun 2006 10:47:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKHa-0007sy-V6 for speermint@ietf.org; Fri, 30 Jun 2006 10:47:46 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwKHZ-0003KS-Il for speermint@ietf.org; Fri, 30 Jun 2006 10:47:46 -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 k5UElgHw005759; Fri, 30 Jun 2006 07:47:42 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k5UElglQ005758; Fri, 30 Jun 2006 07:47:42 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 30 Jun 2006 07:47:42 -0700 From: David Meyer To: Richard Shockey Subject: Re: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Message-ID: <20060630144742.GA3330@1-4-5.net> References: <0BFA99D8-CD4E-4844-ADBF-0AC09DF3A07A@layer8.net> <013501c69be0$d67b6b30$23f0a544@cis.neustar.com> Mime-Version: 1.0 In-Reply-To: <013501c69be0$d67b6b30$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: cd26b070c2577ac175cd3a6d878c6248 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="===============0595410160==" Errors-To: speermint-bounces@ietf.org --===============0595410160== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 29, 2006 at 09:02:18PM -0400, Richard Shockey wrote: >=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)) > >=20 > > rohan, > >=20 > > 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 >=20 > Face the music you will support TLS whether you like it or 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 > relationships between domain bountries do you want a longer list of why y= ou > need SIP security? >=20 > This whole thread is highlighting the central problem this 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 total= ly > private internet with completely private points of interconnection and > within a the great wall of GSM you have security. >=20 > It works ..is that the model you want? =20 >=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 consen= sus > that without a robust security/trust model defined ASAP for speermint all > other discussions are futile and a waste of time. Thanks for the prompting Richard. FYI, one of the things we've been discussing to address this is a "speermint security considerations" document, on the theory that rather that thrashing around as we've been doing, we'll have a concrete piece of work that we can discuss.=20 --dmm --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEpTmNORgD1qCZ2KcRAoXaAKCB/k7zVpYNgZ/bWuEKSXa4VNY6TwCfR23v brxeUgOmvryJkG7gRgR4k8E= =w9pF -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- --===============0595410160== 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 --===============0595410160==-- From speermint-bounces@ietf.org Fri Jun 30 11:27:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKtb-00034r-PE; Fri, 30 Jun 2006 11:27:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKta-00034Z-22 for speermint@ietf.org; Fri, 30 Jun 2006 11:27:02 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwKtY-0005ZP-Jw for speermint@ietf.org; Fri, 30 Jun 2006 11:27:02 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k5UFQvdm013183; Fri, 30 Jun 2006 08:26:57 -0700 Received: from OVE1WNEXCB02.vcorp.ad.vrsn.com ([10.60.13.34]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 08:26:46 -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]requirementsdraft submitted)) Date: Fri, 30 Jun 2006 10:26:55 -0500 Message-ID: <122A5731B827474C99ED552C6BFE23ED30CF07@OVE1WNEXCB02.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Thread-Index: AcacUq5Lyo2SeavKQOq8o06Z4WkTnwABmfFw From: "McCandless, Kevin" To: "Andrew Newton" , "Rohan Mahy" X-OriginalArrivalTime: 30 Jun 2006 15:26:46.0119 (UTC) FILETIME=[9918A770:01C69C59] X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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 A voice of reason among the group. =20 We went through this very discussion, in Sigtran, and came out that IPSEC works just as well and left the choice to the implementers between IPSEC and TLS. Why not leverage this work? See RFC http://www.ietf.org/rfc/rfc3788.txt, especially sections 7 & 8. -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Friday, June 30, 2006 9:31 AM 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 am not a liberty to give specific numbers, but I can assure you =20 that your assumptions are wrong. We have a lot of very expensive =20 equipment that would fall over if it did all signaling over TLS or =20 even just TCP. And we have done the tests and measurements, and a =20 $2000 rack mount server cannot handle the load. And since you are asking for "real requirements", I'd like to know =20 what your "real requirements" are for specifying TLS for signaling. =20 Specifically, I'd like to know the following: 1) Why is it you are advocating security of the signaling but not the =20 media? What requirement determines that signaling is important to =20 secure but media is not important to secure? 2) Why do you believe TLS offers better authentication than any other =20 method, especially given that there is no global trust anchor? 3) What requirement makes TLS more secure than a dedicated link? 4) What requirement makes TLS more secure than IPSec? 5) Given that providers interconnect today without TLS, what =20 requirement is not met by the current interconnection methods that =20 TLS will provide? Don't get me wrong. I think all vendors should support TLS, and I =20 think providers and carriers should be able to have it at their =20 disposal when doing interconnection, but it is only one of many options. -andy On Jun 29, 2006, at 8:05 PM, 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 =20 >> 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 Jun 30 11:40:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwL6g-0004wJ-Uv; Fri, 30 Jun 2006 11:40:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwL6f-0004wE-WB for speermint@ietf.org; Fri, 30 Jun 2006 11:40:34 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwL6e-0006pF-Mu for speermint@ietf.org; Fri, 30 Jun 2006 11:40:33 -0400 Received: by py-out-1112.google.com with SMTP id b36so686778pyb for ; Fri, 30 Jun 2006 08:40: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=a6TE6kdkK2dKHXvnoIPptLeHS3hHyLmfgJadn9KMyXS6dAIfJtavPKdaHYWolpv3kv61fhww32Sp10Q0+a9HF1DULNJM55GNs2DVvr5mlXrrk9/z4hVH/pbU0qK+tYUDP66mF+TnzcajqB72w7/UnP6BvMp0c8ms8NTPFVoXP8A= Received: by 10.35.57.5 with SMTP id j5mr613730pyk; Fri, 30 Jun 2006 08:40:32 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Fri, 30 Jun 2006 08:40:32 -0700 (PDT) Message-ID: <953beacc0606300840h741d071cle64c12045a7de878@mail.gmail.com> Date: Fri, 30 Jun 2006 08:40:32 -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: e1b0e72ff1bbd457ceef31828f216a86 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 Andy, I am just leaving for a short vacation, but I will commit to answering your questions before the meeting in Montreal. I think these are good questions and I want to take the time to answer them properly. So that we can make apples to apples comparisons, it would be useful to start with an order of magnitude number of calls per day. This does not need to be Sunrocket's (or any other carrier's) actual current or expected peering traffic, but it should be plausible. thanks, -rohan 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. > > 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? > 2) Why do you believe TLS offers better authentication than any other > method, especially given that there is no global trust anchor? > 3) What requirement makes TLS more secure than a dedicated link? > 4) What requirement makes TLS more secure than IPSec? > 5) Given that providers interconnect today without TLS, what > requirement is not met by the current interconnection methods that > TLS will provide? > > 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. > > -andy > > On Jun 29, 2006, at 8:05 PM, 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 From speermint-bounces@ietf.org Fri Jun 30 11:42:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwL8U-000578-N7; Fri, 30 Jun 2006 11:42:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwL8T-00056u-H7 for speermint@ietf.org; Fri, 30 Jun 2006 11:42:25 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwL8S-00073Y-Vn for speermint@ietf.org; Fri, 30 Jun 2006 11:42:25 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 30 Jun 2006 08:42:24 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5UFgO0i018062; Fri, 30 Jun 2006 08:42:24 -0700 Received: from [192.168.1.2] (sjc-vpn2-416.cisco.com [10.21.113.160]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5UFgNke014932; Fri, 30 Jun 2006 08:42:23 -0700 (PDT) In-Reply-To: <44A52F56.2010203@erkkila.org> References: <00ae01c69ae3$70cc78e0$4d201f0a@cis.neustar.com> <732EB664-954E-410E-A7BD-9F53D350F119@hxr.us> <953beacc0606291705j603aa36fwb08b9f0687fb7150@mail.gmail.com> <44A52F56.2010203@erkkila.org> 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 Date: Fri, 30 Jun 2006 08:42:22 -0700 To: speermint@ietf.org X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=5948; t=1151682144; x=1152546144; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:TLS=20for=20peering=20-=20Just=20the=20facts=20please=20=3A-); X=v=3Dcisco.com=3B=20h=3Dd+kFZLAdjHwYdQsQi7NveSGLB3U=3D; b=iuY3dK2FtxBeQJCquqDbwP0LKtFey85LE6bvtmWrOgKXJdl0dEP5II5aQDQHo1MzCgEs6rNz lF9wBtMlXfkY2NzyXmckgKABPyLV/kDdOjJDNXUVhJuI2zSyz55QgRSP; Authentication-Results: sj-dkim-4.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: "Khan, Sohel Q \[\[CTO\]\]" , "Uzelac, Adam" Subject: [Speermint] TLS for peering - Just the facts please :-) 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 been involved with several TLS implementations for SIP including writing most the code for one and also some deployments. Sorry, I am not fully up to speed on this discussion of if I say something that has already been well covered, my apologies - there have been a few transaction on the topic :-) I'm don't know what this WG should choose but let me provide some information that might help.... Do vendors implement it? I don't have the exact numbers but I think at the last SIPit there was something like over 50 vendors that had TLS - we can get more details if needed. Every major vendor I am aware of has it on a proxy that would be used in this type of situations. It's actually pretty easy to support - don't confuse it with sips which is somewhat harder to support. Most proxies use some SSL library such as openssl or BSAFE. Given a library like that, it tends to add less than a 1000 lines of code to the proxy. Do people use it? Microsoft has a popular presence server known as LCS. LCS uses TLS for it's peering. If you do a bit of googling around you will find there are a lot of things that choose to interoperate with LCS. Enterprise that deploys LCS can peer with AOL, Yahoo, and MSN. Again over TLS. It's a pretty good example of some running code. Don't underestimate the size of this deployment and keep in mind it is already peering with three of the very largest IM providers. I forget when this all first deployed but it's been years. Is it Expensive? Your average proxy running on some intel or sun box will do something like a few thousand sip transactions per second then it hits the CPU limit. Every proxy I have seen, the performance bottleneck has been CPU. Now if you compute the bandwidth for this amount of SIP traffic, then look at how much CPU is required to AES encrypt that much traffic, you will realize - the encryption time is going to make pretty much no difference to the number of transaction per second this box can do. If you talk to SIP implementers, the hard part of TLS is keeping open tens of thousands of connections form a proxy to a UA. This is not what you are talking about here - Here we are talking about keeping open 100s to 1000s of connections from one proxy to another. These are long lived connections - they can be set up quickly and stay up for very long time. A small amount of data flows over them (by small, I mean less than few Mbps). I expect the expense to be very low in terms of implementation effort, hardware required to run this, and operation effort to run them. Don't confuse the issues of proxy doing TLS to many UA connected to it with the proxy doing TLS to the other proxies it connects to. What does it provide? It provides some integrity and confidentiality protection, yawn, yawn, yawn - not clear that this helps your threat models much but is definitely of some use. But let's get on to the next thing. TLS lets you authenticate that you connected to the proxy you meant to connect to. I expect this might be very important for the threat models you are interested in. The reason in MUST implement in proxies is that this is the *only* way SIP provides for one proxy to know that it connected to the correct next proxy. If you need to know who you are connecting to, you probably want to think seriously about TLS. It also provides a way of using certificates to delegate certain authorization decisions. Let me give an example. Lets say a bunch of organization A, B, C agree to peer and form so peering consortium, call it PeersAreUs. Everyone that joins PeersAreUs has to sing some sort of contract about behavior. They do enum look ups to some enum root at PeersAreUs. Now when a new organization D joins PeersAreUs, how do A,B,C find out they are authorized. One possibility is having PeersAreUs issue some sort of cert to D. Now A looks up a number in enum, gets routed to D, and D presents a certificate that lets A know that D is a valid member of PeersAreUs. This sounds sort of interesting to me from a operation expense point of view. Note that A, B, and C did not need to do anything when D joined and PeersAreUs did not have to run some large proxy that could deal with all the traffic of all it's members. I imagine you can find other ways to achieve this too, but hey, this one is already MUST implement in 3261 and widely implemented in deployed devices. Is IPsec an alternative? Possibly for some threat models and not for others. The inter-sting thing about IPsec is how will you key it? Given the scope of work in this WG, I would expect this group to describe that if IPsec is chosen. Setting up manual key associations between from one proxy to thousands of others sounds like an very expensive solution from an operations point of view so I would guess that something other than manual configuration would be chosen. Once you go down that path you run into questions of how the proxy knows it connected to the correct domain. I'm willing to believe that there might be solutions to this but not clear to me what they are or that anyone has implemented them. Are there other alternatives? The answer to this is always yes but I encourage the group to figure out what the threats, list the alternative solutions, and focus on saying which concrete proposal looks best instead of saying I don't like proposal X. This is going to be an exercise in picking the thing you hate least not having some silver bullet that is perfect in every way. Should this group mandate TLS use? Heck if I know :-) I think you are a ways from saying all the things you need to accomplish in securing a peer so it makes it a little hard to say if any given solution would meet all the needs. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 30 11:44:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLA7-0005Sv-Qf; Fri, 30 Jun 2006 11:44:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLA5-0005Sj-QS for speermint@ietf.org; Fri, 30 Jun 2006 11:44:05 -0400 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FwLA4-0007rt-Cv for speermint@ietf.org; Fri, 30 Jun 2006 11:44:05 -0400 Received: (qmail 91657 invoked from network); 30 Jun 2006 15:42:12 -0000 Received: from dsl254-017-242.sea1.dsl.speakeasy.net (HELO ?172.16.100.251?) (ben@216.254.17.242) by layer8.net with SMTP; 30 Jun 2006 15:42:12 -0000 In-Reply-To: <122A5731B827474C99ED552C6BFE23ED30CF07@OVE1WNEXCB02.vcorp.ad.vrsn.com> References: <122A5731B827474C99ED552C6BFE23ED30CF07@OVE1WNEXCB02.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <33DEFEAD-C6C4-4CC3-819A-378B9FDE9040@layer8.net> Content-Transfer-Encoding: 7bit From: Benjamin Black Subject: Re: TLS for peering (was RE: Comments(RE:[speermint]requirementsdraft submitted)) Date: Fri, 30 Jun 2006 08:44:02 -0700 To: "McCandless, Kevin" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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 kevin, 3788 is a very useful reference for this discussion. i think speermint needs both better specified requirements and a richer set of options, however. bb On Jun 30, 2006, at 8:26 AM, McCandless, Kevin wrote: > A voice of reason among the group. > > We went through this very discussion, in Sigtran, and came out that > IPSEC works just as well and left the choice to the implementers > between > IPSEC and TLS. Why not leverage this work? See RFC > http://www.ietf.org/rfc/rfc3788.txt, especially sections 7 & 8. > > > > > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Friday, June 30, 2006 9:31 AM > 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 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. > > 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? > 2) Why do you believe TLS offers better authentication than any other > method, especially given that there is no global trust anchor? > 3) What requirement makes TLS more secure than a dedicated link? > 4) What requirement makes TLS more secure than IPSec? > 5) Given that providers interconnect today without TLS, what > requirement is not met by the current interconnection methods that > TLS will provide? > > 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. > > -andy > > On Jun 29, 2006, at 8:05 PM, 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 > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 30 12:16:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLfH-0007xO-Mp; Fri, 30 Jun 2006 12:16:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLfG-0007xJ-Ku for speermint@ietf.org; Fri, 30 Jun 2006 12:16:18 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwLfE-0002xZ-CG for speermint@ietf.org; Fri, 30 Jun 2006 12:16:18 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 30 Jun 2006 09:16:16 -0700 X-IronPort-AV: i="4.06,197,1149490800"; d="scan'208"; a="432316436:sNHT39624488" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5UGGFL7011581 for ; Fri, 30 Jun 2006 09:16:15 -0700 Received: from [192.168.1.2] (sjc-vpn2-416.cisco.com [10.21.113.160]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5UGGF9s029088 for ; Fri, 30 Jun 2006 09:16:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D965820E9@PACDCEXCMB03.cable.comcast.com> References: <4884CD6C1DF0A8429DD8DAD942BF9D965820E9@PACDCEXCMB03.cable.comcast.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6E10BE8A-4880-4889-B698-3262DC3951E0@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt Date: Fri, 30 Jun 2006 09:16:14 -0700 To: speermint@ietf.org X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=346; t=1151684175; x=1152548175; c=relaxed/simple; s=sjdkim1001; h=From:Subject; 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=3DCcLYD/WffRAc0oxNAgVWrojzams=3D; b=s/eLyO+J2cSC+WerOUpAYInGDmiWAGgVmB8GQYwlG5N7IPs08D9fwzGXVxaB+0hu99Fj4j7G 4srj0OPAU+HnumzvaX9Ya9E/7SDEKFKkmmfsb8r/XQs8zhexdZ7NGTYI; Authentication-Results: sj-dkim-1.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 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 From speermint-bounces@ietf.org Fri Jun 30 12:20:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLip-00009z-K7; Fri, 30 Jun 2006 12:19:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLin-00009u-IX for speermint@ietf.org; Fri, 30 Jun 2006 12:19:57 -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 1FwLil-00034L-9p for speermint@ietf.org; Fri, 30 Jun 2006 12:19:57 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 30 Jun 2006 09:19:54 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5UGJsIF016518 for ; Fri, 30 Jun 2006 09:19:54 -0700 Received: from [192.168.1.2] (sjc-vpn2-416.cisco.com [10.21.113.160]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5UGJs9s001973 for ; Fri, 30 Jun 2006 09:19:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <6E10BE8A-4880-4889-B698-3262DC3951E0@cisco.com> References: <4884CD6C1DF0A8429DD8DAD942BF9D965820E9@PACDCEXCMB03.cable.comcast.com> <6E10BE8A-4880-4889-B698-3262DC3951E0@cisco.com> 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: Fri, 30 Jun 2006 09:19:53 -0700 To: speermint@ietf.org X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=567; t=1151684394; x=1152548394; c=relaxed/simple; s=sjdkim1001; h=From:Subject; 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=3DCcLYD/WffRAc0oxNAgVWrojzams=3D; b=hXZfz0+K0MMlRFiL9VZjJYrOXDEBmFwUgTqjFUeMgWU2keSAW2wHkSJCA+iDvNg3iq+OvCz+ oHntqmGWcaNQiADIVGFwssl8qVriQ+tegB82Wb15iQc32hLxEma80hE0; Authentication-Results: sj-dkim-1.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 9:16 AM, Cullen Jennings wrote: > > 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. > I clearly had not had enough coffee before hitting send on this message. Please ignore this this complete wrong statement :-) Sorry. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 30 12:47:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwM9p-0004jK-Sa; Fri, 30 Jun 2006 12:47:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwM9o-0004cy-HU for speermint@ietf.org; Fri, 30 Jun 2006 12:47:52 -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 1FwM9n-0004xW-8Z for speermint@ietf.org; Fri, 30 Jun 2006 12:47:52 -0400 Received: from [10.0.1.105] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 30 Jun 2006 12:48:09 -0400 id 01588125.44A555C9.00002643 In-Reply-To: <7205DCD3-75B6-4668-9100-4BEAC76CB781@cisco.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> <7205DCD3-75B6-4668-9100-4BEAC76CB781@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Fri, 30 Jun 2006 12:47:49 -0400 To: Cullen Jennings X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "Khan, Sohel Q \[\[CTO\]\]" , speermint@ietf.org, Adam Uzelac Subject: [Speermint] Re: UPD ? 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 12:00 PM, Cullen Jennings wrote: > My real concern is IETF is acting as if we will move to TCP, > 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 that this speermint WG has operators that are connected with > the real 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 From speermint-bounces@ietf.org Fri Jun 30 12:54:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwMGH-00086X-7x; Fri, 30 Jun 2006 12:54:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwMGF-00086I-2w for speermint@ietf.org; Fri, 30 Jun 2006 12:54: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 1FwLUy-00026X-92 for speermint@ietf.org; Fri, 30 Jun 2006 12:05:40 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FwLQ4-00083r-0g for speermint@ietf.org; Fri, 30 Jun 2006 12:00:37 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 30 Jun 2006 09:00:20 -0700 X-IronPort-AV: i="4.06,197,1149490800"; d="scan'208"; a="432310573:sNHT43350725564" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5UG0JCP022840; Fri, 30 Jun 2006 09:00:19 -0700 Received: from [192.168.1.2] (sjc-vpn2-416.cisco.com [10.21.113.160]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5UG0ICU025634; Fri, 30 Jun 2006 09:00:19 -0700 (PDT) In-Reply-To: <6A4304EA-845D-4120-B0F4-FDC390334328@hxr.us> 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> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7205DCD3-75B6-4668-9100-4BEAC76CB781@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Fri, 30 Jun 2006 09:00:17 -0700 To: speermint@ietf.org X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=2315; t=1151683219; x=1152547219; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:UPD=20?; X=v=3Dcisco.com=3B=20h=3DAh1cIPzzZgHGLV2UtIqXy9FLny4=3D; b=NVQ1EWYlfJqiU27P8i8wCL7D/+xgU+nkX+s35mslyebTz6VJAZ8ft/fhQ5kXi9YhuYdthQ7M jZ3sP31fRC+mdew4i51Gr7xS7mqtYQSCkyCJgnq1Uj6KjLXaj3bAk/H0; Authentication-Results: sj-dkim-1.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "Khan, Sohel Q \[\[CTO\]\]" , Adam Uzelac Subject: [Speermint] UPD ? 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 7:30 AM, Andrew Newton wrote: > > 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. Andy, this gets to another topic which is possible even more or important than this TLS or not questions. the questions is TCP or UDP for proxy to proxy. I have a growing concern of a theory vs. practice mismatch here. I don't know if you saw the recent thread on MMUSIC but Magnus constructed a very plausible SDP message that could occur in real world that is over 10k long (that would be 10k bytes in practice but 10,000 octets in theory :-). Many of the deployments I am aware of use UDP and say there are some serious problems with TCP. I believe this but as much as possible would like to understand what they are. On the other hand, the IETF is more and more defining stuff in SIP that is pushing the size of SIP packets to the point where it is questionable if they will work on UDP given the fragmentation issues. Some of the concerns I have see about TCP have been based on the ideas each transaction would form a new TCP connection - this clearly won't work so let's base the conversation on long lived TCP connections between peering proxies. My real concern is IETF is acting as if we will move to TCP, 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 that this speermint WG has operators that are connected with the real issues so this seems as good a place as any to discuss this. Cullen (BTW, all these emails sent with my individual contributor hat on) PS - note TLS can be run on TCP or over UDP with DTLS so the TLS or not question is separate from the UDP/TCP question PPS - just to head off the inevitable rat hole ahead ... Yes, I know about SCTP. On this thread I'm interested in what are the problems with deploying TCP and not really interested in all the great things SCTP can provide - we can get to that later. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 30 13:33:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwMsH-0001ta-Kl; Fri, 30 Jun 2006 13:33:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwMsG-0001s7-B3 for speermint@ietf.org; Fri, 30 Jun 2006 13:33:48 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwMsD-0008DP-VG for speermint@ietf.org; Fri, 30 Jun 2006 13:33:48 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 7EFD0222425 for ; Fri, 30 Jun 2006 10:41:55 -0700 (PDT) To: speermint@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Fri, 30 Jun 2006 10:33:45 -0700 From: Eric Rescorla Message-Id: <20060630174155.7EFD0222425@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Speermint] Some notes on security for Speermint connections 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 been reading the thread about TLS and speermint with interest and thought I'd add my $.02. 1. In Web-based TLS settings, the performance is dominated by the public key crypto in the handshake (typically RSA). The canonical reference on this is [CDW02], which obtained about 250cps on a 933 MHz machine with semi-realistic simulated workloads. Extrapolating, a 3.8 GHz single-core machine would give you order 1000 cps. 2. As I understand it, this setting is mostly long-lived connections so the dominating factor isn't connection setup but rather throughput. Microbenchmarks show performance something like: RC4 -- 125 MB/s SHA-1 -- 10-116 MB/s (dependent on packet size) 3. We've run HTTPS benchmarks on large files with high rates of session resumption (which removes the effect of the handshake) and get throughputs of about 33 MB/s on low-end server class machines (3.0 GHz P4s running FreeBSD). For comparison, we get about 60 MB/s running pure HTTP traffic with otherwise equivalent parameters. Note that this isn't perfectly realistic because the performance of HTTPS partly depends on record size, so if you're using a lot of small (< 1k, say) messages, you'd see inferior performance. 4. I would expect TLS and IPsec performance to be roughly equivalent, provided that you used the same algorithms. TLS handshake performance is somewhat better because it doesn't require a DH exchange, but as indicated above, that cost probably isn't an issue here. There has been some work on comparing SSL and IPsec bulk performance (E.g., [AS05]), which seems to indicate that SSL is faster but I haven't studied the methodology enough to be comfortable making that claim. Hope this helps, -Ekr [CDW02] Cristian Coarfa, Peter Druschel, and Dan S. Wallach, "Performance Analysis of TLS Web Servers", Network and Distributed Systems Security Symposium (San Diego, California), February 2002. http://www.cs.rice.edu/~dwallach/pub/ndss2002.html [AS05] Abdel Nasir Alshamsi and Takamichi Saito, "A Technical Comparison of IPSec and SSL", AINA 2005. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 30 13:36:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwMvG-0002mM-Ii; Fri, 30 Jun 2006 13:36:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwMvF-0002mG-IO for speermint@ietf.org; Fri, 30 Jun 2006 13:36:53 -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 1FwMvF-00006l-4o for speermint@ietf.org; Fri, 30 Jun 2006 13:36:53 -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 k5UHagaK016041; Fri, 30 Jun 2006 17:36:43 GMT Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted)) From: Daryl Malas To: Rohan Mahy In-Reply-To: <953beacc0606300840h741d071cle64c12045a7de878@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> <953beacc0606300840h741d071cle64c12045a7de878@mail.gmail.com> Content-Type: text/plain Date: Fri, 30 Jun 2006 11:36:09 -0600 Message-Id: <1151688969.10104.30.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: 68ba2b07ef271dba6ee42a93832cfa4c 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 Okay, we have gone round and round on this topic....I have become lost in the discussion and want to make sure we are still arguing the same question. Is the question we are arguing, still: --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? Why does it have to be the only option? I still assert, it should be included in the requirements document as a one of several methods (one of the methods is required -- but not all) for providing security in a peering topology. This being said...it would be to the detriment of a provider not willing to peer with another provider if that provider only supports TLS (yet they would be compliant with the requirements). I can say we (Level 3) would seriously consider implementing it (if we hadn't already) and supporting it based on the opportunity. But, before an opportunity presents itself, TCP/TLS creates a lot of (arguably) unnecessary overhead. --Daryl On Fri, 2006-06-30 at 08:40 -0700, Rohan Mahy wrote: > Andy, > > I am just leaving for a short vacation, but I will commit to answering > your questions before the meeting in Montreal. I think these are good > questions and I want to take the time to answer them properly. > > So that we can make apples to apples comparisons, it would be useful > to start with an order of magnitude number of calls per day. This > does not need to be Sunrocket's (or any other carrier's) actual > current or expected peering traffic, but it should be plausible. > > thanks, > -rohan > > > 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. > > > > 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? > > 2) Why do you believe TLS offers better authentication than any other > > method, especially given that there is no global trust anchor? > > 3) What requirement makes TLS more secure than a dedicated link? > > 4) What requirement makes TLS more secure than IPSec? > > 5) Given that providers interconnect today without TLS, what > > requirement is not met by the current interconnection methods that > > TLS will provide? > > > > 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. > > > > -andy > > > > On Jun 29, 2006, at 8:05 PM, 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