From speermint-bounces@ietf.org Tue Oct 02 04:48:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdOF-0001xP-VA; Tue, 02 Oct 2007 04:46:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdOD-0001pY-Lw for speermint@ietf.org; Tue, 02 Oct 2007 04:46:01 -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 1IcdO2-00028L-7i for speermint@ietf.org; Tue, 02 Oct 2007 04:45:56 -0400 Received: from outbound1-fra.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-fra-R.bigfish.com (Postfix) with ESMTP id CE2FD8E0753; Tue, 2 Oct 2007 08:45:32 +0000 (UTC) Received: from mail8-fra-R.bigfish.com (unknown [10.4.252.3]) by outbound1-fra.bigfish.com (Postfix) with ESMTP id CC3FB570001; Tue, 2 Oct 2007 08:45:32 +0000 (UTC) Received: from mail8-fra (localhost.localdomain [127.0.0.1]) by mail8-fra-R.bigfish.com (Postfix) with ESMTP id 70838180127; Tue, 2 Oct 2007 08:45:32 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 212.120.142.30; Service: EHS Received: by mail8-fra (MessageSwitch) id 1191314732207312_28083; Tue, 2 Oct 2007 08:45:32 +0000 (UCT) Received: from GSMDUBEX02.GSM.TLD (unknown [212.120.142.30]) by mail8-fra.bigfish.com (Postfix) with ESMTP id E8B4F128056; Tue, 2 Oct 2007 08:45:31 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] [wg-business] WGLCfordraft-ietf-speermint-terminology-12 Date: Tue, 2 Oct 2007 09:45:29 +0100 Message-ID: <6918D1F7F8770C4FB182838A7BDFD6C8016FF1F5@GSMDUBEX02.GSM.TLD> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business] WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgAaIO7/hEeVa9kTQKfLRakKTmBwAAcct/QAPw2WGA= From: "Dan Warren" To: "Elwell, John" , "Daryl Malas" X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: "Malas, Daryl" , "Peterson, , dmm"@1-4-5.net, speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org All Some of the points made by John (in his comments 14, 15 and 16) I agree with but I think it goes further than that. So rather than making a proper comment, can I check my understanding of the terms as someone that has picked the spec up recently and tried to understand it? There are four terms relating to network types - peer network, service provider, SIP Service Provider and Internet Telephony Service Provider. The document states that SSP and ITSP are synonymous, although I might argue that an ITSP is a subset of an SSP, purely because the 'T' part suggests a specific service attributable to the UA's within that network and hence also implies something about the way that service is delivered (or at least ought to). SSP is more general and hence could include applications that do not have the same requirements on QoS and hence do not require the same DSCP marking, but if you are all happy for these to be equivalent, I am not going to fuss about the semantics of what is implied by 'telephony'. Now I get slightly confused. A Peer Network sounds like it is a special case of an SSP - in effect a peered SSP. Is that correct? If so I'd suggest for readability of the document, SSP is defined before Peer Network, and Peer Network is defined as I describe above. Similarly, an SSP seems to be a specialised SP, in that not only does it provide L3 transport of SIP signalling and media packets, but also includes SIP end points. Similar to my last point, it would help the document to define SP before SSP, so that the definition of SSP can be 'An SSP is an SP that also includes UASs and UACs...' and then a Peer Network can be defined as '...an SSP that has connections to peer SSPs via...'. A nice hierarchical definition (start with the broadest term and get narrower' generally saves a lot of redefinition, which in itself can create ambiguity. And that leads me quite neatly on to a question - how are you classifying the transit or carrier network that would sit between the SSPs to provide interconnectivity? It is clearly an SP since it will provide L3 transport of SIP and media, but if my comments above are right, SP is intended to be an umberella term covering all the sub-variants of SP. It will also need to have some characteristics dependent upon whether it is expected to provide any additional functionality - it clearly needs to be DiffServ aware, but it could also be required to provide a bunch of functions around transcoding and reframing in the media plane, and maybe SIP variant interworking, which could imply B2BUAs. It seems though that this network, be it the internet or something provided by a carrier operator is only alluded to in the definition of Federations. Is there not a need to identify it explicitly, even if it is far simpler than I have conceived it to be? I note that in the Architecture document, in Figure 3 a 'Transit IP Provider' is identified (although the text never refers to Figure 3 nor Transit IP Provider), but then in Figure 1 of the same document a whole bunch of terms not defined in this document are used... I'd appreciate at least comments on whether what I have laid out as the herarchy of these terms is right or not, but I'm not going to get fussy about whether the proposed shuffle of the ordering takes place. Cheers Dan > > > 14) "3.8. Service Provider > > > = > > > A Service Provider (or SP) is defined to be an entity > > that provides > > > layer 3 (IP) transport of SIP signaling and media packets. An = > > > example of this may be an Internet Service Provider (ISP)." > > > This at first glance is reasonable, but then the next > > section goes on to > > > define a SIP Service Provider as something that is not a > > special case of > > > a Service Provider, since it operates at layer 5, not at = > layer 3. We = > > > should perhaps find a different term for "Service Provider" > > when we mean > > > layer 3, e.g., "Network Service Provider". > > That's fine with me....although terms like this are ambiguous. I = > > think we had specified Internet Service Provider before, but there = > > were arguments against being that "specific". So, we = > generalized the = > > term and just provided it as an example. > [JRE] I think we have to do something. The term SP is OK if = > it is intended to embrace all types of SP that we are dealing = > with, including SSP. But if we need a term for an SP that = > operates only at layer 3, we need a different term. > = > > > = > > > 15) "A SIP Service Provider (or SSP) is an entity that provides = > > > application level transport of SIP signaling to its = > customers." = > > > Elsewhere the document talks about level 5 peering, but = > now it talks = > > > about application level. Also, isn't it more than just = > transport. I = > > > don't have a particular proposal, but I don't really like > > the present > > > definition. > > = > > Hmmm...I'll see if I can think of something to make this clearer. > > Anyone else have an opinion (heh...that's a stupid = > question. Everyone = > > has an opinion, right?!)? :-) > = > > > = > > > 16) "3.10. Internet Telephony Service Provider > > > = > > > An Internet Telephony Service Provider, or ITSP, is a > > synonym for > > > SSP. While the terms ITSP and SSP are frequently used = > > > interchangeably, the SPEERMINT working group uses the = > term SSP." > > > So why define the term if we are not going to use it? We > > could mention > > > it in a note below the definition of SSP, if really needed. > > > = > > ....don't care either way...we can do that to. Does it = > significantly = > > make things simpler by doing as you suggest? > [JRE] The point is, by having an explicit definition of ITSP, = > it tends to encourage other SPEERMINT documents to use it, = > even though there is an explicit statement that SPEERMINT = > will use only SSP. I thought just making it a note below the = > definition of SSP would help to de-emphasise ITSP further. Forthcoming GSMA Events: = GSMA Mobile Asia Congress Macau 12 - 15 November 2007 www.mobileasiacongress.com = GSMA Mobile World Congress Barcelona 11 - 14 February 2008 www.mobileworldcongress.com This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 759 2300 and highlight the error _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 02 05:26:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icdzi-00070Y-0u; Tue, 02 Oct 2007 05:24:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icdzh-00070S-6v for speermint@ietf.org; Tue, 02 Oct 2007 05:24:45 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcdzW-0003BP-Gb for speermint@ietf.org; Tue, 02 Oct 2007 05:24:45 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JPA00C0U23XB8@siemenscomms.co.uk> for speermint@ietf.org; Tue, 02 Oct 2007 10:23:57 +0100 (BST) Date: Tue, 02 Oct 2007 10:24:16 +0100 From: "Elwell, John" Subject: RE: [Speermint] [wg-business] WGLCfordraft-ietf-speermint-terminology-12 In-reply-to: <6918D1F7F8770C4FB182838A7BDFD6C8016FF1F5@GSMDUBEX02.GSM.TLD> To: Dan Warren , Daryl Malas Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0325618@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Speermint] [wg-business] WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgAaIO7/hEeVa9kTQKfLRakKTmBwAAcct/QAPw2WGAAAnUVkA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <6918D1F7F8770C4FB182838A7BDFD6C8016FF1F5@GSMDUBEX02.GSM.TLD> X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: "Malas, Daryl" , "Peterson, , dmm"@1-4-5.net, speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Dan, I agree with most of what you say. One point, however, is your proposal: 'An SSP is an SP that also includes UASs and UACs...' (which I guess comes from text in the existing definition of Peer Network, which I failed to comment on). Is it a necessary condition that an SSP include UAs (other than B2BUAs, perhaps)? I guess it depends what we perceive as the scope of an SSP. UAs such as PSTN gateways, media servers, etc. might be considered part of the SSP. But a UA in a user's home that uses the services of an SSP? That to me is not really part of the SSP. John > -----Original Message----- > From: Dan Warren [mailto:DWarren@gsm.org] > Sent: 02 October 2007 09:45 > To: Elwell, John; Daryl Malas > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > speermint@ietf.org; Livingood, Jason > Subject: RE: [Speermint] [wg-business] > WGLCfordraft-ietf-speermint-terminology-12 > > All > > Some of the points made by John (in his comments 14, 15 and > 16) I agree > with but I think it goes further than that. So rather than making a > proper comment, can I check my understanding of the terms as someone > that has picked the spec up recently and tried to understand it? > > There are four terms relating to network types - peer network, service > provider, SIP Service Provider and Internet Telephony Service > Provider. > The document states that SSP and ITSP are synonymous, although I might > argue that an ITSP is a subset of an SSP, purely because the 'T' part > suggests a specific service attributable to the UA's within > that network > and hence also implies something about the way that service > is delivered > (or at least ought to). SSP is more general and hence could include > applications that do not have the same requirements on QoS > and hence do > not require the same DSCP marking, but if you are all happy > for these to > be equivalent, I am not going to fuss about the semantics of what is > implied by 'telephony'. > > Now I get slightly confused. A Peer Network sounds like it > is a special > case of an SSP - in effect a peered SSP. Is that correct? If so I'd > suggest for readability of the document, SSP is defined before Peer > Network, and Peer Network is defined as I describe above. > > Similarly, an SSP seems to be a specialised SP, in that not > only does it > provide L3 transport of SIP signalling and media packets, but also > includes SIP end points. Similar to my last point, it would help the > document to define SP before SSP, so that the definition of SSP can be > 'An SSP is an SP that also includes UASs and UACs...' and then a Peer > Network can be defined as '...an SSP that has connections to peer SSPs > via...'. A nice hierarchical definition (start with the broadest term > and get narrower' generally saves a lot of redefinition, > which in itself > can create ambiguity. > > And that leads me quite neatly on to a question - how are you > classifying the transit or carrier network that would sit between the > SSPs to provide interconnectivity? It is clearly an SP since it will > provide L3 transport of SIP and media, but if my comments above are > right, SP is intended to be an umberella term covering all the > sub-variants of SP. It will also need to have some characteristics > dependent upon whether it is expected to provide any additional > functionality - it clearly needs to be DiffServ aware, but it > could also > be required to provide a bunch of functions around transcoding and > reframing in the media plane, and maybe SIP variant > interworking, which > could imply B2BUAs. It seems though that this network, be it the > internet or something provided by a carrier operator is only > alluded to > in the definition of Federations. Is there not a need to identify it > explicitly, even if it is far simpler than I have conceived > it to be? I > note that in the Architecture document, in Figure 3 a 'Transit IP > Provider' is identified (although the text never refers to > Figure 3 nor > Transit IP Provider), but then in Figure 1 of the same > document a whole > bunch of terms not defined in this document are used... > > I'd appreciate at least comments on whether what I have laid > out as the > herarchy of these terms is right or not, but I'm not going to > get fussy > about whether the proposed shuffle of the ordering takes place. > > Cheers > > Dan > > > > > > 14) "3.8. Service Provider > > > > > > > > A Service Provider (or SP) is defined to be an entity > > > that provides > > > > layer 3 (IP) transport of SIP signaling and media > packets. An > > > > example of this may be an Internet Service Provider (ISP)." > > > > This at first glance is reasonable, but then the next > > > section goes on to > > > > define a SIP Service Provider as something that is not a > > > special case of > > > > a Service Provider, since it operates at layer 5, not at > > layer 3. We > > > > should perhaps find a different term for "Service Provider" > > > when we mean > > > > layer 3, e.g., "Network Service Provider". > > > That's fine with me....although terms like this are ambiguous. I > > > think we had specified Internet Service Provider before, > but there > > > were arguments against being that "specific". So, we > > generalized the > > > term and just provided it as an example. > > [JRE] I think we have to do something. The term SP is OK if > > it is intended to embrace all types of SP that we are dealing > > with, including SSP. But if we need a term for an SP that > > operates only at layer 3, we need a different term. > > > > > > > > > > 15) "A SIP Service Provider (or SSP) is an entity that provides > > > > application level transport of SIP signaling to its > > customers." > > > > Elsewhere the document talks about level 5 peering, but > > now it talks > > > > about application level. Also, isn't it more than just > > transport. I > > > > don't have a particular proposal, but I don't really like > > > the present > > > > definition. > > > > > > Hmmm...I'll see if I can think of something to make this clearer. > > > Anyone else have an opinion (heh...that's a stupid > > question. Everyone > > > has an opinion, right?!)? :-) > > > > > > > > > > 16) "3.10. Internet Telephony Service Provider > > > > > > > > An Internet Telephony Service Provider, or ITSP, is a > > > synonym for > > > > SSP. While the terms ITSP and SSP are frequently used > > > > interchangeably, the SPEERMINT working group uses the > > term SSP." > > > > So why define the term if we are not going to use it? We > > > could mention > > > > it in a note below the definition of SSP, if really needed. > > > > > > > ....don't care either way...we can do that to. Does it > > significantly > > > make things simpler by doing as you suggest? > > [JRE] The point is, by having an explicit definition of ITSP, > > it tends to encourage other SPEERMINT documents to use it, > > even though there is an explicit statement that SPEERMINT > > will use only SSP. I thought just making it a note below the > > definition of SSP would help to de-emphasise ITSP further. > > Forthcoming GSMA Events: > > GSMA Mobile Asia Congress > Macau > 12 - 15 November 2007 > www.mobileasiacongress.com > > GSMA Mobile World Congress > Barcelona > 11 - 14 February 2008 > www.mobileworldcongress.com > > > This email and its attachments are intended for the above > named only and may be confidential. If they have come to you > in error you must take no action based on them, nor must you > copy or show them to anyone; please reply to this email or > call +44 207 759 2300 and highlight the error > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 02 07:04:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcfXO-0002c0-Pc; Tue, 02 Oct 2007 07:03:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcfXM-0002RZ-EW for speermint@ietf.org; Tue, 02 Oct 2007 07:03:36 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound6-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcfXG-0005LM-24 for speermint@ietf.org; Tue, 02 Oct 2007 07:03:36 -0400 Received: from outbound6-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound6-cpk-R.bigfish.com (Postfix) with ESMTP id A68247F3103; Tue, 2 Oct 2007 11:03:11 +0000 (UTC) Received: from mail124-cpk-R.bigfish.com (unknown [10.2.40.3]) by outbound6-cpk.bigfish.com (Postfix) with ESMTP id 9946CF6004E; Tue, 2 Oct 2007 11:03:11 +0000 (UTC) Received: from mail124-cpk (localhost.localdomain [127.0.0.1]) by mail124-cpk-R.bigfish.com (Postfix) with ESMTP id D6C97B68276; Tue, 2 Oct 2007 11:02:54 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 212.120.142.30; Service: EHS Received: by mail124-cpk (MessageSwitch) id 1191322964172233_26896; Tue, 2 Oct 2007 11:02:44 +0000 (UCT) Received: from GSMDUBEX02.GSM.TLD (unknown [212.120.142.30]) by mail124-cpk.bigfish.com (Postfix) with ESMTP id 4EBE0558065; Tue, 2 Oct 2007 11:01:30 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] [wg-business] WGLCfordraft-ietf-speermint-terminology-12 Date: Tue, 2 Oct 2007 11:58:17 +0100 Message-ID: <6918D1F7F8770C4FB182838A7BDFD6C8016FF2CD@GSMDUBEX02.GSM.TLD> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business] WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgAaIO7/hEeVa9kTQKfLRakKTmBwAAcct/QAPw2WGAAAnUVkAACxNog From: "Dan Warren" To: "Elwell, John" , "Daryl Malas" X-Spam-Score: -2.8 (--) X-Scan-Signature: efc5d1db3729b4b7031f1bb5f5a30ae3 Cc: "Malas, Daryl" , "Peterson, , dmm"@1-4-5.net, speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org John You said... 'Is it a necessary condition that an SSP include UAs (other than B2BUAs, perhaps)? I guess it depends what we perceive as the scope of an SSP. UAs such as PSTN gateways, media servers, etc. might be considered part of the SSP. But a UA in a user's home that uses the services of an SSP? That to me is not really part of the SSP.' I agree that under the current terminology and associated definitions it isn't, but lets consider what the practicalities of implementation are. Suppose I have a UA on my laptop. Unless the ISP I am using is handling the SIP signalling from that UA in a special way compared with other non-SIP traffic, then the ISP is operating as a SP (as defined in 3.8). The UA has to be associated with some sort of network where my sessions are handled, applications are applied and methods are forwarded. This has to be in an SSP/ITSP, and if that SSP is attached to other SSPs then it is also a Peer Network. I guess the point is, do we conceive of UA's that are in homes that do not need to have an association with an SSP, even if it is only short term? = I have to admit that on reading your mail I figured I had made a mistake, but then on analysing the text and thinking about it, I think it is an interesting question. Maybe the way to consider it is conversely - what do you classify a 'set of SIP user agent servers (UASs) [2] and SIP user agent clients (UACs) [2] (customers) that are controlled by a single administrative domain' but do not peer? So a completely self contained and non-peering network... If an SSP does not imply UACs and UASs, what is the level of SIP awareness within the SSP space? I am not trying to be intentionally provocative, I am just aware that there seems to be some gaps in the definitions like could be usefully closed before they cause problems when we need a term for a network classification that is not defined... I again make note though that I am coming to this with fresh eyes and it might be that I am just misunderstanding what is written. Cheers Dan > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] = > Sent: 02 October 2007 10:24 > To: Dan Warren; Daryl Malas > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; = > speermint@ietf.org; Livingood, Jason > Subject: RE: [Speermint] [wg-business] = > WGLCfordraft-ietf-speermint-terminology-12 > = > Dan, > = > I agree with most of what you say. One point, however, is = > your proposal: > 'An SSP is an SP that also includes UASs and UACs...' (which = > I guess comes from text in the existing definition of Peer = > Network, which I failed to comment on). > = > Is it a necessary condition that an SSP include UAs (other = > than B2BUAs, perhaps)? I guess it depends what we perceive as = > the scope of an SSP. > UAs such as PSTN gateways, media servers, etc. might be = > considered part of the SSP. But a UA in a user's home that = > uses the services of an SSP? > That to me is not really part of the SSP. > = > John > = > > -----Original Message----- > > From: Dan Warren [mailto:DWarren@gsm.org] > > Sent: 02 October 2007 09:45 > > To: Elwell, John; Daryl Malas > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; speermint@ietf.org; = > > Livingood, Jason > > Subject: RE: [Speermint] [wg-business] > > WGLCfordraft-ietf-speermint-terminology-12 > > = > > All > > = > > Some of the points made by John (in his comments 14, 15 and > > 16) I agree > > with but I think it goes further than that. So rather than = > making a = > > proper comment, can I check my understanding of the terms = > as someone = > > that has picked the spec up recently and tried to understand it? > > = > > There are four terms relating to network types - peer = > network, service = > > provider, SIP Service Provider and Internet Telephony Service = > > Provider. > > The document states that SSP and ITSP are synonymous, = > although I might = > > argue that an ITSP is a subset of an SSP, purely because = > the 'T' part = > > suggests a specific service attributable to the UA's within that = > > network and hence also implies something about the way that = > service is = > > delivered (or at least ought to). SSP is more general and = > hence could = > > include applications that do not have the same requirements = > on QoS and = > > hence do not require the same DSCP marking, but if you are = > all happy = > > for these to be equivalent, I am not going to fuss about = > the semantics = > > of what is implied by 'telephony'. > > = > > Now I get slightly confused. A Peer Network sounds like it is a = > > special case of an SSP - in effect a peered SSP. Is that = > correct? If = > > so I'd suggest for readability of the document, SSP is = > defined before = > > Peer Network, and Peer Network is defined as I describe above. > > = > > Similarly, an SSP seems to be a specialised SP, in that not = > only does = > > it provide L3 transport of SIP signalling and media = > packets, but also = > > includes SIP end points. Similar to my last point, it = > would help the = > > document to define SP before SSP, so that the definition of = > SSP can be = > > 'An SSP is an SP that also includes UASs and UACs...' and = > then a Peer = > > Network can be defined as '...an SSP that has connections = > to peer SSPs = > > via...'. A nice hierarchical definition (start with the = > broadest term = > > and get narrower' generally saves a lot of redefinition, which in = > > itself can create ambiguity. > > = > > And that leads me quite neatly on to a question - how are you = > > classifying the transit or carrier network that would sit = > between the = > > SSPs to provide interconnectivity? It is clearly an SP = > since it will = > > provide L3 transport of SIP and media, but if my comments above are = > > right, SP is intended to be an umberella term covering all the = > > sub-variants of SP. It will also need to have some characteristics = > > dependent upon whether it is expected to provide any additional = > > functionality - it clearly needs to be DiffServ aware, but it could = > > also be required to provide a bunch of functions around transcoding = > > and reframing in the media plane, and maybe SIP variant = > interworking, = > > which could imply B2BUAs. It seems though that this network, be it = > > the internet or something provided by a carrier operator is only = > > alluded to in the definition of Federations. Is there not = > a need to = > > identify it explicitly, even if it is far simpler than I have = > > conceived it to be? I note that in the Architecture document, in = > > Figure 3 a 'Transit IP Provider' is identified (although the text = > > never refers to Figure 3 nor Transit IP Provider), but then = > in Figure = > > 1 of the same document a whole bunch of terms not defined in this = > > document are used... > > = > > I'd appreciate at least comments on whether what I have laid out as = > > the herarchy of these terms is right or not, but I'm not = > going to get = > > fussy about whether the proposed shuffle of the ordering = > takes place. > > = > > Cheers > > = > > Dan > > = > > = > > > > > 14) "3.8. Service Provider > > > > > = > > > > > A Service Provider (or SP) is defined to be an entity > > > > that provides > > > > > layer 3 (IP) transport of SIP signaling and media > > packets. An > > > > > example of this may be an Internet Service Provider (ISP)." > > > > > This at first glance is reasonable, but then the next > > > > section goes on to > > > > > define a SIP Service Provider as something that is not a > > > > special case of > > > > > a Service Provider, since it operates at layer 5, not at > > > layer 3. We > > > > > should perhaps find a different term for "Service Provider" > > > > when we mean > > > > > layer 3, e.g., "Network Service Provider". > > > > That's fine with me....although terms like this are = > ambiguous. I = > > > > think we had specified Internet Service Provider before, > > but there > > > > were arguments against being that "specific". So, we > > > generalized the > > > > term and just provided it as an example. > > > [JRE] I think we have to do something. The term SP is OK if it is = > > > intended to embrace all types of SP that we are dealing with, = > > > including SSP. But if we need a term for an SP that = > operates only at = > > > layer 3, we need a different term. > > > = > > > > > = > > > > > 15) "A SIP Service Provider (or SSP) is an entity = > that provides = > > > > > application level transport of SIP signaling to its > > > customers." = > > > > > Elsewhere the document talks about level 5 peering, but > > > now it talks > > > > > about application level. Also, isn't it more than just > > > transport. I > > > > > don't have a particular proposal, but I don't really like > > > > the present > > > > > definition. > > > > = > > > > Hmmm...I'll see if I can think of something to make = > this clearer. > > > > Anyone else have an opinion (heh...that's a stupid > > > question. Everyone > > > > has an opinion, right?!)? :-) > > > = > > > > > = > > > > > 16) "3.10. Internet Telephony Service Provider > > > > > = > > > > > An Internet Telephony Service Provider, or ITSP, is a > > > > synonym for > > > > > SSP. While the terms ITSP and SSP are frequently used = > > > > > interchangeably, the SPEERMINT working group uses the > > > term SSP." > > > > > So why define the term if we are not going to use it? We > > > > could mention > > > > > it in a note below the definition of SSP, if really needed. > > > > > = > > > > ....don't care either way...we can do that to. Does it > > > significantly > > > > make things simpler by doing as you suggest? > > > [JRE] The point is, by having an explicit definition of ITSP, it = > > > tends to encourage other SPEERMINT documents to use it, = > even though = > > > there is an explicit statement that SPEERMINT will use = > only SSP. I = > > > thought just making it a note below the definition of SSP = > would help = > > > to de-emphasise ITSP further. > > = > > Forthcoming GSMA Events: > > = > > GSMA Mobile Asia Congress > > Macau > > 12 - 15 November 2007 > > www.mobileasiacongress.com > > = > > GSMA Mobile World Congress > > Barcelona > > 11 - 14 February 2008 > > www.mobileworldcongress.com > > = > > = > > This email and its attachments are intended for the above = > named only = > > and may be confidential. If they have come to you in error you must = > > take no action based on them, nor must you copy or show them to = > > anyone; please reply to this email or call +44 207 759 2300 and = > > highlight the error > > = > > = > > = > = > = Forthcoming GSMA Events: = GSMA Mobile Asia Congress Macau 12 - 15 November 2007 www.mobileasiacongress.com = GSMA Mobile World Congress Barcelona 11 - 14 February 2008 www.mobileworldcongress.com This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 759 2300 and highlight the error _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 02 08:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icgnw-0007dl-0S; Tue, 02 Oct 2007 08:24:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icgnu-0007Wo-GM for speermint@ietf.org; Tue, 02 Oct 2007 08:24:46 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Icgno-0007wc-1u for speermint@ietf.org; Tue, 02 Oct 2007 08:24:46 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JPA00AB3AFQVD@siemenscomms.co.uk> for speermint@ietf.org; Tue, 02 Oct 2007 13:23:50 +0100 (BST) Date: Tue, 02 Oct 2007 13:24:10 +0100 From: "Elwell, John" Subject: RE: [Speermint] [wg-business] WGLCfordraft-ietf-speermint-terminology-12 In-reply-to: <6918D1F7F8770C4FB182838A7BDFD6C8016FF2CD@GSMDUBEX02.GSM.TLD> To: Dan Warren , Daryl Malas Message-id: <0D5F89FAC29E2C41B98A6A762007F5D032565E@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Speermint] [wg-business] WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgAaIO7/hEeVa9kTQKfLRakKTmBwAAcct/QAPw2WGAAAnUVkAACxNogAAOQLeA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <6918D1F7F8770C4FB182838A7BDFD6C8016FF2CD@GSMDUBEX02.GSM.TLD> X-Spam-Score: 1.2 (+) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Cc: "Malas, Daryl" , "Peterson, , dmm"@1-4-5.net, speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Dan, It is probably a moot point whether a residential UA is within the SSP or not. Perhaps if the UA is in possession of credentials for that SSP, allowing it to register and submit other requests such as INVITE and MESSAGE, then you might regard it as logically part of that SSP. But I guess the main point I was trying to make is whether it is a necessary condition that an SSP include UAs. Consider a transit SSP used in indirect peering. It can be a transit SSP without possessing a single UA (gateway, phone, media server or whatever). John > -----Original Message----- > From: Dan Warren [mailto:DWarren@gsm.org] > Sent: 02 October 2007 11:58 > To: Elwell, John; Daryl Malas > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > speermint@ietf.org; Livingood, Jason > Subject: RE: [Speermint] [wg-business] > WGLCfordraft-ietf-speermint-terminology-12 > > John > > You said... > > 'Is it a necessary condition that an SSP include UAs (other > than B2BUAs, > perhaps)? I guess it depends what we perceive as the scope of an SSP. > UAs such as PSTN gateways, media servers, etc. might be > considered part > of the SSP. But a UA in a user's home that uses the services > of an SSP? > That to me is not really part of the SSP.' > > I agree that under the current terminology and associated > definitions it > isn't, but lets consider what the practicalities of > implementation are. > Suppose I have a UA on my laptop. Unless the ISP I am using > is handling > the SIP signalling from that UA in a special way compared with other > non-SIP traffic, then the ISP is operating as a SP (as > defined in 3.8). > The UA has to be associated with some sort of network where > my sessions > are handled, applications are applied and methods are forwarded. This > has to be in an SSP/ITSP, and if that SSP is attached to > other SSPs then > it is also a Peer Network. I guess the point is, do we > conceive of UA's > that are in homes that do not need to have an association with an SSP, > even if it is only short term? > > I have to admit that on reading your mail I figured I had made a > mistake, but then on analysing the text and thinking about it, I think > it is an interesting question. Maybe the way to consider it is > conversely - what do you classify a 'set of SIP user agent servers > (UASs) [2] and SIP user agent clients (UACs) [2] (customers) that are > controlled by a single administrative domain' but do not peer? So a > completely self contained and non-peering network... If an > SSP does not > imply UACs and UASs, what is the level of SIP awareness within the SSP > space? > > I am not trying to be intentionally provocative, I am just aware that > there seems to be some gaps in the definitions like could be usefully > closed before they cause problems when we need a term for a network > classification that is not defined... I again make note > though that I am > coming to this with fresh eyes and it might be that I am just > misunderstanding what is written. > > Cheers > > Dan > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: 02 October 2007 10:24 > > To: Dan Warren; Daryl Malas > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > speermint@ietf.org; Livingood, Jason > > Subject: RE: [Speermint] [wg-business] > > WGLCfordraft-ietf-speermint-terminology-12 > > > > Dan, > > > > I agree with most of what you say. One point, however, is > > your proposal: > > 'An SSP is an SP that also includes UASs and UACs...' (which > > I guess comes from text in the existing definition of Peer > > Network, which I failed to comment on). > > > > Is it a necessary condition that an SSP include UAs (other > > than B2BUAs, perhaps)? I guess it depends what we perceive as > > the scope of an SSP. > > UAs such as PSTN gateways, media servers, etc. might be > > considered part of the SSP. But a UA in a user's home that > > uses the services of an SSP? > > That to me is not really part of the SSP. > > > > John > > > > > -----Original Message----- > > > From: Dan Warren [mailto:DWarren@gsm.org] > > > Sent: 02 October 2007 09:45 > > > To: Elwell, John; Daryl Malas > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > speermint@ietf.org; > > > Livingood, Jason > > > Subject: RE: [Speermint] [wg-business] > > > WGLCfordraft-ietf-speermint-terminology-12 > > > > > > All > > > > > > Some of the points made by John (in his comments 14, 15 and > > > 16) I agree > > > with but I think it goes further than that. So rather than > > making a > > > proper comment, can I check my understanding of the terms > > as someone > > > that has picked the spec up recently and tried to understand it? > > > > > > There are four terms relating to network types - peer > > network, service > > > provider, SIP Service Provider and Internet Telephony Service > > > Provider. > > > The document states that SSP and ITSP are synonymous, > > although I might > > > argue that an ITSP is a subset of an SSP, purely because > > the 'T' part > > > suggests a specific service attributable to the UA's within that > > > network and hence also implies something about the way that > > service is > > > delivered (or at least ought to). SSP is more general and > > hence could > > > include applications that do not have the same requirements > > on QoS and > > > hence do not require the same DSCP marking, but if you are > > all happy > > > for these to be equivalent, I am not going to fuss about > > the semantics > > > of what is implied by 'telephony'. > > > > > > Now I get slightly confused. A Peer Network sounds like it is a > > > special case of an SSP - in effect a peered SSP. Is that > > correct? If > > > so I'd suggest for readability of the document, SSP is > > defined before > > > Peer Network, and Peer Network is defined as I describe above. > > > > > > Similarly, an SSP seems to be a specialised SP, in that not > > only does > > > it provide L3 transport of SIP signalling and media > > packets, but also > > > includes SIP end points. Similar to my last point, it > > would help the > > > document to define SP before SSP, so that the definition of > > SSP can be > > > 'An SSP is an SP that also includes UASs and UACs...' and > > then a Peer > > > Network can be defined as '...an SSP that has connections > > to peer SSPs > > > via...'. A nice hierarchical definition (start with the > > broadest term > > > and get narrower' generally saves a lot of redefinition, which in > > > itself can create ambiguity. > > > > > > And that leads me quite neatly on to a question - how are you > > > classifying the transit or carrier network that would sit > > between the > > > SSPs to provide interconnectivity? It is clearly an SP > > since it will > > > provide L3 transport of SIP and media, but if my comments > above are > > > right, SP is intended to be an umberella term covering all the > > > sub-variants of SP. It will also need to have some > characteristics > > > dependent upon whether it is expected to provide any additional > > > functionality - it clearly needs to be DiffServ aware, > but it could > > > also be required to provide a bunch of functions around > transcoding > > > and reframing in the media plane, and maybe SIP variant > > interworking, > > > which could imply B2BUAs. It seems though that this > network, be it > > > the internet or something provided by a carrier operator is only > > > alluded to in the definition of Federations. Is there not > > a need to > > > identify it explicitly, even if it is far simpler than I have > > > conceived it to be? I note that in the Architecture document, in > > > Figure 3 a 'Transit IP Provider' is identified (although the text > > > never refers to Figure 3 nor Transit IP Provider), but then > > in Figure > > > 1 of the same document a whole bunch of terms not defined in this > > > document are used... > > > > > > I'd appreciate at least comments on whether what I have > laid out as > > > the herarchy of these terms is right or not, but I'm not > > going to get > > > fussy about whether the proposed shuffle of the ordering > > takes place. > > > > > > Cheers > > > > > > Dan > > > > > > > > > > > > 14) "3.8. Service Provider > > > > > > > > > > > > A Service Provider (or SP) is defined to be an entity > > > > > that provides > > > > > > layer 3 (IP) transport of SIP signaling and media > > > packets. An > > > > > > example of this may be an Internet Service > Provider (ISP)." > > > > > > This at first glance is reasonable, but then the next > > > > > section goes on to > > > > > > define a SIP Service Provider as something that is not a > > > > > special case of > > > > > > a Service Provider, since it operates at layer 5, not at > > > > layer 3. We > > > > > > should perhaps find a different term for "Service Provider" > > > > > when we mean > > > > > > layer 3, e.g., "Network Service Provider". > > > > > That's fine with me....although terms like this are > > ambiguous. I > > > > > think we had specified Internet Service Provider before, > > > but there > > > > > were arguments against being that "specific". So, we > > > > generalized the > > > > > term and just provided it as an example. > > > > [JRE] I think we have to do something. The term SP is > OK if it is > > > > intended to embrace all types of SP that we are dealing with, > > > > including SSP. But if we need a term for an SP that > > operates only at > > > > layer 3, we need a different term. > > > > > > > > > > > > > > > > 15) "A SIP Service Provider (or SSP) is an entity > > that provides > > > > > > application level transport of SIP signaling to its > > > > customers." > > > > > > Elsewhere the document talks about level 5 peering, but > > > > now it talks > > > > > > about application level. Also, isn't it more than just > > > > transport. I > > > > > > don't have a particular proposal, but I don't really like > > > > > the present > > > > > > definition. > > > > > > > > > > Hmmm...I'll see if I can think of something to make > > this clearer. > > > > > Anyone else have an opinion (heh...that's a stupid > > > > question. Everyone > > > > > has an opinion, right?!)? :-) > > > > > > > > > > > > > > > > 16) "3.10. Internet Telephony Service Provider > > > > > > > > > > > > An Internet Telephony Service Provider, or ITSP, is a > > > > > synonym for > > > > > > SSP. While the terms ITSP and SSP are frequently used > > > > > > interchangeably, the SPEERMINT working group uses the > > > > term SSP." > > > > > > So why define the term if we are not going to use it? We > > > > > could mention > > > > > > it in a note below the definition of SSP, if really needed. > > > > > > > > > > > ....don't care either way...we can do that to. Does it > > > > significantly > > > > > make things simpler by doing as you suggest? > > > > [JRE] The point is, by having an explicit definition of > ITSP, it > > > > tends to encourage other SPEERMINT documents to use it, > > even though > > > > there is an explicit statement that SPEERMINT will use > > only SSP. I > > > > thought just making it a note below the definition of SSP > > would help > > > > to de-emphasise ITSP further. > > > > > > Forthcoming GSMA Events: > > > > > > GSMA Mobile Asia Congress > > > Macau > > > 12 - 15 November 2007 > > > www.mobileasiacongress.com > > > > > > GSMA Mobile World Congress > > > Barcelona > > > 11 - 14 February 2008 > > > www.mobileworldcongress.com > > > > > > > > > This email and its attachments are intended for the above > > named only > > > and may be confidential. If they have come to you in > error you must > > > take no action based on them, nor must you copy or show them to > > > anyone; please reply to this email or call +44 207 759 2300 and > > > highlight the error > > > > > > > > > > > > > > > Forthcoming GSMA Events: > > GSMA Mobile Asia Congress > Macau > 12 - 15 November 2007 > www.mobileasiacongress.com > > GSMA Mobile World Congress > Barcelona > 11 - 14 February 2008 > www.mobileworldcongress.com > > > This email and its attachments are intended for the above > named only and may be confidential. If they have come to you > in error you must take no action based on them, nor must you > copy or show them to anyone; please reply to this email or > call +44 207 759 2300 and highlight the error > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 02 08:35:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icgvs-0000x1-L1; Tue, 02 Oct 2007 08:33:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icgvq-0000rX-Gb for speermint@ietf.org; Tue, 02 Oct 2007 08:32:58 -0400 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound7-sin-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icgvi-0002H3-ND for speermint@ietf.org; Tue, 02 Oct 2007 08:32:53 -0400 Received: from outbound7-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound7-sin-R.bigfish.com (Postfix) with ESMTP id B1C4A512B9D; Tue, 2 Oct 2007 12:32:45 +0000 (UTC) Received: from mail38-sin-R.bigfish.com (unknown [10.3.40.3]) by outbound7-sin.bigfish.com (Postfix) with ESMTP id 661AA134006A; Tue, 2 Oct 2007 12:32:45 +0000 (UTC) Received: from mail38-sin (localhost.localdomain [127.0.0.1]) by mail38-sin-R.bigfish.com (Postfix) with ESMTP id D28714701C2; Tue, 2 Oct 2007 12:32:43 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 212.120.142.30; Service: EHS Received: by mail38-sin (MessageSwitch) id 1191328363796167_20432; Tue, 2 Oct 2007 12:32:43 +0000 (UCT) Received: from GSMDUBEX02.GSM.TLD (unknown [212.120.142.30]) by mail38-sin.bigfish.com (Postfix) with ESMTP id AC4891748055; Tue, 2 Oct 2007 12:32:40 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] [wg-business] WGLCfordraft-ietf-speermint-terminology-12 Date: Tue, 2 Oct 2007 13:31:20 +0100 Message-ID: <6918D1F7F8770C4FB182838A7BDFD6C8016FF350@GSMDUBEX02.GSM.TLD> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business] WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgAaIO7/hEeVa9kTQKfLRakKTmBwAAcct/QAPw2WGAAAnUVkAACxNogAAOQLeAAAEPmEA== From: "Dan Warren" To: "Elwell, John" , "Daryl Malas" X-Spam-Score: 1.2 (+) X-Scan-Signature: 5d99cba2a085c3987933aa34e30e85ab Cc: "Malas, Daryl" , "Peterson, , dmm"@1-4-5.net, speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org John You just successfully (maybe inadvertently?) answered my other question from my first mail - how to classify the transit network, particularly the transit where there is SIP awareness. If that transit network is also an SSP then that makes life a little easier to understand. The only question that then remains is whether SSPs for tranist with no UAs should be categorised separately from SSPs that do have UAs but don't peer. But then an SSP with UAs that doesn't peer is not in scope of the work... I'll shut up now. Thanks for the help. Dan = > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] = > Sent: 02 October 2007 13:24 > To: Dan Warren; Daryl Malas > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; = > speermint@ietf.org; Livingood, Jason > Subject: RE: [Speermint] [wg-business] = > WGLCfordraft-ietf-speermint-terminology-12 > = > Dan, > = > It is probably a moot point whether a residential UA is = > within the SSP or not. Perhaps if the UA is in possession of = > credentials for that SSP, allowing it to register and submit = > other requests such as INVITE and MESSAGE, then you might = > regard it as logically part of that SSP. But I guess the main = > point I was trying to make is whether it is a necessary = > condition that an SSP include UAs. Consider a transit SSP = > used in indirect peering. It can be a transit SSP without = > possessing a single UA (gateway, phone, media server or whatever). > = > John > = > = > > -----Original Message----- > > From: Dan Warren [mailto:DWarren@gsm.org] > > Sent: 02 October 2007 11:58 > > To: Elwell, John; Daryl Malas > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; speermint@ietf.org; = > > Livingood, Jason > > Subject: RE: [Speermint] [wg-business] > > WGLCfordraft-ietf-speermint-terminology-12 > > = > > John > > = > > You said... > > = > > 'Is it a necessary condition that an SSP include UAs (other than = > > B2BUAs, perhaps)? I guess it depends what we perceive as = > the scope of = > > an SSP. > > UAs such as PSTN gateways, media servers, etc. might be considered = > > part of the SSP. But a UA in a user's home that uses the = > services of = > > an SSP? > > That to me is not really part of the SSP.' > > = > > I agree that under the current terminology and associated = > definitions = > > it isn't, but lets consider what the practicalities of = > implementation = > > are. > > Suppose I have a UA on my laptop. Unless the ISP I am using is = > > handling the SIP signalling from that UA in a special way compared = > > with other non-SIP traffic, then the ISP is operating as a SP (as = > > defined in 3.8). > > The UA has to be associated with some sort of network where my = > > sessions are handled, applications are applied and methods are = > > forwarded. This has to be in an SSP/ITSP, and if that SSP = > is attached = > > to other SSPs then it is also a Peer Network. I guess the = > point is, = > > do we conceive of UA's that are in homes that do not need = > to have an = > > association with an SSP, even if it is only short term? > > = > > I have to admit that on reading your mail I figured I had made a = > > mistake, but then on analysing the text and thinking about = > it, I think = > > it is an interesting question. Maybe the way to consider it is = > > conversely - what do you classify a 'set of SIP user agent servers > > (UASs) [2] and SIP user agent clients (UACs) [2] = > (customers) that are = > > controlled by a single administrative domain' but do not = > peer? So a = > > completely self contained and non-peering network... If an = > SSP does = > > not imply UACs and UASs, what is the level of SIP awareness = > within the = > > SSP space? > > = > > I am not trying to be intentionally provocative, I am just = > aware that = > > there seems to be some gaps in the definitions like could = > be usefully = > > closed before they cause problems when we need a term for a network = > > classification that is not defined... I again make note = > though that I > > am coming to this with fresh eyes and it might be that I am just = > > misunderstanding what is written. > > = > > Cheers > > = > > Dan > > = > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: 02 October 2007 10:24 > > > To: Dan Warren; Daryl Malas > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; = > speermint@ietf.org; = > > > Livingood, Jason > > > Subject: RE: [Speermint] [wg-business] > > > WGLCfordraft-ietf-speermint-terminology-12 > > > = > > > Dan, > > > = > > > I agree with most of what you say. One point, however, is your = > > > proposal: > > > 'An SSP is an SP that also includes UASs and UACs...' = > (which I guess = > > > comes from text in the existing definition of Peer = > Network, which I = > > > failed to comment on). > > > = > > > Is it a necessary condition that an SSP include UAs (other than = > > > B2BUAs, perhaps)? I guess it depends what we perceive as = > the scope = > > > of an SSP. > > > UAs such as PSTN gateways, media servers, etc. might be = > considered = > > > part of the SSP. But a UA in a user's home that uses the = > services of = > > > an SSP? > > > That to me is not really part of the SSP. > > > = > > > John > > > = > > > > -----Original Message----- > > > > From: Dan Warren [mailto:DWarren@gsm.org] > > > > Sent: 02 October 2007 09:45 > > > > To: Elwell, John; Daryl Malas > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > speermint@ietf.org; > > > > Livingood, Jason > > > > Subject: RE: [Speermint] [wg-business] > > > > WGLCfordraft-ietf-speermint-terminology-12 > > > > = > > > > All > > > > = > > > > Some of the points made by John (in his comments 14, 15 and > > > > 16) I agree > > > > with but I think it goes further than that. So rather than > > > making a > > > > proper comment, can I check my understanding of the terms > > > as someone > > > > that has picked the spec up recently and tried to understand it? > > > > = > > > > There are four terms relating to network types - peer > > > network, service > > > > provider, SIP Service Provider and Internet Telephony Service = > > > > Provider. > > > > The document states that SSP and ITSP are synonymous, > > > although I might > > > > argue that an ITSP is a subset of an SSP, purely because > > > the 'T' part > > > > suggests a specific service attributable to the UA's = > within that = > > > > network and hence also implies something about the way that > > > service is > > > > delivered (or at least ought to). SSP is more general and > > > hence could > > > > include applications that do not have the same requirements > > > on QoS and > > > > hence do not require the same DSCP marking, but if you are > > > all happy > > > > for these to be equivalent, I am not going to fuss about > > > the semantics > > > > of what is implied by 'telephony'. > > > > = > > > > Now I get slightly confused. A Peer Network sounds = > like it is a = > > > > special case of an SSP - in effect a peered SSP. Is that > > > correct? If > > > > so I'd suggest for readability of the document, SSP is > > > defined before > > > > Peer Network, and Peer Network is defined as I describe above. > > > > = > > > > Similarly, an SSP seems to be a specialised SP, in that not > > > only does > > > > it provide L3 transport of SIP signalling and media > > > packets, but also > > > > includes SIP end points. Similar to my last point, it > > > would help the > > > > document to define SP before SSP, so that the definition of > > > SSP can be > > > > 'An SSP is an SP that also includes UASs and UACs...' and > > > then a Peer > > > > Network can be defined as '...an SSP that has connections > > > to peer SSPs > > > > via...'. A nice hierarchical definition (start with the > > > broadest term > > > > and get narrower' generally saves a lot of = > redefinition, which in = > > > > itself can create ambiguity. > > > > = > > > > And that leads me quite neatly on to a question - how are you = > > > > classifying the transit or carrier network that would sit > > > between the > > > > SSPs to provide interconnectivity? It is clearly an SP > > > since it will > > > > provide L3 transport of SIP and media, but if my comments > > above are > > > > right, SP is intended to be an umberella term covering all the = > > > > sub-variants of SP. It will also need to have some > > characteristics > > > > dependent upon whether it is expected to provide any additional = > > > > functionality - it clearly needs to be DiffServ aware, > > but it could > > > > also be required to provide a bunch of functions around > > transcoding > > > > and reframing in the media plane, and maybe SIP variant > > > interworking, > > > > which could imply B2BUAs. It seems though that this > > network, be it > > > > the internet or something provided by a carrier = > operator is only = > > > > alluded to in the definition of Federations. Is there not > > > a need to > > > > identify it explicitly, even if it is far simpler than I have = > > > > conceived it to be? I note that in the Architecture = > document, in = > > > > Figure 3 a 'Transit IP Provider' is identified = > (although the text = > > > > never refers to Figure 3 nor Transit IP Provider), but then > > > in Figure > > > > 1 of the same document a whole bunch of terms not = > defined in this = > > > > document are used... > > > > = > > > > I'd appreciate at least comments on whether what I have > > laid out as > > > > the herarchy of these terms is right or not, but I'm not > > > going to get > > > > fussy about whether the proposed shuffle of the ordering > > > takes place. > > > > = > > > > Cheers > > > > = > > > > Dan > > > > = > > > > = > > > > > > > 14) "3.8. Service Provider > > > > > > > = > > > > > > > A Service Provider (or SP) is defined to be an entity > > > > > > that provides > > > > > > > layer 3 (IP) transport of SIP signaling and media > > > > packets. An > > > > > > > example of this may be an Internet Service > > Provider (ISP)." > > > > > > > This at first glance is reasonable, but then the next > > > > > > section goes on to > > > > > > > define a SIP Service Provider as something that is not a > > > > > > special case of > > > > > > > a Service Provider, since it operates at layer 5, not at > > > > > layer 3. We > > > > > > > should perhaps find a different term for "Service = > Provider" > > > > > > when we mean > > > > > > > layer 3, e.g., "Network Service Provider". > > > > > > That's fine with me....although terms like this are > > > ambiguous. I > > > > > > think we had specified Internet Service Provider before, > > > > but there > > > > > > were arguments against being that "specific". So, we > > > > > generalized the > > > > > > term and just provided it as an example. > > > > > [JRE] I think we have to do something. The term SP is > > OK if it is > > > > > intended to embrace all types of SP that we are dealing with, = > > > > > including SSP. But if we need a term for an SP that > > > operates only at > > > > > layer 3, we need a different term. > > > > > = > > > > > > > = > > > > > > > 15) "A SIP Service Provider (or SSP) is an entity > > > that provides > > > > > > > application level transport of SIP signaling to its > > > > > customers." = > > > > > > > Elsewhere the document talks about level 5 peering, but > > > > > now it talks > > > > > > > about application level. Also, isn't it more than just > > > > > transport. I > > > > > > > don't have a particular proposal, but I don't really like > > > > > > the present > > > > > > > definition. > > > > > > = > > > > > > Hmmm...I'll see if I can think of something to make > > > this clearer. > > > > > > Anyone else have an opinion (heh...that's a stupid > > > > > question. Everyone > > > > > > has an opinion, right?!)? :-) > > > > > = > > > > > > > = > > > > > > > 16) "3.10. Internet Telephony Service Provider > > > > > > > = > > > > > > > An Internet Telephony Service Provider, or ITSP, is a > > > > > > synonym for > > > > > > > SSP. While the terms ITSP and SSP are frequently used = > > > > > > > interchangeably, the SPEERMINT working group uses the > > > > > term SSP." > > > > > > > So why define the term if we are not going to use it? We > > > > > > could mention > > > > > > > it in a note below the definition of SSP, if = > really needed. > > > > > > > = > > > > > > ....don't care either way...we can do that to. Does it > > > > > significantly > > > > > > make things simpler by doing as you suggest? > > > > > [JRE] The point is, by having an explicit definition of > > ITSP, it > > > > > tends to encourage other SPEERMINT documents to use it, > > > even though > > > > > there is an explicit statement that SPEERMINT will use > > > only SSP. I > > > > > thought just making it a note below the definition of SSP > > > would help > > > > > to de-emphasise ITSP further. > > > > = > > > > Forthcoming GSMA Events: > > > > = > > > > GSMA Mobile Asia Congress > > > > Macau > > > > 12 - 15 November 2007 > > > > www.mobileasiacongress.com > > > > = > > > > GSMA Mobile World Congress > > > > Barcelona > > > > 11 - 14 February 2008 > > > > www.mobileworldcongress.com > > > > = > > > > = > > > > This email and its attachments are intended for the above > > > named only > > > > and may be confidential. If they have come to you in > > error you must > > > > take no action based on them, nor must you copy or show them to = > > > > anyone; please reply to this email or call +44 207 759 2300 and = > > > > highlight the error > > > > = > > > > = > > > > = > > > = > > > = > > = > > Forthcoming GSMA Events: > > = > > GSMA Mobile Asia Congress > > Macau > > 12 - 15 November 2007 > > www.mobileasiacongress.com > > = > > GSMA Mobile World Congress > > Barcelona > > 11 - 14 February 2008 > > www.mobileworldcongress.com > > = > > = > > This email and its attachments are intended for the above = > named only = > > and may be confidential. If they have come to you in error you must = > > take no action based on them, nor must you copy or show them to = > > anyone; please reply to this email or call +44 207 759 2300 and = > > highlight the error > > = > > = > > = > = > = Forthcoming GSMA Events: = GSMA Mobile Asia Congress Macau 12 - 15 November 2007 www.mobileasiacongress.com = GSMA Mobile World Congress Barcelona 11 - 14 February 2008 www.mobileworldcongress.com This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 759 2300 and highlight the error _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 02 10:27:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icigx-0005aB-6p; Tue, 02 Oct 2007 10:25:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icigv-0005RV-U5 for speermint@ietf.org; Tue, 02 Oct 2007 10:25:41 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icigq-0005n6-7X for speermint@ietf.org; Tue, 02 Oct 2007 10: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 B1E549193; Tue, 2 Oct 2007 10:25:25 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Oct 2007 10:25: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] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Date: Tue, 2 Oct 2007 10:25:22 -0400 Message-ID: In-Reply-To: <6918D1F7F8770C4FB182838A7BDFD6C8016FF350@GSMDUBEX02.GSM.TLD> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgAaIO7/hEeVa9kTQKfLRakKTmBwAAcct/QAPw2WGAAAnUVkAACxNogAAOQLeAAAEPmEAADblfA References: <6918D1F7F8770C4FB182838A7BDFD6C8016FF350@GSMDUBEX02.GSM.TLD> From: "Uzelac, Adam" To: "Dan Warren" , "Elwell, John" , "Daryl Malas" X-OriginalArrivalTime: 02 Oct 2007 14:25:25.0141 (UTC) FILETIME=[12AB3C50:01C80500] X-Spam-Score: 1.2 (+) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 Cc: "Malas, Daryl" , "Peterson, , dmm"@1-4-5.net, speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > I'll shut up now. Thanks for the help. >=20 > Dan=20 Oh no - you don't get to run away so quickly! ;) I think there's some "wrongness" going on here. The transit SSP scenario can and does (in the real world) contain both UACs and UASs. The bare minimum would be UASs I believe. The transit most certainly is a SSP, as is the originating and terminating domain. There may be more than one transit. Any and all of the SSPs can have UACs and/or UASs. It's more about the function that the domain performs or pertains to.=20 If a residential UA is registered to a UAS or not really shouldn't matter. A residential UA alone with some static SIP-routing would define the originating domain. If there's reachability with other UAs without crossing into another SSP, like sessions in the same building, neighborhood, business group, etc - these are all within the same domain and no peering occurs. Should the look-up function result in the terminating UA being in the terminating domain (think called party) - then it's a peer relationship between 2 parties: SSP(O) <---> SSP(T) If there's no direct path between the originating domain [SSP(O)] and the terminating domain [SSP(T)], then employment of an intermediary or transit domain [SSP(t)] may, and oftentimes does, get used: SSP(O) <---> SSP(t) <---> SSP(T) I don't know if that clears things up or not, but it's how I organize the world. ;) -AU > -----Original Message----- > From: Dan Warren [mailto:DWarren@gsm.org]=20 > Sent: Tuesday, October 02, 2007 8:31 AM > To: Elwell, John; Daryl Malas > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net;=20 > speermint@ietf.org; Livingood, Jason > Subject: RE: [Speermint]=20 > [wg-business]WGLCfordraft-ietf-speermint-terminology-12 >=20 > John >=20 > You just successfully (maybe inadvertently?) answered my=20 > other question from my first mail - how to classify the=20 > transit network, particularly the transit where there is SIP=20 > awareness. If that transit network is also an SSP then that=20 > makes life a little easier to understand. >=20 > The only question that then remains is whether SSPs for=20 > tranist with no UAs should be categorised separately from=20 > SSPs that do have UAs but don't peer. But then an SSP with=20 > UAs that doesn't peer is not in scope of the work... >=20 > I'll shut up now. Thanks for the help. >=20 > Dan=20 >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: 02 October 2007 13:24 > > To: Dan Warren; Daryl Malas > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; speermint@ietf.org;=20 > > Livingood, Jason > > Subject: RE: [Speermint] [wg-business] > > WGLCfordraft-ietf-speermint-terminology-12 > >=20 > > Dan, > >=20 > > It is probably a moot point whether a residential UA is=20 > within the SSP=20 > > or not. Perhaps if the UA is in possession of credentials for that=20 > > SSP, allowing it to register and submit other requests such=20 > as INVITE=20 > > and MESSAGE, then you might regard it as logically part of=20 > that SSP.=20 > > But I guess the main point I was trying to make is whether it is a=20 > > necessary condition that an SSP include UAs. Consider a transit SSP=20 > > used in indirect peering. It can be a transit SSP without=20 > possessing a=20 > > single UA (gateway, phone, media server or whatever). > >=20 > > John > > =20 > >=20 > > > -----Original Message----- > > > From: Dan Warren [mailto:DWarren@gsm.org] > > > Sent: 02 October 2007 11:58 > > > To: Elwell, John; Daryl Malas > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net;=20 > speermint@ietf.org;=20 > > > Livingood, Jason > > > Subject: RE: [Speermint] [wg-business] > > > WGLCfordraft-ietf-speermint-terminology-12 > > >=20 > > > John > > >=20 > > > You said... > > >=20 > > > 'Is it a necessary condition that an SSP include UAs (other than=20 > > > B2BUAs, perhaps)? I guess it depends what we perceive as > > the scope of > > > an SSP. > > > UAs such as PSTN gateways, media servers, etc. might be=20 > considered=20 > > > part of the SSP. But a UA in a user's home that uses the > > services of > > > an SSP? > > > That to me is not really part of the SSP.' > > >=20 > > > I agree that under the current terminology and associated > > definitions > > > it isn't, but lets consider what the practicalities of > > implementation > > > are. > > > Suppose I have a UA on my laptop. Unless the ISP I am using is=20 > > > handling the SIP signalling from that UA in a special way=20 > compared=20 > > > with other non-SIP traffic, then the ISP is operating as a SP (as=20 > > > defined in 3.8). > > > The UA has to be associated with some sort of network where my=20 > > > sessions are handled, applications are applied and methods are=20 > > > forwarded. This has to be in an SSP/ITSP, and if that SSP > > is attached > > > to other SSPs then it is also a Peer Network. I guess the > > point is, > > > do we conceive of UA's that are in homes that do not need > > to have an > > > association with an SSP, even if it is only short term? > > >=20 > > > I have to admit that on reading your mail I figured I had made a=20 > > > mistake, but then on analysing the text and thinking about > > it, I think > > > it is an interesting question. Maybe the way to consider it is=20 > > > conversely - what do you classify a 'set of SIP user agent servers > > > (UASs) [2] and SIP user agent clients (UACs) [2] > > (customers) that are > > > controlled by a single administrative domain' but do not > > peer? So a > > > completely self contained and non-peering network... If an > > SSP does > > > not imply UACs and UASs, what is the level of SIP awareness > > within the > > > SSP space? > > >=20 > > > I am not trying to be intentionally provocative, I am just > > aware that > > > there seems to be some gaps in the definitions like could > > be usefully > > > closed before they cause problems when we need a term for=20 > a network=20 > > > classification that is not defined... I again make note > > though that I > > > am coming to this with fresh eyes and it might be that I am just=20 > > > misunderstanding what is written. > > >=20 > > > Cheers > > >=20 > > > Dan > > >=20 > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > Sent: 02 October 2007 10:24 > > > > To: Dan Warren; Daryl Malas > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > speermint@ietf.org; > > > > Livingood, Jason > > > > Subject: RE: [Speermint] [wg-business] > > > > WGLCfordraft-ietf-speermint-terminology-12 > > > >=20 > > > > Dan, > > > >=20 > > > > I agree with most of what you say. One point, however, is your > > > > proposal: > > > > 'An SSP is an SP that also includes UASs and UACs...'=20 > > (which I guess > > > > comes from text in the existing definition of Peer > > Network, which I > > > > failed to comment on). > > > >=20 > > > > Is it a necessary condition that an SSP include UAs (other than=20 > > > > B2BUAs, perhaps)? I guess it depends what we perceive as > > the scope > > > > of an SSP. > > > > UAs such as PSTN gateways, media servers, etc. might be > > considered > > > > part of the SSP. But a UA in a user's home that uses the > > services of > > > > an SSP? > > > > That to me is not really part of the SSP. > > > >=20 > > > > John > > > >=20 > > > > > -----Original Message----- > > > > > From: Dan Warren [mailto:DWarren@gsm.org] > > > > > Sent: 02 October 2007 09:45 > > > > > To: Elwell, John; Daryl Malas > > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > > speermint@ietf.org; > > > > > Livingood, Jason > > > > > Subject: RE: [Speermint] [wg-business] > > > > > WGLCfordraft-ietf-speermint-terminology-12 > > > > >=20 > > > > > All > > > > >=20 > > > > > Some of the points made by John (in his comments 14, 15 and > > > > > 16) I agree > > > > > with but I think it goes further than that. So rather than > > > > making a > > > > > proper comment, can I check my understanding of the terms > > > > as someone > > > > > that has picked the spec up recently and tried to=20 > understand it? > > > > >=20 > > > > > There are four terms relating to network types - peer > > > > network, service > > > > > provider, SIP Service Provider and Internet Telephony Service=20 > > > > > Provider. > > > > > The document states that SSP and ITSP are synonymous, > > > > although I might > > > > > argue that an ITSP is a subset of an SSP, purely because > > > > the 'T' part > > > > > suggests a specific service attributable to the UA's > > within that > > > > > network and hence also implies something about the way that > > > > service is > > > > > delivered (or at least ought to). SSP is more general and > > > > hence could > > > > > include applications that do not have the same requirements > > > > on QoS and > > > > > hence do not require the same DSCP marking, but if you are > > > > all happy > > > > > for these to be equivalent, I am not going to fuss about > > > > the semantics > > > > > of what is implied by 'telephony'. > > > > >=20 > > > > > Now I get slightly confused. A Peer Network sounds > > like it is a > > > > > special case of an SSP - in effect a peered SSP. Is that > > > > correct? If > > > > > so I'd suggest for readability of the document, SSP is > > > > defined before > > > > > Peer Network, and Peer Network is defined as I describe above. > > > > >=20 > > > > > Similarly, an SSP seems to be a specialised SP, in that not > > > > only does > > > > > it provide L3 transport of SIP signalling and media > > > > packets, but also > > > > > includes SIP end points. Similar to my last point, it > > > > would help the > > > > > document to define SP before SSP, so that the definition of > > > > SSP can be > > > > > 'An SSP is an SP that also includes UASs and UACs...' and > > > > then a Peer > > > > > Network can be defined as '...an SSP that has connections > > > > to peer SSPs > > > > > via...'. A nice hierarchical definition (start with the > > > > broadest term > > > > > and get narrower' generally saves a lot of > > redefinition, which in > > > > > itself can create ambiguity. > > > > >=20 > > > > > And that leads me quite neatly on to a question - how are you=20 > > > > > classifying the transit or carrier network that would sit > > > > between the > > > > > SSPs to provide interconnectivity? It is clearly an SP > > > > since it will > > > > > provide L3 transport of SIP and media, but if my comments > > > above are > > > > > right, SP is intended to be an umberella term=20 > covering all the=20 > > > > > sub-variants of SP. It will also need to have some > > > characteristics > > > > > dependent upon whether it is expected to provide any=20 > additional=20 > > > > > functionality - it clearly needs to be DiffServ aware, > > > but it could > > > > > also be required to provide a bunch of functions around > > > transcoding > > > > > and reframing in the media plane, and maybe SIP variant > > > > interworking, > > > > > which could imply B2BUAs. It seems though that this > > > network, be it > > > > > the internet or something provided by a carrier > > operator is only > > > > > alluded to in the definition of Federations. Is there not > > > > a need to > > > > > identify it explicitly, even if it is far simpler than I have=20 > > > > > conceived it to be? I note that in the Architecture > > document, in > > > > > Figure 3 a 'Transit IP Provider' is identified > > (although the text > > > > > never refers to Figure 3 nor Transit IP Provider), but then > > > > in Figure > > > > > 1 of the same document a whole bunch of terms not > > defined in this > > > > > document are used... > > > > >=20 > > > > > I'd appreciate at least comments on whether what I have > > > laid out as > > > > > the herarchy of these terms is right or not, but I'm not > > > > going to get > > > > > fussy about whether the proposed shuffle of the ordering > > > > takes place. > > > > >=20 > > > > > Cheers > > > > >=20 > > > > > Dan > > > > >=20 > > > > >=20 > > > > > > > > 14) "3.8. Service Provider > > > > > > > >=20 > > > > > > > > A Service Provider (or SP) is defined to be an entity > > > > > > > that provides > > > > > > > > layer 3 (IP) transport of SIP signaling and media > > > > > packets. An > > > > > > > > example of this may be an Internet Service > > > Provider (ISP)." > > > > > > > > This at first glance is reasonable, but then the next > > > > > > > section goes on to > > > > > > > > define a SIP Service Provider as something that is not a > > > > > > > special case of > > > > > > > > a Service Provider, since it operates at layer 5, not at > > > > > > layer 3. We > > > > > > > > should perhaps find a different term for "Service > > Provider" > > > > > > > when we mean > > > > > > > > layer 3, e.g., "Network Service Provider". > > > > > > > That's fine with me....although terms like this are > > > > ambiguous. I > > > > > > > think we had specified Internet Service Provider before, > > > > > but there > > > > > > > were arguments against being that "specific". So, we > > > > > > generalized the > > > > > > > term and just provided it as an example. > > > > > > [JRE] I think we have to do something. The term SP is > > > OK if it is > > > > > > intended to embrace all types of SP that we are=20 > dealing with,=20 > > > > > > including SSP. But if we need a term for an SP that > > > > operates only at > > > > > > layer 3, we need a different term. > > > > > >=20 > > > > > > > >=20 > > > > > > > > 15) "A SIP Service Provider (or SSP) is an entity > > > > that provides > > > > > > > > application level transport of SIP signaling to its > > > > > > customers."=20 > > > > > > > > Elsewhere the document talks about level 5 peering, but > > > > > > now it talks > > > > > > > > about application level. Also, isn't it more than just > > > > > > transport. I > > > > > > > > don't have a particular proposal, but I don't=20 > really like > > > > > > > the present > > > > > > > > definition. > > > > > > >=20 > > > > > > > Hmmm...I'll see if I can think of something to make > > > > this clearer. > > > > > > > Anyone else have an opinion (heh...that's a stupid > > > > > > question. Everyone > > > > > > > has an opinion, right?!)? :-) > > > > > >=20 > > > > > > > >=20 > > > > > > > > 16) "3.10. Internet Telephony Service Provider > > > > > > > >=20 > > > > > > > > An Internet Telephony Service Provider, or ITSP, is a > > > > > > > synonym for > > > > > > > > SSP. While the terms ITSP and SSP are=20 > frequently used=20 > > > > > > > > interchangeably, the SPEERMINT working group uses the > > > > > > term SSP." > > > > > > > > So why define the term if we are not going to use it? We > > > > > > > could mention > > > > > > > > it in a note below the definition of SSP, if > > really needed. > > > > > > > >=20 > > > > > > > ....don't care either way...we can do that to. Does it > > > > > > significantly > > > > > > > make things simpler by doing as you suggest? > > > > > > [JRE] The point is, by having an explicit definition of > > > ITSP, it > > > > > > tends to encourage other SPEERMINT documents to use it, > > > > even though > > > > > > there is an explicit statement that SPEERMINT will use > > > > only SSP. I > > > > > > thought just making it a note below the definition of SSP > > > > would help > > > > > > to de-emphasise ITSP further. > > > > >=20 > > > > > Forthcoming GSMA Events: > > > > > =20 > > > > > GSMA Mobile Asia Congress > > > > > Macau > > > > > 12 - 15 November 2007 > > > > > www.mobileasiacongress.com > > > > > =20 > > > > > GSMA Mobile World Congress > > > > > Barcelona > > > > > 11 - 14 February 2008 > > > > > www.mobileworldcongress.com > > > > >=20 > > > > >=20 > > > > > This email and its attachments are intended for the above > > > > named only > > > > > and may be confidential. If they have come to you in > > > error you must > > > > > take no action based on them, nor must you copy or=20 > show them to=20 > > > > > anyone; please reply to this email or call +44 207=20 > 759 2300 and=20 > > > > > highlight the error > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > >=20 > > > Forthcoming GSMA Events: > > > =20 > > > GSMA Mobile Asia Congress > > > Macau > > > 12 - 15 November 2007 > > > www.mobileasiacongress.com > > > =20 > > > GSMA Mobile World Congress > > > Barcelona > > > 11 - 14 February 2008 > > > www.mobileworldcongress.com > > >=20 > > >=20 > > > This email and its attachments are intended for the above > > named only > > > and may be confidential. If they have come to you in=20 > error you must=20 > > > take no action based on them, nor must you copy or show them to=20 > > > anyone; please reply to this email or call +44 207 759 2300 and=20 > > > highlight the error > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 > Forthcoming GSMA Events: > =20 > GSMA Mobile Asia Congress > Macau > 12 - 15 November 2007 > www.mobileasiacongress.com > =20 > GSMA Mobile World Congress > Barcelona > 11 - 14 February 2008 > www.mobileworldcongress.com >=20 >=20 > This email and its attachments are intended for the above=20 > named only and may be confidential. If they have come to you=20 > in error you must take no action based on them, nor must you=20 > copy or show them to anyone; please reply to this email or=20 > call +44 207 759 2300 and highlight the error >=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 Tue Oct 02 10:48:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icj1j-0001lZ-JG; Tue, 02 Oct 2007 10:47:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icj1h-0001eM-Ux for speermint@ietf.org; Tue, 02 Oct 2007 10:47:09 -0400 Received: from mail-dub.bigfish.com ([213.199.154.10] helo=mail111-dub-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Icj1W-0003jh-CB for speermint@ietf.org; Tue, 02 Oct 2007 10:47:04 -0400 Received: from mail111-dub (localhost.localdomain [127.0.0.1]) by mail111-dub-R.bigfish.com (Postfix) with ESMTP id 8DB2A16A8316; Tue, 2 Oct 2007 14:46:40 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 212.120.142.30; Service: EHS Received: by mail111-dub (MessageSwitch) id 1191336399293870_3576; Tue, 2 Oct 2007 14:46:39 +0000 (UCT) Received: from GSMDUBEX02.GSM.TLD (unknown [212.120.142.30]) by mail111-dub.bigfish.com (Postfix) with ESMTP id BEDBA17A005D; Tue, 2 Oct 2007 14:46:37 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Date: Tue, 2 Oct 2007 15:42:31 +0100 Message-ID: <6918D1F7F8770C4FB182838A7BDFD6C8016FF424@GSMDUBEX02.GSM.TLD> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgAaIO7/hEeVa9kTQKfLRakKTmBwAAcct/QAPw2WGAAAnUVkAACxNogAAOQLeAAAEPmEAADblfAAAEF83A= From: "Dan Warren" To: "Uzelac, Adam" , "Elwell, John" , "Daryl Malas" X-Spam-Score: 1.2 (+) X-Scan-Signature: c6d4566aad1fef50f784fa8a77ccada7 Cc: "Malas, Daryl" , "Peterson, , dmm"@1-4-5.net, speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org = > = > > I'll shut up now. Thanks for the help. > > = > > Dan > = > Oh no - you don't get to run away so quickly! ;) = Well in that case... > I think = > there's some "wrongness" going on here. The transit SSP = > scenario can and does (in > the real world) contain both UACs and UASs. The bare = > minimum would be > UASs I believe. The transit most certainly is a SSP, as is = > the originating and terminating domain. There may be more = > than one transit. > Any and all of the SSPs can have UACs and/or UASs. It's more = > about the function that the domain performs or pertains to. = > = > If a residential UA is registered to a UAS or not really = > shouldn't matter. A residential UA alone with some static = > SIP-routing would define the originating domain. If there's = > reachability with other UAs without crossing into another = > SSP, like sessions in the same building, neighborhood, = > business group, etc - these are all within the same domain = > and no peering occurs. Should the look-up function result in = > the terminating UA being in the terminating domain (think = > called party) - then it's a peer relationship between 2 parties: > = > SSP(O) <---> SSP(T) > = > If there's no direct path between the originating domain = > [SSP(O)] and the terminating domain [SSP(T)], then employment = > of an intermediary or transit domain [SSP(t)] may, and = > oftentimes does, get used: > = > SSP(O) <---> SSP(t) <---> SSP(T) > = > I don't know if that clears things up or not, but it's how I = > organize the world. ;) > = > -AU I think we are all arguing the same way now. There is a question of semantics and a question of reality. So semantics (and the definition in the terminology draft) says that the SSP does not have to include UAS's and/or UAC's but the reality is that the concept of a SSP with UAS's or UAC's is pretty hard to comprehend. In your example above SSP(t) is ONLY an SSP, whilst SSP(O) and SSP(T) are both Peer Networks (which in my mind at least is a special case of SSP) since they are *ahem* well, peering. UA(O) and UA(T) may attach to SSP(O) and SSP(T) respectively across SP's (single S intentional) such as a DSL provider that is providing pure connectivity at L3. So what is the nature of SSP(t)? Does it have to have UAS and UACs to be L5 aware? Or could it just be contain SIP Proxies, making it an SSP with UAS and UACs as John proposed? If it doesn't have any SIP awareness, then it is clearly just an SP since again, it is just L3 connectivity based. > = > = > > -----Original Message----- > > From: Dan Warren [mailto:DWarren@gsm.org] > > Sent: Tuesday, October 02, 2007 8:31 AM > > To: Elwell, John; Daryl Malas > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; speermint@ietf.org; = > > Livingood, Jason > > Subject: RE: [Speermint] > > [wg-business]WGLCfordraft-ietf-speermint-terminology-12 > > = > > John > > = > > You just successfully (maybe inadvertently?) answered my other = > > question from my first mail - how to classify the transit network, = > > particularly the transit where there is SIP awareness. If that = > > transit network is also an SSP then that makes life a = > little easier to = > > understand. > > = > > The only question that then remains is whether SSPs for = > tranist with = > > no UAs should be categorised separately from SSPs that do = > have UAs but = > > don't peer. But then an SSP with UAs that doesn't peer is not in = > > scope of the work... > > = > > I'll shut up now. Thanks for the help. > > = > > Dan > > = > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: 02 October 2007 13:24 > > > To: Dan Warren; Daryl Malas > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; = > speermint@ietf.org; = > > > Livingood, Jason > > > Subject: RE: [Speermint] [wg-business] > > > WGLCfordraft-ietf-speermint-terminology-12 > > > = > > > Dan, > > > = > > > It is probably a moot point whether a residential UA is > > within the SSP > > > or not. Perhaps if the UA is in possession of credentials = > for that = > > > SSP, allowing it to register and submit other requests such > > as INVITE > > > and MESSAGE, then you might regard it as logically part of > > that SSP. = > > > But I guess the main point I was trying to make is = > whether it is a = > > > necessary condition that an SSP include UAs. Consider a = > transit SSP = > > > used in indirect peering. It can be a transit SSP without > > possessing a > > > single UA (gateway, phone, media server or whatever). > > > = > > > John > > > = > > > = > > > > -----Original Message----- > > > > From: Dan Warren [mailto:DWarren@gsm.org] > > > > Sent: 02 October 2007 11:58 > > > > To: Elwell, John; Daryl Malas > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > speermint@ietf.org; > > > > Livingood, Jason > > > > Subject: RE: [Speermint] [wg-business] > > > > WGLCfordraft-ietf-speermint-terminology-12 > > > > = > > > > John > > > > = > > > > You said... > > > > = > > > > 'Is it a necessary condition that an SSP include UAs = > (other than = > > > > B2BUAs, perhaps)? I guess it depends what we perceive as > > > the scope of > > > > an SSP. > > > > UAs such as PSTN gateways, media servers, etc. might be > > considered > > > > part of the SSP. But a UA in a user's home that uses the > > > services of > > > > an SSP? > > > > That to me is not really part of the SSP.' > > > > = > > > > I agree that under the current terminology and associated > > > definitions > > > > it isn't, but lets consider what the practicalities of > > > implementation > > > > are. > > > > Suppose I have a UA on my laptop. Unless the ISP I am using is = > > > > handling the SIP signalling from that UA in a special way > > compared > > > > with other non-SIP traffic, then the ISP is operating = > as a SP (as = > > > > defined in 3.8). > > > > The UA has to be associated with some sort of network where my = > > > > sessions are handled, applications are applied and methods are = > > > > forwarded. This has to be in an SSP/ITSP, and if that SSP > > > is attached > > > > to other SSPs then it is also a Peer Network. I guess the > > > point is, > > > > do we conceive of UA's that are in homes that do not need > > > to have an > > > > association with an SSP, even if it is only short term? > > > > = > > > > I have to admit that on reading your mail I figured I = > had made a = > > > > mistake, but then on analysing the text and thinking about > > > it, I think > > > > it is an interesting question. Maybe the way to consider it is = > > > > conversely - what do you classify a 'set of SIP user = > agent servers > > > > (UASs) [2] and SIP user agent clients (UACs) [2] > > > (customers) that are > > > > controlled by a single administrative domain' but do not > > > peer? So a > > > > completely self contained and non-peering network... If an > > > SSP does > > > > not imply UACs and UASs, what is the level of SIP awareness > > > within the > > > > SSP space? > > > > = > > > > I am not trying to be intentionally provocative, I am just > > > aware that > > > > there seems to be some gaps in the definitions like could > > > be usefully > > > > closed before they cause problems when we need a term for > > a network > > > > classification that is not defined... I again make note > > > though that I > > > > am coming to this with fresh eyes and it might be that = > I am just = > > > > misunderstanding what is written. > > > > = > > > > Cheers > > > > = > > > > Dan > > > > = > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > > Sent: 02 October 2007 10:24 > > > > > To: Dan Warren; Daryl Malas > > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > > speermint@ietf.org; > > > > > Livingood, Jason > > > > > Subject: RE: [Speermint] [wg-business] > > > > > WGLCfordraft-ietf-speermint-terminology-12 > > > > > = > > > > > Dan, > > > > > = > > > > > I agree with most of what you say. One point, however, is your > > > > > proposal: > > > > > 'An SSP is an SP that also includes UASs and UACs...' = > > > (which I guess > > > > > comes from text in the existing definition of Peer > > > Network, which I > > > > > failed to comment on). > > > > > = > > > > > Is it a necessary condition that an SSP include UAs = > (other than = > > > > > B2BUAs, perhaps)? I guess it depends what we perceive as > > > the scope > > > > > of an SSP. > > > > > UAs such as PSTN gateways, media servers, etc. might be > > > considered > > > > > part of the SSP. But a UA in a user's home that uses the > > > services of > > > > > an SSP? > > > > > That to me is not really part of the SSP. > > > > > = > > > > > John > > > > > = > > > > > > -----Original Message----- > > > > > > From: Dan Warren [mailto:DWarren@gsm.org] > > > > > > Sent: 02 October 2007 09:45 > > > > > > To: Elwell, John; Daryl Malas > > > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > > > speermint@ietf.org; > > > > > > Livingood, Jason > > > > > > Subject: RE: [Speermint] [wg-business] > > > > > > WGLCfordraft-ietf-speermint-terminology-12 > > > > > > = > > > > > > All > > > > > > = > > > > > > Some of the points made by John (in his comments 14, 15 and > > > > > > 16) I agree > > > > > > with but I think it goes further than that. So rather than > > > > > making a > > > > > > proper comment, can I check my understanding of the terms > > > > > as someone > > > > > > that has picked the spec up recently and tried to > > understand it? > > > > > > = > > > > > > There are four terms relating to network types - peer > > > > > network, service > > > > > > provider, SIP Service Provider and Internet = > Telephony Service = > > > > > > Provider. > > > > > > The document states that SSP and ITSP are synonymous, > > > > > although I might > > > > > > argue that an ITSP is a subset of an SSP, purely because > > > > > the 'T' part > > > > > > suggests a specific service attributable to the UA's > > > within that > > > > > > network and hence also implies something about the way that > > > > > service is > > > > > > delivered (or at least ought to). SSP is more general and > > > > > hence could > > > > > > include applications that do not have the same requirements > > > > > on QoS and > > > > > > hence do not require the same DSCP marking, but if you are > > > > > all happy > > > > > > for these to be equivalent, I am not going to fuss about > > > > > the semantics > > > > > > of what is implied by 'telephony'. > > > > > > = > > > > > > Now I get slightly confused. A Peer Network sounds > > > like it is a > > > > > > special case of an SSP - in effect a peered SSP. Is that > > > > > correct? If > > > > > > so I'd suggest for readability of the document, SSP is > > > > > defined before > > > > > > Peer Network, and Peer Network is defined as I = > describe above. > > > > > > = > > > > > > Similarly, an SSP seems to be a specialised SP, in that not > > > > > only does > > > > > > it provide L3 transport of SIP signalling and media > > > > > packets, but also > > > > > > includes SIP end points. Similar to my last point, it > > > > > would help the > > > > > > document to define SP before SSP, so that the definition of > > > > > SSP can be > > > > > > 'An SSP is an SP that also includes UASs and UACs...' and > > > > > then a Peer > > > > > > Network can be defined as '...an SSP that has connections > > > > > to peer SSPs > > > > > > via...'. A nice hierarchical definition (start with the > > > > > broadest term > > > > > > and get narrower' generally saves a lot of > > > redefinition, which in > > > > > > itself can create ambiguity. > > > > > > = > > > > > > And that leads me quite neatly on to a question - = > how are you = > > > > > > classifying the transit or carrier network that would sit > > > > > between the > > > > > > SSPs to provide interconnectivity? It is clearly an SP > > > > > since it will > > > > > > provide L3 transport of SIP and media, but if my comments > > > > above are > > > > > > right, SP is intended to be an umberella term > > covering all the > > > > > > sub-variants of SP. It will also need to have some > > > > characteristics > > > > > > dependent upon whether it is expected to provide any > > additional > > > > > > functionality - it clearly needs to be DiffServ aware, > > > > but it could > > > > > > also be required to provide a bunch of functions around > > > > transcoding > > > > > > and reframing in the media plane, and maybe SIP variant > > > > > interworking, > > > > > > which could imply B2BUAs. It seems though that this > > > > network, be it > > > > > > the internet or something provided by a carrier > > > operator is only > > > > > > alluded to in the definition of Federations. Is there not > > > > > a need to > > > > > > identify it explicitly, even if it is far simpler = > than I have = > > > > > > conceived it to be? I note that in the Architecture > > > document, in > > > > > > Figure 3 a 'Transit IP Provider' is identified > > > (although the text > > > > > > never refers to Figure 3 nor Transit IP Provider), but then > > > > > in Figure > > > > > > 1 of the same document a whole bunch of terms not > > > defined in this > > > > > > document are used... > > > > > > = > > > > > > I'd appreciate at least comments on whether what I have > > > > laid out as > > > > > > the herarchy of these terms is right or not, but I'm not > > > > > going to get > > > > > > fussy about whether the proposed shuffle of the ordering > > > > > takes place. > > > > > > = > > > > > > Cheers > > > > > > = > > > > > > Dan > > > > > > = > > > > > > = > > > > > > > > > 14) "3.8. Service Provider > > > > > > > > > = > > > > > > > > > A Service Provider (or SP) is defined to = > be an entity > > > > > > > > that provides > > > > > > > > > layer 3 (IP) transport of SIP signaling and media > > > > > > packets. An > > > > > > > > > example of this may be an Internet Service > > > > Provider (ISP)." > > > > > > > > > This at first glance is reasonable, but then the next > > > > > > > > section goes on to > > > > > > > > > define a SIP Service Provider as something = > that is not a > > > > > > > > special case of > > > > > > > > > a Service Provider, since it operates at = > layer 5, not at > > > > > > > layer 3. We > > > > > > > > > should perhaps find a different term for "Service > > > Provider" > > > > > > > > when we mean > > > > > > > > > layer 3, e.g., "Network Service Provider". > > > > > > > > That's fine with me....although terms like this are > > > > > ambiguous. I > > > > > > > > think we had specified Internet Service Provider before, > > > > > > but there > > > > > > > > were arguments against being that "specific". So, we > > > > > > > generalized the > > > > > > > > term and just provided it as an example. > > > > > > > [JRE] I think we have to do something. The term SP is > > > > OK if it is > > > > > > > intended to embrace all types of SP that we are > > dealing with, > > > > > > > including SSP. But if we need a term for an SP that > > > > > operates only at > > > > > > > layer 3, we need a different term. > > > > > > > = > > > > > > > > > = > > > > > > > > > 15) "A SIP Service Provider (or SSP) is an entity > > > > > that provides > > > > > > > > > application level transport of SIP signaling to its > > > > > > > customers." = > > > > > > > > > Elsewhere the document talks about level 5 = > peering, but > > > > > > > now it talks > > > > > > > > > about application level. Also, isn't it more than just > > > > > > > transport. I > > > > > > > > > don't have a particular proposal, but I don't > > really like > > > > > > > > the present > > > > > > > > > definition. > > > > > > > > = > > > > > > > > Hmmm...I'll see if I can think of something to make > > > > > this clearer. > > > > > > > > Anyone else have an opinion (heh...that's a stupid > > > > > > > question. Everyone > > > > > > > > has an opinion, right?!)? :-) > > > > > > > = > > > > > > > > > = > > > > > > > > > 16) "3.10. Internet Telephony Service Provider > > > > > > > > > = > > > > > > > > > An Internet Telephony Service Provider, or = > ITSP, is a > > > > > > > > synonym for > > > > > > > > > SSP. While the terms ITSP and SSP are > > frequently used > > > > > > > > > interchangeably, the SPEERMINT working = > group uses the > > > > > > > term SSP." > > > > > > > > > So why define the term if we are not going to = > use it? We > > > > > > > > could mention > > > > > > > > > it in a note below the definition of SSP, if > > > really needed. > > > > > > > > > = > > > > > > > > ....don't care either way...we can do that to. Does it > > > > > > > significantly > > > > > > > > make things simpler by doing as you suggest? > > > > > > > [JRE] The point is, by having an explicit definition of > > > > ITSP, it > > > > > > > tends to encourage other SPEERMINT documents to use it, > > > > > even though > > > > > > > there is an explicit statement that SPEERMINT will use > > > > > only SSP. I > > > > > > > thought just making it a note below the definition of SSP > > > > > would help > > > > > > > to de-emphasise ITSP further. > > > > > > = > > > > > > Forthcoming GSMA Events: > > > > > > = > > > > > > GSMA Mobile Asia Congress > > > > > > Macau > > > > > > 12 - 15 November 2007 > > > > > > www.mobileasiacongress.com > > > > > > = > > > > > > GSMA Mobile World Congress > > > > > > Barcelona > > > > > > 11 - 14 February 2008 > > > > > > www.mobileworldcongress.com > > > > > > = > > > > > > = > > > > > > This email and its attachments are intended for the above > > > > > named only > > > > > > and may be confidential. If they have come to you in > > > > error you must > > > > > > take no action based on them, nor must you copy or > > show them to > > > > > > anyone; please reply to this email or call +44 207 > > 759 2300 and > > > > > > highlight the error > > > > > > = > > > > > > = > > > > > > = > > > > > = > > > > > = > > > > = > > > > Forthcoming GSMA Events: > > > > = > > > > GSMA Mobile Asia Congress > > > > Macau > > > > 12 - 15 November 2007 > > > > www.mobileasiacongress.com > > > > = > > > > GSMA Mobile World Congress > > > > Barcelona > > > > 11 - 14 February 2008 > > > > www.mobileworldcongress.com > > > > = > > > > = > > > > This email and its attachments are intended for the above > > > named only > > > > and may be confidential. If they have come to you in > > error you must > > > > take no action based on them, nor must you copy or show them to = > > > > anyone; please reply to this email or call +44 207 759 2300 and = > > > > highlight the error > > > > = > > > > = > > > > = > > > = > > > = > > = > > Forthcoming GSMA Events: > > = > > GSMA Mobile Asia Congress > > Macau > > 12 - 15 November 2007 > > www.mobileasiacongress.com > > = > > GSMA Mobile World Congress > > Barcelona > > 11 - 14 February 2008 > > www.mobileworldcongress.com > > = > > = > > This email and its attachments are intended for the above = > named only = > > and may be confidential. If they have come to you in error you must = > > take no action based on them, nor must you copy or show them to = > > anyone; please reply to this email or call +44 207 759 2300 and = > > highlight the error > > = > > = > > = > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > = > = > = Forthcoming GSMA Events: = GSMA Mobile Asia Congress Macau 12 - 15 November 2007 www.mobileasiacongress.com = GSMA Mobile World Congress Barcelona 11 - 14 February 2008 www.mobileworldcongress.com This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 759 2300 and highlight the error _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 02 10:58:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcjBu-0005Sf-RW; Tue, 02 Oct 2007 10:57:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcjBt-0005Gz-Bj for speermint@ietf.org; Tue, 02 Oct 2007 10:57:41 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcjBm-00043f-Sf for speermint@ietf.org; Tue, 02 Oct 2007 10:57:41 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JPA003AHHIDE7@siemenscomms.co.uk> for speermint@ietf.org; Tue, 02 Oct 2007 15:56:38 +0100 (BST) Date: Tue, 02 Oct 2007 15:56:57 +0100 From: "Elwell, John" Subject: RE: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 In-reply-to: To: "Uzelac, Adam" , Dan Warren , Daryl Malas Message-id: <0D5F89FAC29E2C41B98A6A762007F5D03256AE@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgAaIO7/hEeVa9kTQKfLRakKTmBwAAcct/QAPw2WGAAAnUVkAACxNogAAOQLeAAAEPmEAADblfAAAGpyZA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <6918D1F7F8770C4FB182838A7BDFD6C8016FF350@GSMDUBEX02.GSM.TLD> X-Spam-Score: 1.2 (+) X-Scan-Signature: c8611c7316981838cbe4195d07ac7fdb Cc: "Malas, Daryl" , "Peterson, , dmm"@1-4-5.net, speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Adam and others, As an aside, please can we stop talking about UACs and UASs as if they are really different entities? We have UAs, which when they send a request act as UACs and when they receive a request act as UASs. A stand-along UAC or UAS is highly unlikely to exist. For example, a stand-alone UAS would be able to receive a call (receive an INVITE request) but would not be able to initiate clearing a call (sending a BYE request). Please let's just talk about UAs. John > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: 02 October 2007 15:25 > To: Dan Warren; Elwell, John; Daryl Malas > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > speermint@ietf.org; Livingood, Jason > Subject: RE: [Speermint] > [wg-business]WGLCfordraft-ietf-speermint-terminology-12 > > > I'll shut up now. Thanks for the help. > > > > Dan > > Oh no - you don't get to run away so quickly! ;) I think > there's some > "wrongness" going on here. The transit SSP scenario can and does (in > the real world) contain both UACs and UASs. The bare > minimum would be > UASs I believe. The transit most certainly is a SSP, as is the > originating and terminating domain. There may be more than > one transit. > Any and all of the SSPs can have UACs and/or UASs. It's more > about the > function that the domain performs or pertains to. > > If a residential UA is registered to a UAS or not really shouldn't > matter. A residential UA alone with some static SIP-routing would > define the originating domain. If there's reachability with other UAs > without crossing into another SSP, like sessions in the same building, > neighborhood, business group, etc - these are all within the > same domain > and no peering occurs. Should the look-up function result in the > terminating UA being in the terminating domain (think called party) - > then it's a peer relationship between 2 parties: > > SSP(O) <---> SSP(T) > > If there's no direct path between the originating domain [SSP(O)] and > the terminating domain [SSP(T)], then employment of an intermediary or > transit domain [SSP(t)] may, and oftentimes does, get used: > > SSP(O) <---> SSP(t) <---> SSP(T) > > I don't know if that clears things up or not, but it's how I organize > the world. ;) > > -AU > > > > -----Original Message----- > > From: Dan Warren [mailto:DWarren@gsm.org] > > Sent: Tuesday, October 02, 2007 8:31 AM > > To: Elwell, John; Daryl Malas > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > speermint@ietf.org; Livingood, Jason > > Subject: RE: [Speermint] > > [wg-business]WGLCfordraft-ietf-speermint-terminology-12 > > > > John > > > > You just successfully (maybe inadvertently?) answered my > > other question from my first mail - how to classify the > > transit network, particularly the transit where there is SIP > > awareness. If that transit network is also an SSP then that > > makes life a little easier to understand. > > > > The only question that then remains is whether SSPs for > > tranist with no UAs should be categorised separately from > > SSPs that do have UAs but don't peer. But then an SSP with > > UAs that doesn't peer is not in scope of the work... > > > > I'll shut up now. Thanks for the help. > > > > Dan > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: 02 October 2007 13:24 > > > To: Dan Warren; Daryl Malas > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > speermint@ietf.org; > > > Livingood, Jason > > > Subject: RE: [Speermint] [wg-business] > > > WGLCfordraft-ietf-speermint-terminology-12 > > > > > > Dan, > > > > > > It is probably a moot point whether a residential UA is > > within the SSP > > > or not. Perhaps if the UA is in possession of credentials > for that > > > SSP, allowing it to register and submit other requests such > > as INVITE > > > and MESSAGE, then you might regard it as logically part of > > that SSP. > > > But I guess the main point I was trying to make is > whether it is a > > > necessary condition that an SSP include UAs. Consider a > transit SSP > > > used in indirect peering. It can be a transit SSP without > > possessing a > > > single UA (gateway, phone, media server or whatever). > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: Dan Warren [mailto:DWarren@gsm.org] > > > > Sent: 02 October 2007 11:58 > > > > To: Elwell, John; Daryl Malas > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > speermint@ietf.org; > > > > Livingood, Jason > > > > Subject: RE: [Speermint] [wg-business] > > > > WGLCfordraft-ietf-speermint-terminology-12 > > > > > > > > John > > > > > > > > You said... > > > > > > > > 'Is it a necessary condition that an SSP include UAs > (other than > > > > B2BUAs, perhaps)? I guess it depends what we perceive as > > > the scope of > > > > an SSP. > > > > UAs such as PSTN gateways, media servers, etc. might be > > considered > > > > part of the SSP. But a UA in a user's home that uses the > > > services of > > > > an SSP? > > > > That to me is not really part of the SSP.' > > > > > > > > I agree that under the current terminology and associated > > > definitions > > > > it isn't, but lets consider what the practicalities of > > > implementation > > > > are. > > > > Suppose I have a UA on my laptop. Unless the ISP I am using is > > > > handling the SIP signalling from that UA in a special way > > compared > > > > with other non-SIP traffic, then the ISP is operating > as a SP (as > > > > defined in 3.8). > > > > The UA has to be associated with some sort of network where my > > > > sessions are handled, applications are applied and methods are > > > > forwarded. This has to be in an SSP/ITSP, and if that SSP > > > is attached > > > > to other SSPs then it is also a Peer Network. I guess the > > > point is, > > > > do we conceive of UA's that are in homes that do not need > > > to have an > > > > association with an SSP, even if it is only short term? > > > > > > > > I have to admit that on reading your mail I figured I > had made a > > > > mistake, but then on analysing the text and thinking about > > > it, I think > > > > it is an interesting question. Maybe the way to consider it is > > > > conversely - what do you classify a 'set of SIP user > agent servers > > > > (UASs) [2] and SIP user agent clients (UACs) [2] > > > (customers) that are > > > > controlled by a single administrative domain' but do not > > > peer? So a > > > > completely self contained and non-peering network... If an > > > SSP does > > > > not imply UACs and UASs, what is the level of SIP awareness > > > within the > > > > SSP space? > > > > > > > > I am not trying to be intentionally provocative, I am just > > > aware that > > > > there seems to be some gaps in the definitions like could > > > be usefully > > > > closed before they cause problems when we need a term for > > a network > > > > classification that is not defined... I again make note > > > though that I > > > > am coming to this with fresh eyes and it might be that > I am just > > > > misunderstanding what is written. > > > > > > > > Cheers > > > > > > > > Dan > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > > Sent: 02 October 2007 10:24 > > > > > To: Dan Warren; Daryl Malas > > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > > speermint@ietf.org; > > > > > Livingood, Jason > > > > > Subject: RE: [Speermint] [wg-business] > > > > > WGLCfordraft-ietf-speermint-terminology-12 > > > > > > > > > > Dan, > > > > > > > > > > I agree with most of what you say. One point, however, is your > > > > > proposal: > > > > > 'An SSP is an SP that also includes UASs and UACs...' > > > (which I guess > > > > > comes from text in the existing definition of Peer > > > Network, which I > > > > > failed to comment on). > > > > > > > > > > Is it a necessary condition that an SSP include UAs > (other than > > > > > B2BUAs, perhaps)? I guess it depends what we perceive as > > > the scope > > > > > of an SSP. > > > > > UAs such as PSTN gateways, media servers, etc. might be > > > considered > > > > > part of the SSP. But a UA in a user's home that uses the > > > services of > > > > > an SSP? > > > > > That to me is not really part of the SSP. > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Dan Warren [mailto:DWarren@gsm.org] > > > > > > Sent: 02 October 2007 09:45 > > > > > > To: Elwell, John; Daryl Malas > > > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > > > speermint@ietf.org; > > > > > > Livingood, Jason > > > > > > Subject: RE: [Speermint] [wg-business] > > > > > > WGLCfordraft-ietf-speermint-terminology-12 > > > > > > > > > > > > All > > > > > > > > > > > > Some of the points made by John (in his comments 14, 15 and > > > > > > 16) I agree > > > > > > with but I think it goes further than that. So rather than > > > > > making a > > > > > > proper comment, can I check my understanding of the terms > > > > > as someone > > > > > > that has picked the spec up recently and tried to > > understand it? > > > > > > > > > > > > There are four terms relating to network types - peer > > > > > network, service > > > > > > provider, SIP Service Provider and Internet > Telephony Service > > > > > > Provider. > > > > > > The document states that SSP and ITSP are synonymous, > > > > > although I might > > > > > > argue that an ITSP is a subset of an SSP, purely because > > > > > the 'T' part > > > > > > suggests a specific service attributable to the UA's > > > within that > > > > > > network and hence also implies something about the way that > > > > > service is > > > > > > delivered (or at least ought to). SSP is more general and > > > > > hence could > > > > > > include applications that do not have the same requirements > > > > > on QoS and > > > > > > hence do not require the same DSCP marking, but if you are > > > > > all happy > > > > > > for these to be equivalent, I am not going to fuss about > > > > > the semantics > > > > > > of what is implied by 'telephony'. > > > > > > > > > > > > Now I get slightly confused. A Peer Network sounds > > > like it is a > > > > > > special case of an SSP - in effect a peered SSP. Is that > > > > > correct? If > > > > > > so I'd suggest for readability of the document, SSP is > > > > > defined before > > > > > > Peer Network, and Peer Network is defined as I > describe above. > > > > > > > > > > > > Similarly, an SSP seems to be a specialised SP, in that not > > > > > only does > > > > > > it provide L3 transport of SIP signalling and media > > > > > packets, but also > > > > > > includes SIP end points. Similar to my last point, it > > > > > would help the > > > > > > document to define SP before SSP, so that the definition of > > > > > SSP can be > > > > > > 'An SSP is an SP that also includes UASs and UACs...' and > > > > > then a Peer > > > > > > Network can be defined as '...an SSP that has connections > > > > > to peer SSPs > > > > > > via...'. A nice hierarchical definition (start with the > > > > > broadest term > > > > > > and get narrower' generally saves a lot of > > > redefinition, which in > > > > > > itself can create ambiguity. > > > > > > > > > > > > And that leads me quite neatly on to a question - > how are you > > > > > > classifying the transit or carrier network that would sit > > > > > between the > > > > > > SSPs to provide interconnectivity? It is clearly an SP > > > > > since it will > > > > > > provide L3 transport of SIP and media, but if my comments > > > > above are > > > > > > right, SP is intended to be an umberella term > > covering all the > > > > > > sub-variants of SP. It will also need to have some > > > > characteristics > > > > > > dependent upon whether it is expected to provide any > > additional > > > > > > functionality - it clearly needs to be DiffServ aware, > > > > but it could > > > > > > also be required to provide a bunch of functions around > > > > transcoding > > > > > > and reframing in the media plane, and maybe SIP variant > > > > > interworking, > > > > > > which could imply B2BUAs. It seems though that this > > > > network, be it > > > > > > the internet or something provided by a carrier > > > operator is only > > > > > > alluded to in the definition of Federations. Is there not > > > > > a need to > > > > > > identify it explicitly, even if it is far simpler > than I have > > > > > > conceived it to be? I note that in the Architecture > > > document, in > > > > > > Figure 3 a 'Transit IP Provider' is identified > > > (although the text > > > > > > never refers to Figure 3 nor Transit IP Provider), but then > > > > > in Figure > > > > > > 1 of the same document a whole bunch of terms not > > > defined in this > > > > > > document are used... > > > > > > > > > > > > I'd appreciate at least comments on whether what I have > > > > laid out as > > > > > > the herarchy of these terms is right or not, but I'm not > > > > > going to get > > > > > > fussy about whether the proposed shuffle of the ordering > > > > > takes place. > > > > > > > > > > > > Cheers > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > 14) "3.8. Service Provider > > > > > > > > > > > > > > > > > > A Service Provider (or SP) is defined to > be an entity > > > > > > > > that provides > > > > > > > > > layer 3 (IP) transport of SIP signaling and media > > > > > > packets. An > > > > > > > > > example of this may be an Internet Service > > > > Provider (ISP)." > > > > > > > > > This at first glance is reasonable, but then the next > > > > > > > > section goes on to > > > > > > > > > define a SIP Service Provider as something > that is not a > > > > > > > > special case of > > > > > > > > > a Service Provider, since it operates at > layer 5, not at > > > > > > > layer 3. We > > > > > > > > > should perhaps find a different term for "Service > > > Provider" > > > > > > > > when we mean > > > > > > > > > layer 3, e.g., "Network Service Provider". > > > > > > > > That's fine with me....although terms like this are > > > > > ambiguous. I > > > > > > > > think we had specified Internet Service Provider before, > > > > > > but there > > > > > > > > were arguments against being that "specific". So, we > > > > > > > generalized the > > > > > > > > term and just provided it as an example. > > > > > > > [JRE] I think we have to do something. The term SP is > > > > OK if it is > > > > > > > intended to embrace all types of SP that we are > > dealing with, > > > > > > > including SSP. But if we need a term for an SP that > > > > > operates only at > > > > > > > layer 3, we need a different term. > > > > > > > > > > > > > > > > > > > > > > > > > 15) "A SIP Service Provider (or SSP) is an entity > > > > > that provides > > > > > > > > > application level transport of SIP signaling to its > > > > > > > customers." > > > > > > > > > Elsewhere the document talks about level 5 > peering, but > > > > > > > now it talks > > > > > > > > > about application level. Also, isn't it more than just > > > > > > > transport. I > > > > > > > > > don't have a particular proposal, but I don't > > really like > > > > > > > > the present > > > > > > > > > definition. > > > > > > > > > > > > > > > > Hmmm...I'll see if I can think of something to make > > > > > this clearer. > > > > > > > > Anyone else have an opinion (heh...that's a stupid > > > > > > > question. Everyone > > > > > > > > has an opinion, right?!)? :-) > > > > > > > > > > > > > > > > > > > > > > > > > 16) "3.10. Internet Telephony Service Provider > > > > > > > > > > > > > > > > > > An Internet Telephony Service Provider, or > ITSP, is a > > > > > > > > synonym for > > > > > > > > > SSP. While the terms ITSP and SSP are > > frequently used > > > > > > > > > interchangeably, the SPEERMINT working > group uses the > > > > > > > term SSP." > > > > > > > > > So why define the term if we are not going to > use it? We > > > > > > > > could mention > > > > > > > > > it in a note below the definition of SSP, if > > > really needed. > > > > > > > > > > > > > > > > > ....don't care either way...we can do that to. Does it > > > > > > > significantly > > > > > > > > make things simpler by doing as you suggest? > > > > > > > [JRE] The point is, by having an explicit definition of > > > > ITSP, it > > > > > > > tends to encourage other SPEERMINT documents to use it, > > > > > even though > > > > > > > there is an explicit statement that SPEERMINT will use > > > > > only SSP. I > > > > > > > thought just making it a note below the definition of SSP > > > > > would help > > > > > > > to de-emphasise ITSP further. > > > > > > > > > > > > Forthcoming GSMA Events: > > > > > > > > > > > > GSMA Mobile Asia Congress > > > > > > Macau > > > > > > 12 - 15 November 2007 > > > > > > www.mobileasiacongress.com > > > > > > > > > > > > GSMA Mobile World Congress > > > > > > Barcelona > > > > > > 11 - 14 February 2008 > > > > > > www.mobileworldcongress.com > > > > > > > > > > > > > > > > > > This email and its attachments are intended for the above > > > > > named only > > > > > > and may be confidential. If they have come to you in > > > > error you must > > > > > > take no action based on them, nor must you copy or > > show them to > > > > > > anyone; please reply to this email or call +44 207 > > 759 2300 and > > > > > > highlight the error > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Forthcoming GSMA Events: > > > > > > > > GSMA Mobile Asia Congress > > > > Macau > > > > 12 - 15 November 2007 > > > > www.mobileasiacongress.com > > > > > > > > GSMA Mobile World Congress > > > > Barcelona > > > > 11 - 14 February 2008 > > > > www.mobileworldcongress.com > > > > > > > > > > > > This email and its attachments are intended for the above > > > named only > > > > and may be confidential. If they have come to you in > > error you must > > > > take no action based on them, nor must you copy or show them to > > > > anyone; please reply to this email or call +44 207 759 2300 and > > > > highlight the error > > > > > > > > > > > > > > > > > > > > > > Forthcoming GSMA Events: > > > > GSMA Mobile Asia Congress > > Macau > > 12 - 15 November 2007 > > www.mobileasiacongress.com > > > > GSMA Mobile World Congress > > Barcelona > > 11 - 14 February 2008 > > www.mobileworldcongress.com > > > > > > This email and its attachments are intended for the above > > named only and may be confidential. If they have come to you > > in error you must take no action based on them, nor must you > > copy or show them to anyone; please reply to this email or > > call +44 207 759 2300 and highlight the error > > > > > > > > _______________________________________________ > > Speermint mailing 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 Oct 02 11:29:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icjfd-0004vZ-DR; Tue, 02 Oct 2007 11:28:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icjfc-0004nv-6k for speermint@ietf.org; Tue, 02 Oct 2007 11:28:24 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcjfV-00074a-3S for speermint@ietf.org; Tue, 02 Oct 2007 11:28:19 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 94A0F91E8; Tue, 2 Oct 2007 11:28:14 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Oct 2007 11:28:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Date: Tue, 2 Oct 2007 11:28:12 -0400 Message-ID: In-Reply-To: <6918D1F7F8770C4FB182838A7BDFD6C8016FF424@GSMDUBEX02.GSM.TLD> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgAaIO7/hEeVa9kTQKfLRakKTmBwAAcct/QAPw2WGAAAnUVkAACxNogAAOQLeAAAEPmEAADblfAAAEF83AAALVzEA== References: <6918D1F7F8770C4FB182838A7BDFD6C8016FF424@GSMDUBEX02.GSM.TLD> From: "Uzelac, Adam" To: "Dan Warren" , "Elwell, John" , "Daryl Malas" X-OriginalArrivalTime: 02 Oct 2007 15:28:14.0573 (UTC) FILETIME=[D96CE9D0:01C80508] X-Spam-Score: 1.2 (+) X-Scan-Signature: 778b456acd32f555185589e04d062871 Cc: "Malas, Daryl" , speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Note: I might be contradicting myself here a bit, but be that as it may....I don't think that we should get into the game of how a SP becomes a SSP. It's a slippery slope there. (Think DPI as an example) The basic premise or proposition which underlies being an SSP is that it is "SIP-aware", not how the SP becomes "SIP-aware". The nature of the SSP(t) is to enable connectivity between SSP(O) and SSP(T). It's unrealistic to think we can have a complete mesh between all SSP(O)s and all SSP(T)s. Let me go on record as a fan of http://tools.ietf.org/id/draft-lendl-domain-policy-ddds-02.txt to help with this. Please note also that I think that any middlemen - read as SSP(t)s - that add no value will be disintermediated, sooner or later. (attribution to Mike Hammer from a thread long ago) Look back to threads from long ago about 'Basic Peering Requirements'...It's simply impractical, at this time, to have local route awareness of all SSP(T)s in the world. Therefore the value of the SSP(t) here can be to provide route aggregation. SSP(O)s will most likely have multiple upstream SSP(t)s. Until reachability between all 'O and T' SSPs is realized, the SSP(t) or indirect SIP PATH (do not read as media path) will be a reality. -AU > -----Original Message----- > From: Dan Warren [mailto:DWarren@gsm.org]=20 > Sent: Tuesday, October 02, 2007 10:43 AM > To: Uzelac, Adam; Elwell, John; Daryl Malas > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net;=20 > speermint@ietf.org; Livingood, Jason > Subject: RE: [Speermint]=20 > [wg-business]WGLCfordraft-ietf-speermint-terminology-12 >=20 > =20 > >=20 > > > I'll shut up now. Thanks for the help. > > >=20 > > > Dan > >=20 > > Oh no - you don't get to run away so quickly! ;) >=20 > Well in that case... >=20 > > I think > > there's some "wrongness" going on here. The transit SSP=20 > scenario can=20 > > and does (in > > the real world) contain both UACs and UASs. The bare=20 > > minimum would be > > UASs I believe. The transit most certainly is a SSP, as is the=20 > > originating and terminating domain. There may be more than one=20 > > transit. > > Any and all of the SSPs can have UACs and/or UASs. It's more about=20 > > the function that the domain performs or pertains to. > >=20 > > If a residential UA is registered to a UAS or not really shouldn't=20 > > matter. A residential UA alone with some static SIP-routing would=20 > > define the originating domain. If there's reachability=20 > with other UAs=20 > > without crossing into another SSP, like sessions in the=20 > same building,=20 > > neighborhood, business group, etc - these are all within the same=20 > > domain and no peering occurs. Should the look-up function=20 > result in=20 > > the terminating UA being in the terminating domain (think called=20 > > party) - then it's a peer relationship between 2 parties: > >=20 > > SSP(O) <---> SSP(T) > >=20 > > If there's no direct path between the originating domain=20 > [SSP(O)] and=20 > > the terminating domain [SSP(T)], then employment of an=20 > intermediary or=20 > > transit domain [SSP(t)] may, and oftentimes does, get used: > >=20 > > SSP(O) <---> SSP(t) <---> SSP(T) > >=20 > > I don't know if that clears things up or not, but it's how=20 > I organize=20 > > the world. ;) > >=20 > > -AU >=20 > I think we are all arguing the same way now. There is a=20 > question of semantics and a question of reality. So=20 > semantics (and the definition in the terminology draft) says=20 > that the SSP does not have to include UAS's and/or UAC's but=20 > the reality is that the concept of a SSP with UAS's or UAC's=20 > is pretty hard to comprehend. >=20 > In your example above SSP(t) is ONLY an SSP, whilst SSP(O)=20 > and SSP(T) are both Peer Networks (which in my mind at least=20 > is a special case of > SSP) since they are *ahem* well, peering. UA(O) and UA(T)=20 > may attach to > SSP(O) and SSP(T) respectively across SP's (single S=20 > intentional) such as a DSL provider that is providing pure=20 > connectivity at L3. >=20 > So what is the nature of SSP(t)? Does it have to have UAS=20 > and UACs to be L5 aware? Or could it just be contain SIP=20 > Proxies, making it an SSP with UAS and UACs as John proposed?=20 > If it doesn't have any SIP awareness, then it is clearly=20 > just an SP since again, it is just L3 connectivity based. >=20 >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Dan Warren [mailto:DWarren@gsm.org] > > > Sent: Tuesday, October 02, 2007 8:31 AM > > > To: Elwell, John; Daryl Malas > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net;=20 > speermint@ietf.org;=20 > > > Livingood, Jason > > > Subject: RE: [Speermint] > > > [wg-business]WGLCfordraft-ietf-speermint-terminology-12 > > >=20 > > > John > > >=20 > > > You just successfully (maybe inadvertently?) answered my other=20 > > > question from my first mail - how to classify the transit=20 > network,=20 > > > particularly the transit where there is SIP awareness. If that=20 > > > transit network is also an SSP then that makes life a > > little easier to > > > understand. > > >=20 > > > The only question that then remains is whether SSPs for > > tranist with > > > no UAs should be categorised separately from SSPs that do > > have UAs but > > > don't peer. But then an SSP with UAs that doesn't peer is not in=20 > > > scope of the work... > > >=20 > > > I'll shut up now. Thanks for the help. > > >=20 > > > Dan > > >=20 > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > Sent: 02 October 2007 13:24 > > > > To: Dan Warren; Daryl Malas > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > speermint@ietf.org; > > > > Livingood, Jason > > > > Subject: RE: [Speermint] [wg-business] > > > > WGLCfordraft-ietf-speermint-terminology-12 > > > >=20 > > > > Dan, > > > >=20 > > > > It is probably a moot point whether a residential UA is > > > within the SSP > > > > or not. Perhaps if the UA is in possession of credentials > > for that > > > > SSP, allowing it to register and submit other requests such > > > as INVITE > > > > and MESSAGE, then you might regard it as logically part of > > > that SSP.=20 > > > > But I guess the main point I was trying to make is > > whether it is a > > > > necessary condition that an SSP include UAs. Consider a > > transit SSP > > > > used in indirect peering. It can be a transit SSP without > > > possessing a > > > > single UA (gateway, phone, media server or whatever). > > > >=20 > > > > John > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Dan Warren [mailto:DWarren@gsm.org] > > > > > Sent: 02 October 2007 11:58 > > > > > To: Elwell, John; Daryl Malas > > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > > speermint@ietf.org; > > > > > Livingood, Jason > > > > > Subject: RE: [Speermint] [wg-business] > > > > > WGLCfordraft-ietf-speermint-terminology-12 > > > > >=20 > > > > > John > > > > >=20 > > > > > You said... > > > > >=20 > > > > > 'Is it a necessary condition that an SSP include UAs > > (other than > > > > > B2BUAs, perhaps)? I guess it depends what we perceive as > > > > the scope of > > > > > an SSP. > > > > > UAs such as PSTN gateways, media servers, etc. might be > > > considered > > > > > part of the SSP. But a UA in a user's home that uses the > > > > services of > > > > > an SSP? > > > > > That to me is not really part of the SSP.' > > > > >=20 > > > > > I agree that under the current terminology and associated > > > > definitions > > > > > it isn't, but lets consider what the practicalities of > > > > implementation > > > > > are. > > > > > Suppose I have a UA on my laptop. Unless the ISP I=20 > am using is=20 > > > > > handling the SIP signalling from that UA in a special way > > > compared > > > > > with other non-SIP traffic, then the ISP is operating > > as a SP (as > > > > > defined in 3.8). > > > > > The UA has to be associated with some sort of network=20 > where my=20 > > > > > sessions are handled, applications are applied and=20 > methods are=20 > > > > > forwarded. This has to be in an SSP/ITSP, and if that SSP > > > > is attached > > > > > to other SSPs then it is also a Peer Network. I guess the > > > > point is, > > > > > do we conceive of UA's that are in homes that do not need > > > > to have an > > > > > association with an SSP, even if it is only short term? > > > > >=20 > > > > > I have to admit that on reading your mail I figured I > > had made a > > > > > mistake, but then on analysing the text and thinking about > > > > it, I think > > > > > it is an interesting question. Maybe the way to=20 > consider it is=20 > > > > > conversely - what do you classify a 'set of SIP user > > agent servers > > > > > (UASs) [2] and SIP user agent clients (UACs) [2] > > > > (customers) that are > > > > > controlled by a single administrative domain' but do not > > > > peer? So a > > > > > completely self contained and non-peering network... If an > > > > SSP does > > > > > not imply UACs and UASs, what is the level of SIP awareness > > > > within the > > > > > SSP space? > > > > >=20 > > > > > I am not trying to be intentionally provocative, I am just > > > > aware that > > > > > there seems to be some gaps in the definitions like could > > > > be usefully > > > > > closed before they cause problems when we need a term for > > > a network > > > > > classification that is not defined... I again make note > > > > though that I > > > > > am coming to this with fresh eyes and it might be that > > I am just > > > > > misunderstanding what is written. > > > > >=20 > > > > > Cheers > > > > >=20 > > > > > Dan > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > > > Sent: 02 October 2007 10:24 > > > > > > To: Dan Warren; Daryl Malas > > > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > > > speermint@ietf.org; > > > > > > Livingood, Jason > > > > > > Subject: RE: [Speermint] [wg-business] > > > > > > WGLCfordraft-ietf-speermint-terminology-12 > > > > > >=20 > > > > > > Dan, > > > > > >=20 > > > > > > I agree with most of what you say. One point,=20 > however, is your > > > > > > proposal: > > > > > > 'An SSP is an SP that also includes UASs and UACs...'=20 > > > > (which I guess > > > > > > comes from text in the existing definition of Peer > > > > Network, which I > > > > > > failed to comment on). > > > > > >=20 > > > > > > Is it a necessary condition that an SSP include UAs > > (other than > > > > > > B2BUAs, perhaps)? I guess it depends what we perceive as > > > > the scope > > > > > > of an SSP. > > > > > > UAs such as PSTN gateways, media servers, etc. might be > > > > considered > > > > > > part of the SSP. But a UA in a user's home that uses the > > > > services of > > > > > > an SSP? > > > > > > That to me is not really part of the SSP. > > > > > >=20 > > > > > > John > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Dan Warren [mailto:DWarren@gsm.org] > > > > > > > Sent: 02 October 2007 09:45 > > > > > > > To: Elwell, John; Daryl Malas > > > > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > > > > speermint@ietf.org; > > > > > > > Livingood, Jason > > > > > > > Subject: RE: [Speermint] [wg-business] > > > > > > > WGLCfordraft-ietf-speermint-terminology-12 > > > > > > >=20 > > > > > > > All > > > > > > >=20 > > > > > > > Some of the points made by John (in his comments=20 > 14, 15 and > > > > > > > 16) I agree > > > > > > > with but I think it goes further than that. So=20 > rather than > > > > > > making a > > > > > > > proper comment, can I check my understanding of the terms > > > > > > as someone > > > > > > > that has picked the spec up recently and tried to > > > understand it? > > > > > > >=20 > > > > > > > There are four terms relating to network types - peer > > > > > > network, service > > > > > > > provider, SIP Service Provider and Internet > > Telephony Service > > > > > > > Provider. > > > > > > > The document states that SSP and ITSP are synonymous, > > > > > > although I might > > > > > > > argue that an ITSP is a subset of an SSP, purely because > > > > > > the 'T' part > > > > > > > suggests a specific service attributable to the UA's > > > > within that > > > > > > > network and hence also implies something about=20 > the way that > > > > > > service is > > > > > > > delivered (or at least ought to). SSP is more general and > > > > > > hence could > > > > > > > include applications that do not have the same=20 > requirements > > > > > > on QoS and > > > > > > > hence do not require the same DSCP marking, but if you are > > > > > > all happy > > > > > > > for these to be equivalent, I am not going to fuss about > > > > > > the semantics > > > > > > > of what is implied by 'telephony'. > > > > > > >=20 > > > > > > > Now I get slightly confused. A Peer Network sounds > > > > like it is a > > > > > > > special case of an SSP - in effect a peered SSP. Is that > > > > > > correct? If > > > > > > > so I'd suggest for readability of the document, SSP is > > > > > > defined before > > > > > > > Peer Network, and Peer Network is defined as I > > describe above. > > > > > > >=20 > > > > > > > Similarly, an SSP seems to be a specialised SP,=20 > in that not > > > > > > only does > > > > > > > it provide L3 transport of SIP signalling and media > > > > > > packets, but also > > > > > > > includes SIP end points. Similar to my last point, it > > > > > > would help the > > > > > > > document to define SP before SSP, so that the=20 > definition of > > > > > > SSP can be > > > > > > > 'An SSP is an SP that also includes UASs and UACs...' and > > > > > > then a Peer > > > > > > > Network can be defined as '...an SSP that has connections > > > > > > to peer SSPs > > > > > > > via...'. A nice hierarchical definition (start with the > > > > > > broadest term > > > > > > > and get narrower' generally saves a lot of > > > > redefinition, which in > > > > > > > itself can create ambiguity. > > > > > > >=20 > > > > > > > And that leads me quite neatly on to a question - > > how are you > > > > > > > classifying the transit or carrier network that would sit > > > > > > between the > > > > > > > SSPs to provide interconnectivity? It is clearly an SP > > > > > > since it will > > > > > > > provide L3 transport of SIP and media, but if my comments > > > > > above are > > > > > > > right, SP is intended to be an umberella term > > > covering all the > > > > > > > sub-variants of SP. It will also need to have some > > > > > characteristics > > > > > > > dependent upon whether it is expected to provide any > > > additional > > > > > > > functionality - it clearly needs to be DiffServ aware, > > > > > but it could > > > > > > > also be required to provide a bunch of functions around > > > > > transcoding > > > > > > > and reframing in the media plane, and maybe SIP variant > > > > > > interworking, > > > > > > > which could imply B2BUAs. It seems though that this > > > > > network, be it > > > > > > > the internet or something provided by a carrier > > > > operator is only > > > > > > > alluded to in the definition of Federations. Is there not > > > > > > a need to > > > > > > > identify it explicitly, even if it is far simpler > > than I have > > > > > > > conceived it to be? I note that in the Architecture > > > > document, in > > > > > > > Figure 3 a 'Transit IP Provider' is identified > > > > (although the text > > > > > > > never refers to Figure 3 nor Transit IP=20 > Provider), but then > > > > > > in Figure > > > > > > > 1 of the same document a whole bunch of terms not > > > > defined in this > > > > > > > document are used... > > > > > > >=20 > > > > > > > I'd appreciate at least comments on whether what I have > > > > > laid out as > > > > > > > the herarchy of these terms is right or not, but I'm not > > > > > > going to get > > > > > > > fussy about whether the proposed shuffle of the ordering > > > > > > takes place. > > > > > > >=20 > > > > > > > Cheers > > > > > > >=20 > > > > > > > Dan > > > > > > >=20 > > > > > > >=20 > > > > > > > > > > 14) "3.8. Service Provider > > > > > > > > > >=20 > > > > > > > > > > A Service Provider (or SP) is defined to > > be an entity > > > > > > > > > that provides > > > > > > > > > > layer 3 (IP) transport of SIP signaling and media > > > > > > > packets. An > > > > > > > > > > example of this may be an Internet Service > > > > > Provider (ISP)." > > > > > > > > > > This at first glance is reasonable, but=20 > then the next > > > > > > > > > section goes on to > > > > > > > > > > define a SIP Service Provider as something > > that is not a > > > > > > > > > special case of > > > > > > > > > > a Service Provider, since it operates at > > layer 5, not at > > > > > > > > layer 3. We > > > > > > > > > > should perhaps find a different term for "Service > > > > Provider" > > > > > > > > > when we mean > > > > > > > > > > layer 3, e.g., "Network Service Provider". > > > > > > > > > That's fine with me....although terms like this are > > > > > > ambiguous. I > > > > > > > > > think we had specified Internet Service=20 > Provider before, > > > > > > > but there > > > > > > > > > were arguments against being that "specific". So, we > > > > > > > > generalized the > > > > > > > > > term and just provided it as an example. > > > > > > > > [JRE] I think we have to do something. The term SP is > > > > > OK if it is > > > > > > > > intended to embrace all types of SP that we are > > > dealing with, > > > > > > > > including SSP. But if we need a term for an SP that > > > > > > operates only at > > > > > > > > layer 3, we need a different term. > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > 15) "A SIP Service Provider (or SSP) is an entity > > > > > > that provides > > > > > > > > > > application level transport of SIP=20 > signaling to its > > > > > > > > customers."=20 > > > > > > > > > > Elsewhere the document talks about level 5 > > peering, but > > > > > > > > now it talks > > > > > > > > > > about application level. Also, isn't it=20 > more than just > > > > > > > > transport. I > > > > > > > > > > don't have a particular proposal, but I don't > > > really like > > > > > > > > > the present > > > > > > > > > > definition. > > > > > > > > >=20 > > > > > > > > > Hmmm...I'll see if I can think of something to make > > > > > > this clearer. > > > > > > > > > Anyone else have an opinion (heh...that's a stupid > > > > > > > > question. Everyone > > > > > > > > > has an opinion, right?!)? :-) > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > 16) "3.10. Internet Telephony Service Provider > > > > > > > > > >=20 > > > > > > > > > > An Internet Telephony Service Provider, or > > ITSP, is a > > > > > > > > > synonym for > > > > > > > > > > SSP. While the terms ITSP and SSP are > > > frequently used > > > > > > > > > > interchangeably, the SPEERMINT working > > group uses the > > > > > > > > term SSP." > > > > > > > > > > So why define the term if we are not going to > > use it? We > > > > > > > > > could mention > > > > > > > > > > it in a note below the definition of SSP, if > > > > really needed. > > > > > > > > > >=20 > > > > > > > > > ....don't care either way...we can do that=20 > to. Does it > > > > > > > > significantly > > > > > > > > > make things simpler by doing as you suggest? > > > > > > > > [JRE] The point is, by having an explicit definition of > > > > > ITSP, it > > > > > > > > tends to encourage other SPEERMINT documents to use it, > > > > > > even though > > > > > > > > there is an explicit statement that SPEERMINT will use > > > > > > only SSP. I > > > > > > > > thought just making it a note below the=20 > definition of SSP > > > > > > would help > > > > > > > > to de-emphasise ITSP further. > > > > > > >=20 > > > > > > > Forthcoming GSMA Events: > > > > > > > =20 > > > > > > > GSMA Mobile Asia Congress > > > > > > > Macau > > > > > > > 12 - 15 November 2007 > > > > > > > www.mobileasiacongress.com > > > > > > > =20 > > > > > > > GSMA Mobile World Congress > > > > > > > Barcelona > > > > > > > 11 - 14 February 2008 > > > > > > > www.mobileworldcongress.com > > > > > > >=20 > > > > > > >=20 > > > > > > > This email and its attachments are intended for the above > > > > > > named only > > > > > > > and may be confidential. If they have come to you in > > > > > error you must > > > > > > > take no action based on them, nor must you copy or > > > show them to > > > > > > > anyone; please reply to this email or call +44 207 > > > 759 2300 and > > > > > > > highlight the error > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > > Forthcoming GSMA Events: > > > > > =20 > > > > > GSMA Mobile Asia Congress > > > > > Macau > > > > > 12 - 15 November 2007 > > > > > www.mobileasiacongress.com > > > > > =20 > > > > > GSMA Mobile World Congress > > > > > Barcelona > > > > > 11 - 14 February 2008 > > > > > www.mobileworldcongress.com > > > > >=20 > > > > >=20 > > > > > This email and its attachments are intended for the above > > > > named only > > > > > and may be confidential. If they have come to you in > > > error you must > > > > > take no action based on them, nor must you copy or=20 > show them to=20 > > > > > anyone; please reply to this email or call +44 207=20 > 759 2300 and=20 > > > > > highlight the error > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > >=20 > > > Forthcoming GSMA Events: > > > =20 > > > GSMA Mobile Asia Congress > > > Macau > > > 12 - 15 November 2007 > > > www.mobileasiacongress.com > > > =20 > > > GSMA Mobile World Congress > > > Barcelona > > > 11 - 14 February 2008 > > > www.mobileworldcongress.com > > >=20 > > >=20 > > > This email and its attachments are intended for the above > > named only > > > and may be confidential. If they have come to you in=20 > error you must=20 > > > take no action based on them, nor must you copy or show them to=20 > > > anyone; please reply to this email or call +44 207 759 2300 and=20 > > > highlight the error > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > >=20 > >=20 > >=20 >=20 > Forthcoming GSMA Events: > =20 > GSMA Mobile Asia Congress > Macau > 12 - 15 November 2007 > www.mobileasiacongress.com > =20 > GSMA Mobile World Congress > Barcelona > 11 - 14 February 2008 > www.mobileworldcongress.com >=20 >=20 > This email and its attachments are intended for the above=20 > named only and may be confidential. If they have come to you=20 > in error you must take no action based on them, nor must you=20 > copy or show them to anyone; please reply to this email or=20 > call +44 207 759 2300 and highlight the error >=20 >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 02 11:46:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcjwM-0000QS-Pf; Tue, 02 Oct 2007 11:45:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcjwK-0000CY-OF for speermint@ietf.org; Tue, 02 Oct 2007 11:45:40 -0400 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcjwI-0007Pf-0H for speermint@ietf.org; Tue, 02 Oct 2007 11:45:38 -0400 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1Icjvk-0008K0-00; Tue, 02 Oct 2007 17:45:04 +0200 Date: Tue, 2 Oct 2007 17:45:04 +0200 From: Otmar Lendl To: "Uzelac, Adam" Message-ID: <20071002154504.GA31938@nic.at> Mail-Followup-To: Otmar Lendl , "Uzelac, Adam" , Daryl Malas , speermint@ietf.org, "Livingood, Jason" References: <6918D1F7F8770C4FB182838A7BDFD6C8016FF350@GSMDUBEX02.GSM.TLD> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: "Livingood, Jason" , speermint@ietf.org Subject: [Speermint] Indirect Peering (was: WGLCfordraft-ietf-speermint-terminology-12) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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, excuse me for barging in here: On 2007/10/02 16:10, "Uzelac, Adam" wrote: > > If a residential UA is registered to a UAS or not really shouldn't > matter. A residential UA alone with some static SIP-routing would > define the originating domain. If there's reachability with other UAs > without crossing into another SSP, like sessions in the same building, > neighborhood, business group, etc - these are all within the same domain > and no peering occurs. Should the look-up function result in the > terminating UA being in the terminating domain (think called party) - > then it's a peer relationship between 2 parties: > > SSP(O) <---> SSP(T) > > If there's no direct path between the originating domain [SSP(O)] and > the terminating domain [SSP(T)], then employment of an intermediary or > transit domain [SSP(t)] may, and oftentimes does, get used: > > SSP(O) <---> SSP(t) <---> SSP(T) > > I don't know if that clears things up or not, but it's how I organize > the world. ;) > This is my understanding as well. I just want to bring up a terminology question here. Your graph from above could just as well be SSP(O) <---> SSP(t1) <---> SSP(t2) <---> SSP(T) or involve even more transit SSPs. The current terminology draft talks of SSP(O) and SSP(T) peering with each other ("indirect peering"). The longer I thing about this, the more I'm no longer sure whether this is good choice of words. Consider the Layer 3 (IP layer) world: In that case "peering" is only used for the relationship between two AS which directly talk to each other. The case of "assisted peering" does have its equivalence in the L3 world in the case of route-reflectors at Internet Exchanges. If ISP-1 has a BGP session with ISP-2, who in turn talks BGP with ISP-3 then endpoints within ISP-1 can talk IP to endpoints in ISP-3 (if ISP-2 provides transit). The language there would NOT talk of ISP-1 having a peering relationship with ISP-3. Instead, the terminology used in the L3 world would talk about ISP-3 being reachable from ISP-1. "Peering via a transit provider" is an oxymoron in the L3 world. It's perfectly ok if we chose this route with open eyes. I'm just not sure whether we have sufficently thought about this one. cheers, /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 03 02:59:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcyAW-0001ls-Mf; Wed, 03 Oct 2007 02:57:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcyAV-0001l0-FB for speermint@ietf.org; Wed, 03 Oct 2007 02:57:15 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcyAV-00062f-1w for speermint@ietf.org; Wed, 03 Oct 2007 02:57:15 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JPB0099VPYS2R@siemenscomms.co.uk> for speermint@ietf.org; Wed, 03 Oct 2007 07:56:53 +0100 (BST) Date: Wed, 03 Oct 2007 07:57:12 +0100 From: "Elwell, John" Subject: RE: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 In-reply-to: <6918D1F7F8770C4FB182838A7BDFD6C8016FF424@GSMDUBEX02.GSM.TLD> To: Dan Warren , "Uzelac, Adam" , Daryl Malas Message-id: <0D5F89FAC29E2C41B98A6A762007F5D032571A@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgAaIO7/hEeVa9kTQKfLRakKTmBwAAcct/QAPw2WGAAAnUVkAACxNogAAOQLeAAAEPmEAADblfAAAEF83AAIbJ6EA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <6918D1F7F8770C4FB182838A7BDFD6C8016FF424@GSMDUBEX02.GSM.TLD> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "Malas, Daryl" , "Peterson, , dmm"@1-4-5.net, speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > I think we are all arguing the same way now. There is a question of > semantics and a question of reality. So semantics (and the definition > in the terminology draft) says that the SSP does not have to include > UAS's and/or UAC's but the reality is that the concept of a SSP with > UAS's or UAC's is pretty hard to comprehend. [JRE] Just getting back to terminology-12, in fact the definition of SSP makes no mention of UAC and UAS, but the definition of Peer Network does. I think we have 3 issues here that have been raised at certain times in this thread: 1. We should not try to distinguish between UAC and UAS. If we need to talk about UA, just use the term UA. 2. What is the intended difference between a Peer Network and an SSP? Are they totally different or is one a subset of the other? Or are they the same (in which case we should have only a single term)? Possibly a diagram showing relationships between Peer Networks, SSPs and SPs would help. If it is hard to draw a diagram (e.g., things are not a simple hierarchy), then it probably means we have got something wrong. 3. Is the inclusion of UAs a NECESSARY aspect of a Peer Network and/or an SSP FOR THE PURPOSES OF SPEERMINT? Whilst in practice a Peer Network or an SSP is likely to have UAs, is it of relevance to SPEERMINT discussions? Obviously for SSP(O) and SSP(T) there has to be an associated UA (whether this is part of the SSP or separate, I am not sure). But for SSP(t) the existence of UAs seems irrelevant to SPEERMINT. So for a general definition of SSP or Peer Network, from which we can derive definitions of more specialised objects (such as SSP(O)) if we wish, I would still argue that the inclusion of UAs is unnecessary. John _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 03 04:11:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IczIp-000761-B6; Wed, 03 Oct 2007 04:09:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IczIm-0006t7-Ii for speermint@ietf.org; Wed, 03 Oct 2007 04:09:53 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound6-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IczIg-0003os-9m for speermint@ietf.org; Wed, 03 Oct 2007 04:09:52 -0400 Received: from outbound6-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound6-cpk-R.bigfish.com (Postfix) with ESMTP id 5FBAA7F30B7; Wed, 3 Oct 2007 08:09:24 +0000 (UTC) Received: from mail43-cpk-R.bigfish.com (unknown [10.2.40.3]) by outbound6-cpk.bigfish.com (Postfix) with ESMTP id 1CDDCF6004E; Wed, 3 Oct 2007 08:09:24 +0000 (UTC) Received: from mail43-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail43-cpk-R.bigfish.com (Postfix) with ESMTP id 85AB79F0140; Wed, 3 Oct 2007 08:09:25 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 212.120.142.30; Service: EHS Received: by mail43-cpk (MessageSwitch) id 1191398964472954_14695; Wed, 3 Oct 2007 08:09:24 +0000 (UCT) Received: from GSMDUBEX02.GSM.TLD (unknown [212.120.142.30]) by mail43-cpk.bigfish.com (Postfix) with ESMTP id B277CA2006F; Wed, 3 Oct 2007 08:09:23 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Date: Wed, 3 Oct 2007 09:09:21 +0100 Message-ID: <6918D1F7F8770C4FB182838A7BDFD6C8016FF60D@GSMDUBEX02.GSM.TLD> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgAaIO7/hEeVa9kTQKfLRakKTmBwAAcct/QAPw2WGAAAnUVkAACxNogAAOQLeAAAEPmEAADblfAAAEF83AAIbJ6EAACoooQ From: "Dan Warren" To: "Elwell, John" , "Uzelac, Adam" , "Daryl Malas" X-Spam-Score: -4.0 (----) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: "Malas, Daryl" , "Peterson, , dmm"@1-4-5.net, speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > [JRE] Just getting back to terminology-12, in fact the = > definition of SSP makes no mention of UAC and UAS, but the = > definition of Peer Network does. I think we have 3 issues = > here that have been raised at certain times in this thread: > = > 1. We should not try to distinguish between UAC and UAS. If = > we need to talk about UA, just use the term UA. Agreed. > = > 2. What is the intended difference between a Peer Network and an SSP? > Are they totally different or is one a subset of the other? = > Or are they the same (in which case we should have only a = > single term)? Possibly a diagram showing relationships = > between Peer Networks, SSPs and SPs would help. If it is hard = > to draw a diagram (e.g., things are not a simple hierarchy), = > then it probably means we have got something wrong. Let me expand the problem you identify a little. In the terminology draft there are identified;- -Service Providers, SIP Service Providers (which includes or is identical to ITSPs?), Peer Networks -Layer 3 and Layer 5 interconnect, with subcategories of L5 i/c being -Direct and Indirect Interconnect -Assisted Interconnect (implicitly there must also be Unassisted?) -Dynamic and Static Interconnect Because of the subcategories of L5 i/c, there is a lot of different permutations and combinations of different Provider types that could be conceived, so it is going to prove very difficult to come up with one picture. In your architecture. That is before you have considered third party access providers and mobile roaming. > = > 3. Is the inclusion of UAs a NECESSARY aspect of a Peer = > Network and/or an SSP FOR THE PURPOSES OF SPEERMINT? Whilst = > in practice a Peer Network or an SSP is likely to have UAs, = > is it of relevance to SPEERMINT discussions? Obviously for = > SSP(O) and SSP(T) there has to be an associated UA (whether = > this is part of the SSP or separate, I am not sure). But for = > SSP(t) the existence of UAs seems irrelevant to SPEERMINT. So = > for a general definition of SSP or Peer Network, from which = > we can derive definitions of more specialised objects (such as > SSP(O)) if we wish, I would still argue that the inclusion of = > UAs is unnecessary. = I'd argue that SSP(t) is not a Peer Network. SSP(O) and SSP(T) are Peering with each other, whilst SSP(t) is providing the mechanism by which that Peering takes place. Where it gets blurred is if SSP(t) is doing more than just providing transit, but includes elements doing SIP profile interworking, transcoding (and transcoder insertion), reframing and so on. That has a certain implication about the presence of a B2BUA, which I think is probably the (dare we use the phrase) peering point. It's where the two protocol profiles of SSP(O) and SSP(T) clash, but SSP(t) offers the interworking as part of a Federation agreement, that the status of SSP(t) is called into question under current definitions... Dan > = > John > = > = Forthcoming GSMA Events: = GSMA Mobile Asia Congress Macau 12 - 15 November 2007 www.mobileasiacongress.com = GSMA Mobile World Congress Barcelona 11 - 14 February 2008 www.mobileworldcongress.com This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 759 2300 and highlight the error _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 03 05:57:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0xI-0005OX-3C; Wed, 03 Oct 2007 05:55:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0xG-0005MA-AR for speermint@ietf.org; Wed, 03 Oct 2007 05:55:46 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id0xF-0002uE-Hd for speermint@ietf.org; Wed, 03 Oct 2007 05:55:46 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JPB00C65Y8AV9@siemenscomms.co.uk> for speermint@ietf.org; Wed, 03 Oct 2007 10:55:22 +0100 (BST) Date: Wed, 03 Oct 2007 10:55:42 +0100 From: "Elwell, John" Subject: RE: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 In-reply-to: <6918D1F7F8770C4FB182838A7BDFD6C8016FF60D@GSMDUBEX02.GSM.TLD> To: Dan Warren , "Uzelac, Adam" , Daryl Malas Message-id: <0D5F89FAC29E2C41B98A6A762007F5D032573E@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgAaIO7/hEeVa9kTQKfLRakKTmBwAAcct/QAPw2WGAAAnUVkAACxNogAAOQLeAAAEPmEAADblfAAAEF83AAIbJ6EAACoooQAAQb1gA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <6918D1F7F8770C4FB182838A7BDFD6C8016FF60D@GSMDUBEX02.GSM.TLD> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: "Malas, Daryl" , "Peterson, , dmm"@1-4-5.net, speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > -----Original Message----- > From: Dan Warren [mailto:DWarren@gsm.org] > Sent: 03 October 2007 09:09 > To: Elwell, John; Uzelac, Adam; Daryl Malas > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > speermint@ietf.org; Livingood, Jason > Subject: RE: [Speermint] > [wg-business]WGLCfordraft-ietf-speermint-terminology-12 > > > [JRE] Just getting back to terminology-12, in fact the > > definition of SSP makes no mention of UAC and UAS, but the > > definition of Peer Network does. I think we have 3 issues > > here that have been raised at certain times in this thread: > > > > 1. We should not try to distinguish between UAC and UAS. If > > we need to talk about UA, just use the term UA. > > Agreed. > > > > > 2. What is the intended difference between a Peer Network > and an SSP? > > Are they totally different or is one a subset of the other? > > Or are they the same (in which case we should have only a > > single term)? Possibly a diagram showing relationships > > between Peer Networks, SSPs and SPs would help. If it is hard > > to draw a diagram (e.g., things are not a simple hierarchy), > > then it probably means we have got something wrong. > > Let me expand the problem you identify a little. In the terminology > draft there are identified;- > > -Service Providers, SIP Service Providers (which includes or is > identical to ITSPs?), Peer Networks > > -Layer 3 and Layer 5 interconnect, with subcategories of L5 i/c being > -Direct and Indirect Interconnect > -Assisted Interconnect (implicitly there must also be > Unassisted?) > -Dynamic and Static Interconnect > > Because of the subcategories of L5 i/c, there is a lot of different > permutations and combinations of different Provider types > that could be > conceived, so it is going to prove very difficult to come up with one > picture. In your architecture. That is before you have considered > third party access providers and mobile roaming. [JRE] But all I wanted is a diagram to show the relationship between the 3 objects we are trying to define: Peer Network, SSP and SP. I'm not necessarily saying that such a diagram needs to go into the RFC, but it might help the discussion. > > > > > 3. Is the inclusion of UAs a NECESSARY aspect of a Peer > > Network and/or an SSP FOR THE PURPOSES OF SPEERMINT? Whilst > > in practice a Peer Network or an SSP is likely to have UAs, > > is it of relevance to SPEERMINT discussions? Obviously for > > SSP(O) and SSP(T) there has to be an associated UA (whether > > this is part of the SSP or separate, I am not sure). But for > > SSP(t) the existence of UAs seems irrelevant to SPEERMINT. So > > for a general definition of SSP or Peer Network, from which > > we can derive definitions of more specialised objects (such as > > SSP(O)) if we wish, I would still argue that the inclusion of > > UAs is unnecessary. > > I'd argue that SSP(t) is not a Peer Network. SSP(O) and SSP(T) are > Peering with each other, whilst SSP(t) is providing the mechanism by > which that Peering takes place. Where it gets blurred is if SSP(t) is > doing more than just providing transit, but includes elements > doing SIP > profile interworking, transcoding (and transcoder insertion), > reframing > and so on. That has a certain implication about the presence of a > B2BUA, which I think is probably the (dare we use the phrase) peering > point. It's where the two protocol profiles of SSP(O) and > SSP(T) clash, > but SSP(t) offers the interworking as part of a Federation agreement, > that the status of SSP(t) is called into question under current > definitions... [JRE] I think you are saying that a Peer Network is a special case of an SSP. SSP(O) and SSP(T) are Peer Networks, but SSP(t) is not. So therefore can we define Peer Network in terms of SSP? > > Dan > > > > > John > > > > > > Forthcoming GSMA Events: > > GSMA Mobile Asia Congress > Macau > 12 - 15 November 2007 > www.mobileasiacongress.com > > GSMA Mobile World Congress > Barcelona > 11 - 14 February 2008 > www.mobileworldcongress.com > > > This email and its attachments are intended for the above > named only and may be confidential. If they have come to you > in error you must take no action based on them, nor must you > copy or show them to anyone; please reply to this email or > call +44 207 759 2300 and highlight the error > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 03 06:13:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id1DP-0007rG-US; Wed, 03 Oct 2007 06:12:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id1DN-0007WP-Pf for speermint@ietf.org; Wed, 03 Oct 2007 06:12:25 -0400 Received: from mail-dub.bigfish.com ([213.199.154.10] helo=mail30-dub-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id1DH-0003MN-Pw for speermint@ietf.org; Wed, 03 Oct 2007 06:12:20 -0400 Received: from mail30-dub (localhost.localdomain [127.0.0.1]) by mail30-dub-R.bigfish.com (Postfix) with ESMTP id 560667F0631; Wed, 3 Oct 2007 10:12:16 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 212.120.142.30; Service: EHS Received: by mail30-dub (MessageSwitch) id 1191406331172223_29989; Wed, 3 Oct 2007 10:12:11 +0000 (UCT) Received: from GSMDUBEX02.GSM.TLD (unknown [212.120.142.30]) by mail30-dub.bigfish.com (Postfix) with ESMTP id B5BB622005D; Wed, 3 Oct 2007 10:12:10 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Date: Wed, 3 Oct 2007 11:12:05 +0100 Message-ID: <6918D1F7F8770C4FB182838A7BDFD6C801763543@GSMDUBEX02.GSM.TLD> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgAaIO7/hEeVa9kTQKfLRakKTmBwAAcct/QAPw2WGAAAnUVkAACxNogAAOQLeAAAEPmEAADblfAAAEF83AAIbJ6EAACoooQAAQb1gAAAIpVgA== From: "Dan Warren" To: "Elwell, John" , "Uzelac, Adam" , "Daryl Malas" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: "Malas, Daryl" , "Peterson, , dmm"@1-4-5.net, speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org = > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] = > Sent: 03 October 2007 10:56 > To: Dan Warren; Uzelac, Adam; Daryl Malas > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; = > speermint@ietf.org; Livingood, Jason > Subject: RE: [Speermint] = > [wg-business]WGLCfordraft-ietf-speermint-terminology-12 > = > = > = > > -----Original Message----- > > From: Dan Warren [mailto:DWarren@gsm.org] > > Sent: 03 October 2007 09:09 > > To: Elwell, John; Uzelac, Adam; Daryl Malas > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; speermint@ietf.org; = > > Livingood, Jason > > Subject: RE: [Speermint] > > [wg-business]WGLCfordraft-ietf-speermint-terminology-12 > > = > > > [JRE] Just getting back to terminology-12, in fact the = > definition of = > > > SSP makes no mention of UAC and UAS, but the definition of Peer = > > > Network does. I think we have 3 issues here that have = > been raised at = > > > certain times in this thread: > > > = > > > 1. We should not try to distinguish between UAC and UAS. = > If we need = > > > to talk about UA, just use the term UA. > > = > > Agreed. > > = > > > = > > > 2. What is the intended difference between a Peer Network > > and an SSP? > > > Are they totally different or is one a subset of the other? = > > > Or are they the same (in which case we should have only a single = > > > term)? Possibly a diagram showing relationships between Peer = > > > Networks, SSPs and SPs would help. If it is hard to draw = > a diagram = > > > (e.g., things are not a simple hierarchy), then it = > probably means we = > > > have got something wrong. > > = > > Let me expand the problem you identify a little. In the = > terminology = > > draft there are identified;- > > = > > -Service Providers, SIP Service Providers (which includes or is = > > identical to ITSPs?), Peer Networks > > = > > -Layer 3 and Layer 5 interconnect, with subcategories of L5 = > i/c being > > -Direct and Indirect Interconnect > > -Assisted Interconnect (implicitly there must also be > > Unassisted?) > > -Dynamic and Static Interconnect > > = > > Because of the subcategories of L5 i/c, there is a lot of different = > > permutations and combinations of different Provider types = > that could = > > be conceived, so it is going to prove very difficult to = > come up with = > > one picture. In your architecture. That is before you have = > > considered third party access providers and mobile roaming. > [JRE] But all I wanted is a diagram to show the relationship = > between the > 3 objects we are trying to define: Peer Network, SSP and SP. = > I'm not necessarily saying that such a diagram needs to go = > into the RFC, but it might help the discussion. How about a description? SP is operating at L3. SSP is operating at L5 (and hence L3 so is a specialised SP). Peer Network is an SSP with UA's. Clearly not a final proposal (there aren't enough words and it doesn't include any exceptions to the rules - a good definition always has exceptions, right?), but maybe a starting point for you all to dissect and destroy. > = > > = > > > = > > > 3. Is the inclusion of UAs a NECESSARY aspect of a Peer Network = > > > and/or an SSP FOR THE PURPOSES OF SPEERMINT? Whilst in practice a = > > > Peer Network or an SSP is likely to have UAs, is it of = > relevance to = > > > SPEERMINT discussions? Obviously for > > > SSP(O) and SSP(T) there has to be an associated UA = > (whether this is = > > > part of the SSP or separate, I am not sure). But for > > > SSP(t) the existence of UAs seems irrelevant to = > SPEERMINT. So for a = > > > general definition of SSP or Peer Network, from which we = > can derive = > > > definitions of more specialised objects (such as > > > SSP(O)) if we wish, I would still argue that the = > inclusion of UAs is = > > > unnecessary. > > = > > I'd argue that SSP(t) is not a Peer Network. SSP(O) and SSP(T) are = > > Peering with each other, whilst SSP(t) is providing the = > mechanism by = > > which that Peering takes place. Where it gets blurred is = > if SSP(t) is = > > doing more than just providing transit, but includes elements doing = > > SIP profile interworking, transcoding (and transcoder insertion), = > > reframing and so on. That has a certain implication about the = > > presence of a B2BUA, which I think is probably the (dare we use the = > > phrase) peering point. It's where the two protocol = > profiles of SSP(O) = > > and > > SSP(T) clash, > > but SSP(t) offers the interworking as part of a Federation = > agreement, = > > that the status of SSP(t) is called into question under current = > > definitions... > [JRE] I think you are saying that a Peer Network is a special = > case of an SSP. SSP(O) and SSP(T) are Peer Networks, but = > SSP(t) is not. So therefore can we define Peer Network in = > terms of SSP? See above... I think we ought to be able to. > = > > = > > Dan > > = > > > = > > > John > > > = > > > = > > = > > Forthcoming GSMA Events: > > = > > GSMA Mobile Asia Congress > > Macau > > 12 - 15 November 2007 > > www.mobileasiacongress.com > > = > > GSMA Mobile World Congress > > Barcelona > > 11 - 14 February 2008 > > www.mobileworldcongress.com > > = > > = > > This email and its attachments are intended for the above = > named only = > > and may be confidential. If they have come to you in error you must = > > take no action based on them, nor must you copy or show them to = > > anyone; please reply to this email or call +44 207 759 2300 and = > > highlight the error > > = > > = > > > = > = Forthcoming GSMA Events: = GSMA Mobile Asia Congress Macau 12 - 15 November 2007 www.mobileasiacongress.com = GSMA Mobile World Congress Barcelona 11 - 14 February 2008 www.mobileworldcongress.com This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 759 2300 and highlight the error _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 03 06:31:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id1Ue-0006TE-LM; Wed, 03 Oct 2007 06:30:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id1Ud-0006T4-Da for speermint@ietf.org; Wed, 03 Oct 2007 06:30:15 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id1UX-0007pP-7R for speermint@ietf.org; Wed, 03 Oct 2007 06:30:15 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JPB00M0YZT6A7@siemenscomms.co.uk> for speermint@ietf.org; Wed, 03 Oct 2007 11:29:30 +0100 (BST) Date: Wed, 03 Oct 2007 11:29:51 +0100 From: "Elwell, John" Subject: RE: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 In-reply-to: <6918D1F7F8770C4FB182838A7BDFD6C801763543@GSMDUBEX02.GSM.TLD> To: Dan Warren , "Uzelac, Adam" , Daryl Malas Message-id: <0D5F89FAC29E2C41B98A6A762007F5D032574A@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgAaIO7/hEeVa9kTQKfLRakKTmBwAAcct/QAPw2WGAAAnUVkAACxNogAAOQLeAAAEPmEAADblfAAAEF83AAIbJ6EAACoooQAAQb1gAAAIpVgAAAo6DQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <6918D1F7F8770C4FB182838A7BDFD6C801763543@GSMDUBEX02.GSM.TLD> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "Malas, Daryl" , "Peterson, , dmm"@1-4-5.net, speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Dan, > How about a description? > > SP is operating at L3. > SSP is operating at L5 (and hence L3 so is a specialised SP). > Peer Network is an SSP with UA's. > > Clearly not a final proposal (there aren't enough words and it doesn't > include any exceptions to the rules - a good definition always has > exceptions, right?), but maybe a starting point for you all to dissect > and destroy. [JRE] OK, but in practice almost any SSP will be a Peer Network (even if in certain use cases there is no UA involved, e.g., when acting as an SSP(t)). So why do we need the term Peer Network? I notice it is not used in the architecture draft, although it is used in the consolidated use cases draft. Why can't we stick to SSP? If we really need both terms, I don't believe the presence or absence of UAs is an appropriate distinction. John _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 03 06:56:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id1tC-0000ri-Bz; Wed, 03 Oct 2007 06:55:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id1tB-0000SB-7X for speermint@ietf.org; Wed, 03 Oct 2007 06:55:37 -0400 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound10-sin-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id1t2-0008Ts-Hs for speermint@ietf.org; Wed, 03 Oct 2007 06:55:35 -0400 Received: from outbound10-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound10-sin-R.bigfish.com (Postfix) with ESMTP id C01671BA9839; Wed, 3 Oct 2007 10:53:11 +0000 (UTC) Received: from mail58-sin-R.bigfish.com (unknown [10.3.40.3]) by outbound10-sin.bigfish.com (Postfix) with ESMTP id B2E812C004F; Wed, 3 Oct 2007 10:53:11 +0000 (UTC) Received: from mail58-sin (localhost.localdomain [127.0.0.1]) by mail58-sin-R.bigfish.com (Postfix) with ESMTP id 6AC198401F3; Wed, 3 Oct 2007 10:53:10 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 212.120.142.30; Service: EHS Received: by mail58-sin (MessageSwitch) id 1191408790363800_29053; Wed, 3 Oct 2007 10:53:10 +0000 (UCT) Received: from GSMDUBEX02.GSM.TLD (unknown [212.120.142.30]) by mail58-sin.bigfish.com (Postfix) with ESMTP id 5F7C8E2807F; Wed, 3 Oct 2007 10:53:08 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Date: Wed, 3 Oct 2007 11:53:09 +0100 Message-ID: <6918D1F7F8770C4FB182838A7BDFD6C80176355A@GSMDUBEX02.GSM.TLD> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgAaIO7/hEeVa9kTQKfLRakKTmBwAAcct/QAPw2WGAAAnUVkAACxNogAAOQLeAAAEPmEAADblfAAAEF83AAIbJ6EAACoooQAAQb1gAAAIpVgAAAo6DQAADPzWA= From: "Dan Warren" To: "Elwell, John" , "Uzelac, Adam" , "Daryl Malas" X-Spam-Score: -4.0 (----) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: "Malas, Daryl" , "Peterson, , dmm"@1-4-5.net, speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > Dan, > = > > How about a description? > > = > > SP is operating at L3. > > SSP is operating at L5 (and hence L3 so is a specialised SP). > > Peer Network is an SSP with UA's. > > = > > Clearly not a final proposal (there aren't enough words and = > it doesn't = > > include any exceptions to the rules - a good definition always has = > > exceptions, right?), but maybe a starting point for you all = > to dissect = > > and destroy. > [JRE] OK, but in practice almost any SSP will be a Peer = > Network (even if in certain use cases there is no UA = > involved, e.g., when acting as an SSP(t)). So why do we need = > the term Peer Network? I notice it is not used in the = > architecture draft, although it is used in the consolidated = > use cases draft. Why can't we stick to SSP? > = > If we really need both terms, I don't believe the presence or = > absence of UAs is an appropriate distinction. Should it then be presence or absence of subscribers/end users then? Taking the term 'peer' literally, it means 'at the same level' or 'equivalent'. SSP(O) and SSP(T) are equivalent networks as they are fulfilling the same functions (albeit potentially in different ways) for the same types of customers. SSP(t) is not a 'peer' of SSP(O) and SSP(T) because it is doing something distinctly different. I think I said once before, SSP(O) and SSP(T) are peering, SSP(t) is providing the capability and connectivity for the peering to take place. Dan > = > John > = > = Forthcoming GSMA Events: = GSMA Mobile Asia Congress Macau 12 - 15 November 2007 www.mobileasiacongress.com = GSMA Mobile World Congress Barcelona 11 - 14 February 2008 www.mobileworldcongress.com This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 759 2300 and highlight the error _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 03 08:08:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id2zo-0007Lk-4P; Wed, 03 Oct 2007 08:06:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id2zm-0007JD-Ui for speermint@ietf.org; Wed, 03 Oct 2007 08:06:30 -0400 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id2zc-00022r-NH for speermint@ietf.org; Wed, 03 Oct 2007 08:06:26 -0400 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1Id2zH-0000Ak-00 for ; Wed, 03 Oct 2007 14:05:59 +0200 Date: Wed, 3 Oct 2007 14:05:59 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Message-ID: <20071003120559.GA627@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <6918D1F7F8770C4FB182838A7BDFD6C801763543@GSMDUBEX02.GSM.TLD> <0D5F89FAC29E2C41B98A6A762007F5D032574A@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D032574A@GBNTHT12009MSX.gb002.siemens.net> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 2007/10/03 12:10, "Elwell, John" wrote: > Dan: > > How about a description? > > > > SP is operating at L3. > > SSP is operating at L5 (and hence L3 so is a specialised SP). > > Peer Network is an SSP with UA's. > > > > Clearly not a final proposal (there aren't enough words and it doesn't > > include any exceptions to the rules - a good definition always has > > exceptions, right?), but maybe a starting point for you all to dissect > > and destroy. > [JRE] OK, but in practice almost any SSP will be a Peer Network (even if > in certain use cases there is no UA involved, e.g., when acting as an > SSP(t)). So why do we need the term Peer Network? I notice it is not > used in the architecture draft, although it is used in the consolidated > use cases draft. Why can't we stick to SSP? That's simple. Because this working group is named "session PEERING for ...", so the authors assumed a need to talk only about "peering" (which is IMnsHO the more-or-less direct interconnection between two networks for their mutual benefit), even though some of the cases they describe is pure "transit" which is only needed due to a lack of peering. *shrug* (Seriously: yes, we need to talk about transit. I just object to calling it peering.) /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 03 09:20:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id48b-00035t-U2; Wed, 03 Oct 2007 09:19:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id48b-000336-6V for speermint@ietf.org; Wed, 03 Oct 2007 09:19:41 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id48U-0004gr-Hb for speermint@ietf.org; Wed, 03 Oct 2007 09:19:40 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JPC00J547NUWT@siemenscomms.co.uk> for speermint@ietf.org; Wed, 03 Oct 2007 14:19:06 +0100 (BST) Date: Wed, 03 Oct 2007 14:19:25 +0100 From: "Elwell, John" Subject: RE: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 In-reply-to: <6918D1F7F8770C4FB182838A7BDFD6C80176355A@GSMDUBEX02.GSM.TLD> To: Dan Warren , "Uzelac, Adam" , Daryl Malas Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0325771@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgAaIO7/hEeVa9kTQKfLRakKTmBwAAcct/QAPw2WGAAAnUVkAACxNogAAOQLeAAAEPmEAADblfAAAEF83AAIbJ6EAACoooQAAQb1gAAAIpVgAAAo6DQAADPzWAABB2BEA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <6918D1F7F8770C4FB182838A7BDFD6C80176355A@GSMDUBEX02.GSM.TLD> X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: "Malas, Daryl" , "Peterson, , dmm"@1-4-5.net, speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > -----Original Message----- > From: Dan Warren [mailto:DWarren@gsm.org] > Sent: 03 October 2007 11:53 > To: Elwell, John; Uzelac, Adam; Daryl Malas > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > speermint@ietf.org; Livingood, Jason > Subject: RE: [Speermint] > [wg-business]WGLCfordraft-ietf-speermint-terminology-12 > > > Dan, > > > > > How about a description? > > > > > > SP is operating at L3. > > > SSP is operating at L5 (and hence L3 so is a specialised SP). > > > Peer Network is an SSP with UA's. > > > > > > Clearly not a final proposal (there aren't enough words and > > it doesn't > > > include any exceptions to the rules - a good definition > always has > > > exceptions, right?), but maybe a starting point for you all > > to dissect > > > and destroy. > > [JRE] OK, but in practice almost any SSP will be a Peer > > Network (even if in certain use cases there is no UA > > involved, e.g., when acting as an SSP(t)). So why do we need > > the term Peer Network? I notice it is not used in the > > architecture draft, although it is used in the consolidated > > use cases draft. Why can't we stick to SSP? > > > > If we really need both terms, I don't believe the presence or > > absence of UAs is an appropriate distinction. > > Should it then be presence or absence of subscribers/end users then? > Taking the term 'peer' literally, it means 'at the same level' or > 'equivalent'. SSP(O) and SSP(T) are equivalent networks as they are > fulfilling the same functions (albeit potentially in > different ways) for > the same types of customers. SSP(t) is not a 'peer' of SSP(O) and > SSP(T) because it is doing something distinctly different. I think I > said once before, SSP(O) and SSP(T) are peering, SSP(t) is > providing the > capability and connectivity for the peering to take place. [JRE] Even an SSP that acts as an SSP(t) is likely to have subscribers, although they would not be involved in that particular case. Also the term "subscriber" is not a SIP term and has connotations of charging - not so applicable for enterprise peering. So I see "subscriber" as being no better (perhaps worse) than "UA". Also an SSP(O) or SSP(T) can act on behalf of a UA that is a gateway to PSTN, so there is no "subscriber" (in the traditional sense) involved here. Notwithstanding Otmar's comment, which I will address separately, I guess an SSP becomes a Peering Network when it is acting on behalf of a UA that has originated a SIP request that needs to be routed outside the SSP or is the destination of a SIP request that has been received from outside the SSP. Am I on the right track? I think we end up with the following hierarchy: SP | SSP | | Peer SSP(t) Network | | SSP(O) SSP(T) So SSP(O), SSP(T) and SSP(t) are specialisations of SSP, but Peer Network is the particular grouping of SSP(O) and SSP(T). Assuming this is what is intended, and assuming all these terms are required, their definitions should reflect this hierarchy, e.g: SSP(O): an SSP that for a particular SIP request SSP(T): an SSP that for a particular SIP request SSP(t): an SSP that for a particular SIP request Peer Network: an SSP that can behave as an SSP(O) and/or an SSP (T). John > > Dan > > > > > John > > > > > > Forthcoming GSMA Events: > > GSMA Mobile Asia Congress > Macau > 12 - 15 November 2007 > www.mobileasiacongress.com > > GSMA Mobile World Congress > Barcelona > 11 - 14 February 2008 > www.mobileworldcongress.com > > > This email and its attachments are intended for the above > named only and may be confidential. If they have come to you > in error you must take no action based on them, nor must you > copy or show them to anyone; please reply to this email or > call +44 207 759 2300 and highlight the error > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 03 09:20:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id48t-0003iB-G2; Wed, 03 Oct 2007 09:19:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id48s-0003i0-VW for speermint@ietf.org; Wed, 03 Oct 2007 09:19:58 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id48r-0004iV-Nk for speermint@ietf.org; Wed, 03 Oct 2007 09:19:58 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JPC00J5S7OBWT@siemenscomms.co.uk> for speermint@ietf.org; Wed, 03 Oct 2007 14:19:23 +0100 (BST) Date: Wed, 03 Oct 2007 14:19:42 +0100 From: "Elwell, John" Subject: RE: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 In-reply-to: <20071003120559.GA627@nic.at> To: Otmar Lendl , speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0325772@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgFtwXe2gSBm4zlSVabHjPQR9s4TAAB6LEQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <6918D1F7F8770C4FB182838A7BDFD6C801763543@GSMDUBEX02.GSM.TLD> <0D5F89FAC29E2C41B98A6A762007F5D032574A@GBNTHT12009MSX.gb002.siemens.net> <20071003120559.GA627@nic.at> X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar, I understand your point (and the point you made in your previous posting). I think the concept of indirect peering was formulated before I got actively involved in SPEERMINT, so I don't want to destabilise that work. However, I do have some sympathy for what you say. Consider the following case UA --- Enterprise --- Carrier --- Carrier --- Enterprise --- UA A B C D E F UA A on enterprise B makes a request to UA F on enterprise E. Enterprise B sends all its requests to non-direct-peering domains via carrier C. Enterprise E receives all its requests from non-direct-peering domains via carrier E. According to the SPEERMINT concept of peering, Enterprise B is peering with Enterprise E. Carrier C is not peering with Carrier D or with Enterprise B. Carrier D is not peering with carrier C or with Enterprise F. So in this case, Carrier C and Carrier D are not Peering Networks. I am not sure this is a correct view. I understand that your view would be that Enterprise B is peering with Carrier C, Carrier C is peering with Carrier D, etc.. John > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: 03 October 2007 13:06 > To: speermint@ietf.org > Subject: Re: [Speermint] > [wg-business]WGLCfordraft-ietf-speermint-terminology-12 > > On 2007/10/03 12:10, "Elwell, John" wrote: > > Dan: > > > How about a description? > > > > > > SP is operating at L3. > > > SSP is operating at L5 (and hence L3 so is a specialised SP). > > > Peer Network is an SSP with UA's. > > > > > > Clearly not a final proposal (there aren't enough words > and it doesn't > > > include any exceptions to the rules - a good definition always has > > > exceptions, right?), but maybe a starting point for you > all to dissect > > > and destroy. > > [JRE] OK, but in practice almost any SSP will be a Peer > Network (even if > > in certain use cases there is no UA involved, e.g., when > acting as an > > SSP(t)). So why do we need the term Peer Network? I notice it is not > > used in the architecture draft, although it is used in the > consolidated > > use cases draft. Why can't we stick to SSP? > > > > That's simple. > > Because this working group is named "session PEERING for ...", so the > authors assumed a need to talk only about "peering" (which is IMnsHO > the more-or-less direct interconnection between two networks for their > mutual benefit), even though some of the cases they describe is pure > "transit" which is only needed due to a lack of peering. > > *shrug* > > (Seriously: yes, we need to talk about transit. I just object > to calling it peering.) > > /ol > -- > / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ > | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | > \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 03 12:52:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id7QL-0005gg-7J; Wed, 03 Oct 2007 12:50:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id7QK-0005SP-75 for speermint@ietf.org; Wed, 03 Oct 2007 12:50:12 -0400 Received: from mail20.messagelabs.com ([216.82.245.67]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Id7QC-0008He-El for speermint@ietf.org; Wed, 03 Oct 2007 12:50:05 -0400 X-VirusChecked: Checked X-Env-Sender: daryl@level3.net X-Msg-Ref: server-3.tower-20.messagelabs.com!1191430148!28287982!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.106] Received: (qmail 18885 invoked from network); 3 Oct 2007 16:49:09 -0000 Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106) by server-3.tower-20.messagelabs.com with SMTP; 3 Oct 2007 16:49:09 -0000 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f10bb8-10 (Postfix) with ESMTP id 9B5104CBA; Wed, 3 Oct 2007 16:49:08 +0000 (GMT) Subject: RE: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 From: Daryl Malas To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0325771@GBNTHT12009MSX.gb002.siemens.net> References: <6918D1F7F8770C4FB182838A7BDFD6C80176355A@GSMDUBEX02.GSM.TLD> <0D5F89FAC29E2C41B98A6A762007F5D0325771@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain Date: Wed, 03 Oct 2007 10:56:00 -0600 Message-Id: <1191430561.1297.303.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.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: "Uzelac, Adam" , speermint@ietf.org, "Malas, Daryl" , Peterson, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Okay, although I have not responded yet, I have been reading all of these emails going back and forth. Let me see if I can suggest some updates to resolve some of the confusion. First, a Peer Network contains UA's. A transit or indirect peer contains UA's, but is used for indirect peering to other UA's in a terminating network not directly peered to the originating network. Second, the hierarchy is currently setup in the document to define SP first, and then SSP, ITSP, etc. This was intended to establish the hierarchy approach as described. I personally think the hierarchy should be: SP | SSP | Peer Network | | SSP(O) SSP(T) The reason for this, is from the SSP(O)'s perspective the SSP(T)'s network IS the terminating network, even if it is actually in-directly proxying the call to another peer beyond itself. SSP(T) is acting as an indirect peer in this case, but it IS still the terminating peer to the SSP(O). It is acting on behalf of the true SSP(T) by way of an agreed up relationship. The reason we included a definition of the indirect peer is to describe how this may take place when transiting a call to the true SSP(T) by way of the virtual SSP(T) --indirect peer. SSP(O) has NO relationship with the REAL SSP(T) that owns the intended UA. It only has a peering relationship with SSP(T). This is a confusing concept, and it required a lot of discussion in Montreal. I do not think there is an easy way to describe it in the terminology document, hence we use the term to describe the concept and not the business application. If we have not described the concept clearly enough, then I will adjust several of the definitions to help. --Daryl On Wed, 2007-10-03 at 14:19 +0100, Elwell, John wrote: > > > -----Original Message----- > > From: Dan Warren [mailto:DWarren@gsm.org] > > Sent: 03 October 2007 11:53 > > To: Elwell, John; Uzelac, Adam; Daryl Malas > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > speermint@ietf.org; Livingood, Jason > > Subject: RE: [Speermint] > > [wg-business]WGLCfordraft-ietf-speermint-terminology-12 > > > > > Dan, > > > > > > > How about a description? > > > > > > > > SP is operating at L3. > > > > SSP is operating at L5 (and hence L3 so is a specialised SP). > > > > Peer Network is an SSP with UA's. > > > > > > > > Clearly not a final proposal (there aren't enough words and > > > it doesn't > > > > include any exceptions to the rules - a good definition > > always has > > > > exceptions, right?), but maybe a starting point for you all > > > to dissect > > > > and destroy. > > > [JRE] OK, but in practice almost any SSP will be a Peer > > > Network (even if in certain use cases there is no UA > > > involved, e.g., when acting as an SSP(t)). So why do we need > > > the term Peer Network? I notice it is not used in the > > > architecture draft, although it is used in the consolidated > > > use cases draft. Why can't we stick to SSP? > > > > > > If we really need both terms, I don't believe the presence or > > > absence of UAs is an appropriate distinction. > > > > Should it then be presence or absence of subscribers/end users then? > > Taking the term 'peer' literally, it means 'at the same level' or > > 'equivalent'. SSP(O) and SSP(T) are equivalent networks as they are > > fulfilling the same functions (albeit potentially in > > different ways) for > > the same types of customers. SSP(t) is not a 'peer' of SSP(O) and > > SSP(T) because it is doing something distinctly different. I think I > > said once before, SSP(O) and SSP(T) are peering, SSP(t) is > > providing the > > capability and connectivity for the peering to take place. > [JRE] Even an SSP that acts as an SSP(t) is likely to have subscribers, > although they would not be involved in that particular case. Also the > term "subscriber" is not a SIP term and has connotations of charging - > not so applicable for enterprise peering. So I see "subscriber" as being > no better (perhaps worse) than "UA". Also an SSP(O) or SSP(T) can act on > behalf of a UA that is a gateway to PSTN, so there is no "subscriber" > (in the traditional sense) involved here. > Notwithstanding Otmar's comment, which I will address separately, I > guess an SSP becomes a Peering Network when it is acting on behalf of a > UA that has originated a SIP request that needs to be routed outside the > SSP or is the destination of a SIP request that has been received from > outside the SSP. Am I on the right track? > > I think we end up with the following hierarchy: > SP > | > SSP > | | > Peer SSP(t) > Network > | | > SSP(O) SSP(T) > > So SSP(O), SSP(T) and SSP(t) are specialisations of SSP, but Peer > Network is the particular grouping of SSP(O) and SSP(T). Assuming this > is what is intended, and assuming all these terms are required, their > definitions should reflect this hierarchy, e.g: > SSP(O): an SSP that for a particular SIP request behaviour> > SSP(T): an SSP that for a particular SIP request behaviour> > SSP(t): an SSP that for a particular SIP request behaviour> > Peer Network: an SSP that can behave as an SSP(O) and/or an SSP (T). > > John > > > > > Dan > > > > > > > > John > > > > > > > > > > Forthcoming GSMA Events: > > > > GSMA Mobile Asia Congress > > Macau > > 12 - 15 November 2007 > > www.mobileasiacongress.com > > > > GSMA Mobile World Congress > > Barcelona > > 11 - 14 February 2008 > > www.mobileworldcongress.com > > > > > > This email and its attachments are intended for the above > > named only and may be confidential. If they have come to you > > in error you must take no action based on them, nor must you > > copy or show them to anyone; please reply to this email or > > call +44 207 759 2300 and highlight the error > > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 04 03:44:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdLM4-0002rJ-M9; Thu, 04 Oct 2007 03:42:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdLM3-0002r6-Rx for speermint@ietf.org; Thu, 04 Oct 2007 03:42:43 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdLM2-0000da-Sw for speermint@ietf.org; Thu, 04 Oct 2007 03:42:43 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JPD00GB8MQ8SM@siemenscomms.co.uk> for speermint@ietf.org; Thu, 04 Oct 2007 08:42:09 +0100 (BST) Date: Thu, 04 Oct 2007 08:42:28 +0100 From: "Elwell, John" Subject: RE: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 In-reply-to: <1191430561.1297.303.camel@montag.eng.level3.com> To: Daryl Malas Message-id: <0D5F89FAC29E2C41B98A6A762007F5D03257F0@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Thread-Index: AcgF3X6+uc5JrnjlRtyAOT3ymg7diQAfElCw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <6918D1F7F8770C4FB182838A7BDFD6C80176355A@GSMDUBEX02.GSM.TLD> <0D5F89FAC29E2C41B98A6A762007F5D0325771@GBNTHT12009MSX.gb002.siemens.net> <1191430561.1297.303.camel@montag.eng.level3.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: "Uzelac, Adam" , Peterson@siemens.com, speermint@ietf.org, "Malas, Daryl" , "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl, I think I follow and agree with what you say, but I think in some places where you wrote "SSP(T)" you meant "SSP(t)" (i.e., the transit, not the terminating). Or are you implying that we should not use the term "SSP(t)", because the transit or intermediate SSP is really an SSP(T) (from the viewpoint of the real SSP(O)) and an SSP(O) (from the viewpoint of the real SSP(T))? John > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: 03 October 2007 17:56 > To: Elwell, John > Cc: Dan Warren; Uzelac, Adam; Malas, Daryl; > Peterson@siemens.com; dmm@1-4-5.net; speermint@ietf.org; > Livingood, Jason > Subject: RE: [Speermint] > [wg-business]WGLCfordraft-ietf-speermint-terminology-12 > > Okay, although I have not responded yet, I have been reading all of > these emails going back and forth. Let me see if I can suggest some > updates to resolve some of the confusion. > > First, a Peer Network contains UA's. A transit or indirect peer > contains UA's, but is used for indirect peering to other UA's in a > terminating network not directly peered to the originating network. > > Second, the hierarchy is currently setup in the document to define SP > first, and then SSP, ITSP, etc. This was intended to establish the > hierarchy approach as described. I personally think the hierarchy > should be: > > SP > | > SSP > | > Peer > Network > | | > SSP(O) SSP(T) > > The reason for this, is from the SSP(O)'s perspective the SSP(T)'s > network IS the terminating network, even if it is actually in-directly > proxying the call to another peer beyond itself. SSP(T) is > acting as an > indirect peer in this case, but it IS still the terminating > peer to the > SSP(O). It is acting on behalf of the true SSP(T) by way of an agreed > up relationship. The reason we included a definition of the indirect > peer is to describe how this may take place when transiting a call to > the true SSP(T) by way of the virtual SSP(T) --indirect peer. SSP(O) > has NO relationship with the REAL SSP(T) that owns the > intended UA. It > only has a peering relationship with SSP(T). > > This is a confusing concept, and it required a lot of discussion in > Montreal. I do not think there is an easy way to describe it in the > terminology document, hence we use the term to describe the > concept and > not the business application. If we have not described the concept > clearly enough, then I will adjust several of the definitions to help. > > --Daryl > > On Wed, 2007-10-03 at 14:19 +0100, Elwell, John wrote: > > > > > -----Original Message----- > > > From: Dan Warren [mailto:DWarren@gsm.org] > > > Sent: 03 October 2007 11:53 > > > To: Elwell, John; Uzelac, Adam; Daryl Malas > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > > speermint@ietf.org; Livingood, Jason > > > Subject: RE: [Speermint] > > > [wg-business]WGLCfordraft-ietf-speermint-terminology-12 > > > > > > > Dan, > > > > > > > > > How about a description? > > > > > > > > > > SP is operating at L3. > > > > > SSP is operating at L5 (and hence L3 so is a specialised SP). > > > > > Peer Network is an SSP with UA's. > > > > > > > > > > Clearly not a final proposal (there aren't enough words and > > > > it doesn't > > > > > include any exceptions to the rules - a good definition > > > always has > > > > > exceptions, right?), but maybe a starting point for you all > > > > to dissect > > > > > and destroy. > > > > [JRE] OK, but in practice almost any SSP will be a Peer > > > > Network (even if in certain use cases there is no UA > > > > involved, e.g., when acting as an SSP(t)). So why do we need > > > > the term Peer Network? I notice it is not used in the > > > > architecture draft, although it is used in the consolidated > > > > use cases draft. Why can't we stick to SSP? > > > > > > > > If we really need both terms, I don't believe the presence or > > > > absence of UAs is an appropriate distinction. > > > > > > Should it then be presence or absence of subscribers/end > users then? > > > Taking the term 'peer' literally, it means 'at the same level' or > > > 'equivalent'. SSP(O) and SSP(T) are equivalent networks > as they are > > > fulfilling the same functions (albeit potentially in > > > different ways) for > > > the same types of customers. SSP(t) is not a 'peer' of SSP(O) and > > > SSP(T) because it is doing something distinctly > different. I think I > > > said once before, SSP(O) and SSP(T) are peering, SSP(t) is > > > providing the > > > capability and connectivity for the peering to take place. > > [JRE] Even an SSP that acts as an SSP(t) is likely to have > subscribers, > > although they would not be involved in that particular > case. Also the > > term "subscriber" is not a SIP term and has connotations of > charging - > > not so applicable for enterprise peering. So I see > "subscriber" as being > > no better (perhaps worse) than "UA". Also an SSP(O) or > SSP(T) can act on > > behalf of a UA that is a gateway to PSTN, so there is no > "subscriber" > > (in the traditional sense) involved here. > > Notwithstanding Otmar's comment, which I will address separately, I > > guess an SSP becomes a Peering Network when it is acting on > behalf of a > > UA that has originated a SIP request that needs to be > routed outside the > > SSP or is the destination of a SIP request that has been > received from > > outside the SSP. Am I on the right track? > > > > I think we end up with the following hierarchy: > > SP > > | > > SSP > > | | > > Peer SSP(t) > > Network > > | | > > SSP(O) SSP(T) > > > > So SSP(O), SSP(T) and SSP(t) are specialisations of SSP, but Peer > > Network is the particular grouping of SSP(O) and SSP(T). > Assuming this > > is what is intended, and assuming all these terms are > required, their > > definitions should reflect this hierarchy, e.g: > > SSP(O): an SSP that for a particular SIP request > behaviour> > > SSP(T): an SSP that for a particular SIP request > behaviour> > > SSP(t): an SSP that for a particular SIP request > behaviour> > > Peer Network: an SSP that can behave as an SSP(O) and/or an SSP (T). > > > > John > > > > > > > > Dan > > > > > > > > > > > John > > > > > > > > > > > > > > Forthcoming GSMA Events: > > > > > > GSMA Mobile Asia Congress > > > Macau > > > 12 - 15 November 2007 > > > www.mobileasiacongress.com > > > > > > GSMA Mobile World Congress > > > Barcelona > > > 11 - 14 February 2008 > > > www.mobileworldcongress.com > > > > > > > > > This email and its attachments are intended for the above > > > named only and may be confidential. If they have come to you > > > in error you must take no action based on them, nor must you > > > copy or show them to anyone; please reply to this email or > > > call +44 207 759 2300 and highlight the error > > > > > > > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 04 11:01:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdSAS-0000zD-M1; Thu, 04 Oct 2007 10:59:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdSAR-0000vg-MP for speermint@ietf.org; Thu, 04 Oct 2007 10:59:11 -0400 Received: from mail20.messagelabs.com ([216.82.245.67]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IdSAG-0001te-RD for speermint@ietf.org; Thu, 04 Oct 2007 10:59:01 -0400 X-VirusChecked: Checked X-Env-Sender: daryl@level3.net X-Msg-Ref: server-6.tower-20.messagelabs.com!1191509938!40725005!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.106] Received: (qmail 28383 invoked from network); 4 Oct 2007 14:58:58 -0000 Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106) by server-6.tower-20.messagelabs.com with SMTP; 4 Oct 2007 14:58:58 -0000 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f10bb8-10 (Postfix) with ESMTP id 6F0B24CB5; Thu, 4 Oct 2007 14:58:58 +0000 (GMT) Subject: RE: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 From: Daryl Malas To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D03257F0@GBNTHT12009MSX.gb002.siemens.net> References: <6918D1F7F8770C4FB182838A7BDFD6C80176355A@GSMDUBEX02.GSM.TLD> <0D5F89FAC29E2C41B98A6A762007F5D0325771@GBNTHT12009MSX.gb002.siemens.net> <1191430561.1297.303.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D03257F0@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain Date: Thu, 04 Oct 2007 09:05:54 -0600 Message-Id: <1191510354.1297.305.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.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: "Uzelac, Adam" , Peterson@siemens.com, speermint@ietf.org, "Malas, Daryl" , "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Thu, 2007-10-04 at 08:42 +0100, Elwell, John wrote: > Daryl, > > I think I follow and agree with what you say, but I think in some places > where you wrote "SSP(T)" you meant "SSP(t)" (i.e., the transit, not the > terminating). > > Or are you implying that we should not use the term "SSP(t)", because > the transit or intermediate SSP is really an SSP(T) (from the viewpoint > of the real SSP(O)) and an SSP(O) (from the viewpoint of the real > SSP(T))? > This is exactly what I am implying. > John > > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: 03 October 2007 17:56 > > To: Elwell, John > > Cc: Dan Warren; Uzelac, Adam; Malas, Daryl; > > Peterson@siemens.com; dmm@1-4-5.net; speermint@ietf.org; > > Livingood, Jason > > Subject: RE: [Speermint] > > [wg-business]WGLCfordraft-ietf-speermint-terminology-12 > > > > Okay, although I have not responded yet, I have been reading all of > > these emails going back and forth. Let me see if I can suggest some > > updates to resolve some of the confusion. > > > > First, a Peer Network contains UA's. A transit or indirect peer > > contains UA's, but is used for indirect peering to other UA's in a > > terminating network not directly peered to the originating network. > > > > Second, the hierarchy is currently setup in the document to define SP > > first, and then SSP, ITSP, etc. This was intended to establish the > > hierarchy approach as described. I personally think the hierarchy > > should be: > > > > SP > > | > > SSP > > | > > Peer > > Network > > | | > > SSP(O) SSP(T) > > > > The reason for this, is from the SSP(O)'s perspective the SSP(T)'s > > network IS the terminating network, even if it is actually in-directly > > proxying the call to another peer beyond itself. SSP(T) is > > acting as an > > indirect peer in this case, but it IS still the terminating > > peer to the > > SSP(O). It is acting on behalf of the true SSP(T) by way of an agreed > > up relationship. The reason we included a definition of the indirect > > peer is to describe how this may take place when transiting a call to > > the true SSP(T) by way of the virtual SSP(T) --indirect peer. SSP(O) > > has NO relationship with the REAL SSP(T) that owns the > > intended UA. It > > only has a peering relationship with SSP(T). > > > > This is a confusing concept, and it required a lot of discussion in > > Montreal. I do not think there is an easy way to describe it in the > > terminology document, hence we use the term to describe the > > concept and > > not the business application. If we have not described the concept > > clearly enough, then I will adjust several of the definitions to help. > > > > --Daryl > > > > On Wed, 2007-10-03 at 14:19 +0100, Elwell, John wrote: > > > > > > > -----Original Message----- > > > > From: Dan Warren [mailto:DWarren@gsm.org] > > > > Sent: 03 October 2007 11:53 > > > > To: Elwell, John; Uzelac, Adam; Daryl Malas > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; > > > > speermint@ietf.org; Livingood, Jason > > > > Subject: RE: [Speermint] > > > > [wg-business]WGLCfordraft-ietf-speermint-terminology-12 > > > > > > > > > Dan, > > > > > > > > > > > How about a description? > > > > > > > > > > > > SP is operating at L3. > > > > > > SSP is operating at L5 (and hence L3 so is a specialised SP). > > > > > > Peer Network is an SSP with UA's. > > > > > > > > > > > > Clearly not a final proposal (there aren't enough words and > > > > > it doesn't > > > > > > include any exceptions to the rules - a good definition > > > > always has > > > > > > exceptions, right?), but maybe a starting point for you all > > > > > to dissect > > > > > > and destroy. > > > > > [JRE] OK, but in practice almost any SSP will be a Peer > > > > > Network (even if in certain use cases there is no UA > > > > > involved, e.g., when acting as an SSP(t)). So why do we need > > > > > the term Peer Network? I notice it is not used in the > > > > > architecture draft, although it is used in the consolidated > > > > > use cases draft. Why can't we stick to SSP? > > > > > > > > > > If we really need both terms, I don't believe the presence or > > > > > absence of UAs is an appropriate distinction. > > > > > > > > Should it then be presence or absence of subscribers/end > > users then? > > > > Taking the term 'peer' literally, it means 'at the same level' or > > > > 'equivalent'. SSP(O) and SSP(T) are equivalent networks > > as they are > > > > fulfilling the same functions (albeit potentially in > > > > different ways) for > > > > the same types of customers. SSP(t) is not a 'peer' of SSP(O) and > > > > SSP(T) because it is doing something distinctly > > different. I think I > > > > said once before, SSP(O) and SSP(T) are peering, SSP(t) is > > > > providing the > > > > capability and connectivity for the peering to take place. > > > [JRE] Even an SSP that acts as an SSP(t) is likely to have > > subscribers, > > > although they would not be involved in that particular > > case. Also the > > > term "subscriber" is not a SIP term and has connotations of > > charging - > > > not so applicable for enterprise peering. So I see > > "subscriber" as being > > > no better (perhaps worse) than "UA". Also an SSP(O) or > > SSP(T) can act on > > > behalf of a UA that is a gateway to PSTN, so there is no > > "subscriber" > > > (in the traditional sense) involved here. > > > Notwithstanding Otmar's comment, which I will address separately, I > > > guess an SSP becomes a Peering Network when it is acting on > > behalf of a > > > UA that has originated a SIP request that needs to be > > routed outside the > > > SSP or is the destination of a SIP request that has been > > received from > > > outside the SSP. Am I on the right track? > > > > > > I think we end up with the following hierarchy: > > > SP > > > | > > > SSP > > > | | > > > Peer SSP(t) > > > Network > > > | | > > > SSP(O) SSP(T) > > > > > > So SSP(O), SSP(T) and SSP(t) are specialisations of SSP, but Peer > > > Network is the particular grouping of SSP(O) and SSP(T). > > Assuming this > > > is what is intended, and assuming all these terms are > > required, their > > > definitions should reflect this hierarchy, e.g: > > > SSP(O): an SSP that for a particular SIP request > > behaviour> > > > SSP(T): an SSP that for a particular SIP request > > behaviour> > > > SSP(t): an SSP that for a particular SIP request > > behaviour> > > > Peer Network: an SSP that can behave as an SSP(O) and/or an SSP (T). > > > > > > John > > > > > > > > > > > Dan > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > Forthcoming GSMA Events: > > > > > > > > GSMA Mobile Asia Congress > > > > Macau > > > > 12 - 15 November 2007 > > > > www.mobileasiacongress.com > > > > > > > > GSMA Mobile World Congress > > > > Barcelona > > > > 11 - 14 February 2008 > > > > www.mobileworldcongress.com > > > > > > > > > > > > This email and its attachments are intended for the above > > > > named only and may be confidential. If they have come to you > > > > in error you must take no action based on them, nor must you > > > > copy or show them to anyone; please reply to this email or > > > > call +44 207 759 2300 and highlight the error > > > > > > > > > > > > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 04 21:36:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idc4d-0000Fp-AJ; Thu, 04 Oct 2007 21:33:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idc4c-0000CN-HO; Thu, 04 Oct 2007 21:33:50 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Idc4b-00083i-Tg; Thu, 04 Oct 2007 21:33:50 -0400 Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l951XMlC017923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Oct 2007 18:33:31 -0700 From: "Richard Shockey" To: , Date: Thu, 4 Oct 2007 21:31:44 -0400 Message-ID: <047301c806ef$8294f650$87bee2f0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgG73xvlvmFOVwrSta7zBc9QnPNgg== Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Subject: [Speermint] I'd like to guage interest in restarting a BOF on the subject of Peppermint. X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 time last year I tried to start up a BOF on some of the ongoing provisioning issues between various forms of ENUM registries and network entities. I've had a few folks ask what ever happened to that. I still think there is a strong need to do this and the work could have relevance if the scope were expanded not to be just service provider to registry but also PBX to registries as well. I'd like to test the water to see if there is any interest in doing this in Vancouver. The original BOF proposal was this: Comments as usual are welcome Peppermint BOF Provisioning Extensions in Peering Registries for Multimedia Intererconnection. Mailing Lists: BOF chairs: Richard Shockey [rich.shockey@neustar.biz] Temporary Area Directorate: Real Time Applications (RAI) Ultimate Area Directorate: TBD BOF Purpose. The ENUM and SPEERMINT working groups are working on various aspects of Multi Media Interconnection. ENUM is specifically chartered to develop protocols that involve the translation of E.164 numbers to URI's. SPEERMINT has been chartered to develop best current practices among real-time application service providers and how such services interconnect across domain boundaries. It is clear from discussions in both working groups that Multi-Media Interconnection will require various forms of data to be exchanged among administrative domains outside the normal scope of establishing a SIP session. Such data exchanges might be provisioning of various forms of Registries containing mappings of phone numbers to URI, policies surrounding the admission to points of network interconnection and the distribution of Registry data to various types of databases. The purpose of the BOF is to determine the need and scope for such data exchanges, what existing protocols need to be adapted to meet those needs and the appropriate schema and queries are needed to facilitate such exchanges. The IETF has in the past done significant work on data exchanges among various administrative entities. In particular the PROVREG working group developed various schema and query mechanisms to facilitate the exchange of data among domain name registries and registrars. The ENUM Working group has adapted PROVREG working group protocols to develop RFC 4114, which facilitates the provisioning of ENUM data in the DNS tree. However, there has been little adoption of RFC 4114, and many of the participants of the SPEERMINT working group require both data models and protocol features not found in RFC 4114. The proposed PEPPERMINT working group will build upon the knowledge gained from those efforts, and the intent of this proposed working group is to find a provisioning solution for peering as defined by SPEERMINT. The final work product(s) from this working group will be based upon XML. Additionally, bias will be given to re-using either EPP, HTTP/REST, HTTP/XML-RPC, or HTTP/SOAP. Proposed Deliverables Requirements for SPEERMINT data exchange. Provisioning of SPEERMINT data registries. Provisioning of SPEERMINT/ENUM data caches. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 08 04:58:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeoPZ-0007FZ-6s; Mon, 08 Oct 2007 04:56:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeoPY-0007CY-Qo for speermint@ietf.org; Mon, 08 Oct 2007 04:56:24 -0400 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeoPS-00070B-Ua for speermint@ietf.org; Mon, 08 Oct 2007 04:56:19 -0400 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1IeoMN-0001cX-00; Mon, 08 Oct 2007 10:53:07 +0200 Date: Mon, 8 Oct 2007 10:53:07 +0200 From: Otmar Lendl To: "Elwell, John" Subject: Re: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Message-ID: <20071008085307.GB6165@nic.at> Mail-Followup-To: Otmar Lendl , "Elwell, John" , speermint@ietf.org References: <6918D1F7F8770C4FB182838A7BDFD6C801763543@GSMDUBEX02.GSM.TLD> <0D5F89FAC29E2C41B98A6A762007F5D032574A@GBNTHT12009MSX.gb002.siemens.net> <20071003120559.GA627@nic.at> <0D5F89FAC29E2C41B98A6A762007F5D0325772@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0325772@GBNTHT12009MSX.gb002.siemens.net> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 2007/10/03 15:10, "Elwell, John" wrote: > Otmar, John, > > I understand your point (and the point you made in your previous > posting). I think the concept of indirect peering was formulated before > I got actively involved in SPEERMINT, so I don't want to destabilise > that work. Feel free to join in the fun. As the terminology work seems to prejudice some aspects of the final architecture, any input now is welcome. > However, I do have some sympathy for what you say. Consider the following case > > UA --- Enterprise --- Carrier --- Carrier --- Enterprise --- UA > A B C D E F > > UA A on enterprise B makes a request to UA F on enterprise E. Enterprise > B sends all its requests to non-direct-peering domains via carrier C. > Enterprise E receives all its requests from non-direct-peering domains > via carrier E. According to the SPEERMINT concept of peering, Enterprise > B is peering with Enterprise E. Carrier C is not peering with Carrier D > or with Enterprise B. Carrier D is not peering with carrier C or with > Enterprise F. So in this case, Carrier C and Carrier D are not Peering > Networks. I am not sure this is a correct view. According to the currect definitions, this seems to be correct. > I understand that your > view would be that Enterprise B is peering with Carrier C, Carrier C is > peering with Carrier D, etc.. In the strict sense of the word, the peering would be just between C and D. B-C and D-E might use the same protocol features for their interconnect, but this is not a "meeting of peers", but likely a customer-supplier interaction. Just replace SIP by BGP: B-C and D-E becomes "IP upstream/downstream" and only C-D is called "peering". The difference is more on the commercial side than on the technical side (all three interfaces use BGP as the protocol). We do protocol design here, thus we need no concern ourselves with that distincion. /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 08 05:24:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieooz-0006iS-HY; Mon, 08 Oct 2007 05:22:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieooy-0006iN-HB for speermint@ietf.org; Mon, 08 Oct 2007 05:22:40 -0400 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ieooy-0007lQ-3T for speermint@ietf.org; Mon, 08 Oct 2007 05:22:40 -0400 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1Ieoox-0001dK-00 for ; Mon, 08 Oct 2007 11:22:39 +0200 Date: Mon, 8 Oct 2007 11:22:39 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 Message-ID: <20071008092239.GC6165@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <6918D1F7F8770C4FB182838A7BDFD6C80176355A@GSMDUBEX02.GSM.TLD> <0D5F89FAC29E2C41B98A6A762007F5D0325771@GBNTHT12009MSX.gb002.siemens.net> <1191430561.1297.303.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D03257F0@GBNTHT12009MSX.gb002.siemens.net> <1191510354.1297.305.camel@montag.eng.level3.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1191510354.1297.305.camel@montag.eng.level3.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/10/04 17:10, Daryl Malas wrote: > On Thu, 2007-10-04 at 08:42 +0100, Elwell, John wrote: > > Daryl, > > > > I think I follow and agree with what you say, but I think in some places > > where you wrote "SSP(T)" you meant "SSP(t)" (i.e., the transit, not the > > terminating). > > > > Or are you implying that we should not use the term "SSP(t)", because > > the transit or intermediate SSP is really an SSP(T) (from the viewpoint > > of the real SSP(O)) and an SSP(O) (from the viewpoint of the real > > SSP(T))? > > > This is exactly what I am implying. Ok, then do I get this right: In a scenario like SSP(O) - SSP(t) - SSP(T) the indirect peering is between SSP(O) and SSP(t)? Could you clarify |4.2.2. Indirect Peering | | Indirect, or transit, peering refers to the establishment of either a | signaling and media path or signaling path alone via one (or more) | referral or transit network(s). In this case it is generally required | that a trust relationship is established between the originating | service provider and the transit network on one side, and the transit | network and the termination network on the other side. in order to make this explicit? /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 09 11:29:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGzp-0006aY-Dp; Tue, 09 Oct 2007 11:27:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGzo-0006El-82 for speermint@ietf.org; Tue, 09 Oct 2007 11:27:44 -0400 Received: from mail28.messagelabs.com ([216.82.249.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IfGzb-0002vL-0t for speermint@ietf.org; Tue, 09 Oct 2007 11:27:37 -0400 X-VirusChecked: Checked X-Env-Sender: daryl@level3.net X-Msg-Ref: server-10.tower-28.messagelabs.com!1191943632!45860831!3 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.106] Received: (qmail 12795 invoked from network); 9 Oct 2007 15:27:14 -0000 Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106) by server-10.tower-28.messagelabs.com with SMTP; 9 Oct 2007 15:27:14 -0000 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f10bb8-10 (Postfix) with ESMTP id CE8984CB6; Tue, 9 Oct 2007 15:27:13 +0000 (GMT) Subject: Re: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12 From: Daryl Malas To: Otmar Lendl In-Reply-To: <20071008092239.GC6165@nic.at> References: <6918D1F7F8770C4FB182838A7BDFD6C80176355A@GSMDUBEX02.GSM.TLD> <0D5F89FAC29E2C41B98A6A762007F5D0325771@GBNTHT12009MSX.gb002.siemens.net> <1191430561.1297.303.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D03257F0@GBNTHT12009MSX.gb002.siemens.net> <1191510354.1297.305.camel@montag.eng.level3.com> <20071008092239.GC6165@nic.at> Content-Type: text/plain Date: Tue, 09 Oct 2007 09:34:29 -0600 Message-Id: <1191944069.1297.313.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.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Yes, I will update 4.2.2 (Comment inline.). On Mon, 2007-10-08 at 11:22 +0200, Otmar Lendl wrote: > On 2007/10/04 17:10, Daryl Malas wrote: > > On Thu, 2007-10-04 at 08:42 +0100, Elwell, John wrote: > > > Daryl, > > > > > > I think I follow and agree with what you say, but I think in some places > > > where you wrote "SSP(T)" you meant "SSP(t)" (i.e., the transit, not the > > > terminating). > > > > > > Or are you implying that we should not use the term "SSP(t)", because > > > the transit or intermediate SSP is really an SSP(T) (from the viewpoint > > > of the real SSP(O)) and an SSP(O) (from the viewpoint of the real > > > SSP(T))? > > > > > This is exactly what I am implying. > > Ok, then do I get this right: In a scenario like > > SSP(O) - SSP(t) - SSP(T) > > the indirect peering is between SSP(O) and SSP(t)? Yes > > Could you clarify > > |4.2.2. Indirect Peering > | > | Indirect, or transit, peering refers to the establishment of either a > | signaling and media path or signaling path alone via one (or more) > | referral or transit network(s). In this case it is generally required > | that a trust relationship is established between the originating > | service provider and the transit network on one side, and the transit > | network and the termination network on the other side. > > in order to make this explicit? > > /ol _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 10 12:19:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfeFX-0003Vl-7B; Wed, 10 Oct 2007 12:17:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfeFV-0003RI-8K; Wed, 10 Oct 2007 12:17:29 -0400 Received: from mail.xconnect.net ([213.187.46.35] helo=xconnect.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfeFI-0007Kr-BD; Wed, 10 Oct 2007 12:17: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] I'd like to guage interest in restarting a BOF on thesubject of Peppermint. Date: Wed, 10 Oct 2007 17:16:42 +0100 Message-ID: <062B8EE81F2EC945A577C3EFAE1DD68E89571C@mail.xconnect.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I'd like to guage interest in restarting a BOF on thesubject of Peppermint. Thread-Index: AcgG73xvlvmFOVwrSta7zBc9QnPNggEZjYdw References: <047301c806ef$8294f650$87bee2f0$@us> From: "Eli Katz" To: "Richard Shockey" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I concur with Rich, in that any efforts to help standardisation of SP Registry Provisioning will be useful to the telecom industry.=20 The lack of a commonly used (standards based or other) methodology is currently hindering take up of industry-demanded registry-based interconnection. Eli Eli Katz Founder & CEO XConnect - Bridging the VoIP Islands T : +44 (0) 870 794 1100 F : +44 (0) 870 794 1101 M : +44 (0) 7973 632 364 eli@xconnect.net www.xconnect.net=20 -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: 05 October 2007 02:32 To: enum@ietf.org; speermint@ietf.org Subject: [Speermint] I'd like to guage interest in restarting a BOF on thesubject of Peppermint. This time last year I tried to start up a BOF on some of the ongoing provisioning issues between various forms of ENUM registries and network entities. I've had a few folks ask what ever happened to that. I still think there is a strong need to do this and the work could have relevance if the scope were expanded not to be just service provider to registry but also PBX to registries as well. I'd like to test the water to see if there is any interest in doing this in Vancouver. The original BOF proposal was this: Comments as usual are welcome Peppermint BOF Provisioning Extensions in Peering Registries for Multimedia Intererconnection. Mailing Lists: BOF chairs: Richard Shockey [rich.shockey@neustar.biz] Temporary Area Directorate: Real Time Applications (RAI) Ultimate Area Directorate: TBD BOF Purpose. The ENUM and SPEERMINT working groups are working on various aspects of Multi Media Interconnection. ENUM is specifically chartered to develop protocols that involve the translation of E.164 numbers to URI's. =20 SPEERMINT has been chartered to develop best current practices among real-time application service providers and how such services interconnect across domain boundaries. It is clear from discussions in both working groups that Multi-Media Interconnection will require various forms of data to be exchanged among administrative domains outside the normal scope of establishing a SIP session. Such data exchanges might be provisioning of various forms of Registries containing mappings of phone numbers to URI, policies surrounding the admission to points of network interconnection and the distribution of Registry data to various types of databases. The purpose of the BOF is to determine the need and scope for such data exchanges, what existing protocols need to be adapted to meet those needs and the appropriate schema and queries are needed to facilitate such exchanges. The IETF has in the past done significant work on data exchanges among various administrative entities. In particular the PROVREG working group developed various schema and query mechanisms to facilitate the exchange of data among domain name registries and registrars. The ENUM Working group has adapted PROVREG working group protocols to develop RFC 4114, which facilitates the provisioning of ENUM data in the DNS tree. However, there has been little adoption of RFC 4114, and many of the participants of the SPEERMINT working group require both data models and protocol features not found in RFC 4114. The proposed PEPPERMINT working group will build upon the knowledge gained from those efforts, and the intent of this proposed working group is to find a provisioning solution for peering as defined by SPEERMINT. The final work product(s) from this working group will be based upon XML. =20 Additionally, bias will be given to re-using either EPP, HTTP/REST, HTTP/XML-RPC, or HTTP/SOAP. Proposed Deliverables Requirements for SPEERMINT data exchange. Provisioning of SPEERMINT data registries. Provisioning of SPEERMINT/ENUM data caches. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 10 12:33:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfeUH-0005wP-24; Wed, 10 Oct 2007 12:32:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfeUG-0005wF-F0 for speermint@ietf.org; Wed, 10 Oct 2007 12:32:44 -0400 Received: from mail164.messagelabs.com ([216.82.253.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IfeUA-0007oe-Qj for speermint@ietf.org; Wed, 10 Oct 2007 12:32:44 -0400 X-VirusChecked: Checked X-Env-Sender: daryl@level3.net X-Msg-Ref: server-9.tower-164.messagelabs.com!1192033948!13159655!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.106] Received: (qmail 11150 invoked from network); 10 Oct 2007 16:32:28 -0000 Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106) by server-9.tower-164.messagelabs.com with SMTP; 10 Oct 2007 16:32:28 -0000 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f10bb8-10 (Postfix) with ESMTP id 2DD2F4CB2 for ; Wed, 10 Oct 2007 16:32:28 +0000 (GMT) Subject: [Speermint] WGLC draft-ietf-speermint-terminology-12 From: Daryl Malas To: speermint@ietf.org Content-Type: text/plain Date: Wed, 10 Oct 2007 10:39:47 -0600 Message-Id: <1192034387.1297.318.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org It looks to me the final discussions have died down. I'm going to make a revision to the draft incorporating the comments from the list, John, and Otmar. I will post the draft on another website for further discussion before I submit it. Look for a revision in the next two weeks. Thanks for all of the feedback. --Daryl _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 11 10:46:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfzHZ-0005us-C1; Thu, 11 Oct 2007 10:45:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfzHY-0004Zh-1l; Thu, 11 Oct 2007 10:45:00 -0400 Received: from mail28.messagelabs.com ([216.82.249.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IfzHN-0004uo-Os; Thu, 11 Oct 2007 10:44:56 -0400 X-VirusChecked: Checked X-Env-Sender: daryl@level3.net X-Msg-Ref: server-17.tower-28.messagelabs.com!1192113867!52720733!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.107] Received: (qmail 10653 invoked from network); 11 Oct 2007 14:44:27 -0000 Received: from unknown.level3.net (HELO f10cc8-10.level3.com) (209.245.18.107) by server-17.tower-28.messagelabs.com with SMTP; 11 Oct 2007 14:44:27 -0000 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f10cc8-10.level3.com (Postfix) with ESMTP id 6670D2DC9; Thu, 11 Oct 2007 14:44:27 +0000 (GMT) Subject: Re: [Speermint] I'd like to guage interest in restarting a BOF on the subject of Peppermint. From: Daryl Malas To: Richard Shockey In-Reply-To: <047301c806ef$8294f650$87bee2f0$@us> References: <047301c806ef$8294f650$87bee2f0$@us> Content-Type: text/plain Date: Thu, 11 Oct 2007 08:51:50 -0600 Message-Id: <1192114310.1297.322.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: enum@ietf.org, 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 IMO, I believe this is warranted, but I do not think we are ready for it yet. I suspect this will be of a lot more interest in this BOF in about 1 year, after several of the SPEERMINT milestones are completed. Daryl On Thu, 2007-10-04 at 21:31 -0400, Richard Shockey wrote: > This time last year I tried to start up a BOF on some of the ongoing > provisioning issues between various forms of ENUM registries and network > entities. I've had a few folks ask what ever happened to that. I still think > there is a strong need to do this and the work could have relevance if the > scope were expanded not to be just service provider to registry but also PBX > to registries as well. > > I'd like to test the water to see if there is any interest in doing this in > Vancouver. > > > The original BOF proposal was this: > > Comments as usual are welcome > > > Peppermint BOF > > Provisioning Extensions in Peering Registries for Multimedia > Intererconnection. > > Mailing Lists: > > BOF chairs: > > Richard Shockey [rich.shockey@neustar.biz] > > Temporary Area Directorate: Real Time Applications (RAI) > > Ultimate Area Directorate: TBD > > > BOF Purpose. > > The ENUM and SPEERMINT working groups are working on various aspects of > Multi Media Interconnection. ENUM is specifically chartered to develop > protocols that involve the translation of E.164 numbers to URI's. > SPEERMINT has been chartered to develop best current practices among > real-time application service providers and how such services interconnect > across domain boundaries. > > It is clear from discussions in both working groups that Multi-Media > Interconnection will require various forms of data to be exchanged among > administrative domains outside the normal scope of establishing a SIP > session. > > Such data exchanges might be provisioning of various forms of Registries > containing mappings of phone numbers to URI, policies surrounding the > admission to points of network interconnection and the distribution of > Registry data to various types of databases. > > The purpose of the BOF is to determine the need and scope for such data > exchanges, what existing protocols need to be adapted to meet those needs > and the appropriate schema and queries are needed to facilitate such > exchanges. > > The IETF has in the past done significant work on data exchanges among > various administrative entities. In particular the PROVREG working group > developed various schema and query mechanisms to facilitate the exchange of > data among domain name registries and registrars. > > The ENUM Working group has adapted PROVREG working group protocols to > develop RFC 4114, which facilitates the provisioning of ENUM data in the DNS > tree. However, there has been little adoption of RFC 4114, and many of the > participants of the SPEERMINT working group require both data models and > protocol features not found in RFC 4114. > > The proposed PEPPERMINT working group will build upon the knowledge gained > from those efforts, and the intent of this proposed working group is to find > a provisioning solution for peering as defined by SPEERMINT. The final work > product(s) from this working group will be based upon XML. > > Additionally, > bias will be given to re-using either EPP, HTTP/REST, HTTP/XML-RPC, or > HTTP/SOAP. > > Proposed Deliverables > > Requirements for SPEERMINT data exchange. > > Provisioning of SPEERMINT data registries. > > Provisioning of SPEERMINT/ENUM data caches. > > Richard Shockey > Director, Member of the Technical Staff > NeuStar > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org > PSTN Office +1 571.434.5651 > PSTN Mobile: +1 703.593.2683 > > > > > > > _______________________________________________ > Speermint mailing 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 Oct 12 08:48:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgJu5-0001BU-4n; Fri, 12 Oct 2007 08:46:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgJu4-0001BD-1D; Fri, 12 Oct 2007 08:46:08 -0400 Received: from pacdcimo02.cable.comcast.com ([24.40.8.146]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgJu3-0002tq-BI; Fri, 12 Oct 2007 08:46:07 -0400 Received: from ([10.52.116.30]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.12553149; Fri, 12 Oct 2007 08:45:44 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 08:45:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: [Speermint] I'd like to guage interest in restarting aBOF on the subject of Peppermint. Date: Fri, 12 Oct 2007 08:45:57 -0400 Message-ID: <45AEC6EF95942140888406588E1A660202D8FBDE@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <1192114310.1297.322.camel@montag.eng.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Re: [Speermint] I'd like to guage interest in restarting aBOF on the subject of Peppermint. Thread-Index: AcgMFicLMUUpmr9ASp2sz3u5Ax1VTgAt6b1A References: <047301c806ef$8294f650$87bee2f0$@us> <1192114310.1297.322.camel@montag.eng.level3.com> From: "Creighton, Tom" To: "Daryl Malas" , "Richard Shockey" X-OriginalArrivalTime: 12 Oct 2007 12:45:44.0614 (UTC) FILETIME=[CE20BC60:01C80CCD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: enum@ietf.org, 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 disagree. This work needs to begin immediately so that in a year from now we might actually have working code. Tom > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Thursday, October 11, 2007 10:52 > To: Richard Shockey > Cc: enum@ietf.org; speermint@ietf.org > Subject: [Enum] Re: [Speermint] I'd like to guage interest in restarting > aBOF on the subject of Peppermint. >=20 > IMO, I believe this is warranted, but I do not think we are ready for it > yet. I suspect this will be of a lot more interest in this BOF in about > 1 year, after several of the SPEERMINT milestones are completed. >=20 > Daryl >=20 > On Thu, 2007-10-04 at 21:31 -0400, Richard Shockey wrote: > > This time last year I tried to start up a BOF on some of the ongoing > > provisioning issues between various forms of ENUM registries and network > > entities. I've had a few folks ask what ever happened to that. I still > think > > there is a strong need to do this and the work could have relevance if > the > > scope were expanded not to be just service provider to registry but also > PBX > > to registries as well. > > > > I'd like to test the water to see if there is any interest in doing this > in > > Vancouver. > > > > > > The original BOF proposal was this: > > > > Comments as usual are welcome > > > > > > Peppermint BOF > > > > Provisioning Extensions in Peering Registries for Multimedia > > Intererconnection. > > > > Mailing Lists: > > > > BOF chairs: > > > > Richard Shockey [rich.shockey@neustar.biz] > > > > Temporary Area Directorate: Real Time Applications (RAI) > > > > Ultimate Area Directorate: TBD > > > > > > BOF Purpose. > > > > The ENUM and SPEERMINT working groups are working on various aspects of > > Multi Media Interconnection. ENUM is specifically chartered to develop > > protocols that involve the translation of E.164 numbers to URI's. > > SPEERMINT has been chartered to develop best current practices among > > real-time application service providers and how such services > interconnect > > across domain boundaries. > > > > It is clear from discussions in both working groups that Multi-Media > > Interconnection will require various forms of data to be exchanged among > > administrative domains outside the normal scope of establishing a SIP > > session. > > > > Such data exchanges might be provisioning of various forms of Registries > > containing mappings of phone numbers to URI, policies surrounding the > > admission to points of network interconnection and the distribution of > > Registry data to various types of databases. > > > > The purpose of the BOF is to determine the need and scope for such data > > exchanges, what existing protocols need to be adapted to meet those > needs > > and the appropriate schema and queries are needed to facilitate such > > exchanges. > > > > The IETF has in the past done significant work on data exchanges among > > various administrative entities. In particular the PROVREG working group > > developed various schema and query mechanisms to facilitate the exchange > of > > data among domain name registries and registrars. > > > > The ENUM Working group has adapted PROVREG working group protocols to > > develop RFC 4114, which facilitates the provisioning of ENUM data in the > DNS > > tree. However, there has been little adoption of RFC 4114, and many of > the > > participants of the SPEERMINT working group require both data models and > > protocol features not found in RFC 4114. > > > > The proposed PEPPERMINT working group will build upon the knowledge > gained > > from those efforts, and the intent of this proposed working group is to > find > > a provisioning solution for peering as defined by SPEERMINT. The final > work > > product(s) from this working group will be based upon XML. > > > > Additionally, > > bias will be given to re-using either EPP, HTTP/REST, HTTP/XML-RPC, or > > HTTP/SOAP. > > > > Proposed Deliverables > > > > Requirements for SPEERMINT data exchange. > > > > Provisioning of SPEERMINT data registries. > > > > Provisioning of SPEERMINT/ENUM data caches. > > > > Richard Shockey > > Director, Member of the Technical Staff > > NeuStar > > 46000 Center Oak Plaza - Sterling, VA 20166 > > sip:rshockey(at)iptel.org > > PSTN Office +1 571.434.5651 > > PSTN Mobile: +1 703.593.2683 > > > > > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=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 Oct 12 13:19:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgO9R-0003kP-6C; Fri, 12 Oct 2007 13:18:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgO9Q-0003kA-MZ; Fri, 12 Oct 2007 13:18:16 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgO9K-0005x4-DY; Fri, 12 Oct 2007 13:18:16 -0400 Received: from rshockeyPC (mit.xs4all.nl [213.84.95.205]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l9CHFmdm005100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Oct 2007 10:17:38 -0700 From: "Richard Shockey" To: "'Daryl Malas'" References: <047301c806ef$8294f650$87bee2f0$@us> <1192114310.1297.322.camel@montag.eng.level3.com> In-Reply-To: <1192114310.1297.322.camel@montag.eng.level3.com> Subject: RE: [Enum] Re: [Speermint] I'd like to guage interest in restarting a BOF on the subject of Peppermint. Date: Fri, 12 Oct 2007 13:15:46 -0400 Message-ID: <1aaf01c80cf3$c97a7090$5c6f51b0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgMFUfjs9YMQo2nRHOSAEn0KhT6DgAoXWpw Content-language: en-us X-Spam-Score: -1.0 (-) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: enum@ietf.org, 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 Don't you think the work can proceed in parallel? Provisioning is the Achillies heel of interconnection .. > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Thursday, October 11, 2007 10:52 AM > To: Richard Shockey > Cc: enum@ietf.org; speermint@ietf.org > Subject: [Enum] Re: [Speermint] I'd like to guage interest in > restarting a BOF on the subject of Peppermint. > > IMO, I believe this is warranted, but I do not think we are ready for > it > yet. I suspect this will be of a lot more interest in this BOF in > about > 1 year, after several of the SPEERMINT milestones are completed. > > Daryl > > On Thu, 2007-10-04 at 21:31 -0400, Richard Shockey wrote: > > This time last year I tried to start up a BOF on some of the ongoing > > provisioning issues between various forms of ENUM registries and > network > > entities. I've had a few folks ask what ever happened to that. I > still think > > there is a strong need to do this and the work could have relevance > if the > > scope were expanded not to be just service provider to registry but > also PBX > > to registries as well. > > > > I'd like to test the water to see if there is any interest in doing > this in > > Vancouver. > > > > > > The original BOF proposal was this: > > > > Comments as usual are welcome > > > > > > Peppermint BOF > > > > Provisioning Extensions in Peering Registries for Multimedia > > Intererconnection. > > > > Mailing Lists: > > > > BOF chairs: > > > > Richard Shockey [rich.shockey@neustar.biz] > > > > Temporary Area Directorate: Real Time Applications (RAI) > > > > Ultimate Area Directorate: TBD > > > > > > BOF Purpose. > > > > The ENUM and SPEERMINT working groups are working on various aspects > of > > Multi Media Interconnection. ENUM is specifically chartered to > develop > > protocols that involve the translation of E.164 numbers to URI's. > > SPEERMINT has been chartered to develop best current practices among > > real-time application service providers and how such services > interconnect > > across domain boundaries. > > > > It is clear from discussions in both working groups that Multi-Media > > Interconnection will require various forms of data to be exchanged > among > > administrative domains outside the normal scope of establishing a > SIP > > session. > > > > Such data exchanges might be provisioning of various forms of > Registries > > containing mappings of phone numbers to URI, policies surrounding > the > > admission to points of network interconnection and the distribution > of > > Registry data to various types of databases. > > > > The purpose of the BOF is to determine the need and scope for such > data > > exchanges, what existing protocols need to be adapted to meet those > needs > > and the appropriate schema and queries are needed to facilitate such > > exchanges. > > > > The IETF has in the past done significant work on data exchanges > among > > various administrative entities. In particular the PROVREG working > group > > developed various schema and query mechanisms to facilitate the > exchange of > > data among domain name registries and registrars. > > > > The ENUM Working group has adapted PROVREG working group protocols > to > > develop RFC 4114, which facilitates the provisioning of ENUM data in > the DNS > > tree. However, there has been little adoption of RFC 4114, and many > of the > > participants of the SPEERMINT working group require both data models > and > > protocol features not found in RFC 4114. > > > > The proposed PEPPERMINT working group will build upon the knowledge > gained > > from those efforts, and the intent of this proposed working group is > to find > > a provisioning solution for peering as defined by SPEERMINT. The > final work > > product(s) from this working group will be based upon XML. > > > > Additionally, > > bias will be given to re-using either EPP, HTTP/REST, HTTP/XML-RPC, > or > > HTTP/SOAP. > > > > Proposed Deliverables > > > > Requirements for SPEERMINT data exchange. > > > > Provisioning of SPEERMINT data registries. > > > > Provisioning of SPEERMINT/ENUM data caches. > > > > Richard Shockey > > Director, Member of the Technical Staff > > NeuStar > > 46000 Center Oak Plaza - Sterling, VA 20166 > > sip:rshockey(at)iptel.org > > PSTN Office +1 571.434.5651 > > PSTN Mobile: +1 703.593.2683 > > > > > > > > > > > > > > _______________________________________________ > > 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 Tue Oct 16 17:44:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihu9O-0000LA-0U; Tue, 16 Oct 2007 17:40:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihu9M-0000Kw-91; Tue, 16 Oct 2007 17:40:28 -0400 Received: from mail34.messagelabs.com ([216.82.241.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ihu9F-0006sh-9I; Tue, 16 Oct 2007 17:40:28 -0400 X-VirusChecked: Checked X-Env-Sender: daryl@level3.net X-Msg-Ref: server-7.tower-34.messagelabs.com!1192570801!2951796!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.106] Received: (qmail 774 invoked from network); 16 Oct 2007 21:40:01 -0000 Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106) by server-7.tower-34.messagelabs.com with SMTP; 16 Oct 2007 21:40:01 -0000 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f10bb8-10 (Postfix) with ESMTP id 6E3184C9A; Tue, 16 Oct 2007 21:40:01 +0000 (GMT) Subject: RE: [Enum] Re: [Speermint] I'd like to guage interest in restarting a BOF on the subject of Peppermint. From: Daryl Malas To: Richard Shockey In-Reply-To: <1aaf01c80cf3$c97a7090$5c6f51b0$@us> References: <047301c806ef$8294f650$87bee2f0$@us> <1192114310.1297.322.camel@montag.eng.level3.com> <1aaf01c80cf3$c97a7090$5c6f51b0$@us> Content-Type: text/plain Date: Tue, 16 Oct 2007 15:47:44 -0600 Message-Id: <1192571265.1297.336.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: enum@ietf.org, 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 >From my perspective, we are just, finally, nearing completion of the terminology draft. Since, we have not completed drafts, such as "Requirements" and "Architecture", I would be concerned the PEPPERMINT group/BOF understands exactly what the requirements of the interconnection would look like in order to provision it appropriately. IMO, continued discussion around this topic is warranted, but I think the PEPPERMINT BOF should wait until near or after the following SPEERMINT milestone is met: Feb 2008 Submit SPEERMINT minimum requirements for SIP-based VoIP interconnection. (BCP) Based on this, I would recommend a BOF in the spring (likely Summer) and perhaps the need for a WG at the fall 2008 IETF conference. This way the PEPPERMINT group will fully understand the requirements, and will be able to appropriately define a charter. --Daryl On Fri, 2007-10-12 at 13:15 -0400, Richard Shockey wrote: > Don't you think the work can proceed in parallel? > > Provisioning is the Achillies heel of interconnection .. > > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: Thursday, October 11, 2007 10:52 AM > > To: Richard Shockey > > Cc: enum@ietf.org; speermint@ietf.org > > Subject: [Enum] Re: [Speermint] I'd like to guage interest in > > restarting a BOF on the subject of Peppermint. > > > > IMO, I believe this is warranted, but I do not think we are ready for > > it > > yet. I suspect this will be of a lot more interest in this BOF in > > about > > 1 year, after several of the SPEERMINT milestones are completed. > > > > Daryl > > > > On Thu, 2007-10-04 at 21:31 -0400, Richard Shockey wrote: > > > This time last year I tried to start up a BOF on some of the ongoing > > > provisioning issues between various forms of ENUM registries and > > network > > > entities. I've had a few folks ask what ever happened to that. I > > still think > > > there is a strong need to do this and the work could have relevance > > if the > > > scope were expanded not to be just service provider to registry but > > also PBX > > > to registries as well. > > > > > > I'd like to test the water to see if there is any interest in doing > > this in > > > Vancouver. > > > > > > > > > The original BOF proposal was this: > > > > > > Comments as usual are welcome > > > > > > > > > Peppermint BOF > > > > > > Provisioning Extensions in Peering Registries for Multimedia > > > Intererconnection. > > > > > > Mailing Lists: > > > > > > BOF chairs: > > > > > > Richard Shockey [rich.shockey@neustar.biz] > > > > > > Temporary Area Directorate: Real Time Applications (RAI) > > > > > > Ultimate Area Directorate: TBD > > > > > > > > > BOF Purpose. > > > > > > The ENUM and SPEERMINT working groups are working on various aspects > > of > > > Multi Media Interconnection. ENUM is specifically chartered to > > develop > > > protocols that involve the translation of E.164 numbers to URI's. > > > SPEERMINT has been chartered to develop best current practices among > > > real-time application service providers and how such services > > interconnect > > > across domain boundaries. > > > > > > It is clear from discussions in both working groups that Multi-Media > > > Interconnection will require various forms of data to be exchanged > > among > > > administrative domains outside the normal scope of establishing a > > SIP > > > session. > > > > > > Such data exchanges might be provisioning of various forms of > > Registries > > > containing mappings of phone numbers to URI, policies surrounding > > the > > > admission to points of network interconnection and the distribution > > of > > > Registry data to various types of databases. > > > > > > The purpose of the BOF is to determine the need and scope for such > > data > > > exchanges, what existing protocols need to be adapted to meet those > > needs > > > and the appropriate schema and queries are needed to facilitate such > > > exchanges. > > > > > > The IETF has in the past done significant work on data exchanges > > among > > > various administrative entities. In particular the PROVREG working > > group > > > developed various schema and query mechanisms to facilitate the > > exchange of > > > data among domain name registries and registrars. > > > > > > The ENUM Working group has adapted PROVREG working group protocols > > to > > > develop RFC 4114, which facilitates the provisioning of ENUM data in > > the DNS > > > tree. However, there has been little adoption of RFC 4114, and many > > of the > > > participants of the SPEERMINT working group require both data models > > and > > > protocol features not found in RFC 4114. > > > > > > The proposed PEPPERMINT working group will build upon the knowledge > > gained > > > from those efforts, and the intent of this proposed working group is > > to find > > > a provisioning solution for peering as defined by SPEERMINT. The > > final work > > > product(s) from this working group will be based upon XML. > > > > > > Additionally, > > > bias will be given to re-using either EPP, HTTP/REST, HTTP/XML-RPC, > > or > > > HTTP/SOAP. > > > > > > Proposed Deliverables > > > > > > Requirements for SPEERMINT data exchange. > > > > > > Provisioning of SPEERMINT data registries. > > > > > > Provisioning of SPEERMINT/ENUM data caches. > > > > > > Richard Shockey > > > Director, Member of the Technical Staff > > > NeuStar > > > 46000 Center Oak Plaza - Sterling, VA 20166 > > > sip:rshockey(at)iptel.org > > > PSTN Office +1 571.434.5651 > > > PSTN Mobile: +1 703.593.2683 > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 Tue Oct 16 21:54:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihy6R-000479-E8; Tue, 16 Oct 2007 21:53:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihy6P-00046k-EU; Tue, 16 Oct 2007 21:53:41 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihy6O-0000KU-CU; Tue, 16 Oct 2007 21:53:41 -0400 Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l9H1rEPO003838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Oct 2007 18:53:20 -0700 From: "Richard Shockey" To: "'Daryl Malas'" References: <047301c806ef$8294f650$87bee2f0$@us> <1192114310.1297.322.camel@montag.eng.level3.com> <1aaf01c80cf3$c97a7090$5c6f51b0$@us> <1192571265.1297.336.camel@montag.eng.level3.com> In-Reply-To: <1192571265.1297.336.camel@montag.eng.level3.com> Subject: RE: [Enum] Re: [Speermint] I'd like to guage interest in restarting a BOF on the subject of Peppermint. Date: Tue, 16 Oct 2007 21:53:01 -0400 Message-ID: <013001c81060$770b4030$6521c090$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgQPWAEfB7rFjFDQ7eW54n2AgyFhAAIc5kA Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: enum@ietf.org, 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 Clearly I don't agree. I think there are time to market issues that require a parallel effort. The deployment of ENUM in its various forms specifically private instantiations as well as federations surrounding cable and mobile networks indicate that if action is not taken anarchy will occur. Provisioning as I have stated countless times is the Achilles' Heel of the entire federation process. There are multiple issues in provisioning, not just the location of various points of interconnection but internal provisioning of highly cached ENUM servers, what I refer to as IP-SCP's that are rapidly becoming core network elements of NGN. For instance discovery of points of interconnection may require separate internal trunking decisions on how the traffic is to be routed based on internal policy on how Layer1-3 connections are made. It is my intention to have a new ENUM ID ready shortly that will outline how to create a new ENUMservice based on RFC 4904. > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Tuesday, October 16, 2007 5:48 PM > To: Richard Shockey > Cc: enum@ietf.org; speermint@ietf.org > Subject: RE: [Enum] Re: [Speermint] I'd like to guage interest in > restarting a BOF on the subject of Peppermint. > > >From my perspective, we are just, finally, nearing completion of the > terminology draft. Since, we have not completed drafts, such as > "Requirements" and "Architecture", I would be concerned the PEPPERMINT > group/BOF understands exactly what the requirements of the > interconnection would look like in order to provision it > appropriately. > > IMO, continued discussion around this topic is warranted, but I think > the PEPPERMINT BOF should wait until near or after the following > SPEERMINT milestone is met: > > Feb 2008 Submit SPEERMINT minimum requirements for SIP-based VoIP > interconnection. (BCP) > > Based on this, I would recommend a BOF in the spring (likely Summer) > and > perhaps the need for a WG at the fall 2008 IETF conference. > > This way the PEPPERMINT group will fully understand the requirements, > and will be able to appropriately define a charter. > > --Daryl > > On Fri, 2007-10-12 at 13:15 -0400, Richard Shockey wrote: > > Don't you think the work can proceed in parallel? > > > > Provisioning is the Achillies heel of interconnection .. > > > > > -----Original Message----- > > > From: Daryl Malas [mailto:daryl@level3.net] > > > Sent: Thursday, October 11, 2007 10:52 AM > > > To: Richard Shockey > > > Cc: enum@ietf.org; speermint@ietf.org > > > Subject: [Enum] Re: [Speermint] I'd like to guage interest in > > > restarting a BOF on the subject of Peppermint. > > > > > > IMO, I believe this is warranted, but I do not think we are ready > for > > > it > > > yet. I suspect this will be of a lot more interest in this BOF > in > > > about > > > 1 year, after several of the SPEERMINT milestones are completed. > > > > > > Daryl > > > > > > On Thu, 2007-10-04 at 21:31 -0400, Richard Shockey wrote: > > > > This time last year I tried to start up a BOF on some of the > ongoing > > > > provisioning issues between various forms of ENUM registries > and > > > network > > > > entities. I've had a few folks ask what ever happened to that. > I > > > still think > > > > there is a strong need to do this and the work could have > relevance > > > if the > > > > scope were expanded not to be just service provider to registry > but > > > also PBX > > > > to registries as well. > > > > > > > > I'd like to test the water to see if there is any interest in > doing > > > this in > > > > Vancouver. > > > > > > > > > > > > The original BOF proposal was this: > > > > > > > > Comments as usual are welcome > > > > > > > > > > > > Peppermint BOF > > > > > > > > Provisioning Extensions in Peering Registries for Multimedia > > > > Intererconnection. > > > > > > > > Mailing Lists: > > > > > > > > BOF chairs: > > > > > > > > Richard Shockey [rich.shockey@neustar.biz] > > > > > > > > Temporary Area Directorate: Real Time Applications (RAI) > > > > > > > > Ultimate Area Directorate: TBD > > > > > > > > > > > > BOF Purpose. > > > > > > > > The ENUM and SPEERMINT working groups are working on various > aspects > > > of > > > > Multi Media Interconnection. ENUM is specifically chartered to > > > develop > > > > protocols that involve the translation of E.164 numbers to > URI's. > > > > SPEERMINT has been chartered to develop best current practices > among > > > > real-time application service providers and how such services > > > interconnect > > > > across domain boundaries. > > > > > > > > It is clear from discussions in both working groups that Multi- > Media > > > > Interconnection will require various forms of data to be > exchanged > > > among > > > > administrative domains outside the normal scope of establishing > a > > > SIP > > > > session. > > > > > > > > Such data exchanges might be provisioning of various forms of > > > Registries > > > > containing mappings of phone numbers to URI, policies > surrounding > > > the > > > > admission to points of network interconnection and the > distribution > > > of > > > > Registry data to various types of databases. > > > > > > > > The purpose of the BOF is to determine the need and scope for > such > > > data > > > > exchanges, what existing protocols need to be adapted to meet > those > > > needs > > > > and the appropriate schema and queries are needed to facilitate > such > > > > exchanges. > > > > > > > > The IETF has in the past done significant work on data > exchanges > > > among > > > > various administrative entities. In particular the PROVREG > working > > > group > > > > developed various schema and query mechanisms to facilitate the > > > exchange of > > > > data among domain name registries and registrars. > > > > > > > > The ENUM Working group has adapted PROVREG working group > protocols > > > to > > > > develop RFC 4114, which facilitates the provisioning of ENUM > data in > > > the DNS > > > > tree. However, there has been little adoption of RFC 4114, and > many > > > of the > > > > participants of the SPEERMINT working group require both data > models > > > and > > > > protocol features not found in RFC 4114. > > > > > > > > The proposed PEPPERMINT working group will build upon the > knowledge > > > gained > > > > from those efforts, and the intent of this proposed working > group is > > > to find > > > > a provisioning solution for peering as defined by SPEERMINT. > The > > > final work > > > > product(s) from this working group will be based upon XML. > > > > > > > > Additionally, > > > > bias will be given to re-using either EPP, HTTP/REST, HTTP/XML- > RPC, > > > or > > > > HTTP/SOAP. > > > > > > > > Proposed Deliverables > > > > > > > > Requirements for SPEERMINT data exchange. > > > > > > > > Provisioning of SPEERMINT data registries. > > > > > > > > Provisioning of SPEERMINT/ENUM data caches. > > > > > > > > Richard Shockey > > > > Director, Member of the Technical Staff > > > > NeuStar > > > > 46000 Center Oak Plaza - Sterling, VA 20166 > > > > sip:rshockey(at)iptel.org > > > > PSTN Office +1 571.434.5651 > > > > PSTN Mobile: +1 703.593.2683 > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > _______________________________________________ > 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 Wed Oct 17 15:13:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiEIc-0001Qz-Vo; Wed, 17 Oct 2007 15:11:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiEIa-0001PX-Qg; Wed, 17 Oct 2007 15:11:20 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiEIZ-00083W-LZ; Wed, 17 Oct 2007 15:11:20 -0400 Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.47847303; Wed, 17 Oct 2007 15:10:59 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 15:10: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: [Enum] Re: [Speermint] I'd like to guage interest inrestarting a BOF on the subject of Peppermint. Date: Wed, 17 Oct 2007 15:11:02 -0400 Message-ID: <45AEC6EF95942140888406588E1A660202ECC379@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <1192571265.1297.336.camel@montag.eng.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Re: [Speermint] I'd like to guage interest inrestarting a BOF on the subject of Peppermint. Thread-Index: AcgQPjS4npWhayLGTPSlxlVzIGMceQAqtQ6A References: <047301c806ef$8294f650$87bee2f0$@us><1192114310.1297.322.camel@montag.eng.level3.com><1aaf01c80cf3$c97a7090$5c6f51b0$@us> <1192571265.1297.336.camel@montag.eng.level3.com> From: "Creighton, Tom" To: "Daryl Malas" , "Richard Shockey" X-OriginalArrivalTime: 17 Oct 2007 19:10:59.0700 (UTC) FILETIME=[73DBB340:01C810F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: enum@ietf.org, speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl: I understand your concern that we might be placing the cart before the horse; but have you considered that the cart might actually be a horse? SPEERMINT, as we all know, was designed to take a collection of protocols and provide a set of recommendations as to how they should be used. PEPPERMINT, however, would need to define a set of protocols that could be used to exchange provisioning data in support of efforts such as SPEERMINT. These standards would need to support a myriad of use cases within the IETF which could then be the basis of a SPEERMINT BCP. There is a DIRE need for standardization in this area today because the current standard of exchanging provisioning data (such as call routing tables) using Excel is not acceptable. Tom > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Tuesday, October 16, 2007 17:48 > To: Richard Shockey > Cc: enum@ietf.org; speermint@ietf.org > Subject: RE: [Enum] Re: [Speermint] I'd like to guage interest > inrestarting a BOF on the subject of Peppermint. >=20 > >From my perspective, we are just, finally, nearing completion of the > terminology draft. Since, we have not completed drafts, such as > "Requirements" and "Architecture", I would be concerned the PEPPERMINT > group/BOF understands exactly what the requirements of the > interconnection would look like in order to provision it appropriately. >=20 > IMO, continued discussion around this topic is warranted, but I think > the PEPPERMINT BOF should wait until near or after the following > SPEERMINT milestone is met: >=20 > Feb 2008 Submit SPEERMINT minimum requirements for SIP-based VoIP > interconnection. (BCP) >=20 > Based on this, I would recommend a BOF in the spring (likely Summer) and > perhaps the need for a WG at the fall 2008 IETF conference. >=20 > This way the PEPPERMINT group will fully understand the requirements, > and will be able to appropriately define a charter. >=20 > --Daryl >=20 > On Fri, 2007-10-12 at 13:15 -0400, Richard Shockey wrote: > > Don't you think the work can proceed in parallel? > > > > Provisioning is the Achillies heel of interconnection .. > > > > > -----Original Message----- > > > From: Daryl Malas [mailto:daryl@level3.net] > > > Sent: Thursday, October 11, 2007 10:52 AM > > > To: Richard Shockey > > > Cc: enum@ietf.org; speermint@ietf.org > > > Subject: [Enum] Re: [Speermint] I'd like to guage interest in > > > restarting a BOF on the subject of Peppermint. > > > > > > IMO, I believe this is warranted, but I do not think we are ready for > > > it > > > yet. I suspect this will be of a lot more interest in this BOF in > > > about > > > 1 year, after several of the SPEERMINT milestones are completed. > > > > > > Daryl > > > > > > On Thu, 2007-10-04 at 21:31 -0400, Richard Shockey wrote: > > > > This time last year I tried to start up a BOF on some of the > ongoing > > > > provisioning issues between various forms of ENUM registries and > > > network > > > > entities. I've had a few folks ask what ever happened to that. I > > > still think > > > > there is a strong need to do this and the work could have relevance > > > if the > > > > scope were expanded not to be just service provider to registry but > > > also PBX > > > > to registries as well. > > > > > > > > I'd like to test the water to see if there is any interest in doing > > > this in > > > > Vancouver. > > > > > > > > > > > > The original BOF proposal was this: > > > > > > > > Comments as usual are welcome > > > > > > > > > > > > Peppermint BOF > > > > > > > > Provisioning Extensions in Peering Registries for Multimedia > > > > Intererconnection. > > > > > > > > Mailing Lists: > > > > > > > > BOF chairs: > > > > > > > > Richard Shockey [rich.shockey@neustar.biz] > > > > > > > > Temporary Area Directorate: Real Time Applications (RAI) > > > > > > > > Ultimate Area Directorate: TBD > > > > > > > > > > > > BOF Purpose. > > > > > > > > The ENUM and SPEERMINT working groups are working on various > aspects > > > of > > > > Multi Media Interconnection. ENUM is specifically chartered to > > > develop > > > > protocols that involve the translation of E.164 numbers to URI's. > > > > SPEERMINT has been chartered to develop best current practices > among > > > > real-time application service providers and how such services > > > interconnect > > > > across domain boundaries. > > > > > > > > It is clear from discussions in both working groups that Multi- > Media > > > > Interconnection will require various forms of data to be exchanged > > > among > > > > administrative domains outside the normal scope of establishing a > > > SIP > > > > session. > > > > > > > > Such data exchanges might be provisioning of various forms of > > > Registries > > > > containing mappings of phone numbers to URI, policies surrounding > > > the > > > > admission to points of network interconnection and the distribution > > > of > > > > Registry data to various types of databases. > > > > > > > > The purpose of the BOF is to determine the need and scope for such > > > data > > > > exchanges, what existing protocols need to be adapted to meet those > > > needs > > > > and the appropriate schema and queries are needed to facilitate > such > > > > exchanges. > > > > > > > > The IETF has in the past done significant work on data exchanges > > > among > > > > various administrative entities. In particular the PROVREG working > > > group > > > > developed various schema and query mechanisms to facilitate the > > > exchange of > > > > data among domain name registries and registrars. > > > > > > > > The ENUM Working group has adapted PROVREG working group protocols > > > to > > > > develop RFC 4114, which facilitates the provisioning of ENUM data > in > > > the DNS > > > > tree. However, there has been little adoption of RFC 4114, and > many > > > of the > > > > participants of the SPEERMINT working group require both data > models > > > and > > > > protocol features not found in RFC 4114. > > > > > > > > The proposed PEPPERMINT working group will build upon the knowledge > > > gained > > > > from those efforts, and the intent of this proposed working group > is > > > to find > > > > a provisioning solution for peering as defined by SPEERMINT. The > > > final work > > > > product(s) from this working group will be based upon XML. > > > > > > > > Additionally, > > > > bias will be given to re-using either EPP, HTTP/REST, HTTP/XML-RPC, > > > or > > > > HTTP/SOAP. > > > > > > > > Proposed Deliverables > > > > > > > > Requirements for SPEERMINT data exchange. > > > > > > > > Provisioning of SPEERMINT data registries. > > > > > > > > Provisioning of SPEERMINT/ENUM data caches. > > > > > > > > Richard Shockey > > > > Director, Member of the Technical Staff > > > > NeuStar > > > > 46000 Center Oak Plaza - Sterling, VA 20166 > > > > sip:rshockey(at)iptel.org > > > > PSTN Office +1 571.434.5651 > > > > PSTN Mobile: +1 703.593.2683 > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 >=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 Oct 17 23:08:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiLhv-0006Yd-G5; Wed, 17 Oct 2007 23:05:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiLht-0006Xx-CM; Wed, 17 Oct 2007 23:05:57 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiLhs-00065U-3X; Wed, 17 Oct 2007 23:05:57 -0400 Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l9I35WE1009611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Oct 2007 20:05:33 -0700 From: "Richard Shockey" To: , , References: In-Reply-To: Date: Wed, 17 Oct 2007 23:05:16 -0400 Message-ID: <011001c81133$b6867ad0$23937070$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acdq2YSxJnBpAM8fRfeozkdMO0FALymWRc5w Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Subject: [Speermint] I have formally requested a BOF on the PEPPERMINT proposition for Vancouver. X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 submitted to the RAI AD's and the agenda folks a proposed BOF. I would like folks to consider the proposed charter and comment. Should folks wish to present drafts or simply wish to present ideas let us know ASAP. Peppermint BOF Provisioning Extensions in Peering Registries for Multimedia Interconnection. Mailing Lists: peppermint@ietf.org General information about the mailing list is at: https://www1.ietf.org/mailman/listinfo/peppermint BOF chairs: Richard Shockey [richard.shockey@neustar.biz] Other co-chairs TBD waiting on approvals... Temporary Area Directorate: Real Time Applications (RAI) Ultimate Area Directorate: TBD BOF Purpose. The ENUM and SPEERMINT working groups are working on various aspects of Multi Media Interconnection. ENUM is specifically chartered to develop protocols that involve the translation of E.164 numbers to URI's. SPEERMINT has been chartered to develop best current practices among real-time application service providers and how such services interconnect across domain boundaries. It is clear from discussions in both working groups that Multi-Media Interconnection will require various forms of data to be exchanged among administrative domains outside the normal scope of establishing various forms of a SIP session. Such data exchanges might be provisioning of various forms of Registries containing mappings of phone numbers to URI, policies surrounding the admission to points of network interconnection, trunking data and the distribution of Registry data to various types of databases. Provisioning may include PBX to service provider data exchanges as well. The purpose of the BOF is to determine the need and scope for such data exchanges, what existing protocols need to be adapted to meet those needs and the appropriate schema and queries are needed to facilitate such exchanges. The IETF has in the past done significant work on data exchanges among various administrative entities. In particular the PROVREG working group developed various schema and query mechanisms to facilitate the exchange of data among domain name registries and registrars. The ENUM Working group has adapted PROVREG working group protocols to develop RFC 4114, which facilitates the provisioning of ENUM data in the DNS tree. However, there has been little adoption of RFC 4114, and many of the participants of the SPEERMINT working group require both data models and protocol features not found in RFC 4114. The proposed PEPPERMINT working group will build upon the knowledge gained from those efforts, and the intent of this proposed working group is to find a provisioning solution for peering as defined by SPEERMINT. The final work product(s) from this working group will be based upon XML. Additionally, bias will be given to re-using either EPP, HTTP/REST, HTTP/XML-RPC, or HTTP/SOAP. Proposed Deliverables Requirements for PEPPERMINT data exchanges. Provisioning of PEPPERMINT data registries. Provisioning of PEPPERMINT/ENUM data caches. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 18 11:09:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWyN-0000Oh-Lo; Thu, 18 Oct 2007 11:07:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWyL-0000MZ-BA; Thu, 18 Oct 2007 11:07:41 -0400 Received: from mail28.messagelabs.com ([216.82.249.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IiWyK-0005YQ-7K; Thu, 18 Oct 2007 11:07:41 -0400 X-VirusChecked: Checked X-Env-Sender: daryl@level3.net X-Msg-Ref: server-21.tower-28.messagelabs.com!1192720058!42239860!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.106] Received: (qmail 25906 invoked from network); 18 Oct 2007 15:07:38 -0000 Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106) by server-21.tower-28.messagelabs.com with SMTP; 18 Oct 2007 15:07:38 -0000 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f10bb8-10 (Postfix) with ESMTP id 9A2CF4CB4; Thu, 18 Oct 2007 15:07:38 +0000 (GMT) Subject: RE: [Enum] Re: [Speermint] I'd like to guage interest inrestarting a BOF on the subject of Peppermint. From: Daryl Malas To: "Creighton, Tom" In-Reply-To: <45AEC6EF95942140888406588E1A660202ECC379@PACDCEXCMB04.cable.comcast.com> References: <047301c806ef$8294f650$87bee2f0$@us> <1192114310.1297.322.camel@montag.eng.level3.com> <1aaf01c80cf3$c97a7090$5c6f51b0$@us> <1192571265.1297.336.camel@montag.eng.level3.com> <45AEC6EF95942140888406588E1A660202ECC379@PACDCEXCMB04.cable.comcast.com> Content-Type: text/plain Date: Thu, 18 Oct 2007 09:15:28 -0600 Message-Id: <1192720528.1297.340.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.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: enum@ietf.org, 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 Tom/Richard, I perceive you both are closer to an existing problem relative to this than I am. Let me know how I can support you from SPEERMINT aspects. --Daryl On Wed, 2007-10-17 at 15:11 -0400, Creighton, Tom wrote: > Daryl: > > I understand your concern that we might be placing the cart before the > horse; but have you considered that the cart might actually be a horse? > SPEERMINT, as we all know, was designed to take a collection of > protocols and provide a set of recommendations as to how they should be > used. PEPPERMINT, however, would need to define a set of protocols that > could be used to exchange provisioning data in support of efforts such > as SPEERMINT. These standards would need to support a myriad of use > cases within the IETF which could then be the basis of a SPEERMINT BCP. > > There is a DIRE need for standardization in this area today because the > current standard of exchanging provisioning data (such as call routing > tables) using Excel is not acceptable. > > Tom > > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: Tuesday, October 16, 2007 17:48 > > To: Richard Shockey > > Cc: enum@ietf.org; speermint@ietf.org > > Subject: RE: [Enum] Re: [Speermint] I'd like to guage interest > > inrestarting a BOF on the subject of Peppermint. > > > > >From my perspective, we are just, finally, nearing completion of the > > terminology draft. Since, we have not completed drafts, such as > > "Requirements" and "Architecture", I would be concerned the PEPPERMINT > > group/BOF understands exactly what the requirements of the > > interconnection would look like in order to provision it > appropriately. > > > > IMO, continued discussion around this topic is warranted, but I think > > the PEPPERMINT BOF should wait until near or after the following > > SPEERMINT milestone is met: > > > > Feb 2008 Submit SPEERMINT minimum requirements for SIP-based VoIP > > interconnection. (BCP) > > > > Based on this, I would recommend a BOF in the spring (likely Summer) > and > > perhaps the need for a WG at the fall 2008 IETF conference. > > > > This way the PEPPERMINT group will fully understand the requirements, > > and will be able to appropriately define a charter. > > > > --Daryl > > > > On Fri, 2007-10-12 at 13:15 -0400, Richard Shockey wrote: > > > Don't you think the work can proceed in parallel? > > > > > > Provisioning is the Achillies heel of interconnection .. > > > > > > > -----Original Message----- > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > Sent: Thursday, October 11, 2007 10:52 AM > > > > To: Richard Shockey > > > > Cc: enum@ietf.org; speermint@ietf.org > > > > Subject: [Enum] Re: [Speermint] I'd like to guage interest in > > > > restarting a BOF on the subject of Peppermint. > > > > > > > > IMO, I believe this is warranted, but I do not think we are ready > for > > > > it > > > > yet. I suspect this will be of a lot more interest in this BOF > in > > > > about > > > > 1 year, after several of the SPEERMINT milestones are completed. > > > > > > > > Daryl > > > > > > > > On Thu, 2007-10-04 at 21:31 -0400, Richard Shockey wrote: > > > > > This time last year I tried to start up a BOF on some of the > > ongoing > > > > > provisioning issues between various forms of ENUM registries > and > > > > network > > > > > entities. I've had a few folks ask what ever happened to that. > I > > > > still think > > > > > there is a strong need to do this and the work could have > relevance > > > > if the > > > > > scope were expanded not to be just service provider to registry > but > > > > also PBX > > > > > to registries as well. > > > > > > > > > > I'd like to test the water to see if there is any interest in > doing > > > > this in > > > > > Vancouver. > > > > > > > > > > > > > > > The original BOF proposal was this: > > > > > > > > > > Comments as usual are welcome > > > > > > > > > > > > > > > Peppermint BOF > > > > > > > > > > Provisioning Extensions in Peering Registries for Multimedia > > > > > Intererconnection. > > > > > > > > > > Mailing Lists: > > > > > > > > > > BOF chairs: > > > > > > > > > > Richard Shockey [rich.shockey@neustar.biz] > > > > > > > > > > Temporary Area Directorate: Real Time Applications (RAI) > > > > > > > > > > Ultimate Area Directorate: TBD > > > > > > > > > > > > > > > BOF Purpose. > > > > > > > > > > The ENUM and SPEERMINT working groups are working on various > > aspects > > > > of > > > > > Multi Media Interconnection. ENUM is specifically chartered to > > > > develop > > > > > protocols that involve the translation of E.164 numbers to > URI's. > > > > > SPEERMINT has been chartered to develop best current practices > > among > > > > > real-time application service providers and how such services > > > > interconnect > > > > > across domain boundaries. > > > > > > > > > > It is clear from discussions in both working groups that Multi- > > Media > > > > > Interconnection will require various forms of data to be > exchanged > > > > among > > > > > administrative domains outside the normal scope of establishing > a > > > > SIP > > > > > session. > > > > > > > > > > Such data exchanges might be provisioning of various forms of > > > > Registries > > > > > containing mappings of phone numbers to URI, policies > surrounding > > > > the > > > > > admission to points of network interconnection and the > distribution > > > > of > > > > > Registry data to various types of databases. > > > > > > > > > > The purpose of the BOF is to determine the need and scope for > such > > > > data > > > > > exchanges, what existing protocols need to be adapted to meet > those > > > > needs > > > > > and the appropriate schema and queries are needed to facilitate > > such > > > > > exchanges. > > > > > > > > > > The IETF has in the past done significant work on data > exchanges > > > > among > > > > > various administrative entities. In particular the PROVREG > working > > > > group > > > > > developed various schema and query mechanisms to facilitate the > > > > exchange of > > > > > data among domain name registries and registrars. > > > > > > > > > > The ENUM Working group has adapted PROVREG working group > protocols > > > > to > > > > > develop RFC 4114, which facilitates the provisioning of ENUM > data > > in > > > > the DNS > > > > > tree. However, there has been little adoption of RFC 4114, and > > many > > > > of the > > > > > participants of the SPEERMINT working group require both data > > models > > > > and > > > > > protocol features not found in RFC 4114. > > > > > > > > > > The proposed PEPPERMINT working group will build upon the > knowledge > > > > gained > > > > > from those efforts, and the intent of this proposed working > group > > is > > > > to find > > > > > a provisioning solution for peering as defined by SPEERMINT. > The > > > > final work > > > > > product(s) from this working group will be based upon XML. > > > > > > > > > > Additionally, > > > > > bias will be given to re-using either EPP, HTTP/REST, > HTTP/XML-RPC, > > > > or > > > > > HTTP/SOAP. > > > > > > > > > > Proposed Deliverables > > > > > > > > > > Requirements for SPEERMINT data exchange. > > > > > > > > > > Provisioning of SPEERMINT data registries. > > > > > > > > > > Provisioning of SPEERMINT/ENUM data caches. > > > > > > > > > > Richard Shockey > > > > > Director, Member of the Technical Staff > > > > > NeuStar > > > > > 46000 Center Oak Plaza - Sterling, VA 20166 > > > > > sip:rshockey(at)iptel.org > > > > > PSTN Office +1 571.434.5651 > > > > > PSTN Mobile: +1 703.593.2683 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > _______________________________________________ > 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 Oct 18 17:08:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iicam-0001jw-Il; Thu, 18 Oct 2007 17:07:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iical-0001ii-AE; Thu, 18 Oct 2007 17:07:43 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iicak-000150-SU; Thu, 18 Oct 2007 17:07:43 -0400 Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l9IL7MaB029091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Oct 2007 14:07:23 -0700 From: "Richard Shockey" To: , , Date: Thu, 18 Oct 2007 17:07:03 -0400 Message-ID: <015401c811ca$d62a1fd0$827e5f70$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgRytTsDz5Ud6eaTUeuHZBKD8ZgGQ== Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Speermint] These were the documents from the last time we considered a Peppermint BOF. X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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://tools.ietf.org/html/draft-schwartz-peppermint-e164-provisioning-data- set-00 http://tools.ietf.org/html/draft-newton-peppermint-problem-statement-00 http://tools.ietf.org/html/draft-lewis-peppermint-enum-reg-if-00 It would be a good time to review them and see whether they are still relevant. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 23 11:01:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkLDp-0007Ma-0b; Tue, 23 Oct 2007 10:59:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkLDn-0007Lz-6P; Tue, 23 Oct 2007 10:59:07 -0400 Received: from services.erkkila.org ([24.97.94.217] helo=erkkila.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkLDm-0002Mt-SX; Tue, 23 Oct 2007 10:59:07 -0400 Received: from [10.1.1.20] (peetop.erkkila.org [::ffff:10.1.1.20]) (AUTH: PLAIN pee@erkkila.org, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by erkkila.org with esmtp; Tue, 23 Oct 2007 14:59:06 +0000 id 0020B228.471E0C3A.000065AF Message-ID: <471E0C98.7010303@erkkila.org> Date: Tue, 23 Oct 2007 15:00:40 +0000 From: Paul Erkkila User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Richard Shockey References: <047301c806ef$8294f650$87bee2f0$@us> In-Reply-To: <047301c806ef$8294f650$87bee2f0$@us> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: enum@ietf.org, speermint@ietf.org Subject: [Speermint] Re: [Enum] I'd like to guage interest in restarting a BOF on the subject of Peppermint. X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I would be interested in this BOF, as I believe there are significant resources being expended towards solving this problem right now. The sooner open dialog on issues and methods can be established the better. -pee (If it turns out to be a B2B interface for exchanging excel spreadsheets I'm going to cry in public...) Richard Shockey wrote: > This time last year I tried to start up a BOF on some of the ongoing > provisioning issues between various forms of ENUM registries and network > entities. I've had a few folks ask what ever happened to that. I still think > there is a strong need to do this and the work could have relevance if the > scope were expanded not to be just service provider to registry but also PBX > to registries as well. > > I'd like to test the water to see if there is any interest in doing this in > Vancouver. > > > The original BOF proposal was this: > > Comments as usual are welcome > > > Peppermint BOF > > Provisioning Extensions in Peering Registries for Multimedia > Intererconnection. > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 23 12:10:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkMJd-0003HE-A7; Tue, 23 Oct 2007 12:09:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkMJb-0003Fa-Km for speermint@ietf.org; Tue, 23 Oct 2007 12:09:11 -0400 Received: from web90607.mail.mud.yahoo.com ([216.252.100.190]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IkMJb-0005A3-0H for speermint@ietf.org; Tue, 23 Oct 2007 12:09:11 -0400 Received: (qmail 93798 invoked by uid 60001); 23 Oct 2007 16:09:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=03IzrxQLbueOwROiYJswtmqrQE9Eu0ZfXCgyZSaR4sPqjksaUQiYccqRYtwUVdVSwi9mpC+FqIkWjsdWWmu09FkaqJky9rEzinjSWz1N/ActI2Z1a0L82xwyp1yVp52jqCTnll/ZLJuVLmqcuyZMdZXLy+LB9fu8+ddZazVVCdE=; X-YMail-OSG: Xsl5QecVM1njrOR2W3DfpkU.NQCTcTWpsuS.FPAkQZp29kGHclvliTHchWJmUvU3ZEVE5U_8KlLVR34nJJY.cQ_Jl0KmWdCZyP5NaDuNUVqC0CQOx1k- Received: from [65.113.98.146] by web90607.mail.mud.yahoo.com via HTTP; Tue, 23 Oct 2007 09:09:10 PDT X-Mailer: YahooMailRC/814.06 YahooMailWebService/0.7.134.12 Date: Tue, 23 Oct 2007 09:09:10 -0700 (PDT) From: Sukanta ganguly Subject: Re: [Speermint] Re: [Enum] I'd like to guage interest in restarting a BOF on the subject of Peppermint. To: Paul Erkkila , Richard Shockey MIME-Version: 1.0 Message-ID: <530636.92774.qm@web90607.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: enum@ietf.org, 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="===============0609740597==" Errors-To: speermint-bounces@ietf.org --===============0609740597== Content-Type: multipart/alternative; boundary="0-722659610-1193155750=:92774" --0-722659610-1193155750=:92774 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I would be very interested in this BoF. This is going to be a very importan= t area.=0A=0AThanks=0ASG=0A=0A=0A----- Original Message ----=0AFrom: Paul E= rkkila =0ATo: Richard Shockey =0ACc: e= num@ietf.org; speermint@ietf.org=0ASent: Tuesday, October 23, 2007 8:00:40 = AM=0ASubject: [Speermint] Re: [Enum] I'd like to guage interest in restarti= ng a BOF on the subject of Peppermint.=0A=0A=0A I would be interested in t= his BOF, as I believe there are significant=0Aresources being expended towa= rds solving this problem right now. The=0Asooner open dialog on issues and = methods can be established the better.=0A=0A-pee=0A=0A=0A(If it turns out t= o be a B2B interface for exchanging excel spreadsheets=0AI'm going to cry i= n public...)=0A=0A=0ARichard Shockey wrote:=0A> This time last year I tried= to start up a BOF on some of the ongoing=0A> provisioning issues between v= arious forms of ENUM registries and network=0A> entities. I've had a few fo= lks ask what ever happened to that. I still think=0A> there is a strong nee= d to do this and the work could have relevance if the=0A> scope were expand= ed not to be just service provider to registry but also PBX=0A> to registri= es as well.=0A> =0A> I'd like to test the water to see if there is any inte= rest in doing this in=0A> Vancouver.=0A> =0A> =0A> The original BOF proposa= l was this:=0A> =0A> Comments as usual are welcome=0A> =0A> =0A> Peppermint= BOF=0A> =0A> Provisioning Extensions in Peering Registries for Multimedia= =0A> Intererconnection.=0A> =0A=0A=0A________________________________= _______________=0ASpeermint mailing list=0ASpeermint@ietf.org=0Ahttps://www= 1.ietf.org/mailman/listinfo/speermint=0A=0A________________________________= __________________=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the b= est spam protection around =0Ahttp://mail.yahoo.com --0-722659610-1193155750=:92774 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
I would be very interested in this BoF. This is g= oing to be a very important area.
=0A
 
=0A
SG

=0A
----- Original Mess= age ----
From: Paul Erkkila <pee@erkkila.org>
To: Richard Shock= ey <richard@shockey.us>
Cc: enum@ietf.org; speermint@ietf.org
S= ent: Tuesday, October 23, 2007 8:00:40 AM
Subject: [Speermint] Re: [Enum= ] I'd like to guage interest in restarting a BOF on the subject of Peppermi= nt.


  I would be interested in this BOF, as I believe there= are significant
resources being expended towards solving this problem r= ight now. The
sooner open dialog on issues and methods can be establishe= d the better.

-pee


(If it turns out to be a B2B interface= for exchanging excel spreadsheets
I'm going to cry in public...)

Richard Shockey wrote:
> This time last year I tried to start up= a BOF on some of the ongoing
> provisioning issues between various f= orms of ENUM registries and network
> entities. I've had a few folks ask what ever happened to t= hat. I still think
> there is a strong need to do this and the work c= ould have relevance if the
> scope were expanded not to be just servi= ce provider to registry but also PBX
> to registries as well.
>=
> I'd like to test the water to see if there is any interest in doi= ng this in
> Vancouver.
>
>
> The original BOF pr= oposal was this:
>
> Comments as usual are welcome
> >
> Peppermint BOF
>
> Provisioning Extensions in P= eering Registries for Multimedia
> Intererconnection.
>
<= ;snip>

_______________________________________________
Speermi= nt mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint
=0A


______________________________________= ____________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best = spam protection around
http://mail.yahoo.com --0-722659610-1193155750=:92774-- --===============0609740597== 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 --===============0609740597==-- From speermint-bounces@ietf.org Thu Oct 25 19:03:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlBgx-0003zT-Ct; Thu, 25 Oct 2007 19:00:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlBgw-0003vE-Fy for speermint@ietf.org; Thu, 25 Oct 2007 19:00:42 -0400 Received: from mail44.messagelabs.com ([216.82.249.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IlBgk-0000kW-2R for speermint@ietf.org; Thu, 25 Oct 2007 19:00:36 -0400 X-VirusChecked: Checked X-Env-Sender: daryl@level3.net X-Msg-Ref: server-16.tower-44.messagelabs.com!1193353198!27498623!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.106] Received: (qmail 15728 invoked from network); 25 Oct 2007 22:59:58 -0000 Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106) by server-16.tower-44.messagelabs.com with SMTP; 25 Oct 2007 22:59:58 -0000 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f10bb8-10 (Postfix) with ESMTP id 67EB54CB4; Thu, 25 Oct 2007 22:59:58 +0000 (GMT) Subject: Re: [Speermint] [wg-business] WGLC for draft-ietf-speermint-terminology-12 From: Daryl Malas To: Otmar Lendl In-Reply-To: <20070918154835.GA16188@nic.at> References: <45AEC6EF95942140888406588E1A6602026BA4CC@PACDCEXCMB04.cable.comcast.com> <45AEC6EF95942140888406588E1A660202A031F5@PACDCEXCMB04.cable.comcast.com> <20070918154835.GA16188@nic.at> Content-Type: text/plain Date: Thu, 25 Oct 2007 17:08:16 -0600 Message-Id: <1193353696.1297.368.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 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 Otmar, I apologize for taking so long to respond to your comments. Thank you for taking the time to review and provide feedback. Comments in-line... (FYI...I'm updating the draft right now.) On Tue, 2007-09-18 at 17:48 +0200, Otmar Lendl wrote: > On 2007/09/18 14:09, "Livingood, Jason" wrote: > > Just a reminder that WGLC on this draft closes tomorrow. If you have > > any comments, please post them to this list. > > Ok, I'll bite (sorry for the last minute input). > > > > >2. SPEERMINT Context > > > > while the horizontal lines indicate working group scope. While the > > SPEERMINT working group is not limited (or coupled in any way) to the > > use of E.164 numbers, in the case shown here an E.164 number [5] is > > used as a key in an E.164 to Uniform Resource Identifier (URI) > > mapping (ENUM [4]). That URI is in turn used to retrieve a Naming > > Authority Pointer (NAPTR) record [3], which is in turn resolved into > > a SIP URI. Call routing is based on the resulting SIP URI. > > This is an incorrect description of ENUM. > > The E.164 number is turned into a FQDN, and based on that FQDN the DNS > is queried for NAPTR records. I recommend changing the last sentences to > > "The result of this step (which involves looking up NAPTR records > in the DNS) is a SIP URI, on which the subsequent call routing is based." > I agree. > > Note that > > the call routing step does not depend on the presence of an E.164 > > number. Indeed, the resulting SIP URI may no longer even contain any > > numbers of any type. In particular, the SIP URI can be advertised in > > various other ways, such as on a web page. > > > > Correct. > > I have issues with this diagram: The basic idea is good and helpful, but > it isn't clear what piece of data is actually handed off between the > layers. > > > E.164 number <--- Peer Discovery > > I don't understand what "Peer Discovery" is doing here. IMHO that's > definitly a part of the speermint WG's work and thus should not > appear in the ENUM section of the diagram. > Keep in mind, the breakout is not chronological to the steps to complete a call with a peer. It appears to me your comments are generally around a view of this diagram depicting a chronological view of events. > > | > > | <--- ENUM lookup of NAPTR in Domain Name System (DNS) > > | > > | > > | ENUM Working Group Scope > > =====+==================================================== > > | SPEERMINT Working Group Scope > > Lookup > > Discovery <--- Session Establishment Data (SED) > > SIP URI > > According to the SED definition below, SED is definitly not > the input into the speermint WG scope; instead I see it as > the result of this step: > I disagree with some of this. Although, I could agree the "SIP URI" is not part of the scope of SPEERMINT, it is derived of information attained through steps defined in SPEERMINT. Lookup = Look-up Function Discovery = Location Function SIP URI = Derived information from these prior to functions > > | > > | <--- Federation Detection, Policy > > | Lookup, and Service Location > > > > | > > | > > Hostname <--- Addressing and session establishment > > | > > > > | SPEERMINT Working Group Scope > > =====+==================================================== > > | Out of scope for the SPEERMINT Working Group > > | > > | <--- Lookup of A and AAAA in DNS > > | > > IP address > > | > > | <--- Routing protocols, ARP [14] etc. > > | > > MAC-address > > > > Figure 1: Session Interconnect Context > > > What about: > > INPUT: E.164 number > | > | ENUM lookup of NAPTR in Domain Name System (DNS) > | > | ENUM Working Group Scope > =====+=== INPUT/OUTPUT: SIP URI/AoR ======================== > | SPEERMINT Working Group Scope > | > | Federation Detection, Peer Discovery, Policy Lookup. > | > | -> Determination which SSP to hand to call to > | > | Service Location lookup to derive details of the > | peering: Addressing and session establishment. > | > | SPEERMINT Working Group Scope > =====+=== I/O: Session Establishment Data (SED) ========== > | Out of scope for the SPEERMINT Working Group > | > | Lookup of SRV/A and AAAA in DNS (RFC 3263) > | > | SIP message generation. (RFC 3261) > | IP Routing > | > > > Note that in Figure 1, Session Establishment Data (SED), is the data > > used to route a call to the called domain's ingress point (see > > Section 3.3 for additional detail). > > > > > As illustrated in Figure 1, the ENUM Working Group is primarily > > concerned with the acquisition of SED while the SPEERMINT Working > > Group is focused on the use of such SED in routing session signaling > > requests. Importantly, the SED can be derived from ENUM (i.e., an > > E.164 DNS entry) or via any other mechanism available to theuser. > > Again: this does not match the definition of SED. Proposed change: > > > As illustrated in Figure 1, the ENUM Working Group is primarily > concerned with the acquisition of SIP URI while the SPEERMINT Working > Group is focused on determing the Session Establishment Data (SED) > needed to the send a SIP message to a suitable next hop (on the SIP > layer). The ENUM step (the translation from E.164 number to SIP > URI) is optional if the user entered a SIP AoR directly as his call > target. I'm okay with most of this....I would like to suggest this change to the first sentence: "...to send a SIP message to a suitable SSP's (See Section 3.9 below) SIP proxy or SBE (See Section 3.1 below). The ENUM step..." > > > Finally, note that the term "call" is being used here in the most > > general sense, i.e., call routing and session routing are used > > interchangeably. > > > >3. General Definitions > > > > > >3.3. Session Establishment Data > > > > Session Establishment Data, or SED, is the data used to route a call > > to the called domain's ingress point. A domain's ingress point can be > > thought of as the location pointed to by the SRV record [1] that > > resulted from the resolution of the SED (i.e., a SIP URI). > > brr. > > What about > > A domain's ingress point is > the SBE which will accept incoming calls from the originating SSP. > How about: "A domain's ingress point is the proxy or SBE which will accept incoming calls from the originating SSP." > > > > More specifically, the SED is the set of parameters that the outgoing > > SBEs need to complete the call, and may include: > > > > . A destination SIP URI > > > > . A SIP proxy to send the INVITE to, including > > > > o Fully Qualified Domain Name (FQDN) > > > > o Port > > > > o Transport Protocol (UDP/TCP/TLS [9/10/11]) > > > > . Security Parameters, including > > > > o TLS certificate to use > > > > o TLS certificate to expect > > > > o TLS certificate verification setting > > > > . Optional resource control parameters such as > > > > o Limits on the total number of calls to a peer > > > > o Limits on SIP transactions/second > > > > o Limits on the total amount of bandwidth used on a peering > > link > > > > o In addition, lower layer parameters (such as Differentiated > > Services Code Point (DSCP) [8] markings on SIP and/or media > > packets) might also be included. > > Perhaps one need to point out that the SED which carrier A uses to talk > to carrier B does not need to be equal to the SED that carrier C uses > when talking to B. I agree, but I do not think it is necessary. There is no mention in the draft of exclusivity. Is this necessary? I do not believe it is. I think this is understood. > > > > >3.4. Call Routing > > > > Call routing is the set of processes, rules, and SED used to route a > > call to its proper (SIP) destination. More generally, call routing > > can be thought of as the set of processes, rules and SED which are > > used to route a real-time session to its termination point. > > Please strike SED from this paragraph. As I described earlier, I think the Look-up and Location functions are part of deriving SED for peering. > > > > >4.2.1. Direct Peering > >4.2.2. Indirect Peering > >4.2.3. Assisted Peering > >4.2.4. On-demand Peering > >4.2.5. Static Peering > > These definition are good. Perhaps add a paragraph like this: > > The concepts direct/indirect, assisted/not-assisted, and on-demand/statis > are orthogonal to each other. All eight combinations are possible. The orthogonal representation is stated in the last sentence of both 4.2.4 and 4.2.5. Let me know if you think it should still be added separately. > > > > >4.3. Functions > > > > The following are terms associated with the functions required for > > peering. > > > >4.3.1. Look-Up Function > > > > The Look-Up Function (LUF) provides a mechanism for querying an > > internal and/or external database, which maintains a list of SIP user > > names and associated peering domains. > > "user names"? username@domain.com ...could be "user part" > > This reeks of number-based lookups via the back-door of encoding > them in the username part of SIP URIs. I don't like this. > > >4.3.2. Location Function > > > > The Location Function (LF) develops call routing data (CRD) by > > discovering the Signaling Function (SF), and SF's reachable host (IP > > Address and port). > > Didn't we replace CRD with SED? Yes...oversight, thanks...will replace. > > >4.3.3. Signaling Function > > > > The SF performs routing of SIP messages, to optionally perform > > termination and re-initiation of the call, and to assist in the > > discovery/exchange of parameters to be used by the Media Function > > (MF). > > > >4.3.4. Media Function > > > > The MF performs media related functions such as media transcoding and > > media security implementation between two SSPs. > > IMHO these two are obsolete. Isn't SF replaced by SDE and MF by DBE? I don't think so...it was my understanding they are in addition to SBE and DBE. Hence, my comments about proxy and SBE earlier. Are we saying an SBE is a proxy...I think of it more like a B2BUA. > > >5. Federations > > Finally, note that a SSP can be a member of > > > > o No federation (e.g., the SSP has only bilateral peering > > agreements) > > I still think that bilateral peerings are special cases of federations > (i.e. one with exactly two members), but I don't insist on that. I thought we agreed a federation must contain more than 2 SSP's. I suggest we update the following sentence: "A federation is a group of SSPs which agree..." to "A federation is a group of three or more SSPs which agree..." Thoughts? > > HTH, > > /ol > > _______________________________________________ > Speermint mailing 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 Oct 27 13:21:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlpJM-0005eZ-EF; Sat, 27 Oct 2007 13:19:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlpJL-0005eO-AW; Sat, 27 Oct 2007 13:18:59 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlpJK-0001SZ-TF; Sat, 27 Oct 2007 13:18:59 -0400 Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l9RHISTj011099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 27 Oct 2007 10:18:34 -0700 From: "Richard Shockey" To: , , Date: Sat, 27 Oct 2007 13:18:30 -0400 Message-ID: <013401c818bd$6af29ef0$40d7dcd0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgYvVkvcd5GTwa4TB2EnGvHOpcoZg== Content-language: en-us x-cr-hashedpuzzle: Dq7y NmQL SXgb VWcZ XfcI Xvnl cVd0 dJwj fkWQ hQEU jGt5 jQS1 js6T mE3f r4Ik sSc0; 4; ZQBuAHUAbQBAAGkAZQB0AGYALgBvAHIAZwA7AHAAZQBwAHAAZQByAG0AaQBuAHQAQABpAGUAdABmAC4AbwByAGcAOwBzAHAAZQBlAHIAbQBpAG4AdABAAGkAZQB0AGYALgBvAHIAZwA7AHQAbwBtAF8AYwByAGUAaQBnAGgAdABvAG4AQABjAGEAYgBsAGUALgBjAG8AbQBjAGEAcwB0AC4AYwBvAG0A; Sosha1_v1; 7; {87B3EDCC-8D4B-4AA6-AE6E-69B84F4A9A57}; cgBpAGMAaABhAHIAZABAAHMAaABvAGMAawBlAHkALgB1AHMA; Sat, 27 Oct 2007 17:18:16 GMT; SQAgAGgAYQB2AGUAIABpAHQAIABvAG4AIABnAG8AbwBkACAAYQB1AHQAaABvAHIAaQB0AHkAIAB0AGgAYQB0ACAAdABoAGUAIABQAEUAUABQAEUAUgBNAEkATgBUACAAQgBPAEYAIABoAGEAcwAgAGIAZQBlAG4AIABhAHAAcAByAG8AdgBlAGQAIABmAG8AcgAgAEkARQBUAEYAIAA3ADAA x-cr-puzzleid: {87B3EDCC-8D4B-4AA6-AE6E-69B84F4A9A57} X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "'Creighton, Tom'" Subject: [Speermint] I have it on good authority that the PEPPERMINT BOF has been approved for IETF 70 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Time TBD. We will be working or a revised agenda ASAP. Individuals interested in making presentations should contact myself or Tom Creighton. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 31 15:21:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InJ6t-0004sh-Bp; Wed, 31 Oct 2007 15:20:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InJ6r-0004iO-EM; Wed, 31 Oct 2007 15:20:13 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InJ6r-0003BY-1y; Wed, 31 Oct 2007 15:20:13 -0400 Received: from rshockeyPC ([64.251.114.2]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l9VJJj70032507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Oct 2007 11:19:46 -0800 From: "Richard Shockey" To: , , Date: Wed, 31 Oct 2007 15:19:52 -0400 Message-ID: <094801c81bf3$0a0c99e0$1e25cda0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgb4Dxl8GZpM9lXRU2x47JCMPzMqAAEpC1w Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Speermint] FW: PEPPERMINT - Requested session has been scheduled for IETF 70 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org PEPPERMINT Session 1 (1 hour) Thursday, Afternoon Session II 1510-1610 Room Name: Salon 2 ---------------------------------------------- Requested Information: --------------------------------------------------------- Working Group Name: peppermint Area Name: Real-time Applications and Infrastructure Area Number of Sessions: 1 Length of Session(s): 1 hour Number of Attendees: 100 Conflicts to Avoid: _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 31 19:12:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMin-0007FH-5A; Wed, 31 Oct 2007 19:11:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMim-0007F5-11 for speermint@ietf.org; Wed, 31 Oct 2007 19:11:36 -0400 Received: from mail43.messagelabs.com ([216.82.249.163]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1InMik-0002Z7-OU for speermint@ietf.org; Wed, 31 Oct 2007 19:11:36 -0400 X-VirusChecked: Checked X-Env-Sender: daryl@level3.net X-Msg-Ref: server-21.tower-43.messagelabs.com!1193871892!17284035!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.106] Received: (qmail 5544 invoked from network); 31 Oct 2007 23:04:52 -0000 Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106) by server-21.tower-43.messagelabs.com with SMTP; 31 Oct 2007 23:04:52 -0000 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f10bb8-10 (Postfix) with ESMTP id 2E5CE4CB4 for ; Wed, 31 Oct 2007 23:04:52 +0000 (GMT) Subject: [Speermint] Updated: draft-ietf-speermint-terminology-13 From: Daryl Malas To: speermint@ietf.org Content-Type: text/plain Date: Wed, 31 Oct 2007 17:13:33 -0600 Message-Id: <1193872413.1297.374.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 order to avoid several revisions prior to Vancouver, I have place an updated draft here: http://www.malas.net-a.googlepages.com/draft-ietf-speermint-terminology-13.txt This revision updates the WGLC of rev 12 discussion points. Please review the draft and provide feedback. Thanks... Daryl _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint