From speermint-bounces@ietf.org Thu Jul 05 15:35: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 1I6X6u-0007Iw-Vj; Thu, 05 Jul 2007 15:35:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6X6t-0007DS-GL for speermint@ietf.org; Thu, 05 Jul 2007 15:35:27 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6X6t-0000S6-6A for speermint@ietf.org; Thu, 05 Jul 2007 15:35:27 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l65JYG7h018350; Thu, 5 Jul 2007 19:34:17 GMT Subject: Re: [Speermint] NITS review for draft-ietf-speermint-terminology-07 From: Daryl Malas To: Alexander Mayrhofer In-Reply-To: <468390BF.6090709@enum.at> References: <468390BF.6090709@enum.at> Content-Type: text/plain Date: Thu, 05 Jul 2007 12:35:23 -0600 Message-Id: <1183660524.26829.0.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: speermint X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Alexander, Thank you...I will update draft. --Daryl On Thu, 2007-06-28 at 12:43 +0200, Alexander Mayrhofer wrote: > 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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 05 17:45: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 1I6Z8R-0006QC-Mg; Thu, 05 Jul 2007 17:45:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Z8Q-0006Q3-0K for speermint@ietf.org; Thu, 05 Jul 2007 17:45:10 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6Z8P-0000bJ-HP for speermint@ietf.org; Thu, 05 Jul 2007 17:45:09 -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 l65Lhtjg025729; Thu, 5 Jul 2007 15:43:55 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Thu, 5 Jul 2007 15:43:55 -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] comments on draft-ietf-speermint-voip-consolidated-usecases-02 Date: Thu, 5 Jul 2007 15:43:47 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C62E9C2E@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speermint] comments on draft-ietf-speermint-voip-consolidated-usecases-02 Thread-Index: AceXQ5LoKh6mOINvSpGrq35soxK40gBjgkkgAUT+LVAAP7QhQAaI024w References: A<45AEC6EF95942140888406588E1A660201A2987F@PACDCEXCMB04.cable.comcast.com><0D5F89FAC29E2C41B98A6A762007F5D012F1BD@GBNTHT12009MSX.gb002.siemens.net> From: "Jean-Francois Mule" To: "Uzelac, Adam" , , , , , X-Approved: ondar X-Spam-Score: 1.1 (+) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Find below some comments on draft-ietf-speermint-voip-consolidated-usecases-02. --- editorial - Given this is a use case document, is "Intended status: Standards Track" correct? The charter says Informational. - terminology draft-07 alignment: The use case I-D still has too many definitions and some terms used in the description of the use cases (like session manager) are not in the terminology draft-07. This section could be reduced by introducing the conventions used for logical entities that are in the originating (O-), terminating (T-) or transit (t-) domains. --- technical - The use case examples dedicate quite a bit of time & text to describe what all the variants are within one SSP/user group domain: does the originating or terminating "domain" have SBE, SDE, SM, LS, etc.? I am not sure I understand where this leads us in terms of requirements on the interconnect points.=20 Each user group or service provider mging a domain can do whatever they want and add as many layers of indirect signaling/media as they wish. I thought that elements "at the boundary" of the networks were the ones where we wanted speermint to focus on.=20 =3D=3D> what are the differences between (4) in figure 2, (5) in figure = 3, and (5) in figure 4 -- just to focus on signaling? =3D=3D> if there are differences, why do they matter for best current practices? Beyond the labels of the boxes being different, at this stage, the justifications provided in 3.1.2.2. solely focus on the functions an SBE (SBC?) can provide. Some of these are a) session "scrubbing": relates to sip interop stuff which is out of scope of speermint, b) overlapping net10 or RFC1918 address spaces which is suggesting the use case is about SIP/SDP ALG-like mechanisms rather than endpoint functionality like ICE, ...=20 How do those use cases help identify different requirements between scenarios at this stage? I'd be interested in understanding what differs, what kind of SIP headers should be present/supported to allow these use cases. This comment applies across section 3. Thoughts or suggestions for direct peering use case: - take the use case in section 3.1.1. as the only case for direct peering (the others in section 3.1 are trivial simplifications) - add details on special cases where SBE/DBE are typically not necessary, when they are required, what changes in the protocol exchanges between those elements. For e.g., why is it desirable that an SBE be capable of "inserting' an SDE in some cases? One case that is quite common (I think) seems to be missing: an O-SSP has multiple O-SBEs and selection of the SBE depends on the T-SSP domain (multiple "egress" points) or the reverse case (multiple "ingress" points for SBEs, or SDEs). - identification of requirements through the use case examples: Section 3 states: |there are different requirements between the scenarios and=20 |this document serves to help identify the requirements=20 |for SIP Peering for VoIP. Differences in use cases may not always imply differences in requirements; in the next revision, it would be good to summarize what some of those differences are at the end of each section (direct, indirect, assisted). - 4.2.5.: what does this section bring to the use case draft? Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 05 18:16:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ZcU-000636-FW; Thu, 05 Jul 2007 18:16:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Zc9-0004b4-86; Thu, 05 Jul 2007 18:15:53 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6Zc9-0004xn-15; Thu, 05 Jul 2007 18:15:53 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id CF1142AC9C; Thu, 5 Jul 2007 22:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I6ZbK-0006HZ-IQ; Thu, 05 Jul 2007 18:15: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: Thu, 05 Jul 2007 18:15:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-consolidated-presence-im-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 : Presence & Instant Messaging Peering Use Cases Author(s) : A. Houri, et al. Filename : draft-ietf-speermint-consolidated-presence-im-usecases-02.txt Pages : 9 Date : 2007-7-5 The document describes several use cases of peering of non-VoIP services between two or more Service Providers (SP). These Service Providers create a peering relationship between themselves thus enabling their users to collaborate with users on the other Service Provider network. The target of the document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services and presence and Instant Messaging (IM) in particular. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-consolidated-presence-im-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-consolidated-presence-im-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-consolidated-presence-im-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-7-5171514.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-consolidated-presence-im-usecases-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-consolidated-presence-im-usecases-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-5171514.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 Fri Jul 06 06:25:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6l0W-0008I0-7L; Fri, 06 Jul 2007 06:25:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6l0V-0008Hl-3L for speermint@ietf.org; Fri, 06 Jul 2007 06:25:47 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6l0U-0006NX-Q1 for speermint@ietf.org; Fri, 06 Jul 2007 06:25:47 -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 l66APLCc015673 for ; Fri, 6 Jul 2007 04:25:21 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 6 Jul 2007 04:25:21 -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 Date: Fri, 6 Jul 2007 04:25:05 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C62E9C48@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: speermint terminology draft07: on-demand and static Thread-Index: Ace/t+tttXZ8angsR2OAzhoclIErmg== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Speermint] speermint terminology draft07: on-demand and static X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Draft 07 says: --- 4.2.1. Direct Peering=20 Direct peering describes those cases in which two service providers=20 interconnect without using an intervening layer 5 network. ... and then 4.2.4. On-demand Peering=20 Service providers are said to peer on-demand when they are able to=20 exchange traffic without any pre-association prior to the origination of a real-time transaction (like a SIP message) between the domains.=20 Any information that needs to be exchanged between domains in support of peering can be learned through a dynamic protocol mechanism. 4.2.5. Static Peering=20 Service providers are said to peer statically when pre-association=20 between providers is required for the initiation of any real-time=20 transactions (like a SIP message). ----- First, I read this as the debate we had on static vs. dynamic policy is now moving into the basic definitions of peering. I view this ("this" being static vs. on-demand association) as separate from the type of peering and distinct for the 3 basic definitions we had (direct, indirect, assisted). - static peering is a special case of direct peering as "pre-association" is meant between *two* SSPs, and it means that a special policy requires that those 2 SSPs meet and agree on certain policy parameters such as security requirements or associations?, etc. - on-demand peering can be applied to direct, or indirect peering. It is already difficult for everyone to use common terms in the wg documents and I would recommend keeping 3 definitions (direct, indirect, assisted). If the point of those additions is to introduce static vs. dynamic policy stuff, then it could be presented elsewhere in the terminology document. Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 06 10:42:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6p0f-0007L5-Tc; Fri, 06 Jul 2007 10:42:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6p0e-0007Dm-BI for speermint@ietf.org; Fri, 06 Jul 2007 10:42:12 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6p0Z-0005FV-V2 for speermint@ietf.org; Fri, 06 Jul 2007 10:42:12 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l66Eg57h015124; Fri, 6 Jul 2007 14:42:06 GMT Subject: Re: [Speermint] speermint terminology draft07: on-demand and static From: Daryl Malas To: Jean-Francois Mule In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C62E9C48@srvxchg3.cablelabs.com> References: <9AAEDF491EF7CA48AB587781B8F5D7C62E9C48@srvxchg3.cablelabs.com> Content-Type: text/plain Date: Fri, 06 Jul 2007 07:43:16 -0600 Message-Id: <1183729396.26829.6.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org So, I updated 4.2.4 and 4.2.5 with the caveat that both of these are applicable to direct, indirect, assisted. I was hoping this would clarify these from being considered an "either/or" situation to a "and/also" situation. I can remove them entirely if we want to go back down that road, but I think it is clearer now. I just submitted a revision last night, so take a look at -08 and let me know what you think. Thanks...--Daryl On Fri, 2007-07-06 at 04:25 -0600, Jean-Francois Mule wrote: > Draft 07 says: > --- > 4.2.1. Direct Peering > > Direct peering describes those cases in which two service providers > interconnect without using an intervening layer 5 network. > ... > and then > > 4.2.4. On-demand Peering > > Service providers are said to peer on-demand when they are able to > exchange traffic without any pre-association prior to the origination > > of a real-time transaction (like a SIP message) between the domains. > Any information that needs to be exchanged between domains in support > > of peering can be learned through a dynamic protocol mechanism. > > 4.2.5. Static Peering > > Service providers are said to peer statically when pre-association > between providers is required for the initiation of any real-time > transactions (like a SIP message). > ----- > > First, I read this as the debate we had on static vs. dynamic policy is > now moving into the basic definitions of peering. I view this ("this" > being static vs. on-demand association) as separate from the type of > peering and distinct for the 3 basic definitions we had (direct, > indirect, assisted). > - static peering is a special case of direct peering as > "pre-association" is meant between *two* SSPs, and it means that a > special policy requires that those 2 SSPs meet and agree on certain > policy parameters such as security requirements or associations?, etc. > - on-demand peering can be applied to direct, or indirect > peering. > > It is already difficult for everyone to use common terms in the wg > documents and I would recommend keeping 3 definitions (direct, indirect, > assisted). If the point of those additions is to introduce static vs. > dynamic policy stuff, then it could be presented elsewhere in the > terminology document. > > Jean-Francois. > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 06 14:16: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 1I6sLi-0007yJ-4a; Fri, 06 Jul 2007 14:16:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6sLR-0007FZ-DC; Fri, 06 Jul 2007 14:15:53 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6sLQ-00031D-5Z; Fri, 06 Jul 2007 14:15:53 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 059382ACB2; Fri, 6 Jul 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I6sKb-0002td-Oa; Fri, 06 Jul 2007 14:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 06 Jul 2007 14:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-08.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-08.txt Pages : 12 Date : 2007-7-6 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-08.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-08.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-08.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-7-6132200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-terminology-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-terminology-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-6132200.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 Fri Jul 06 17:03:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6uxa-0002zK-DW; Fri, 06 Jul 2007 17:03:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6uxZ-0002yo-Ae for speermint@ietf.org; Fri, 06 Jul 2007 17:03:25 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6uxJ-0004Os-3Q for speermint@ietf.org; Fri, 06 Jul 2007 17:03:24 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l66L2E7h007695 for ; Fri, 6 Jul 2007 21:02:15 GMT Subject: [Speermint] Release Notes: draft-ietf-speermint-terminology-08 From: Daryl Malas To: speermint@ietf.org Content-Type: text/plain Date: Fri, 06 Jul 2007 14:03:26 -0600 Message-Id: <1183752206.26829.12.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org The following updates were made in -08: - I expanded as many acronyms as I could find. I also put references in for almost all of them too. - I updated section 3.9 and made a clarification in 3.8 to provide an ISP as an example SP. - I removed "secure" from section 4.2 and 4.2.2 - I added clarification to "static" and "on-demand" that either can be used for "direct/indirect/assisted" peering types - I changed the case of "Codec" - I changed "SIP" to "SSP" and other "SP" references to "SSP" in section 5. - Also, there should be page breaks now. - I also tweaked a couple of other things as minor nits. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 06 17:06:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6v0Y-0004wk-01; Fri, 06 Jul 2007 17:06:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6v0V-0004oK-M8 for speermint@ietf.org; Fri, 06 Jul 2007 17:06:27 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6v0R-0006fN-BM for speermint@ietf.org; Fri, 06 Jul 2007 17:06:27 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l66L6M7h008989 for ; Fri, 6 Jul 2007 21:06:22 GMT Subject: Re: [Speermint] Release Notes: draft-ietf-speermint-terminology-08 From: Daryl Malas To: speermint@ietf.org In-Reply-To: <1183752206.26829.12.camel@montag.eng.level3.com> References: <1183752206.26829.12.camel@montag.eng.level3.com> Content-Type: text/plain Date: Fri, 06 Jul 2007 14:07:34 -0600 Message-Id: <1183752454.26829.14.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Also, FYI...a -09 version will likely be rolling off very soon, so if you have comments, please send them to me ASAP! Thanks...--Daryl On Fri, 2007-07-06 at 14:03 -0600, Daryl Malas wrote: > The following updates were made in -08: > > - I expanded as many acronyms as I could find. I also put references in > for almost all of them too. > > - I updated section 3.9 and made a clarification in 3.8 to provide an > ISP as an example SP. > > - I removed "secure" from section 4.2 and 4.2.2 > > - I added clarification to "static" and "on-demand" that either can be > used for "direct/indirect/assisted" peering types > > - I changed the case of "Codec" > > - I changed "SIP" to "SSP" and other "SP" references to "SSP" in section > 5. > > - Also, there should be page breaks now. > > - I also tweaked a couple of other things as minor nits. > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jul 06 18:28: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 1I6wHy-0003Bj-Ru; Fri, 06 Jul 2007 18:28:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6wHx-0002tG-Bi for speermint@ietf.org; Fri, 06 Jul 2007 18:28:33 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6wHs-0001qi-30 for speermint@ietf.org; Fri, 06 Jul 2007 18:28:33 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l66MSR7h014750 for ; Fri, 6 Jul 2007 22:28:27 GMT Subject: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology From: Daryl Malas To: speermint@ietf.org Content-Type: text/plain Date: Fri, 06 Jul 2007 16:29:35 -0600 Message-Id: <1183760975.26829.21.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 et. al. (Authors of "draft-ietf-speermint-voip-consolidated-usecases"), Okay, I read through the terminology of the "voip-consolidated-usecases" draft, and here is my analysis: Remove the following term definitions from your draft, because they are already covered in the terminology draft: Direct Peering Indirect Peering Assisted Peering Federations (Note...you have Federations in your terminology section twice!) Voice Service Provider (Now SSP in Terminology draft) Signaling Border Element Data Path Border Element Peering Service Provider - The function of this is included in the SIP Service Provider definition. Direct PSP - I think this is also covered by existing definitions Assisting PSP - Same as Direct PSP comment. There are 3 (1 definite, 2 questionable) terms, which should be added to the next rev. of the terminology draft: Location Server Session Manager - Although I'm not quite sure I understand exactly what this does. User Endpoint - Again, I'm not sure what this is, because this should be a UAC, UAS, or UA in my opinion. These are well defined in RFC 3261 and referenced in the terminology draft. Other terms, which I think should remain in your draft and NOT in the terminology draft are more specific delineations of the terms in the terminology draft. They include: Originating VSP - Which at a minimum should be changed to Originating SSP to remain consistent with the terminology draft. Terminating VSP - See Originating VSP comment. O-SBE T-SBE t-SBE A-SBE O-DBE T-DBE t-DBE This my two cents...Thoughts...--Daryl _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 09 06:11:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7qCu-00059O-Iz; Mon, 09 Jul 2007 06:11:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7qCt-00059J-Pr for speermint@ietf.org; Mon, 09 Jul 2007 06:11:03 -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 1I7qCp-00024Q-1r for speermint@ietf.org; Mon, 09 Jul 2007 06:11: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: FW: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology Date: Mon, 9 Jul 2007 13:10:54 +0300 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A606550376965E@isr-jlm-mail.Kayote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology Thread-Index: AcfAHQW7uBRJugwhTLmbBKF5N/NDTAB4pxWwAALCOIAAATkdwA== From: "David Schwartz" To: "Malas, Daryl" X-Spam-Score: 0.1 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi Daryl I know it's probably too late for this to make it in but I just have a few comments. You define "Assisted Peering" as employing a central SIP proxy - therefore forcing a hub-and-spoke model for this category. I see it differently. I see assisted as "assisting" in call setup but not necessarily having to be in the actual call path.=20 As discussed in previous emails on this thread "Assisted" should be orthogonal to both direct and indirect and if indeed a centralized SIP proxy is deployed than this is an instantiation of both assisted and indirect peering. I would word 4.2.1 - 4.2.3 as follows... 4.2.1. Direct Peering=20 Direct peering describes those cases in which two service providers=20 interconnect without using an intervening layer 5 network.=20 4.2.2. Indirect Peering=20 Indirect, or transit, peering refers to the establishment of a either a signaling and media path or signaling path alone via one (or more) referral or transit network(s). Transit network may be used for technical =20 reasons (e.g. signaling interoperability or media transcoding) or non technical reasons (e.g. QoS, Anonymity). It is generally required that=20 a trust relationship is established between the originating service=20 provider and the transit network on one side, and the transit network and the termination network on the other side.=20 4.2.3. Assisted Peering=20 In this case, some entity (usually a federation, see Section 5)=20 provides peering assistance to either the originating or terminating=20 party. Examples of such assistance can include (but are not limited to): * The lookup function (who owns the number) =20 * 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 relevant lookup information) * The policy function (who can see what and how) * Who gets a direct uri to other peer=20 * Who must use intermediary * Who gets a 404 Not found * The location function (ingress point at terminating or transit peer) =20 * covers any mechanism (including BUT NOT LIMITED to RFC 3263) used to locate the next routing hop for this call. Note that this may=20 require the assistance of an element filling the role of indirect=20 peering as described above. Note as well that this may or may not be related to lookup function. If we can agree on these definitions than there is no need for the additional definitions of on-demand and static peering as these can be represented in terms of the 3 defined terms. For example, on-demand peering is defined today as follows... Service providers are said to peer on-demand when they are able to=20 exchange traffic without any pre-association prior to the origination of a real-time transaction (like a SIP message) between the domains.=20 Any information that needs to be exchanged between domains in support of peering can be learned through a dynamic protocol mechanism. On- demand peering can occur as direct, indirect, or assisted.=20 What is described here can be implemented with a public ENUM root coupled with RFC 3263 filling the roles of Assisted peering and the signaling going directly to the terminating peer filling the role of Direct peering. So why introduce another confusing term? If we think of the 3 peering terms in a logical as opposed to physical sense all models can fold into these terms. One final note. As you probably noticed under assisted peering I broke the location function into a lookup function and a location function. In my experience it is this subtlety that can provide most of the flexibility we need to accommodate most of the models out there. While in many or most cases one URI can be used both for lookup and location - the flexibility to have separate URIs for these must not be sacrificed. I would therefore add this term to the draft as well. Once again I am so sorry that these comments are coming so late but my circumstances did not allow me to devote any time to this until now :( Your thoughts? D. -----Original Message----- From: Daryl Malas [mailto:daryl@level3.net]=20 Sent: Saturday, July 07, 2007 1:30 AM To: speermint@ietf.org Subject: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology Adam et. al. (Authors of "draft-ietf-speermint-voip-consolidated-usecases"), Okay, I read through the terminology of the "voip-consolidated-usecases" draft, and here is my analysis: =20 Remove the following term definitions from your draft, because they are already covered in the terminology draft: =20 Direct Peering Indirect Peering Assisted Peering Federations (Note...you have Federations in your terminology section twice!) Voice Service Provider (Now SSP in Terminology draft) Signaling Border Element Data Path Border Element Peering Service Provider - The function of this is included in the SIP Service Provider definition. Direct PSP - I think this is also covered by existing definitions Assisting PSP - Same as Direct PSP comment. =20 There are 3 (1 definite, 2 questionable) terms, which should be added to the next rev. of the terminology draft: =20 Location Server Session Manager - Although I'm not quite sure I understand exactly what this does. User Endpoint - Again, I'm not sure what this is, because this should be a UAC, UAS, or UA in my opinion. These are well defined in RFC 3261 and referenced in the terminology draft. =20 Other terms, which I think should remain in your draft and NOT in the terminology draft are more specific delineations of the terms in the terminology draft. They include: =20 Originating VSP - Which at a minimum should be changed to Originating SSP to remain consistent with the terminology draft. Terminating VSP - See Originating VSP comment. O-SBE T-SBE t-SBE A-SBE O-DBE T-DBE t-DBE =20 This my two cents...Thoughts...--Daryl _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 09 06:31:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7qWd-0007Gb-1C; Mon, 09 Jul 2007 06:31:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7qWc-0007GR-1u for speermint@ietf.org; Mon, 09 Jul 2007 06:31:26 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I7qWX-0002Yi-Rl for speermint@ietf.org; Mon, 09 Jul 2007 06:31:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology Date: Mon, 9 Jul 2007 12:31:31 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D466B1DC3@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology Thread-Index: AcfAHQW7uBRJugwhTLmbBKF5N/NDTAB4pxWwAALCOIAAATkdwAAA2Ono References: <1DDB0D3CC4E7F14FAE946361C0A606550376965E@isr-jlm-mail.Kayote.com> From: "Stastny Richard" To: "David Schwartz" , "Malas, Daryl" X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi, =20 I basically agree with David =20 I have only two comments: =20 1. In the definitions 4.2.1 - 4.2.3 the term "network" is used. First, this term is not defined anywhere and secondly, it is IMO wrongly used on Layer 5. =20 In the definitions of section 3 the term "domain" is used, it should = also be used here, or even better "administrative domain" =20 2. I like the separation David proposes with the lookup function and the location function. It should also be stated clearly that we mean with location function the locating of SIP servers and not the locating of the end-user. =20 Richard ________________________________ Von: David Schwartz [mailto:David.Schwartz@Kayote.com] Gesendet: Mo 09.07.2007 12:10 An: Malas, Daryl Cc: speermint@ietf.org Betreff: FW: [Speermint] Terminology Draft vs. VoIP Usecases Draft = Terminology Hi Daryl I know it's probably too late for this to make it in but I just have a few comments. You define "Assisted Peering" as employing a central SIP proxy - therefore forcing a hub-and-spoke model for this category. I see it differently. I see assisted as "assisting" in call setup but not necessarily having to be in the actual call path. As discussed in previous emails on this thread "Assisted" should be orthogonal to both direct and indirect and if indeed a centralized SIP proxy is deployed than this is an instantiation of both assisted and indirect peering. I would word 4.2.1 - 4.2.3 as follows... 4.2.1. Direct Peering Direct peering describes those cases in which two service providers interconnect without using an intervening layer 5 network. 4.2.2. Indirect Peering Indirect, or transit, peering refers to the establishment of a either a signaling and media path or signaling path alone via one (or more) referral or transit network(s). Transit network may be used for technical =20 reasons (e.g. signaling interoperability or media transcoding) or non technical reasons (e.g. QoS, Anonymity). It is generally required that a trust relationship is established between the originating service provider and the transit network on one side, and the transit network and the termination network on the other side. 4.2.3. Assisted Peering In this case, some entity (usually a federation, see Section 5) provides peering assistance to either the originating or terminating party. Examples of such assistance can include (but are not limited to): * The lookup function (who owns the number) =20 * 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 relevant lookup information) * The policy function (who can see what and how) * Who gets a direct uri to other peer * Who must use intermediary * Who gets a 404 Not found * The location function (ingress point at terminating or transit peer) =20 * covers any mechanism (including BUT NOT LIMITED to RFC 3263) used to locate the next routing hop for this call. Note that this may require the assistance of an element filling the role of indirect peering as described above. Note as well that this may or may not be related to lookup function. If we can agree on these definitions than there is no need for the additional definitions of on-demand and static peering as these can be represented in terms of the 3 defined terms. For example, on-demand peering is defined today as follows... Service providers are said to peer on-demand when they are able to exchange traffic without any pre-association prior to the origination of a real-time transaction (like a SIP message) between the domains. Any information that needs to be exchanged between domains in support of peering can be learned through a dynamic protocol mechanism. On- demand peering can occur as direct, indirect, or assisted. What is described here can be implemented with a public ENUM root coupled with RFC 3263 filling the roles of Assisted peering and the signaling going directly to the terminating peer filling the role of Direct peering. So why introduce another confusing term? If we think of the 3 peering terms in a logical as opposed to physical sense all models can fold into these terms. One final note. As you probably noticed under assisted peering I broke the location function into a lookup function and a location function. In my experience it is this subtlety that can provide most of the flexibility we need to accommodate most of the models out there. While in many or most cases one URI can be used both for lookup and location - the flexibility to have separate URIs for these must not be sacrificed. I would therefore add this term to the draft as well. Once again I am so sorry that these comments are coming so late but my circumstances did not allow me to devote any time to this until now :( Your thoughts? D. -----Original Message----- From: Daryl Malas [mailto:daryl@level3.net] Sent: Saturday, July 07, 2007 1:30 AM To: speermint@ietf.org Subject: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology Adam et. al. (Authors of "draft-ietf-speermint-voip-consolidated-usecases"), Okay, I read through the terminology of the "voip-consolidated-usecases" draft, and here is my analysis: Remove the following term definitions from your draft, because they are already covered in the terminology draft: Direct Peering Indirect Peering Assisted Peering Federations (Note...you have Federations in your terminology section twice!) Voice Service Provider (Now SSP in Terminology draft) Signaling Border Element Data Path Border Element Peering Service Provider - The function of this is included in the SIP Service Provider definition. Direct PSP - I think this is also covered by existing definitions Assisting PSP - Same as Direct PSP comment. There are 3 (1 definite, 2 questionable) terms, which should be added to the next rev. of the terminology draft: Location Server Session Manager - Although I'm not quite sure I understand exactly what this does. User Endpoint - Again, I'm not sure what this is, because this should be a UAC, UAS, or UA in my opinion. These are well defined in RFC 3261 and referenced in the terminology draft. Other terms, which I think should remain in your draft and NOT in the terminology draft are more specific delineations of the terms in the terminology draft. They include: Originating VSP - Which at a minimum should be changed to Originating SSP to remain consistent with the terminology draft. Terminating VSP - See Originating VSP comment. O-SBE T-SBE t-SBE A-SBE O-DBE T-DBE t-DBE This my two cents...Thoughts...--Daryl _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 09 07:49:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7rjk-0006x5-Oz; Mon, 09 Jul 2007 07:49:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7rjX-0006uC-V3 for speermint@ietf.org; Mon, 09 Jul 2007 07:48:52 -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 1I7rjT-0004ZM-HO for speermint@ietf.org; Mon, 09 Jul 2007 07:48:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology Date: Mon, 9 Jul 2007 14:48:40 +0300 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A60655037696B0@isr-jlm-mail.Kayote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology Thread-Index: AcfAHQW7uBRJugwhTLmbBKF5N/NDTAB4pxWwAALCOIAAATkdwA== From: "David Schwartz" To: "Malas, Daryl" , "Uzelac, Adam" X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Sorry for nitpicking :) but... I have seen the term "generally required" (as in ..."It is generally required that a trust relationship is established...") appear in both this draft and the Use case draft and I think that it a "generally" bad idea. Something should be either required or not. Adding the word generally only adds a dimension of confusion and ensures that "generally" everybody gets it wrong. :-) _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 10 10:53:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8H5x-0007aX-IO; Tue, 10 Jul 2007 10:53:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8H5w-0007ZV-Q5 for speermint@ietf.org; Tue, 10 Jul 2007 10:53:40 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8H5w-0006sp-Jp for speermint@ietf.org; Tue, 10 Jul 2007 10:53:40 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l6AEr65F020282; Tue, 10 Jul 2007 14:53:07 GMT Subject: Re: FW: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology From: Daryl Malas To: David Schwartz In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A60655037696B0@isr-jlm-mail.Kayote.com> References: <1DDB0D3CC4E7F14FAE946361C0A60655037696B0@isr-jlm-mail.Kayote.com> Content-Type: text/plain Date: Tue, 10 Jul 2007 08:54:28 -0600 Message-Id: <1184079269.1297.2.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Malas, Daryl" , speermint@ietf.org, "Uzelac, Adam" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org No problem...I generally agree with you. ;-) On Mon, 2007-07-09 at 14:48 +0300, David Schwartz wrote: > Sorry for nitpicking :) but... > > I have seen the term "generally required" (as in ..."It is generally > required that a trust relationship is established...") appear in both > this draft and the Use case draft and I think that it a "generally" bad > idea. > > Something should be either required or not. Adding the word generally > only adds a dimension of confusion and ensures that "generally" > everybody gets it wrong. > > :-) > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 10 12:42:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8InY-0002pl-O3; Tue, 10 Jul 2007 12:42:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8InX-0002ny-Vw for speermint@ietf.org; Tue, 10 Jul 2007 12:42:47 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8InX-0002BB-Cd for speermint@ietf.org; Tue, 10 Jul 2007 12:42:47 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l6AGgh5F021805; Tue, 10 Jul 2007 16:42:43 GMT Subject: Re: FW: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology From: Daryl Malas To: David Schwartz In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A606550376965E@isr-jlm-mail.Kayote.com> References: <1DDB0D3CC4E7F14FAE946361C0A606550376965E@isr-jlm-mail.Kayote.com> Content-Type: text/plain Date: Tue, 10 Jul 2007 10:44:05 -0600 Message-Id: <1184085846.1297.15.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: "Malas, Daryl" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Re: 4.2.2 - I updated the section, it now reads: Indirect, or transit, peering refers to the establishment of either a signaling and media path or signaling path alone via one (or more) referral or transit network(s). In this case it is generally required that a trust relationship is established between the originating service provider and the transit network on one side, and the transit network and the termination network on the other side. --I left out the portion you have describing what a Transit network may be used for, since I think this should be included in the "use case" draft. Re: 4.2.3 - I updated the section, it now reads: In this case, some entity (usually a federation, see Section 5) provides peering assistance to either the originating or terminating peer by providing one or more functions (see Section 4.3) on behalf of the peers (which is not itself a SSP) to bridge calls between participating networks. I've now included a section of the terminology draft to include the functions as defined in the "architecture" draft. These functions include Location, Signaling, and Media. In the architecture draft, I think it should be described within the Location function the ability to do a "Lookup" as a sub-function. This is a similar to what I encouraged for describe sub-terms within the use case draft. Finally, the "Policy" function has been argued again and again, and this has been intentionally removed at this point from all of the drafts. Per the WG chairs, this can be defined in a separate draft as necessary in the future. Thanks...I will submit -09, but I may need to post it to a website if they will not accept it (due to beyond the deadline). --Daryl On Mon, 2007-07-09 at 13:10 +0300, David Schwartz wrote: > Hi Daryl > > I know it's probably too late for this to make it in but I just have a > few comments. You define "Assisted Peering" as employing a central SIP > proxy - therefore forcing a hub-and-spoke model for this category. I see > it differently. I see assisted as "assisting" in call setup but not > necessarily having to be in the actual call path. > > As discussed in previous emails on this thread "Assisted" should be > orthogonal to both direct and indirect and if indeed a centralized SIP > proxy is deployed than this is an instantiation of both assisted and > indirect peering. > > I would word 4.2.1 - 4.2.3 as follows... > > 4.2.1. Direct Peering > > Direct peering describes those cases in which two service providers > interconnect without using an intervening layer 5 network. > > 4.2.2. Indirect Peering > > Indirect, or transit, peering refers to the establishment of a either > a signaling and media path or signaling path alone via one (or more) > > referral or transit network(s). Transit network may be used for > technical > reasons (e.g. signaling interoperability or media transcoding) or non > > technical reasons (e.g. QoS, Anonymity). It is generally required > that > a trust relationship is established between the originating service > provider and the transit network on one side, and the transit network > > and the termination network on the other side. > > 4.2.3. Assisted Peering > > In this case, some entity (usually a federation, see Section 5) > provides peering assistance to either the originating or terminating > party. Examples of such assistance can include (but are not limited > to): > > * 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 relevant lookup information) > > * The policy function (who can see what and how) > > * Who gets a direct uri to other peer > * Who must use intermediary > * Who gets a 404 Not found > > * The location function (ingress point at terminating or transit > peer) > > * covers any mechanism (including BUT NOT LIMITED to RFC 3263) used > to locate the next routing hop for this call. Note that this may > require the assistance of an element filling the role of > indirect > peering as described above. Note as well that this may or may not > be related to lookup function. > > > If we can agree on these definitions than there is no need for the > additional definitions of on-demand and static peering as these can be > represented in terms of the 3 defined terms. For example, on-demand > peering is defined today as follows... > > Service providers are said to peer on-demand when they are able to > exchange traffic without any pre-association prior to the origination > > of a real-time transaction (like a SIP message) between the domains. > Any information that needs to be exchanged between domains in support > > of peering can be learned through a dynamic protocol mechanism. On- > demand peering can occur as direct, indirect, or assisted. > > What is described here can be implemented with a public ENUM root > coupled with RFC 3263 filling the roles of Assisted peering and the > signaling going directly to the terminating peer filling the role of > Direct peering. So why introduce another confusing term? > > If we think of the 3 peering terms in a logical as opposed to physical > sense all models can fold into these terms. > > One final note. As you probably noticed under assisted peering I broke > the location function into a lookup function and a location function. In > my experience it is this subtlety that can provide most of the > flexibility we need to accommodate most of the models out there. While > in many or most cases one URI can be used both for lookup and location - > the flexibility to have separate URIs for these must not be sacrificed. > I would therefore add this term to the draft as well. > > Once again I am so sorry that these comments are coming so late but my > circumstances did not allow me to devote any time to this until now :( > > Your thoughts? > > D. > > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Saturday, July 07, 2007 1:30 AM > To: speermint@ietf.org > Subject: [Speermint] Terminology Draft vs. VoIP Usecases Draft > Terminology > > Adam et. al. (Authors of > "draft-ietf-speermint-voip-consolidated-usecases"), > > Okay, I read through the terminology of the "voip-consolidated-usecases" > draft, and here is my analysis: > > Remove the following term definitions from your draft, because they > are already covered in the terminology draft: > > Direct Peering > Indirect Peering > Assisted Peering > Federations (Note...you have Federations in your terminology section > twice!) > Voice Service Provider (Now SSP in Terminology draft) > Signaling Border Element > Data Path Border Element > Peering Service Provider - The function of this is included in the SIP > Service Provider definition. > Direct PSP - I think this is also covered by existing definitions > Assisting PSP - Same as Direct PSP comment. > > There are 3 (1 definite, 2 questionable) terms, which should be added to > the next rev. of the terminology draft: > > Location Server > Session Manager - Although I'm not quite sure I understand exactly > what this does. > User Endpoint - Again, I'm not sure what this is, because this should > be a UAC, UAS, or UA in my opinion. These are well defined in RFC 3261 > and referenced in the terminology draft. > > Other terms, which I think should remain in your draft and NOT in the > terminology draft are more specific delineations of the terms in the > terminology draft. They include: > > Originating VSP - Which at a minimum should be changed to Originating > SSP to remain consistent with the terminology draft. > Terminating VSP - See Originating VSP comment. > O-SBE > T-SBE > t-SBE > A-SBE > O-DBE > T-DBE > t-DBE > > This my two cents...Thoughts...--Daryl > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 10 12:50:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Iup-0002cN-Bq; Tue, 10 Jul 2007 12:50:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Iuo-0002cH-6j for speermint@ietf.org; Tue, 10 Jul 2007 12:50:18 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Iun-0001fQ-MQ for speermint@ietf.org; Tue, 10 Jul 2007 12:50:18 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l6AGnf5F023779; Tue, 10 Jul 2007 16:49:42 GMT Subject: Re: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology From: Daryl Malas To: Stastny Richard In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466B1DC3@oefeg-s04.oefeg.loc> References: <1DDB0D3CC4E7F14FAE946361C0A606550376965E@isr-jlm-mail.Kayote.com> <32755D354E6B65498C3BD9FD496C7D466B1DC3@oefeg-s04.oefeg.loc> Content-Type: text/plain Date: Tue, 10 Jul 2007 10:51:03 -0600 Message-Id: <1184086264.1297.18.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: "Malas, Daryl" , speermint@ietf.org, David Schwartz X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 clarified the Location Function definition to make sure it does not indicate it provides the location of the end-user, but rather the SF of the SSP. On Mon, 2007-07-09 at 12:31 +0200, Stastny Richard wrote: > Hi, > > I basically agree with David > > I have only two comments: > > 1. In the definitions 4.2.1 - 4.2.3 the term "network" is used. > First, this term is not defined anywhere and secondly, it is IMO wrongly > used on Layer 5. > > In the definitions of section 3 the term "domain" is used, it should also be used > here, or even better "administrative domain" > > 2. I like the separation David proposes with the lookup function > and the location function. It should also be stated clearly > that we mean with location function the locating of SIP servers > and not the locating of the end-user. > > Richard > > ________________________________ > > Von: David Schwartz [mailto:David.Schwartz@Kayote.com] > Gesendet: Mo 09.07.2007 12:10 > An: Malas, Daryl > Cc: speermint@ietf.org > Betreff: FW: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology > > > > > Hi Daryl > > I know it's probably too late for this to make it in but I just have a > few comments. You define "Assisted Peering" as employing a central SIP > proxy - therefore forcing a hub-and-spoke model for this category. I see > it differently. I see assisted as "assisting" in call setup but not > necessarily having to be in the actual call path. > > As discussed in previous emails on this thread "Assisted" should be > orthogonal to both direct and indirect and if indeed a centralized SIP > proxy is deployed than this is an instantiation of both assisted and > indirect peering. > > I would word 4.2.1 - 4.2.3 as follows... > > 4.2.1. Direct Peering > > Direct peering describes those cases in which two service providers > interconnect without using an intervening layer 5 network. > > 4.2.2. Indirect Peering > > Indirect, or transit, peering refers to the establishment of a either > a signaling and media path or signaling path alone via one (or more) > > referral or transit network(s). Transit network may be used for > technical > reasons (e.g. signaling interoperability or media transcoding) or non > > technical reasons (e.g. QoS, Anonymity). It is generally required > that > a trust relationship is established between the originating service > provider and the transit network on one side, and the transit network > > and the termination network on the other side. > > 4.2.3. Assisted Peering > > In this case, some entity (usually a federation, see Section 5) > provides peering assistance to either the originating or terminating > party. Examples of such assistance can include (but are not limited > to): > > * 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 relevant lookup information) > > * The policy function (who can see what and how) > > * Who gets a direct uri to other peer > * Who must use intermediary > * Who gets a 404 Not found > > * The location function (ingress point at terminating or transit > peer) > > * covers any mechanism (including BUT NOT LIMITED to RFC 3263) used > to locate the next routing hop for this call. Note that this may > require the assistance of an element filling the role of > indirect > peering as described above. Note as well that this may or may not > be related to lookup function. > > > If we can agree on these definitions than there is no need for the > additional definitions of on-demand and static peering as these can be > represented in terms of the 3 defined terms. For example, on-demand > peering is defined today as follows... > > Service providers are said to peer on-demand when they are able to > exchange traffic without any pre-association prior to the origination > > of a real-time transaction (like a SIP message) between the domains. > Any information that needs to be exchanged between domains in support > > of peering can be learned through a dynamic protocol mechanism. On- > demand peering can occur as direct, indirect, or assisted. > > What is described here can be implemented with a public ENUM root > coupled with RFC 3263 filling the roles of Assisted peering and the > signaling going directly to the terminating peer filling the role of > Direct peering. So why introduce another confusing term? > > If we think of the 3 peering terms in a logical as opposed to physical > sense all models can fold into these terms. > > One final note. As you probably noticed under assisted peering I broke > the location function into a lookup function and a location function. In > my experience it is this subtlety that can provide most of the > flexibility we need to accommodate most of the models out there. While > in many or most cases one URI can be used both for lookup and location - > the flexibility to have separate URIs for these must not be sacrificed. > I would therefore add this term to the draft as well. > > Once again I am so sorry that these comments are coming so late but my > circumstances did not allow me to devote any time to this until now :( > > Your thoughts? > > D. > > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Saturday, July 07, 2007 1:30 AM > To: speermint@ietf.org > Subject: [Speermint] Terminology Draft vs. VoIP Usecases Draft > Terminology > > Adam et. al. (Authors of > "draft-ietf-speermint-voip-consolidated-usecases"), > > Okay, I read through the terminology of the "voip-consolidated-usecases" > draft, and here is my analysis: > > Remove the following term definitions from your draft, because they > are already covered in the terminology draft: > > Direct Peering > Indirect Peering > Assisted Peering > Federations (Note...you have Federations in your terminology section > twice!) > Voice Service Provider (Now SSP in Terminology draft) > Signaling Border Element > Data Path Border Element > Peering Service Provider - The function of this is included in the SIP > Service Provider definition. > Direct PSP - I think this is also covered by existing definitions > Assisting PSP - Same as Direct PSP comment. > > There are 3 (1 definite, 2 questionable) terms, which should be added to > the next rev. of the terminology draft: > > Location Server > Session Manager - Although I'm not quite sure I understand exactly > what this does. > User Endpoint - Again, I'm not sure what this is, because this should > be a UAC, UAS, or UA in my opinion. These are well defined in RFC 3261 > and referenced in the terminology draft. > > Other terms, which I think should remain in your draft and NOT in the > terminology draft are more specific delineations of the terms in the > terminology draft. They include: > > Originating VSP - Which at a minimum should be changed to Originating > SSP to remain consistent with the terminology draft. > Terminating VSP - See Originating VSP comment. > O-SBE > T-SBE > t-SBE > A-SBE > O-DBE > T-DBE > t-DBE > > This my two cents...Thoughts...--Daryl > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jul 11 06:33: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 1I8ZVj-0007NQ-0d; Wed, 11 Jul 2007 06:33:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ZVg-0007NA-Tu for speermint@ietf.org; Wed, 11 Jul 2007 06:33:28 -0400 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8ZVg-0004OE-Cz for speermint@ietf.org; Wed, 11 Jul 2007 06:33:28 -0400 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1I8ZV9-0003pA-00 for ; Wed, 11 Jul 2007 12:32:55 +0200 Date: Wed, 11 Jul 2007 12:32:55 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology Message-ID: <20070711103254.GA14627@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <1DDB0D3CC4E7F14FAE946361C0A606550376965E@isr-jlm-mail.Kayote.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A606550376965E@isr-jlm-mail.Kayote.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org David, On 2007/07/09 12:07, David Schwartz wrote: > > 4.2.3. Assisted Peering > > In this case, some entity (usually a federation, see Section 5) > provides peering assistance to either the originating or terminating > party. Examples of such assistance can include (but are not limited to): > > * 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 relevant lookup information) > > * The policy function (who can see what and how) > > * Who gets a direct uri to other peer > * Who must use intermediary > * Who gets a 404 Not found > > * The location function (ingress point at terminating or transit peer) > > * covers any mechanism (including BUT NOT LIMITED to RFC 3263) used > to locate the next routing hop for this call. Note that this may > require the assistance of an element filling the role of indirect > peering as described above. Note as well that this may or may not > be related to lookup function. I really like way you structured the peering problem into these three steps. Limiting this to "Assisted Peering" is selling the idea short, though: Even direct and indirect peering have to perform these three steps (although they might be mixed up in some cases). Let's look how standard ENUM/SIP performs these three steps: * The lookup function (who owns the number) User ENUM according to RFC3761. Public DNS. * The policy function (who can see what and how) Not needed as everybody talks to everybody * The location function (ingress point at terminating or transit peer) RFC 3263: NAPTR/SRV/A lookup My proposal from last year (see http://tools.ietf.org/html/draft-lendl-domain-policy-ddds-02 and http://tools.ietf.org/html/draft-lendl-speermint-federations-03 ) can also be described according to this scheme: * The lookup function (who owns the number) Public Infrastructure ENUM * The policy function (who can see what and how) It's not a question of "can see", but "can use": Domain policy DDDS application (see the drafts) * The location function (ingress point at terminating or transit peer) Federation specific. > > One final note. As you probably noticed under assisted peering I broke > the location function into a lookup function and a location function. In > my experience it is this subtlety that can provide most of the > flexibility we need to accommodate most of the models out there. While > in many or most cases one URI can be used both for lookup and location - > the flexibility to have separate URIs for these must not be sacrificed. > I would therefore add this term to the draft as well. Once again, I concur. The flexibility gained by this approach makes a simple, unified peering architecture for all scenarios feasible. /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jul 12 13:15:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I92G4-0000hc-Ux; Thu, 12 Jul 2007 13:15:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I92Fz-0000ag-Lc; Thu, 12 Jul 2007 13:15:11 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I92Fy-0003Mq-DS; Thu, 12 Jul 2007 13:15:11 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 5F769329E4; Thu, 12 Jul 2007 17:15:10 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I92Fx-0005Lw-Hi; Thu, 12 Jul 2007 13:15:09 -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: Thu, 12 Jul 2007 13:15:09 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-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 : SPEERMINT Requirements for SIP-based VoIP Interconnection Author(s) : J. Mule Filename : draft-ietf-speermint-requirements-02.txt Pages : 26 Date : 2007-7-12 This memo defines Best Current Practices for session peering between SIP Service Providers for voice or other types of multimedia traffic exchanges. In its current state, this document describes high-level guidelines and general requirements for session peering for multimedia interconnect . It also defines a minimum set of requirements applicable to session peering for voice over IP, presence and instant messaging interconnects. It is intended to become best current practices based on the use cases discussed in the SPEERMINT working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-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-requirements-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-requirements-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-7-12120459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12120459.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 Jul 16 13:31:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUQD-0006Iz-J2; Mon, 16 Jul 2007 13:31:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUQC-0006Il-Fk for speermint@ietf.org; Mon, 16 Jul 2007 13:31:44 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAUQ2-0006AN-7Q for speermint@ietf.org; Mon, 16 Jul 2007 13:31:44 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l6GHUR5F027168 for ; Mon, 16 Jul 2007 17:30:27 GMT Subject: [Speermint] draft-ietf-speermint-terminology-09 From: Daryl Malas To: speermint@ietf.org Content-Type: text/plain Date: Mon, 16 Jul 2007 11:32:13 -0600 Message-Id: <1184607133.1297.33.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 submitted a revision update to -08 after the dead-line, but will be leveraging it for discussion in Chicago. Until it posts after Chicago, it can be found here: http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-09.txt Release notes for -09: Updated section 4.2.2 and 4.2.3 Included and/or updated terminology defined in the "VoIP Usecases" and "Architecture" drafts. Added section 4.3 regarding functions - I've now included a section of the terminology draft to include the functions as defined in the "architecture" draft. These functions include Location, Signaling, and Media. I clarified the Location Function definition (4.3.1) to make sure it does not indicate it provides the location of the end-user, but rather the SF of the SSP. Thanks... --Daryl _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Jul 22 22:06: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 1ICnHw-0001ae-Vg; Sun, 22 Jul 2007 22:04:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICnHv-0001aV-3y for speermint@ietf.org; Sun, 22 Jul 2007 22:04:43 -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 1ICnHt-0001OS-PC for speermint@ietf.org; Sun, 22 Jul 2007 22:04:43 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JLM00K730FDKB@siemenscomms.co.uk> for speermint@ietf.org; Mon, 23 Jul 2007 03:04:25 +0100 (BST) Date: Mon, 23 Jul 2007 03:04:39 +0100 From: "Elwell, John" Subject: RE: [Speermint] Release Notes: draft-ietf-speermint-terminology-08 In-reply-to: <1183752206.26829.12.camel@montag.eng.level3.com> To: Daryl Malas , speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0205DAD@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] Release Notes: draft-ietf-speermint-terminology-08 Thread-Index: AcfAER0ILMwdqKfTRRuEIZ1sZcLwCAMWNoxg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1183752206.26829.12.camel@montag.eng.level3.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl, The definitions make a clear distinction between SIP service provider (SSP) and service provider (SP), yet I suspect in a lot of the document the term SP is used when really SSP is intended. Even in the definition of SSP it says "Such a service provider", when I think it means "Such a SIP service provider". Then in the section "Layer 5 peering" it states "Layer 5 (Session) peering refers to interconnection of two service providers...." - shouldn't it say "SIP service providers"? And in the section "Direct Peering", shouldn't "two service providers" be "two SIP service providers"? John > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: 06 July 2007 21:03 > To: speermint@ietf.org > Subject: [Speermint] Release Notes: > draft-ietf-speermint-terminology-08 > > The following updates were made in -08: > > - I expanded as many acronyms as I could find. I also put > references in > for almost all of them too. > > - I updated section 3.9 and made a clarification in 3.8 to provide an > ISP as an example SP. > > - I removed "secure" from section 4.2 and 4.2.2 > > - I added clarification to "static" and "on-demand" that either can be > used for "direct/indirect/assisted" peering types > > - I changed the case of "Codec" > > - I changed "SIP" to "SSP" and other "SP" references to "SSP" > in section > 5. > > - Also, there should be page breaks now. > > - I also tweaked a couple of other things as minor nits. > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 23 03:32:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICsNZ-0006PL-88; Mon, 23 Jul 2007 03:30:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICsNY-0006PG-FK for speermint@ietf.org; Mon, 23 Jul 2007 03:30:52 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICsNY-0006GJ-4a for speermint@ietf.org; Mon, 23 Jul 2007 03:30:52 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 23 Jul 2007 00:30:51 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Jul 2007 03:30:50 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2809A22DC7@proton.jnpr.net> In-Reply-To: <1184607133.1297.33.camel@montag.eng.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-speermint-architecture-04 Thread-Index: AcfHzzxeYrBREmRHT/uwVQVo2bo+5AFK1/wQ From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "Livingood, Jason" Subject: [Speermint] draft-ietf-speermint-architecture-04 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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 updated the architecture draft to 04. You can get it using the link below. http://www.geocities.com/reinaldopenno@sbcglobal.net/draft-ietf-speermin t-architecture-04.txt Discussion tomorrow will leverage the new version. I'm sorry for the late notice. Changes:=20 * Incorporated some of R. Mahy's changes in his draft-mahy-speermint-direct-peering-02. Included R. Mahy as co-author. * Tried to align to new terminology as much as possible Somewhat challenging since terminology seems spread between terminology draft -09 and use cases -02 * Put SF, LF and MF in the context of SBE, DBE, SM, LS and others * Rearranged/inserted sections under SF to put in context the notion of initiating vs. receiving peer. * New architecture picture to align with use-cases and terminology If some reason you cannot access the link above let me know. Thanks, Reinaldo _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 23 08:13: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 1ICwlM-0002cl-Iy; Mon, 23 Jul 2007 08:11:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICwlL-0002cf-LS for speermint@ietf.org; Mon, 23 Jul 2007 08:11:43 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICwlK-0002vv-Js for speermint@ietf.org; Mon, 23 Jul 2007 08:11:43 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JLM00GEESJ29T@siemenscomms.co.uk> for speermint@ietf.org; Mon, 23 Jul 2007 13:11:26 +0100 (BST) Date: Mon, 23 Jul 2007 13:11:37 +0100 From: "Elwell, John" To: Jean-Francois Mule , speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0205E0C@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: Comments on draft-ietf-speermint-requirements-02 Thread-Index: AcfNIp44hVeHBU0tTY67j/8+zvdkyg== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Subject: [Speermint] Comments on draft-ietf-speermint-requirements-02 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Jean-Francois, 1. I have difficulty understanding the need to mention media border elements in this document. In fact the only mention seems to be in section 3.2: "maximum flexibility should be given for how signaling path and media path border elements are declared, dynamically advertised and updated" and "If the SSP also provides media streams to its users, an SSP SHOULD declare the media border elements " Why is there a need to declare media border elements. If media has to pass through a border element, then surely that will be indicated in the SDP on a per session basis. I see no need for prior declaration or advertising. 2. Later in 3.2 it states: "Ingress and egress SBE points MAY be peer-dependent, and/or media-dependent." and then later: "For example, within an SSP network, some SBEs may be dedicated for certain types of media traffic due to specific SIP extensions required for certain media types (e.g. SIMPLE, the SIP MESSAGE Method for Instant Messaging [RFC3428] or the Message Sessions Relay Protocol (MSRP))." How can this be so? Suppose I have one SBE for audio/video and another for MSRP. How do I establish a session that has audio and MSRP? What if I establish a session for audio and then decide mid-session to add MSRP, or vice versa? 3. The title is: "SPEERMINT Requirements for SIP-based VoIP Interconnection" and in section 1 it states: "This document describes guidelines and requirements that are intended to become Best Current Practices for session peering (direct, indirect or assisted)." This is document is rather unusual. We have many "requirements" documents in the IETF that are requirements for a protocol or requirements for a solution to a problem. Here we seem to be stating requirements on an SSP. So we should make it quite clear that we are specifying requirements on an SSP, and perhaps even consider changing the title. Then, throughout the document, wherever a normative statement is made (RFC 2119 language), we must make it absolutely clear to what the normative statement applies. So we should typically begin "An SSP MUST" or "an originating SSP SHOULD". Statements such as: "it MUST be possible to determine whether the SSP domain servicing the URI allows for session peering, and if it does, it SHOULD be possible to locate and retrieve the domain's policy and SBE entities." in 3.3.2 are not helpful. Does this mean there is a requirement to advertise the policy and SBE entities, or does it mean that there is a requirement on an originating SSP to find and utilise advertised policy and SBE entities? 4. In 4.1 it states: "Such specifications SHOULD include protocol implementation compliance statements, indicate the minimal extensions that MUST be supported, and the full details on what options and protocol features MUST be supported, MUST NOT be supported or MAY be supported." The use of "MUST" and "MUST NOT" here is inappropriate use of RFC 2119 language. 5. In 4.2: "the use of the Require header must be configurable on a per SSP target domain basis in order to match a network peer's policy and to maximize interoperability." The Require header field is end-to-end, i.e., inserted by the UAC, so it is not under the control of the SBE. 6. In 4.5.2: "SIP and SBE servers involved in the secure session establishment over TLS MUST have valid X.509 certificates and MUST be able to receive a TLS connection on a well-known port." Why is it necessary to be able to receive on a well-known port, if the port it advertised in SRV records? 7. In 4.5.2: "SIP and SBE servers involved in the session establishment over TLS MUST verify and validate the client certificates: the client certificate MUST contain a DNS or URI choice type in the subjectAltName which corresponds to the domain asserted in the host portion of the URI contained in the From header." This does not work when receiving from a domain that is not the originating domain or if the domain in the From header field URI is anonymous.invalid. I believe it is only necessary to check that the subjectAltName identifies a domain with which peering is allowed. John _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 23 08:31: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 1ICx2m-0006Mx-Oc; Mon, 23 Jul 2007 08:29:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICx2l-0006Ms-TM for speermint@ietf.org; Mon, 23 Jul 2007 08:29:43 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICx2l-0003H0-8B for speermint@ietf.org; Mon, 23 Jul 2007 08:29:43 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JLM00M8PTD25P@siemenscomms.co.uk> for speermint@ietf.org; Mon, 23 Jul 2007 13:29:27 +0100 (BST) Date: Mon, 23 Jul 2007 13:29:40 +0100 From: "Elwell, John" To: Rohan Mahy , speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0205E10@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: Comments on draft-mahy-speermint-direct-peering-02 Thread-Index: AcfNJSN0NpnaS01IRZGS6a582OB2Jg== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Subject: [Speermint] Comments on draft-mahy-speermint-direct-peering-02 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Rohan, I generally like this draft. A few comments. 1. In section 3: "verifiably assert an identity for the sender of most messages". Only requests - not responses. 2. In section 4.1.6: "The initiating provider MUST be prepared to provide a TLS client certificate upon request during the TLS handshake. The client certificate MUST contain a DNS or URI choice type in the subjectAltName which corresponds to the domain asserted in the host production of the From header URI." Although the scope of this document is direct peering, it won't work if two or more direct peering hops are used in for indirect peering. For example, suppose enterprise domain exampleA.com submits a request from alice@exampleA.com to tel:+123456789, and domain A's policy is to route such a request to service provider exampleB.com. This then determines that the request is to be routed to sip:56789@exampleC.com. The exampleC.com domain will receive the request from exampleB.com (exampleB.com in the TLS certificate of the client) but the From header field URI will contain exampleA.com. Also it won't work if Alice has put anonymous.invalid in the From header field domain. It should only be necessary to check that the certificate indicates a domain with which peering is acceptable. Likewise the following statements later are wrong: "The Identity-Info header must present a domain name which is represented in the certificate presented when establishing the TLS connection over which the request is sent." and "Next the receiving verifies that the Identity header is valid, corresponds to the message, corresponds to the Identity-Info header, and that the domain in the From header corresponds to one of the domains in the TLS client certificate." 3. In section 4.1.7: "The following are not acceptable: From: "2125551212" <2125551212@example.net;user=phone> From: "Anonymous" " I believe the first is valid (at least between enterprise domains). The second is certainly valid. 4. "The initiating peer SHOULD include an Identity header on in-dialog requests as well, if the From header field value matches an identity the initiating peer is willing to assert." There should be a reference to RFC 4916. John _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 23 16:05:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID49R-0007RD-Nq; Mon, 23 Jul 2007 16:05:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID49Q-0007Qg-7V for speermint@ietf.org; Mon, 23 Jul 2007 16:05:04 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID49P-0000Yq-QQ for speermint@ietf.org; Mon, 23 Jul 2007 16:05:04 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l6NK51RI020847 for ; Mon, 23 Jul 2007 20:05:01 GMT Subject: [Speermint] Lookup Function and Location Function From: Daryl Malas To: speermint@ietf.org Content-Type: text/plain Date: Mon, 23 Jul 2007 14:07:14 -0600 Message-Id: <1185221235.1297.58.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org The question came up today as to whether or not the Location Function term should be broken into Look-up and Location Function. Below is the "Location Function" as it is defined today, and the proposed "Look-up Function". Another way to look at it...should a "Look-up Function" be defined in addition to the "Location Function". Location Function - The Location Function (LF) develops call routing data (CRD) by discovering the Signaling Function (SF), and SF's reachable host (IP Address and port). Look-up Function - The Look-up Function provides a mechanism for querying an internal and/or external database, which maintains a list of SIP user names and associated peering domains. Thanks...--Daryl _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 23 16:15:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID4Jm-0000Ej-G6; Mon, 23 Jul 2007 16:15:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID4JY-00084y-LY; Mon, 23 Jul 2007 16:15:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID4JY-0000mX-76; Mon, 23 Jul 2007 16:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 1C5572AC81; Mon, 23 Jul 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ID4J3-0008UY-R9; Mon, 23 Jul 2007 16:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 23 Jul 2007 16:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-09.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-09.txt Pages : 13 Date : 2007-7-23 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-09.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-09.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-09.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-7-23152826.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-terminology-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-terminology-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-23152826.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 Jul 23 16:15:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID4Jw-0000ei-Ct; Mon, 23 Jul 2007 16:15:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID4JZ-00087H-4K; Mon, 23 Jul 2007 16:15:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID4JY-0000me-J5; Mon, 23 Jul 2007 16:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 46E99175FE; Mon, 23 Jul 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ID4J3-0008UV-QX; Mon, 23 Jul 2007 16:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 23 Jul 2007 16:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-09.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-09.txt Pages : 13 Date : 2007-7-23 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-09.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-09.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-09.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-7-23152806.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-terminology-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-terminology-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-23152806.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 Jul 23 16:32:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID4ZY-0004SB-6Z; Mon, 23 Jul 2007 16:32:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID4ZW-0004S5-Cl for speermint@ietf.org; Mon, 23 Jul 2007 16:32:02 -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 1ID4ZU-0002uM-Td for speermint@ietf.org; Mon, 23 Jul 2007 16:32:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Lookup Function and Location Function Date: Mon, 23 Jul 2007 23:31:56 +0300 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A60655039C6432@isr-jlm-mail.Kayote.com> In-Reply-To: <1185221235.1297.58.camel@montag.eng.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Lookup Function and Location Function Thread-Index: AcfNZMjGdf2nTZsPROeon5mogcg2aQAA60qA References: <1185221235.1297.58.camel@montag.eng.level3.com> From: "David Schwartz" To: "Daryl Malas" , X-Spam-Score: 3.8 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 am ok with that. Thanks -----Original Message----- From: Daryl Malas [mailto:daryl@level3.net]=20 Sent: Monday, July 23, 2007 11:07 PM To: speermint@ietf.org Subject: [Speermint] Lookup Function and Location Function The question came up today as to whether or not the Location Function term should be broken into Look-up and Location Function. Below is the "Location Function" as it is defined today, and the proposed "Look-up Function". Another way to look at it...should a "Look-up Function" be defined in addition to the "Location Function". =20 Location Function - The Location Function (LF) develops call routing data (CRD) by discovering the Signaling Function (SF), and SF's reachable host (IP Address and port). Look-up Function - The Look-up Function provides a mechanism for querying an internal and/or external database, which maintains a list of SIP user names and associated peering domains. Thanks...--Daryl _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 23 17:58: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 1ID5ui-0005nL-Gx; Mon, 23 Jul 2007 17:58:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID5ug-0005n2-Ub for speermint@ietf.org; Mon, 23 Jul 2007 17:57:59 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID5ug-0003ai-Eo for speermint@ietf.org; Mon, 23 Jul 2007 17:57:58 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 23 Jul 2007 14:57:53 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Lookup Function and Location Function Date: Mon, 23 Jul 2007 17:57:49 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2809A230BE@proton.jnpr.net> In-Reply-To: <1185221235.1297.58.camel@montag.eng.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Lookup Function and Location Function Thread-Index: AcfNZM/vQjGhnERpQeaqMdSgwUexLAADlsjA From: "Reinaldo Penno" To: "Daryl Malas" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I think this distinction is necessary. When I was updating the arch draft I was struggling on how to map SM and LS (as defines by use cases-02) to LF. I think today SM is contained within both LF and LUF (Look-up function). In the use cases draft it says SM is logical and can contain more than one entity. The problem is that LF and LUF are also logical. Usually architectures are defined cased on functions/logical entities. We need to define the top of the hierarchy. IMHO should start with LF, MF, SF and map everything (elements/boxes) to it. Today seems the other way around, we are defining elements (SBE, etc) and putting functions on them. But the function can span more than one element, so things start to get complicated.=20 > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net]=20 > Sent: Monday, July 23, 2007 1:07 PM > To: speermint@ietf.org > Subject: [Speermint] Lookup Function and Location Function >=20 > The question came up today as to whether or not the Location=20 > Function term should be broken into Look-up and Location=20 > Function. Below is the "Location Function" as it is defined=20 > today, and the proposed "Look-up Function". Another way to=20 > look at it...should a "Look-up Function" be defined in=20 > addition to the "Location Function". =20 >=20 > Location Function - >=20 > The Location Function (LF) develops call routing data (CRD)=20 > by discovering the Signaling Function (SF), and SF's=20 > reachable host (IP Address and port). >=20 > Look-up Function - >=20 > The Look-up Function provides a mechanism for querying an=20 > internal and/or external database, which maintains a list of=20 > SIP user names and associated peering domains. >=20 > Thanks...--Daryl >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 23 21:01:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID8mc-0007qU-Ib; Mon, 23 Jul 2007 21:01:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID8mb-0007qP-PM for speermint@ietf.org; Mon, 23 Jul 2007 21:01:49 -0400 Received: from pacdcimo02.cable.comcast.com ([24.40.8.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID8mb-0008Ku-BL for speermint@ietf.org; Mon, 23 Jul 2007 21:01:49 -0400 Received: from ([10.52.116.31]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.9633721; Mon, 23 Jul 2007 21:01:39 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 21:01:38 -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] Lookup Function and Location Function Date: Mon, 23 Jul 2007 21:01:19 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602022A5857@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2809A230BE@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Lookup Function and Location Function Thread-Index: AcfNZM/vQjGhnERpQeaqMdSgwUexLAADlsjAAAZ5AgA= From: "Lee, Yiu" To: "Reinaldo Penno" , "Daryl Malas" , X-OriginalArrivalTime: 24 Jul 2007 01:01:38.0797 (UTC) FILETIME=[309CA1D0:01C7CD8E] X-Spam-Score: 1.2 (+) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Both LF and LUF are providing services to find the next-hop. In the use case draft, the LF is the entity that contains both LF and LUF. SM is the signaling entity that connects the UAC and UAS. SM doesn't contain any user-to-location mapping. It sends the LF request to the LF. -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Monday, July 23, 2007 5:58 PM To: Daryl Malas; speermint@ietf.org Subject: RE: [Speermint] Lookup Function and Location Function I think this distinction is necessary. When I was updating the arch draft I was struggling on how to map SM and LS (as defines by use cases-02) to LF. I think today SM is contained within both LF and LUF (Look-up function). In the use cases draft it says SM is logical and can contain more than one entity. The problem is that LF and LUF are also logical. Usually architectures are defined cased on functions/logical entities. We need to define the top of the hierarchy. IMHO should start with LF, MF, SF and map everything (elements/boxes) to it. Today seems the other way around, we are defining elements (SBE, etc) and putting functions on them. But the function can span more than one element, so things start to get complicated.=20 > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Monday, July 23, 2007 1:07 PM > To: speermint@ietf.org > Subject: [Speermint] Lookup Function and Location Function >=20 > The question came up today as to whether or not the Location Function=20 > term should be broken into Look-up and Location Function. Below is=20 > the "Location Function" as it is defined today, and the proposed=20 > "Look-up Function". Another way to look at it...should a "Look-up=20 > Function" be defined in addition to the "Location Function". >=20 > Location Function - >=20 > The Location Function (LF) develops call routing data (CRD) by=20 > discovering the Signaling Function (SF), and SF's reachable host (IP=20 > Address and port). >=20 > Look-up Function - >=20 > The Look-up Function provides a mechanism for querying an internal=20 > and/or external database, which maintains a list of SIP user names and > associated peering domains. >=20 > Thanks...--Daryl >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 24 00:07: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 1IDBgG-0002Wx-Hx; Tue, 24 Jul 2007 00:07:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDBgF-0002Wr-5X for speermint@ietf.org; Tue, 24 Jul 2007 00:07:27 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDBgE-0003YJ-LP for speermint@ietf.org; Tue, 24 Jul 2007 00:07:27 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 23 Jul 2007 21:07:25 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Lookup Function and Location Function Date: Tue, 24 Jul 2007 00:07:19 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2809A23150@proton.jnpr.net> In-Reply-To: <45AEC6EF95942140888406588E1A6602022A5857@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Lookup Function and Location Function Thread-Index: AcfNZM/vQjGhnERpQeaqMdSgwUexLAADlsjAAAZ5AgAABp2gAA== From: "Reinaldo Penno" To: "Lee, Yiu" , "Daryl Malas" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hello Yiu, The word "LF" does not even appear in the user cases draft. =20 On the other hand, the definition of SM says: "It is also responsible for locating the user home=20 proxy. SM is logical, it MAY contain one functional entity or multiple functional entities. " Special attention to "...locating the user home proxy..". So, putting these two together we do not have a clear picture of LF, LUF, SM and others. My suggestion is the use cases draft put SBE, DBE, and others in the context of LF, SF, and MF. In other words, how these boxes map to the functions in the arch draft. Thanks, Reinaldo > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com]=20 > Sent: Monday, July 23, 2007 6:01 PM > To: Reinaldo Penno; Daryl Malas; speermint@ietf.org > Subject: RE: [Speermint] Lookup Function and Location Function >=20 > Both LF and LUF are providing services to find the next-hop.=20 > In the use case draft, the LF is the entity that contains=20 > both LF and LUF. SM is the signaling entity that connects the=20 > UAC and UAS. SM doesn't contain any user-to-location mapping.=20 > It sends the LF request to the LF. >=20 >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Monday, July 23, 2007 5:58 PM > To: Daryl Malas; speermint@ietf.org > Subject: RE: [Speermint] Lookup Function and Location Function >=20 > I think this distinction is necessary. When I was updating=20 > the arch draft I was struggling on how to map SM and LS (as=20 > defines by use > cases-02) to LF. >=20 > I think today SM is contained within both LF and LUF (Look-up=20 > function). > In the use cases draft it says SM is logical and can contain=20 > more than one entity. The problem is that LF and LUF are also=20 > logical. Usually architectures are defined cased on=20 > functions/logical entities. >=20 > We need to define the top of the hierarchy. IMHO should start=20 > with LF, MF, SF and map everything (elements/boxes) to it.=20 > Today seems the other way around, we are defining elements=20 > (SBE, etc) and putting functions on them. But the function=20 > can span more than one element, so things start to get complicated.=20 >=20 > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: Monday, July 23, 2007 1:07 PM > > To: speermint@ietf.org > > Subject: [Speermint] Lookup Function and Location Function > >=20 > > The question came up today as to whether or not the=20 > Location Function=20 > > term should be broken into Look-up and Location Function. Below is=20 > > the "Location Function" as it is defined today, and the proposed=20 > > "Look-up Function". Another way to look at it...should a "Look-up=20 > > Function" be defined in addition to the "Location Function". > >=20 > > Location Function - > >=20 > > The Location Function (LF) develops call routing data (CRD) by=20 > > discovering the Signaling Function (SF), and SF's reachable=20 > host (IP=20 > > Address and port). > >=20 > > Look-up Function - > >=20 > > The Look-up Function provides a mechanism for querying an internal=20 > > and/or external database, which maintains a list of SIP=20 > user names and >=20 > > associated peering domains. > >=20 > > Thanks...--Daryl > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 24 11:16: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 1IDM7R-0000A1-OD; Tue, 24 Jul 2007 11:16:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDM7Q-00009n-Nm for speermint@ietf.org; Tue, 24 Jul 2007 11:16:12 -0400 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDM7Q-0001EU-5R for speermint@ietf.org; Tue, 24 Jul 2007 11:16:12 -0400 Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.5812384; Tue, 24 Jul 2007 11:15:48 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 11:15:48 -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] Lookup Function and Location Function Date: Tue, 24 Jul 2007 11:15:27 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602022A596D@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2809A23150@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Lookup Function and Location Function Thread-Index: AcfNZM/vQjGhnERpQeaqMdSgwUexLAADlsjAAAZ5AgAABp2gAAAXUvcQ From: "Lee, Yiu" To: "Reinaldo Penno" , "Daryl Malas" , X-OriginalArrivalTime: 24 Jul 2007 15:15:48.0136 (UTC) FILETIME=[83992A80:01C7CE05] X-Spam-Score: 1.2 (+) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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 Ah, I see where the confusion comes from :-) In the -03 draft, SM is: Session Manager (SM): A SM is the home registrar of the user=20 endpoint. SM is responsible to receive and send SIP messages from=20 the peer. If the user endpoint speaks non-SIP, SM will translate=20 the non-SIP protocol to SIP protocol and vice versa.=20 We don't have LF defined in the draft because we referenced the LF from the term draft. Since the term draft is updated to show LF and LUF, we will update the use-case draft accordingly. Thanks, Yiu=20 -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Tuesday, July 24, 2007 12:07 AM To: Lee, Yiu; Daryl Malas; speermint@ietf.org Subject: RE: [Speermint] Lookup Function and Location Function Hello Yiu, The word "LF" does not even appear in the user cases draft. =20 On the other hand, the definition of SM says: "It is also responsible for locating the user home=20 proxy. SM is logical, it MAY contain one functional entity or multiple functional entities. " Special attention to "...locating the user home proxy..". So, putting these two together we do not have a clear picture of LF, LUF, SM and others. My suggestion is the use cases draft put SBE, DBE, and others in the context of LF, SF, and MF. In other words, how these boxes map to the functions in the arch draft. Thanks, Reinaldo > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com] > Sent: Monday, July 23, 2007 6:01 PM > To: Reinaldo Penno; Daryl Malas; speermint@ietf.org > Subject: RE: [Speermint] Lookup Function and Location Function >=20 > Both LF and LUF are providing services to find the next-hop.=20 > In the use case draft, the LF is the entity that contains both LF and=20 > LUF. SM is the signaling entity that connects the UAC and UAS. SM=20 > doesn't contain any user-to-location mapping. > It sends the LF request to the LF. >=20 >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Monday, July 23, 2007 5:58 PM > To: Daryl Malas; speermint@ietf.org > Subject: RE: [Speermint] Lookup Function and Location Function >=20 > I think this distinction is necessary. When I was updating the arch=20 > draft I was struggling on how to map SM and LS (as defines by use > cases-02) to LF. >=20 > I think today SM is contained within both LF and LUF (Look-up=20 > function). > In the use cases draft it says SM is logical and can contain more than > one entity. The problem is that LF and LUF are also logical. Usually=20 > architectures are defined cased on functions/logical entities. >=20 > We need to define the top of the hierarchy. IMHO should start with LF, > MF, SF and map everything (elements/boxes) to it. > Today seems the other way around, we are defining elements (SBE, etc)=20 > and putting functions on them. But the function can span more than one > element, so things start to get complicated. >=20 > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: Monday, July 23, 2007 1:07 PM > > To: speermint@ietf.org > > Subject: [Speermint] Lookup Function and Location Function > >=20 > > The question came up today as to whether or not the > Location Function > > term should be broken into Look-up and Location Function. Below is=20 > > the "Location Function" as it is defined today, and the proposed=20 > > "Look-up Function". Another way to look at it...should a "Look-up=20 > > Function" be defined in addition to the "Location Function". > >=20 > > Location Function - > >=20 > > The Location Function (LF) develops call routing data (CRD) by=20 > > discovering the Signaling Function (SF), and SF's reachable > host (IP > > Address and port). > >=20 > > Look-up Function - > >=20 > > The Look-up Function provides a mechanism for querying an internal=20 > > and/or external database, which maintains a list of SIP > user names and >=20 > > associated peering domains. > >=20 > > Thanks...--Daryl > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 24 12:15:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDN3A-00040f-TA; Tue, 24 Jul 2007 12:15:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDN2t-0003Ua-QS; Tue, 24 Jul 2007 12:15:35 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDN2r-0006Xr-14; Tue, 24 Jul 2007 12:15:35 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id DED942ACCD; Tue, 24 Jul 2007 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IDN2M-0005W4-E9; Tue, 24 Jul 2007 12:15: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: Tue, 24 Jul 2007 12:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 : 21 Date : 2007-6-8 This document will capture VoIP use case for SIP Peering. It is a consolidation of Speermint use cases drafts. This documents depicts many common VoIP peering use cases. These use cases are categorized into three types: Direct, Indirect and Assisted. They are not the exhaust set of use cases but the most common use cases deployed in production today. This document captures them to provide a reference. 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-7-24113058.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-7-24113058.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 Tue Jul 24 15:32:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQ7a-0006iJ-7U; Tue, 24 Jul 2007 15:32:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQ7Y-0006i8-QE for speermint@ietf.org; Tue, 24 Jul 2007 15:32:36 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDQ7Y-0004fO-6B for speermint@ietf.org; Tue, 24 Jul 2007 15:32:36 -0400 Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.35023504; Tue, 24 Jul 2007 15:32:24 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 15:32: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] Lookup Function and Location Function Date: Tue, 24 Jul 2007 15:32:24 -0400 Message-ID: <45AEC6EF95942140888406588E1A660201A2A3A4@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602022A5857@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Lookup Function and Location Function Thread-Index: AcfNZM/vQjGhnERpQeaqMdSgwUexLAADlsjAAAZ5AgAAJsxaoA== References: <9BD5D7887235424FA97DFC223CAE3C2809A230BE@proton.jnpr.net> <45AEC6EF95942140888406588E1A6602022A5857@PACDCEXCMB04.cable.comcast.com> From: "Livingood, Jason" To: "Lee, Yiu" , "Reinaldo Penno" , "Daryl Malas" , X-OriginalArrivalTime: 24 Jul 2007 19:32:24.0300 (UTC) FILETIME=[5C6D5AC0:01C7CE29] 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 Yiu - If you are proposing a modification to the suggested text, please submit that in full in this thread. =20 Thanks Jason=20 > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 > Sent: Monday, July 23, 2007 9:01 PM > To: Reinaldo Penno; Daryl Malas; speermint@ietf.org > Subject: RE: [Speermint] Lookup Function and Location Function >=20 > Both LF and LUF are providing services to find the next-hop.=20 > In the use case draft, the LF is the entity that contains=20 > both LF and LUF. SM is the signaling entity that connects the=20 > UAC and UAS. SM doesn't contain any user-to-location mapping.=20 > It sends the LF request to the LF. >=20 >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Monday, July 23, 2007 5:58 PM > To: Daryl Malas; speermint@ietf.org > Subject: RE: [Speermint] Lookup Function and Location Function >=20 > I think this distinction is necessary. When I was updating=20 > the arch draft I was struggling on how to map SM and LS (as=20 > defines by use > cases-02) to LF. >=20 > I think today SM is contained within both LF and LUF (Look-up=20 > function). > In the use cases draft it says SM is logical and can contain=20 > more than one entity. The problem is that LF and LUF are also=20 > logical. Usually architectures are defined cased on=20 > functions/logical entities. >=20 > We need to define the top of the hierarchy. IMHO should start=20 > with LF, MF, SF and map everything (elements/boxes) to it.=20 > Today seems the other way around, we are defining elements=20 > (SBE, etc) and putting functions on them. But the function=20 > can span more than one element, so things start to get complicated.=20 >=20 > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: Monday, July 23, 2007 1:07 PM > > To: speermint@ietf.org > > Subject: [Speermint] Lookup Function and Location Function > >=20 > > The question came up today as to whether or not the=20 > Location Function=20 > > term should be broken into Look-up and Location Function. Below is=20 > > the "Location Function" as it is defined today, and the proposed=20 > > "Look-up Function". Another way to look at it...should a "Look-up=20 > > Function" be defined in addition to the "Location Function". > >=20 > > Location Function - > >=20 > > The Location Function (LF) develops call routing data (CRD) by=20 > > discovering the Signaling Function (SF), and SF's reachable=20 > host (IP=20 > > Address and port). > >=20 > > Look-up Function - > >=20 > > The Look-up Function provides a mechanism for querying an internal=20 > > and/or external database, which maintains a list of SIP=20 > user names and >=20 > > associated peering domains. > >=20 > > Thanks...--Daryl > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 24 15:32:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQ7b-0006jJ-E9; Tue, 24 Jul 2007 15:32:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQ7Z-0006iD-J6 for speermint@ietf.org; Tue, 24 Jul 2007 15:32:37 -0400 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDQ7Z-0000wv-Ba for speermint@ietf.org; Tue, 24 Jul 2007 15:32:37 -0400 Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.5829039; Tue, 24 Jul 2007 15:32:24 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 15:32:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Jul 2007 15:31:43 -0400 Message-ID: <45AEC6EF95942140888406588E1A660201A2A3A1@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Final 2 Issues on Terminology Draft Thread-Index: AcfOKUPjH3CFN922TxWE/yGwfA842Q== From: "Livingood, Jason" To: "Daryl Malas" , X-OriginalArrivalTime: 24 Jul 2007 19:32:23.0688 (UTC) FILETIME=[5C0FF880:01C7CE29] X-Spam-Score: 1.2 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Speermint] Final 2 Issues on Terminology Draft X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Per the IETF 69 meeting, we have 2 final issues to close out before we can update to a -10 draft and then issue WGLC. 1 - Location & Lookup Function definitions. You already submitted a thread on that. Seems like you have rough consensus, pending any suggested changes from Yiu Lee (Yiu --> please get these in today or indicate no changes requested.) 2 - Separation of Indirect & Assisted definitions. =20 --> Daryl - Can you submit your proposed change today or tomorrow while the discussion is fresh in your mind? Thanks Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 24 15:37:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQBx-0000ZO-3Y; Tue, 24 Jul 2007 15:37:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQBw-0000ZJ-K5 for speermint@ietf.org; Tue, 24 Jul 2007 15:37:08 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDQBw-0004pS-7c for speermint@ietf.org; Tue, 24 Jul 2007 15:37:08 -0400 Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.35023831; Tue, 24 Jul 2007 15:36:46 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 15:36:45 -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] Final 2 Issues on Terminology Draft Date: Tue, 24 Jul 2007 15:36:24 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602022A5AE2@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A660201A2A3A1@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Final 2 Issues on Terminology Draft Thread-Index: AcfOKUPjH3CFN922TxWE/yGwfA842QAAEYaw From: "Lee, Yiu" To: "Livingood, Jason" , "Daryl Malas" , X-OriginalArrivalTime: 24 Jul 2007 19:36:45.0714 (UTC) FILETIME=[F83DF720:01C7CE29] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I am ok for the LF and LUF. The discussion between Reinaldo and I is about the Session Manager in the use-case draft. Thanks, Yiu=20 -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Tuesday, July 24, 2007 3:32 PM To: Daryl Malas; speermint@ietf.org Subject: [Speermint] Final 2 Issues on Terminology Draft Per the IETF 69 meeting, we have 2 final issues to close out before we can update to a -10 draft and then issue WGLC. 1 - Location & Lookup Function definitions. You already submitted a thread on that. Seems like you have rough consensus, pending any suggested changes from Yiu Lee (Yiu --> please get these in today or indicate no changes requested.) 2 - Separation of Indirect & Assisted definitions. =20 --> Daryl - Can you submit your proposed change today or tomorrow while the discussion is fresh in your mind? Thanks Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 24 15:56:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQUy-0007yN-So; Tue, 24 Jul 2007 15:56:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQUx-0007yC-Ia for speermint@ietf.org; Tue, 24 Jul 2007 15:56:47 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDQUw-0001e1-DZ for speermint@ietf.org; Tue, 24 Jul 2007 15:56:47 -0400 Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.44956305; Tue, 24 Jul 2007 15:56:30 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 15:56:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Final 2 Issues on Terminology Draft Date: Tue, 24 Jul 2007 15:54:44 -0400 Message-ID: <45AEC6EF95942140888406588E1A660201A2A3AB@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602022A5AE2@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Final 2 Issues on Terminology Draft Thread-Index: AcfOKUPjH3CFN922TxWE/yGwfA842QAAEYawAAC5I0A= References: <45AEC6EF95942140888406588E1A660201A2A3A1@PACDCEXCMB04.cable.comcast.com> <45AEC6EF95942140888406588E1A6602022A5AE2@PACDCEXCMB04.cable.comcast.com> From: "Livingood, Jason" To: "Lee, Yiu" , "Daryl Malas" , X-OriginalArrivalTime: 24 Jul 2007 19:56:29.0959 (UTC) FILETIME=[BA1B6970:01C7CE2C] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Great! =20 So Daryl - one of your two final issues for Terminology is now closed. :-) Jason=20 > -----Original Message----- > From: Lee, Yiu=20 > Sent: Tuesday, July 24, 2007 3:36 PM > To: Livingood, Jason; Daryl Malas; speermint@ietf.org > Subject: RE: [Speermint] Final 2 Issues on Terminology Draft >=20 > I am ok for the LF and LUF. The discussion between Reinaldo=20 > and I is about the Session Manager in the use-case draft. >=20 > Thanks, > Yiu=20 >=20 > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Tuesday, July 24, 2007 3:32 PM > To: Daryl Malas; speermint@ietf.org > Subject: [Speermint] Final 2 Issues on Terminology Draft >=20 > Per the IETF 69 meeting, we have 2 final issues to close out=20 > before we can update to a -10 draft and then issue WGLC. >=20 > 1 - Location & Lookup Function definitions. You already=20 > submitted a thread on that. Seems like you have rough=20 > consensus, pending any suggested changes from Yiu Lee (Yiu=20 > --> please get these in today or indicate no changes requested.) >=20 > 2 - Separation of Indirect & Assisted definitions. =20 > --> Daryl - Can you submit your proposed change today=20 > or tomorrow while the discussion is fresh in your mind? >=20 > Thanks > Jason >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _________________From speermint-bounces@ietf.org Tue Jul 24 15:56:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQUy-0007yN-So; Tue, 24 Jul 2007 15:56:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQUx-0007yC-Ia for speermint@ietf.org; Tue, 24 Jul 2007 15:56:47 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDQUw-0001e1-DZ for speermint@ietf.org; Tue, 24 Jul 2007 15:56:47 -0400 Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.44956305; Tue, 24 Jul 2007 15:56:30 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 15:56:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Final 2 Issues on Terminology Draft Date: Tue, 24 Jul 2007 15:54:44 -0400 Message-ID: <45AEC6EF95942140888406588E1A660201A2A3AB@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602022A5AE2@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Final 2 Issues on Terminology Draft Thread-Index: AcfOKUPjH3CFN922TxWE/yGwfA842QAAEYawAAC5I0A= References: <45AEC6EF95942140888406588E1A660201A2A3A1@PACDCEXCMB04.cable.comcast.com> <45AEC6EF95942140888406588E1A6602022A5AE2@PACDCEXCMB04.cable.comcast.com> From: "Livingood, Jason" To: "Lee, Yiu" , "Daryl Malas" , X-OriginalArrivalTime: 24 Jul 2007 19:56:29.0959 (UTC) FILETIME=[BA1B6970:01C7CE2C] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Great! =20 So Daryl - one of your two final issues for Terminology is now closed. :-) Jason=20 > -----Original Message----- > From: Lee, Yiu=20 > Sent: Tuesday, July 24, 2007 3:36 PM > To: Livingood, Jason; Daryl Malas; speermint@ietf.org > Subject: RE: [Speermint] Final 2 Issues on Terminology Draft >=20 > I am ok for the LF and LUF. The discussion between Reinaldo=20 > and I is about the Session Manager in the use-case draft. >=20 > Thanks, > Yiu=20 >=20 > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Tuesday, July 24, 2007 3:32 PM > To: Daryl Malas; speermint@ietf.org > Subject: [Speermint] Final 2 Issues on Terminology Draft >=20 > Per the IETF 69 meeting, we have 2 final issues to close out=20 > before we can update to a -10 draft and then issue WGLC. >=20 > 1 - Location & Lookup Function definitions. You already=20 > submitted a thread on that. Seems like you have rough=20 > consensus, pending any suggested changes from Yiu Lee (Yiu=20 > --> please get these in today or indicate no changes requested.) >=20 > 2 - Separation of Indirect & Assisted definitions. =20 > --> Daryl - Can you submit your proposed change today=20 > or tomorrow while the discussion is fresh in your mind? >=20 > Thanks > Jason >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 24 15:56:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQV0-0007ya-2n; Tue, 24 Jul 2007 15:56:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQUy-0007yI-JI for speermint@ietf.org; Tue, 24 Jul 2007 15:56:48 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDQUx-0001e1-Mf for speermint@ietf.org; Tue, 24 Jul 2007 15:56:48 -0400 Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.44956301; Tue, 24 Jul 2007 15:56:29 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 15:56:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Final 2 Issues on Terminology Draft Date: Tue, 24 Jul 2007 15:56:19 -0400 Message-ID: <45AEC6EF95942140888406588E1A660201A2A3AA@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A660201A2A3A1@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Final 2 Issues on Terminology Draft Thread-Index: AcfOKUPjH3CFN922TxWE/yGwfA842QAA1ifQ References: <45AEC6EF95942140888406588E1A660201A2A3A1@PACDCEXCMB04.cable.comcast.com> From: "Livingood, Jason" To: "Daryl Malas" , X-OriginalArrivalTime: 24 Jul 2007 19:56:29.0740 (UTC) FILETIME=[B9F9FEC0:01C7CE2C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Per the other thread, item #1 is now closed. Item #2 is all that is left:=20 2 - Separation of Indirect & Assisted definitions. =20 --> Daryl - Can you submit your proposed change today or tomorrow while the discussion is fresh in your mind? Jason > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Tuesday, July 24, 2007 3:32 PM > To: Daryl Malas; speermint@ietf.org > Subject: [Speermint] Final 2 Issues on Terminology Draft >=20 > Per the IETF 69 meeting, we have 2 final issues to close out=20 > before we can update to a -10 draft and then issue WGLC. >=20 > 1 - Location & Lookup Function definitions. You already=20 > submitted a thread on that. Seems like you have rough=20 > consensus, pending any suggested changes from Yiu Lee (Yiu=20 > --> please get these in today or indicate no changes requested.) >=20 > 2 - Separation of Indirect & Assisted definitions. =20 > --> Daryl - Can you submit your proposed change today=20 > or tomorrow while the discussion is fresh in your mind? >=20 > Thanks > Jason >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint ______________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jul 24 15:56:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQV0-0007ya-2n; Tue, 24 Jul 2007 15:56:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQUy-0007yI-JI for speermint@ietf.org; Tue, 24 Jul 2007 15:56:48 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDQUx-0001e1-Mf for speermint@ietf.org; Tue, 24 Jul 2007 15:56:48 -0400 Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.44956301; Tue, 24 Jul 2007 15:56:29 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 15:56:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Final 2 Issues on Terminology Draft Date: Tue, 24 Jul 2007 15:56:19 -0400 Message-ID: <45AEC6EF95942140888406588E1A660201A2A3AA@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A660201A2A3A1@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Final 2 Issues on Terminology Draft Thread-Index: AcfOKUPjH3CFN922TxWE/yGwfA842QAA1ifQ References: <45AEC6EF95942140888406588E1A660201A2A3A1@PACDCEXCMB04.cable.comcast.com> From: "Livingood, Jason" To: "Daryl Malas" , X-OriginalArrivalTime: 24 Jul 2007 19:56:29.0740 (UTC) FILETIME=[B9F9FEC0:01C7CE2C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Per the other thread, item #1 is now closed. Item #2 is all that is left:=20 2 - Separation of Indirect & Assisted definitions. =20 --> Daryl - Can you submit your proposed change today or tomorrow while the discussion is fresh in your mind? Jason > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 > Sent: Tuesday, July 24, 2007 3:32 PM > To: Daryl Malas; speermint@ietf.org > Subject: [Speermint] Final 2 Issues on Terminology Draft >=20 > Per the IETF 69 meeting, we have 2 final issues to close out=20 > before we can update to a -10 draft and then issue WGLC. >=20 > 1 - Location & Lookup Function definitions. You already=20 > submitted a thread on that. Seems like you have rough=20 > consensus, pending any suggested changes from Yiu Lee (Yiu=20 > --> please get these in today or indicate no changes requested.) >=20 > 2 - Separation of Indirect & Assisted definitions. =20 > --> Daryl - Can you submit your proposed change today=20 > or tomorrow while the discussion is fresh in your mind? >=20 > Thanks > Jason >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jul 30 05:07:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFRDh-000445-3C; Mon, 30 Jul 2007 05:07:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFRDg-00043p-1M; Mon, 30 Jul 2007 05:07:16 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IFRDf-0005LL-0y; Mon, 30 Jul 2007 05:07:15 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm6a46adb77a; Mon, 30 Jul 2007 17:19:07 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm3746a77907; Wed, 25 Jul 2007 19:59:29 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 25 Jul 2007 19:59:29 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDN38-0003nv-GA; Tue, 24 Jul 2007 12:15:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDN2t-0003Ua-QS; Tue, 24 Jul 2007 12:15:35 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDN2r-0006Xr-14; Tue, 24 Jul 2007 12:15:35 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id DED942ACCD; Tue, 24 Jul 2007 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IDN2M-0005W4-E9; Tue, 24 Jul 2007 12:15: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: Tue, 24 Jul 2007 12:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt X-BeenThere: speermint@ietf.org Reply-To: internet-drafts@ietf.org List-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 : 21 Date : 2007-6-8 This document will capture VoIP use case for SIP Peering. It is a consolidation of Speermint use cases drafts. This documents depicts many common VoIP peering use cases. These use cases are categorized into three types: Direct, Indirect and Assisted. They are not the exhaust set of use cases but the most common use cases deployed in production today. This document captures them to provide a reference. 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-7-24113058.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-7-24113058.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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--