From speermint-bounces@ietf.org Wed Aug 01 06:53: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 1IGBpn-0002tA-9r; Wed, 01 Aug 2007 06:53:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGBpm-0002sp-Ei for speermint@ietf.org; Wed, 01 Aug 2007 06:53:42 -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 1IGBpm-0002Pu-0z for speermint@ietf.org; Wed, 01 Aug 2007 06:53:42 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JM300A0JCNZ7S@siemenscomms.co.uk> for speermint@ietf.org; Wed, 01 Aug 2007 11:47:59 +0100 (BST) Date: Wed, 01 Aug 2007 11:48:13 +0100 From: "Elwell, John" To: speermint@ietf.org, Jean-Francois Mule Message-id: <0D5F89FAC29E2C41B98A6A762007F5D026E7CF@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: Normative language in draft-ietf-speermint-requirements-02 Thread-Index: AcfUKXVJflhMCE7XSpKe8x117zcnmA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Speermint] Normative language in draft-ietf-speermint-requirements-02 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org In an earlier message (http://www1.ietf.org/mail-archive/web/speermint/current/msg02064.html) I commented, amongst other things, on the normative language (RFC2119) in the requirements draft, and suggested that, if the document does indeed specify requirements on SSPs, then the normative language should reflect that. This would be in contrast to most requirements documents from the IETF, which specify requirements on future IETF work (e.g., on protocols, architecture) and therefore use normative language in a different way (e.g., "It MUST be possible to ...", "The mechanism SHOULD provide a means to....", "The solution MUST NOT permit...."). I raised this again during our meeting in Chicago, and it seemed from the discussion there that this draft is intended to place requirements on further work by the SPEERMINT group, and therefore normative language should reflect that. Consequently any statements that appear to place a requirement on an SSP should receive some attention. Looking again at the draft, much of the draft seems to be written in a way that is inconsistent with the view that emerged from the meeting. In particular the Abstract and Introduction position the draft as a BCP for service providers. So I think we need to establish exactly what the purpose of the document is. John _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 03 15:46: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 1IH362-0003xQ-Kb; Fri, 03 Aug 2007 15:46:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH361-0003xL-Ur for speermint@ietf.org; Fri, 03 Aug 2007 15:46:01 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IH361-0005qO-Ho for speermint@ietf.org; Fri, 03 Aug 2007 15:46:01 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l73JjwRI000858 for ; Fri, 3 Aug 2007 19:45:59 GMT Subject: [Speermint] Terminology Draft: New Assisted Peering Verbiage From: Daryl Malas To: speermint@ietf.org Content-Type: text/plain Date: Fri, 03 Aug 2007 13:48:55 -0600 Message-Id: <1186170535.1297.107.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: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org At the conference in Chicago, there was some confusion around the difference between Assisted and Indirect peering. I have updated the Assisted Peering section (4.2.3) to be the following: In this case, some entity (usually a federation, see Section 5) provides peering assistance to either the originating or terminating peer by providing one or more functions (see Section 4.3) on behalf of the peers (which is not itself a SSP) to bridge calls between participating networks. The assisting entity may provide information relating to a direct (Section 4.2.1) or indirect (Section 4.2.2) peer as necessary on behalf of the originating or terminating peer. Please let me know if this clears up the section and eliminates the confusion. If so, I will submit a version -10 tomorrow. Thanks... --Daryl _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 06 03:08: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 1IHwhN-0004Sz-09; Mon, 06 Aug 2007 03:08:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHwhM-0004St-8m for speermint@ietf.org; Mon, 06 Aug 2007 03:08:16 -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 1IHwhL-0007HR-9g for speermint@ietf.org; Mon, 06 Aug 2007 03:08:15 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JMC00I8GBT9DM@siemenscomms.co.uk> for speermint@ietf.org; Mon, 06 Aug 2007 08:07:57 +0100 (BST) Date: Mon, 06 Aug 2007 08:08:14 +0100 From: "Elwell, John" Subject: RE: [Speermint] Terminology Draft: New Assisted Peering Verbiage In-reply-to: <1186170535.1297.107.camel@montag.eng.level3.com> To: Daryl Malas , speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D026E9DD@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] Terminology Draft: New Assisted Peering Verbiage Thread-Index: AcfWBvXdx3mK1dNoQaK0H9EHpkt9swB7nKmg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1186170535.1297.107.camel@montag.eng.level3.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl, This seems to reflect the orthogonality between assisted and direct/indirect peering. I don't think the wording is quite right, however. 1. In the first sentence the words "(which is not itself a SSP)" follow "peers", which is grammatically incorrect. In fact those words are intended to refer to something earlier in the sentence, so the order of the sentence needs changing. 2. It refers to 4.2.1 and 4.2.2 for definitions of "direct peer" and "indirect peer" respectively, yet those sections do not define those terms - the define "direct peering" and "indirect peering". 3. The use of the word "bridge" has connotations of conference mixing. 4. "between participating networks" - shouldn't this be "between participating service providers"? 5. In 4.2.2 we talk about "originating service provider" and "terminating service provider", so we shouldn't switch to saying "originating peer" and terminating peer". The following words would fix these problems (new or revised words in caps): "In this case, some entity (usually a federation, see Section 5) THAT IS NOT ITSELF A SERVICE PROVIDER provides peering assistance to either the originating or terminating SERVICE PROVIDER by providing one or more functions (see Section 4.3) THAT ASSIST IN ESTABLISHING calls between THOSE SERVICE PROVIDERS. The assisting entity may provide information relating to direct (Section 4.2.1) or indirect (Section 4.2.2) PEERING as necessary." John > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: 03 August 2007 20:49 > To: speermint@ietf.org > Subject: [Speermint] Terminology Draft: New Assisted Peering Verbiage > > At the conference in Chicago, there was some confusion around the > difference between Assisted and Indirect peering. I have updated the > Assisted Peering section (4.2.3) to be the following: > > In this case, some entity (usually a federation, see Section > 5) provides > peering assistance to either the originating or terminating peer by > providing one or more functions (see Section 4.3) on behalf > of the peers > (which is not itself a SSP) to bridge calls between participating > networks. The assisting entity may provide information relating to a > direct (Section 4.2.1) or indirect (Section 4.2.2) peer as > necessary on > behalf of the originating or terminating peer. > > Please let me know if this clears up the section and eliminates the > confusion. > > If so, I will submit a version -10 tomorrow. > > Thanks... > > --Daryl > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Aug 06 18:11:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIAnT-000857-OM; Mon, 06 Aug 2007 18:11:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIAnT-000852-2h for speermint@ietf.org; Mon, 06 Aug 2007 18:11:31 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIAnS-0007GT-FH for speermint@ietf.org; Mon, 06 Aug 2007 18:11:30 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l76MBQRI023640; Mon, 6 Aug 2007 22:11:27 GMT Subject: RE: [Speermint] Terminology Draft: New Assisted Peering Verbiage From: Daryl Malas To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D026E9DD@GBNTHT12009MSX.gb002.siemens.net> References: <1186170535.1297.107.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026E9DD@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain Date: Mon, 06 Aug 2007 16:14:35 -0600 Message-Id: <1186438475.1297.131.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: 34d35111647d654d033d58d318c0d21a Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org John, Thanks for the feedback. I can understand how the current verbiage can cause confusion. I would like to suggest the following revision based on your feedback: "In this case, some entity (usually a 3rd party SSP or federation) provides peering assistance to either the originating or terminating SSP by providing one or more functions (see Section 4.3) assisting in the establishment of SIP dialogs between one or more SSP's. The assisting entity may provide information relating to direct (see Section 4.2.1) or indirect (see Section 4.2.2) peering as necessary." In this case, I am including the ability for an individual SSP or federation to provide this capability in an orthogonal manner. I cleaned up the other language to help create the separation I think you are looking for below. Let me know if I accomplished this. --Daryl On Mon, 2007-08-06 at 08:08 +0100, Elwell, John wrote: > Daryl, > > This seems to reflect the orthogonality between assisted and > direct/indirect peering. I don't think the wording is quite right, > however. > > 1. In the first sentence the words "(which is not itself a SSP)" follow > "peers", which is grammatically incorrect. In fact those words are > intended to refer to something earlier in the sentence, so the order of > the sentence needs changing. > > 2. It refers to 4.2.1 and 4.2.2 for definitions of "direct peer" and > "indirect peer" respectively, yet those sections do not define those > terms - the define "direct peering" and "indirect peering". > > 3. The use of the word "bridge" has connotations of conference mixing. > > 4. "between participating networks" - shouldn't this be "between > participating service providers"? > > 5. In 4.2.2 we talk about "originating service provider" and > "terminating service provider", so we shouldn't switch to saying > "originating peer" and terminating peer". > > The following words would fix these problems (new or revised words in > caps): > > "In this case, some entity (usually a federation, see Section 5) THAT IS > NOT ITSELF A SERVICE PROVIDER provides peering assistance to either the > originating or terminating SERVICE PROVIDER by providing one or more > functions (see Section 4.3) THAT ASSIST IN ESTABLISHING calls between > THOSE SERVICE PROVIDERS. The assisting entity may provide information > relating to direct (Section 4.2.1) or indirect (Section 4.2.2) PEERING > as necessary." > > John > > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: 03 August 2007 20:49 > > To: speermint@ietf.org > > Subject: [Speermint] Terminology Draft: New Assisted Peering Verbiage > > > > At the conference in Chicago, there was some confusion around the > > difference between Assisted and Indirect peering. I have updated the > > Assisted Peering section (4.2.3) to be the following: > > > > In this case, some entity (usually a federation, see Section > > 5) provides > > peering assistance to either the originating or terminating peer by > > providing one or more functions (see Section 4.3) on behalf > > of the peers > > (which is not itself a SSP) to bridge calls between participating > > networks. The assisting entity may provide information relating to a > > direct (Section 4.2.1) or indirect (Section 4.2.2) peer as > > necessary on > > behalf of the originating or terminating peer. > > > > Please let me know if this clears up the section and eliminates the > > confusion. > > > > If so, I will submit a version -10 tomorrow. > > > > Thanks... > > > > --Daryl > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Aug 07 04:03: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 1IIK1u-0004Mw-FD; Tue, 07 Aug 2007 04:03:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIK1t-0004Mq-LA for speermint@ietf.org; Tue, 07 Aug 2007 04:03:01 -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 1IIK1s-00034p-RR for speermint@ietf.org; Tue, 07 Aug 2007 04:03:01 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JME0052P90JIW@siemenscomms.co.uk> for speermint@ietf.org; Tue, 07 Aug 2007 09:02:43 +0100 (BST) Date: Tue, 07 Aug 2007 09:02:58 +0100 From: "Elwell, John" Subject: RE: [Speermint] Terminology Draft: New Assisted Peering Verbiage In-reply-to: <1186438475.1297.131.camel@montag.eng.level3.com> To: Daryl Malas Message-id: <0D5F89FAC29E2C41B98A6A762007F5D026EACD@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] Terminology Draft: New Assisted Peering Verbiage Thread-Index: AcfYdsE+PpwUGDk3S+KpB17X4RtGegAUUfyA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1186170535.1297.107.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026E9DD@GBNTHT12009MSX.gb002.siemens.net> <1186438475.1297.131.camel@montag.eng.level3.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl, Compared with my proposal (and also compared with your original proposal), your new proposal does not say that the assisting entity is not an SSP. I agree it could also be an SSP, but when playing the role of an assisting entity it is not acting as an SSP. I don't have a strong objection to your new words, if everyone is happy that we don't need to say that the assisting entity is not an SSP. On a further point, your new proposal talks about dialog establishment rather than calls, which extends its scope (to cover SUBSCRIBE-initiated dialogs). That is fine, but they what about non-dialog-based communications (e.g., using the MESSAGE and PUBLISH methods)? John > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: 06 August 2007 23:15 > To: Elwell, John > Cc: speermint@ietf.org > Subject: RE: [Speermint] Terminology Draft: New Assisted > Peering Verbiage > > John, > > Thanks for the feedback. I can understand how the current > verbiage can > cause confusion. I would like to suggest the following revision based > on your feedback: > > "In this case, some entity (usually a 3rd party SSP or federation) > provides peering assistance to either the originating or > terminating SSP > by providing one or more functions (see Section 4.3) assisting in the > establishment of SIP dialogs between one or more SSP's. The assisting > entity may provide information relating to direct (see > Section 4.2.1) or > indirect (see Section 4.2.2) peering as necessary." > > In this case, I am including the ability for an individual SSP or > federation to provide this capability in an orthogonal manner. I > cleaned up the other language to help create the separation I > think you > are looking for below. Let me know if I accomplished this. > > --Daryl > > On Mon, 2007-08-06 at 08:08 +0100, Elwell, John wrote: > > Daryl, > > > > This seems to reflect the orthogonality between assisted and > > direct/indirect peering. I don't think the wording is quite right, > > however. > > > > 1. In the first sentence the words "(which is not itself a > SSP)" follow > > "peers", which is grammatically incorrect. In fact those words are > > intended to refer to something earlier in the sentence, so > the order of > > the sentence needs changing. > > > > 2. It refers to 4.2.1 and 4.2.2 for definitions of "direct peer" and > > "indirect peer" respectively, yet those sections do not define those > > terms - the define "direct peering" and "indirect peering". > > > > 3. The use of the word "bridge" has connotations of > conference mixing. > > > > 4. "between participating networks" - shouldn't this be "between > > participating service providers"? > > > > 5. In 4.2.2 we talk about "originating service provider" and > > "terminating service provider", so we shouldn't switch to saying > > "originating peer" and terminating peer". > > > > The following words would fix these problems (new or > revised words in > > caps): > > > > "In this case, some entity (usually a federation, see > Section 5) THAT IS > > NOT ITSELF A SERVICE PROVIDER provides peering assistance > to either the > > originating or terminating SERVICE PROVIDER by providing one or more > > functions (see Section 4.3) THAT ASSIST IN ESTABLISHING > calls between > > THOSE SERVICE PROVIDERS. The assisting entity may provide > information > > relating to direct (Section 4.2.1) or indirect (Section > 4.2.2) PEERING > > as necessary." > > > > John > > > > > -----Original Message----- > > > From: Daryl Malas [mailto:daryl@level3.net] > > > Sent: 03 August 2007 20:49 > > > To: speermint@ietf.org > > > Subject: [Speermint] Terminology Draft: New Assisted > Peering Verbiage > > > > > > At the conference in Chicago, there was some confusion around the > > > difference between Assisted and Indirect peering. I have > updated the > > > Assisted Peering section (4.2.3) to be the following: > > > > > > In this case, some entity (usually a federation, see Section > > > 5) provides > > > peering assistance to either the originating or > terminating peer by > > > providing one or more functions (see Section 4.3) on behalf > > > of the peers > > > (which is not itself a SSP) to bridge calls between participating > > > networks. The assisting entity may provide information > relating to a > > > direct (Section 4.2.1) or indirect (Section 4.2.2) peer as > > > necessary on > > > behalf of the originating or terminating peer. > > > > > > Please let me know if this clears up the section and > eliminates the > > > confusion. > > > > > > If so, I will submit a version -10 tomorrow. > > > > > > Thanks... > > > > > > --Daryl > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 09 16:36: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 1IJEkT-0007tv-Kr; Thu, 09 Aug 2007 16:36:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJEkR-0007tX-7W for speermint@ietf.org; Thu, 09 Aug 2007 16:36:47 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJEkP-0004cl-Rz for speermint@ietf.org; Thu, 09 Aug 2007 16:36:47 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l79KagRI029580; Thu, 9 Aug 2007 20:36:43 GMT Subject: RE: [Speermint] Terminology Draft: New Assisted Peering Verbiage From: Daryl Malas To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D026EACD@GBNTHT12009MSX.gb002.siemens.net> References: <1186170535.1297.107.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026E9DD@GBNTHT12009MSX.gb002.siemens.net> <1186438475.1297.131.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026EACD@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain Date: Thu, 09 Aug 2007 14:40:01 -0600 Message-Id: <1186692002.1297.175.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: 0770535483960d190d4a0d020e7060bd Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org John, I guess I see the SSP in question as being capable of serving a dual role as an assisting entity and an SSP, or it could be serving as simply an assisting entity as you stated. Since, no one else seems to be providing feedback, I guess it is up to us to decide. Also, I was trying to broaden the usage of SIP in peering by simply stating "dialog establishment" instead of calls. I think MESSAGE and PUBLISH are also valid SIP messages in peering. Perhaps I should simply state it as SIP messaging or something similar. Thanks for your feedback. --Daryl On Tue, 2007-08-07 at 09:02 +0100, Elwell, John wrote: > Daryl, > > Compared with my proposal (and also compared with your original > proposal), your new proposal does not say that the assisting entity is > not an SSP. I agree it could also be an SSP, but when playing the role > of an assisting entity it is not acting as an SSP. I don't have a strong > objection to your new words, if everyone is happy that we don't need to > say that the assisting entity is not an SSP. > > On a further point, your new proposal talks about dialog establishment > rather than calls, which extends its scope (to cover SUBSCRIBE-initiated > dialogs). That is fine, but they what about non-dialog-based > communications (e.g., using the MESSAGE and PUBLISH methods)? > > John > > > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: 06 August 2007 23:15 > > To: Elwell, John > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Terminology Draft: New Assisted > > Peering Verbiage > > > > John, > > > > Thanks for the feedback. I can understand how the current > > verbiage can > > cause confusion. I would like to suggest the following revision based > > on your feedback: > > > > "In this case, some entity (usually a 3rd party SSP or federation) > > provides peering assistance to either the originating or > > terminating SSP > > by providing one or more functions (see Section 4.3) assisting in the > > establishment of SIP dialogs between one or more SSP's. The assisting > > entity may provide information relating to direct (see > > Section 4.2.1) or > > indirect (see Section 4.2.2) peering as necessary." > > > > In this case, I am including the ability for an individual SSP or > > federation to provide this capability in an orthogonal manner. I > > cleaned up the other language to help create the separation I > > think you > > are looking for below. Let me know if I accomplished this. > > > > --Daryl > > > > On Mon, 2007-08-06 at 08:08 +0100, Elwell, John wrote: > > > Daryl, > > > > > > This seems to reflect the orthogonality between assisted and > > > direct/indirect peering. I don't think the wording is quite right, > > > however. > > > > > > 1. In the first sentence the words "(which is not itself a > > SSP)" follow > > > "peers", which is grammatically incorrect. In fact those words are > > > intended to refer to something earlier in the sentence, so > > the order of > > > the sentence needs changing. > > > > > > 2. It refers to 4.2.1 and 4.2.2 for definitions of "direct peer" and > > > "indirect peer" respectively, yet those sections do not define those > > > terms - the define "direct peering" and "indirect peering". > > > > > > 3. The use of the word "bridge" has connotations of > > conference mixing. > > > > > > 4. "between participating networks" - shouldn't this be "between > > > participating service providers"? > > > > > > 5. In 4.2.2 we talk about "originating service provider" and > > > "terminating service provider", so we shouldn't switch to saying > > > "originating peer" and terminating peer". > > > > > > The following words would fix these problems (new or > > revised words in > > > caps): > > > > > > "In this case, some entity (usually a federation, see > > Section 5) THAT IS > > > NOT ITSELF A SERVICE PROVIDER provides peering assistance > > to either the > > > originating or terminating SERVICE PROVIDER by providing one or more > > > functions (see Section 4.3) THAT ASSIST IN ESTABLISHING > > calls between > > > THOSE SERVICE PROVIDERS. The assisting entity may provide > > information > > > relating to direct (Section 4.2.1) or indirect (Section > > 4.2.2) PEERING > > > as necessary." > > > > > > John > > > > > > > -----Original Message----- > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > Sent: 03 August 2007 20:49 > > > > To: speermint@ietf.org > > > > Subject: [Speermint] Terminology Draft: New Assisted > > Peering Verbiage > > > > > > > > At the conference in Chicago, there was some confusion around the > > > > difference between Assisted and Indirect peering. I have > > updated the > > > > Assisted Peering section (4.2.3) to be the following: > > > > > > > > In this case, some entity (usually a federation, see Section > > > > 5) provides > > > > peering assistance to either the originating or > > terminating peer by > > > > providing one or more functions (see Section 4.3) on behalf > > > > of the peers > > > > (which is not itself a SSP) to bridge calls between participating > > > > networks. The assisting entity may provide information > > relating to a > > > > direct (Section 4.2.1) or indirect (Section 4.2.2) peer as > > > > necessary on > > > > behalf of the originating or terminating peer. > > > > > > > > Please let me know if this clears up the section and > > eliminates the > > > > confusion. > > > > > > > > If so, I will submit a version -10 tomorrow. > > > > > > > > Thanks... > > > > > > > > --Daryl > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Aug 09 20:35: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 1IJISy-0007Fd-PZ; Thu, 09 Aug 2007 20:35:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJISx-0007FP-T5 for speermint@ietf.org; Thu, 09 Aug 2007 20:34:59 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IJISw-0002Mg-4l for speermint@ietf.org; Thu, 09 Aug 2007 20:34:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Terminology Draft: New Assisted Peering Verbiage Date: Fri, 10 Aug 2007 02:32:06 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D466B1DFF@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology Draft: New Assisted Peering Verbiage Thread-Index: AcfaxRBrPFCz4tJ/Ty2jevGE75iJYQAINEKG References: <1186170535.1297.107.camel@montag.eng.level3.com><0D5F89FAC29E2C41B98A6A762007F5D026E9DD@GBNTHT12009MSX.gb002.siemens.net><1186438475.1297.131.camel@montag.eng.level3.com><0D5F89FAC29E2C41B98A6A762007F5D026EACD@GBNTHT12009MSX.gb002.siemens.net> <1186692002.1297.175.camel@montag.eng.level3.com> From: "Stastny Richard" To: "Daryl Malas" , "Elwell, John" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl, =20 I agree with John. =20 In this case we are talking roles, and each role should be uniquely = identified. In practice one entity may always serve more then one role. =20 Richard ________________________________ From: Daryl Malas [mailto:daryl@level3.net] Sent: Thu 09.08.2007 22:40 To: Elwell, John Cc: speermint@ietf.org Subject: RE: [Speermint] Terminology Draft: New Assisted Peering = Verbiage John, I guess I see the SSP in question as being capable of serving a dual role as an assisting entity and an SSP, or it could be serving as simply an assisting entity as you stated. Since, no one else seems to be providing feedback, I guess it is up to us to decide. Also, I was trying to broaden the usage of SIP in peering by simply stating "dialog establishment" instead of calls. I think MESSAGE and PUBLISH are also valid SIP messages in peering. Perhaps I should simply state it as SIP messaging or something similar. Thanks for your feedback. --Daryl On Tue, 2007-08-07 at 09:02 +0100, Elwell, John wrote: > Daryl, > > Compared with my proposal (and also compared with your original > proposal), your new proposal does not say that the assisting entity is > not an SSP. I agree it could also be an SSP, but when playing the role > of an assisting entity it is not acting as an SSP. I don't have a = strong > objection to your new words, if everyone is happy that we don't need = to > say that the assisting entity is not an SSP. > > On a further point, your new proposal talks about dialog establishment > rather than calls, which extends its scope (to cover = SUBSCRIBE-initiated > dialogs). That is fine, but they what about non-dialog-based > communications (e.g., using the MESSAGE and PUBLISH methods)? > > John > > > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: 06 August 2007 23:15 > > To: Elwell, John > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Terminology Draft: New Assisted > > Peering Verbiage > > > > John, > > > > Thanks for the feedback. I can understand how the current > > verbiage can > > cause confusion. I would like to suggest the following revision = based > > on your feedback: > > > > "In this case, some entity (usually a 3rd party SSP or federation) > > provides peering assistance to either the originating or > > terminating SSP > > by providing one or more functions (see Section 4.3) assisting in = the > > establishment of SIP dialogs between one or more SSP's. The = assisting > > entity may provide information relating to direct (see > > Section 4.2.1) or > > indirect (see Section 4.2.2) peering as necessary." > > > > In this case, I am including the ability for an individual SSP or > > federation to provide this capability in an orthogonal manner. I > > cleaned up the other language to help create the separation I > > think you > > are looking for below. Let me know if I accomplished this. > > > > --Daryl > > > > On Mon, 2007-08-06 at 08:08 +0100, Elwell, John wrote: > > > Daryl, > > > > > > This seems to reflect the orthogonality between assisted and > > > direct/indirect peering. I don't think the wording is quite right, > > > however. > > > > > > 1. In the first sentence the words "(which is not itself a > > SSP)" follow > > > "peers", which is grammatically incorrect. In fact those words are > > > intended to refer to something earlier in the sentence, so > > the order of > > > the sentence needs changing. > > > > > > 2. It refers to 4.2.1 and 4.2.2 for definitions of "direct peer" = and > > > "indirect peer" respectively, yet those sections do not define = those > > > terms - the define "direct peering" and "indirect peering". > > > > > > 3. The use of the word "bridge" has connotations of > > conference mixing. > > > > > > 4. "between participating networks" - shouldn't this be "between > > > participating service providers"? > > > > > > 5. In 4.2.2 we talk about "originating service provider" and > > > "terminating service provider", so we shouldn't switch to saying > > > "originating peer" and terminating peer". > > > > > > The following words would fix these problems (new or > > revised words in > > > caps): > > > > > > "In this case, some entity (usually a federation, see > > Section 5) THAT IS > > > NOT ITSELF A SERVICE PROVIDER provides peering assistance > > to either the > > > originating or terminating SERVICE PROVIDER by providing one or = more > > > functions (see Section 4.3) THAT ASSIST IN ESTABLISHING > > calls between > > > THOSE SERVICE PROVIDERS. The assisting entity may provide > > information > > > relating to direct (Section 4.2.1) or indirect (Section > > 4.2.2) PEERING > > > as necessary." > > > > > > John > > > > > > > -----Original Message----- > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > Sent: 03 August 2007 20:49 > > > > To: speermint@ietf.org > > > > Subject: [Speermint] Terminology Draft: New Assisted > > Peering Verbiage > > > > > > > > At the conference in Chicago, there was some confusion around = the > > > > difference between Assisted and Indirect peering. I have > > updated the > > > > Assisted Peering section (4.2.3) to be the following: > > > > > > > > In this case, some entity (usually a federation, see Section > > > > 5) provides > > > > peering assistance to either the originating or > > terminating peer by > > > > providing one or more functions (see Section 4.3) on behalf > > > > of the peers > > > > (which is not itself a SSP) to bridge calls between = participating > > > > networks. The assisting entity may provide information > > relating to a > > > > direct (Section 4.2.1) or indirect (Section 4.2.2) peer as > > > > necessary on > > > > behalf of the originating or terminating peer. > > > > > > > > Please let me know if this clears up the section and > > eliminates the > > > > confusion. > > > > > > > > If so, I will submit a version -10 tomorrow. > > > > > > > > Thanks... > > > > > > > > --Daryl > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 10 02:18: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 1IJNp2-0007v9-SP; Fri, 10 Aug 2007 02:18:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJNp0-0007kV-W0 for speermint@ietf.org; Fri, 10 Aug 2007 02:18:07 -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 1IJNp0-0006dv-0n for speermint@ietf.org; Fri, 10 Aug 2007 02:18:06 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JMJ00J2VO5OEP@siemenscomms.co.uk> for speermint@ietf.org; Fri, 10 Aug 2007 07:17:48 +0100 (BST) Date: Fri, 10 Aug 2007 07:18:04 +0100 From: "Elwell, John" Subject: RE: [Speermint] Terminology Draft: New Assisted Peering Verbiage In-reply-to: <1186692002.1297.175.camel@montag.eng.level3.com> To: Daryl Malas Message-id: <0D5F89FAC29E2C41B98A6A762007F5D026ED81@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] Terminology Draft: New Assisted Peering Verbiage Thread-Index: AcfaxR2X9yi4wdEnRsWjsybUYSI/hwAT4kjw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1186170535.1297.107.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026E9DD@GBNTHT12009MSX.gb002.siemens.net> <1186438475.1297.131.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026EACD@GBNTHT12009MSX.gb002.siemens.net> <1186692002.1297.175.camel@montag.eng.level3.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl, Yes, the dual role is certainly a possibility, but that is not relevant to the definition of assisted. So I would suggest delete "SSP". On the other point, we should use "SIP requests" rather than "SIP messages" or "SIP messaging". However, perhaps it can do more than assisting in the routing of SIP requests, so I think we still need to retain the bit about dialogs as well, and perhaps even mention sessions too (since sessions introduce other considerations). "In this case, some entity (usually a 3rd party or federation) provides peering assistance to either the originating or terminating SSP by providing one or more functions (see Section 4.3) assisting in the routing of SIP requests and the establishment of SIP dialogs and sessions between one or more SSP's. The assisting entity may provide information relating to direct (see Section 4.2.1) or indirect (see Section 4.2.2) peering as necessary." John > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: 09 August 2007 21:40 > To: Elwell, John > Cc: speermint@ietf.org > Subject: RE: [Speermint] Terminology Draft: New Assisted > Peering Verbiage > > John, > > I guess I see the SSP in question as being capable of serving a dual > role as an assisting entity and an SSP, or it could be > serving as simply > an assisting entity as you stated. Since, no one else seems to be > providing feedback, I guess it is up to us to decide. Also, I was > trying to broaden the usage of SIP in peering by simply > stating "dialog > establishment" instead of calls. I think MESSAGE and PUBLISH are also > valid SIP messages in peering. Perhaps I should simply state > it as SIP > messaging or something similar. > > Thanks for your feedback. > > --Daryl > > On Tue, 2007-08-07 at 09:02 +0100, Elwell, John wrote: > > Daryl, > > > > Compared with my proposal (and also compared with your original > > proposal), your new proposal does not say that the > assisting entity is > > not an SSP. I agree it could also be an SSP, but when > playing the role > > of an assisting entity it is not acting as an SSP. I don't > have a strong > > objection to your new words, if everyone is happy that we > don't need to > > say that the assisting entity is not an SSP. > > > > On a further point, your new proposal talks about dialog > establishment > > rather than calls, which extends its scope (to cover > SUBSCRIBE-initiated > > dialogs). That is fine, but they what about non-dialog-based > > communications (e.g., using the MESSAGE and PUBLISH methods)? > > > > John > > > > > > > -----Original Message----- > > > From: Daryl Malas [mailto:daryl@level3.net] > > > Sent: 06 August 2007 23:15 > > > To: Elwell, John > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Terminology Draft: New Assisted > > > Peering Verbiage > > > > > > John, > > > > > > Thanks for the feedback. I can understand how the current > > > verbiage can > > > cause confusion. I would like to suggest the following > revision based > > > on your feedback: > > > > > > "In this case, some entity (usually a 3rd party SSP or federation) > > > provides peering assistance to either the originating or > > > terminating SSP > > > by providing one or more functions (see Section 4.3) > assisting in the > > > establishment of SIP dialogs between one or more SSP's. > The assisting > > > entity may provide information relating to direct (see > > > Section 4.2.1) or > > > indirect (see Section 4.2.2) peering as necessary." > > > > > > In this case, I am including the ability for an individual SSP or > > > federation to provide this capability in an orthogonal manner. I > > > cleaned up the other language to help create the separation I > > > think you > > > are looking for below. Let me know if I accomplished this. > > > > > > --Daryl > > > > > > On Mon, 2007-08-06 at 08:08 +0100, Elwell, John wrote: > > > > Daryl, > > > > > > > > This seems to reflect the orthogonality between assisted and > > > > direct/indirect peering. I don't think the wording is > quite right, > > > > however. > > > > > > > > 1. In the first sentence the words "(which is not itself a > > > SSP)" follow > > > > "peers", which is grammatically incorrect. In fact > those words are > > > > intended to refer to something earlier in the sentence, so > > > the order of > > > > the sentence needs changing. > > > > > > > > 2. It refers to 4.2.1 and 4.2.2 for definitions of > "direct peer" and > > > > "indirect peer" respectively, yet those sections do not > define those > > > > terms - the define "direct peering" and "indirect peering". > > > > > > > > 3. The use of the word "bridge" has connotations of > > > conference mixing. > > > > > > > > 4. "between participating networks" - shouldn't this > be "between > > > > participating service providers"? > > > > > > > > 5. In 4.2.2 we talk about "originating service provider" and > > > > "terminating service provider", so we shouldn't switch to saying > > > > "originating peer" and terminating peer". > > > > > > > > The following words would fix these problems (new or > > > revised words in > > > > caps): > > > > > > > > "In this case, some entity (usually a federation, see > > > Section 5) THAT IS > > > > NOT ITSELF A SERVICE PROVIDER provides peering assistance > > > to either the > > > > originating or terminating SERVICE PROVIDER by > providing one or more > > > > functions (see Section 4.3) THAT ASSIST IN ESTABLISHING > > > calls between > > > > THOSE SERVICE PROVIDERS. The assisting entity may provide > > > information > > > > relating to direct (Section 4.2.1) or indirect (Section > > > 4.2.2) PEERING > > > > as necessary." > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > > Sent: 03 August 2007 20:49 > > > > > To: speermint@ietf.org > > > > > Subject: [Speermint] Terminology Draft: New Assisted > > > Peering Verbiage > > > > > > > > > > At the conference in Chicago, there was some > confusion around the > > > > > difference between Assisted and Indirect peering. I have > > > updated the > > > > > Assisted Peering section (4.2.3) to be the following: > > > > > > > > > > In this case, some entity (usually a federation, see Section > > > > > 5) provides > > > > > peering assistance to either the originating or > > > terminating peer by > > > > > providing one or more functions (see Section 4.3) on behalf > > > > > of the peers > > > > > (which is not itself a SSP) to bridge calls between > participating > > > > > networks. The assisting entity may provide information > > > relating to a > > > > > direct (Section 4.2.1) or indirect (Section 4.2.2) peer as > > > > > necessary on > > > > > behalf of the originating or terminating peer. > > > > > > > > > > Please let me know if this clears up the section and > > > eliminates the > > > > > confusion. > > > > > > > > > > If so, I will submit a version -10 tomorrow. > > > > > > > > > > Thanks... > > > > > > > > > > --Daryl > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 10 10:43: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 1IJViH-0001DC-SH; Fri, 10 Aug 2007 10:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJViH-0001D7-66 for speermint@ietf.org; Fri, 10 Aug 2007 10:43:41 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJViF-0007Hy-UC for speermint@ietf.org; Fri, 10 Aug 2007 10:43:41 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l7AEhJRI020130; Fri, 10 Aug 2007 14:43:19 GMT Subject: RE: [Speermint] Terminology Draft: New Assisted Peering Verbiage From: Daryl Malas To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D026ED81@GBNTHT12009MSX.gb002.siemens.net> References: <1186170535.1297.107.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026E9DD@GBNTHT12009MSX.gb002.siemens.net> <1186438475.1297.131.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026EACD@GBNTHT12009MSX.gb002.siemens.net> <1186692002.1297.175.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026ED81@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain Date: Fri, 10 Aug 2007 08:46:42 -0600 Message-Id: <1186757202.1297.177.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: bacfc6c7290e34d410f9bc22b825ce96 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org That works for me. I will update the draft. Since, this is the last revision necessary from Chicago, I will submit a new version of the draft today unless anyone else has any issues. Thanks... --Daryl On Fri, 2007-08-10 at 07:18 +0100, Elwell, John wrote: > Daryl, > > Yes, the dual role is certainly a possibility, but that is not relevant > to the definition of assisted. So I would suggest delete "SSP". > > On the other point, we should use "SIP requests" rather than "SIP > messages" or "SIP messaging". However, perhaps it can do more than > assisting in the routing of SIP requests, so I think we still need to > retain the bit about dialogs as well, and perhaps even mention sessions > too (since sessions introduce other considerations). > > "In this case, some entity (usually a 3rd party or federation) > provides peering assistance to either the originating or terminating SSP > by providing one or more functions (see Section 4.3) assisting in the > routing of SIP requests and the establishment of SIP dialogs and > sessions > between one or more SSP's. The assisting > entity may provide information relating to direct (see Section 4.2.1) or > indirect (see Section 4.2.2) peering as necessary." > > John > > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: 09 August 2007 21:40 > > To: Elwell, John > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Terminology Draft: New Assisted > > Peering Verbiage > > > > John, > > > > I guess I see the SSP in question as being capable of serving a dual > > role as an assisting entity and an SSP, or it could be > > serving as simply > > an assisting entity as you stated. Since, no one else seems to be > > providing feedback, I guess it is up to us to decide. Also, I was > > trying to broaden the usage of SIP in peering by simply > > stating "dialog > > establishment" instead of calls. I think MESSAGE and PUBLISH are also > > valid SIP messages in peering. Perhaps I should simply state > > it as SIP > > messaging or something similar. > > > > Thanks for your feedback. > > > > --Daryl > > > > On Tue, 2007-08-07 at 09:02 +0100, Elwell, John wrote: > > > Daryl, > > > > > > Compared with my proposal (and also compared with your original > > > proposal), your new proposal does not say that the > > assisting entity is > > > not an SSP. I agree it could also be an SSP, but when > > playing the role > > > of an assisting entity it is not acting as an SSP. I don't > > have a strong > > > objection to your new words, if everyone is happy that we > > don't need to > > > say that the assisting entity is not an SSP. > > > > > > On a further point, your new proposal talks about dialog > > establishment > > > rather than calls, which extends its scope (to cover > > SUBSCRIBE-initiated > > > dialogs). That is fine, but they what about non-dialog-based > > > communications (e.g., using the MESSAGE and PUBLISH methods)? > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > Sent: 06 August 2007 23:15 > > > > To: Elwell, John > > > > Cc: speermint@ietf.org > > > > Subject: RE: [Speermint] Terminology Draft: New Assisted > > > > Peering Verbiage > > > > > > > > John, > > > > > > > > Thanks for the feedback. I can understand how the current > > > > verbiage can > > > > cause confusion. I would like to suggest the following > > revision based > > > > on your feedback: > > > > > > > > "In this case, some entity (usually a 3rd party SSP or federation) > > > > provides peering assistance to either the originating or > > > > terminating SSP > > > > by providing one or more functions (see Section 4.3) > > assisting in the > > > > establishment of SIP dialogs between one or more SSP's. > > The assisting > > > > entity may provide information relating to direct (see > > > > Section 4.2.1) or > > > > indirect (see Section 4.2.2) peering as necessary." > > > > > > > > In this case, I am including the ability for an individual SSP or > > > > federation to provide this capability in an orthogonal manner. I > > > > cleaned up the other language to help create the separation I > > > > think you > > > > are looking for below. Let me know if I accomplished this. > > > > > > > > --Daryl > > > > > > > > On Mon, 2007-08-06 at 08:08 +0100, Elwell, John wrote: > > > > > Daryl, > > > > > > > > > > This seems to reflect the orthogonality between assisted and > > > > > direct/indirect peering. I don't think the wording is > > quite right, > > > > > however. > > > > > > > > > > 1. In the first sentence the words "(which is not itself a > > > > SSP)" follow > > > > > "peers", which is grammatically incorrect. In fact > > those words are > > > > > intended to refer to something earlier in the sentence, so > > > > the order of > > > > > the sentence needs changing. > > > > > > > > > > 2. It refers to 4.2.1 and 4.2.2 for definitions of > > "direct peer" and > > > > > "indirect peer" respectively, yet those sections do not > > define those > > > > > terms - the define "direct peering" and "indirect peering". > > > > > > > > > > 3. The use of the word "bridge" has connotations of > > > > conference mixing. > > > > > > > > > > 4. "between participating networks" - shouldn't this > > be "between > > > > > participating service providers"? > > > > > > > > > > 5. In 4.2.2 we talk about "originating service provider" and > > > > > "terminating service provider", so we shouldn't switch to saying > > > > > "originating peer" and terminating peer". > > > > > > > > > > The following words would fix these problems (new or > > > > revised words in > > > > > caps): > > > > > > > > > > "In this case, some entity (usually a federation, see > > > > Section 5) THAT IS > > > > > NOT ITSELF A SERVICE PROVIDER provides peering assistance > > > > to either the > > > > > originating or terminating SERVICE PROVIDER by > > providing one or more > > > > > functions (see Section 4.3) THAT ASSIST IN ESTABLISHING > > > > calls between > > > > > THOSE SERVICE PROVIDERS. The assisting entity may provide > > > > information > > > > > relating to direct (Section 4.2.1) or indirect (Section > > > > 4.2.2) PEERING > > > > > as necessary." > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > > > Sent: 03 August 2007 20:49 > > > > > > To: speermint@ietf.org > > > > > > Subject: [Speermint] Terminology Draft: New Assisted > > > > Peering Verbiage > > > > > > > > > > > > At the conference in Chicago, there was some > > confusion around the > > > > > > difference between Assisted and Indirect peering. I have > > > > updated the > > > > > > Assisted Peering section (4.2.3) to be the following: > > > > > > > > > > > > In this case, some entity (usually a federation, see Section > > > > > > 5) provides > > > > > > peering assistance to either the originating or > > > > terminating peer by > > > > > > providing one or more functions (see Section 4.3) on behalf > > > > > > of the peers > > > > > > (which is not itself a SSP) to bridge calls between > > participating > > > > > > networks. The assisting entity may provide information > > > > relating to a > > > > > > direct (Section 4.2.1) or indirect (Section 4.2.2) peer as > > > > > > necessary on > > > > > > behalf of the originating or terminating peer. > > > > > > > > > > > > Please let me know if this clears up the section and > > > > eliminates the > > > > > > confusion. > > > > > > > > > > > > If so, I will submit a version -10 tomorrow. > > > > > > > > > > > > Thanks... > > > > > > > > > > > > --Daryl > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Speermint mailing list > > > > > > Speermint@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 10 10:44: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 1IJVip-0001OE-Lh; Fri, 10 Aug 2007 10:44:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJVio-0001O3-5K for speermint@ietf.org; Fri, 10 Aug 2007 10:44:14 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJVim-0007Ig-T4 for speermint@ietf.org; Fri, 10 Aug 2007 10:44:14 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l7AEi8RI020675; Fri, 10 Aug 2007 14:44:10 GMT Subject: RE: [Speermint] Terminology Draft: New Assisted Peering Verbiage From: Daryl Malas To: Stastny Richard In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466B1DFF@oefeg-s04.oefeg.loc> References: <1186170535.1297.107.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026E9DD@GBNTHT12009MSX.gb002.siemens.net> <1186438475.1297.131.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026EACD@GBNTHT12009MSX.gb002.siemens.net> <1186692002.1297.175.camel@montag.eng.level3.com> <32755D354E6B65498C3BD9FD496C7D466B1DFF@oefeg-s04.oefeg.loc> Content-Type: text/plain Date: Fri, 10 Aug 2007 08:47:31 -0600 Message-Id: <1186757251.1297.179.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: ccfb4541e989aa743998098cd315d0fd Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Thanks for the feedback. I am updating the draft to align with this. --Daryl On Fri, 2007-08-10 at 02:32 +0200, Stastny Richard wrote: > Daryl, > > I agree with John. > > In this case we are talking roles, and each role should be uniquely identified. > In practice one entity may always serve more then one role. > > Richard > > ________________________________ > > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Thu 09.08.2007 22:40 > To: Elwell, John > Cc: speermint@ietf.org > Subject: RE: [Speermint] Terminology Draft: New Assisted Peering Verbiage > > > > John, > > I guess I see the SSP in question as being capable of serving a dual > role as an assisting entity and an SSP, or it could be serving as simply > an assisting entity as you stated. Since, no one else seems to be > providing feedback, I guess it is up to us to decide. Also, I was > trying to broaden the usage of SIP in peering by simply stating "dialog > establishment" instead of calls. I think MESSAGE and PUBLISH are also > valid SIP messages in peering. Perhaps I should simply state it as SIP > messaging or something similar. > > Thanks for your feedback. > > --Daryl > > On Tue, 2007-08-07 at 09:02 +0100, Elwell, John wrote: > > Daryl, > > > > Compared with my proposal (and also compared with your original > > proposal), your new proposal does not say that the assisting entity is > > not an SSP. I agree it could also be an SSP, but when playing the role > > of an assisting entity it is not acting as an SSP. I don't have a strong > > objection to your new words, if everyone is happy that we don't need to > > say that the assisting entity is not an SSP. > > > > On a further point, your new proposal talks about dialog establishment > > rather than calls, which extends its scope (to cover SUBSCRIBE-initiated > > dialogs). That is fine, but they what about non-dialog-based > > communications (e.g., using the MESSAGE and PUBLISH methods)? > > > > John > > > > > > > -----Original Message----- > > > From: Daryl Malas [mailto:daryl@level3.net] > > > Sent: 06 August 2007 23:15 > > > To: Elwell, John > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Terminology Draft: New Assisted > > > Peering Verbiage > > > > > > John, > > > > > > Thanks for the feedback. I can understand how the current > > > verbiage can > > > cause confusion. I would like to suggest the following revision based > > > on your feedback: > > > > > > "In this case, some entity (usually a 3rd party SSP or federation) > > > provides peering assistance to either the originating or > > > terminating SSP > > > by providing one or more functions (see Section 4.3) assisting in the > > > establishment of SIP dialogs between one or more SSP's. The assisting > > > entity may provide information relating to direct (see > > > Section 4.2.1) or > > > indirect (see Section 4.2.2) peering as necessary." > > > > > > In this case, I am including the ability for an individual SSP or > > > federation to provide this capability in an orthogonal manner. I > > > cleaned up the other language to help create the separation I > > > think you > > > are looking for below. Let me know if I accomplished this. > > > > > > --Daryl > > > > > > On Mon, 2007-08-06 at 08:08 +0100, Elwell, John wrote: > > > > Daryl, > > > > > > > > This seems to reflect the orthogonality between assisted and > > > > direct/indirect peering. I don't think the wording is quite right, > > > > however. > > > > > > > > 1. In the first sentence the words "(which is not itself a > > > SSP)" follow > > > > "peers", which is grammatically incorrect. In fact those words are > > > > intended to refer to something earlier in the sentence, so > > > the order of > > > > the sentence needs changing. > > > > > > > > 2. It refers to 4.2.1 and 4.2.2 for definitions of "direct peer" and > > > > "indirect peer" respectively, yet those sections do not define those > > > > terms - the define "direct peering" and "indirect peering". > > > > > > > > 3. The use of the word "bridge" has connotations of > > > conference mixing. > > > > > > > > 4. "between participating networks" - shouldn't this be "between > > > > participating service providers"? > > > > > > > > 5. In 4.2.2 we talk about "originating service provider" and > > > > "terminating service provider", so we shouldn't switch to saying > > > > "originating peer" and terminating peer". > > > > > > > > The following words would fix these problems (new or > > > revised words in > > > > caps): > > > > > > > > "In this case, some entity (usually a federation, see > > > Section 5) THAT IS > > > > NOT ITSELF A SERVICE PROVIDER provides peering assistance > > > to either the > > > > originating or terminating SERVICE PROVIDER by providing one or more > > > > functions (see Section 4.3) THAT ASSIST IN ESTABLISHING > > > calls between > > > > THOSE SERVICE PROVIDERS. The assisting entity may provide > > > information > > > > relating to direct (Section 4.2.1) or indirect (Section > > > 4.2.2) PEERING > > > > as necessary." > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > > Sent: 03 August 2007 20:49 > > > > > To: speermint@ietf.org > > > > > Subject: [Speermint] Terminology Draft: New Assisted > > > Peering Verbiage > > > > > > > > > > At the conference in Chicago, there was some confusion around the > > > > > difference between Assisted and Indirect peering. I have > > > updated the > > > > > Assisted Peering section (4.2.3) to be the following: > > > > > > > > > > In this case, some entity (usually a federation, see Section > > > > > 5) provides > > > > > peering assistance to either the originating or > > > terminating peer by > > > > > providing one or more functions (see Section 4.3) on behalf > > > > > of the peers > > > > > (which is not itself a SSP) to bridge calls between participating > > > > > networks. The assisting entity may provide information > > > relating to a > > > > > direct (Section 4.2.1) or indirect (Section 4.2.2) peer as > > > > > necessary on > > > > > behalf of the originating or terminating peer. > > > > > > > > > > Please let me know if this clears up the section and > > > eliminates the > > > > > confusion. > > > > > > > > > > If so, I will submit a version -10 tomorrow. > > > > > > > > > > Thanks... > > > > > > > > > > --Daryl > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 10 10:53: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 1IJVrU-0001LW-5G; Fri, 10 Aug 2007 10:53:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJVrS-0001LO-IS for speermint@ietf.org; Fri, 10 Aug 2007 10:53:10 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJVrR-0007W7-3I for speermint@ietf.org; Fri, 10 Aug 2007 10:53:10 -0400 Received: from unknown (HELO 300815ANEX3.global.avaya.com) ([198.152.6.138]) by co300216-co-outbound.avaya.com with ESMTP; 10 Aug 2007 10:53:08 -0400 X-IronPort-AV: i="4.19,245,1183348800"; d="scan'208"; a="52162513:sNHT114146148" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Terminology Draft: New Assisted Peering Verbiage Date: Fri, 10 Aug 2007 10:52:11 -0400 Message-ID: <3036F4A94122BD4AAAAB441FE88845283C2D3A@300815ANEX3.global.avaya.com> In-Reply-To: <1186757202.1297.177.camel@montag.eng.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology Draft: New Assisted Peering Verbiage Thread-Index: AcfbXN/ZUWWp/opCQY+niGL/O6duZwAAHfaA References: <1186170535.1297.107.camel@montag.eng.level3.com><0D5F89FAC29E2C41B98A6A762007F5D026E9DD@GBNTHT12009MSX.gb002.siemens.net><1186438475.1297.131.camel@montag.eng.level3.com><0D5F89FAC29E2C41B98A6A762007F5D026EACD@GBNTHT12009MSX.gb002.siemens.net><1186692002.1297.175.camel@montag.eng.level3.com><0D5F89FAC29E2C41B98A6A762007F5D026ED81@GBNTHT12009MSX.gb002.siemens.net> <1186757202.1297.177.camel@montag.eng.level3.com> From: "Rodrig, Benny (Benny)" To: "Daryl Malas" , "Elwell, John" X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 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 What does "between one or more SSP's" mean here? Does it imply some use case involving just one SSP? Why not say just "between SSP's"? Benny -----Original Message----- From: Daryl Malas [mailto:daryl@level3.net]=20 Sent: Friday, August 10, 2007 10:47 AM To: Elwell, John Cc: speermint@ietf.org Subject: RE: [Speermint] Terminology Draft: New Assisted Peering Verbiage That works for me. I will update the draft. Since, this is the last revision necessary from Chicago, I will submit a new version of the draft today unless anyone else has any issues. Thanks... --Daryl On Fri, 2007-08-10 at 07:18 +0100, Elwell, John wrote: > Daryl, >=20 > Yes, the dual role is certainly a possibility, but that is not=20 > relevant to the definition of assisted. So I would suggest delete "SSP". >=20 > On the other point, we should use "SIP requests" rather than "SIP=20 > messages" or "SIP messaging". However, perhaps it can do more than=20 > assisting in the routing of SIP requests, so I think we still need to=20 > retain the bit about dialogs as well, and perhaps even mention=20 > sessions too (since sessions introduce other considerations). >=20 > "In this case, some entity (usually a 3rd party or federation)=20 > provides peering assistance to either the originating or terminating=20 > SSP by providing one or more functions (see Section 4.3) assisting in=20 > the routing of SIP requests and the establishment of SIP dialogs and=20 > sessions between one or more SSP's. The assisting entity may provide=20 > information relating to direct (see Section 4.2.1) or indirect (see=20 > Section 4.2.2) peering as necessary." >=20 > John >=20 > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: 09 August 2007 21:40 > > To: Elwell, John > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Terminology Draft: New Assisted Peering=20 > > Verbiage > >=20 > > John, > >=20 > > I guess I see the SSP in question as being capable of serving a dual > > role as an assisting entity and an SSP, or it could be serving as=20 > > simply an assisting entity as you stated. Since, no one else seems=20 > > to be providing feedback, I guess it is up to us to decide. Also, I=20 > > was trying to broaden the usage of SIP in peering by simply stating=20 > > "dialog establishment" instead of calls. I think MESSAGE and=20 > > PUBLISH are also valid SIP messages in peering. Perhaps I should=20 > > simply state it as SIP messaging or something similar. > >=20 > > Thanks for your feedback. > >=20 > > --Daryl > >=20 > > On Tue, 2007-08-07 at 09:02 +0100, Elwell, John wrote: > > > Daryl, > > >=20 > > > Compared with my proposal (and also compared with your original=20 > > > proposal), your new proposal does not say that the > > assisting entity is > > > not an SSP. I agree it could also be an SSP, but when > > playing the role > > > of an assisting entity it is not acting as an SSP. I don't > > have a strong > > > objection to your new words, if everyone is happy that we > > don't need to > > > say that the assisting entity is not an SSP. > > >=20 > > > On a further point, your new proposal talks about dialog > > establishment > > > rather than calls, which extends its scope (to cover > > SUBSCRIBE-initiated > > > dialogs). That is fine, but they what about non-dialog-based=20 > > > communications (e.g., using the MESSAGE and PUBLISH methods)? > > >=20 > > > John > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > Sent: 06 August 2007 23:15 > > > > To: Elwell, John > > > > Cc: speermint@ietf.org > > > > Subject: RE: [Speermint] Terminology Draft: New Assisted Peering > > > > Verbiage > > > >=20 > > > > John, > > > >=20 > > > > Thanks for the feedback. I can understand how the current=20 > > > > verbiage can cause confusion. I would like to suggest the=20 > > > > following > > revision based > > > > on your feedback: > > > >=20 > > > > "In this case, some entity (usually a 3rd party SSP or=20 > > > > federation) provides peering assistance to either the=20 > > > > originating or terminating SSP by providing one or more=20 > > > > functions (see Section 4.3) > > assisting in the > > > > establishment of SIP dialogs between one or more SSP's. =20 > > The assisting > > > > entity may provide information relating to direct (see Section=20 > > > > 4.2.1) or indirect (see Section 4.2.2) peering as necessary." > > > >=20 > > > > In this case, I am including the ability for an individual SSP=20 > > > > or federation to provide this capability in an orthogonal=20 > > > > manner. I cleaned up the other language to help create the=20 > > > > separation I think you are looking for below. Let me know if I=20 > > > > accomplished this. > > > >=20 > > > > --Daryl > > > >=20 > > > > On Mon, 2007-08-06 at 08:08 +0100, Elwell, John wrote: > > > > > Daryl, > > > > >=20 > > > > > This seems to reflect the orthogonality between assisted and=20 > > > > > direct/indirect peering. I don't think the wording is > > quite right, > > > > > however. > > > > >=20 > > > > > 1. In the first sentence the words "(which is not itself a > > > > SSP)" follow > > > > > "peers", which is grammatically incorrect. In fact > > those words are > > > > > intended to refer to something earlier in the sentence, so > > > > the order of > > > > > the sentence needs changing. > > > > >=20 > > > > > 2. It refers to 4.2.1 and 4.2.2 for definitions of > > "direct peer" and > > > > > "indirect peer" respectively, yet those sections do not > > define those > > > > > terms - the define "direct peering" and "indirect peering". > > > > >=20 > > > > > 3. The use of the word "bridge" has connotations of > > > > conference mixing. > > > > >=20 > > > > > 4. "between participating networks" - shouldn't this > > be "between > > > > > participating service providers"? > > > > >=20 > > > > > 5. In 4.2.2 we talk about "originating service provider" and=20 > > > > > "terminating service provider", so we shouldn't switch to=20 > > > > > saying "originating peer" and terminating peer". > > > > >=20 > > > > > The following words would fix these problems (new or > > > > revised words in > > > > > caps): > > > > >=20 > > > > > "In this case, some entity (usually a federation, see > > > > Section 5) THAT IS > > > > > NOT ITSELF A SERVICE PROVIDER provides peering assistance > > > > to either the > > > > > originating or terminating SERVICE PROVIDER by > > providing one or more > > > > > functions (see Section 4.3) THAT ASSIST IN ESTABLISHING > > > > calls between > > > > > THOSE SERVICE PROVIDERS. The assisting entity may provide > > > > information > > > > > relating to direct (Section 4.2.1) or indirect (Section > > > > 4.2.2) PEERING > > > > > as necessary."=20 > > > > >=20 > > > > > John > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > > > Sent: 03 August 2007 20:49 > > > > > > To: speermint@ietf.org > > > > > > Subject: [Speermint] Terminology Draft: New Assisted > > > > Peering Verbiage > > > > > >=20 > > > > > > At the conference in Chicago, there was some > > confusion around the > > > > > > difference between Assisted and Indirect peering. I have > > > > updated the > > > > > > Assisted Peering section (4.2.3) to be the following: > > > > > >=20 > > > > > > In this case, some entity (usually a federation, see Section > > > > > > 5) provides > > > > > > peering assistance to either the originating or > > > > terminating peer by > > > > > > providing one or more functions (see Section 4.3) on behalf=20 > > > > > > of the peers (which is not itself a SSP) to bridge calls=20 > > > > > > between > > participating > > > > > > networks. The assisting entity may provide information > > > > relating to a > > > > > > direct (Section 4.2.1) or indirect (Section 4.2.2) peer as=20 > > > > > > necessary on behalf of the originating or terminating peer. > > > > > >=20 > > > > > > Please let me know if this clears up the section and > > > > eliminates the > > > > > > confusion. > > > > > >=20 > > > > > > If so, I will submit a version -10 tomorrow. > > > > > >=20 > > > > > > Thanks... > > > > > >=20 > > > > > > --Daryl > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Speermint mailing list > > > > > > Speermint@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > >=20 > > > >=20 > > > >=20 > >=20 > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 10 10:56: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 1IJVuO-0004Lb-NT; Fri, 10 Aug 2007 10:56:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJVuN-0004Gs-BX for speermint@ietf.org; Fri, 10 Aug 2007 10:56:11 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJVuM-0007Zg-0B for speermint@ietf.org; Fri, 10 Aug 2007 10:56:11 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l7AEu5RI026576; Fri, 10 Aug 2007 14:56:05 GMT Subject: RE: [Speermint] Terminology Draft: New Assisted Peering Verbiage From: Daryl Malas To: "Rodrig, Benny (Benny)" In-Reply-To: <3036F4A94122BD4AAAAB441FE88845283C2D3A@300815ANEX3.global.avaya.com> References: <1186170535.1297.107.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026E9DD@GBNTHT12009MSX.gb002.siemens.net> <1186438475.1297.131.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026EACD@GBNTHT12009MSX.gb002.siemens.net> <1186692002.1297.175.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026ED81@GBNTHT12009MSX.gb002.siemens.net> <1186757202.1297.177.camel@montag.eng.level3.com> <3036F4A94122BD4AAAAB441FE88845283C2D3A@300815ANEX3.global.avaya.com> Content-Type: text/plain Date: Fri, 10 Aug 2007 08:59:28 -0600 Message-Id: <1186757968.1297.181.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: 6a45e05c1e4343200aa6b327df2c43fc 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 Meaning it is a relationship between an originating SSP and one or more SSP peers. --Daryl On Fri, 2007-08-10 at 10:52 -0400, Rodrig, Benny (Benny) wrote: > What does "between one or more SSP's" mean here? Does it imply some use > case involving just one SSP? Why not say just "between SSP's"? > > Benny > > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Friday, August 10, 2007 10:47 AM > To: Elwell, John > Cc: speermint@ietf.org > Subject: RE: [Speermint] Terminology Draft: New Assisted Peering > Verbiage > > That works for me. I will update the draft. Since, this is the last > revision necessary from Chicago, I will submit a new version of the > draft today unless anyone else has any issues. > > Thanks... > > --Daryl > > On Fri, 2007-08-10 at 07:18 +0100, Elwell, John wrote: > > Daryl, > > > > Yes, the dual role is certainly a possibility, but that is not > > relevant to the definition of assisted. So I would suggest delete > "SSP". > > > > On the other point, we should use "SIP requests" rather than "SIP > > messages" or "SIP messaging". However, perhaps it can do more than > > assisting in the routing of SIP requests, so I think we still need to > > retain the bit about dialogs as well, and perhaps even mention > > sessions too (since sessions introduce other considerations). > > > > "In this case, some entity (usually a 3rd party or federation) > > provides peering assistance to either the originating or terminating > > SSP by providing one or more functions (see Section 4.3) assisting in > > the routing of SIP requests and the establishment of SIP dialogs and > > sessions between one or more SSP's. The assisting entity may provide > > information relating to direct (see Section 4.2.1) or indirect (see > > Section 4.2.2) peering as necessary." > > > > John > > > > > -----Original Message----- > > > From: Daryl Malas [mailto:daryl@level3.net] > > > Sent: 09 August 2007 21:40 > > > To: Elwell, John > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Terminology Draft: New Assisted Peering > > > Verbiage > > > > > > John, > > > > > > I guess I see the SSP in question as being capable of serving a dual > > > > role as an assisting entity and an SSP, or it could be serving as > > > simply an assisting entity as you stated. Since, no one else seems > > > to be providing feedback, I guess it is up to us to decide. Also, I > > > was trying to broaden the usage of SIP in peering by simply stating > > > "dialog establishment" instead of calls. I think MESSAGE and > > > PUBLISH are also valid SIP messages in peering. Perhaps I should > > > simply state it as SIP messaging or something similar. > > > > > > Thanks for your feedback. > > > > > > --Daryl > > > > > > On Tue, 2007-08-07 at 09:02 +0100, Elwell, John wrote: > > > > Daryl, > > > > > > > > Compared with my proposal (and also compared with your original > > > > proposal), your new proposal does not say that the > > > assisting entity is > > > > not an SSP. I agree it could also be an SSP, but when > > > playing the role > > > > of an assisting entity it is not acting as an SSP. I don't > > > have a strong > > > > objection to your new words, if everyone is happy that we > > > don't need to > > > > say that the assisting entity is not an SSP. > > > > > > > > On a further point, your new proposal talks about dialog > > > establishment > > > > rather than calls, which extends its scope (to cover > > > SUBSCRIBE-initiated > > > > dialogs). That is fine, but they what about non-dialog-based > > > > communications (e.g., using the MESSAGE and PUBLISH methods)? > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > > Sent: 06 August 2007 23:15 > > > > > To: Elwell, John > > > > > Cc: speermint@ietf.org > > > > > Subject: RE: [Speermint] Terminology Draft: New Assisted Peering > > > > > > Verbiage > > > > > > > > > > John, > > > > > > > > > > Thanks for the feedback. I can understand how the current > > > > > verbiage can cause confusion. I would like to suggest the > > > > > following > > > revision based > > > > > on your feedback: > > > > > > > > > > "In this case, some entity (usually a 3rd party SSP or > > > > > federation) provides peering assistance to either the > > > > > originating or terminating SSP by providing one or more > > > > > functions (see Section 4.3) > > > assisting in the > > > > > establishment of SIP dialogs between one or more SSP's. > > > The assisting > > > > > entity may provide information relating to direct (see Section > > > > > 4.2.1) or indirect (see Section 4.2.2) peering as necessary." > > > > > > > > > > In this case, I am including the ability for an individual SSP > > > > > or federation to provide this capability in an orthogonal > > > > > manner. I cleaned up the other language to help create the > > > > > separation I think you are looking for below. Let me know if I > > > > > accomplished this. > > > > > > > > > > --Daryl > > > > > > > > > > On Mon, 2007-08-06 at 08:08 +0100, Elwell, John wrote: > > > > > > Daryl, > > > > > > > > > > > > This seems to reflect the orthogonality between assisted and > > > > > > direct/indirect peering. I don't think the wording is > > > quite right, > > > > > > however. > > > > > > > > > > > > 1. In the first sentence the words "(which is not itself a > > > > > SSP)" follow > > > > > > "peers", which is grammatically incorrect. In fact > > > those words are > > > > > > intended to refer to something earlier in the sentence, so > > > > > the order of > > > > > > the sentence needs changing. > > > > > > > > > > > > 2. It refers to 4.2.1 and 4.2.2 for definitions of > > > "direct peer" and > > > > > > "indirect peer" respectively, yet those sections do not > > > define those > > > > > > terms - the define "direct peering" and "indirect peering". > > > > > > > > > > > > 3. The use of the word "bridge" has connotations of > > > > > conference mixing. > > > > > > > > > > > > 4. "between participating networks" - shouldn't this > > > be "between > > > > > > participating service providers"? > > > > > > > > > > > > 5. In 4.2.2 we talk about "originating service provider" and > > > > > > "terminating service provider", so we shouldn't switch to > > > > > > saying "originating peer" and terminating peer". > > > > > > > > > > > > The following words would fix these problems (new or > > > > > revised words in > > > > > > caps): > > > > > > > > > > > > "In this case, some entity (usually a federation, see > > > > > Section 5) THAT IS > > > > > > NOT ITSELF A SERVICE PROVIDER provides peering assistance > > > > > to either the > > > > > > originating or terminating SERVICE PROVIDER by > > > providing one or more > > > > > > functions (see Section 4.3) THAT ASSIST IN ESTABLISHING > > > > > calls between > > > > > > THOSE SERVICE PROVIDERS. The assisting entity may provide > > > > > information > > > > > > relating to direct (Section 4.2.1) or indirect (Section > > > > > 4.2.2) PEERING > > > > > > as necessary." > > > > > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > > > > Sent: 03 August 2007 20:49 > > > > > > > To: speermint@ietf.org > > > > > > > Subject: [Speermint] Terminology Draft: New Assisted > > > > > Peering Verbiage > > > > > > > > > > > > > > At the conference in Chicago, there was some > > > confusion around the > > > > > > > difference between Assisted and Indirect peering. I have > > > > > updated the > > > > > > > Assisted Peering section (4.2.3) to be the following: > > > > > > > > > > > > > > In this case, some entity (usually a federation, see Section > > > > > > > 5) provides > > > > > > > peering assistance to either the originating or > > > > > terminating peer by > > > > > > > providing one or more functions (see Section 4.3) on behalf > > > > > > > of the peers (which is not itself a SSP) to bridge calls > > > > > > > between > > > participating > > > > > > > networks. The assisting entity may provide information > > > > > relating to a > > > > > > > direct (Section 4.2.1) or indirect (Section 4.2.2) peer as > > > > > > > necessary on behalf of the originating or terminating peer. > > > > > > > > > > > > > > Please let me know if this clears up the section and > > > > > eliminates the > > > > > > > confusion. > > > > > > > > > > > > > > If so, I will submit a version -10 tomorrow. > > > > > > > > > > > > > > Thanks... > > > > > > > > > > > > > > --Daryl > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Speermint mailing list > > > > > > > Speermint@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 10 11:03:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJW1a-0002uT-VR; Fri, 10 Aug 2007 11:03:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJW1a-0002uO-AL for speermint@ietf.org; Fri, 10 Aug 2007 11:03:38 -0400 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJW1Y-0007mM-W1 for speermint@ietf.org; Fri, 10 Aug 2007 11:03:38 -0400 Received: from 138.6.152.198.in-addr.arpa (HELO 300815ANEX3.global.avaya.com) ([198.152.6.138]) by nj300815-nj-outbound.avaya.com with ESMTP; 10 Aug 2007 11:03:36 -0400 X-IronPort-AV: i="4.19,245,1183348800"; d="scan'208"; a="47642607:sNHT14952984" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Terminology Draft: New Assisted Peering Verbiage Date: Fri, 10 Aug 2007 11:03:22 -0400 Message-ID: <3036F4A94122BD4AAAAB441FE88845283C2D53@300815ANEX3.global.avaya.com> In-Reply-To: <1186757968.1297.181.camel@montag.eng.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology Draft: New Assisted Peering Verbiage Thread-Index: AcfbXqc6hVEDpbgmSASiDobYEPMFWAAAI4zg References: <1186170535.1297.107.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026E9DD@GBNTHT12009MSX.gb002.siemens.net> <1186438475.1297.131.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026EACD@GBNTHT12009MSX.gb002.siemens.net> <1186692002.1297.175.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026ED81@GBNTHT12009MSX.gb002.siemens.net> <1186757202.1297.177.camel@montag.eng.level3.com> <3036F4A94122BD4AAAAB441FE88845283C2D3A@300815ANEX3.global.avaya.com> <1186757968.1297.181.camel@montag.eng.level3.com> From: "Rodrig, Benny (Benny)" To: "Daryl Malas" X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Then the text would probably be clearer saying "between the SSP and one or more SSP peers" Benny -----Original Message----- From: Daryl Malas [mailto:daryl@level3.net]=20 Sent: Friday, August 10, 2007 10:59 AM To: Rodrig, Benny (Benny) Cc: Elwell, John; speermint@ietf.org Subject: RE: [Speermint] Terminology Draft: New Assisted Peering Verbiage Meaning it is a relationship between an originating SSP and one or more SSP peers. --Daryl On Fri, 2007-08-10 at 10:52 -0400, Rodrig, Benny (Benny) wrote: > What does "between one or more SSP's" mean here? Does it imply some=20 > use case involving just one SSP? Why not say just "between SSP's"? >=20 > Benny >=20 > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Friday, August 10, 2007 10:47 AM > To: Elwell, John > Cc: speermint@ietf.org > Subject: RE: [Speermint] Terminology Draft: New Assisted Peering=20 > Verbiage >=20 > That works for me. I will update the draft. Since, this is the last=20 > revision necessary from Chicago, I will submit a new version of the=20 > draft today unless anyone else has any issues. >=20 > Thanks... >=20 > --Daryl >=20 > On Fri, 2007-08-10 at 07:18 +0100, Elwell, John wrote: > > Daryl, > >=20 > > Yes, the dual role is certainly a possibility, but that is not=20 > > relevant to the definition of assisted. So I would suggest delete > "SSP". > >=20 > > On the other point, we should use "SIP requests" rather than "SIP=20 > > messages" or "SIP messaging". However, perhaps it can do more than=20 > > assisting in the routing of SIP requests, so I think we still need=20 > > to retain the bit about dialogs as well, and perhaps even mention=20 > > sessions too (since sessions introduce other considerations). > >=20 > > "In this case, some entity (usually a 3rd party or federation)=20 > > provides peering assistance to either the originating or terminating > > SSP by providing one or more functions (see Section 4.3) assisting=20 > > in the routing of SIP requests and the establishment of SIP dialogs=20 > > and sessions between one or more SSP's. The assisting entity may=20 > > provide information relating to direct (see Section 4.2.1) or=20 > > indirect (see Section 4.2.2) peering as necessary." > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Daryl Malas [mailto:daryl@level3.net] > > > Sent: 09 August 2007 21:40 > > > To: Elwell, John > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Terminology Draft: New Assisted Peering=20 > > > Verbiage > > >=20 > > > John, > > >=20 > > > I guess I see the SSP in question as being capable of serving a=20 > > > dual >=20 > > > role as an assisting entity and an SSP, or it could be serving as=20 > > > simply an assisting entity as you stated. Since, no one else=20 > > > seems to be providing feedback, I guess it is up to us to decide.=20 > > > Also, I was trying to broaden the usage of SIP in peering by=20 > > > simply stating "dialog establishment" instead of calls. I think=20 > > > MESSAGE and PUBLISH are also valid SIP messages in peering. =20 > > > Perhaps I should simply state it as SIP messaging or something similar. > > >=20 > > > Thanks for your feedback. > > >=20 > > > --Daryl > > >=20 > > > On Tue, 2007-08-07 at 09:02 +0100, Elwell, John wrote: > > > > Daryl, > > > >=20 > > > > Compared with my proposal (and also compared with your original=20 > > > > proposal), your new proposal does not say that the > > > assisting entity is > > > > not an SSP. I agree it could also be an SSP, but when > > > playing the role > > > > of an assisting entity it is not acting as an SSP. I don't > > > have a strong > > > > objection to your new words, if everyone is happy that we > > > don't need to > > > > say that the assisting entity is not an SSP. > > > >=20 > > > > On a further point, your new proposal talks about dialog > > > establishment > > > > rather than calls, which extends its scope (to cover > > > SUBSCRIBE-initiated > > > > dialogs). That is fine, but they what about non-dialog-based=20 > > > > communications (e.g., using the MESSAGE and PUBLISH methods)? > > > >=20 > > > > John > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > > Sent: 06 August 2007 23:15 > > > > > To: Elwell, John > > > > > Cc: speermint@ietf.org > > > > > Subject: RE: [Speermint] Terminology Draft: New Assisted=20 > > > > > Peering >=20 > > > > > Verbiage > > > > >=20 > > > > > John, > > > > >=20 > > > > > Thanks for the feedback. I can understand how the current=20 > > > > > verbiage can cause confusion. I would like to suggest the=20 > > > > > following > > > revision based > > > > > on your feedback: > > > > >=20 > > > > > "In this case, some entity (usually a 3rd party SSP or > > > > > federation) provides peering assistance to either the=20 > > > > > originating or terminating SSP by providing one or more=20 > > > > > functions (see Section 4.3) > > > assisting in the > > > > > establishment of SIP dialogs between one or more SSP's. =20 > > > The assisting > > > > > entity may provide information relating to direct (see Section > > > > > 4.2.1) or indirect (see Section 4.2.2) peering as necessary." > > > > >=20 > > > > > In this case, I am including the ability for an individual SSP > > > > > or federation to provide this capability in an orthogonal=20 > > > > > manner. I cleaned up the other language to help create the=20 > > > > > separation I think you are looking for below. Let me know if=20 > > > > > I accomplished this. > > > > >=20 > > > > > --Daryl > > > > >=20 > > > > > On Mon, 2007-08-06 at 08:08 +0100, Elwell, John wrote: > > > > > > Daryl, > > > > > >=20 > > > > > > This seems to reflect the orthogonality between assisted and > > > > > > direct/indirect peering. I don't think the wording is > > > quite right, > > > > > > however. > > > > > >=20 > > > > > > 1. In the first sentence the words "(which is not itself a > > > > > SSP)" follow > > > > > > "peers", which is grammatically incorrect. In fact > > > those words are > > > > > > intended to refer to something earlier in the sentence, so > > > > > the order of > > > > > > the sentence needs changing. > > > > > >=20 > > > > > > 2. It refers to 4.2.1 and 4.2.2 for definitions of > > > "direct peer" and > > > > > > "indirect peer" respectively, yet those sections do not > > > define those > > > > > > terms - the define "direct peering" and "indirect peering". > > > > > >=20 > > > > > > 3. The use of the word "bridge" has connotations of > > > > > conference mixing. > > > > > >=20 > > > > > > 4. "between participating networks" - shouldn't this > > > be "between > > > > > > participating service providers"? > > > > > >=20 > > > > > > 5. In 4.2.2 we talk about "originating service provider" and > > > > > > "terminating service provider", so we shouldn't switch to=20 > > > > > > saying "originating peer" and terminating peer". > > > > > >=20 > > > > > > The following words would fix these problems (new or > > > > > revised words in > > > > > > caps): > > > > > >=20 > > > > > > "In this case, some entity (usually a federation, see > > > > > Section 5) THAT IS > > > > > > NOT ITSELF A SERVICE PROVIDER provides peering assistance > > > > > to either the > > > > > > originating or terminating SERVICE PROVIDER by > > > providing one or more > > > > > > functions (see Section 4.3) THAT ASSIST IN ESTABLISHING > > > > > calls between > > > > > > THOSE SERVICE PROVIDERS. The assisting entity may provide > > > > > information > > > > > > relating to direct (Section 4.2.1) or indirect (Section > > > > > 4.2.2) PEERING > > > > > > as necessary."=20 > > > > > >=20 > > > > > > John > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > > > > Sent: 03 August 2007 20:49 > > > > > > > To: speermint@ietf.org > > > > > > > Subject: [Speermint] Terminology Draft: New Assisted > > > > > Peering Verbiage > > > > > > >=20 > > > > > > > At the conference in Chicago, there was some > > > confusion around the > > > > > > > difference between Assisted and Indirect peering. I have > > > > > updated the > > > > > > > Assisted Peering section (4.2.3) to be the following: > > > > > > >=20 > > > > > > > In this case, some entity (usually a federation, see=20 > > > > > > > Section > > > > > > > 5) provides > > > > > > > peering assistance to either the originating or > > > > > terminating peer by > > > > > > > providing one or more functions (see Section 4.3) on=20 > > > > > > > behalf of the peers (which is not itself a SSP) to bridge=20 > > > > > > > calls between > > > participating > > > > > > > networks. The assisting entity may provide information > > > > > relating to a > > > > > > > direct (Section 4.2.1) or indirect (Section 4.2.2) peer as > > > > > > > necessary on behalf of the originating or terminating peer. > > > > > > >=20 > > > > > > > Please let me know if this clears up the section and > > > > > eliminates the > > > > > > > confusion. > > > > > > >=20 > > > > > > > If so, I will submit a version -10 tomorrow. > > > > > > >=20 > > > > > > > Thanks... > > > > > > >=20 > > > > > > > --Daryl > > > > > > >=20 > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > Speermint mailing list > > > > > > > Speermint@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > >=20 > > > > >=20 > > > > >=20 > > >=20 > > >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 10 11:12: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 1IJWA4-00021j-N2; Fri, 10 Aug 2007 11:12:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJWA3-00021e-7g for speermint@ietf.org; Fri, 10 Aug 2007 11:12:23 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJWA2-0005lm-09 for speermint@ietf.org; Fri, 10 Aug 2007 11:12:22 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l7AFCHRI005123; Fri, 10 Aug 2007 15:12:18 GMT Subject: RE: [Speermint] Terminology Draft: New Assisted Peering Verbiage From: Daryl Malas To: "Rodrig, Benny (Benny)" In-Reply-To: <3036F4A94122BD4AAAAB441FE88845283C2D53@300815ANEX3.global.avaya.com> References: <1186170535.1297.107.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026E9DD@GBNTHT12009MSX.gb002.siemens.net> <1186438475.1297.131.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026EACD@GBNTHT12009MSX.gb002.siemens.net> <1186692002.1297.175.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D026ED81@GBNTHT12009MSX.gb002.siemens.net> <1186757202.1297.177.camel@montag.eng.level3.com> <3036F4A94122BD4AAAAB441FE88845283C2D3A@300815ANEX3.global.avaya.com> <1186757968.1297.181.camel@montag.eng.level3.com> <3036F4A94122BD4AAAAB441FE88845283C2D53@300815ANEX3.global.avaya.com> Content-Type: text/plain Date: Fri, 10 Aug 2007 09:15:40 -0600 Message-Id: <1186758941.1297.183.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: 83e9494d829b08cc3f644ef6ac1b9bd4 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 Actually, after reading it again, I think it would be fine to simply say "between peers". --Daryl On Fri, 2007-08-10 at 11:03 -0400, Rodrig, Benny (Benny) wrote: > Then the text would probably be clearer saying "between the SSP and one > or more SSP peers" > > Benny > > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Friday, August 10, 2007 10:59 AM > To: Rodrig, Benny (Benny) > Cc: Elwell, John; speermint@ietf.org > Subject: RE: [Speermint] Terminology Draft: New Assisted Peering > Verbiage > > Meaning it is a relationship between an originating SSP and one or more > SSP peers. > > --Daryl > > On Fri, 2007-08-10 at 10:52 -0400, Rodrig, Benny (Benny) wrote: > > What does "between one or more SSP's" mean here? Does it imply some > > use case involving just one SSP? Why not say just "between SSP's"? > > > > Benny > > > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: Friday, August 10, 2007 10:47 AM > > To: Elwell, John > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Terminology Draft: New Assisted Peering > > Verbiage > > > > That works for me. I will update the draft. Since, this is the last > > revision necessary from Chicago, I will submit a new version of the > > draft today unless anyone else has any issues. > > > > Thanks... > > > > --Daryl > > > > On Fri, 2007-08-10 at 07:18 +0100, Elwell, John wrote: > > > Daryl, > > > > > > Yes, the dual role is certainly a possibility, but that is not > > > relevant to the definition of assisted. So I would suggest delete > > "SSP". > > > > > > On the other point, we should use "SIP requests" rather than "SIP > > > messages" or "SIP messaging". However, perhaps it can do more than > > > assisting in the routing of SIP requests, so I think we still need > > > to retain the bit about dialogs as well, and perhaps even mention > > > sessions too (since sessions introduce other considerations). > > > > > > "In this case, some entity (usually a 3rd party or federation) > > > provides peering assistance to either the originating or terminating > > > > SSP by providing one or more functions (see Section 4.3) assisting > > > in the routing of SIP requests and the establishment of SIP dialogs > > > and sessions between one or more SSP's. The assisting entity may > > > provide information relating to direct (see Section 4.2.1) or > > > indirect (see Section 4.2.2) peering as necessary." > > > > > > John > > > > > > > -----Original Message----- > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > Sent: 09 August 2007 21:40 > > > > To: Elwell, John > > > > Cc: speermint@ietf.org > > > > Subject: RE: [Speermint] Terminology Draft: New Assisted Peering > > > > Verbiage > > > > > > > > John, > > > > > > > > I guess I see the SSP in question as being capable of serving a > > > > dual > > > > > > role as an assisting entity and an SSP, or it could be serving as > > > > simply an assisting entity as you stated. Since, no one else > > > > seems to be providing feedback, I guess it is up to us to decide. > > > > Also, I was trying to broaden the usage of SIP in peering by > > > > simply stating "dialog establishment" instead of calls. I think > > > > MESSAGE and PUBLISH are also valid SIP messages in peering. > > > > Perhaps I should simply state it as SIP messaging or something > similar. > > > > > > > > Thanks for your feedback. > > > > > > > > --Daryl > > > > > > > > On Tue, 2007-08-07 at 09:02 +0100, Elwell, John wrote: > > > > > Daryl, > > > > > > > > > > Compared with my proposal (and also compared with your original > > > > > proposal), your new proposal does not say that the > > > > assisting entity is > > > > > not an SSP. I agree it could also be an SSP, but when > > > > playing the role > > > > > of an assisting entity it is not acting as an SSP. I don't > > > > have a strong > > > > > objection to your new words, if everyone is happy that we > > > > don't need to > > > > > say that the assisting entity is not an SSP. > > > > > > > > > > On a further point, your new proposal talks about dialog > > > > establishment > > > > > rather than calls, which extends its scope (to cover > > > > SUBSCRIBE-initiated > > > > > dialogs). That is fine, but they what about non-dialog-based > > > > > communications (e.g., using the MESSAGE and PUBLISH methods)? > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > > > Sent: 06 August 2007 23:15 > > > > > > To: Elwell, John > > > > > > Cc: speermint@ietf.org > > > > > > Subject: RE: [Speermint] Terminology Draft: New Assisted > > > > > > Peering > > > > > > > > Verbiage > > > > > > > > > > > > John, > > > > > > > > > > > > Thanks for the feedback. I can understand how the current > > > > > > verbiage can cause confusion. I would like to suggest the > > > > > > following > > > > revision based > > > > > > on your feedback: > > > > > > > > > > > > "In this case, some entity (usually a 3rd party SSP or > > > > > > federation) provides peering assistance to either the > > > > > > originating or terminating SSP by providing one or more > > > > > > functions (see Section 4.3) > > > > assisting in the > > > > > > establishment of SIP dialogs between one or more SSP's. > > > > The assisting > > > > > > entity may provide information relating to direct (see Section > > > > > > 4.2.1) or indirect (see Section 4.2.2) peering as necessary." > > > > > > > > > > > > In this case, I am including the ability for an individual SSP > > > > > > > or federation to provide this capability in an orthogonal > > > > > > manner. I cleaned up the other language to help create the > > > > > > separation I think you are looking for below. Let me know if > > > > > > I accomplished this. > > > > > > > > > > > > --Daryl > > > > > > > > > > > > On Mon, 2007-08-06 at 08:08 +0100, Elwell, John wrote: > > > > > > > Daryl, > > > > > > > > > > > > > > This seems to reflect the orthogonality between assisted and > > > > > > > > direct/indirect peering. I don't think the wording is > > > > quite right, > > > > > > > however. > > > > > > > > > > > > > > 1. In the first sentence the words "(which is not itself a > > > > > > SSP)" follow > > > > > > > "peers", which is grammatically incorrect. In fact > > > > those words are > > > > > > > intended to refer to something earlier in the sentence, so > > > > > > the order of > > > > > > > the sentence needs changing. > > > > > > > > > > > > > > 2. It refers to 4.2.1 and 4.2.2 for definitions of > > > > "direct peer" and > > > > > > > "indirect peer" respectively, yet those sections do not > > > > define those > > > > > > > terms - the define "direct peering" and "indirect peering". > > > > > > > > > > > > > > 3. The use of the word "bridge" has connotations of > > > > > > conference mixing. > > > > > > > > > > > > > > 4. "between participating networks" - shouldn't this > > > > be "between > > > > > > > participating service providers"? > > > > > > > > > > > > > > 5. In 4.2.2 we talk about "originating service provider" and > > > > > > > > "terminating service provider", so we shouldn't switch to > > > > > > > saying "originating peer" and terminating peer". > > > > > > > > > > > > > > The following words would fix these problems (new or > > > > > > revised words in > > > > > > > caps): > > > > > > > > > > > > > > "In this case, some entity (usually a federation, see > > > > > > Section 5) THAT IS > > > > > > > NOT ITSELF A SERVICE PROVIDER provides peering assistance > > > > > > to either the > > > > > > > originating or terminating SERVICE PROVIDER by > > > > providing one or more > > > > > > > functions (see Section 4.3) THAT ASSIST IN ESTABLISHING > > > > > > calls between > > > > > > > THOSE SERVICE PROVIDERS. The assisting entity may provide > > > > > > information > > > > > > > relating to direct (Section 4.2.1) or indirect (Section > > > > > > 4.2.2) PEERING > > > > > > > as necessary." > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > > > > > Sent: 03 August 2007 20:49 > > > > > > > > To: speermint@ietf.org > > > > > > > > Subject: [Speermint] Terminology Draft: New Assisted > > > > > > Peering Verbiage > > > > > > > > > > > > > > > > At the conference in Chicago, there was some > > > > confusion around the > > > > > > > > difference between Assisted and Indirect peering. I have > > > > > > updated the > > > > > > > > Assisted Peering section (4.2.3) to be the following: > > > > > > > > > > > > > > > > In this case, some entity (usually a federation, see > > > > > > > > Section > > > > > > > > 5) provides > > > > > > > > peering assistance to either the originating or > > > > > > terminating peer by > > > > > > > > providing one or more functions (see Section 4.3) on > > > > > > > > behalf of the peers (which is not itself a SSP) to bridge > > > > > > > > calls between > > > > participating > > > > > > > > networks. The assisting entity may provide information > > > > > > relating to a > > > > > > > > direct (Section 4.2.1) or indirect (Section 4.2.2) peer as > > > > > > > > > necessary on behalf of the originating or terminating > peer. > > > > > > > > > > > > > > > > Please let me know if this clears up the section and > > > > > > eliminates the > > > > > > > > confusion. > > > > > > > > > > > > > > > > If so, I will submit a version -10 tomorrow. > > > > > > > > > > > > > > > > Thanks... > > > > > > > > > > > > > > > > --Daryl > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Speermint mailing list > > > > > > > > Speermint@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Aug 10 13:15:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJY5M-00046i-QG; Fri, 10 Aug 2007 13:15:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJY5F-0003rP-Lm; Fri, 10 Aug 2007 13:15:33 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJY5D-0002Ef-Qw; Fri, 10 Aug 2007 13:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id C2760328EF; Fri, 10 Aug 2007 17:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IJY4j-0007vY-Ml; Fri, 10 Aug 2007 13:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 10 Aug 2007 13:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-10.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Terminology Author(s) : D. Malas, D. Meyer Filename : draft-ietf-speermint-terminology-10.txt Pages : 13 Date : 2007-8-10 This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-terminology-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-terminology-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-10123055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-terminology-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-terminology-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-10123055.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Mon Aug 13 05:20: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 1IKW5k-0006eK-2x; Mon, 13 Aug 2007 05:20:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKW5i-0006eC-U1 for speermint@ietf.org; Mon, 13 Aug 2007 05:20:02 -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 1IKW5i-0005zK-08 for speermint@ietf.org; Mon, 13 Aug 2007 05:20:02 -0400 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1IKW5g-0005Sy-00 for ; Mon, 13 Aug 2007 11:20:00 +0200 Date: Mon, 13 Aug 2007 11:20:00 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Normative language in draft-ietf-speermint-requirements-02 Message-ID: <20070813092000.GA20998@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <0D5F89FAC29E2C41B98A6A762007F5D026E7CF@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D026E7CF@GBNTHT12009MSX.gb002.siemens.net> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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/08/01 12:08, "Elwell, John" wrote: > In an earlier message > (http://www1.ietf.org/mail-archive/web/speermint/current/msg02064.html) > I commented, amongst other things, on the normative language (RFC2119) > in the requirements draft, and suggested that, if the document does > indeed specify requirements on SSPs, then the normative language should > reflect that. This would be in contrast to most requirements documents > from the IETF, which specify requirements on future IETF work (e.g., on > protocols, architecture) and therefore use normative language in a > different way (e.g., "It MUST be possible to ...", "The mechanism SHOULD > provide a means to....", "The solution MUST NOT permit...."). :-) I made the same assumption last year. > I raised this again during our meeting in Chicago, and it seemed from > the discussion there that this draft is intended to place requirements > on further work by the SPEERMINT group, and therefore normative language > should reflect that. Consequently any statements that appear to place a > requirement on an SSP should receive some attention. > > Looking again at the draft, much of the draft seems to be written in a > way that is inconsistent with the view that emerged from the meeting. In > particular the Abstract and Introduction position the draft as a BCP for > service providers. > > So I think we need to establish exactly what the purpose of the document > is. My recollection from last year's meetings is that this document is supposed to document what SSPs must support to do SIP peering. I have to admit that I never understood what goal this document is supposed to achieve. A SIP profile document would indeed be helpful, but for that the title is misleading. The other problem I have with this document is that the "requirements" documented there are neither "sufficient" nor "necessary". (From a mathematical/logical point of view, conditions have to be either to be meaningful.) These requirements are not "sufficient", as they don't imply that all SSPs which fulfill these requirements are in fact peering with each other, are willing to do so, or are even able to do so (for number-based calls). Nor are these requirements "necessary" in the sense that whenever peering is taking place, these requirements are met. There are a number of peering operational now which do not conform to this list. The only point I can see in this document is as a guideline for SSPs for selecting technology partners and/or products. For that, too, it is misnamed. /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 Aug 13 14:15: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 1IKeRX-0001We-Nv; Mon, 13 Aug 2007 14:15:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKeRS-0001Vd-E8; Mon, 13 Aug 2007 14:15:02 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKeRS-0007ef-1v; Mon, 13 Aug 2007 14:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id DEF082AC8C; Mon, 13 Aug 2007 18:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IKeRR-0000x8-LS; Mon, 13 Aug 2007 14:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 13 Aug 2007 14:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-architecture-04.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Peering Architecture Author(s) : R. Penno, et al. Filename : draft-ietf-speermint-architecture-04.txt Pages : 22 Date : 2007-8-13 This document defines the SPEERMINT peering architecture, its functional components and peering interface functions. It also describes the steps taken to establish a session between two peering domains in the context of the functions defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-architecture-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-architecture-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-13132740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-architecture-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-architecture-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-13132740.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Mon Aug 13 14:15: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 1IKeRX-0001WY-Gu; Mon, 13 Aug 2007 14:15:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKeRS-0001Vc-CZ; Mon, 13 Aug 2007 14:15:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKeRR-0007Rh-Uf; Mon, 13 Aug 2007 14:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id CE03E26E5C; Mon, 13 Aug 2007 18:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IKeRR-0000xL-Nz; Mon, 13 Aug 2007 14:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 13 Aug 2007 14:15:01 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-11.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Terminology Author(s) : D. Malas, D. Meyer Filename : draft-ietf-speermint-terminology-11.txt Pages : 13 Date : 2007-8-13 This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-terminology-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-terminology-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-13134231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-terminology-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-terminology-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-13134231.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Wed Aug 15 16:15:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPGj-00061p-Bk; Wed, 15 Aug 2007 16:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPGg-00060t-Cl; Wed, 15 Aug 2007 16:15:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILPGf-000886-Vh; Wed, 15 Aug 2007 16:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id E8F5732896; Wed, 15 Aug 2007 20:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ILPGf-0000m8-RU; Wed, 15 Aug 2007 16:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 15 Aug 2007 16:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-12.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Terminology Author(s) : D. Malas, D. Meyer Filename : draft-ietf-speermint-terminology-12.txt Pages : 13 Date : 2007-8-15 This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-terminology-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-terminology-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-15151005.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-terminology-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-terminology-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-15151005.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart--