From speermint-bounces@ietf.org Tue Jun 05 12:50:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcEm-0005dI-Pk; Tue, 05 Jun 2007 12:50:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcEl-0005bR-Gq for speermint@ietf.org; Tue, 05 Jun 2007 12:50:27 -0400 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvcEk-00077k-7q for speermint@ietf.org; Tue, 05 Jun 2007 12:50:27 -0400 Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.4251909; Tue, 05 Jun 2007 12:50:03 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 12:50:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] [wg-business] WGLC fordraft-ietf-speermint-consolidated-presence-im-usecases-01 Date: Tue, 5 Jun 2007 12:50:03 -0400 Message-ID: <45AEC6EF95942140888406588E1A660201A29C68@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A660201A8A108@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business] WGLC fordraft-ietf-speermint-consolidated-presence-im-usecases-01 Thread-Index: Acebz2lVIOAXLXIbTuCM59kog2h/xALvx27A References: <45AEC6EF95942140888406588E1A660201A8A108@PACDCEXCMB04.cable.comcast.com> From: "Livingood, Jason" To: X-OriginalArrivalTime: 05 Jun 2007 16:50:03.0215 (UTC) FILETIME=[900BFDF0:01C7A791] X-Spam-Score: 1.1 (+) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org WGLC for this draft is now closed. Thanks for everyone's feedback. I believe the authors are working now to update the I-D to incorporate this final feedback and will publish an update soon. Thanks! Jason > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Monday, May 21, 2007 1:43 PM > To: speermint@ietf.org > Subject: [Speermint] [wg-business] WGLC=20 > fordraft-ietf-speermint-consolidated-presence-im-usecases-01 >=20 > Title : Presence & IM Use Cases > Author(s) : A. Houri, et. al. > Filename : > draft-ietf-speermint-consolidated-presence-im-usecases-01.txt > Pages : 12 > Date : 9 May 2007 >=20 > Abstract > =20 > The document describes several use cases of peering between two or > more service providers that provide none VOIP based collaboration > services and presence and IM in particular. These service=20 > providers > create a peering relationship between themselves thus=20 > enabling their > users to collaborate with users on other communities. The=20 > target of > the document is to drive requirements for peering between domains > that provide the none VOIP based collaboration services. >=20 > A URL for this Internet-Draft is: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-speermint-conso > lidated-pr > esence-im-usecases-01.txt >=20 > The intent of the last call is to solicit comments before=20 > submitting the ID to the IESG. >=20 > The purpose of a working group Last Call is in the style of=20 > "speak now or forever hold your peace" in case there are=20 > fundamental objections which have not gotten previous or=20 > adequate discussion, or minor errors which need correction. >=20 > Work group last call will extend for 2 weeks from today, 21=20 > May 2007, until at least 4 June 2007 (though we can modify=20 > that if new issues come up). >=20 > Please post any comments in reply to the list, as well as to the > editor(s) of this draft. >=20 > Regards, >=20 > Jason=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jun 05 12:50:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcEw-0006AJ-PY; Tue, 05 Jun 2007 12:50:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcEv-00069N-8X for speermint@ietf.org; Tue, 05 Jun 2007 12:50:37 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvcEt-00078t-VY for speermint@ietf.org; Tue, 05 Jun 2007 12:50:37 -0400 Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.33418315; Tue, 05 Jun 2007 12:50:08 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 12:50:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jun 2007 12:50:08 -0400 Message-ID: <45AEC6EF95942140888406588E1A660201A29C6C@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internet-Drafts Submission Cutoff Dates for the 69th IETF Meeting in Chicago, IL, USA Thread-Index: AcekAc4VK66a0QB4TfmEh1woVc9edgDjbjNQ From: "Livingood, Jason" To: X-OriginalArrivalTime: 05 Jun 2007 16:50:08.0384 (UTC) FILETIME=[9320B800:01C7A791] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Speermint] FW: Internet-Drafts Submission Cutoff Dates for the 69th IETF Meeting in Chicago, IL, USA X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org FYI 2 July: Deadline for -00 drafts 9 July: Deadline for -01 and higher drafts=20 Jason -----Original Message----- From: ietf-secretariat@ietf.org [mailto:ietf-secretariat@ietf.org]=20 Sent: Friday, June 01, 2007 12:00 AM To: ietf-announce@ietf.org Subject: Internet-Drafts Submission Cutoff Dates for the 69th IETF Meeting in Chicago, IL, USA=20 There are two (2) Internet-Draft cutoff dates for the 69th IETF Meeting in Chicago, IL, USA: July 2nd: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions=20 All initial Internet-Drafts (version -00) must be submitted by Monday, July 2nd at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, June 25th at 9:00 AM ET. July 9th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions=20 All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, July 9th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, July 23rd at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 69th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_69.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 08 15:50:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwkTc-0002yk-IV; Fri, 08 Jun 2007 15:50:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwkTD-0002KS-2X; Fri, 08 Jun 2007 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwkTC-00076j-MJ; Fri, 08 Jun 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5C8F526EEF; Fri, 8 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HwkTC-0001Ci-2b; Fri, 08 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 08 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : VoIP SIP Peering Use Cases Author(s) : A. Uzelac, et al. Filename : draft-ietf-speermint-voip-consolidated-usecases-02.txt Pages : 23 Date : 2007-6-8 This document will capture VoIP use case for SIP Peering. It is a consolidation of Speermint use cases drafts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-02.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-voip-consolidated-usecases-02.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-voip-consolidated-usecases-02.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-6-8143613.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-voip-consolidated-usecases-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-8143613.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 Jun 11 00:45:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxbmD-00028g-AF; Mon, 11 Jun 2007 00:45:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxbmB-00028a-Qz for speermint@ietf.org; Mon, 11 Jun 2007 00:45:11 -0400 Received: from smtp3.infoteck.qc.ca ([205.151.16.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxbmA-0002HH-GX for speermint@ietf.org; Mon, 11 Jun 2007 00:45:11 -0400 Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.44) id 1Hxbm8-0008BJ-CU for speermint@ietf.org; Mon, 11 Jun 2007 00:45:09 -0400 Received: from [207.96.234.38] (helo=ITOS) by relay.infoteck.qc.ca with esmtp (Exim 4.43) id 1Hxbm6-00089Q-Lw for speermint@ietf.org; Mon, 11 Jun 2007 00:45:08 -0400 From: "Francois Menard" To: Date: Mon, 11 Jun 2007 00:44:51 -0400 Organization: none Message-ID: <000e01c7abe3$3f71d8a0$be5589e0$@ca> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acer4z9I1Pt6tpTQTVesgRff8p0/xA== Content-Language: en-ca X-Spam-Score: 0.0 (/) X-Spam-Report: Spam detection software, running on the system "spamx1.tr.xittel.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Has anybody given more thought than I did on using KPML (RFC 4730) as a standardized alternative to use of SIP-INFO for carrying DTMF across a SF interface? F. Francois arobas menards.ca [...] Content analysis details: (0.0 points, 6.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 HTML_MESSAGE BODY: HTML included in message X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [Speermint] use of KPML for transmitting DTMF across a SF interface X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: francois@menards.ca List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1838973491==" Errors-To: speermint-bounces@ietf.org This is a multipart message in MIME format. --===============1838973491== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C7ABC1.B86038A0" Content-Language: en-ca This is a multipart message in MIME format. ------=_NextPart_000_000F_01C7ABC1.B86038A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Has anybody given more thought than I did on using KPML (RFC 4730) as a standardized alternative to use of SIP-INFO for carrying DTMF across a SF interface? F. Francois arobas menards.ca ------=_NextPart_000_000F_01C7ABC1.B86038A0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Has anybody given more thought than I did on using = KPML (RFC 4730)  as a standardized alternative to use of SIP-INFO for = carrying DTMF across a SF interface?

 

F.

 

Francois arobas menards.ca

 

------=_NextPart_000_000F_01C7ABC1.B86038A0-- --===============1838973491== 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 --===============1838973491==-- From speermint-bounces@ietf.org Mon Jun 11 01:59:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxcvV-0004wB-P3; Mon, 11 Jun 2007 01:58:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxcvU-0004w2-HT for speermint@ietf.org; Mon, 11 Jun 2007 01:58:52 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxcvT-0002w2-17 for speermint@ietf.org; Mon, 11 Jun 2007 01:58:52 -0400 Received: from unknown (HELO up-smtp.jnpr.net) ([172.26.192.132]) by smtpa.juniper.net with ESMTP; 10 Jun 2007 22:58:50 -0700 X-IronPort-AV: i="4.16,406,1175497200"; d="scan'208,217"; a="17136586:sNHT91659108" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jun 2007 06:58:48 +0100 Content-class: urn:content-classes:message Subject: RE: [Speermint] use of KPML for transmitting DTMF across a SF interface MIME-Version: 1.0 Date: Mon, 11 Jun 2007 06:58:46 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Message-ID: <0E48B768805E4D44A70709C8AE09209097E8CC@EMAILEMEA3.jnpr.net> In-Reply-To: <000e01c7abe3$3f71d8a0$be5589e0$@ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] use of KPML for transmitting DTMF across a SF interface Thread-Index: Acer4z9I1Pt6tpTQTVesgRff8p0/xAACHFrQ References: <000e01c7abe3$3f71d8a0$be5589e0$@ca> From: "Gilad Shaham" To: X-OriginalArrivalTime: 11 Jun 2007 05:58:48.0488 (UTC) FILETIME=[942C5280:01C7ABED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0470755895==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0470755895== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7ABED.944D1EB7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7ABED.944D1EB7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Francois, =20 You're correct about KPML, it is the recommended way for implementing DTMF on the SF. DTMF on INFO is not standard despite the fact that there are various deployments that do it. There is a long discussion in the SIP WG and the result of this discussion will probably be a BCP for INFO.=20 =20 I agree it's too bad that RFC 4730 doesn't clarify this, but the BCP will. =20 Gilad =20 ________________________________ From: Francois Menard [mailto:ietf-monitor@menards.ca]=20 Sent: Monday, June 11, 2007 7:45 AM To: speermint@ietf.org Subject: [Speermint] use of KPML for transmitting DTMF across a SF interface =20 Has anybody given more thought than I did on using KPML (RFC 4730) as a standardized alternative to use of SIP-INFO for carrying DTMF across a SF interface? =20 F. =20 Francois arobas menards.ca =20 ------_=_NextPart_001_01C7ABED.944D1EB7 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi = Francois,

 

You’re correct about KPML, it = is the recommended way for implementing DTMF on the SF. DTMF on INFO is not = standard despite the fact that there are various deployments that do it. There is = a long discussion in the SIP WG and the result of this discussion will probably = be a BCP for INFO.

 

I agree it’s too bad that RFC = 4730 doesn’t clarify this, but the BCP = will.

 

Gilad

 

From: = Francois Menard [mailto:ietf-monitor@menards.ca]
Sent: Monday, June 11, = 2007 7:45 AM
To: = speermint@ietf.org
Subject: [Speermint] use = of KPML for transmitting DTMF across a SF interface

 

Has anybody given more thought than I did on using KPML (RFC = 4730)  as a standardized alternative to use of SIP-INFO for carrying DTMF across a = SF interface?

 

F.

 

Francois arobas menards.ca

 

------_=_NextPart_001_01C7ABED.944D1EB7-- --===============0470755895== 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 --===============0470755895==-- From speermint-bounces@ietf.org Mon Jun 11 14:29: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 1Hxodc-0004QV-BI; Mon, 11 Jun 2007 14:29:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxoda-0004Ia-SV for speermint@ietf.org; Mon, 11 Jun 2007 14:29:10 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxodZ-0000gk-Fz for speermint@ietf.org; Mon, 11 Jun 2007 14:29:10 -0400 Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.43634012; Mon, 11 Jun 2007 14:28:37 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 14:28:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7AC56.53DE311B" Subject: RE: [Speermint] [wg-business] 69th IETF - DRAFT Meeting Agenda forReview Date: Mon, 11 Jun 2007 14:28:37 -0400 Message-ID: <45AEC6EF95942140888406588E1A660201A29D1E@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A660201A8A9F0@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business] 69th IETF - DRAFT Meeting Agenda forReview Thread-Index: AcedUyAHhTdmad+hTzSr2W8XvcQ3ZQAuGnjQA5JUzwA= References: <45AEC6EF95942140888406588E1A660201A8A9F0@PACDCEXCMB04.cable.comcast.com> From: "Livingood, Jason" To: X-OriginalArrivalTime: 11 Jun 2007 18:28:37.0948 (UTC) FILETIME=[53FB1FC0:01C7AC56] X-Spam-Score: 0.5 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7AC56.53DE311B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is a draft agenda for speermint - please advise if you have any comments. Thanks! Jason=20 > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Thursday, May 24, 2007 10:00 AM > To: speermint@ietf.org > Subject: [Speermint] [wg-business] 69th IETF - DRAFT Meeting=20 > Agenda forReview=20 >=20 > A draft IETF-69 agenda is up. Looks like we are=20 > *tentatively* scheduled for Monday, 23 July, at 1300 hours. >=20 > Jason >=20 > -----Original Message----- > From: IETF Agenda [mailto:agenda@ietf.org] > Sent: Wednesday, May 23, 2007 11:56 AM > To: wgchairs@ietf.org; bofchairs@ietf.org; irsg@isi.edu; iesg@ietf.org > Subject: 69th IETF - DRAFT Meeting Agenda for Review=20 >=20 > Dear ALL: > =20 > The DRAFT agenda for the 69th IETF Meeting can be found at: > https://datatracker.ietf.org/public/meeting_agenda_html.cgi?me > eting_num=3D > 69. > Please note that the agenda is in draft form and is subject to change. > =20 > We would like to ask you to review the Draft Agenda and send=20 > your comments to agenda@ietf.org. We shall be working on your=20 > comments until the Final Agenda is published which is on=20 > Monday, July 2nd) (Important Meeting Dates can be found at=20 > http://www.ietf.org/meetings/69-IETF.html). > =20 > We would really appreciate your inputs or suggestions on the=20 > draft agenda and shall try to accommodate your priorities if possible. > =20 > IETF Secretariat > =20 > +++ >=20 > The milestones and deadlines for scheduling-related activities are as > follows: > =20 > -- Cut-off date for requesting a Working Group session and=20 > for preliminary BOF proposals to ADs: Monday, May 21 at 17:00=20 > ET (21:00 UTC/GMT). > -- Cut-off date for requests to schedule BoFs: Monday, June=20 > 11 at 17:00 ET (21:00 UTC/GMT). > -- Preliminary agenda published for comment: Friday, June 15=20 > by midnight ET. > -- Cut-off date for requests to reschedule a session:=20 > Wednesday, June 27 at 09:00 ET (13:00 UTC/GMT). > -- Final agenda published: Monday, July 2 before midnight ET. > -- Draft Working Group agendas due: Wednesday, July 11 at=20 > 17:00 ET (21:00 UTC/GMT). > -- Revised Working Group agendas due: Monday, July 16 at=20 > 12:00 ET (16:00 UTC/GMT), upload using IETF Meeting Materials=20 > Management Tool >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 ------_=_NextPart_001_01C7AC56.53DE311B Content-Type: text/plain; name="speermint_agenda_ietf69.txt" Content-Transfer-Encoding: base64 Content-Description: speermint_agenda_ietf69.txt Content-Disposition: attachment; filename="speermint_agenda_ietf69.txt" U2Vzc2lvbiBQRUVSaW5nIGZvciBNdWx0aW1lZGlhIElOVGVyY29ubmVjdCAoc3BlZXJtaW50KQ0K DQpNb25kYXksIEp1bHkgMjMsIDIwMDcsIDEzMDAgLSAxNTAwIChBZnRlcm5vb24gU2Vzc2lvbiBJ KSANClJvb20gTmFtZTogR3JhbmQgQmFsbHJvb20NCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCg0KQ0hBSVJTOgkgICAgICAgCQlEYXZpZCBNZXllciAgICAgIAk8ZG1tQDEt NC01Lm5ldD4NCgkJCUphc29uIExpdmluZ29vZCAgCTxqYXNvbl9saXZpbmdvb2RAY2FibGUuY29t Y2FzdC5jb20+DQoNClNFQ1JFVEFSWTogIAkJQWxleGFuZGVyIE1heXJob2ZlciAJPGFsZXhhbmRl ci5tYXlyaG9mZXJAbmljLmF0Pg0KDQpSQUkgQVJFQSBESVJFQ1RPUlM6CUN1bGxlbiBKZW5uaW5n cyAJPGZsdWZmeUBjaXNjby5jb20+DQoJCQlKb24gUGV0ZXJzb24gCQk8am9uLnBldGVyc29uQG5l dXN0YXIuYml6Pg0KDQpSQUkgQVJFQSBBRFZJU09SOglKb24gUGV0ZXJzb24gCQk8am9uLnBldGVy c29uQG5ldXN0YXIuYml6Pg0KDQoNCkdFTkVSQUwgKDE1IG1pbnV0ZXMpDQoNCjEgLSBXZWxjb21l ICYgSW50cm9kdWN0aW9uIHRvIHNwZWVybWludCAvIEFkbWluaXN0cml2aWEJICAJCTUgbWludXRl cw0KICAgICAJRGF2ZSBNZXllcg0KDQogICAtIE1haWxpbmcgbGlzdDogc3BlZXJtaW50LXJlcXVl c3RAaWV0Zi5vcmcNCiAgICAgc3Vic2NyaWJlDQoNCiAgIC0gU2NyaWJlIChqYWJiZXIpDQogICAN CiAgIC0gQmx1ZSBTaGVldHMNCg0KDQoyIC0gQWdlbmRhIEJhc2hpbmcgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAkJNSBtaW51dGVzDQogICAgIAlEYXZlIE1leWVyDQoN Cg0KMyAtIFJldmlldyBvZiBNaWxlc3RvbmVzICYgRG9jdW1lbnQgRmxvdwkJCQk1IG1pbnV0ZXMN CglKYXNvbiBMaXZpbmdvb2QNCg0KDQpSRVZJRVcgUFJJTUFSWSBXRyBEUkFGVFMgKDkwIG1pbnV0 ZXMpDQoNCg0KNCAtIEZJTkFMIEZFRURCQUNLIE9OIC0tPiBTUEVFUk1JTlQgVGVybWlub2xvZ3kg RHJhZnQJCQkxMCBtaW51dGVzDQoJaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtaWV0Zi1zcGVlcm1pbnQtdGVybWlub2xvZ3ktMDcudHh0DQoJRGFyeWwgTWFsYXMNCg0K DQo1IC0gRklOQUwgRkVFREJBQ0sgT04gLS0+IFZvSVAgQ29uc29saWRhdGVkIFVzZSBDYXNlcwkJ CTE1IG1pbnV0ZXMNCglodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1p ZXRmLXNwZWVybWludC12b2lwLWNvbnNvbGlkYXRlZC11c2VjYXNlcy0wMi50eHQNCglBZGFtIFV6 ZWxhYw0KDQo2IC0gV0cgRGlzY3VzczogQ29uc29saWRhdGVkIFJlcXVpcmVtZW50cyBvciBWb0lQ ICYgSU0gU2VwYXJhdGU/IAkwIG1pbnV0ZXMNCglUbyBiZSBkaXNjdXNzZWQgbGF0ZXIgZHVyaW5n IG9wZW4gbWljLCBidXQgbWVudGlvbiBub3cuDQoJSmFzb24gTGl2aW5nb29kDQoNCjcgLSBERVRB SUxFRCBSRVZJRVcgLS0+IFNQRUVSTUlOVCBSZXF1aXJlbWVudHMgZm9yIFNJUC1iYXNlZCAJCTQ1 IG1pbnV0ZXMNCglWb0lQIEludGVyY29ubmVjdGlvbg0KCWh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtc3BlZXJtaW50LXJlcXVpcmVtZW50cy0wMi50eHQNCglK ZWFuLUZyYW5jb2lzIE11bGUNCg0KNyAtIERFVEFJTEVEIFJFVklFVyAtLT4gU1BFRVJNSU5UIFBl ZXJpbmcgQXJjaGl0ZWN0dXJlCSAJCTIwIG1pbnV0ZXMNCglodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNwZWVybWludC1hcmNoaXRlY3R1cmUtMDMudHh0DQoJ UmVpbmFsZG8gUGVubm8NCg0KUkVWSUVXIE5FVyBJTkRJVklEVUFMIERSQUZUUyAoMCBtaW51dGVz KQ0KDQoJTm9uZQ0KDQoNCg0KT1BFTiBESVNDVVNTSU9OIAkgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAkJMTUgbWludXRlcw0KICAgDQoNCg== ------_=_NextPart_001_01C7AC56.53DE311B Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint ------_=_NextPart_001_01C7AC56.53DE311B-- From speermint-bounces@ietf.org Mon Jun 18 14:39:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0M8e-0007s6-Ow; Mon, 18 Jun 2007 14:39:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0M8d-0007s1-3p for speermint@ietf.org; Mon, 18 Jun 2007 14:39:43 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0M8b-0002qH-Mo for speermint@ietf.org; Mon, 18 Jun 2007 14:39:43 -0400 Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.33867301; Mon, 18 Jun 2007 14:39:25 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 14:39:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt Date: Mon, 18 Jun 2007 14:39:24 -0400 Message-ID: <45AEC6EF95942140888406588E1A660201A29E41@PACDCEXCMB04.cable.comcast.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt Thread-Index: AceqBlIdXcS1i2PSRICH6YaePBSSAgH0VtRA References: From: "Livingood, Jason" To: , "Alexander Mayrhofer" X-OriginalArrivalTime: 18 Jun 2007 18:39:24.0863 (UTC) FILETIME=[FE76C4F0:01C7B1D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 Alex -=20 According to our milestones, we're looking to complete work on this I-D in August. Since the underlying draft should now be fairly stable in the run-up to IETF-69, would you please peform a NITS review of this document? I suspect the authors will have some minor changes to make following IETF-69 just before they are ready for WGLC. If we can fix some of the NITS before IETF-69, all the better. Thanks! Jason=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Friday, June 08, 2007 3:50 PM > To: i-d-announce@ietf.org > Cc: speermint@ietf.org > Subject: [Speermint] I-D=20 > ACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session PEERing for=20 > Multimedia INTerconnect Working Group of the IETF. >=20 > Title : VoIP SIP Peering Use Cases > Author(s) : A. Uzelac, et al. > Filename :=20 > draft-ietf-speermint-voip-consolidated-usecases-02.txt > Pages : 23 > Date : 2007-6-8 > =09 > This document will capture VoIP use case for SIP Peering. It is a=20 > consolidation of Speermint use cases drafts. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip- > consolidated-usecases-02.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-speermint-voip-consolidated-usecases-02.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-ietf-speermint-voip-consolidated-usecas > es-02.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jun 18 17:22:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0OgH-00058G-BC; Mon, 18 Jun 2007 17:22:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0OgE-000588-Vf for speermint@ietf.org; Mon, 18 Jun 2007 17:22:35 -0400 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0OgB-0000v2-6n for speermint@ietf.org; Mon, 18 Jun 2007 17:22:34 -0400 Received: from unknown (HELO 300815ANEX3.global.avaya.com) ([198.152.6.139]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Jun 2007 17:22:29 -0400 X-IronPort-AV: i="4.16,436,1175486400"; d="scan'208"; a="28259257:sNHT18463152" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt Date: Mon, 18 Jun 2007 17:21:58 -0400 Message-ID: <3036F4A94122BD4AAAAB441FE888452818688C@300815ANEX3.global.avaya.com> In-Reply-To: <45AEC6EF95942140888406588E1A660201A29E41@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt Thread-Index: AceqBlIdXcS1i2PSRICH6YaePBSSAgH0VtRAAAELLpA= References: <45AEC6EF95942140888406588E1A660201A29E41@PACDCEXCMB04.cable.comcast.com> From: "Rodrig, Benny \(Benny\)" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Adam, all, I have a few comments on draft-ietf-speermint-voip-consolidated-usecases-02. I think the draft should state that the Originating Domain and/or the Terminating Domain can be either a commercial service provider or an enterprise. This statement can be added in section 3 just before 3.1. I'd suggest also adding a couple of points regarding enterprises after this statement, or possibly somewhere else in the draft: One is a sentence about regulatory requirements potentially being different in the case of enterprises.=20 And the other is something like the following sentence: 'Other models for session interconnect in the context of enterprise scenarios, such as subscription-based models and transit models for intra-enterprise communications, are out of scope of Speermint.' If there is agreement that the domains can be enterprises, then a decision is needed on the use of the term VSP. The draft can say clearly that the term VSP in this draft refers to either a commercial VoIP service provider or an enterprise VoIP domain. This can be added to the definition of VSP in the terminology section. The text in section 3.1.2.2 that distinguishes between a service provider and an enterprise should then be explicit and say something like 'commercial VoIP Service Provider'. Also 3.1.3.2 seems to use the term VSP to mean non-enterprise, but there the distinction doesn't seem to be needed at all as a following sentence adds that this is also applicable to enterprises. Does it make sense to add to the administrative characteristics of transit (section 3.2.1.1) something about transitive conditions, e.g. an originating enterprise is willing to peer indirectly through Transit-PSP only with domains that meet certain requirements such as that the connection between the Transit-PSP and the terminating domain is secured?=20 In the indirect section it may be worth mentioning the possibility of traversing two transit domains, e.g. if the originating and terminating domains are enterprises that each has a relationship with a different transit PSP. This version of the I-D is much clearer than the previous one regarding Transit and Assisted, but the difference between the cases may not be clear yet. According to the definitions and to Figure 6, I'd think that the Assisting PSP does not handle the media. But then the mention of DBE and of media sub-function in section 3.3 seem to suggest otherwise, as well as step 8 in section 3.3.1 that says 'O/A/T DBE'. Wouldn't this make it a Transit domain?=20 Also in section 3.3. about the Assisted case there are a couple of sentences that refer to 'the federation'. This may be confusing. A couple of editorial nits: Section 3.1.3 first line - SBCs should be SBEs Figure 4, bottom right - O-UE should be T-UE Section 3.3.1 section title, as well as Figure 6 title, 'Assisted PSP' better be 'Assisting PSP' Benny -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Monday, June 18, 2007 2:39 PM To: speermint@ietf.org; Alexander Mayrhofer Subject: RE: [Speermint] I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt=20 Alex -=20 According to our milestones, we're looking to complete work on this I-D in August. Since the underlying draft should now be fairly stable in the run-up to IETF-69, would you please peform a NITS review of this document? I suspect the authors will have some minor changes to make following IETF-69 just before they are ready for WGLC. If we can fix some of the NITS before IETF-69, all the better. Thanks! Jason=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, June 08, 2007 3:50 PM > To: i-d-announce@ietf.org > Cc: speermint@ietf.org > Subject: [Speermint] I-D > ACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Session PEERing for Multimedia=20 > INTerconnect Working Group of the IETF. >=20 > Title : VoIP SIP Peering Use Cases > Author(s) : A. Uzelac, et al. > Filename :=20 > draft-ietf-speermint-voip-consolidated-usecases-02.txt > Pages : 23 > Date : 2007-6-8 > =09 > This document will capture VoIP use case for SIP Peering. It is a=20 > consolidation of Speermint use cases drafts. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip- > consolidated-usecases-02.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then "get=20 > draft-ietf-speermint-voip-consolidated-usecases-02.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-ietf-speermint-voip-consolidated-usecas > es-02.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 22 09:58:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jeZ-0005PZ-59; Fri, 22 Jun 2007 09:58:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jeX-0005PS-Tn for speermint@ietf.org; Fri, 22 Jun 2007 09:58:21 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1jeW-0005dK-GZ for speermint@ietf.org; Fri, 22 Jun 2007 09:58:21 -0400 Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8/Debian-2) with ESMTP id l5MDwJsH008993 for ; Fri, 22 Jun 2007 06:58:19 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.0/8.13.8/Submit) id l5MDwJqB008992 for speermint@ietf.org; Fri, 22 Jun 2007 06:58:19 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 22 Jun 2007 06:58:19 -0700 From: David Meyer To: speermint@ietf.org Message-ID: <20070622135819.GA8971@1-4-5.net> MIME-Version: 1.0 X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "No wasted time, we're alive today, Churnin up the past, there's no easier way, Time's been between us, a means to an end, G_d it's good to be here walking together my friend" -- srv, Life By The Drop User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [Speermint] FYI -- Internet-Drafts Submission Cutoff Dates for the 69th IETF Meeting in Chicago, IL, USA X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1245002962==" Errors-To: speermint-bounces@ietf.org --===============1245002962== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > From: ietf-secretariat@ietf.org > Date: June 22, 2007 12:00:02 AM EDT > To: ietf-announce@ietf.org > Subject: Internet-Drafts Submission Cutoff Dates for the 69th IETF =20 > Meeting in Chicago, IL, USA >=20 >=20 > There are two (2) Internet-Draft cutoff dates for the 69th > IETF Meeting in Chicago, IL, USA: >=20 > July 2nd: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions >=20 > All initial Internet-Drafts (version -00) must be submitted by Monday, > July 2nd at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > June 25th at 9:00 AM ET. >=20 > July 9th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions >=20 > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, July 9th at 9:00 AM ET. >=20 > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, July 23rd at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. >=20 > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. >=20 > The IETF Secretariat >=20 > FYI: The Internet-Draft cutoff dates as well as other significant =20 > dates > for the 69th IETF Meeting can be found at http://www.ietf.org/=20 > meetings/cutoff_dates_69.html. >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFGe9V7ORgD1qCZ2KcRApb0AJ9WA+OJkAX9SkFyTx9bu20V7jzwiQCfQPCG uz4BWMj73GL9zX8JXm2HdQ4= =lnr8 -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- --===============1245002962== 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 --===============1245002962==-- From speermint-bounces@ietf.org Fri Jun 22 13:15:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1mj5-00005a-Et; Fri, 22 Jun 2007 13:15:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1mj4-00005P-MC for speermint@ietf.org; Fri, 22 Jun 2007 13:15:14 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1mj4-0002Fz-0J for speermint@ietf.org; Fri, 22 Jun 2007 13:15:14 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JK10056PRPAMR@siemenscomms.co.uk> for speermint@ietf.org; Fri, 22 Jun 2007 18:10:22 +0100 (BST) Date: Fri, 22 Jun 2007 18:10:32 +0100 From: "Elwell, John" Subject: RE: [Speermint] I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt In-reply-to: A <3036F4A94122BD4AAAAB441FE888452818688C@300815ANEX3.global.avaya.com> To: "Rodrig, Benny (Benny)" , speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019EC03@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] I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt Thread-Index: AceqBlIdXcS1i2PSRICH6YaePBSSAgH0VtRAAAELLpAAxQmdUA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <45AEC6EF95942140888406588E1A660201A29E41@PACDCEXCMB04.cable.comcast.com> A <3036F4A94122BD4AAAAB441FE888452818688C@300815ANEX3.global.avaya.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I have not seen any discussion on this since Benny posted it, but as co-author of the enterprise peering draft I agree with these comments. I have other comments too, including more concerns about the assisted versus indirect issue, which I will post separately. John > -----Original Message----- > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > Sent: 18 June 2007 22:22 > To: speermint@ietf.org > Subject: RE: [Speermint] > I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt > > Adam, all, > > I have a few comments on > draft-ietf-speermint-voip-consolidated-usecases-02. > > I think the draft should state that the Originating Domain and/or the > Terminating Domain can be either a commercial service provider or an > enterprise. This statement can be added in section 3 just before 3.1. > > I'd suggest also adding a couple of points regarding enterprises after > this statement, or possibly somewhere else in the draft: > One is a sentence about regulatory requirements potentially being > different in the case of enterprises. > And the other is something like the following sentence: 'Other models > for session interconnect in the context of enterprise > scenarios, such as > subscription-based models and transit models for intra-enterprise > communications, are out of scope of Speermint.' > > If there is agreement that the domains can be enterprises, then a > decision is needed on the use of the term VSP. The draft can > say clearly > that the term VSP in this draft refers to either a commercial VoIP > service provider or an enterprise VoIP domain. This can be > added to the > definition of VSP in the terminology section. The text in section > 3.1.2.2 that distinguishes between a service provider and an > enterprise > should then be explicit and say something like 'commercial > VoIP Service > Provider'. Also 3.1.3.2 seems to use the term VSP to mean > non-enterprise, but there the distinction doesn't seem to be needed at > all as a following sentence adds that this is also applicable to > enterprises. > > Does it make sense to add to the administrative characteristics of > transit (section 3.2.1.1) something about transitive > conditions, e.g. an > originating enterprise is willing to peer indirectly through > Transit-PSP > only with domains that meet certain requirements such as that the > connection between the Transit-PSP and the terminating domain is > secured? > > In the indirect section it may be worth mentioning the possibility of > traversing two transit domains, e.g. if the originating and > terminating > domains are enterprises that each has a relationship with a different > transit PSP. > > This version of the I-D is much clearer than the previous one > regarding > Transit and Assisted, but the difference between the cases may not be > clear yet. According to the definitions and to Figure 6, I'd > think that > the Assisting PSP does not handle the media. But then the > mention of DBE > and of media sub-function in section 3.3 seem to suggest otherwise, as > well as step 8 in section 3.3.1 that says 'O/A/T DBE'. Wouldn't this > make it a Transit domain? > > Also in section 3.3. about the Assisted case there are a couple of > sentences that refer to 'the federation'. This may be confusing. > > A couple of editorial nits: > Section 3.1.3 first line - SBCs should be SBEs > Figure 4, bottom right - O-UE should be T-UE > Section 3.3.1 section title, as well as Figure 6 title, 'Assisted PSP' > better be 'Assisting PSP' > > > Benny > > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, June 18, 2007 2:39 PM > To: speermint@ietf.org; Alexander Mayrhofer > Subject: RE: [Speermint] > I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt > > Alex - > > According to our milestones, we're looking to complete work > on this I-D > in August. Since the underlying draft should now be fairly stable in > the run-up to IETF-69, would you please peform a NITS review of this > document? I suspect the authors will have some minor changes to make > following IETF-69 just before they are ready for WGLC. If we can fix > some of the NITS before IETF-69, all the better. > > Thanks! > Jason > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Friday, June 08, 2007 3:50 PM > > To: i-d-announce@ietf.org > > Cc: speermint@ietf.org > > Subject: [Speermint] I-D > > ACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Session PEERing for Multimedia > > INTerconnect Working Group of the IETF. > > > > Title : VoIP SIP Peering Use Cases > > Author(s) : A. Uzelac, et al. > > Filename : > > draft-ietf-speermint-voip-consolidated-usecases-02.txt > > Pages : 23 > > Date : 2007-6-8 > > > > This document will capture VoIP use case for SIP Peering. It is a > > consolidation of Speermint use cases drafts. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip- > > consolidated-usecases-02.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-voip-consolidated-usecases-02.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-voip-consolidated-usecas > > es-02.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jun 22 16:16: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 1I1pYs-0004TO-Kq; Fri, 22 Jun 2007 16:16:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1pYq-0004TF-T5 for speermint@ietf.org; Fri, 22 Jun 2007 16:16:52 -0400 Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1pYp-0002Y4-5M for speermint@ietf.org; Fri, 22 Jun 2007 16:16:52 -0400 Received: from notes.rz.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1I1pYo-0001QQ-9X; Fri, 22 Jun 2007 22:16:50 +0200 From: Heike Schmidt-Hunkel/Denic To: speermint@ietf.org Message-ID: Date: Fri, 22 Jun 2007 22:16:42 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 22.06.2007 22:16:49 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Speermint] =?iso-8859-1?q?Heike_Schmidt-Hunkel_ist_au=DFer_Haus?= =?iso-8859-1?q?=2E?= X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Ich werde ab 22.06.2007 nicht im B=FCro sein. Ich kehre zur=FCck am 0= 2.07.2007. Ich werde Ihre Nachricht nach meiner R=FCckkehr beantworten.= _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jun 25 08:39:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nqj-00084Q-LJ; Mon, 25 Jun 2007 08:39:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nqi-00084L-GM for speermint@ietf.org; Mon, 25 Jun 2007 08:39:20 -0400 Received: from bzq-25-94-44.static.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2nqg-0006zo-HX for speermint@ietf.org; Mon, 25 Jun 2007 08:39:20 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Speermint] I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt Date: Mon, 25 Jun 2007 15:39:12 +0300 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A60655034CAB5C@isr-jlm-mail.Kayote.com> In-Reply-To: <3036F4A94122BD4AAAAB441FE888452818688C@300815ANEX3.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt Thread-Index: AceqBlIdXcS1i2PSRICH6YaePBSSAgH0VtRAAAELLpABTxIEMA== References: <45AEC6EF95942140888406588E1A660201A29E41@PACDCEXCMB04.cable.comcast.com> <3036F4A94122BD4AAAAB441FE888452818688C@300815ANEX3.global.avaya.com> From: "David Schwartz" To: "Rodrig, Benny (Benny)" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi Benny. I see this issue coming up in many postings regarding the differences between indirect and assisted peering so I figured I would throw in my two cents.=20 While not what I had initially put down in my use case draft, the more I think about it the more I feel that this should be our approach. I think we can all agree that indirect (as the name implies) refers to either signaling or media or both traversing one or more intermediary nodes.=20 Assisted on the other hand makes no such assumption. Assisted merely implies that some assistance is provided to the originating or terminating party in peering. Since assistance in the form of signaling (e.g. interoperability) or media (e.g. transcoding) is covered under the indirect relationship, the functions I see associated with the assisted model are: * The lookup function (who owns the number) * covers any mechanism reducing the need for an endpoint=20 to hold all number ranges of all his peers (this can=20 include a centralized database accessible via ENUM or a=20 DHT containing all relevant information) * Routing (how to get there) * note that this may require the assistance of an element filling the Role of indirect peering * Policy (who can see what) * Who gets a direct uri to other peer=20 * Who must use intermediary * Who gets a 404 Not found A hub and spoke federation would thus be fulfilling the two functions at the same time - the role of assisted for lookup and the role of indirect for the anchoring of signaling and media. Any thoughts? D. -----Original Message----- From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com]=20 Sent: Tuesday, June 19, 2007 12:22 AM To: speermint@ietf.org Subject: RE: [Speermint] I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt=20 Adam, all, I have a few comments on draft-ietf-speermint-voip-consolidated-usecases-02. I think the draft should state that the Originating Domain and/or the Terminating Domain can be either a commercial service provider or an enterprise. This statement can be added in section 3 just before 3.1. I'd suggest also adding a couple of points regarding enterprises after this statement, or possibly somewhere else in the draft: One is a sentence about regulatory requirements potentially being different in the case of enterprises.=20 And the other is something like the following sentence: 'Other models for session interconnect in the context of enterprise scenarios, such as subscription-based models and transit models for intra-enterprise communications, are out of scope of Speermint.' If there is agreement that the domains can be enterprises, then a decision is needed on the use of the term VSP. The draft can say clearly that the term VSP in this draft refers to either a commercial VoIP service provider or an enterprise VoIP domain. This can be added to the definition of VSP in the terminology section. The text in section 3.1.2.2 that distinguishes between a service provider and an enterprise should then be explicit and say something like 'commercial VoIP Service Provider'. Also 3.1.3.2 seems to use the term VSP to mean non-enterprise, but there the distinction doesn't seem to be needed at all as a following sentence adds that this is also applicable to enterprises. Does it make sense to add to the administrative characteristics of transit (section 3.2.1.1) something about transitive conditions, e.g. an originating enterprise is willing to peer indirectly through Transit-PSP only with domains that meet certain requirements such as that the connection between the Transit-PSP and the terminating domain is secured?=20 In the indirect section it may be worth mentioning the possibility of traversing two transit domains, e.g. if the originating and terminating domains are enterprises that each has a relationship with a different transit PSP. This version of the I-D is much clearer than the previous one regarding Transit and Assisted, but the difference between the cases may not be clear yet. According to the definitions and to Figure 6, I'd think that the Assisting PSP does not handle the media. But then the mention of DBE and of media sub-function in section 3.3 seem to suggest otherwise, as well as step 8 in section 3.3.1 that says 'O/A/T DBE'. Wouldn't this make it a Transit domain?=20 Also in section 3.3. about the Assisted case there are a couple of sentences that refer to 'the federation'. This may be confusing. A couple of editorial nits: Section 3.1.3 first line - SBCs should be SBEs Figure 4, bottom right - O-UE should be T-UE Section 3.3.1 section title, as well as Figure 6 title, 'Assisted PSP' better be 'Assisting PSP' Benny -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Monday, June 18, 2007 2:39 PM To: speermint@ietf.org; Alexander Mayrhofer Subject: RE: [Speermint] I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt=20 Alex -=20 According to our milestones, we're looking to complete work on this I-D in August. Since the underlying draft should now be fairly stable in the run-up to IETF-69, would you please peform a NITS review of this document? I suspect the authors will have some minor changes to make following IETF-69 just before they are ready for WGLC. If we can fix some of the NITS before IETF-69, all the better. Thanks! Jason=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, June 08, 2007 3:50 PM > To: i-d-announce@ietf.org > Cc: speermint@ietf.org > Subject: [Speermint] I-D > ACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Session PEERing for Multimedia=20 > INTerconnect Working Group of the IETF. >=20 > Title : VoIP SIP Peering Use Cases > Author(s) : A. Uzelac, et al. > Filename :=20 > draft-ietf-speermint-voip-consolidated-usecases-02.txt > Pages : 23 > Date : 2007-6-8 > =09 > This document will capture VoIP use case for SIP Peering. It is a=20 > consolidation of Speermint use cases drafts. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip- > consolidated-usecases-02.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then "get=20 > draft-ietf-speermint-voip-consolidated-usecases-02.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-ietf-speermint-voip-consolidated-usecas > es-02.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jun 25 11:05:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2q89-0006qM-5N; Mon, 25 Jun 2007 11:05:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2q87-0006qH-Jy for speermint@ietf.org; Mon, 25 Jun 2007 11:05:27 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2q86-00079M-Sn for speermint@ietf.org; Mon, 25 Jun 2007 11:05:27 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JK700I7Z5TYJV@siemenscomms.co.uk> for speermint@ietf.org; Mon, 25 Jun 2007 16:03:34 +0100 (BST) Date: Mon, 25 Jun 2007 16:03:43 +0100 From: "Elwell, John" Subject: RE: [Speermint]I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt In-reply-to: <1DDB0D3CC4E7F14FAE946361C0A60655034CAB5C@isr-jlm-mail.Kayote.com> To: David Schwartz , "Rodrig, Benny (Benny)" , speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019ECD9@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]I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt Thread-Index: AceqBlIdXcS1i2PSRICH6YaePBSSAgH0VtRAAAELLpABTxIEMAAITyUg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <45AEC6EF95942140888406588E1A660201A29E41@PACDCEXCMB04.cable.comcast.com> <3036F4A94122BD4AAAAB441FE888452818688C@300815ANEX3.global.avaya.com> <1DDB0D3CC4E7F14FAE946361C0A60655034CAB5C@isr-jlm-mail.Kayote.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > -----Original Message----- > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > Sent: 25 June 2007 13:39 > To: Rodrig, Benny (Benny); speermint@ietf.org > Subject: RE: > [Speermint]I-DACTION:draft-ietf-speermint-voip-consolidated-us > ecases-02.txt > > Hi Benny. > > I see this issue coming up in many postings regarding the differences > between indirect and assisted peering so I figured I would throw in my > two cents. > > While not what I had initially put down in my use case draft, > the more I > think about it the more I feel that this should be our approach. > > I think we can all agree that indirect (as the name implies) refers to > either signaling or media or both traversing one or more intermediary > nodes. [JRE] It seems reasonable to use this term when signalling traverses one or more intermediate nodes, whether or not media does so too. I don't see a case where media does so without signalling. > > Assisted on the other hand makes no such assumption. Assisted merely > implies that some assistance is provided to the originating or > terminating party in peering. Since assistance in the form of > signaling > (e.g. interoperability) or media (e.g. transcoding) is > covered under the > indirect relationship, the functions I see associated with > the assisted > model are: > > * The lookup function (who owns the number) > * covers any mechanism reducing the need for an endpoint > to hold all number ranges of all his peers (this can > include a centralized database accessible via ENUM or a > DHT containing all relevant information) > > * Routing (how to get there) > * note that this may require the assistance of an element filling > the > Role of indirect peering > > * Policy (who can see what) > * Who gets a direct uri to other peer > * Who must use intermediary > * Who gets a 404 Not found > > A hub and spoke federation would thus be fulfilling the two > functions at > the same time - the role of assisted for lookup and the role > of indirect > for the anchoring of signaling and media. [JRE] This seems to imply to me that indirect is a subset of assisted, i.e., with indirect, the intermediate signalling nodes are still doing look-up, routing and policy. John > > Any thoughts? > > D. > > -----Original Message----- > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > Sent: Tuesday, June 19, 2007 12:22 AM > To: speermint@ietf.org > Subject: RE: [Speermint] > I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt > > Adam, all, > > I have a few comments on > draft-ietf-speermint-voip-consolidated-usecases-02. > > I think the draft should state that the Originating Domain and/or the > Terminating Domain can be either a commercial service provider or an > enterprise. This statement can be added in section 3 just before 3.1. > > I'd suggest also adding a couple of points regarding enterprises after > this statement, or possibly somewhere else in the draft: > One is a sentence about regulatory requirements potentially being > different in the case of enterprises. > And the other is something like the following sentence: 'Other models > for session interconnect in the context of enterprise > scenarios, such as > subscription-based models and transit models for intra-enterprise > communications, are out of scope of Speermint.' > > If there is agreement that the domains can be enterprises, then a > decision is needed on the use of the term VSP. The draft can > say clearly > that the term VSP in this draft refers to either a commercial VoIP > service provider or an enterprise VoIP domain. This can be > added to the > definition of VSP in the terminology section. The text in section > 3.1.2.2 that distinguishes between a service provider and an > enterprise > should then be explicit and say something like 'commercial > VoIP Service > Provider'. Also 3.1.3.2 seems to use the term VSP to mean > non-enterprise, but there the distinction doesn't seem to be needed at > all as a following sentence adds that this is also applicable to > enterprises. > > Does it make sense to add to the administrative characteristics of > transit (section 3.2.1.1) something about transitive > conditions, e.g. an > originating enterprise is willing to peer indirectly through > Transit-PSP > only with domains that meet certain requirements such as that the > connection between the Transit-PSP and the terminating domain is > secured? > > In the indirect section it may be worth mentioning the possibility of > traversing two transit domains, e.g. if the originating and > terminating > domains are enterprises that each has a relationship with a different > transit PSP. > > This version of the I-D is much clearer than the previous one > regarding > Transit and Assisted, but the difference between the cases may not be > clear yet. According to the definitions and to Figure 6, I'd > think that > the Assisting PSP does not handle the media. But then the > mention of DBE > and of media sub-function in section 3.3 seem to suggest otherwise, as > well as step 8 in section 3.3.1 that says 'O/A/T DBE'. Wouldn't this > make it a Transit domain? > > Also in section 3.3. about the Assisted case there are a couple of > sentences that refer to 'the federation'. This may be confusing. > > A couple of editorial nits: > Section 3.1.3 first line - SBCs should be SBEs > Figure 4, bottom right - O-UE should be T-UE > Section 3.3.1 section title, as well as Figure 6 title, 'Assisted PSP' > better be 'Assisting PSP' > > > Benny > > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, June 18, 2007 2:39 PM > To: speermint@ietf.org; Alexander Mayrhofer > Subject: RE: [Speermint] > I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt > > Alex - > > According to our milestones, we're looking to complete work > on this I-D > in August. Since the underlying draft should now be fairly stable in > the run-up to IETF-69, would you please peform a NITS review of this > document? I suspect the authors will have some minor changes to make > following IETF-69 just before they are ready for WGLC. If we can fix > some of the NITS before IETF-69, all the better. > > Thanks! > Jason > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Friday, June 08, 2007 3:50 PM > > To: i-d-announce@ietf.org > > Cc: speermint@ietf.org > > Subject: [Speermint] I-D > > ACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Session PEERing for Multimedia > > INTerconnect Working Group of the IETF. > > > > Title : VoIP SIP Peering Use Cases > > Author(s) : A. Uzelac, et al. > > Filename : > > draft-ietf-speermint-voip-consolidated-usecases-02.txt > > Pages : 23 > > Date : 2007-6-8 > > > > This document will capture VoIP use case for SIP Peering. It is a > > consolidation of Speermint use cases drafts. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip- > > consolidated-usecases-02.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-voip-consolidated-usecases-02.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-voip-consolidated-usecas > > es-02.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jun 25 11:27: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 1I2qT6-0003GQ-7t; Mon, 25 Jun 2007 11:27:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qT5-0003GI-0p for speermint@ietf.org; Mon, 25 Jun 2007 11:27:07 -0400 Received: from bzq-25-94-44.static.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2qT3-00070B-Lj for speermint@ietf.org; Mon, 25 Jun 2007 11:27:07 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Speermint]I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt Date: Mon, 25 Jun 2007 18:27:03 +0300 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A60655034CABC6@isr-jlm-mail.Kayote.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019ECD9@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint]I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt Thread-Index: AceqBlIdXcS1i2PSRICH6YaePBSSAgH0VtRAAAELLpABTxIEMAAITyUgAACFjQA= References: <45AEC6EF95942140888406588E1A660201A29E41@PACDCEXCMB04.cable.comcast.com> <3036F4A94122BD4AAAAB441FE888452818688C@300815ANEX3.global.avaya.com> <1DDB0D3CC4E7F14FAE946361C0A60655034CAB5C@isr-jlm-mail.Kayote.com> <0D5F89FAC29E2C41B98A6A762007F5D019ECD9@GBNTHT12009MSX.gb002.siemens.net> From: "David Schwartz" To: "Elwell, John" , "Rodrig, Benny (Benny)" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >> I think we can all agree that indirect (as the name implies) refers to >> either signaling or media or both traversing one or more intermediary >> nodes.=20 >[JRE] It seems reasonable to use this term when signalling traverses one >or more intermediate nodes, whether or not media does so too. I don't > see a case where media does so without signalling. Good point. >> Assisted on the other hand makes no such assumption. Assisted merely >> implies that some assistance is provided to the originating or >> terminating party in peering. Since assistance in the form of=20 >> signaling (e.g. interoperability) or media (e.g. transcoding) is=20 >> covered under the indirect relationship, the functions I see=20 >> associated with the assisted model are ... >[JRE] This seems to imply to me that indirect is a subset of assisted, >i.e., with indirect, the intermediate signalling nodes are still doing >look-up, routing and policy. Not necessarily. Let's not confuse the entity doing the lookup with the entity providing the lookup as a service. Yes the intermediate elements need to look up the information and for all we know they may look it up at the same place that the originating peer did (and will probably get a different answer - they are more trusted). The point is the indirect peer does not hold this information himself and provide this as a service (unless he is also the assisting peer). I see all these models as service providing roles. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jun 25 13:38:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sWM-0001dz-Aj; Mon, 25 Jun 2007 13:38:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sWL-0001ZN-Lp for speermint@ietf.org; Mon, 25 Jun 2007 13:38:37 -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 1I2sWJ-0004WR-BY for speermint@ietf.org; Mon, 25 Jun 2007 13:38:37 -0400 Received: from unknown (HELO 300815ANEX3.global.avaya.com) ([198.152.6.137]) by co300216-co-outbound.avaya.com with ESMTP; 25 Jun 2007 13:38:34 -0400 X-IronPort-AV: i="4.16,460,1175486400"; d="scan'208"; a="33762630:sNHT10478700" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint]I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt Date: Mon, 25 Jun 2007 13:37:06 -0400 Message-ID: <3036F4A94122BD4AAAAB441FE88845281B29AF@300815ANEX3.global.avaya.com> In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A60655034CABC6@isr-jlm-mail.Kayote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint]I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt Thread-Index: AceqBlIdXcS1i2PSRICH6YaePBSSAgH0VtRAAAELLpABTxIEMAAITyUgAACFjQAAA7tl4A== References: <45AEC6EF95942140888406588E1A660201A29E41@PACDCEXCMB04.cable.comcast.com> <3036F4A94122BD4AAAAB441FE888452818688C@300815ANEX3.global.avaya.com> <1DDB0D3CC4E7F14FAE946361C0A60655034CAB5C@isr-jlm-mail.Kayote.com> <0D5F89FAC29E2C41B98A6A762007F5D019ECD9@GBNTHT12009MSX.gb002.siemens.net> <1DDB0D3CC4E7F14FAE946361C0A60655034CABC6@isr-jlm-mail.Kayote.com> From: "Rodrig, Benny (Benny)" To: "David Schwartz" , "Elwell, John" , X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org David, This makes sense to me. But I think you're saying that Assisted is kind of orthogonal to direct/indirect, and if this is the approach we take, then the draft should not describe them simply as three cases implying either/or.=20 According to this approach Figure 5 in draft -02 is really Assisted via Transit PSP. If you want to account for the case that the Assisting PSP and the Transit PSP are different providers then the diagram can show some optional separation between the upper and the lower parts of that domain. If there is a valid use case of Indirect/Transit which is not also Assisted peering, then a new diagram and description are needed, which are similar to Figure 5 but do not have the interactions (2) and (3) between O-SM and t-SM/t-LS and instead have interactions between t-SBE and t-SM/t-LS. Benny -----Original Message----- From: David Schwartz [mailto:David.Schwartz@Kayote.com]=20 Sent: Monday, June 25, 2007 11:27 AM To: Elwell, John; Rodrig, Benny (Benny); speermint@ietf.org Subject: RE: [Speermint]I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02. txt >> I think we can all agree that indirect (as the name implies) refers to >> either signaling or media or both traversing one or more intermediary >> nodes. >[JRE] It seems reasonable to use this term when signalling traverses one >or more intermediate nodes, whether or not media does so too. I don't =20 >see a case where media does so without signalling. Good point. >> Assisted on the other hand makes no such assumption. Assisted merely=20 >> implies that some assistance is provided to the originating or=20 >> terminating party in peering. Since assistance in the form of=20 >> signaling (e.g. interoperability) or media (e.g. transcoding) is=20 >> covered under the indirect relationship, the functions I see=20 >> associated with the assisted model are ... >[JRE] This seems to imply to me that indirect is a subset of assisted,=20 >i.e., with indirect, the intermediate signalling nodes are still doing=20 >look-up, routing and policy. Not necessarily. Let's not confuse the entity doing the lookup with the entity providing the lookup as a service. Yes the intermediate elements need to look up the information and for all we know they may look it up at the same place that the originating peer did (and will probably get a different answer - they are more trusted). The point is the indirect peer does not hold this information himself and provide this as a service (unless he is also the assisting peer). I see all these models as service providing roles. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jun 25 14:08:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2szc-0007Hy-KY; Mon, 25 Jun 2007 14:08:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2szb-0007Hs-Aq for speermint@ietf.org; Mon, 25 Jun 2007 14:08:51 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2sza-0001Pg-Tu for speermint@ietf.org; Mon, 25 Jun 2007 14:08:51 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JK700J5PEEF35@siemenscomms.co.uk> for speermint@ietf.org; Mon, 25 Jun 2007 19:08:39 +0100 (BST) Date: Mon, 25 Jun 2007 19:08:49 +0100 From: "Elwell, John" Subject: RE: [Speermint]I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt In-reply-to: A <3036F4A94122BD4AAAAB441FE88845281B29AF@300815ANEX3.global.avaya.com> To: "Rodrig, Benny (Benny)" , David Schwartz , speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019ED0C@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]I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt Thread-Index: AceqBlIdXcS1i2PSRICH6YaePBSSAgH0VtRAAAELLpABTxIEMAAITyUgAACFjQAAA7tl4AACUQBw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <45AEC6EF95942140888406588E1A660201A29E41@PACDCEXCMB04.cable.comcast.com> <3036F4A94122BD4AAAAB441FE888452818688C@300815ANEX3.global.avaya.com> <1DDB0D3CC4E7F14FAE946361C0A60655034CAB5C@isr-jlm-mail.Kayote.com> <0D5F89FAC29E2C41B98A6A762007F5D019ECD9@GBNTHT12009MSX.gb002.siemens.net> <1DDB0D3CC4E7F14FAE946361C0A60655034CABC6@isr-jlm-mail.Kayote.com> A <3036F4A94122BD4AAAAB441FE88845281B29AF@300815ANEX3.global.avaya.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Yes, I agree they are two orthogonal concepts. If they were described in that way it would make sense. John > -----Original Message----- > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > Sent: 25 June 2007 18:37 > To: David Schwartz; Elwell, John; speermint@ietf.org > Subject: RE: > [Speermint]I-DACTION:draft-ietf-speermint-voip-consolidated-us > ecases-02.txt > > David, > > This makes sense to me. But I think you're saying that > Assisted is kind > of orthogonal to direct/indirect, and if this is the approach we take, > then the draft should not describe them simply as three cases implying > either/or. > > According to this approach Figure 5 in draft -02 is really > Assisted via > Transit PSP. If you want to account for the case that the > Assisting PSP > and the Transit PSP are different providers then the diagram can show > some optional separation between the upper and the lower parts of that > domain. > > If there is a valid use case of Indirect/Transit which is not also > Assisted peering, then a new diagram and description are needed, which > are similar to Figure 5 but do not have the interactions (2) and (3) > between O-SM and t-SM/t-LS and instead have interactions between t-SBE > and t-SM/t-LS. > > Benny > > > -----Original Message----- > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > Sent: Monday, June 25, 2007 11:27 AM > To: Elwell, John; Rodrig, Benny (Benny); speermint@ietf.org > Subject: RE: > [Speermint]I-DACTION:draft-ietf-speermint-voip-consolidated-us > ecases-02. > txt > > >> I think we can all agree that indirect (as the name implies) refers > to > >> either signaling or media or both traversing one or more > intermediary > > >> nodes. > > >[JRE] It seems reasonable to use this term when signalling traverses > one > >or more intermediate nodes, whether or not media does so > too. I don't > >see a case where media does so without signalling. > > Good point. > > >> Assisted on the other hand makes no such assumption. > Assisted merely > >> implies that some assistance is provided to the originating or > >> terminating party in peering. Since assistance in the form of > >> signaling (e.g. interoperability) or media (e.g. transcoding) is > >> covered under the indirect relationship, the functions I see > >> associated with the assisted model are ... > > >[JRE] This seems to imply to me that indirect is a subset of > assisted, > >i.e., with indirect, the intermediate signalling nodes are > still doing > >look-up, routing and policy. > > Not necessarily. Let's not confuse the entity doing the > lookup with the > entity providing the lookup as a service. Yes the > intermediate elements > need to look up the information and for all we know they may > look it up > at the same place that the originating peer did (and will > probably get a > different answer - they are more trusted). The point is the indirect > peer does not hold this information himself and provide this as a > service (unless he is also the assisting peer). > > I see all these models as service providing roles. > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jun 25 15:51:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2uat-0001Ht-B3; Mon, 25 Jun 2007 15:51:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2uaT-0000cP-7p; Mon, 25 Jun 2007 15:51:01 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2uZW-0003vE-AH; Mon, 25 Jun 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 46A973289D; Mon, 25 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I2uZW-0000g3-5X; Mon, 25 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 25 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-07.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-07.txt Pages : 11 Date : 2007-6-25 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-07.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-07.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-07.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-6-25131254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-terminology-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-terminology-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-25131254.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 Jun 27 18:35:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3g77-0002ej-IM; Wed, 27 Jun 2007 18:35:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3g76-0002ee-TT for speermint@ietf.org; Wed, 27 Jun 2007 18:35:52 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3g6W-0008CG-QZ for speermint@ietf.org; Wed, 27 Jun 2007 18:35:52 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l5RMZFRC007114 for ; Wed, 27 Jun 2007 16:35:16 -0600 (MDT) Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 27 Jun 2007 16:35:15 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [speermint] terminology draft-07, SSP and collapse of indirect & assisted peering Date: Wed, 27 Jun 2007 16:35:20 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C62E9718@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] terminology draft-07, SSP and collapse of indirect & assisted peering Thread-Index: Ace5C3FU3itkKC6IRB6ravv0/xribQ== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org With the replacement of VSP by SSP and the related changes in the SSP definition, I'm not sure what the differences are between indirect and assisted peering.=20 The 2 terms seem to collapse into one - can someone explain? Thank you, Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jun 28 06:45:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rVI-0008Ak-Na; Thu, 28 Jun 2007 06:45:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rVH-00088C-04 for speermint@ietf.org; Thu, 28 Jun 2007 06:45:35 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3rUs-0003Nm-D4 for speermint@ietf.org; Thu, 28 Jun 2007 06:45:34 -0400 Received: from [10.10.0.127] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 28 Jun 2007 12:45:07 +0200 id 0006C06D.46839134.000062C0 Message-ID: <468390BF.6090709@enum.at> Date: Thu, 28 Jun 2007 12:43:11 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: speermint Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Speermint] NITS review for draft-ietf-speermint-terminology-07 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi, I've done a NITS review on the draft - my comments are as follows: - the automatic idnits checker reports a few problems - most notably, the draft does not seem to contain any proper page breaks (confirmed here while printing the draft). - The document contains a lot of acronyms that are never expanded/refered - I've seen NAPTR (section 1), SRV (section 3.3), TLS (section 3.3), DSCP (section 3.3), UAS/UAC (section 3.7), BGP (section 4.1), RTCP/RTCP-XR (section 5). In most cases, an informative reference would also be good. - I'm slightly confused by section 3.8 vs. 3.9 - i think the difference between those definitions would become much clearer if we would change "... that provides transport ..." to "... that provides application level transport ..." in section 3.9 - otherwise it's really hard to distinguish those two definitions. (SP = "my ISP", SSP = "my voip provider" if i got it right?) - Section 4.2 mandates Layer 5 peering to be "secure call signaling". Does that mean that plain RFC3261/RFC3263 SIP signaling over UDP/TCP does not qualify? Same applies to section 4.2.2 - I think that some of the peering definitions might overlap. For example, is "on-demand peering" always "direct"? It seems to my as if there are several "dimensions" of peering types, one dimension being "direct/indirect/assisted", and the other dimension "on-demand/static" - eg. RFC3261/3263 would be "direct", and "on-demand". Not sure whether it would make sense to say something about that, though. - I'd prefer "CODEC" not to be written in all caps unless there is some special meaning behind (Section 5) - There seems to be a typo in section 5, "Finally, note that a SIP can..." probably should read "Finally, note that a SP can..." hope this is useful :) Alex _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint