From speermint-bounces@ietf.org Mon Feb 2 09:35:26 2009 Return-Path: X-Original-To: speermint-archive@megatron.ietf.org Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67C628C259; Mon, 2 Feb 2009 09:35:26 -0800 (PST) X-Original-To: speermint@ietf.org Delivered-To: speermint@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 51E3B28C1D0; Mon, 2 Feb 2009 09:35:24 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090202173524.51E3B28C1D0@core3.amsl.com> Date: Mon, 2 Feb 2009 09:35:24 -0800 (PST) Cc: speermint chair , speermint mailing list , Internet Architecture Board , RFC Editor Subject: [Speermint] Document Action: 'SPEERMINT Terminology' to Informational RFC X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org The IESG has approved the following document: - 'SPEERMINT Terminology ' as an Informational RFC This document is the product of the Session PEERing for Multimedia INTerconnect Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-17.txt Technical Summary This document defines the basic terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). Working Group Summary There is consensus in the WG to publish this document. Several Working Group Last Calls have been issued, and we have finally achieved consensus and resolved all concerns. All changes suggested by the WG have been made to this draft. A nits review has also been performed by our secretary, and those changes made as well. Document Quality There are no protocol implementations proposed, only terminology. The new terms and now consistently in use across all SPEERMINT documents. Personnel Document Shepherd: Jason Livingood Responsible AD: Jon Peterson IANA Experts Required: No _______________________________________________ Speermint mailing list Speermint@ietf.org https://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 3 09:02:37 2009 Return-Path: X-Original-To: speermint-archive@megatron.ietf.org Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FDA128C123; Tue, 3 Feb 2009 09:02:37 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31F463A6C3A for ; Tue, 3 Feb 2009 09:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umhkkTAAuvcf for ; Tue, 3 Feb 2009 09:02:35 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id BC0AE3A6C41 for ; Tue, 3 Feb 2009 09:02:34 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n13H2DVh009057; Tue, 3 Feb 2009 10:02:15 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 3 Feb 2009 10:02:13 -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 Date: Tue, 3 Feb 2009 10:02:13 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491B1B072@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Meeting minutes from IETF 73 Speermint session (Arch Draft Review) Thread-Index: AclheIM6vfcHtNx+S0q4AzvQWgZd6QeqtZlgAX4X54A= References: <160DE07A1C4F8E4AA2715DEC577DA491B1AF74@srvxchg3.cablelabs.com> From: "Daryl Malas" To: X-Approved: ondar Subject: [Speermint] RE: Meeting minutes from IETF 73 Speermint session (Arch Draft Review) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Jim, Thanks for the review. Comments in-line... ---------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Monday, January 26, 2009 8:28 PM > To: speermint@ietf.org > Cc: Daryl Malas > Subject: RE: [Speermint] Meeting minutes from IETF 73 > Speermint session > > Daryl, > I volunteered to do a detailed review of the SPEERMINT > Peering Architecture draft, so in the spirit of "better late > than never" I will begin sending my comments to the list for > consideration. My comments will be in several emails over > the rest of the week... > > First a nit: > > 1. References. It appears that the references (at least in the > introduction) are off by one. SPEERMINT Requirements is shown > as [13], but is actually [14] while Terminology is shown as > [12] but is [13] in the reference section. I didn't go > further, but please check to ensure references are correct. > > Next, a couple of general comments related to consistency: > > 2. Originating vs. Initiating SSP: Sometimes we use one, > sometimes the other. In this case I'm pretty sure everyone > agrees on what we mean, so let's pick one or the other and > use it throughout. (I'm kind of leaning toward "initiating" > but cold live with either.) I personally prefer "originating". > > 3. SSP vs. peer: Most of the time we use "SSP", but in some > sections we begin to use "peer". I think the term "peer" is > relative, and leaves us open to all sorts of confusion, while > the SSP is clear. My preference is to use SSP throughout, and > I will assume that in any remaining comments. I agree with using SSP. > > 4. Target vs. Terminating: I'll save that one for later, as > I don't believe we all are in agreement just yet on that > particular one. I think Jon made valid points at the last WG meeting that 'Target' is a better term, since a call may be transferred or re-targeted later. I suggest we use 'Target'. > > Now on to section specific comments: > > 5. Section 2. Network Context, final paragraph says: > " The members of a federation may jointly use a set of functions such > as location function..." > Comment: The terminology draft defines LUF and LRF, but does > not define "location function". Similarly, this draft also > discusses LUF and LRF, but not "location function". > Recommended Solution: Change "location function" to "Look-Up > Function, Location Routing Function,". While we are at it, > we probably should capitalize the other functions the way we > have done in the Terminology draft. > > 6. Section 3. Procedures, > Bullet 5 states " the determination of the UAS,". > Comment: This is unclear to me. I think we are determining > something about the UAS, perhaps the location of the UAS. If > this is correct, then we should change it to say this. I agree this is a little too ambiguous. I recommend we change it to "determine the location of the target UA". On a separate note, there has been previous discussion on the use of UAC or UAS versus simply UA. I believe in those previous discussions it was determined the preference was to simply refer to either as a 'UA'. This is a minor nit, but believe it will make the draft more consistent with other similar IETF works. > > 7. Section 3. Procedures > This section might be strengthened by changing to the active > voice. For example, bullet 6 would be a lot clearer (to me > at least) if we just said "establish the session". However, > I'm ok with group consensus on this one. I am okay with either. To me, they mean the same thing. > > 8. Section 3. Procedures: > The final paragraph states that "In the case the target SSP > is different from the terminating SSP ...". > Comment: If we are going to open this can of worms (and I > fear we must) then it is crucial that we clearly define what > terminating and target SSP mean, and use them with absolute > consistency throughout the document. If there was a > consensus on the list after Minneapolis, I missed it; to me > it sounded like two solitudes. > > Since I don't want to just raise issues, I am going to > propose what I think makes sense here, and let people react. > Target SSP = the SSP we are currently trying to reach. If > the session is "retargeted" then it is given a new target SSP > (unless of course the new target is in the same SSP). This > seems consistent with general usage. > Terminating SSP = the SSP where the session actually does terminate. I am glad you brought this issue up. My preference is to simply scrap "Terminating SSP" altogether. IMO, it is to difficult for it to be consistent. If we must use it, I prefer we refer to "Terminating SSP" only if the session actually *ends* there. In this case, I mean a successful "BYE" dialog occurs. All other references should refer to "Target SSP". > > The remainder of my comments assume these definitions. > > In the spirit of making concrete suggestions, I would suggest > that the final paragraph of Section 3 be modified as follows: > > Current text: > "In the case the target SSP is different from the terminating SSP it > would repeat steps 1-4. This is reflected in Figure 2 that > shows the > target SSP with its own peering functions." > > Change to: > " In the case the initial target SSP is different from the > terminating SSP it would repeat steps 1-4. This is reflected > in Figure 2 that shows the > target SSP with its own peering functions." Keeping in the spirit of removing Terminating SSP, I would suggest we change it to "In the case the target SSP changes during the session it would repeat steps 1-4. This is reflected in Figure 2 that shows the target SSP with its own peering functions." > > 9. Section 5.1. Originating SSP Procedures We use > "originating SSP" in the section heading, but "initiating > SSP" in the body. > > 10. Section 5.1.1. The Look-Up Function > Currently states "Purpose is to determine the SF of the > target domain ..." > Comment: Earlier in this document, and in the Terminology > draft, we state that the LUF determines the target domain - > not the SF of the target domain. In addition, we later state > that the LRF determines the location of the SF. Therefore I > believe we should change as follows: > Current text: > "Purpose is to determine the SF of the target domain ..." > > Change to: > "Purpose is to determine the target domain ..." > > 11. Section 5.1.1. The Look-Up Function > Currently states "...optionally develop Session Establishment > Data (SED) [12]." > Comment: I believe this is only true when the target address > is in the same domain as the initiating SSP, otherwise the > LRF develops the SED. > Therefore I suggest we change as follows: > Current text: > "... optionally develop Session Establishment Data (SED) [12]. " > > Change to: > "... if the target address is in the same administrative > domain as the initiating SSP, optionally develop Session > Establishment Data (SED) [12]. " > > 12. Section 5.1.1.1 Target address analysis. > Second paragraph states that > "... the initiating SSP resolves the call routing data by > using the Location Routing Function (LRF)" > > I suggest we recognize the step where the LUF first > determines the target domain, by changing the above to read: > "... the initiating SSP first determines the target domain, > and then resolves the call routing data by using the Location > Routing Function (LRF)" > > 13. Section 5.1.1.1 Target address analysis. > The third paragraph begins with "For example...". This confuses me. > The previous paragraph ends by saying what the LRF does, but > then immediately gives examples of how the LUF works - at > least I think this is what it is providing. At the very > least we need to somehow qualify the examples, though to be > honest I'd be happy if we just deleted the third and fourth > paragraphs.. > > ---- end of first set of comments ---- > > More comments to follow in a day or so. > > > Jim McEachern > T:+1 613 763-3419 > M:+1 613 853-0176 > > > -----Original Message----- > From: speermint-bounces@ietf.org > [mailto:speermint-bounces@ietf.org] On Behalf Of Daryl Malas > Sent: Thursday, December 18, 2008 8:24 PM > To: speermint@ietf.org > Cc: Alexander Mayrhofer; Livingood,Jason > Subject: [Speermint] Meeting minutes from IETF 73 Speermint session > > All, > > The meeting minutes for the IETF 73 Speermint session can be > found here: > > http://www.ietf.org/proceedings/08nov/minutes/speermint.txt > > Please check the notes, as some of you volunteered to do > things...and, some by the end of the year (2008). Also, > there were several issues that were going to be further > discussed on the mailing list. Those of you presenting on > these topics, please start the threads. > > If you have questions, concerns, or feel like something > important was left out let us know. > > Thank you for your participation in Minneapolis. > > Regards, > > Daryl > > Speermint co-Chair > > > ---------------- > Daryl Malas > CableLabs > (o) +1 303 661 3302 > (f) +1 303 661 9199 > mailto:d.malas@cablelabs.com > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 3 09:11:03 2009 Return-Path: X-Original-To: speermint-archive@megatron.ietf.org Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E6C828C27E; Tue, 3 Feb 2009 09:11:03 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2349D28C276 for ; Tue, 3 Feb 2009 09:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVZIrz3mnHMj for ; Tue, 3 Feb 2009 09:11:00 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 450AE28C275 for ; Tue, 3 Feb 2009 09:11:00 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n13HAf8u009850 for ; Tue, 3 Feb 2009 10:10:41 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 3 Feb 2009 10:10:41 -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 Date: Tue, 3 Feb 2009 10:10:40 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491B1B073@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Problem: SIP Interoperability between Peers Thread-Index: AcmGIlgRBjX9+QL7TDKFiJizRmNVqA== From: "Daryl Malas" To: X-Approved: ondar Subject: [Speermint] Problem: SIP Interoperability between Peers X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org All, I regularly hear the biggest problem facing SSPs attempting to peer is SIP interoperability. There are simply too many optional uses of SIP today. My questions are how do we solve this problem, and should it be solved in Speermint? In the past few months, I have spoke with different service providers, and each of them have their own *spreadsheet* describing what SIP extensions and variables you must conform to in order to peer with them. In addition to the other capabilities an SBC provides, it is also becoming a peer SIP profile manager. Operational teams are screaming they spend most of their time trying to figure out what profile to use for what peer. How do we solve this problem? At Minneapolis, during the RAI open meeting, there was a discussion that the IETF does not support implementers with real problems. Here is a real problem plaguing the industry. How do we solve it? Thoughts and feedback is appreciated. Regards, Daryl ---------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com _______________________________________________ Speermint mailing list Speermint@ietf.org https://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 3 09:16:16 2009 Return-Path: X-Original-To: speermint-archive@megatron.ietf.org Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175AA28C267; Tue, 3 Feb 2009 09:16:16 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C680B28C262 for ; Tue, 3 Feb 2009 09:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ccp6EZ999IsD for ; Tue, 3 Feb 2009 09:16:13 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C97C928C167 for ; Tue, 3 Feb 2009 09:16:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,373,1231113600"; d="scan'208";a="35808662" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Feb 2009 17:15:53 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13HFr66011021; Tue, 3 Feb 2009 12:15:53 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13HFjMe003250; Tue, 3 Feb 2009 17:15:53 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 12:15:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Feb 2009 12:15:01 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30645FAF7@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA491B1B072@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Meeting minutes from IETF 73 Speermint session(Arch Draft Review) Thread-Index: AclheIM6vfcHtNx+S0q4AzvQWgZd6QeqtZlgAX4X54AAAZ3Q8A== References: <160DE07A1C4F8E4AA2715DEC577DA491B1AF74@srvxchg3.cablelabs.com> <160DE07A1C4F8E4AA2715DEC577DA491B1B072@srvxchg3.cablelabs.com> From: "Mike Hammer (hmmr)" To: "Daryl Malas" , X-OriginalArrivalTime: 03 Feb 2009 17:15:51.0192 (UTC) FILETIME=[10484980:01C98623] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11368; t=1233681353; x=1234545353; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hmmr@cisco.com; z=From:=20=22Mike=20Hammer=20(hmmr)=22=20 |Subject:=20RE=3A=20[Speermint]=20RE=3A=20Meeting=20minutes =20from=20IETF=2073=20Speermint=20session(Arch=20Draft=20Rev iew) |Sender:=20 |To:=20=22Daryl=20Malas=22=20,=20; bh=B2babUJ/aBmiuh5Fe7hJzsA8K56ODvCFjZudJl58CQk=; b=AHhzsLEgizbdhIzLQsQUd2BnsgTcyRWvhyWC3mqzlXwhrBv4qII8enSmWs EA3Bg5zFSFCZl8WkeUW4oOc8qTFZ7cqf5X5jUUdihcqnZwcWf//s2evQNMR7 unJiw0QyT4; Authentication-Results: rtp-dkim-1; header.From=hmmr@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Speermint] Meeting minutes from IETF 73 Speermint session(Arch Draft Review) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Daryl, I believe the original intent of the Terminating SSP is to identify the SSP serving the called party, i.e. the one that provides all the services and functionality (beyond just call routing) for the person who actually answers the call. What used to be called supplementary services. It is not an intermediate node that is just playing the role of an IXC switch. This also plays into the idea of targeting being the intended end-user, which through various features, like call forwarding, could be re-targeted to another end-user. In any case, so long as there is a distinction between intermediate hops and the final point serving the end-user, we have done our job. It is not clear to me if you remove that term, then what term replaces it? Mike > -----Original Message----- > From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On > Behalf Of Daryl Malas > Sent: Tuesday, February 03, 2009 12:02 PM > To: speermint@ietf.org > Subject: [Speermint] RE: Meeting minutes from IETF 73 Speermint > session(Arch Draft Review) > > Jim, > > Thanks for the review. > > Comments in-line... > > > ---------------- > Daryl Malas > CableLabs > (o) +1 303 661 3302 > (f) +1 303 661 9199 > mailto:d.malas@cablelabs.com > > > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Monday, January 26, 2009 8:28 PM > > To: speermint@ietf.org > > Cc: Daryl Malas > > Subject: RE: [Speermint] Meeting minutes from IETF 73 > > Speermint session > > > > Daryl, > > I volunteered to do a detailed review of the SPEERMINT > > Peering Architecture draft, so in the spirit of "better late > > than never" I will begin sending my comments to the list for > > consideration. My comments will be in several emails over > > the rest of the week... > > > > First a nit: > > > > 1. References. It appears that the references (at least in the > > introduction) are off by one. SPEERMINT Requirements is shown > > as [13], but is actually [14] while Terminology is shown as > > [12] but is [13] in the reference section. I didn't go > > further, but please check to ensure references are correct. > > > > Next, a couple of general comments related to consistency: > > > > 2. Originating vs. Initiating SSP: Sometimes we use one, > > sometimes the other. In this case I'm pretty sure everyone > > agrees on what we mean, so let's pick one or the other and > > use it throughout. (I'm kind of leaning toward "initiating" > > but cold live with either.) > > I personally prefer "originating". > > > > > 3. SSP vs. peer: Most of the time we use "SSP", but in some > > sections we begin to use "peer". I think the term "peer" is > > relative, and leaves us open to all sorts of confusion, while > > the SSP is clear. My preference is to use SSP throughout, and > > I will assume that in any remaining comments. > > I agree with using SSP. > > > > > 4. Target vs. Terminating: I'll save that one for later, as > > I don't believe we all are in agreement just yet on that > > particular one. > > I think Jon made valid points at the last WG meeting that 'Target' is a > better term, since a call may be transferred or re-targeted later. I > suggest we use 'Target'. > > > > > Now on to section specific comments: > > > > 5. Section 2. Network Context, final paragraph says: > > " The members of a federation may jointly use a set of functions such > > as location function..." > > Comment: The terminology draft defines LUF and LRF, but does > > not define "location function". Similarly, this draft also > > discusses LUF and LRF, but not "location function". > > Recommended Solution: Change "location function" to "Look-Up > > Function, Location Routing Function,". While we are at it, > > we probably should capitalize the other functions the way we > > have done in the Terminology draft. > > > > 6. Section 3. Procedures, > > Bullet 5 states " the determination of the UAS,". > > Comment: This is unclear to me. I think we are determining > > something about the UAS, perhaps the location of the UAS. If > > this is correct, then we should change it to say this. > > I agree this is a little too ambiguous. I recommend we change it to > "determine the location of the target UA". On a separate note, there > has been previous discussion on the use of UAC or UAS versus simply UA. > I believe in those previous discussions it was determined the preference > was to simply refer to either as a 'UA'. This is a minor nit, but > believe it will make the draft more consistent with other similar IETF > works. > > > > > 7. Section 3. Procedures > > This section might be strengthened by changing to the active > > voice. For example, bullet 6 would be a lot clearer (to me > > at least) if we just said "establish the session". However, > > I'm ok with group consensus on this one. > > I am okay with either. To me, they mean the same thing. > > > > > 8. Section 3. Procedures: > > The final paragraph states that "In the case the target SSP > > is different from the terminating SSP ...". > > Comment: If we are going to open this can of worms (and I > > fear we must) then it is crucial that we clearly define what > > terminating and target SSP mean, and use them with absolute > > consistency throughout the document. If there was a > > consensus on the list after Minneapolis, I missed it; to me > > it sounded like two solitudes. > > > > Since I don't want to just raise issues, I am going to > > propose what I think makes sense here, and let people react. > > Target SSP = the SSP we are currently trying to reach. If > > the session is "retargeted" then it is given a new target SSP > > (unless of course the new target is in the same SSP). This > > seems consistent with general usage. > > Terminating SSP = the SSP where the session actually does terminate. > > I am glad you brought this issue up. My preference is to simply scrap > "Terminating SSP" altogether. IMO, it is to difficult for it to be > consistent. If we must use it, I prefer we refer to "Terminating SSP" > only if the session actually *ends* there. In this case, I mean a > successful "BYE" dialog occurs. All other references should refer to > "Target SSP". > > > > > The remainder of my comments assume these definitions. > > > > In the spirit of making concrete suggestions, I would suggest > > that the final paragraph of Section 3 be modified as follows: > > > > Current text: > > "In the case the target SSP is different from the terminating SSP it > > would repeat steps 1-4. This is reflected in Figure 2 that > > shows the > > target SSP with its own peering functions." > > > > Change to: > > " In the case the initial target SSP is different from the > > terminating SSP it would repeat steps 1-4. This is reflected > > in Figure 2 that shows the > > target SSP with its own peering functions." > > Keeping in the spirit of removing Terminating SSP, I would suggest we > change it to "In the case the target SSP changes during the session it > would repeat steps 1-4. This is reflected in Figure 2 that shows the > target SSP with its own peering functions." > > > > > 9. Section 5.1. Originating SSP Procedures We use > > "originating SSP" in the section heading, but "initiating > > SSP" in the body. > > > > 10. Section 5.1.1. The Look-Up Function > > Currently states "Purpose is to determine the SF of the > > target domain ..." > > Comment: Earlier in this document, and in the Terminology > > draft, we state that the LUF determines the target domain - > > not the SF of the target domain. In addition, we later state > > that the LRF determines the location of the SF. Therefore I > > believe we should change as follows: > > Current text: > > "Purpose is to determine the SF of the target domain ..." > > > > Change to: > > "Purpose is to determine the target domain ..." > > > > 11. Section 5.1.1. The Look-Up Function > > Currently states "...optionally develop Session Establishment > > Data (SED) [12]." > > Comment: I believe this is only true when the target address > > is in the same domain as the initiating SSP, otherwise the > > LRF develops the SED. > > Therefore I suggest we change as follows: > > Current text: > > "... optionally develop Session Establishment Data (SED) [12]. " > > > > Change to: > > "... if the target address is in the same administrative > > domain as the initiating SSP, optionally develop Session > > Establishment Data (SED) [12]. " > > > > 12. Section 5.1.1.1 Target address analysis. > > Second paragraph states that > > "... the initiating SSP resolves the call routing data by > > using the Location Routing Function (LRF)" > > > > I suggest we recognize the step where the LUF first > > determines the target domain, by changing the above to read: > > "... the initiating SSP first determines the target domain, > > and then resolves the call routing data by using the Location > > Routing Function (LRF)" > > > > 13. Section 5.1.1.1 Target address analysis. > > The third paragraph begins with "For example...". This confuses me. > > The previous paragraph ends by saying what the LRF does, but > > then immediately gives examples of how the LUF works - at > > least I think this is what it is providing. At the very > > least we need to somehow qualify the examples, though to be > > honest I'd be happy if we just deleted the third and fourth > > paragraphs.. > > > > ---- end of first set of comments ---- > > > > More comments to follow in a day or so. > > > > > > Jim McEachern > > T:+1 613 763-3419 > > M:+1 613 853-0176 > > > > > > -----Original Message----- > > From: speermint-bounces@ietf.org > > [mailto:speermint-bounces@ietf.org] On Behalf Of Daryl Malas > > Sent: Thursday, December 18, 2008 8:24 PM > > To: speermint@ietf.org > > Cc: Alexander Mayrhofer; Livingood,Jason > > Subject: [Speermint] Meeting minutes from IETF 73 Speermint session > > > > All, > > > > The meeting minutes for the IETF 73 Speermint session can be > > found here: > > > > http://www.ietf.org/proceedings/08nov/minutes/speermint.txt > > > > Please check the notes, as some of you volunteered to do > > things...and, some by the end of the year (2008). Also, > > there were several issues that were going to be further > > discussed on the mailing list. Those of you presenting on > > these topics, please start the threads. > > > > If you have questions, concerns, or feel like something > > important was left out let us know. > > > > Thank you for your participation in Minneapolis. > > > > Regards, > > > > Daryl > > > > Speermint co-Chair > > > > > > ---------------- > > Daryl Malas > > CableLabs > > (o) +1 303 661 3302 > > (f) +1 303 661 9199 > > mailto:d.malas@cablelabs.com > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 3 09:24:46 2009 Return-Path: X-Original-To: speermint-archive@megatron.ietf.org Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC6773A6C43; Tue, 3 Feb 2009 09:24:46 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6723A6C43 for ; Tue, 3 Feb 2009 09:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.163 X-Spam-Level: X-Spam-Status: No, score=-0.163 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzUSTgiaCJ+g for ; Tue, 3 Feb 2009 09:24:44 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 87FC83A6C41 for ; Tue, 3 Feb 2009 09:24:44 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n13HONbO011159; Tue, 3 Feb 2009 10:24:23 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 3 Feb 2009 10:24:23 -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 Date: Tue, 3 Feb 2009 10:24:22 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491B1B075@srvxchg3.cablelabs.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30645FAF7@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Meeting minutes from IETF 73 Speermint session(Arch Draft Review) Thread-Index: AclheIM6vfcHtNx+S0q4AzvQWgZd6QeqtZlgAX4X54AAAZ3Q8AAAcVeg References: <160DE07A1C4F8E4AA2715DEC577DA491B1AF74@srvxchg3.cablelabs.com> <160DE07A1C4F8E4AA2715DEC577DA491B1B072@srvxchg3.cablelabs.com> <072C5B76F7CEAB488172C6F64B30B5E30645FAF7@xmb-rtp-20b.amer.cisco.com> From: "Daryl Malas" To: "Mike Hammer (hmmr)" , X-Approved: ondar Subject: Re: [Speermint] Meeting minutes from IETF 73 Speermint session(Arch Draft Review) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Mike, While I want to try to avoid "violent agreement" on the use of this term, I will clarify I was not referring to it as an IXC switch. It is more to indicate a UA that is the target for the session may not remain the target, and "terminating" seems to indicate to me finality. This makes the term limiting and confusion, imo. Regards, Daryl ---------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com > -----Original Message----- > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > Sent: Tuesday, February 03, 2009 10:15 AM > To: Daryl Malas; speermint@ietf.org > Subject: RE: [Speermint] RE: Meeting minutes from IETF 73 > Speermint session(Arch Draft Review) > > Daryl, > > I believe the original intent of the Terminating SSP is to > identify the SSP serving the called party, i.e. the one that > provides all the services and functionality (beyond just call > routing) for the person who actually answers the call. What > used to be called supplementary services. It is not an > intermediate node that is just playing the role of an IXC switch. > > This also plays into the idea of targeting being the intended > end-user, which through various features, like call > forwarding, could be re-targeted to another end-user. > > In any case, so long as there is a distinction between > intermediate hops and the final point serving the end-user, > we have done our job. It is not clear to me if you remove > that term, then what term replaces it? > > Mike > > > > > -----Original Message----- > > From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] > On > > Behalf Of Daryl Malas > > Sent: Tuesday, February 03, 2009 12:02 PM > > To: speermint@ietf.org > > Subject: [Speermint] RE: Meeting minutes from IETF 73 Speermint > > session(Arch Draft Review) > > > > Jim, > > > > Thanks for the review. > > > > Comments in-line... > > > > > > ---------------- > > Daryl Malas > > CableLabs > > (o) +1 303 661 3302 > > (f) +1 303 661 9199 > > mailto:d.malas@cablelabs.com > > > > > > > -----Original Message----- > > > From: James McEachern [mailto:jmce@nortel.com] > > > Sent: Monday, January 26, 2009 8:28 PM > > > To: speermint@ietf.org > > > Cc: Daryl Malas > > > Subject: RE: [Speermint] Meeting minutes from IETF 73 Speermint > > > session > > > > > > Daryl, > > > I volunteered to do a detailed review of the SPEERMINT Peering > > > Architecture draft, so in the spirit of "better late than > never" I > > > will begin sending my comments to the list for consideration. My > > > comments will be in several emails over the rest of the week... > > > > > > First a nit: > > > > > > 1. References. It appears that the references (at least in the > > > introduction) are off by one. SPEERMINT Requirements is shown as > > > [13], but is actually [14] while Terminology is shown as > [12] but is > > > [13] in the reference section. I didn't go further, but please > > > check to ensure references are correct. > > > > > > Next, a couple of general comments related to consistency: > > > > > > 2. Originating vs. Initiating SSP: Sometimes we use one, > sometimes > > > the other. In this case I'm pretty sure everyone agrees > on what we > > > mean, so let's pick one or the other and use it throughout. (I'm > > > kind of leaning toward "initiating" > > > but cold live with either.) > > > > I personally prefer "originating". > > > > > > > > 3. SSP vs. peer: Most of the time we use "SSP", but in > some sections > > > we begin to use "peer". I think the term "peer" is relative, and > > > leaves us open to all sorts of confusion, while the SSP > is clear. My > > > preference is to use SSP throughout, and I will assume > that in any > > > remaining comments. > > > > I agree with using SSP. > > > > > > > > 4. Target vs. Terminating: I'll save that one for later, > as I don't > > > believe we all are in agreement just yet on that particular one. > > > > I think Jon made valid points at the last WG meeting that > 'Target' is > a > > better term, since a call may be transferred or re-targeted > later. I > > suggest we use 'Target'. > > > > > > > > Now on to section specific comments: > > > > > > 5. Section 2. Network Context, final paragraph says: > > > " The members of a federation may jointly use a set of functions > such > > > as location function..." > > > Comment: The terminology draft defines LUF and LRF, but does not > > > define "location function". Similarly, this draft also discusses > > > LUF and LRF, but not "location function". > > > Recommended Solution: Change "location function" to "Look-Up > > > Function, Location Routing Function,". While we are at it, we > > > probably should capitalize the other functions the way we > have done > > > in the Terminology draft. > > > > > > 6. Section 3. Procedures, > > > Bullet 5 states " the determination of the UAS,". > > > Comment: This is unclear to me. I think we are determining > > > something about the UAS, perhaps the location of the UAS. > If this > > > is correct, then we should change it to say this. > > > > I agree this is a little too ambiguous. I recommend we > change it to > > "determine the location of the target UA". On a separate > note, there > > has been previous discussion on the use of UAC or UAS versus simply > UA. > > I believe in those previous discussions it was determined the > preference > > was to simply refer to either as a 'UA'. This is a minor nit, but > > believe it will make the draft more consistent with other > similar IETF > > works. > > > > > > > > 7. Section 3. Procedures > > > This section might be strengthened by changing to the > active voice. > > > For example, bullet 6 would be a lot clearer (to me at > least) if we > > > just said "establish the session". However, I'm ok with group > > > consensus on this one. > > > > I am okay with either. To me, they mean the same thing. > > > > > > > > 8. Section 3. Procedures: > > > The final paragraph states that "In the case the target SSP is > > > different from the terminating SSP ...". > > > Comment: If we are going to open this can of worms (and I fear we > > > must) then it is crucial that we clearly define what > terminating and > > > target SSP mean, and use them with absolute consistency > throughout > > > the document. If there was a consensus on the list after > > > Minneapolis, I missed it; to me it sounded like two solitudes. > > > > > > Since I don't want to just raise issues, I am going to > propose what > > > I think makes sense here, and let people react. > > > Target SSP = the SSP we are currently trying to reach. If the > > > session is "retargeted" then it is given a new target SSP > (unless of > > > course the new target is in the same SSP). This seems consistent > > > with general usage. > > > Terminating SSP = the SSP where the session actually does > terminate. > > > > I am glad you brought this issue up. My preference is to > simply scrap > > "Terminating SSP" altogether. IMO, it is to difficult for it to be > > consistent. If we must use it, I prefer we refer to > "Terminating SSP" > > only if the session actually *ends* there. In this case, I mean a > > successful "BYE" dialog occurs. All other references > should refer to > > "Target SSP". > > > > > > > > The remainder of my comments assume these definitions. > > > > > > In the spirit of making concrete suggestions, I would > suggest that > > > the final paragraph of Section 3 be modified as follows: > > > > > > Current text: > > > "In the case the target SSP is different from the > terminating SSP it > > > would repeat steps 1-4. This is reflected in Figure 2 > that shows > > > the > > > target SSP with its own peering functions." > > > > > > Change to: > > > " In the case the initial target SSP is different from the > > > terminating SSP it would repeat steps 1-4. This is reflected in > > > Figure 2 that shows the > > > target SSP with its own peering functions." > > > > Keeping in the spirit of removing Terminating SSP, I would > suggest we > > change it to "In the case the target SSP changes during the > session it > > would repeat steps 1-4. This is reflected in Figure 2 that > shows the > > target SSP with its own peering functions." > > > > > > > > 9. Section 5.1. Originating SSP Procedures We use > "originating SSP" > > > in the section heading, but "initiating SSP" in the body. > > > > > > 10. Section 5.1.1. The Look-Up Function Currently states > "Purpose is > > > to determine the SF of the target domain ..." > > > Comment: Earlier in this document, and in the Terminology > draft, we > > > state that the LUF determines the target domain - not the > SF of the > > > target domain. In addition, we later state that the LRF > determines > > > the location of the SF. Therefore I believe we should change as > > > follows: > > > Current text: > > > "Purpose is to determine the SF of the target domain ..." > > > > > > Change to: > > > "Purpose is to determine the target domain ..." > > > > > > 11. Section 5.1.1. The Look-Up Function Currently states > > > "...optionally develop Session Establishment Data (SED) [12]." > > > Comment: I believe this is only true when the target > address is in > > > the same domain as the initiating SSP, otherwise the LRF develops > > > the SED. > > > Therefore I suggest we change as follows: > > > Current text: > > > "... optionally develop Session Establishment Data (SED) [12]. " > > > > > > Change to: > > > "... if the target address is in the same administrative > domain as > > > the initiating SSP, optionally develop Session Establishment Data > > > (SED) [12]. " > > > > > > 12. Section 5.1.1.1 Target address analysis. > > > Second paragraph states that > > > "... the initiating SSP resolves the call routing data by > using the > > > Location Routing Function (LRF)" > > > > > > I suggest we recognize the step where the LUF first > determines the > > > target domain, by changing the above to read: > > > "... the initiating SSP first determines the target > domain, and then > > > resolves the call routing data by using the Location Routing > > > Function (LRF)" > > > > > > 13. Section 5.1.1.1 Target address analysis. > > > The third paragraph begins with "For example...". This > confuses me. > > > The previous paragraph ends by saying what the LRF does, but then > > > immediately gives examples of how the LUF works - at > least I think > > > this is what it is providing. At the very least we need > to somehow > > > qualify the examples, though to be honest I'd be happy if we just > > > deleted the third and fourth paragraphs.. > > > > > > ---- end of first set of comments ---- > > > > > > More comments to follow in a day or so. > > > > > > > > > Jim McEachern > > > T:+1 613 763-3419 > > > M:+1 613 853-0176 > > > > > > > > > -----Original Message----- > > > From: speermint-bounces@ietf.org > > > [mailto:speermint-bounces@ietf.org] On Behalf Of Daryl Malas > > > Sent: Thursday, December 18, 2008 8:24 PM > > > To: speermint@ietf.org > > > Cc: Alexander Mayrhofer; Livingood,Jason > > > Subject: [Speermint] Meeting minutes from IETF 73 > Speermint session > > > > > > All, > > > > > > The meeting minutes for the IETF 73 Speermint session can > be found > > > here: > > > > > > http://www.ietf.org/proceedings/08nov/minutes/speermint.txt > > > > > > Please check the notes, as some of you volunteered to do > > > things...and, some by the end of the year (2008). Also, > there were > > > several issues that were going to be further discussed on the > > > mailing list. Those of you presenting on these topics, > please start > > > the threads. > > > > > > If you have questions, concerns, or feel like something important > > > was left out let us know. > > > > > > Thank you for your participation in Minneapolis. > > > > > > Regards, > > > > > > Daryl > > > > > > Speermint co-Chair > > > > > > > > > ---------------- > > > Daryl Malas > > > CableLabs > > > (o) +1 303 661 3302 > > > (f) +1 303 661 9199 > > > mailto:d.malas@cablelabs.com > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www.ietf.org/mailman/listinfo/speermint > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 3 09:54:39 2009 Return-Path: X-Original-To: speermint-archive@megatron.ietf.org Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56B128C164; Tue, 3 Feb 2009 09:54:39 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FF313A6B17 for ; Tue, 3 Feb 2009 09:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77ztfluv6Tgg for ; Tue, 3 Feb 2009 09:54:36 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 583283A68AE for ; Tue, 3 Feb 2009 09:54:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,373,1231113600"; d="scan'208";a="35775295" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Feb 2009 17:54:16 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n13HsGRI021574; Tue, 3 Feb 2009 12:54:16 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n13HsGHT018905; Tue, 3 Feb 2009 17:54:16 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 12:54:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Feb 2009 12:53:47 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30645FB2C@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA491B1B075@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Meeting minutes from IETF 73 Speermint session(Arch Draft Review) Thread-Index: AclheIM6vfcHtNx+S0q4AzvQWgZd6QeqtZlgAX4X54AAAZ3Q8AAAcVegAADybFA= References: <160DE07A1C4F8E4AA2715DEC577DA491B1AF74@srvxchg3.cablelabs.com> <160DE07A1C4F8E4AA2715DEC577DA491B1B072@srvxchg3.cablelabs.com> <072C5B76F7CEAB488172C6F64B30B5E30645FAF7@xmb-rtp-20b.amer.cisco.com> <160DE07A1C4F8E4AA2715DEC577DA491B1B075@srvxchg3.cablelabs.com> From: "Mike Hammer (hmmr)" To: "Daryl Malas" , X-OriginalArrivalTime: 03 Feb 2009 17:54:15.0945 (UTC) FILETIME=[6E05AF90:01C98628] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14285; t=1233683656; x=1234547656; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hmmr@cisco.com; z=From:=20=22Mike=20Hammer=20(hmmr)=22=20 |Subject:=20RE=3A=20[Speermint]=20RE=3A=20Meeting=20minutes =20from=20IETF=2073=20Speermint=20session(Arch=20Draft=20Rev iew) |Sender:=20 |To:=20=22Daryl=20Malas=22=20,=20; bh=vbHqS3RnxzKDrNgCOdTGb7pxRa1mHhshvidQ2ixeam4=; b=pu/wuDlLdaSG8KCrln2Jahc9p5MwHcGtWkxU8J2vPCYBNCinb7YNmBFmld JKWyV9mo9QmVVz3h9YtgUdSI8cAORnULSt0q+l7NaEFi/vbltg5tSejuvlwP z1vn6qzt19; Authentication-Results: rtp-dkim-2; header.From=hmmr@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Speermint] Meeting minutes from IETF 73 Speermint session(Arch Draft Review) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Daryl, Understand. Calls can be forwarded and redirected in various ways. So, the goal is to use the term "Target SSP" with the idea that eventually the call gets "completed" and "terminates" at some place where an end-user can start receiving media? I am ok with that. I just wanted to have distinction between nodes that target calls and those that just route them. Maybe one day SIP gets the Request-URI and Route headers to have such a clean distinction as well. Mike > -----Original Message----- > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > Sent: Tuesday, February 03, 2009 12:24 PM > To: Mike Hammer (hmmr); speermint@ietf.org > Subject: RE: [Speermint] RE: Meeting minutes from IETF 73 Speermint > session(Arch Draft Review) > > Mike, > > While I want to try to avoid "violent agreement" on the use of this > term, I will clarify I was not referring to it as an IXC switch. It is > more to indicate a UA that is the target for the session may not remain > the target, and "terminating" seems to indicate to me finality. This > makes the term limiting and confusion, imo. > > Regards, > > Daryl > > > ---------------- > Daryl Malas > CableLabs > (o) +1 303 661 3302 > (f) +1 303 661 9199 > mailto:d.malas@cablelabs.com > > > > -----Original Message----- > > From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] > > Sent: Tuesday, February 03, 2009 10:15 AM > > To: Daryl Malas; speermint@ietf.org > > Subject: RE: [Speermint] RE: Meeting minutes from IETF 73 > > Speermint session(Arch Draft Review) > > > > Daryl, > > > > I believe the original intent of the Terminating SSP is to > > identify the SSP serving the called party, i.e. the one that > > provides all the services and functionality (beyond just call > > routing) for the person who actually answers the call. What > > used to be called supplementary services. It is not an > > intermediate node that is just playing the role of an IXC switch. > > > > This also plays into the idea of targeting being the intended > > end-user, which through various features, like call > > forwarding, could be re-targeted to another end-user. > > > > In any case, so long as there is a distinction between > > intermediate hops and the final point serving the end-user, > > we have done our job. It is not clear to me if you remove > > that term, then what term replaces it? > > > > Mike > > > > > > > > > -----Original Message----- > > > From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] > > On > > > Behalf Of Daryl Malas > > > Sent: Tuesday, February 03, 2009 12:02 PM > > > To: speermint@ietf.org > > > Subject: [Speermint] RE: Meeting minutes from IETF 73 Speermint > > > session(Arch Draft Review) > > > > > > Jim, > > > > > > Thanks for the review. > > > > > > Comments in-line... > > > > > > > > > ---------------- > > > Daryl Malas > > > CableLabs > > > (o) +1 303 661 3302 > > > (f) +1 303 661 9199 > > > mailto:d.malas@cablelabs.com > > > > > > > > > > -----Original Message----- > > > > From: James McEachern [mailto:jmce@nortel.com] > > > > Sent: Monday, January 26, 2009 8:28 PM > > > > To: speermint@ietf.org > > > > Cc: Daryl Malas > > > > Subject: RE: [Speermint] Meeting minutes from IETF 73 Speermint > > > > session > > > > > > > > Daryl, > > > > I volunteered to do a detailed review of the SPEERMINT Peering > > > > Architecture draft, so in the spirit of "better late than > > never" I > > > > will begin sending my comments to the list for consideration. My > > > > comments will be in several emails over the rest of the week... > > > > > > > > First a nit: > > > > > > > > 1. References. It appears that the references (at least in the > > > > introduction) are off by one. SPEERMINT Requirements is shown as > > > > [13], but is actually [14] while Terminology is shown as > > [12] but is > > > > [13] in the reference section. I didn't go further, but please > > > > check to ensure references are correct. > > > > > > > > Next, a couple of general comments related to consistency: > > > > > > > > 2. Originating vs. Initiating SSP: Sometimes we use one, > > sometimes > > > > the other. In this case I'm pretty sure everyone agrees > > on what we > > > > mean, so let's pick one or the other and use it throughout. (I'm > > > > kind of leaning toward "initiating" > > > > but cold live with either.) > > > > > > I personally prefer "originating". > > > > > > > > > > > 3. SSP vs. peer: Most of the time we use "SSP", but in > > some sections > > > > we begin to use "peer". I think the term "peer" is relative, and > > > > leaves us open to all sorts of confusion, while the SSP > > is clear. My > > > > preference is to use SSP throughout, and I will assume > > that in any > > > > remaining comments. > > > > > > I agree with using SSP. > > > > > > > > > > > 4. Target vs. Terminating: I'll save that one for later, > > as I don't > > > > believe we all are in agreement just yet on that particular one. > > > > > > I think Jon made valid points at the last WG meeting that > > 'Target' is > > a > > > better term, since a call may be transferred or re-targeted > > later. I > > > suggest we use 'Target'. > > > > > > > > > > > Now on to section specific comments: > > > > > > > > 5. Section 2. Network Context, final paragraph says: > > > > " The members of a federation may jointly use a set of functions > > such > > > > as location function..." > > > > Comment: The terminology draft defines LUF and LRF, but does not > > > > define "location function". Similarly, this draft also discusses > > > > LUF and LRF, but not "location function". > > > > Recommended Solution: Change "location function" to "Look-Up > > > > Function, Location Routing Function,". While we are at it, we > > > > probably should capitalize the other functions the way we > > have done > > > > in the Terminology draft. > > > > > > > > 6. Section 3. Procedures, > > > > Bullet 5 states " the determination of the UAS,". > > > > Comment: This is unclear to me. I think we are determining > > > > something about the UAS, perhaps the location of the UAS. > > If this > > > > is correct, then we should change it to say this. > > > > > > I agree this is a little too ambiguous. I recommend we > > change it to > > > "determine the location of the target UA". On a separate > > note, there > > > has been previous discussion on the use of UAC or UAS versus simply > > UA. > > > I believe in those previous discussions it was determined the > > preference > > > was to simply refer to either as a 'UA'. This is a minor nit, but > > > believe it will make the draft more consistent with other > > similar IETF > > > works. > > > > > > > > > > > 7. Section 3. Procedures > > > > This section might be strengthened by changing to the > > active voice. > > > > For example, bullet 6 would be a lot clearer (to me at > > least) if we > > > > just said "establish the session". However, I'm ok with group > > > > consensus on this one. > > > > > > I am okay with either. To me, they mean the same thing. > > > > > > > > > > > 8. Section 3. Procedures: > > > > The final paragraph states that "In the case the target SSP is > > > > different from the terminating SSP ...". > > > > Comment: If we are going to open this can of worms (and I fear we > > > > must) then it is crucial that we clearly define what > > terminating and > > > > target SSP mean, and use them with absolute consistency > > throughout > > > > the document. If there was a consensus on the list after > > > > Minneapolis, I missed it; to me it sounded like two solitudes. > > > > > > > > Since I don't want to just raise issues, I am going to > > propose what > > > > I think makes sense here, and let people react. > > > > Target SSP = the SSP we are currently trying to reach. If the > > > > session is "retargeted" then it is given a new target SSP > > (unless of > > > > course the new target is in the same SSP). This seems consistent > > > > with general usage. > > > > Terminating SSP = the SSP where the session actually does > > terminate. > > > > > > I am glad you brought this issue up. My preference is to > > simply scrap > > > "Terminating SSP" altogether. IMO, it is to difficult for it to be > > > consistent. If we must use it, I prefer we refer to > > "Terminating SSP" > > > only if the session actually *ends* there. In this case, I mean a > > > successful "BYE" dialog occurs. All other references > > should refer to > > > "Target SSP". > > > > > > > > > > > The remainder of my comments assume these definitions. > > > > > > > > In the spirit of making concrete suggestions, I would > > suggest that > > > > the final paragraph of Section 3 be modified as follows: > > > > > > > > Current text: > > > > "In the case the target SSP is different from the > > terminating SSP it > > > > would repeat steps 1-4. This is reflected in Figure 2 > > that shows > > > > the > > > > target SSP with its own peering functions." > > > > > > > > Change to: > > > > " In the case the initial target SSP is different from the > > > > terminating SSP it would repeat steps 1-4. This is reflected in > > > > Figure 2 that shows the > > > > target SSP with its own peering functions." > > > > > > Keeping in the spirit of removing Terminating SSP, I would > > suggest we > > > change it to "In the case the target SSP changes during the > > session it > > > would repeat steps 1-4. This is reflected in Figure 2 that > > shows the > > > target SSP with its own peering functions." > > > > > > > > > > > 9. Section 5.1. Originating SSP Procedures We use > > "originating SSP" > > > > in the section heading, but "initiating SSP" in the body. > > > > > > > > 10. Section 5.1.1. The Look-Up Function Currently states > > "Purpose is > > > > to determine the SF of the target domain ..." > > > > Comment: Earlier in this document, and in the Terminology > > draft, we > > > > state that the LUF determines the target domain - not the > > SF of the > > > > target domain. In addition, we later state that the LRF > > determines > > > > the location of the SF. Therefore I believe we should change as > > > > follows: > > > > Current text: > > > > "Purpose is to determine the SF of the target domain ..." > > > > > > > > Change to: > > > > "Purpose is to determine the target domain ..." > > > > > > > > 11. Section 5.1.1. The Look-Up Function Currently states > > > > "...optionally develop Session Establishment Data (SED) [12]." > > > > Comment: I believe this is only true when the target > > address is in > > > > the same domain as the initiating SSP, otherwise the LRF develops > > > > the SED. > > > > Therefore I suggest we change as follows: > > > > Current text: > > > > "... optionally develop Session Establishment Data (SED) [12]. " > > > > > > > > Change to: > > > > "... if the target address is in the same administrative > > domain as > > > > the initiating SSP, optionally develop Session Establishment Data > > > > (SED) [12]. " > > > > > > > > 12. Section 5.1.1.1 Target address analysis. > > > > Second paragraph states that > > > > "... the initiating SSP resolves the call routing data by > > using the > > > > Location Routing Function (LRF)" > > > > > > > > I suggest we recognize the step where the LUF first > > determines the > > > > target domain, by changing the above to read: > > > > "... the initiating SSP first determines the target > > domain, and then > > > > resolves the call routing data by using the Location Routing > > > > Function (LRF)" > > > > > > > > 13. Section 5.1.1.1 Target address analysis. > > > > The third paragraph begins with "For example...". This > > confuses me. > > > > The previous paragraph ends by saying what the LRF does, but then > > > > immediately gives examples of how the LUF works - at > > least I think > > > > this is what it is providing. At the very least we need > > to somehow > > > > qualify the examples, though to be honest I'd be happy if we just > > > > deleted the third and fourth paragraphs.. > > > > > > > > ---- end of first set of comments ---- > > > > > > > > More comments to follow in a day or so. > > > > > > > > > > > > Jim McEachern > > > > T:+1 613 763-3419 > > > > M:+1 613 853-0176 > > > > > > > > > > > > -----Original Message----- > > > > From: speermint-bounces@ietf.org > > > > [mailto:speermint-bounces@ietf.org] On Behalf Of Daryl Malas > > > > Sent: Thursday, December 18, 2008 8:24 PM > > > > To: speermint@ietf.org > > > > Cc: Alexander Mayrhofer; Livingood,Jason > > > > Subject: [Speermint] Meeting minutes from IETF 73 > > Speermint session > > > > > > > > All, > > > > > > > > The meeting minutes for the IETF 73 Speermint session can > > be found > > > > here: > > > > > > > > http://www.ietf.org/proceedings/08nov/minutes/speermint.txt > > > > > > > > Please check the notes, as some of you volunteered to do > > > > things...and, some by the end of the year (2008). Also, > > there were > > > > several issues that were going to be further discussed on the > > > > mailing list. Those of you presenting on these topics, > > please start > > > > the threads. > > > > > > > > If you have questions, concerns, or feel like something important > > > > was left out let us know. > > > > > > > > Thank you for your participation in Minneapolis. > > > > > > > > Regards, > > > > > > > > Daryl > > > > > > > > Speermint co-Chair > > > > > > > > > > > > ---------------- > > > > Daryl Malas > > > > CableLabs > > > > (o) +1 303 661 3302 > > > > (f) +1 303 661 9199 > > > > mailto:d.malas@cablelabs.com > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www.ietf.org/mailman/listinfo/speermint > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 3 10:20:22 2009 Return-Path: X-Original-To: speermint-archive@megatron.ietf.org Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04BE83A6982; Tue, 3 Feb 2009 10:20:22 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1DC3A6C50 for ; Tue, 3 Feb 2009 10:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hvg5w-y8FOWs for ; Tue, 3 Feb 2009 10:20:20 -0800 (PST) Received: from outbound-mail-132.bluehost.com (outbound-mail-132.bluehost.com [67.222.39.22]) by core3.amsl.com (Postfix) with SMTP id 964F83A6829 for ; Tue, 3 Feb 2009 10:20:16 -0800 (PST) Received: (qmail 1888 invoked by uid 0); 3 Feb 2009 18:19:55 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy4.bluehost.com with SMTP; 3 Feb 2009 18:19:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=WOmh4PV3sDoXU024bD3lbdRAM8uNxksVETX5O1PXLG/RVw7GbStLtNsgnxnNXzH+pw2ByX3pov81vNHP/9lF1Hh9sYz7bGvsyWyrKjqDTnJ0IIrK94LExF11oQq7YlBn; Received: from pni-63-239-16-243.prioritynetworks.net ([63.239.16.243] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LUPsI-0005ON-Fn; Tue, 03 Feb 2009 11:19:54 -0700 From: "Richard Shockey" To: "'Daryl Malas'" , References: <160DE07A1C4F8E4AA2715DEC577DA491B1B073@srvxchg3.cablelabs.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA491B1B073@srvxchg3.cablelabs.com> Date: Tue, 3 Feb 2009 13:19:52 -0500 Message-ID: <01af01c9862c$02c863e0$08592ba0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmGIlgRBjX9+QL7TDKFiJizRmNVqAACSOPQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 63.239.16.243 authed with richard+shockey.us} Subject: Re: [Speermint] Problem: SIP Interoperability between Peers X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org This is exactly what the SIPforum is trying to do with initiatives like SIPit and SIPconnect. I don't have much confidence that the IETF is the place to solve SIP interoperability problems. If there are lessons learned certainly they need to be reincorporated into the relevant RFC's but IMHO the structure of the IETF does not lend itself well to solving operational problems you describe. > -----Original Message----- > From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] > On Behalf Of Daryl Malas > Sent: Tuesday, February 03, 2009 12:11 PM > To: speermint@ietf.org > Subject: [Speermint] Problem: SIP Interoperability between Peers > > All, > > I regularly hear the biggest problem facing SSPs attempting to peer is > SIP interoperability. There are simply too many optional uses of SIP > today. My questions are how do we solve this problem, and should it > be > solved in Speermint? In the past few months, I have spoke with > different service providers, and each of them have their own > *spreadsheet* describing what SIP extensions and variables you must > conform to in order to peer with them. In addition to the other > capabilities an SBC provides, it is also becoming a peer SIP profile > manager. Operational teams are screaming they spend most of their > time > trying to figure out what profile to use for what peer. > > How do we solve this problem? At Minneapolis, during the RAI open > meeting, there was a discussion that the IETF does not support > implementers with real problems. Here is a real problem plaguing the > industry. How do we solve it? > > Thoughts and feedback is appreciated. > > Regards, > > Daryl > > > ---------------- > Daryl Malas > CableLabs > (o) +1 303 661 3302 > (f) +1 303 661 9199 > mailto:d.malas@cablelabs.com > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www.ietf.org/mailman/listinfo/speermint From john.elwell@siemens.com Wed Feb 4 00:41:07 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A12928C170 for ; Wed, 4 Feb 2009 00:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-EdYP-OJhCD for ; Wed, 4 Feb 2009 00:41:06 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 1E9EE28C14C for ; Wed, 4 Feb 2009 00:41:06 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KEJ0054W9FYTG@siemenscomms.co.uk> for speermint@ietf.org; Wed, 04 Feb 2009 08:40:46 +0000 (GMT) Date: Wed, 04 Feb 2009 08:40:43 +0000 From: "Elwell, John" In-reply-to: <01af01c9862c$02c863e0$08592ba0$@us> To: Richard Shockey , Daryl Malas , speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0017FB44F@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: quoted-printable Thread-Topic: [Speermint] Problem: SIP Interoperability between Peers Thread-Index: AcmGIlgRBjX9+QL7TDKFiJizRmNVqAACSOPQAB4avvA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <160DE07A1C4F8E4AA2715DEC577DA491B1B073@srvxchg3.cablelabs.com> <01af01c9862c$02c863e0$08592ba0$@us> Subject: Re: [Speermint] Problem: SIP Interoperability between Peers X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 08:41:07 -0000 Daryl, I would endorse what Richard says. In my opinion we are making great progress with SIPconnect 1.1, but of course the proof will be when we get it published (hopefully in the next few months) and when it gets adopted in the market. It seems the SP-SP problem could be addressed by a similar approach. John=20 > -----Original Message----- > From: speermint-bounces@ietf.org=20 > [mailto:speermint-bounces@ietf.org] On Behalf Of Richard Shockey > Sent: 03 February 2009 18:20 > To: 'Daryl Malas'; speermint@ietf.org > Subject: Re: [Speermint] Problem: SIP Interoperability between Peers >=20 > This is exactly what the SIPforum is trying to do with=20 > initiatives like > SIPit and SIPconnect. >=20 > I don't have much confidence that the IETF is the place to solve SIP > interoperability problems. >=20 > If there are lessons learned certainly they need to be=20 > reincorporated into > the relevant RFC's but IMHO the structure of the IETF does=20 > not lend itself > well to solving operational problems you describe. >=20 > > -----Original Message----- > > From: speermint-bounces@ietf.org=20 > [mailto:speermint-bounces@ietf.org] > > On Behalf Of Daryl Malas > > Sent: Tuesday, February 03, 2009 12:11 PM > > To: speermint@ietf.org > > Subject: [Speermint] Problem: SIP Interoperability between Peers > > =20 > > All, > > =20 > > I regularly hear the biggest problem facing SSPs=20 > attempting to peer is > > SIP interoperability. There are simply too many optional=20 > uses of SIP > > today. My questions are how do we solve this problem, and=20 > should it > > be > > solved in Speermint? In the past few months, I have spoke with > > different service providers, and each of them have their own > > *spreadsheet* describing what SIP extensions and variables you must > > conform to in order to peer with them. In addition to the other > > capabilities an SBC provides, it is also becoming a peer=20 > SIP profile > > manager. Operational teams are screaming they spend most of their > > time > > trying to figure out what profile to use for what peer. > > =20 > > How do we solve this problem? At Minneapolis, during the RAI open > > meeting, there was a discussion that the IETF does not support > > implementers with real problems. Here is a real problem=20 > plaguing the > > industry. How do we solve it? > > =20 > > Thoughts and feedback is appreciated. > > =20 > > Regards, > > =20 > > Daryl > > =20 > > =20 > > ---------------- > > Daryl Malas > > CableLabs > > (o) +1 303 661 3302 > > (f) +1 303 661 9199 > > mailto:d.malas@cablelabs.com > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint >=20 From D.Malas@cablelabs.com Wed Feb 4 08:02:32 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34B843A6A73 for ; Wed, 4 Feb 2009 08:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45MS3AUrCAkh for ; Wed, 4 Feb 2009 08:02:31 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 5705F3A6941 for ; Wed, 4 Feb 2009 08:02:31 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n14G2BO3029441; Wed, 4 Feb 2009 09:02:11 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 4 Feb 2009 09:02:11 -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: Wed, 4 Feb 2009 09:02:11 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491B1B082@srvxchg3.cablelabs.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0017FB44F@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Problem: SIP Interoperability between Peers Thread-Index: AcmGIlgRBjX9+QL7TDKFiJizRmNVqAACSOPQAB4avvAAD01V8A== References: <160DE07A1C4F8E4AA2715DEC577DA491B1B073@srvxchg3.cablelabs.com> <01af01c9862c$02c863e0$08592ba0$@us> <0D5F89FAC29E2C41B98A6A762007F5D0017FB44F@GBNTHT12009MSX.gb002.siemens.net> From: "Daryl Malas" To: "Elwell, John" , "Richard Shockey" , X-Approved: ondar Subject: Re: [Speermint] Problem: SIP Interoperability between Peers X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 16:02:32 -0000 John and Richard, I do not have a preference as to where the task is taken up. My biggest concern is that SSPs do not seem to be very involved in the SIPForum. How do we make sure there is the right level of visibility on this work in order to assure adoption across the industry? To some extent, I think this issue should go back to SIP or SIPPING. For a number of reasons, SIP has a huge menu of options. The issue facing any group on deciding what is important and what is not wrt to SIP has been a very challenging one. When is SIP 3.0 coming out again? While I joke, the interoperability issues of SIP are the one issue that seems to plague this protocol. Regards, Daryl ---------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Wednesday, February 04, 2009 1:41 AM > To: Richard Shockey; Daryl Malas; speermint@ietf.org > Subject: RE: [Speermint] Problem: SIP Interoperability between Peers >=20 > Daryl, >=20 > I would endorse what Richard says. In my opinion we are=20 > making great progress with SIPconnect 1.1, but of course the=20 > proof will be when we get it published (hopefully in the next=20 > few months) and when it gets adopted in the market. It seems=20 > the SP-SP problem could be addressed by a similar approach. >=20 > John=20 >=20 > > -----Original Message----- > > From: speermint-bounces@ietf.org > > [mailto:speermint-bounces@ietf.org] On Behalf Of Richard Shockey > > Sent: 03 February 2009 18:20 > > To: 'Daryl Malas'; speermint@ietf.org > > Subject: Re: [Speermint] Problem: SIP Interoperability between Peers > >=20 > > This is exactly what the SIPforum is trying to do with initiatives=20 > > like SIPit and SIPconnect. > >=20 > > I don't have much confidence that the IETF is the place to=20 > solve SIP=20 > > interoperability problems. > >=20 > > If there are lessons learned certainly they need to be=20 > reincorporated=20 > > into the relevant RFC's but IMHO the structure of the IETF does not=20 > > lend itself well to solving operational problems you describe. > >=20 > > > -----Original Message----- > > > From: speermint-bounces@ietf.org > > [mailto:speermint-bounces@ietf.org] > > > On Behalf Of Daryl Malas > > > Sent: Tuesday, February 03, 2009 12:11 PM > > > To: speermint@ietf.org > > > Subject: [Speermint] Problem: SIP Interoperability between Peers > > > =20 > > > All, > > > =20 > > > I regularly hear the biggest problem facing SSPs > > attempting to peer is > > > SIP interoperability. There are simply too many optional > > uses of SIP > > > today. My questions are how do we solve this problem, and > > should it > > > be > > > solved in Speermint? In the past few months, I have spoke with =20 > > > different service providers, and each of them have their own > > > *spreadsheet* describing what SIP extensions and=20 > variables you must =20 > > > conform to in order to peer with them. In addition to the other =20 > > > capabilities an SBC provides, it is also becoming a peer > > SIP profile > > > manager. Operational teams are screaming they spend=20 > most of their =20 > > > time trying to figure out what profile to use for what peer. > > > =20 > > > How do we solve this problem? At Minneapolis, during=20 > the RAI open =20 > > > meeting, there was a discussion that the IETF does not support =20 > > > implementers with real problems. Here is a real problem > > plaguing the > > > industry. How do we solve it? > > > =20 > > > Thoughts and feedback is appreciated. > > > =20 > > > Regards, > > > =20 > > > Daryl > > > =20 > > > =20 > > > ---------------- > > > Daryl Malas > > > CableLabs > > > (o) +1 303 661 3302 > > > (f) +1 303 661 9199 > > > mailto:d.malas@cablelabs.com > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www.ietf.org/mailman/listinfo/speermint > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www.ietf.org/mailman/listinfo/speermint > >=20 >=20 From richard@shockey.us Wed Feb 4 09:29:20 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5943A6B42 for ; Wed, 4 Feb 2009 09:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iswTndIfqdQV for ; Wed, 4 Feb 2009 09:29:19 -0800 (PST) Received: from outbound-mail-21.bluehost.com (outbound-mail-21.bluehost.com [69.89.21.16]) by core3.amsl.com (Postfix) with SMTP id 98AEC28C108 for ; Wed, 4 Feb 2009 09:29:19 -0800 (PST) Received: (qmail 21771 invoked by uid 0); 4 Feb 2009 17:28:47 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy2.bluehost.com with SMTP; 4 Feb 2009 17:28:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=cm1aWnUP2zgR/cExi+EXQXszKZYTbLQfgCW88fmtyu/EwkBIToGH6H56yiknL33y/FU/1nnDGHb4t3s+b+WE6Mc51dNY9+5C9FIHFliZwXydYroxFRxY8NnajmeJz4Tq; Received: from pni-63-239-16-253.prioritynetworks.net ([63.239.16.253] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LUlYZ-00061f-Sv; Wed, 04 Feb 2009 10:29:00 -0700 From: "Richard Shockey" To: "'Daryl Malas'" , "'Elwell, John'" , References: <160DE07A1C4F8E4AA2715DEC577DA491B1B073@srvxchg3.cablelabs.com> <01af01c9862c$02c863e0$08592ba0$@us> <0D5F89FAC29E2C41B98A6A762007F5D0017FB44F@GBNTHT12009MSX.gb002.siemens.net> <160DE07A1C4F8E4AA2715DEC577DA491B1B082@srvxchg3.cablelabs.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA491B1B082@srvxchg3.cablelabs.com> Date: Wed, 4 Feb 2009 12:28:57 -0500 Message-ID: <010b01c986ee$10082f00$30188d00$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmGIlgRBjX9+QL7TDKFiJizRmNVqAACSOPQAB4avvAAD01V8AABuRSA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 63.239.16.253 authed with richard+shockey.us} Subject: Re: [Speermint] Problem: SIP Interoperability between Peers X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 17:29:20 -0000 > -----Original Message----- > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > Sent: Wednesday, February 04, 2009 11:02 AM > To: Elwell, John; Richard Shockey; speermint@ietf.org > Subject: RE: [Speermint] Problem: SIP Interoperability between Peers > > John and Richard, > > I do not have a preference as to where the task is taken up. My > biggest > concern is that SSPs do not seem to be very involved in the SIPForum. Well if I recall CableLabs is a member of the SIPforum :-) as are several MSO's. http://www.sipforum.org/component/option,com_fullmember/Itemid,195/ Your point however is well taken however. Speaking as a Member of the BOD of the SIPforum, we have been lacking in gathering sufficient SSP support, but that is changing. SIPit is still the principal mechanism to test SIP interoperability but SSP have not been strong participants there either, nor have they used their 'power of the wallet' to force their vendors to comply with many of the relevant and important RFC's that would ease the interoperability issues. There has been a everlasting discussion within the SIPforum on formalized SIP compliance testing ( much like ASCII in RFC's) with no consensus among the participant members. Cost to the vendor community is the core problem. > How do we make sure there is the right level of visibility on this > work > in order to assure adoption across the industry? > > To some extent, I think this issue should go back to SIP or SIPPING. > For a number of reasons, SIP has a huge menu of options. The issue > facing any group on deciding what is important and what is not wrt to > SIP has been a very challenging one. Again I would strongly recommend against that. Its pretty obvious that the RAI area in general and the core SIP WG are grossly overloaded. The current IETF structure does not lend it to solving interoperability or operations related issues. The IETF does not like "profiles". Been there done that. Discussions like these need very different formats and venues than is traditional in the IETF. IMHO need real face to face meetings lasting over several days and many more specialized Design teams to draft and debate documents. Not a scatter shot of 2 hour meetings we have in the IETF. Perhaps something more like how CableLabs operates :-) Perhaps its time again for one of our RAI SIPforum Lunch meetings in SF or a long 2 hour min RAI general area meeting where this could be discussed. Daryl, you were right to raise the issue and indeed there is a problem. > > When is SIP 3.0 coming out again? While I joke, the interoperability > issues of SIP are the one issue that seems to plague this protocol. > > Regards, > > Daryl > > > ---------------- > Daryl Malas > CableLabs > (o) +1 303 661 3302 > (f) +1 303 661 9199 > mailto:d.malas@cablelabs.com > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Wednesday, February 04, 2009 1:41 AM > > To: Richard Shockey; Daryl Malas; speermint@ietf.org > > Subject: RE: [Speermint] Problem: SIP Interoperability between Peers > > > > Daryl, > > > > I would endorse what Richard says. In my opinion we are > > making great progress with SIPconnect 1.1, but of course the > > proof will be when we get it published (hopefully in the next > > few months) and when it gets adopted in the market. It seems > > the SP-SP problem could be addressed by a similar approach. > > > > John > > > > > -----Original Message----- > > > From: speermint-bounces@ietf.org > > > [mailto:speermint-bounces@ietf.org] On Behalf Of Richard Shockey > > > Sent: 03 February 2009 18:20 > > > To: 'Daryl Malas'; speermint@ietf.org > > > Subject: Re: [Speermint] Problem: SIP Interoperability between > Peers > > > > > > This is exactly what the SIPforum is trying to do with initiatives > > > like SIPit and SIPconnect. > > > > > > I don't have much confidence that the IETF is the place to > > solve SIP > > > interoperability problems. > > > > > > If there are lessons learned certainly they need to be > > reincorporated > > > into the relevant RFC's but IMHO the structure of the IETF does > not > > > lend itself well to solving operational problems you describe. > > > > > > > -----Original Message----- > > > > From: speermint-bounces@ietf.org > > > [mailto:speermint-bounces@ietf.org] > > > > On Behalf Of Daryl Malas > > > > Sent: Tuesday, February 03, 2009 12:11 PM > > > > To: speermint@ietf.org > > > > Subject: [Speermint] Problem: SIP Interoperability between > Peers > > > > > > > > All, > > > > > > > > I regularly hear the biggest problem facing SSPs > > > attempting to peer is > > > > SIP interoperability. There are simply too many optional > > > uses of SIP > > > > today. My questions are how do we solve this problem, and > > > should it > > > > be > > > > solved in Speermint? In the past few months, I have spoke with > > > > different service providers, and each of them have their own > > > > *spreadsheet* describing what SIP extensions and > > variables you must > > > > conform to in order to peer with them. In addition to the other > > > > capabilities an SBC provides, it is also becoming a peer > > > SIP profile > > > > manager. Operational teams are screaming they spend > > most of their > > > > time trying to figure out what profile to use for what peer. > > > > > > > > How do we solve this problem? At Minneapolis, during > > the RAI open > > > > meeting, there was a discussion that the IETF does not support > > > > implementers with real problems. Here is a real problem > > > plaguing the > > > > industry. How do we solve it? > > > > > > > > Thoughts and feedback is appreciated. > > > > > > > > Regards, > > > > > > > > Daryl > > > > > > > > > > > > ---------------- > > > > Daryl Malas > > > > CableLabs > > > > (o) +1 303 661 3302 > > > > (f) +1 303 661 9199 > > > > mailto:d.malas@cablelabs.com > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www.ietf.org/mailman/listinfo/speermint > > > > > From JMCE@nortel.com Wed Feb 4 16:49:20 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1900C3A6A7B for ; Wed, 4 Feb 2009 16:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hizIFwFq1Q83 for ; Wed, 4 Feb 2009 16:49:18 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 83DF63A6864 for ; Wed, 4 Feb 2009 16:49:18 -0800 (PST) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n150mr206323; Thu, 5 Feb 2009 00:48:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Feb 2009 19:48:34 -0500 Message-ID: In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA491B1B072@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Meeting minutes from IETF 73 Speermint session (Arch Draft Review) Thread-Index: AclheIM6vfcHtNx+S0q4AzvQWgZd6QeqtZlgAX4X54AAQTDaoA== References: <160DE07A1C4F8E4AA2715DEC577DA491B1AF74@srvxchg3.cablelabs.com> <160DE07A1C4F8E4AA2715DEC577DA491B1B072@srvxchg3.cablelabs.com> From: "James McEachern" To: "Daryl Malas" , Subject: Re: [Speermint] Meeting minutes from IETF 73 Speermint session (Arch Draft Review) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 00:49:20 -0000 Daryl, Your comments generally look good to me. Now that I know someone is listening, I will continue my review over the next few days. Based on your comments, I will assume the following for the remainder of my review: - I will use Originating SSP rather than Initiating SSP - I will assume we are using SSP rather than peer - I will try to use only Target SSP =20 - I will only use UA All your other specific suggestions are fine with me. Jim McEachern T:+1 613 763-3419 M:+1 613 853-0176 -----Original Message----- From: Daryl Malas [mailto:D.Malas@cablelabs.com]=20 Sent: Tuesday, February 03, 2009 12:02 PM To: speermint@ietf.org Cc: McEachern, James (CAR:AR00) Subject: [Speermint] RE: Meeting minutes from IETF 73 Speermint session (Arch Draft Review)=20 Jim, Thanks for the review. Comments in-line... ---------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com =20 > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com]=20 > Sent: Monday, January 26, 2009 8:28 PM > To: speermint@ietf.org > Cc: Daryl Malas > Subject: RE: [Speermint] Meeting minutes from IETF 73=20 > Speermint session >=20 > Daryl, > I volunteered to do a detailed review of the SPEERMINT=20 > Peering Architecture draft, so in the spirit of "better late=20 > than never" I will begin sending my comments to the list for=20 > consideration. My comments will be in several emails over=20 > the rest of the week... >=20 > First a nit: >=20 > 1. References. It appears that the references (at least in the > introduction) are off by one. SPEERMINT Requirements is shown=20 > as [13], but is actually [14] while Terminology is shown as=20 > [12] but is [13] in the reference section. I didn't go=20 > further, but please check to ensure references are correct. >=20 > Next, a couple of general comments related to consistency: >=20 > 2. Originating vs. Initiating SSP: Sometimes we use one,=20 > sometimes the other. In this case I'm pretty sure everyone=20 > agrees on what we mean, so let's pick one or the other and=20 > use it throughout. (I'm kind of leaning toward "initiating"=20 > but cold live with either.) I personally prefer "originating". >=20 > 3. SSP vs. peer: Most of the time we use "SSP", but in some=20 > sections we begin to use "peer". I think the term "peer" is=20 > relative, and leaves us open to all sorts of confusion, while=20 > the SSP is clear. My preference is to use SSP throughout, and=20 > I will assume that in any remaining comments. I agree with using SSP. >=20 > 4. Target vs. Terminating: I'll save that one for later, as=20 > I don't believe we all are in agreement just yet on that=20 > particular one. I think Jon made valid points at the last WG meeting that 'Target' is a better term, since a call may be transferred or re-targeted later. I suggest we use 'Target'. >=20 > Now on to section specific comments: >=20 > 5. Section 2. Network Context, final paragraph says: > " The members of a federation may jointly use a set of functions such=20 > as location function..." > Comment: The terminology draft defines LUF and LRF, but does=20 > not define "location function". Similarly, this draft also=20 > discusses LUF and LRF, but not "location function".=20 > Recommended Solution: Change "location function" to "Look-Up=20 > Function, Location Routing Function,". While we are at it,=20 > we probably should capitalize the other functions the way we=20 > have done in the Terminology draft. >=20 > 6. Section 3. Procedures, > Bullet 5 states " the determination of the UAS,". > Comment: This is unclear to me. I think we are determining=20 > something about the UAS, perhaps the location of the UAS. If=20 > this is correct, then we should change it to say this. I agree this is a little too ambiguous. I recommend we change it to "determine the location of the target UA". On a separate note, there has been previous discussion on the use of UAC or UAS versus simply UA. I believe in those previous discussions it was determined the preference was to simply refer to either as a 'UA'. This is a minor nit, but believe it will make the draft more consistent with other similar IETF works. >=20 > 7. Section 3. Procedures > This section might be strengthened by changing to the active=20 > voice. For example, bullet 6 would be a lot clearer (to me=20 > at least) if we just said "establish the session". However,=20 > I'm ok with group consensus on this one. I am okay with either. To me, they mean the same thing. >=20 > 8. Section 3. Procedures:=20 > The final paragraph states that "In the case the target SSP=20 > is different from the terminating SSP ...". =20 > Comment: If we are going to open this can of worms (and I=20 > fear we must) then it is crucial that we clearly define what=20 > terminating and target SSP mean, and use them with absolute=20 > consistency throughout the document. If there was a=20 > consensus on the list after Minneapolis, I missed it; to me=20 > it sounded like two solitudes.=20 >=20 > Since I don't want to just raise issues, I am going to=20 > propose what I think makes sense here, and let people react. > Target SSP =3D the SSP we are currently trying to reach. If=20 > the session is "retargeted" then it is given a new target SSP=20 > (unless of course the new target is in the same SSP). This=20 > seems consistent with general usage. > Terminating SSP =3D the SSP where the session actually does terminate. = I am glad you brought this issue up. My preference is to simply scrap "Terminating SSP" altogether. IMO, it is to difficult for it to be consistent. If we must use it, I prefer we refer to "Terminating SSP" only if the session actually *ends* there. In this case, I mean a successful "BYE" dialog occurs. All other references should refer to "Target SSP". >=20 > The remainder of my comments assume these definitions. =20 >=20 > In the spirit of making concrete suggestions, I would suggest=20 > that the final paragraph of Section 3 be modified as follows: >=20 > Current text: > "In the case the target SSP is different from the terminating SSP it=20 > would repeat steps 1-4. This is reflected in Figure 2 that=20 > shows the=20 > target SSP with its own peering functions." >=20 > Change to: > " In the case the initial target SSP is different from the=20 > terminating SSP it would repeat steps 1-4. This is reflected=20 > in Figure 2 that shows the=20 > target SSP with its own peering functions." Keeping in the spirit of removing Terminating SSP, I would suggest we change it to "In the case the target SSP changes during the session it would repeat steps 1-4. This is reflected in Figure 2 that shows the target SSP with its own peering functions." >=20 > 9. Section 5.1. Originating SSP Procedures We use=20 > "originating SSP" in the section heading, but "initiating=20 > SSP" in the body. >=20 > 10. Section 5.1.1. The Look-Up Function > Currently states "Purpose is to determine the SF of the=20 > target domain ..." > Comment: Earlier in this document, and in the Terminology=20 > draft, we state that the LUF determines the target domain -=20 > not the SF of the target domain. In addition, we later state=20 > that the LRF determines the location of the SF. Therefore I=20 > believe we should change as follows: > Current text: > "Purpose is to determine the SF of the target domain ..." >=20 > Change to: > "Purpose is to determine the target domain ..." >=20 > 11. Section 5.1.1. The Look-Up Function > Currently states "...optionally develop Session Establishment=20 > Data (SED) [12]." =20 > Comment: I believe this is only true when the target address=20 > is in the same domain as the initiating SSP, otherwise the=20 > LRF develops the SED. > Therefore I suggest we change as follows: > Current text: > "... optionally develop Session Establishment Data (SED) [12]. " >=20 > Change to: > "... if the target address is in the same administrative=20 > domain as the initiating SSP, optionally develop Session=20 > Establishment Data (SED) [12]. " >=20 > 12. Section 5.1.1.1 Target address analysis. > Second paragraph states that > "... the initiating SSP resolves the call routing data by=20 > using the Location Routing Function (LRF)" >=20 > I suggest we recognize the step where the LUF first=20 > determines the target domain, by changing the above to read: > "... the initiating SSP first determines the target domain,=20 > and then resolves the call routing data by using the Location=20 > Routing Function (LRF)" >=20 > 13. Section 5.1.1.1 Target address analysis. > The third paragraph begins with "For example...". This confuses me. > The previous paragraph ends by saying what the LRF does, but=20 > then immediately gives examples of how the LUF works - at=20 > least I think this is what it is providing. At the very=20 > least we need to somehow qualify the examples, though to be=20 > honest I'd be happy if we just deleted the third and fourth=20 > paragraphs.. >=20 > ---- end of first set of comments ---- >=20 > More comments to follow in a day or so. >=20 >=20 > Jim McEachern > T:+1 613 763-3419 > M:+1 613 853-0176 >=20 >=20 > -----Original Message----- > From: speermint-bounces@ietf.org=20 > [mailto:speermint-bounces@ietf.org] On Behalf Of Daryl Malas > Sent: Thursday, December 18, 2008 8:24 PM > To: speermint@ietf.org > Cc: Alexander Mayrhofer; Livingood,Jason > Subject: [Speermint] Meeting minutes from IETF 73 Speermint session >=20 > All, >=20 > The meeting minutes for the IETF 73 Speermint session can be=20 > found here: >=20 > http://www.ietf.org/proceedings/08nov/minutes/speermint.txt >=20 > Please check the notes, as some of you volunteered to do=20 > things...and, some by the end of the year (2008). Also,=20 > there were several issues that were going to be further=20 > discussed on the mailing list. Those of you presenting on=20 > these topics, please start the threads. >=20 > If you have questions, concerns, or feel like something=20 > important was left out let us know. >=20 > Thank you for your participation in Minneapolis. >=20 > Regards, >=20 > Daryl >=20 > Speermint co-Chair >=20 >=20 > ---------------- > Daryl Malas > CableLabs > (o) +1 303 661 3302 > (f) +1 303 661 9199 > mailto:d.malas@cablelabs.com > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint >=20 From JMCE@nortel.com Wed Feb 4 19:25:07 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91ED3A6895 for ; Wed, 4 Feb 2009 19:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDgKuZPRukCh for ; Wed, 4 Feb 2009 19:25:06 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5A5363A6B67 for ; Wed, 4 Feb 2009 19:25:06 -0800 (PST) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n153OgF19280; Thu, 5 Feb 2009 03:24:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Feb 2009 22:24:20 -0500 Message-ID: In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA491B1B072@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Meeting minutes from IETF 73 Speermint session (Arch Draft Review) Thread-Index: AclheIM6vfcHtNx+S0q4AzvQWgZd6QeqtZlgAX4X54AAQ/+AoA== References: <160DE07A1C4F8E4AA2715DEC577DA491B1AF74@srvxchg3.cablelabs.com> <160DE07A1C4F8E4AA2715DEC577DA491B1B072@srvxchg3.cablelabs.com> From: "James McEachern" To: "Daryl Malas" , Subject: Re: [Speermint] Meeting minutes from IETF 73 Speermint session (Arch Draft Review) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 03:25:08 -0000 Architecture Draft Review - Part 2 This email continues the detailed review of the Architecture Draft Review from the point where I left off on my first email. 1. Section 5.1.1.2. User ENUM Lookup This section refers to the "peer" in several places. This should be changed to "SSP" 2. Section 5.1.1.2 User ENUM Lookup This section states that "... the initiating peer [change to "originating SSP] consults the public "User ENUM" ..." I fully expect to be overruled here, but I strongly believe that the query to User ENUM should be subject to local policy, one important aspect of which would be the explicit preferences of the originating UA. I would prefer to change "consults" to "may consult" - but as I say, I am resigned to being overruled, if not flamed.=20 3. Section 5.1.1.3. Infrastructure ENUM Lookup Change "initiating peer" to "originating SSP" and "peer" to "SSP" (several times). Change "carrier ENUM" to "Infrastructure ENUM". 4. Section 5.1.2. Location Routing Function (LRF) Change "Initiating SSP" to "Originating SSP". This section also states that the LRF analyses the target address and discovers the next hop... I believe that the analysis includes the target domain that was identified by the LUF. Therefore, with these two changes, I suggest this section should read: "The LRF of the Originating SSP analyses target address and target domain, identified by the LUF, and discovers the next hop signaling function (SF) in the peering relationship. ..." 5. Section 5.1.2.1. Routing Table I have several issues with this section. =20 First of all, I think it should be moved to after 5.1.2.2 SIP DNS Resolution, since you should only be performing PSTN breakout if SIP DNS resolution fails. Change "initiating" to "Originating", and "peer" to "SSP" throughout. I believe that the third paragraph should be deleted. The first paragraph states that this section applies when you "cannot discover the carrier-of-record or ... cannot reach it via SIP peering" and then this paragraph goes on to say you should forward to the target SSP using sip peering. Just doesn't make sense. The text beginning with the "Note" does seems confusing to me. How about starting a new paragraph at that point, and use the following text (through to the new end of this section). "Note that the Originating SSP may still forward the call to a PSTN gateway in another SSP by prior arrangement using the routing table. If so, the Originating SSP may rewrite the Request-URI to address the PSTN gateway and may forward the request to that SSP using SIP procedures." 6. Section 5.1.2.2 SIP DNS Resolution As said earlier, this should go before the Routing Table section. This section also introduces a new term, the "receiving peer". This should be changed to "Target SSP". 7. Section 5.1.2.3 SIP Redirect Server I am not at all certain this section adds value. I would delete it. 8. Section 5.1.3 The Signaling Function The first paragraph states that the SF can optionally perform termination and re-initiation of a call, but the second paragraph states that this is performed by the SBE. Which is it? The third paragraph also says the SF can process SDP payloads, which makes it a B2BUA. As I understand it, a B2BUA includes an SF (two actually) but an SF does not include a B2BUA. I think the problem is that this section is really describing the SBE, which includes one or more signaling functions. Calling it the SF just confuses the issue - or at least it confuses me. Why not just call a spade a spade, and write this section as the SBE that can include signaling function, modify SDP, etc. 9. Section 5.1.3.1.1 TLS connection This section states that "the initiating [should be "Originating"] SSP will open ... TLS connection". I would prefer to change "will" to "can" since there are circumstances where it is permissible to use IPSec rather than TLS. 10. Section 5.1.3.1.3 Co-Location Says that messages "would" be sent as clear text. I think it would be better to say they "could" be sent as clear text. 11. Sections 5.1.3.2 and 5.1.3.2.1 Change "peer" to "SSP" - in several places. ---- end of second comments email ----- =20 Jim McEachern T:+1 613 763-3419 M:+1 613 853-0176 From john.elwell@siemens.com Thu Feb 5 06:03:54 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94E3028C1A2 for ; Thu, 5 Feb 2009 06:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huYhROQcm1Iu for ; Thu, 5 Feb 2009 06:03:53 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 2DC933A6927 for ; Thu, 5 Feb 2009 06:03:53 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KEL00HCDJ1WI7@siemenscomms.co.uk> for speermint@ietf.org; Thu, 05 Feb 2009 14:03:32 +0000 (GMT) Date: Thu, 05 Feb 2009 14:03:31 +0000 From: "Elwell, John" In-reply-to: <010b01c986ee$10082f00$30188d00$@us> To: Richard Shockey , Daryl Malas , speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00182CF73@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: quoted-printable Thread-Topic: [Speermint] Problem: SIP Interoperability between Peers thread-index: AcmGIlgRBjX9+QL7TDKFiJizRmNVqAACSOPQAB4avvAAD01V8AABuRSAACw5gLA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <160DE07A1C4F8E4AA2715DEC577DA491B1B073@srvxchg3.cablelabs.com> <01af01c9862c$02c863e0$08592ba0$@us> <0D5F89FAC29E2C41B98A6A762007F5D0017FB44F@GBNTHT12009MSX.gb002.siemens.net> <160DE07A1C4F8E4AA2715DEC577DA491B1B082@srvxchg3.cablelabs.com> <010b01c986ee$10082f00$30188d00$@us> Subject: Re: [Speermint] Problem: SIP Interoperability between Peers X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 14:03:54 -0000 Daryl, Have you seen Jon Peterson's proposal on the RAI mailing list for restructuring (message posted yesterday)? It might be worth making your concerns known on that thread. However, I still tend to agree that the SIP Forum would be a better venue. John=20 > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us]=20 > Sent: 04 February 2009 17:29 > To: 'Daryl Malas'; Elwell, John; speermint@ietf.org > Subject: RE: [Speermint] Problem: SIP Interoperability between Peers >=20 > > -----Original Message----- > > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > Sent: Wednesday, February 04, 2009 11:02 AM > > To: Elwell, John; Richard Shockey; speermint@ietf.org > > Subject: RE: [Speermint] Problem: SIP Interoperability=20 > between Peers > > =20 > > John and Richard, > > =20 > > I do not have a preference as to where the task is taken up. My > > biggest > > concern is that SSPs do not seem to be very involved in=20 > the SIPForum. >=20 > Well if I recall CableLabs is a member of the SIPforum :-)=20 > as are several > MSO's. >=20 > http://www.sipforum.org/component/option,com_fullmember/Itemid,195/ >=20 > Your point however is well taken however. Speaking as a=20 > Member of the BOD of > the SIPforum, we have been lacking in gathering sufficient=20 > SSP support, but > that is changing. >=20 > SIPit is still the principal mechanism to test SIP=20 > interoperability but SSP > have not been strong participants there either, nor have they=20 > used their > 'power of the wallet' to force their vendors to comply with=20 > many of the > relevant and important RFC's that would ease the=20 > interoperability issues. > There has been a everlasting discussion within the SIPforum=20 > on formalized > SIP compliance testing ( much like ASCII in RFC's) with no=20 > consensus among > the participant members. Cost to the vendor community is the=20 > core problem. >=20 > > How do we make sure there is the right level of visibility on this > > work > > in order to assure adoption across the industry? > > =20 > > To some extent, I think this issue should go back to SIP=20 > or SIPPING. > > For a number of reasons, SIP has a huge menu of options. The issue > > facing any group on deciding what is important and what is=20 > not wrt to > > SIP has been a very challenging one. >=20 > Again I would strongly recommend against that. Its pretty=20 > obvious that the > RAI area in general and the core SIP WG are grossly overloaded. =20 >=20 > The current IETF structure does not lend it to solving=20 > interoperability or > operations related issues. The IETF does not like "profiles".=20 > Been there > done that. >=20 > Discussions like these need very different formats and venues than is > traditional in the IETF. IMHO need real face to face=20 > meetings lasting over > several days and many more specialized Design teams to draft=20 > and debate > documents. Not a scatter shot of 2 hour meetings we have in the IETF. > Perhaps something more like how CableLabs operates :-)=20 >=20 > Perhaps its time again for one of our RAI SIPforum Lunch=20 > meetings in SF or a > long 2 hour min RAI general area meeting where this could be=20 > discussed. >=20 > Daryl, you were right to raise the issue and indeed there is=20 > a problem. >=20 > > =20 > > When is SIP 3.0 coming out again? While I joke, the=20 > interoperability > > issues of SIP are the one issue that seems to plague this protocol. > > =20 > > Regards, > > =20 > > Daryl > > =20 > > =20 > > ---------------- > > Daryl Malas > > CableLabs > > (o) +1 303 661 3302 > > (f) +1 303 661 9199 > > mailto:d.malas@cablelabs.com > > =20 > > =20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: Wednesday, February 04, 2009 1:41 AM > > > To: Richard Shockey; Daryl Malas; speermint@ietf.org > > > Subject: RE: [Speermint] Problem: SIP Interoperability=20 > between Peers > > > > > > Daryl, > > > > > > I would endorse what Richard says. In my opinion we are > > > making great progress with SIPconnect 1.1, but of course the > > > proof will be when we get it published (hopefully in the next > > > few months) and when it gets adopted in the market. It seems > > > the SP-SP problem could be addressed by a similar approach. > > > > > > John > > > > > > > -----Original Message----- > > > > From: speermint-bounces@ietf.org > > > > [mailto:speermint-bounces@ietf.org] On Behalf Of=20 > Richard Shockey > > > > Sent: 03 February 2009 18:20 > > > > To: 'Daryl Malas'; speermint@ietf.org > > > > Subject: Re: [Speermint] Problem: SIP Interoperability between > > Peers > > > > > > > > This is exactly what the SIPforum is trying to do with=20 > initiatives > > > > like SIPit and SIPconnect. > > > > > > > > I don't have much confidence that the IETF is the place to > > > solve SIP > > > > interoperability problems. > > > > > > > > If there are lessons learned certainly they need to be > > > reincorporated > > > > into the relevant RFC's but IMHO the structure of the IETF does > > not > > > > lend itself well to solving operational problems you describe. > > > > > > > > > -----Original Message----- > > > > > From: speermint-bounces@ietf.org > > > > [mailto:speermint-bounces@ietf.org] > > > > > On Behalf Of Daryl Malas > > > > > Sent: Tuesday, February 03, 2009 12:11 PM > > > > > To: speermint@ietf.org > > > > > Subject: [Speermint] Problem: SIP Interoperability between > > Peers > > > > > > > > > > All, > > > > > > > > > > I regularly hear the biggest problem facing SSPs > > > > attempting to peer is > > > > > SIP interoperability. There are simply too many optional > > > > uses of SIP > > > > > today. My questions are how do we solve this problem, and > > > > should it > > > > > be > > > > > solved in Speermint? In the past few months, I=20 > have spoke with > > > > > different service providers, and each of them have their own > > > > > *spreadsheet* describing what SIP extensions and > > > variables you must > > > > > conform to in order to peer with them. In addition=20 > to the other > > > > > capabilities an SBC provides, it is also becoming a peer > > > > SIP profile > > > > > manager. Operational teams are screaming they spend > > > most of their > > > > > time trying to figure out what profile to use for what peer. > > > > > > > > > > How do we solve this problem? At Minneapolis, during > > > the RAI open > > > > > meeting, there was a discussion that the IETF does=20 > not support > > > > > implementers with real problems. Here is a real problem > > > > plaguing the > > > > > industry. How do we solve it? > > > > > > > > > > Thoughts and feedback is appreciated. > > > > > > > > > > Regards, > > > > > > > > > > Daryl > > > > > > > > > > > > > > > ---------------- > > > > > Daryl Malas > > > > > CableLabs > > > > > (o) +1 303 661 3302 > > > > > (f) +1 303 661 9199 > > > > > mailto:d.malas@cablelabs.com > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/speermint > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www.ietf.org/mailman/listinfo/speermint > > > > > > > >=20 >=20 From D.Malas@cablelabs.com Fri Feb 6 16:15:11 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FDEF3A6B3F for ; Fri, 6 Feb 2009 16:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.43 X-Spam-Level: X-Spam-Status: No, score=-0.43 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aX5IMKCxPzZw for ; Fri, 6 Feb 2009 16:15:09 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 291783A6A30 for ; Fri, 6 Feb 2009 16:15:08 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n170F8bR012376; Fri, 6 Feb 2009 17:15:09 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 6 Feb 2009 17:15:09 -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 Feb 2009 17:15:08 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491B1B0BE@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Meeting minutes from IETF 73 Speermint session (Arch Draft Review) Thread-Index: AclheIM6vfcHtNx+S0q4AzvQWgZd6QeqtZlgAX4X54AAQ/+AoABh4Nrw References: <160DE07A1C4F8E4AA2715DEC577DA491B1AF74@srvxchg3.cablelabs.com> <160DE07A1C4F8E4AA2715DEC577DA491B1B072@srvxchg3.cablelabs.com> From: "Daryl Malas" To: "James McEachern" , X-Approved: ondar Subject: Re: [Speermint] Meeting minutes from IETF 73 Speermint session (Arch Draft Review) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 00:15:11 -0000 Jim et. al., Comments in-line... ---------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com =20 > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com]=20 > Sent: Wednesday, February 04, 2009 8:24 PM > To: Daryl Malas; speermint@ietf.org > Subject: RE: [Speermint] RE: Meeting minutes from IETF 73=20 > Speermint session (Arch Draft Review)=20 >=20 > Architecture Draft Review - Part 2 >=20 > This email continues the detailed review of the Architecture=20 > Draft Review from the point where I left off on my first email. >=20 > 1. Section 5.1.1.2. User ENUM Lookup > This section refers to the "peer" in several places. This=20 > should be changed to "SSP" >=20 > 2. Section 5.1.1.2 User ENUM Lookup > This section states that "... the initiating peer [change to=20 > "originating SSP] consults the public "User ENUM" ..." >=20 > I fully expect to be overruled here, but I strongly believe=20 > that the query to User ENUM should be subject to local=20 > policy, one important aspect of which would be the explicit=20 > preferences of the originating UA. > I would prefer to change "consults" to "may consult" - but as=20 > I say, I am resigned to being overruled, if not flamed.=20 First, I think "User ENUM" should be changed to "End User ENUM" as described in RFC 5067. I think this is the ENUM model being described here. Second, regarding your question, is there any reason why an SSP could not participate in a peering relationship using End User, Infrastructure, or Private ENUM models? If this is the case, I think we should either add a 3rd section for Private ENUM or indicate one of the 3 models may be used in 1 section. Also, should *Next* be at the beginning of Section 5.1.1.3? I think an SSP could simply query an Infrastructure ENUM server and derive the steps to reach the subscriber at the target SSP peer. I do not think it requires a query to each. I may be confused by the varying ENUM models, though. >=20 > 3. Section 5.1.1.3. Infrastructure ENUM Lookup Change=20 > "initiating peer" to "originating SSP" and "peer" to "SSP" > (several times). > Change "carrier ENUM" to "Infrastructure ENUM". >=20 > 4. Section 5.1.2. Location Routing Function (LRF) Change=20 > "Initiating SSP" to "Originating SSP". >=20 > This section also states that the LRF analyses the target=20 > address and discovers the next hop... I believe that the=20 > analysis includes the target domain that was identified by=20 > the LUF. Therefore, with these two changes, I suggest this=20 > section should read: > "The LRF of the Originating SSP analyses target address and=20 > target domain, identified by the LUF, and discovers the next=20 > hop signaling function (SF) in the peering relationship. ..." >=20 > 5. Section 5.1.2.1. Routing Table > I have several issues with this section. =20 > First of all, I think it should be moved to after 5.1.2.2 SIP=20 > DNS Resolution, since you should only be performing PSTN=20 > breakout if SIP DNS resolution fails. > Change "initiating" to "Originating", and "peer" to "SSP" throughout. >=20 > I believe that the third paragraph should be deleted. The=20 > first paragraph states that this section applies when you=20 > "cannot discover the carrier-of-record or ... cannot reach it=20 > via SIP peering" and then this paragraph goes on to say you=20 > should forward to the target SSP using sip peering. Just=20 > doesn't make sense. >=20 > The text beginning with the "Note" does seems confusing to=20 > me. How about starting a new paragraph at that point, and=20 > use the following text (through to the new end of this section). > "Note that the Originating SSP may still forward the call to=20 > a PSTN gateway in another SSP by prior arrangement using the=20 > routing table. If so, the Originating SSP may rewrite the=20 > Request-URI to address the PSTN gateway and may forward the=20 > request to that SSP using SIP procedures." >=20 > 6. Section 5.1.2.2 SIP DNS Resolution > As said earlier, this should go before the Routing Table section. > This section also introduces a new term, the "receiving=20 > peer". This should be changed to "Target SSP". >=20 > 7. Section 5.1.2.3 SIP Redirect Server > I am not at all certain this section adds value. I would delete it. I think the reason why this is in here is that a SIP Redirect is a very viable alternative to ENUM. One of the challenges this and several Speermint documents face is placing too much emphasis on the use of ENUM in peering. While I believe this is a very efficient way for SSPs to peer, not all SSPs are ready or plan to utilize ENUM. What is a better recommendation for documenting a very valid approach to peering simply by using the constructs in SIP? >=20 > 8. Section 5.1.3 The Signaling Function > The first paragraph states that the SF can optionally perform=20 > termination and re-initiation of a call, but the second=20 > paragraph states that this is performed by the SBE. Which is=20 > it? The third paragraph also says the SF can process SDP=20 > payloads, which makes it a B2BUA. As I understand it, a=20 > B2BUA includes an SF (two actually) but an SF does not=20 > include a B2BUA. >=20 > I think the problem is that this section is really describing=20 > the SBE, which includes one or more signaling functions. =20 > Calling it the SF just confuses the issue - or at least it=20 > confuses me. Why not just call a spade a spade, and write=20 > this section as the SBE that can include signaling function,=20 > modify SDP, etc. Agreed. >=20 > 9. Section 5.1.3.1.1 TLS connection > This section states that "the initiating [should be=20 > "Originating"] SSP will open ... TLS connection". I would=20 > prefer to change "will" to "can" > since there are circumstances where it is permissible to use=20 > IPSec rather than TLS. >=20 > 10. Section 5.1.3.1.3 Co-Location > Says that messages "would" be sent as clear text. I think it=20 > would be better to say they "could" be sent as clear text. >=20 > 11. Sections 5.1.3.2 and 5.1.3.2.1 > Change "peer" to "SSP" - in several places. >=20 > ---- end of second comments email ----- >=20 > =20 >=20 > Jim McEachern > T:+1 613 763-3419 > M:+1 613 853-0176 >=20 >=20 From HKaplan@acmepacket.com Sat Feb 14 10:06:07 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EC0A3A67B4 for ; Sat, 14 Feb 2009 10:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNX-sr9d-6vc for ; Sat, 14 Feb 2009 10:06:06 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BB9C53A6C2C for ; Sat, 14 Feb 2009 10:06:05 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 14 Feb 2009 13:04:53 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 14 Feb 2009 13:04:53 -0500 From: Hadriel Kaplan To: Richard Shockey , 'Daryl Malas' , "'Elwell, John'" , "speermint@ietf.org" Date: Sat, 14 Feb 2009 13:04:52 -0500 Thread-Topic: [Speermint] Problem: SIP Interoperability between Peers Thread-Index: AcmGIlgRBjX9+QL7TDKFiJizRmNVqAACSOPQAB4avvAAD01V8AABuRSAAhGRR0A= Message-ID: References: <160DE07A1C4F8E4AA2715DEC577DA491B1B073@srvxchg3.cablelabs.com> <01af01c9862c$02c863e0$08592ba0$@us> <0D5F89FAC29E2C41B98A6A762007F5D0017FB44F@GBNTHT12009MSX.gb002.siemens.net> <160DE07A1C4F8E4AA2715DEC577DA491B1B082@srvxchg3.cablelabs.com> <010b01c986ee$10082f00$30188d00$@us> In-Reply-To: <010b01c986ee$10082f00$30188d00$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Speermint] Problem: SIP Interoperability between Peers X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 18:06:07 -0000 > -----Original Message----- > From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On > Behalf Of Richard Shockey > > SIPit is still the principal mechanism to test SIP interoperability but > SSP > have not been strong participants there either, nor have they used their > 'power of the wallet' to force their vendors to comply with many of the > relevant and important RFC's that would ease the interoperability issues. > There has been a everlasting discussion within the SIPforum on formalized > SIP compliance testing ( much like ASCII in RFC's) with no consensus amon= g > the participant members. Cost to the vendor community is the core problem= . Sipit is a great event to test product implementations for specific RFC mec= hanisms, but it does nothing to validate interoperability of multiple SIP d= omains' worth of deployed equipment with each other. (nor is that it's goal= , obviously) Part of the problem is the large installed base of legacy equ= ipment, part of it is the large installed base of vendors who don't go to s= ipit. But the real biggie is most equipment can be provisioned to do diffe= rent things when deployed, which has nothing to do with what gets tested in= an interop event, and you can't tell the other peer to change how their eq= uipment is provisioned inside their network. For example take just one of the myriad of common interop issues: PRACK. P= RACK itself causes interop issues due to SDP offer/answer complexity, but t= he major issue is when one operator requires PRACK because they believe it = provides a superior user experience, while another operator will not allow = PRACK because it causes them internal interop issues (ie, calls fail). The= current solution is to have a middlebox "interwork" the two policies, whic= h is just a horrible protocol solution. And I don't mean just from a proto= col purism perspective - it actually means the middlebox has to create an S= DP answer out of thin air for some calls, choosing codecs/media/etc. on beh= alf of the ultimate UAS, which is seriously bad mojo. It gets even worse t= han that, but you get the gist. I think a profile will help, if for no other reason than to provide a commo= n set of rules for the interconnection, and put the onus of "interworking" = or "fixing" them on whichever side does not follow them, such that they are= the ones motivated to (eventually) address and correct them internally if = the fixing causes issues. But it will also help in reducing the provisioni= ng of the peering connection, which is a good thing. (it won't be 100%, but= even 50% reduction would be good, or even having several profiles) -hadriel From HKaplan@acmepacket.com Sat Feb 14 10:17:46 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25AE23A6956 for ; Sat, 14 Feb 2009 10:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRxVTJ9k39JA for ; Sat, 14 Feb 2009 10:17:45 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4B9063A67EE for ; Sat, 14 Feb 2009 10:17:45 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 14 Feb 2009 13:16:33 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 14 Feb 2009 13:16:32 -0500 From: Hadriel Kaplan To: "Elwell, John" , Richard Shockey , Daryl Malas , "speermint@ietf.org" Date: Sat, 14 Feb 2009 13:16:31 -0500 Thread-Topic: [Speermint] Problem: SIP Interoperability between Peers Thread-Index: AcmGIlgRBjX9+QL7TDKFiJizRmNVqAACSOPQAB4avvAAD01V8AABuRSAACw5gLAB5pgy4A== Message-ID: References: <160DE07A1C4F8E4AA2715DEC577DA491B1B073@srvxchg3.cablelabs.com> <01af01c9862c$02c863e0$08592ba0$@us> <0D5F89FAC29E2C41B98A6A762007F5D0017FB44F@GBNTHT12009MSX.gb002.siemens.net> <160DE07A1C4F8E4AA2715DEC577DA491B1B082@srvxchg3.cablelabs.com> <010b01c986ee$10082f00$30188d00$@us> <0D5F89FAC29E2C41B98A6A762007F5D00182CF73@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00182CF73@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Speermint] Problem: SIP Interoperability between Peers X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 18:17:46 -0000 > -----Original Message----- > From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Thursday, February 05, 2009 9:04 AM > > Have you seen Jon Peterson's proposal on the RAI mailing list for > restructuring (message posted yesterday)? It might be worth making your > concerns known on that thread. However, I still tend to agree that the > SIP Forum would be a better venue. Isn't this actually within the scope of Speermint? I can't quite tell. I = mean an interconnection profile would essentially be a BCP for peering, but= the charter makes it sound potentially out of scope. Can the chairs chime= in on that? But anyway SIP Forum has many IETF folks in it, but few service providers. = SIP Forum has Cablelabs' and a few others, but my sense is a broader base = go to the IETF, including many more from outside the US. -hadriel From Adam.Uzelac@globalcrossing.com Mon Feb 16 10:55:46 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011573A6BB7 for ; Mon, 16 Feb 2009 10:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWMfminHVAPV for ; Mon, 16 Feb 2009 10:55:45 -0800 (PST) Received: from mailsrv.ams.gblxint.com (unknown-141-roc.globalcrossing.com [209.130.177.141]) by core3.amsl.com (Postfix) with ESMTP id 40FFD3A6A73 for ; Mon, 16 Feb 2009 10:55:45 -0800 (PST) Received: from w3uspdyvs212.ams.gblxint.com (w3uspdyvs212.ams.gblxint.com [10.60.54.213]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 42F02E86D0 for ; Mon, 16 Feb 2009 13:55:42 -0500 (EST) Received: from w3uspdyvs241.ams.gblxint.com ([10.60.54.202]) by w3uspdyvs212.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Feb 2009 13:55:41 -0500 Received: from EVS20.ams.gblxint.com ([10.60.53.123]) by w3uspdyvs241.ams.gblxint.com ([10.60.54.202]) with mapi; Mon, 16 Feb 2009 13:55:41 -0500 From: "Uzelac, Adam" To: "speermint@ietf.org" Date: Mon, 16 Feb 2009 13:55:40 -0500 Thread-Topic: Updating the SPEERMINT Arch Draft... Thread-Index: AcmQaCl11Ph4b5s0QeKXUCP/R4TFXA== Message-ID: <278488ECD81E6A42A7289E84524D2A256EAFAC2C@EVS20.ams.gblxint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Feb 2009 18:55:41.0866 (UTC) FILETIME=[2A5F58A0:01C99068] Subject: [Speermint] Updating the SPEERMINT Arch Draft... X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 18:55:46 -0000 Based on email threads I will be updating the Arch draft with the following= . Please let me know if anyone has issue before I knock this out. Thanks = in advance. Below should be considered rough consensus. =20 1) TARGET in replace of TERMINATING=20 - Target SSP will be used in replace of Terminating SSP. Agreed? Anyone v= iolently disapprove? 2) Remove INITIATING SSP=20 - Originating SSP will be used, replacing any instances of 'initiating SSP= '. As the document sits today, these are both used with the same meaning. = Just settling on one descriptive term. The remainder of the issues based on feedback (mostly from James and Daryl)= will be incorporated. I just want to ensure we have rough consensus on th= e two items above, as they appear to be the most contentious. Adam Uzelac Global Crossing Director, Converged Network Architecture and Planning 585-563-4359 From D.Malas@cablelabs.com Tue Feb 17 09:25:30 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F4E43A6D15 for ; Tue, 17 Feb 2009 09:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78qe9EvPYMOE for ; Tue, 17 Feb 2009 09:25:29 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 42BEF28C12D for ; Tue, 17 Feb 2009 09:25:29 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n1HHPdul016705 for ; Tue, 17 Feb 2009 10:25:39 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 17 Feb 2009 10:25:39 -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: Tue, 17 Feb 2009 10:25:39 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491B1B0E8@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] FW: 74th IETF - DRAFT Agenda Thread-Index: AcmORg7mzfhQHUFRTQ2qaUprOBuQBQC3XGqw From: "Daryl Malas" To: X-Approved: ondar Subject: [Speermint] FW: 74th IETF - DRAFT Agenda X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 17:25:30 -0000 All, The 74th IETF is quickly approaching. Currently, Speermint is scheduled to meet Tuesday during the "Afternoon Session II" from 1520 - 1700. As always, this is tentative, so keep checking back for further updates. Also, it should be noted there are some RAI meetings during the afternoon on Friday. This is also a good time to consider the updates that you may need to make to current drafts and to initiate or continue discussions on the mailing list prior to the meeting. We look forward to seeing you all there. Regards, Daryl=20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IETF Agenda Sent: Friday, February 13, 2009 7:47 PM To: IETF Announcement list Subject: 74th IETF - DRAFT Agenda=20 The Draft agenda is now available at: https://datatracker.ietf.org/meeting/74/agenda.html Online registration for the IETF meeting is at: http://www.ietf.org/meetings/74/ Only 36 days until the San Francisco IETF!=20 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From D.Malas@cablelabs.com Tue Feb 17 09:35:23 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87913A6A67 for ; Tue, 17 Feb 2009 09:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzLvX-JCYe90 for ; Tue, 17 Feb 2009 09:35:23 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id F3C5C3A68AC for ; Tue, 17 Feb 2009 09:35:22 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n1HHZOds017617; Tue, 17 Feb 2009 10:35:24 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 17 Feb 2009 10:35:25 -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: Tue, 17 Feb 2009 10:35:25 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491B1B0EA@srvxchg3.cablelabs.com> In-Reply-To: <278488ECD81E6A42A7289E84524D2A256EAFAC2C@EVS20.ams.gblxint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Updating the SPEERMINT Arch Draft... Thread-Index: AcmQaCl11Ph4b5s0QeKXUCP/R4TFXAAvb/jQ References: <278488ECD81E6A42A7289E84524D2A256EAFAC2C@EVS20.ams.gblxint.com> From: "Daryl Malas" To: "Uzelac, Adam" , X-Approved: ondar Subject: [Speermint] RE: Updating the SPEERMINT Arch Draft... X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 17:35:23 -0000 Adam, Feedback in-line... ---------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com =20 > -----Original Message----- > From: speermint-bounces@ietf.org=20 > [mailto:speermint-bounces@ietf.org] On Behalf Of Uzelac, Adam > Sent: Monday, February 16, 2009 11:56 AM > To: speermint@ietf.org > Subject: [Speermint] Updating the SPEERMINT Arch Draft... >=20 > Based on email threads I will be updating the Arch draft with=20 > the following. Please let me know if anyone has issue before=20 > I knock this out. Thanks in advance. Below should be=20 > considered rough consensus. =20 >=20 > 1) TARGET in replace of TERMINATING=20 > - Target SSP will be used in replace of Terminating=20 > SSP. Agreed? Anyone violently disapprove? Agreed. >=20 > 2) Remove INITIATING SSP=20 > - Originating SSP will be used, replacing any instances=20 > of 'initiating SSP'. As the document sits today, these are=20 > both used with the same meaning. Just settling on one=20 > descriptive term. Agreed. >=20 > The remainder of the issues based on feedback (mostly from=20 > James and Daryl) will be incorporated. I just want to ensure=20 > we have rough consensus on the two items above, as they=20 > appear to be the most contentious. >=20 > Adam Uzelac > Global Crossing > Director, Converged Network Architecture and Planning > 585-563-4359 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint >=20 From JMCE@nortel.com Mon Feb 23 18:33:05 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1F43A6823 for ; Mon, 23 Feb 2009 18:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfLn6rn62TO7 for ; Mon, 23 Feb 2009 18:33:05 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E23273A657C for ; Mon, 23 Feb 2009 18:33:04 -0800 (PST) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1O2XKg19607; Tue, 24 Feb 2009 02:33:20 GMT 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 Feb 2009 21:33:12 -0500 Message-ID: In-Reply-To: <278488ECD81E6A42A7289E84524D2A256EAFAC2C@EVS20.ams.gblxint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Updating the SPEERMINT Arch Draft... Thread-Index: AcmQaCl11Ph4b5s0QeKXUCP/R4TFXAFvtl+w References: <278488ECD81E6A42A7289E84524D2A256EAFAC2C@EVS20.ams.gblxint.com> From: "James McEachern" To: "Uzelac, Adam" , Subject: Re: [Speermint] Updating the SPEERMINT Arch Draft... X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 02:33:06 -0000 Adam, I've been very delinquent in posting my final comments on the Architecture draft. If there is still time, I offer the following comments on the remainder of the document. (I will leave out any additional observations of the global replaces that have already been agreed to.) Section 5.2.1.1 This section is currently titled "Publish EMUN Records". Would it be more accurate to call this "Publish Infrastructure ENUM Records"? Section 5.2.1.2 Publish SIP DNS Records This says that we publish these records in the LF, but as I read section 5.1.1.1 it appears that we would publish them in the LRF. Section 5.2.1.3 Subscribe Notify.=20 The most recent reference that I can find to this document is from October 2006. Do we really want to mention it here when it seems to have gone cold? Section 7. Address space considerations. We might consider deleting the following from this paragraph: Delete "which is defined by the federation". I think it still works without this bit. That's it for me. =20 Jim McEachern T:+1 613 763-3419 M:+1 613 853-0176 -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Uzelac, Adam Sent: Monday, February 16, 2009 1:56 PM To: speermint@ietf.org Subject: [Speermint] Updating the SPEERMINT Arch Draft... Based on email threads I will be updating the Arch draft with the following. Please let me know if anyone has issue before I knock this out. Thanks in advance. Below should be considered rough consensus. =20 1) TARGET in replace of TERMINATING=20 - Target SSP will be used in replace of Terminating SSP. Agreed? Anyone violently disapprove? 2) Remove INITIATING SSP=20 - Originating SSP will be used, replacing any instances of 'initiating SSP'. As the document sits today, these are both used with the same meaning. Just settling on one descriptive term. The remainder of the issues based on feedback (mostly from James and Daryl) will be incorporated. I just want to ensure we have rough consensus on the two items above, as they appear to be the most contentious. Adam Uzelac Global Crossing Director, Converged Network Architecture and Planning 585-563-4359 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www.ietf.org/mailman/listinfo/speermint From JMCE@nortel.com Mon Feb 23 18:38:15 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777A528C1D2 for ; Mon, 23 Feb 2009 18:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm5WPe-A3GEX for ; Mon, 23 Feb 2009 18:38:14 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 50BBB3A69FE for ; Mon, 23 Feb 2009 18:38:14 -0800 (PST) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n1O2YFV15805; Tue, 24 Feb 2009 02:34:15 GMT 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 Feb 2009 21:38:27 -0500 Message-ID: In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA491B1B0BE@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Meeting minutes from IETF 73 Speermint session (Arch Draft Review) Thread-Index: AclheIM6vfcHtNx+S0q4AzvQWgZd6QeqtZlgAX4X54AAQ/+AoABh4NrwA11RizA= References: <160DE07A1C4F8E4AA2715DEC577DA491B1AF74@srvxchg3.cablelabs.com> <160DE07A1C4F8E4AA2715DEC577DA491B1B072@srvxchg3.cablelabs.com> <160DE07A1C4F8E4AA2715DEC577DA491B1B0BE@srvxchg3.cablelabs.com> From: "James McEachern" To: "Daryl Malas" , Subject: Re: [Speermint] Meeting minutes from IETF 73 Speermint session (Arch Draft Review) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 02:38:15 -0000 Daryl, Comment inline... Jim McEachern T:+1 613 763-3419 M:+1 613 853-0176 -----Original Message----- From: Daryl Malas [mailto:D.Malas@cablelabs.com]=20 Sent: Friday, February 06, 2009 7:15 PM To: McEachern, James (CAR:AR00); speermint@ietf.org Subject: RE: [Speermint] RE: Meeting minutes from IETF 73 Speermint session (Arch Draft Review)=20 Jim et. al., Comments in-line... ---------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com =20 > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com]=20 > Sent: Wednesday, February 04, 2009 8:24 PM > To: Daryl Malas; speermint@ietf.org > Subject: RE: [Speermint] RE: Meeting minutes from IETF 73=20 > Speermint session (Arch Draft Review)=20 >=20 -------- snip ------------- >=20 > 7. Section 5.1.2.3 SIP Redirect Server > I am not at all certain this section adds value. I would delete it. I think the reason why this is in here is that a SIP Redirect is a very viable alternative to ENUM. One of the challenges this and several Speermint documents face is placing too much emphasis on the use of ENUM in peering. While I believe this is a very efficient way for SSPs to peer, not all SSPs are ready or plan to utilize ENUM. What is a better recommendation for documenting a very valid approach to peering simply by using the constructs in SIP? [jmce] Fair enough - I'm happy to leave it. My hesitation was that the trick is how you set up the magic database that the SIP Redirect Server uses to find the route. But I guess you could say exactly the same about the magic used to populate ENUM. So I'm fine with it as is.